Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: hibernate: mask DAIF before restoring hibernated kernel<br /> <br /> The arm64 hibernate code manages the exception masking in an unsound<br /> way, leading to potential crashes and/or warnings during resume.<br /> <br /> When a hibernation image is saved in `swsusp_arch_suspend()`, all DAIF<br /> exceptions are masked (by virtue of `local_daif_save()`), and the<br /> suspended image is saved assuming that all DAIF exceptions will remain<br /> masked when the image is restored.<br /> <br /> When a hibernation image is resumed by `swsusp_arch_resume()`, only<br /> interrupts are masked (by virtue of `local_irq_disable()` in<br /> `resume_target_kernel()`). When pseudo-NMI is enabled the DAIF.IF bits<br /> will be clear, and regardless of pseudo-NMI the DAIF.DA bits will be<br /> clear.<br /> <br /> This means that there are two problems:<br /> <br /> (1) It is possible to take Debug, SError, or pseudo-NMI exceptions<br /> during the resume process. This is unsafe, as during the resume<br /> process both the old ane new kernels will tranisently be in an<br /> inconsistent state, and swsusp_arch_suspend_exit() won&amp;#39;t retain<br /> an executable mapping of any exception vectors.<br /> <br /> Any exception taken here will be fatal and silent.<br /> <br /> (2) When re-entering the resumed kernel, some DAIF bits will be clear<br /> unexpectedly. This permits Debug, SError, or pseudo-NMI exceptions<br /> to be taken for a short period while the resumed kernel is not yet<br /> in a consistent state.<br /> <br /> This is detected by CONFIG_ARM64_DEBUG_PRIORITY_MASKING.<br /> <br /> Avoid these issues by masking all DAIF exceptions during resume.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: handle nogenerate/noverify properly in fs-integrity<br /> <br /> Check the BIP_CHECK flags before generating or verifying PI information,<br /> otherwise this can be incorrectly called for non-PI metadata and<br /> cause generation of incorrect metadata and crashed in the verification<br /> handler.<br /> <br /> The new behavior matches that of the block layer auto-generated<br /> metadata.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: do not use make_bad_inode() in ocfs2_read_inode_block_full()<br /> <br /> This reverts commit 58b6fcd2ab34 ("ocfs2: mark inode bad upon validation<br /> failure during read").<br /> <br /> Since &amp;#39;make_bad_inode()&amp;#39; resets inode type to S_IFREG, doing this for<br /> directory inode during active VFS lookup is likely to confuse the latter,<br /> including VFS_BUG_ON_INODE() triggered in this case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/irq: Fix missing r2 clobber in PCREL inline assembly<br /> <br /> In CONFIG_PPC_KERNEL_PCREL mode, r2 is no longer reserved for the TOC<br /> pointer and is available as a caller-saved register [0].<br /> <br /> Both call_do_irq() and call_do_softirq() use inline assembly to call<br /> functions with stack switching, but fail to list r2 in their clobber<br /> lists. This causes the compiler to assume r2 is preserved across these<br /> calls, leading to register corruption when the called functions<br /> (__do_irq and __do_softirq) clobber r2.<br /> <br /> As a result of this kernel crash during interrupt handling is seen and<br /> the kernel fails to boot:<br /> <br /> BUG: Unable to handle kernel data access on write at 0xc000000404697638<br /> Faulting instruction address: 0xc0000000000181ec<br /> Oops: Kernel access of bad area, sig: 11 [#1]<br /> NIP [c0000000000181ec] __do_IRQ+0x6c/0xc0<br /> <br /> With older GCC, the compiler would conservatively allocate<br /> callee-saved registers (like r31) for values spanning function calls,<br /> accidentally avoiding the bug:<br /> <br /> :<br /> 00 00 00 60 nop<br /> a6 02 08 7c mflr r0<br /> f8 ff e1 fb std r31,-8(r1)<br /> f0 ff c1 fb std r30,-16(r1)<br /> 2d 03 10 06 pla r31,53297316<br /> <br /> ...<br /> <br /> 3d e8 ff 4b bl c0000000000165ac <br /> 00 00 21 e8 ld r1,0(r1)<br /> 28 00 4d e9 ld r10,40(r13)<br /> 40 00 21 38 addi r1,r1,64<br /> 2a f9 aa 7f stdx r29,r10,r31<br /> <br /> With newer GCC 14, the compiler uses r2 for such values, exposing the<br /> missing clobber specification:<br /> <br /> :<br /> 00 00 00 60 nop<br /> a6 02 08 7c mflr r0<br /> f0 ff c1 fb std r30,-16(r1)<br /> f8 ff e1 fb std r31,-8(r1)<br /> 29 02 10 06 pla r2,36252592 # c0000000022aadc0 <br /> <br /> ...<br /> <br /> 85 dc ff 4b bl c000000000015ee0 <br /> 00 00 21 e8 ld r1,0(r1)<br /> 28 00 2d e9 ld r9,40(r13)<br /> 30 00 21 38 addi r1,r1,48<br /> 2a 11 c9 7f stdx r30,r9,r2<br /> <br /> Fix this by adding r2 to the clobber list for both call_do_irq() and<br /> call_do_softirq() when CONFIG_PPC_KERNEL_PCREL is enabled.<br /> <br /> [0]: https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg313226.html

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> locking/lockdep: Fix NULL pointer dereference in __lock_set_class()<br /> <br /> register_lock_class() can return NULL when the lock class pool is<br /> exhausted, graph_lock() fails, or key validation fails. However,<br /> __lock_set_class() uses the return value directly in pointer arithmetic<br /> without a NULL check:<br /> <br /> class = register_lock_class(lock, subclass, 0);<br /> hlock-&gt;class_idx = class - lock_classes;<br /> <br /> If class is NULL, this computes a wild offset that corrupts<br /> hlock-&gt;class_idx. The subsequent reacquire_held_locks() call will<br /> invoke hlock_class() with this corrupted index, leading to a NULL or<br /> out-of-bounds pointer dereference.<br /> <br /> Add the missing NULL check, consistent with how __lock_acquire() already<br /> handles this case at the same call site.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: amlogic-spisg: Make sure clk_init_data is fully initialized<br /> <br /> The clk_init_data structure contains several mutually-exclusive members<br /> for different methods to specify the possible parents of a clock,<br /> prompting drivers to initialize only the members they need. However,<br /> not initializing all members may cause subtle issues, which are only<br /> exposed when CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_NONE is<br /> enabled.<br /> <br /> aml_spisg_clk_init() fills in init.parent_data, and assumes that<br /> init.parent_names is NULL. However, the latter in uninitialized, and<br /> thus may cause a crash.<br /> <br /> Make sure all members are fully initialized, to fix such bugs, and to<br /> avoid future breakage when converting drivers to a different method for<br /> specifying the parents.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2: fix circular locking dependency in ocfs2_init_acl()<br /> <br /> A lockdep warning indicates a circular locking dependency between<br /> `&amp;oi-&gt;ip_xattr_sem` and `&amp;journal-&gt;j_trans_barrier`:<br /> <br /> WARNING: possible circular locking dependency detected<br /> is trying to acquire lock:<br /> (&amp;oi-&gt;ip_xattr_sem){++++}-{4:4}, at: ocfs2_init_acl+0x2fd/0x7e0<br /> fs/ocfs2/acl.c:367<br /> <br /> but task is already holding lock:<br /> (&amp;journal-&gt;j_trans_barrier){.+.+}-{4:4}, at: ocfs2_start_trans+0x3ab/0x700<br /> fs/ocfs2/journal.c:369<br /> <br /> The deadlock involves two code paths: Path 1 (setxattr) where<br /> `ocfs2_xattr_set()` acquires `ip_xattr_sem` (write) and then starts a<br /> transaction, which acquires `j_trans_barrier` (read); and Path 2<br /> (mkdir/mknod) where `ocfs2_mknod()` starts a transaction (`j_trans_barrier`<br /> read) and then calls `ocfs2_init_acl()`, which attempts to acquire<br /> `ip_xattr_sem` (read) on the parent directory to retrieve the default ACL.<br /> <br /> Because rw_semaphores are subject to writer priority, a pending writer on<br /> `j_trans_barrier` (e.g., the journal commit thread) can cause Path 1 to<br /> block, while Path 2 is blocked waiting for Path 1 to release<br /> `ip_xattr_sem`.<br /> <br /> The patch fixes the lock ordering by precomputing the ACL state before<br /> starting the OCFS2 transaction, while preserving POSIX ACL storage<br /> semantics and the existing inode/security initialization order. By reading<br /> the parent directory&amp;#39;s default ACL and preparing the new inode&amp;#39;s ACLs<br /> outside the transaction, `ip_xattr_sem` is always acquired before<br /> `j_trans_barrier`.<br /> <br /> `struct ocfs2_acl_state` encapsulates the prepared ACL state, while<br /> `ocfs2_acl_init_prepare()` and `ocfs2_acl_init_release()` avoid code<br /> duplication between `ocfs2_mknod()` and `ocfs2_init_security_and_acl()`.<br /> `ocfs2_calc_xattr_init()` and `ocfs2_init_acl()` use this precomputed<br /> state, removing internal `ip_xattr_sem` acquisition and redundant disk<br /> reads.<br /> <br /> Additionally, remove the `ip_xattr_sem` acquisition from<br /> `ocfs2_xattr_set_handle()`. This function is only used while initializing a<br /> new inode that has not yet been inserted into the inode hash or attached to<br /> a dentry, meaning there is no risk of concurrent access and the lock is<br /> unnecessary.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sched/isolation: Defer freeing of cpumask memblock memory to initcall<br /> <br /> When testing a linux-next kernel with commit 59bd1d914bb5 ("memblock:<br /> warn when freeing reserved memory before memory map is initialized"),<br /> the following warning was hit when there was a "nohz_full" kernel boot<br /> parameter.<br /> <br /> Cannot free reserved memory because of deferred initialization of the memory map<br /> WARNING: mm/memblock.c:904 at __free_reserved_area+0xde/0xf0, CPU#0: swapper/0/0<br /> :<br /> Call Trace:<br /> <br /> memblock_phys_free+0xcb/0x100<br /> housekeeping_init+0x14c/0x170<br /> start_kernel+0x207/0x450<br /> x86_64_start_reservations+0x24/0x30<br /> x86_64_start_kernel+0xda/0xe0<br /> common_startup_64+0x13e/0x141<br /> <br /> <br /> IOW, we shouldn&amp;#39;t free memblock allocated memory so early<br /> in the boot process when memory map isn&amp;#39;t fully initialized in<br /> deferred_init_memmap().<br /> <br /> Fix it by saving the housekeeping cpumask memblock memory to be<br /> freed into a llist free list in housekeeping_init() and add a new<br /> housekeeping_late_init() helper to defer the actual freeing of memblock<br /> memory to when initcall&amp;#39;s are being processed. The cpumask memblock<br /> memory is treated as a llist_node with the size of a "long" type which<br /> is also smallest cpumask size that can be allocated.<br /> <br /> The non-atomic version of the llist APIs are used as there is no<br /> contention.<br /> <br /> This commit depends on the presence of commit 7c2eee9c1367 ("memblock:<br /> don&amp;#39;t touch memblock arrays when memblock_free() is called late")<br /> to prevent a KASAN UAF bug report [1].<br /> <br /> [1] https://lore.kernel.org/lkml/20260505051821.1107133-1-longman@redhat.com/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: entry: Avoid unnecessary local_irq_disable() on kernel exit<br /> <br /> Currently, when exiting to kernel mode, we attempt involuntary<br /> preemption. The preemption logic expects IRQs to be disabled, which is<br /> why we call local_irq_disable() before attempting preemption.<br /> <br /> However, depending on the context, local_irq_disable() may be<br /> unnecessary:<br /> <br /> - __el1_irq(), the non-NMI EL1 IRQ path, already has IRQs disabled, so<br /> local_irq_disable() is redundant.<br /> <br /> - irqentry_exit_to_kernel_mode_preempt() immediately returns when<br /> exiting from an NMI-like context, so calling local_irq_disable()<br /> beforehand is unnecessary work.<br /> <br /> Furthermore, it confuses the pNMI state tracking when we are in a<br /> context with interrupts disabled and the GIC_PRIO_PSR_I_SET bit is set<br /> in the PMR, leading to a warning when<br /> CONFIG_ARM64_DEBUG_PRIORITY_MASKING=y:<br /> <br /> WARNING: ./arch/arm64/include/asm/irqflags.h:63 at arm64_exit_to_kernel_mode+0xb8/0xc0, CPU#40: retsnoop/31805<br /> CPU: 40 UID: 0 PID: 31805 Comm: retsnoop Not tainted 7.2.0-rc6-next-20260805 #7 PREEMPTLAZY<br /> pstate: 234013c9 (nzCv DAIF +PAN -UAO +TCO +DIT +SSBS BTYPE=--)<br /> pc : arm64_exit_to_kernel_mode (arch/arm64/kernel/entry-common.c:63)<br /> lr : el1_abort (arch/arm64/kernel/entry-common.c:323)<br /> pmr: 000000f0<br /> Call trace:<br /> arm64_exit_to_kernel_mode (arch/arm64/kernel/entry-common.c:63) (P)<br /> el1_abort (arch/arm64/kernel/entry-common.c:323)<br /> el1h_64_sync_handler (arch/arm64/kernel/entry-common.c:449)<br /> el1h_64_sync (arch/arm64/kernel/entry.S:589)<br /> [...]<br /> <br /> Split arm64_exit_to_kernel_mode() into preempt, non-preempt, and<br /> dispatch parts so that we can avoid this extra work where it is not<br /> needed and avoid breaking the pNMI tracking logic.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vxlan: mdb: Fix use-after-free in vxlan_mdb_flush()<br /> <br /> vxlan_mdb_flush() iterates over the MDB entries using<br /> hlist_for_each_entry_safe(), which only tolerates the removal of the<br /> current entry. Contrary to the comment above the loop, the removal of an<br /> entry can trigger the removal of another entry.<br /> <br /> Flushing the remotes of a (*, G) entry also removes the (S, G) entries<br /> that were created for its source list, once they are left without<br /> remotes:<br /> <br /> vxlan_mdb_remotes_flush()<br /> -&gt; vxlan_mdb_remote_del()<br /> -&gt; vxlan_mdb_remote_srcs_del()<br /> -&gt; vxlan_mdb_remote_src_del()<br /> -&gt; vxlan_mdb_remote_src_fwd_del()<br /> -&gt; __vxlan_mdb_del()<br /> -&gt; vxlan_mdb_entry_put()<br /> <br /> Such an entry can be located after the (*, G) entry in the list, as<br /> vxlan_mdb_entry_get() returns an existing entry without moving it to the<br /> head of the list. This order is obtained by adding the (S, G) entry<br /> before the (*, G) entry, the latter with NLM_F_REPLACE, as the addition<br /> of the source otherwise fails with -EEXIST. The (S, G) entry is then the<br /> entry saved by hlist_for_each_entry_safe() and it is freed while the<br /> (*, G) entry is processed. The next iteration calls hlist_del() on it<br /> again, writing LIST_POISON1 to LIST_POISON2 [1].<br /> <br /> Besides device deletion, the flush is also reachable from RTM_DELMDB<br /> with NLM_F_BULK.<br /> <br /> Fix by re-reading the next entry after the remotes were flushed. The<br /> current entry cannot be removed by this flush, as source lists can only<br /> be configured on (*, G) entries and the removed entries are (S, G)<br /> entries. It is therefore still linked and its next pointer reflects the<br /> removals.<br /> <br /> [1]<br /> BUG: KASAN: wild-memory-access in vxlan_mdb_entry_put.part.0+0x328/0x588<br /> Write of size 8 at addr dead000000000122 by task ip/327<br /> <br /> CPU: 3 UID: 1000 PID: 327 Comm: ip Not tainted 7.2.0-rc7 #2 PREEMPT<br /> Call trace:<br /> vxlan_mdb_entry_put.part.0+0x328/0x588<br /> vxlan_mdb_flush+0x1d8/0x25c<br /> vxlan_mdb_fini+0x8c/0x100<br /> vxlan_uninit+0x1c/0x7c<br /> unregister_netdevice_many_notify+0x954/0xd4c<br /> rtnl_dellink+0x210/0x530<br /> rtnetlink_rcv_msg+0x434/0x4d0<br /> netlink_rcv_skb+0xc4/0x204<br /> rtnetlink_rcv+0x18/0x24<br /> netlink_unicast+0x4b8/0x548<br /> netlink_sendmsg+0x29c/0x560<br /> ____sys_sendmsg+0x390/0x3ec<br /> ___sys_sendmsg+0x114/0x188<br /> __sys_sendmsg+0xf0/0x178<br /> __arm64_sys_sendmsg+0x48/0x60<br /> invoke_syscall.constprop.0+0x58/0x180<br /> el0_svc_common.constprop.0+0x74/0x140<br /> do_el0_svc+0x30/0x40<br /> el0_svc+0x38/0x98<br /> el0t_64_sync_handler+0xa0/0xe4<br /> el0t_64_sync+0x198/0x19c

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPI: bus: Introduce acpi_bus_get_primary_device()<br /> <br /> The function used for obtaining the first "physical" device for which<br /> the given ACPI one is the ACPI companion, acpi_get_first_physical_node(),<br /> may return a stale device pointer (mostly in theory) because<br /> acpi_unbind_one() may run as a whole after dropping the ACPI device&amp;#39;s<br /> physical_node_lock in acpi_get_first_physical_node() and before it<br /> returns. The last reference to the "physical" device may be dropped<br /> then before the pointer to it is returned to the caller.<br /> <br /> If that happens and the acpi_get_first_physical_node() caller invokes<br /> get_device() on the pointer obtained from it, which is done by the<br /> majority of its callers, a use-after-free will occur.<br /> <br /> To prepare for addressing this problem, introduce a new function for<br /> getting the first "physical" device associated with the given ACPI one<br /> (the "primary physical device") that will also reference count the<br /> device in question before returning a pointer to it.<br /> <br /> Make that new function and acpi_get_first_physical_node() share the<br /> physical node list lookup code.<br /> <br /> No intentional functional impact.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla2xxx: Fix response queue over-consumption in __qla_consume_iocb()<br /> <br /> qla24xx_process_response_queue() advances ring_ptr past the head IOCB<br /> before dispatching, so by the time __qla_consume_iocb() runs, ring_ptr<br /> already points at the first continuation IOCB. The function however<br /> looped purex-&gt;entry_count times starting at ring_ptr. As entry_count<br /> includes the head, this consumed one entry too many: it stamped<br /> RESPONSE_PROCESSED on the next, unrelated IOCB and advanced the ring<br /> past it, silently dropping a legitimate firmware response. The head<br /> IOCB&amp;#39;s signature was also never marked.<br /> <br /> Mark the head processed and account for it, then consume only the<br /> entry_count - 1 continuation IOCBs, matching __qla_copy_purex_to_buffer().