Vulnerabilidades

*** Pendiente de traducción *** 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]

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix leak of kobject name for sub-group space_info<br /> <br /> When create_space_info_sub_group() allocates elements of<br /> space_info-&gt;sub_group[], kobject_init_and_add() is called for each<br /> element via btrfs_sysfs_add_space_info_type(). However, when<br /> check_removing_space_info() frees these elements, it does not call<br /> btrfs_sysfs_remove_space_info() on them. As a result, kobject_put() is<br /> not called and the associated kobj-&gt;name objects are leaked.<br /> <br /> This memory leak is reproduced by running the blktests test case<br /> zbd/009 on kernels built with CONFIG_DEBUG_KMEMLEAK. The kmemleak<br /> feature reports the following error:<br /> <br /> unreferenced object 0xffff888112877d40 (size 16):<br /> comm "mount", pid 1244, jiffies 4294996972<br /> hex dump (first 16 bytes):<br /> 64 61 74 61 2d 72 65 6c 6f 63 00 c4 c6 a7 cb 7f data-reloc......<br /> backtrace (crc 53ffde4d):<br /> __kmalloc_node_track_caller_noprof+0x619/0x870<br /> kstrdup+0x42/0xc0<br /> kobject_set_name_vargs+0x44/0x110<br /> kobject_init_and_add+0xcf/0x150<br /> btrfs_sysfs_add_space_info_type+0xfc/0x210 [btrfs]<br /> create_space_info_sub_group.constprop.0+0xfb/0x1b0 [btrfs]<br /> create_space_info+0x211/0x320 [btrfs]<br /> btrfs_init_space_info+0x15a/0x1b0 [btrfs]<br /> open_ctree+0x33c7/0x4a50 [btrfs]<br /> btrfs_get_tree.cold+0x9f/0x1ee [btrfs]<br /> vfs_get_tree+0x87/0x2f0<br /> vfs_cmd_create+0xbd/0x280<br /> __do_sys_fsconfig+0x3df/0x990<br /> do_syscall_64+0x136/0x1540<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> To avoid the leak, call btrfs_sysfs_remove_space_info() instead of<br /> kfree() for the elements.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Fix read abandonment during retry<br /> <br /> Under certain circumstances, all the remaining subrequests from a read<br /> request will get abandoned during retry. The abandonment process expects<br /> the &amp;#39;subreq&amp;#39; variable to be set to the place to start abandonment from, but<br /> it doesn&amp;#39;t always have a useful value (it will be uninitialised on the<br /> first pass through the loop and it may point to a deleted subrequest on<br /> later passes).<br /> <br /> Fix the first jump to "abandon:" to set subreq to the start of the first<br /> subrequest expected to need retry (which, in this abandonment case, turned<br /> out unexpectedly to no longer have NEED_RETRY set).<br /> <br /> Also clear the subreq pointer after discarding superfluous retryable<br /> subrequests to cause an oops if we do try to access it.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: idxd: fix possible wrong descriptor completion in llist_abort_desc()<br /> <br /> At the end of this function, d is the traversal cursor of flist, but the<br /> code completes found instead. This can lead to issues such as NULL pointer<br /> dereferences, double completion, or descriptor leaks.<br /> <br /> Fix this by completing d instead of found in the final<br /> list_for_each_entry_safe() loop.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfs: Fix NULL pointer dereference in netfs_unbuffered_write() on retry<br /> <br /> When a write subrequest is marked NETFS_SREQ_NEED_RETRY, the retry path<br /> in netfs_unbuffered_write() unconditionally calls stream-&gt;prepare_write()<br /> without checking if it is NULL.<br /> <br /> Filesystems such as 9P do not set the prepare_write operation, so<br /> stream-&gt;prepare_write remains NULL. When get_user_pages() fails with<br /> -EFAULT and the subrequest is flagged for retry, this results in a NULL<br /> pointer dereference at fs/netfs/direct_write.c:189.<br /> <br /> Fix this by mirroring the pattern already used in write_retry.c: if<br /> stream-&gt;prepare_write is NULL, skip renegotiation and directly reissue<br /> the subrequest via netfs_reissue_write(), which handles iterator reset,<br /> IN_PROGRESS flag, stats update and reissue internally.