December 2019 - Linux-stable-mirror

[PATCH] jffs2: Fix integer underflow in jffs2_rtime_compress

by Richard Weinberger

The rtime compressor assumes that at least two bytes are compressed. If we try to compress just one byte, the loop condition will wrap around and an out-of-bounds write happens. Cc: <stable(a)vger.kernel.org> Signed-off-by: Richard Weinberger <richard(a)nod.at> --- fs/jffs2/compr_rtime.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/fs/jffs2/compr_rtime.c b/fs/jffs2/compr_rtime.c index 406d9cc84ba8..cbf700001fc9 100644 --- a/fs/jffs2/compr_rtime.c +++ b/fs/jffs2/compr_rtime.c @@ -39,6 +39,9 @@ static int jffs2_rtime_compress(unsigned char *data_in, memset(positions,0,sizeof(positions)); + if (*dstlen < 2) + return -1; + while (pos < (*sourcelen) && outpos <= (*dstlen)-2) { int backpos, runlen=0; unsigned char value; -- 2.20.0

5 years, 2 months

2
3
0 0

[PATCH v2] drm/dp_mst: Remove VCPI while disabling topology mgr

by Wayne Lin

[Why] This patch is trying to address the issue observed when hotplug DP daisy chain monitors. e.g. src-mstb-mstb-sst -> src (unplug) mstb-mstb-sst -> src-mstb-mstb-sst (plug in again) Once unplug a DP MST capable device, driver will call drm_dp_mst_topology_mgr_set_mst() to disable MST. In this function, it cleans data of topology manager while disabling mst_state. However, it doesn't clean up the proposed_vcpis of topology manager. If proposed_vcpi is not reset, once plug in MST daisy chain monitors later, code will fail at checking port validation while trying to allocate payloads. When MST capable device is plugged in again and try to allocate payloads by calling drm_dp_update_payload_part1(), this function will iterate over all proposed virtual channels to see if any proposed VCPI's num_slots is greater than 0. If any proposed VCPI's num_slots is greater than 0 and the port which the specific virtual channel directed to is not in the topology, code then fails at the port validation. Since there are stale VCPI allocations from the previous topology enablement in proposed_vcpi[], code will fail at port validation and reurn EINVAL. [How] Clean up the data of stale proposed_vcpi[] and reset mgr->proposed_vcpis to NULL while disabling mst in drm_dp_mst_topology_mgr_set_mst(). Changes since v1: *Add on more details in commit message to describe the issue which the patch is trying to fix Signed-off-by: Wayne Lin <Wayne.Lin(a)amd.com> --- drivers/gpu/drm/drm_dp_mst_topology.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c index ae5809a1f19a..bf4f745a4edb 100644 --- a/drivers/gpu/drm/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/drm_dp_mst_topology.c @@ -3386,6 +3386,7 @@ static int drm_dp_get_vc_payload_bw(u8 dp_link_bw, u8 dp_link_count) int drm_dp_mst_topology_mgr_set_mst(struct drm_dp_mst_topology_mgr *mgr, bool mst_state) { int ret = 0; + int i = 0; struct drm_dp_mst_branch *mstb = NULL; mutex_lock(&mgr->lock); @@ -3446,10 +3447,21 @@ int drm_dp_mst_topology_mgr_set_mst(struct drm_dp_mst_topology_mgr *mgr, bool ms /* this can fail if the device is gone */ drm_dp_dpcd_writeb(mgr->aux, DP_MSTM_CTRL, 0); ret = 0; + mutex_lock(&mgr->payload_lock); memset(mgr->payloads, 0, mgr->max_payloads * sizeof(struct drm_dp_payload)); mgr->payload_mask = 0; set_bit(0, &mgr->payload_mask); + for (i = 0; i < mgr->max_payloads; i++) { + struct drm_dp_vcpi *vcpi = mgr->proposed_vcpis[i]; + + if (vcpi) { + vcpi->vcpi = 0; + vcpi->num_slots = 0; + } + mgr->proposed_vcpis[i] = NULL; + } mgr->vcpi_mask = 0; + mutex_unlock(&mgr->payload_lock); } out_unlock: -- 2.17.1

5 years, 2 months

4
9
0 0

[PATCH] iwlwifi: mvm: don't send the IWL_MVM_RXQ_NSSN_SYNC notif to Rx queues

by Emmanuel Grumbach

The purpose of this was to keep all the queues updated with the Rx sequence numbers because unlikely yet possible situations where queues can't understand if a specific packet needs to be dropped or not. Unfortunately, it was reported that this caused issues in our DMA engine. We don't fully understand how this is related, but this is being currently debugged. For now, just don't send this notification to the Rx queues. This de-facto reverts my commit 3c514bf831ac12356b695ff054bef641b9e99593: iwlwifi: mvm: add a loose synchronization of the NSSN across Rx queues This issue was reported here: https://bugzilla.kernel.org/show_bug.cgi?id=204873 https://bugzilla.kernel.org/show_bug.cgi?id=205001 and others maybe. Fixes: 3c514bf831ac ("iwlwifi: mvm: add a loose synchronization of the NSSN across Rx queues") CC: <stable(a)vger.kernel.org> # 5.3+ Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach(a)intel.com> --- drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c b/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c index 75a7af5ad7b2..8925fe5976cb 100644 --- a/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c +++ b/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c @@ -521,7 +521,11 @@ static void iwl_mvm_sync_nssn(struct iwl_mvm *mvm, u8 baid, u16 nssn) .nssn_sync.nssn = nssn, }; - iwl_mvm_sync_rx_queues_internal(mvm, (void *)&notif, sizeof(notif)); + /* + * This allow to synchronize the queues, but it has been reported + * to cause FH issues. Don't send the notification for now. + * iwl_mvm_sync_rx_queues_internal(mvm, (void *)&notif, sizeof(notif)); + */ } #define RX_REORDER_BUF_TIMEOUT_MQ (HZ / 10) -- 2.17.1

5 years, 2 months

3
9
0 0

[PATCH RESEND RESEND] media: uvc: Avoid cyclic entity chains due to malformed USB descriptors

by Will Deacon

Way back in 2017, fuzzing the 4.14-rc2 USB stack with syzkaller kicked up the following WARNING from the UVC chain scanning code: | list_add double add: new=ffff880069084010, prev=ffff880069084010, | next=ffff880067d22298. | ------------[ cut here ]------------ | WARNING: CPU: 1 PID: 1846 at lib/list_debug.c:31 __list_add_valid+0xbd/0xf0 | Modules linked in: | CPU: 1 PID: 1846 Comm: kworker/1:2 Not tainted | 4.14.0-rc2-42613-g1488251d1a98 #238 | Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 | Workqueue: usb_hub_wq hub_event | task: ffff88006b01ca40 task.stack: ffff880064358000 | RIP: 0010:__list_add_valid+0xbd/0xf0 lib/list_debug.c:29 | RSP: 0018:ffff88006435ddd0 EFLAGS: 00010286 | RAX: 0000000000000058 RBX: ffff880067d22298 RCX: 0000000000000000 | RDX: 0000000000000058 RSI: ffffffff85a58800 RDI: ffffed000c86bbac | RBP: ffff88006435dde8 R08: 1ffff1000c86ba52 R09: 0000000000000000 | R10: 0000000000000002 R11: 0000000000000000 R12: ffff880069084010 | R13: ffff880067d22298 R14: ffff880069084010 R15: ffff880067d222a0 | FS: 0000000000000000(0000) GS:ffff88006c900000(0000) knlGS:0000000000000000 | CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 | CR2: 0000000020004ff2 CR3: 000000006b447000 CR4: 00000000000006e0 | Call Trace: | __list_add ./include/linux/list.h:59 | list_add_tail+0x8c/0x1b0 ./include/linux/list.h:92 | uvc_scan_chain_forward.isra.8+0x373/0x416 | drivers/media/usb/uvc/uvc_driver.c:1471 | uvc_scan_chain drivers/media/usb/uvc/uvc_driver.c:1585 | uvc_scan_device drivers/media/usb/uvc/uvc_driver.c:1769 | uvc_probe+0x77f2/0x8f00 drivers/media/usb/uvc/uvc_driver.c:2104 Looking into the output from usbmon, the interesting part is the following data packet: ffff880069c63e00 30710169 C Ci:1:002:0 0 143 = 09028f00 01030080 00090403 00000e01 00000924 03000103 7c003328 010204db If we drop the lead configuration and interface descriptors, we're left with an output terminal descriptor describing a generic display: /* Output terminal descriptor */ buf[0] 09 buf[1] 24 buf[2] 03 /* UVC_VC_OUTPUT_TERMINAL */ buf[3] 00 /* ID */ buf[4] 01 /* type == 0x0301 (UVC_OTT_DISPLAY) */ buf[5] 03 buf[6] 7c buf[7] 00 /* source ID refers to self! */ buf[8] 33 The problem with this descriptor is that it is self-referential: the source ID of 0 matches itself! This causes the 'struct uvc_entity' representing the display to be added to its chain list twice during 'uvc_scan_chain()': once via 'uvc_scan_chain_entity()' when it is processed directly from the 'dev->entities' list and then again immediately afterwards when trying to follow the source ID in 'uvc_scan_chain_forward()' Add a check before adding an entity to a chain list to ensure that the entity is not already part of a chain. Cc: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Cc: Mauro Carvalho Chehab <mchehab(a)kernel.org> Cc: Dmitry Vyukov <dvyukov(a)google.com> Cc: Kostya Serebryany <kcc(a)google.com> Cc: <stable(a)vger.kernel.org> Fixes: c0efd232929c ("V4L/DVB (8145a): USB Video Class driver") Reported-by: Andrey Konovalov <andreyknvl(a)google.com> Link: https://lore.kernel.org/linux-media/CAAeHK+z+Si69jUR+N-SjN9q4O+o5KFiNManqEa… Signed-off-by: Will Deacon <will(a)kernel.org> --- That's right, it's the same patch again! No changes since either of: http://lkml.kernel.org/r/20191002112753.21630-1-will@kernel.org https://lore.kernel.org/lkml/20191016195800.22099-1-will@kernel.org Please consider merging. drivers/media/usb/uvc/uvc_driver.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc_driver.c index 66ee168ddc7e..e24420b1750a 100644 --- a/drivers/media/usb/uvc/uvc_driver.c +++ b/drivers/media/usb/uvc/uvc_driver.c @@ -1493,6 +1493,11 @@ static int uvc_scan_chain_forward(struct uvc_video_chain *chain, break; if (forward == prev) continue; + if (forward->chain.next || forward->chain.prev) { + uvc_trace(UVC_TRACE_DESCR, "Found reference to " + "entity %d already in chain.\n", forward->id); + return -EINVAL; + } switch (UVC_ENTITY_TYPE(forward)) { case UVC_VC_EXTENSION_UNIT: @@ -1574,6 +1579,13 @@ static int uvc_scan_chain_backward(struct uvc_video_chain *chain, return -1; } + if (term->chain.next || term->chain.prev) { + uvc_trace(UVC_TRACE_DESCR, "Found reference to " + "entity %d already in chain.\n", + term->id); + return -EINVAL; + } + if (uvc_trace_param & UVC_TRACE_PROBE) printk(KERN_CONT " %d", term->id); -- 2.24.0.rc1.363.gb1bccd3e3d-goog

5 years, 2 months

4
12
0 0

[PATCH] Revert "um: Enable CONFIG_CONSTRUCTORS"

by Johannes Berg

From: Johannes Berg <johannes.berg(a)intel.com> This reverts commit 786b2384bf1c ("um: Enable CONFIG_CONSTRUCTORS"). There are two issues with this commit, uncovered by Anton in tests on some (Debian) systems: 1) I completely forgot to call any constructors if CONFIG_CONSTRUCTORS isn't set. Don't recall now if it just wasn't needed on my system, or if I never tested this case. 2) With that fixed, it works - with CONFIG_CONSTRUCTORS *unset*. If I set CONFIG_CONSTRUCTORS, it fails again, which isn't totally unexpected since whatever wanted to run is likely to have to run before the kernel init etc. that calls the constructors in this case. Basically, some constructors that gcc emits (libc has?) need to run very early during init; the failure mode otherwise was that the ptrace fork test already failed: ---------------------- $ ./linux mem=512M Core dump limits : soft - 0 hard - NONE Checking that ptrace can change system call numbers...check_ptrace : child exited with exitcode 6, while expecting 0; status 0x67f Aborted ---------------------- Thinking more about this, it's clear that we simply cannot support CONFIG_CONSTRUCTORS in UML. All the cases we need now (gcov, kasan) involve not use of the __attribute__((constructor)), but instead some constructor code/entry generated by gcc. Therefore, we cannot distinguish between kernel constructors and system constructors. Thus, revert this commit. Cc: stable(a)vger.kernel.org [5.4+] Fixes: 786b2384bf1c ("um: Enable CONFIG_CONSTRUCTORS") Reported-by: Anton Ivanov <anton.ivanov(a)cambridgegreys.com> Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> --- arch/um/include/asm/common.lds.S | 2 +- arch/um/kernel/dyn.lds.S | 1 + init/Kconfig | 1 + kernel/gcov/Kconfig | 2 +- 4 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/um/include/asm/common.lds.S b/arch/um/include/asm/common.lds.S index d7086b985f27..4049f2c46387 100644 --- a/arch/um/include/asm/common.lds.S +++ b/arch/um/include/asm/common.lds.S @@ -83,8 +83,8 @@ __preinit_array_end = .; } .init_array : { - /* dummy - we call this ourselves */ __init_array_start = .; + *(.init_array) __init_array_end = .; } .fini_array : { diff --git a/arch/um/kernel/dyn.lds.S b/arch/um/kernel/dyn.lds.S index c69d69ee96be..f5001481010c 100644 --- a/arch/um/kernel/dyn.lds.S +++ b/arch/um/kernel/dyn.lds.S @@ -103,6 +103,7 @@ SECTIONS be empty, which isn't pretty. */ . = ALIGN(32 / 8); .preinit_array : { *(.preinit_array) } + .init_array : { *(.init_array) } .fini_array : { *(.fini_array) } .data : { INIT_TASK_DATA(KERNEL_STACK_SIZE) diff --git a/init/Kconfig b/init/Kconfig index b4daad2bac23..0328b53d09ad 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -54,6 +54,7 @@ config CC_DISABLE_WARN_MAYBE_UNINITIALIZED config CONSTRUCTORS bool + depends on !UML config IRQ_WORK bool diff --git a/kernel/gcov/Kconfig b/kernel/gcov/Kconfig index 060e8e726755..3941a9c48f83 100644 --- a/kernel/gcov/Kconfig +++ b/kernel/gcov/Kconfig @@ -4,7 +4,7 @@ menu "GCOV-based kernel profiling" config GCOV_KERNEL bool "Enable gcov-based kernel profiling" depends on DEBUG_FS - select CONSTRUCTORS + select CONSTRUCTORS if !UML default n ---help--- This option enables gcov-based code profiling (e.g. for code coverage -- 2.23.0

5 years, 2 months

3
2
0 0

[PATCH RFC 0/1] mount: universally disallow mounting over symlinks

by Aleksa Sarai

An undocumented feature of the mount interface was that it was possible to mount over a symlink (even with the old mount API) by mounting over /proc/self/fd/$n -- where the corresponding file descrpitor was opened with (O_PATH|O_NOFOLLOW). This didn't work with traditional "new" mounts (for a variety of reasons), but MS_BIND worked without issue. With the new mount API it was even easier. A reasonably detailed explanation of the issues is provided in the patch itself, but the full traces produced by both the oopses and deadlocks is included below (it makes little sense to include them in the commit since we are disabling this feature, not directly fixing the bugs themselves). I've posted this as an RFC on whether this feature should be allowed at all (and if anyone knows of legitimate uses for it), or if we should work on fixing these other kernel bugs that it exposes. Oops on NULL dereference: BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) - not-present page PGD 8000000181b1f067 P4D 8000000181b1f067 PUD 24829c067 PMD 0 Oops: 0010 [#1] SMP PTI CPU: 6 PID: 20796 Comm: mount_to_symlin Tainted: G OE 5.5.0-rc1+openat2~v18+ #123 Hardware name: LENOVO 20KHCTO1WW/20KHCTO1WW, BIOS N23ET55W (1.30 ) 08/31/2018 RIP: 0010:0x0 Code: Bad RIP value. RSP: 0018:ffffbc7d87e1bcb0 EFLAGS: 00010206 RAX: 0000000000000000 RBX: ffffa0c28cb633c0 RCX: 000000000000ae5a RDX: 0000000000000089 RSI: ffffa0c0eece8840 RDI: ffffa0c0eb8843b0 RBP: ffffa0c0eb8843b0 R08: ffffdc7d7fbbb770 R09: ffffa0c0ca333000 R10: 0000000000000000 R11: 808080807fffffff R12: ffffa0c0eece8840 R13: 0000000000000089 R14: ffffbc7d87e1bdb0 R15: 0000000000000080 FS: 00007fd921508540(0000) GS:ffffa0c3cf580000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffffffffd6 CR3: 000000018878a003 CR4: 00000000003606e0 Call Trace: __lookup_slow+0x94/0x160 lookup_slow+0x36/0x50 path_mountpoint+0x1be/0x350 filename_mountpoint+0xa5/0x150 ? __lookup_hash+0xa0/0xa0 ksys_umount+0x78/0x490 __x64_sys_umount+0x12/0x20 do_syscall_64+0x64/0x240 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x7fd92143f4e7 Code: 09 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 31 f6 e9 09 00 00 00 66 0f 1f 84 00 00 00 00 00 b8 a6 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 69 09 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007ffe98c89cc8 EFLAGS: 00000202 ORIG_RAX: 00000000000000a6 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fd92143f4e7 RDX: 0000000000000000 RSI: 0000000000000002 RDI: 000000000167a330 RBP: 00007ffe98c89da0 R08: 0000000000000000 R09: 000000000000000f R10: 00000000004004c6 R11: 0000000000000202 R12: 00000000004010c0 R13: 00007ffe98c89e80 R14: 0000000000000000 R15: 0000000000000000 CR2: 0000000000000000 Oops on kernel address: BUG: unable to handle page fault for address: ffffbc7d87e1bcc0 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 107d4a067 P4D 107d4a067 PUD 107d4b067 PMD 46d753067 PTE 0 Oops: 0002 [#2] SMP PTI CPU: 4 PID: 20975 Comm: mount_to_symlin Tainted: G D OE 5.5.0-rc1+openat2~v18+ #123 Hardware name: LENOVO 20KHCTO1WW/20KHCTO1WW, BIOS N23ET55W (1.30 ) 08/31/2018 RIP: 0010:_raw_spin_lock_irqsave+0x28/0x50 Code: 00 00 0f 1f 44 00 00 41 54 53 48 89 fb 9c 58 0f 1f 44 00 00 49 89 c4 fa 66 0f 1f 44 00 00 e8 3f 55 82 ff 31 c0 ba 01 00 00 00 <f0> 0f b1 13 75 07 4c 89 e0 5b 41 5c c3 89 c6 48 89 df e8 01 52 77 RSP: 0018:ffffbc7d90067bd8 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffffbc7d87e1bcc0 RCX: 0000000200000000 RDX: 0000000000000001 RSI: ffffbc7d90067c50 RDI: ffffbc7d87e1bcc0 RBP: ffffbc7d87e1bcc0 R08: 0000000000000001 R09: 0000000000000003 R10: 0000000000000000 R11: 808080807fffffff R12: 0000000000000246 R13: ffffa0c28cb633c0 R14: ffffbc7d90067db0 R15: ffffa0c0eece8898 FS: 00007f4b80214540(0000) GS:ffffa0c3cf500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffbc7d87e1bcc0 CR3: 000000026d4d0002 CR4: 00000000003606e0 Call Trace: add_wait_queue+0x15/0x40 d_alloc_parallel+0x36d/0x480 ? get_acl+0x1a/0x160 ? wake_up_q+0xa0/0xa0 __lookup_slow+0x6b/0x160 lookup_slow+0x36/0x50 path_mountpoint+0x1be/0x350 filename_mountpoint+0xa5/0x150 ? __lookup_hash+0xa0/0xa0 ksys_umount+0x78/0x490 __x64_sys_umount+0x12/0x20 do_syscall_64+0x64/0x240 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x7f4b8014b4e7 Code: 09 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 31 f6 e9 09 00 00 00 66 0f 1f 84 00 00 00 00 00 b8 a6 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 69 09 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007ffee8041b28 EFLAGS: 00000206 ORIG_RAX: 00000000000000a6 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f4b8014b4e7 RDX: 0000000000000000 RSI: 0000000000000002 RDI: 00000000019c8330 RBP: 00007ffee8041c00 R08: 0000000000000000 R09: 000000000000000f R10: 00000000004004c6 R11: 0000000000000206 R12: 00000000004010c0 R13: 00007ffee8041ce0 R14: 0000000000000000 R15: 0000000000000000 CR2: ffffbc7d87e1bcc0 Apparent deadlock in d_alloc_parallel: watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [mount_to_symlin:21285] CPU: 0 PID: 21285 Comm: mount_to_symlin Tainted: G D OE 5.5.0-rc1+openat2~v18+ #123 Hardware name: LENOVO 20KHCTO1WW/20KHCTO1WW, BIOS N23ET55W (1.30 ) 08/31/2018 RIP: 0010:native_queued_spin_lock_slowpath+0x5b/0x1d0 Code: 6d f0 0f ba 2f 08 0f 92 c0 0f b6 c0 c1 e0 08 89 c2 8b 07 30 e4 09 d0 a9 00 01 ff ff 75 47 85 c0 74 0e 8b 07 84 c0 74 08 f3 90 <8b> 07 84 c0 75 f8 b8 01 00 00 00 66 89 07 c3 8b 37 81 fe 00 01 00 RSP: 0018:ffffbc7d90547be8 EFLAGS: 00000202 ORIG_RAX: ffffffffffffff13 RAX: 0000000000000101 RBX: ffffffffbac7ac60 RCX: 0000000000000018 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffa0c0eece8898 RBP: ffffa0c0eece8898 R08: 00000000006f6f66 R09: 0000000000000003 R10: 0000000000000000 R11: 808080807fffffff R12: 00000000e25b3c73 R13: ffffa0c28cb633c0 R14: ffffbc7d90547db0 R15: ffffa0c0eece8898 FS: 00007fbb1fd30540(0000) GS:ffffa0c3cf400000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fbb1fbd25a0 CR3: 0000000181ace005 CR4: 00000000003606f0 Call Trace: _raw_spin_lock+0x1a/0x20 lockref_get_not_dead+0x4f/0x90 d_alloc_parallel+0x1a8/0x480 ? get_acl+0x1a/0x160 __lookup_slow+0x6b/0x160 lookup_slow+0x36/0x50 path_mountpoint+0x1be/0x350 filename_mountpoint+0xa5/0x150 ? __lookup_hash+0xa0/0xa0 ksys_umount+0x78/0x490 __x64_sys_umount+0x12/0x20 do_syscall_64+0x64/0x240 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x7fbb1fc674e7 Code: 09 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 31 f6 e9 09 00 00 00 66 0f 1f 84 00 00 00 00 00 b8 a6 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 69 09 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007ffd75fcb858 EFLAGS: 00000202 ORIG_RAX: 00000000000000a6 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fbb1fc674e7 RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000f6c330 RBP: 00007ffd75fcb930 R08: 0000000000000000 R09: 000000000000000f R10: 00000000004004a6 R11: 0000000000000202 R12: 00000000004010b0 R13: 00007ffd75fcba10 R14: 0000000000000000 R15: 0000000000000000 RCU stall when trying to grab /proc/$pid/stack for the stuck process: rcu: INFO: rcu_sched self-detected stall on CPU rcu: 0-....: (15000 ticks this GP) idle=2c6/1/0x4000000000000002 softirq=1172554/1172554 fqs=6849 (t=15001 jiffies g=1935177 q=25734) NMI backtrace for cpu 0 CPU: 0 PID: 21285 Comm: mount_to_symlin Tainted: G D OEL 5.5.0-rc1+openat2~v18+ #123 Hardware name: LENOVO 20KHCTO1WW/20KHCTO1WW, BIOS N23ET55W (1.30 ) 08/31/2018 Call Trace: <IRQ> dump_stack+0x8f/0xd0 ? lapic_can_unplug_cpu.cold+0x3e/0x3e nmi_cpu_backtrace.cold+0x14/0x52 nmi_trigger_cpumask_backtrace+0xf6/0xf8 rcu_dump_cpu_stacks+0x8f/0xbd rcu_sched_clock_irq.cold+0x1b2/0x39f update_process_times+0x24/0x50 tick_sched_handle+0x22/0x60 tick_sched_timer+0x38/0x80 ? tick_sched_do_timer+0x60/0x60 __hrtimer_run_queues+0xf6/0x270 hrtimer_interrupt+0x10e/0x240 smp_apic_timer_interrupt+0x6c/0x130 apic_timer_interrupt+0xf/0x20 </IRQ> RIP: 0010:native_queued_spin_lock_slowpath+0x5b/0x1d0 Code: 6d f0 0f ba 2f 08 0f 92 c0 0f b6 c0 c1 e0 08 89 c2 8b 07 30 e4 09 d0 a9 00 01 ff ff 75 47 85 c0 74 0e 8b 07 84 c0 74 08 f3 90 <8b> 07 84 c0 75 f8 b8 01 00 00 00 66 89 07 c3 8b 37 81 fe 00 01 00 RSP: 0018:ffffbc7d90547be8 EFLAGS: 00000202 ORIG_RAX: ffffffffffffff13 RAX: 0000000000000101 RBX: ffffffffbac7ac60 RCX: 0000000000000018 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffa0c0eece8898 RBP: ffffa0c0eece8898 R08: 00000000006f6f66 R09: 0000000000000003 R10: 0000000000000000 R11: 808080807fffffff R12: 00000000e25b3c73 R13: ffffa0c28cb633c0 R14: ffffbc7d90547db0 R15: ffffa0c0eece8898 _raw_spin_lock+0x1a/0x20 lockref_get_not_dead+0x4f/0x90 d_alloc_parallel+0x1a8/0x480 ? get_acl+0x1a/0x160 __lookup_slow+0x6b/0x160 lookup_slow+0x36/0x50 path_mountpoint+0x1be/0x350 filename_mountpoint+0xa5/0x150 ? __lookup_hash+0xa0/0xa0 ksys_umount+0x78/0x490 __x64_sys_umount+0x12/0x20 do_syscall_64+0x64/0x240 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x7fbb1fc674e7 Code: 09 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 31 f6 e9 09 00 00 00 66 0f 1f 84 00 00 00 00 00 b8 a6 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 69 09 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007ffd75fcb858 EFLAGS: 00000202 ORIG_RAX: 00000000000000a6 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fbb1fc674e7 RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000f6c330 RBP: 00007ffd75fcb930 R08: 0000000000000000 R09: 000000000000000f R10: 00000000004004a6 R11: 0000000000000202 R12: 00000000004010b0 R13: 00007ffd75fcba10 R14: 0000000000000000 R15: 0000000000000000 Deadlock on lock_mount after a successful umount(). The watchdog does trigger, but I could only find this stall when trying to suspend the system in my logs: Freezing of tasks failed after 20.010 seconds (2 tasks refusing to freeze, wq_busy=0): mount_to_symlin D 0 5850 5849 0x00000004 Call Trace: ? __schedule+0x2dd/0x770 schedule+0x4a/0xb0 rwsem_down_write_slowpath+0x256/0x500 lock_mount+0x22/0xf0 do_mount+0x4b7/0x9f0 ksys_mount+0x7e/0xc0 __x64_sys_mount+0x21/0x30 do_syscall_64+0x64/0x240 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x7f86e6355fda Code: Bad RIP value. RSP: 002b:00007ffc36f952d8 EFLAGS: 00000206 ORIG_RAX: 00000000000000a5 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f86e6355fda RDX: 0000000000402099 RSI: 00000000019a5310 RDI: 00007ffc36f96ee1 RBP: 00007ffc36f953b0 R08: 0000000000402099 R09: 000000000000000f R10: 0000000000001000 R11: 0000000000000206 R12: 00000000004010c0 R13: 00007ffc36f95490 R14: 0000000000000000 R15: 0000000000000000 Cc: stable(a)vger.kernel.org # pre-git Cc: Al Viro <viro(a)zeniv.linux.org.uk> Cc: David Howells <dhowells(a)redhat.com> Cc: Eric Biederman <ebiederm(a)xmission.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Aleksa Sarai <cyphar(a)cyphar.com> Aleksa Sarai (1): mount: universally disallow mounting over symlinks fs/namespace.c | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) base-commit: fd6988496e79a6a4bdb514a4655d2920209eb85d -- 2.24.1

5 years, 2 months

7
52
0 0

[PATCH v2 10/13] KVM: x86: Protect memory accesses from Spectre-v1/L1TF attacks in x86.c

by Marios Pomonis

This fixes Spectre-v1/L1TF vulnerabilities in vmx_read_guest_seg_selector(), vmx_read_guest_seg_base(), vmx_read_guest_seg_limit() and vmx_read_guest_seg_ar(). These functions contain index computations based on the (attacker-influenced) segment value. Fixes: commit 2fb92db1ec08 ("KVM: VMX: Cache vmcs segment fields") Signed-off-by: Nick Finco <nifi(a)google.com> Signed-off-by: Marios Pomonis <pomonis(a)google.com> Reviewed-by: Andrew Honig <ahonig(a)google.com> Cc: stable(a)vger.kernel.org --- arch/x86/kvm/vmx/vmx.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c index d39475e2d44e..82b25f1812aa 100644 --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -753,7 +753,9 @@ static bool vmx_segment_cache_test_set(struct vcpu_vmx *vmx, unsigned seg, static u16 vmx_read_guest_seg_selector(struct vcpu_vmx *vmx, unsigned seg) { - u16 *p = &vmx->segment_cache.seg[seg].selector; + size_t size = ARRAY_SIZE(vmx->segment_cache.seg); + size_t index = array_index_nospec(seg, size); + u16 *p = &vmx->segment_cache.seg[index].selector; if (!vmx_segment_cache_test_set(vmx, seg, SEG_FIELD_SEL)) *p = vmcs_read16(kvm_vmx_segment_fields[seg].selector); @@ -762,7 +764,9 @@ static u16 vmx_read_guest_seg_selector(struct vcpu_vmx *vmx, unsigned seg) static ulong vmx_read_guest_seg_base(struct vcpu_vmx *vmx, unsigned seg) { - ulong *p = &vmx->segment_cache.seg[seg].base; + size_t size = ARRAY_SIZE(vmx->segment_cache.seg); + size_t index = array_index_nospec(seg, size); + ulong *p = &vmx->segment_cache.seg[index].base; if (!vmx_segment_cache_test_set(vmx, seg, SEG_FIELD_BASE)) *p = vmcs_readl(kvm_vmx_segment_fields[seg].base); @@ -771,7 +775,9 @@ static ulong vmx_read_guest_seg_base(struct vcpu_vmx *vmx, unsigned seg) static u32 vmx_read_guest_seg_limit(struct vcpu_vmx *vmx, unsigned seg) { - u32 *p = &vmx->segment_cache.seg[seg].limit; + size_t size = ARRAY_SIZE(vmx->segment_cache.seg); + size_t index = array_index_nospec(seg, size); + u32 *p = &vmx->segment_cache.seg[index].limit; if (!vmx_segment_cache_test_set(vmx, seg, SEG_FIELD_LIMIT)) *p = vmcs_read32(kvm_vmx_segment_fields[seg].limit); @@ -780,7 +786,9 @@ static u32 vmx_read_guest_seg_limit(struct vcpu_vmx *vmx, unsigned seg) static u32 vmx_read_guest_seg_ar(struct vcpu_vmx *vmx, unsigned seg) { - u32 *p = &vmx->segment_cache.seg[seg].ar; + size_t size = ARRAY_SIZE(vmx->segment_cache.seg); + size_t index = array_index_nospec(seg, size); + u32 *p = &vmx->segment_cache.seg[index].ar; if (!vmx_segment_cache_test_set(vmx, seg, SEG_FIELD_AR)) *p = vmcs_read32(kvm_vmx_segment_fields[seg].ar_bytes); -- 2.24.0.525.g8f36a354ae-goog

5 years, 2 months

3
2
0 0

[PATCH v1 1/2] scsi: ufs: set device as default active power mode during initialization only

by Stanley Chu

Currently ufshcd_probe_hba() always sets device status as "active". This shall be by an assumption that device is already in active state during the boot stage before kernel. However, if link is configured as "off" state and device is requested to enter "sleep" or "powerdown" power mode during suspend flow, device will NOT be waken up to "active" power mode during resume flow because device is already set as "active" power mode in ufhcd_probe_hba(). Fix it by setting device as default active power mode during initialization only, and skipping changing mode during PM flow in ufshcd_probe_hba(). Fixes: 7caf489b99a4 (scsi: ufs: issue link starup 2 times if device isn't active) Cc: Alim Akhtar <alim.akhtar(a)samsung.com> Cc: Avri Altman <avri.altman(a)wdc.com> Cc: Bart Van Assche <bvanassche(a)acm.org> Cc: Bean Huo <beanhuo(a)micron.com> Cc: Can Guo <cang(a)codeaurora.org> Cc: Matthias Brugger <matthias.bgg(a)gmail.com> Cc: Subhash Jadavani <subhashj(a)codeaurora.org> Cc: stable(a)vger.kernel.org Signed-off-by: Stanley Chu <stanley.chu(a)mediatek.com> --- drivers/scsi/ufs/ufshcd.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c index ed02a704c1c2..9abb7085a5d0 100644 --- a/drivers/scsi/ufs/ufshcd.c +++ b/drivers/scsi/ufs/ufshcd.c @@ -6986,7 +6986,8 @@ static int ufshcd_probe_hba(struct ufs_hba *hba) ufshcd_tune_unipro_params(hba); /* UFS device is also active now */ - ufshcd_set_ufs_dev_active(hba); + if (!hba->pm_op_in_progress) + ufshcd_set_ufs_dev_active(hba); ufshcd_force_reset_auto_bkops(hba); hba->wlun_dev_clr_ua = true; -- 2.18.0

5 years, 2 months

4
12
0 0

[PATCH] ubifs: Fix wrong memory allocation

by Sascha Hauer

In create_default_filesystem() when we allocate the idx node we must use the idx_node_size we calculated just one line before, not tmp, which contains completely other data. Fixes: c4de6d7e4319 ("ubifs: Refactor create_default_filesystem()") Cc: stable(a)vger.kernel.org # v4.20+ Reported-by: Naga Sureshkumar Relli <nagasure(a)xilinx.com> Tested-by: Naga Sureshkumar Relli <nagasure(a)xilinx.com> Signed-off-by: Sascha Hauer <s.hauer(a)pengutronix.de> --- fs/ubifs/sb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/ubifs/sb.c b/fs/ubifs/sb.c index 2b7c04bf8983..17c90dff7266 100644 --- a/fs/ubifs/sb.c +++ b/fs/ubifs/sb.c @@ -161,7 +161,7 @@ static int create_default_filesystem(struct ubifs_info *c) sup = kzalloc(ALIGN(UBIFS_SB_NODE_SZ, c->min_io_size), GFP_KERNEL); mst = kzalloc(c->mst_node_alsz, GFP_KERNEL); idx_node_size = ubifs_idx_node_sz(c, 1); - idx = kzalloc(ALIGN(tmp, c->min_io_size), GFP_KERNEL); + idx = kzalloc(ALIGN(idx_node_size, c->min_io_size), GFP_KERNEL); ino = kzalloc(ALIGN(UBIFS_INO_NODE_SZ, c->min_io_size), GFP_KERNEL); cs = kzalloc(ALIGN(UBIFS_CS_NODE_SZ, c->min_io_size), GFP_KERNEL); -- 2.24.0

5 years, 2 months

2
1
0 0

[PATCH] ARM: davinci: select CONFIG_RESET_CONTROLLER

by Arnd Bergmann

Selecting RESET_CONTROLLER is actually required, otherwise we can get a link failure in the clock driver: drivers/clk/davinci/psc.o: In function `__davinci_psc_register_clocks': psc.c:(.text+0x9a0): undefined reference to `devm_reset_controller_register' drivers/clk/davinci/psc-da850.o: In function `da850_psc0_init': psc-da850.c:(.text+0x24): undefined reference to `reset_controller_add_lookup' Fixes: f962396ce292 ("ARM: davinci: support multiplatform build for ARM v5") Cc: <stable(a)vger.kernel.org> # v5.4 Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- arch/arm/mach-davinci/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig index dd427bd2768c..02b180ad7245 100644 --- a/arch/arm/mach-davinci/Kconfig +++ b/arch/arm/mach-davinci/Kconfig @@ -9,6 +9,7 @@ menuconfig ARCH_DAVINCI select PM_GENERIC_DOMAINS if PM select PM_GENERIC_DOMAINS_OF if PM && OF select REGMAP_MMIO + select RESET_CONTROLLER select HAVE_IDE select PINCTRL_SINGLE -- 2.20.0

5 years, 2 months

7
8
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror December 2019