Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ntfs3: fix integer overflow in run_unpack() volume boundary check<br /> <br /> The volume boundary check `lcn + len &gt; sbi-&gt;used.bitmap.nbits` uses raw<br /> addition which can wrap around for large lcn and len values, bypassing<br /> the validation. Use check_add_overflow() as is already done for the<br /> adjacent prev_lcn + dlcn and vcn64 + len checks added by commit<br /> 3ac37e100385 ("ntfs3: Fix integer overflow in run_unpack()").<br /> <br /> Found by fuzzing with a source-patched harness (LibAFL + QEMU).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/shstk: Prevent deadlock during shstk sigreturn<br /> <br /> During sigreturn the shadow stack signal frame is popped. The kernel does<br /> this by reading the shadow stack using normal read accesses. When it can&amp;#39;t<br /> assume the memory is shadow stack, it takes extra steps to makes sure it is<br /> reading actual shadow stack memory and not other normal readable memory. It<br /> does this by holding the mmap read lock while doing the access and checking<br /> the flags of the VMA.<br /> <br /> Unfortunately that is not safe. If the read of the shadow stack sigframe<br /> hits a page fault, the fault handler will try to recursively grab another<br /> mmap read lock. This normally works ok, but if a writer on another CPU is<br /> also waiting, the second read lock could fail and cause a deadlock.<br /> <br /> Fix this by not holding mmap lock during the read access to userspace.<br /> <br /> Instead use mmap_lock_speculate_...() to watch for changes between dropping<br /> mmap lock and the userspace access. Retry if anything grabbed an mmap write<br /> lock in between and could have changed the VMA.<br /> <br /> These mmap_lock_speculate_...() helpers use mm::mm_lock_seq, which is only<br /> available when PER_VMA_LOCK is configured. So make X86_USER_SHADOW_STACK<br /> depend on it. On x86, PER_VMA_LOCK is a default configuration for SMP<br /> kernels. So drop support for the other configs under the assumption that<br /> the !SMP shadow stack user base does not exist.<br /> <br /> Currently there is a check that skips the lookup work when the SSP can be<br /> assumed to be on a shadow stack. While reorganizing the function, remove<br /> the optimization to make the tricky code flows more common, such that<br /> issues like this cannot escape detection for so long.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ibmasm: fix heap over-read in ibmasm_send_i2o_message()<br /> <br /> The ibmasm_send_i2o_message() function uses get_dot_command_size() to<br /> compute the byte count for memcpy_toio(), but this value is derived from<br /> user-controlled fields in the dot_command_header (command_size: u8,<br /> data_size: u16) and is never validated against the actual allocation size.<br /> A root user can write a small buffer with inflated header fields, causing<br /> memcpy_toio() to read up to ~65 KB past the end of the allocation into<br /> adjacent kernel heap, which is then forwarded to the service processor<br /> over MMIO.<br /> <br /> Silently clamping the copy size is not sufficient: if the header fields<br /> claim a larger size than the buffer, the SP receives a dot command whose<br /> own header is inconsistent with the I2O message length, which can cause<br /> the SP to desynchronize. Reject such commands outright by returning<br /> failure.<br /> <br /> Validate command_size before calling get_mfa_inbound() to avoid leaking<br /> an I2O message frame: reading INBOUND_QUEUE_PORT dequeues a hardware<br /> frame from the controller&amp;#39;s free pool, and returning without a<br /> corresponding set_mfa_inbound() call would permanently exhaust it.<br /> <br /> Additionally, clamp command_size to I2O_COMMAND_SIZE before the<br /> memcpy_toio() so the MMIO write stays within the I2O message frame,<br /> consistent with the clamping already performed by outgoing_message_size()<br /> for the header field.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: nSVM: Always use NextRIP as vmcb02&amp;#39;s NextRIP after first L2 VMRUN<br /> <br /> For guests with NRIPS disabled, L1 does not provide NextRIP when running<br /> an L2 with an injected soft interrupt, instead it advances the current RIP<br /> before running it. KVM uses the current RIP as the NextRIP in vmcb02 to<br /> emulate a CPU without NRIPS.<br /> <br /> However, after L2 runs the first time, NextRIP will be updated by the CPU<br /> and/or KVM, and the current RIP is no longer the correct value to use in<br /> vmcb02. Hence, after save/restore, use the current RIP if and only if a<br /> nested run is pending, otherwise use NextRIP. Give soft_int_next_rip the<br /> same treatment, as it&amp;#39;s the same logic, just for a narrower use case.<br /> <br /> [sean: give soft_int_next_rip the same treatment]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: qat - fix IRQ cleanup on 6xxx probe failure<br /> <br /> When adf_dev_up() partially completes and then fails, the IRQ<br /> handlers registered during adf_isr_resource_alloc() are not detached<br /> before the MSI-X vectors are released.<br /> <br /> Since the device is enabled with pcim_enable_device(), calling<br /> pci_alloc_irq_vectors() internally registers pcim_msi_release() as a<br /> devres action. On probe failure, devres runs pcim_msi_release() which<br /> calls pci_free_irq_vectors(), tearing down the MSI-X vectors while IRQ<br /> handlers (for example &amp;#39;qat0-bundle0&amp;#39;) are still attached. This causes<br /> remove_proc_entry() warnings:<br /> <br /> [ 22.163964] remove_proc_entry: removing non-empty directory &amp;#39;irq/143&amp;#39;, leaking at least &amp;#39;qat0-bundle0&amp;#39;<br /> <br /> Moving the devm_add_action_or_reset() before adf_dev_up() does not solve<br /> the problem since devres runs in LIFO order and pcim_msi_release(),<br /> registered later inside adf_dev_up(), would still fire before<br /> adf_device_down().<br /> <br /> Fix by calling adf_dev_down() explicitly when adf_dev_up() fails, to<br /> properly free IRQ handlers before devres releases the MSI-X vectors.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jbd2: fix deadlock in jbd2_journal_cancel_revoke()<br /> <br /> Commit f76d4c28a46a ("fs/jbd2: use sleeping version of<br /> __find_get_block()") changed jbd2_journal_cancel_revoke() to use<br /> __find_get_block_nonatomic() which holds the folio lock instead of<br /> i_private_lock. This breaks the lock ordering (folio -&gt; buffer) and<br /> causes an ABBA deadlock when the filesystem blocksize

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: amphion: Fix race between m2m job_abort and device_run<br /> <br /> Fix kernel panic caused by race condition where v4l2_m2m_ctx_release()<br /> frees m2m_ctx while v4l2_m2m_try_run() is about to call device_run<br /> with the same context.<br /> <br /> Race sequence:<br /> v4l2_m2m_try_run(): v4l2_m2m_ctx_release():<br /> lock/unlock v4l2_m2m_cancel_job()<br /> job_abort()<br /> v4l2_m2m_job_finish()<br /> kfree(m2m_ctx)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> landlock: Fix LOG_SUBDOMAINS_OFF inheritance across fork()<br /> <br /> hook_cred_transfer() only copies the Landlock security blob when the<br /> source credential has a domain. This is inconsistent with<br /> landlock_restrict_self() which can set LOG_SUBDOMAINS_OFF on a<br /> credential without creating a domain (via the ruleset_fd=-1 path): the<br /> field is committed but not preserved across fork() because the child&amp;#39;s<br /> prepare_creds() calls hook_cred_transfer() which skips the copy when<br /> domain is NULL.<br /> <br /> This breaks the documented use case where a process mutes subdomain logs<br /> before forking sandboxed children: the children lose the muting and<br /> their domains produce unexpected audit records.<br /> <br /> Fix this by unconditionally copying the Landlock credential blob.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> apparmor: Fix string overrun due to missing termination<br /> <br /> When booting Ubuntu 26.04 with Linux 7.0-rc4 on an ARM64 Qualcomm<br /> Snapdragon X1 we see a string buffer overrun:<br /> <br /> BUG: KASAN: slab-out-of-bounds in aa_dfa_match (security/apparmor/match.c:535)<br /> Read of size 1 at addr ffff0008901cc000 by task snap-update-ns/2120<br /> <br /> CPU: 5 UID: 60578 PID: 2120 Comm: snap-update-ns Not tainted 7.0.0-rc4+ #22 PREEMPTLAZY<br /> Hardware name: LENOVO 83ED/LNVNB161216, BIOS NHCN60WW 09/11/2025<br /> Call trace:<br /> show_stack (arch/arm64/kernel/stacktrace.c:501) (C)<br /> dump_stack_lvl (lib/dump_stack.c:122)<br /> print_report (mm/kasan/report.c:379 mm/kasan/report.c:482)<br /> kasan_report (mm/kasan/report.c:597)<br /> __asan_report_load1_noabort (mm/kasan/report_generic.c:378)<br /> aa_dfa_match (security/apparmor/match.c:535)<br /> match_mnt_path_str (security/apparmor/mount.c:244 security/apparmor/mount.c:336)<br /> match_mnt (security/apparmor/mount.c:371)<br /> aa_bind_mount (security/apparmor/mount.c:447 (discriminator 4))<br /> apparmor_sb_mount (security/apparmor/lsm.c:719 (discriminator 1))<br /> security_sb_mount (security/security.c:1062 (discriminator 31))<br /> path_mount (fs/namespace.c:4101)<br /> __arm64_sys_mount (fs/namespace.c:4172 fs/namespace.c:4361 fs/namespace.c:4338 fs/namespace.c:4338)<br /> invoke_syscall.constprop.0 (arch/arm64/kernel/syscall.c:35 arch/arm64/kernel/syscall.c:49)<br /> el0_svc_common.constprop.0 (./include/linux/thread_info.h:142 (discriminator 2) arch/arm64/kernel/syscall.c:140 (discriminator 2))<br /> do_el0_svc (arch/arm64/kernel/syscall.c:152)<br /> el0_svc (arch/arm64/kernel/entry-common.c:80 arch/arm64/kernel/entry-common.c:725)<br /> el0t_64_sync_handler (arch/arm64/kernel/entry-common.c:744)<br /> el0t_64_sync (arch/arm64/kernel/entry.S:596)<br /> <br /> Allocated by task 2120:<br /> kasan_save_stack (mm/kasan/common.c:58)<br /> kasan_save_track (./arch/arm64/include/asm/current.h:19 mm/kasan/common.c:70 mm/kasan/common.c:79)<br /> kasan_save_alloc_info (mm/kasan/generic.c:571)<br /> __kasan_kmalloc (mm/kasan/common.c:419)<br /> __kmalloc_noprof (./include/linux/kasan.h:263 mm/slub.c:5260 mm/slub.c:5272)<br /> aa_get_buffer (security/apparmor/lsm.c:2201)<br /> aa_bind_mount (security/apparmor/mount.c:442)<br /> apparmor_sb_mount (security/apparmor/lsm.c:719 (discriminator 1))<br /> security_sb_mount (security/security.c:1062 (discriminator 31))<br /> path_mount (fs/namespace.c:4101)<br /> __arm64_sys_mount (fs/namespace.c:4172 fs/namespace.c:4361 fs/namespace.c:4338 fs/namespace.c:4338)<br /> invoke_syscall.constprop.0 (arch/arm64/kernel/syscall.c:35 arch/arm64/kernel/syscall.c:49)<br /> el0_svc_common.constprop.0 (./include/linux/thread_info.h:142 (discriminator 2) arch/arm64/kernel/syscall.c:140 (discriminator 2))<br /> do_el0_svc (arch/arm64/kernel/syscall.c:152)<br /> el0_svc (arch/arm64/kernel/entry-common.c:80 arch/arm64/kernel/entry-common.c:725)<br /> el0t_64_sync_handler (arch/arm64/kernel/entry-common.c:744)<br /> el0t_64_sync (arch/arm64/kernel/entry.S:596)<br /> <br /> The buggy address belongs to the object at ffff0008901ca000<br /> which belongs to the cache kmalloc-rnd-06-8k of size 8192<br /> The buggy address is located 0 bytes to the right of<br /> allocated 8192-byte region [ffff0008901ca000, ffff0008901cc000)<br /> <br /> The buggy address belongs to the physical page:<br /> page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x9101c8<br /> head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:-1 pincount:0<br /> flags: 0x8000000000000040(head|zone=2)<br /> page_type: f5(slab)<br /> raw: 8000000000000040 ffff000800016c40 fffffdffe2d14e10 ffff000800015c70<br /> raw: 0000000000000000 0000000800010001 00000000f5000000 0000000000000000<br /> head: 8000000000000040 ffff000800016c40 fffffdffe2d14e10 ffff000800015c70<br /> head: 0000000000000000 0000000800010001 00000000f5000000 0000000000000000<br /> head: 8000000000000003 fffffdffe2407201 fffffdffffffffff 00000000ffffffff<br /> head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008<br /> page dumped because: kasan: bad access detected<br /> <br /> Memory state around the buggy address:<br /> ffff0008901cbf00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> ffff0008<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_event: fix potential UAF in SSP passkey handlers<br /> <br /> hci_conn lookup and field access must be covered by hdev lock in<br /> hci_user_passkey_notify_evt() and hci_keypress_notify_evt(), otherwise<br /> the connection can be freed concurrently.<br /> <br /> Extend the hci_dev_lock critical section to cover all conn usage in both<br /> handlers.<br /> <br /> Keep the existing keypress notification behavior unchanged by routing<br /> the early exits through a common unlock path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> selinux: fix overlayfs mmap() and mprotect() access checks<br /> <br /> The existing SELinux security model for overlayfs is to allow access if<br /> the current task is able to access the top level file (the "user" file)<br /> and the mounter&amp;#39;s credentials are sufficient to access the lower<br /> level file (the "backing" file). Unfortunately, the current code does<br /> not properly enforce these access controls for both mmap() and mprotect()<br /> operations on overlayfs filesystems.<br /> <br /> This patch makes use of the newly created security_mmap_backing_file()<br /> LSM hook to provide the missing backing file enforcement for mmap()<br /> operations, and leverages the backing file API and new LSM blob to<br /> provide the necessary information to properly enforce the mprotect()<br /> access controls.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix missing brelse() in ext4_xattr_inode_dec_ref_all()<br /> <br /> The commit c8e008b60492 ("ext4: ignore xattrs past end")<br /> introduced a refcount leak in when block_csum is false.<br /> <br /> ext4_xattr_inode_dec_ref_all() calls ext4_get_inode_loc() to<br /> get iloc.bh, but never releases it with brelse().