Vulnerabilities

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 /> netfs: Fix kernel BUG in netfs_limit_iter() for ITER_KVEC iterators<br /> <br /> When a process crashes and the kernel writes a core dump to a 9P<br /> filesystem, __kernel_write() creates an ITER_KVEC iterator. This<br /> iterator reaches netfs_limit_iter() via netfs_unbuffered_write(), which<br /> only handles ITER_FOLIOQ, ITER_BVEC and ITER_XARRAY iterator types,<br /> hitting the BUG() for any other type.<br /> <br /> Fix this by adding netfs_limit_kvec() following the same pattern as<br /> netfs_limit_bvec(), since both kvec and bvec are simple segment arrays<br /> with pointer and length fields. Dispatch it from netfs_limit_iter() when<br /> the iterator type is ITER_KVEC.

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: idxd: Fix memory leak when a wq is reset<br /> <br /> idxd_wq_disable_cleanup() which is called from the reset path for a<br /> workqueue, sets the wq type to NONE, which for other parts of the<br /> driver mean that the wq is empty (all its resources were released).<br /> <br /> Only set the wq type to NONE after its resources are released.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: idxd: Fix possible invalid memory access after FLR<br /> <br /> In the case that the first Function Level Reset (FLR) concludes<br /> correctly, but in the second FLR the scratch area for the saved<br /> configuration cannot be allocated, it&amp;#39;s possible for a invalid memory<br /> access to happen.<br /> <br /> Always set the deallocated scratch area to NULL after FLR completes.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: idxd: Fix crash when the event log is disabled<br /> <br /> If reporting errors to the event log is not supported by the hardware,<br /> and an error that causes Function Level Reset (FLR) is received, the<br /> driver will try to restore the event log even if it was not allocated.<br /> <br /> Also, only try to free the event log if it was properly allocated.

Insufficient validation of Chrome extension identifiers in Raindrop.io Bookmark Manager Web App 5.6.76.0 allows attackers to obtain sensitive user data via a crafted request.