From: Greg Kroah-Hartman Date: Mon, 24 Nov 2025 13:43:40 +0000 (+0100) Subject: 6.1-stable patches X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=55df554b1c0644c6cb522a5293dd7f9ea31b0272;p=thirdparty%2Fkernel%2Fstable-queue.git 6.1-stable patches added patches: input-cros_ec_keyb-fix-an-invalid-memory-access.patch input-imx_sc_key-fix-memory-corruption-on-unload.patch input-pegasus-notetaker-fix-potential-out-of-bounds-access.patch loongarch-don-t-panic-if-no-valid-cache-info-for-pci.patch mips-malta-fix-eva-soc-it-pci-mmio.patch mptcp-fix-race-condition-in-mptcp_schedule_work.patch nvme-nvme-fc-ensure-ioerr_work-is-cancelled-in-nvme_fc_delete_ctrl.patch scsi-sg-do-not-sleep-in-atomic-context.patch scsi-target-tcm_loop-fix-segfault-in-tcm_loop_tpg_address_show.patch --- diff --git a/queue-6.1/input-cros_ec_keyb-fix-an-invalid-memory-access.patch b/queue-6.1/input-cros_ec_keyb-fix-an-invalid-memory-access.patch new file mode 100644 index 0000000000..18a67836fe --- /dev/null +++ b/queue-6.1/input-cros_ec_keyb-fix-an-invalid-memory-access.patch @@ -0,0 +1,53 @@ +From e08969c4d65ac31297fcb4d31d4808c789152f68 Mon Sep 17 00:00:00 2001 +From: Tzung-Bi Shih +Date: Tue, 4 Nov 2025 07:03:10 +0000 +Subject: Input: cros_ec_keyb - fix an invalid memory access + +From: Tzung-Bi Shih + +commit e08969c4d65ac31297fcb4d31d4808c789152f68 upstream. + +If cros_ec_keyb_register_matrix() isn't called (due to +`buttons_switches_only`) in cros_ec_keyb_probe(), `ckdev->idev` remains +NULL. An invalid memory access is observed in cros_ec_keyb_process() +when receiving an EC_MKBP_EVENT_KEY_MATRIX event in cros_ec_keyb_work() +in such case. + + Unable to handle kernel read from unreadable memory at virtual address 0000000000000028 + ... + x3 : 0000000000000000 x2 : 0000000000000000 + x1 : 0000000000000000 x0 : 0000000000000000 + Call trace: + input_event + cros_ec_keyb_work + blocking_notifier_call_chain + ec_irq_thread + +It's still unknown about why the kernel receives such malformed event, +in any cases, the kernel shouldn't access `ckdev->idev` and friends if +the driver doesn't intend to initialize them. + +Signed-off-by: Tzung-Bi Shih +Link: https://patch.msgid.link/20251104070310.3212712-1-tzungbi@kernel.org +Cc: stable@vger.kernel.org +Signed-off-by: Dmitry Torokhov +Signed-off-by: Greg Kroah-Hartman +--- + drivers/input/keyboard/cros_ec_keyb.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +--- a/drivers/input/keyboard/cros_ec_keyb.c ++++ b/drivers/input/keyboard/cros_ec_keyb.c +@@ -248,6 +248,12 @@ static int cros_ec_keyb_work(struct noti + case EC_MKBP_EVENT_KEY_MATRIX: + pm_wakeup_event(ckdev->dev, 0); + ++ if (!ckdev->idev) { ++ dev_warn_once(ckdev->dev, ++ "Unexpected key matrix event\n"); ++ return NOTIFY_OK; ++ } ++ + if (ckdev->ec->event_size != ckdev->cols) { + dev_err(ckdev->dev, + "Discarded incomplete key matrix event.\n"); diff --git a/queue-6.1/input-imx_sc_key-fix-memory-corruption-on-unload.patch b/queue-6.1/input-imx_sc_key-fix-memory-corruption-on-unload.patch new file mode 100644 index 0000000000..a7a864b8e3 --- /dev/null +++ b/queue-6.1/input-imx_sc_key-fix-memory-corruption-on-unload.patch @@ -0,0 +1,36 @@ +From d83f1512758f4ef6fc5e83219fe7eeeb6b428ea4 Mon Sep 17 00:00:00 2001 +From: Dan Carpenter +Date: Sat, 1 Nov 2025 16:25:27 +0300 +Subject: Input: imx_sc_key - fix memory corruption on unload + +From: Dan Carpenter + +commit d83f1512758f4ef6fc5e83219fe7eeeb6b428ea4 upstream. + +This is supposed to be "priv" but we accidentally pass "&priv" which is +an address in the stack and so it will lead to memory corruption when +the imx_sc_key_action() function is called. Remove the &. + +Fixes: 768062fd1284 ("Input: imx_sc_key - use devm_add_action_or_reset() to handle all cleanups") +Signed-off-by: Dan Carpenter +Reviewed-by: Peng Fan +Reviewed-by: Frank Li +Link: https://patch.msgid.link/aQYKR75r2VMFJutT@stanley.mountain +Cc: stable@vger.kernel.org +Signed-off-by: Dmitry Torokhov +Signed-off-by: Greg Kroah-Hartman +--- + drivers/input/keyboard/imx_sc_key.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/input/keyboard/imx_sc_key.c ++++ b/drivers/input/keyboard/imx_sc_key.c +@@ -158,7 +158,7 @@ static int imx_sc_key_probe(struct platf + return error; + } + +- error = devm_add_action_or_reset(&pdev->dev, imx_sc_key_action, &priv); ++ error = devm_add_action_or_reset(&pdev->dev, imx_sc_key_action, priv); + if (error) + return error; + diff --git a/queue-6.1/input-pegasus-notetaker-fix-potential-out-of-bounds-access.patch b/queue-6.1/input-pegasus-notetaker-fix-potential-out-of-bounds-access.patch new file mode 100644 index 0000000000..05b21a912d --- /dev/null +++ b/queue-6.1/input-pegasus-notetaker-fix-potential-out-of-bounds-access.patch @@ -0,0 +1,54 @@ +From 69aeb507312306f73495598a055293fa749d454e Mon Sep 17 00:00:00 2001 +From: Seungjin Bae +Date: Fri, 17 Oct 2025 15:36:31 -0700 +Subject: Input: pegasus-notetaker - fix potential out-of-bounds access + +From: Seungjin Bae + +commit 69aeb507312306f73495598a055293fa749d454e upstream. + +In the pegasus_notetaker driver, the pegasus_probe() function allocates +the URB transfer buffer using the wMaxPacketSize value from +the endpoint descriptor. An attacker can use a malicious USB descriptor +to force the allocation of a very small buffer. + +Subsequently, if the device sends an interrupt packet with a specific +pattern (e.g., where the first byte is 0x80 or 0x42), +the pegasus_parse_packet() function parses the packet without checking +the allocated buffer size. This leads to an out-of-bounds memory access. + +Fixes: 1afca2b66aac ("Input: add Pegasus Notetaker tablet driver") +Signed-off-by: Seungjin Bae +Link: https://lore.kernel.org/r/20251007214131.3737115-2-eeodqql09@gmail.com +Cc: stable@vger.kernel.org +Signed-off-by: Dmitry Torokhov +Signed-off-by: Greg Kroah-Hartman +--- + drivers/input/tablet/pegasus_notetaker.c | 9 +++++++++ + 1 file changed, 9 insertions(+) + +--- a/drivers/input/tablet/pegasus_notetaker.c ++++ b/drivers/input/tablet/pegasus_notetaker.c +@@ -63,6 +63,9 @@ + #define BUTTON_PRESSED 0xb5 + #define COMMAND_VERSION 0xa9 + ++/* 1 Status + 1 Color + 2 X + 2 Y = 6 bytes */ ++#define NOTETAKER_PACKET_SIZE 6 ++ + /* in xy data packet */ + #define BATTERY_NO_REPORT 0x40 + #define BATTERY_LOW 0x41 +@@ -303,6 +306,12 @@ static int pegasus_probe(struct usb_inte + } + + pegasus->data_len = usb_maxpacket(dev, pipe); ++ if (pegasus->data_len < NOTETAKER_PACKET_SIZE) { ++ dev_err(&intf->dev, "packet size is too small (%d)\n", ++ pegasus->data_len); ++ error = -EINVAL; ++ goto err_free_mem; ++ } + + pegasus->data = usb_alloc_coherent(dev, pegasus->data_len, GFP_KERNEL, + &pegasus->data_dma); diff --git a/queue-6.1/loongarch-don-t-panic-if-no-valid-cache-info-for-pci.patch b/queue-6.1/loongarch-don-t-panic-if-no-valid-cache-info-for-pci.patch new file mode 100644 index 0000000000..421b455c32 --- /dev/null +++ b/queue-6.1/loongarch-don-t-panic-if-no-valid-cache-info-for-pci.patch @@ -0,0 +1,39 @@ +From a6b533adfc05ba15360631e019d3e18275080275 Mon Sep 17 00:00:00 2001 +From: Huacai Chen +Date: Thu, 20 Nov 2025 14:42:05 +0800 +Subject: LoongArch: Don't panic if no valid cache info for PCI + +From: Huacai Chen + +commit a6b533adfc05ba15360631e019d3e18275080275 upstream. + +If there is no valid cache info detected (may happen in virtual machine) +for pci_dfl_cache_line_size, kernel shouldn't panic. Because in the PCI +core it will be evaluated to (L1_CACHE_BYTES >> 2). + +Cc: +Signed-off-by: Jiaxun Yang +Signed-off-by: Huacai Chen +Signed-off-by: Greg Kroah-Hartman +--- + arch/loongarch/pci/pci.c | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +--- a/arch/loongarch/pci/pci.c ++++ b/arch/loongarch/pci/pci.c +@@ -51,11 +51,11 @@ static int __init pcibios_init(void) + */ + lsize = cpu_last_level_cache_line_size(); + +- BUG_ON(!lsize); ++ if (lsize) { ++ pci_dfl_cache_line_size = lsize >> 2; + +- pci_dfl_cache_line_size = lsize >> 2; +- +- pr_debug("PCI: pci_cache_line_size set to %d bytes\n", lsize); ++ pr_debug("PCI: pci_cache_line_size set to %d bytes\n", lsize); ++ } + + return 0; + } diff --git a/queue-6.1/mips-malta-fix-eva-soc-it-pci-mmio.patch b/queue-6.1/mips-malta-fix-eva-soc-it-pci-mmio.patch new file mode 100644 index 0000000000..bc046668ad --- /dev/null +++ b/queue-6.1/mips-malta-fix-eva-soc-it-pci-mmio.patch @@ -0,0 +1,100 @@ +From ebd729fef31620e0bf74cbf8a4c7fda73a2a4e7e Mon Sep 17 00:00:00 2001 +From: "Maciej W. Rozycki" +Date: Mon, 20 Oct 2025 02:11:49 +0100 +Subject: MIPS: Malta: Fix !EVA SOC-it PCI MMIO + +From: Maciej W. Rozycki + +commit ebd729fef31620e0bf74cbf8a4c7fda73a2a4e7e upstream. + +Fix a regression that has caused accesses to the PCI MMIO window to +complete unclaimed in non-EVA configurations with the SOC-it family of +system controllers, preventing PCI devices from working that use MMIO. + +In the non-EVA case PHYS_OFFSET is set to 0, meaning that PCI_BAR0 is +set with an empty mask (and PCI_HEAD4 matches addresses starting from 0 +accordingly). Consequently all addresses are matched for incoming DMA +accesses from PCI. This seems to confuse the system controller's logic +and outgoing bus cycles targeting the PCI MMIO window seem not to make +it to the intended devices. + +This happens as well when a wider mask is used with PCI_BAR0, such as +0x80000000 or 0xe0000000, that makes addresses match that overlap with +the PCI MMIO window, which starts at 0x10000000 in our configuration. + +Set the mask in PCI_BAR0 to 0xf0000000 for non-EVA then, covering the +non-EVA maximum 256 MiB of RAM, which is what YAMON does and which used +to work correctly up to the offending commit. Set PCI_P2SCMSKL to match +PCI_BAR0 as required by the system controller's specification, and match +PCI_P2SCMAPL to PCI_HEAD4 for identity mapping. + +Verified with: + +Core board type/revision = 0x0d (Core74K) / 0x01 +System controller/revision = MIPS SOC-it 101 OCP / 1.3 SDR-FW-4:1 +Processor Company ID/options = 0x01 (MIPS Technologies, Inc.) / 0x1c +Processor ID/revision = 0x97 (MIPS 74Kf) / 0x4c + +for non-EVA and with: + +Core board type/revision = 0x0c (CoreFPGA-5) / 0x00 +System controller/revision = MIPS ROC-it2 / 0.0 FW-1:1 (CLK_unknown) GIC +Processor Company ID/options = 0x01 (MIPS Technologies, Inc.) / 0x00 +Processor ID/revision = 0xa0 (MIPS interAptiv UP) / 0x20 + +for EVA/non-EVA, fixing: + +defxx 0000:00:12.0: assign IRQ: got 10 +defxx: v1.12 2021/03/10 Lawrence V. Stefani and others +0000:00:12.0: Could not read adapter factory MAC address! + +vs: + +defxx 0000:00:12.0: assign IRQ: got 10 +defxx: v1.12 2021/03/10 Lawrence V. Stefani and others +0000:00:12.0: DEFPA at MMIO addr = 0x10142000, IRQ = 10, Hardware addr = 00-00-f8-xx-xx-xx +0000:00:12.0: registered as fddi0 + +for non-EVA and causing no change for EVA. + +Signed-off-by: Maciej W. Rozycki +Fixes: 422dd256642b ("MIPS: Malta: Allow PCI devices DMA to lower 2GB physical") +Cc: stable@vger.kernel.org # v4.9+ +Signed-off-by: Thomas Bogendoerfer +Signed-off-by: Greg Kroah-Hartman +--- + arch/mips/mti-malta/malta-init.c | 20 +++++++++++++------- + 1 file changed, 13 insertions(+), 7 deletions(-) + +--- a/arch/mips/mti-malta/malta-init.c ++++ b/arch/mips/mti-malta/malta-init.c +@@ -241,16 +241,22 @@ mips_pci_controller: + #endif + + /* +- * Setup the Malta max (2GB) memory for PCI DMA in host bridge +- * in transparent addressing mode. ++ * Set up memory mapping in host bridge for PCI DMA masters, ++ * in transparent addressing mode. For EVA use the Malta ++ * maximum of 2 GiB memory in the alias space at 0x80000000 ++ * as per PHYS_OFFSET. Otherwise use 256 MiB of memory in ++ * the regular space, avoiding mapping the PCI MMIO window ++ * for DMA as it seems to confuse the system controller's ++ * logic, causing PCI MMIO to stop working. + */ +- mask = PHYS_OFFSET | PCI_BASE_ADDRESS_MEM_PREFETCH; +- MSC_WRITE(MSC01_PCI_BAR0, mask); +- MSC_WRITE(MSC01_PCI_HEAD4, mask); ++ mask = PHYS_OFFSET ? PHYS_OFFSET : 0xf0000000; ++ MSC_WRITE(MSC01_PCI_BAR0, ++ mask | PCI_BASE_ADDRESS_MEM_PREFETCH); ++ MSC_WRITE(MSC01_PCI_HEAD4, ++ PHYS_OFFSET | PCI_BASE_ADDRESS_MEM_PREFETCH); + +- mask &= MSC01_PCI_BAR0_SIZE_MSK; + MSC_WRITE(MSC01_PCI_P2SCMSKL, mask); +- MSC_WRITE(MSC01_PCI_P2SCMAPL, mask); ++ MSC_WRITE(MSC01_PCI_P2SCMAPL, PHYS_OFFSET); + + /* Don't handle target retries indefinitely. */ + if ((data & MSC01_PCI_CFG_MAXRTRY_MSK) == diff --git a/queue-6.1/mptcp-fix-race-condition-in-mptcp_schedule_work.patch b/queue-6.1/mptcp-fix-race-condition-in-mptcp_schedule_work.patch new file mode 100644 index 0000000000..b7868d8260 --- /dev/null +++ b/queue-6.1/mptcp-fix-race-condition-in-mptcp_schedule_work.patch @@ -0,0 +1,96 @@ +From 035bca3f017ee9dea3a5a756e77a6f7138cc6eea Mon Sep 17 00:00:00 2001 +From: Eric Dumazet +Date: Thu, 13 Nov 2025 10:39:24 +0000 +Subject: mptcp: fix race condition in mptcp_schedule_work() + +From: Eric Dumazet + +commit 035bca3f017ee9dea3a5a756e77a6f7138cc6eea upstream. + +syzbot reported use-after-free in mptcp_schedule_work() [1] + +Issue here is that mptcp_schedule_work() schedules a work, +then gets a refcount on sk->sk_refcnt if the work was scheduled. +This refcount will be released by mptcp_worker(). + +[A] if (schedule_work(...)) { +[B] sock_hold(sk); + return true; + } + +Problem is that mptcp_worker() can run immediately and complete before [B] + +We need instead : + + sock_hold(sk); + if (schedule_work(...)) + return true; + sock_put(sk); + +[1] +refcount_t: addition on 0; use-after-free. + WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25 +Call Trace: + + __refcount_add include/linux/refcount.h:-1 [inline] + __refcount_inc include/linux/refcount.h:366 [inline] + refcount_inc include/linux/refcount.h:383 [inline] + sock_hold include/net/sock.h:816 [inline] + mptcp_schedule_work+0x164/0x1a0 net/mptcp/protocol.c:943 + mptcp_tout_timer+0x21/0xa0 net/mptcp/protocol.c:2316 + call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747 + expire_timers kernel/time/timer.c:1798 [inline] + __run_timers kernel/time/timer.c:2372 [inline] + __run_timer_base+0x648/0x970 kernel/time/timer.c:2384 + run_timer_base kernel/time/timer.c:2393 [inline] + run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403 + handle_softirqs+0x22f/0x710 kernel/softirq.c:622 + __do_softirq kernel/softirq.c:656 [inline] + run_ktimerd+0xcf/0x190 kernel/softirq.c:1138 + smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160 + kthread+0x711/0x8a0 kernel/kthread.c:463 + ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 + ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 + +Cc: stable@vger.kernel.org +Fixes: 3b1d6210a957 ("mptcp: implement and use MPTCP-level retransmission") +Reported-by: syzbot+355158e7e301548a1424@syzkaller.appspotmail.com +Closes: https://lore.kernel.org/netdev/6915b46f.050a0220.3565dc.0028.GAE@google.com/T/#u +Signed-off-by: Eric Dumazet +Reviewed-by: Matthieu Baerts (NGI0) +Link: https://patch.msgid.link/20251113103924.3737425-1-edumazet@google.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + net/mptcp/protocol.c | 19 ++++++++++++------- + 1 file changed, 12 insertions(+), 7 deletions(-) + +--- a/net/mptcp/protocol.c ++++ b/net/mptcp/protocol.c +@@ -966,14 +966,19 @@ static void mptcp_reset_rtx_timer(struct + + bool mptcp_schedule_work(struct sock *sk) + { +- if (inet_sk_state_load(sk) != TCP_CLOSE && +- schedule_work(&mptcp_sk(sk)->work)) { +- /* each subflow already holds a reference to the sk, and the +- * workqueue is invoked by a subflow, so sk can't go away here. +- */ +- sock_hold(sk); ++ if (inet_sk_state_load(sk) == TCP_CLOSE) ++ return false; ++ ++ /* Get a reference on this socket, mptcp_worker() will release it. ++ * As mptcp_worker() might complete before us, we can not avoid ++ * a sock_hold()/sock_put() if schedule_work() returns false. ++ */ ++ sock_hold(sk); ++ ++ if (schedule_work(&mptcp_sk(sk)->work)) + return true; +- } ++ ++ sock_put(sk); + return false; + } + diff --git a/queue-6.1/nvme-nvme-fc-ensure-ioerr_work-is-cancelled-in-nvme_fc_delete_ctrl.patch b/queue-6.1/nvme-nvme-fc-ensure-ioerr_work-is-cancelled-in-nvme_fc_delete_ctrl.patch new file mode 100644 index 0000000000..e43a15882e --- /dev/null +++ b/queue-6.1/nvme-nvme-fc-ensure-ioerr_work-is-cancelled-in-nvme_fc_delete_ctrl.patch @@ -0,0 +1,90 @@ +From 0a2c5495b6d1ecb0fa18ef6631450f391a888256 Mon Sep 17 00:00:00 2001 +From: "Ewan D. Milne" +Date: Mon, 10 Nov 2025 16:20:01 -0500 +Subject: nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl() + +From: Ewan D. Milne + +commit 0a2c5495b6d1ecb0fa18ef6631450f391a888256 upstream. + +nvme_fc_delete_assocation() waits for pending I/O to complete before +returning, and an error can cause ->ioerr_work to be queued after +cancel_work_sync() had been called. Move the call to cancel_work_sync() to +be after nvme_fc_delete_association() to ensure ->ioerr_work is not running +when the nvme_fc_ctrl object is freed. Otherwise the following can occur: + +[ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL +[ 1135.917705] ------------[ cut here ]------------ +[ 1135.922336] kernel BUG at lib/list_debug.c:52! +[ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI +[ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary) +[ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025 +[ 1135.950969] Workqueue: 0x0 (nvme-wq) +[ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f +[ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b +[ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046 +[ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000 +[ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0 +[ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08 +[ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100 +[ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0 +[ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000 +[ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0 +[ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +[ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 +[ 1136.055910] PKRU: 55555554 +[ 1136.058623] Call Trace: +[ 1136.061074] +[ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0 +[ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0 +[ 1136.071898] ? move_linked_works+0x4a/0xa0 +[ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f +[ 1136.081744] ? __die_body.cold+0x8/0x12 +[ 1136.085584] ? die+0x2e/0x50 +[ 1136.088469] ? do_trap+0xca/0x110 +[ 1136.091789] ? do_error_trap+0x65/0x80 +[ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f +[ 1136.101289] ? exc_invalid_op+0x50/0x70 +[ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f +[ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20 +[ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f +[ 1136.120806] move_linked_works+0x4a/0xa0 +[ 1136.124733] worker_thread+0x216/0x3a0 +[ 1136.128485] ? __pfx_worker_thread+0x10/0x10 +[ 1136.132758] kthread+0xfa/0x240 +[ 1136.135904] ? __pfx_kthread+0x10/0x10 +[ 1136.139657] ret_from_fork+0x31/0x50 +[ 1136.143236] ? __pfx_kthread+0x10/0x10 +[ 1136.146988] ret_from_fork_asm+0x1a/0x30 +[ 1136.150915] + +Fixes: 19fce0470f05 ("nvme-fc: avoid calling _nvme_fc_abort_outstanding_ios from interrupt context") +Cc: stable@vger.kernel.org +Tested-by: Marco Patalano +Reviewed-by: Justin Tee +Signed-off-by: Ewan D. Milne +Signed-off-by: Keith Busch +Signed-off-by: Greg Kroah-Hartman +--- + drivers/nvme/host/fc.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/nvme/host/fc.c ++++ b/drivers/nvme/host/fc.c +@@ -3262,7 +3262,6 @@ nvme_fc_delete_ctrl(struct nvme_ctrl *nc + { + struct nvme_fc_ctrl *ctrl = to_fc_ctrl(nctrl); + +- cancel_work_sync(&ctrl->ioerr_work); + cancel_delayed_work_sync(&ctrl->connect_work); + /* + * kill the association on the link side. this will block +@@ -3333,6 +3332,7 @@ nvme_fc_reset_ctrl_work(struct work_stru + + /* will block will waiting for io to terminate */ + nvme_fc_delete_association(ctrl); ++ cancel_work_sync(&ctrl->ioerr_work); + + if (!nvme_change_ctrl_state(&ctrl->ctrl, NVME_CTRL_CONNECTING)) + dev_err(ctrl->ctrl.device, diff --git a/queue-6.1/scsi-sg-do-not-sleep-in-atomic-context.patch b/queue-6.1/scsi-sg-do-not-sleep-in-atomic-context.patch new file mode 100644 index 0000000000..8fa1fe08cb --- /dev/null +++ b/queue-6.1/scsi-sg-do-not-sleep-in-atomic-context.patch @@ -0,0 +1,47 @@ +From 90449f2d1e1f020835cba5417234636937dd657e Mon Sep 17 00:00:00 2001 +From: Bart Van Assche +Date: Thu, 13 Nov 2025 10:16:43 -0800 +Subject: scsi: sg: Do not sleep in atomic context + +From: Bart Van Assche + +commit 90449f2d1e1f020835cba5417234636937dd657e upstream. + +sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may +sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead +of disabled. + +Reported-by: syzbot+c01f8e6e73f20459912e@syzkaller.appspotmail.com +Closes: https://lore.kernel.org/linux-scsi/691560c4.a70a0220.3124cb.001a.GAE@google.com/ +Cc: Hannes Reinecke +Cc: stable@vger.kernel.org +Fixes: 97d27b0dd015 ("scsi: sg: close race condition in sg_remove_sfp_usercontext()") +Signed-off-by: Bart Van Assche +Link: https://patch.msgid.link/20251113181643.1108973-1-bvanassche@acm.org +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/scsi/sg.c | 10 +++++++++- + 1 file changed, 9 insertions(+), 1 deletion(-) + +--- a/drivers/scsi/sg.c ++++ b/drivers/scsi/sg.c +@@ -2204,9 +2204,17 @@ sg_remove_sfp_usercontext(struct work_st + write_lock_irqsave(&sfp->rq_list_lock, iflags); + while (!list_empty(&sfp->rq_list)) { + srp = list_first_entry(&sfp->rq_list, Sg_request, entry); +- sg_finish_rem_req(srp); + list_del(&srp->entry); ++ write_unlock_irqrestore(&sfp->rq_list_lock, iflags); ++ ++ sg_finish_rem_req(srp); ++ /* ++ * sg_rq_end_io() uses srp->parentfp. Hence, only clear ++ * srp->parentfp after blk_mq_free_request() has been called. ++ */ + srp->parentfp = NULL; ++ ++ write_lock_irqsave(&sfp->rq_list_lock, iflags); + } + write_unlock_irqrestore(&sfp->rq_list_lock, iflags); + diff --git a/queue-6.1/scsi-target-tcm_loop-fix-segfault-in-tcm_loop_tpg_address_show.patch b/queue-6.1/scsi-target-tcm_loop-fix-segfault-in-tcm_loop_tpg_address_show.patch new file mode 100644 index 0000000000..5b1147f493 --- /dev/null +++ b/queue-6.1/scsi-target-tcm_loop-fix-segfault-in-tcm_loop_tpg_address_show.patch @@ -0,0 +1,55 @@ +From e6965188f84a7883e6a0d3448e86b0cf29b24dfc Mon Sep 17 00:00:00 2001 +From: Hamza Mahfooz +Date: Wed, 5 Nov 2025 11:25:46 -0800 +Subject: scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show() + +From: Hamza Mahfooz + +commit e6965188f84a7883e6a0d3448e86b0cf29b24dfc upstream. + +If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we +attempt to dereference it in tcm_loop_tpg_address_show() we will get a +segfault, see below for an example. So, check tl_hba->sh before +dereferencing it. + + Unable to allocate struct scsi_host + BUG: kernel NULL pointer dereference, address: 0000000000000194 + #PF: supervisor read access in kernel mode + #PF: error_code(0x0000) - not-present page + PGD 0 P4D 0 + Oops: 0000 [#1] PREEMPT SMP NOPTI + CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 + Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 + RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] +... + Call Trace: + + configfs_read_iter+0x12d/0x1d0 [configfs] + vfs_read+0x1b5/0x300 + ksys_read+0x6f/0xf0 +... + +Cc: stable@vger.kernel.org +Fixes: 2628b352c3d4 ("tcm_loop: Show address of tpg in configfs") +Signed-off-by: Hamza Mahfooz +Reviewed-by: Chaitanya Kulkarni +Reviewed-by: Allen Pais +Link: https://patch.msgid.link/1762370746-6304-1-git-send-email-hamzamahfooz@linux.microsoft.com +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/target/loopback/tcm_loop.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/drivers/target/loopback/tcm_loop.c ++++ b/drivers/target/loopback/tcm_loop.c +@@ -934,6 +934,9 @@ static ssize_t tcm_loop_tpg_address_show + struct tcm_loop_tpg, tl_se_tpg); + struct tcm_loop_hba *tl_hba = tl_tpg->tl_hba; + ++ if (!tl_hba->sh) ++ return -ENODEV; ++ + return snprintf(page, PAGE_SIZE, "%d:0:%d\n", + tl_hba->sh->host_no, tl_tpg->tl_tpgt); + } diff --git a/queue-6.1/series b/queue-6.1/series index a7db34cabb..6ff75175bd 100644 --- a/queue-6.1/series +++ b/queue-6.1/series @@ -436,3 +436,12 @@ mips-mm-prevent-a-tlb-shutdown-on-initial-uniquification.patch ata-libata-scsi-add-missing-scsi_device_put-in-ata_scsi_dev_rescan.patch be2net-pass-wrb_params-in-case-of-os2bmc.patch net-dsa-microchip-lan937x-fix-rgmii-delay-tuning.patch +input-cros_ec_keyb-fix-an-invalid-memory-access.patch +input-imx_sc_key-fix-memory-corruption-on-unload.patch +input-pegasus-notetaker-fix-potential-out-of-bounds-access.patch +nvme-nvme-fc-ensure-ioerr_work-is-cancelled-in-nvme_fc_delete_ctrl.patch +scsi-sg-do-not-sleep-in-atomic-context.patch +scsi-target-tcm_loop-fix-segfault-in-tcm_loop_tpg_address_show.patch +mips-malta-fix-eva-soc-it-pci-mmio.patch +loongarch-don-t-panic-if-no-valid-cache-info-for-pci.patch +mptcp-fix-race-condition-in-mptcp_schedule_work.patch