Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring/msg_ring: ensure io_kiocb freeing is deferred for RCU<br /> <br /> syzbot reports that defer/local task_work adding via msg_ring can hit<br /> a request that has been freed:<br /> <br /> CPU: 1 UID: 0 PID: 19356 Comm: iou-wrk-19354 Not tainted 6.16.0-rc4-syzkaller-00108-g17bbde2e1716 #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:408 [inline]<br /> print_report+0xd2/0x2b0 mm/kasan/report.c:521<br /> kasan_report+0x118/0x150 mm/kasan/report.c:634<br /> io_req_local_work_add io_uring/io_uring.c:1184 [inline]<br /> __io_req_task_work_add+0x589/0x950 io_uring/io_uring.c:1252<br /> io_msg_remote_post io_uring/msg_ring.c:103 [inline]<br /> io_msg_data_remote io_uring/msg_ring.c:133 [inline]<br /> __io_msg_ring_data+0x820/0xaa0 io_uring/msg_ring.c:151<br /> io_msg_ring_data io_uring/msg_ring.c:173 [inline]<br /> io_msg_ring+0x134/0xa00 io_uring/msg_ring.c:314<br /> __io_issue_sqe+0x17e/0x4b0 io_uring/io_uring.c:1739<br /> io_issue_sqe+0x165/0xfd0 io_uring/io_uring.c:1762<br /> io_wq_submit_work+0x6e9/0xb90 io_uring/io_uring.c:1874<br /> io_worker_handle_work+0x7cd/0x1180 io_uring/io-wq.c:642<br /> io_wq_worker+0x42f/0xeb0 io_uring/io-wq.c:696<br /> ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245<br /> <br /> <br /> which is supposed to be safe with how requests are allocated. But msg<br /> ring requests alloc and free on their own, and hence must defer freeing<br /> to a sane time.<br /> <br /> Add an rcu_head and use kfree_rcu() in both spots where requests are<br /> freed. Only the one in io_msg_tw_complete() is strictly required as it<br /> has been visible on the other ring, but use it consistently in the other<br /> spot as well.<br /> <br /> This should not cause any other issues outside of KASAN rightfully<br /> complaining about it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nbd: fix uaf in nbd_genl_connect() error path<br /> <br /> There is a use-after-free issue in nbd:<br /> <br /> block nbd6: Receive control failed (result -104)<br /> block nbd6: shutting down sockets<br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in recv_work+0x694/0xa80 drivers/block/nbd.c:1022<br /> Write of size 4 at addr ffff8880295de478 by task kworker/u33:0/67<br /> <br /> CPU: 2 UID: 0 PID: 67 Comm: kworker/u33:0 Not tainted 6.15.0-rc5-syzkaller-00123-g2c89c1b655c0 #0 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014<br /> Workqueue: nbd6-recv recv_work<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:408 [inline]<br /> print_report+0xc3/0x670 mm/kasan/report.c:521<br /> kasan_report+0xe0/0x110 mm/kasan/report.c:634<br /> check_region_inline mm/kasan/generic.c:183 [inline]<br /> kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189<br /> instrument_atomic_read_write include/linux/instrumented.h:96 [inline]<br /> atomic_dec include/linux/atomic/atomic-instrumented.h:592 [inline]<br /> recv_work+0x694/0xa80 drivers/block/nbd.c:1022<br /> process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238<br /> process_scheduled_works kernel/workqueue.c:3319 [inline]<br /> worker_thread+0x6c8/0xf10 kernel/workqueue.c:3400<br /> kthread+0x3c2/0x780 kernel/kthread.c:464<br /> ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245<br /> <br /> <br /> nbd_genl_connect() does not properly stop the device on certain<br /> error paths after nbd_start_device() has been called. This causes<br /> the error path to put nbd-&gt;config while recv_work continue to use<br /> the config after putting it, leading to use-after-free in recv_work.<br /> <br /> This patch moves nbd_start_device() after the backend file creation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> raid10: cleanup memleak at raid10_make_request<br /> <br /> If raid10_read_request or raid10_write_request registers a new<br /> request and the REQ_NOWAIT flag is set, the code does not<br /> free the malloc from the mempool.<br /> <br /> unreferenced object 0xffff8884802c3200 (size 192):<br /> comm "fio", pid 9197, jiffies 4298078271<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 88 41 02 00 00 00 00 00 .........A......<br /> 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace (crc c1a049a2):<br /> __kmalloc+0x2bb/0x450<br /> mempool_alloc+0x11b/0x320<br /> raid10_make_request+0x19e/0x650 [raid10]<br /> md_handle_request+0x3b3/0x9e0<br /> __submit_bio+0x394/0x560<br /> __submit_bio_noacct+0x145/0x530<br /> submit_bio_noacct_nocheck+0x682/0x830<br /> __blkdev_direct_IO_async+0x4dc/0x6b0<br /> blkdev_read_iter+0x1e5/0x3b0<br /> __io_read+0x230/0x1110<br /> io_read+0x13/0x30<br /> io_issue_sqe+0x134/0x1180<br /> io_submit_sqes+0x48c/0xe90<br /> __do_sys_io_uring_enter+0x574/0x8b0<br /> do_syscall_64+0x5c/0xe0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> V4: changing backing tree to see if CKI tests will pass.<br /> The patch code has not changed between any versions.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/raid1: Fix stack memory use after return in raid1_reshape<br /> <br /> In the raid1_reshape function, newpool is<br /> allocated on the stack and assigned to conf-&gt;r1bio_pool.<br /> This results in conf-&gt;r1bio_pool.wait.head pointing<br /> to a stack address.<br /> Accessing this address later can lead to a kernel panic.<br /> <br /> Example access path:<br /> <br /> raid1_reshape()<br /> {<br /> // newpool is on the stack<br /> mempool_t newpool, oldpool;<br /> // initialize newpool.wait.head to stack address<br /> mempool_init(&amp;newpool, ...);<br /> conf-&gt;r1bio_pool = newpool;<br /> }<br /> <br /> raid1_read_request() or raid1_write_request()<br /> {<br /> alloc_r1bio()<br /> {<br /> mempool_alloc()<br /> {<br /> // if pool-&gt;alloc fails<br /> remove_element()<br /> {<br /> --pool-&gt;curr_nr;<br /> }<br /> }<br /> }<br /> }<br /> <br /> mempool_free()<br /> {<br /> if (pool-&gt;curr_nr min_nr) {<br /> // pool-&gt;wait.head is a stack address<br /> // wake_up() will try to access this invalid address<br /> // which leads to a kernel panic<br /> return;<br /> wake_up(&amp;pool-&gt;wait);<br /> }<br /> }<br /> <br /> Fix:<br /> reinit conf-&gt;r1bio_pool.wait after assigning newpool.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix potential use-after-free in oplock/lease break ack<br /> <br /> If ksmbd_iov_pin_rsp return error, use-after-free can happen by<br /> accessing opinfo-&gt;state and opinfo_put and ksmbd_fd_put could<br /> called twice.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bnxt_en: Set DMA unmap len correctly for XDP_REDIRECT<br /> <br /> When transmitting an XDP_REDIRECT packet, call dma_unmap_len_set()<br /> with the proper length instead of 0. This bug triggers this warning<br /> on a system with IOMMU enabled:<br /> <br /> WARNING: CPU: 36 PID: 0 at drivers/iommu/dma-iommu.c:842 __iommu_dma_unmap+0x159/0x170<br /> RIP: 0010:__iommu_dma_unmap+0x159/0x170<br /> Code: a8 00 00 00 00 48 c7 45 b0 00 00 00 00 48 c7 45 c8 00 00 00 00 48 c7 45 a0 ff ff ff ff 4c 89 45<br /> b8 4c 89 45 c0 e9 77 ff ff ff 0b e9 60 ff ff ff e8 8b bf 6a 00 66 66 2e 0f 1f 84 00 00 00 00<br /> RSP: 0018:ff22d31181150c88 EFLAGS: 00010206<br /> RAX: 0000000000002000 RBX: 00000000e13a0000 RCX: 0000000000000000<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000<br /> RBP: ff22d31181150cf0 R08: ff22d31181150ca8 R09: 0000000000000000<br /> R10: 0000000000000000 R11: ff22d311d36c9d80 R12: 0000000000001000<br /> R13: ff13544d10645010 R14: ff22d31181150c90 R15: ff13544d0b2bac00<br /> FS: 0000000000000000(0000) GS:ff13550908a00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00005be909dacff8 CR3: 0008000173408003 CR4: 0000000000f71ef0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? show_regs+0x6d/0x80<br /> ? __warn+0x89/0x160<br /> ? __iommu_dma_unmap+0x159/0x170<br /> ? report_bug+0x17e/0x1b0<br /> ? handle_bug+0x46/0x90<br /> ? exc_invalid_op+0x18/0x80<br /> ? asm_exc_invalid_op+0x1b/0x20<br /> ? __iommu_dma_unmap+0x159/0x170<br /> ? __iommu_dma_unmap+0xb3/0x170<br /> iommu_dma_unmap_page+0x4f/0x100<br /> dma_unmap_page_attrs+0x52/0x220<br /> ? srso_alias_return_thunk+0x5/0xfbef5<br /> ? xdp_return_frame+0x2e/0xd0<br /> bnxt_tx_int_xdp+0xdf/0x440 [bnxt_en]<br /> __bnxt_poll_work_done+0x81/0x1e0 [bnxt_en]<br /> bnxt_poll+0xd3/0x1e0 [bnxt_en]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: flowtable: account for Ethernet header in nf_flow_pppoe_proto()<br /> <br /> syzbot found a potential access to uninit-value in nf_flow_pppoe_proto()<br /> <br /> Blamed commit forgot the Ethernet header.<br /> <br /> BUG: KMSAN: uninit-value in nf_flow_offload_inet_hook+0x7e4/0x940 net/netfilter/nf_flow_table_inet.c:27<br /> nf_flow_offload_inet_hook+0x7e4/0x940 net/netfilter/nf_flow_table_inet.c:27<br /> nf_hook_entry_hookfn include/linux/netfilter.h:157 [inline]<br /> nf_hook_slow+0xe1/0x3d0 net/netfilter/core.c:623<br /> nf_hook_ingress include/linux/netfilter_netdev.h:34 [inline]<br /> nf_ingress net/core/dev.c:5742 [inline]<br /> __netif_receive_skb_core+0x4aff/0x70c0 net/core/dev.c:5837<br /> __netif_receive_skb_one_core net/core/dev.c:5975 [inline]<br /> __netif_receive_skb+0xcc/0xac0 net/core/dev.c:6090<br /> netif_receive_skb_internal net/core/dev.c:6176 [inline]<br /> netif_receive_skb+0x57/0x630 net/core/dev.c:6235<br /> tun_rx_batched+0x1df/0x980 drivers/net/tun.c:1485<br /> tun_get_user+0x4ee0/0x6b40 drivers/net/tun.c:1938<br /> tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1984<br /> new_sync_write fs/read_write.c:593 [inline]<br /> vfs_write+0xb4b/0x1580 fs/read_write.c:686<br /> ksys_write fs/read_write.c:738 [inline]<br /> __do_sys_write fs/read_write.c:749 [inline]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: SOF: Intel: hda: Use devm_kstrdup() to avoid memleak.<br /> <br /> sof_pdata-&gt;tplg_filename can have address allocated by kstrdup()<br /> and can be overwritten. Memory leak was detected with kmemleak:<br /> <br /> unreferenced object 0xffff88812391ff60 (size 16):<br /> comm "kworker/4:1", pid 161, jiffies 4294802931<br /> hex dump (first 16 bytes):<br /> 73 6f 66 2d 68 64 61 2d 67 65 6e 65 72 69 63 00 sof-hda-generic.<br /> backtrace (crc 4bf1675c):<br /> __kmalloc_node_track_caller_noprof+0x49c/0x6b0<br /> kstrdup+0x46/0xc0<br /> hda_machine_select.cold+0x1de/0x12cf [snd_sof_intel_hda_generic]<br /> sof_init_environment+0x16f/0xb50 [snd_sof]<br /> sof_probe_continue+0x45/0x7c0 [snd_sof]<br /> sof_probe_work+0x1e/0x40 [snd_sof]<br /> process_one_work+0x894/0x14b0<br /> worker_thread+0x5e5/0xfb0<br /> kthread+0x39d/0x760<br /> ret_from_fork+0x31/0x70<br /> ret_from_fork_asm+0x1a/0x30

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Fix race between DIM disable and net_dim()<br /> <br /> There&amp;#39;s a race between disabling DIM and NAPI callbacks using the dim<br /> pointer on the RQ or SQ.<br /> <br /> If NAPI checks the DIM state bit and sees it still set, it assumes<br /> `rq-&gt;dim` or `sq-&gt;dim` is valid. But if DIM gets disabled right after<br /> that check, the pointer might already be set to NULL, leading to a NULL<br /> pointer dereference in net_dim().<br /> <br /> Fix this by calling `synchronize_net()` before freeing the DIM context.<br /> This ensures all in-progress NAPI callbacks are finished before the<br /> pointer is cleared.<br /> <br /> Kernel log:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> ...<br /> RIP: 0010:net_dim+0x23/0x190<br /> ...<br /> Call Trace:<br /> <br /> ? __die+0x20/0x60<br /> ? page_fault_oops+0x150/0x3e0<br /> ? common_interrupt+0xf/0xa0<br /> ? sysvec_call_function_single+0xb/0x90<br /> ? exc_page_fault+0x74/0x130<br /> ? asm_exc_page_fault+0x22/0x30<br /> ? net_dim+0x23/0x190<br /> ? mlx5e_poll_ico_cq+0x41/0x6f0 [mlx5_core]<br /> ? sysvec_apic_timer_interrupt+0xb/0x90<br /> mlx5e_handle_rx_dim+0x92/0xd0 [mlx5_core]<br /> mlx5e_napi_poll+0x2cd/0xac0 [mlx5_core]<br /> ? mlx5e_poll_ico_cq+0xe5/0x6f0 [mlx5_core]<br /> busy_poll_stop+0xa2/0x200<br /> ? mlx5e_napi_poll+0x1d9/0xac0 [mlx5_core]<br /> ? mlx5e_trigger_irq+0x130/0x130 [mlx5_core]<br /> __napi_busy_loop+0x345/0x3b0<br /> ? sysvec_call_function_single+0xb/0x90<br /> ? asm_sysvec_call_function_single+0x16/0x20<br /> ? sysvec_apic_timer_interrupt+0xb/0x90<br /> ? pcpu_free_area+0x1e4/0x2e0<br /> napi_busy_loop+0x11/0x20<br /> xsk_recvmsg+0x10c/0x130<br /> sock_recvmsg+0x44/0x70<br /> __sys_recvfrom+0xbc/0x130<br /> ? __schedule+0x398/0x890<br /> __x64_sys_recvfrom+0x20/0x30<br /> do_syscall_64+0x4c/0x100<br /> entry_SYSCALL_64_after_hwframe+0x4b/0x53<br /> ...<br /> ---[ end trace 0000000000000000 ]---<br /> ...<br /> ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: reject bs &gt; ps block devices when THP is disabled<br /> <br /> If THP is disabled and when a block device with logical block size &gt;<br /> page size is present, the following null ptr deref panic happens during<br /> boot:<br /> <br /> [ [13.2 mK AOSAN: null-ptr-deref in range [0x0000000000000000-0x0000000000K0 0 0[07]<br /> [ 13.017749] RIP: 0010:create_empty_buffers+0x3b/0x380<br /> <br /> [ 13.025448] Call Trace:<br /> [ 13.025692] <br /> [ 13.025895] block_read_full_folio+0x610/0x780<br /> [ 13.026379] ? __pfx_blkdev_get_block+0x10/0x10<br /> [ 13.027008] ? __folio_batch_add_and_move+0x1fa/0x2b0<br /> [ 13.027548] ? __pfx_blkdev_read_folio+0x10/0x10<br /> [ 13.028080] filemap_read_folio+0x9b/0x200<br /> [ 13.028526] ? __pfx_filemap_read_folio+0x10/0x10<br /> [ 13.029030] ? __filemap_get_folio+0x43/0x620<br /> [ 13.029497] do_read_cache_folio+0x155/0x3b0<br /> [ 13.029962] ? __pfx_blkdev_read_folio+0x10/0x10<br /> [ 13.030381] read_part_sector+0xb7/0x2a0<br /> [ 13.030805] read_lba+0x174/0x2c0<br /> <br /> [ 13.045348] nvme_scan_ns+0x684/0x850 [nvme_core]<br /> [ 13.045858] ? __pfx_nvme_scan_ns+0x10/0x10 [nvme_core]<br /> [ 13.046414] ? _raw_spin_unlock+0x15/0x40<br /> [ 13.046843] ? __switch_to+0x523/0x10a0<br /> [ 13.047253] ? kvm_clock_get_cycles+0x14/0x30<br /> [ 13.047742] ? __pfx_nvme_scan_ns_async+0x10/0x10 [nvme_core]<br /> [ 13.048353] async_run_entry_fn+0x96/0x4f0<br /> [ 13.048787] process_one_work+0x667/0x10a0<br /> [ 13.049219] worker_thread+0x63c/0xf60<br /> <br /> As large folio support depends on THP, only allow bs &gt; ps block devices<br /> if THP is enabled.

In high traffic environments, a Silicon Labs OpenThread RCP (see impacted versions) fails to clear the SPI transmit buffer and may send a corrupt packet over SPI to its host,  causing the host to reset the RCP which results in a denial of service.

A client-side security misconfiguration vulnerability exists in OpenBlow whistleblowing platform across multiple versions and default deployments, due to the absence of critical HTTP response headers including Content-Security-Policy, Referrer-Policy, Permissions-Policy, Cross-Origin-Embedder-Policy, and Cross-Origin-Resource-Policy. This omission weakens browser-level defenses and exposes users to cross-site scripting (XSS), clickjacking, and referer leakage. Although some instances attempt to enforce CSP via HTML tags, this method is ineffective, as modern browsers rely on header-based enforcement to reliably block inline scripts and untrusted resources.