Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: u_serial: Fix race condition in TTY wakeup<br /> <br /> A race condition occurs when gs_start_io() calls either gs_start_rx() or<br /> gs_start_tx(), as those functions briefly drop the port_lock for<br /> usb_ep_queue(). This allows gs_close() and gserial_disconnect() to clear<br /> port.tty and port_usb, respectively.<br /> <br /> Use the null-safe TTY Port helper function to wake up TTY.<br /> <br /> Example<br /> CPU1: CPU2:<br /> gserial_connect() // lock<br /> gs_close() // await lock<br /> gs_start_rx() // unlock<br /> usb_ep_queue()<br /> gs_close() // lock, reset port.tty and unlock<br /> gs_start_rx() // lock<br /> tty_wakeup() // NPE

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/md-bitmap: fix GPF in bitmap_get_stats()<br /> <br /> The commit message of commit 6ec1f0239485 ("md/md-bitmap: fix stats<br /> collection for external bitmaps") states:<br /> <br /> Remove the external bitmap check as the statistics should be<br /> available regardless of bitmap storage location.<br /> <br /> Return -EINVAL only for invalid bitmap with no storage (neither in<br /> superblock nor in external file).<br /> <br /> But, the code does not adhere to the above, as it does only check for<br /> a valid super-block for "internal" bitmaps. Hence, we observe:<br /> <br /> Oops: GPF, probably for non-canonical address 0x1cd66f1f40000028<br /> RIP: 0010:bitmap_get_stats+0x45/0xd0<br /> Call Trace:<br /> <br /> seq_read_iter+0x2b9/0x46a<br /> seq_read+0x12f/0x180<br /> proc_reg_read+0x57/0xb0<br /> vfs_read+0xf6/0x380<br /> ksys_read+0x6d/0xf0<br /> do_syscall_64+0x8c/0x1b0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> We fix this by checking the existence of a super-block for both the<br /> internal and external case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: imx: Fix an out-of-bounds access in dispmix_csr_clk_dev_data<br /> <br /> When num_parents is 4, __clk_register() occurs an out-of-bounds<br /> when accessing parent_names member. Use ARRAY_SIZE() instead of<br /> hardcode number here.<br /> <br /> BUG: KASAN: global-out-of-bounds in __clk_register+0x1844/0x20d8<br /> Read of size 8 at addr ffff800086988e78 by task kworker/u24:3/59<br /> Hardware name: NXP i.MX95 19X19 board (DT)<br /> Workqueue: events_unbound deferred_probe_work_func<br /> Call trace:<br /> dump_backtrace+0x94/0xec<br /> show_stack+0x18/0x24<br /> dump_stack_lvl+0x8c/0xcc<br /> print_report+0x398/0x5fc<br /> kasan_report+0xd4/0x114<br /> __asan_report_load8_noabort+0x20/0x2c<br /> __clk_register+0x1844/0x20d8<br /> clk_hw_register+0x44/0x110<br /> __clk_hw_register_mux+0x284/0x3a8<br /> imx95_bc_probe+0x4f4/0xa70

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/rmap: fix potential out-of-bounds page table access during batched unmap<br /> <br /> As pointed out by David[1], the batched unmap logic in<br /> try_to_unmap_one() may read past the end of a PTE table when a large<br /> folio&amp;#39;s PTE mappings are not fully contained within a single page<br /> table.<br /> <br /> While this scenario might be rare, an issue triggerable from userspace<br /> must be fixed regardless of its likelihood. This patch fixes the<br /> out-of-bounds access by refactoring the logic into a new helper,<br /> folio_unmap_pte_batch().<br /> <br /> The new helper correctly calculates the safe batch size by capping the<br /> scan at both the VMA and PMD boundaries. To simplify the code, it also<br /> supports partial batching (i.e., any number of pages from 1 up to the<br /> calculated safe maximum), as there is no strong reason to special-case<br /> for fully mapped folios.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/gem: Acquire references on GEM handles for framebuffers<br /> <br /> A GEM handle can be released while the GEM buffer object is attached<br /> to a DRM framebuffer. This leads to the release of the dma-buf backing<br /> the buffer object, if any. [1] Trying to use the framebuffer in further<br /> mode-setting operations leads to a segmentation fault. Most easily<br /> happens with driver that use shadow planes for vmap-ing the dma-buf<br /> during a page flip. An example is shown below.<br /> <br /> [ 156.791968] ------------[ cut here ]------------<br /> [ 156.796830] WARNING: CPU: 2 PID: 2255 at drivers/dma-buf/dma-buf.c:1527 dma_buf_vmap+0x224/0x430<br /> [...]<br /> [ 156.942028] RIP: 0010:dma_buf_vmap+0x224/0x430<br /> [ 157.043420] Call Trace:<br /> [ 157.045898] <br /> [ 157.048030] ? show_trace_log_lvl+0x1af/0x2c0<br /> [ 157.052436] ? show_trace_log_lvl+0x1af/0x2c0<br /> [ 157.056836] ? show_trace_log_lvl+0x1af/0x2c0<br /> [ 157.061253] ? drm_gem_shmem_vmap+0x74/0x710<br /> [ 157.065567] ? dma_buf_vmap+0x224/0x430<br /> [ 157.069446] ? __warn.cold+0x58/0xe4<br /> [ 157.073061] ? dma_buf_vmap+0x224/0x430<br /> [ 157.077111] ? report_bug+0x1dd/0x390<br /> [ 157.080842] ? handle_bug+0x5e/0xa0<br /> [ 157.084389] ? exc_invalid_op+0x14/0x50<br /> [ 157.088291] ? asm_exc_invalid_op+0x16/0x20<br /> [ 157.092548] ? dma_buf_vmap+0x224/0x430<br /> [ 157.096663] ? dma_resv_get_singleton+0x6d/0x230<br /> [ 157.101341] ? __pfx_dma_buf_vmap+0x10/0x10<br /> [ 157.105588] ? __pfx_dma_resv_get_singleton+0x10/0x10<br /> [ 157.110697] drm_gem_shmem_vmap+0x74/0x710<br /> [ 157.114866] drm_gem_vmap+0xa9/0x1b0<br /> [ 157.118763] drm_gem_vmap_unlocked+0x46/0xa0<br /> [ 157.123086] drm_gem_fb_vmap+0xab/0x300<br /> [ 157.126979] drm_atomic_helper_prepare_planes.part.0+0x487/0xb10<br /> [ 157.133032] ? lockdep_init_map_type+0x19d/0x880<br /> [ 157.137701] drm_atomic_helper_commit+0x13d/0x2e0<br /> [ 157.142671] ? drm_atomic_nonblocking_commit+0xa0/0x180<br /> [ 157.147988] drm_mode_atomic_ioctl+0x766/0xe40<br /> [...]<br /> [ 157.346424] ---[ end trace 0000000000000000 ]---<br /> <br /> Acquiring GEM handles for the framebuffer&amp;#39;s GEM buffer objects prevents<br /> this from happening. The framebuffer&amp;#39;s cleanup later puts the handle<br /> references.<br /> <br /> Commit 1a148af06000 ("drm/gem-shmem: Use dma_buf from GEM object<br /> instance") triggers the segmentation fault easily by using the dma-buf<br /> field more widely. The underlying issue with reference counting has<br /> been present before.<br /> <br /> v2:<br /> - acquire the handle instead of the BO (Christian)<br /> - fix comment style (Christian)<br /> - drop the Fixes tag (Christian)<br /> - rename err_ gotos<br /> - add missing Link tag

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7925: prevent NULL pointer dereference in mt7925_sta_set_decap_offload()<br /> <br /> Add a NULL check for msta-&gt;vif before accessing its members to prevent<br /> a kernel panic in AP mode deployment. This also fix the issue reported<br /> in [1].<br /> <br /> The crash occurs when this function is triggered before the station is<br /> fully initialized. The call trace shows a page fault at<br /> mt7925_sta_set_decap_offload() due to accessing resources when msta-&gt;vif<br /> is NULL.<br /> <br /> Fix this by adding an early return if msta-&gt;vif is NULL and also check<br /> wcid.sta is ready. This ensures we only proceed with decap offload<br /> configuration when the station&amp;#39;s state is properly initialized.<br /> <br /> [14739.655703] Unable to handle kernel paging request at virtual address ffffffffffffffa0<br /> [14739.811820] CPU: 0 UID: 0 PID: 895854 Comm: hostapd Tainted: G<br /> [14739.821394] Tainted: [C]=CRAP, [O]=OOT_MODULE<br /> [14739.825746] Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT)<br /> [14739.831577] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [14739.838538] pc : mt7925_sta_set_decap_offload+0xc0/0x1b8 [mt7925_common]<br /> [14739.845271] lr : mt7925_sta_set_decap_offload+0x58/0x1b8 [mt7925_common]<br /> [14739.851985] sp : ffffffc085efb500<br /> [14739.855295] x29: ffffffc085efb500 x28: 0000000000000000 x27: ffffff807803a158<br /> [14739.862436] x26: ffffff8041ececb8 x25: 0000000000000001 x24: 0000000000000001<br /> [14739.869577] x23: 0000000000000001 x22: 0000000000000008 x21: ffffff8041ecea88<br /> [14739.876715] x20: ffffff8041c19ca0 x19: ffffff8078031fe0 x18: 0000000000000000<br /> [14739.883853] x17: 0000000000000000 x16: ffffffe2aeac1110 x15: 000000559da48080<br /> [14739.890991] x14: 0000000000000001 x13: 0000000000000000 x12: 0000000000000000<br /> [14739.898130] x11: 0a10020001008e88 x10: 0000000000001a50 x9 : ffffffe26457bfa0<br /> [14739.905269] x8 : ffffff8042013bb0 x7 : ffffff807fb6cbf8 x6 : dead000000000100<br /> [14739.912407] x5 : dead000000000122 x4 : ffffff80780326c8 x3 : 0000000000000000<br /> [14739.919546] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff8041ececb8<br /> [14739.926686] Call trace:<br /> [14739.929130] mt7925_sta_set_decap_offload+0xc0/0x1b8 [mt7925_common]<br /> [14739.935505] ieee80211_check_fast_rx+0x19c/0x510 [mac80211]<br /> [14739.941344] _sta_info_move_state+0xe4/0x510 [mac80211]<br /> [14739.946860] sta_info_move_state+0x1c/0x30 [mac80211]<br /> [14739.952116] sta_apply_auth_flags.constprop.0+0x90/0x1b0 [mac80211]<br /> [14739.958708] sta_apply_parameters+0x234/0x5e0 [mac80211]<br /> [14739.964332] ieee80211_add_station+0xdc/0x190 [mac80211]<br /> [14739.969950] nl80211_new_station+0x46c/0x670 [cfg80211]<br /> [14739.975516] genl_family_rcv_msg_doit+0xdc/0x150<br /> [14739.980158] genl_rcv_msg+0x218/0x298<br /> [14739.983830] netlink_rcv_skb+0x64/0x138<br /> [14739.987670] genl_rcv+0x40/0x60<br /> [14739.990816] netlink_unicast+0x314/0x380<br /> [14739.994742] netlink_sendmsg+0x198/0x3f0<br /> [14739.998664] __sock_sendmsg+0x64/0xc0<br /> [14740.002324] ____sys_sendmsg+0x260/0x298<br /> [14740.006242] ___sys_sendmsg+0xb4/0x110

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethernet: rtsn: Fix a null pointer dereference in rtsn_probe()<br /> <br /> Add check for the return value of rcar_gen4_ptp_alloc()<br /> to prevent potential null pointer dereference.

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.