Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xfs: close crash window in attr dabtree inactivation<br /> <br /> When inactivating an inode with node-format extended attributes,<br /> xfs_attr3_node_inactive() invalidates all child leaf/node blocks via<br /> xfs_trans_binval(), but intentionally does not remove the corresponding<br /> entries from their parent node blocks. The implicit assumption is that<br /> xfs_attr_inactive() will truncate the entire attr fork to zero extents<br /> afterwards, so log recovery will never reach the root node and follow<br /> those stale pointers.<br /> <br /> However, if a log shutdown occurs after the leaf/node block cancellations<br /> commit but before the attr bmap truncation commits, this assumption<br /> breaks. Recovery replays the attr bmap intact (the inode still has<br /> attr fork extents), but suppresses replay of all cancelled leaf/node<br /> blocks, maybe leaving them as stale data on disk. On the next mount,<br /> xlog_recover_process_iunlinks() retries inactivation and attempts to<br /> read the root node via the attr bmap. If the root node was not replayed,<br /> reading the unreplayed root block triggers a metadata verification<br /> failure immediately; if it was replayed, following its child pointers<br /> to unreplayed child blocks triggers the same failure:<br /> <br /> XFS (pmem0): Metadata corruption detected at<br /> xfs_da3_node_read_verify+0x53/0x220, xfs_da3_node block 0x78<br /> XFS (pmem0): Unmount and run xfs_repair<br /> XFS (pmem0): First 128 bytes of corrupted metadata buffer:<br /> 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> XFS (pmem0): metadata I/O error in "xfs_da_read_buf+0x104/0x190" at daddr 0x78 len 8 error 117<br /> <br /> Fix this in two places:<br /> <br /> In xfs_attr3_node_inactive(), after calling xfs_trans_binval() on a<br /> child block, immediately remove the entry that references it from the<br /> parent node in the same transaction. This eliminates the window where<br /> the parent holds a pointer to a cancelled block. Once all children are<br /> removed, the now-empty root node is converted to a leaf block within the<br /> same transaction. This node-to-leaf conversion is necessary for crash<br /> safety. If the system shutdown after the empty node is written to the<br /> log but before the second-phase bmap truncation commits, log recovery<br /> will attempt to verify the root block on disk. xfs_da3_node_verify()<br /> does not permit a node block with count == 0; such a block will fail<br /> verification and trigger a metadata corruption shutdown. on the other<br /> hand, leaf blocks are allowed to have this transient state.<br /> <br /> In xfs_attr_inactive(), split the attr fork truncation into two explicit<br /> phases. First, truncate all extents beyond the root block (the child<br /> extents whose parent references have already been removed above).<br /> Second, invalidate the root block and truncate the attr bmap to zero in<br /> a single transaction. The two operations in the second phase must be<br /> atomic: as long as the attr bmap has any non-zero length, recovery can<br /> follow it to the root block, so the root block invalidation must commit<br /> together with the bmap-to-zero truncation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: target: tcm_loop: Drain commands in target_reset handler<br /> <br /> tcm_loop_target_reset() violates the SCSI EH contract: it returns SUCCESS<br /> without draining any in-flight commands. The SCSI EH documentation<br /> (scsi_eh.rst) requires that when a reset handler returns SUCCESS the driver<br /> has made lower layers "forget about timed out scmds" and is ready for new<br /> commands. Every other SCSI LLD (virtio_scsi, mpt3sas, ipr, scsi_debug,<br /> mpi3mr) enforces this by draining or completing outstanding commands before<br /> returning SUCCESS.<br /> <br /> Because tcm_loop_target_reset() doesn&amp;#39;t drain, the SCSI EH reuses in-flight<br /> scsi_cmnd structures for recovery commands (e.g. TUR) while the target core<br /> still has async completion work queued for the old se_cmd. The memset in<br /> queuecommand zeroes se_lun and lun_ref_active, causing<br /> transport_lun_remove_cmd() to skip its percpu_ref_put(). The leaked LUN<br /> reference prevents transport_clear_lun_ref() from completing, hanging<br /> configfs LUN unlink forever in D-state:<br /> <br /> INFO: task rm:264 blocked for more than 122 seconds.<br /> rm D 0 264 258 0x00004000<br /> Call Trace:<br /> __schedule+0x3d0/0x8e0<br /> schedule+0x36/0xf0<br /> transport_clear_lun_ref+0x78/0x90 [target_core_mod]<br /> core_tpg_remove_lun+0x28/0xb0 [target_core_mod]<br /> target_fabric_port_unlink+0x50/0x60 [target_core_mod]<br /> configfs_unlink+0x156/0x1f0 [configfs]<br /> vfs_unlink+0x109/0x290<br /> do_unlinkat+0x1d5/0x2d0<br /> <br /> Fix this by making tcm_loop_target_reset() actually drain commands:<br /> <br /> 1. Issue TMR_LUN_RESET via tcm_loop_issue_tmr() to drain all commands that<br /> the target core knows about (those not yet CMD_T_COMPLETE).<br /> <br /> 2. Use blk_mq_tagset_busy_iter() to iterate all started requests and<br /> flush_work() on each se_cmd — this drains any deferred completion work<br /> for commands that already had CMD_T_COMPLETE set before the TMR (which<br /> the TMR skips via __target_check_io_state()). This is the same pattern<br /> used by mpi3mr, scsi_debug, and libsas to drain outstanding commands<br /> during reset.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: logitech-hidpp: Prevent use-after-free on force feedback initialisation failure<br /> <br /> Presently, if the force feedback initialisation fails when probing the<br /> Logitech G920 Driving Force Racing Wheel for Xbox One, an error number<br /> will be returned and propagated before the userspace infrastructure<br /> (sysfs and /dev/input) has been torn down. If userspace ignores the<br /> errors and continues to use its references to these dangling entities, a<br /> UAF will promptly follow.<br /> <br /> We have 2 options; continue to return the error, but ensure that all of<br /> the infrastructure is torn down accordingly or continue to treat this<br /> condition as a warning by emitting the message but returning success.<br /> It is thought that the original author&amp;#39;s intention was to emit the<br /> warning but keep the device functional, less the force feedback feature,<br /> so let&amp;#39;s go with that.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: core: Mitigate potential OOB by removing bogus memset()<br /> <br /> The memset() in hid_report_raw_event() has the good intention of<br /> clearing out bogus data by zeroing the area from the end of the incoming<br /> data string to the assumed end of the buffer. However, as we have<br /> previously seen, doing so can easily result in OOB reads and writes in<br /> the subsequent thread of execution.<br /> <br /> The current suggestion from one of the HID maintainers is to remove the<br /> memset() and simply return if the incoming event buffer size is not<br /> large enough to fill the associated report.<br /> <br /> Suggested-by Benjamin Tissoires <br /> <br /> [bentiss: changed the return value]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: multitouch: Check to ensure report responses match the request<br /> <br /> It is possible for a malicious (or clumsy) device to respond to a<br /> specific report&amp;#39;s feature request using a completely different report<br /> ID. This can cause confusion in the HID core resulting in nasty<br /> side-effects such as OOB writes.<br /> <br /> Add a check to ensure that the report ID in the response, matches the<br /> one that was requested. If it doesn&amp;#39;t, omit reporting the raw event and<br /> return early.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ti: icssg-prueth: fix missing data copy and wrong recycle in ZC RX dispatch<br /> <br /> emac_dispatch_skb_zc() allocates a new skb via napi_alloc_skb() but<br /> never copies the packet data from the XDP buffer into it. The skb is<br /> passed up the stack containing uninitialized heap memory instead of<br /> the actual received packet, leaking kernel heap contents to userspace.<br /> <br /> Copy the received packet data from the XDP buffer into the skb using<br /> skb_copy_to_linear_data().<br /> <br /> Additionally, remove the skb_mark_for_recycle() call since the skb is<br /> backed by the NAPI page frag allocator, not page_pool. Marking a<br /> non-page_pool skb for recycle causes the free path to return pages to<br /> a page_pool that does not own them, corrupting page_pool state.<br /> <br /> The non-ZC path (emac_rx_packet) does not have these issues because it<br /> uses napi_build_skb() to wrap the existing page_pool page directly,<br /> requiring no copy, and correctly marks for recycle since the page comes<br /> from page_pool_dev_alloc_pages().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ipv6: ndisc: fix ndisc_ra_useropt to initialize nduseropt_padX fields to zero to prevent an info-leak<br /> <br /> When processing Router Advertisements with user options the kernel<br /> builds an RTM_NEWNDUSEROPT netlink message. The nduseroptmsg struct<br /> has three padding fields that are never zeroed and can leak kernel data<br /> <br /> The fix is simple, just zeroes the padding fields.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: qrtr: replace qrtr_tx_flow radix_tree with xarray to fix memory leak<br /> <br /> __radix_tree_create() allocates and links intermediate nodes into the<br /> tree one by one. If a subsequent allocation fails, the already-linked<br /> nodes remain in the tree with no corresponding leaf entry. These orphaned<br /> internal nodes are never reclaimed because radix_tree_for_each_slot()<br /> only visits slots containing leaf values.<br /> <br /> The radix_tree API is deprecated in favor of xarray. As suggested by<br /> Matthew Wilcox, migrate qrtr_tx_flow from radix_tree to xarray instead<br /> of fixing the radix_tree itself [1]. xarray properly handles cleanup of<br /> internal nodes — xa_destroy() frees all internal xarray nodes when the<br /> qrtr_node is released, preventing the leak.<br /> <br /> [1] https://lore.kernel.org/all/20260225071623.41275-1-jiayuan.chen@linux.dev/T/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mpls: add seqcount to protect the platform_label{,s} pair<br /> <br /> The RCU-protected codepaths (mpls_forward, mpls_dump_routes) can have<br /> an inconsistent view of platform_labels vs platform_label in case of a<br /> concurrent resize (resize_platform_label_table, under<br /> platform_mutex). This can lead to OOB accesses.<br /> <br /> This patch adds a seqcount, so that we get a consistent snapshot.<br /> <br /> Note that mpls_label_ok is also susceptible to this, so the check<br /> against RTA_DST in rtm_to_route_config, done outside platform_mutex,<br /> is not sufficient. This value gets passed to mpls_label_ok once more<br /> in both mpls_route_add and mpls_route_del, so there is no issue, but<br /> that additional check must not be removed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: af-alg - fix NULL pointer dereference in scatterwalk<br /> <br /> The AF_ALG interface fails to unmark the end of a Scatter/Gather List (SGL)<br /> when chaining a new af_alg_tsgl structure. If a sendmsg() fills an SGL<br /> exactly to MAX_SGL_ENTS, the last entry is marked as the end. A subsequent<br /> sendmsg() allocates a new SGL and chains it, but fails to clear the end<br /> marker on the previous SGL&amp;#39;s last data entry.<br /> <br /> This causes the crypto scatterwalk to hit a premature end, returning NULL<br /> on sg_next() and leading to a kernel panic during dereference.<br /> <br /> Fix this by explicitly unmarking the end of the previous SGL when<br /> performing sg_chain() in af_alg_alloc_tsgl().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: caam - fix DMA corruption on long hmac keys<br /> <br /> When a key longer than block size is supplied, it is copied and then<br /> hashed into the real key. The memory allocated for the copy needs to<br /> be rounded to DMA cache alignment, as otherwise the hashed key may<br /> corrupt neighbouring memory.<br /> <br /> The rounding was performed, but never actually used for the allocation.<br /> Fix this by replacing kmemdup with kmalloc for a larger buffer,<br /> followed by memcpy.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: reject root items with drop_progress and zero drop_level<br /> <br /> [BUG]<br /> When recovering relocation at mount time, merge_reloc_root() and<br /> btrfs_drop_snapshot() both use BUG_ON(level == 0) to guard against<br /> an impossible state: a non-zero drop_progress combined with a zero<br /> drop_level in a root_item, which can be triggered:<br /> <br /> ------------[ cut here ]------------<br /> kernel BUG at fs/btrfs/relocation.c:1545!<br /> Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI<br /> CPU: 1 UID: 0 PID: 283 ... Tainted: 6.18.0+ #16 PREEMPT(voluntary)<br /> Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE<br /> Hardware name: QEMU Ubuntu 24.04 PC v2, BIOS 1.16.3-debian-1.16.3-2<br /> RIP: 0010:merge_reloc_root+0x1266/0x1650 fs/btrfs/relocation.c:1545<br /> Code: ffff0000 00004589 d7e9acfa ffffe8a1 79bafebe 02000000<br /> Call Trace:<br /> merge_reloc_roots+0x295/0x890 fs/btrfs/relocation.c:1861<br /> btrfs_recover_relocation+0xd6e/0x11d0 fs/btrfs/relocation.c:4195<br /> btrfs_start_pre_rw_mount+0xa4d/0x1810 fs/btrfs/disk-io.c:3130<br /> open_ctree+0x5824/0x5fe0 fs/btrfs/disk-io.c:3640<br /> btrfs_fill_super fs/btrfs/super.c:987 [inline]<br /> btrfs_get_tree_super fs/btrfs/super.c:1951 [inline]<br /> btrfs_get_tree_subvol fs/btrfs/super.c:2094 [inline]<br /> btrfs_get_tree+0x111c/0x2190 fs/btrfs/super.c:2128<br /> vfs_get_tree+0x9a/0x370 fs/super.c:1758<br /> fc_mount fs/namespace.c:1199 [inline]<br /> do_new_mount_fc fs/namespace.c:3642 [inline]<br /> do_new_mount fs/namespace.c:3718 [inline]<br /> path_mount+0x5b8/0x1ea0 fs/namespace.c:4028<br /> do_mount fs/namespace.c:4041 [inline]<br /> __do_sys_mount fs/namespace.c:4229 [inline]<br /> __se_sys_mount fs/namespace.c:4206 [inline]<br /> __x64_sys_mount+0x282/0x320 fs/namespace.c:4206<br /> ...<br /> RIP: 0033:0x7f969c9a8fde<br /> Code: 0f1f4000 48c7c2b0 fffffff7 d8648902 b8ffffff ffc3660f<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> The bug is reproducible on 7.0.0-rc2-next-20260310 with our dynamic<br /> metadata fuzzing tool that corrupts btrfs metadata at runtime.<br /> <br /> [CAUSE]<br /> A non-zero drop_progress.objectid means an interrupted<br /> btrfs_drop_snapshot() left a resume point on disk, and in that case<br /> drop_level must be greater than 0 because the checkpoint is only<br /> saved at internal node levels.<br /> <br /> Although this invariant is enforced when the kernel writes the root<br /> item, it is not validated when the root item is read back from disk.<br /> That allows on-disk corruption to provide an invalid state with<br /> drop_progress.objectid != 0 and drop_level == 0.<br /> <br /> When relocation recovery later processes such a root item,<br /> merge_reloc_root() reads drop_level and hits BUG_ON(level == 0). The<br /> same invalid metadata can also trigger the corresponding BUG_ON() in<br /> btrfs_drop_snapshot().<br /> <br /> [FIX]<br /> Fix this by validating the root_item invariant in tree-checker when<br /> reading root items from disk: if drop_progress.objectid is non-zero,<br /> drop_level must also be non-zero. Reject such malformed metadata with<br /> -EUCLEAN before it reaches merge_reloc_root() or btrfs_drop_snapshot()<br /> and triggers the BUG_ON.<br /> <br /> After the fix, the same corruption is correctly rejected by tree-checker<br /> and the BUG_ON is no longer triggered.