Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/vc4: platform_get_irq_byname() returns an int<br /> <br /> platform_get_irq_byname() will return a negative value if an error<br /> happens, so it should be checked and not just passed directly into<br /> devm_request_threaded_irq() hoping all will be ok.

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.

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.

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.

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.

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.

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.

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.

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.

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().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: MGMT: Fix list corruption and UAF in command complete handlers<br /> <br /> Commit 302a1f674c00 ("Bluetooth: MGMT: Fix possible UAFs") introduced<br /> mgmt_pending_valid(), which not only validates the pending command but<br /> also unlinks it from the pending list if it is valid. This change in<br /> semantics requires updates to several completion handlers to avoid list<br /> corruption and memory safety issues.<br /> <br /> This patch addresses two left-over issues from the aforementioned rework:<br /> <br /> 1. In mgmt_add_adv_patterns_monitor_complete(), mgmt_pending_remove()<br /> is replaced with mgmt_pending_free() in the success path. Since<br /> mgmt_pending_valid() already unlinks the command at the beginning of<br /> the function, calling mgmt_pending_remove() leads to a double list_del()<br /> and subsequent list corruption/kernel panic.<br /> <br /> 2. In set_mesh_complete(), the use of mgmt_pending_foreach() in the error<br /> path is removed. Since the current command is already unlinked by<br /> mgmt_pending_valid(), this foreach loop would incorrectly target other<br /> pending mesh commands, potentially freeing them while they are still being<br /> processed concurrently (leading to UAFs). The redundant mgmt_cmd_status()<br /> is also simplified to use cmd-&gt;opcode directly.