Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: stm32: sai: fix OF node leak on probe<br /> <br /> The reference taken to the sync provider OF node when probing the<br /> platform device is currently only dropped if the set_sync() callback<br /> fails during DAI probe.<br /> <br /> Make sure to drop the reference on platform probe failures (e.g. probe<br /> deferral) and on driver unbind.<br /> <br /> This also avoids a potential use-after-free in case the DAI is ever<br /> reprobed without first rebinding the platform driver.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: btusb: revert use of devm_kzalloc in btusb<br /> <br /> This reverts commit 98921dbd00c4e ("Bluetooth: Use devm_kzalloc in<br /> btusb.c file").<br /> <br /> In btusb_probe(), we use devm_kzalloc() to allocate the btusb data. This<br /> ties the lifetime of all the btusb data to the binding of a driver to<br /> one interface, INTF. In a driver that binds to other interfaces, ISOC<br /> and DIAG, this is an accident waiting to happen.<br /> <br /> The issue is revealed in btusb_disconnect(), where calling<br /> usb_driver_release_interface(&amp;btusb_driver, data-&gt;intf) will have devm<br /> free the data that is also being used by the other interfaces of the<br /> driver that may not be released yet.<br /> <br /> To fix this, revert the use of devm and go back to freeing memory<br /> explicitly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/ttm: Avoid NULL pointer deref for evicted BOs<br /> <br /> It is possible for a BO to exist that is not currently associated with a<br /> resource, e.g. because it has been evicted.<br /> <br /> When devcoredump tries to read the contents of all BOs for dumping, we need<br /> to expect this as well -- in this case, ENODATA is recorded instead of the<br /> buffer contents.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ntfs: set dummy blocksize to read boot_block when mounting<br /> <br /> When mounting, sb-&gt;s_blocksize is used to read the boot_block without<br /> being defined or validated. Set a dummy blocksize before attempting to<br /> read the boot_block.<br /> <br /> The issue can be triggered with the following syz reproducer:<br /> <br /> mkdirat(0xffffffffffffff9c, &amp;(0x7f0000000080)=&amp;#39;./file1\x00&amp;#39;, 0x0)<br /> r4 = openat$nullb(0xffffffffffffff9c, &amp;(0x7f0000000040), 0x121403, 0x0)<br /> ioctl$FS_IOC_SETFLAGS(r4, 0x40081271, &amp;(0x7f0000000980)=0x4000)<br /> mount(&amp;(0x7f0000000140)=@nullb, &amp;(0x7f0000000040)=&amp;#39;./cgroup\x00&amp;#39;,<br /> &amp;(0x7f0000000000)=&amp;#39;ntfs3\x00&amp;#39;, 0x2208004, 0x0)<br /> syz_clone(0x88200200, 0x0, 0x0, 0x0, 0x0, 0x0)<br /> <br /> Here, the ioctl sets the bdev block size to 16384. During mount,<br /> get_tree_bdev_flags() calls sb_set_blocksize(sb, block_size(bdev)),<br /> but since block_size(bdev) &gt; PAGE_SIZE, sb_set_blocksize() leaves<br /> sb-&gt;s_blocksize at zero.<br /> <br /> Later, ntfs_init_from_boot() attempts to read the boot_block while<br /> sb-&gt;s_blocksize is still zero, which triggers the bug.<br /> <br /> [almaz.alexandrovich@paragon-software.com: changed comment style, added<br /> return value handling]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ublk: clean up user copy references on ublk server exit<br /> <br /> If a ublk server process releases a ublk char device file, any requests<br /> dispatched to the ublk server but not yet completed will retain a ref<br /> value of UBLK_REFCOUNT_INIT. Before commit e63d2228ef83 ("ublk: simplify<br /> aborting ublk request"), __ublk_fail_req() would decrement the reference<br /> count before completing the failed request. However, that commit<br /> optimized __ublk_fail_req() to call __ublk_complete_rq() directly<br /> without decrementing the request reference count.<br /> The leaked reference count incorrectly allows user copy and zero copy<br /> operations on the completed ublk request. It also triggers the<br /> WARN_ON_ONCE(refcount_read(&amp;io-&gt;ref)) warnings in ublk_queue_reinit()<br /> and ublk_deinit_queue().<br /> Commit c5c5eb24ed61 ("ublk: avoid ublk_io_release() called after ublk<br /> char dev is closed") already fixed the issue for ublk devices using<br /> UBLK_F_SUPPORT_ZERO_COPY or UBLK_F_AUTO_BUF_REG. However, the reference<br /> count leak also affects UBLK_F_USER_COPY, the other reference-counted<br /> data copy mode. Fix the condition in ublk_check_and_reset_active_ref()<br /> to include all reference-counted data copy modes. This ensures that any<br /> ublk requests still owned by the ublk server when it exits have their<br /> reference counts reset to 0.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/mediatek: fix use-after-free on probe deferral<br /> <br /> The driver is dropping the references taken to the larb devices during<br /> probe after successful lookup as well as on errors. This can<br /> potentially lead to a use-after-free in case a larb device has not yet<br /> been bound to its driver so that the iommu driver probe defers.<br /> <br /> Fix this by keeping the references as expected while the iommu driver is<br /> bound.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> shmem: fix recovery on rename failures<br /> <br /> maple_tree insertions can fail if we are seriously short on memory;<br /> simple_offset_rename() does not recover well if it runs into that.<br /> The same goes for simple_offset_rename_exchange().<br /> <br /> Moreover, shmem_whiteout() expects that if it succeeds, the caller will<br /> progress to d_move(), i.e. that shmem_rename2() won&amp;#39;t fail past the<br /> successful call of shmem_whiteout().<br /> <br /> Not hard to fix, fortunately - mtree_store() can&amp;#39;t fail if the index we<br /> are trying to store into is already present in the tree as a singleton.<br /> <br /> For simple_offset_rename_exchange() that&amp;#39;s enough - we just need to be<br /> careful about the order of operations.<br /> <br /> For simple_offset_rename() solution is to preinsert the target into the<br /> tree for new_dir; the rest can be done without any potentially failing<br /> operations.<br /> <br /> That preinsertion has to be done in shmem_rename2() rather than in<br /> simple_offset_rename() itself - otherwise we&amp;#39;d need to deal with the<br /> possibility of failure after successful shmem_whiteout().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: lkkbd - disable pending work before freeing device<br /> <br /> lkkbd_interrupt() schedules lk-&gt;tq via schedule_work(), and the work<br /> handler lkkbd_reinit() dereferences the lkkbd structure and its<br /> serio/input_dev fields.<br /> <br /> lkkbd_disconnect() and error paths in lkkbd_connect() free the lkkbd<br /> structure without preventing the reinit work from being queued again<br /> until serio_close() returns. This can allow the work handler to run<br /> after the structure has been freed, leading to a potential use-after-free.<br /> <br /> Use disable_work_sync() instead of cancel_work_sync() to ensure the<br /> reinit work cannot be re-queued, and call it both in lkkbd_disconnect()<br /> and in lkkbd_connect() error paths after serio_open().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> svcrdma: bound check rq_pages index in inline path<br /> <br /> svc_rdma_copy_inline_range indexed rqstp-&gt;rq_pages[rc_curpage] without<br /> verifying rc_curpage stays within the allocated page array. Add guards<br /> before the first use and after advancing to a new page.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: invalidate dentry cache on failed whiteout creation<br /> <br /> F2FS can mount filesystems with corrupted directory depth values that<br /> get runtime-clamped to MAX_DIR_HASH_DEPTH. When RENAME_WHITEOUT<br /> operations are performed on such directories, f2fs_rename performs<br /> directory modifications (updating target entry and deleting source<br /> entry) before attempting to add the whiteout entry via f2fs_add_link.<br /> <br /> If f2fs_add_link fails due to the corrupted directory structure, the<br /> function returns an error to VFS, but the partial directory<br /> modifications have already been committed to disk. VFS assumes the<br /> entire rename operation failed and does not update the dentry cache,<br /> leaving stale mappings.<br /> <br /> In the error path, VFS does not call d_move() to update the dentry<br /> cache. This results in new_dentry still pointing to the old inode<br /> (new_inode) which has already had its i_nlink decremented to zero.<br /> The stale cache causes subsequent operations to incorrectly reference<br /> the freed inode.<br /> <br /> This causes subsequent operations to use cached dentry information that<br /> no longer matches the on-disk state. When a second rename targets the<br /> same entry, VFS attempts to decrement i_nlink on the stale inode, which<br /> may already have i_nlink=0, triggering a WARNING in drop_nlink().<br /> <br /> Example sequence:<br /> 1. First rename (RENAME_WHITEOUT): file2 → file1<br /> - f2fs updates file1 entry on disk (points to inode 8)<br /> - f2fs deletes file2 entry on disk<br /> - f2fs_add_link(whiteout) fails (corrupted directory)<br /> - Returns error to VFS<br /> - VFS does not call d_move() due to error<br /> - VFS cache still has: file1 → inode 7 (stale!)<br /> - inode 7 has i_nlink=0 (already decremented)<br /> <br /> 2. Second rename: file3 → file1<br /> - VFS uses stale cache: file1 → inode 7<br /> - Tries to drop_nlink on inode 7 (i_nlink already 0)<br /> - WARNING in drop_nlink()<br /> <br /> Fix this by explicitly invalidating old_dentry and new_dentry when<br /> f2fs_add_link fails during whiteout creation. This forces VFS to<br /> refresh from disk on subsequent operations, ensuring cache consistency<br /> even when the rename partially succeeds.<br /> <br /> Reproducer:<br /> 1. Mount F2FS image with corrupted i_current_depth<br /> 2. renameat2(file2, file1, RENAME_WHITEOUT)<br /> 3. renameat2(file3, file1, 0)<br /> 4. System triggers WARNING in drop_nlink()

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: aic94xx: fix use-after-free in device removal path<br /> <br /> The asd_pci_remove() function fails to synchronize with pending tasklets<br /> before freeing the asd_ha structure, leading to a potential<br /> use-after-free vulnerability.<br /> <br /> When a device removal is triggered (via hot-unplug or module unload),<br /> race condition can occur.<br /> <br /> The fix adds tasklet_kill() before freeing the asd_ha structure,<br /> ensuring all scheduled tasklets complete before cleanup proceeds.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> functionfs: fix the open/removal races<br /> <br /> ffs_epfile_open() can race with removal, ending up with file-&gt;private_data<br /> pointing to freed object.<br /> <br /> There is a total count of opened files on functionfs (both ep0 and<br /> dynamic ones) and when it hits zero, dynamic files get removed.<br /> Unfortunately, that removal can happen while another thread is<br /> in ffs_epfile_open(), but has not incremented the count yet.<br /> In that case open will succeed, leaving us with UAF on any subsequent<br /> read() or write().<br /> <br /> The root cause is that ffs-&gt;opened is misused; atomic_dec_and_test() vs.<br /> atomic_add_return() is not a good idea, when object remains visible all<br /> along.<br /> <br /> To untangle that<br /> * serialize openers on ffs-&gt;mutex (both for ep0 and for dynamic files)<br /> * have dynamic ones use atomic_inc_not_zero() and fail if we had<br /> zero -&gt;opened; in that case the file we are opening is doomed.<br /> * have the inodes of dynamic files marked on removal (from the<br /> callback of simple_recursive_removal()) - clear -&gt;i_private there.<br /> * have open of dynamic ones verify they hadn&amp;#39;t been already removed,<br /> along with checking that state is FFS_ACTIVE.