Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: replace BUG_ON with proper error handling in ext4_read_inline_folio<br /> <br /> Replace BUG_ON() with proper error handling when inline data size<br /> exceeds PAGE_SIZE. This prevents kernel panic and allows the system to<br /> continue running while properly reporting the filesystem corruption.<br /> <br /> The error is logged via ext4_error_inode(), the buffer head is released<br /> to prevent memory leak, and -EFSCORRUPTED is returned to indicate<br /> filesystem corruption.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: convert inline data to extents when truncate exceeds inline size<br /> <br /> Add a check in ext4_setattr() to convert files from inline data storage<br /> to extent-based storage when truncate() grows the file size beyond the<br /> inline capacity. This prevents the filesystem from entering an<br /> inconsistent state where the inline data flag is set but the file size<br /> exceeds what can be stored inline.<br /> <br /> Without this fix, the following sequence causes a kernel BUG_ON():<br /> <br /> 1. Mount filesystem with inode that has inline flag set and small size<br /> 2. truncate(file, 50MB) - grows size but inline flag remains set<br /> 3. sendfile() attempts to write data<br /> 4. ext4_write_inline_data() hits BUG_ON(write_size &gt; inline_capacity)<br /> <br /> The crash occurs because ext4_write_inline_data() expects inline storage<br /> to accommodate the write, but the actual inline capacity (~60 bytes for<br /> i_block + ~96 bytes for xattrs) is far smaller than the file size and<br /> write request.<br /> <br /> The fix checks if the new size from setattr exceeds the inode&amp;#39;s actual<br /> inline capacity (EXT4_I(inode)-&gt;i_inline_size) and converts the file to<br /> extent-based storage before proceeding with the size change.<br /> <br /> This addresses the root cause by ensuring the inline data flag and file<br /> size remain consistent during truncate operations.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: avoid dereferencing log items after push callbacks<br /> <br /> After xfsaild_push_item() calls iop_push(), the log item may have been<br /> freed if the AIL lock was dropped during the push. Background inode<br /> reclaim or the dquot shrinker can free the log item while the AIL lock<br /> is not held, and the tracepoints in the switch statement dereference<br /> the log item after iop_push() returns.<br /> <br /> Fix this by capturing the log item type, flags, and LSN before calling<br /> xfsaild_push_item(), and introducing a new xfs_ail_push_class trace<br /> event class that takes these pre-captured values and the ailp pointer<br /> instead of the log item pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: save ailp before dropping the AIL lock in push callbacks<br /> <br /> In xfs_inode_item_push() and xfs_qm_dquot_logitem_push(), the AIL lock<br /> is dropped to perform buffer IO. Once the cluster buffer no longer<br /> protects the log item from reclaim, the log item may be freed by<br /> background reclaim or the dquot shrinker. The subsequent spin_lock()<br /> call dereferences lip-&gt;li_ailp, which is a use-after-free.<br /> <br /> Fix this by saving the ailp pointer in a local variable while the AIL<br /> lock is held and the log item is guaranteed to be valid.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix use-after-free and NULL deref in smb_grant_oplock()<br /> <br /> smb_grant_oplock() has two issues in the oplock publication sequence:<br /> <br /> 1) opinfo is linked into ci-&gt;m_op_list (via opinfo_add) before<br /> add_lease_global_list() is called. If add_lease_global_list()<br /> fails (kmalloc returns NULL), the error path frees the opinfo<br /> via __free_opinfo() while it is still linked in ci-&gt;m_op_list.<br /> Concurrent m_op_list readers (opinfo_get_list, or direct iteration<br /> in smb_break_all_levII_oplock) dereference the freed node.<br /> <br /> 2) opinfo-&gt;o_fp is assigned after add_lease_global_list() publishes<br /> the opinfo on the global lease list. A concurrent<br /> find_same_lease_key() can walk the lease list and dereference<br /> opinfo-&gt;o_fp-&gt;f_ci while o_fp is still NULL.<br /> <br /> Fix by restructuring the publication sequence to eliminate post-publish<br /> failure:<br /> <br /> - Set opinfo-&gt;o_fp before any list publication (fixes NULL deref).<br /> - Preallocate lease_table via alloc_lease_table() before opinfo_add()<br /> so add_lease_global_list() becomes infallible after publication.<br /> - Keep the original m_op_list publication order (opinfo_add before<br /> lease list) so concurrent opens via same_client_has_lease() and<br /> opinfo_get_list() still see the in-flight grant.<br /> - Use opinfo_put() instead of __free_opinfo() on err_out so that<br /> the RCU-deferred free path is used.<br /> <br /> This also requires splitting add_lease_global_list() to take a<br /> preallocated lease_table and changing its return type from int to void,<br /> since it can no longer fail.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/damon/core: avoid use of half-online-committed context<br /> <br /> One major usage of damon_call() is online DAMON parameters update. It is<br /> done by calling damon_commit_ctx() inside the damon_call() callback<br /> function. damon_commit_ctx() can fail for two reasons: 1) invalid<br /> parameters and 2) internal memory allocation failures. In case of<br /> failures, the damon_ctx that attempted to be updated (commit destination)<br /> can be partially updated (or, corrupted from a perspective), and therefore<br /> shouldn&amp;#39;t be used anymore. The function only ensures the damon_ctx object<br /> can safely deallocated using damon_destroy_ctx().<br /> <br /> The API callers are, however, calling damon_commit_ctx() only after<br /> asserting the parameters are valid, to avoid damon_commit_ctx() fails due<br /> to invalid input parameters. But it can still theoretically fail if the<br /> internal memory allocation fails. In the case, DAMON may run with the<br /> partially updated damon_ctx. This can result in unexpected behaviors<br /> including even NULL pointer dereference in case of damos_commit_dests()<br /> failure [1]. Such allocation failure is arguably too small to fail, so<br /> the real world impact would be rare. But, given the bad consequence, this<br /> needs to be fixed.<br /> <br /> Avoid such partially-committed (maybe-corrupted) damon_ctx use by saving<br /> the damon_commit_ctx() failure on the damon_ctx object. For this,<br /> introduce damon_ctx-&gt;maybe_corrupted field. damon_commit_ctx() sets it<br /> when it is failed. kdamond_call() checks if the field is set after each<br /> damon_call_control-&gt;fn() is executed. If it is set, ignore remaining<br /> callback requests and return. All kdamond_call() callers including<br /> kdamond_fn() also check the maybe_corrupted field right after<br /> kdamond_call() invocations. If the field is set, break the kdamond_fn()<br /> main loop so that DAMON sill doesn&amp;#39;t use the context that might be<br /> corrupted.<br /> <br /> [sj@kernel.org: let kdamond_call() with cancel regardless of maybe_corrupted]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix use-after-free in update_super_work when racing with umount<br /> <br /> Commit b98535d09179 ("ext4: fix bug_on in start_this_handle during umount<br /> filesystem") moved ext4_unregister_sysfs() before flushing s_sb_upd_work<br /> to prevent new error work from being queued via /proc/fs/ext4/xx/mb_groups<br /> reads during unmount. However, this introduced a use-after-free because<br /> update_super_work calls ext4_notify_error_sysfs() -&gt; sysfs_notify() which<br /> accesses the kobject&amp;#39;s kernfs_node after it has been freed by kobject_del()<br /> in ext4_unregister_sysfs():<br /> <br /> update_super_work ext4_put_super<br /> ----------------- --------------<br /> ext4_unregister_sysfs(sb)<br /> kobject_del(&amp;sbi-&gt;s_kobj)<br /> __kobject_del()<br /> sysfs_remove_dir()<br /> kobj-&gt;sd = NULL<br /> sysfs_put(sd)<br /> kernfs_put() // RCU free<br /> ext4_notify_error_sysfs(sbi)<br /> sysfs_notify(&amp;sbi-&gt;s_kobj)<br /> kn = kobj-&gt;sd // stale pointer<br /> kernfs_get(kn) // UAF on freed kernfs_node<br /> ext4_journal_destroy()<br /> flush_work(&amp;sbi-&gt;s_sb_upd_work)<br /> <br /> Instead of reordering the teardown sequence, fix this by making<br /> ext4_notify_error_sysfs() detect that sysfs has already been torn down<br /> by checking s_kobj.state_in_sysfs, and skipping the sysfs_notify() call<br /> in that case. A dedicated mutex (s_error_notify_mutex) serializes<br /> ext4_notify_error_sysfs() against kobject_del() in ext4_unregister_sysfs()<br /> to prevent TOCTOU races where the kobject could be deleted between the<br /> state_in_sysfs check and the sysfs_notify() call.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: reject mount if bigalloc with s_first_data_block != 0<br /> <br /> bigalloc with s_first_data_block != 0 is not supported, reject mounting<br /> it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: avoid infinite loops caused by residual data<br /> <br /> On the mkdir/mknod path, when mapping logical blocks to physical blocks,<br /> if inserting a new extent into the extent tree fails (in this example,<br /> because the file system disabled the huge file feature when marking the<br /> inode as dirty), ext4_ext_map_blocks() only calls ext4_free_blocks() to<br /> reclaim the physical block without deleting the corresponding data in<br /> the extent tree. This causes subsequent mkdir operations to reference<br /> the previously reclaimed physical block number again, even though this<br /> physical block is already being used by the xattr block. Therefore, a<br /> situation arises where both the directory and xattr are using the same<br /> buffer head block in memory simultaneously.<br /> <br /> The above causes ext4_xattr_block_set() to enter an infinite loop about<br /> "inserted" and cannot release the inode lock, ultimately leading to the<br /> 143s blocking problem mentioned in [1].<br /> <br /> If the metadata is corrupted, then trying to remove some extent space<br /> can do even more harm. Also in case EXT4_GET_BLOCKS_DELALLOC_RESERVE<br /> was passed, remove space wrongly update quota information.<br /> Jan Kara suggests distinguishing between two cases:<br /> <br /> 1) The error is ENOSPC or EDQUOT - in this case the filesystem is fully<br /> consistent and we must maintain its consistency including all the<br /> accounting. However these errors can happen only early before we&amp;#39;ve<br /> inserted the extent into the extent tree. So current code works correctly<br /> for this case.<br /> <br /> 2) Some other error - this means metadata is corrupted. We should strive to<br /> do as few modifications as possible to limit damage. So I&amp;#39;d just skip<br /> freeing of allocated blocks.<br /> <br /> [1]<br /> INFO: task syz.0.17:5995 blocked for more than 143 seconds.<br /> Call Trace:<br /> inode_lock_nested include/linux/fs.h:1073 [inline]<br /> __start_dirop fs/namei.c:2923 [inline]<br /> start_dirop fs/namei.c:2934 [inline]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: validate p_idx bounds in ext4_ext_correct_indexes<br /> <br /> ext4_ext_correct_indexes() walks up the extent tree correcting<br /> index entries when the first extent in a leaf is modified. Before<br /> accessing path[k].p_idx-&gt;ei_block, there is no validation that<br /> p_idx falls within the valid range of index entries for that<br /> level.<br /> <br /> If the on-disk extent header contains a corrupted or crafted<br /> eh_entries value, p_idx can point past the end of the allocated<br /> buffer, causing a slab-out-of-bounds read.<br /> <br /> Fix this by validating path[k].p_idx against EXT_LAST_INDEX() at<br /> both access sites: before the while loop and inside it. Return<br /> -EFSCORRUPTED if the index pointer is out of range, consistent<br /> with how other bounds violations are handled in the ext4 extent<br /> tree code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: xilinx: xdma: Fix regmap init error handling<br /> <br /> devm_regmap_init_mmio returns an ERR_PTR() upon error, not NULL.<br /> Fix the error check and also fix the error message. Use the error code<br /> from ERR_PTR() instead of the wrong value in ret.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: idxd: Fix leaking event log memory<br /> <br /> During the device remove process, the device is reset, causing the<br /> configuration registers to go back to their default state, which is<br /> zero. As the driver is checking if the event log support was enabled<br /> before deallocating, it will fail if a reset happened before.<br /> <br /> Do not check if the support was enabled, the check for &amp;#39;idxd-&gt;evl&amp;#39;<br /> being valid (only allocated if the HW capability is available) is<br /> enough.