Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/v3d: Reject empty multisync extension to prevent infinite loop<br /> <br /> v3d_get_extensions() walks a userspace-provided singly-linked list of<br /> ioctl extensions without any bound on the chain length. A local user<br /> can craft a self-referential extension (ext-&gt;next == &amp;ext) with zero<br /> in_sync_count and out_sync_count, which bypasses the existing duplicate-<br /> extension guard:<br /> <br /> if (se-&gt;in_sync_count || se-&gt;out_sync_count)<br /> return -EINVAL;<br /> <br /> The guard never fires because v3d_get_multisync_post_deps() returns<br /> immediately when count is zero, leaving both fields at zero on every<br /> iteration. The result is an infinite loop in kernel context, blocking<br /> the calling thread and pegging a CPU core indefinitely.<br /> <br /> Fix this by rejecting a multisync extension where both in_sync_count<br /> and out_sync_count are zero in v3d_get_multisync_submit_deps(). An<br /> empty multisync carries no synchronization information and serves no<br /> useful purpose, so returning -EINVAL for such an extension is the<br /> correct defense against this attack vector.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/userq: fix access to stale wptr mapping<br /> <br /> Use drm_exec to take both locks i.e vm root bo and<br /> wptr_obj bo to access the mapping data properly.<br /> <br /> This fixes the security issue of unmap the wptr_obj while<br /> a queue creation is in progress and passing other<br /> bo at same address.<br /> <br /> (cherry picked from commit 1fc6c8ab45dbee096469c08c13f6099d57a52d6c)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmet: avoid recursive nvmet-wq flush in nvmet_ctrl_free<br /> <br /> nvmet_tcp_release_queue_work() runs on nvmet-wq and can drop the<br /> final controller reference through nvmet_cq_put(). If that triggers<br /> nvmet_ctrl_free(), the teardown path flushes ctrl-&gt;async_event_work on<br /> the same nvmet-wq.<br /> <br /> Call chain:<br /> <br /> nvmet_tcp_schedule_release_queue()<br /> kref_put(&amp;queue-&gt;kref, nvmet_tcp_release_queue)<br /> nvmet_tcp_release_queue()<br /> queue_work(nvmet_wq, &amp;queue-&gt;release_work) nvme_cq)<br /> nvmet_cq_destroy()<br /> nvmet_ctrl_put(cq-&gt;ctrl)<br /> nvmet_ctrl_free()<br /> flush_work(&amp;ctrl-&gt;async_event_work) async_event_work);<br /> <br /> This trips lockdep with a possible recursive locking warning.<br /> <br /> [ 5223.015876] run blktests nvme/003 at 2026-04-07 20:53:55<br /> [ 5223.061801] loop0: detected capacity change from 0 to 2097152<br /> [ 5223.072206] nvmet: adding nsid 1 to subsystem blktests-subsystem-1<br /> [ 5223.088368] nvmet_tcp: enabling port 0 (127.0.0.1:4420)<br /> [ 5223.126086] nvmet: Created discovery controller 1 for subsystem nqn.2014-08.org.nvmexpress.discovery for NQN nqn.2014-08.org.nvmexpress:uuid:0f01fb42-9f7f-4856-b0b3-51e60b8de349.<br /> [ 5223.128453] nvme nvme1: new ctrl: NQN "nqn.2014-08.org.nvmexpress.discovery", addr 127.0.0.1:4420, hostnqn: nqn.2014-08.org.nvmexpress:uuid:0f01fb42-9f7f-4856-b0b3-51e60b8de349<br /> [ 5233.199447] nvme nvme1: Removing ctrl: NQN "nqn.2014-08.org.nvmexpress.discovery"<br /> <br /> [ 5233.227718] ============================================<br /> [ 5233.231283] WARNING: possible recursive locking detected<br /> [ 5233.234696] 7.0.0-rc3nvme+ #20 Tainted: G O N<br /> [ 5233.238434] --------------------------------------------<br /> [ 5233.241852] kworker/u192:6/2413 is trying to acquire lock:<br /> [ 5233.245429] ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x26/0x90<br /> [ 5233.251438]<br /> but task is already holding lock:<br /> [ 5233.255254] ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x5cc/0x6e0<br /> [ 5233.261125]<br /> other info that might help us debug this:<br /> [ 5233.265333] Possible unsafe locking scenario:<br /> <br /> [ 5233.269217] CPU0<br /> [ 5233.270795] ----<br /> [ 5233.272436] lock((wq_completion)nvmet-wq);<br /> [ 5233.275241] lock((wq_completion)nvmet-wq);<br /> [ 5233.278020]<br /> *** DEADLOCK ***<br /> <br /> [ 5233.281793] May be due to missing lock nesting notation<br /> <br /> [ 5233.286195] 3 locks held by kworker/u192:6/2413:<br /> [ 5233.289192] #0: ffff888111632548 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x5cc/0x6e0<br /> [ 5233.294569] #1: ffffc9000e2a7e40 ((work_completion)(&amp;queue-&gt;release_work)){+.+.}-{0:0}, at: process_one_work+0x1c5/0x6e0<br /> [ 5233.300128] #2: ffffffff82d7dc40 (rcu_read_lock){....}-{1:3}, at: __flush_work+0x62/0x530<br /> [ 5233.304290]<br /> stack backtrace:<br /> [ 5233.306520] CPU: 4 UID: 0 PID: 2413 Comm: kworker/u192:6 Tainted: G O N 7.0.0-rc3nvme+ #20 PREEMPT(full)<br /> [ 5233.306524] Tainted: [O]=OOT_MODULE, [N]=TEST<br /> [ 5233.306525] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014<br /> [ 5233.306527] Workqueue: nvmet-wq nvmet_tcp_release_queue_work [nvmet_tcp]<br /> [ 5233.306532] Call Trace:<br /> [ 5233.306534] <br /> [ 5233.306536] dump_stack_lvl+0x73/0xb0<br /> [ 5233.306552] print_deadlock_bug+0x225/0x2f0<br /> [ 5233.306556] __lock_acquire+0x13f0/0x2290<br /> [ 5233.306563] lock_acquire+0xd0/0x300<br /> [ 5233.306565] ? touch_wq_lockdep_map+0x26/0x90<br /> [ 5233.306571] ? __flush_work+0x20b/0x530<br /> [ 5233.306573] ? touch_wq_lockdep_map+0x26/0x90<br /> [ 5233.306577] touch_wq_lockdep_map+0x3b/0x90<br /> [ 5233.306580] ? touch_wq_lockdep_map+0x26/0x90<br /> [ 52<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> staging: rtl8723bs: os_dep: avoid NULL pointer dereference in rtw_cbuf_alloc<br /> <br /> The return value of kzalloc_flex() is used without<br /> ensuring that the allocation succeeded, and the<br /> pointer is dereferenced unconditionally.<br /> <br /> Guard the access to the allocated structure to<br /> avoid a potential NULL pointer dereference if the<br /> allocation fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> flow_dissector: do not dissect PPPoE PFC frames<br /> <br /> RFC 2516 Section 7 states that Protocol Field Compression (PFC) is NOT<br /> RECOMMENDED for PPPoE. In practice, pppd does not support negotiating<br /> PFC for PPPoE sessions, and the flow dissector driver has assumed an<br /> uncompressed frame until the blamed commit.<br /> <br /> During the review process of that commit [1], support for PFC is<br /> suggested. However, having a compressed (1-byte) protocol field means<br /> the subsequent PPP payload is shifted by one byte, causing 4-byte<br /> misalignment for the network header and an unaligned access exception<br /> on some architectures.<br /> <br /> The exception can be reproduced by sending a PPPoE PFC frame to an<br /> ethernet interface of a MIPS board, with RPS enabled, even if no PPPoE<br /> session is active on that interface:<br /> <br /> $ 0 : 00000000 80c40000 00000000 85144817<br /> $ 4 : 00000008 00000100 80a75758 81dc9bb8<br /> $ 8 : 00000010 8087ae2c 0000003d 00000000<br /> $12 : 000000e0 00000039 00000000 00000000<br /> $16 : 85043240 80a75758 81dc9bb8 00006488<br /> $20 : 0000002f 00000007 85144810 80a70000<br /> $24 : 81d1bda0 00000000<br /> $28 : 81dc8000 81dc9aa8 00000000 805ead08<br /> Hi : 00009d51<br /> Lo : 2163358a<br /> epc : 805e91f0 __skb_flow_dissect+0x1b0/0x1b50<br /> ra : 805ead08 __skb_get_hash_net+0x74/0x12c<br /> Status: 11000403 KERNEL EXL IE<br /> Cause : 40800010 (ExcCode 04)<br /> BadVA : 85144817<br /> PrId : 0001992f (MIPS 1004Kc)<br /> Call Trace:<br /> [] __skb_flow_dissect+0x1b0/0x1b50<br /> [] __skb_get_hash_net+0x74/0x12c<br /> [] get_rps_cpu+0x1b8/0x3fc<br /> [] netif_receive_skb_list_internal+0x324/0x364<br /> [] napi_complete_done+0x68/0x2a4<br /> [] mtk_napi_rx+0x228/0xfec<br /> [] __napi_poll+0x3c/0x1c4<br /> [] napi_threaded_poll_loop+0x234/0x29c<br /> [] napi_threaded_poll+0x8c/0xb0<br /> [] kthread+0x104/0x12c<br /> [] ret_from_kernel_thread+0x14/0x1c<br /> <br /> Code: 02d51821 1060045b 00000000 3084000f 2c820005 144001a2 00042080 8e220000<br /> <br /> To reduce the attack surface and maintain performance, do not process<br /> PPPoE PFC frames.<br /> <br /> [1] https://lore.kernel.org/r/20220630231016.GA392@debian.home

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath5k: do not access array OOB<br /> <br /> Vincent reports:<br /> &gt; The ath5k driver seems to do an array-index-out-of-bounds access as<br /> &gt; shown by the UBSAN kernel message:<br /> &gt; UBSAN: array-index-out-of-bounds in drivers/net/wireless/ath/ath5k/base.c:1741:20<br /> &gt; index 4 is out of range for type &amp;#39;ieee80211_tx_rate [4]&amp;#39;<br /> &gt; ...<br /> &gt; Call Trace:<br /> &gt; <br /> &gt; dump_stack_lvl+0x5d/0x80<br /> &gt; ubsan_epilogue+0x5/0x2b<br /> &gt; __ubsan_handle_out_of_bounds.cold+0x46/0x4b<br /> &gt; ath5k_tasklet_tx+0x4e0/0x560 [ath5k]<br /> &gt; tasklet_action_common+0xb5/0x1c0<br /> <br /> It is real. &amp;#39;ts-&gt;ts_final_idx&amp;#39; can be 3 on 5212, so:<br /> info-&gt;status.rates[ts-&gt;ts_final_idx + 1].idx = -1;<br /> with the array defined as:<br /> struct ieee80211_tx_rate rates[IEEE80211_TX_MAX_RATES];<br /> while the size is:<br /> #define IEEE80211_TX_MAX_RATES 4<br /> is indeed bogus.<br /> <br /> Set this &amp;#39;idx = -1&amp;#39; sentinel only if the array index is less than the<br /> array size. As mac80211 will not look at rates beyond the size<br /> (IEEE80211_TX_MAX_RATES).<br /> <br /> Note: The effect of the OOB write is negligible. It just overwrites the<br /> next member of info-&gt;status, i.e. ack_signal.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pmdomain: mediatek: fix use-after-free in scpsys_get_bus_protection_legacy()<br /> <br /> In scpsys_get_bus_protection_legacy(), of_find_node_with_property()<br /> returns a device node with its reference count incremented. The function<br /> then calls of_node_put(node) before checking whether<br /> syscon_regmap_lookup_by_phandle() returns an error. If an error occurs,<br /> dev_err_probe() dereferences the node pointer to print diagnostic<br /> information, but the node memory may have already been freed due to the<br /> earlier of_node_put(), leading to a use-after-free vulnerability.<br /> <br /> Fix this by moving the of_node_put() call after the error check, ensuring<br /> the node is still valid when accessed in the error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe/uapi: Reject coh_none PAT index for CPU cached memory in madvise<br /> <br /> Add validation in xe_vm_madvise_ioctl() to reject PAT indices with<br /> XE_COH_NONE coherency mode when applied to CPU cached memory.<br /> <br /> Using coh_none with CPU cached buffers is a security issue. When the<br /> kernel clears pages before reallocation, the clear operation stays in<br /> CPU cache (dirty). GPU with coh_none can bypass CPU caches and read<br /> stale sensitive data directly from DRAM, potentially leaking data from<br /> previously freed pages of other processes.<br /> <br /> This aligns with the existing validation in vm_bind path<br /> (xe_vm_bind_ioctl_validate_bo).<br /> <br /> v2(Matthew brost)<br /> - Add fixes<br /> - Move one debug print to better place<br /> <br /> v3(Matthew Auld)<br /> - Should be drm/xe/uapi<br /> - More Cc<br /> <br /> v4(Shuicheng Lin)<br /> - Fix kmem leak issues by the way<br /> <br /> v5<br /> - Remove kmem leak because it has been merged by another patch<br /> <br /> v6<br /> - Remove the fix which is not related to current fix<br /> <br /> v7<br /> - No change<br /> <br /> v8<br /> - Rebase<br /> <br /> v9<br /> - Limit the restrictions to iGPU<br /> <br /> v10<br /> - No change<br /> <br /> (cherry picked from commit 016ccdb674b8c899940b3944952c96a6a490d10a)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: renesas: vsp1: Fix NULL pointer deref on module unload<br /> <br /> When unloading the module on gen 4, we hit a NULL pointer dereference.<br /> This is caused by the cleanup code calling vsp1_drm_cleanup() where it<br /> should be calling vsp1_vspx_cleanup().<br /> <br /> Fix this by checking the IP version and calling the drm or vspx function<br /> accordingly, the same way as the init code does.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hfsplus: fix held lock freed on hfsplus_fill_super()<br /> <br /> hfsplus_fill_super() calls hfs_find_init() to initialize a search<br /> structure, which acquires tree-&gt;tree_lock. If the subsequent call to<br /> hfsplus_cat_build_key() fails, the function jumps to the out_put_root<br /> error label without releasing the lock. The later cleanup path then<br /> frees the tree data structure with the lock still held, triggering a<br /> held lock freed warning.<br /> <br /> Fix this by adding the missing hfs_find_exit(&amp;fd) call before jumping<br /> to the out_put_root error label. This ensures that tree-&gt;tree_lock is<br /> properly released on the error path.<br /> <br /> The bug was originally detected on v6.13-rc1 using an experimental<br /> static analysis tool we are developing, and we have verified that the<br /> issue persists in the latest mainline kernel. The tool is specifically<br /> designed to detect memory management issues. It is currently under active<br /> development and not yet publicly available.<br /> <br /> We confirmed the bug by runtime testing under QEMU with x86_64 defconfig,<br /> lockdep enabled, and CONFIG_HFSPLUS_FS=y. To trigger the error path, we<br /> used GDB to dynamically shrink the max_unistr_len parameter to 1 before<br /> hfsplus_asc2uni() is called. This forces hfsplus_asc2uni() to naturally<br /> return -ENAMETOOLONG, which propagates to hfsplus_cat_build_key() and<br /> exercises the faulty error path. The following warning was observed<br /> during mount:<br /> <br /> =========================<br /> WARNING: held lock freed!<br /> 7.0.0-rc3-00016-gb4f0dd314b39 #4 Not tainted<br /> -------------------------<br /> mount/174 is freeing memory ffff888103f92000-ffff888103f92fff, with a lock still held there!<br /> ffff888103f920b0 (&amp;tree-&gt;tree_lock){+.+.}-{4:4}, at: hfsplus_find_init+0x154/0x1e0<br /> 2 locks held by mount/174:<br /> #0: ffff888103f960e0 (&amp;type-&gt;s_umount_key#42/1){+.+.}-{4:4}, at: alloc_super.constprop.0+0x167/0xa40<br /> #1: ffff888103f920b0 (&amp;tree-&gt;tree_lock){+.+.}-{4:4}, at: hfsplus_find_init+0x154/0x1e0<br /> <br /> stack backtrace:<br /> CPU: 2 UID: 0 PID: 174 Comm: mount Not tainted 7.0.0-rc3-00016-gb4f0dd314b39 #4 PREEMPT(lazy)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x82/0xd0<br /> debug_check_no_locks_freed+0x13a/0x180<br /> kfree+0x16b/0x510<br /> ? hfsplus_fill_super+0xcb4/0x18a0<br /> hfsplus_fill_super+0xcb4/0x18a0<br /> ? __pfx_hfsplus_fill_super+0x10/0x10<br /> ? srso_return_thunk+0x5/0x5f<br /> ? bdev_open+0x65f/0xc30<br /> ? srso_return_thunk+0x5/0x5f<br /> ? pointer+0x4ce/0xbf0<br /> ? trace_contention_end+0x11c/0x150<br /> ? __pfx_pointer+0x10/0x10<br /> ? srso_return_thunk+0x5/0x5f<br /> ? bdev_open+0x79b/0xc30<br /> ? srso_return_thunk+0x5/0x5f<br /> ? srso_return_thunk+0x5/0x5f<br /> ? vsnprintf+0x6da/0x1270<br /> ? srso_return_thunk+0x5/0x5f<br /> ? __mutex_unlock_slowpath+0x157/0x740<br /> ? __pfx_vsnprintf+0x10/0x10<br /> ? srso_return_thunk+0x5/0x5f<br /> ? srso_return_thunk+0x5/0x5f<br /> ? mark_held_locks+0x49/0x80<br /> ? srso_return_thunk+0x5/0x5f<br /> ? srso_return_thunk+0x5/0x5f<br /> ? irqentry_exit+0x17b/0x5e0<br /> ? trace_irq_disable.constprop.0+0x116/0x150<br /> ? __pfx_hfsplus_fill_super+0x10/0x10<br /> ? __pfx_hfsplus_fill_super+0x10/0x10<br /> get_tree_bdev_flags+0x302/0x580<br /> ? __pfx_get_tree_bdev_flags+0x10/0x10<br /> ? vfs_parse_fs_qstr+0x129/0x1a0<br /> ? __pfx_vfs_parse_fs_qstr+0x3/0x10<br /> vfs_get_tree+0x89/0x320<br /> fc_mount+0x10/0x1d0<br /> path_mount+0x5c5/0x21c0<br /> ? __pfx_path_mount+0x10/0x10<br /> ? trace_irq_enable.constprop.0+0x116/0x150<br /> ? trace_irq_enable.constprop.0+0x116/0x150<br /> ? srso_return_thunk+0x5/0x5f<br /> ? srso_return_thunk+0x5/0x5f<br /> ? kmem_cache_free+0x307/0x540<br /> ? user_path_at+0x51/0x60<br /> ? __x64_sys_mount+0x212/0x280<br /> ? srso_return_thunk+0x5/0x5f<br /> __x64_sys_mount+0x212/0x280<br /> ? __pfx___x64_sys_mount+0x10/0x10<br /> ? srso_return_thunk+0x5/0x5f<br /> ? trace_irq_enable.constprop.0+0x116/0x150<br /> ? srso_return_thunk+0x5/0x5f<br /> do_syscall_64+0x111/0x680<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7ffacad55eae<br /> Code: 48 8b 0d 85 1f 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 a5 00 00 8<br /> RSP: 002b<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: s3c64xx: fix NULL-deref on driver unbind<br /> <br /> A change moving DMA channel allocation from probe() back to<br /> s3c64xx_spi_prepare_transfer() failed to remove the corresponding<br /> deallocation from remove().<br /> <br /> Drop the bogus DMA channel release from remove() to avoid triggering a<br /> NULL-pointer dereference on driver unbind.<br /> <br /> This issue was flagged by Sashiko when reviewing a controller<br /> deregistration fix.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: libwx: use request_irq for VF misc interrupt<br /> <br /> Currently, request_threaded_irq() is used with a primary handler but a<br /> NULL threaded handler, while also setting the IRQF_ONESHOT flag. This<br /> specific combination triggers a WARNING since the commit aef30c8d569c<br /> ("genirq: Warn about using IRQF_ONESHOT without a threaded handler").<br /> <br /> WARNING: kernel/irq/manage.c:1502 at __setup_irq+0x4fa/0x760<br /> <br /> Fix the issue by switching to request_irq(), which is the appropriate<br /> interface or a non-threaded interrupt handler, and removing the<br /> unnecessary IRQF_ONESHOT flag.