From f2b5207fc0752da58f039943707dfd9c692c16e8 Mon Sep 17 00:00:00 2001 From: Jonathan Maple Date: Tue, 21 Oct 2025 18:24:57 -0400 Subject: [PATCH 01/11] udmabuf: Set the DMA mask for the udmabuf device (v2) jira VULN-69833 cve CVE-2022-49983 commit-author Vivek Kasireddy commit 9e9fa6a9198b767b00f48160800128e83a038f9f If the DMA mask is not set explicitly, the following warning occurs when the userspace tries to access the dma-buf via the CPU as reported by syzbot here: WARNING: CPU: 1 PID: 3595 at kernel/dma/mapping.c:188 __dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188 Modules linked in: CPU: 0 PID: 3595 Comm: syz-executor249 Not tainted 5.17.0-rc2-syzkaller-00316-g0457e5153e0e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188 Code: 00 00 00 00 00 fc ff df 48 c1 e8 03 80 3c 10 00 75 71 4c 8b 3d c0 83 b5 0d e9 db fe ff ff e8 b6 0f 13 00 0f 0b e8 af 0f 13 00 <0f> 0b 45 31 e4 e9 54 ff ff ff e8 a0 0f 13 00 49 8d 7f 50 48 b8 00 RSP: 0018:ffffc90002a07d68 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: ffff88807e25e2c0 RSI: ffffffff81649e91 RDI: ffff88801b848408 RBP: ffff88801b848000 R08: 0000000000000002 R09: ffff88801d86c74f R10: ffffffff81649d72 R11: 0000000000000001 R12: 0000000000000002 R13: ffff88801d86c680 R14: 0000000000000001 R15: 0000000000000000 FS: 0000555556e30300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200000cc CR3: 000000001d74a000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: dma_map_sgtable+0x70/0xf0 kernel/dma/mapping.c:264 get_sg_table.isra.0+0xe0/0x160 drivers/dma-buf/udmabuf.c:72 begin_cpu_udmabuf+0x130/0x1d0 drivers/dma-buf/udmabuf.c:126 dma_buf_begin_cpu_access+0xfd/0x1d0 drivers/dma-buf/dma-buf.c:1164 dma_buf_ioctl+0x259/0x2b0 drivers/dma-buf/dma-buf.c:363 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:874 [inline] __se_sys_ioctl fs/ioctl.c:860 [inline] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:860 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f62fcf530f9 Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffe3edab9b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f62fcf530f9 RDX: 0000000020000200 RSI: 0000000040086200 RDI: 0000000000000006 RBP: 00007f62fcf170e0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f62fcf17170 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 v2: Dont't forget to deregister if DMA mask setup fails. Reported-by: syzbot+10e27961f4da37c443b2@syzkaller.appspotmail.com Cc: Gerd Hoffmann Signed-off-by: Vivek Kasireddy Link: http://patchwork.freedesktop.org/patch/msgid/20220520205235.3687336-1-vivek.kasireddy@intel.com Signed-off-by: Gerd Hoffmann (cherry picked from commit 9e9fa6a9198b767b00f48160800128e83a038f9f) Signed-off-by: Jonathan Maple --- drivers/dma-buf/udmabuf.c | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c index 9631f2fd2faf7..38e8767ec3715 100644 --- a/drivers/dma-buf/udmabuf.c +++ b/drivers/dma-buf/udmabuf.c @@ -368,7 +368,23 @@ static struct miscdevice udmabuf_misc = { static int __init udmabuf_dev_init(void) { - return misc_register(&udmabuf_misc); + int ret; + + ret = misc_register(&udmabuf_misc); + if (ret < 0) { + pr_err("Could not initialize udmabuf device\n"); + return ret; + } + + ret = dma_coerce_mask_and_coherent(udmabuf_misc.this_device, + DMA_BIT_MASK(64)); + if (ret < 0) { + pr_err("Could not setup DMA mask for udmabuf device\n"); + misc_deregister(&udmabuf_misc); + return ret; + } + + return 0; } static void __exit udmabuf_dev_exit(void) From cbabb8800bec50721c8dd421f96d393dd39dfbf2 Mon Sep 17 00:00:00 2001 From: Jonathan Maple Date: Tue, 21 Oct 2025 18:25:01 -0400 Subject: [PATCH 02/11] bpf: Don't use tnum_range on array range checking for poke descriptors jira VULN-136653 cve CVE-2022-49985 commit-author Daniel Borkmann commit a657182a5c5150cdfacb6640aad1d2712571a409 Hsin-Wei reported a KASAN splat triggered by their BPF runtime fuzzer which is based on a customized syzkaller: BUG: KASAN: slab-out-of-bounds in bpf_int_jit_compile+0x1257/0x13f0 Read of size 8 at addr ffff888004e90b58 by task syz-executor.0/1489 CPU: 1 PID: 1489 Comm: syz-executor.0 Not tainted 5.19.0 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: dump_stack_lvl+0x9c/0xc9 print_address_description.constprop.0+0x1f/0x1f0 ? bpf_int_jit_compile+0x1257/0x13f0 kasan_report.cold+0xeb/0x197 ? kvmalloc_node+0x170/0x200 ? bpf_int_jit_compile+0x1257/0x13f0 bpf_int_jit_compile+0x1257/0x13f0 ? arch_prepare_bpf_dispatcher+0xd0/0xd0 ? rcu_read_lock_sched_held+0x43/0x70 bpf_prog_select_runtime+0x3e8/0x640 ? bpf_obj_name_cpy+0x149/0x1b0 bpf_prog_load+0x102f/0x2220 ? __bpf_prog_put.constprop.0+0x220/0x220 ? find_held_lock+0x2c/0x110 ? __might_fault+0xd6/0x180 ? lock_downgrade+0x6e0/0x6e0 ? lock_is_held_type+0xa6/0x120 ? __might_fault+0x147/0x180 __sys_bpf+0x137b/0x6070 ? bpf_perf_link_attach+0x530/0x530 ? new_sync_read+0x600/0x600 ? __fget_files+0x255/0x450 ? lock_downgrade+0x6e0/0x6e0 ? fput+0x30/0x1a0 ? ksys_write+0x1a8/0x260 __x64_sys_bpf+0x7a/0xc0 ? syscall_enter_from_user_mode+0x21/0x70 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f917c4e2c2d The problem here is that a range of tnum_range(0, map->max_entries - 1) has limited ability to represent the concrete tight range with the tnum as the set of resulting states from value + mask can result in a superset of the actual intended range, and as such a tnum_in(range, reg->var_off) check may yield true when it shouldn't, for example tnum_range(0, 2) would result in 00XX -> v = 0000, m = 0011 such that the intended set of {0, 1, 2} is here represented by a less precise superset of {0, 1, 2, 3}. As the register is known const scalar, really just use the concrete reg->var_off.value for the upper index check. Fixes: d2e4c1e6c294 ("bpf: Constant map key tracking for prog array pokes") Reported-by: Hsin-Wei Hung Signed-off-by: Daniel Borkmann Cc: Shung-Hsi Yu Acked-by: John Fastabend Link: https://lore.kernel.org/r/984b37f9fdf7ac36831d2137415a4a915744c1b6.1661462653.git.daniel@iogearbox.net Signed-off-by: Alexei Starovoitov (cherry picked from commit a657182a5c5150cdfacb6640aad1d2712571a409) Signed-off-by: Jonathan Maple --- kernel/bpf/verifier.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c index ba7a0b99036e7..f9bf6125b3448 100644 --- a/kernel/bpf/verifier.c +++ b/kernel/bpf/verifier.c @@ -5893,8 +5893,7 @@ record_func_key(struct bpf_verifier_env *env, struct bpf_call_arg_meta *meta, struct bpf_insn_aux_data *aux = &env->insn_aux_data[insn_idx]; struct bpf_reg_state *regs = cur_regs(env), *reg; struct bpf_map *map = meta->map_ptr; - struct tnum range; - u64 val; + u64 val, max; int err; if (func_id != BPF_FUNC_tail_call) @@ -5904,10 +5903,11 @@ record_func_key(struct bpf_verifier_env *env, struct bpf_call_arg_meta *meta, return -EINVAL; } - range = tnum_range(0, map->max_entries - 1); reg = ®s[BPF_REG_3]; + val = reg->var_off.value; + max = map->max_entries; - if (!register_is_const(reg) || !tnum_in(range, reg->var_off)) { + if (!(register_is_const(reg) && val < max)) { bpf_map_key_store(aux, BPF_MAP_KEY_POISON); return 0; } @@ -5915,8 +5915,6 @@ record_func_key(struct bpf_verifier_env *env, struct bpf_call_arg_meta *meta, err = mark_chain_precision(env, BPF_REG_3); if (err) return err; - - val = reg->var_off.value; if (bpf_map_key_unseen(aux)) bpf_map_key_store(aux, val); else if (!bpf_map_key_poisoned(aux) && From c8b67139cccc672206dc3617f159a57f84f4781b Mon Sep 17 00:00:00 2001 From: Jonathan Maple Date: Tue, 21 Oct 2025 18:25:04 -0400 Subject: [PATCH 03/11] scsi: storvsc: Remove WQ_MEM_RECLAIM from storvsc_error_wq jira VULN-69284 cve CVE-2022-49986 commit-author Saurabh Sengar commit d957e7ffb2c72410bcc1a514153a46719255a5da storvsc_error_wq workqueue should not be marked as WQ_MEM_RECLAIM as it doesn't need to make forward progress under memory pressure. Marking this workqueue as WQ_MEM_RECLAIM may cause deadlock while flushing a non-WQ_MEM_RECLAIM workqueue. In the current state it causes the following warning: [ 14.506347] ------------[ cut here ]------------ [ 14.506354] workqueue: WQ_MEM_RECLAIM storvsc_error_wq_0:storvsc_remove_lun is flushing !WQ_MEM_RECLAIM events_freezable_power_:disk_events_workfn [ 14.506360] WARNING: CPU: 0 PID: 8 at <-snip->kernel/workqueue.c:2623 check_flush_dependency+0xb5/0x130 [ 14.506390] CPU: 0 PID: 8 Comm: kworker/u4:0 Not tainted 5.4.0-1086-azure #91~18.04.1-Ubuntu [ 14.506391] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022 [ 14.506393] Workqueue: storvsc_error_wq_0 storvsc_remove_lun [ 14.506395] RIP: 0010:check_flush_dependency+0xb5/0x130 <-snip-> [ 14.506408] Call Trace: [ 14.506412] __flush_work+0xf1/0x1c0 [ 14.506414] __cancel_work_timer+0x12f/0x1b0 [ 14.506417] ? kernfs_put+0xf0/0x190 [ 14.506418] cancel_delayed_work_sync+0x13/0x20 [ 14.506420] disk_block_events+0x78/0x80 [ 14.506421] del_gendisk+0x3d/0x2f0 [ 14.506423] sr_remove+0x28/0x70 [ 14.506427] device_release_driver_internal+0xef/0x1c0 [ 14.506428] device_release_driver+0x12/0x20 [ 14.506429] bus_remove_device+0xe1/0x150 [ 14.506431] device_del+0x167/0x380 [ 14.506432] __scsi_remove_device+0x11d/0x150 [ 14.506433] scsi_remove_device+0x26/0x40 [ 14.506434] storvsc_remove_lun+0x40/0x60 [ 14.506436] process_one_work+0x209/0x400 [ 14.506437] worker_thread+0x34/0x400 [ 14.506439] kthread+0x121/0x140 [ 14.506440] ? process_one_work+0x400/0x400 [ 14.506441] ? kthread_park+0x90/0x90 [ 14.506443] ret_from_fork+0x35/0x40 [ 14.506445] ---[ end trace 2d9633159fdc6ee7 ]--- Link: https://lore.kernel.org/r/1659628534-17539-1-git-send-email-ssengar@linux.microsoft.com Fixes: 436ad9413353 ("scsi: storvsc: Allow only one remove lun work item to be issued per lun") Reviewed-by: Michael Kelley Signed-off-by: Saurabh Sengar Signed-off-by: Martin K. Petersen (cherry picked from commit d957e7ffb2c72410bcc1a514153a46719255a5da) Signed-off-by: Jonathan Maple --- drivers/scsi/storvsc_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c index 5104b39a17370..cee13527f11e5 100644 --- a/drivers/scsi/storvsc_drv.c +++ b/drivers/scsi/storvsc_drv.c @@ -2088,7 +2088,7 @@ static int storvsc_probe(struct hv_device *device, */ host_dev->handle_error_wq = alloc_ordered_workqueue("storvsc_error_wq_%d", - WQ_MEM_RECLAIM, + 0, host->host_no); if (!host_dev->handle_error_wq) { ret = -ENOMEM; From e1d81f68df24d895558258ffbb966c0c33c0ba80 Mon Sep 17 00:00:00 2001 From: Jonathan Maple Date: Tue, 21 Oct 2025 18:25:13 -0400 Subject: [PATCH 04/11] ext4: avoid resizing to a partial cluster size jira VULN-69322 cve CVE-2022-50020 commit-author Kiselev, Oleg commit 69cb8e9d8cd97cdf5e293b26d70a9dee3e35e6bd This patch avoids an attempt to resize the filesystem to an unaligned cluster boundary. An online resize to a size that is not integral to cluster size results in the last iteration attempting to grow the fs by a negative amount, which trips a BUG_ON and leaves the fs with a corrupted in-memory superblock. Signed-off-by: Oleg Kiselev Link: https://lore.kernel.org/r/0E92A0AB-4F16-4F1A-94B7-702CC6504FDE@amazon.com Signed-off-by: Theodore Ts'o (cherry picked from commit 69cb8e9d8cd97cdf5e293b26d70a9dee3e35e6bd) Signed-off-by: Jonathan Maple --- fs/ext4/resize.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/fs/ext4/resize.c b/fs/ext4/resize.c index df02905a43cae..edaea4c995ffc 100644 --- a/fs/ext4/resize.c +++ b/fs/ext4/resize.c @@ -1957,6 +1957,16 @@ int ext4_resize_fs(struct super_block *sb, ext4_fsblk_t n_blocks_count) } brelse(bh); + /* + * For bigalloc, trim the requested size to the nearest cluster + * boundary to avoid creating an unusable filesystem. We do this + * silently, instead of returning an error, to avoid breaking + * callers that blindly resize the filesystem to the full size of + * the underlying block device. + */ + if (ext4_has_feature_bigalloc(sb)) + n_blocks_count &= ~((1 << EXT4_CLUSTER_BITS(sb)) - 1); + retry: o_blocks_count = ext4_blocks_count(es); From 043c5924825930ae39a1e1b65cd24e0e1f8d38dd Mon Sep 17 00:00:00 2001 From: Jonathan Maple Date: Tue, 21 Oct 2025 18:25:17 -0400 Subject: [PATCH 05/11] drivers:md:fix a potential use-after-free bug jira VULN-69330 cve CVE-2022-50022 commit-author Wentao_Liang commit 104212471b1c1817b311771d817fb692af983173 In line 2884, "raid5_release_stripe(sh);" drops the reference to sh and may cause sh to be released. However, sh is subsequently used in lines 2886 "if (sh->batch_head && sh != sh->batch_head)". This may result in an use-after-free bug. It can be fixed by moving "raid5_release_stripe(sh);" to the bottom of the function. Signed-off-by: Wentao_Liang Signed-off-by: Song Liu Signed-off-by: Jens Axboe (cherry picked from commit 104212471b1c1817b311771d817fb692af983173) Signed-off-by: Jonathan Maple --- drivers/md/raid5.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c index 0969c66c80a25..8bdcf4190f2d5 100644 --- a/drivers/md/raid5.c +++ b/drivers/md/raid5.c @@ -2904,10 +2904,10 @@ static void raid5_end_write_request(struct bio *bi) if (!test_and_clear_bit(R5_DOUBLE_LOCKED, &sh->dev[i].flags)) clear_bit(R5_LOCKED, &sh->dev[i].flags); set_bit(STRIPE_HANDLE, &sh->state); - raid5_release_stripe(sh); if (sh->batch_head && sh != sh->batch_head) raid5_release_stripe(sh->batch_head); + raid5_release_stripe(sh); } static void raid5_error(struct mddev *mddev, struct md_rdev *rdev) From 90219fbf773b5e5b49a491d5dbba6f6bdb3ceac8 Mon Sep 17 00:00:00 2001 From: Jonathan Maple Date: Tue, 21 Oct 2025 18:25:21 -0400 Subject: [PATCH 06/11] stmmac: intel: Add a missing clk_disable_unprepare() call in intel_eth_pci_remove() jira VULN-71070 cve CVE-2022-50039 commit-author Christophe JAILLET commit 5c23d6b717e4e956376f3852b90f58e262946b50 Commit 09f012e64e4b ("stmmac: intel: Fix clock handling on error and remove paths") removed this clk_disable_unprepare() This was partly revert by commit ac322f86b56c ("net: stmmac: Fix clock handling on remove path") which removed this clk_disable_unprepare() because: " While unloading the dwmac-intel driver, clk_disable_unprepare() is being called twice in stmmac_dvr_remove() and intel_eth_pci_remove(). This causes kernel panic on the second call. " However later on, commit 5ec55823438e8 ("net: stmmac: add clocks management for gmac driver") has updated stmmac_dvr_remove() which do not call clk_disable_unprepare() anymore. So this call should now be called from intel_eth_pci_remove(). Fixes: 5ec55823438e8 ("net: stmmac: add clocks management for gmac driver") Signed-off-by: Christophe JAILLET Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/d7c8c1dadf40df3a7c9e643f76ffadd0ccc1ad1b.1660659689.git.christophe.jaillet@wanadoo.fr Signed-off-by: Jakub Kicinski (cherry picked from commit 5c23d6b717e4e956376f3852b90f58e262946b50) Signed-off-by: Jonathan Maple --- drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c index ab77146428916..6102dbdce4bdd 100644 --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c @@ -1033,6 +1033,7 @@ static void intel_eth_pci_remove(struct pci_dev *pdev) stmmac_dvr_remove(&pdev->dev); + clk_disable_unprepare(priv->plat->stmmac_clk); clk_unregister_fixed_rate(priv->plat->stmmac_clk); pcim_iounmap_regions(pdev, BIT(0)); From 5e332a0a063090b4c47ac9fa3175e670ea847f97 Mon Sep 17 00:00:00 2001 From: Jonathan Maple Date: Tue, 21 Oct 2025 18:25:25 -0400 Subject: [PATCH 07/11] net: qrtr: start MHI channel after endpoit creation jira VULN-69364 cve CVE-2022-50044 commit-author Maxim Kochetkov commit 68a838b84effb7b57ba7d50b1863fc6ae35a54ce MHI channel may generates event/interrupt right after enabling. It may leads to 2 race conditions issues. 1) Such event may be dropped by qcom_mhi_qrtr_dl_callback() at check: if (!qdev || mhi_res->transaction_status) return; Because dev_set_drvdata(&mhi_dev->dev, qdev) may be not performed at this moment. In this situation qrtr-ns will be unable to enumerate services in device. --------------------------------------------------------------- 2) Such event may come at the moment after dev_set_drvdata() and before qrtr_endpoint_register(). In this case kernel will panic with accessing wrong pointer at qcom_mhi_qrtr_dl_callback(): rc = qrtr_endpoint_post(&qdev->ep, mhi_res->buf_addr, mhi_res->bytes_xferd); Because endpoint is not created yet. -------------------------------------------------------------- So move mhi_prepare_for_transfer_autoqueue after endpoint creation to fix it. Fixes: a2e2cc0dbb11 ("net: qrtr: Start MHI channels during init") Signed-off-by: Maxim Kochetkov Reviewed-by: Hemant Kumar Reviewed-by: Manivannan Sadhasivam Reviewed-by: Loic Poulain Signed-off-by: David S. Miller (cherry picked from commit 68a838b84effb7b57ba7d50b1863fc6ae35a54ce) Signed-off-by: Jonathan Maple --- net/qrtr/mhi.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/net/qrtr/mhi.c b/net/qrtr/mhi.c index 18196e1c8c2fd..9ced13c0627a7 100644 --- a/net/qrtr/mhi.c +++ b/net/qrtr/mhi.c @@ -78,11 +78,6 @@ static int qcom_mhi_qrtr_probe(struct mhi_device *mhi_dev, struct qrtr_mhi_dev *qdev; int rc; - /* start channels */ - rc = mhi_prepare_for_transfer_autoqueue(mhi_dev); - if (rc) - return rc; - qdev = devm_kzalloc(&mhi_dev->dev, sizeof(*qdev), GFP_KERNEL); if (!qdev) return -ENOMEM; @@ -96,6 +91,13 @@ static int qcom_mhi_qrtr_probe(struct mhi_device *mhi_dev, if (rc) return rc; + /* start channels */ + rc = mhi_prepare_for_transfer_autoqueue(mhi_dev); + if (rc) { + qrtr_endpoint_unregister(&qdev->ep); + return rc; + } + dev_dbg(qdev->dev, "Qualcomm MHI QRTR driver probed\n"); return 0; From 74885eda8f11df307af6849248f087ea92c9fe23 Mon Sep 17 00:00:00 2001 From: Jonathan Maple Date: Tue, 21 Oct 2025 18:25:29 -0400 Subject: [PATCH 08/11] mptcp: do not queue data on closed subflows jira VULN-70535 cve CVE-2022-50070 commit-author Paolo Abeni commit c886d70286bf3ad411eb3d689328a67f7102c6ae Dipanjan reported a syzbot splat at close time: WARNING: CPU: 1 PID: 10818 at net/ipv4/af_inet.c:153 inet_sock_destruct+0x6d0/0x8e0 net/ipv4/af_inet.c:153 Modules linked in: uio_ivshmem(OE) uio(E) CPU: 1 PID: 10818 Comm: kworker/1:16 Tainted: G OE 5.19.0-rc6-g2eae0556bb9d #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Workqueue: events mptcp_worker RIP: 0010:inet_sock_destruct+0x6d0/0x8e0 net/ipv4/af_inet.c:153 Code: 21 02 00 00 41 8b 9c 24 28 02 00 00 e9 07 ff ff ff e8 34 4d 91 f9 89 ee 4c 89 e7 e8 4a 47 60 ff e9 a6 fc ff ff e8 20 4d 91 f9 <0f> 0b e9 84 fe ff ff e8 14 4d 91 f9 0f 0b e9 d4 fd ff ff e8 08 4d RSP: 0018:ffffc9001b35fa78 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 00000000002879d0 RCX: ffff8881326f3b00 RDX: 0000000000000000 RSI: ffff8881326f3b00 RDI: 0000000000000002 RBP: ffff888179662674 R08: ffffffff87e983a0 R09: 0000000000000000 R10: 0000000000000005 R11: 00000000000004ea R12: ffff888179662400 R13: ffff888179662428 R14: 0000000000000001 R15: ffff88817e38e258 FS: 0000000000000000(0000) GS:ffff8881f5f00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020007bc0 CR3: 0000000179592000 CR4: 0000000000150ee0 Call Trace: __sk_destruct+0x4f/0x8e0 net/core/sock.c:2067 sk_destruct+0xbd/0xe0 net/core/sock.c:2112 __sk_free+0xef/0x3d0 net/core/sock.c:2123 sk_free+0x78/0xa0 net/core/sock.c:2134 sock_put include/net/sock.h:1927 [inline] __mptcp_close_ssk+0x50f/0x780 net/mptcp/protocol.c:2351 __mptcp_destroy_sock+0x332/0x760 net/mptcp/protocol.c:2828 mptcp_worker+0x5d2/0xc90 net/mptcp/protocol.c:2586 process_one_work+0x9cc/0x1650 kernel/workqueue.c:2289 worker_thread+0x623/0x1070 kernel/workqueue.c:2436 kthread+0x2e9/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302 The root cause of the problem is that an mptcp-level (re)transmit can race with mptcp_close() and the packet scheduler checks the subflow state before acquiring the socket lock: we can try to (re)transmit on an already closed ssk. Fix the issue checking again the subflow socket status under the subflow socket lock protection. Additionally add the missing check for the fallback-to-tcp case. Fixes: d5f49190def6 ("mptcp: allow picking different xmit subflows") Reported-by: Dipanjan Das Reviewed-by: Mat Martineau Signed-off-by: Paolo Abeni Signed-off-by: Mat Martineau Signed-off-by: David S. Miller (cherry picked from commit c886d70286bf3ad411eb3d689328a67f7102c6ae) Signed-off-by: Jonathan Maple --- net/mptcp/protocol.c | 8 +++++++- net/mptcp/protocol.h | 11 +++++++---- 2 files changed, 14 insertions(+), 5 deletions(-) diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index 422500d2b4da3..f6aeaf13d90fd 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -1282,6 +1282,9 @@ static int mptcp_sendmsg_frag(struct sock *sk, struct sock *ssk, info->limit > dfrag->data_len)) return 0; + if (unlikely(!__tcp_can_send(ssk))) + return -EAGAIN; + /* compute send limit */ info->mss_now = tcp_send_mss(ssk, &info->size_goal, info->flags); copy = info->size_goal; @@ -1445,7 +1448,8 @@ static struct sock *mptcp_subflow_get_send(struct mptcp_sock *msk) if (__mptcp_check_fallback(msk)) { if (!msk->first) return NULL; - return sk_stream_memory_free(msk->first) ? msk->first : NULL; + return __tcp_can_send(msk->first) && + sk_stream_memory_free(msk->first) ? msk->first : NULL; } /* re-use last subflow, if the burst allow that */ @@ -1570,6 +1574,8 @@ void __mptcp_push_pending(struct sock *sk, unsigned int flags) ret = mptcp_sendmsg_frag(sk, ssk, dfrag, &info); if (ret <= 0) { + if (ret == -EAGAIN) + continue; mptcp_push_release(ssk, &info); goto out; } diff --git a/net/mptcp/protocol.h b/net/mptcp/protocol.h index 64a2cd933afa5..2ad33eeaf260b 100644 --- a/net/mptcp/protocol.h +++ b/net/mptcp/protocol.h @@ -565,16 +565,19 @@ void mptcp_info2sockaddr(const struct mptcp_addr_info *info, struct sockaddr_storage *addr, unsigned short family); -static inline bool __mptcp_subflow_active(struct mptcp_subflow_context *subflow) +static inline bool __tcp_can_send(const struct sock *ssk) { - struct sock *ssk = mptcp_subflow_tcp_sock(subflow); + /* only send if our side has not closed yet */ + return ((1 << inet_sk_state_load(ssk)) & (TCPF_ESTABLISHED | TCPF_CLOSE_WAIT)); +} +static inline bool __mptcp_subflow_active(struct mptcp_subflow_context *subflow) +{ /* can't send if JOIN hasn't completed yet (i.e. is usable for mptcp) */ if (subflow->request_join && !subflow->fully_established) return false; - /* only send if our side has not closed yet */ - return ((1 << ssk->sk_state) & (TCPF_ESTABLISHED | TCPF_CLOSE_WAIT)); + return __tcp_can_send(mptcp_subflow_tcp_sock(subflow)); } void mptcp_subflow_set_active(struct mptcp_subflow_context *subflow); From 9c2eba1ab09c68b189730efdeae2d4749a100ea9 Mon Sep 17 00:00:00 2001 From: Jonathan Maple Date: Tue, 21 Oct 2025 18:25:32 -0400 Subject: [PATCH 09/11] ext4: add EXT4_INODE_HAS_XATTR_SPACE macro in xattr.h jira VULN-70069 cve CVE-2022-50083 commit-author Baokun Li commit 179b14152dcb6a24c3415200603aebca70ff13af When adding an xattr to an inode, we must ensure that the inode_size is not less than EXT4_GOOD_OLD_INODE_SIZE + extra_isize + pad. Otherwise, the end position may be greater than the start position, resulting in UAF. Signed-off-by: Baokun Li Reviewed-by: Jan Kara Reviewed-by: Ritesh Harjani (IBM) Link: https://lore.kernel.org/r/20220616021358.2504451-2-libaokun1@huawei.com Signed-off-by: Theodore Ts'o (cherry picked from commit 179b14152dcb6a24c3415200603aebca70ff13af) Signed-off-by: Jonathan Maple --- fs/ext4/xattr.h | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/fs/ext4/xattr.h b/fs/ext4/xattr.h index f39cad2abe2a8..990084e00374f 100644 --- a/fs/ext4/xattr.h +++ b/fs/ext4/xattr.h @@ -95,6 +95,19 @@ struct ext4_xattr_entry { #define EXT4_ZERO_XATTR_VALUE ((void *)-1) +/* + * If we want to add an xattr to the inode, we should make sure that + * i_extra_isize is not 0 and that the inode size is not less than + * EXT4_GOOD_OLD_INODE_SIZE + extra_isize + pad. + * EXT4_GOOD_OLD_INODE_SIZE extra_isize header entry pad data + * |--------------------------|------------|------|---------|---|-------| + */ +#define EXT4_INODE_HAS_XATTR_SPACE(inode) \ + ((EXT4_I(inode)->i_extra_isize != 0) && \ + (EXT4_GOOD_OLD_INODE_SIZE + EXT4_I(inode)->i_extra_isize + \ + sizeof(struct ext4_xattr_ibody_header) + EXT4_XATTR_PAD <= \ + EXT4_INODE_SIZE((inode)->i_sb))) + struct ext4_xattr_info { const char *name; const void *value; From b9140476fdd1357b2e6836cbdf9d7371dfe91873 Mon Sep 17 00:00:00 2001 From: Jonathan Maple Date: Tue, 21 Oct 2025 18:25:37 -0400 Subject: [PATCH 10/11] usb: xhci_plat_remove: avoid NULL dereference jira VULN-69460 cve CVE-2022-50133 commit-author Alexey Sheplyakov commit d7de14d74d6551f0d097430f9893ce82ad17e5b8 Since commit 4736ebd7fcaff1eb8481c140ba494962847d6e0a ("usb: host: xhci-plat: omit shared hcd if either root hub has no ports") xhci->shared_hcd can be NULL, which causes the following Oops on reboot: [ 710.124450] systemd-shutdown[1]: Rebooting. [ 710.298861] xhci-hcd xhci-hcd.2.auto: remove, state 4 [ 710.304217] usb usb3: USB disconnect, device number 1 [ 710.317441] xhci-hcd xhci-hcd.2.auto: USB bus 3 deregistered [ 710.323280] xhci-hcd xhci-hcd.2.auto: remove, state 1 [ 710.328401] usb usb2: USB disconnect, device number 1 [ 710.333515] usb 2-3: USB disconnect, device number 2 [ 710.467649] xhci-hcd xhci-hcd.2.auto: USB bus 2 deregistered [ 710.475450] Unable to handle kernel NULL pointer dereference at virtual address 00000000000003b8 [ 710.484425] Mem abort info: [ 710.487265] ESR = 0x0000000096000004 [ 710.491060] EC = 0x25: DABT (current EL), IL = 32 bits [ 710.496427] SET = 0, FnV = 0 [ 710.499525] EA = 0, S1PTW = 0 [ 710.502716] FSC = 0x04: level 0 translation fault [ 710.507648] Data abort info: [ 710.510577] ISV = 0, ISS = 0x00000004 [ 710.514462] CM = 0, WnR = 0 [ 710.517480] user pgtable: 4k pages, 48-bit VAs, pgdp=00000008b0050000 [ 710.523976] [00000000000003b8] pgd=0000000000000000, p4d=0000000000000000 [ 710.530961] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 710.536551] Modules linked in: rfkill input_leds snd_soc_simple_card snd_soc_simple_card_utils snd_soc_nau8822 designware_i2s snd_soc_core dw_hdmi_ahb_audio snd_pcm_dmaengine arm_ccn panfrost ac97_bus gpu_sched snd_pcm at24 fuse configfs sdhci_of_dwcmshc sdhci_pltfm sdhci nvme led_class mmc_core nvme_core bt1_pvt polynomial tp_serio snd_seq_midi snd_seq_midi_event snd_seq snd_timer snd_rawmidi snd_seq_device snd soundcore efivarfs ipv6 [ 710.575286] CPU: 7 PID: 1 Comm: systemd-shutdow Not tainted 5.19.0-rc7-00043-gfd8619f4fd54 #1 [ 710.583822] Hardware name: T-Platforms TF307-MB/BM1BM1-A, BIOS 5.6 07/06/2022 [ 710.590972] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 710.597949] pc : usb_remove_hcd+0x34/0x1e4 [ 710.602067] lr : xhci_plat_remove+0x74/0x140 [ 710.606351] sp : ffff800009f3b7c0 [ 710.609674] x29: ffff800009f3b7c0 x28: ffff000800960040 x27: 0000000000000000 [ 710.616833] x26: ffff800008dc22a0 x25: 0000000000000000 x24: 0000000000000000 [ 710.623992] x23: 0000000000000000 x22: ffff000805465810 x21: ffff000805465800 [ 710.631149] x20: ffff000800f80000 x19: 0000000000000000 x18: ffffffffffffffff [ 710.638307] x17: ffff000805096000 x16: ffff00080633b800 x15: ffff000806537a1c [ 710.645465] x14: 0000000000000001 x13: 0000000000000000 x12: ffff00080378d6f0 [ 710.652621] x11: ffff00080041a900 x10: ffff800009b204e8 x9 : ffff8000088abaa4 [ 710.659779] x8 : ffff000800960040 x7 : ffff800009409000 x6 : 0000000000000001 [ 710.666936] x5 : ffff800009241000 x4 : ffff800009241440 x3 : 0000000000000000 [ 710.674094] x2 : ffff000800960040 x1 : ffff000800960040 x0 : 0000000000000000 [ 710.681251] Call trace: [ 710.683704] usb_remove_hcd+0x34/0x1e4 [ 710.687467] xhci_plat_remove+0x74/0x140 [ 710.691400] platform_remove+0x34/0x70 [ 710.695165] device_remove+0x54/0x90 [ 710.698753] device_release_driver_internal+0x200/0x270 [ 710.703992] device_release_driver+0x24/0x30 [ 710.708273] bus_remove_device+0xe0/0x16c [ 710.712293] device_del+0x178/0x390 [ 710.715797] platform_device_del.part.0+0x24/0x90 [ 710.720514] platform_device_unregister+0x30/0x50 [ 710.725232] dwc3_host_exit+0x20/0x30 [ 710.728907] dwc3_remove+0x174/0x1b0 [ 710.732494] platform_remove+0x34/0x70 [ 710.736254] device_remove+0x54/0x90 [ 710.739840] device_release_driver_internal+0x200/0x270 [ 710.745078] device_release_driver+0x24/0x30 [ 710.749359] bus_remove_device+0xe0/0x16c [ 710.753380] device_del+0x178/0x390 [ 710.756881] platform_device_del.part.0+0x24/0x90 [ 710.761598] platform_device_unregister+0x30/0x50 [ 710.766314] of_platform_device_destroy+0xe8/0x100 [ 710.771119] device_for_each_child_reverse+0x70/0xc0 [ 710.776099] of_platform_depopulate+0x48/0x90 [ 710.780468] __dwc3_of_simple_teardown+0x28/0xe0 [ 710.785099] dwc3_of_simple_shutdown+0x20/0x30 [ 710.789555] platform_shutdown+0x30/0x40 [ 710.793490] device_shutdown+0x138/0x32c [ 710.797425] __do_sys_reboot+0x1c4/0x2ac [ 710.801362] __arm64_sys_reboot+0x30/0x40 [ 710.805383] invoke_syscall+0x50/0x120 [ 710.809146] el0_svc_common.constprop.0+0x68/0x124 [ 710.813950] do_el0_svc+0x3c/0xcc [ 710.817275] el0_svc+0x60/0x12c [ 710.820428] el0t_64_sync_handler+0xc0/0x13c [ 710.824710] el0t_64_sync+0x18c/0x190 [ 710.828386] Code: a9025bf5 f942c420 f9001fe0 d2800000 (b943ba62) [ 710.834498] ---[ end trace 0000000000000000 ]--- [ 710.875958] pstore: crypto_comp_compress failed, ret = -22! [ 710.895047] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b [ 710.902757] Kernel Offset: disabled [ 710.906255] CPU features: 0x800,00004811,00001082 [ 710.910971] Memory Limit: none [ 710.927474] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]--- To avoid the problem check for NULL in usb_remove_hcd. Fixes: 4736ebd7fcaf ("usb: host: xhci-plat: omit shared hcd if either root hub has no ports") Signed-off-by: Alexey Sheplyakov Link: https://lore.kernel.org/r/20220722141700.1271439-1-asheplyakov@basealt.ru Signed-off-by: Greg Kroah-Hartman (cherry picked from commit d7de14d74d6551f0d097430f9893ce82ad17e5b8) Signed-off-by: Jonathan Maple --- drivers/usb/core/hcd.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c index cac2bd0db9525..24c9fb42a86fd 100644 --- a/drivers/usb/core/hcd.c +++ b/drivers/usb/core/hcd.c @@ -2998,9 +2998,15 @@ EXPORT_SYMBOL_GPL(usb_add_hcd); */ void usb_remove_hcd(struct usb_hcd *hcd) { - struct usb_device *rhdev = hcd->self.root_hub; + struct usb_device *rhdev; bool rh_registered; + if (!hcd) { + pr_debug("%s: hcd is NULL\n", __func__); + return; + } + rhdev = hcd->self.root_hub; + dev_info(hcd->self.controller, "remove, state %x\n", hcd->state); usb_get_dev(rhdev); From a857843f469a6e82fb2b4b3b0357a2206e5bae47 Mon Sep 17 00:00:00 2001 From: Jonathan Maple Date: Tue, 21 Oct 2025 18:25:41 -0400 Subject: [PATCH 11/11] RDMA/siw: Fix duplicated reported IW_CM_EVENT_CONNECT_REPLY event jira VULN-70621 cve CVE-2022-50136 commit-author Cheng Xu commit 3056fc6c32e613b760422b94c7617ac9a24a4721 If siw_recv_mpa_rr returns -EAGAIN, it means that the MPA reply hasn't been received completely, and should not report IW_CM_EVENT_CONNECT_REPLY in this case. This may trigger a call trace in iw_cm. A simple way to trigger this: server: ib_send_lat client: ib_send_lat -R The call trace looks like this: kernel BUG at drivers/infiniband/core/iwcm.c:894! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI <...> Workqueue: iw_cm_wq cm_work_handler [iw_cm] Call Trace: cm_work_handler+0x1dd/0x370 [iw_cm] process_one_work+0x1e2/0x3b0 worker_thread+0x49/0x2e0 ? rescuer_thread+0x370/0x370 kthread+0xe5/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 Fixes: 6c52fdc244b5 ("rdma/siw: connection management") Link: https://lore.kernel.org/r/dae34b5fd5c2ea2bd9744812c1d2653a34a94c67.1657706960.git.chengyou@linux.alibaba.com Signed-off-by: Cheng Xu Signed-off-by: Leon Romanovsky (cherry picked from commit 3056fc6c32e613b760422b94c7617ac9a24a4721) Signed-off-by: Jonathan Maple --- drivers/infiniband/sw/siw/siw_cm.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/infiniband/sw/siw/siw_cm.c b/drivers/infiniband/sw/siw/siw_cm.c index 17f34d584cd9e..f88d2971c2c63 100644 --- a/drivers/infiniband/sw/siw/siw_cm.c +++ b/drivers/infiniband/sw/siw/siw_cm.c @@ -725,11 +725,11 @@ static int siw_proc_mpareply(struct siw_cep *cep) enum mpa_v2_ctrl mpa_p2p_mode = MPA_V2_RDMA_NO_RTR; rv = siw_recv_mpa_rr(cep); - if (rv != -EAGAIN) - siw_cancel_mpatimer(cep); if (rv) goto out_err; + siw_cancel_mpatimer(cep); + rep = &cep->mpa.hdr; if (__mpa_rr_revision(rep->params.bits) > MPA_REVISION_2) { @@ -895,7 +895,8 @@ static int siw_proc_mpareply(struct siw_cep *cep) } out_err: - siw_cm_upcall(cep, IW_CM_EVENT_CONNECT_REPLY, -EINVAL); + if (rv != -EAGAIN) + siw_cm_upcall(cep, IW_CM_EVENT_CONNECT_REPLY, -EINVAL); return rv; }