shumeipai #186
Open
shumeipai #186
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
commit 5f0fabf upstream. smatch found this error: CHECK drivers/net/wireless/mwifiex/join.c drivers/net/wireless/mwifiex/join.c:1121 mwifiex_cmd_802_11_ad_hoc_join() error: testing array offset 'i' after use. Signed-off-by: Bing Zhao <[email protected]> Signed-off-by: John W. Linville <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 3118a4f upstream. It is possible to wrap the counter used to allocate the buffer for relocation copies. This could lead to heap writing overflows. CVE-2013-0913 v3: collapse test, improve comment v2: move check into validate_exec_list Signed-off-by: Kees Cook <[email protected]> Reported-by: Pinkie Pie Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 16dad1d upstream. EDID spreads some values across multiple bytes; bit-fiddling is needed to retrieve these. The current code to parse "detailed timings" has a cut&paste error that results in a vsync offset of at most 15 lines instead of 63. See http://en.wikipedia.org/wiki/EDID and in the "EDID Detailed Timing Descriptor" see bytes 10+11 show why that needs to be a left shift. Signed-off-by: Torsten Duwe <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
…mit accouting commit d002858 upstream. hugetlb_total_pages is used for overcommit calculations but the current implementation considers only the default hugetlb page size (which is either the first defined hugepage size or the one specified by default_hugepagesz kernel boot parameter). If the system is configured for more than one hugepage size, which is possible since commit a137e1c ("hugetlbfs: per mount huge page sizes") then the overcommit estimation done by __vm_enough_memory() (resp. shown by meminfo_proc_show) is not precise - there is an impression of more available/allowed memory. This can lead to an unexpected ENOMEM/EFAULT resp. SIGSEGV when memory is accounted. Testcase: boot: hugepagesz=1G hugepages=1 the default overcommit ratio is 50 before patch: egrep 'CommitLimit' /proc/meminfo CommitLimit: 55434168 kB after patch: egrep 'CommitLimit' /proc/meminfo CommitLimit: 54909880 kB [[email protected]: coding-style tweak] Signed-off-by: Wanpeng Li <[email protected]> Acked-by: Michal Hocko <[email protected]> Cc: "Aneesh Kumar K.V" <[email protected]> Cc: Hillf Danton <[email protected]> Cc: KAMEZAWA Hiroyuki <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit f853c61 upstream. We've had several reports of people attempting to mount Windows 8 shares and getting failures with a return code of -EINVAL. The default sec= mode changed recently to sec=ntlmssp. With that, we expect and parse a SPNEGO blob from the server in the NEGOTIATE reply. The current decode_negTokenInit function first parses all of the mechTypes and then tries to parse the rest of the negTokenInit reply. The parser however currently expects a mechListMIC or nothing to follow the mechTypes, but Windows 8 puts a mechToken field there instead to carry some info for the new NegoEx stuff. In practice, we don't do anything with the fields after the mechTypes anyway so I don't see any real benefit in continuing to parse them. This patch just has the kernel ignore the fields after the mechTypes. We'll probably need to reinstate some of this if we ever want to support NegoEx. Reported-by: Jason Burgess <[email protected]> Reported-by: Yan Li <[email protected]> Signed-off-by: Jeff Layton <[email protected]> Signed-off-by: Steve French <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
…nt() commit 3a22567 upstream. This commit fixes a wrong return value of the number of the allocated blocks in ext4_split_extent. When the length of blocks we want to allocate is greater than the length of the current extent, we return a wrong number. Let's see what happens in the following case when we call ext4_split_extent(). map: [48, 72] ex: [32, 64, u] 'ex' will be split into two parts: ex1: [32, 47, u] ex2: [48, 64, w] 'map->m_len' is returned from this function, and the value is 24. But the real length is 16. So it should be fixed. Meanwhile in this commit we use right length of the allocated blocks when get_reserved_cluster_alloc in ext4_ext_handle_uninitialized_extents is called. Signed-off-by: Zheng Liu <[email protected]> Signed-off-by: "Theodore Ts'o" <[email protected]> Cc: Dmitry Monakhov <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 29f86e6 upstream. Device stucks on filesystem writes, unless following quirk is passed: echo 04e8:5136:m > /sys/module/usb_storage/parameters/quirks Add corresponding entry to unusual_devs.h Signed-off-by: Dmitry Artamonow <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 1ee9e2a upstream. Commit f0dc117 ("IPoIB: Fix TX queue lockup with mixed UD/CM traffic") attempts to solve an issue where unprocessed UD send completions can deadlock the netdev. The patch doesn't fully resolve the issue because if more than half the tx_outstanding's were UD and all of the destinations are RC reachable, arming the CQ doesn't solve the issue. This patch uses the IB_CQ_REPORT_MISSED_EVENTS on the ib_req_notify_cq(). If the rc is above 0, the UD send cq completion callback is called directly to re-arm the send completion timer. This issue is seen in very large parallel filesystem deployments and the patch has been shown to correct the issue. Reviewed-by: Dean Luick <[email protected]> Signed-off-by: Mike Marciniszyn <[email protected]> Signed-off-by: Roland Dreier <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit a7dc19b upstream. Currently tick_check_broadcast_device doesn't reject clock_event_devices with CLOCK_EVT_FEAT_DUMMY, and may select them in preference to real hardware if they have a higher rating value. In this situation, the dummy timer is responsible for broadcasting to itself, and the core clockevents code may attempt to call non-existent callbacks for programming the dummy, eventually leading to a panic. This patch makes tick_check_broadcast_device always reject dummy timers, preventing this problem. Signed-off-by: Mark Rutland <[email protected]> Cc: [email protected] Cc: Jon Medhurst (Tixy) <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 66db3fe upstream. The increment of "to" in copy_user_handle_tail() will have incremented before a failure has been noted. This causes us to skip a byte in the failure case. Only do the increment when assured there is no failure. Signed-off-by: CQ Tang <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Mike Marciniszyn <[email protected]> Signed-off-by: H. Peter Anvin <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit f826434 upstream. According to XHCI specification (5.5.2.1) the IP is bit 0 and IE is bit 1 of IMAN register. Previously their definitions were reversed. Even though there are no ill effects being observed from the swapped definitions (because IMAN_IP is RW1C and in legacy PCI case we come in with it already set to 1 so it was clearing itself even though we were setting IMAN_IE instead of IMAN_IP), we should still correct the values. This patch should be backported to kernels as old as 2.6.36, that contain the commit 4e833c0 "xhci: don't re-enable IE constantly". Signed-off-by: Dmitry Torokhov <[email protected]> Signed-off-by: Sarah Sharp <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit d797105 upstream. Make sure the interface is not released before our serial device. Note that drivers are still not allowed to access the interface in any way that may interfere with another driver that may have gotten bound to the same interface after disconnect returns. Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 89b1f39 upstream. For large UDF filesystems with 512-byte blocks the number of necessary bitmap blocks is larger than 2^16 so s_nr_groups in udf_bitmap overflows (the number will overflow for filesystems larger than 128 GB with 512-byte blocks). That results in ENOSPC errors despite the filesystem has plenty of free space. Fix the problem by changing s_nr_groups' type to 'int'. That is enough even for filesystems 2^32 blocks (UDF maximum) and 512-byte blocksize. Reported-and-tested-by: [email protected] Signed-off-by: Jan Kara <[email protected]> Cc: Jim Trigg <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 618aa10 upstream. Remove bogus disconnect test introduced by 95bef01 ("USB: more serial drivers writing after disconnect") which prevented queued data from being freed on disconnect. The possible IO it was supposed to prevent is long gone. Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 5492bf3 upstream. Add missing get_icount field to two-port driver. The two-port driver was not updated when switching to the new icount interface in commit 0bca1b9 ("tty: Convert the USB drivers to the new icount interface"). Signed-off-by: Johan Hovold <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit a84a921 upstream. On an error iov may still have been reallocated and need freeing Signed-off-by: Alan Cox <[email protected]> Signed-off-by: David Howells <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
… security keys commit 8aec0f5 upstream. Looking at mm/process_vm_access.c:process_vm_rw() and comparing it to compat_process_vm_rw() shows that the compatibility code requires an explicit "access_ok()" check before calling compat_rw_copy_check_uvector(). The same difference seems to appear when we compare fs/read_write.c:do_readv_writev() to fs/compat.c:compat_do_readv_writev(). This subtle difference between the compat and non-compat requirements should probably be debated, as it seems to be error-prone. In fact, there are two others sites that use this function in the Linux kernel, and they both seem to get it wrong: Now shifting our attention to fs/aio.c, we see that aio_setup_iocb() also ends up calling compat_rw_copy_check_uvector() through aio_setup_vectored_rw(). Unfortunately, the access_ok() check appears to be missing. Same situation for security/keys/compat.c:compat_keyctl_instantiate_key_iov(). I propose that we add the access_ok() check directly into compat_rw_copy_check_uvector(), so callers don't have to worry about it, and it therefore makes the compat call code similar to its non-compat counterpart. Place the access_ok() check in the same location where copy_from_user() can trigger a -EFAULT error in the non-compat code, so the ABI behaviors are alike on both compat and non-compat. While we are here, fix compat_do_readv_writev() so it checks for compat_rw_copy_check_uvector() negative return values. And also, fix a memory leak in compat_keyctl_instantiate_key_iov() error handling. Acked-by: Linus Torvalds <[email protected]> Acked-by: Al Viro <[email protected]> Signed-off-by: Mathieu Desnoyers <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit fe685aa upstream. For type 1 the parent_offset member in struct isofs_fid gets copied uninitialized to userland. Fix this by initializing it to 0. Signed-off-by: Mathias Krause <[email protected]> Signed-off-by: Jan Kara <[email protected]> Cc: Ben Hutchings <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 0143fc5 upstream. For type 0x51 the udf.parent_partref member in struct fid gets copied uninitialized to userland. Fix this by initializing it to 0. Signed-off-by: Mathias Krause <[email protected]> Signed-off-by: Jan Kara <[email protected]> Cc: Ben Hutchings <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit d627b62 upstream. This is rather a hack to fix brightness hotkeys on a Clevo laptop. CADL is not used anywhere in the driver code at the moment, but it could be used in BIOS as is the case with the Clevo laptop. The Clevo B7130 requires the CADL field to contain at least the ID of the LCD device. If this field is empty, the ACPI methods that are called on pressing brightness / display switching hotkeys will not trigger a notification. As a result, it appears as no hotkey has been pressed. Reference: https://bugs.freedesktop.org/show_bug.cgi?id=45452 Tested-by: Peter Wu <[email protected]> Signed-off-by: Peter Wu <[email protected]> Acked-by: Jesse Barnes <[email protected]> Signed-off-by: Daniel Vetter <[email protected]> Cc: Ben Hutchings <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit d740269 upstream. To avoid an explosion of request_module calls on a chain of abusive scripts, fail maximum recursion with -ELOOP instead of -ENOEXEC. As soon as maximum recursion depth is hit, the error will fail all the way back up the chain, aborting immediately. This also has the side-effect of stopping the user's shell from attempting to reexecute the top-level file as a shell script. As seen in the dash source: if (cmd != path_bshell && errno == ENOEXEC) { *argv-- = cmd; *argv = cmd = path_bshell; goto repeat; } The above logic was designed for running scripts automatically that lacked the "#!" header, not to re-try failed recursion. On a legitimate -ENOEXEC, things continue to behave as the shell expects. Additionally, when tracking recursion, the binfmt handlers should not be involved. The recursion being tracked is the depth of calls through search_binary_handler(), so that function should be exclusively responsible for tracking the depth. Signed-off-by: Kees Cook <[email protected]> Cc: halfdog <[email protected]> Cc: P J P <[email protected]> Cc: Alexander Viro <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> Cc: Ben Hutchings <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit 6ef9e2f upstream. If CONFIG_MAC80211_MESH is not set, cfg80211 will now allow advertising interface combinations with NL80211_IFTYPE_MESH_POINT present. Add appropriate ifdefs to avoid running into errors. [Backported for 3.8-stable. Removed code of simultaneous AP and mesh mode added in 4a5fc6d 3.9-rc1.] Signed-off-by: Felix Fietkau <[email protected]> Acked-by: Gertjan van Wingerde <[email protected]> Signed-off-by: John W. Linville <[email protected]> Signed-off-by: Lingzhu Xiang <[email protected]> Reviewed-by: CAI Qian <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
commit cb7da02 upstream. Since commit 8871e99 ('asus-laptop: HRWS/HWRS typo'), module initialisation is very slow on the Asus UL30A. The HWRS method takes about 12 seconds to run, and subsequent initialisation also seems to be delayed. Since we don't really need the result, don't bother calling it on init. Those who are curious can still get the result through the 'infos' device attribute. Update the comment about HWRS in show_infos(). Reported-by: ryan <[email protected]> References: http://bugs.debian.org/692436 Signed-off-by: Ben Hutchings <[email protected]> Signed-off-by: Corentin Chary <[email protected]> Signed-off-by: Matthew Garrett <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Fix oops when I tryed load bcm4330.ko wich not present in my hw
configuration:
[ 428.020000] [mmc_pm]: No sdio card, please check your config !!
[ 428.020000] Config Error: not for huawei mw269x sdio wifi module
[ 428.020000] [mmc_pm]: No sdio card, please check your config !!
[ 428.030000] kernel BUG at drivers/mmc/sunxi-host/host_op.c:585!
[ 428.050000] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[ 428.060000] pgd = d7a4c000
[ 428.070000] [00000000] *pgd=52d15831, *pte=00000000, *ppte=00000000
[ 428.080000] Internal error: Oops: 817 [#1] PREEMPT
[ 428.080000] Modules linked in: bcm4330(+) mali ump
[ 428.080000] CPU: 0 Not tainted (3.0.62+ #2)
[ 428.080000] PC is at __bug+0x24/0x30
[ 428.080000] LR is at __schedule+0x2f4/0x58c
[ 428.080000] pc : [<c00393ec>] lr : [<c04f5bd4>] psr: 400f001
[ 428.080000] sp : d2d03e48 ip : d2d03cd8 fp : d2d03e54
[ 428.080000] r10: bf06a000 r9 : c0089864 r8 : bf05b074
[ 428.080000] r7 : d2d02000 r6 : c0739b80 r5 : bf05b150 r4 : 00000002
[ 428.080000] r3 : 00000000 r2 : d2d02000 r1 : 00000002 r0 : 00000049
sdxc_prepare_pio handle invalid parameners in unusual way - it crash even when only one caller have error handling.
On some devices like (DNS Airpad M82) ts controller's power controled via MOSFET for powersaving. This patch enable power control with GPIO pin ctp_power_port in ctp_para, make touchscreen work on simular hardware configurations.
Attempting to consolidate the ARM LED code, this removes the custom RealView LED trigger code to turn LEDs on and off in response to CPU activity and replace it with a standard trigger. ([email protected]: It introduces several syscore stubs into this trigger. It also provides ledtrig_cpu trigger event stub in <linux/leds.h>. Although it was inspired by ARM work, it can be used in other arch.) Cc: Richard Purdie <[email protected]> Signed-off-by: Linus Walleij <[email protected]> Signed-off-by: Bryan Wu <[email protected]> Reviewed-by: Jamie Iles <[email protected]> Tested-by: Jochen Friedrich <[email protected]>
Seeing the following every time the CPU enters or leaves idle on a Beagleboard: BUG: sleeping function called from invalid context at kernel/mutex.c:269 in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper/0 no locks held by swapper/0/0. [<c001659c>] (unwind_backtrace+0x0/0xf8) from [<c05aaa7c>] (mutex_lock_nested+0x24/0x380) [<c05aaa7c>] (mutex_lock_nested+0x24/0x380) from [<c043bd1c>] (ledtrig_cpu+0x38/0x88) [<c043bd1c>] (ledtrig_cpu+0x38/0x88) from [<c000f4b0>] (cpu_idle+0xf4/0x120) [<c000f4b0>] (cpu_idle+0xf4/0x120) from [<c07e47c8>] (start_kernel+0x2bc/0x30c) Miles Lane has reported seeing similar splats during system suspend. The mutex in struct led_trigger_cpu appears to have no function: it resides in a per-cpu data structure which never changes after the trigger is registered. So just remove it. Reported-by: Miles Lane <[email protected]> Signed-off-by: Nathan Lynch <[email protected]> Signed-off-by: Bryan Wu <roc@roc-samos.(none)>
Backport of fa8bbb13 from Linus master. Signed-off-by: Michal Suchanek <[email protected]> Conflicts: arch/arm/kernel/process.c
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.