- 27 Aug, 2020 40 commits
-
-
Paul E. McKenney authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit 9f47eb54 ] Very large I/Os can cause the following RCU CPU stall warning: RIP: 0010:rb_prev+0x8/0x50 Code: 49 89 c0 49 89 d1 48 89 c2 48 89 f8 e9 e5 fd ff ff 4c 89 48 10 c3 4c = 89 06 c3 4c 89 40 10 c3 0f 1f 00 48 8b 0f 48 39 cf 74 38 <48> 8b 47 10 48 85 c0 74 22 48 8b 50 08 48 85 d2 74 0c 48 89 d0 48 RSP: 0018:ffffc9002212bab0 EFLAGS: 00000287 ORIG_RAX: ffffffffffffff13 RAX: ffff888821f93630 RBX: ffff888821f93630 RCX: ffff888821f937e0 RDX: 0000000000000000 RSI: 0000000000102000 RDI: ffff888821f93630 RBP: 0000000000103000 R08: 000000000006c000 R09: 0000000000000238 R10: 0000000000102fff R11: ffffc9002212bac8 R12: 0000000000000001 R13: ffffffffffffffff R14: 0000000000102000 R15: ffff888821f937e0 __lookup_extent_mapping+0xa0/0x110 try_release_extent_mapping+0xdc/0x220 btrfs_releasepage+0x45/0x70 shrink_page_list+0xa39/0xb30 shrink_inactive_list+0x18f/0x3b0 shrink_lruvec+0x38e/0x6b0 shrink_node+0x14d/0x690 do_try_to_free_pages+0xc6/0x3e0 try_to_free_mem_cgroup_pages+0xe6/0x1e0 reclaim_high.constprop.73+0x87/0xc0 mem_cgroup_handle_over_high+0x66/0x150 exit_to_usermode_loop+0x82/0xd0 do_syscall_64+0xd4/0x100 entry_SYSCALL_64_after_hwframe+0x44/0xa9 On a PREEMPT=n kernel, the try_release_extent_mapping() function's "while" loop might run for a very long time on a large I/O. This commit therefore adds a cond_resched() to this loop, providing RCU any needed quiescent states. Signed-off-by:
Paul E. McKenney <paulmck@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
Khalid Elmously <khalid.elmously@canonical.com> Signed-off-by:
Ian May <ian.may@canonical.com> Signed-off-by:
Kelsey Skunberg <kelsey.skunberg@canonical.com>
-
Lihong Kou authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit f9c70bdc ] In the case we set or free the global value listen_chan in different threads, we can encounter the UAF problems because the method is not protected by any lock, add one to avoid this bug. BUG: KASAN: use-after-free in l2cap_chan_close+0x48/0x990 net/bluetooth/l2cap_core.c:730 Read of size 8 at addr ffff888096950000 by task kworker/1:102/2868 CPU: 1 PID: 2868 Comm: kworker/1:102 Not tainted 5.5.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: events do_enable_set Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1fb/0x318 lib/dump_stack.c:118 print_address_description+0x74/0x5c0 mm/kasan/report.c:374 __kasan_report+0x149/0x1c0 mm/kasan/report.c:506 kasan_report+0x26/0x50 mm/kasan/common.c:641 __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:135 l2cap_chan_close+0x48/0x990 net/bluetooth/l2cap_core.c:730 do_enable_set+0x660/0x900 net/bluetooth/6lowpan.c:1074 process_one_work+0x7f5/0x10f0 kernel/workqueue.c:2264 worker_thread+0xbbc/0x1630 kernel/workqueue.c:2410 kthread+0x332/0x350 kernel/kthread.c:255 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 Allocated by task 2870: save_stack mm/kasan/common.c:72 [inline] set_track mm/kasan/common.c:80 [inline] __kasan_kmalloc+0x118/0x1c0 mm/kasan/common.c:515 kasan_kmalloc+0x9/0x10 mm/kasan/common.c:529 kmem_cache_alloc_trace+0x221/0x2f0 mm/slab.c:3551 kmalloc include/linux/slab.h:555 [inline] kzalloc include/linux/slab.h:669 [inline] l2cap_chan_create+0x50/0x320 net/bluetooth/l2cap_core.c:446 chan_create net/bluetooth/6lowpan.c:640 [inline] bt_6lowpan_listen net/bluetooth/6lowpan.c:959 [inline] do_enable_set+0x6a4/0x900 net/bluetooth/6lowpan.c:1078 process_one_work+0x7f5/0x10f0 kernel/workqueue.c:2264 worker_thread+0xbbc/0x1630 kernel/workqueue.c:2410 kthread+0x332/0x350 kernel/kthread.c:255 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 Freed by task 2870: save_stack mm/kasan/common.c:72 [inline] set_track mm/kasan/common.c:80 [inline] kasan_set_free_info mm/kasan/common.c:337 [inline] __kasan_slab_free+0x12e/0x1e0 mm/kasan/common.c:476 kasan_slab_free+0xe/0x10 mm/kasan/common.c:485 __cache_free mm/slab.c:3426 [inline] kfree+0x10d/0x220 mm/slab.c:3757 l2cap_chan_destroy net/bluetooth/l2cap_core.c:484 [inline] kref_put include/linux/kref.h:65 [inline] l2cap_chan_put+0x170/0x190 net/bluetooth/l2cap_core.c:498 do_enable_set+0x66c/0x900 net/bluetooth/6lowpan.c:1075 process_one_work+0x7f5/0x10f0 kernel/workqueue.c:2264 worker_thread+0xbbc/0x1630 kernel/workqueue.c:2410 kthread+0x332/0x350 kernel/kthread.c:255 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352 The buggy address belongs to the object at ffff888096950000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 0 bytes inside of 2048-byte region [ffff888096950000, ffff888096950800) The buggy address belongs to the page: page:ffffea00025a5400 refcount:1 mapcount:0 mapping:ffff8880aa400e00 index:0x0 flags: 0xfffe0000000200(slab) raw: 00fffe0000000200 ffffea00027d1548 ffffea0002397808 ffff8880aa400e00 raw: 0000000000000000 ffff888096950000 0000000100000001 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88809694ff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff88809694ff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff888096950000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888096950080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888096950100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== Reported-by: syzbot+96414aa0033c363d8458@syzkaller.appspotmail.com Signed-off-by:
Lihong Kou <koulihong@huawei.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
Tomi Valkeinen authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit 3f9c1c87 ] If videomode_from_timings() returns true, the mode allocated with drm_mode_create will be leaked. Also, the return value of drm_mode_create() is never checked, and thus could cause NULL deref. Fix these two issues. Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200429104234.18910-1-tomi.valkeinen@ti.comReviewed-by:
Jyri Sarha <jsarha@ti.com> Acked-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
-
Yu Kuai authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit 3ad7b4e8 ] if of_find_device_by_node() succeed, socfpga_setup_ocram_self_refresh doesn't have a corresponding put_device(). Thus add a jump target to fix the exception handling for this function implementation. Fixes: 44fd8c7d ("ARM: socfpga: support suspend to ram") Signed-off-by:
Yu Kuai <yukuai3@huawei.com> Signed-off-by:
Dinh Nguyen <dinguyen@kernel.org> Signed-off-by:
-
yu kuai authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit f87a4f02 ] if of_find_device_by_node() succeed, at91_pm_sram_init() doesn't have a corresponding put_device(). Thus add a jump target to fix the exception handling for this function implementation. Fixes: d2e46790 ("ARM: at91: pm: use the mmio-sram pool to access SRAM") Signed-off-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20200604123301.3905837-1-yukuai3@huawei.comSigned-off-by:
-
Finn Thain authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit 931fc82a ] When writing values to the IOP status/control register make sure those values do not have any extraneous bits that will clear interrupt flags. To place the SCC IOP into bypass mode would be desirable but this is not achieved by writing IOP_DMAINACTIVE | IOP_RUN | IOP_AUTOINC | IOP_BYPASS to the control register. Drop this ineffective register write. Remove the flawed and unused iop_bypass() function. Make use of the unused iop_stop() function. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
Finn Thain <fthain@telegraphics.com.au> Tested-by:
Stan Johnson <userm57@yahoo.com> Cc: Joshua Thompson <funaho@jurai.org> Link: https://lore.kernel.org/r/09bcb7359a1719a18b551ee515da3c4c3cf709e6.1590880333.git.fthain@telegraphics.com.auSigned-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
Finn Thain authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit aeb445bf ] In the following sequence of calls, iop_do_send() gets called when the "send" channel is not in the IOP_MSG_IDLE state: iop_ism_irq() iop_handle_send() (msg->handler)() iop_send_message() iop_do_send() Avoid this by testing the channel state before calling iop_do_send(). When sending, and iop_send_queue is empty, call iop_do_send() because the channel is idle. If iop_send_queue is not empty, iop_do_send() will get called later by iop_handle_send(). Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
-
Qiushi Wu authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit 17ed808a ] When kobject_init_and_add() returns an error, it should be handled because kobject_init_and_add() takes a reference even when it fails. If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Therefore, replace calling kfree() and call kobject_put() and add a missing kobject_put() in the edac_device_register_sysfs_main_kobj() error path. [ bp: Massage and merge into a single patch. ] Fixes: b2ed215a ("Kobject: change drivers/edac to use kobject_init_and_add") Signed-off-by:
Qiushi Wu <wu000273@umn.edu> Signed-off-by:
Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20200528202238.18078-1-wu000273@umn.edu Link: https://lkml.kernel.org/r/20200528203526.20908-1-wu000273@umn.eduSigned-off-by:
-
Uwe Kleine-König authored
BugLink: https://bugs.launchpad.net/bugs/1892822 This happens for the spi-imx driver when running a dt-enabled kernel on a non-dt machine on Linux 4.0. Among the still supported stable versions only 4.4 and 4.9 are affected. (However the spi-imx driver doesn't call of_get_named_gpio() since v4.8-rc1 (commit b36581df ("spi: imx: Using existing properties for chipselects")) any more, but the problem might still affect other users of of_get_named_gpio().) In 4.14-rc1 this problem is gone with commit 7eb6ce2f ("gpio: Convert to using %pOF instead of full_name"). This commit however doesn't seem sensible to backport as it depends on ce4fecf1 ("vsprintf: Add %p extension "%pOF" for device tree") which doesn't trivially apply to v4.4. [ 1.649453] Unable to handle kernel NULL pointer dereference at virtual address 0000000c [ 1.659270] pgd = c0004000 [ 1.662036] [0000000c] *pgd=00000000 [ 1.665919] Internal error: Oops - BUG: 5 [#1] PREEMPT ARM [ 1.671438] Modules linked in: [ 1.674552] CPU: 0 PID: 1 Comm: swapper Not tainted 4.0.0 #1 [ 1.680235] Hardware name: Eckelmann ECU01 [ 1.684361] task: c7840000 ti: c7842000 task.ti: c7842000 [ 1.689821] PC is at of_get_named_gpiod_flags+0xac/0xe0 [ 1.695104] LR is at of_find_property+0x38/0x7c [ 1.699674] pc : [<c025db2c>] lr : [<c03c5f54>] psr: a0000013 [ 1.699674] sp : c7843cc8 ip : c7843c38 fp : c7843d3c [ 1.711183] r10: c7884dc0 r9 : c7a8de10 r8 : 00000000 [ 1.716434] r7 : 00000000 r6 : 00000000 r5 : c065ef50 r4 : fffffffe [ 1.722986] r3 : 00000000 r2 : 00000000 r1 : c065ef50 r0 : fffffffe [ 1.729541] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [ 1.736879] Control: 0005317f Table: 80004000 DAC: 00000017 [ 1.742652] Process swapper (pid: 1, stack limit = 0xc7842190) [ 1.748510] Stack: (0xc7843cc8 to 0xc7844000) [ 1.752906] 3cc0: c7843cd4 c003ccec 00000000 00000000 00000000 00000000 [ 1.761125] 3ce0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 1.769345] 3d00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 fffffdfb [ 1.777566] 3d20: 00000000 c78b4e10 c7a8dc00 000001ff c7843d4c c7843d40 c025db70 c025da90 [ 1.785788] 3d40: c7843dcc c7843d50 c02f8938 c025db70 c7843d74 c7843d60 c79bc3c0 c79bc320 [ 1.794007] 3d60: c78bb140 c065476c c7a8de10 00000000 c78b4e10 c78b4e00 00000004 00000001 [ 1.802227] 3d80: c06d25d4 00000000 c7843dbc c7843d98 c0115a68 c0112538 00000001 c78b4e10 [ 1.810448] 3da0: c78b4e18 ffffffed c78b4e10 fffffdfb c070bc80 00000000 c06d25d4 00000000 [ 1.818669] 3dc0: c7843dec c7843dd0 c02a0670 c02f8828 c78b4e10 c073fcb0 00000000 c070bc80 [ 1.826890] 3de0: c7843e14 c7843df0 c029f064 c02a0630 00000000 c78b4e10 c070bc80 c78b4e44 [ 1.835110] 3e00: 00000000 c06c8cac c7843e34 c7843e18 c029f204 c029ef70 c029f170 00000000 [ 1.843332] 3e20: c070bc80 c029f170 c7843e5c c7843e38 c029d6f4 c029f180 c785c1cc c7873c30 [ 1.851553] 3e40: c0235728 c070bc80 c7ab9720 c0701e20 c7843e6c c7843e60 c029eb74 c029d6a4 [ 1.859774] 3e60: c7843e94 c7843e70 c029e7f4 c029eb64 c065f390 c7843e80 c070bc80 c06f0718 [ 1.867998] 3e80: c7ab8d60 c06b1528 c7843eac c7843e98 c029f810 c029e728 c06f0718 c06f0718 [ 1.876220] 3ea0: c7843ebc c7843eb0 c02a04dc c029f7ac c7843ecc c7843ec0 c06c8cc4 c02a049c [ 1.884443] 3ec0: c7843f4c c7843ed0 c00089dc c06c8cbc c0109ec0 c0109d18 c780ac00 00000001 [ 1.892665] 3ee0: c7843f00 c7843ef0 c06b1544 c0238a24 c7ffca48 c054c854 c7843f4c c7843f08 [ 1.900886] 3f00: c002e7f4 c06b1538 c003d0e0 00000006 00000006 c06af1a4 00000000 c066ccb4 [ 1.909107] 3f20: c7843f4c c06ea994 00000006 c071ff20 c06b1528 c06d25e0 c06d25d4 0000008f [ 1.917327] 3f40: c7843f94 c7843f50 c06b1e6c c0008964 00000006 00000006 c06b1528 dfe48a08 [ 1.925547] 3f60: 33f73660 3fd760c5 0b5d4bfd 00000000 c0527ef0 00000000 00000000 00000000 [ 1.933768] 3f80: 00000000 00000000 c7843fac c7843f98 c0527f00 c06b1d00 c7842000 00000000 [ 1.941988] 3fa0: 00000000 c7843fb0 c0009798 c0527f00 00000000 00000000 00000000 00000000 [ 1.950206] 3fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 1.958424] 3fe0: 00000000 00000000 00000000 00000000 00000013 00000000 b3cf731f fe6afeef [ 1.966617] Backtrace: [ 1.969150] [<c025da80>] (of_get_named_gpiod_flags) from [<c025db70>] (of_get_named_gpio_flags+0x10/0x24) [ 1.978744] r7:000001ff r6:c7a8dc00 r5:c78b4e10 r4:00000000 [ 1.984548] [<c025db60>] (of_get_named_gpio_flags) from [<c02f8938>] (spi_imx_probe+0x120/0x67c) [ 1.993390] [<c02f8818>] (spi_imx_probe) from [<c02a0670>] (platform_drv_probe+0x50/0xac) [ 2.001589] r10:00000000 r9:c06d25d4 r8:00000000 r7:c070bc80 r6:fffffdfb r5:c78b4e10 [ 2.009549] r4:ffffffed [ 2.012144] [<c02a0620>] (platform_drv_probe) from [<c029f064>] (driver_probe_device+0x104/0x210) [ 2.021040] r7:c070bc80 r6:00000000 r5:c073fcb0 r4:c78b4e10 [ 2.026822] [<c029ef60>] (driver_probe_device) from [<c029f204>] (__driver_attach+0x94/0x98) [ 2.035282] r8:c06c8cac r7:00000000 r6:c78b4e44 r5:c070bc80 r4:c78b4e10 r3:00000000 [ 2.043191] [<c029f170>] (__driver_attach) from [<c029d6f4>] (bus_for_each_dev+0x60/0x90) [ 2.051394] r6:c029f170 r5:c070bc80 r4:00000000 r3:c029f170 [ 2.057185] [<c029d694>] (bus_for_each_dev) from [<c029eb74>] (driver_attach+0x20/0x28) [ 2.065212] r6:c0701e20 r5:c7ab9720 r4:c070bc80 [ 2.069931] [<c029eb54>] (driver_attach) from [<c029e7f4>] (bus_add_driver+0xdc/0x1dc) [ 2.077894] [<c029e718>] (bus_add_driver) from [<c029f810>] (driver_register+0x74/0xec) [ 2.085919] r7:c06b1528 r6:c7ab8d60 r5:c06f0718 r4:c070bc80 [ 2.091705] [<c029f79c>] (driver_register) from [<c02a04dc>] (__platform_driver_register+0x50/0x64) [ 2.100774] r5:c06f0718 r4:c06f0718 [ 2.104437] [<c02a048c>] (__platform_driver_register) from [<c06c8cc4>] (spi_imx_driver_init+0x18/0x20) [ 2.113884] [<c06c8cac>] (spi_imx_driver_init) from [<c00089dc>] (do_one_initcall+0x88/0x1b0) [ 2.122459] [<c0008954>] (do_one_initcall) from [<c06b1e6c>] (kernel_init_freeable+0x17c/0x248) [ 2.131182] r10:0000008f r9:c06d25d4 r8:c06d25e0 r7:c06b1528 r6:c071ff20 r5:00000006 [ 2.139141] r4:c06ea994 [ 2.141751] [<c06b1cf0>] (kernel_init_freeable) from [<c0527f00>] (kernel_init+0x10/0xec) [ 2.149955] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c0527ef0 [ 2.157909] r4:00000000 [ 2.160508] [<c0527ef0>] (kernel_init) from [<c0009798>] (ret_from_fork+0x14/0x3c) [ 2.168099] r4:00000000 r3:c7842000 [ 2.171755] Code: eb0b2dc2 e51b0020 e24bd01c e89da8f0 (e597300c) Cc: stable@vger.kernel.org # v4.4.x, v4.9.x Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
Dexuan Cui authored
BugLink: https://bugs.launchpad.net/bugs/1892822 The v4.4 stable kernel lacks this bugfix: commit 32786821 ("make skb_copy_datagram_msg() et.al. preserve ->msg_iter on error"). As a result, the v4.4 kernel can deliver corrupt data to the application when a corrupt UDP packet is closely followed by a valid UDP packet: the same invocation of the recvmsg() syscall can deliver the corrupt packet's UDP payload to the application with the UDP payload length and the "from IP/Port" of the valid packet. Details: For a UDP packet longer than 76 bytes (see the v5.8-rc6 kernel's include/linux/skbuff.h:3951), Linux delays the UDP checksum verification until the application invokes the syscall recvmsg(). In the recvmsg() syscall handler, while Linux is copying the UDP payload to the application's memory, it calculates the UDP checksum. If the calculated checksum doesn't match the received checksum, Linux drops the corrupt UDP packet, and then starts to process the next packet (if any), and if the next packet is valid (i.e. the checksum is correct), Linux will copy the valid UDP packet's payload to the application's receiver buffer. The bug is: before Linux starts to copy the valid UDP packet, the data structure used to track how many more bytes should be copied to the application memory is not reset to what it was when the application just entered the kernel by the syscall! Consequently, only a small portion or none of the valid packet's payload is copied to the application's receive buffer, and later when the application exits from the kernel, actually most of the application's receive buffer contains the payload of the corrupt packet while recvmsg() returns the length of the UDP payload of the valid packet. For the mainline kernel, the bug was fixed in commit 32786821, but unluckily the bugfix is only backported to v4.9+. It turns out backporting 32786821 to v4.4 means that some supporting patches must be backported first, so the overall changes seem too big, so the alternative is performs the csum validation earlier and drops the corrupt packets earlier. Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
Dexuan Cui <decui@microsoft.com> Acked-by:
-
Nick Desaulniers authored
BugLink: https://bugs.launchpad.net/bugs/1892822 commit f3751ad0 upstream. __tracepoint_string's have their string data stored in .rodata, and an address to that data stored in the "__tracepoint_str" section. Functions that refer to those strings refer to the symbol of the address. Compiler optimization can replace those address references with references directly to the string data. If the address doesn't appear to have other uses, then it appears dead to the compiler and is removed. This can break the /tracing/printk_formats sysfs node which iterates the addresses stored in the "__tracepoint_str" section. Like other strings stored in custom sections in this header, mark these __used to inform the compiler that there are other non-obvious users of the address, so they should still be emitted. Link: https://lkml.kernel.org/r/20200730224555.2142154-2-ndesaulniers@google.com Cc: Ingo Molnar <mingo@redhat.com> Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> Cc: stable@vger.kernel.org Fixes: 102c9323 ("tracing: Add __tracepoint_string() to export string pointers") Reported-by:
Tim Murray <timmurray@google.com> Reported-by:
Simon MacMullen <simonmacm@google.com> Suggested-by:
Greg Hackmann <ghackmann@google.com> Signed-off-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Eric Biggers authored
BugLink: https://bugs.launchpad.net/bugs/1892822 commit beb4ee67 upstream. smk_write_relabel_self() frees memory from the task's credentials with no locking, which can easily cause a use-after-free because multiple tasks can share the same credentials structure. Fix this by using prepare_creds() and commit_creds() to correctly modify the task's credentials. Reproducer for "BUG: KASAN: use-after-free in smk_write_relabel_self": #include <fcntl.h> #include <pthread.h> #include <unistd.h> static void *thrproc(void *arg) { int fd = open("/sys/fs/smackfs/relabel-self", O_WRONLY); for (;;) write(fd, "foo", 3); } int main() { pthread_t t; pthread_create(&t, NULL, thrproc, NULL); thrproc(NULL); } Reported-by: syzbot+e6416dabb497a650da40@syzkaller.appspotmail.com Fixes: 38416e53 ("Smack: limited capability for changing process label") Cc: <stable@vger.kernel.org> # v4.4+ Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
Casey Schaufler <casey@schaufler-ca.com> Signed-off-by:
-
Ido Schimmel authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit b5141915 ] The commit cited below removed the RCU read-side critical section from rtnl_fdb_dump() which means that the ndo_fdb_dump() callback is invoked without RCU protection. This results in the following warning [1] in the VXLAN driver, which relied on the callback being invoked from an RCU read-side critical section. Fix this by calling rcu_read_lock() in the VXLAN driver, as already done in the bridge driver. [1] WARNING: suspicious RCU usage 5.8.0-rc4-custom-01521-g481007553ce6 #29 Not tainted ----------------------------- drivers/net/vxlan.c:1379 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by bridge/166: #0: ffffffff85a27850 (rtnl_mutex){+.+.}-{3:3}, at: netlink_dump+0xea/0x1090 stack backtrace: CPU: 1 PID: 166 Comm: bridge Not tainted 5.8.0-rc4-custom-01521-g481007553ce6 #29 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-2.fc32 04/01/2014 Call Trace: dump_stack+0x100/0x184 lockdep_rcu_suspicious+0x153/0x15d vxlan_fdb_dump+0x51e/0x6d0 rtnl_fdb_dump+0x4dc/0xad0 netlink_dump+0x540/0x1090 __netlink_dump_start+0x695/0x950 rtnetlink_rcv_msg+0x802/0xbd0 netlink_rcv_skb+0x17a/0x480 rtnetlink_rcv+0x22/0x30 netlink_unicast+0x5ae/0x890 netlink_sendmsg+0x98a/0xf40 __sys_sendto+0x279/0x3b0 __x64_sys_sendto+0xe6/0x1a0 do_syscall_64+0x54/0xa0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7fe14fa2ade0 Code: Bad RIP value. RSP: 002b:00007fff75bb5b88 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00005614b1ba0020 RCX: 00007fe14fa2ade0 RDX: 000000000000011c RSI: 00007fff75bb5b90 RDI: 0000000000000003 RBP: 00007fff75bb5b90 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00005614b1b89160 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Fixes: 5e6d2435 ("bridge: netlink dump interface at par with brctl") Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Reviewed-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Rustam Kovhaev authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit e911e99a ] in case of an error tty_register_device_attr() returns ERR_PTR(), add IS_ERR() check Reported-and-tested-by: syzbot+67b2bd0e34f952d0321e@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=67b2bd0e34f952d0321eSigned-off-by:
Rustam Kovhaev <rkovhaev@gmail.com> Reviewed-by:
-
Johan Hovold authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit ea060b35 ] Drop the bogus endpoint-lookup helper which could end up accepting interfaces based on endpoints belonging to unrelated altsettings. Note that the returned bulk pipes and interrupt endpoint descriptor were never actually used. Instead the bulk-endpoint numbers are hardcoded to 1 and 2 (matching the specification), while the interrupt- endpoint descriptor was assumed to be the third descriptor created by USB core. Try to bring some order to this by dropping the bogus lookup helper and adding the missing endpoint sanity checks while keeping the interrupt- descriptor assumption for now. Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Hangbin Liu authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit a0dced17 ] This reverts commit 71130f29. In commit 71130f29 ("vxlan: fix tos value before xmit") we want to make sure the tos value are filtered by RT_TOS() based on RFC1349. 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | PRECEDENCE | TOS | MBZ | +-----+-----+-----+-----+-----+-----+-----+-----+ But RFC1349 has been obsoleted by RFC2474. The new DSCP field defined like 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | DS FIELD, DSCP | ECN FIELD | +-----+-----+-----+-----+-----+-----+-----+-----+ So with IPTOS_TOS_MASK 0x1E RT_TOS(tos) ((tos)&IPTOS_TOS_MASK) the first 3 bits DSCP info will get lost. To take all the DSCP info in xmit, we should revert the patch and just push all tos bits to ip_tunnel_ecn_encap(), which will handling ECN field later. Fixes: 71130f29 ("vxlan: fix tos value before xmit") Signed-off-by:
Hangbin Liu <liuhangbin@gmail.com> Acked-by:
Guillaume Nault <gnault@redhat.com> Signed-off-by:
-
Cong Wang authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit 8c0de6e9 ] IPV6_ADDRFORM causes resource leaks when converting an IPv6 socket to IPv4, particularly struct ipv6_ac_socklist. Similar to struct ipv6_mc_socklist, we should just close it on this path. This bug can be easily reproduced with the following C program: #include <stdio.h> #include <string.h> #include <sys/types.h> #include <sys/socket.h> #include <arpa/inet.h> int main() { int s, value; struct sockaddr_in6 addr; struct ipv6_mreq m6; s = socket(AF_INET6, SOCK_DGRAM, 0); addr.sin6_family = AF_INET6; addr.sin6_port = htons(5000); inet_pton(AF_INET6, "::ffff:192.168.122.194", &addr.sin6_addr); connect(s, (struct sockaddr *)&addr, sizeof(addr)); inet_pton(AF_INET6, "fe80::AAAA", &m6.ipv6mr_multiaddr); m6.ipv6mr_interface = 5; setsockopt(s, SOL_IPV6, IPV6_JOIN_ANYCAST, &m6, sizeof(m6)); value = AF_INET; setsockopt(s, SOL_IPV6, IPV6_ADDRFORM, &value, sizeof(value)); close(s); return 0; } Reported-by: ch3332xr@gmail.com Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
-
Ido Schimmel authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit 83f35228 ] fib_trie_unmerge() is called with RTNL held, but not from an RCU read-side critical section. This leads to the following warning [1] when the FIB alias list in a leaf is traversed with hlist_for_each_entry_rcu(). Since the function is always called with RTNL held and since modification of the list is protected by RTNL, simply use hlist_for_each_entry() and silence the warning. [1] WARNING: suspicious RCU usage 5.8.0-rc4-custom-01520-gc1f937f3f83b #30 Not tainted ----------------------------- net/ipv4/fib_trie.c:1867 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/164: #0: ffffffff85a27850 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x49a/0xbd0 stack backtrace: CPU: 0 PID: 164 Comm: ip Not tainted 5.8.0-rc4-custom-01520-gc1f937f3f83b #30 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-2.fc32 04/01/2014 Call Trace: dump_stack+0x100/0x184 lockdep_rcu_suspicious+0x153/0x15d fib_trie_unmerge+0x608/0xdb0 fib_unmerge+0x44/0x360 fib4_rule_configure+0xc8/0xad0 fib_nl_newrule+0x37a/0x1dd0 rtnetlink_rcv_msg+0x4f7/0xbd0 netlink_rcv_skb+0x17a/0x480 rtnetlink_rcv+0x22/0x30 netlink_unicast+0x5ae/0x890 netlink_sendmsg+0x98a/0xf40 ____sys_sendmsg+0x879/0xa00 ___sys_sendmsg+0x122/0x190 __sys_sendmsg+0x103/0x1d0 __x64_sys_sendmsg+0x7d/0xb0 do_syscall_64+0x54/0xa0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7fc80a234e97 Code: Bad RIP value. RSP: 002b:00007ffef8b66798 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fc80a234e97 RDX: 0000000000000000 RSI: 00007ffef8b66800 RDI: 0000000000000003 RBP: 000000005f141b1c R08: 0000000000000001 R09: 0000000000000000 R10: 00007fc80a2a8ac0 R11: 0000000000000246 R12: 0000000000000001 R13: 0000000000000000 R14: 00007ffef8b67008 R15: 0000556fccb10020 Fixes: 0ddcf43d ("ipv4: FIB Local/MAIN table collapse") Signed-off-by:
-
Jann Horn authored
BugLink: https://bugs.launchpad.net/bugs/1892822 commit 4b836a14 upstream. Binder is designed such that a binder_proc never has references to itself. If this rule is violated, memory corruption can occur when a process sends a transaction to itself; see e.g. <https://syzkaller.appspot.com/bug?extid=09e05aba06723a94d43d>. There is a remaining edgecase through which such a transaction-to-self can still occur from the context of a task with BINDER_SET_CONTEXT_MGR access: - task A opens /dev/binder twice, creating binder_proc instances P1 and P2 - P1 becomes context manager - P2 calls ACQUIRE on the magic handle 0, allocating index 0 in its handle table - P1 dies (by closing the /dev/binder fd and waiting a bit) - P2 becomes context manager - P2 calls ACQUIRE on the magic handle 0, allocating index 1 in its handle table [this triggers a warning: "binder: 1974:1974 tried to acquire reference to desc 0, got 1 instead"] - task B opens /dev/binder once, creating binder_proc instance P3 - P3 calls P2 (via magic handle 0) with (void*)1 as argument (two-way transaction) - P2 receives the handle and uses it to call P3 (two-way transaction) - P3 calls P2 (via magic handle 0) (two-way transaction) - P2 calls P2 (via handle 1) (two-way transaction) And then, if P2 does *NOT* accept the incoming transaction work, but instead closes the binder fd, we get a crash. Solve it by preventing the context manager from using ACQUIRE on ref 0. There shouldn't be any legitimate reason for the context manager to do that. Additionally, print a warning if someone manages to find another way to trigger a transaction-to-self bug in the future. Cc: stable@vger.kernel.org Fixes: 457b9a6f ("Staging: android: add binder driver") Acked-by:
Todd Kjos <tkjos@google.com> Signed-off-by:
Jann Horn <jannh@google.com> Reviewed-by:
Martijn Coenen <maco@android.com> Link: https://lore.kernel.org/r/20200727120424.1627555-1-jannh@google.com [manual backport: remove fine-grained locking and error reporting that don't exist in <=4.9] Signed-off-by:
-
Philippe Duplessis-Guindon authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit e24c6447 ] I compiled with AddressSanitizer and I had these memory leaks while I was using the tep_parse_format function: Direct leak of 28 byte(s) in 4 object(s) allocated from: #0 0x7fb07db49ffe in __interceptor_realloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10dffe) #1 0x7fb07a724228 in extend_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:985 #2 0x7fb07a724c21 in __read_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1140 #3 0x7fb07a724f78 in read_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1206 #4 0x7fb07a725191 in __read_expect_type /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1291 #5 0x7fb07a7251df in read_expect_type /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1299 #6 0x7fb07a72e6c8 in process_dynamic_array_len /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:2849 #7 0x7fb07a7304b8 in process_function /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3161 #8 0x7fb07a730900 in process_arg_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3207 #9 0x7fb07a727c0b in process_arg /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1786 #10 0x7fb07a731080 in event_read_print_args /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3285 #11 0x7fb07a731722 in event_read_print /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3369 #12 0x7fb07a740054 in __tep_parse_format /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:6335 #13 0x7fb07a74047a in __parse_event /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:6389 #14 0x7fb07a740536 in tep_parse_format /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:6431 #15 0x7fb07a785acf in parse_event ../../../src/fs-src/fs.c:251 #16 0x7fb07a785ccd in parse_systems ../../../src/fs-src/fs.c:284 #17 0x7fb07a786fb3 in read_metadata ../../../src/fs-src/fs.c:593 #18 0x7fb07a78760e in ftrace_fs_source_init ../../../src/fs-src/fs.c:727 #19 0x7fb07d90c19c in add_component_with_init_method_data ../../../../src/lib/graph/graph.c:1048 #20 0x7fb07d90c87b in add_source_component_with_initialize_method_data ../../../../src/lib/graph/graph.c:1127 #21 0x7fb07d90c92a in bt_graph_add_source_component ../../../../src/lib/graph/graph.c:1152 #22 0x55db11aa632e in cmd_run_ctx_create_components_from_config_components ../../../src/cli/babeltrace2.c:2252 #23 0x55db11aa6fda in cmd_run_ctx_create_components ../../../src/cli/babeltrace2.c:2347 #24 0x55db11aa780c in cmd_run ../../../src/cli/babeltrace2.c:2461 #25 0x55db11aa8a7d in main ../../../src/cli/babeltrace2.c:2673 #26 0x7fb07d5460b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2) The token variable in the process_dynamic_array_len function is allocated in the read_expect_type function, but is not freed before calling the read_token function. Free the token variable before calling read_token in order to plug the leak. Signed-off-by:
Philippe Duplessis-Guindon <pduplessis@efficios.com> Reviewed-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Xin Xiong authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit 51875dad ] atmtcp_remove_persistent() invokes atm_dev_lookup(), which returns a reference of atm_dev with increased refcount or NULL if fails. The refcount leaks issues occur in two error handling paths. If dev_data->persist is zero or PRIV(dev)->vcc isn't NULL, the function returns 0 without decreasing the refcount kept by a local variable, resulting in refcount leaks. Fix the issue by adding atm_dev_put() before returning 0 both when dev_data->persist is zero or PRIV(dev)->vcc isn't NULL. Signed-off-by:
Xin Xiong <xiongx18@fudan.edu.cn> Signed-off-by:
Xiyu Yang <xiyuyang19@fudan.edu.cn> Signed-off-by:
Xin Tan <tanxin.ctf@gmail.com> Signed-off-by:
-
Francesco Ruggeri authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit 024a8168 ] We observed two panics involving races with igb_reset_task. The first panic is caused by this race condition: kworker reboot -f igb_reset_task igb_reinit_locked igb_down napi_synchronize __igb_shutdown igb_clear_interrupt_scheme igb_free_q_vectors igb_free_q_vector adapter->q_vector[v_idx] = NULL; napi_disable Panics trying to access adapter->q_vector[v_idx].napi_state The second panic (a divide error) is caused by this race: kworker reboot -f tx packet igb_reset_task __igb_shutdown rtnl_lock() ... igb_clear_interrupt_scheme igb_free_q_vectors adapter->num_tx_queues = 0 ... rtnl_unlock() rtnl_lock() igb_reinit_locked igb_down igb_up netif_tx_start_all_queues dev_hard_start_xmit igb_xmit_frame igb_tx_queue_mapping Panics on r_idx % adapter->num_tx_queues This commit applies to igb_reset_task the same changes that were applied to ixgbe in commit 2f90b865 ("ixgbe: this patch adds support for DCB to the kernel and ixgbe driver"), commit 8f4c5c9f ("ixgbe: reinit_locked() should be called with rtnl_lock") and commit 88adce4e ("ixgbe: fix possible race in reset subtask"). Signed-off-by:
Francesco Ruggeri <fruggeri@arista.com> Tested-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by:
-
Julian Squires authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit 4052d3d2 ] In the case where a vendor command does not implement doit, and has no flags set, doit would not be validated and a NULL pointer dereference would occur, for example when invoking the vendor command via iw. I encountered this while developing new vendor commands. Perhaps in practice it is advisable to always implement doit along with dumpit, but it seems reasonable to me to always check doit anyway, not just when NEED_WDEV. Signed-off-by:
Julian Squires <julian@cipht.net> Link: https://lore.kernel.org/r/20200706211353.2366470-1-julian@cipht.netSigned-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Ben Skeggs authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit 498595ab ] Stale pointer was tripping up the unload path. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
-
Christoph Hellwig authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit a39c4606 ] p9_fd_open just fgets file descriptors passed in from userspace, but doesn't verify that they are valid for read or writing. This gets cought down in the VFS when actually attempting a read or write, but a new warning added in linux-next upsets syzcaller. Fix this by just verifying the fds early on. Link: http://lkml.kernel.org/r/20200710085722.435850-1-hch@lst.de Reported-by: syzbot+e6f77e16ff68b2434a2c@syzkaller.appspotmail.com Signed-off-by:
Christoph Hellwig <hch@lst.de> [Dominique: amend goto as per Doug Nazar's review] Signed-off-by:
Dominique Martinet <asmadeus@codewreck.org> Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: https://bugs.launchpad.net/bugs/1892822 commit f7e6b19b upstream. When doing a "write" ioctl call, properly check that we have permissions to do so before copying anything from userspace or anything else so we can "fail fast". This includes also covering the MEMWRITE ioctl which previously missed checking for this. Cc: Miquel Raynal <miquel.raynal@bootlin.com> Cc: Richard Weinberger <richard@nod.at> Cc: Vignesh Raghavendra <vigneshr@ti.com> Cc: stable <stable@kernel.org> Signed-off-by:
Richard Weinberger <richard@nod.at> Signed-off-by:
-
Yunhai Zhang authored
BugLink: https://bugs.launchpad.net/bugs/1892822 commit ebfdfeea upstream. vgacon_scrollback_update() always leaves enbough room in the scrollback buffer for the next call, but if the console size changed that room might not actually be enough, and so we need to re-check. The check should be in the loop since vgacon_scrollback_cur->tail is updated in the loop and count may be more than 1 when triggered by CSI M, as Jiri's PoC: #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <sys/types.h> #include <sys/stat.h> #include <sys/ioctl.h> #include <fcntl.h> int main(int argc, char** argv) { int fd = open("/dev/tty1", O_RDWR); unsigned short size[3] = {25, 200, 0}; ioctl(fd, 0x5609, size); // VT_RESIZE write(fd, "\e[1;1H", 6); for (int i = 0; i < 30; i++) write(fd, "\e[10M", 5); } It leads to various crashes as vgacon_scrollback_update writes out of the buffer: BUG: unable to handle page fault for address: ffffc900001752a0 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page RIP: 0010:mutex_unlock+0x13/0x30 ... Call Trace: n_tty_write+0x1a0/0x4d0 tty_write+0x1a0/0x2e0 Or to KASAN reports: BUG: KASAN: slab-out-of-bounds in vgacon_scroll+0x57a/0x8ed This fixes CVE-2020-14331. Reported-by:
张云海 <zhangyunhai@nsfocus.com> Reported-by:
Yang Yingliang <yangyingliang@huawei.com> Reported-by:
Kyungtae Kim <kt0755@gmail.com> Fixes: 15bdab95 ([PATCH] vgacon: Add support for soft scrollback) Cc: stable@vger.kernel.org Cc: linux-fbdev@vger.kernel.org Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Solar Designer <solar@openwall.com> Cc: "Srivatsa S. Bhat" <srivatsa@csail.mit.edu> Cc: Anthony Liguori <aliguori@amazon.com> Cc: Yang Yingliang <yangyingliang@huawei.com> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: Jiri Slaby <jirislaby@kernel.org> Signed-off-by:
-
Peilin Ye authored
BugLink: https://bugs.launchpad.net/bugs/1892822 commit 629b49c8 upstream. Check `num_rsp` before using it as for-loop counter. Add `unlock` label. Cc: stable@vger.kernel.org Signed-off-by:
Peilin Ye <yepeilin.cs@gmail.com> Signed-off-by:
-
Peilin Ye authored
BugLink: https://bugs.launchpad.net/bugs/1892822 commit 75bbd2ea upstream. Check `num_rsp` before using it as for-loop counter. Cc: stable@vger.kernel.org Signed-off-by:
-
Peilin Ye authored
BugLink: https://bugs.launchpad.net/bugs/1892822 commit 51c19bf3 upstream. Check upon `num_rsp` is insufficient. A malformed event packet with a large `num_rsp` number makes hci_extended_inquiry_result_evt() go out of bounds. Fix it. This patch fixes the following syzbot bug: https://syzkaller.appspot.com/bug?id=4bf11aa05c4ca51ce0df86e500fce486552dc8d2 Reported-by: syzbot+d8489a79b781849b9c46@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Signed-off-by:
-
Takashi Iwai authored
BugLink: https://bugs.launchpad.net/bugs/1892822 commit 80982c7e upstream. Some ioctls via OSS sequencer API may race and lead to UAF when the port create and delete are performed concurrently, as spotted by a couple of syzkaller cases. This patch is an attempt to address it by serializing the ioctls with the existing register_mutex. Basically OSS sequencer API is an obsoleted interface and was designed without much consideration of the concurrency. There are very few applications with it, and the concurrent performance isn't asked, hence this "big hammer" approach should be good enough. Reported-by: syzbot+1a54a94bd32716796edd@syzkaller.appspotmail.com Reported-by: syzbot+9d2abfef257f3e2d4713@syzkaller.appspotmail.com Suggested-by:
Hillf Danton <hdanton@sina.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200804185815.2453-1-tiwai@suse.deSigned-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Erik Ekman authored
BugLink: https://bugs.launchpad.net/bugs/1892822 commit d2a4309c upstream. When running qmi-firmware-update on the Sierra Wireless EM7305 in a Toshiba laptop, it changed product ID to 0x9062 when entering QDL mode: usb 2-4: new high-speed USB device number 78 using xhci_hcd usb 2-4: New USB device found, idVendor=1199, idProduct=9062, bcdDevice= 0.00 usb 2-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 2-4: Product: EM7305 usb 2-4: Manufacturer: Sierra Wireless, Incorporated The upgrade could complete after running # echo 1199 9062 > /sys/bus/usb-serial/drivers/qcserial/new_id qcserial 2-4:1.0: Qualcomm USB modem converter detected usb 2-4: Qualcomm USB modem converter now attached to ttyUSB0 Signed-off-by:
Erik Ekman <erik@kryo.se> Link: https://lore.kernel.org/r/20200717185118.3640219-1-erik@kryo.se Cc: stable@vger.kernel.org Signed-off-by:
-
Jiang Ying authored
BugLink: https://bugs.launchpad.net/bugs/1892822 This patch is used to fix ext4 direct I/O read error when the read size is not aligned with block size. Then, I will use a test to explain the error. (1) Make a file that is not aligned with block size: $dd if=/dev/zero of=./test.jar bs=1000 count=3 (2) I wrote a source file named "direct_io_read_file.c" as following: #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <sys/file.h> #include <sys/types.h> #include <sys/stat.h> #include <string.h> #define BUF_SIZE 1024 int main() { int fd; int ret; unsigned char *buf; ret = posix_memalign((void **)&buf, 512, BUF_SIZE); if (ret) { perror("posix_memalign failed"); exit(1); } fd = open("./test.jar", O_RDONLY | O_DIRECT, 0755); if (fd < 0){ perror("open ./test.jar failed"); exit(1); } do { ret = read(fd, buf, BUF_SIZE); printf("ret=%d\n",ret); if (ret < 0) { perror("write test.jar failed"); } } while (ret > 0); free(buf); close(fd); } (3) Compile the source file: $gcc direct_io_read_file.c -D_GNU_SOURCE (4) Run the test program: $./a.out The result is as following: ret=1024 ret=1024 ret=952 ret=-1 write test.jar failed: Invalid argument. I have tested this program on XFS filesystem, XFS does not have this problem, because XFS use iomap_dio_rw() to do direct I/O read. And the comparing between read offset and file size is done in iomap_dio_rw(), the code is as following: if (pos < size) { retval = filemap_write_and_wait_range(mapping, pos, pos + iov_length(iov, nr_segs) - 1); if (!retval) { retval = mapping->a_ops->direct_IO(READ, iocb, iov, pos, nr_segs); } ... } ...only when "pos < size", direct I/O can be done, or 0 will be return. I have tested the fix patch on Ext4, it is up to the mustard of EINVAL in man2(read) as following: #include <unistd.h> ssize_t read(int fd, void *buf, size_t count); EINVAL fd is attached to an object which is unsuitable for reading; or the file was opened with the O_DIRECT flag, and either the address specified in buf, the value specified in count, or the current file offset is not suitably aligned. So I think this patch can be applied to fix ext4 direct I/O error. However Ext4 introduces direct I/O read using iomap infrastructure on kernel 5.5, the patch is commit <b1b4705d> ("ext4: introduce direct I/O read using iomap infrastructure"), then Ext4 will be the same as XFS, they all use iomap_dio_rw() to do direct I/O read. So this problem does not exist on kernel 5.5 for Ext4. >From above description, we can see this problem exists on all the kernel versions between kernel 3.14 and kernel 5.4. It will cause the Applications to fail to read. For example, when the search service downloads a new full index file, the search engine is loading the previous index file and is processing the search request, it can not use buffer io that may squeeze the previous index file in use from pagecache, so the serch service must use direct I/O read. Please apply this patch on these kernel versions, or please use the method on kernel 5.5 to fix this problem. Fixes: 9fe55eea ("Fix race when checking i_size on direct i/o read") Reviewed-by:
Jan Kara <jack@suse.cz> Reviewed-by:
Wang Long <wanglong19@meituan.com> Signed-off-by:
Jiang Ying <jiangying8582@126.com> Signed-off-by:
-
Linus Torvalds authored
BugLink: https://bugs.launchpad.net/bugs/1892822 commit c0842fbc upstream. The addition of percpu.h to the list of includes in random.h revealed some circular dependencies on arm64 and possibly other platforms. This include was added solely for the pseudo-random definitions, which have nothing to do with the rest of the definitions in this file but are still there for legacy reasons. This patch moves the pseudo-random parts to linux/prandom.h and the percpu.h include with it, which is now guarded by _LINUX_PRANDOM_H and protected against recursive inclusion. A further cleanup step would be to remove this from <linux/random.h> entirely, and make people who use the prandom infrastructure include just the new header file. That's a bit of a churn patch, but grepping for "prandom_" and "next_pseudo_random32" "struct rnd_state" should catch most users. But it turns out that that nice cleanup step is fairly painful, because a _lot_ of code currently seems to depend on the implicit include of <linux/random.h>, which can currently come in a lot of ways, including such fairly core headfers as <linux/net.h>. So the "nice cleanup" part may or may never happen. Fixes: 1c9df907 ("random: fix circular include dependency on arm64 after addition of percpu.h") Tested-by:
Guenter Roeck <linux@roeck-us.net> Acked-by:
Willy Tarreau <w@1wt.eu> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Linus Torvalds authored
BugLink: https://bugs.launchpad.net/bugs/1892822 commit 83bdc727 upstream. It turns out that the plugin right now ends up being really unhappy about the change from 'static' to 'extern' storage that happened in commit f227e3ec ("random32: update the net random state on interrupt and activity"). This is probably a trivial fix for the latent_entropy plugin, but for now, just remove net_rand_state from the list of things the plugin worries about. Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Cc: Emese Revfy <re.emese@gmail.com> Cc: Kees Cook <keescook@chromium.org> Cc: Willy Tarreau <w@1wt.eu> Signed-off-by:
-
Willy Tarreau authored
BugLink: https://bugs.launchpad.net/bugs/1892822 commit 1c9df907 upstream. Daniel Díaz and Kees Cook independently reported that commit f227e3ec ("random32: update the net random state on interrupt and activity") broke arm64 due to a circular dependency on include files since the addition of percpu.h in random.h. The correct fix would definitely be to move all the prandom32 stuff out of random.h but for backporting, a smaller solution is preferred. This one replaces linux/percpu.h with asm/percpu.h, and this fixes the problem on x86_64, arm64, arm, and mips. Note that moving percpu.h around didn't change anything and that removing it entirely broke differently. When backporting, such options might still be considered if this patch fails to help. [ It turns out that an alternate fix seems to be to just remove the troublesome <asm/pointer_auth.h> remove from the arm64 <asm/smp.h> that causes the circular dependency. But we might as well do the whole belt-and-suspenders thing, and minimize inclusion in <linux/random.h> too. Either will fix the problem, and both are good changes. - Linus ] Reported-by:
Daniel Díaz <daniel.diaz@linaro.org> Reported-by:
Kees Cook <keescook@chromium.org> Tested-by:
Marc Zyngier <maz@kernel.org> Fixes: f227e3ec Cc: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
Grygorii Strashko authored
BugLink: https://bugs.launchpad.net/bugs/1892822 commit aa54ea90 upstream. Fix build error for the case: defined(CONFIG_SMP) && !defined(CONFIG_CPU_V6) config: keystone_defconfig CC arch/arm/kernel/signal.o In file included from ../include/linux/random.h:14, from ../arch/arm/kernel/signal.c:8: ../arch/arm/include/asm/percpu.h: In function ‘__my_cpu_offset’: ../arch/arm/include/asm/percpu.h:29:34: error: ‘current_stack_pointer’ undeclared (first use in this function); did you mean ‘user_stack_pointer’? : "Q" (*(const unsigned long *)current_stack_pointer)); ^~~~~~~~~~~~~~~~~~~~~ user_stack_pointer Fixes: f227e3ec ("random32: update the net random state on interrupt and activity") Signed-off-by:
Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by:
-
Willy Tarreau authored
BugLink: https://bugs.launchpad.net/bugs/1892822 commit f227e3ec upstream. This modifies the first 32 bits out of the 128 bits of a random CPU's net_rand_state on interrupt or CPU activity to complicate remote observations that could lead to guessing the network RNG's internal state. Note that depending on some network devices' interrupt rate moderation or binding, this re-seeding might happen on every packet or even almost never. In addition, with NOHZ some CPUs might not even get timer interrupts, leaving their local state rarely updated, while they are running networked processes making use of the random state. For this reason, we also perform this update in update_process_times() in order to at least update the state when there is user or system activity, since it's the only case we care about. Reported-by:
Amit Klein <aksecurity@gmail.com> Suggested-by:
-
Thomas Gleixner authored
BugLink: https://bugs.launchpad.net/bugs/1892822 commit bdd65589 upstream. 0day reported a possible circular locking dependency: Chain exists of: &irq_desc_lock_class --> console_owner --> &port_lock_key Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&port_lock_key); lock(console_owner); lock(&port_lock_key); lock(&irq_desc_lock_class); The reason for this is a printk() in the i8259 interrupt chip driver which is invoked with the irq descriptor lock held, which reverses the lock operations vs. printk() from arbitrary contexts. Switch the printk() to printk_deferred() to avoid that. Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Ingo Molnar <mingo@kernel.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/87365abt2v.fsf@nanos.tec.linutronix.deSigned-off-by:
-
Andrea Righi authored
BugLink: https://bugs.launchpad.net/bugs/1892822 [ Upstream commit c2c63310 ] There's a potential race in xennet_remove(); this is what the driver is doing upon unregistering a network device: 1. state = read bus state 2. if state is not "Closed": 3. request to set state to "Closing" 4. wait for state to be set to "Closing" 5. request to set state to "Closed" 6. wait for state to be set to "Closed" If the state changes to "Closed" immediately after step 1 we are stuck forever in step 4, because the state will never go back from "Closed" to "Closing". Make sure to check also for state == "Closed" in step 4 to prevent the deadlock. Also add a 5 sec timeout any time we wait for the bus state to change, to avoid getting stuck forever in wait_event(). Signed-off-by:
Andrea Righi <andrea.righi@canonical.com> Signed-off-by:
-
