Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86-64: rename misleadingly named &amp;#39;__copy_user_nocache()&amp;#39; function<br /> <br /> This function was a masterclass in bad naming, for various historical<br /> reasons.<br /> <br /> It claimed to be a non-cached user copy. It is literally _neither_ of<br /> those things. It&amp;#39;s a specialty memory copy routine that uses<br /> non-temporal stores for the destination (but not the source), and that<br /> does exception handling for both source and destination accesses.<br /> <br /> Also note that while it works for unaligned targets, any unaligned parts<br /> (whether at beginning or end) will not use non-temporal stores, since<br /> only words and quadwords can be non-temporal on x86.<br /> <br /> The exception handling means that it _can_ be used for user space<br /> accesses, but not on its own - it needs all the normal "start user space<br /> access" logic around it.<br /> <br /> But typically the user space access would be the source, not the<br /> non-temporal destination. That was the original intention of this,<br /> where the destination was some fragile persistent memory target that<br /> needed non-temporal stores in order to catch machine check exceptions<br /> synchronously and deal with them gracefully.<br /> <br /> Thus that non-descriptive name: one use case was to copy from user space<br /> into a non-cached kernel buffer. However, the existing users are a mix<br /> of that intended use-case, and a couple of random drivers that just did<br /> this as a performance tweak.<br /> <br /> Some of those random drivers then actively misused the user copying<br /> version (with STAC/CLAC and all) to do kernel copies without ever even<br /> caring about the exception handling, _just_ for the non-temporal<br /> destination.<br /> <br /> Rename it as a first small step to actually make it halfway sane, and<br /> change the prototype to be more normal: it doesn&amp;#39;t take a user pointer<br /> unless the caller has done the proper conversion, and the argument size<br /> is the full size_t (it still won&amp;#39;t actually copy more than 4GB in one<br /> go, but there&amp;#39;s also no reason to silently truncate the size argument in<br /> the caller).<br /> <br /> Finally, use this now sanely named function in the NTB code, which<br /> mis-used a user copy version (with STAC/CLAC and all) of this interface<br /> despite it not actually being a user copy at all.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Reset register ID for BPF_END value tracking<br /> <br /> When a register undergoes a BPF_END (byte swap) operation, its scalar<br /> value is mutated in-place. If this register previously shared a scalar ID<br /> with another register (e.g., after an `r1 = r0` assignment), this tie must<br /> be broken.<br /> <br /> Currently, the verifier misses resetting `dst_reg-&gt;id` to 0 for BPF_END.<br /> Consequently, if a conditional jump checks the swapped register, the<br /> verifier incorrectly propagates the learned bounds to the linked register,<br /> leading to false confidence in the linked register&amp;#39;s value and potentially<br /> allowing out-of-bounds memory accesses.<br /> <br /> Fix this by explicitly resetting `dst_reg-&gt;id` to 0 in the BPF_END case<br /> to break the scalar tie, similar to how BPF_NEG handles it via<br /> `__mark_reg_known`.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dcache: Limit the minimal number of bucket to two<br /> <br /> There is an OOB read problem on dentry_hashtable when user sets<br /> &amp;#39;dhash_entries=1&amp;#39;:<br /> BUG: unable to handle page fault for address: ffff888b30b774b0<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> Oops: Oops: 0000 [#1] SMP PTI<br /> RIP: 0010:__d_lookup+0x56/0x120<br /> Call Trace:<br /> d_lookup.cold+0x16/0x5d<br /> lookup_dcache+0x27/0xf0<br /> lookup_one_qstr_excl+0x2a/0x180<br /> start_dirop+0x55/0xa0<br /> simple_start_creating+0x8d/0xa0<br /> debugfs_start_creating+0x8c/0x180<br /> debugfs_create_dir+0x1d/0x1c0<br /> pinctrl_init+0x6d/0x140<br /> do_one_initcall+0x6d/0x3d0<br /> kernel_init_freeable+0x39f/0x460<br /> kernel_init+0x2a/0x260<br /> <br /> There will be only one bucket in dentry_hashtable when dhash_entries is<br /> set as one, and d_hash_shift is calculated as 32 by dcache_init(). Then,<br /> following process will access more than one buckets(which memory region<br /> is not allocated) in dentry_hashtable:<br /> d_lookup<br /> b = d_hash(hash)<br /> dentry_hashtable + ((u32)hashlen &gt;&gt; d_hash_shift)<br /> // The C standard defines the behavior of right shift amounts<br /> // exceeding the bit width of the operand as undefined. The<br /> // result of &amp;#39;(u32)hashlen &gt;&gt; d_hash_shift&amp;#39; becomes &amp;#39;hashlen&amp;#39;,<br /> // so &amp;#39;b&amp;#39; will point to an unallocated memory region.<br /> hlist_bl_for_each_entry_rcu(b)<br /> hlist_bl_first_rcu(head)<br /> h-&gt;first // read OOB!<br /> <br /> Fix it by limiting the minimal number of dentry_hashtable bucket to two,<br /> so that &amp;#39;d_hash_shift&amp;#39; won&amp;#39;t exceeds the bit width of type u32.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: avoid allocate block from corrupted group in ext4_mb_find_by_goal()<br /> <br /> There&amp;#39;s issue as follows:<br /> ...<br /> EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117<br /> EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost<br /> <br /> EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117<br /> EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost<br /> <br /> EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117<br /> EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost<br /> <br /> EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117<br /> EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost<br /> <br /> EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2243 at logical offset 0 with max blocks 1 with error 117<br /> EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost<br /> <br /> EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2239 at logical offset 0 with max blocks 1 with error 117<br /> EXT4-fs (mmcblk0p1): This should not happen!! Data will be lost<br /> <br /> EXT4-fs (mmcblk0p1): error count since last fsck: 1<br /> EXT4-fs (mmcblk0p1): initial error at time 1765597433: ext4_mb_generate_buddy:760<br /> EXT4-fs (mmcblk0p1): last error at time 1765597433: ext4_mb_generate_buddy:760<br /> ...<br /> <br /> According to the log analysis, blocks are always requested from the<br /> corrupted block group. This may happen as follows:<br /> ext4_mb_find_by_goal<br /> ext4_mb_load_buddy<br /> ext4_mb_load_buddy_gfp<br /> ext4_mb_init_cache<br /> ext4_read_block_bitmap_nowait<br /> ext4_wait_block_bitmap<br /> ext4_validate_block_bitmap<br /> if (!grp || EXT4_MB_GRP_BBITMAP_CORRUPT(grp))<br /> return -EFSCORRUPTED; // There&amp;#39;s no logs.<br /> if (err)<br /> return err; // Will return error<br /> ext4_lock_group(ac-&gt;ac_sb, group);<br /> if (unlikely(EXT4_MB_GRP_BBITMAP_CORRUPT(e4b-&gt;bd_info))) // Unreachable<br /> goto out;<br /> <br /> After commit 9008a58e5dce ("ext4: make the bitmap read routines return<br /> real error codes") merged, Commit 163a203ddb36 ("ext4: mark block group<br /> as corrupt on block bitmap error") is no real solution for allocating<br /> blocks from corrupted block groups. This is because if<br /> &amp;#39;EXT4_MB_GRP_BBITMAP_CORRUPT(e4b-&gt;bd_info)&amp;#39; is true, then<br /> &amp;#39;ext4_mb_load_buddy()&amp;#39; may return an error. This means that the block<br /> allocation will fail.<br /> Therefore, check block group if corrupted when ext4_mb_load_buddy()<br /> returns error.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> serial: 8250: Fix TX deadlock when using DMA<br /> <br /> `dmaengine_terminate_async` does not guarantee that the<br /> `__dma_tx_complete` callback will run. The callback is currently the<br /> only place where `dma-&gt;tx_running` gets cleared. If the transaction is<br /> canceled and the callback never runs, then `dma-&gt;tx_running` will never<br /> get cleared and we will never schedule new TX DMA transactions again.<br /> <br /> This change makes it so we clear `dma-&gt;tx_running` after we terminate<br /> the DMA transaction. This is "safe" because `serial8250_tx_dma_flush`<br /> is holding the UART port lock. The first thing the callback does is also<br /> grab the UART port lock, so access to `dma-&gt;tx_running` is serialized.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: idxd: Fix not releasing workqueue on .release()<br /> <br /> The workqueue associated with an DSA/IAA device is not released when<br /> the object is freed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: always drain queued discard work in ext4_mb_release()<br /> <br /> While reviewing recent ext4 patch[1], Sashiko raised the following<br /> concern[2]:<br /> <br /> &gt; If the filesystem is initially mounted with the discard option,<br /> &gt; deleting files will populate sbi-&gt;s_discard_list and queue<br /> &gt; s_discard_work. If it is then remounted with nodiscard, the<br /> &gt; EXT4_MOUNT_DISCARD flag is cleared, but the pending s_discard_work is<br /> &gt; neither cancelled nor flushed.<br /> <br /> [1] https://lore.kernel.org/r/20260319094545.19291-1-qiang.zhang@linux.dev/<br /> [2] https://sashiko.dev/#/patchset/20260319094545.19291-1-qiang.zhang%40linux.dev<br /> <br /> The concern was valid, but it had nothing to do with the patch[1].<br /> One of the problems with Sashiko in its current (early) form is that<br /> it will detect pre-existing issues and report it as a problem with the<br /> patch that it is reviewing.<br /> <br /> In practice, it would be hard to hit deliberately (unless you are a<br /> malicious syzkaller fuzzer), since it would involve mounting the file<br /> system with -o discard, and then deleting a large number of files,<br /> remounting the file system with -o nodiscard, and then immediately<br /> unmounting the file system before the queued discard work has a change<br /> to drain on its own.<br /> <br /> Fix it because it&amp;#39;s a real bug, and to avoid Sashiko from raising this<br /> concern when analyzing future patches to mballoc.c.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix iloc.bh leak in ext4_fc_replay_inode() error paths<br /> <br /> During code review, Joseph found that ext4_fc_replay_inode() calls<br /> ext4_get_fc_inode_loc() to get the inode location, which holds a<br /> reference to iloc.bh that must be released via brelse().<br /> <br /> However, several error paths jump to the &amp;#39;out&amp;#39; label without<br /> releasing iloc.bh:<br /> <br /> - ext4_handle_dirty_metadata() failure<br /> - sync_dirty_buffer() failure<br /> - ext4_mark_inode_used() failure<br /> - ext4_iget() failure<br /> <br /> Fix this by introducing an &amp;#39;out_brelse&amp;#39; label placed just before<br /> the existing &amp;#39;out&amp;#39; label to ensure iloc.bh is always released.<br /> <br /> Additionally, make ext4_fc_replay_inode() propagate errors<br /> properly instead of always returning 0.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nft_ct: drop pending enqueued packets on removal<br /> <br /> Packets sitting in nfqueue might hold a reference to:<br /> <br /> - templates that specify the conntrack zone, because a percpu area is<br /> used and module removal is possible.<br /> - conntrack timeout policies and helper, where object removal leave<br /> a stale reference.<br /> <br /> Since these objects can just go away, drop enqueued packets to avoid<br /> stale reference to them.<br /> <br /> If there is a need for finer grain removal, this logic can be revisited<br /> to make selective packet drop upon dependencies.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: L2CAP: Fix type confusion in l2cap_ecred_reconf_rsp()<br /> <br /> l2cap_ecred_reconf_rsp() casts the incoming data to struct<br /> l2cap_ecred_conn_rsp (the ECRED *connection* response, 8 bytes with<br /> result at offset 6) instead of struct l2cap_ecred_reconf_rsp (2 bytes<br /> with result at offset 0).<br /> <br /> This causes two problems:<br /> <br /> - The sizeof(*rsp) length check requires 8 bytes instead of the<br /> correct 2, so valid L2CAP_ECRED_RECONF_RSP packets are rejected<br /> with -EPROTO.<br /> <br /> - rsp-&gt;result reads from offset 6 instead of offset 0, returning<br /> wrong data when the packet is large enough to pass the check.<br /> <br /> Fix by using the correct type. Also pass the already byte-swapped<br /> result variable to BT_DBG instead of the raw __le16 field.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: don&amp;#39;t irele after failing to iget in xfs_attri_recover_work<br /> <br /> xlog_recovery_iget* never set @ip to a valid pointer if they return<br /> an error, so this irele will walk off a dangling pointer. Fix that.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: handle wraparound when searching for blocks for indirect mapped blocks<br /> <br /> Commit 4865c768b563 ("ext4: always allocate blocks only from groups<br /> inode can use") restricts what blocks will be allocated for indirect<br /> block based files to block numbers that fit within 32-bit block<br /> numbers.<br /> <br /> However, when using a review bot running on the latest Gemini LLM to<br /> check this commit when backporting into an LTS based kernel, it raised<br /> this concern:<br /> <br /> If ac-&gt;ac_g_ex.fe_group is &gt;= ngroups (for instance, if the goal<br /> group was populated via stream allocation from s_mb_last_groups),<br /> then start will be &gt;= ngroups.<br /> <br /> Does this allow allocating blocks beyond the 32-bit limit for<br /> indirect block mapped files? The commit message mentions that<br /> ext4_mb_scan_groups_linear() takes care to not select unsupported<br /> groups. However, its loop uses group = *start, and the very first<br /> iteration will call ext4_mb_scan_group() with this unsupported<br /> group because next_linear_group() is only called at the end of the<br /> iteration.<br /> <br /> After reviewing the code paths involved and considering the LLM<br /> review, I determined that this can happen when there is a file system<br /> where some files/directories are extent-mapped and others are<br /> indirect-block mapped. To address this, add a safety clamp in<br /> ext4_mb_scan_groups().