Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sock_map: Add a cond_resched() in sock_hash_free()<br /> <br /> Several syzbot soft lockup reports all have in common sock_hash_free()<br /> <br /> If a map with a large number of buckets is destroyed, we need to yield<br /> the cpu when needed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: wilc1000: fix potential RCU dereference issue in wilc_parse_join_bss_param<br /> <br /> In the `wilc_parse_join_bss_param` function, the TSF field of the `ies`<br /> structure is accessed after the RCU read-side critical section is<br /> unlocked. According to RCU usage rules, this is illegal. Reusing this<br /> pointer can lead to unpredictable behavior, including accessing memory<br /> that has been updated or causing use-after-free issues.<br /> <br /> This possible bug was identified using a static analysis tool developed<br /> by myself, specifically designed to detect RCU-related issues.<br /> <br /> To address this, the TSF value is now stored in a local variable<br /> `ies_tsf` before the RCU lock is released. The `param-&gt;tsf_lo` field is<br /> then assigned using this local variable, ensuring that the TSF value is<br /> safely accessed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop()<br /> <br /> Since &amp;#39;__dev_queue_xmit()&amp;#39; should be called with interrupts enabled,<br /> the following backtrace:<br /> <br /> ieee80211_do_stop()<br /> ...<br /> spin_lock_irqsave(&amp;local-&gt;queue_stop_reason_lock, flags)<br /> ...<br /> ieee80211_free_txskb()<br /> ieee80211_report_used_skb()<br /> ieee80211_report_ack_skb()<br /> cfg80211_mgmt_tx_status_ext()<br /> nl80211_frame_tx_status()<br /> genlmsg_multicast_netns()<br /> genlmsg_multicast_netns_filtered()<br /> nlmsg_multicast_filtered()<br /> netlink_broadcast_filtered()<br /> do_one_broadcast()<br /> netlink_broadcast_deliver()<br /> __netlink_sendskb()<br /> netlink_deliver_tap()<br /> __netlink_deliver_tap_skb()<br /> dev_queue_xmit()<br /> __dev_queue_xmit() ; with IRQS disabled<br /> ...<br /> spin_unlock_irqrestore(&amp;local-&gt;queue_stop_reason_lock, flags)<br /> <br /> issues the warning (as reported by syzbot reproducer):<br /> <br /> WARNING: CPU: 2 PID: 5128 at kernel/softirq.c:362 __local_bh_enable_ip+0xc3/0x120<br /> <br /> Fix this by implementing a two-phase skb reclamation in<br /> &amp;#39;ieee80211_do_stop()&amp;#39;, where actual work is performed<br /> outside of a section with interrupts disabled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> IB/mlx5: Fix UMR pd cleanup on error flow of driver init<br /> <br /> The cited commit moves the pd allocation from function<br /> mlx5r_umr_resource_cleanup() to a new function mlx5r_umr_cleanup().<br /> So the fix in commit [1] is broken. In error flow, will hit panic [2].<br /> <br /> Fix it by checking pd pointer to avoid panic if it is NULL;<br /> <br /> [1] RDMA/mlx5: Fix UMR cleanup on error flow of driver init<br /> [2]<br /> [ 347.567063] infiniband mlx5_0: Couldn&amp;#39;t register device with driver model<br /> [ 347.591382] BUG: kernel NULL pointer dereference, address: 0000000000000020<br /> [ 347.593438] #PF: supervisor read access in kernel mode<br /> [ 347.595176] #PF: error_code(0x0000) - not-present page<br /> [ 347.596962] PGD 0 P4D 0<br /> [ 347.601361] RIP: 0010:ib_dealloc_pd_user+0x12/0xc0 [ib_core]<br /> [ 347.604171] RSP: 0018:ffff888106293b10 EFLAGS: 00010282<br /> [ 347.604834] RAX: 0000000000000000 RBX: 000000000000000e RCX: 0000000000000000<br /> [ 347.605672] RDX: ffff888106293ad0 RSI: 0000000000000000 RDI: 0000000000000000<br /> [ 347.606529] RBP: 0000000000000000 R08: ffff888106293ae0 R09: ffff888106293ae0<br /> [ 347.607379] R10: 0000000000000a06 R11: 0000000000000000 R12: 0000000000000000<br /> [ 347.608224] R13: ffffffffa0704dc0 R14: 0000000000000001 R15: 0000000000000001<br /> [ 347.609067] FS: 00007fdc720cd9c0(0000) GS:ffff88852c880000(0000) knlGS:0000000000000000<br /> [ 347.610094] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 347.610727] CR2: 0000000000000020 CR3: 0000000103012003 CR4: 0000000000370eb0<br /> [ 347.611421] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 347.612113] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 347.612804] Call Trace:<br /> [ 347.613130] <br /> [ 347.613417] ? __die+0x20/0x60<br /> [ 347.613793] ? page_fault_oops+0x150/0x3e0<br /> [ 347.614243] ? free_msg+0x68/0x80 [mlx5_core]<br /> [ 347.614840] ? cmd_exec+0x48f/0x11d0 [mlx5_core]<br /> [ 347.615359] ? exc_page_fault+0x74/0x130<br /> [ 347.615808] ? asm_exc_page_fault+0x22/0x30<br /> [ 347.616273] ? ib_dealloc_pd_user+0x12/0xc0 [ib_core]<br /> [ 347.616801] mlx5r_umr_cleanup+0x23/0x90 [mlx5_ib]<br /> [ 347.617365] mlx5_ib_stage_pre_ib_reg_umr_cleanup+0x36/0x40 [mlx5_ib]<br /> [ 347.618025] __mlx5_ib_add+0x96/0xd0 [mlx5_ib]<br /> [ 347.618539] mlx5r_probe+0xe9/0x310 [mlx5_ib]<br /> [ 347.619032] ? kernfs_add_one+0x107/0x150<br /> [ 347.619478] ? __mlx5_ib_add+0xd0/0xd0 [mlx5_ib]<br /> [ 347.619984] auxiliary_bus_probe+0x3e/0x90<br /> [ 347.620448] really_probe+0xc5/0x3a0<br /> [ 347.620857] __driver_probe_device+0x80/0x160<br /> [ 347.621325] driver_probe_device+0x1e/0x90<br /> [ 347.621770] __driver_attach+0xec/0x1c0<br /> [ 347.622213] ? __device_attach_driver+0x100/0x100<br /> [ 347.622724] bus_for_each_dev+0x71/0xc0<br /> [ 347.623151] bus_add_driver+0xed/0x240<br /> [ 347.623570] driver_register+0x58/0x100<br /> [ 347.623998] __auxiliary_driver_register+0x6a/0xc0<br /> [ 347.624499] ? driver_register+0xae/0x100<br /> [ 347.624940] ? 0xffffffffa0893000<br /> [ 347.625329] mlx5_ib_init+0x16a/0x1e0 [mlx5_ib]<br /> [ 347.625845] do_one_initcall+0x4a/0x2a0<br /> [ 347.626273] ? gcov_event+0x2e2/0x3a0<br /> [ 347.626706] do_init_module+0x8a/0x260<br /> [ 347.627126] init_module_from_file+0x8b/0xd0<br /> [ 347.627596] __x64_sys_finit_module+0x1ca/0x2f0<br /> [ 347.628089] do_syscall_64+0x4c/0x100

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: check stripe size compatibility on remount as well<br /> <br /> We disable stripe size in __ext4_fill_super if it is not a multiple of<br /> the cluster ratio however this check is missed when trying to remount.<br /> This can leave us with cases where stripe s_stripe) become 0 that can cause some<br /> unforeseen bugs like divide by 0.<br /> <br /> Fix that by adding the check in remount path as well.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fail verification for sign-extension of packet data/data_end/data_meta<br /> <br /> syzbot reported a kernel crash due to<br /> commit 1f1e864b6555 ("bpf: Handle sign-extenstin ctx member accesses").<br /> The reason is due to sign-extension of 32-bit load for<br /> packet data/data_end/data_meta uapi field.<br /> <br /> The original code looks like:<br /> r2 = *(s32 *)(r1 + 76) /* load __sk_buff-&gt;data */<br /> r3 = *(u32 *)(r1 + 80) /* load __sk_buff-&gt;data_end */<br /> r0 = r2<br /> r0 += 8<br /> if r3 &gt; r0 goto +1<br /> ...<br /> Note that __sk_buff-&gt;data load has 32-bit sign extension.<br /> <br /> After verification and convert_ctx_accesses(), the final asm code looks like:<br /> r2 = *(u64 *)(r1 +208)<br /> r2 = (s32)r2<br /> r3 = *(u64 *)(r1 +80)<br /> r0 = r2<br /> r0 += 8<br /> if r3 &gt; r0 goto pc+1<br /> ...<br /> Note that &amp;#39;r2 = (s32)r2&amp;#39; may make the kernel __sk_buff-&gt;data address invalid<br /> which may cause runtime failure.<br /> <br /> Currently, in C code, typically we have<br /> void *data = (void *)(long)skb-&gt;data;<br /> void *data_end = (void *)(long)skb-&gt;data_end;<br /> ...<br /> and it will generate<br /> r2 = *(u64 *)(r1 +208)<br /> r3 = *(u64 *)(r1 +80)<br /> r0 = r2<br /> r0 += 8<br /> if r3 &gt; r0 goto pc+1<br /> <br /> If we allow sign-extension,<br /> void *data = (void *)(long)(int)skb-&gt;data;<br /> void *data_end = (void *)(long)skb-&gt;data_end;<br /> ...<br /> the generated code looks like<br /> r2 = *(u64 *)(r1 +208)<br /> r2 = 32<br /> r3 = *(u64 *)(r1 +80)<br /> r0 = r2<br /> r0 += 8<br /> if r3 &gt; r0 goto pc+1<br /> and this will cause verification failure since "r2

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, lsm: Add check for BPF LSM return value<br /> <br /> A bpf prog returning a positive number attached to file_alloc_security<br /> hook makes kernel panic.<br /> <br /> This happens because file system can not filter out the positive number<br /> returned by the LSM prog using IS_ERR, and misinterprets this positive<br /> number as a file pointer.<br /> <br /> Given that hook file_alloc_security never returned positive number<br /> before the introduction of BPF LSM, and other BPF LSM hooks may<br /> encounter similar issues, this patch adds LSM return value check<br /> in verifier, to ensure no unexpected value is returned.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Check link_res-&gt;hpo_dp_link_enc before using it<br /> <br /> [WHAT &amp; HOW]<br /> Functions dp_enable_link_phy and dp_disable_link_phy can pass link_res<br /> without initializing hpo_dp_link_enc and it is necessary to check for<br /> null before dereferencing.<br /> <br /> This fixes 2 FORWARD_NULL issues reported by Coverity.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> IB/core: Fix ib_cache_setup_one error flow cleanup<br /> <br /> When ib_cache_update return an error, we exit ib_cache_setup_one<br /> instantly with no proper cleanup, even though before this we had<br /> already successfully done gid_table_setup_one, that results in<br /> the kernel WARN below.<br /> <br /> Do proper cleanup using gid_table_cleanup_one before returning<br /> the err in order to fix the issue.<br /> <br /> WARNING: CPU: 4 PID: 922 at drivers/infiniband/core/cache.c:806 gid_table_release_one+0x181/0x1a0<br /> Modules linked in:<br /> CPU: 4 UID: 0 PID: 922 Comm: c_repro Not tainted 6.11.0-rc1+ #3<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:gid_table_release_one+0x181/0x1a0<br /> Code: 44 8b 38 75 0c e8 2f cb 34 ff 4d 8b b5 28 05 00 00 e8 23 cb 34 ff 44 89 f9 89 da 4c 89 f6 48 c7 c7 d0 58 14 83 e8 4f de 21 ff 0b 4c 8b 75 30 e9 54 ff ff ff 48 8 3 c4 10 5b 5d 41 5c 41 5d 41<br /> RSP: 0018:ffffc90002b835b0 EFLAGS: 00010286<br /> RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c8527<br /> RDX: 0000000000000000 RSI: ffffffff811c8534 RDI: 0000000000000001<br /> RBP: ffff8881011b3d00 R08: ffff88810b3abe00 R09: 205d303839303631<br /> R10: 666572207972746e R11: 72746e6520444947 R12: 0000000000000001<br /> R13: ffff888106390000 R14: ffff8881011f2110 R15: 0000000000000001<br /> FS: 00007fecc3b70800(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000020000340 CR3: 000000010435a001 CR4: 00000000003706b0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ? show_regs+0x94/0xa0<br /> ? __warn+0x9e/0x1c0<br /> ? gid_table_release_one+0x181/0x1a0<br /> ? report_bug+0x1f9/0x340<br /> ? gid_table_release_one+0x181/0x1a0<br /> ? handle_bug+0xa2/0x110<br /> ? exc_invalid_op+0x31/0xa0<br /> ? asm_exc_invalid_op+0x16/0x20<br /> ? __warn_printk+0xc7/0x180<br /> ? __warn_printk+0xd4/0x180<br /> ? gid_table_release_one+0x181/0x1a0<br /> ib_device_release+0x71/0xe0<br /> ? __pfx_ib_device_release+0x10/0x10<br /> device_release+0x44/0xd0<br /> kobject_put+0x135/0x3d0<br /> put_device+0x20/0x30<br /> rxe_net_add+0x7d/0xa0<br /> rxe_newlink+0xd7/0x190<br /> nldev_newlink+0x1b0/0x2a0<br /> ? __pfx_nldev_newlink+0x10/0x10<br /> rdma_nl_rcv_msg+0x1ad/0x2e0<br /> rdma_nl_rcv_skb.constprop.0+0x176/0x210<br /> netlink_unicast+0x2de/0x400<br /> netlink_sendmsg+0x306/0x660<br /> __sock_sendmsg+0x110/0x120<br /> ____sys_sendmsg+0x30e/0x390<br /> ___sys_sendmsg+0x9b/0xf0<br /> ? kstrtouint+0x6e/0xa0<br /> ? kstrtouint_from_user+0x7c/0xb0<br /> ? get_pid_task+0xb0/0xd0<br /> ? proc_fail_nth_write+0x5b/0x140<br /> ? __fget_light+0x9a/0x200<br /> ? preempt_count_add+0x47/0xa0<br /> __sys_sendmsg+0x61/0xd0<br /> do_syscall_64+0x50/0x110<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds<br /> <br /> In the function init_conns(), after the create_con() and create_cm() for<br /> loop if something fails. In the cleanup for loop after the destroy tag, we<br /> access out of bound memory because cid is set to clt_path-&gt;s.con_num.<br /> <br /> This commits resets the cid to clt_path-&gt;s.con_num - 1, to stay in bounds<br /> in the cleanup loop later.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency<br /> <br /> In the commit aee2424246f9 ("RDMA/iwcm: Fix a use-after-free related to<br /> destroying CM IDs"), the function flush_workqueue is invoked to flush the<br /> work queue iwcm_wq.<br /> <br /> But at that time, the work queue iwcm_wq was created via the function<br /> alloc_ordered_workqueue without the flag WQ_MEM_RECLAIM.<br /> <br /> Because the current process is trying to flush the whole iwcm_wq, if<br /> iwcm_wq doesn&amp;#39;t have the flag WQ_MEM_RECLAIM, verify that the current<br /> process is not reclaiming memory or running on a workqueue which doesn&amp;#39;t<br /> have the flag WQ_MEM_RECLAIM as that can break forward-progress guarantee<br /> leading to a deadlock.<br /> <br /> The call trace is as below:<br /> <br /> [ 125.350876][ T1430] Call Trace:<br /> [ 125.356281][ T1430] <br /> [ 125.361285][ T1430] ? __warn (kernel/panic.c:693)<br /> [ 125.367640][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9))<br /> [ 125.375689][ T1430] ? report_bug (lib/bug.c:180 lib/bug.c:219)<br /> [ 125.382505][ T1430] ? handle_bug (arch/x86/kernel/traps.c:239)<br /> [ 125.388987][ T1430] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1))<br /> [ 125.395831][ T1430] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621)<br /> [ 125.403125][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9))<br /> [ 125.410984][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9))<br /> [ 125.418764][ T1430] __flush_workqueue (kernel/workqueue.c:3970)<br /> [ 125.426021][ T1430] ? __pfx___might_resched (kernel/sched/core.c:10151)<br /> [ 125.433431][ T1430] ? destroy_cm_id (drivers/infiniband/core/iwcm.c:375) iw_cm<br /> [ 125.441209][ T1430] ? __pfx___flush_workqueue (kernel/workqueue.c:3910)<br /> [ 125.473900][ T1430] ? _raw_spin_lock_irqsave (arch/x86/include/asm/atomic.h:107 include/linux/atomic/atomic-arch-fallback.h:2170 include/linux/atomic/atomic-instrumented.h:1302 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162)<br /> [ 125.473909][ T1430] ? __pfx__raw_spin_lock_irqsave (kernel/locking/spinlock.c:161)<br /> [ 125.482537][ T1430] _destroy_id (drivers/infiniband/core/cma.c:2044) rdma_cm<br /> [ 125.495072][ T1430] nvme_rdma_free_queue (drivers/nvme/host/rdma.c:656 drivers/nvme/host/rdma.c:650) nvme_rdma<br /> [ 125.505827][ T1430] nvme_rdma_reset_ctrl_work (drivers/nvme/host/rdma.c:2180) nvme_rdma<br /> [ 125.505831][ T1430] process_one_work (kernel/workqueue.c:3231)<br /> [ 125.515122][ T1430] worker_thread (kernel/workqueue.c:3306 kernel/workqueue.c:3393)<br /> [ 125.515127][ T1430] ? __pfx_worker_thread (kernel/workqueue.c:3339)<br /> [ 125.531837][ T1430] kthread (kernel/kthread.c:389)<br /> [ 125.539864][ T1430] ? __pfx_kthread (kernel/kthread.c:342)<br /> [ 125.550628][ T1430] ret_from_fork (arch/x86/kernel/process.c:147)<br /> [ 125.558840][ T1430] ? __pfx_kthread (kernel/kthread.c:342)<br /> [ 125.558844][ T1430] ret_from_fork_asm (arch/x86/entry/entry_64.S:257)<br /> [ 125.566487][ T1430] <br /> [ 125.566488][ T1430] ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error<br /> <br /> Ensure index in rtl2830_pid_filter does not exceed 31 to prevent<br /> out-of-bounds access.<br /> <br /> dev-&gt;filters is a 32-bit value, so set_bit and clear_bit functions should<br /> only operate on indices from 0 to 31. If index is 32, it will attempt to<br /> access a non-existent 33rd bit, leading to out-of-bounds access.<br /> Change the boundary check from index &gt; 32 to index &gt;= 32 to resolve this<br /> issue.