- 05 Jun, 2017 29 commits
-
-
Rafał Miłecki authored
commit a971df0b upstream. This allows tracking device state and e.g. makes devm work as expected. Signed-off-by:
Rafał Miłecki <rafal@milecki.pl> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Jan Kara authored
commit 3b136499 upstream. ext4_journalled_write_end() did not propely handle all the cases when generic_perform_write() did not copy all the data into the target page and could mark buffers with uninitialized contents as uptodate and dirty leading to possible data corruption (which would be quickly fixed by generic_perform_write() retrying the write but still). Fix the problem by carefully handling the case when the page that is written to is not uptodate. Reported-by:
Al Viro <viro@ZenIV.linux.org.uk> Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Theodore Ts'o <tytso@mit.edu> [bwh: Backported to 3.2: adjust context] Signed-off-by:
-
Theodore Ts'o authored
commit b90197b6 upstream. If there is a error while copying data from userspace into the page cache during a write(2) system call, in data=journal mode, in ext4_journalled_write_end() were using page_zero_new_buffers() from fs/buffer.c. Unfortunately, this sets the buffer dirty flag, which is no good if journalling is enabled. This is a long-standing bug that goes back for years and years in ext3, but a combination of (a) data=journal not being very common, (b) in many case it only results in a warning message. and (c) only very rarely causes the kernel hang, means that we only really noticed this as a problem when commit 998ef75d caused this failure to happen frequently enough to cause generic/208 to fail when run in data=journal mode. The fix is to have our own version of this function that doesn't call mark_dirty_buffer(), since we will end up calling ext4_handle_dirty_metadata() on the buffer head(s) in questions very shortly afterwards in ext4_journalled_write_end(). Thanks to Dave Hansen and Linus Torvalds for helping to identify the root cause of the problem. Signed-off-by:
Jan Kara <jack@suse.com> [bwh: Backported to 3.2: adjust context, indentation] Signed-off-by:
-
Jan Kara authored
commit cd648b8a upstream. If filesystem groups are artifically small (using parameter -g to mkfs.ext4), ext4_mb_normalize_request() can result in a request that is larger than a block group. Trim the request size to not confuse allocation code. Reported-by:
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> Signed-off-by:
-
Alex Deucher authored
commit a882f5de upstream. The vfct table can contain multiple vbios images if the platform contains multiple GPUs. Noticed by netkas on phoronix forums. This patch fixes those platforms. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> [bwh: Backported to 3.2: adjust context] Signed-off-by:
-
Michel Dänzer authored
commit 239ac65f upstream. The current caching state may not be tt_cached, even though the placement contains TTM_PL_FLAG_CACHED, because placement can contain multiple caching flags. Trying to swap out such a BO would trip up the BUG_ON(ttm->caching_state != tt_cached); in ttm_tt_swapout. Signed-off-by:
Michel Dänzer <michel.daenzer@amd.com> Reviewed-by:
Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Christian König <christian.koenig@amd.com>. Reviewed-by:
Sinclair Yeh <syeh@vmware.com> Signed-off-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Johan Hovold authored
commit c6dce262 upstream. Since commit 557aaa7f ("ft232: support the ASYNC_LOW_LATENCY flag") the FTDI driver has been using a receive latency-timer value of 1 ms instead of the device default of 16 ms. The latency timer is used to periodically empty a non-full receive buffer, but a status header is always sent when the timer expires including when the buffer is empty. This means that a two-byte bulk message is received every millisecond also for an otherwise idle port as long as it is open. Let's restore the pre-2009 behaviour which reduces the rate of the status messages to 1/16th (e.g. interrupt frequency drops from 1 kHz to 62.5 Hz) by not setting ASYNC_LOW_LATENCY by default. Anyone willing to pay the price for the minimum-latency behaviour should set the flag explicitly instead using the TIOCSSERIAL ioctl or a tool such as setserial (e.g. setserial /dev/ttyUSB0 low_latency). Note that since commit 0cbd81a9 ("USB: ftdi_sio: remove tty->low_latency") the ASYNC_LOW_LATENCY flag has no other effects but to set a minimal latency timer. Reported-by:
Antoine Aubert <a.aubert@overkiz.com> Fixes: 557aaa7f ("ft232: support the ASYNC_LOW_LATENCY flag") Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Arnd Bergmann authored
commit 8c9b23ff upstream. A clean mips64 build produces no output except for two lines: Checking missing-syscalls for N32 Checking missing-syscalls for O32 On other architectures, there is no output at all, so let's do the same here for the sake of build testing. The 'kecho' macro is used to print the message on a normal build but skip it with 'make -s'. Fixes: e48ce6b8 ("[MIPS] Simplify missing-syscalls for N32 and O32") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Cc: Paul Burton <paul.burton@imgtec.com> Cc: Matt Redfearn <matt.redfearn@imgtec.com> Cc: Huacai Chen <chenhc@lemote.com> Cc: Maarten ter Huurne <maarten@treewalker.org> Cc: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/15040/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
Krzysztof Opasiak authored
commit 33e4c1a9 upstream. As IN request has to be allocated in set_alt() and released in disable() we cannot use mutex to protect it as we cannot sleep in those funcitons. Let's replace this mutex with a spinlock. Tested-by:
David Lechner <david@lechnology.com> Signed-off-by:
Krzysztof Opasiak <k.opasiak@samsung.com> Signed-off-by:
Felipe Balbi <felipe.balbi@linux.intel.com> [bwh: Backported to 3.2: adjust filename, context] Signed-off-by:
-
Felipe Balbi authored
commit ffb80fc6 upstream. At least macOS seems to be sending ClearFeature(ENDPOINT_HALT) to endpoints which aren't Halted. This makes DWC3's CLEARSTALL command time out which causes several issues for the driver. Instead, let's just return 0 and bail out early. Signed-off-by:
-
Brian Norris authored
commit 6183468a upstream. Similar to commit fcd2042e ("mwifiex: printk() overflow with 32-byte SSIDs"), we failed to account for the existence of 32-char SSIDs in our debugfs code. Unlike in that case though, we zeroed out the containing struct first, and I'm pretty sure we're guaranteed to have some padding after the 'ssid.ssid' and 'ssid.ssid_len' fields (the struct is 33 bytes long). So, this is the difference between: # cat /sys/kernel/debug/mwifiex/mlan0/info ... essid="0123456789abcdef0123456789abcdef " ... and the correct output: # cat /sys/kernel/debug/mwifiex/mlan0/info ... essid="0123456789abcdef0123456789abcdef" ... Fixes: 5e6e3a92 ("wireless: mwifiex: initial commit for Marvell mwifiex driver") Signed-off-by:
Brian Norris <briannorris@chromium.org> Signed-off-by:
-
Michael Petlan authored
commit 5c64f99b upstream. The "--dump-raw-script" is not a valid option, replace it with the valid one, "--dump-raw-trace" Signed-off-by:
Michael Petlan <mpetlan@redhat.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Fixes: 133dc4c3 ("perf: Rename 'perf trace' to 'perf script'") LPU-Reference: 728644547.14560155.1484320012612.JavaMail.zimbra@redhat.com Signed-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Arnd Bergmann authored
commit 6e017006 upstream. gcc-7 detects that wlanhdr_to_ethhdr() in two drivers calls memcpy() with a destination argument that an earlier function call may have set to NULL: staging/rtl8188eu/core/rtw_recv.c: In function 'wlanhdr_to_ethhdr': staging/rtl8188eu/core/rtw_recv.c:1318:2: warning: argument 1 null where non-null expected [-Wnonnull] staging/rtl8712/rtl871x_recv.c: In function 'r8712_wlanhdr_to_ethhdr': staging/rtl8712/rtl871x_recv.c:649:2: warning: argument 1 null where non-null expected [-Wnonnull] I'm fixing this by adding a NULL pointer check and returning failure from the function, which is hopefully already handled properly. This seems to date back to when the drivers were originally added, so backporting the fix to stable seems appropriate. There are other related realtek drivers in the kernel, but none of them contain a function with a similar name or produce this warning. Fixes: 1cc18a22 ("staging: r8188eu: Add files for new driver - part 5") Fixes: 2865d42c ("staging: r8712u: Add the new driver to the mainline kernel") Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> [bwh: Backported to 3.2: drop changes to r8188eu] Signed-off-by:
-
Johan Hovold authored
commit 39712e8b upstream. Make sure to detect and return an error on zero-length control-message transfers when reading from the device. This addresses a potential failure to detect an empty transmit buffer during close. Also remove a redundant check for short transfer when sending a command. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Reviewed-by:
-
Johan Hovold authored
commit 1eac5c24 upstream. Make sure to detect short control-message transfers rather than continue with zero-initialised data when retrieving modem status and during device initialisation. Fixes: 52af9545 ("USB: add USB serial ssu100 driver") Reviewed-by:
-
Johan Hovold authored
commit 36356a66 upstream. Make sure to detect short control-message transfers so that errors are logged when reading the modem status at open. Note that while this also avoids initialising the modem status using uninitialised heap data, these bits could not leak to user space as they are currently not used. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Reviewed-by:
-
Johan Hovold authored
commit 3c0e25d8 upstream. Make sure to detect short control-message transfers and log an error when reading incomplete manufacturer and boot descriptors. Note that the default all-zero descriptors will now be used after a short transfer is detected instead of partially initialised ones. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Reviewed-by:
-
Johan Hovold authored
commit e4457d97 upstream. Use a dedicated buffer for the DMA transfer and make sure to detect short transfers to avoid parsing a corrupt descriptor. Fixes: 6e8cf775 ("USB: add EPIC support to the io_edgeport driver") Reviewed-by:
-
Johan Hovold authored
commit e3e574ad upstream. Make sure to detect short responses when reading the latency timer to avoid using stale buffer data. Note that no heap data would currently leak through sysfs as ASYNC_LOW_LATENCY is set by default. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Reviewed-by:
-
Johan Hovold authored
commit 427c3a95 upstream. Make sure to detect short responses when fetching the modem status in order to avoid parsing uninitialised buffer data and having bits of it leak to user space. Note that we still allow for short 1-byte responses. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Reviewed-by:
-
Johan Hovold authored
commit b631433b upstream. Fix open error handling which failed to detect errors when reading the MSR and LSR registers, something which could lead to the shadow registers being initialised from errnos. Note that calling the generic close implementation is sufficient in the error paths as the interrupt urb has not yet been submitted and the register updates have not been made. Fixes: f4c1e8d5 ("USB: ark3116: Make existing functions 16450-aware and add close and release functions.") Reviewed-by:
-
Johan Hovold authored
commit 9fef37d7 upstream. The current implementation failed to detect short transfers, something which could lead to bits of the uninitialised heap transfer buffer leaking to user space. Fixes: 149fc791 ("USB: ark3116: Setup some basic infrastructure for new ark3116 driver.") Fixes: f4c1e8d5 ("USB: ark3116: Make existing functions 16450-aware and add close and release functions.") Reviewed-by:
-
Johan Hovold authored
commit a0467a96 upstream. The modem-status register was read as part of device configuration at port_probe and then again at open (and reset-resume). During open (and reset-resume) the MSR was read before submitting the interrupt URB, something which could lead to an MSR-change going unnoticed when it races with open (reset-resume). Fix this by dropping the redundant reconfiguration of the port at every open, and only read the MSR after the interrupt URB has been submitted. Fixes: 664d5df9 ("USB: usb-serial ch341: support for DTR/RTS/CTS") Signed-off-by:
-
Feras Daoud authored
commit 27d41d29 upstream. Since ipoib_cm_tx_start function and ipoib_cm_tx_reap function belong to different work queues, they can run in parallel. In this case if ipoib_cm_tx_reap calls list_del and release the lock, ipoib_cm_tx_start may acquire it and call list_del_init on the already deleted object. Changing list_del to list_del_init in ipoib_cm_tx_reap fixes the problem. Fixes: 839fcaba ("IPoIB: Connected mode experimental support") Signed-off-by:
Feras Daoud <ferasda@mellanox.com> Signed-off-by:
Erez Shitrit <erezsh@mellanox.com> Reviewed-by:
Alex Vesker <valex@mellanox.com> Signed-off-by:
Leon Romanovsky <leon@kernel.org> Reviewed-by:
Yuval Shaia <yuval.shaia@oracle.com> Signed-off-by:
Doug Ledford <dledford@redhat.com> Signed-off-by:
-
Feras Daoud authored
commit 80b5b35a upstream. When changing the connection mode, the ipoib_set_mode function did not check if the previous connection mode equals to the new one. This commit adds the required check and return 0 if the new mode equals to the previous one. Fixes: 839fcaba ("IPoIB: Connected mode experimental support") Signed-off-by:
-
Jason Gunthorpe authored
commit 55efcfcd upstream. The RDMA core uses ib_pack() to convert from unpacked CPU structs to on-the-wire bitpacked structs. This process requires that 1 bit fields are declared as u8 in the unpacked struct, otherwise the packing process does not read the value properly and the packed result is wired to 0. Several places wrongly used int. Crucially this means the kernel has never, set reversible correctly in the path record request. It has always asked for irreversible paths even if the ULP requests otherwise. When the kernel is used with a SM that supports this feature, it completely breaks communication management if reversible paths are not properly requested. The only reason this ever worked is because opensm ignores the reversible bit. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Signed-off-by:
-
Felix Fietkau authored
commit a70e1d6f upstream. Simply return -EOPNOTSUPP instead. Signed-off-by:
Felix Fietkau <nbd@nbd.name> Signed-off-by:
Kalle Valo <kvalo@qca.qualcomm.com> Signed-off-by:
-
Javier Martinez Canillas authored
commit abe81f3b upstream. If the driver is built as a module, autoload won't work because the module alias information is not filled. So user-space can't match the registered device with the corresponding module. Export the module alias information using the MODULE_DEVICE_TABLE() macro. Before this patch: $ modinfo drivers/tty/serial/msm_serial.ko | grep alias $ After this patch: $ modinfo drivers/tty/serial/msm_serial.ko | grep alias alias: of:N*T*Cqcom,msm-uartdmC* alias: of:N*T*Cqcom,msm-uartdm alias: of:N*T*Cqcom,msm-uartC* alias: of:N*T*Cqcom,msm-uart Signed-off-by:
Javier Martinez Canillas <javier@osg.samsung.com> Acked-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
-
Dan Carpenter authored
commit c705a6b3 upstream. We accidentally return success when adm8211_alloc_rings() fails but we should preserve the error code. Fixes: cc0b88cf ("[PATCH] Add adm8211 802.11b wireless driver") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
- 04 Apr, 2017 5 commits
-
-
Ben Hutchings authored
-
Ben Hutchings authored
The "dead" key type has no match operation, and a search for keys of this type can cause a null dereference in keyring_search_aux(). keyring_search() has a check for this, but request_keyring_and_link() does not. Move the check into keyring_search_aux(), covering both of them. This was fixed upstream by commit c06cfb08 ("KEYS: Remove key_type::match in favour of overriding default by match_preparse"), part of a series of large changes that are not suitable for backporting. CVE-2017-2647 / CVE-2017-6951 Reported-by:
Igor Redko <redkoi@virtuozzo.com> Reported-by:
Andrey Ryabinin <aryabinin@virtuozzo.com> References: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2017-2647Reported-by:
idl3r <idler1984@gmail.com> References: https://www.spinics.net/lists/keyrings/msg01845.htmlSigned-off-by:
-
Guillaume Nault authored
commit 32c23116 upstream. Lock socket before checking the SOCK_ZAPPED flag in l2tp_ip6_bind(). Without lock, a concurrent call could modify the socket flags between the sock_flag(sk, SOCK_ZAPPED) test and the lock_sock() call. This way, a socket could be inserted twice in l2tp_ip6_bind_table. Releasing it would then leave a stale pointer there, generating use-after-free errors when walking through the list or modifying adjacent entries. BUG: KASAN: use-after-free in l2tp_ip6_close+0x22e/0x290 at addr ffff8800081b0ed8 Write of size 8 by task syz-executor/10987 CPU: 0 PID: 10987 Comm: syz-executor Not tainted 4.8.0+ #39 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014 ffff880031d97838 ffffffff829f835b ffff88001b5a1640 ffff8800081b0ec0 ffff8800081b15a0 ffff8800081b6d20 ffff880031d97860 ffffffff8174d3cc ffff880031d978f0 ffff8800081b0e80 ffff88001b5a1640 ffff880031d978e0 Call Trace: [<ffffffff829f835b>] dump_stack+0xb3/0x118 lib/dump_stack.c:15 [<ffffffff8174d3cc>] kasan_object_err+0x1c/0x70 mm/kasan/report.c:156 [< inline >] print_address_description mm/kasan/report.c:194 [<ffffffff8174d666>] kasan_report_error+0x1f6/0x4d0 mm/kasan/report.c:283 [< inline >] kasan_report mm/kasan/report.c:303 [<ffffffff8174db7e>] __asan_report_store8_noabort+0x3e/0x40 mm/kasan/report.c:329 [< inline >] __write_once_size ./include/linux/compiler.h:249 [< inline >] __hlist_del ./include/linux/list.h:622 [< inline >] hlist_del_init ./include/linux/list.h:637 [<ffffffff8579047e>] l2tp_ip6_close+0x22e/0x290 net/l2tp/l2tp_ip6.c:239 [<ffffffff850b2dfd>] inet_release+0xed/0x1c0 net/ipv4/af_inet.c:415 [<ffffffff851dc5a0>] inet6_release+0x50/0x70 net/ipv6/af_inet6.c:422 [<ffffffff84c4581d>] sock_release+0x8d/0x1d0 net/socket.c:570 [<ffffffff84c45976>] sock_close+0x16/0x20 net/socket.c:1017 [<ffffffff817a108c>] __fput+0x28c/0x780 fs/file_table.c:208 [<ffffffff817a1605>] ____fput+0x15/0x20 fs/file_table.c:244 [<ffffffff813774f9>] task_work_run+0xf9/0x170 [<ffffffff81324aae>] do_exit+0x85e/0x2a00 [<ffffffff81326dc8>] do_group_exit+0x108/0x330 [<ffffffff81348cf7>] get_signal+0x617/0x17a0 kernel/signal.c:2307 [<ffffffff811b49af>] do_signal+0x7f/0x18f0 [<ffffffff810039bf>] exit_to_usermode_loop+0xbf/0x150 arch/x86/entry/common.c:156 [< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:190 [<ffffffff81006060>] syscall_return_slowpath+0x1a0/0x1e0 arch/x86/entry/common.c:259 [<ffffffff85e4d726>] entry_SYSCALL_64_fastpath+0xc4/0xc6 Object at ffff8800081b0ec0, in cache L2TP/IPv6 size: 1448 Allocated: PID = 10987 [ 1116.897025] [<ffffffff811ddcb6>] save_stack_trace+0x16/0x20 [ 1116.897025] [<ffffffff8174c736>] save_stack+0x46/0xd0 [ 1116.897025] [<ffffffff8174c9ad>] kasan_kmalloc+0xad/0xe0 [ 1116.897025] [<ffffffff8174cee2>] kasan_slab_alloc+0x12/0x20 [ 1116.897025] [< inline >] slab_post_alloc_hook mm/slab.h:417 [ 1116.897025] [< inline >] slab_alloc_node mm/slub.c:2708 [ 1116.897025] [< inline >] slab_alloc mm/slub.c:2716 [ 1116.897025] [<ffffffff817476a8>] kmem_cache_alloc+0xc8/0x2b0 mm/slub.c:2721 [ 1116.897025] [<ffffffff84c4f6a9>] sk_prot_alloc+0x69/0x2b0 net/core/sock.c:1326 [ 1116.897025] [<ffffffff84c58ac8>] sk_alloc+0x38/0xae0 net/core/sock.c:1388 [ 1116.897025] [<ffffffff851ddf67>] inet6_create+0x2d7/0x1000 net/ipv6/af_inet6.c:182 [ 1116.897025] [<ffffffff84c4af7b>] __sock_create+0x37b/0x640 net/socket.c:1153 [ 1116.897025] [< inline >] sock_create net/socket.c:1193 [ 1116.897025] [< inline >] SYSC_socket net/socket.c:1223 [ 1116.897025] [<ffffffff84c4b46f>] SyS_socket+0xef/0x1b0 net/socket.c:1203 [ 1116.897025] [<ffffffff85e4d685>] entry_SYSCALL_64_fastpath+0x23/0xc6 Freed: PID = 10987 [ 1116.897025] [<ffffffff811ddcb6>] save_stack_trace+0x16/0x20 [ 1116.897025] [<ffffffff8174c736>] save_stack+0x46/0xd0 [ 1116.897025] [<ffffffff8174cf61>] kasan_slab_free+0x71/0xb0 [ 1116.897025] [< inline >] slab_free_hook mm/slub.c:1352 [ 1116.897025] [< inline >] slab_free_freelist_hook mm/slub.c:1374 [ 1116.897025] [< inline >] slab_free mm/slub.c:2951 [ 1116.897025] [<ffffffff81748b28>] kmem_cache_free+0xc8/0x330 mm/slub.c:2973 [ 1116.897025] [< inline >] sk_prot_free net/core/sock.c:1369 [ 1116.897025] [<ffffffff84c541eb>] __sk_destruct+0x32b/0x4f0 net/core/sock.c:1444 [ 1116.897025] [<ffffffff84c5aca4>] sk_destruct+0x44/0x80 net/core/sock.c:1452 [ 1116.897025] [<ffffffff84c5ad33>] __sk_free+0x53/0x220 net/core/sock.c:1460 [ 1116.897025] [<ffffffff84c5af23>] sk_free+0x23/0x30 net/core/sock.c:1471 [ 1116.897025] [<ffffffff84c5cb6c>] sk_common_release+0x28c/0x3e0 ./include/net/sock.h:1589 [ 1116.897025] [<ffffffff8579044e>] l2tp_ip6_close+0x1fe/0x290 net/l2tp/l2tp_ip6.c:243 [ 1116.897025] [<ffffffff850b2dfd>] inet_release+0xed/0x1c0 net/ipv4/af_inet.c:415 [ 1116.897025] [<ffffffff851dc5a0>] inet6_release+0x50/0x70 net/ipv6/af_inet6.c:422 [ 1116.897025] [<ffffffff84c4581d>] sock_release+0x8d/0x1d0 net/socket.c:570 [ 1116.897025] [<ffffffff84c45976>] sock_close+0x16/0x20 net/socket.c:1017 [ 1116.897025] [<ffffffff817a108c>] __fput+0x28c/0x780 fs/file_table.c:208 [ 1116.897025] [<ffffffff817a1605>] ____fput+0x15/0x20 fs/file_table.c:244 [ 1116.897025] [<ffffffff813774f9>] task_work_run+0xf9/0x170 [ 1116.897025] [<ffffffff81324aae>] do_exit+0x85e/0x2a00 [ 1116.897025] [<ffffffff81326dc8>] do_group_exit+0x108/0x330 [ 1116.897025] [<ffffffff81348cf7>] get_signal+0x617/0x17a0 kernel/signal.c:2307 [ 1116.897025] [<ffffffff811b49af>] do_signal+0x7f/0x18f0 [ 1116.897025] [<ffffffff810039bf>] exit_to_usermode_loop+0xbf/0x150 arch/x86/entry/common.c:156 [ 1116.897025] [< inline >] prepare_exit_to_usermode arch/x86/entry/common.c:190 [ 1116.897025] [<ffffffff81006060>] syscall_return_slowpath+0x1a0/0x1e0 arch/x86/entry/common.c:259 [ 1116.897025] [<ffffffff85e4d726>] entry_SYSCALL_64_fastpath+0xc4/0xc6 Memory state around the buggy address: ffff8800081b0d80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff8800081b0e00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff8800081b0e80: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb ^ ffff8800081b0f00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8800081b0f80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== The same issue exists with l2tp_ip_bind() and l2tp_ip_bind_table. Fixes: c51ce497 ("l2tp: fix oops in L2TP IP sockets for connect() AF_UNSPEC case") Reported-by:
Baozeng Ding <sploving1@gmail.com> Reported-by:
Andrey Konovalov <andreyknvl@google.com> Tested-by:
Guillaume Nault <g.nault@alphalink.fr> Signed-off-by:
David S. Miller <davem@davemloft.net> [bwh: Backported to 3.2: drop IPv6 changes] Signed-off-by:
-
Michal Hocko authored
This is a stable follow up fix for an incorrect backport. The issue is not present in the upstream kernel. Miroslav has noticed the following splat when testing my 3.2 forward port of 8310d48b ("mm/huge_memory.c: respect FOLL_FORCE/FOLL_COW for thp") to 3.12: BUG: Bad page state in process a.out pfn:26400 page:ffffea000085e000 count:0 mapcount:1 mapping: (null) index:0x7f049d600 page flags: 0x1fffff80108018(uptodate|dirty|head|swapbacked) page dumped because: nonzero mapcount [iii] CPU: 2 PID: 5926 Comm: a.out Tainted: G E 3.12.61-0-default #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014 0000000000000000 ffffffff81515830 ffffea000085e000 ffffffff81800ad7 ffffffff815118a5 ffffea000085e000 0000000000000000 000fffff80000000 ffffffff81140f18 fff000007c000000 ffffea000085e000 0000000000000009 Call Trace: [<ffffffff8100475d>] dump_trace+0x7d/0x2d0 [<ffffffff81004a44>] show_stack_log_lvl+0x94/0x170 [<ffffffff81005ce1>] show_stack+0x21/0x50 [<ffffffff81515830>] dump_stack+0x5d/0x78 [<ffffffff815118a5>] bad_page.part.67+0xe8/0x102 [<ffffffff81140f18>] free_pages_prepare+0x198/0x1b0 [<ffffffff81141275>] __free_pages_ok+0x15/0xd0 [<ffffffff8116444c>] __access_remote_vm+0x7c/0x1e0 [<ffffffff81205afb>] mem_rw.isra.13+0x14b/0x1a0 [<ffffffff811a3b18>] vfs_write+0xb8/0x1e0 [<ffffffff811a469b>] SyS_pwrite64+0x6b/0xa0 [<ffffffff81523b49>] system_call_fastpath+0x16/0x1b [<00007f049da18573>] 0x7f049da18572 The problem is that the original 3.2 backport didn't return NULL page on the FOLL_COW page and so the page got reused. Reported-and-tested-by:
Miroslav Beneš <mbenes@suse.com> Signed-off-by:
Michal Hocko <mhocko@suse.com> Signed-off-by:
-
Eric Dumazet authored
Upstream commit 34b2cef2 ("ipv4: keep skb->dst around in presence of IP options") incorrectly root caused commit d826eb14 ("ipv4: PKTINFO doesnt need dst reference") as bug origin. This patch should fix the issue for 3.2.xx stable kernels, since IPv4 options seem to get more traction these days, after years of oblivion ;) Fixes: f84af32c ("net: ip_queue_rcv_skb() helper")) Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
Anarcheuz Fritz <anarcheuz@gmail.com> Signed-off-by:
-
- 16 Mar, 2017 6 commits
-
-
Ben Hutchings authored
-
Alexander Popov authored
commit 82f2341c upstream. Currently N_HDLC line discipline uses a self-made singly linked list for data buffers and has n_hdlc.tbuf pointer for buffer retransmitting after an error. The commit be10eb75 ("tty: n_hdlc add buffer flushing") introduced racy access to n_hdlc.tbuf. After tx error concurrent flush_tx_queue() and n_hdlc_send_frames() can put one data buffer to tx_free_buf_list twice. That causes double free in n_hdlc_release(). Let's use standard kernel linked list and get rid of n_hdlc.tbuf: in case of tx error put current data buffer after the head of tx_buf_list. Signed-off-by:
Alexander Popov <alex.popov@linux.com> Signed-off-by:
-
Jiri Pirko authored
commit 6d7581e6 upstream. non-rcu variant of list_first_or_null_rcu Signed-off-by:
Jiri Pirko <jiri@resnulli.us> Signed-off-by:
-
Jiri Slaby authored
commit e9b736d8 upstream. The class of 4 n_hdls buf locks is the same because a single function n_hdlc_buf_list_init is used to init all the locks. But since flush_tx_queue takes n_hdlc->tx_buf_list.spinlock and then calls n_hdlc_buf_put which takes n_hdlc->tx_free_buf_list.spinlock, lockdep emits a warning: ============================================= [ INFO: possible recursive locking detected ] 4.3.0-25.g91e30a7-default #1 Not tainted --------------------------------------------- a.out/1248 is trying to acquire lock: (&(&list->spinlock)->rlock){......}, at: [<ffffffffa01fd020>] n_hdlc_buf_put+0x20/0x60 [n_hdlc] but task is already holding lock: (&(&list->spinlock)->rlock){......}, at: [<ffffffffa01fdc07>] n_hdlc_tty_ioctl+0x127/0x1d0 [n_hdlc] other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&(&list->spinlock)->rlock); lock(&(&list->spinlock)->rlock); *** DEADLOCK *** May be due to missing lock nesting notation 2 locks held by a.out/1248: #0: (&tty->ldisc_sem){++++++}, at: [<ffffffff814c9eb0>] tty_ldisc_ref_wait+0x20/0x50 #1: (&(&list->spinlock)->rlock){......}, at: [<ffffffffa01fdc07>] n_hdlc_tty_ioctl+0x127/0x1d0 [n_hdlc] ... Call Trace: ... [<ffffffff81738fd0>] _raw_spin_lock_irqsave+0x50/0x70 [<ffffffffa01fd020>] n_hdlc_buf_put+0x20/0x60 [n_hdlc] [<ffffffffa01fdc24>] n_hdlc_tty_ioctl+0x144/0x1d0 [n_hdlc] [<ffffffff814c25c1>] tty_ioctl+0x3f1/0xe40 ... Fix it by initializing the spin_locks separately. This removes also reduntand memset of a freshly kzallocated space. Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Reported-by:
Dmitry Vyukov <dvyukov@google.com> Signed-off-by:
-
Marcelo Ricardo Leitner authored
commit dfcb9f4f upstream. commit 2dcab598 ("sctp: avoid BUG_ON on sctp_wait_for_sndbuf") attempted to avoid a BUG_ON call when the association being used for a sendmsg() is blocked waiting for more sndbuf and another thread did a peeloff operation on such asoc, moving it to another socket. As Ben Hutchings noticed, then in such case it would return without locking back the socket and would cause two unlocks in a row. Further analysis also revealed that it could allow a double free if the application managed to peeloff the asoc that is created during the sendmsg call, because then sctp_sendmsg() would try to free the asoc that was created only for that call. This patch takes another approach. It will deny the peeloff operation if there is a thread sleeping on the asoc, so this situation doesn't exist anymore. This avoids the issues described above and also honors the syscalls that are already being handled (it can be multiple sendmsg calls). Joint work with Xin Long. Fixes: 2dcab598 ("sctp: avoid BUG_ON on sctp_wait_for_sndbuf") Cc: Alexander Popov <alex.popov@linux.com> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by:
Xin Long <lucien.xin@gmail.com> Signed-off-by:
-
Marcelo Ricardo Leitner authored
commit 2dcab598 upstream. Alexander Popov reported that an application may trigger a BUG_ON in sctp_wait_for_sndbuf if the socket tx buffer is full, a thread is waiting on it to queue more data and meanwhile another thread peels off the association being used by the first thread. This patch replaces the BUG_ON call with a proper error handling. It will return -EPIPE to the original sendmsg call, similarly to what would have been done if the association wasn't found in the first place. Acked-by:
-
