Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: zoned: return EIO on RAID1 block group write pointer mismatch<br /> <br /> There was a bug report about a NULL pointer dereference in<br /> __btrfs_add_free_space_zoned() that ultimately happens because a<br /> conversion from the default metadata profile DUP to a RAID1 profile on two<br /> disks.<br /> <br /> The stack trace has the following signature:<br /> <br /> BTRFS error (device sdc): zoned: write pointer offset mismatch of zones in raid1 profile<br /> BUG: kernel NULL pointer dereference, address: 0000000000000058<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> RIP: 0010:__btrfs_add_free_space_zoned.isra.0+0x61/0x1a0<br /> RSP: 0018:ffffa236b6f3f6d0 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: ffff96c8132f3400 RCX: 0000000000000001<br /> RDX: 0000000010000000 RSI: 0000000000000000 RDI: ffff96c8132f3410<br /> RBP: 0000000010000000 R08: 0000000000000003 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 00000000ffffffff R12: 0000000000000000<br /> R13: ffff96c758f65a40 R14: 0000000000000001 R15: 000011aac0000000<br /> FS: 00007fdab1cb2900(0000) GS:ffff96e60ca00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000058 CR3: 00000001a05ae000 CR4: 0000000000350ef0<br /> Call Trace:<br /> <br /> ? __die_body.cold+0x19/0x27<br /> ? page_fault_oops+0x15c/0x2f0<br /> ? exc_page_fault+0x7e/0x180<br /> ? asm_exc_page_fault+0x26/0x30<br /> ? __btrfs_add_free_space_zoned.isra.0+0x61/0x1a0<br /> btrfs_add_free_space_async_trimmed+0x34/0x40<br /> btrfs_add_new_free_space+0x107/0x120<br /> btrfs_make_block_group+0x104/0x2b0<br /> btrfs_create_chunk+0x977/0xf20<br /> btrfs_chunk_alloc+0x174/0x510<br /> ? srso_return_thunk+0x5/0x5f<br /> btrfs_inc_block_group_ro+0x1b1/0x230<br /> btrfs_relocate_block_group+0x9e/0x410<br /> btrfs_relocate_chunk+0x3f/0x130<br /> btrfs_balance+0x8ac/0x12b0<br /> ? srso_return_thunk+0x5/0x5f<br /> ? srso_return_thunk+0x5/0x5f<br /> ? __kmalloc_cache_noprof+0x14c/0x3e0<br /> btrfs_ioctl+0x2686/0x2a80<br /> ? srso_return_thunk+0x5/0x5f<br /> ? ioctl_has_perm.constprop.0.isra.0+0xd2/0x120<br /> __x64_sys_ioctl+0x97/0xc0<br /> do_syscall_64+0x82/0x160<br /> ? srso_return_thunk+0x5/0x5f<br /> ? __memcg_slab_free_hook+0x11a/0x170<br /> ? srso_return_thunk+0x5/0x5f<br /> ? kmem_cache_free+0x3f0/0x450<br /> ? srso_return_thunk+0x5/0x5f<br /> ? srso_return_thunk+0x5/0x5f<br /> ? syscall_exit_to_user_mode+0x10/0x210<br /> ? srso_return_thunk+0x5/0x5f<br /> ? do_syscall_64+0x8e/0x160<br /> ? sysfs_emit+0xaf/0xc0<br /> ? srso_return_thunk+0x5/0x5f<br /> ? srso_return_thunk+0x5/0x5f<br /> ? seq_read_iter+0x207/0x460<br /> ? srso_return_thunk+0x5/0x5f<br /> ? vfs_read+0x29c/0x370<br /> ? srso_return_thunk+0x5/0x5f<br /> ? srso_return_thunk+0x5/0x5f<br /> ? syscall_exit_to_user_mode+0x10/0x210<br /> ? srso_return_thunk+0x5/0x5f<br /> ? do_syscall_64+0x8e/0x160<br /> ? srso_return_thunk+0x5/0x5f<br /> ? exc_page_fault+0x7e/0x180<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7fdab1e0ca6d<br /> RSP: 002b:00007ffeb2b60c80 EFLAGS: 00000246 ORIG_RAX: 0000000000000010<br /> RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fdab1e0ca6d<br /> RDX: 00007ffeb2b60d80 RSI: 00000000c4009420 RDI: 0000000000000003<br /> RBP: 00007ffeb2b60cd0 R08: 0000000000000000 R09: 0000000000000013<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000<br /> R13: 00007ffeb2b6343b R14: 00007ffeb2b60d80 R15: 0000000000000001<br /> <br /> CR2: 0000000000000058<br /> ---[ end trace 0000000000000000 ]---<br /> <br /> The 1st line is the most interesting here:<br /> <br /> BTRFS error (device sdc): zoned: write pointer offset mismatch of zones in raid1 profile<br /> <br /> When a RAID1 block-group is created and a write pointer mismatch between<br /> the disks in the RAID set is detected, btrfs sets the alloc_offset to the<br /> length of the block group marking it as full. Afterwards the code expects<br /> that a balance operation will evacuate the data in this block-group and<br /> repair the problems.<br /> <br /> But before this is possible, the new space of this block-group will be<br /> accounted in the free space cache. But in __btrfs_<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/eevdf: Fix se-&gt;slice being set to U64_MAX and resulting crash<br /> <br /> There is a code path in dequeue_entities() that can set the slice of a<br /> sched_entity to U64_MAX, which sometimes results in a crash.<br /> <br /> The offending case is when dequeue_entities() is called to dequeue a<br /> delayed group entity, and then the entity&amp;#39;s parent&amp;#39;s dequeue is delayed.<br /> In that case:<br /> <br /> 1. In the if (entity_is_task(se)) else block at the beginning of<br /> dequeue_entities(), slice is set to<br /> cfs_rq_min_slice(group_cfs_rq(se)). If the entity was delayed, then<br /> it has no queued tasks, so cfs_rq_min_slice() returns U64_MAX.<br /> 2. The first for_each_sched_entity() loop dequeues the entity.<br /> 3. If the entity was its parent&amp;#39;s only child, then the next iteration<br /> tries to dequeue the parent.<br /> 4. If the parent&amp;#39;s dequeue needs to be delayed, then it breaks from the<br /> first for_each_sched_entity() loop _without updating slice_.<br /> 5. The second for_each_sched_entity() loop sets the parent&amp;#39;s -&gt;slice to<br /> the saved slice, which is still U64_MAX.<br /> <br /> This throws off subsequent calculations with potentially catastrophic<br /> results. A manifestation we saw in production was:<br /> <br /> 6. In update_entity_lag(), se-&gt;slice is used to calculate limit, which<br /> ends up as a huge negative number.<br /> 7. limit is used in se-&gt;vlag = clamp(vlag, -limit, limit). Because limit<br /> is negative, vlag &gt; limit, so se-&gt;vlag is set to the same huge<br /> negative number.<br /> 8. In place_entity(), se-&gt;vlag is scaled, which overflows and results in<br /> another huge (positive or negative) number.<br /> 9. The adjusted lag is subtracted from se-&gt;vruntime, which increases or<br /> decreases se-&gt;vruntime by a huge number.<br /> 10. pick_eevdf() calls entity_eligible()/vruntime_eligible(), which<br /> incorrectly returns false because the vruntime is so far from the<br /> other vruntimes on the queue, causing the<br /> (vruntime - cfs_rq-&gt;min_vruntime) * load calulation to overflow.<br /> 11. Nothing appears to be eligible, so pick_eevdf() returns NULL.<br /> 12. pick_next_entity() tries to dereference the return value of<br /> pick_eevdf() and crashes.<br /> <br /> Dumping the cfs_rq states from the core dumps with drgn showed tell-tale<br /> huge vruntime ranges and bogus vlag values, and I also traced se-&gt;slice<br /> being set to U64_MAX on live systems (which was usually "benign" since<br /> the rest of the runqueue needed to be in a particular state to crash).<br /> <br /> Fix it in dequeue_entities() by always setting slice from the first<br /> non-empty cfs_rq.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xen-netfront: handle NULL returned by xdp_convert_buff_to_frame()<br /> <br /> The function xdp_convert_buff_to_frame() may return NULL if it fails<br /> to correctly convert the XDP buffer into an XDP frame due to memory<br /> constraints, internal errors, or invalid data. Failing to check for NULL<br /> may lead to a NULL pointer dereference if the result is used later in<br /> processing, potentially causing crashes, data corruption, or undefined<br /> behavior.<br /> <br /> On XDP redirect failure, the associated page must be released explicitly<br /> if it was previously retained via get_page(). Failing to do so may result<br /> in a memory leak, as the pages reference count is not decremented.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> irqchip/gic-v2m: Prevent use after free of gicv2m_get_fwnode()<br /> <br /> With ACPI in place, gicv2m_get_fwnode() is registered with the pci<br /> subsystem as pci_msi_get_fwnode_cb(), which may get invoked at runtime<br /> during a PCI host bridge probe. But, the call back is wrongly marked as<br /> __init, causing it to be freed, while being registered with the PCI<br /> subsystem and could trigger:<br /> <br /> Unable to handle kernel paging request at virtual address ffff8000816c0400<br /> gicv2m_get_fwnode+0x0/0x58 (P)<br /> pci_set_bus_msi_domain+0x74/0x88<br /> pci_register_host_bridge+0x194/0x548<br /> <br /> This is easily reproducible on a Juno board with ACPI boot.<br /> <br /> Retain the function for later use.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: Return NULL from huge_pte_offset() for invalid PMD<br /> <br /> LoongArch&amp;#39;s huge_pte_offset() currently returns a pointer to a PMD slot<br /> even if the underlying entry points to invalid_pte_table (indicating no<br /> mapping). Callers like smaps_hugetlb_range() fetch this invalid entry<br /> value (the address of invalid_pte_table) via this pointer.<br /> <br /> The generic is_swap_pte() check then incorrectly identifies this address<br /> as a swap entry on LoongArch, because it satisfies the "!pte_present()<br /> &amp;&amp; !pte_none()" conditions. This misinterpretation, combined with a<br /> coincidental match by is_migration_entry() on the address bits, leads to<br /> kernel crashes in pfn_swap_entry_to_page().<br /> <br /> Fix this at the architecture level by modifying huge_pte_offset() to<br /> check the PMD entry&amp;#39;s content using pmd_none() before returning. If the<br /> entry is invalid (i.e., it points to invalid_pte_table), return NULL<br /> instead of the pointer to the slot.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ufs: core: Add NULL check in ufshcd_mcq_compl_pending_transfer()<br /> <br /> Add a NULL check for the returned hwq pointer by ufshcd_mcq_req_to_hwq().<br /> <br /> This is similar to the fix in commit 74736103fb41 ("scsi: ufs: core: Fix<br /> ufshcd_abort_one racing issue").

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: uprobes: Add missing fence.i after building the XOL buffer<br /> <br /> The XOL (execute out-of-line) buffer is used to single-step the<br /> replaced instruction(s) for uprobes. The RISC-V port was missing a<br /> proper fence.i (i$ flushing) after constructing the XOL buffer, which<br /> can result in incorrect execution of stale/broken instructions.<br /> <br /> This was found running the BPF selftests "test_progs:<br /> uprobe_autoattach, attach_probe" on the Spacemit K1/X60, where the<br /> uprobes tests randomly blew up.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mcb: fix a double free bug in chameleon_parse_gdd()<br /> <br /> In chameleon_parse_gdd(), if mcb_device_register() fails, &amp;#39;mdev&amp;#39;<br /> would be released in mcb_device_register() via put_device().<br /> Thus, goto &amp;#39;err&amp;#39; label and free &amp;#39;mdev&amp;#39; again causes a double free.<br /> Just return if mcb_device_register() fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mei: vsc: Fix fortify-panic caused by invalid counted_by() use<br /> <br /> gcc 15 honors the __counted_by(len) attribute on vsc_tp_packet.buf[]<br /> and the vsc-tp.c code is using this in a wrong way. len does not contain<br /> the available size in the buffer, it contains the actual packet length<br /> *without* the crc. So as soon as vsc_tp_xfer() tries to add the crc to<br /> buf[] the fortify-panic handler gets triggered:<br /> <br /> [ 80.842193] memcpy: detected buffer overflow: 4 byte write of buffer size 0<br /> [ 80.842243] WARNING: CPU: 4 PID: 272 at lib/string_helpers.c:1032 __fortify_report+0x45/0x50<br /> ...<br /> [ 80.843175] __fortify_panic+0x9/0xb<br /> [ 80.843186] vsc_tp_xfer.cold+0x67/0x67 [mei_vsc_hw]<br /> [ 80.843210] ? seqcount_lockdep_reader_access.constprop.0+0x82/0x90<br /> [ 80.843229] ? lockdep_hardirqs_on+0x7c/0x110<br /> [ 80.843250] mei_vsc_hw_start+0x98/0x120 [mei_vsc]<br /> [ 80.843270] mei_reset+0x11d/0x420 [mei]<br /> <br /> The easiest fix would be to just drop the counted-by but with the exception<br /> of the ack buffer in vsc_tp_xfer_helper() which only contains enough room<br /> for the packet-header, all other uses of vsc_tp_packet always use a buffer<br /> of VSC_TP_MAX_XFER_SIZE bytes for the packet.<br /> <br /> Instead of just dropping the counted-by, split the vsc_tp_packet struct<br /> definition into a header and a full-packet definition and use a fixed<br /> size buf[] in the packet definition, this way fortify-source buffer<br /> overrun checking still works when enabled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: microchip: pci1xxxx: Fix Kernel panic during IRQ handler registration<br /> <br /> Resolve kernel panic while accessing IRQ handler associated with the<br /> generated IRQ. This is done by acquiring the spinlock and storing the<br /> current interrupt state before handling the interrupt request using<br /> generic_handle_irq.<br /> <br /> A previous fix patch was submitted where &amp;#39;generic_handle_irq&amp;#39; was<br /> replaced with &amp;#39;handle_nested_irq&amp;#39;. However, this change also causes<br /> the kernel panic where after determining which GPIO triggered the<br /> interrupt and attempting to call handle_nested_irq with the mapped<br /> IRQ number, leads to a failure in locating the registered handler.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: Require CAP_SYS_ADMIN for all usages of TIOCL_SELMOUSEREPORT<br /> <br /> This requirement was overeagerly loosened in commit 2f83e38a095f<br /> ("tty: Permit some TIOCL_SETSEL modes without CAP_SYS_ADMIN"), but as<br /> it turns out,<br /> <br /> (1) the logic I implemented there was inconsistent (apologies!),<br /> <br /> (2) TIOCL_SELMOUSEREPORT might actually be a small security risk<br /> after all, and<br /> <br /> (3) TIOCL_SELMOUSEREPORT is only meant to be used by the mouse<br /> daemon (GPM or Consolation), which runs as CAP_SYS_ADMIN<br /> already.<br /> <br /> In more detail:<br /> <br /> 1. The previous patch has inconsistent logic:<br /> <br /> In commit 2f83e38a095f ("tty: Permit some TIOCL_SETSEL modes<br /> without CAP_SYS_ADMIN"), we checked for sel_mode ==<br /> TIOCL_SELMOUSEREPORT, but overlooked that the lower four bits of<br /> this "mode" parameter were actually used as an additional way to<br /> pass an argument. So the patch did actually still require<br /> CAP_SYS_ADMIN, if any of the mouse button bits are set, but did not<br /> require it if none of the mouse buttons bits are set.<br /> <br /> This logic is inconsistent and was not intentional. We should have<br /> the same policies for using TIOCL_SELMOUSEREPORT independent of the<br /> value of the "hidden" mouse button argument.<br /> <br /> I sent a separate documentation patch to the man page list with<br /> more details on TIOCL_SELMOUSEREPORT:<br /> https://lore.kernel.org/all/20250223091342.35523-2-gnoack3000@gmail.com/<br /> <br /> 2. TIOCL_SELMOUSEREPORT is indeed a potential security risk which can<br /> let an attacker simulate "keyboard" input to command line<br /> applications on the same terminal, like TIOCSTI and some other<br /> TIOCLINUX "selection mode" IOCTLs.<br /> <br /> By enabling mouse reporting on a terminal and then injecting mouse<br /> reports through TIOCL_SELMOUSEREPORT, an attacker can simulate<br /> mouse movements on the same terminal, similar to the TIOCSTI<br /> keystroke injection attacks that were previously possible with<br /> TIOCSTI and other TIOCL_SETSEL selection modes.<br /> <br /> Many programs (including libreadline/bash) are then prone to<br /> misinterpret these mouse reports as normal keyboard input because<br /> they do not expect input in the X11 mouse protocol form. The<br /> attacker does not have complete control over the escape sequence,<br /> but they can at least control the values of two consecutive bytes<br /> in the binary mouse reporting escape sequence.<br /> <br /> I went into more detail on that in the discussion at<br /> https://lore.kernel.org/all/20250221.0a947528d8f3@gnoack.org/<br /> <br /> It is not equally trivial to simulate arbitrary keystrokes as it<br /> was with TIOCSTI (commit 83efeeeb3d04 ("tty: Allow TIOCSTI to be<br /> disabled")), but the general mechanism is there, and together with<br /> the small number of existing legit use cases (see below), it would<br /> be better to revert back to requiring CAP_SYS_ADMIN for<br /> TIOCL_SELMOUSEREPORT, as it was already the case before<br /> commit 2f83e38a095f ("tty: Permit some TIOCL_SETSEL modes without<br /> CAP_SYS_ADMIN").<br /> <br /> 3. TIOCL_SELMOUSEREPORT is only used by the mouse daemons (GPM or<br /> Consolation), and they are the only legit use case:<br /> <br /> To quote console_codes(4):<br /> <br /> The mouse tracking facility is intended to return<br /> xterm(1)-compatible mouse status reports. Because the console<br /> driver has no way to know the device or type of the mouse, these<br /> reports are returned in the console input stream only when the<br /> virtual terminal driver receives a mouse update ioctl. These<br /> ioctls must be generated by a mouse-aware user-mode application<br /> such as the gpm(8) daemon.<br /> <br /> Jared Finder has also confirmed in<br /> https://lore.kernel.org/all/491f3df9de6593df8e70dbe77614b026@finder.org/<br /> that Emacs does not call TIOCL_SELMOUSEREPORT directly, and it<br /> would be difficult to find good reasons for doing that, given that<br /> it would interfere with the reports that GPM is sending.<br /> <br /> More information on the interaction between GPM, terminals and th<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: xhci: Fix invalid pointer dereference in Etron workaround<br /> <br /> This check is performed before prepare_transfer() and prepare_ring(), so<br /> enqueue can already point at the final link TRB of a segment. And indeed<br /> it will, some 0.4% of times this code is called.<br /> <br /> Then enqueue + 1 is an invalid pointer. It will crash the kernel right<br /> away or load some junk which may look like a link TRB and cause the real<br /> link TRB to be replaced with a NOOP. This wouldn&amp;#39;t end well.<br /> <br /> Use a functionally equivalent test which doesn&amp;#39;t dereference the pointer<br /> and always gives correct result.<br /> <br /> Something has crashed my machine twice in recent days while playing with<br /> an Etron HC, and a control transfer stress test ran for confirmation has<br /> just crashed it again. The same test passes with this patch applied.