There are 1705 open security issues in bookworm.

1689 important issues:

CVE-2020-0347:

        In iptables, there is a possible out of bounds write due to an incorrect bounds check. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-11Android ID: A-136658008

CVE-2021-3847:

        An unauthorized access to the execution of the setuid file with capabilities flaw in the Linux kernel OverlayFS subsystem was found in the way user copying a capable file from a nosuid mount into another mount. A local user could use this flaw to escalate their privileges on the system.

CVE-2021-3864:

        A flaw was found in the way the dumpable flag setting was handled when certain SUID binaries executed its descendants. The prerequisite is a SUID binary that sets real UID equal to effective UID, and real GID equal to effective GID. The descendant will then have a dumpable value set to 1. As a result, if the descendant process crashes and core_pattern is set to a relative value, its core dump is stored in the current directory with uid:gid permissions. An unprivileged local user with eligible root SUID binary could use this flaw to place core dumps into root-owned directories, potentially resulting in escalation of privileges.

CVE-2023-0597:

        A flaw possibility of memory leak in the Linux kernel cpu_entry_area mapping of X86 CPU data to memory was found in the way user can guess location of exception stack(s) or other important data. A local user could use this flaw to get access to some important data with expected location in memory.

CVE-2023-3397:

        A race condition occurred between the functions lmLogClose and txEnd in JFS, in the Linux Kernel, executed in different threads. This flaw allows a local attacker with normal user privileges to crash the system or leak internal kernel information.

CVE-2023-4133:

        A use-after-free vulnerability was found in the cxgb4 driver in the Linux kernel. The bug occurs when the cxgb4 device is detaching due to a possible rearming of the flower_stats_timer from the work queue. This flaw allows a local user to crash the system, causing a denial of service condition.

CVE-2023-6039:

        A use-after-free flaw was found in lan78xx_disconnect in drivers/net/usb/lan78xx.c in the network sub-component, net/usb/lan78xx in the Linux Kernel. This flaw allows a local attacker to crash the system when the LAN78XX USB device detaches.

CVE-2023-6240:

        A Marvin vulnerability side-channel leakage was found in the RSA decryption operation in the Linux Kernel. This issue may allow a network attacker to decrypt ciphertexts or forge signatures, limiting the services that use that private key.

CVE-2024-2193:

        A Speculative Race Condition (SRC) vulnerability that impacts modern CPU architectures supporting speculative execution (related to Spectre V1) has been disclosed. An unauthenticated attacker can exploit this vulnerability to disclose arbitrary data from the CPU using race conditions to access the speculative executable code paths.

CVE-2020-36694:

        An issue was discovered in netfilter in the Linux kernel before 5.10. There can be a use-after-free in the packet processing context, because the per-CPU sequence count is mishandled during concurrent iptables rules replacement. This could be exploited with the CAP_NET_ADMIN capability in an unprivileged namespace. NOTE: cc00bca was reverted in 5.12.

CVE-2023-21264:

        In multiple functions of mem_protect.c, there is a possible way to access hypervisor memory due to a memory access check in the wrong place. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation.

CVE-2023-23005:

        In the Linux kernel before 6.2, mm/memory-tiers.c misinterprets the alloc_memory_type return value (expects it to be NULL in the error case, whereas it is actually an error pointer). NOTE: this is disputed by third parties because there are no realistic cases in which a user can cause the alloc_memory_type error case to be reached.

CVE-2023-31082:

        An issue was discovered in drivers/tty/n_gsm.c in the Linux kernel 6.2. There is a sleeping function called from an invalid context in gsmld_write, which will block the kernel. Note: This has been disputed by 3rd parties as not a valid vulnerability.

CVE-2023-37454:

        An issue was discovered in the Linux kernel through 6.4.2. A crafted UDF filesystem image causes a use-after-free write operation in the udf_put_super and udf_close_lvid functions in fs/udf/super.c. NOTE: the suse.com reference has a different perspective about this.

CVE-2023-52452:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: Fix accesses to uninit stack slots  Privileged programs are supposed to be able to read uninitialized stack memory (ever since 6715df8d5) but, before this patch, these accesses were permitted inconsistently. In particular, accesses were permitted above state->allocated_stack, but not below it. In other words, if the stack was already "large enough", the access was permitted, but otherwise the access was rejected instead of being allowed to "grow the stack". This undesired rejection was happening in two places: - in check_stack_slot_within_bounds() - in check_stack_range_initialized() This patch arranges for these accesses to be permitted. A bunch of tests that were relying on the old rejection had to change; all of them were changed to add also run unprivileged, in which case the old behavior persists. One tests couldn't be updated - global_func16 - because it can't run unprivileged for other reasons.  This patch also fixes the tracking of the stack size for variable-offset reads. This second fix is bundled in the same commit as the first one because they're inter-related. Before this patch, writes to the stack using registers containing a variable offset (as opposed to registers with fixed, known values) were not properly contributing to the function's needed stack size. As a result, it was possible for a program to verify, but then to attempt to read out-of-bounds data at runtime because a too small stack had been allocated for it.  Each function tracks the size of the stack it needs in bpf_subprog_info.stack_depth, which is maintained by update_stack_depth(). For regular memory accesses, check_mem_access() was calling update_state_depth() but it was passing in only the fixed part of the offset register, ignoring the variable offset. This was incorrect; the minimum possible value of that register should be used instead.  This tracking is now fixed by centralizing the tracking of stack size in grow_stack_state(), and by lifting the calls to grow_stack_state() to check_stack_access_within_bounds() as suggested by Andrii. The code is now simpler and more convincingly tracks the correct maximum stack size. check_stack_range_initialized() can now rely on enough stack having been allocated for the access; this helps with the fix for the first issue.  A few tests were changed to also check the stack depth computation. The one that fails without this patch is verifier_var_off:stack_write_priv_vs_unpriv.

CVE-2023-52586:

        In the Linux kernel, the following vulnerability has been resolved:  drm/msm/dpu: Add mutex lock in control vblank irq  Add a mutex lock to control vblank irq to synchronize vblank enable/disable operations happening from different threads to prevent race conditions while registering/unregistering the vblank irq callback.  v4: -Removed vblank_ctl_lock from dpu_encoder_virt, so it is only a     parameter of dpu_encoder_phys.     -Switch from atomic refcnt to a simple int counter as mutex has     now been added v3: Mistakenly did not change wording in last version. It is done now. v2: Slightly changed wording of commit message  Patchwork: https://patchwork.freedesktop.org/patch/571854/

CVE-2023-52590:

        In the Linux kernel, the following vulnerability has been resolved:  ocfs2: Avoid touching renamed directory if parent does not change  The VFS will not be locking moved directory if its parent does not change. Change ocfs2 rename code to avoid touching renamed directory if its parent does not change as without locking that can corrupt the filesystem.

CVE-2023-52591:

        In the Linux kernel, the following vulnerability has been resolved:  reiserfs: Avoid touching renamed directory if parent does not change  The VFS will not be locking moved directory if its parent does not change. Change reiserfs rename code to avoid touching renamed directory if its parent does not change as without locking that can corrupt the filesystem.

CVE-2023-52624:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Wake DMCUB before executing GPINT commands  [Why] DMCUB can be in idle when we attempt to interface with the HW through the GPINT mailbox resulting in a system hang.  [How] Add dc_wake_and_execute_gpint() to wrap the wake, execute, sleep sequence.  If the GPINT executes successfully then DMCUB will be put back into sleep after the optional response is returned.  It functions similar to the inbox command interface.

CVE-2023-52625:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Refactor DMCUB enter/exit idle interface  [Why] We can hang in place trying to send commands when the DMCUB isn't powered on.  [How] We need to exit out of the idle state prior to sending a command, but the process that performs the exit also invokes a command itself.  Fixing this issue involves the following:  1. Using a software state to track whether or not we need to start    the process to exit idle or notify idle.  It's possible for the hardware to have exited an idle state without driver knowledge, but entering one is always restricted to a driver allow - which makes the SW state vs HW state mismatch issue purely one of optimization, which should seldomly be hit, if at all.  2. Refactor any instances of exit/notify idle to use a single wrapper    that maintains this SW state.  This works simialr to dc_allow_idle_optimizations, but works at the DMCUB level and makes sure the state is marked prior to any notify/exit idle so we don't enter an infinite loop.  3. Make sure we exit out of idle prior to sending any commands or    waiting for DMCUB idle.  This patch takes care of 1/2. A future patch will take care of wrapping DMCUB command submission with calls to this new interface.

CVE-2023-52648:

        In the Linux kernel, the following vulnerability has been resolved:  drm/vmwgfx: Unmap the surface before resetting it on a plane state  Switch to a new plane state requires unreferencing of all held surfaces. In the work required for mob cursors the mapped surfaces started being cached but the variable indicating whether the surface is currently mapped was not being reset. This leads to crashes as the duplicated state, incorrectly, indicates the that surface is mapped even when no surface is present. That's because after unreferencing the surface it's perfectly possible for the plane to be backed by a bo instead of a surface.  Reset the surface mapped flag when unreferencing the plane state surface to fix null derefs in cleanup. Fixes crashes in KDE KWin 6.0 on Wayland:  Oops: 0000 [#1] PREEMPT SMP PTI CPU: 4 PID: 2533 Comm: kwin_wayland Not tainted 6.7.0-rc3-vmwgfx #2 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 RIP: 0010:vmw_du_cursor_plane_cleanup_fb+0x124/0x140 [vmwgfx] Code: 00 00 00 75 3a 48 83 c4 10 5b 5d c3 cc cc cc cc 48 8b b3 a8 00 00 00 48 c7 c7 99 90 43 c0 e8 93 c5 db ca 48 8b 83 a8 00 00 00 <48> 8b 78 28 e8 e3 f> RSP: 0018:ffffb6b98216fa80 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff969d84cdcb00 RCX: 0000000000000027 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff969e75f21600 RBP: ffff969d4143dc50 R08: 0000000000000000 R09: ffffb6b98216f920 R10: 0000000000000003 R11: ffff969e7feb3b10 R12: 0000000000000000 R13: 0000000000000000 R14: 000000000000027b R15: ffff969d49c9fc00 FS:  00007f1e8f1b4180(0000) GS:ffff969e75f00000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000028 CR3: 0000000104006004 CR4: 00000000003706f0 Call Trace:  <TASK>  ? __die+0x23/0x70  ? page_fault_oops+0x171/0x4e0  ? exc_page_fault+0x7f/0x180  ? asm_exc_page_fault+0x26/0x30  ? vmw_du_cursor_plane_cleanup_fb+0x124/0x140 [vmwgfx]  drm_atomic_helper_cleanup_planes+0x9b/0xc0  commit_tail+0xd1/0x130  drm_atomic_helper_commit+0x11a/0x140  drm_atomic_commit+0x97/0xd0  ? __pfx___drm_printfn_info+0x10/0x10  drm_atomic_helper_update_plane+0xf5/0x160  drm_mode_cursor_universal+0x10e/0x270  drm_mode_cursor_common+0x102/0x230  ? __pfx_drm_mode_cursor2_ioctl+0x10/0x10  drm_ioctl_kernel+0xb2/0x110  drm_ioctl+0x26d/0x4b0  ? __pfx_drm_mode_cursor2_ioctl+0x10/0x10  ? __pfx_drm_ioctl+0x10/0x10  vmw_generic_ioctl+0xa4/0x110 [vmwgfx]  __x64_sys_ioctl+0x94/0xd0  do_syscall_64+0x61/0xe0  ? __x64_sys_ioctl+0xaf/0xd0  ? syscall_exit_to_user_mode+0x2b/0x40  ? do_syscall_64+0x70/0xe0  ? __x64_sys_ioctl+0xaf/0xd0  ? syscall_exit_to_user_mode+0x2b/0x40  ? do_syscall_64+0x70/0xe0  ? exc_page_fault+0x7f/0x180  entry_SYSCALL_64_after_hwframe+0x6e/0x76 RIP: 0033:0x7f1e93f279ed Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff f> RSP: 002b:00007ffca0faf600 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 000055db876ed2c0 RCX: 00007f1e93f279ed RDX: 00007ffca0faf6c0 RSI: 00000000c02464bb RDI: 0000000000000015 RBP: 00007ffca0faf650 R08: 000055db87184010 R09: 0000000000000007 R10: 000055db886471a0 R11: 0000000000000246 R12: 00007ffca0faf6c0 R13: 00000000c02464bb R14: 0000000000000015 R15: 00007ffca0faf790  </TASK> Modules linked in: snd_seq_dummy snd_hrtimer nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_ine> CR2: 0000000000000028 ---[ end trace 0000000000000000 ]--- RIP: 0010:vmw_du_cursor_plane_cleanup_fb+0x124/0x140 [vmwgfx] Code: 00 00 00 75 3a 48 83 c4 10 5b 5d c3 cc cc cc cc 48 8b b3 a8 00 00 00 48 c7 c7 99 90 43 c0 e8 93 c5 db ca 48 8b 83 a8 00 00 00 <48> 8b 78 28 e8 e3 f> RSP: 0018:ffffb6b98216fa80 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff969d84cdcb00 RCX: 0000000000000027 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff969e75f21600 RBP: ffff969d4143 ---truncated---

CVE-2023-52653:

        In the Linux kernel, the following vulnerability has been resolved:  SUNRPC: fix a memleak in gss_import_v2_context  The ctx->mech_used.data allocated by kmemdup is not freed in neither gss_import_v2_context nor it only caller gss_krb5_import_sec_context, which frees ctx on error.  Thus, this patch reform the last call of gss_import_v2_context to the gss_krb5_import_ctx_v2, preventing the memleak while keepping the return formation.

CVE-2023-52671:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Fix hang/underflow when transitioning to ODM4:1  [Why] Under some circumstances, disabling an OPTC and attempting to reclaim its OPP(s) for a different OPTC could cause a hang/underflow due to OPPs not being properly disconnected from the disabled OPTC.  [How] Ensure that all OPPs are unassigned from an OPTC when it gets disabled.

CVE-2023-52751:

        In the Linux kernel, the following vulnerability has been resolved:  smb: client: fix use-after-free in smb2_query_info_compound()  The following UAF was triggered when running fstests generic/072 with KASAN enabled against Windows Server 2022 and mount options 'multichannel,max_channels=2,vers=3.1.1,mfsymlinks,noperm'    BUG: KASAN: slab-use-after-free in smb2_query_info_compound+0x423/0x6d0 [cifs]   Read of size 8 at addr ffff888014941048 by task xfs_io/27534    CPU: 0 PID: 27534 Comm: xfs_io Not tainted 6.6.0-rc7 #1   Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS   rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014   Call Trace:    dump_stack_lvl+0x4a/0x80    print_report+0xcf/0x650    ? srso_alias_return_thunk+0x5/0x7f    ? srso_alias_return_thunk+0x5/0x7f    ? __phys_addr+0x46/0x90    kasan_report+0xda/0x110    ? smb2_query_info_compound+0x423/0x6d0 [cifs]    ? smb2_query_info_compound+0x423/0x6d0 [cifs]    smb2_query_info_compound+0x423/0x6d0 [cifs]    ? __pfx_smb2_query_info_compound+0x10/0x10 [cifs]    ? srso_alias_return_thunk+0x5/0x7f    ? __stack_depot_save+0x39/0x480    ? kasan_save_stack+0x33/0x60    ? kasan_set_track+0x25/0x30    ? ____kasan_slab_free+0x126/0x170    smb2_queryfs+0xc2/0x2c0 [cifs]    ? __pfx_smb2_queryfs+0x10/0x10 [cifs]    ? __pfx___lock_acquire+0x10/0x10    smb311_queryfs+0x210/0x220 [cifs]    ? __pfx_smb311_queryfs+0x10/0x10 [cifs]    ? srso_alias_return_thunk+0x5/0x7f    ? __lock_acquire+0x480/0x26c0    ? lock_release+0x1ed/0x640    ? srso_alias_return_thunk+0x5/0x7f    ? do_raw_spin_unlock+0x9b/0x100    cifs_statfs+0x18c/0x4b0 [cifs]    statfs_by_dentry+0x9b/0xf0    fd_statfs+0x4e/0xb0    __do_sys_fstatfs+0x7f/0xe0    ? __pfx___do_sys_fstatfs+0x10/0x10    ? srso_alias_return_thunk+0x5/0x7f    ? lockdep_hardirqs_on_prepare+0x136/0x200    ? srso_alias_return_thunk+0x5/0x7f    do_syscall_64+0x3f/0x90    entry_SYSCALL_64_after_hwframe+0x6e/0xd8    Allocated by task 27534:    kasan_save_stack+0x33/0x60    kasan_set_track+0x25/0x30    __kasan_kmalloc+0x8f/0xa0    open_cached_dir+0x71b/0x1240 [cifs]    smb2_query_info_compound+0x5c3/0x6d0 [cifs]    smb2_queryfs+0xc2/0x2c0 [cifs]    smb311_queryfs+0x210/0x220 [cifs]    cifs_statfs+0x18c/0x4b0 [cifs]    statfs_by_dentry+0x9b/0xf0    fd_statfs+0x4e/0xb0    __do_sys_fstatfs+0x7f/0xe0    do_syscall_64+0x3f/0x90    entry_SYSCALL_64_after_hwframe+0x6e/0xd8    Freed by task 27534:    kasan_save_stack+0x33/0x60    kasan_set_track+0x25/0x30    kasan_save_free_info+0x2b/0x50    ____kasan_slab_free+0x126/0x170    slab_free_freelist_hook+0xd0/0x1e0    __kmem_cache_free+0x9d/0x1b0    open_cached_dir+0xff5/0x1240 [cifs]    smb2_query_info_compound+0x5c3/0x6d0 [cifs]    smb2_queryfs+0xc2/0x2c0 [cifs]  This is a race between open_cached_dir() and cached_dir_lease_break() where the cache entry for the open directory handle receives a lease break while creating it.  And before returning from open_cached_dir(), we put the last reference of the new @cfid because of !@cfid->has_lease.  Besides the UAF, while running xfstests a lot of missed lease breaks have been noticed in tests that run several concurrent statfs(2) calls on those cached fids    CIFS: VFS: \\w22-root1.gandalf.test No task to wake, unknown frame...   CIFS: VFS: \\w22-root1.gandalf.test Cmd: 18 Err: 0x0 Flags: 0x1...   CIFS: VFS: \\w22-root1.gandalf.test smb buf 00000000715bfe83 len 108   CIFS: VFS: Dump pending requests:   CIFS: VFS: \\w22-root1.gandalf.test No task to wake, unknown frame...   CIFS: VFS: \\w22-root1.gandalf.test Cmd: 18 Err: 0x0 Flags: 0x1...   CIFS: VFS: \\w22-root1.gandalf.test smb buf 000000005aa7316e len 108   ...  To fix both, in open_cached_dir() ensure that @cfid->has_lease is set right before sending out compounded request so that any potential lease break will be get processed by demultiplex thread while we're still caching @cfid.  And, if open failed for some reason, re-check @cfid->has_lease to decide whether or not put lease reference.

CVE-2023-52761:

        In the Linux kernel, the following vulnerability has been resolved:  riscv: VMAP_STACK overflow detection thread-safe  commit 31da94c25aea ("riscv: add VMAP_STACK overflow detection") added support for CONFIG_VMAP_STACK. If overflow is detected, CPU switches to `shadow_stack` temporarily before switching finally to per-cpu `overflow_stack`.  If two CPUs/harts are racing and end up in over flowing kernel stack, one or both will end up corrupting each other state because `shadow_stack` is not per-cpu. This patch optimizes per-cpu overflow stack switch by directly picking per-cpu `overflow_stack` and gets rid of `shadow_stack`.  Following are the changes in this patch   - Defines an asm macro to obtain per-cpu symbols in destination    register.  - In entry.S, when overflow is detected, per-cpu overflow stack is    located using per-cpu asm macro. Computing per-cpu symbol requires    a temporary register. x31 is saved away into CSR_SCRATCH    (CSR_SCRATCH is anyways zero since we're in kernel).  Please see Links for additional relevant disccussion and alternative solution.  Tested by `echo EXHAUST_STACK > /sys/kernel/debug/provoke-crash/DIRECT` Kernel crash log below   Insufficient stack space to handle exception!/debug/provoke-crash/DIRECT  Task stack:     [0xff20000010a98000..0xff20000010a9c000]  Overflow stack: [0xff600001f7d98370..0xff600001f7d99370]  CPU: 1 PID: 205 Comm: bash Not tainted 6.1.0-rc2-00001-g328a1f96f7b9 #34  Hardware name: riscv-virtio,qemu (DT)  epc : __memset+0x60/0xfc   ra : recursive_loop+0x48/0xc6 [lkdtm]  epc : ffffffff808de0e4 ra : ffffffff0163a752 sp : ff20000010a97e80   gp : ffffffff815c0330 tp : ff600000820ea280 t0 : ff20000010a97e88   t1 : 000000000000002e t2 : 3233206874706564 s0 : ff20000010a982b0   s1 : 0000000000000012 a0 : ff20000010a97e88 a1 : 0000000000000000   a2 : 0000000000000400 a3 : ff20000010a98288 a4 : 0000000000000000   a5 : 0000000000000000 a6 : fffffffffffe43f0 a7 : 00007fffffffffff   s2 : ff20000010a97e88 s3 : ffffffff01644680 s4 : ff20000010a9be90   s5 : ff600000842ba6c0 s6 : 00aaaaaac29e42b0 s7 : 00fffffff0aa3684   s8 : 00aaaaaac2978040 s9 : 0000000000000065 s10: 00ffffff8a7cad10   s11: 00ffffff8a76a4e0 t3 : ffffffff815dbaf4 t4 : ffffffff815dbaf4   t5 : ffffffff815dbab8 t6 : ff20000010a9bb48  status: 0000000200000120 badaddr: ff20000010a97e88 cause: 000000000000000f  Kernel panic - not syncing: Kernel stack overflow  CPU: 1 PID: 205 Comm: bash Not tainted 6.1.0-rc2-00001-g328a1f96f7b9 #34  Hardware name: riscv-virtio,qemu (DT)  Call Trace:  [<ffffffff80006754>] dump_backtrace+0x30/0x38  [<ffffffff808de798>] show_stack+0x40/0x4c  [<ffffffff808ea2a8>] dump_stack_lvl+0x44/0x5c  [<ffffffff808ea2d8>] dump_stack+0x18/0x20  [<ffffffff808dec06>] panic+0x126/0x2fe  [<ffffffff800065ea>] walk_stackframe+0x0/0xf0  [<ffffffff0163a752>] recursive_loop+0x48/0xc6 [lkdtm]  SMP: stopping secondary CPUs  ---[ end Kernel panic - not syncing: Kernel stack overflow ]---

CVE-2023-52770:

        In the Linux kernel, the following vulnerability has been resolved:  f2fs: split initial and dynamic conditions for extent_cache  Let's allocate the extent_cache tree without dynamic conditions to avoid a missing condition causing a panic as below.   # create a file w/ a compressed flag  # disable the compression  # panic while updating extent_cache  F2FS-fs (dm-64): Swapfile: last extent is not aligned to section F2FS-fs (dm-64): Swapfile (3) is not align to section: 1) creat(), 2) ioctl(F2FS_IOC_SET_PIN_FILE), 3) fallocate(2097152 * N) Adding 124996k swap on ./swap-file.  Priority:0 extents:2 across:17179494468k ================================================================== BUG: KASAN: null-ptr-deref in instrument_atomic_read_write out/common/include/linux/instrumented.h:101 [inline] BUG: KASAN: null-ptr-deref in atomic_try_cmpxchg_acquire out/common/include/asm-generic/atomic-instrumented.h:705 [inline] BUG: KASAN: null-ptr-deref in queued_write_lock out/common/include/asm-generic/qrwlock.h:92 [inline] BUG: KASAN: null-ptr-deref in __raw_write_lock out/common/include/linux/rwlock_api_smp.h:211 [inline] BUG: KASAN: null-ptr-deref in _raw_write_lock+0x5a/0x110 out/common/kernel/locking/spinlock.c:295 Write of size 4 at addr 0000000000000030 by task syz-executor154/3327  CPU: 0 PID: 3327 Comm: syz-executor154 Tainted: G           O      5.10.185 #1 Hardware name: emulation qemu-x86/qemu-x86, BIOS 2023.01-21885-gb3cc1cd24d 01/01/2023 Call Trace:  __dump_stack out/common/lib/dump_stack.c:77 [inline]  dump_stack_lvl+0x17e/0x1c4 out/common/lib/dump_stack.c:118  __kasan_report+0x16c/0x260 out/common/mm/kasan/report.c:415  kasan_report+0x51/0x70 out/common/mm/kasan/report.c:428  kasan_check_range+0x2f3/0x340 out/common/mm/kasan/generic.c:186  __kasan_check_write+0x14/0x20 out/common/mm/kasan/shadow.c:37  instrument_atomic_read_write out/common/include/linux/instrumented.h:101 [inline]  atomic_try_cmpxchg_acquire out/common/include/asm-generic/atomic-instrumented.h:705 [inline]  queued_write_lock out/common/include/asm-generic/qrwlock.h:92 [inline]  __raw_write_lock out/common/include/linux/rwlock_api_smp.h:211 [inline]  _raw_write_lock+0x5a/0x110 out/common/kernel/locking/spinlock.c:295  __drop_extent_tree+0xdf/0x2f0 out/common/fs/f2fs/extent_cache.c:1155  f2fs_drop_extent_tree+0x17/0x30 out/common/fs/f2fs/extent_cache.c:1172  f2fs_insert_range out/common/fs/f2fs/file.c:1600 [inline]  f2fs_fallocate+0x19fd/0x1f40 out/common/fs/f2fs/file.c:1764  vfs_fallocate+0x514/0x9b0 out/common/fs/open.c:310  ksys_fallocate out/common/fs/open.c:333 [inline]  __do_sys_fallocate out/common/fs/open.c:341 [inline]  __se_sys_fallocate out/common/fs/open.c:339 [inline]  __x64_sys_fallocate+0xb8/0x100 out/common/fs/open.c:339  do_syscall_64+0x35/0x50 out/common/arch/x86/entry/common.c:46

CVE-2023-52771:

        In the Linux kernel, the following vulnerability has been resolved:  cxl/port: Fix delete_endpoint() vs parent unregistration race  The CXL subsystem, at cxl_mem ->probe() time, establishes a lineage of ports (struct cxl_port objects) between an endpoint and the root of a CXL topology. Each port including the endpoint port is attached to the cxl_port driver.  Given that setup, it follows that when either any port in that lineage goes through a cxl_port ->remove() event, or the memdev goes through a cxl_mem ->remove() event. The hierarchy below the removed port, or the entire hierarchy if the memdev is removed needs to come down.  The delete_endpoint() callback is careful to check whether it is being called to tear down the hierarchy, or if it is only being called to teardown the memdev because an ancestor port is going through ->remove().  That care needs to take the device_lock() of the endpoint's parent. Which requires 2 bugs to be fixed:  1/ A reference on the parent is needed to prevent use-after-free    scenarios like this signature:      BUG: spinlock bad magic on CPU#0, kworker/u56:0/11     Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20230524-3.fc38 05/24/2023     Workqueue: cxl_port detach_memdev [cxl_core]     RIP: 0010:spin_bug+0x65/0xa0     Call Trace:       do_raw_spin_lock+0x69/0xa0      __mutex_lock+0x695/0xb80      delete_endpoint+0xad/0x150 [cxl_core]      devres_release_all+0xb8/0x110      device_unbind_cleanup+0xe/0x70      device_release_driver_internal+0x1d2/0x210      detach_memdev+0x15/0x20 [cxl_core]      process_one_work+0x1e3/0x4c0      worker_thread+0x1dd/0x3d0  2/ In the case of RCH topologies, the parent device that needs to be    locked is not always @port->dev as returned by cxl_mem_find_port(), use    endpoint->dev.parent instead.

CVE-2023-52797:

        In the Linux kernel, the following vulnerability has been resolved:  drivers: perf: Check find_first_bit() return value  We must check the return value of find_first_bit() before using the return value as an index array since it happens to overflow the array and then panic:  [  107.318430] Kernel BUG [#1] [  107.319434] CPU: 3 PID: 1238 Comm: kill Tainted: G            E      6.6.0-rc6ubuntu-defconfig #2 [  107.319465] Hardware name: riscv-virtio,qemu (DT) [  107.319551] epc : pmu_sbi_ovf_handler+0x3a4/0x3ae [  107.319840]  ra : pmu_sbi_ovf_handler+0x52/0x3ae [  107.319868] epc : ffffffff80a0a77c ra : ffffffff80a0a42a sp : ffffaf83fecda350 [  107.319884]  gp : ffffffff823961a8 tp : ffffaf8083db1dc0 t0 : ffffaf83fecda480 [  107.319899]  t1 : ffffffff80cafe62 t2 : 000000000000ff00 s0 : ffffaf83fecda520 [  107.319921]  s1 : ffffaf83fecda380 a0 : 00000018fca29df0 a1 : ffffffffffffffff [  107.319936]  a2 : 0000000001073734 a3 : 0000000000000004 a4 : 0000000000000000 [  107.319951]  a5 : 0000000000000040 a6 : 000000001d1c8774 a7 : 0000000000504d55 [  107.319965]  s2 : ffffffff82451f10 s3 : ffffffff82724e70 s4 : 000000000000003f [  107.319980]  s5 : 0000000000000011 s6 : ffffaf8083db27c0 s7 : 0000000000000000 [  107.319995]  s8 : 0000000000000001 s9 : 00007fffb45d6558 s10: 00007fffb45d81a0 [  107.320009]  s11: ffffaf7ffff60000 t3 : 0000000000000004 t4 : 0000000000000000 [  107.320023]  t5 : ffffaf7f80000000 t6 : ffffaf8000000000 [  107.320037] status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003 [  107.320081] [<ffffffff80a0a77c>] pmu_sbi_ovf_handler+0x3a4/0x3ae [  107.320112] [<ffffffff800b42d0>] handle_percpu_devid_irq+0x9e/0x1a0 [  107.320131] [<ffffffff800ad92c>] generic_handle_domain_irq+0x28/0x36 [  107.320148] [<ffffffff8065f9f8>] riscv_intc_irq+0x36/0x4e [  107.320166] [<ffffffff80caf4a0>] handle_riscv_irq+0x54/0x86 [  107.320189] [<ffffffff80cb0036>] do_irq+0x64/0x96 [  107.320271] Code: 85a6 855e b097 ff7f 80e7 9220 b709 9002 4501 bbd9 (9002) 6097 [  107.320585] ---[ end trace 0000000000000000 ]--- [  107.320704] Kernel panic - not syncing: Fatal exception in interrupt [  107.320775] SMP: stopping secondary CPUs [  107.321219] Kernel Offset: 0x0 from 0xffffffff80000000 [  107.333051] ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---

CVE-2023-52888:

        In the Linux kernel, the following vulnerability has been resolved:  media: mediatek: vcodec: Only free buffer VA that is not NULL  In the MediaTek vcodec driver, while mtk_vcodec_mem_free() is mostly called only when the buffer to free exists, there are some instances that didn't do the check and triggered warnings in practice.  We believe those checks were forgotten unintentionally. Add the checks back to fix the warnings.

CVE-2023-52920:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: support non-r10 register spill/fill to/from stack in precision tracking  Use instruction (jump) history to record instructions that performed register spill/fill to/from stack, regardless if this was done through read-only r10 register, or any other register after copying r10 into it *and* potentially adjusting offset.  To make this work reliably, we push extra per-instruction flags into instruction history, encoding stack slot index (spi) and stack frame number in extra 10 bit flags we take away from prev_idx in instruction history. We don't touch idx field for maximum performance, as it's checked most frequently during backtracking.  This change removes basically the last remaining practical limitation of precision backtracking logic in BPF verifier. It fixes known deficiencies, but also opens up new opportunities to reduce number of verified states, explored in the subsequent patches.  There are only three differences in selftests' BPF object files according to veristat, all in the positive direction (less states).  File                                    Program        Insns (A)  Insns (B)  Insns  (DIFF)  States (A)  States (B)  States (DIFF) --------------------------------------  -------------  ---------  ---------  -------------  ----------  ----------  ------------- test_cls_redirect_dynptr.bpf.linked3.o  cls_redirect        2987       2864  -123 (-4.12%)         240         231    -9 (-3.75%) xdp_synproxy_kern.bpf.linked3.o         syncookie_tc       82848      82661  -187 (-0.23%)        5107        5073   -34 (-0.67%) xdp_synproxy_kern.bpf.linked3.o         syncookie_xdp      85116      84964  -152 (-0.18%)        5162        5130   -32 (-0.62%)  Note, I avoided renaming jmp_history to more generic insn_hist to minimize number of lines changed and potential merge conflicts between bpf and bpf-next trees.  Notice also cur_hist_entry pointer reset to NULL at the beginning of instruction verification loop. This pointer avoids the problem of relying on last jump history entry's insn_idx to determine whether we already have entry for current instruction or not. It can happen that we added jump history entry because current instruction is_jmp_point(), but also we need to add instruction flags for stack access. In this case, we don't want to entries, so we need to reuse last added entry, if it is present.  Relying on insn_idx comparison has the same ambiguity problem as the one that was fixed recently in [0], so we avoid that.    [0] https://patchwork.kernel.org/project/netdevbpf/patch/20231110002638.4168352-3-andrii@kernel.org/

CVE-2023-53149:

        In the Linux kernel, the following vulnerability has been resolved:  ext4: avoid deadlock in fs reclaim with page writeback  Ext4 has a filesystem wide lock protecting ext4_writepages() calls to avoid races with switching of journalled data flag or inode format. This lock can however cause a deadlock like:  CPU0                            CPU1  ext4_writepages()   percpu_down_read(sbi->s_writepages_rwsem);                                 ext4_change_inode_journal_flag()                                   percpu_down_write(sbi->s_writepages_rwsem);                                     - blocks, all readers block from now on   ext4_do_writepages()     ext4_init_io_end()       kmem_cache_zalloc(io_end_cachep, GFP_KERNEL)         fs_reclaim frees dentry...           dentry_unlink_inode()             iput() - last ref =>               iput_final() - inode dirty =>                 write_inode_now()...                   ext4_writepages() tries to acquire sbi->s_writepages_rwsem                     and blocks forever  Make sure we cannot recurse into filesystem reclaim from writeback code to avoid the deadlock.

CVE-2023-53218:

        In the Linux kernel, the following vulnerability has been resolved:  rxrpc: Make it so that a waiting process can be aborted  When sendmsg() creates an rxrpc call, it queues it to wait for a connection and channel to be assigned and then waits before it can start shovelling data as the encrypted DATA packet content includes a summary of the connection parameters.  However, sendmsg() may get interrupted before a connection gets assigned and further sendmsg() calls will fail with EBUSY until an assignment is made.  Fix this so that the call can at least be aborted without failing on EBUSY.  We have to be careful here as sendmsg() mustn't be allowed to start the call timer if the call doesn't yet have a connection assigned as an oops may follow shortly thereafter.

CVE-2023-53261:

        In the Linux kernel, the following vulnerability has been resolved:  coresight: Fix memory leak in acpi_buffer->pointer  There are memory leaks reported by kmemleak: ... unreferenced object 0xffff00213c141000 (size 1024):   comm "systemd-udevd", pid 2123, jiffies 4294909467 (age 6062.160s)   hex dump (first 32 bytes):     04 00 00 00 02 00 00 00 18 10 14 3c 21 00 ff ff  ...........<!...     00 00 00 00 00 00 00 00 03 00 00 00 10 00 00 00  ................   backtrace:     [<000000004b7c9001>] __kmem_cache_alloc_node+0x2f8/0x348     [<00000000b0fc7ceb>] __kmalloc+0x58/0x108     [<0000000064ff4695>] acpi_os_allocate+0x2c/0x68     [<000000007d57d116>] acpi_ut_initialize_buffer+0x54/0xe0     [<0000000024583908>] acpi_evaluate_object+0x388/0x438     [<0000000017b2e72b>] acpi_evaluate_object_typed+0xe8/0x240     [<000000005df0eac2>] coresight_get_platform_data+0x1b4/0x988 [coresight] ...  The ACPI buffer memory (buf.pointer) should be freed. But the buffer is also used after returning from acpi_get_dsd_graph(). Move the temporary variables buf to acpi_coresight_parse_graph(), and free it before the function return to prevent memory leak.

CVE-2023-53367:

        In the Linux kernel, the following vulnerability has been resolved:  accel/habanalabs: fix mem leak in capture user mappings  This commit fixes a memory leak caused when clearing the user_mappings info when a new context is opened immediately after user_mapping is captured and a hard reset is performed.

CVE-2023-53394:

        In the Linux kernel, the following vulnerability has been resolved:  net/mlx5e: xsk: Fix crash on regular rq reactivation  When the regular rq is reactivated after the XSK socket is closed it could be reading stale cqes which eventually corrupts the rq. This leads to no more traffic being received on the regular rq and a crash on the next close or deactivation of the rq.  Kal Cuttler Conely reported this issue as a crash on the release path when the xdpsock sample program is stopped (killed) and restarted in sequence while traffic is running.  This patch flushes all cqes when during the rq flush. The cqe flushing is done in the reset state of the rq. mlx5e_rq_to_ready code is moved into the flush function to allow for this.

CVE-2023-53447:

        In the Linux kernel, the following vulnerability has been resolved:  f2fs: don't reset unchangable mount option in f2fs_remount()  syzbot reports a bug as below:  general protection fault, probably for non-canonical address 0xdffffc0000000009: 0000 [#1] PREEMPT SMP KASAN RIP: 0010:__lock_acquire+0x69/0x2000 kernel/locking/lockdep.c:4942 Call Trace:  lock_acquire+0x1e3/0x520 kernel/locking/lockdep.c:5691  __raw_write_lock include/linux/rwlock_api_smp.h:209 [inline]  _raw_write_lock+0x2e/0x40 kernel/locking/spinlock.c:300  __drop_extent_tree+0x3ac/0x660 fs/f2fs/extent_cache.c:1100  f2fs_drop_extent_tree+0x17/0x30 fs/f2fs/extent_cache.c:1116  f2fs_insert_range+0x2d5/0x3c0 fs/f2fs/file.c:1664  f2fs_fallocate+0x4e4/0x6d0 fs/f2fs/file.c:1838  vfs_fallocate+0x54b/0x6b0 fs/open.c:324  ksys_fallocate fs/open.c:347 [inline]  __do_sys_fallocate fs/open.c:355 [inline]  __se_sys_fallocate fs/open.c:353 [inline]  __x64_sys_fallocate+0xbd/0x100 fs/open.c:353  do_syscall_x64 arch/x86/entry/common.c:50 [inline]  do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80  entry_SYSCALL_64_after_hwframe+0x63/0xcd  The root cause is race condition as below: - since it tries to remount rw filesystem, so that do_remount won't call sb_prepare_remount_readonly to block fallocate, there may be race condition in between remount and fallocate. - in f2fs_remount(), default_options() will reset mount option to default one, and then update it based on result of parse_options(), so there is a hole which race condition can happen.  Thread A			Thread B - f2fs_fill_super  - parse_options   - clear_opt(READ_EXTENT_CACHE)  - f2fs_remount  - default_options   - set_opt(READ_EXTENT_CACHE) 				- f2fs_fallocate 				 - f2fs_insert_range 				  - f2fs_drop_extent_tree 				   - __drop_extent_tree 				    - __may_extent_tree 				     - test_opt(READ_EXTENT_CACHE) return true 				    - write_lock(&et->lock) access NULL pointer  - parse_options   - clear_opt(READ_EXTENT_CACHE)

CVE-2023-53460:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: rtw88: fix memory leak in rtw_usb_probe()  drivers/net/wireless/realtek/rtw88/usb.c:876 rtw_usb_probe() warn: 'hw' from ieee80211_alloc_hw() not released on lines: 811  Fix this by modifying return to a goto statement.

CVE-2023-53523:

        In the Linux kernel, the following vulnerability has been resolved:  can: gs_usb: fix time stamp counter initialization  If the gs_usb device driver is unloaded (or unbound) before the interface is shut down, the USB stack first calls the struct usb_driver::disconnect and then the struct net_device_ops::ndo_stop callback.  In gs_usb_disconnect() all pending bulk URBs are killed, i.e. no more RX'ed CAN frames are send from the USB device to the host. Later in gs_can_close() a reset control message is send to each CAN channel to remove the controller from the CAN bus. In this race window the USB device can still receive CAN frames from the bus and internally queue them to be send to the host.  At least in the current version of the candlelight firmware, the queue of received CAN frames is not emptied during the reset command. After loading (or binding) the gs_usb driver, new URBs are submitted during the struct net_device_ops::ndo_open callback and the candlelight firmware starts sending its already queued CAN frames to the host.  However, this scenario was not considered when implementing the hardware timestamp function. The cycle counter/time counter infrastructure is set up (gs_usb_timestamp_init()) after the USBs are submitted, resulting in a NULL pointer dereference if timecounter_cyc2time() (via the call chain: gs_usb_receive_bulk_callback() -> gs_usb_set_timestamp() -> gs_usb_skb_set_timestamp()) is called too early.  Move the gs_usb_timestamp_init() function before the URBs are submitted to fix this problem.  For a comprehensive solution, we need to consider gs_usb devices with more than 1 channel. The cycle counter/time counter infrastructure is setup per channel, but the RX URBs are per device. Once gs_can_open() of _a_ channel has been called, and URBs have been submitted, the gs_usb_receive_bulk_callback() can be called for _all_ available channels, even for channels that are not running, yet. As cycle counter/time counter has not set up, this will again lead to a NULL pointer dereference.  Convert the cycle counter/time counter from a "per channel" to a "per device" functionality. Also set it up, before submitting any URBs to the device.  Further in gs_usb_receive_bulk_callback(), don't process any URBs for not started CAN channels, only resubmit the URB.

CVE-2023-53529:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: rtw88: Fix memory leak in rtw88_usb  Kmemleak shows the following leak arising from routine in the usb probe routine:  unreferenced object 0xffff895cb29bba00 (size 512):   comm "(udev-worker)", pid 534, jiffies 4294903932 (age 102751.088s)   hex dump (first 32 bytes):     77 30 30 30 00 00 00 00 02 2f 2d 2b 30 00 00 00  w000...../-+0...     02 00 2a 28 00 00 00 00 ff 55 ff ff ff 00 00 00  ..*(.....U......   backtrace:     [<ffffffff9265fa36>] kmalloc_trace+0x26/0x90     [<ffffffffc17eec41>] rtw_usb_probe+0x2f1/0x680 [rtw_usb]     [<ffffffffc03e19fd>] usb_probe_interface+0xdd/0x2e0 [usbcore]     [<ffffffff92b4f2fe>] really_probe+0x18e/0x3d0     [<ffffffff92b4f5b8>] __driver_probe_device+0x78/0x160     [<ffffffff92b4f6bf>] driver_probe_device+0x1f/0x90     [<ffffffff92b4f8df>] __driver_attach+0xbf/0x1b0     [<ffffffff92b4d350>] bus_for_each_dev+0x70/0xc0     [<ffffffff92b4e51e>] bus_add_driver+0x10e/0x210     [<ffffffff92b50935>] driver_register+0x55/0xf0     [<ffffffffc03e0708>] usb_register_driver+0x88/0x140 [usbcore]     [<ffffffff92401153>] do_one_initcall+0x43/0x210     [<ffffffff9254f42a>] do_init_module+0x4a/0x200     [<ffffffff92551d1c>] __do_sys_finit_module+0xac/0x120     [<ffffffff92ee6626>] do_syscall_64+0x56/0x80     [<ffffffff9300006a>] entry_SYSCALL_64_after_hwframe+0x46/0xb0  The leak was verified to be real by unloading the driver, which resulted in a dangling pointer to the allocation.  The allocated memory is freed in rtw_usb_intf_deinit().

CVE-2023-53781:

        In the Linux kernel, the following vulnerability has been resolved:  smc: Fix use-after-free in tcp_write_timer_handler().  With Eric's ref tracker, syzbot finally found a repro for use-after-free in tcp_write_timer_handler() by kernel TCP sockets. [0]  If SMC creates a kernel socket in __smc_create(), the kernel socket is supposed to be freed in smc_clcsock_release() by calling sock_release() when we close() the parent SMC socket.  However, at the end of smc_clcsock_release(), the kernel socket's sk_state might not be TCP_CLOSE.  This means that we have not called inet_csk_destroy_sock() in __tcp_close() and have not stopped the TCP timers.  The kernel socket's TCP timers can be fired later, so we need to hold a refcnt for net as we do for MPTCP subflows in mptcp_subflow_create_socket().  [0]: leaked reference.  sk_alloc (./include/net/net_namespace.h:335 net/core/sock.c:2108)  inet_create (net/ipv4/af_inet.c:319 net/ipv4/af_inet.c:244)  __sock_create (net/socket.c:1546)  smc_create (net/smc/af_smc.c:3269 net/smc/af_smc.c:3284)  __sock_create (net/socket.c:1546)  __sys_socket (net/socket.c:1634 net/socket.c:1618 net/socket.c:1661)  __x64_sys_socket (net/socket.c:1672)  do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)  entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120) ================================================================== BUG: KASAN: slab-use-after-free in tcp_write_timer_handler (net/ipv4/tcp_timer.c:378 net/ipv4/tcp_timer.c:624 net/ipv4/tcp_timer.c:594) Read of size 1 at addr ffff888052b65e0d by task syzrepro/18091  CPU: 0 PID: 18091 Comm: syzrepro Tainted: G        W          6.3.0-rc4-01174-gb5d54eb5899a #7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.amzn2022.0.1 04/01/2014 Call Trace:  <IRQ>  dump_stack_lvl (lib/dump_stack.c:107)  print_report (mm/kasan/report.c:320 mm/kasan/report.c:430)  kasan_report (mm/kasan/report.c:538)  tcp_write_timer_handler (net/ipv4/tcp_timer.c:378 net/ipv4/tcp_timer.c:624 net/ipv4/tcp_timer.c:594)  tcp_write_timer (./include/linux/spinlock.h:390 net/ipv4/tcp_timer.c:643)  call_timer_fn (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/timer.h:127 kernel/time/timer.c:1701)  __run_timers.part.0 (kernel/time/timer.c:1752 kernel/time/timer.c:2022)  run_timer_softirq (kernel/time/timer.c:2037)  __do_softirq (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/irq.h:142 kernel/softirq.c:572)  __irq_exit_rcu (kernel/softirq.c:445 kernel/softirq.c:650)  irq_exit_rcu (kernel/softirq.c:664)  sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1107 (discriminator 14))  </IRQ>

CVE-2023-53823:

        In the Linux kernel, the following vulnerability has been resolved:  block/rq_qos: protect rq_qos apis with a new lock  commit 50e34d78815e ("block: disable the elevator int del_gendisk") move rq_qos_exit() from disk_release() to del_gendisk(), this will introduce some problems:  1) If rq_qos_add() is triggered by enabling iocost/iolatency through    cgroupfs, then it can concurrent with del_gendisk(), it's not safe to    write 'q->rq_qos' concurrently.  2) Activate cgroup policy that is relied on rq_qos will call    rq_qos_add() and blkcg_activate_policy(), and if rq_qos_exit() is    called in the middle, null-ptr-dereference will be triggered in    blkcg_activate_policy().  3) blkg_conf_open_bdev() can call blkdev_get_no_open() first to find the    disk, then if rq_qos_exit() from del_gendisk() is done before    rq_qos_add(), then memory will be leaked.  This patch add a new disk level mutex 'rq_qos_mutex':  1) The lock will protect rq_qos_exit() directly.  2) For wbt that doesn't relied on blk-cgroup, rq_qos_add() can only be    called from disk initialization for now because wbt can't be    destructed until rq_qos_exit(), so it's safe not to protect wbt for    now. Hoever, in case that rq_qos dynamically destruction is supported    in the furture, this patch also protect rq_qos_add() from wbt_init()    directly, this is enough because blk-sysfs already synchronize    writers with disk removal.  3) For iocost and iolatency, in order to synchronize disk removal and    cgroup configuration, the lock is held after blkdev_get_no_open()    from blkg_conf_open_bdev(), and is released in blkg_conf_exit().    In order to fix the above memory leak, disk_live() is checked after    holding the new lock.

CVE-2023-53846:

        In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to do sanity check on direct node in truncate_dnode()  syzbot reports below bug:  BUG: KASAN: slab-use-after-free in f2fs_truncate_data_blocks_range+0x122a/0x14c0 fs/f2fs/file.c:574 Read of size 4 at addr ffff88802a25c000 by task syz-executor148/5000  CPU: 1 PID: 5000 Comm: syz-executor148 Not tainted 6.4.0-rc7-syzkaller-00041-ge660abd551f1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023 Call Trace:  <TASK>  __dump_stack lib/dump_stack.c:88 [inline]  dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106  print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351  print_report mm/kasan/report.c:462 [inline]  kasan_report+0x11c/0x130 mm/kasan/report.c:572  f2fs_truncate_data_blocks_range+0x122a/0x14c0 fs/f2fs/file.c:574  truncate_dnode+0x229/0x2e0 fs/f2fs/node.c:944  f2fs_truncate_inode_blocks+0x64b/0xde0 fs/f2fs/node.c:1154  f2fs_do_truncate_blocks+0x4ac/0xf30 fs/f2fs/file.c:721  f2fs_truncate_blocks+0x7b/0x300 fs/f2fs/file.c:749  f2fs_truncate.part.0+0x4a5/0x630 fs/f2fs/file.c:799  f2fs_truncate include/linux/fs.h:825 [inline]  f2fs_setattr+0x1738/0x2090 fs/f2fs/file.c:1006  notify_change+0xb2c/0x1180 fs/attr.c:483  do_truncate+0x143/0x200 fs/open.c:66  handle_truncate fs/namei.c:3295 [inline]  do_open fs/namei.c:3640 [inline]  path_openat+0x2083/0x2750 fs/namei.c:3791  do_filp_open+0x1ba/0x410 fs/namei.c:3818  do_sys_openat2+0x16d/0x4c0 fs/open.c:1356  do_sys_open fs/open.c:1372 [inline]  __do_sys_creat fs/open.c:1448 [inline]  __se_sys_creat fs/open.c:1442 [inline]  __x64_sys_creat+0xcd/0x120 fs/open.c:1442  do_syscall_x64 arch/x86/entry/common.c:50 [inline]  do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80  entry_SYSCALL_64_after_hwframe+0x63/0xcd  The root cause is, inodeA references inodeB via inodeB's ino, once inodeA is truncated, it calls truncate_dnode() to truncate data blocks in inodeB's node page, it traverse mapping data from node->i.i_addr[0] to node->i.i_addr[ADDRS_PER_BLOCK() - 1], result in out-of-boundary access.  This patch fixes to add sanity check on dnode page in truncate_dnode(), so that, it can help to avoid triggering such issue, and once it encounters such issue, it will record newly introduced ERROR_INVALID_NODE_REFERENCE error into superblock, later fsck can detect such issue and try repairing.  Also, it removes f2fs_truncate_data_blocks() for cleanup due to the function has only one caller, and uses f2fs_truncate_data_blocks_range() instead.

CVE-2023-54013:

        In the Linux kernel, the following vulnerability has been resolved:  interconnect: Fix locking for runpm vs reclaim  For cases where icc_bw_set() can be called in callbaths that could deadlock against shrinker/reclaim, such as runpm resume, we need to decouple the icc locking.  Introduce a new icc_bw_lock for cases where we need to serialize bw aggregation and update to decouple that from paths that require memory allocation such as node/link creation/ destruction.  Fixes this lockdep splat:     ======================================================    WARNING: possible circular locking dependency detected    6.2.0-rc8-debug+ #554 Not tainted    ------------------------------------------------------    ring0/132 is trying to acquire lock:    ffffff80871916d0 (&gmu->lock){+.+.}-{3:3}, at: a6xx_pm_resume+0xf0/0x234     but task is already holding lock:    ffffffdb5aee57e8 (dma_fence_map){++++}-{0:0}, at: msm_job_run+0x68/0x150     which lock already depends on the new lock.     the existing dependency chain (in reverse order) is:     -> #4 (dma_fence_map){++++}-{0:0}:           __dma_fence_might_wait+0x74/0xc0           dma_resv_lockdep+0x1f4/0x2f4           do_one_initcall+0x104/0x2bc           kernel_init_freeable+0x344/0x34c           kernel_init+0x30/0x134           ret_from_fork+0x10/0x20     -> #3 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}:           fs_reclaim_acquire+0x80/0xa8           slab_pre_alloc_hook.constprop.0+0x40/0x25c           __kmem_cache_alloc_node+0x60/0x1cc           __kmalloc+0xd8/0x100           topology_parse_cpu_capacity+0x8c/0x178           get_cpu_for_node+0x88/0xc4           parse_cluster+0x1b0/0x28c           parse_cluster+0x8c/0x28c           init_cpu_topology+0x168/0x188           smp_prepare_cpus+0x24/0xf8           kernel_init_freeable+0x18c/0x34c           kernel_init+0x30/0x134           ret_from_fork+0x10/0x20     -> #2 (fs_reclaim){+.+.}-{0:0}:           __fs_reclaim_acquire+0x3c/0x48           fs_reclaim_acquire+0x54/0xa8           slab_pre_alloc_hook.constprop.0+0x40/0x25c           __kmem_cache_alloc_node+0x60/0x1cc           __kmalloc+0xd8/0x100           kzalloc.constprop.0+0x14/0x20           icc_node_create_nolock+0x4c/0xc4           icc_node_create+0x38/0x58           qcom_icc_rpmh_probe+0x1b8/0x248           platform_probe+0x70/0xc4           really_probe+0x158/0x290           __driver_probe_device+0xc8/0xe0           driver_probe_device+0x44/0x100           __driver_attach+0xf8/0x108           bus_for_each_dev+0x78/0xc4           driver_attach+0x2c/0x38           bus_add_driver+0xd0/0x1d8           driver_register+0xbc/0xf8           __platform_driver_register+0x30/0x3c           qnoc_driver_init+0x24/0x30           do_one_initcall+0x104/0x2bc           kernel_init_freeable+0x344/0x34c           kernel_init+0x30/0x134           ret_from_fork+0x10/0x20     -> #1 (icc_lock){+.+.}-{3:3}:           __mutex_lock+0xcc/0x3c8           mutex_lock_nested+0x30/0x44           icc_set_bw+0x88/0x2b4           _set_opp_bw+0x8c/0xd8           _set_opp+0x19c/0x300           dev_pm_opp_set_opp+0x84/0x94           a6xx_gmu_resume+0x18c/0x804           a6xx_pm_resume+0xf8/0x234           adreno_runtime_resume+0x2c/0x38           pm_generic_runtime_resume+0x30/0x44           __rpm_callback+0x15c/0x174           rpm_callback+0x78/0x7c           rpm_resume+0x318/0x524           __pm_runtime_resume+0x78/0xbc           adreno_load_gpu+0xc4/0x17c           msm_open+0x50/0x120           drm_file_alloc+0x17c/0x228           drm_open_helper+0x74/0x118           drm_open+0xa0/0x144           drm_stub_open+0xd4/0xe4           chrdev_open+0x1b8/0x1e4           do_dentry_open+0x2f8/0x38c           vfs_open+0x34/0x40           path_openat+0x64c/0x7b4           do_filp_open+0x54/0xc4           do_sys_openat2+0x9c/0x100           do_sys_open+0x50/0x7c           __arm64_sys_openat+0x28/0x34           invoke_syscall+0x8c/0x128           el0_svc_common.constprop.0+0xa0/0x11c           do_el0_ ---truncated---

CVE-2023-54030:

        In the Linux kernel, the following vulnerability has been resolved:  io_uring/net: don't overflow multishot recv  Don't allow overflowing multishot recv CQEs, it might get out of hand, hurt performance, and in the worst case scenario OOM the task.

CVE-2023-54088:

        In the Linux kernel, the following vulnerability has been resolved:  blk-cgroup: hold queue_lock when removing blkg->q_node  When blkg is removed from q->blkg_list from blkg_free_workfn(), queue_lock has to be held, otherwise, all kinds of bugs(list corruption, hard lockup, ..) can be triggered from blkg_destroy_all().

CVE-2023-54107:

        In the Linux kernel, the following vulnerability has been resolved:  blk-cgroup: dropping parent refcount after pd_free_fn() is done  Some cgroup policies will access parent pd through child pd even after pd_offline_fn() is done. If pd_free_fn() for parent is called before child, then UAF can be triggered. Hence it's better to guarantee the order of pd_free_fn().  Currently refcount of parent blkg is dropped in __blkg_release(), which is before pd_free_fn() is called in blkg_free_work_fn() while blkg_free_work_fn() is called asynchronously.  This patch make sure pd_free_fn() called from removing cgroup is ordered by delaying dropping parent refcount after calling pd_free_fn() for child.  BTW, pd_free_fn() will also be called from blkcg_deactivate_policy() from deleting device, and following patches will guarantee the order.

CVE-2023-54280:

        In the Linux kernel, the following vulnerability has been resolved:  cifs: fix potential race when tree connecting ipc  Protect access of TCP_Server_Info::hostname when building the ipc tree name as it might get freed in cifsd thread and thus causing an use-after-free bug in __tree_connect_dfs_target().  Also, while at it, update status of IPC tcon on success and then avoid any extra tree connects.

CVE-2024-14040:

        In the Linux kernel, the following vulnerability has been resolved:  net: nexthop: Increase weight to u16  In CLOS networks, as link failures occur at various points in the network, ECMP weights of the involved nodes are adjusted to compensate. With high fan-out of the involved nodes, and overall high number of nodes, a (non-)ECMP weight ratio that we would like to configure does not fit into 8 bits. Instead of, say, 255:254, we might like to configure something like 1000:999. For these deployments, the 8-bit weight may not be enough.  To that end, in this patch increase the next hop weight from u8 to u16.  Increasing the width of an integral type can be tricky, because while the code still compiles, the types may not check out anymore, and numerical errors come up. To prevent this, the conversion was done in two steps. First the type was changed from u8 to a single-member structure, which invalidated all uses of the field. This allowed going through them one by one and audit for type correctness. Then the structure was replaced with a vanilla u16 again. This should ensure that no place was missed.  The UAPI for configuring nexthop group members is that an attribute NHA_GROUP carries an array of struct nexthop_grp entries:  	struct nexthop_grp { 		__u32	id;	  /* nexthop id - must exist */ 		__u8	weight;   /* weight of this nexthop */ 		__u8	resvd1; 		__u16	resvd2; 	};  The field resvd1 is currently validated and required to be zero. We can lift this requirement and carry high-order bits of the weight in the reserved field:  	struct nexthop_grp { 		__u32	id;	  /* nexthop id - must exist */ 		__u8	weight;   /* weight of this nexthop */ 		__u8	weight_high; 		__u16	resvd2; 	};  Keeping the fields split this way was chosen in case an existing userspace makes assumptions about the width of the weight field, and to sidestep any endianness issues.  The weight field is currently encoded as the weight value minus one, because weight of 0 is invalid. This same trick is impossible for the new weight_high field, because zero must mean actual zero. With this in place:  - Old userspace is guaranteed to carry weight_high of 0, therefore   configuring 8-bit weights as appropriate. When dumping nexthops with   16-bit weight, it would only show the lower 8 bits. But configuring such   nexthops implies existence of userspace aware of the extension in the   first place.  - New userspace talking to an old kernel will work as long as it only   attempts to configure 8-bit weights, where the high-order bits are zero.   Old kernel will bounce attempts at configuring >8-bit weights.  Renaming reserved fields as they are allocated for some purpose is commonly done in Linux. Whoever touches a reserved field is doing so at their own risk. nexthop_grp::resvd1 in particular is currently used by at least strace, however they carry an own copy of UAPI headers, and the conversion should be trivial. A helper is provided for decoding the weight out of the two fields. Forcing a conversion seems preferable to bending backwards and introducing anonymous unions or whatever.

CVE-2024-21803:

        Use After Free vulnerability in Linux Linux kernel kernel on Linux, x86, ARM (bluetooth modules) allows Local Execution of Code. This vulnerability is associated with program files https://gitee.Com/anolis/cloud-kernel/blob/devel-5.10/net/bluetooth/af_bluetooth.C.  This issue affects Linux kernel: from v2.6.12-rc2 before v6.8-rc1.

CVE-2024-24864:

        A race condition was found in the Linux kernel's media/dvb-core in dvbdmx_write() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.

CVE-2024-25740:

        A memory leak flaw was found in the UBI driver in drivers/mtd/ubi/attach.c in the Linux kernel through 6.7.4 for UBI_IOCATT, because kobj->name is not released.

CVE-2024-25742:

        In the Linux kernel before 6.9, an untrusted hypervisor can inject virtual interrupt 29 (#VC) at any point in time and can trigger its handler. This affects AMD SEV-SNP and AMD SEV-ES.

CVE-2024-25743:

        In the Linux kernel through 6.9, an untrusted hypervisor can inject virtual interrupts 0 and 14 at any point in time and can trigger the SIGFPE signal handler in userspace applications. This affects AMD SEV-SNP and AMD SEV-ES.

CVE-2024-26661:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Add NULL test for 'timing generator' in 'dcn21_set_pipe()'  In "u32 otg_inst = pipe_ctx->stream_res.tg->inst;" pipe_ctx->stream_res.tg could be NULL, it is relying on the caller to ensure the tg is not NULL.

CVE-2024-26662:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Fix 'panel_cntl' could be null in 'dcn21_set_backlight_level()'  'panel_cntl' structure used to control the display panel could be null, dereferencing it could lead to a null pointer access.  Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn21/dcn21_hwseq.c:269 dcn21_set_backlight_level() error: we previously assumed 'panel_cntl' could be null (see line 250)

CVE-2024-26669:

        In the Linux kernel, the following vulnerability has been resolved:  net/sched: flower: Fix chain template offload  When a qdisc is deleted from a net device the stack instructs the underlying driver to remove its flow offload callback from the associated filter block using the 'FLOW_BLOCK_UNBIND' command. The stack then continues to replay the removal of the filters in the block for this driver by iterating over the chains in the block and invoking the 'reoffload' operation of the classifier being used. In turn, the classifier in its 'reoffload' operation prepares and emits a 'FLOW_CLS_DESTROY' command for each filter.  However, the stack does not do the same for chain templates and the underlying driver never receives a 'FLOW_CLS_TMPLT_DESTROY' command when a qdisc is deleted. This results in a memory leak [1] which can be reproduced using [2].  Fix by introducing a 'tmplt_reoffload' operation and have the stack invoke it with the appropriate arguments as part of the replay. Implement the operation in the sole classifier that supports chain templates (flower) by emitting the 'FLOW_CLS_TMPLT_{CREATE,DESTROY}' command based on whether a flow offload callback is being bound to a filter block or being unbound from one.  As far as I can tell, the issue happens since cited commit which reordered tcf_block_offload_unbind() before tcf_block_flush_all_chains() in __tcf_block_put(). The order cannot be reversed as the filter block is expected to be freed after flushing all the chains.  [1] unreferenced object 0xffff888107e28800 (size 2048):   comm "tc", pid 1079, jiffies 4294958525 (age 3074.287s)   hex dump (first 32 bytes):     b1 a6 7c 11 81 88 ff ff e0 5b b3 10 81 88 ff ff  ..|......[......     01 00 00 00 00 00 00 00 e0 aa b0 84 ff ff ff ff  ................   backtrace:     [<ffffffff81c06a68>] __kmem_cache_alloc_node+0x1e8/0x320     [<ffffffff81ab374e>] __kmalloc+0x4e/0x90     [<ffffffff832aec6d>] mlxsw_sp_acl_ruleset_get+0x34d/0x7a0     [<ffffffff832bc195>] mlxsw_sp_flower_tmplt_create+0x145/0x180     [<ffffffff832b2e1a>] mlxsw_sp_flow_block_cb+0x1ea/0x280     [<ffffffff83a10613>] tc_setup_cb_call+0x183/0x340     [<ffffffff83a9f85a>] fl_tmplt_create+0x3da/0x4c0     [<ffffffff83a22435>] tc_ctl_chain+0xa15/0x1170     [<ffffffff838a863c>] rtnetlink_rcv_msg+0x3cc/0xed0     [<ffffffff83ac87f0>] netlink_rcv_skb+0x170/0x440     [<ffffffff83ac6270>] netlink_unicast+0x540/0x820     [<ffffffff83ac6e28>] netlink_sendmsg+0x8d8/0xda0     [<ffffffff83793def>] ____sys_sendmsg+0x30f/0xa80     [<ffffffff8379d29a>] ___sys_sendmsg+0x13a/0x1e0     [<ffffffff8379d50c>] __sys_sendmsg+0x11c/0x1f0     [<ffffffff843b9ce0>] do_syscall_64+0x40/0xe0 unreferenced object 0xffff88816d2c0400 (size 1024):   comm "tc", pid 1079, jiffies 4294958525 (age 3074.287s)   hex dump (first 32 bytes):     40 00 00 00 00 00 00 00 57 f6 38 be 00 00 00 00  @.......W.8.....     10 04 2c 6d 81 88 ff ff 10 04 2c 6d 81 88 ff ff  ..,m......,m....   backtrace:     [<ffffffff81c06a68>] __kmem_cache_alloc_node+0x1e8/0x320     [<ffffffff81ab36c1>] __kmalloc_node+0x51/0x90     [<ffffffff81a8ed96>] kvmalloc_node+0xa6/0x1f0     [<ffffffff82827d03>] bucket_table_alloc.isra.0+0x83/0x460     [<ffffffff82828d2b>] rhashtable_init+0x43b/0x7c0     [<ffffffff832aed48>] mlxsw_sp_acl_ruleset_get+0x428/0x7a0     [<ffffffff832bc195>] mlxsw_sp_flower_tmplt_create+0x145/0x180     [<ffffffff832b2e1a>] mlxsw_sp_flow_block_cb+0x1ea/0x280     [<ffffffff83a10613>] tc_setup_cb_call+0x183/0x340     [<ffffffff83a9f85a>] fl_tmplt_create+0x3da/0x4c0     [<ffffffff83a22435>] tc_ctl_chain+0xa15/0x1170     [<ffffffff838a863c>] rtnetlink_rcv_msg+0x3cc/0xed0     [<ffffffff83ac87f0>] netlink_rcv_skb+0x170/0x440     [<ffffffff83ac6270>] netlink_unicast+0x540/0x820     [<ffffffff83ac6e28>] netlink_sendmsg+0x8d8/0xda0     [<ffffffff83793def>] ____sys_sendmsg+0x30f/0xa80  [2]  # tc qdisc add dev swp1 clsact  # tc chain add dev swp1 ingress proto ip chain 1 flower dst_ip 0.0.0.0/32  # tc qdisc del dev ---truncated---

CVE-2024-26670:

        In the Linux kernel, the following vulnerability has been resolved:  arm64: entry: fix ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD  Currently the ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD workaround isn't quite right, as it is supposed to be applied after the last explicit memory access, but is immediately followed by an LDR.  The ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD workaround is used to handle Cortex-A520 erratum 2966298 and Cortex-A510 erratum 3117295, which are described in:  * https://developer.arm.com/documentation/SDEN2444153/0600/?lang=en * https://developer.arm.com/documentation/SDEN1873361/1600/?lang=en  In both cases the workaround is described as:  | If pagetable isolation is disabled, the context switch logic in the | kernel can be updated to execute the following sequence on affected | cores before exiting to EL0, and after all explicit memory accesses: | | 1. A non-shareable TLBI to any context and/or address, including |    unused contexts or addresses, such as a `TLBI VALE1 Xzr`. | | 2. A DSB NSH to guarantee completion of the TLBI.  The important part being that the TLBI+DSB must be placed "after all explicit memory accesses".  Unfortunately, as-implemented, the TLBI+DSB is immediately followed by an LDR, as we have:  | alternative_if ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD | 	tlbi	vale1, xzr | 	dsb	nsh | alternative_else_nop_endif | alternative_if_not ARM64_UNMAP_KERNEL_AT_EL0 | 	ldr	lr, [sp, #S_LR] | 	add	sp, sp, #PT_REGS_SIZE		// restore sp | 	eret | alternative_else_nop_endif | | [ ... KPTI exception return path ... ]  This patch fixes this by reworking the logic to place the TLBI+DSB immediately before the ERET, after all explicit memory accesses.  The ERET is currently in a separate alternative block, and alternatives cannot be nested. To account for this, the alternative block for ARM64_UNMAP_KERNEL_AT_EL0 is replaced with a single alternative branch to skip the KPTI logic, with the new shape of the logic being:  | alternative_insn "b .L_skip_tramp_exit_\@", nop, ARM64_UNMAP_KERNEL_AT_EL0 | 	[ ... KPTI exception return path ... ] | .L_skip_tramp_exit_\@: | | 	ldr	lr, [sp, #S_LR] | 	add	sp, sp, #PT_REGS_SIZE		// restore sp | | alternative_if ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD | 	tlbi	vale1, xzr | 	dsb	nsh | alternative_else_nop_endif | 	eret  The new structure means that the workaround is only applied when KPTI is not in use; this is fine as noted in the documented implications of the erratum:  | Pagetable isolation between EL0 and higher level ELs prevents the | issue from occurring.  ... and as per the workaround description quoted above, the workaround is only necessary "If pagetable isolation is disabled".

CVE-2024-26672:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu: Fix variable 'mca_funcs' dereferenced before NULL check in 'amdgpu_mca_smu_get_mca_entry()'  Fixes the below:  drivers/gpu/drm/amd/amdgpu/amdgpu_mca.c:377 amdgpu_mca_smu_get_mca_entry() warn: variable dereferenced before check 'mca_funcs' (see line 368)  357 int amdgpu_mca_smu_get_mca_entry(struct amdgpu_device *adev, 				     enum amdgpu_mca_error_type type, 358                                  int idx, struct mca_bank_entry *entry) 359 { 360         const struct amdgpu_mca_smu_funcs *mca_funcs = 						adev->mca.mca_funcs; 361         int count; 362 363         switch (type) { 364         case AMDGPU_MCA_ERROR_TYPE_UE: 365                 count = mca_funcs->max_ue_count;  mca_funcs is dereferenced here.  366                 break; 367         case AMDGPU_MCA_ERROR_TYPE_CE: 368                 count = mca_funcs->max_ce_count;  mca_funcs is dereferenced here.  369                 break; 370         default: 371                 return -EINVAL; 372         } 373 374         if (idx >= count) 375                 return -EINVAL; 376 377         if (mca_funcs && mca_funcs->mca_get_mca_entry) 	        ^^^^^^^^^  Checked too late!

CVE-2024-26677:

        In the Linux kernel, the following vulnerability has been resolved:  rxrpc: Fix delayed ACKs to not set the reference serial number  Fix the construction of delayed ACKs to not set the reference serial number as they can't be used as an RTT reference.

CVE-2024-26691:

        In the Linux kernel, the following vulnerability has been resolved:  KVM: arm64: Fix circular locking dependency  The rule inside kvm enforces that the vcpu->mutex is taken *inside* kvm->lock. The rule is violated by the pkvm_create_hyp_vm() which acquires the kvm->lock while already holding the vcpu->mutex lock from kvm_vcpu_ioctl(). Avoid the circular locking dependency altogether by protecting the hyp vm handle with the config_lock, much like we already do for other forms of VM-scoped data.

CVE-2024-26740:

        In the Linux kernel, the following vulnerability has been resolved:  net/sched: act_mirred: use the backlog for mirred ingress  The test Davide added in commit ca22da2fbd69 ("act_mirred: use the backlog for nested calls to mirred ingress") hangs our testing VMs every 10 or so runs, with the familiar tcp_v4_rcv -> tcp_v4_rcv deadlock reported by lockdep.  The problem as previously described by Davide (see Link) is that if we reverse flow of traffic with the redirect (egress -> ingress) we may reach the same socket which generated the packet. And we may still be holding its socket lock. The common solution to such deadlocks is to put the packet in the Rx backlog, rather than run the Rx path inline. Do that for all egress -> ingress reversals, not just once we started to nest mirred calls.  In the past there was a concern that the backlog indirection will lead to loss of error reporting / less accurate stats. But the current workaround does not seem to address the issue.

CVE-2024-26756:

        In the Linux kernel, the following vulnerability has been resolved:  md: Don't register sync_thread for reshape directly  Currently, if reshape is interrupted, then reassemble the array will register sync_thread directly from pers->run(), in this case 'MD_RECOVERY_RUNNING' is set directly, however, there is no guarantee that md_do_sync() will be executed, hence stop_sync_thread() will hang because 'MD_RECOVERY_RUNNING' can't be cleared.  Last patch make sure that md_do_sync() will set MD_RECOVERY_DONE, however, following hang can still be triggered by dm-raid test shell/lvconvert-raid-reshape.sh occasionally:  [root@fedora ~]# cat /proc/1982/stack [<0>] stop_sync_thread+0x1ab/0x270 [md_mod] [<0>] md_frozen_sync_thread+0x5c/0xa0 [md_mod] [<0>] raid_presuspend+0x1e/0x70 [dm_raid] [<0>] dm_table_presuspend_targets+0x40/0xb0 [dm_mod] [<0>] __dm_destroy+0x2a5/0x310 [dm_mod] [<0>] dm_destroy+0x16/0x30 [dm_mod] [<0>] dev_remove+0x165/0x290 [dm_mod] [<0>] ctl_ioctl+0x4bb/0x7b0 [dm_mod] [<0>] dm_ctl_ioctl+0x11/0x20 [dm_mod] [<0>] vfs_ioctl+0x21/0x60 [<0>] __x64_sys_ioctl+0xb9/0xe0 [<0>] do_syscall_64+0xc6/0x230 [<0>] entry_SYSCALL_64_after_hwframe+0x6c/0x74  Meanwhile mddev->recovery is: MD_RECOVERY_RUNNING | MD_RECOVERY_INTR | MD_RECOVERY_RESHAPE | MD_RECOVERY_FROZEN  Fix this problem by remove the code to register sync_thread directly from raid10 and raid5. And let md_check_recovery() to register sync_thread.

CVE-2024-26757:

        In the Linux kernel, the following vulnerability has been resolved:  md: Don't ignore read-only array in md_check_recovery()  Usually if the array is not read-write, md_check_recovery() won't register new sync_thread in the first place. And if the array is read-write and sync_thread is registered, md_set_readonly() will unregister sync_thread before setting the array read-only. md/raid follow this behavior hence there is no problem.  After commit f52f5c71f3d4 ("md: fix stopping sync thread"), following hang can be triggered by test shell/integrity-caching.sh:  1) array is read-only. dm-raid update super block: rs_update_sbs  ro = mddev->ro  mddev->ro = 0   -> set array read-write  md_update_sb  2) register new sync thread concurrently.  3) dm-raid set array back to read-only: rs_update_sbs  mddev->ro = ro  4) stop the array: raid_dtr  md_stop   stop_sync_thread     set_bit(MD_RECOVERY_INTR, &mddev->recovery);     md_wakeup_thread_directly(mddev->sync_thread);     wait_event(..., !test_bit(MD_RECOVERY_RUNNING, &mddev->recovery))  5) sync thread done:  md_do_sync  set_bit(MD_RECOVERY_DONE, &mddev->recovery);  md_wakeup_thread(mddev->thread);  6) daemon thread can't unregister sync thread:  md_check_recovery   if (!md_is_rdwr(mddev) &&       !test_bit(MD_RECOVERY_NEEDED, &mddev->recovery))    return;   -> -> MD_RECOVERY_RUNNING can't be cleared, hence step 4 hang;  The root cause is that dm-raid manipulate 'mddev->ro' by itself, however, dm-raid really should stop sync thread before setting the array read-only. Unfortunately, I need to read more code before I can refacter the handler of 'mddev->ro' in dm-raid, hence let's fix the problem the easy way for now to prevent dm-raid regression.

CVE-2024-26758:

        In the Linux kernel, the following vulnerability has been resolved:  md: Don't ignore suspended array in md_check_recovery()  mddev_suspend() never stop sync_thread, hence it doesn't make sense to ignore suspended array in md_check_recovery(), which might cause sync_thread can't be unregistered.  After commit f52f5c71f3d4 ("md: fix stopping sync thread"), following hang can be triggered by test shell/integrity-caching.sh:  1) suspend the array: raid_postsuspend  mddev_suspend  2) stop the array: raid_dtr  md_stop   __md_stop_writes    stop_sync_thread     set_bit(MD_RECOVERY_INTR, &mddev->recovery);     md_wakeup_thread_directly(mddev->sync_thread);     wait_event(..., !test_bit(MD_RECOVERY_RUNNING, &mddev->recovery))  3) sync thread done: md_do_sync  set_bit(MD_RECOVERY_DONE, &mddev->recovery);  md_wakeup_thread(mddev->thread);  4) daemon thread can't unregister sync thread: md_check_recovery  if (mddev->suspended)    return; -> return directly  md_read_sync_thread  clear_bit(MD_RECOVERY_RUNNING, &mddev->recovery);  -> MD_RECOVERY_RUNNING can't be cleared, hence step 2 hang;  This problem is not just related to dm-raid, fix it by ignoring suspended array in md_check_recovery(). And follow up patches will improve dm-raid better to frozen sync thread during suspend.

CVE-2024-26768:

        In the Linux kernel, the following vulnerability has been resolved:  LoongArch: Change acpi_core_pic[NR_CPUS] to acpi_core_pic[MAX_CORE_PIC]  With default config, the value of NR_CPUS is 64. When HW platform has more then 64 cpus, system will crash on these platforms. MAX_CORE_PIC is the maximum cpu number in MADT table (max physical number) which can exceed the supported maximum cpu number (NR_CPUS, max logical number), but kernel should not crash. Kernel should boot cpus with NR_CPUS, let the remainder cpus stay in BIOS.  The potential crash reason is that the array acpi_core_pic[NR_CPUS] can be overflowed when parsing MADT table, and it is obvious that CORE_PIC should be corresponding to physical core rather than logical core, so it is better to define the array as acpi_core_pic[MAX_CORE_PIC].  With the patch, system can boot up 64 vcpus with qemu parameter -smp 128, otherwise system will crash with the following message.  [    0.000000] CPU 0 Unable to handle kernel paging request at virtual address 0000420000004259, era == 90000000037a5f0c, ra == 90000000037a46ec [    0.000000] Oops[#1]: [    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.8.0-rc2+ #192 [    0.000000] Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022 [    0.000000] pc 90000000037a5f0c ra 90000000037a46ec tp 9000000003c90000 sp 9000000003c93d60 [    0.000000] a0 0000000000000019 a1 9000000003d93bc0 a2 0000000000000000 a3 9000000003c93bd8 [    0.000000] a4 9000000003c93a74 a5 9000000083c93a67 a6 9000000003c938f0 a7 0000000000000005 [    0.000000] t0 0000420000004201 t1 0000000000000000 t2 0000000000000001 t3 0000000000000001 [    0.000000] t4 0000000000000003 t5 0000000000000000 t6 0000000000000030 t7 0000000000000063 [    0.000000] t8 0000000000000014 u0 ffffffffffffffff s9 0000000000000000 s0 9000000003caee98 [    0.000000] s1 90000000041b0480 s2 9000000003c93da0 s3 9000000003c93d98 s4 9000000003c93d90 [    0.000000] s5 9000000003caa000 s6 000000000a7fd000 s7 000000000f556b60 s8 000000000e0a4330 [    0.000000]    ra: 90000000037a46ec platform_init+0x214/0x250 [    0.000000]   ERA: 90000000037a5f0c efi_runtime_init+0x30/0x94 [    0.000000]  CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) [    0.000000]  PRMD: 00000000 (PPLV0 -PIE -PWE) [    0.000000]  EUEN: 00000000 (-FPE -SXE -ASXE -BTE) [    0.000000]  ECFG: 00070800 (LIE=11 VS=7) [    0.000000] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0) [    0.000000]  BADV: 0000420000004259 [    0.000000]  PRID: 0014c010 (Loongson-64bit, Loongson-3A5000) [    0.000000] Modules linked in: [    0.000000] Process swapper (pid: 0, threadinfo=(____ptrval____), task=(____ptrval____)) [    0.000000] Stack : 9000000003c93a14 9000000003800898 90000000041844f8 90000000037a46ec [    0.000000]         000000000a7fd000 0000000008290000 0000000000000000 0000000000000000 [    0.000000]         0000000000000000 0000000000000000 00000000019d8000 000000000f556b60 [    0.000000]         000000000a7fd000 000000000f556b08 9000000003ca7700 9000000003800000 [    0.000000]         9000000003c93e50 9000000003800898 9000000003800108 90000000037a484c [    0.000000]         000000000e0a4330 000000000f556b60 000000000a7fd000 000000000f556b08 [    0.000000]         9000000003ca7700 9000000004184000 0000000000200000 000000000e02b018 [    0.000000]         000000000a7fd000 90000000037a0790 9000000003800108 0000000000000000 [    0.000000]         0000000000000000 000000000e0a4330 000000000f556b60 000000000a7fd000 [    0.000000]         000000000f556b08 000000000eaae298 000000000eaa5040 0000000000200000 [    0.000000]         ... [    0.000000] Call Trace: [    0.000000] [<90000000037a5f0c>] efi_runtime_init+0x30/0x94 [    0.000000] [<90000000037a46ec>] platform_init+0x214/0x250 [    0.000000] [<90000000037a484c>] setup_arch+0x124/0x45c [    0.000000] [<90000000037a0790>] start_kernel+0x90/0x670 [    0.000000] [<900000000378b0d8>] kernel_entry+0xd8/0xdc

CVE-2024-26799:

        In the Linux kernel, the following vulnerability has been resolved:  ASoC: qcom: Fix uninitialized pointer dmactl  In the case where __lpass_get_dmactl_handle is called and the driver id dai_id is invalid the pointer dmactl is not being assigned a value, and dmactl contains a garbage value since it has not been initialized and so the null check may not work. Fix this to initialize dmactl to NULL. One could argue that modern compilers will set this to zero, but it is useful to keep this initialized as per the same way in functions __lpass_platform_codec_intf_init and lpass_cdc_dma_daiops_hw_params.  Cleans up clang scan build warning: sound/soc/qcom/lpass-cdc-dma.c:275:7: warning: Branch condition evaluates to a garbage value [core.uninitialized.Branch]

CVE-2024-26836:

        In the Linux kernel, the following vulnerability has been resolved:  platform/x86: think-lmi: Fix password opcode ordering for workstations  The Lenovo workstations require the password opcode to be run before the attribute value is changed (if Admin password is enabled).  Tested on some Thinkpads to confirm they are OK with this order too.

CVE-2024-26841:

        In the Linux kernel, the following vulnerability has been resolved:  LoongArch: Update cpu_sibling_map when disabling nonboot CPUs  Update cpu_sibling_map when disabling nonboot CPUs by defining & calling clear_cpu_sibling_map(), otherwise we get such errors on SMT systems:  jump label: negative count! WARNING: CPU: 6 PID: 45 at kernel/jump_label.c:263 __static_key_slow_dec_cpuslocked+0xec/0x100 CPU: 6 PID: 45 Comm: cpuhp/6 Not tainted 6.8.0-rc5+ #1340 pc 90000000004c302c ra 90000000004c302c tp 90000001005bc000 sp 90000001005bfd20 a0 000000000000001b a1 900000000224c278 a2 90000001005bfb58 a3 900000000224c280 a4 900000000224c278 a5 90000001005bfb50 a6 0000000000000001 a7 0000000000000001 t0 ce87a4763eb5234a t1 ce87a4763eb5234a t2 0000000000000000 t3 0000000000000000 t4 0000000000000006 t5 0000000000000000 t6 0000000000000064 t7 0000000000001964 t8 000000000009ebf6 u0 9000000001f2a068 s9 0000000000000000 s0 900000000246a2d8 s1 ffffffffffffffff s2 ffffffffffffffff s3 90000000021518c0 s4 0000000000000040 s5 9000000002151058 s6 9000000009828e40 s7 00000000000000b4 s8 0000000000000006    ra: 90000000004c302c __static_key_slow_dec_cpuslocked+0xec/0x100   ERA: 90000000004c302c __static_key_slow_dec_cpuslocked+0xec/0x100  CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)  PRMD: 00000004 (PPLV0 +PIE -PWE)  EUEN: 00000000 (-FPE -SXE -ASXE -BTE)  ECFG: 00071c1c (LIE=2-4,10-12 VS=7) ESTAT: 000c0000 [BRK] (IS= ECode=12 EsubCode=0)  PRID: 0014d000 (Loongson-64bit, Loongson-3A6000-HV) CPU: 6 PID: 45 Comm: cpuhp/6 Not tainted 6.8.0-rc5+ #1340 Stack : 0000000000000000 900000000203f258 900000000179afc8 90000001005bc000         90000001005bf980 0000000000000000 90000001005bf988 9000000001fe0be0         900000000224c280 900000000224c278 90000001005bf8c0 0000000000000001         0000000000000001 ce87a4763eb5234a 0000000007f38000 90000001003f8cc0         0000000000000000 0000000000000006 0000000000000000 4c206e6f73676e6f         6f4c203a656d616e 000000000009ec99 0000000007f38000 0000000000000000         900000000214b000 9000000001fe0be0 0000000000000004 0000000000000000         0000000000000107 0000000000000009 ffffffffffafdabe 00000000000000b4         0000000000000006 90000000004c302c 9000000000224528 00005555939a0c7c         00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c         ... Call Trace: [<9000000000224528>] show_stack+0x48/0x1a0 [<900000000179afc8>] dump_stack_lvl+0x78/0xa0 [<9000000000263ed0>] __warn+0x90/0x1a0 [<90000000017419b8>] report_bug+0x1b8/0x280 [<900000000179c564>] do_bp+0x264/0x420 [<90000000004c302c>] __static_key_slow_dec_cpuslocked+0xec/0x100 [<90000000002b4d7c>] sched_cpu_deactivate+0x2fc/0x300 [<9000000000266498>] cpuhp_invoke_callback+0x178/0x8a0 [<9000000000267f70>] cpuhp_thread_fun+0xf0/0x240 [<90000000002a117c>] smpboot_thread_fn+0x1dc/0x2e0 [<900000000029a720>] kthread+0x140/0x160 [<9000000000222288>] ret_from_kernel_thread+0xc/0xa4

CVE-2024-26866:

        In the Linux kernel, the following vulnerability has been resolved:  spi: lpspi: Avoid potential use-after-free in probe()  fsl_lpspi_probe() is allocating/disposing memory manually with spi_alloc_host()/spi_alloc_target(), but uses devm_spi_register_controller(). In case of error after the latter call the memory will be explicitly freed in the probe function by spi_controller_put() call, but used afterwards by "devm" management outside probe() (spi_unregister_controller() <- devm_spi_unregister() below).  Unable to handle kernel NULL pointer dereference at virtual address 0000000000000070 ... Call trace:  kernfs_find_ns  kernfs_find_and_get_ns  sysfs_remove_group  sysfs_remove_groups  device_remove_attrs  device_del  spi_unregister_controller  devm_spi_unregister  release_nodes  devres_release_all  really_probe  driver_probe_device  __device_attach_driver  bus_for_each_drv  __device_attach  device_initial_probe  bus_probe_device  deferred_probe_work_func  process_one_work  worker_thread  kthread  ret_from_fork

CVE-2024-26869:

        In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to truncate meta inode pages forcely  Below race case can cause data corruption:  Thread A				GC thread 					- gc_data_segment 					 - ra_data_block 					  - locked meta_inode page - f2fs_inplace_write_data  - invalidate_mapping_pages  : fail to invalidate meta_inode page    due to lock failure or dirty|writeback    status  - f2fs_submit_page_bio  : write last dirty data to old blkaddr 					 - move_data_block 					  - load old data from meta_inode page 					  - f2fs_submit_page_write 					  : write old data to new blkaddr  Because invalidate_mapping_pages() will skip invalidating page which has unclear status including locked, dirty, writeback and so on, so we need to use truncate_inode_pages_range() instead of invalidate_mapping_pages() to make sure meta_inode page will be dropped.

CVE-2024-26876:

        In the Linux kernel, the following vulnerability has been resolved:  drm/bridge: adv7511: fix crash on irq during probe  Moved IRQ registration down to end of adv7511_probe().  If an IRQ already is pending during adv7511_probe (before adv7511_cec_init) then cec_received_msg_ts could crash using uninitialized data:      Unable to handle kernel read from unreadable memory at virtual address 00000000000003d5     Internal error: Oops: 96000004 [#1] PREEMPT_RT SMP     Call trace:      cec_received_msg_ts+0x48/0x990 [cec]      adv7511_cec_irq_process+0x1cc/0x308 [adv7511]      adv7511_irq_process+0xd8/0x120 [adv7511]      adv7511_irq_handler+0x1c/0x30 [adv7511]      irq_thread_fn+0x30/0xa0      irq_thread+0x14c/0x238      kthread+0x190/0x1a8

CVE-2024-26902:

        In the Linux kernel, the following vulnerability has been resolved:  perf: RISCV: Fix panic on pmu overflow handler  (1 << idx) of int is not desired when setting bits in unsigned long overflowed_ctrs, use BIT() instead. This panic happens when running 'perf record -e branches' on sophgo sg2042.  [  273.311852] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000098 [  273.320851] Oops [#1] [  273.323179] Modules linked in: [  273.326303] CPU: 0 PID: 1475 Comm: perf Not tainted 6.6.0-rc3+ #9 [  273.332521] Hardware name: Sophgo Mango (DT) [  273.336878] epc : riscv_pmu_ctr_get_width_mask+0x8/0x62 [  273.342291]  ra : pmu_sbi_ovf_handler+0x2e0/0x34e [  273.347091] epc : ffffffff80aecd98 ra : ffffffff80aee056 sp : fffffff6e36928b0 [  273.354454]  gp : ffffffff821f82d0 tp : ffffffd90c353200 t0 : 0000002ade4f9978 [  273.361815]  t1 : 0000000000504d55 t2 : ffffffff8016cd8c s0 : fffffff6e3692a70 [  273.369180]  s1 : 0000000000000020 a0 : 0000000000000000 a1 : 00001a8e81800000 [  273.376540]  a2 : 0000003c00070198 a3 : 0000003c00db75a4 a4 : 0000000000000015 [  273.383901]  a5 : ffffffd7ff8804b0 a6 : 0000000000000015 a7 : 000000000000002a [  273.391327]  s2 : 000000000000ffff s3 : 0000000000000000 s4 : ffffffd7ff8803b0 [  273.398773]  s5 : 0000000000504d55 s6 : ffffffd905069800 s7 : ffffffff821fe210 [  273.406139]  s8 : 000000007fffffff s9 : ffffffd7ff8803b0 s10: ffffffd903f29098 [  273.413660]  s11: 0000000080000000 t3 : 0000000000000003 t4 : ffffffff8017a0ca [  273.421022]  t5 : ffffffff8023cfc2 t6 : ffffffd9040780e8 [  273.426437] status: 0000000200000100 badaddr: 0000000000000098 cause: 000000000000000d [  273.434512] [<ffffffff80aecd98>] riscv_pmu_ctr_get_width_mask+0x8/0x62 [  273.441169] [<ffffffff80076bd8>] handle_percpu_devid_irq+0x98/0x1ee [  273.447562] [<ffffffff80071158>] generic_handle_domain_irq+0x28/0x36 [  273.454151] [<ffffffff8047a99a>] riscv_intc_irq+0x36/0x4e [  273.459659] [<ffffffff80c944de>] handle_riscv_irq+0x4a/0x74 [  273.465442] [<ffffffff80c94c48>] do_irq+0x62/0x92 [  273.470360] Code: 0420 60a2 6402 5529 0141 8082 0013 0000 0013 0000 (6d5c) b783 [  273.477921] ---[ end trace 0000000000000000 ]--- [  273.482630] Kernel panic - not syncing: Fatal exception in interrupt

CVE-2024-26913:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Fix dcn35 8k30 Underflow/Corruption Issue  [why] odm calculation is missing for pipe split policy determination and cause Underflow/Corruption issue.  [how] Add the odm calculation.

CVE-2024-26914:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: fix incorrect mpc_combine array size  [why] MAX_SURFACES is per stream, while MAX_PLANES is per asic. The mpc_combine is an array that records all the planes per asic. Therefore MAX_PLANES should be used as the array size. Using MAX_SURFACES causes array overflow when there are more than 3 planes.  [how] Use the MAX_PLANES for the mpc_combine array size.

CVE-2024-26944:

        In the Linux kernel, the following vulnerability has been resolved:  btrfs: zoned: fix use-after-free in do_zone_finish()  Shinichiro reported the following use-after-free triggered by the device replace operation in fstests btrfs/070.   BTRFS info (device nullb1): scrub: finished on devid 1 with status: 0  ==================================================================  BUG: KASAN: slab-use-after-free in do_zone_finish+0x91a/0xb90 [btrfs]  Read of size 8 at addr ffff8881543c8060 by task btrfs-cleaner/3494007   CPU: 0 PID: 3494007 Comm: btrfs-cleaner Tainted: G        W          6.8.0-rc5-kts #1  Hardware name: Supermicro Super Server/X11SPi-TF, BIOS 3.3 02/21/2020  Call Trace:   <TASK>   dump_stack_lvl+0x5b/0x90   print_report+0xcf/0x670   ? __virt_addr_valid+0x200/0x3e0   kasan_report+0xd8/0x110   ? do_zone_finish+0x91a/0xb90 [btrfs]   ? do_zone_finish+0x91a/0xb90 [btrfs]   do_zone_finish+0x91a/0xb90 [btrfs]   btrfs_delete_unused_bgs+0x5e1/0x1750 [btrfs]   ? __pfx_btrfs_delete_unused_bgs+0x10/0x10 [btrfs]   ? btrfs_put_root+0x2d/0x220 [btrfs]   ? btrfs_clean_one_deleted_snapshot+0x299/0x430 [btrfs]   cleaner_kthread+0x21e/0x380 [btrfs]   ? __pfx_cleaner_kthread+0x10/0x10 [btrfs]   kthread+0x2e3/0x3c0   ? __pfx_kthread+0x10/0x10   ret_from_fork+0x31/0x70   ? __pfx_kthread+0x10/0x10   ret_from_fork_asm+0x1b/0x30   </TASK>   Allocated by task 3493983:   kasan_save_stack+0x33/0x60   kasan_save_track+0x14/0x30   __kasan_kmalloc+0xaa/0xb0   btrfs_alloc_device+0xb3/0x4e0 [btrfs]   device_list_add.constprop.0+0x993/0x1630 [btrfs]   btrfs_scan_one_device+0x219/0x3d0 [btrfs]   btrfs_control_ioctl+0x26e/0x310 [btrfs]   __x64_sys_ioctl+0x134/0x1b0   do_syscall_64+0x99/0x190   entry_SYSCALL_64_after_hwframe+0x6e/0x76   Freed by task 3494056:   kasan_save_stack+0x33/0x60   kasan_save_track+0x14/0x30   kasan_save_free_info+0x3f/0x60   poison_slab_object+0x102/0x170   __kasan_slab_free+0x32/0x70   kfree+0x11b/0x320   btrfs_rm_dev_replace_free_srcdev+0xca/0x280 [btrfs]   btrfs_dev_replace_finishing+0xd7e/0x14f0 [btrfs]   btrfs_dev_replace_by_ioctl+0x1286/0x25a0 [btrfs]   btrfs_ioctl+0xb27/0x57d0 [btrfs]   __x64_sys_ioctl+0x134/0x1b0   do_syscall_64+0x99/0x190   entry_SYSCALL_64_after_hwframe+0x6e/0x76   The buggy address belongs to the object at ffff8881543c8000   which belongs to the cache kmalloc-1k of size 1024  The buggy address is located 96 bytes inside of   freed 1024-byte region [ffff8881543c8000, ffff8881543c8400)   The buggy address belongs to the physical page:  page:00000000fe2c1285 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1543c8  head:00000000fe2c1285 order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0  flags: 0x17ffffc0000840(slab|head|node=0|zone=2|lastcpupid=0x1fffff)  page_type: 0xffffffff()  raw: 0017ffffc0000840 ffff888100042dc0 ffffea0019e8f200 dead000000000002  raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000  page dumped because: kasan: bad access detected   Memory state around the buggy address:   ffff8881543c7f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ffff8881543c7f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >ffff8881543c8000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb                                                         ^   ffff8881543c8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb   ffff8881543c8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb  This UAF happens because we're accessing stale zone information of a already removed btrfs_device in do_zone_finish().  The sequence of events is as follows:  btrfs_dev_replace_start   btrfs_scrub_dev    btrfs_dev_replace_finishing     btrfs_dev_replace_update_device_in_mapping_tree <-- devices replaced     btrfs_rm_dev_replace_free_srcdev      btrfs_free_device                              <-- device freed  cleaner_kthread  btrfs_delete_unused_bgs   btrfs_zone_finish    do_zone_finish              <-- refers the freed device  The reason for this is that we're using a ---truncated---

CVE-2024-26947:

        In the Linux kernel, the following vulnerability has been resolved:  ARM: 9359/1: flush: check if the folio is reserved for no-mapping addresses  Since commit a4d5613c4dc6 ("arm: extend pfn_valid to take into account freed memory map alignment") changes the semantics of pfn_valid() to check presence of the memory map for a PFN. A valid page for an address which is reserved but not mapped by the kernel[1], the system crashed during some uio test with the following memory layout:   node   0: [mem 0x00000000c0a00000-0x00000000cc8fffff]  node   0: [mem 0x00000000d0000000-0x00000000da1fffff]  the uio layout is：0xc0900000, 0x100000  the crash backtrace like:    Unable to handle kernel paging request at virtual address bff00000   [...]   CPU: 1 PID: 465 Comm: startapp.bin Tainted: G           O      5.10.0 #1   Hardware name: Generic DT based system   PC is at b15_flush_kern_dcache_area+0x24/0x3c   LR is at __sync_icache_dcache+0x6c/0x98   [...]    (b15_flush_kern_dcache_area) from (__sync_icache_dcache+0x6c/0x98)    (__sync_icache_dcache) from (set_pte_at+0x28/0x54)    (set_pte_at) from (remap_pfn_range+0x1a0/0x274)    (remap_pfn_range) from (uio_mmap+0x184/0x1b8 [uio])    (uio_mmap [uio]) from (__mmap_region+0x264/0x5f4)    (__mmap_region) from (__do_mmap_mm+0x3ec/0x440)    (__do_mmap_mm) from (do_mmap+0x50/0x58)    (do_mmap) from (vm_mmap_pgoff+0xfc/0x188)    (vm_mmap_pgoff) from (ksys_mmap_pgoff+0xac/0xc4)    (ksys_mmap_pgoff) from (ret_fast_syscall+0x0/0x5c)   Code: e0801001 e2423001 e1c00003 f57ff04f (ee070f3e)   ---[ end trace 09cf0734c3805d52 ]---   Kernel panic - not syncing: Fatal exception  So check if PG_reserved was set to solve this issue.  [1]: https://lore.kernel.org/lkml/Zbtdue57RO0QScJM@linux.ibm.com/

CVE-2024-26948:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Add a dc_state NULL check in dc_state_release  [How] Check wheather state is NULL before releasing it.

CVE-2024-26953:

        In the Linux kernel, the following vulnerability has been resolved:  net: esp: fix bad handling of pages from page_pool  When the skb is reorganized during esp_output (!esp->inline), the pages coming from the original skb fragments are supposed to be released back to the system through put_page. But if the skb fragment pages are originating from a page_pool, calling put_page on them will trigger a page_pool leak which will eventually result in a crash.  This leak can be easily observed when using CONFIG_DEBUG_VM and doing ipsec + gre (non offloaded) forwarding:    BUG: Bad page state in process ksoftirqd/16  pfn:1451b6   page:00000000de2b8d32 refcount:0 mapcount:0 mapping:0000000000000000 index:0x1451b6000 pfn:0x1451b6   flags: 0x200000000000000(node=0|zone=2)   page_type: 0xffffffff()   raw: 0200000000000000 dead000000000040 ffff88810d23c000 0000000000000000   raw: 00000001451b6000 0000000000000001 00000000ffffffff 0000000000000000   page dumped because: page_pool leak   Modules linked in: ip_gre gre mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat nf_nat xt_addrtype br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core overlay zram zsmalloc fuse [last unloaded: mlx5_core]   CPU: 16 PID: 96 Comm: ksoftirqd/16 Not tainted 6.8.0-rc4+ #22   Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014   Call Trace:    <TASK>    dump_stack_lvl+0x36/0x50    bad_page+0x70/0xf0    free_unref_page_prepare+0x27a/0x460    free_unref_page+0x38/0x120    esp_ssg_unref.isra.0+0x15f/0x200    esp_output_tail+0x66d/0x780    esp_xmit+0x2c5/0x360    validate_xmit_xfrm+0x313/0x370    ? validate_xmit_skb+0x1d/0x330    validate_xmit_skb_list+0x4c/0x70    sch_direct_xmit+0x23e/0x350    __dev_queue_xmit+0x337/0xba0    ? nf_hook_slow+0x3f/0xd0    ip_finish_output2+0x25e/0x580    iptunnel_xmit+0x19b/0x240    ip_tunnel_xmit+0x5fb/0xb60    ipgre_xmit+0x14d/0x280 [ip_gre]    dev_hard_start_xmit+0xc3/0x1c0    __dev_queue_xmit+0x208/0xba0    ? nf_hook_slow+0x3f/0xd0    ip_finish_output2+0x1ca/0x580    ip_sublist_rcv_finish+0x32/0x40    ip_sublist_rcv+0x1b2/0x1f0    ? ip_rcv_finish_core.constprop.0+0x460/0x460    ip_list_rcv+0x103/0x130    __netif_receive_skb_list_core+0x181/0x1e0    netif_receive_skb_list_internal+0x1b3/0x2c0    napi_gro_receive+0xc8/0x200    gro_cell_poll+0x52/0x90    __napi_poll+0x25/0x1a0    net_rx_action+0x28e/0x300    __do_softirq+0xc3/0x276    ? sort_range+0x20/0x20    run_ksoftirqd+0x1e/0x30    smpboot_thread_fn+0xa6/0x130    kthread+0xcd/0x100    ? kthread_complete_and_exit+0x20/0x20    ret_from_fork+0x31/0x50    ? kthread_complete_and_exit+0x20/0x20    ret_from_fork_asm+0x11/0x20    </TASK>  The suggested fix is to introduce a new wrapper (skb_page_unref) that covers page refcounting for page_pool pages as well.

CVE-2024-26962:

        In the Linux kernel, the following vulnerability has been resolved:  dm-raid456, md/raid456: fix a deadlock for dm-raid456 while io concurrent with reshape  For raid456, if reshape is still in progress, then IO across reshape position will wait for reshape to make progress. However, for dm-raid, in following cases reshape will never make progress hence IO will hang:  1) the array is read-only; 2) MD_RECOVERY_WAIT is set; 3) MD_RECOVERY_FROZEN is set;  After commit c467e97f079f ("md/raid6: use valid sector values to determine if an I/O should wait on the reshape") fix the problem that IO across reshape position doesn't wait for reshape, the dm-raid test shell/lvconvert-raid-reshape.sh start to hang:  [root@fedora ~]# cat /proc/979/stack [<0>] wait_woken+0x7d/0x90 [<0>] raid5_make_request+0x929/0x1d70 [raid456] [<0>] md_handle_request+0xc2/0x3b0 [md_mod] [<0>] raid_map+0x2c/0x50 [dm_raid] [<0>] __map_bio+0x251/0x380 [dm_mod] [<0>] dm_submit_bio+0x1f0/0x760 [dm_mod] [<0>] __submit_bio+0xc2/0x1c0 [<0>] submit_bio_noacct_nocheck+0x17f/0x450 [<0>] submit_bio_noacct+0x2bc/0x780 [<0>] submit_bio+0x70/0xc0 [<0>] mpage_readahead+0x169/0x1f0 [<0>] blkdev_readahead+0x18/0x30 [<0>] read_pages+0x7c/0x3b0 [<0>] page_cache_ra_unbounded+0x1ab/0x280 [<0>] force_page_cache_ra+0x9e/0x130 [<0>] page_cache_sync_ra+0x3b/0x110 [<0>] filemap_get_pages+0x143/0xa30 [<0>] filemap_read+0xdc/0x4b0 [<0>] blkdev_read_iter+0x75/0x200 [<0>] vfs_read+0x272/0x460 [<0>] ksys_read+0x7a/0x170 [<0>] __x64_sys_read+0x1c/0x30 [<0>] do_syscall_64+0xc6/0x230 [<0>] entry_SYSCALL_64_after_hwframe+0x6c/0x74  This is because reshape can't make progress.  For md/raid, the problem doesn't exist because register new sync_thread doesn't rely on the IO to be done any more:  1) If array is read-only, it can switch to read-write by ioctl/sysfs; 2) md/raid never set MD_RECOVERY_WAIT; 3) If MD_RECOVERY_FROZEN is set, mddev_suspend() doesn't hold    'reconfig_mutex', hence it can be cleared and reshape can continue by    sysfs api 'sync_action'.  However, I'm not sure yet how to avoid the problem in dm-raid yet. This patch on the one hand make sure raid_message() can't change sync_thread() through raid_message() after presuspend(), on the other hand detect the above 3 cases before wait for IO do be done in dm_suspend(), and let dm-raid requeue those IO.

CVE-2024-27010:

        In the Linux kernel, the following vulnerability has been resolved:  net/sched: Fix mirred deadlock on device recursion  When the mirred action is used on a classful egress qdisc and a packet is mirrored or redirected to self we hit a qdisc lock deadlock. See trace below.  [..... other info removed for brevity....] [   82.890906] [   82.890906] ============================================ [   82.890906] WARNING: possible recursive locking detected [   82.890906] 6.8.0-05205-g77fadd89fe2d-dirty #213 Tainted: G        W [   82.890906] -------------------------------------------- [   82.890906] ping/418 is trying to acquire lock: [   82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at: __dev_queue_xmit+0x1778/0x3550 [   82.890906] [   82.890906] but task is already holding lock: [   82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at: __dev_queue_xmit+0x1778/0x3550 [   82.890906] [   82.890906] other info that might help us debug this: [   82.890906]  Possible unsafe locking scenario: [   82.890906] [   82.890906]        CPU0 [   82.890906]        ---- [   82.890906]   lock(&sch->q.lock); [   82.890906]   lock(&sch->q.lock); [   82.890906] [   82.890906]  *** DEADLOCK *** [   82.890906] [..... other info removed for brevity....]  Example setup (eth0->eth0) to recreate tc qdisc add dev eth0 root handle 1: htb default 30 tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \      action mirred egress redirect dev eth0  Another example(eth0->eth1->eth0) to recreate tc qdisc add dev eth0 root handle 1: htb default 30 tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \      action mirred egress redirect dev eth1  tc qdisc add dev eth1 root handle 1: htb default 30 tc filter add dev eth1 handle 1: protocol ip prio 2 matchall \      action mirred egress redirect dev eth0  We fix this by adding an owner field (CPU id) to struct Qdisc set after root qdisc is entered. When the softirq enters it a second time, if the qdisc owner is the same CPU, the packet is dropped to break the loop.

CVE-2024-27011:

        In the Linux kernel, the following vulnerability has been resolved:  netfilter: nf_tables: fix memleak in map from abort path  The delete set command does not rely on the transaction object for element removal, therefore, a combination of delete element + delete set from the abort path could result in restoring twice the refcount of the mapping.  Check for inactive element in the next generation for the delete element command in the abort path, skip restoring state if next generation bit has been already cleared. This is similar to the activate logic using the set walk iterator.  [ 6170.286929] ------------[ cut here ]------------ [ 6170.286939] WARNING: CPU: 6 PID: 790302 at net/netfilter/nf_tables_api.c:2086 nf_tables_chain_destroy+0x1f7/0x220 [nf_tables] [ 6170.287071] Modules linked in: [...] [ 6170.287633] CPU: 6 PID: 790302 Comm: kworker/6:2 Not tainted 6.9.0-rc3+ #365 [ 6170.287768] RIP: 0010:nf_tables_chain_destroy+0x1f7/0x220 [nf_tables] [ 6170.287886] Code: df 48 8d 7d 58 e8 69 2e 3b df 48 8b 7d 58 e8 80 1b 37 df 48 8d 7d 68 e8 57 2e 3b df 48 8b 7d 68 e8 6e 1b 37 df 48 89 ef eb c4 <0f> 0b 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 0f [ 6170.287895] RSP: 0018:ffff888134b8fd08 EFLAGS: 00010202 [ 6170.287904] RAX: 0000000000000001 RBX: ffff888125bffb28 RCX: dffffc0000000000 [ 6170.287912] RDX: 0000000000000003 RSI: ffffffffa20298ab RDI: ffff88811ebe4750 [ 6170.287919] RBP: ffff88811ebe4700 R08: ffff88838e812650 R09: fffffbfff0623a55 [ 6170.287926] R10: ffffffff8311d2af R11: 0000000000000001 R12: ffff888125bffb10 [ 6170.287933] R13: ffff888125bffb10 R14: dead000000000122 R15: dead000000000100 [ 6170.287940] FS:  0000000000000000(0000) GS:ffff888390b00000(0000) knlGS:0000000000000000 [ 6170.287948] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 6170.287955] CR2: 00007fd31fc00710 CR3: 0000000133f60004 CR4: 00000000001706f0 [ 6170.287962] Call Trace: [ 6170.287967]  <TASK> [ 6170.287973]  ? __warn+0x9f/0x1a0 [ 6170.287986]  ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables] [ 6170.288092]  ? report_bug+0x1b1/0x1e0 [ 6170.287986]  ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables] [ 6170.288092]  ? report_bug+0x1b1/0x1e0 [ 6170.288104]  ? handle_bug+0x3c/0x70 [ 6170.288112]  ? exc_invalid_op+0x17/0x40 [ 6170.288120]  ? asm_exc_invalid_op+0x1a/0x20 [ 6170.288132]  ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables] [ 6170.288243]  ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables] [ 6170.288366]  ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables] [ 6170.288483]  nf_tables_trans_destroy_work+0x588/0x590 [nf_tables]

CVE-2024-27041:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: fix NULL checks for adev->dm.dc in amdgpu_dm_fini()  Since 'adev->dm.dc' in amdgpu_dm_fini() might turn out to be NULL before the call to dc_enable_dmub_notifications(), check beforehand to ensure there will not be a possible NULL-ptr-deref there.  Also, since commit 1e88eb1b2c25 ("drm/amd/display: Drop CONFIG_DRM_AMD_DC_HDCP") there are two separate checks for NULL in 'adev->dm.dc' before dc_deinit_callbacks() and dc_dmub_srv_destroy(). Clean up by combining them all under one 'if'.  Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE.

CVE-2024-27057:

        In the Linux kernel, the following vulnerability has been resolved:  ASoC: SOF: ipc4-pcm: Workaround for crashed firmware on system suspend  When the system is suspended while audio is active, the sof_ipc4_pcm_hw_free() is invoked to reset the pipelines since during suspend the DSP is turned off, streams will be re-started after resume.  If the firmware crashes during while audio is running (or when we reset the stream before suspend) then the sof_ipc4_set_multi_pipeline_state() will fail with IPC error and the state change is interrupted. This will cause misalignment between the kernel and firmware state on next DSP boot resulting errors returned by firmware for IPC messages, eventually failing the audio resume. On stream close the errors are ignored so the kernel state will be corrected on the next DSP boot, so the second boot after the DSP panic.  If sof_ipc4_trigger_pipelines() is called from sof_ipc4_pcm_hw_free() then state parameter is SOF_IPC4_PIPE_RESET and only in this case.  Treat a forced pipeline reset similarly to how we treat a pcm_free by ignoring error on state sending to allow the kernel's state to be consistent with the state the firmware will have after the next boot.

CVE-2024-27062:

        In the Linux kernel, the following vulnerability has been resolved:  nouveau: lock the client object tree.  It appears the client object tree has no locking unless I've missed something else. Fix races around adding/removing client objects, mostly vram bar mappings.   4562.099306] general protection fault, probably for non-canonical address 0x6677ed422bceb80c: 0000 [#1] PREEMPT SMP PTI [ 4562.099314] CPU: 2 PID: 23171 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27 [ 4562.099324] Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021 [ 4562.099330] RIP: 0010:nvkm_object_search+0x1d/0x70 [nouveau] [ 4562.099503] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 48 89 f8 48 85 f6 74 39 48 8b 87 a0 00 00 00 48 85 c0 74 12 <48> 8b 48 f8 48 39 ce 73 15 48 8b 40 10 48 85 c0 75 ee 48 c7 c0 fe [ 4562.099506] RSP: 0000:ffffa94cc420bbf8 EFLAGS: 00010206 [ 4562.099512] RAX: 6677ed422bceb814 RBX: ffff98108791f400 RCX: ffff9810f26b8f58 [ 4562.099517] RDX: 0000000000000000 RSI: ffff9810f26b9158 RDI: ffff98108791f400 [ 4562.099519] RBP: ffff9810f26b9158 R08: 0000000000000000 R09: 0000000000000000 [ 4562.099521] R10: ffffa94cc420bc48 R11: 0000000000000001 R12: ffff9810f02a7cc0 [ 4562.099526] R13: 0000000000000000 R14: 00000000000000ff R15: 0000000000000007 [ 4562.099528] FS:  00007f629c5017c0(0000) GS:ffff98142c700000(0000) knlGS:0000000000000000 [ 4562.099534] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4562.099536] CR2: 00007f629a882000 CR3: 000000017019e004 CR4: 00000000003706f0 [ 4562.099541] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 4562.099542] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 4562.099544] Call Trace: [ 4562.099555]  <TASK> [ 4562.099573]  ? die_addr+0x36/0x90 [ 4562.099583]  ? exc_general_protection+0x246/0x4a0 [ 4562.099593]  ? asm_exc_general_protection+0x26/0x30 [ 4562.099600]  ? nvkm_object_search+0x1d/0x70 [nouveau] [ 4562.099730]  nvkm_ioctl+0xa1/0x250 [nouveau] [ 4562.099861]  nvif_object_map_handle+0xc8/0x180 [nouveau] [ 4562.099986]  nouveau_ttm_io_mem_reserve+0x122/0x270 [nouveau] [ 4562.100156]  ? dma_resv_test_signaled+0x26/0xb0 [ 4562.100163]  ttm_bo_vm_fault_reserved+0x97/0x3c0 [ttm] [ 4562.100182]  ? __mutex_unlock_slowpath+0x2a/0x270 [ 4562.100189]  nouveau_ttm_fault+0x69/0xb0 [nouveau] [ 4562.100356]  __do_fault+0x32/0x150 [ 4562.100362]  do_fault+0x7c/0x560 [ 4562.100369]  __handle_mm_fault+0x800/0xc10 [ 4562.100382]  handle_mm_fault+0x17c/0x3e0 [ 4562.100388]  do_user_addr_fault+0x208/0x860 [ 4562.100395]  exc_page_fault+0x7f/0x200 [ 4562.100402]  asm_exc_page_fault+0x26/0x30 [ 4562.100412] RIP: 0033:0x9b9870 [ 4562.100419] Code: 85 a8 f7 ff ff 8b 8d 80 f7 ff ff 89 08 e9 18 f2 ff ff 0f 1f 84 00 00 00 00 00 44 89 32 e9 90 fa ff ff 0f 1f 84 00 00 00 00 00 <44> 89 32 e9 f8 f1 ff ff 0f 1f 84 00 00 00 00 00 66 44 89 32 e9 e7 [ 4562.100422] RSP: 002b:00007fff9ba2dc70 EFLAGS: 00010246 [ 4562.100426] RAX: 0000000000000004 RBX: 000000000dd65e10 RCX: 000000fff0000000 [ 4562.100428] RDX: 00007f629a882000 RSI: 00007f629a882000 RDI: 0000000000000066 [ 4562.100432] RBP: 00007fff9ba2e570 R08: 0000000000000000 R09: 0000000123ddf000 [ 4562.100434] R10: 0000000000000001 R11: 0000000000000246 R12: 000000007fffffff [ 4562.100436] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 4562.100446]  </TASK> [ 4562.100448] Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink cmac bnep sunrpc iwlmvm intel_rapl_msr intel_rapl_common snd_sof_pci_intel_cnl x86_pkg_temp_thermal intel_powerclamp snd_sof_intel_hda_common mac80211 coretemp snd_soc_acpi_intel_match kvm_intel snd_soc_acpi snd_soc_hdac_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof_intel_hda_mlink  ---truncated---

CVE-2024-27079:

        In the Linux kernel, the following vulnerability has been resolved:  iommu/vt-d: Fix NULL domain on device release  In the kdump kernel, the IOMMU operates in deferred_attach mode. In this mode, info->domain may not yet be assigned by the time the release_device function is called. It leads to the following crash in the crash kernel:      BUG: kernel NULL pointer dereference, address: 000000000000003c     ...     RIP: 0010:do_raw_spin_lock+0xa/0xa0     ...     _raw_spin_lock_irqsave+0x1b/0x30     intel_iommu_release_device+0x96/0x170     iommu_deinit_device+0x39/0xf0     __iommu_group_remove_device+0xa0/0xd0     iommu_bus_notifier+0x55/0xb0     notifier_call_chain+0x5a/0xd0     blocking_notifier_call_chain+0x41/0x60     bus_notify+0x34/0x50     device_del+0x269/0x3d0     pci_remove_bus_device+0x77/0x100     p2sb_bar+0xae/0x1d0     ...     i801_probe+0x423/0x740  Use the release_domain mechanism to fix it. The scalable mode context entry which is not part of release domain should be cleared in release_device().

CVE-2024-27408:

        In the Linux kernel, the following vulnerability has been resolved:  dmaengine: dw-edma: eDMA: Add sync read before starting the DMA transfer in remote setup  The Linked list element and pointer are not stored in the same memory as the eDMA controller register. If the doorbell register is toggled before the full write of the linked list a race condition error will occur. In remote setup we can only use a readl to the memory to assure the full write has occurred.

CVE-2024-35784:

        In the Linux kernel, the following vulnerability has been resolved:  btrfs: fix deadlock with fiemap and extent locking  While working on the patchset to remove extent locking I got a lockdep splat with fiemap and pagefaulting with my new extent lock replacement lock.  This deadlock exists with our normal code, we just don't have lockdep annotations with the extent locking so we've never noticed it.  Since we're copying the fiemap extent to user space on every iteration we have the chance of pagefaulting.  Because we hold the extent lock for the entire range we could mkwrite into a range in the file that we have mmap'ed.  This would deadlock with the following stack trace  [<0>] lock_extent+0x28d/0x2f0 [<0>] btrfs_page_mkwrite+0x273/0x8a0 [<0>] do_page_mkwrite+0x50/0xb0 [<0>] do_fault+0xc1/0x7b0 [<0>] __handle_mm_fault+0x2fa/0x460 [<0>] handle_mm_fault+0xa4/0x330 [<0>] do_user_addr_fault+0x1f4/0x800 [<0>] exc_page_fault+0x7c/0x1e0 [<0>] asm_exc_page_fault+0x26/0x30 [<0>] rep_movs_alternative+0x33/0x70 [<0>] _copy_to_user+0x49/0x70 [<0>] fiemap_fill_next_extent+0xc8/0x120 [<0>] emit_fiemap_extent+0x4d/0xa0 [<0>] extent_fiemap+0x7f8/0xad0 [<0>] btrfs_fiemap+0x49/0x80 [<0>] __x64_sys_ioctl+0x3e1/0xb50 [<0>] do_syscall_64+0x94/0x1a0 [<0>] entry_SYSCALL_64_after_hwframe+0x6e/0x76  I wrote an fstest to reproduce this deadlock without my replacement lock and verified that the deadlock exists with our existing locking.  To fix this simply don't take the extent lock for the entire duration of the fiemap.  This is safe in general because we keep track of where we are when we're searching the tree, so if an ordered extent updates in the middle of our fiemap call we'll still emit the correct extents because we know what offset we were on before.  The only place we maintain the lock is searching delalloc.  Since the delalloc stuff can change during writeback we want to lock the extent range so we have a consistent view of delalloc at the time we're checking to see if we need to set the delalloc flag.  With this patch applied we no longer deadlock with my testcase.

CVE-2024-35794:

        In the Linux kernel, the following vulnerability has been resolved:  dm-raid: really frozen sync_thread during suspend  1) commit f52f5c71f3d4 ("md: fix stopping sync thread") remove    MD_RECOVERY_FROZEN from __md_stop_writes() and doesn't realize that    dm-raid relies on __md_stop_writes() to frozen sync_thread    indirectly. Fix this problem by adding MD_RECOVERY_FROZEN in    md_stop_writes(), and since stop_sync_thread() is only used for    dm-raid in this case, also move stop_sync_thread() to    md_stop_writes(). 2) The flag MD_RECOVERY_FROZEN doesn't mean that sync thread is frozen,    it only prevent new sync_thread to start, and it can't stop the    running sync thread; In order to frozen sync_thread, after seting the    flag, stop_sync_thread() should be used. 3) The flag MD_RECOVERY_FROZEN doesn't mean that writes are stopped, use    it as condition for md_stop_writes() in raid_postsuspend() doesn't    look correct. Consider that reentrant stop_sync_thread() do nothing,    always call md_stop_writes() in raid_postsuspend(). 4) raid_message can set/clear the flag MD_RECOVERY_FROZEN at anytime,    and if MD_RECOVERY_FROZEN is cleared while the array is suspended,    new sync_thread can start unexpected. Fix this by disallow    raid_message() to change sync_thread status during suspend.  Note that after commit f52f5c71f3d4 ("md: fix stopping sync thread"), the test shell/lvconvert-raid-reshape.sh start to hang in stop_sync_thread(), and with previous fixes, the test won't hang there anymore, however, the test will still fail and complain that ext4 is corrupted. And with this patch, the test won't hang due to stop_sync_thread() or fail due to ext4 is corrupted anymore. However, there is still a deadlock related to dm-raid456 that will be fixed in following patches.

CVE-2024-35799:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Prevent crash when disable stream  [Why] Disabling stream encoder invokes a function that no longer exists.  [How] Check if the function declaration is NULL in disable stream encoder.

CVE-2024-35808:

        In the Linux kernel, the following vulnerability has been resolved:  md/dm-raid: don't call md_reap_sync_thread() directly  Currently md_reap_sync_thread() is called from raid_message() directly without holding 'reconfig_mutex', this is definitely unsafe because md_reap_sync_thread() can change many fields that is protected by 'reconfig_mutex'.  However, hold 'reconfig_mutex' here is still problematic because this will cause deadlock, for example, commit 130443d60b1b ("md: refactor idle/frozen_sync_thread() to fix deadlock").  Fix this problem by using stop_sync_thread() to unregister sync_thread, like md/raid did.

CVE-2024-35843:

        In the Linux kernel, the following vulnerability has been resolved:  iommu/vt-d: Use device rbtree in iopf reporting path  The existing I/O page fault handler currently locates the PCI device by calling pci_get_domain_bus_and_slot(). This function searches the list of all PCI devices until the desired device is found. To improve lookup efficiency, replace it with device_rbtree_find() to search the device within the probed device rbtree.  The I/O page fault is initiated by the device, which does not have any synchronization mechanism with the software to ensure that the device stays in the probed device tree. Theoretically, a device could be released by the IOMMU subsystem after device_rbtree_find() and before iopf_get_dev_fault_param(), which would cause a use-after-free problem.  Add a mutex to synchronize the I/O page fault reporting path and the IOMMU release device path. This lock doesn't introduce any performance overhead, as the conflict between I/O page fault reporting and device releasing is very rare.

CVE-2024-35860:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: support deferring bpf_link dealloc to after RCU grace period  BPF link for some program types is passed as a "context" which can be used by those BPF programs to look up additional information. E.g., for multi-kprobes and multi-uprobes, link is used to fetch BPF cookie values.  Because of this runtime dependency, when bpf_link refcnt drops to zero there could still be active BPF programs running accessing link data.  This patch adds generic support to defer bpf_link dealloc callback to after RCU GP, if requested. This is done by exposing two different deallocation callbacks, one synchronous and one deferred. If deferred one is provided, bpf_link_free() will schedule dealloc_deferred() callback to happen after RCU GP.  BPF is using two flavors of RCU: "classic" non-sleepable one and RCU tasks trace one. The latter is used when sleepable BPF programs are used. bpf_link_free() accommodates that by checking underlying BPF program's sleepable flag, and goes either through normal RCU GP only for non-sleepable, or through RCU tasks trace GP *and* then normal RCU GP (taking into account rcu_trace_implies_rcu_gp() optimization), if BPF program is sleepable.  We use this for multi-kprobe and multi-uprobe links, which dereference link during program run. We also preventively switch raw_tp link to use deferred dealloc callback, as upcoming changes in bpf-next tree expose raw_tp link data (specifically, cookie value) to BPF program at runtime as well.

CVE-2024-35904:

        In the Linux kernel, the following vulnerability has been resolved:  selinux: avoid dereference of garbage after mount failure  In case kern_mount() fails and returns an error pointer return in the error branch instead of continuing and dereferencing the error pointer.  While on it drop the never read static variable selinuxfs_mount.

CVE-2024-35924:

        In the Linux kernel, the following vulnerability has been resolved:  usb: typec: ucsi: Limit read size on v1.2  Between UCSI 1.2 and UCSI 2.0, the size of the MESSAGE_IN region was increased from 16 to 256. In order to avoid overflowing reads for older systems, add a mechanism to use the read UCSI version to truncate read sizes on UCSI v1.2.

CVE-2024-35931:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu: Skip do PCI error slot reset during RAS recovery  Why:     The PCI error slot reset maybe triggered after inject ue to UMC multi times, this     caused system hang.     [  557.371857] amdgpu 0000:af:00.0: amdgpu: GPU reset succeeded, trying to resume     [  557.373718] [drm] PCIE GART of 512M enabled.     [  557.373722] [drm] PTB located at 0x0000031FED700000     [  557.373788] [drm] VRAM is lost due to GPU reset!     [  557.373789] [drm] PSP is resuming...     [  557.547012] mlx5_core 0000:55:00.0: mlx5_pci_err_detected Device state = 1 pci_status: 0. Exit, result = 3, need reset     [  557.547067] [drm] PCI error: detected callback, state(1)!!     [  557.547069] [drm] No support for XGMI hive yet...     [  557.548125] mlx5_core 0000:55:00.0: mlx5_pci_slot_reset Device state = 1 pci_status: 0. Enter     [  557.607763] mlx5_core 0000:55:00.0: wait vital counter value 0x16b5b after 1 iterations     [  557.607777] mlx5_core 0000:55:00.0: mlx5_pci_slot_reset Device state = 1 pci_status: 1. Exit, err = 0, result = 5, recovered     [  557.610492] [drm] PCI error: slot reset callback!!     ...     [  560.689382] amdgpu 0000:3f:00.0: amdgpu: GPU reset(2) succeeded!     [  560.689546] amdgpu 0000:5a:00.0: amdgpu: GPU reset(2) succeeded!     [  560.689562] general protection fault, probably for non-canonical address 0x5f080b54534f611f: 0000 [#1] SMP NOPTI     [  560.701008] CPU: 16 PID: 2361 Comm: kworker/u448:9 Tainted: G           OE     5.15.0-91-generic #101-Ubuntu     [  560.712057] Hardware name: Microsoft C278A/C278A, BIOS C2789.5.BS.1C11.AG.1 11/08/2023     [  560.720959] Workqueue: amdgpu-reset-hive amdgpu_ras_do_recovery [amdgpu]     [  560.728887] RIP: 0010:amdgpu_device_gpu_recover.cold+0xbf1/0xcf5 [amdgpu]     [  560.736891] Code: ff 41 89 c6 e9 1b ff ff ff 44 0f b6 45 b0 e9 4f ff ff ff be 01 00 00 00 4c 89 e7 e8 76 c9 8b ff 44 0f b6 45 b0 e9 3c fd ff ff <48> 83 ba 18 02 00 00 00 0f 84 6a f8 ff ff 48 8d 7a 78 be 01 00 00     [  560.757967] RSP: 0018:ffa0000032e53d80 EFLAGS: 00010202     [  560.763848] RAX: ffa00000001dfd10 RBX: ffa0000000197090 RCX: ffa0000032e53db0     [  560.771856] RDX: 5f080b54534f5f07 RSI: 0000000000000000 RDI: ff11000128100010     [  560.779867] RBP: ffa0000032e53df0 R08: 0000000000000000 R09: ffffffffffe77f08     [  560.787879] R10: 0000000000ffff0a R11: 0000000000000001 R12: 0000000000000000     [  560.795889] R13: ffa0000032e53e00 R14: 0000000000000000 R15: 0000000000000000     [  560.803889] FS:  0000000000000000(0000) GS:ff11007e7e800000(0000) knlGS:0000000000000000     [  560.812973] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033     [  560.819422] CR2: 000055a04c118e68 CR3: 0000000007410005 CR4: 0000000000771ee0     [  560.827433] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000     [  560.835433] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400     [  560.843444] PKRU: 55555554     [  560.846480] Call Trace:     [  560.849225]  <TASK>     [  560.851580]  ? show_trace_log_lvl+0x1d6/0x2ea     [  560.856488]  ? show_trace_log_lvl+0x1d6/0x2ea     [  560.861379]  ? amdgpu_ras_do_recovery+0x1b2/0x210 [amdgpu]     [  560.867778]  ? show_regs.part.0+0x23/0x29     [  560.872293]  ? __die_body.cold+0x8/0xd     [  560.876502]  ? die_addr+0x3e/0x60     [  560.880238]  ? exc_general_protection+0x1c5/0x410     [  560.885532]  ? asm_exc_general_protection+0x27/0x30     [  560.891025]  ? amdgpu_device_gpu_recover.cold+0xbf1/0xcf5 [amdgpu]     [  560.898323]  amdgpu_ras_do_recovery+0x1b2/0x210 [amdgpu]     [  560.904520]  process_one_work+0x228/0x3d0 How:     In RAS recovery, mode-1 reset is issued from RAS fatal error handling and expected     all the nodes in a hive to be reset. no need to issue another mode-1 during this procedure.

CVE-2024-35942:

        In the Linux kernel, the following vulnerability has been resolved:  pmdomain: imx8mp-blk-ctrl: imx8mp_blk: Add fdcc clock to hdmimix domain  According to i.MX8MP RM and HDMI ADD, the fdcc clock is part of hdmi rx verification IP that should not enable for HDMI TX. But actually if the clock is disabled before HDMI/LCDIF probe, LCDIF will not get pixel clock from HDMI PHY and print the error logs:  [CRTC:39:crtc-2] vblank wait timed out WARNING: CPU: 2 PID: 9 at drivers/gpu/drm/drm_atomic_helper.c:1634 drm_atomic_helper_wait_for_vblanks.part.0+0x23c/0x260  Add fdcc clock to LCDIF and HDMI TX power domains to fix the issue.

CVE-2024-35945:

        In the Linux kernel, the following vulnerability has been resolved:  net: phy: phy_device: Prevent nullptr exceptions on ISR  If phydev->irq is set unconditionally, check for valid interrupt handler or fall back to polling mode to prevent nullptr exceptions in interrupt service routine.

CVE-2024-35946:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: rtw89: fix null pointer access when abort scan  During cancel scan we might use vif that weren't scanning. Fix this by using the actual scanning vif.

CVE-2024-35951:

        In the Linux kernel, the following vulnerability has been resolved:  drm/panfrost: Fix the error path in panfrost_mmu_map_fault_addr()  Subject: [PATCH] drm/panfrost: Fix the error path in  panfrost_mmu_map_fault_addr()  If some the pages or sgt allocation failed, we shouldn't release the pages ref we got earlier, otherwise we will end up with unbalanced get/put_pages() calls. We should instead leave everything in place and let the BO release function deal with extra cleanup when the object is destroyed, or let the fault handler try again next time it's called.

CVE-2024-35961:

        In the Linux kernel, the following vulnerability has been resolved:  net/mlx5: Register devlink first under devlink lock  In case device is having a non fatal FW error during probe, the driver will report the error to user via devlink. This will trigger a WARN_ON, since mlx5 is calling devlink_register() last. In order to avoid the WARN_ON[1], change mlx5 to invoke devl_register() first under devlink lock.  [1] WARNING: CPU: 5 PID: 227 at net/devlink/health.c:483 devlink_recover_notify.constprop.0+0xb8/0xc0 CPU: 5 PID: 227 Comm: kworker/u16:3 Not tainted 6.4.0-rc5_for_upstream_min_debug_2023_06_12_12_38 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5_health0000:08:00.0 mlx5_fw_reporter_err_work [mlx5_core] RIP: 0010:devlink_recover_notify.constprop.0+0xb8/0xc0 Call Trace:  <TASK>  ? __warn+0x79/0x120  ? devlink_recover_notify.constprop.0+0xb8/0xc0  ? report_bug+0x17c/0x190  ? handle_bug+0x3c/0x60  ? exc_invalid_op+0x14/0x70  ? asm_exc_invalid_op+0x16/0x20  ? devlink_recover_notify.constprop.0+0xb8/0xc0  devlink_health_report+0x4a/0x1c0  mlx5_fw_reporter_err_work+0xa4/0xd0 [mlx5_core]  process_one_work+0x1bb/0x3c0  ? process_one_work+0x3c0/0x3c0  worker_thread+0x4d/0x3c0  ? process_one_work+0x3c0/0x3c0  kthread+0xc6/0xf0  ? kthread_complete_and_exit+0x20/0x20  ret_from_fork+0x1f/0x30  </TASK>

CVE-2024-36024:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Disable idle reallow as part of command/gpint execution  [Why] Workaroud for a race condition where DMCUB is in the process of committing to IPS1 during the handshake causing us to miss the transition into IPS2 and touch the INBOX1 RPTR causing a HW hang.  [How] Disable the reallow to ensure that we have enough of a gap between entry and exit and we're not seeing back-to-back wake_and_executes.

CVE-2024-36881:

        In the Linux kernel, the following vulnerability has been resolved:  mm/userfaultfd: reset ptes when close() for wr-protected ones  Userfaultfd unregister includes a step to remove wr-protect bits from all the relevant pgtable entries, but that only covered an explicit UFFDIO_UNREGISTER ioctl, not a close() on the userfaultfd itself.  Cover that too.  This fixes a WARN trace.  The only user visible side effect is the user can observe leftover wr-protect bits even if the user close()ed on an userfaultfd when releasing the last reference of it.  However hopefully that should be harmless, and nothing bad should happen even if so.  This change is now more important after the recent page-table-check patch we merged in mm-unstable (446dd9ad37d0 ("mm/page_table_check: support userfault wr-protect entries")), as we'll do sanity check on uffd-wp bits without vma context.  So it's better if we can 100% guarantee no uffd-wp bit leftovers, to make sure each report will be valid.

CVE-2024-36911:

        In the Linux kernel, the following vulnerability has been resolved:  hv_netvsc: Don't free decrypted memory  In CoCo VMs it is possible for the untrusted host to cause set_memory_encrypted() or set_memory_decrypted() to fail such that an error is returned and the resulting memory is shared. Callers need to take care to handle these errors to avoid returning decrypted (shared) memory to the page allocator, which could lead to functional or security issues.  The netvsc driver could free decrypted/shared pages if set_memory_decrypted() fails. Check the decrypted field in the gpadl to decide whether to free the memory.

CVE-2024-36949:

        In the Linux kernel, the following vulnerability has been resolved:  amd/amdkfd: sync all devices to wait all processes being evicted  If there are more than one device doing reset in parallel, the first device will call kfd_suspend_all_processes() to evict all processes on all devices, this call takes time to finish. other device will start reset and recover without waiting. if the process has not been evicted before doing recover, it will be restored, then caused page fault.

CVE-2024-36951:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdkfd: range check cp bad op exception interrupts  Due to a CP interrupt bug, bad packet garbage exception codes are raised. Do a range check so that the debugger and runtime do not receive garbage codes. Update the user api to guard exception code type checking as well.

CVE-2024-36968:

        In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init()  l2cap_le_flowctl_init() can cause both div-by-zero and an integer overflow since hdev->le_mtu may not fall in the valid range.  Move MTU from hci_dev to hci_conn to validate MTU and stop the connection process earlier if MTU is invalid. Also, add a missing validation in read_buffer_size() and make it return an error value if the validation fails. Now hci_conn_add() returns ERR_PTR() as it can fail due to the both a kzalloc failure and invalid MTU value.  divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 PID: 67 Comm: kworker/u5:0 Tainted: G        W          6.9.0-rc5+ #20 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: hci0 hci_rx_work RIP: 0010:l2cap_le_flowctl_init+0x19e/0x3f0 net/bluetooth/l2cap_core.c:547 Code: e8 17 17 0c 00 66 41 89 9f 84 00 00 00 bf 01 00 00 00 41 b8 02 00 00 00 4c 89 fe 4c 89 e2 89 d9 e8 27 17 0c 00 44 89 f0 31 d2 <66> f7 f3 89 c3 ff c3 4d 8d b7 88 00 00 00 4c 89 f0 48 c1 e8 03 42 RSP: 0018:ffff88810bc0f858 EFLAGS: 00010246 RAX: 00000000000002a0 RBX: 0000000000000000 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: ffff88810bc0f7c0 RDI: ffffc90002dcb66f RBP: ffff88810bc0f880 R08: aa69db2dda70ff01 R09: 0000ffaaaaaaaaaa R10: 0084000000ffaaaa R11: 0000000000000000 R12: ffff88810d65a084 R13: dffffc0000000000 R14: 00000000000002a0 R15: ffff88810d65a000 FS:  0000000000000000(0000) GS:ffff88811ac00000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000100 CR3: 0000000103268003 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace:  <TASK>  l2cap_le_connect_req net/bluetooth/l2cap_core.c:4902 [inline]  l2cap_le_sig_cmd net/bluetooth/l2cap_core.c:5420 [inline]  l2cap_le_sig_channel net/bluetooth/l2cap_core.c:5486 [inline]  l2cap_recv_frame+0xe59d/0x11710 net/bluetooth/l2cap_core.c:6809  l2cap_recv_acldata+0x544/0x10a0 net/bluetooth/l2cap_core.c:7506  hci_acldata_packet net/bluetooth/hci_core.c:3939 [inline]  hci_rx_work+0x5e5/0xb20 net/bluetooth/hci_core.c:4176  process_one_work kernel/workqueue.c:3254 [inline]  process_scheduled_works+0x90f/0x1530 kernel/workqueue.c:3335  worker_thread+0x926/0xe70 kernel/workqueue.c:3416  kthread+0x2e3/0x380 kernel/kthread.c:388  ret_from_fork+0x5c/0x90 arch/x86/kernel/process.c:147  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244  </TASK> Modules linked in: ---[ end trace 0000000000000000 ]---

CVE-2024-38557:

        In the Linux kernel, the following vulnerability has been resolved:  net/mlx5: Reload only IB representors upon lag disable/enable  On lag disable, the bond IB device along with all of its representors are destroyed, and then the slaves' representors get reloaded.  In case the slave IB representor load fails, the eswitch error flow unloads all representors, including ethernet representors, where the netdevs get detached and removed from lag bond. Such flow is inaccurate as the lag driver is not responsible for loading/unloading ethernet representors. Furthermore, the flow described above begins by holding lag lock to prevent bond changes during disable flow. However, when reaching the ethernet representors detachment from lag, the lag lock is required again, triggering the following deadlock:  Call trace: __switch_to+0xf4/0x148 __schedule+0x2c8/0x7d0 schedule+0x50/0xe0 schedule_preempt_disabled+0x18/0x28 __mutex_lock.isra.13+0x2b8/0x570 __mutex_lock_slowpath+0x1c/0x28 mutex_lock+0x4c/0x68 mlx5_lag_remove_netdev+0x3c/0x1a0 [mlx5_core] mlx5e_uplink_rep_disable+0x70/0xa0 [mlx5_core] mlx5e_detach_netdev+0x6c/0xb0 [mlx5_core] mlx5e_netdev_change_profile+0x44/0x138 [mlx5_core] mlx5e_netdev_attach_nic_profile+0x28/0x38 [mlx5_core] mlx5e_vport_rep_unload+0x184/0x1b8 [mlx5_core] mlx5_esw_offloads_rep_load+0xd8/0xe0 [mlx5_core] mlx5_eswitch_reload_reps+0x74/0xd0 [mlx5_core] mlx5_disable_lag+0x130/0x138 [mlx5_core] mlx5_lag_disable_change+0x6c/0x70 [mlx5_core] // hold ldev->lock mlx5_devlink_eswitch_mode_set+0xc0/0x410 [mlx5_core] devlink_nl_cmd_eswitch_set_doit+0xdc/0x180 genl_family_rcv_msg_doit.isra.17+0xe8/0x138 genl_rcv_msg+0xe4/0x220 netlink_rcv_skb+0x44/0x108 genl_rcv+0x40/0x58 netlink_unicast+0x198/0x268 netlink_sendmsg+0x1d4/0x418 sock_sendmsg+0x54/0x60 __sys_sendto+0xf4/0x120 __arm64_sys_sendto+0x30/0x40 el0_svc_common+0x8c/0x120 do_el0_svc+0x30/0xa0 el0_svc+0x20/0x30 el0_sync_handler+0x90/0xb8 el0_sync+0x160/0x180  Thus, upon lag enable/disable, load and unload only the IB representors of the slaves preventing the deadlock mentioned above.  While at it, refactor the mlx5_esw_offloads_rep_load() function to have a static helper method for its internal logic, in symmetry with the representor unload design.

CVE-2024-38564:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: Add BPF_PROG_TYPE_CGROUP_SKB attach type enforcement in BPF_LINK_CREATE  bpf_prog_attach uses attach_type_to_prog_type to enforce proper attach type for BPF_PROG_TYPE_CGROUP_SKB. link_create uses bpf_prog_get and relies on bpf_prog_attach_check_attach_type to properly verify prog_type <> attach_type association.  Add missing attach_type enforcement for the link_create case. Otherwise, it's currently possible to attach cgroup_skb prog types to other cgroup hooks.

CVE-2024-38570:

        In the Linux kernel, the following vulnerability has been resolved:  gfs2: Fix potential glock use-after-free on unmount  When a DLM lockspace is released and there ares still locks in that lockspace, DLM will unlock those locks automatically.  Commit fb6791d100d1b started exploiting this behavior to speed up filesystem unmount: gfs2 would simply free glocks it didn't want to unlock and then release the lockspace.  This didn't take the bast callbacks for asynchronous lock contention notifications into account, which remain active until until a lock is unlocked or its lockspace is released.  To prevent those callbacks from accessing deallocated objects, put the glocks that should not be unlocked on the sd_dead_glocks list, release the lockspace, and only then free those glocks.  As an additional measure, ignore unexpected ast and bast callbacks if the receiving glock is dead.

CVE-2024-38594:

        In the Linux kernel, the following vulnerability has been resolved:  net: stmmac: move the EST lock to struct stmmac_priv  Reinitialize the whole EST structure would also reset the mutex lock which is embedded in the EST structure, and then trigger the following warning. To address this, move the lock to struct stmmac_priv. We also need to reacquire the mutex lock when doing this initialization.  DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: CPU: 3 PID: 505 at kernel/locking/mutex.c:587 __mutex_lock+0xd84/0x1068  Modules linked in:  CPU: 3 PID: 505 Comm: tc Not tainted 6.9.0-rc6-00053-g0106679839f7-dirty #29  Hardware name: NXP i.MX8MPlus EVK board (DT)  pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)  pc : __mutex_lock+0xd84/0x1068  lr : __mutex_lock+0xd84/0x1068  sp : ffffffc0864e3570  x29: ffffffc0864e3570 x28: ffffffc0817bdc78 x27: 0000000000000003  x26: ffffff80c54f1808 x25: ffffff80c9164080 x24: ffffffc080d723ac  x23: 0000000000000000 x22: 0000000000000002 x21: 0000000000000000  x20: 0000000000000000 x19: ffffffc083bc3000 x18: ffffffffffffffff  x17: ffffffc08117b080 x16: 0000000000000002 x15: ffffff80d2d40000  x14: 00000000000002da x13: ffffff80d2d404b8 x12: ffffffc082b5a5c8  x11: ffffffc082bca680 x10: ffffffc082bb2640 x9 : ffffffc082bb2698  x8 : 0000000000017fe8 x7 : c0000000ffffefff x6 : 0000000000000001  x5 : ffffff8178fe0d48 x4 : 0000000000000000 x3 : 0000000000000027  x2 : ffffff8178fe0d50 x1 : 0000000000000000 x0 : 0000000000000000  Call trace:   __mutex_lock+0xd84/0x1068   mutex_lock_nested+0x28/0x34   tc_setup_taprio+0x118/0x68c   stmmac_setup_tc+0x50/0xf0   taprio_change+0x868/0xc9c

CVE-2024-38608:

        In the Linux kernel, the following vulnerability has been resolved:  net/mlx5e: Fix netif state handling  mlx5e_suspend cleans resources only if netif_device_present() returns true. However, mlx5e_resume changes the state of netif, via mlx5e_nic_enable, only if reg_state == NETREG_REGISTERED. In the below case, the above leads to NULL-ptr Oops[1] and memory leaks:  mlx5e_probe  _mlx5e_resume   mlx5e_attach_netdev    mlx5e_nic_enable  <-- netdev not reg, not calling netif_device_attach()   register_netdev <-- failed for some reason. ERROR_FLOW:  _mlx5e_suspend <-- netif_device_present return false, resources aren't freed :(  Hence, clean resources in this case as well.  [1] BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: 0010 [#1] SMP CPU: 2 PID: 9345 Comm: test-ovs-ct-gen Not tainted 6.5.0_for_upstream_min_debug_2023_09_05_16_01 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:0x0 Code: Unable to access opcode bytes at0xffffffffffffffd6. RSP: 0018:ffff888178aaf758 EFLAGS: 00010246 Call Trace:  <TASK>  ? __die+0x20/0x60  ? page_fault_oops+0x14c/0x3c0  ? exc_page_fault+0x75/0x140  ? asm_exc_page_fault+0x22/0x30  notifier_call_chain+0x35/0xb0  blocking_notifier_call_chain+0x3d/0x60  mlx5_blocking_notifier_call_chain+0x22/0x30 [mlx5_core]  mlx5_core_uplink_netdev_event_replay+0x3e/0x60 [mlx5_core]  mlx5_mdev_netdev_track+0x53/0x60 [mlx5_ib]  mlx5_ib_roce_init+0xc3/0x340 [mlx5_ib]  __mlx5_ib_add+0x34/0xd0 [mlx5_ib]  mlx5r_probe+0xe1/0x210 [mlx5_ib]  ? auxiliary_match_id+0x6a/0x90  auxiliary_bus_probe+0x38/0x80  ? driver_sysfs_add+0x51/0x80  really_probe+0xc9/0x3e0  ? driver_probe_device+0x90/0x90  __driver_probe_device+0x80/0x160  driver_probe_device+0x1e/0x90  __device_attach_driver+0x7d/0x100  bus_for_each_drv+0x80/0xd0  __device_attach+0xbc/0x1f0  bus_probe_device+0x86/0xa0  device_add+0x637/0x840  __auxiliary_device_add+0x3b/0xa0  add_adev+0xc9/0x140 [mlx5_core]  mlx5_rescan_drivers_locked+0x22a/0x310 [mlx5_core]  mlx5_register_device+0x53/0xa0 [mlx5_core]  mlx5_init_one_devl_locked+0x5c4/0x9c0 [mlx5_core]  mlx5_init_one+0x3b/0x60 [mlx5_core]  probe_one+0x44c/0x730 [mlx5_core]  local_pci_probe+0x3e/0x90  pci_device_probe+0xbf/0x210  ? kernfs_create_link+0x5d/0xa0  ? sysfs_do_create_link_sd+0x60/0xc0  really_probe+0xc9/0x3e0  ? driver_probe_device+0x90/0x90  __driver_probe_device+0x80/0x160  driver_probe_device+0x1e/0x90  __device_attach_driver+0x7d/0x100  bus_for_each_drv+0x80/0xd0  __device_attach+0xbc/0x1f0  pci_bus_add_device+0x54/0x80  pci_iov_add_virtfn+0x2e6/0x320  sriov_enable+0x208/0x420  mlx5_core_sriov_configure+0x9e/0x200 [mlx5_core]  sriov_numvfs_store+0xae/0x1a0  kernfs_fop_write_iter+0x10c/0x1a0  vfs_write+0x291/0x3c0  ksys_write+0x5f/0xe0  do_syscall_64+0x3d/0x90  entry_SYSCALL_64_after_hwframe+0x46/0xb0  CR2: 0000000000000000  ---[ end trace 0000000000000000  ]---

CVE-2024-38622:

        In the Linux kernel, the following vulnerability has been resolved:  drm/msm/dpu: Add callback function pointer check before its call  In dpu_core_irq_callback_handler() callback function pointer is compared to NULL, but then callback function is unconditionally called by this pointer. Fix this bug by adding conditional return.  Found by Linux Verification Center (linuxtesting.org) with SVACE.  Patchwork: https://patchwork.freedesktop.org/patch/588237/

CVE-2024-38625:

        In the Linux kernel, the following vulnerability has been resolved:  fs/ntfs3: Check 'folio' pointer for NULL  It can be NULL if bmap is called.

CVE-2024-38630:

        In the Linux kernel, the following vulnerability has been resolved:  watchdog: cpu5wdt.c: Fix use-after-free bug caused by cpu5wdt_trigger  When the cpu5wdt module is removing, the origin code uses del_timer() to de-activate the timer. If the timer handler is running, del_timer() could not stop it and will return directly. If the port region is released by release_region() and then the timer handler cpu5wdt_trigger() calls outb() to write into the region that is released, the use-after-free bug will happen.  Change del_timer() to timer_shutdown_sync() in order that the timer handler could be finished before the port region is released.

CVE-2024-39508:

        In the Linux kernel, the following vulnerability has been resolved:  io_uring/io-wq: Use set_bit() and test_bit() at worker->flags  Utilize set_bit() and test_bit() on worker->flags within io_uring/io-wq to address potential data races.  The structure io_worker->flags may be accessed through various data paths, leading to concurrency issues. When KCSAN is enabled, it reveals data races occurring in io_worker_handle_work and io_wq_activate_free_worker functions.  	 BUG: KCSAN: data-race in io_worker_handle_work / io_wq_activate_free_worker 	 write to 0xffff8885c4246404 of 4 bytes by task 49071 on cpu 28: 	 io_worker_handle_work (io_uring/io-wq.c:434 io_uring/io-wq.c:569) 	 io_wq_worker (io_uring/io-wq.c:?) <snip>  	 read to 0xffff8885c4246404 of 4 bytes by task 49024 on cpu 5: 	 io_wq_activate_free_worker (io_uring/io-wq.c:? io_uring/io-wq.c:285) 	 io_wq_enqueue (io_uring/io-wq.c:947) 	 io_queue_iowq (io_uring/io_uring.c:524) 	 io_req_task_submit (io_uring/io_uring.c:1511) 	 io_handle_tw_list (io_uring/io_uring.c:1198) <snip>  Line numbers against commit 18daea77cca6 ("Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm").  These races involve writes and reads to the same memory location by different tasks running on different CPUs. To mitigate this, refactor the code to use atomic operations such as set_bit(), test_bit(), and clear_bit() instead of basic "and" and "or" operations. This ensures thread-safe manipulation of worker flags.  Also, move `create_index` to avoid holes in the structure.

CVE-2024-40965:

        In the Linux kernel, the following vulnerability has been resolved:  i2c: lpi2c: Avoid calling clk_get_rate during transfer  Instead of repeatedly calling clk_get_rate for each transfer, lock the clock rate and cache the value. A deadlock has been observed while adding tlv320aic32x4 audio codec to the system. When this clock provider adds its clock, the clk mutex is locked already, it needs to access i2c, which in return needs the mutex for clk_get_rate as well.

CVE-2024-40969:

        In the Linux kernel, the following vulnerability has been resolved:  f2fs: don't set RO when shutting down f2fs  Shutdown does not check the error of thaw_super due to readonly, which causes a deadlock like below.  f2fs_ioc_shutdown(F2FS_GOING_DOWN_FULLSYNC)        issue_discard_thread  - bdev_freeze   - freeze_super  - f2fs_stop_checkpoint()   - f2fs_handle_critical_error                     - sb_start_write     - set RO                                         - waiting  - bdev_thaw   - thaw_super_locked     - return -EINVAL, if sb_rdonly()  - f2fs_stop_discard_thread   -> wait for kthread_stop(discard_thread);

CVE-2024-40975:

        In the Linux kernel, the following vulnerability has been resolved:  platform/x86: x86-android-tablets: Unregister devices in reverse order  Not all subsystems support a device getting removed while there are still consumers of the device with a reference to the device.  One example of this is the regulator subsystem. If a regulator gets unregistered while there are still drivers holding a reference a WARN() at drivers/regulator/core.c:5829 triggers, e.g.:   WARNING: CPU: 1 PID: 1587 at drivers/regulator/core.c:5829 regulator_unregister  Hardware name: Intel Corp. VALLEYVIEW C0 PLATFORM/BYT-T FFD8, BIOS BLADE_21.X64.0005.R00.1504101516 FFD8_X64_R_2015_04_10_1516 04/10/2015  RIP: 0010:regulator_unregister  Call Trace:   <TASK>   regulator_unregister   devres_release_group   i2c_device_remove   device_release_driver_internal   bus_remove_device   device_del   device_unregister   x86_android_tablet_remove  On the Lenovo Yoga Tablet 2 series the bq24190 charger chip also provides a 5V boost converter output for powering USB devices connected to the micro USB port, the bq24190-charger driver exports this as a Vbus regulator.  On the 830 (8") and 1050 ("10") models this regulator is controlled by a platform_device and x86_android_tablet_remove() removes platform_device-s before i2c_clients so the consumer gets removed first.  But on the 1380 (13") model there is a lc824206xa micro-USB switch connected over I2C and the extcon driver for that controls the regulator. The bq24190 i2c-client *must* be registered first, because that creates the regulator with the lc824206xa listed as its consumer. If the regulator has not been registered yet the lc824206xa driver will end up getting a dummy regulator.  Since in this case both the regulator provider and consumer are I2C devices, the only way to ensure that the consumer is unregistered first is to unregister the I2C devices in reverse order of in which they were created.  For consistency and to avoid similar problems in the future change x86_android_tablet_remove() to unregister all device types in reverse order.

CVE-2024-40998:

        In the Linux kernel, the following vulnerability has been resolved:  ext4: fix uninitialized ratelimit_state->lock access in __ext4_fill_super()  In the following concurrency we will access the uninitialized rs->lock:  ext4_fill_super   ext4_register_sysfs    // sysfs registered msg_ratelimit_interval_ms                              // Other processes modify rs->interval to                              // non-zero via msg_ratelimit_interval_ms   ext4_orphan_cleanup     ext4_msg(sb, KERN_INFO, "Errors on filesystem, "       __ext4_msg         ___ratelimit(&(EXT4_SB(sb)->s_msg_ratelimit_state)           if (!rs->interval)  // do nothing if interval is 0             return 1;           raw_spin_trylock_irqsave(&rs->lock, flags)             raw_spin_trylock(lock)               _raw_spin_trylock                 __raw_spin_trylock                   spin_acquire(&lock->dep_map, 0, 1, _RET_IP_)                     lock_acquire                       __lock_acquire                         register_lock_class                           assign_lock_key                             dump_stack();   ratelimit_state_init(&sbi->s_msg_ratelimit_state, 5 * HZ, 10);     raw_spin_lock_init(&rs->lock);     // init rs->lock here  and get the following dump_stack:  ========================================================= INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 12 PID: 753 Comm: mount Tainted: G E 6.7.0-rc6-next-20231222 #504 [...] Call Trace:  dump_stack_lvl+0xc5/0x170  dump_stack+0x18/0x30  register_lock_class+0x740/0x7c0  __lock_acquire+0x69/0x13a0  lock_acquire+0x120/0x450  _raw_spin_trylock+0x98/0xd0  ___ratelimit+0xf6/0x220  __ext4_msg+0x7f/0x160 [ext4]  ext4_orphan_cleanup+0x665/0x740 [ext4]  __ext4_fill_super+0x21ea/0x2b10 [ext4]  ext4_fill_super+0x14d/0x360 [ext4] [...] =========================================================  Normally interval is 0 until s_msg_ratelimit_state is initialized, so ___ratelimit() does nothing. But registering sysfs precedes initializing rs->lock, so it is possible to change rs->interval to a non-zero value via the msg_ratelimit_interval_ms interface of sysfs while rs->lock is uninitialized, and then a call to ext4_msg triggers the problem by accessing an uninitialized rs->lock. Therefore register sysfs after all initializations are complete to avoid such problems.

CVE-2024-40999:

        In the Linux kernel, the following vulnerability has been resolved:  net: ena: Add validation for completion descriptors consistency  Validate that `first` flag is set only for the first descriptor in multi-buffer packets. In case of an invalid descriptor, a reset will occur. A new reset reason for RX data corruption has been added.

CVE-2024-41008:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu: change vm->task_info handling  This patch changes the handling and lifecycle of vm->task_info object. The major changes are: - vm->task_info is a dynamically allocated ptr now, and its uasge is   reference counted. - introducing two new helper funcs for task_info lifecycle management     - amdgpu_vm_get_task_info: reference counts up task_info before       returning this info     - amdgpu_vm_put_task_info: reference counts down task_info - last put to task_info() frees task_info from the vm.  This patch also does logistical changes required for existing usage of vm->task_info.  V2: Do not block all the prints when task_info not found (Felix)  V3: Fixed review comments from Felix    - Fix wrong indentation    - No debug message for -ENOMEM    - Add NULL check for task_info    - Do not duplicate the debug messages (ti vs no ti)    - Get first reference of task_info in vm_init(), put last      in vm_fini()  V4: Fixed review comments from Felix    - fix double reference increment in create_task_info    - change amdgpu_vm_get_task_info_pasid    - additional changes in amdgpu_gem.c while porting

CVE-2024-41023:

        In the Linux kernel, the following vulnerability has been resolved:  sched/deadline: Fix task_struct reference leak  During the execution of the following stress test with linux-rt:  stress-ng --cyclic 30 --timeout 30 --minimize --quiet  kmemleak frequently reported a memory leak concerning the task_struct:  unreferenced object 0xffff8881305b8000 (size 16136):   comm "stress-ng", pid 614, jiffies 4294883961 (age 286.412s)   object hex dump (first 32 bytes):     02 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00  .@..............     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................   debug hex dump (first 16 bytes):     53 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00  S...............   backtrace:     [<00000000046b6790>] dup_task_struct+0x30/0x540     [<00000000c5ca0f0b>] copy_process+0x3d9/0x50e0     [<00000000ced59777>] kernel_clone+0xb0/0x770     [<00000000a50befdc>] __do_sys_clone+0xb6/0xf0     [<000000001dbf2008>] do_syscall_64+0x5d/0xf0     [<00000000552900ff>] entry_SYSCALL_64_after_hwframe+0x6e/0x76  The issue occurs in start_dl_timer(), which increments the task_struct reference count and sets a timer. The timer callback, dl_task_timer, is supposed to decrement the reference count upon expiration. However, if enqueue_task_dl() is called before the timer expires and cancels it, the reference count is not decremented, leading to the leak.  This patch fixes the reference leak by ensuring the task_struct reference count is properly decremented when the timer is canceled.

CVE-2024-41031:

        In the Linux kernel, the following vulnerability has been resolved:  mm/filemap: skip to create PMD-sized page cache if needed  On ARM64, HPAGE_PMD_ORDER is 13 when the base page size is 64KB.  The PMD-sized page cache can't be supported by xarray as the following error messages indicate.  ------------[ cut here ]------------ WARNING: CPU: 35 PID: 7484 at lib/xarray.c:1025 xas_split_alloc+0xf8/0x128 Modules linked in: nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib  \ nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct    \ nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4    \ ip_set rfkill nf_tables nfnetlink vfat fat virtio_balloon drm      \ fuse xfs libcrc32c crct10dif_ce ghash_ce sha2_ce sha256_arm64      \ sha1_ce virtio_net net_failover virtio_console virtio_blk failover \ dimlib virtio_mmio CPU: 35 PID: 7484 Comm: test Kdump: loaded Tainted: G W 6.10.0-rc5-gavin+ #9 Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-1.el9 05/24/2024 pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : xas_split_alloc+0xf8/0x128 lr : split_huge_page_to_list_to_order+0x1c4/0x720 sp : ffff800087a4f6c0 x29: ffff800087a4f6c0 x28: ffff800087a4f720 x27: 000000001fffffff x26: 0000000000000c40 x25: 000000000000000d x24: ffff00010625b858 x23: ffff800087a4f720 x22: ffffffdfc0780000 x21: 0000000000000000 x20: 0000000000000000 x19: ffffffdfc0780000 x18: 000000001ff40000 x17: 00000000ffffffff x16: 0000018000000000 x15: 51ec004000000000 x14: 0000e00000000000 x13: 0000000000002000 x12: 0000000000000020 x11: 51ec000000000000 x10: 51ece1c0ffff8000 x9 : ffffbeb961a44d28 x8 : 0000000000000003 x7 : ffffffdfc0456420 x6 : ffff0000e1aa6eb8 x5 : 20bf08b4fe778fca x4 : ffffffdfc0456420 x3 : 0000000000000c40 x2 : 000000000000000d x1 : 000000000000000c x0 : 0000000000000000 Call trace:  xas_split_alloc+0xf8/0x128  split_huge_page_to_list_to_order+0x1c4/0x720  truncate_inode_partial_folio+0xdc/0x160  truncate_inode_pages_range+0x1b4/0x4a8  truncate_pagecache_range+0x84/0xa0  xfs_flush_unmap_range+0x70/0x90 [xfs]  xfs_file_fallocate+0xfc/0x4d8 [xfs]  vfs_fallocate+0x124/0x2e8  ksys_fallocate+0x4c/0xa0  __arm64_sys_fallocate+0x24/0x38  invoke_syscall.constprop.0+0x7c/0xd8  do_el0_svc+0xb4/0xd0  el0_svc+0x44/0x1d8  el0t_64_sync_handler+0x134/0x150  el0t_64_sync+0x17c/0x180  Fix it by skipping to allocate PMD-sized page cache when its size is larger than MAX_PAGECACHE_ORDER.  For this specific case, we will fall to regular path where the readahead window is determined by BDI's sysfs file (read_ahead_kb).

CVE-2024-41045:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: Defer work in bpf_timer_cancel_and_free  Currently, the same case as previous patch (two timer callbacks trying to cancel each other) can be invoked through bpf_map_update_elem as well, or more precisely, freeing map elements containing timers. Since this relies on hrtimer_cancel as well, it is prone to the same deadlock situation as the previous patch.  It would be sufficient to use hrtimer_try_to_cancel to fix this problem, as the timer cannot be enqueued after async_cancel_and_free. Once async_cancel_and_free has been done, the timer must be reinitialized before it can be armed again. The callback running in parallel trying to arm the timer will fail, and freeing bpf_hrtimer without waiting is sufficient (given kfree_rcu), and bpf_timer_cb will return HRTIMER_NORESTART, preventing the timer from being rearmed again.  However, there exists a UAF scenario where the callback arms the timer before entering this function, such that if cancellation fails (due to timer callback invoking this routine, or the target timer callback running concurrently). In such a case, if the timer expiration is significantly far in the future, the RCU grace period expiration happening before it will free the bpf_hrtimer state and along with it the struct hrtimer, that is enqueued.  Hence, it is clear cancellation needs to occur after async_cancel_and_free, and yet it cannot be done inline due to deadlock issues. We thus modify bpf_timer_cancel_and_free to defer work to the global workqueue, adding a work_struct alongside rcu_head (both used at _different_ points of time, so can share space).  Update existing code comments to reflect the new state of affairs.

CVE-2024-41082:

        In the Linux kernel, the following vulnerability has been resolved:  nvme-fabrics: use reserved tag for reg read/write command  In some scenarios, if too many commands are issued by nvme command in the same time by user tasks, this may exhaust all tags of admin_q. If a reset (nvme reset or IO timeout) occurs before these commands finish, reconnect routine may fail to update nvme regs due to insufficient tags, which will cause kernel hang forever. In order to workaround this issue, maybe we can let reg_read32()/reg_read64()/reg_write32() use reserved tags. This maybe safe for nvmf:  1. For the disable ctrl path,  we will not issue connect command 2. For the enable ctrl / fw activate path, since connect and reg_xx()    are called serially.  So the reserved tags may still be enough while reg_xx() use reserved tags.

CVE-2024-41935:

        In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to shrink read extent node in batches  We use rwlock to protect core structure data of extent tree during its shrink, however, if there is a huge number of extent nodes in extent tree, during shrink of extent tree, it may hold rwlock for a very long time, which may trigger kernel hang issue.  This patch fixes to shrink read extent node in batches, so that, critical region of the rwlock can be shrunk to avoid its extreme long time hold.

CVE-2024-42107:

        In the Linux kernel, the following vulnerability has been resolved:  ice: Don't process extts if PTP is disabled  The ice_ptp_extts_event() function can race with ice_ptp_release() and result in a NULL pointer dereference which leads to a kernel panic.  Panic occurs because the ice_ptp_extts_event() function calls ptp_clock_event() with a NULL pointer. The ice driver has already released the PTP clock by the time the interrupt for the next external timestamp event occurs.  To fix this, modify the ice_ptp_extts_event() function to check the PTP state and bail early if PTP is not ready.

CVE-2024-42118:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Do not return negative stream id for array  [WHY] resource_stream_to_stream_idx returns an array index and it return -1 when not found; however, -1 is not a valid array index number.  [HOW] When this happens, call ASSERT(), and return a zero instead.  This fixes an OVERRUN and an NEGATIVE_RETURNS issues reported by Coverity.

CVE-2024-42123:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu: fix double free err_addr pointer warnings  In amdgpu_umc_bad_page_polling_timeout, the amdgpu_umc_handle_bad_pages will be run many times so that double free err_addr in some special case. So set the err_addr to NULL to avoid the warnings.

CVE-2024-42128:

        In the Linux kernel, the following vulnerability has been resolved:  leds: an30259a: Use devm_mutex_init() for mutex initialization  In this driver LEDs are registered using devm_led_classdev_register() so they are automatically unregistered after module's remove() is done. led_classdev_unregister() calls module's led_set_brightness() to turn off the LEDs and that callback uses mutex which was destroyed already in module's remove() so use devm API instead.

CVE-2024-42139:

        In the Linux kernel, the following vulnerability has been resolved:  ice: Fix improper extts handling  Extts events are disabled and enabled by the application ts2phc. However, in case where the driver is removed when the application is running, a specific extts event remains enabled and can cause a kernel crash. As a side effect, when the driver is reloaded and application is started again, remaining extts event for the channel from a previous run will keep firing and the message "extts on unexpected channel" might be printed to the user.  To avoid that, extts events shall be disabled when PTP is released.

CVE-2024-42155:

        In the Linux kernel, the following vulnerability has been resolved:  s390/pkey: Wipe copies of protected- and secure-keys  Although the clear-key of neither protected- nor secure-keys is accessible, this key material should only be visible to the calling process. So wipe all copies of protected- or secure-keys from stack, even in case of an error.

CVE-2024-42156:

        In the Linux kernel, the following vulnerability has been resolved:  s390/pkey: Wipe copies of clear-key structures on failure  Wipe all sensitive data from stack for all IOCTLs, which convert a clear-key into a protected- or secure-key.

CVE-2024-42158:

        In the Linux kernel, the following vulnerability has been resolved:  s390/pkey: Use kfree_sensitive() to fix Coccinelle warnings  Replace memzero_explicit() and kfree() with kfree_sensitive() to fix warnings reported by Coccinelle:  WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1506) WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1643) WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1770)

CVE-2024-42162:

        In the Linux kernel, the following vulnerability has been resolved:  gve: Account for stopped queues when reading NIC stats  We now account for the fact that the NIC might send us stats for a subset of queues. Without this change, gve_get_ethtool_stats might make an invalid access on the priv->stats_report->stats array.

CVE-2024-42239:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: Fail bpf_timer_cancel when callback is being cancelled  Given a schedule:  timer1 cb			timer2 cb  bpf_timer_cancel(timer2);	bpf_timer_cancel(timer1);  Both bpf_timer_cancel calls would wait for the other callback to finish executing, introducing a lockup.  Add an atomic_t count named 'cancelling' in bpf_hrtimer. This keeps track of all in-flight cancellation requests for a given BPF timer. Whenever cancelling a BPF timer, we must check if we have outstanding cancellation requests, and if so, we must fail the operation with an error (-EDEADLK) since cancellation is synchronous and waits for the callback to finish executing. This implies that we can enter a deadlock situation involving two or more timer callbacks executing in parallel and attempting to cancel one another.  Note that we avoid incrementing the cancelling counter for the target timer (the one being cancelled) if bpf_timer_cancel is not invoked from a callback, to avoid spurious errors. The whole point of detecting cur->cancelling and returning -EDEADLK is to not enter a busy wait loop (which may or may not lead to a lockup). This does not apply in case the caller is in a non-callback context, the other side can continue to cancel as it sees fit without running into errors.  Background on prior attempts:  Earlier versions of this patch used a bool 'cancelling' bit and used the following pattern under timer->lock to publish cancellation status.  lock(t->lock); t->cancelling = true; mb(); if (cur->cancelling) 	return -EDEADLK; unlock(t->lock); hrtimer_cancel(t->timer); t->cancelling = false;  The store outside the critical section could overwrite a parallel requests t->cancelling assignment to true, to ensure the parallely executing callback observes its cancellation status.  It would be necessary to clear this cancelling bit once hrtimer_cancel is done, but lack of serialization introduced races. Another option was explored where bpf_timer_start would clear the bit when (re)starting the timer under timer->lock. This would ensure serialized access to the cancelling bit, but may allow it to be cleared before in-flight hrtimer_cancel has finished executing, such that lockups can occur again.  Thus, we choose an atomic counter to keep track of all outstanding cancellation requests and use it to prevent lockups in case callbacks attempt to cancel each other while executing in parallel.

CVE-2024-42241:

        In the Linux kernel, the following vulnerability has been resolved:  mm/shmem: disable PMD-sized page cache if needed  For shmem files, it's possible that PMD-sized page cache can't be supported by xarray.  For example, 512MB page cache on ARM64 when the base page size is 64KB can't be supported by xarray.  It leads to errors as the following messages indicate when this sort of xarray entry is split.  WARNING: CPU: 34 PID: 7578 at lib/xarray.c:1025 xas_split_alloc+0xf8/0x128 Modules linked in: binfmt_misc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6   \ nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject        \ nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4  \ ip_set rfkill nf_tables nfnetlink vfat fat virtio_balloon drm fuse xfs  \ libcrc32c crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce virtio_net \ net_failover virtio_console virtio_blk failover dimlib virtio_mmio CPU: 34 PID: 7578 Comm: test Kdump: loaded Tainted: G W 6.10.0-rc5-gavin+ #9 Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-1.el9 05/24/2024 pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : xas_split_alloc+0xf8/0x128 lr : split_huge_page_to_list_to_order+0x1c4/0x720 sp : ffff8000882af5f0 x29: ffff8000882af5f0 x28: ffff8000882af650 x27: ffff8000882af768 x26: 0000000000000cc0 x25: 000000000000000d x24: ffff00010625b858 x23: ffff8000882af650 x22: ffffffdfc0900000 x21: 0000000000000000 x20: 0000000000000000 x19: ffffffdfc0900000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000018000000000 x15: 52f8004000000000 x14: 0000e00000000000 x13: 0000000000002000 x12: 0000000000000020 x11: 52f8000000000000 x10: 52f8e1c0ffff6000 x9 : ffffbeb9619a681c x8 : 0000000000000003 x7 : 0000000000000000 x6 : ffff00010b02ddb0 x5 : ffffbeb96395e378 x4 : 0000000000000000 x3 : 0000000000000cc0 x2 : 000000000000000d x1 : 000000000000000c x0 : 0000000000000000 Call trace:  xas_split_alloc+0xf8/0x128  split_huge_page_to_list_to_order+0x1c4/0x720  truncate_inode_partial_folio+0xdc/0x160  shmem_undo_range+0x2bc/0x6a8  shmem_fallocate+0x134/0x430  vfs_fallocate+0x124/0x2e8  ksys_fallocate+0x4c/0xa0  __arm64_sys_fallocate+0x24/0x38  invoke_syscall.constprop.0+0x7c/0xd8  do_el0_svc+0xb4/0xd0  el0_svc+0x44/0x1d8  el0t_64_sync_handler+0x134/0x150  el0t_64_sync+0x17c/0x180  Fix it by disabling PMD-sized page cache when HPAGE_PMD_ORDER is larger than MAX_PAGECACHE_ORDER.  As Matthew Wilcox pointed, the page cache in a shmem file isn't represented by a multi-index entry and doesn't have this limitation when the xarry entry is split until commit 6b24ca4a1a8d ("mm: Use multi-index entries in the page cache").

CVE-2024-42243:

        In the Linux kernel, the following vulnerability has been resolved:  mm/filemap: make MAX_PAGECACHE_ORDER acceptable to xarray  Patch series "mm/filemap: Limit page cache size to that supported by xarray", v2.  Currently, xarray can't support arbitrary page cache size.  More details can be found from the WARN_ON() statement in xas_split_alloc().  In our test whose code is attached below, we hit the WARN_ON() on ARM64 system where the base page size is 64KB and huge page size is 512MB.  The issue was reported long time ago and some discussions on it can be found here [1].  [1] https://www.spinics.net/lists/linux-xfs/msg75404.html  In order to fix the issue, we need to adjust MAX_PAGECACHE_ORDER to one supported by xarray and avoid PMD-sized page cache if needed.  The code changes are suggested by David Hildenbrand.  PATCH[1] adjusts MAX_PAGECACHE_ORDER to that supported by xarray PATCH[2-3] avoids PMD-sized page cache in the synchronous readahead path PATCH[4] avoids PMD-sized page cache for shmem files if needed  Test program ============ # cat test.c #define _GNU_SOURCE #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <string.h> #include <fcntl.h> #include <errno.h> #include <sys/syscall.h> #include <sys/mman.h>  #define TEST_XFS_FILENAME	"/tmp/data" #define TEST_SHMEM_FILENAME	"/dev/shm/data" #define TEST_MEM_SIZE		0x20000000  int main(int argc, char **argv) { 	const char *filename; 	int fd = 0; 	void *buf = (void *)-1, *p; 	int pgsize = getpagesize(); 	int ret;  	if (pgsize != 0x10000) { 		fprintf(stderr, "64KB base page size is required\n"); 		return -EPERM; 	}  	system("echo force > /sys/kernel/mm/transparent_hugepage/shmem_enabled"); 	system("rm -fr /tmp/data"); 	system("rm -fr /dev/shm/data"); 	system("echo 1 > /proc/sys/vm/drop_caches");  	/* Open xfs or shmem file */ 	filename = TEST_XFS_FILENAME; 	if (argc > 1 && !strcmp(argv[1], "shmem")) 		filename = TEST_SHMEM_FILENAME;  	fd = open(filename, O_CREAT | O_RDWR | O_TRUNC); 	if (fd < 0) { 		fprintf(stderr, "Unable to open <%s>\n", filename); 		return -EIO; 	}  	/* Extend file size */ 	ret = ftruncate(fd, TEST_MEM_SIZE); 	if (ret) { 		fprintf(stderr, "Error %d to ftruncate()\n", ret); 		goto cleanup; 	}  	/* Create VMA */ 	buf = mmap(NULL, TEST_MEM_SIZE, 		   PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); 	if (buf == (void *)-1) { 		fprintf(stderr, "Unable to mmap <%s>\n", filename); 		goto cleanup; 	}  	fprintf(stdout, "mapped buffer at 0x%p\n", buf); 	ret = madvise(buf, TEST_MEM_SIZE, MADV_HUGEPAGE);         if (ret) { 		fprintf(stderr, "Unable to madvise(MADV_HUGEPAGE)\n"); 		goto cleanup; 	}  	/* Populate VMA */ 	ret = madvise(buf, TEST_MEM_SIZE, MADV_POPULATE_WRITE); 	if (ret) { 		fprintf(stderr, "Error %d to madvise(MADV_POPULATE_WRITE)\n", ret); 		goto cleanup; 	}  	/* Punch the file to enforce xarray split */ 	ret = fallocate(fd, FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE,         		TEST_MEM_SIZE - pgsize, pgsize); 	if (ret) 		fprintf(stderr, "Error %d to fallocate()\n", ret);  cleanup: 	if (buf != (void *)-1) 		munmap(buf, TEST_MEM_SIZE); 	if (fd > 0) 		close(fd);  	return 0; }  # gcc test.c -o test # cat /proc/1/smaps | grep KernelPageSize | head -n 1 KernelPageSize:       64 kB # ./test shmem    : ------------[ cut here ]------------ WARNING: CPU: 17 PID: 5253 at lib/xarray.c:1025 xas_split_alloc+0xf8/0x128 Modules linked in: nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib  \ nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct    \ nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4    \ ip_set nf_tables rfkill nfnetlink vfat fat virtio_balloon          \ drm fuse xfs libcrc32c crct10dif_ce ghash_ce sha2_ce sha256_arm64  \ virtio_net sha1_ce net_failover failover virtio_console virtio_blk \ dimlib virtio_mmio CPU: 17 PID: 5253 Comm: test Kdump: loaded Tainted: G W 6.10.0-rc5-gavin+ #12 Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-1.el9 05/24/2024 pstate: 83400005 (Nzcv daif +PAN -UAO +TC ---truncated---

CVE-2024-42279:

        In the Linux kernel, the following vulnerability has been resolved:  spi: microchip-core: ensure TX and RX FIFOs are empty at start of a transfer  While transmitting with rx_len == 0, the RX FIFO is not going to be emptied in the interrupt handler. A subsequent transfer could then read crap from the previous transfer out of the RX FIFO into the start RX buffer. The core provides a register that will empty the RX and TX FIFOs, so do that before each transfer.

CVE-2024-42317:

        In the Linux kernel, the following vulnerability has been resolved:  mm/huge_memory: avoid PMD-size page cache if needed  xarray can't support arbitrary page cache size.  the largest and supported page cache size is defined as MAX_PAGECACHE_ORDER by commit 099d90642a71 ("mm/filemap: make MAX_PAGECACHE_ORDER acceptable to xarray").  However, it's possible to have 512MB page cache in the huge memory's collapsing path on ARM64 system whose base page size is 64KB.  512MB page cache is breaking the limitation and a warning is raised when the xarray entry is split as shown in the following example.  [root@dhcp-10-26-1-207 ~]# cat /proc/1/smaps | grep KernelPageSize KernelPageSize:       64 kB [root@dhcp-10-26-1-207 ~]# cat /tmp/test.c    : int main(int argc, char **argv) { 	const char *filename = TEST_XFS_FILENAME; 	int fd = 0; 	void *buf = (void *)-1, *p; 	int pgsize = getpagesize(); 	int ret = 0;  	if (pgsize != 0x10000) { 		fprintf(stdout, "System with 64KB base page size is required!\n"); 		return -EPERM; 	}  	system("echo 0 > /sys/devices/virtual/bdi/253:0/read_ahead_kb"); 	system("echo 1 > /proc/sys/vm/drop_caches");  	/* Open the xfs file */ 	fd = open(filename, O_RDONLY); 	assert(fd > 0);  	/* Create VMA */ 	buf = mmap(NULL, TEST_MEM_SIZE, PROT_READ, MAP_SHARED, fd, 0); 	assert(buf != (void *)-1); 	fprintf(stdout, "mapped buffer at 0x%p\n", buf);  	/* Populate VMA */ 	ret = madvise(buf, TEST_MEM_SIZE, MADV_NOHUGEPAGE); 	assert(ret == 0); 	ret = madvise(buf, TEST_MEM_SIZE, MADV_POPULATE_READ); 	assert(ret == 0);  	/* Collapse VMA */ 	ret = madvise(buf, TEST_MEM_SIZE, MADV_HUGEPAGE); 	assert(ret == 0); 	ret = madvise(buf, TEST_MEM_SIZE, MADV_COLLAPSE); 	if (ret) { 		fprintf(stdout, "Error %d to madvise(MADV_COLLAPSE)\n", errno); 		goto out; 	}  	/* Split xarray entry. Write permission is needed */ 	munmap(buf, TEST_MEM_SIZE); 	buf = (void *)-1; 	close(fd); 	fd = open(filename, O_RDWR); 	assert(fd > 0); 	fallocate(fd, FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE,  		  TEST_MEM_SIZE - pgsize, pgsize); out: 	if (buf != (void *)-1) 		munmap(buf, TEST_MEM_SIZE); 	if (fd > 0) 		close(fd);  	return ret; }  [root@dhcp-10-26-1-207 ~]# gcc /tmp/test.c -o /tmp/test [root@dhcp-10-26-1-207 ~]# /tmp/test  ------------[ cut here ]------------  WARNING: CPU: 25 PID: 7560 at lib/xarray.c:1025 xas_split_alloc+0xf8/0x128  Modules linked in: nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib    \  nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct      \  nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4      \  ip_set rfkill nf_tables nfnetlink vfat fat virtio_balloon drm fuse   \  xfs libcrc32c crct10dif_ce ghash_ce sha2_ce sha256_arm64 virtio_net  \  sha1_ce net_failover virtio_blk virtio_console failover dimlib virtio_mmio  CPU: 25 PID: 7560 Comm: test Kdump: loaded Not tainted 6.10.0-rc7-gavin+ #9  Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-1.el9 05/24/2024  pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)  pc : xas_split_alloc+0xf8/0x128  lr : split_huge_page_to_list_to_order+0x1c4/0x780  sp : ffff8000ac32f660  x29: ffff8000ac32f660 x28: ffff0000e0969eb0 x27: ffff8000ac32f6c0  x26: 0000000000000c40 x25: ffff0000e0969eb0 x24: 000000000000000d  x23: ffff8000ac32f6c0 x22: ffffffdfc0700000 x21: 0000000000000000  x20: 0000000000000000 x19: ffffffdfc0700000 x18: 0000000000000000  x17: 0000000000000000 x16: ffffd5f3708ffc70 x15: 0000000000000000  x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000  x11: ffffffffffffffc0 x10: 0000000000000040 x9 : ffffd5f3708e692c  x8 : 0000000000000003 x7 : 0000000000000000 x6 : ffff0000e0969eb8  x5 : ffffd5f37289e378 x4 : 0000000000000000 x3 : 0000000000000c40  x2 : 000000000000000d x1 : 000000000000000c x0 : 0000000000000000  Call trace:   xas_split_alloc+0xf8/0x128   split_huge_page_to_list_to_order+0x1c4/0x780   truncate_inode_partial_folio+0xdc/0x160   truncate_inode_pages_range+0x1b4/0x4a8   truncate_pagecache_range+0x84/0xa ---truncated---

CVE-2024-43819:

        In the Linux kernel, the following vulnerability has been resolved:  kvm: s390: Reject memory region operations for ucontrol VMs  This change rejects the KVM_SET_USER_MEMORY_REGION and KVM_SET_USER_MEMORY_REGION2 ioctls when called on a ucontrol VM. This is necessary since ucontrol VMs have kvm->arch.gmap set to 0 and would thus result in a null pointer dereference further in. Memory management needs to be performed in userspace and using the ioctls KVM_S390_UCAS_MAP and KVM_S390_UCAS_UNMAP.  Also improve s390 specific documentation for KVM_SET_USER_MEMORY_REGION and KVM_SET_USER_MEMORY_REGION2.  [frankja@linux.ibm.com: commit message spelling fix, subject prefix fix]

CVE-2024-43824:

        In the Linux kernel, the following vulnerability has been resolved:  PCI: endpoint: pci-epf-test: Make use of cached 'epc_features' in pci_epf_test_core_init()  Instead of getting the epc_features from pci_epc_get_features() API, use the cached pci_epf_test::epc_features value to avoid the NULL check. Since the NULL check is already performed in pci_epf_test_bind(), having one more check in pci_epf_test_core_init() is redundant and it is not possible to hit the NULL pointer dereference.  Also with commit a01e7214bef9 ("PCI: endpoint: Remove "core_init_notifier" flag"), 'epc_features' got dereferenced without the NULL check, leading to the following false positive Smatch warning:    drivers/pci/endpoint/functions/pci-epf-test.c:784 pci_epf_test_core_init() error: we previously assumed 'epc_features' could be null (see line 747)  Thus, remove the redundant NULL check and also use the epc_features:: {msix_capable/msi_capable} flags directly to avoid local variables.  [kwilczynski: commit log]

CVE-2024-43850:

        In the Linux kernel, the following vulnerability has been resolved:  soc: qcom: icc-bwmon: Fix refcount imbalance seen during bwmon_remove  The following warning is seen during bwmon_remove due to refcount imbalance, fix this by releasing the OPPs after use.  Logs: WARNING: at drivers/opp/core.c:1640 _opp_table_kref_release+0x150/0x158 Hardware name: Qualcomm Technologies, Inc. X1E80100 CRD (DT) ... Call trace: _opp_table_kref_release+0x150/0x158 dev_pm_opp_remove_table+0x100/0x1b4 devm_pm_opp_of_table_release+0x10/0x1c devm_action_release+0x14/0x20 devres_release_all+0xa4/0x104 device_unbind_cleanup+0x18/0x60 device_release_driver_internal+0x1ec/0x228 driver_detach+0x50/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 platform_driver_unregister+0x14/0x20 bwmon_driver_exit+0x18/0x524 [icc_bwmon] __arm64_sys_delete_module+0x184/0x264 invoke_syscall+0x48/0x118 el0_svc_common.constprop.0+0xc8/0xe8 do_el0_svc+0x20/0x2c el0_svc+0x34/0xdc el0t_64_sync_handler+0x13c/0x158 el0t_64_sync+0x190/0x194 --[ end trace 0000000000000000 ]---

CVE-2024-43872:

        In the Linux kernel, the following vulnerability has been resolved:  RDMA/hns: Fix soft lockup under heavy CEQE load  CEQEs are handled in interrupt handler currently. This may cause the CPU core staying in interrupt context too long and lead to soft lockup under heavy load.  Handle CEQEs in BH workqueue and set an upper limit for the number of CEQE handled by a single call of work handler.

CVE-2024-43899:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Fix null pointer deref in dcn20_resource.c  Fixes a hang thats triggered when MPV is run on a DCN401 dGPU:  mpv --hwdec=vaapi --vo=gpu --hwdec-codecs=all  and then enabling fullscreen playback (double click on the video)  The following calltrace will be seen:  [  181.843989] BUG: kernel NULL pointer dereference, address: 0000000000000000 [  181.843997] #PF: supervisor instruction fetch in kernel mode [  181.844003] #PF: error_code(0x0010) - not-present page [  181.844009] PGD 0 P4D 0 [  181.844020] Oops: 0010 [#1] PREEMPT SMP NOPTI [  181.844028] CPU: 6 PID: 1892 Comm: gnome-shell Tainted: G        W  OE      6.5.0-41-generic #41~22.04.2-Ubuntu [  181.844038] Hardware name: System manufacturer System Product Name/CROSSHAIR VI HERO, BIOS 6302 10/23/2018 [  181.844044] RIP: 0010:0x0 [  181.844079] Code: Unable to access opcode bytes at 0xffffffffffffffd6. [  181.844084] RSP: 0018:ffffb593c2b8f7b0 EFLAGS: 00010246 [  181.844093] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000004 [  181.844099] RDX: ffffb593c2b8f804 RSI: ffffb593c2b8f7e0 RDI: ffff9e3c8e758400 [  181.844105] RBP: ffffb593c2b8f7b8 R08: ffffb593c2b8f9c8 R09: ffffb593c2b8f96c [  181.844110] R10: 0000000000000000 R11: 0000000000000000 R12: ffffb593c2b8f9c8 [  181.844115] R13: 0000000000000001 R14: ffff9e3c88000000 R15: 0000000000000005 [  181.844121] FS:  00007c6e323bb5c0(0000) GS:ffff9e3f85f80000(0000) knlGS:0000000000000000 [  181.844128] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [  181.844134] CR2: ffffffffffffffd6 CR3: 0000000140fbe000 CR4: 00000000003506e0 [  181.844141] Call Trace: [  181.844146]  <TASK> [  181.844153]  ? show_regs+0x6d/0x80 [  181.844167]  ? __die+0x24/0x80 [  181.844179]  ? page_fault_oops+0x99/0x1b0 [  181.844192]  ? do_user_addr_fault+0x31d/0x6b0 [  181.844204]  ? exc_page_fault+0x83/0x1b0 [  181.844216]  ? asm_exc_page_fault+0x27/0x30 [  181.844237]  dcn20_get_dcc_compression_cap+0x23/0x30 [amdgpu] [  181.845115]  amdgpu_dm_plane_validate_dcc.constprop.0+0xe5/0x180 [amdgpu] [  181.845985]  amdgpu_dm_plane_fill_plane_buffer_attributes+0x300/0x580 [amdgpu] [  181.846848]  fill_dc_plane_info_and_addr+0x258/0x350 [amdgpu] [  181.847734]  fill_dc_plane_attributes+0x162/0x350 [amdgpu] [  181.848748]  dm_update_plane_state.constprop.0+0x4e3/0x6b0 [amdgpu] [  181.849791]  ? dm_update_plane_state.constprop.0+0x4e3/0x6b0 [amdgpu] [  181.850840]  amdgpu_dm_atomic_check+0xdfe/0x1760 [amdgpu]

CVE-2024-43901:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Fix NULL pointer dereference for DTN log in DCN401  When users run the command:  cat /sys/kernel/debug/dri/0/amdgpu_dm_dtn_log  The following NULL pointer dereference happens:  [  +0.000003] BUG: kernel NULL pointer dereference, address: NULL [  +0.000005] #PF: supervisor instruction fetch in kernel mode [  +0.000002] #PF: error_code(0x0010) - not-present page [  +0.000002] PGD 0 P4D 0 [  +0.000004] Oops: 0010 [#1] PREEMPT SMP NOPTI [  +0.000003] RIP: 0010:0x0 [  +0.000008] Code: Unable to access opcode bytes at 0xffffffffffffffd6. [...] [  +0.000002] PKRU: 55555554 [  +0.000002] Call Trace: [  +0.000002]  <TASK> [  +0.000003]  ? show_regs+0x65/0x70 [  +0.000006]  ? __die+0x24/0x70 [  +0.000004]  ? page_fault_oops+0x160/0x470 [  +0.000006]  ? do_user_addr_fault+0x2b5/0x690 [  +0.000003]  ? prb_read_valid+0x1c/0x30 [  +0.000005]  ? exc_page_fault+0x8c/0x1a0 [  +0.000005]  ? asm_exc_page_fault+0x27/0x30 [  +0.000012]  dcn10_log_color_state+0xf9/0x510 [amdgpu] [  +0.000306]  ? srso_alias_return_thunk+0x5/0xfbef5 [  +0.000003]  ? vsnprintf+0x2fb/0x600 [  +0.000009]  dcn10_log_hw_state+0xfd0/0xfe0 [amdgpu] [  +0.000218]  ? __mod_memcg_lruvec_state+0xe8/0x170 [  +0.000008]  ? srso_alias_return_thunk+0x5/0xfbef5 [  +0.000002]  ? debug_smp_processor_id+0x17/0x20 [  +0.000003]  ? srso_alias_return_thunk+0x5/0xfbef5 [  +0.000002]  ? srso_alias_return_thunk+0x5/0xfbef5 [  +0.000002]  ? set_ptes.isra.0+0x2b/0x90 [  +0.000004]  ? srso_alias_return_thunk+0x5/0xfbef5 [  +0.000002]  ? _raw_spin_unlock+0x19/0x40 [  +0.000004]  ? srso_alias_return_thunk+0x5/0xfbef5 [  +0.000002]  ? do_anonymous_page+0x337/0x700 [  +0.000004]  dtn_log_read+0x82/0x120 [amdgpu] [  +0.000207]  full_proxy_read+0x66/0x90 [  +0.000007]  vfs_read+0xb0/0x340 [  +0.000005]  ? __count_memcg_events+0x79/0xe0 [  +0.000002]  ? srso_alias_return_thunk+0x5/0xfbef5 [  +0.000003]  ? count_memcg_events.constprop.0+0x1e/0x40 [  +0.000003]  ? handle_mm_fault+0xb2/0x370 [  +0.000003]  ksys_read+0x6b/0xf0 [  +0.000004]  __x64_sys_read+0x19/0x20 [  +0.000003]  do_syscall_64+0x60/0x130 [  +0.000004]  entry_SYSCALL_64_after_hwframe+0x6e/0x76 [  +0.000003] RIP: 0033:0x7fdf32f147e2 [...]  This error happens when the color log tries to read the gamut remap information from DCN401 which is not initialized in the dcn401_dpp_funcs which leads to a null pointer dereference. This commit addresses this issue by adding a proper guard to access the gamut_remap callback in case the specific ASIC did not implement this function.

CVE-2024-43913:

        In the Linux kernel, the following vulnerability has been resolved:  nvme: apple: fix device reference counting  Drivers must call nvme_uninit_ctrl after a successful nvme_init_ctrl. Split the allocation side out to make the error handling boundary easier to navigate. The apple driver had been doing this wrong, leaking the controller device memory on a tagset failure.

CVE-2024-44941:

        In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to cover read extent cache access with lock  syzbot reports a f2fs bug as below:  BUG: KASAN: slab-use-after-free in sanity_check_extent_cache+0x370/0x410 fs/f2fs/extent_cache.c:46 Read of size 4 at addr ffff8880739ab220 by task syz-executor200/5097  CPU: 0 PID: 5097 Comm: syz-executor200 Not tainted 6.9.0-rc6-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Call Trace:  <TASK>  __dump_stack lib/dump_stack.c:88 [inline]  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114  print_address_description mm/kasan/report.c:377 [inline]  print_report+0x169/0x550 mm/kasan/report.c:488  kasan_report+0x143/0x180 mm/kasan/report.c:601  sanity_check_extent_cache+0x370/0x410 fs/f2fs/extent_cache.c:46  do_read_inode fs/f2fs/inode.c:509 [inline]  f2fs_iget+0x33e1/0x46e0 fs/f2fs/inode.c:560  f2fs_nfs_get_inode+0x74/0x100 fs/f2fs/super.c:3237  generic_fh_to_dentry+0x9f/0xf0 fs/libfs.c:1413  exportfs_decode_fh_raw+0x152/0x5f0 fs/exportfs/expfs.c:444  exportfs_decode_fh+0x3c/0x80 fs/exportfs/expfs.c:584  do_handle_to_path fs/fhandle.c:155 [inline]  handle_to_path fs/fhandle.c:210 [inline]  do_handle_open+0x495/0x650 fs/fhandle.c:226  do_syscall_x64 arch/x86/entry/common.c:52 [inline]  do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  We missed to cover sanity_check_extent_cache() w/ extent cache lock, so, below race case may happen, result in use after free issue.  - f2fs_iget  - do_read_inode   - f2fs_init_read_extent_tree   : add largest extent entry in to cache 					- shrink 					 - f2fs_shrink_read_extent_tree 					  - __shrink_extent_tree 					   - __detach_extent_node 					   : drop largest extent entry   - sanity_check_extent_cache   : access et->largest w/o lock  let's refactor sanity_check_extent_cache() to avoid extent cache access and call it before f2fs_init_read_extent_tree() to fix this issue.

CVE-2024-44942:

        In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to do sanity check on F2FS_INLINE_DATA flag in inode during GC  syzbot reports a f2fs bug as below:  ------------[ cut here ]------------ kernel BUG at fs/f2fs/inline.c:258! CPU: 1 PID: 34 Comm: kworker/u8:2 Not tainted 6.9.0-rc6-syzkaller-00012-g9e4bc4bcae01 #0 RIP: 0010:f2fs_write_inline_data+0x781/0x790 fs/f2fs/inline.c:258 Call Trace:  f2fs_write_single_data_page+0xb65/0x1d60 fs/f2fs/data.c:2834  f2fs_write_cache_pages fs/f2fs/data.c:3133 [inline]  __f2fs_write_data_pages fs/f2fs/data.c:3288 [inline]  f2fs_write_data_pages+0x1efe/0x3a90 fs/f2fs/data.c:3315  do_writepages+0x35b/0x870 mm/page-writeback.c:2612  __writeback_single_inode+0x165/0x10b0 fs/fs-writeback.c:1650  writeback_sb_inodes+0x905/0x1260 fs/fs-writeback.c:1941  wb_writeback+0x457/0xce0 fs/fs-writeback.c:2117  wb_do_writeback fs/fs-writeback.c:2264 [inline]  wb_workfn+0x410/0x1090 fs/fs-writeback.c:2304  process_one_work kernel/workqueue.c:3254 [inline]  process_scheduled_works+0xa12/0x17c0 kernel/workqueue.c:3335  worker_thread+0x86d/0xd70 kernel/workqueue.c:3416  kthread+0x2f2/0x390 kernel/kthread.c:388  ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244  The root cause is: inline_data inode can be fuzzed, so that there may be valid blkaddr in its direct node, once f2fs triggers background GC to migrate the block, it will hit f2fs_bug_on() during dirty page writeback.  Let's add sanity check on F2FS_INLINE_DATA flag in inode during GC, so that, it can forbid migrating inline_data inode's data block for fixing.

CVE-2024-44951:

        In the Linux kernel, the following vulnerability has been resolved:  serial: sc16is7xx: fix TX fifo corruption  Sometimes, when a packet is received on channel A at almost the same time as a packet is about to be transmitted on channel B, we observe with a logic analyzer that the received packet on channel A is transmitted on channel B. In other words, the Tx buffer data on channel B is corrupted with data from channel A.  The problem appeared since commit 4409df5866b7 ("serial: sc16is7xx: change EFR lock to operate on each channels"), which changed the EFR locking to operate on each channel instead of chip-wise.  This commit has introduced a regression, because the EFR lock is used not only to protect the EFR registers access, but also, in a very obscure and undocumented way, to protect access to the data buffer, which is shared by the Tx and Rx handlers, but also by each channel of the IC.  Fix this regression first by switching to kfifo_out_linear_ptr() in sc16is7xx_handle_tx() to eliminate the need for a shared Rx/Tx buffer.  Secondly, replace the chip-wise Rx buffer with a separate Rx buffer for each channel.

CVE-2024-44963:

        In the Linux kernel, the following vulnerability has been resolved:  btrfs: do not BUG_ON() when freeing tree block after error  When freeing a tree block, at btrfs_free_tree_block(), if we fail to create a delayed reference we don't deal with the error and just do a BUG_ON(). The error most likely to happen is -ENOMEM, and we have a comment mentioning that only -ENOMEM can happen, but that is not true, because in case qgroups are enabled any error returned from btrfs_qgroup_trace_extent_post() (can be -EUCLEAN or anything returned from btrfs_search_slot() for example) can be propagated back to btrfs_free_tree_block().  So stop doing a BUG_ON() and return the error to the callers and make them abort the transaction to prevent leaking space. Syzbot was triggering this, likely due to memory allocation failure injection.

CVE-2024-45015:

        In the Linux kernel, the following vulnerability has been resolved:  drm/msm/dpu: move dpu_encoder's connector assignment to atomic_enable()  For cases where the crtc's connectors_changed was set without enable/active getting toggled , there is an atomic_enable() call followed by an atomic_disable() but without an atomic_mode_set().  This results in a NULL ptr access for the dpu_encoder_get_drm_fmt() call in the atomic_enable() as the dpu_encoder's connector was cleared in the atomic_disable() but not re-assigned as there was no atomic_mode_set() call.  Fix the NULL ptr access by moving the assignment for atomic_enable() and also use drm_atomic_get_new_connector_for_encoder() to get the connector from the atomic_state.  Patchwork: https://patchwork.freedesktop.org/patch/606729/

CVE-2024-46678:

        In the Linux kernel, the following vulnerability has been resolved:  bonding: change ipsec_lock from spin lock to mutex  In the cited commit, bond->ipsec_lock is added to protect ipsec_list, hence xdo_dev_state_add and xdo_dev_state_delete are called inside this lock. As ipsec_lock is a spin lock and such xfrmdev ops may sleep, "scheduling while atomic" will be triggered when changing bond's active slave.  [  101.055189] BUG: scheduling while atomic: bash/902/0x00000200 [  101.055726] Modules linked in: [  101.058211] CPU: 3 PID: 902 Comm: bash Not tainted 6.9.0-rc4+ #1 [  101.058760] Hardware name: [  101.059434] Call Trace: [  101.059436]  <TASK> [  101.060873]  dump_stack_lvl+0x51/0x60 [  101.061275]  __schedule_bug+0x4e/0x60 [  101.061682]  __schedule+0x612/0x7c0 [  101.062078]  ? __mod_timer+0x25c/0x370 [  101.062486]  schedule+0x25/0xd0 [  101.062845]  schedule_timeout+0x77/0xf0 [  101.063265]  ? asm_common_interrupt+0x22/0x40 [  101.063724]  ? __bpf_trace_itimer_state+0x10/0x10 [  101.064215]  __wait_for_common+0x87/0x190 [  101.064648]  ? usleep_range_state+0x90/0x90 [  101.065091]  cmd_exec+0x437/0xb20 [mlx5_core] [  101.065569]  mlx5_cmd_do+0x1e/0x40 [mlx5_core] [  101.066051]  mlx5_cmd_exec+0x18/0x30 [mlx5_core] [  101.066552]  mlx5_crypto_create_dek_key+0xea/0x120 [mlx5_core] [  101.067163]  ? bonding_sysfs_store_option+0x4d/0x80 [bonding] [  101.067738]  ? kmalloc_trace+0x4d/0x350 [  101.068156]  mlx5_ipsec_create_sa_ctx+0x33/0x100 [mlx5_core] [  101.068747]  mlx5e_xfrm_add_state+0x47b/0xaa0 [mlx5_core] [  101.069312]  bond_change_active_slave+0x392/0x900 [bonding] [  101.069868]  bond_option_active_slave_set+0x1c2/0x240 [bonding] [  101.070454]  __bond_opt_set+0xa6/0x430 [bonding] [  101.070935]  __bond_opt_set_notify+0x2f/0x90 [bonding] [  101.071453]  bond_opt_tryset_rtnl+0x72/0xb0 [bonding] [  101.071965]  bonding_sysfs_store_option+0x4d/0x80 [bonding] [  101.072567]  kernfs_fop_write_iter+0x10c/0x1a0 [  101.073033]  vfs_write+0x2d8/0x400 [  101.073416]  ? alloc_fd+0x48/0x180 [  101.073798]  ksys_write+0x5f/0xe0 [  101.074175]  do_syscall_64+0x52/0x110 [  101.074576]  entry_SYSCALL_64_after_hwframe+0x4b/0x53  As bond_ipsec_add_sa_all and bond_ipsec_del_sa_all are only called from bond_change_active_slave, which requires holding the RTNL lock. And bond_ipsec_add_sa and bond_ipsec_del_sa are xfrm state xdo_dev_state_add and xdo_dev_state_delete APIs, which are in user context. So ipsec_lock doesn't have to be spin lock, change it to mutex, and thus the above issue can be resolved.

CVE-2024-46681:

        In the Linux kernel, the following vulnerability has been resolved:  pktgen: use cpus_read_lock() in pg_net_init()  I have seen the WARN_ON(smp_processor_id() != cpu) firing in pktgen_thread_worker() during tests.  We must use cpus_read_lock()/cpus_read_unlock() around the for_each_online_cpu(cpu) loop.  While we are at it use WARN_ON_ONCE() to avoid a possible syslog flood.

CVE-2024-46698:

        In the Linux kernel, the following vulnerability has been resolved:  video/aperture: optionally match the device in sysfb_disable()  In aperture_remove_conflicting_pci_devices(), we currently only call sysfb_disable() on vga class devices.  This leads to the following problem when the pimary device is not VGA compatible:  1. A PCI device with a non-VGA class is the boot display 2. That device is probed first and it is not a VGA device so    sysfb_disable() is not called, but the device resources    are freed by aperture_detach_platform_device() 3. Non-primary GPU has a VGA class and it ends up calling sysfb_disable() 4. NULL pointer dereference via sysfb_disable() since the resources    have already been freed by aperture_detach_platform_device() when    it was called by the other device.  Fix this by passing a device pointer to sysfb_disable() and checking the device to determine if we should execute it or not.  v2: Fix build when CONFIG_SCREEN_INFO is not set v3: Move device check into the mutex     Drop primary variable in aperture_remove_conflicting_pci_devices()     Drop __init on pci sysfb_pci_dev_is_enabled()

CVE-2024-46727:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Add otg_master NULL check within resource_log_pipe_topology_update  [Why] Coverity reports NULL_RETURN warning.  [How] Add otg_master NULL check.

CVE-2024-46728:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Check index for aux_rd_interval before using  aux_rd_interval has size of 7 and should be checked.  This fixes 3 OVERRUN and 1 INTEGER_OVERFLOW issues reported by Coverity.

CVE-2024-46729:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Fix incorrect size calculation for loop  [WHY] fe_clk_en has size of 5 but sizeof(fe_clk_en) has byte size 20 which is lager than the array size.  [HOW] Divide byte size 20 by its element size.  This fixes 2 OVERRUN issues reported by Coverity.

CVE-2024-46730:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Ensure array index tg_inst won't be -1  [WHY & HOW] tg_inst will be a negative if timing_generator_count equals 0, which should be checked before used.  This fixes 2 OVERRUN issues reported by Coverity.

CVE-2024-46760:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: rtw88: usb: schedule rx work after everything is set up  Right now it's possible to hit NULL pointer dereference in rtw_rx_fill_rx_status on hw object and/or its fields because initialization routine can start getting USB replies before rtw_dev is fully setup.  The stack trace looks like this:  rtw_rx_fill_rx_status rtw8821c_query_rx_desc rtw_usb_rx_handler ... queue_work rtw_usb_read_port_complete ... usb_submit_urb rtw_usb_rx_resubmit rtw_usb_init_rx rtw_usb_probe  So while we do the async stuff rtw_usb_probe continues and calls rtw_register_hw, which does all kinds of initialization (e.g. via ieee80211_register_hw) that rtw_rx_fill_rx_status relies on.  Fix this by moving the first usb_submit_urb after everything is set up.  For me, this bug manifested as: [    8.893177] rtw_8821cu 1-1:1.2: band wrong, packet dropped [    8.910904] rtw_8821cu 1-1:1.2: hw->conf.chandef.chan NULL in rtw_rx_fill_rx_status because I'm using Larry's backport of rtw88 driver with the NULL checks in rtw_rx_fill_rx_status.

CVE-2024-46765:

        In the Linux kernel, the following vulnerability has been resolved:  ice: protect XDP configuration with a mutex  The main threat to data consistency in ice_xdp() is a possible asynchronous PF reset. It can be triggered by a user or by TX timeout handler.  XDP setup and PF reset code access the same resources in the following sections: * ice_vsi_close() in ice_prepare_for_reset() - already rtnl-locked * ice_vsi_rebuild() for the PF VSI - not protected * ice_vsi_open() - already rtnl-locked  With an unfortunate timing, such accesses can result in a crash such as the one below:  [ +1.999878] ice 0000:b1:00.0: Registered XDP mem model MEM_TYPE_XSK_BUFF_POOL on Rx ring 14 [ +2.002992] ice 0000:b1:00.0: Registered XDP mem model MEM_TYPE_XSK_BUFF_POOL on Rx ring 18 [Mar15 18:17] ice 0000:b1:00.0 ens801f0np0: NETDEV WATCHDOG: CPU: 38: transmit queue 14 timed out 80692736 ms [ +0.000093] ice 0000:b1:00.0 ens801f0np0: tx_timeout: VSI_num: 6, Q 14, NTC: 0x0, HW_HEAD: 0x0, NTU: 0x0, INT: 0x4000001 [ +0.000012] ice 0000:b1:00.0 ens801f0np0: tx_timeout recovery level 1, txqueue 14 [ +0.394718] ice 0000:b1:00.0: PTP reset successful [ +0.006184] BUG: kernel NULL pointer dereference, address: 0000000000000098 [ +0.000045] #PF: supervisor read access in kernel mode [ +0.000023] #PF: error_code(0x0000) - not-present page [ +0.000023] PGD 0 P4D 0 [ +0.000018] Oops: 0000 [#1] PREEMPT SMP NOPTI [ +0.000023] CPU: 38 PID: 7540 Comm: kworker/38:1 Not tainted 6.8.0-rc7 #1 [ +0.000031] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0014.082620210524 08/26/2021 [ +0.000036] Workqueue: ice ice_service_task [ice] [ +0.000183] RIP: 0010:ice_clean_tx_ring+0xa/0xd0 [ice] [...] [ +0.000013] Call Trace: [ +0.000016] <TASK> [ +0.000014] ? __die+0x1f/0x70 [ +0.000029] ? page_fault_oops+0x171/0x4f0 [ +0.000029] ? schedule+0x3b/0xd0 [ +0.000027] ? exc_page_fault+0x7b/0x180 [ +0.000022] ? asm_exc_page_fault+0x22/0x30 [ +0.000031] ? ice_clean_tx_ring+0xa/0xd0 [ice] [ +0.000194] ice_free_tx_ring+0xe/0x60 [ice] [ +0.000186] ice_destroy_xdp_rings+0x157/0x310 [ice] [ +0.000151] ice_vsi_decfg+0x53/0xe0 [ice] [ +0.000180] ice_vsi_rebuild+0x239/0x540 [ice] [ +0.000186] ice_vsi_rebuild_by_type+0x76/0x180 [ice] [ +0.000145] ice_rebuild+0x18c/0x840 [ice] [ +0.000145] ? delay_tsc+0x4a/0xc0 [ +0.000022] ? delay_tsc+0x92/0xc0 [ +0.000020] ice_do_reset+0x140/0x180 [ice] [ +0.000886] ice_service_task+0x404/0x1030 [ice] [ +0.000824] process_one_work+0x171/0x340 [ +0.000685] worker_thread+0x277/0x3a0 [ +0.000675] ? preempt_count_add+0x6a/0xa0 [ +0.000677] ? _raw_spin_lock_irqsave+0x23/0x50 [ +0.000679] ? __pfx_worker_thread+0x10/0x10 [ +0.000653] kthread+0xf0/0x120 [ +0.000635] ? __pfx_kthread+0x10/0x10 [ +0.000616] ret_from_fork+0x2d/0x50 [ +0.000612] ? __pfx_kthread+0x10/0x10 [ +0.000604] ret_from_fork_asm+0x1b/0x30 [ +0.000604] </TASK>  The previous way of handling this through returning -EBUSY is not viable, particularly when destroying AF_XDP socket, because the kernel proceeds with removal anyway.  There is plenty of code between those calls and there is no need to create a large critical section that covers all of them, same as there is no need to protect ice_vsi_rebuild() with rtnl_lock().  Add xdp_state_lock mutex to protect ice_vsi_rebuild() and ice_xdp().  Leaving unprotected sections in between would result in two states that have to be considered: 1. when the VSI is closed, but not yet rebuild 2. when VSI is already rebuild, but not yet open  The latter case is actually already handled through !netif_running() case, we just need to adjust flag checking a little. The former one is not as trivial, because between ice_vsi_close() and ice_vsi_rebuild(), a lot of hardware interaction happens, this can make adding/deleting rings exit with an error. Luckily, VSI rebuild is pending and can apply new configuration for us in a managed fashion.  Therefore, add an additional VSI state flag ICE_VSI_REBUILD_PENDING to indicate that ice_x ---truncated---

CVE-2024-46775:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Validate function returns  [WHAT & HOW] Function return values must be checked before data can be used in subsequent functions.  This fixes 4 CHECKED_RETURN issues reported by Coverity.

CVE-2024-46776:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Run DC_LOG_DC after checking link->link_enc  [WHAT] The DC_LOG_DC should be run after link->link_enc is checked, not before.  This fixes 1 REVERSE_INULL issue reported by Coverity.

CVE-2024-46787:

        In the Linux kernel, the following vulnerability has been resolved:  userfaultfd: fix checks for huge PMDs  Patch series "userfaultfd: fix races around pmd_trans_huge() check", v2.  The pmd_trans_huge() code in mfill_atomic() is wrong in three different ways depending on kernel version:  1. The pmd_trans_huge() check is racy and can lead to a BUG_ON() (if you hit    the right two race windows) - I've tested this in a kernel build with    some extra mdelay() calls. See the commit message for a description    of the race scenario.    On older kernels (before 6.5), I think the same bug can even    theoretically lead to accessing transhuge page contents as a page table    if you hit the right 5 narrow race windows (I haven't tested this case). 2. As pointed out by Qi Zheng, pmd_trans_huge() is not sufficient for    detecting PMDs that don't point to page tables.    On older kernels (before 6.5), you'd just have to win a single fairly    wide race to hit this.    I've tested this on 6.1 stable by racing migration (with a mdelay()    patched into try_to_migrate()) against UFFDIO_ZEROPAGE - on my x86    VM, that causes a kernel oops in ptlock_ptr(). 3. On newer kernels (>=6.5), for shmem mappings, khugepaged is allowed    to yank page tables out from under us (though I haven't tested that),    so I think the BUG_ON() checks in mfill_atomic() are just wrong.  I decided to write two separate fixes for these (one fix for bugs 1+2, one fix for bug 3), so that the first fix can be backported to kernels affected by bugs 1+2.   This patch (of 2):  This fixes two issues.  I discovered that the following race can occur:    mfill_atomic                other thread   ============                ============                               <zap PMD>   pmdp_get_lockless() [reads none pmd]   <bail if trans_huge>   <if none:>                               <pagefault creates transhuge zeropage>     __pte_alloc [no-op]                               <zap PMD>   <bail if pmd_trans_huge(*dst_pmd)>   BUG_ON(pmd_none(*dst_pmd))  I have experimentally verified this in a kernel with extra mdelay() calls; the BUG_ON(pmd_none(*dst_pmd)) triggers.  On kernels newer than commit 0d940a9b270b ("mm/pgtable: allow pte_offset_map[_lock]() to fail"), this can't lead to anything worse than a BUG_ON(), since the page table access helpers are actually designed to deal with page tables concurrently disappearing; but on older kernels (<=6.4), I think we could probably theoretically race past the two BUG_ON() checks and end up treating a hugepage as a page table.  The second issue is that, as Qi Zheng pointed out, there are other types of huge PMDs that pmd_trans_huge() can't catch: devmap PMDs and swap PMDs (in particular, migration PMDs).  On <=6.4, this is worse than the first issue: If mfill_atomic() runs on a PMD that contains a migration entry (which just requires winning a single, fairly wide race), it will pass the PMD to pte_offset_map_lock(), which assumes that the PMD points to a page table.  Breakage follows: First, the kernel tries to take the PTE lock (which will crash or maybe worse if there is no "struct page" for the address bits in the migration entry PMD - I think at least on X86 there usually is no corresponding "struct page" thanks to the PTE inversion mitigation, amd64 looks different).  If that didn't crash, the kernel would next try to write a PTE into what it wrongly thinks is a page table.  As part of fixing these issues, get rid of the check for pmd_trans_huge() before __pte_alloc() - that's redundant, we're going to have to check for that after the __pte_alloc() anyway.  Backport note: pmdp_get_lockless() is pmd_read_atomic() in older kernels.

CVE-2024-46806:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu: Fix the warning division or modulo by zero  Checks the partition mode and returns an error for an invalid mode.

CVE-2024-46808:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Add missing NULL pointer check within dpcd_extend_address_range  [Why & How] ASSERT if return NULL from kcalloc.

CVE-2024-46811:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Fix index may exceed array range within fpu_update_bw_bounding_box  [Why] Coverity reports OVERRUN warning. soc.num_states could be 40. But array range of bw_params->clk_table.entries is 8.  [How] Assert if soc.num_states greater than 8.

CVE-2024-46813:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Check link_index before accessing dc->links[]  [WHY & HOW] dc->links[] has max size of MAX_LINKS and NULL is return when trying to access with out-of-bound index.  This fixes 3 OVERRUN and 1 RESOURCE_LEAK issues reported by Coverity.

CVE-2024-46834:

        In the Linux kernel, the following vulnerability has been resolved:  ethtool: fail closed if we can't get max channel used in indirection tables  Commit 0d1b7d6c9274 ("bnxt: fix crashes when reducing ring count with active RSS contexts") proves that allowing indirection table to contain channels with out of bounds IDs may lead to crashes. Currently the max channel check in the core gets skipped if driver can't fetch the indirection table or when we can't allocate memory.  Both of those conditions should be extremely rare but if they do happen we should try to be safe and fail the channel change.

CVE-2024-46860:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: mt76: mt7921: fix NULL pointer access in mt7921_ipv6_addr_change  When disabling wifi mt7921_ipv6_addr_change() is called as a notifier. At this point mvif->phy is already NULL so we cannot use it here.

CVE-2024-46870:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Disable DMCUB timeout for DCN35  [Why] DMCUB can intermittently take longer than expected to process commands.  Old ASIC policy was to continue while logging a diagnostic error - which works fine for ASIC without IPS, but with IPS this could lead to a race condition where we attempt to access DCN state while it's inaccessible, leading to a system hang when the NIU port is not disabled or register accesses that timeout and the display configuration in an undefined state.  [How] We need to investigate why these accesses take longer than expected, but for now we should disable the timeout on DCN35 to avoid this race condition. Since the waits happen only at lower interrupt levels the risk of taking too long at higher IRQ and causing a system watchdog timeout are minimal.

CVE-2024-47141:

        In the Linux kernel, the following vulnerability has been resolved:  pinmux: Use sequential access to access desc->pinmux data  When two client of the same gpio call pinctrl_select_state() for the same functionality, we are seeing NULL pointer issue while accessing desc->mux_owner.  Let's say two processes A, B executing in pin_request() for the same pin and process A updates the desc->mux_usecount but not yet updated the desc->mux_owner while process B see the desc->mux_usecount which got updated by A path and further executes strcmp and while accessing desc->mux_owner it crashes with NULL pointer.  Serialize the access to mux related setting with a mutex lock.  	cpu0 (process A)			cpu1(process B)  pinctrl_select_state() {		  pinctrl_select_state() {   pin_request() {				pin_request() {   ... 						 ....     } else {          desc->mux_usecount++;     						desc->mux_usecount && strcmp(desc->mux_owner, owner)) {           if (desc->mux_usecount > 1)                return 0;          desc->mux_owner = owner;    }						}

CVE-2024-47658:

        In the Linux kernel, the following vulnerability has been resolved:  crypto: stm32/cryp - call finalize with bh disabled  The finalize operation in interrupt mode produce a produces a spinlock recursion warning. The reason is the fact that BH must be disabled during this process.

CVE-2024-47661:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Avoid overflow from uint32_t to uint8_t  [WHAT & HOW] dmub_rb_cmd's ramping_boundary has size of uint8_t and it is assigned 0xFFFF. Fix it by changing it to uint8_t with value of 0xFF.  This fixes 2 INTEGER_OVERFLOW issues reported by Coverity.

CVE-2024-47662:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Remove register from DCN35 DMCUB diagnostic collection  [Why] These registers should not be read from driver and triggering the security violation when DMCUB work times out and diagnostics are collected blocks Z8 entry.  [How] Remove the register read from DCN35.

CVE-2024-47664:

        In the Linux kernel, the following vulnerability has been resolved:  spi: hisi-kunpeng: Add verification for the max_frequency provided by the firmware  If the value of max_speed_hz is 0, it may cause a division by zero error in hisi_calc_effective_speed(). The value of max_speed_hz is provided by firmware. Firmware is generally considered as a trusted domain. However, as division by zero errors can cause system failure, for defense measure, the value of max_speed is validated here. So 0 is regarded as invalid and an error code is returned.

CVE-2024-47691:

        In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread()  syzbot reports a f2fs bug as below:   __dump_stack lib/dump_stack.c:88 [inline]  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114  print_report+0xe8/0x550 mm/kasan/report.c:491  kasan_report+0x143/0x180 mm/kasan/report.c:601  kasan_check_range+0x282/0x290 mm/kasan/generic.c:189  instrument_atomic_read_write include/linux/instrumented.h:96 [inline]  atomic_fetch_add_relaxed include/linux/atomic/atomic-instrumented.h:252 [inline]  __refcount_add include/linux/refcount.h:184 [inline]  __refcount_inc include/linux/refcount.h:241 [inline]  refcount_inc include/linux/refcount.h:258 [inline]  get_task_struct include/linux/sched/task.h:118 [inline]  kthread_stop+0xca/0x630 kernel/kthread.c:704  f2fs_stop_gc_thread+0x65/0xb0 fs/f2fs/gc.c:210  f2fs_do_shutdown+0x192/0x540 fs/f2fs/file.c:2283  f2fs_ioc_shutdown fs/f2fs/file.c:2325 [inline]  __f2fs_ioctl+0x443a/0xbe60 fs/f2fs/file.c:4325  vfs_ioctl fs/ioctl.c:51 [inline]  __do_sys_ioctl fs/ioctl.c:907 [inline]  __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893  do_syscall_x64 arch/x86/entry/common.c:52 [inline]  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  The root cause is below race condition, it may cause use-after-free issue in sbi->gc_th pointer.  - remount  - f2fs_remount   - f2fs_stop_gc_thread    - kfree(gc_th) 				- f2fs_ioc_shutdown 				 - f2fs_do_shutdown 				  - f2fs_stop_gc_thread 				   - kthread_stop(gc_th->f2fs_gc_task)    : sbi->gc_thread = NULL;  We will call f2fs_do_shutdown() in two paths: - for f2fs_ioc_shutdown() path, we should grab sb->s_umount semaphore for fixing. - for f2fs_shutdown() path, it's safe since caller has already grabbed sb->s_umount semaphore.

CVE-2024-47703:

        In the Linux kernel, the following vulnerability has been resolved:  bpf, lsm: Add check for BPF LSM return value  A bpf prog returning a positive number attached to file_alloc_security hook makes kernel panic.  This happens because file system can not filter out the positive number returned by the LSM prog using IS_ERR, and misinterprets this positive number as a file pointer.  Given that hook file_alloc_security never returned positive number before the introduction of BPF LSM, and other BPF LSM hooks may encounter similar issues, this patch adds LSM return value check in verifier, to ensure no unexpected value is returned.

CVE-2024-47752:

        In the Linux kernel, the following vulnerability has been resolved:  media: mediatek: vcodec: Fix H264 stateless decoder smatch warning  Fix a smatch static checker warning on vdec_h264_req_if.c. Which leads to a kernel crash when fb is NULL.

CVE-2024-47794:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: Prevent tailcall infinite loop caused by freplace  There is a potential infinite loop issue that can occur when using a combination of tail calls and freplace.  In an upcoming selftest, the attach target for entry_freplace of tailcall_freplace.c is subprog_tc of tc_bpf2bpf.c, while the tail call in entry_freplace leads to entry_tc. This results in an infinite loop:  entry_tc -> subprog_tc -> entry_freplace --tailcall-> entry_tc.  The problem arises because the tail_call_cnt in entry_freplace resets to zero each time entry_freplace is executed, causing the tail call mechanism to never terminate, eventually leading to a kernel panic.  To fix this issue, the solution is twofold:  1. Prevent updating a program extended by an freplace program to a    prog_array map. 2. Prevent extending a program that is already part of a prog_array map    with an freplace program.  This ensures that:  * If a program or its subprogram has been extended by an freplace program,   it can no longer be updated to a prog_array map. * If a program has been added to a prog_array map, neither it nor its   subprograms can be extended by an freplace program.  Moreover, an extension program should not be tailcalled. As such, return -EINVAL if the program has a type of BPF_PROG_TYPE_EXT when adding it to a prog_array map.  Additionally, fix a minor code style issue by replacing eight spaces with a tab for proper formatting.

CVE-2024-49569:

        In the Linux kernel, the following vulnerability has been resolved:  nvme-rdma: unquiesce admin_q before destroy it  Kernel will hang on destroy admin_q while we create ctrl failed, such as following calltrace:  PID: 23644    TASK: ff2d52b40f439fc0  CPU: 2    COMMAND: "nvme"  #0 [ff61d23de260fb78] __schedule at ffffffff8323bc15  #1 [ff61d23de260fc08] schedule at ffffffff8323c014  #2 [ff61d23de260fc28] blk_mq_freeze_queue_wait at ffffffff82a3dba1  #3 [ff61d23de260fc78] blk_freeze_queue at ffffffff82a4113a  #4 [ff61d23de260fc90] blk_cleanup_queue at ffffffff82a33006  #5 [ff61d23de260fcb0] nvme_rdma_destroy_admin_queue at ffffffffc12686ce  #6 [ff61d23de260fcc8] nvme_rdma_setup_ctrl at ffffffffc1268ced  #7 [ff61d23de260fd28] nvme_rdma_create_ctrl at ffffffffc126919b  #8 [ff61d23de260fd68] nvmf_dev_write at ffffffffc024f362  #9 [ff61d23de260fe38] vfs_write at ffffffff827d5f25     RIP: 00007fda7891d574  RSP: 00007ffe2ef06958  RFLAGS: 00000202     RAX: ffffffffffffffda  RBX: 000055e8122a4d90  RCX: 00007fda7891d574     RDX: 000000000000012b  RSI: 000055e8122a4d90  RDI: 0000000000000004     RBP: 00007ffe2ef079c0   R8: 000000000000012b   R9: 000055e8122a4d90     R10: 0000000000000000  R11: 0000000000000202  R12: 0000000000000004     R13: 000055e8122923c0  R14: 000000000000012b  R15: 00007fda78a54500     ORIG_RAX: 0000000000000001  CS: 0033  SS: 002b  This due to we have quiesced admi_q before cancel requests, but forgot to unquiesce before destroy it, as a result we fail to drain the pending requests, and hang on blk_mq_freeze_queue_wait() forever. Here try to reuse nvme_rdma_teardown_admin_queue() to fix this issue and simplify the code.

CVE-2024-49893:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Check stream_status before it is used  [WHAT & HOW] dc_state_get_stream_status can return null, and therefore null must be checked before stream_status is used.  This fixes 1 NULL_RETURNS issue reported by Coverity.

CVE-2024-49901:

        In the Linux kernel, the following vulnerability has been resolved:  drm/msm/adreno: Assign msm_gpu->pdev earlier to avoid nullptrs  There are some cases, such as the one uncovered by Commit 46d4efcccc68 ("drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails") where  msm_gpu_cleanup() : platform_set_drvdata(gpu->pdev, NULL);  is called on gpu->pdev == NULL, as the GPU device has not been fully initialized yet.  Turns out that there's more than just the aforementioned path that causes this to happen (e.g. the case when there's speedbin data in the catalog, but opp-supported-hw is missing in DT).  Assigning msm_gpu->pdev earlier seems like the least painful solution to this, therefore do so.  Patchwork: https://patchwork.freedesktop.org/patch/602742/

CVE-2024-49906:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Check null pointer before try to access it  [why & how] Change the order of the pipe_ctx->plane_state check to ensure that plane_state is not null before accessing it.

CVE-2024-49908:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Add null check for 'afb' in amdgpu_dm_update_cursor (v2)  This commit adds a null check for the 'afb' variable in the amdgpu_dm_update_cursor function. Previously, 'afb' was assumed to be null at line 8388, but was used later in the code without a null check. This could potentially lead to a null pointer dereference.  Changes since v1: - Moved the null check for 'afb' to the line where 'afb' is used. (Alex)  Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:8433 amdgpu_dm_update_cursor() 	error: we previously assumed 'afb' could be null (see line 8388)

CVE-2024-49910:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Add NULL check for function pointer in dcn401_set_output_transfer_func  This commit adds a null check for the set_output_gamma function pointer in the dcn401_set_output_transfer_func function. Previously, set_output_gamma was being checked for null, but then it was being dereferenced without any null check. This could lead to a null pointer dereference if set_output_gamma is null.  To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma.

CVE-2024-49914:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Add null check for pipe_ctx->plane_state in dcn20_program_pipe  This commit addresses a null pointer dereference issue in the `dcn20_program_pipe` function. The issue could occur when `pipe_ctx->plane_state` is null.  The fix adds a check to ensure `pipe_ctx->plane_state` is not null before accessing. This prevents a null pointer dereference.  Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn20/dcn20_hwseq.c:1925 dcn20_program_pipe() error: we previously assumed 'pipe_ctx->plane_state' could be null (see line 1877)

CVE-2024-49916:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in dcn401_init_hw  This commit addresses a potential null pointer dereference issue in the `dcn401_init_hw` function. The issue could occur when `dc->clk_mgr` or `dc->clk_mgr->funcs` is null.  The fix adds a check to ensure `dc->clk_mgr` and `dc->clk_mgr->funcs` is not null before accessing its functions. This prevents a potential null pointer dereference.  Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn401/dcn401_hwseq.c:416 dcn401_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 225)

CVE-2024-49918:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Add null check for head_pipe in dcn32_acquire_idle_pipe_for_head_pipe_in_layer  This commit addresses a potential null pointer dereference issue in the `dcn32_acquire_idle_pipe_for_head_pipe_in_layer` function. The issue could occur when `head_pipe` is null.  The fix adds a check to ensure `head_pipe` is not null before asserting it. If `head_pipe` is null, the function returns NULL to prevent a potential null pointer dereference.  Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn32/dcn32_resource.c:2690 dcn32_acquire_idle_pipe_for_head_pipe_in_layer() error: we previously assumed 'head_pipe' could be null (see line 2681)

CVE-2024-49919:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Add null check for head_pipe in dcn201_acquire_free_pipe_for_layer  This commit addresses a potential null pointer dereference issue in the `dcn201_acquire_free_pipe_for_layer` function. The issue could occur when `head_pipe` is null.  The fix adds a check to ensure `head_pipe` is not null before asserting it. If `head_pipe` is null, the function returns NULL to prevent a potential null pointer dereference.  Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn201/dcn201_resource.c:1016 dcn201_acquire_free_pipe_for_layer() error: we previously assumed 'head_pipe' could be null (see line 1010)

CVE-2024-49920:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Check null pointers before multiple uses  [WHAT & HOW] Poniters, such as stream_enc and dc->bw_vbios, are null checked previously in the same function, so Coverity warns "implies that stream_enc and dc->bw_vbios might be null". They are used multiple times in the subsequent code and need to be checked.  This fixes 10 FORWARD_NULL issues reported by Coverity.

CVE-2024-49921:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Check null pointers before used  [WHAT & HOW] Poniters, such as dc->clk_mgr, are null checked previously in the same function, so Coverity warns "implies that "dc->clk_mgr" might be null". As a result, these pointers need to be checked when used again.  This fixes 10 FORWARD_NULL issues reported by Coverity.

CVE-2024-49922:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Check null pointers before using them  [WHAT & HOW] These pointers are null checked previously in the same function, indicating they might be null as reported by Coverity. As a result, they need to be checked when used again.  This fixes 3 FORWARD_NULL issue reported by Coverity.

CVE-2024-49923:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Pass non-null to dcn20_validate_apply_pipe_split_flags  [WHAT & HOW] "dcn20_validate_apply_pipe_split_flags" dereferences merge, and thus it cannot be a null pointer. Let's pass a valid pointer to avoid null dereference.  This fixes 2 FORWARD_NULL issues reported by Coverity.

CVE-2024-49926:

        In the Linux kernel, the following vulnerability has been resolved:  rcu-tasks: Fix access non-existent percpu rtpcp variable in rcu_tasks_need_gpcb()  For kernels built with CONFIG_FORCE_NR_CPUS=y, the nr_cpu_ids is defined as NR_CPUS instead of the number of possible cpus, this will cause the following system panic:  smpboot: Allowing 4 CPUs, 0 hotplug CPUs ... setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:512 nr_node_ids:1 ... BUG: unable to handle page fault for address: ffffffff9911c8c8 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 15 Comm: rcu_tasks_trace Tainted: G W 6.6.21 #1 5dc7acf91a5e8e9ac9dcfc35bee0245691283ea6 RIP: 0010:rcu_tasks_need_gpcb+0x25d/0x2c0 RSP: 0018:ffffa371c00a3e60 EFLAGS: 00010082 CR2: ffffffff9911c8c8 CR3: 000000040fa20005 CR4: 00000000001706f0 Call Trace: <TASK> ? __die+0x23/0x80 ? page_fault_oops+0xa4/0x180 ? exc_page_fault+0x152/0x180 ? asm_exc_page_fault+0x26/0x40 ? rcu_tasks_need_gpcb+0x25d/0x2c0 ? __pfx_rcu_tasks_kthread+0x40/0x40 rcu_tasks_one_gp+0x69/0x180 rcu_tasks_kthread+0x94/0xc0 kthread+0xe8/0x140 ? __pfx_kthread+0x40/0x40 ret_from_fork+0x34/0x80 ? __pfx_kthread+0x40/0x40 ret_from_fork_asm+0x1b/0x80 </TASK>  Considering that there may be holes in the CPU numbers, use the maximum possible cpu number, instead of nr_cpu_ids, for configuring enqueue and dequeue limits.  [ neeraj.upadhyay: Fix htmldocs build error reported by Stephen Rothwell ]

CVE-2024-49940:

        In the Linux kernel, the following vulnerability has been resolved:  l2tp: prevent possible tunnel refcount underflow  When a session is created, it sets a backpointer to its tunnel. When the session refcount drops to 0, l2tp_session_free drops the tunnel refcount if session->tunnel is non-NULL. However, session->tunnel is set in l2tp_session_create, before the tunnel refcount is incremented by l2tp_session_register, which leaves a small window where session->tunnel is non-NULL when the tunnel refcount hasn't been bumped.  Moving the assignment to l2tp_session_register is trivial but l2tp_session_create calls l2tp_session_set_header_len which uses session->tunnel to get the tunnel's encap. Add an encap arg to l2tp_session_set_header_len to avoid using session->tunnel.  If l2tpv3 sessions have colliding IDs, it is possible for l2tp_v3_session_get to race with l2tp_session_register and fetch a session which doesn't yet have session->tunnel set. Add a check for this case.

CVE-2024-49945:

        In the Linux kernel, the following vulnerability has been resolved:  net/ncsi: Disable the ncsi work before freeing the associated structure  The work function can run after the ncsi device is freed, resulting in use-after-free bugs or kernel panic.

CVE-2024-49970:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Implement bounds check for stream encoder creation in DCN401  'stream_enc_regs' array is an array of dcn10_stream_enc_registers structures. The array is initialized with four elements, corresponding to the four calls to stream_enc_regs() in the array initializer. This means that valid indices for this array are 0, 1, 2, and 3.  The error message 'stream_enc_regs' 4 <= 5 below, is indicating that there is an attempt to access this array with an index of 5, which is out of bounds. This could lead to undefined behavior  Here, eng_id is used as an index to access the stream_enc_regs array. If eng_id is 5, this would result in an out-of-bounds access on the stream_enc_regs array.  Thus fixing Buffer overflow error in dcn401_stream_encoder_create  Found by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn401/dcn401_resource.c:1209 dcn401_stream_encoder_create() error: buffer overflow 'stream_enc_regs' 4 <= 5

CVE-2024-49988:

        In the Linux kernel, the following vulnerability has been resolved:  ksmbd: add refcnt to ksmbd_conn struct  When sending an oplock break request, opinfo->conn is used, But freed ->conn can be used on multichannel. This patch add a reference count to the ksmbd_conn struct so that it can be freed when it is no longer used.

CVE-2024-50009:

        In the Linux kernel, the following vulnerability has been resolved:  cpufreq: amd-pstate: add check for cpufreq_cpu_get's return value  cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it and return in case of error.  Found by Linux Verification Center (linuxtesting.org) with SVACE.

CVE-2024-50028:

        In the Linux kernel, the following vulnerability has been resolved:  thermal: core: Reference count the zone in thermal_zone_get_by_id()  There are places in the thermal netlink code where nothing prevents the thermal zone object from going away while being accessed after it has been returned by thermal_zone_get_by_id().  To address this, make thermal_zone_get_by_id() get a reference on the thermal zone device object to be returned with the help of get_device(), under thermal_list_lock, and adjust all of its callers to this change with the help of the cleanup.h infrastructure.

CVE-2024-50057:

        In the Linux kernel, the following vulnerability has been resolved:  usb: typec: tipd: Free IRQ only if it was requested before  In polling mode, if no IRQ was requested there is no need to free it. Call devm_free_irq() only if client->irq is set. This fixes the warning caused by the tps6598x module removal:  WARNING: CPU: 2 PID: 333 at kernel/irq/devres.c:144 devm_free_irq+0x80/0x8c ... ... Call trace:   devm_free_irq+0x80/0x8c   tps6598x_remove+0x28/0x88 [tps6598x]   i2c_device_remove+0x2c/0x9c   device_remove+0x4c/0x80   device_release_driver_internal+0x1cc/0x228   driver_detach+0x50/0x98   bus_remove_driver+0x6c/0xbc   driver_unregister+0x30/0x60   i2c_del_driver+0x54/0x64   tps6598x_i2c_driver_exit+0x18/0xc3c [tps6598x]   __arm64_sys_delete_module+0x184/0x264   invoke_syscall+0x48/0x110   el0_svc_common.constprop.0+0xc8/0xe8   do_el0_svc+0x20/0x2c   el0_svc+0x28/0x98   el0t_64_sync_handler+0x13c/0x158   el0t_64_sync+0x190/0x194

CVE-2024-50111:

        In the Linux kernel, the following vulnerability has been resolved:  LoongArch: Enable IRQ if do_ale() triggered in irq-enabled context  Unaligned access exception can be triggered in irq-enabled context such as user mode, in this case do_ale() may call get_user() which may cause sleep. Then we will get:   BUG: sleeping function called from invalid context at arch/loongarch/kernel/access-helper.h:7  in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 129, name: modprobe  preempt_count: 0, expected: 0  RCU nest depth: 0, expected: 0  CPU: 0 UID: 0 PID: 129 Comm: modprobe Tainted: G        W          6.12.0-rc1+ #1723  Tainted: [W]=WARN  Stack : 9000000105e0bd48 0000000000000000 9000000003803944 9000000105e08000          9000000105e0bc70 9000000105e0bc78 0000000000000000 0000000000000000          9000000105e0bc78 0000000000000001 9000000185e0ba07 9000000105e0b890          ffffffffffffffff 9000000105e0bc78 73924b81763be05b 9000000100194500          000000000000020c 000000000000000a 0000000000000000 0000000000000003          00000000000023f0 00000000000e1401 00000000072f8000 0000007ffbb0e260          0000000000000000 0000000000000000 9000000005437650 90000000055d5000          0000000000000000 0000000000000003 0000007ffbb0e1f0 0000000000000000          0000005567b00490 0000000000000000 9000000003803964 0000007ffbb0dfec          00000000000000b0 0000000000000007 0000000000000003 0000000000071c1d          ...  Call Trace:  [<9000000003803964>] show_stack+0x64/0x1a0  [<9000000004c57464>] dump_stack_lvl+0x74/0xb0  [<9000000003861ab4>] __might_resched+0x154/0x1a0  [<900000000380c96c>] emulate_load_store_insn+0x6c/0xf60  [<9000000004c58118>] do_ale+0x78/0x180  [<9000000003801bc8>] handle_ale+0x128/0x1e0  So enable IRQ if unaligned access exception is triggered in irq-enabled context to fix it.

CVE-2024-50135:

        In the Linux kernel, the following vulnerability has been resolved:  nvme-pci: fix race condition between reset and nvme_dev_disable()  nvme_dev_disable() modifies the dev->online_queues field, therefore nvme_pci_update_nr_queues() should avoid racing against it, otherwise we could end up passing invalid values to blk_mq_update_nr_hw_queues().   WARNING: CPU: 39 PID: 61303 at drivers/pci/msi/api.c:347           pci_irq_get_affinity+0x187/0x210  Workqueue: nvme-reset-wq nvme_reset_work [nvme]  RIP: 0010:pci_irq_get_affinity+0x187/0x210  Call Trace:   <TASK>   ? blk_mq_pci_map_queues+0x87/0x3c0   ? pci_irq_get_affinity+0x187/0x210   blk_mq_pci_map_queues+0x87/0x3c0   nvme_pci_map_queues+0x189/0x460 [nvme]   blk_mq_update_nr_hw_queues+0x2a/0x40   nvme_reset_work+0x1be/0x2a0 [nvme]  Fix the bug by locking the shutdown_lock mutex before using dev->online_queues. Give up if nvme_dev_disable() is running or if it has been executed already.

CVE-2024-50166:

        In the Linux kernel, the following vulnerability has been resolved:  fsl/fman: Fix refcount handling of fman-related devices  In mac_probe() there are multiple calls to of_find_device_by_node(), fman_bind() and fman_port_bind() which takes references to of_dev->dev. Not all references taken by these calls are released later on error path in mac_probe() and in mac_remove() which lead to reference leaks.  Add references release.

CVE-2024-50211:

        In the Linux kernel, the following vulnerability has been resolved:  udf: refactor inode_bmap() to handle error  Refactor inode_bmap() to handle error since udf_next_aext() can return error now. On situations like ftruncate, udf_extend_file() can now detect errors and bail out early without resorting to checking for particular offsets and assuming internal behavior of these functions.

CVE-2024-50217:

        In the Linux kernel, the following vulnerability has been resolved:  btrfs: fix use-after-free of block device file in __btrfs_free_extra_devids()  Mounting btrfs from two images (which have the same one fsid and two different dev_uuids) in certain executing order may trigger an UAF for variable 'device->bdev_file' in __btrfs_free_extra_devids(). And following are the details:  1. Attach image_1 to loop0, attach image_2 to loop1, and scan btrfs    devices by ioctl(BTRFS_IOC_SCAN_DEV):               /  btrfs_device_1 → loop0    fs_device              \  btrfs_device_2 → loop1 2. mount /dev/loop0 /mnt    btrfs_open_devices     btrfs_device_1->bdev_file = btrfs_get_bdev_and_sb(loop0)     btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1)    btrfs_fill_super     open_ctree      fail: btrfs_close_devices // -ENOMEM 	    btrfs_close_bdev(btrfs_device_1)              fput(btrfs_device_1->bdev_file) 	      // btrfs_device_1->bdev_file is freed 	    btrfs_close_bdev(btrfs_device_2)              fput(btrfs_device_2->bdev_file)  3. mount /dev/loop1 /mnt    btrfs_open_devices     btrfs_get_bdev_and_sb(&bdev_file)      // EIO, btrfs_device_1->bdev_file is not assigned,      // which points to a freed memory area     btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1)    btrfs_fill_super     open_ctree      btrfs_free_extra_devids       if (btrfs_device_1->bdev_file)        fput(btrfs_device_1->bdev_file) // UAF !  Fix it by setting 'device->bdev_file' as 'NULL' after closing the btrfs_device in btrfs_close_one_device().

CVE-2024-50226:

        In the Linux kernel, the following vulnerability has been resolved:  cxl/port: Fix use-after-free, permit out-of-order decoder shutdown  In support of investigating an initialization failure report [1], cxl_test was updated to register mock memory-devices after the mock root-port/bus device had been registered. That led to cxl_test crashing with a use-after-free bug with the following signature:      cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem0:decoder7.0 @ 0 next: cxl_switch_uport.0 nr_eps: 1 nr_targets: 1     cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem4:decoder14.0 @ 1 next: cxl_switch_uport.0 nr_eps: 2 nr_targets: 1     cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[0] = cxl_switch_dport.0 for mem0:decoder7.0 @ 0 1)  cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[1] = cxl_switch_dport.4 for mem4:decoder14.0 @ 1     [..]     cxld_unregister: cxl decoder14.0:     cxl_region_decode_reset: cxl_region region3:     mock_decoder_reset: cxl_port port3: decoder3.0 reset 2)  mock_decoder_reset: cxl_port port3: decoder3.0: out of order reset, expected decoder3.1     cxl_endpoint_decoder_release: cxl decoder14.0:     [..]     cxld_unregister: cxl decoder7.0: 3)  cxl_region_decode_reset: cxl_region region3:     Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6bc3: 0000 [#1] PREEMPT SMP PTI     [..]     RIP: 0010:to_cxl_port+0x8/0x60 [cxl_core]     [..]     Call Trace:      <TASK>      cxl_region_decode_reset+0x69/0x190 [cxl_core]      cxl_region_detach+0xe8/0x210 [cxl_core]      cxl_decoder_kill_region+0x27/0x40 [cxl_core]      cxld_unregister+0x5d/0x60 [cxl_core]  At 1) a region has been established with 2 endpoint decoders (7.0 and 14.0). Those endpoints share a common switch-decoder in the topology (3.0). At teardown, 2), decoder14.0 is the first to be removed and hits the "out of order reset case" in the switch decoder. The effect though is that region3 cleanup is aborted leaving it in-tact and referencing decoder14.0. At 3) the second attempt to teardown region3 trips over the stale decoder14.0 object which has long since been deleted.  The fix here is to recognize that the CXL specification places no mandate on in-order shutdown of switch-decoders, the driver enforces in-order allocation, and hardware enforces in-order commit. So, rather than fail and leave objects dangling, always remove them.  In support of making cxl_region_decode_reset() always succeed, cxl_region_invalidate_memregion() failures are turned into warnings. Crashing the kernel is ok there since system integrity is at risk if caches cannot be managed around physical address mutation events like CXL region destruction.  A new device_for_each_child_reverse_from() is added to cleanup port->commit_end after all dependent decoders have been disabled. In other words if decoders are allocated 0->1->2 and disabled 1->2->0 then port->commit_end only decrements from 2 after 2 has been disabled, and it decrements all the way to zero since 1 was disabled previously.

CVE-2024-50282:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read()  Avoid a possible buffer overflow if size is larger than 4K.  (cherry picked from commit f5d873f5825b40d886d03bd2aede91d4cf002434)

CVE-2024-50285:

        In the Linux kernel, the following vulnerability has been resolved:  ksmbd: check outstanding simultaneous SMB operations  If Client send simultaneous SMB operations to ksmbd, It exhausts too much memory through the "ksmbd_work_cache”. It will cause OOM issue. ksmbd has a credit mechanism but it can't handle this problem. This patch add the check if it exceeds max credits to prevent this problem by assuming that one smb request consumes at least one credit.

CVE-2024-50289:

        In the Linux kernel, the following vulnerability has been resolved:  media: av7110: fix a spectre vulnerability  As warned by smatch: 	drivers/staging/media/av7110/av7110_ca.c:270 dvb_ca_ioctl() warn: potential spectre issue 'av7110->ci_slot' [w] (local cap)  There is a spectre-related vulnerability at the code. Fix it.

CVE-2024-52559:

        In the Linux kernel, the following vulnerability has been resolved:  drm/msm/gem: prevent integer overflow in msm_ioctl_gem_submit()  The "submit->cmd[i].size" and "submit->cmd[i].offset" variables are u32 values that come from the user via the submit_lookup_cmds() function. This addition could lead to an integer wrapping bug so use size_add() to prevent that.  Patchwork: https://patchwork.freedesktop.org/patch/624696/

CVE-2024-52560:

        In the Linux kernel, the following vulnerability has been resolved:  fs/ntfs3: Mark inode as bad as soon as error detected in mi_enum_attr()  Extended the `mi_enum_attr()` function interface with an additional parameter, `struct ntfs_inode *ni`, to allow marking the inode as bad as soon as an error is detected.

CVE-2024-53051:

        In the Linux kernel, the following vulnerability has been resolved:  drm/i915/hdcp: Add encoder check in intel_hdcp_get_capability  Sometimes during hotplug scenario or suspend/resume scenario encoder is not always initialized when intel_hdcp_get_capability add a check to avoid kernel null pointer dereference.

CVE-2024-53056:

        In the Linux kernel, the following vulnerability has been resolved:  drm/mediatek: Fix potential NULL dereference in mtk_crtc_destroy()  In mtk_crtc_create(), if the call to mbox_request_channel() fails then we set the "mtk_crtc->cmdq_client.chan" pointer to NULL.  In that situation, we do not call cmdq_pkt_create().  During the cleanup, we need to check if the "mtk_crtc->cmdq_client.chan" is NULL first before calling cmdq_pkt_destroy().  Calling cmdq_pkt_destroy() is unnecessary if we didn't call cmdq_pkt_create() and it will result in a NULL pointer dereference.

CVE-2024-53068:

        In the Linux kernel, the following vulnerability has been resolved:  firmware: arm_scmi: Fix slab-use-after-free in scmi_bus_notifier()  The scmi_dev->name is released prematurely in __scmi_device_destroy(), which causes slab-use-after-free when accessing scmi_dev->name in scmi_bus_notifier(). So move the release of scmi_dev->name to scmi_device_release() to avoid slab-use-after-free.    |  BUG: KASAN: slab-use-after-free in strncmp+0xe4/0xec   |  Read of size 1 at addr ffffff80a482bcc0 by task swapper/0/1   |   |  CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.6.38-debug #1   |  Hardware name: Qualcomm Technologies, Inc. SA8775P Ride (DT)   |  Call trace:   |   dump_backtrace+0x94/0x114   |   show_stack+0x18/0x24   |   dump_stack_lvl+0x48/0x60   |   print_report+0xf4/0x5b0   |   kasan_report+0xa4/0xec   |   __asan_report_load1_noabort+0x20/0x2c   |   strncmp+0xe4/0xec   |   scmi_bus_notifier+0x5c/0x54c   |   notifier_call_chain+0xb4/0x31c   |   blocking_notifier_call_chain+0x68/0x9c   |   bus_notify+0x54/0x78   |   device_del+0x1bc/0x840   |   device_unregister+0x20/0xb4   |   __scmi_device_destroy+0xac/0x280   |   scmi_device_destroy+0x94/0xd0   |   scmi_chan_setup+0x524/0x750   |   scmi_probe+0x7fc/0x1508   |   platform_probe+0xc4/0x19c   |   really_probe+0x32c/0x99c   |   __driver_probe_device+0x15c/0x3c4   |   driver_probe_device+0x5c/0x170   |   __driver_attach+0x1c8/0x440   |   bus_for_each_dev+0xf4/0x178   |   driver_attach+0x3c/0x58   |   bus_add_driver+0x234/0x4d4   |   driver_register+0xf4/0x3c0   |   __platform_driver_register+0x60/0x88   |   scmi_driver_init+0xb0/0x104   |   do_one_initcall+0xb4/0x664   |   kernel_init_freeable+0x3c8/0x894   |   kernel_init+0x24/0x1e8   |   ret_from_fork+0x10/0x20   |   |  Allocated by task 1:   |   kasan_save_stack+0x2c/0x54   |   kasan_set_track+0x2c/0x40   |   kasan_save_alloc_info+0x24/0x34   |   __kasan_kmalloc+0xa0/0xb8   |   __kmalloc_node_track_caller+0x6c/0x104   |   kstrdup+0x48/0x84   |   kstrdup_const+0x34/0x40   |   __scmi_device_create.part.0+0x8c/0x408   |   scmi_device_create+0x104/0x370   |   scmi_chan_setup+0x2a0/0x750   |   scmi_probe+0x7fc/0x1508   |   platform_probe+0xc4/0x19c   |   really_probe+0x32c/0x99c   |   __driver_probe_device+0x15c/0x3c4   |   driver_probe_device+0x5c/0x170   |   __driver_attach+0x1c8/0x440   |   bus_for_each_dev+0xf4/0x178   |   driver_attach+0x3c/0x58   |   bus_add_driver+0x234/0x4d4   |   driver_register+0xf4/0x3c0   |   __platform_driver_register+0x60/0x88   |   scmi_driver_init+0xb0/0x104   |   do_one_initcall+0xb4/0x664   |   kernel_init_freeable+0x3c8/0x894   |   kernel_init+0x24/0x1e8   |   ret_from_fork+0x10/0x20   |   |  Freed by task 1:   |   kasan_save_stack+0x2c/0x54   |   kasan_set_track+0x2c/0x40   |   kasan_save_free_info+0x38/0x5c   |   __kasan_slab_free+0xe8/0x164   |   __kmem_cache_free+0x11c/0x230   |   kfree+0x70/0x130   |   kfree_const+0x20/0x40   |   __scmi_device_destroy+0x70/0x280   |   scmi_device_destroy+0x94/0xd0   |   scmi_chan_setup+0x524/0x750   |   scmi_probe+0x7fc/0x1508   |   platform_probe+0xc4/0x19c   |   really_probe+0x32c/0x99c   |   __driver_probe_device+0x15c/0x3c4   |   driver_probe_device+0x5c/0x170   |   __driver_attach+0x1c8/0x440   |   bus_for_each_dev+0xf4/0x178   |   driver_attach+0x3c/0x58   |   bus_add_driver+0x234/0x4d4   |   driver_register+0xf4/0x3c0   |   __platform_driver_register+0x60/0x88   |   scmi_driver_init+0xb0/0x104   |   do_one_initcall+0xb4/0x664   |   kernel_init_freeable+0x3c8/0x894   |   kernel_init+0x24/0x1e8   |   ret_from_fork+0x10/0x20

CVE-2024-53079:

        In the Linux kernel, the following vulnerability has been resolved:  mm/thp: fix deferred split unqueue naming and locking  Recent changes are putting more pressure on THP deferred split queues: under load revealing long-standing races, causing list_del corruptions, "Bad page state"s and worse (I keep BUGs in both of those, so usually don't get to see how badly they end up without).  The relevant recent changes being 6.8's mTHP, 6.10's mTHP swapout, and 6.12's mTHP swapin, improved swap allocation, and underused THP splitting.  Before fixing locking: rename misleading folio_undo_large_rmappable(), which does not undo large_rmappable, to folio_unqueue_deferred_split(), which is what it does.  But that and its out-of-line __callee are mm internals of very limited usability: add comment and WARN_ON_ONCEs to check usage; and return a bool to say if a deferred split was unqueued, which can then be used in WARN_ON_ONCEs around safety checks (sparing callers the arcane conditionals in __folio_unqueue_deferred_split()).  Just omit the folio_unqueue_deferred_split() from free_unref_folios(), all of whose callers now call it beforehand (and if any forget then bad_page() will tell) - except for its caller put_pages_list(), which itself no longer has any callers (and will be deleted separately).  Swapout: mem_cgroup_swapout() has been resetting folio->memcg_data 0 without checking and unqueueing a THP folio from deferred split list; which is unfortunate, since the split_queue_lock depends on the memcg (when memcg is enabled); so swapout has been unqueueing such THPs later, when freeing the folio, using the pgdat's lock instead: potentially corrupting the memcg's list.  __remove_mapping() has frozen refcount to 0 here, so no problem with calling folio_unqueue_deferred_split() before resetting memcg_data.  That goes back to 5.4 commit 87eaceb3faa5 ("mm: thp: make deferred split shrinker memcg aware"): which included a check on swapcache before adding to deferred queue, but no check on deferred queue before adding THP to swapcache.  That worked fine with the usual sequence of events in reclaim (though there were a couple of rare ways in which a THP on deferred queue could have been swapped out), but 6.12 commit dafff3f4c850 ("mm: split underused THPs") avoids splitting underused THPs in reclaim, which makes swapcache THPs on deferred queue commonplace.  Keep the check on swapcache before adding to deferred queue?  Yes: it is no longer essential, but preserves the existing behaviour, and is likely to be a worthwhile optimization (vmstat showed much more traffic on the queue under swapping load if the check was removed); update its comment.  Memcg-v1 move (deprecated): mem_cgroup_move_account() has been changing folio->memcg_data without checking and unqueueing a THP folio from the deferred list, sometimes corrupting "from" memcg's list, like swapout.  Refcount is non-zero here, so folio_unqueue_deferred_split() can only be used in a WARN_ON_ONCE to validate the fix, which must be done earlier: mem_cgroup_move_charge_pte_range() first try to split the THP (splitting of course unqueues), or skip it if that fails.  Not ideal, but moving charge has been requested, and khugepaged should repair the THP later: nobody wants new custom unqueueing code just for this deprecated case.  The 87eaceb3faa5 commit did have the code to move from one deferred list to another (but was not conscious of its unsafety while refcount non-0); but that was removed by 5.6 commit fac0516b5534 ("mm: thp: don't need care deferred split queue in memcg charge move path"), which argued that the existence of a PMD mapping guarantees that the THP cannot be on a deferred list.  As above, false in rare cases, and now commonly false.  Backport to 6.11 should be straightforward.  Earlier backports must take care that other _deferred_list fixes and dependencies are included.  There is not a strong case for backports, but they can fix cornercases.

CVE-2024-53085:

        In the Linux kernel, the following vulnerability has been resolved:  tpm: Lock TPM chip in tpm_pm_suspend() first  Setting TPM_CHIP_FLAG_SUSPENDED in the end of tpm_pm_suspend() can be racy according, as this leaves window for tpm_hwrng_read() to be called while the operation is in progress. The recent bug report gives also evidence of this behaviour.  Aadress this by locking the TPM chip before checking any chip->flags both in tpm_pm_suspend() and tpm_hwrng_read(). Move TPM_CHIP_FLAG_SUSPENDED check inside tpm_get_random() so that it will be always checked only when the lock is reserved.

CVE-2024-53089:

        In the Linux kernel, the following vulnerability has been resolved:  LoongArch: KVM: Mark hrtimer to expire in hard interrupt context  Like commit 2c0d278f3293f ("KVM: LAPIC: Mark hrtimer to expire in hard interrupt context") and commit 9090825fa9974 ("KVM: arm/arm64: Let the timer expire in hardirq context on RT"), On PREEMPT_RT enabled kernels unmarked hrtimers are moved into soft interrupt expiry mode by default. Then the timers are canceled from an preempt-notifier which is invoked with disabled preemption which is not allowed on PREEMPT_RT.  The timer callback is short so in could be invoked in hard-IRQ context. So let the timer expire on hard-IRQ context even on -RT.  This fix a "scheduling while atomic" bug for PREEMPT_RT enabled kernels:   BUG: scheduling while atomic: qemu-system-loo/1011/0x00000002  Modules linked in: amdgpu rfkill nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat ns  CPU: 1 UID: 0 PID: 1011 Comm: qemu-system-loo Tainted: G        W          6.12.0-rc2+ #1774  Tainted: [W]=WARN  Hardware name: Loongson Loongson-3A5000-7A1000-1w-CRB/Loongson-LS3A5000-7A1000-1w-CRB, BIOS vUDK2018-LoongArch-V2.0.0-prebeta9 10/21/2022  Stack : ffffffffffffffff 0000000000000000 9000000004e3ea38 9000000116744000          90000001167475a0 0000000000000000 90000001167475a8 9000000005644830          90000000058dc000 90000000058dbff8 9000000116747420 0000000000000001          0000000000000001 6a613fc938313980 000000000790c000 90000001001c1140          00000000000003fe 0000000000000001 000000000000000d 0000000000000003          0000000000000030 00000000000003f3 000000000790c000 9000000116747830          90000000057ef000 0000000000000000 9000000005644830 0000000000000004          0000000000000000 90000000057f4b58 0000000000000001 9000000116747868          900000000451b600 9000000005644830 9000000003a13998 0000000010000020          00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d          ...  Call Trace:  [<9000000003a13998>] show_stack+0x38/0x180  [<9000000004e3ea34>] dump_stack_lvl+0x84/0xc0  [<9000000003a71708>] __schedule_bug+0x48/0x60  [<9000000004e45734>] __schedule+0x1114/0x1660  [<9000000004e46040>] schedule_rtlock+0x20/0x60  [<9000000004e4e330>] rtlock_slowlock_locked+0x3f0/0x10a0  [<9000000004e4f038>] rt_spin_lock+0x58/0x80  [<9000000003b02d68>] hrtimer_cancel_wait_running+0x68/0xc0  [<9000000003b02e30>] hrtimer_cancel+0x70/0x80  [<ffff80000235eb70>] kvm_restore_timer+0x50/0x1a0 [kvm]  [<ffff8000023616c8>] kvm_arch_vcpu_load+0x68/0x2a0 [kvm]  [<ffff80000234c2d4>] kvm_sched_in+0x34/0x60 [kvm]  [<9000000003a749a0>] finish_task_switch.isra.0+0x140/0x2e0  [<9000000004e44a70>] __schedule+0x450/0x1660  [<9000000004e45cb0>] schedule+0x30/0x180  [<ffff800002354c70>] kvm_vcpu_block+0x70/0x120 [kvm]  [<ffff800002354d80>] kvm_vcpu_halt+0x60/0x3e0 [kvm]  [<ffff80000235b194>] kvm_handle_gspr+0x3f4/0x4e0 [kvm]  [<ffff80000235f548>] kvm_handle_exit+0x1c8/0x260 [kvm]

CVE-2024-53090:

        In the Linux kernel, the following vulnerability has been resolved:  afs: Fix lock recursion  afs_wake_up_async_call() can incur lock recursion.  The problem is that it is called from AF_RXRPC whilst holding the ->notify_lock, but it tries to take a ref on the afs_call struct in order to pass it to a work queue - but if the afs_call is already queued, we then have an extraneous ref that must be put... calling afs_put_call() may call back down into AF_RXRPC through rxrpc_kernel_shutdown_call(), however, which might try taking the ->notify_lock again.  This case isn't very common, however, so defer it to a workqueue.  The oops looks something like:    BUG: spinlock recursion on CPU#0, krxrpcio/7001/1646    lock: 0xffff888141399b30, .magic: dead4ead, .owner: krxrpcio/7001/1646, .owner_cpu: 0   CPU: 0 UID: 0 PID: 1646 Comm: krxrpcio/7001 Not tainted 6.12.0-rc2-build3+ #4351   Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014   Call Trace:    <TASK>    dump_stack_lvl+0x47/0x70    do_raw_spin_lock+0x3c/0x90    rxrpc_kernel_shutdown_call+0x83/0xb0    afs_put_call+0xd7/0x180    rxrpc_notify_socket+0xa0/0x190    rxrpc_input_split_jumbo+0x198/0x1d0    rxrpc_input_data+0x14b/0x1e0    ? rxrpc_input_call_packet+0xc2/0x1f0    rxrpc_input_call_event+0xad/0x6b0    rxrpc_input_packet_on_conn+0x1e1/0x210    rxrpc_input_packet+0x3f2/0x4d0    rxrpc_io_thread+0x243/0x410    ? __pfx_rxrpc_io_thread+0x10/0x10    kthread+0xcf/0xe0    ? __pfx_kthread+0x10/0x10    ret_from_fork+0x24/0x40    ? __pfx_kthread+0x10/0x10    ret_from_fork_asm+0x1a/0x30    </TASK>

CVE-2024-53091:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: Add sk_is_inet and IS_ICSK check in tls_sw_has_ctx_tx/rx  As the introduction of the support for vsock and unix sockets in sockmap, tls_sw_has_ctx_tx/rx cannot presume the socket passed in must be IS_ICSK. vsock and af_unix sockets have vsock_sock and unix_sock instead of inet_connection_sock. For these sockets, tls_get_ctx may return an invalid pointer and cause page fault in function tls_sw_ctx_rx.  BUG: unable to handle page fault for address: 0000000000040030 Workqueue: vsock-loopback vsock_loopback_work RIP: 0010:sk_psock_strp_data_ready+0x23/0x60 Call Trace:  ? __die+0x81/0xc3  ? no_context+0x194/0x350  ? do_page_fault+0x30/0x110  ? async_page_fault+0x3e/0x50  ? sk_psock_strp_data_ready+0x23/0x60  virtio_transport_recv_pkt+0x750/0x800  ? update_load_avg+0x7e/0x620  vsock_loopback_work+0xd0/0x100  process_one_work+0x1a7/0x360  worker_thread+0x30/0x390  ? create_worker+0x1a0/0x1a0  kthread+0x112/0x130  ? __kthread_cancel_work+0x40/0x40  ret_from_fork+0x1f/0x40  v2:   - Add IS_ICSK check v3:   - Update the commits in Fixes

CVE-2024-53094:

        In the Linux kernel, the following vulnerability has been resolved:  RDMA/siw: Add sendpage_ok() check to disable MSG_SPLICE_PAGES  While running ISER over SIW, the initiator machine encounters a warning from skb_splice_from_iter() indicating that a slab page is being used in send_page. To address this, it is better to add a sendpage_ok() check within the driver itself, and if it returns 0, then MSG_SPLICE_PAGES flag should be disabled before entering the network stack.  A similar issue has been discussed for NVMe in this thread: https://lore.kernel.org/all/20240530142417.146696-1-ofir.gal@volumez.com/    WARNING: CPU: 0 PID: 5342 at net/core/skbuff.c:7140 skb_splice_from_iter+0x173/0x320   Call Trace:    tcp_sendmsg_locked+0x368/0xe40    siw_tx_hdt+0x695/0xa40 [siw]    siw_qp_sq_process+0x102/0xb00 [siw]    siw_sq_resume+0x39/0x110 [siw]    siw_run_sq+0x74/0x160 [siw]    kthread+0xd2/0x100    ret_from_fork+0x34/0x40    ret_from_fork_asm+0x1a/0x30

CVE-2024-53095:

        In the Linux kernel, the following vulnerability has been resolved:  smb: client: Fix use-after-free of network namespace.  Recently, we got a customer report that CIFS triggers oops while reconnecting to a server.  [0]  The workload runs on Kubernetes, and some pods mount CIFS servers in non-root network namespaces.  The problem rarely happened, but it was always while the pod was dying.  The root cause is wrong reference counting for network namespace.  CIFS uses kernel sockets, which do not hold refcnt of the netns that the socket belongs to.  That means CIFS must ensure the socket is always freed before its netns; otherwise, use-after-free happens.  The repro steps are roughly:    1. mount CIFS in a non-root netns   2. drop packets from the netns   3. destroy the netns   4. unmount CIFS  We can reproduce the issue quickly with the script [1] below and see the splat [2] if CONFIG_NET_NS_REFCNT_TRACKER is enabled.  When the socket is TCP, it is hard to guarantee the netns lifetime without holding refcnt due to async timers.  Let's hold netns refcnt for each socket as done for SMC in commit 9744d2bf1976 ("smc: Fix use-after-free in tcp_write_timer_handler().").  Note that we need to move put_net() from cifs_put_tcp_session() to clean_demultiplex_info(); otherwise, __sock_create() still could touch a freed netns while cifsd tries to reconnect from cifs_demultiplex_thread().  Also, maybe_get_net() cannot be put just before __sock_create() because the code is not under RCU and there is a small chance that the same address happened to be reallocated to another netns.  [0]: CIFS: VFS: \\XXXXXXXXXXX has not responded in 15 seconds. Reconnecting... CIFS: Serverclose failed 4 times, giving up Unable to handle kernel paging request at virtual address 14de99e461f84a07 Mem abort info:   ESR = 0x0000000096000004   EC = 0x25: DABT (current EL), IL = 32 bits   SET = 0, FnV = 0   EA = 0, S1PTW = 0   FSC = 0x04: level 0 translation fault Data abort info:   ISV = 0, ISS = 0x00000004   CM = 0, WnR = 0 [14de99e461f84a07] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: cls_bpf sch_ingress nls_utf8 cifs cifs_arc4 cifs_md4 dns_resolver tcp_diag inet_diag veth xt_state xt_connmark nf_conntrack_netlink xt_nat xt_statistic xt_MASQUERADE xt_mark xt_addrtype ipt_REJECT nf_reject_ipv4 nft_chain_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment nft_compat nf_tables nfnetlink overlay nls_ascii nls_cp437 sunrpc vfat fat aes_ce_blk aes_ce_cipher ghash_ce sm4_ce_cipher sm4 sm3_ce sm3 sha3_ce sha512_ce sha512_arm64 sha1_ce ena button sch_fq_codel loop fuse configfs dmi_sysfs sha2_ce sha256_arm64 dm_mirror dm_region_hash dm_log dm_mod dax efivarfs CPU: 5 PID: 2690970 Comm: cifsd Not tainted 6.1.103-109.184.amzn2023.aarch64 #1 Hardware name: Amazon EC2 r7g.4xlarge/, BIOS 1.0 11/1/2018 pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : fib_rules_lookup+0x44/0x238 lr : __fib_lookup+0x64/0xbc sp : ffff8000265db790 x29: ffff8000265db790 x28: 0000000000000000 x27: 000000000000bd01 x26: 0000000000000000 x25: ffff000b4baf8000 x24: ffff00047b5e4580 x23: ffff8000265db7e0 x22: 0000000000000000 x21: ffff00047b5e4500 x20: ffff0010e3f694f8 x19: 14de99e461f849f7 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 3f92800abd010002 x11: 0000000000000001 x10: ffff0010e3f69420 x9 : ffff800008a6f294 x8 : 0000000000000000 x7 : 0000000000000006 x6 : 0000000000000000 x5 : 0000000000000001 x4 : ffff001924354280 x3 : ffff8000265db7e0 x2 : 0000000000000000 x1 : ffff0010e3f694f8 x0 : ffff00047b5e4500 Call trace:  fib_rules_lookup+0x44/0x238  __fib_lookup+0x64/0xbc  ip_route_output_key_hash_rcu+0x2c4/0x398  ip_route_output_key_hash+0x60/0x8c  tcp_v4_connect+0x290/0x488  __inet_stream_connect+0x108/0x3d0  inet_stream_connect+0x50/0x78  kernel_connect+0x6c/0xac  generic_ip_conne ---truncated---

CVE-2024-53114:

        In the Linux kernel, the following vulnerability has been resolved:  x86/CPU/AMD: Clear virtualized VMLOAD/VMSAVE on Zen4 client  A number of Zen4 client SoCs advertise the ability to use virtualized VMLOAD/VMSAVE, but using these instructions is reported to be a cause of a random host reboot.  These instructions aren't intended to be advertised on Zen4 client so clear the capability.

CVE-2024-53134:

        In the Linux kernel, the following vulnerability has been resolved:  pmdomain: imx93-blk-ctrl: correct remove path  The check condition should be 'i < bc->onecell_data.num_domains', not 'bc->onecell_data.num_domains' which will make the look never finish and cause kernel panic.  Also disable runtime to address "imx93-blk-ctrl 4ac10000.system-controller: Unbalanced pm_runtime_enable!"

CVE-2024-53147:

        In the Linux kernel, the following vulnerability has been resolved:  exfat: fix out-of-bounds access of directory entries  In the case of the directory size is greater than or equal to the cluster size, if start_clu becomes an EOF cluster(an invalid cluster) due to file system corruption, then the directory entry where ei->hint_femp.eidx hint is outside the directory, resulting in an out-of-bounds access, which may cause further file system corruption.  This commit adds a check for start_clu, if it is an invalid cluster, the file or directory will be treated as empty.

CVE-2024-53168:

        In the Linux kernel, the following vulnerability has been resolved:  sunrpc: fix one UAF issue caused by sunrpc kernel tcp socket  BUG: KASAN: slab-use-after-free in tcp_write_timer_handler+0x156/0x3e0 Read of size 1 at addr ffff888111f322cd by task swapper/0/0  CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc4-dirty #7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 Call Trace:  <IRQ>  dump_stack_lvl+0x68/0xa0  print_address_description.constprop.0+0x2c/0x3d0  print_report+0xb4/0x270  kasan_report+0xbd/0xf0  tcp_write_timer_handler+0x156/0x3e0  tcp_write_timer+0x66/0x170  call_timer_fn+0xfb/0x1d0  __run_timers+0x3f8/0x480  run_timer_softirq+0x9b/0x100  handle_softirqs+0x153/0x390  __irq_exit_rcu+0x103/0x120  irq_exit_rcu+0xe/0x20  sysvec_apic_timer_interrupt+0x76/0x90  </IRQ>  <TASK>  asm_sysvec_apic_timer_interrupt+0x1a/0x20 RIP: 0010:default_idle+0xf/0x20 Code: 4c 01 c7 4c 29 c2 e9 72 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90  90 90 90 90 f3 0f 1e fa 66 90 0f 00 2d 33 f8 25 00 fb f4 <fa> c3 cc cc cc  cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 RSP: 0018:ffffffffa2007e28 EFLAGS: 00000242 RAX: 00000000000f3b31 RBX: 1ffffffff4400fc7 RCX: ffffffffa09c3196 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff9f00590f RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed102360835d R10: ffff88811b041aeb R11: 0000000000000001 R12: 0000000000000000 R13: ffffffffa202d7c0 R14: 0000000000000000 R15: 00000000000147d0  default_idle_call+0x6b/0xa0  cpuidle_idle_call+0x1af/0x1f0  do_idle+0xbc/0x130  cpu_startup_entry+0x33/0x40  rest_init+0x11f/0x210  start_kernel+0x39a/0x420  x86_64_start_reservations+0x18/0x30  x86_64_start_kernel+0x97/0xa0  common_startup_64+0x13e/0x141  </TASK>  Allocated by task 595:  kasan_save_stack+0x24/0x50  kasan_save_track+0x14/0x30  __kasan_slab_alloc+0x87/0x90  kmem_cache_alloc_noprof+0x12b/0x3f0  copy_net_ns+0x94/0x380  create_new_namespaces+0x24c/0x500  unshare_nsproxy_namespaces+0x75/0xf0  ksys_unshare+0x24e/0x4f0  __x64_sys_unshare+0x1f/0x30  do_syscall_64+0x70/0x180  entry_SYSCALL_64_after_hwframe+0x76/0x7e  Freed by task 100:  kasan_save_stack+0x24/0x50  kasan_save_track+0x14/0x30  kasan_save_free_info+0x3b/0x60  __kasan_slab_free+0x54/0x70  kmem_cache_free+0x156/0x5d0  cleanup_net+0x5d3/0x670  process_one_work+0x776/0xa90  worker_thread+0x2e2/0x560  kthread+0x1a8/0x1f0  ret_from_fork+0x34/0x60  ret_from_fork_asm+0x1a/0x30  Reproduction script:  mkdir -p /mnt/nfsshare mkdir -p /mnt/nfs/netns_1 mkfs.ext4 /dev/sdb mount /dev/sdb /mnt/nfsshare systemctl restart nfs-server chmod 777 /mnt/nfsshare exportfs -i -o rw,no_root_squash *:/mnt/nfsshare  ip netns add netns_1 ip link add name veth_1_peer type veth peer veth_1 ifconfig veth_1_peer 11.11.0.254 up ip link set veth_1 netns netns_1 ip netns exec netns_1 ifconfig veth_1 11.11.0.1  ip netns exec netns_1 /root/iptables -A OUTPUT -d 11.11.0.254 -p tcp \ 	--tcp-flags FIN FIN  -j DROP  (note: In my environment, a DESTROY_CLIENTID operation is always sent  immediately, breaking the nfs tcp connection.) ip netns exec netns_1 timeout -s 9 300 mount -t nfs -o proto=tcp,vers=4.1 \ 	11.11.0.254:/mnt/nfsshare /mnt/nfs/netns_1  ip netns del netns_1  The reason here is that the tcp socket in netns_1 (nfs side) has been shutdown and closed (done in xs_destroy), but the FIN message (with ack) is discarded, and the nfsd side keeps sending retransmission messages. As a result, when the tcp sock in netns_1 processes the received message, it sends the message (FIN message) in the sending queue, and the tcp timer is re-established. When the network namespace is deleted, the net structure accessed by tcp's timer handler function causes problems.  To fix this problem, let's hold netns refcnt for the tcp kernel socket as done in other modules. This is an ugly hack which can easily be backported to earlier kernels. A proper fix which cleans up the interfaces will follow, but may not be so easy to backport.

CVE-2024-53176:

        In the Linux kernel, the following vulnerability has been resolved:  smb: During unmount, ensure all cached dir instances drop their dentry  The unmount process (cifs_kill_sb() calling close_all_cached_dirs()) can race with various cached directory operations, which ultimately results in dentries not being dropped and these kernel BUGs:  BUG: Dentry ffff88814f37e358{i=1000000000080,n=/}  still in use (2) [unmount of cifs cifs] VFS: Busy inodes after unmount of cifs (cifs) ------------[ cut here ]------------ kernel BUG at fs/super.c:661!  This happens when a cfid is in the process of being cleaned up when, and has been removed from the cfids->entries list, including:  - Receiving a lease break from the server - Server reconnection triggers invalidate_all_cached_dirs(), which   removes all the cfids from the list - The laundromat thread decides to expire an old cfid.  To solve these problems, dropping the dentry is done in queued work done in a newly-added cfid_put_wq workqueue, and close_all_cached_dirs() flushes that workqueue after it drops all the dentries of which it's aware. This is a global workqueue (rather than scoped to a mount), but the queued work is minimal.  The final cleanup work for cleaning up a cfid is performed via work queued in the serverclose_wq workqueue; this is done separate from dropping the dentries so that close_all_cached_dirs() doesn't block on any server operations.  Both of these queued works expect to invoked with a cfid reference and a tcon reference to avoid those objects from being freed while the work is ongoing.  While we're here, add proper locking to close_all_cached_dirs(), and locking around the freeing of cfid->dentry.

CVE-2024-53178:

        In the Linux kernel, the following vulnerability has been resolved:  smb: Don't leak cfid when reconnect races with open_cached_dir  open_cached_dir() may either race with the tcon reconnection even before compound_send_recv() or directly trigger a reconnection via SMB2_open_init() or SMB_query_info_init().  The reconnection process invokes invalidate_all_cached_dirs() via cifs_mark_open_files_invalid(), which removes all cfids from the cfids->entries list but doesn't drop a ref if has_lease isn't true. This results in the currently-being-constructed cfid not being on the list, but still having a refcount of 2. It leaks if returned from open_cached_dir().  Fix this by setting cfid->has_lease when the ref is actually taken; the cfid will not be used by other threads until it has a valid time.  Addresses these kmemleaks:  unreferenced object 0xffff8881090c4000 (size 1024):   comm "bash", pid 1860, jiffies 4295126592   hex dump (first 32 bytes):     00 01 00 00 00 00 ad de 22 01 00 00 00 00 ad de  ........".......     00 ca 45 22 81 88 ff ff f8 dc 4f 04 81 88 ff ff  ..E"......O.....   backtrace (crc 6f58c20f):     [<ffffffff8b895a1e>] __kmalloc_cache_noprof+0x2be/0x350     [<ffffffff8bda06e3>] open_cached_dir+0x993/0x1fb0     [<ffffffff8bdaa750>] cifs_readdir+0x15a0/0x1d50     [<ffffffff8b9a853f>] iterate_dir+0x28f/0x4b0     [<ffffffff8b9a9aed>] __x64_sys_getdents64+0xfd/0x200     [<ffffffff8cf6da05>] do_syscall_64+0x95/0x1a0     [<ffffffff8d00012f>] entry_SYSCALL_64_after_hwframe+0x76/0x7e unreferenced object 0xffff8881044fdcf8 (size 8):   comm "bash", pid 1860, jiffies 4295126592   hex dump (first 8 bytes):     00 cc cc cc cc cc cc cc                          ........   backtrace (crc 10c106a9):     [<ffffffff8b89a3d3>] __kmalloc_node_track_caller_noprof+0x363/0x480     [<ffffffff8b7d7256>] kstrdup+0x36/0x60     [<ffffffff8bda0700>] open_cached_dir+0x9b0/0x1fb0     [<ffffffff8bdaa750>] cifs_readdir+0x15a0/0x1d50     [<ffffffff8b9a853f>] iterate_dir+0x28f/0x4b0     [<ffffffff8b9a9aed>] __x64_sys_getdents64+0xfd/0x200     [<ffffffff8cf6da05>] do_syscall_64+0x95/0x1a0     [<ffffffff8d00012f>] entry_SYSCALL_64_after_hwframe+0x76/0x7e  And addresses these BUG splats when unmounting the SMB filesystem:  BUG: Dentry ffff888140590ba0{i=1000000000080,n=/}  still in use (2) [unmount of cifs cifs] WARNING: CPU: 3 PID: 3433 at fs/dcache.c:1536 umount_check+0xd0/0x100 Modules linked in: CPU: 3 UID: 0 PID: 3433 Comm: bash Not tainted 6.12.0-rc4-g850925a8133c-dirty #49 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 RIP: 0010:umount_check+0xd0/0x100 Code: 8d 7c 24 40 e8 31 5a f4 ff 49 8b 54 24 40 41 56 49 89 e9 45 89 e8 48 89 d9 41 57 48 89 de 48 c7 c7 80 e7 db ac e8 f0 72 9a ff <0f> 0b 58 31 c0 5a 5b 5d 41 5c 41 5d 41 5e 41 5f e9 2b e5 5d 01 41 RSP: 0018:ffff88811cc27978 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff888140590ba0 RCX: ffffffffaaf20bae RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff8881f6fb6f40 RBP: ffff8881462ec000 R08: 0000000000000001 R09: ffffed1023984ee3 R10: ffff88811cc2771f R11: 00000000016cfcc0 R12: ffff888134383e08 R13: 0000000000000002 R14: ffff8881462ec668 R15: ffffffffaceab4c0 FS:  00007f23bfa98740(0000) GS:ffff8881f6f80000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000556de4a6f808 CR3: 0000000123c80000 CR4: 0000000000350ef0 Call Trace:  <TASK>  d_walk+0x6a/0x530  shrink_dcache_for_umount+0x6a/0x200  generic_shutdown_super+0x52/0x2a0  kill_anon_super+0x22/0x40  cifs_kill_sb+0x159/0x1e0  deactivate_locked_super+0x66/0xe0  cleanup_mnt+0x140/0x210  task_work_run+0xfb/0x170  syscall_exit_to_user_mode+0x29f/0x2b0  do_syscall_64+0xa1/0x1a0  entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f23bfb93ae7 Code: ff ff ff ff c3 66 0f 1f 44 00 00 48 8b 0d 11 93 0d 00 f7 d8 64 89 01 b8 ff ff ff ff eb bf 0f 1f 44 00 00 b8 50 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e9 92 0d 00 f7 d8 64 89  ---truncated---

CVE-2024-53179:

        In the Linux kernel, the following vulnerability has been resolved:  smb: client: fix use-after-free of signing key  Customers have reported use-after-free in @ses->auth_key.response with SMB2.1 + sign mounts which occurs due to following race:  task A                         task B cifs_mount()  dfs_mount_share()   get_session()    cifs_mount_get_session()    cifs_send_recv()     cifs_get_smb_ses()          compound_send_recv()      cifs_setup_session()        smb2_setup_request()       kfree_sensitive()           smb2_calc_signature()                                    crypto_shash_setkey() *UAF*  Fix this by ensuring that we have a valid @ses->auth_key.response by checking whether @ses->ses_status is SES_GOOD or SES_EXITING with @ses->ses_lock held.  After commit 24a9799aa8ef ("smb: client: fix UAF in smb2_reconnect_server()"), we made sure to call ->logoff() only when @ses was known to be good (e.g. valid ->auth_key.response), so it's safe to access signing key when @ses->ses_status == SES_EXITING.

CVE-2024-53187:

        In the Linux kernel, the following vulnerability has been resolved:  io_uring: check for overflows in io_pin_pages  WARNING: CPU: 0 PID: 5834 at io_uring/memmap.c:144 io_pin_pages+0x149/0x180 io_uring/memmap.c:144 CPU: 0 UID: 0 PID: 5834 Comm: syz-executor825 Not tainted 6.12.0-next-20241118-syzkaller #0 Call Trace:  <TASK>  __io_uaddr_map+0xfb/0x2d0 io_uring/memmap.c:183  io_rings_map io_uring/io_uring.c:2611 [inline]  io_allocate_scq_urings+0x1c0/0x650 io_uring/io_uring.c:3470  io_uring_create+0x5b5/0xc00 io_uring/io_uring.c:3692  io_uring_setup io_uring/io_uring.c:3781 [inline]  ...  </TASK>  io_pin_pages()'s uaddr parameter came directly from the user and can be garbage. Don't just add size to it as it can overflow.

CVE-2024-53195:

        In the Linux kernel, the following vulnerability has been resolved:  KVM: arm64: Get rid of userspace_irqchip_in_use  Improper use of userspace_irqchip_in_use led to syzbot hitting the following WARN_ON() in kvm_timer_update_irq():  WARNING: CPU: 0 PID: 3281 at arch/arm64/kvm/arch_timer.c:459 kvm_timer_update_irq+0x21c/0x394 Call trace:   kvm_timer_update_irq+0x21c/0x394 arch/arm64/kvm/arch_timer.c:459   kvm_timer_vcpu_reset+0x158/0x684 arch/arm64/kvm/arch_timer.c:968   kvm_reset_vcpu+0x3b4/0x560 arch/arm64/kvm/reset.c:264   kvm_vcpu_set_target arch/arm64/kvm/arm.c:1553 [inline]   kvm_arch_vcpu_ioctl_vcpu_init arch/arm64/kvm/arm.c:1573 [inline]   kvm_arch_vcpu_ioctl+0x112c/0x1b3c arch/arm64/kvm/arm.c:1695   kvm_vcpu_ioctl+0x4ec/0xf74 virt/kvm/kvm_main.c:4658   vfs_ioctl fs/ioctl.c:51 [inline]   __do_sys_ioctl fs/ioctl.c:907 [inline]   __se_sys_ioctl fs/ioctl.c:893 [inline]   __arm64_sys_ioctl+0x108/0x184 fs/ioctl.c:893   __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]   invoke_syscall+0x78/0x1b8 arch/arm64/kernel/syscall.c:49   el0_svc_common+0xe8/0x1b0 arch/arm64/kernel/syscall.c:132   do_el0_svc+0x40/0x50 arch/arm64/kernel/syscall.c:151   el0_svc+0x54/0x14c arch/arm64/kernel/entry-common.c:712   el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730   el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598  The following sequence led to the scenario:  - Userspace creates a VM and a vCPU.  - The vCPU is initialized with KVM_ARM_VCPU_PMU_V3 during    KVM_ARM_VCPU_INIT.  - Without any other setup, such as vGIC or vPMU, userspace issues    KVM_RUN on the vCPU. Since the vPMU is requested, but not setup,    kvm_arm_pmu_v3_enable() fails in kvm_arch_vcpu_run_pid_change().    As a result, KVM_RUN returns after enabling the timer, but before    incrementing 'userspace_irqchip_in_use':    kvm_arch_vcpu_run_pid_change()        ret = kvm_arm_pmu_v3_enable()            if (!vcpu->arch.pmu.created)                return -EINVAL;        if (ret)            return ret;        [...]        if (!irqchip_in_kernel(kvm))            static_branch_inc(&userspace_irqchip_in_use);  - Userspace ignores the error and issues KVM_ARM_VCPU_INIT again.    Since the timer is already enabled, control moves through the    following flow, ultimately hitting the WARN_ON():    kvm_timer_vcpu_reset()        if (timer->enabled)           kvm_timer_update_irq()               if (!userspace_irqchip())                   ret = kvm_vgic_inject_irq()                       ret = vgic_lazy_init()                           if (unlikely(!vgic_initialized(kvm)))                               if (kvm->arch.vgic.vgic_model !=                                   KVM_DEV_TYPE_ARM_VGIC_V2)                                       return -EBUSY;                   WARN_ON(ret);  Theoretically, since userspace_irqchip_in_use's functionality can be simply replaced by '!irqchip_in_kernel()', get rid of the static key to avoid the mismanagement, which also helps with the syzbot issue.

CVE-2024-53216:

        In the Linux kernel, the following vulnerability has been resolved:  nfsd: release svc_expkey/svc_export with rcu_work  The last reference for `cache_head` can be reduced to zero in `c_show` and `e_show`(using `rcu_read_lock` and `rcu_read_unlock`). Consequently, `svc_export_put` and `expkey_put` will be invoked, leading to two issues:  1. The `svc_export_put` will directly free ex_uuid. However,    `e_show`/`c_show` will access `ex_uuid` after `cache_put`, which can    trigger a use-after-free issue, shown below.     ==================================================================    BUG: KASAN: slab-use-after-free in svc_export_show+0x362/0x430 [nfsd]    Read of size 1 at addr ff11000010fdc120 by task cat/870     CPU: 1 UID: 0 PID: 870 Comm: cat Not tainted 6.12.0-rc3+ #1    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS    1.16.1-2.fc37 04/01/2014    Call Trace:     <TASK>     dump_stack_lvl+0x53/0x70     print_address_description.constprop.0+0x2c/0x3a0     print_report+0xb9/0x280     kasan_report+0xae/0xe0     svc_export_show+0x362/0x430 [nfsd]     c_show+0x161/0x390 [sunrpc]     seq_read_iter+0x589/0x770     seq_read+0x1e5/0x270     proc_reg_read+0xe1/0x140     vfs_read+0x125/0x530     ksys_read+0xc1/0x160     do_syscall_64+0x5f/0x170     entry_SYSCALL_64_after_hwframe+0x76/0x7e     Allocated by task 830:     kasan_save_stack+0x20/0x40     kasan_save_track+0x14/0x30     __kasan_kmalloc+0x8f/0xa0     __kmalloc_node_track_caller_noprof+0x1bc/0x400     kmemdup_noprof+0x22/0x50     svc_export_parse+0x8a9/0xb80 [nfsd]     cache_do_downcall+0x71/0xa0 [sunrpc]     cache_write_procfs+0x8e/0xd0 [sunrpc]     proc_reg_write+0xe1/0x140     vfs_write+0x1a5/0x6d0     ksys_write+0xc1/0x160     do_syscall_64+0x5f/0x170     entry_SYSCALL_64_after_hwframe+0x76/0x7e     Freed by task 868:     kasan_save_stack+0x20/0x40     kasan_save_track+0x14/0x30     kasan_save_free_info+0x3b/0x60     __kasan_slab_free+0x37/0x50     kfree+0xf3/0x3e0     svc_export_put+0x87/0xb0 [nfsd]     cache_purge+0x17f/0x1f0 [sunrpc]     nfsd_destroy_serv+0x226/0x2d0 [nfsd]     nfsd_svc+0x125/0x1e0 [nfsd]     write_threads+0x16a/0x2a0 [nfsd]     nfsctl_transaction_write+0x74/0xa0 [nfsd]     vfs_write+0x1a5/0x6d0     ksys_write+0xc1/0x160     do_syscall_64+0x5f/0x170     entry_SYSCALL_64_after_hwframe+0x76/0x7e  2. We cannot sleep while using `rcu_read_lock`/`rcu_read_unlock`.    However, `svc_export_put`/`expkey_put` will call path_put, which    subsequently triggers a sleeping operation due to the following    `dput`.     =============================    WARNING: suspicious RCU usage    5.10.0-dirty #141 Not tainted    -----------------------------    ...    Call Trace:    dump_stack+0x9a/0xd0    ___might_sleep+0x231/0x240    dput+0x39/0x600    path_put+0x1b/0x30    svc_export_put+0x17/0x80    e_show+0x1c9/0x200    seq_read_iter+0x63f/0x7c0    seq_read+0x226/0x2d0    vfs_read+0x113/0x2c0    ksys_read+0xc9/0x170    do_syscall_64+0x33/0x40    entry_SYSCALL_64_after_hwframe+0x67/0xd1  Fix these issues by using `rcu_work` to help release `svc_expkey`/`svc_export`. This approach allows for an asynchronous context to invoke `path_put` and also facilitates the freeing of `uuid/exp/key` after an RCU grace period.

CVE-2024-53218:

        In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix race in concurrent f2fs_stop_gc_thread  In my test case, concurrent calls to f2fs shutdown report the following stack trace:   Oops: general protection fault, probably for non-canonical address 0xc6cfff63bb5513fc: 0000 [#1] PREEMPT SMP PTI  CPU: 0 UID: 0 PID: 678 Comm: f2fs_rep_shutdo Not tainted 6.12.0-rc5-next-20241029-g6fb2fa9805c5-dirty #85  Call Trace:   <TASK>   ? show_regs+0x8b/0xa0   ? __die_body+0x26/0xa0   ? die_addr+0x54/0x90   ? exc_general_protection+0x24b/0x5c0   ? asm_exc_general_protection+0x26/0x30   ? kthread_stop+0x46/0x390   f2fs_stop_gc_thread+0x6c/0x110   f2fs_do_shutdown+0x309/0x3a0   f2fs_ioc_shutdown+0x150/0x1c0   __f2fs_ioctl+0xffd/0x2ac0   f2fs_ioctl+0x76/0xe0   vfs_ioctl+0x23/0x60   __x64_sys_ioctl+0xce/0xf0   x64_sys_call+0x2b1b/0x4540   do_syscall_64+0xa7/0x240   entry_SYSCALL_64_after_hwframe+0x76/0x7e  The root cause is a race condition in f2fs_stop_gc_thread() called from different f2fs shutdown paths:    [CPU0]                       [CPU1]   ----------------------       -----------------------   f2fs_stop_gc_thread          f2fs_stop_gc_thread                                  gc_th = sbi->gc_thread     gc_th = sbi->gc_thread     kfree(gc_th)     sbi->gc_thread = NULL                                  < gc_th != NULL >                                  kthread_stop(gc_th->f2fs_gc_task) //UAF  The commit c7f114d864ac ("f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread()") attempted to fix this issue by using a read semaphore to prevent races between shutdown and remount threads, but it fails to prevent all race conditions.  Fix it by converting to write lock of s_umount in f2fs_do_shutdown().

CVE-2024-53219:

        In the Linux kernel, the following vulnerability has been resolved:  virtiofs: use pages instead of pointer for kernel direct IO  When trying to insert a 10MB kernel module kept in a virtio-fs with cache disabled, the following warning was reported:    ------------[ cut here ]------------   WARNING: CPU: 1 PID: 404 at mm/page_alloc.c:4551 ......   Modules linked in:   CPU: 1 PID: 404 Comm: insmod Not tainted 6.9.0-rc5+ #123   Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ......   RIP: 0010:__alloc_pages+0x2bf/0x380   ......   Call Trace:    <TASK>    ? __warn+0x8e/0x150    ? __alloc_pages+0x2bf/0x380    __kmalloc_large_node+0x86/0x160    __kmalloc+0x33c/0x480    virtio_fs_enqueue_req+0x240/0x6d0    virtio_fs_wake_pending_and_unlock+0x7f/0x190    queue_request_and_unlock+0x55/0x60    fuse_simple_request+0x152/0x2b0    fuse_direct_io+0x5d2/0x8c0    fuse_file_read_iter+0x121/0x160    __kernel_read+0x151/0x2d0    kernel_read+0x45/0x50    kernel_read_file+0x1a9/0x2a0    init_module_from_file+0x6a/0xe0    idempotent_init_module+0x175/0x230    __x64_sys_finit_module+0x5d/0xb0    x64_sys_call+0x1c3/0x9e0    do_syscall_64+0x3d/0xc0    entry_SYSCALL_64_after_hwframe+0x4b/0x53    ......    </TASK>   ---[ end trace 0000000000000000 ]---  The warning is triggered as follows:  1) syscall finit_module() handles the module insertion and it invokes kernel_read_file() to read the content of the module first.  2) kernel_read_file() allocates a 10MB buffer by using vmalloc() and passes it to kernel_read(). kernel_read() constructs a kvec iter by using iov_iter_kvec() and passes it to fuse_file_read_iter().  3) virtio-fs disables the cache, so fuse_file_read_iter() invokes fuse_direct_io(). As for now, the maximal read size for kvec iter is only limited by fc->max_read. For virtio-fs, max_read is UINT_MAX, so fuse_direct_io() doesn't split the 10MB buffer. It saves the address and the size of the 10MB-sized buffer in out_args[0] of a fuse request and passes the fuse request to virtio_fs_wake_pending_and_unlock().  4) virtio_fs_wake_pending_and_unlock() uses virtio_fs_enqueue_req() to queue the request. Because virtiofs need DMA-able address, so virtio_fs_enqueue_req() uses kmalloc() to allocate a bounce buffer for all fuse args, copies these args into the bounce buffer and passed the physical address of the bounce buffer to virtiofsd. The total length of these fuse args for the passed fuse request is about 10MB, so copy_args_to_argbuf() invokes kmalloc() with a 10MB size parameter and it triggers the warning in __alloc_pages():  	if (WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp)) 		return NULL;  5) virtio_fs_enqueue_req() will retry the memory allocation in a kworker, but it won't help, because kmalloc() will always return NULL due to the abnormal size and finit_module() will hang forever.  A feasible solution is to limit the value of max_read for virtio-fs, so the length passed to kmalloc() will be limited. However it will affect the maximal read size for normal read. And for virtio-fs write initiated from kernel, it has the similar problem but now there is no way to limit fc->max_write in kernel.  So instead of limiting both the values of max_read and max_write in kernel, introducing use_pages_for_kvec_io in fuse_conn and setting it as true in virtiofs. When use_pages_for_kvec_io is enabled, fuse will use pages instead of pointer to pass the KVEC_IO data.  After switching to pages for KVEC_IO data, these pages will be used for DMA through virtio-fs. If these pages are backed by vmalloc(), {flush|invalidate}_kernel_vmap_range() are necessary to flush or invalidate the cache before the DMA operation. So add two new fields in fuse_args_pages to record the base address of vmalloc area and the condition indicating whether invalidation is needed. Perform the flush in fuse_get_user_pages() for write operations and the invalidation in fuse_release_user_pages() for read operations.  It may seem necessary to introduce another fie ---truncated---

CVE-2024-53224:

        In the Linux kernel, the following vulnerability has been resolved:  RDMA/mlx5: Move events notifier registration to be after device registration  Move pkey change work initialization and cleanup from device resources stage to notifier stage, since this is the stage which handles this work events.  Fix a race between the device deregistration and pkey change work by moving MLX5_IB_STAGE_DEVICE_NOTIFIER to be after MLX5_IB_STAGE_IB_REG in order to ensure that the notifier is deregistered before the device during cleanup. Which ensures there are no works that are being executed after the device has already unregistered which can cause the panic below.  BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 630071 Comm: kworker/1:2 Kdump: loaded Tainted: G W OE --------- --- 5.14.0-162.6.1.el9_1.x86_64 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090008 02/27/2023 Workqueue: events pkey_change_handler [mlx5_ib] RIP: 0010:setup_qp+0x38/0x1f0 [mlx5_ib] Code: ee 41 54 45 31 e4 55 89 f5 53 48 89 fb 48 83 ec 20 8b 77 08 65 48 8b 04 25 28 00 00 00 48 89 44 24 18 48 8b 07 48 8d 4c 24 16 <4c> 8b 38 49 8b 87 80 0b 00 00 4c 89 ff 48 8b 80 08 05 00 00 8b 40 RSP: 0018:ffffbcc54068be20 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff954054494128 RCX: ffffbcc54068be36 RDX: ffff954004934000 RSI: 0000000000000001 RDI: ffff954054494128 RBP: 0000000000000023 R08: ffff954001be2c20 R09: 0000000000000001 R10: ffff954001be2c20 R11: ffff9540260133c0 R12: 0000000000000000 R13: 0000000000000023 R14: 0000000000000000 R15: ffff9540ffcb0905 FS: 0000000000000000(0000) GS:ffff9540ffc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010625c001 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: mlx5_ib_gsi_pkey_change+0x20/0x40 [mlx5_ib] process_one_work+0x1e8/0x3c0 worker_thread+0x50/0x3b0 ? rescuer_thread+0x380/0x380 kthread+0x149/0x170 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x22/0x30 Modules linked in: rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) mlx5_fwctl(OE) fwctl(OE) ib_uverbs(OE) mlx5_core(OE) mlxdevm(OE) ib_core(OE) mlx_compat(OE) psample mlxfw(OE) tls knem(OE) netconsole nfsv3 nfs_acl nfs lockd grace fscache netfs qrtr rfkill sunrpc intel_rapl_msr intel_rapl_common rapl hv_balloon hv_utils i2c_piix4 pcspkr joydev fuse ext4 mbcache jbd2 sr_mod sd_mod cdrom t10_pi sg ata_generic pci_hyperv pci_hyperv_intf hyperv_drm drm_shmem_helper drm_kms_helper hv_storvsc syscopyarea hv_netvsc sysfillrect sysimgblt hid_hyperv fb_sys_fops scsi_transport_fc hyperv_keyboard drm ata_piix crct10dif_pclmul crc32_pclmul crc32c_intel libata ghash_clmulni_intel hv_vmbus serio_raw [last unloaded: ib_core] CR2: 0000000000000000 ---[ end trace f6f8be4eae12f7bc ]---

CVE-2024-53687:

        In the Linux kernel, the following vulnerability has been resolved:  riscv: Fix IPIs usage in kfence_protect_page()  flush_tlb_kernel_range() may use IPIs to flush the TLBs of all the cores, which triggers the following warning when the irqs are disabled:  [    3.455330] WARNING: CPU: 1 PID: 0 at kernel/smp.c:815 smp_call_function_many_cond+0x452/0x520 [    3.456647] Modules linked in: [    3.457218] CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.12.0-rc7-00010-g91d3de7240b8 #1 [    3.457416] Hardware name: QEMU QEMU Virtual Machine, BIOS [    3.457633] epc : smp_call_function_many_cond+0x452/0x520 [    3.457736]  ra : on_each_cpu_cond_mask+0x1e/0x30 [    3.457786] epc : ffffffff800b669a ra : ffffffff800b67c2 sp : ff2000000000bb50 [    3.457824]  gp : ffffffff815212b8 tp : ff6000008014f080 t0 : 000000000000003f [    3.457859]  t1 : ffffffff815221e0 t2 : 000000000000000f s0 : ff2000000000bc10 [    3.457920]  s1 : 0000000000000040 a0 : ffffffff815221e0 a1 : 0000000000000001 [    3.457953]  a2 : 0000000000010000 a3 : 0000000000000003 a4 : 0000000000000000 [    3.458006]  a5 : 0000000000000000 a6 : ffffffffffffffff a7 : 0000000000000000 [    3.458042]  s2 : ffffffff815223be s3 : 00fffffffffff000 s4 : ff600001ffe38fc0 [    3.458076]  s5 : ff600001ff950d00 s6 : 0000000200000120 s7 : 0000000000000001 [    3.458109]  s8 : 0000000000000001 s9 : ff60000080841ef0 s10: 0000000000000001 [    3.458141]  s11: ffffffff81524812 t3 : 0000000000000001 t4 : ff60000080092bc0 [    3.458172]  t5 : 0000000000000000 t6 : ff200000000236d0 [    3.458203] status: 0000000200000100 badaddr: ffffffff800b669a cause: 0000000000000003 [    3.458373] [<ffffffff800b669a>] smp_call_function_many_cond+0x452/0x520 [    3.458593] [<ffffffff800b67c2>] on_each_cpu_cond_mask+0x1e/0x30 [    3.458625] [<ffffffff8000e4ca>] __flush_tlb_range+0x118/0x1ca [    3.458656] [<ffffffff8000e6b2>] flush_tlb_kernel_range+0x1e/0x26 [    3.458683] [<ffffffff801ea56a>] kfence_protect+0xc0/0xce [    3.458717] [<ffffffff801e9456>] kfence_guarded_free+0xc6/0x1c0 [    3.458742] [<ffffffff801e9d6c>] __kfence_free+0x62/0xc6 [    3.458764] [<ffffffff801c57d8>] kfree+0x106/0x32c [    3.458786] [<ffffffff80588cf2>] detach_buf_split+0x188/0x1a8 [    3.458816] [<ffffffff8058708c>] virtqueue_get_buf_ctx+0xb6/0x1f6 [    3.458839] [<ffffffff805871da>] virtqueue_get_buf+0xe/0x16 [    3.458880] [<ffffffff80613d6a>] virtblk_done+0x5c/0xe2 [    3.458908] [<ffffffff8058766e>] vring_interrupt+0x6a/0x74 [    3.458930] [<ffffffff800747d8>] __handle_irq_event_percpu+0x7c/0xe2 [    3.458956] [<ffffffff800748f0>] handle_irq_event+0x3c/0x86 [    3.458978] [<ffffffff800786cc>] handle_simple_irq+0x9e/0xbe [    3.459004] [<ffffffff80073934>] generic_handle_domain_irq+0x1c/0x2a [    3.459027] [<ffffffff804bf87c>] imsic_handle_irq+0xba/0x120 [    3.459056] [<ffffffff80073934>] generic_handle_domain_irq+0x1c/0x2a [    3.459080] [<ffffffff804bdb76>] riscv_intc_aia_irq+0x24/0x34 [    3.459103] [<ffffffff809d0452>] handle_riscv_irq+0x2e/0x4c [    3.459133] [<ffffffff809d923e>] call_on_irq_stack+0x32/0x40  So only flush the local TLB and let the lazy kfence page fault handling deal with the faults which could happen when a core has an old protected pte version cached in its TLB. That leads to potential inaccuracies which can be tolerated when using kfence.

CVE-2024-54683:

        In the Linux kernel, the following vulnerability has been resolved:  netfilter: IDLETIMER: Fix for possible ABBA deadlock  Deletion of the last rule referencing a given idletimer may happen at the same time as a read of its file in sysfs:  | ====================================================== | WARNING: possible circular locking dependency detected | 6.12.0-rc7-01692-g5e9a28f41134-dirty #594 Not tainted | ------------------------------------------------------ | iptables/3303 is trying to acquire lock: | ffff8881057e04b8 (kn->active#48){++++}-{0:0}, at: __kernfs_remove+0x20 | | but task is already holding lock: | ffffffffa0249068 (list_mutex){+.+.}-{3:3}, at: idletimer_tg_destroy_v] | | which lock already depends on the new lock.  A simple reproducer is:  | #!/bin/bash | | while true; do |         iptables -A INPUT -i foo -j IDLETIMER --timeout 10 --label "testme" |         iptables -D INPUT -i foo -j IDLETIMER --timeout 10 --label "testme" | done & | while true; do |         cat /sys/class/xt_idletimer/timers/testme >/dev/null | done  Avoid this by freeing list_mutex right after deleting the element from the list, then continuing with the teardown.

CVE-2024-56538:

        In the Linux kernel, the following vulnerability has been resolved:  drm: zynqmp_kms: Unplug DRM device before removal  Prevent userspace accesses to the DRM device from causing use-after-frees by unplugging the device before we remove it. This causes any further userspace accesses to result in an error without further calls into this driver's internals.

CVE-2024-56544:

        In the Linux kernel, the following vulnerability has been resolved:  udmabuf: change folios array from kmalloc to kvmalloc  When PAGE_SIZE 4096, MAX_PAGE_ORDER 10, 64bit machine, page_alloc only support 4MB. If above this, trigger this warn and return NULL.  udmabuf can change size limit, if change it to 3072(3GB), and then alloc 3GB udmabuf, will fail create.  [ 4080.876581] ------------[ cut here ]------------ [ 4080.876843] WARNING: CPU: 3 PID: 2015 at mm/page_alloc.c:4556 __alloc_pages+0x2c8/0x350 [ 4080.878839] RIP: 0010:__alloc_pages+0x2c8/0x350 [ 4080.879470] Call Trace: [ 4080.879473]  <TASK> [ 4080.879473]  ? __alloc_pages+0x2c8/0x350 [ 4080.879475]  ? __warn.cold+0x8e/0xe8 [ 4080.880647]  ? __alloc_pages+0x2c8/0x350 [ 4080.880909]  ? report_bug+0xff/0x140 [ 4080.881175]  ? handle_bug+0x3c/0x80 [ 4080.881556]  ? exc_invalid_op+0x17/0x70 [ 4080.881559]  ? asm_exc_invalid_op+0x1a/0x20 [ 4080.882077]  ? udmabuf_create+0x131/0x400  Because MAX_PAGE_ORDER, kmalloc can max alloc 4096 * (1 << 10), 4MB memory, each array entry is pointer(8byte), so can save 524288 pages(2GB).  Further more, costly order(order 3) may not be guaranteed that it can be applied for, due to fragmentation.  This patch change udmabuf array use kvmalloc_array, this can fallback alloc into vmalloc, which can guarantee allocation for any size and does not affect the performance of kmalloc allocations.

CVE-2024-56565:

        In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to drop all discards after creating snapshot on lvm device  Piergiorgio reported a bug in bugzilla as below:  ------------[ cut here ]------------ WARNING: CPU: 2 PID: 969 at fs/f2fs/segment.c:1330 RIP: 0010:__submit_discard_cmd+0x27d/0x400 [f2fs] Call Trace:  __issue_discard_cmd+0x1ca/0x350 [f2fs]  issue_discard_thread+0x191/0x480 [f2fs]  kthread+0xcf/0x100  ret_from_fork+0x31/0x50  ret_from_fork_asm+0x1a/0x30  w/ below testcase, it can reproduce this bug quickly: - pvcreate /dev/vdb - vgcreate myvg1 /dev/vdb - lvcreate -L 1024m -n mylv1 myvg1 - mount /dev/myvg1/mylv1 /mnt/f2fs - dd if=/dev/zero of=/mnt/f2fs/file bs=1M count=20 - sync - rm /mnt/f2fs/file - sync - lvcreate -L 1024m -s -n mylv1-snapshot /dev/myvg1/mylv1 - umount /mnt/f2fs  The root cause is: it will update discard_max_bytes of mounted lvm device to zero after creating snapshot on this lvm device, then, __submit_discard_cmd() will pass parameter @nr_sects w/ zero value to __blkdev_issue_discard(), it returns a NULL bio pointer, result in panic.  This patch changes as below for fixing: 1. Let's drop all remained discards in f2fs_unfreeze() if snapshot of lvm device is created. 2. Checking discard_max_bytes before submitting discard during __submit_discard_cmd().

CVE-2024-56566:

        In the Linux kernel, the following vulnerability has been resolved:  mm/slub: Avoid list corruption when removing a slab from the full list  Boot with slub_debug=UFPZ.  If allocated object failed in alloc_consistency_checks, all objects of the slab will be marked as used, and then the slab will be removed from the partial list.  When an object belonging to the slab got freed later, the remove_full() function is called. Because the slab is neither on the partial list nor on the full list, it eventually lead to a list corruption (actually a list poison being detected).  So we need to mark and isolate the slab page with metadata corruption, do not put it back in circulation.  Because the debug caches avoid all the fastpaths, reusing the frozen bit to mark slab page with metadata corruption seems to be fine.  [ 4277.385669] list_del corruption, ffffea00044b3e50->next is LIST_POISON1 (dead000000000100) [ 4277.387023] ------------[ cut here ]------------ [ 4277.387880] kernel BUG at lib/list_debug.c:56! [ 4277.388680] invalid opcode: 0000 [#1] PREEMPT SMP PTI [ 4277.389562] CPU: 5 PID: 90 Comm: kworker/5:1 Kdump: loaded Tainted: G           OE      6.6.1-1 #1 [ 4277.392113] Workqueue: xfs-inodegc/vda1 xfs_inodegc_worker [xfs] [ 4277.393551] RIP: 0010:__list_del_entry_valid_or_report+0x7b/0xc0 [ 4277.394518] Code: 48 91 82 e8 37 f9 9a ff 0f 0b 48 89 fe 48 c7 c7 28 49 91 82 e8 26 f9 9a ff 0f 0b 48 89 fe 48 c7 c7 58 49 91 [ 4277.397292] RSP: 0018:ffffc90000333b38 EFLAGS: 00010082 [ 4277.398202] RAX: 000000000000004e RBX: ffffea00044b3e50 RCX: 0000000000000000 [ 4277.399340] RDX: 0000000000000002 RSI: ffffffff828f8715 RDI: 00000000ffffffff [ 4277.400545] RBP: ffffea00044b3e40 R08: 0000000000000000 R09: ffffc900003339f0 [ 4277.401710] R10: 0000000000000003 R11: ffffffff82d44088 R12: ffff888112cf9910 [ 4277.402887] R13: 0000000000000001 R14: 0000000000000001 R15: ffff8881000424c0 [ 4277.404049] FS:  0000000000000000(0000) GS:ffff88842fd40000(0000) knlGS:0000000000000000 [ 4277.405357] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4277.406389] CR2: 00007f2ad0b24000 CR3: 0000000102a3a006 CR4: 00000000007706e0 [ 4277.407589] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 4277.408780] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 4277.410000] PKRU: 55555554 [ 4277.410645] Call Trace: [ 4277.411234]  <TASK> [ 4277.411777]  ? die+0x32/0x80 [ 4277.412439]  ? do_trap+0xd6/0x100 [ 4277.413150]  ? __list_del_entry_valid_or_report+0x7b/0xc0 [ 4277.414158]  ? do_error_trap+0x6a/0x90 [ 4277.414948]  ? __list_del_entry_valid_or_report+0x7b/0xc0 [ 4277.415915]  ? exc_invalid_op+0x4c/0x60 [ 4277.416710]  ? __list_del_entry_valid_or_report+0x7b/0xc0 [ 4277.417675]  ? asm_exc_invalid_op+0x16/0x20 [ 4277.418482]  ? __list_del_entry_valid_or_report+0x7b/0xc0 [ 4277.419466]  ? __list_del_entry_valid_or_report+0x7b/0xc0 [ 4277.420410]  free_to_partial_list+0x515/0x5e0 [ 4277.421242]  ? xfs_iext_remove+0x41a/0xa10 [xfs] [ 4277.422298]  xfs_iext_remove+0x41a/0xa10 [xfs] [ 4277.423316]  ? xfs_inodegc_worker+0xb4/0x1a0 [xfs] [ 4277.424383]  xfs_bmap_del_extent_delay+0x4fe/0x7d0 [xfs] [ 4277.425490]  __xfs_bunmapi+0x50d/0x840 [xfs] [ 4277.426445]  xfs_itruncate_extents_flags+0x13a/0x490 [xfs] [ 4277.427553]  xfs_inactive_truncate+0xa3/0x120 [xfs] [ 4277.428567]  xfs_inactive+0x22d/0x290 [xfs] [ 4277.429500]  xfs_inodegc_worker+0xb4/0x1a0 [xfs] [ 4277.430479]  process_one_work+0x171/0x340 [ 4277.431227]  worker_thread+0x277/0x390 [ 4277.431962]  ? __pfx_worker_thread+0x10/0x10 [ 4277.432752]  kthread+0xf0/0x120 [ 4277.433382]  ? __pfx_kthread+0x10/0x10 [ 4277.434134]  ret_from_fork+0x2d/0x50 [ 4277.434837]  ? __pfx_kthread+0x10/0x10 [ 4277.435566]  ret_from_fork_asm+0x1b/0x30 [ 4277.436280]  </TASK>

CVE-2024-56583:

        In the Linux kernel, the following vulnerability has been resolved:  sched/deadline: Fix warning in migrate_enable for boosted tasks  When running the following command:  while true; do     stress-ng --cyclic 30 --timeout 30s --minimize --quiet done  a warning is eventually triggered:  WARNING: CPU: 43 PID: 2848 at kernel/sched/deadline.c:794 setup_new_dl_entity+0x13e/0x180 ... Call Trace:  <TASK>  ? show_trace_log_lvl+0x1c4/0x2df  ? enqueue_dl_entity+0x631/0x6e0  ? setup_new_dl_entity+0x13e/0x180  ? __warn+0x7e/0xd0  ? report_bug+0x11a/0x1a0  ? handle_bug+0x3c/0x70  ? exc_invalid_op+0x14/0x70  ? asm_exc_invalid_op+0x16/0x20  enqueue_dl_entity+0x631/0x6e0  enqueue_task_dl+0x7d/0x120  __do_set_cpus_allowed+0xe3/0x280  __set_cpus_allowed_ptr_locked+0x140/0x1d0  __set_cpus_allowed_ptr+0x54/0xa0  migrate_enable+0x7e/0x150  rt_spin_unlock+0x1c/0x90  group_send_sig_info+0xf7/0x1a0  ? kill_pid_info+0x1f/0x1d0  kill_pid_info+0x78/0x1d0  kill_proc_info+0x5b/0x110  __x64_sys_kill+0x93/0xc0  do_syscall_64+0x5c/0xf0  entry_SYSCALL_64_after_hwframe+0x6e/0x76  RIP: 0033:0x7f0dab31f92b  This warning occurs because set_cpus_allowed dequeues and enqueues tasks with the ENQUEUE_RESTORE flag set. If the task is boosted, the warning is triggered. A boosted task already had its parameters set by rt_mutex_setprio, and a new call to setup_new_dl_entity is unnecessary, hence the WARN_ON call.  Check if we are requeueing a boosted task and avoid calling setup_new_dl_entity if that's the case.

CVE-2024-56588:

        In the Linux kernel, the following vulnerability has been resolved:  scsi: hisi_sas: Create all dump files during debugfs initialization  For the current debugfs of hisi_sas, after user triggers dump, the driver allocate memory space to save the register information and create debugfs files to display the saved information. In this process, the debugfs files created after each dump.  Therefore, when the dump is triggered while the driver is unbind, the following hang occurs:  [67840.853907] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0 [67840.862947] Mem abort info: [67840.865855]   ESR = 0x0000000096000004 [67840.869713]   EC = 0x25: DABT (current EL), IL = 32 bits [67840.875125]   SET = 0, FnV = 0 [67840.878291]   EA = 0, S1PTW = 0 [67840.881545]   FSC = 0x04: level 0 translation fault [67840.886528] Data abort info: [67840.889524]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [67840.895117]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [67840.900284]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [67840.905709] user pgtable: 4k pages, 48-bit VAs, pgdp=0000002803a1f000 [67840.912263] [00000000000000a0] pgd=0000000000000000, p4d=0000000000000000 [67840.919177] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [67840.996435] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [67841.003628] pc : down_write+0x30/0x98 [67841.007546] lr : start_creating.part.0+0x60/0x198 [67841.012495] sp : ffff8000b979ba20 [67841.016046] x29: ffff8000b979ba20 x28: 0000000000000010 x27: 0000000000024b40 [67841.023412] x26: 0000000000000012 x25: ffff20202b355ae8 x24: ffff20202b35a8c8 [67841.030779] x23: ffffa36877928208 x22: ffffa368b4972240 x21: ffff8000b979bb18 [67841.038147] x20: ffff00281dc1e3c0 x19: fffffffffffffffe x18: 0000000000000020 [67841.045515] x17: 0000000000000000 x16: ffffa368b128a530 x15: ffffffffffffffff [67841.052888] x14: ffff8000b979bc18 x13: ffffffffffffffff x12: ffff8000b979bb18 [67841.060263] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa368b1289b18 [67841.067640] x8 : 0000000000000012 x7 : 0000000000000000 x6 : 00000000000003a9 [67841.075014] x5 : 0000000000000000 x4 : ffff002818c5cb00 x3 : 0000000000000001 [67841.082388] x2 : 0000000000000000 x1 : ffff002818c5cb00 x0 : 00000000000000a0 [67841.089759] Call trace: [67841.092456]  down_write+0x30/0x98 [67841.096017]  start_creating.part.0+0x60/0x198 [67841.100613]  debugfs_create_dir+0x48/0x1f8 [67841.104950]  debugfs_create_files_v3_hw+0x88/0x348 [hisi_sas_v3_hw] [67841.111447]  debugfs_snapshot_regs_v3_hw+0x708/0x798 [hisi_sas_v3_hw] [67841.118111]  debugfs_trigger_dump_v3_hw_write+0x9c/0x120 [hisi_sas_v3_hw] [67841.125115]  full_proxy_write+0x68/0xc8 [67841.129175]  vfs_write+0xd8/0x3f0 [67841.132708]  ksys_write+0x70/0x108 [67841.136317]  __arm64_sys_write+0x24/0x38 [67841.140440]  invoke_syscall+0x50/0x128 [67841.144385]  el0_svc_common.constprop.0+0xc8/0xf0 [67841.149273]  do_el0_svc+0x24/0x38 [67841.152773]  el0_svc+0x38/0xd8 [67841.156009]  el0t_64_sync_handler+0xc0/0xc8 [67841.160361]  el0t_64_sync+0x1a4/0x1a8 [67841.164189] Code: b9000882 d2800002 d2800023 f9800011 (c85ffc05) [67841.170443] ---[ end trace 0000000000000000 ]---  To fix this issue, create all directories and files during debugfs initialization. In this way, the driver only needs to allocate memory space to save information each time the user triggers dumping.

CVE-2024-56591:

        In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: hci_conn: Use disable_delayed_work_sync  This makes use of disable_delayed_work_sync instead cancel_delayed_work_sync as it not only cancel the ongoing work but also disables new submit which is disarable since the object holding the work is about to be freed.

CVE-2024-56592:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: Call free_htab_elem() after htab_unlock_bucket()  For htab of maps, when the map is removed from the htab, it may hold the last reference of the map. bpf_map_fd_put_ptr() will invoke bpf_map_free_id() to free the id of the removed map element. However, bpf_map_fd_put_ptr() is invoked while holding a bucket lock (raw_spin_lock_t), and bpf_map_free_id() attempts to acquire map_idr_lock (spinlock_t), triggering the following lockdep warning:    =============================   [ BUG: Invalid wait context ]   6.11.0-rc4+ #49 Not tainted   -----------------------------   test_maps/4881 is trying to lock:   ffffffff84884578 (map_idr_lock){+...}-{3:3}, at: bpf_map_free_id.part.0+0x21/0x70   other info that might help us debug this:   context-{5:5}   2 locks held by test_maps/4881:    #0: ffffffff846caf60 (rcu_read_lock){....}-{1:3}, at: bpf_fd_htab_map_update_elem+0xf9/0x270    #1: ffff888149ced148 (&htab->lockdep_key#2){....}-{2:2}, at: htab_map_update_elem+0x178/0xa80   stack backtrace:   CPU: 0 UID: 0 PID: 4881 Comm: test_maps Not tainted 6.11.0-rc4+ #49   Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), ...   Call Trace:    <TASK>    dump_stack_lvl+0x6e/0xb0    dump_stack+0x10/0x20    __lock_acquire+0x73e/0x36c0    lock_acquire+0x182/0x450    _raw_spin_lock_irqsave+0x43/0x70    bpf_map_free_id.part.0+0x21/0x70    bpf_map_put+0xcf/0x110    bpf_map_fd_put_ptr+0x9a/0xb0    free_htab_elem+0x69/0xe0    htab_map_update_elem+0x50f/0xa80    bpf_fd_htab_map_update_elem+0x131/0x270    htab_map_update_elem+0x50f/0xa80    bpf_fd_htab_map_update_elem+0x131/0x270    bpf_map_update_value+0x266/0x380    __sys_bpf+0x21bb/0x36b0    __x64_sys_bpf+0x45/0x60    x64_sys_call+0x1b2a/0x20d0    do_syscall_64+0x5d/0x100    entry_SYSCALL_64_after_hwframe+0x76/0x7e  One way to fix the lockdep warning is using raw_spinlock_t for map_idr_lock as well. However, bpf_map_alloc_id() invokes idr_alloc_cyclic() after acquiring map_idr_lock, it will trigger a similar lockdep warning because the slab's lock (s->cpu_slab->lock) is still a spinlock.  Instead of changing map_idr_lock's type, fix the issue by invoking htab_put_fd_value() after htab_unlock_bucket(). However, only deferring the invocation of htab_put_fd_value() is not enough, because the old map pointers in htab of maps can not be saved during batched deletion. Therefore, also defer the invocation of free_htab_elem(), so these to-be-freed elements could be linked together similar to lru map.  There are four callers for ->map_fd_put_ptr:  (1) alloc_htab_elem() (through htab_put_fd_value()) It invokes ->map_fd_put_ptr() under a raw_spinlock_t. The invocation of htab_put_fd_value() can not simply move after htab_unlock_bucket(), because the old element has already been stashed in htab->extra_elems. It may be reused immediately after htab_unlock_bucket() and the invocation of htab_put_fd_value() after htab_unlock_bucket() may release the newly-added element incorrectly. Therefore, saving the map pointer of the old element for htab of maps before unlocking the bucket and releasing the map_ptr after unlock. Beside the map pointer in the old element, should do the same thing for the special fields in the old element as well.  (2) free_htab_elem() (through htab_put_fd_value()) Its caller includes __htab_map_lookup_and_delete_elem(), htab_map_delete_elem() and __htab_map_lookup_and_delete_batch().  For htab_map_delete_elem(), simply invoke free_htab_elem() after htab_unlock_bucket(). For __htab_map_lookup_and_delete_batch(), just like lru map, linking the to-be-freed element into node_to_free list and invoking free_htab_elem() for these element after unlock. It is safe to reuse batch_flink as the link for node_to_free, because these elements have been removed from the hash llist.  Because htab of maps doesn't support lookup_and_delete operation, __htab_map_lookup_and_delete_elem() doesn't have the problem, so kept it as ---truncated---

CVE-2024-56611:

        In the Linux kernel, the following vulnerability has been resolved:  mm/mempolicy: fix migrate_to_node() assuming there is at least one VMA in a MM  We currently assume that there is at least one VMA in a MM, which isn't true.  So we might end up having find_vma() return NULL, to then de-reference NULL.  So properly handle find_vma() returning NULL.  This fixes the report:  Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 UID: 0 PID: 6021 Comm: syz-executor284 Not tainted 6.12.0-rc7-syzkaller-00187-gf868cd251776 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024 RIP: 0010:migrate_to_node mm/mempolicy.c:1090 [inline] RIP: 0010:do_migrate_pages+0x403/0x6f0 mm/mempolicy.c:1194 Code: ... RSP: 0018:ffffc9000375fd08 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffc9000375fd78 RCX: 0000000000000000 RDX: ffff88807e171300 RSI: dffffc0000000000 RDI: ffff88803390c044 RBP: ffff88807e171428 R08: 0000000000000014 R09: fffffbfff2039ef1 R10: ffffffff901cf78f R11: 0000000000000000 R12: 0000000000000003 R13: ffffc9000375fe90 R14: ffffc9000375fe98 R15: ffffc9000375fdf8 FS:  00005555919e1380(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005555919e1ca8 CR3: 000000007f12a000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace:  <TASK>  kernel_migrate_pages+0x5b2/0x750 mm/mempolicy.c:1709  __do_sys_migrate_pages mm/mempolicy.c:1727 [inline]  __se_sys_migrate_pages mm/mempolicy.c:1723 [inline]  __x64_sys_migrate_pages+0x96/0x100 mm/mempolicy.c:1723  do_syscall_x64 arch/x86/entry/common.c:52 [inline]  do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  [akpm@linux-foundation.org: add unlikely()]

CVE-2024-56641:

        In the Linux kernel, the following vulnerability has been resolved:  net/smc: initialize close_work early to avoid warning  We encountered a warning that close_work was canceled before initialization.    WARNING: CPU: 7 PID: 111103 at kernel/workqueue.c:3047 __flush_work+0x19e/0x1b0   Workqueue: events smc_lgr_terminate_work [smc]   RIP: 0010:__flush_work+0x19e/0x1b0   Call Trace:    ? __wake_up_common+0x7a/0x190    ? work_busy+0x80/0x80    __cancel_work_timer+0xe3/0x160    smc_close_cancel_work+0x1a/0x70 [smc]    smc_close_active_abort+0x207/0x360 [smc]    __smc_lgr_terminate.part.38+0xc8/0x180 [smc]    process_one_work+0x19e/0x340    worker_thread+0x30/0x370    ? process_one_work+0x340/0x340    kthread+0x117/0x130    ? __kthread_cancel_work+0x50/0x50    ret_from_fork+0x22/0x30  This is because when smc_close_cancel_work is triggered, e.g. the RDMA driver is rmmod and the LGR is terminated, the conn->close_work is flushed before initialization, resulting in WARN_ON(!work->func).  __smc_lgr_terminate             | smc_connect_{rdma|ism} -------------------------------------------------------------                                 | smc_conn_create 				| \- smc_lgr_register_conn for conn in lgr->conns_all      | \- smc_conn_kill                |    \- smc_close_active_abort    |       \- smc_close_cancel_work  |          \- cancel_work_sync    |             \- __flush_work     | 	         (close_work)   | 	                        | smc_close_init 	                        | \- INIT_WORK(&close_work)  So fix this by initializing close_work before establishing the connection.

CVE-2024-56692:

        In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to do sanity check on node blkaddr in truncate_node()  syzbot reports a f2fs bug as below:  ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2534! RIP: 0010:f2fs_invalidate_blocks+0x35f/0x370 fs/f2fs/segment.c:2534 Call Trace:  truncate_node+0x1ae/0x8c0 fs/f2fs/node.c:909  f2fs_remove_inode_page+0x5c2/0x870 fs/f2fs/node.c:1288  f2fs_evict_inode+0x879/0x15c0 fs/f2fs/inode.c:856  evict+0x4e8/0x9b0 fs/inode.c:723  f2fs_handle_failed_inode+0x271/0x2e0 fs/f2fs/inode.c:986  f2fs_create+0x357/0x530 fs/f2fs/namei.c:394  lookup_open fs/namei.c:3595 [inline]  open_last_lookups fs/namei.c:3694 [inline]  path_openat+0x1c03/0x3590 fs/namei.c:3930  do_filp_open+0x235/0x490 fs/namei.c:3960  do_sys_openat2+0x13e/0x1d0 fs/open.c:1415  do_sys_open fs/open.c:1430 [inline]  __do_sys_openat fs/open.c:1446 [inline]  __se_sys_openat fs/open.c:1441 [inline]  __x64_sys_openat+0x247/0x2a0 fs/open.c:1441  do_syscall_x64 arch/x86/entry/common.c:52 [inline]  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0010:f2fs_invalidate_blocks+0x35f/0x370 fs/f2fs/segment.c:2534  The root cause is: on a fuzzed image, blkaddr in nat entry may be corrupted, then it will cause system panic when using it in f2fs_invalidate_blocks(), to avoid this, let's add sanity check on nat blkaddr in truncate_node().

CVE-2024-56712:

        In the Linux kernel, the following vulnerability has been resolved:  udmabuf: fix memory leak on last export_udmabuf() error path  In export_udmabuf(), if dma_buf_fd() fails because the FD table is full, a dma_buf owning the udmabuf has already been created; but the error handling in udmabuf_create() will tear down the udmabuf without doing anything about the containing dma_buf.  This leaves a dma_buf in memory that contains a dangling pointer; though that doesn't seem to lead to anything bad except a memory leak.  Fix it by moving the dma_buf_fd() call out of export_udmabuf() so that we can give it different error handling.  Note that the shape of this code changed a lot in commit 5e72b2b41a21 ("udmabuf: convert udmabuf driver to use folios"); but the memory leak seems to have existed since the introduction of udmabuf.

CVE-2024-56729:

        In the Linux kernel, the following vulnerability has been resolved:  smb: Initialize cfid->tcon before performing network ops  Avoid leaking a tcon ref when a lease break races with opening the cached directory. Processing the leak break might take a reference to the tcon in cached_dir_lease_break() and then fail to release the ref in cached_dir_offload_close, since cfid->tcon is still NULL.

CVE-2024-56742:

        In the Linux kernel, the following vulnerability has been resolved:  vfio/mlx5: Fix an unwind issue in mlx5vf_add_migration_pages()  Fix an unwind issue in mlx5vf_add_migration_pages().  If a set of pages is allocated but fails to be added to the SG table, they need to be freed to prevent a memory leak.  Any pages successfully added to the SG table will be freed as part of mlx5vf_free_data_buffer().

CVE-2024-56775:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Fix handling of plane refcount  [Why] The mechanism to backup and restore plane states doesn't maintain refcount, which can cause issues if the refcount of the plane changes in between backup and restore operations, such as memory leaks if the refcount was supposed to go down, or double frees / invalid memory accesses if the refcount was supposed to go up.  [How] Cache and re-apply current refcount when restoring plane states.

CVE-2024-57795:

        In the Linux kernel, the following vulnerability has been resolved:  RDMA/rxe: Remove the direct link to net_device  The similar patch in siw is in the link: https://git.kernel.org/rdma/rdma/c/16b87037b48889  This problem also occurred in RXE. The following analyze this problem. In the following Call Traces: " BUG: KASAN: slab-use-after-free in dev_get_flags+0x188/0x1d0 net/core/dev.c:8782 Read of size 4 at addr ffff8880554640b0 by task kworker/1:4/5295  CPU: 1 UID: 0 PID: 5295 Comm: kworker/1:4 Not tainted 6.12.0-rc3-syzkaller-00399-g9197b73fd7bb #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: infiniband ib_cache_event_task Call Trace:  <TASK>  __dump_stack lib/dump_stack.c:94 [inline]  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120  print_address_description mm/kasan/report.c:377 [inline]  print_report+0x169/0x550 mm/kasan/report.c:488  kasan_report+0x143/0x180 mm/kasan/report.c:601  dev_get_flags+0x188/0x1d0 net/core/dev.c:8782  rxe_query_port+0x12d/0x260 drivers/infiniband/sw/rxe/rxe_verbs.c:60  __ib_query_port drivers/infiniband/core/device.c:2111 [inline]  ib_query_port+0x168/0x7d0 drivers/infiniband/core/device.c:2143  ib_cache_update+0x1a9/0xb80 drivers/infiniband/core/cache.c:1494  ib_cache_event_task+0xf3/0x1e0 drivers/infiniband/core/cache.c:1568  process_one_work kernel/workqueue.c:3229 [inline]  process_scheduled_works+0xa65/0x1850 kernel/workqueue.c:3310  worker_thread+0x870/0xd30 kernel/workqueue.c:3391  kthread+0x2f2/0x390 kernel/kthread.c:389  ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244  </TASK> "  1). In the link [1],  "  infiniband syz2: set down "  This means that on 839.350575, the event ib_cache_event_task was sent andi queued in ib_wq.  2). In the link [1],  "  team0 (unregistering): Port device team_slave_0 removed "  It indicates that before 843.251853, the net device should be freed.  3). In the link [1],  "  BUG: KASAN: slab-use-after-free in dev_get_flags+0x188/0x1d0 "  This means that on 850.559070, this slab-use-after-free problem occurred.  In all, on 839.350575, the event ib_cache_event_task was sent and queued in ib_wq,  before 843.251853, the net device veth was freed.  on 850.559070, this event was executed, and the mentioned freed net device was called. Thus, the above call trace occurred.  [1] https://syzkaller.appspot.com/x/log.txt?x=12e7025f980000

CVE-2024-57804:

        In the Linux kernel, the following vulnerability has been resolved:  scsi: mpi3mr: Fix corrupt config pages PHY state is switched in sysfs  The driver, through the SAS transport, exposes a sysfs interface to enable/disable PHYs in a controller/expander setup.  When multiple PHYs are disabled and enabled in rapid succession, the persistent and current config pages related to SAS IO unit/SAS Expander pages could get corrupted.  Use separate memory for each config request.

CVE-2024-57809:

        In the Linux kernel, the following vulnerability has been resolved:  PCI: imx6: Fix suspend/resume support on i.MX6QDL  The suspend/resume functionality is currently broken on the i.MX6QDL platform, as documented in the NXP errata (ERR005723):    https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf  This patch addresses the issue by sharing most of the suspend/resume sequences used by other i.MX devices, while avoiding modifications to critical registers that disrupt the PCIe functionality. It targets the same problem as the following downstream commit:    https://github.com/nxp-imx/linux-imx/commit/4e92355e1f79d225ea842511fcfd42b343b32995  Unlike the downstream commit, this patch also resets the connected PCIe device if possible. Without this reset, certain drivers, such as ath10k or iwlwifi, will crash on resume. The device reset is also done by the driver on other i.MX platforms, making this patch consistent with existing practices.  Upon resuming, the kernel will hang and display an error. Here's an example of the error encountered with the ath10k driver:    ath10k_pci 0000:01:00.0: Unable to change power state from D3hot to D0, device inaccessible   Unhandled fault: imprecise external abort (0x1406) at 0x0106f944  Without this patch, suspend/resume will fail on i.MX6QDL devices if a PCIe device is connected.  [kwilczynski: commit log, added tag for stable releases]

CVE-2024-57857:

        In the Linux kernel, the following vulnerability has been resolved:  RDMA/siw: Remove direct link to net_device  Do not manage a per device direct link to net_device. Rely on associated ib_devices net_device management, not doubling the effort locally. A badly managed local link to net_device was causing a 'KASAN: slab-use-after-free' exception during siw_query_port() call.

CVE-2024-57872:

        In the Linux kernel, the following vulnerability has been resolved:  scsi: ufs: pltfrm: Dellocate HBA during ufshcd_pltfrm_remove()  This will ensure that the scsi host is cleaned up properly using scsi_host_dev_release(). Otherwise, it may lead to memory leaks.

CVE-2024-57888:

        In the Linux kernel, the following vulnerability has been resolved:  workqueue: Do not warn when cancelling WQ_MEM_RECLAIM work from !WQ_MEM_RECLAIM worker  After commit 746ae46c1113 ("drm/sched: Mark scheduler work queues with WQ_MEM_RECLAIM") amdgpu started seeing the following warning:   [ ] workqueue: WQ_MEM_RECLAIM sdma0:drm_sched_run_job_work [gpu_sched] is flushing !WQ_MEM_RECLAIM events:amdgpu_device_delay_enable_gfx_off [amdgpu] ...  [ ] Workqueue: sdma0 drm_sched_run_job_work [gpu_sched] ...  [ ] Call Trace:  [ ]  <TASK> ...  [ ]  ? check_flush_dependency+0xf5/0x110 ...  [ ]  cancel_delayed_work_sync+0x6e/0x80  [ ]  amdgpu_gfx_off_ctrl+0xab/0x140 [amdgpu]  [ ]  amdgpu_ring_alloc+0x40/0x50 [amdgpu]  [ ]  amdgpu_ib_schedule+0xf4/0x810 [amdgpu]  [ ]  ? drm_sched_run_job_work+0x22c/0x430 [gpu_sched]  [ ]  amdgpu_job_run+0xaa/0x1f0 [amdgpu]  [ ]  drm_sched_run_job_work+0x257/0x430 [gpu_sched]  [ ]  process_one_work+0x217/0x720 ...  [ ]  </TASK>  The intent of the verifcation done in check_flush_depedency is to ensure forward progress during memory reclaim, by flagging cases when either a memory reclaim process, or a memory reclaim work item is flushed from a context not marked as memory reclaim safe.  This is correct when flushing, but when called from the cancel(_delayed)_work_sync() paths it is a false positive because work is either already running, or will not be running at all. Therefore cancelling it is safe and we can relax the warning criteria by letting the helper know of the calling context.  References: 746ae46c1113 ("drm/sched: Mark scheduler work queues with WQ_MEM_RECLAIM")

CVE-2024-57900:

        In the Linux kernel, the following vulnerability has been resolved:  ila: serialize calls to nf_register_net_hooks()  syzbot found a race in ila_add_mapping() [1]  commit 031ae72825ce ("ila: call nf_unregister_net_hooks() sooner") attempted to fix a similar issue.  Looking at the syzbot repro, we have concurrent ILA_CMD_ADD commands.  Add a mutex to make sure at most one thread is calling nf_register_net_hooks().  [1]  BUG: KASAN: slab-use-after-free in rht_key_hashfn include/linux/rhashtable.h:159 [inline]  BUG: KASAN: slab-use-after-free in __rhashtable_lookup.constprop.0+0x426/0x550 include/linux/rhashtable.h:604 Read of size 4 at addr ffff888028f40008 by task dhcpcd/5501  CPU: 1 UID: 0 PID: 5501 Comm: dhcpcd Not tainted 6.13.0-rc4-syzkaller-00054-gd6ef8b40d075 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace:  <IRQ>   __dump_stack lib/dump_stack.c:94 [inline]   dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120   print_address_description mm/kasan/report.c:378 [inline]   print_report+0xc3/0x620 mm/kasan/report.c:489   kasan_report+0xd9/0x110 mm/kasan/report.c:602   rht_key_hashfn include/linux/rhashtable.h:159 [inline]   __rhashtable_lookup.constprop.0+0x426/0x550 include/linux/rhashtable.h:604   rhashtable_lookup include/linux/rhashtable.h:646 [inline]   rhashtable_lookup_fast include/linux/rhashtable.h:672 [inline]   ila_lookup_wildcards net/ipv6/ila/ila_xlat.c:127 [inline]   ila_xlat_addr net/ipv6/ila/ila_xlat.c:652 [inline]   ila_nf_input+0x1ee/0x620 net/ipv6/ila/ila_xlat.c:185   nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]   nf_hook_slow+0xbb/0x200 net/netfilter/core.c:626   nf_hook.constprop.0+0x42e/0x750 include/linux/netfilter.h:269   NF_HOOK include/linux/netfilter.h:312 [inline]   ipv6_rcv+0xa4/0x680 net/ipv6/ip6_input.c:309   __netif_receive_skb_one_core+0x12e/0x1e0 net/core/dev.c:5672   __netif_receive_skb+0x1d/0x160 net/core/dev.c:5785   process_backlog+0x443/0x15f0 net/core/dev.c:6117   __napi_poll.constprop.0+0xb7/0x550 net/core/dev.c:6883   napi_poll net/core/dev.c:6952 [inline]   net_rx_action+0xa94/0x1010 net/core/dev.c:7074   handle_softirqs+0x213/0x8f0 kernel/softirq.c:561   __do_softirq kernel/softirq.c:595 [inline]   invoke_softirq kernel/softirq.c:435 [inline]   __irq_exit_rcu+0x109/0x170 kernel/softirq.c:662   irq_exit_rcu+0x9/0x30 kernel/softirq.c:678   instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline]   sysvec_apic_timer_interrupt+0xa4/0xc0 arch/x86/kernel/apic/apic.c:1049

CVE-2024-57974:

        In the Linux kernel, the following vulnerability has been resolved:  udp: Deal with race between UDP socket address change and rehash  If a UDP socket changes its local address while it's receiving datagrams, as a result of connect(), there is a period during which a lookup operation might fail to find it, after the address is changed but before the secondary hash (port and address) and the four-tuple hash (local and remote ports and addresses) are updated.  Secondary hash chains were introduced by commit 30fff9231fad ("udp: bind() optimisation") and, as a result, a rehash operation became needed to make a bound socket reachable again after a connect().  This operation was introduced by commit 719f835853a9 ("udp: add rehash on connect()") which isn't however a complete fix: the socket will be found once the rehashing completes, but not while it's pending.  This is noticeable with a socat(1) server in UDP4-LISTEN mode, and a client sending datagrams to it. After the server receives the first datagram (cf. _xioopen_ipdgram_listen()), it issues a connect() to the address of the sender, in order to set up a directed flow.  Now, if the client, running on a different CPU thread, happens to send a (subsequent) datagram while the server's socket changes its address, but is not rehashed yet, this will result in a failed lookup and a port unreachable error delivered to the client, as apparent from the following reproducer:    LEN=$(($(cat /proc/sys/net/core/wmem_default) / 4))   dd if=/dev/urandom bs=1 count=${LEN} of=tmp.in    while :; do   	taskset -c 1 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,trunc &   	sleep 0.1 || sleep 1   	taskset -c 2 socat OPEN:tmp.in UDP4:localhost:1337,shut-null   	wait   done  where the client will eventually get ECONNREFUSED on a write() (typically the second or third one of a given iteration):    2024/11/13 21:28:23 socat[46901] E write(6, 0x556db2e3c000, 8192): Connection refused  This issue was first observed as a seldom failure in Podman's tests checking UDP functionality while using pasta(1) to connect the container's network namespace, which leads us to a reproducer with the lookup error resulting in an ICMP packet on a tap device:    LOCAL_ADDR="$(ip -j -4 addr show|jq -rM '.[] | .addr_info[0] | select(.scope == "global").local')"    while :; do   	./pasta --config-net -p pasta.pcap -u 1337 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,trunc &   	sleep 0.2 || sleep 1   	socat OPEN:tmp.in UDP4:${LOCAL_ADDR}:1337,shut-null   	wait   	cmp tmp.in tmp.out   done  Once this fails:    tmp.in tmp.out differ: char 8193, line 29  we can finally have a look at what's going on:    $ tshark -r pasta.pcap       1   0.000000           :: ? ff02::16     ICMPv6 110 Multicast Listener Report Message v2       2   0.168690 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192       3   0.168767 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192       4   0.168806 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192       5   0.168827 c6:47:05:8d:dc:04 ? Broadcast    ARP 42 Who has 88.198.0.161? Tell 88.198.0.164       6   0.168851 9a:55:9a:55:9a:55 ? c6:47:05:8d:dc:04 ARP 42 88.198.0.161 is at 9a:55:9a:55:9a:55       7   0.168875 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192       8   0.168896 88.198.0.164 ? 88.198.0.161 ICMP 590 Destination unreachable (Port unreachable)       9   0.168926 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192      10   0.168959 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192      11   0.168989 88.198.0.161 ? 88.198.0.164 UDP 4138 60260 ? 1337 Len=4096      12   0.169010 88.198.0.161 ? 88.198.0.164 UDP 42 60260 ? 1337 Len=0  On the third datagram received, the network namespace of the container initiates an ARP lookup to deliver the ICMP message.  In another variant of this reproducer, starting the client with:    strace -f pasta --config-net -u 1337 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,tru ---truncated---

CVE-2024-57975:

        In the Linux kernel, the following vulnerability has been resolved:  btrfs: do proper folio cleanup when run_delalloc_nocow() failed  [BUG] With CONFIG_DEBUG_VM set, test case generic/476 has some chance to crash with the following VM_BUG_ON_FOLIO():    BTRFS error (device dm-3): cow_file_range failed, start 1146880 end 1253375 len 106496 ret -28   BTRFS error (device dm-3): run_delalloc_nocow failed, start 1146880 end 1253375 len 106496 ret -28   page: refcount:4 mapcount:0 mapping:00000000592787cc index:0x12 pfn:0x10664   aops:btrfs_aops [btrfs] ino:101 dentry name(?):"f1774"   flags: 0x2fffff80004028(uptodate|lru|private|node=0|zone=2|lastcpupid=0xfffff)   page dumped because: VM_BUG_ON_FOLIO(!folio_test_locked(folio))   ------------[ cut here ]------------   kernel BUG at mm/page-writeback.c:2992!   Internal error: Oops - BUG: 00000000f2000800 [#1] SMP   CPU: 2 UID: 0 PID: 3943513 Comm: kworker/u24:15 Tainted: G           OE      6.12.0-rc7-custom+ #87   Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE   Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022   Workqueue: events_unbound btrfs_async_reclaim_data_space [btrfs]   pc : folio_clear_dirty_for_io+0x128/0x258   lr : folio_clear_dirty_for_io+0x128/0x258   Call trace:    folio_clear_dirty_for_io+0x128/0x258    btrfs_folio_clamp_clear_dirty+0x80/0xd0 [btrfs]    __process_folios_contig+0x154/0x268 [btrfs]    extent_clear_unlock_delalloc+0x5c/0x80 [btrfs]    run_delalloc_nocow+0x5f8/0x760 [btrfs]    btrfs_run_delalloc_range+0xa8/0x220 [btrfs]    writepage_delalloc+0x230/0x4c8 [btrfs]    extent_writepage+0xb8/0x358 [btrfs]    extent_write_cache_pages+0x21c/0x4e8 [btrfs]    btrfs_writepages+0x94/0x150 [btrfs]    do_writepages+0x74/0x190    filemap_fdatawrite_wbc+0x88/0xc8    start_delalloc_inodes+0x178/0x3a8 [btrfs]    btrfs_start_delalloc_roots+0x174/0x280 [btrfs]    shrink_delalloc+0x114/0x280 [btrfs]    flush_space+0x250/0x2f8 [btrfs]    btrfs_async_reclaim_data_space+0x180/0x228 [btrfs]    process_one_work+0x164/0x408    worker_thread+0x25c/0x388    kthread+0x100/0x118    ret_from_fork+0x10/0x20   Code: 910a8021 a90363f7 a9046bf9 94012379 (d4210000)   ---[ end trace 0000000000000000 ]---  [CAUSE] The first two lines of extra debug messages show the problem is caused by the error handling of run_delalloc_nocow().  E.g. we have the following dirtied range (4K blocksize 4K page size):      0                 16K                  32K     |//////////////////////////////////////|     |  Pre-allocated  |  And the range [0, 16K) has a preallocated extent.  - Enter run_delalloc_nocow() for range [0, 16K)   Which found range [0, 16K) is preallocated, can do the proper NOCOW   write.  - Enter fallback_to_fow() for range [16K, 32K)   Since the range [16K, 32K) is not backed by preallocated extent, we   have to go COW.  - cow_file_range() failed for range [16K, 32K)   So cow_file_range() will do the clean up by clearing folio dirty,   unlock the folios.    Now the folios in range [16K, 32K) is unlocked.  - Enter extent_clear_unlock_delalloc() from run_delalloc_nocow()   Which is called with PAGE_START_WRITEBACK to start page writeback.   But folios can only be marked writeback when it's properly locked,   thus this triggered the VM_BUG_ON_FOLIO().  Furthermore there is another hidden but common bug that run_delalloc_nocow() is not clearing the folio dirty flags in its error handling path. This is the common bug shared between run_delalloc_nocow() and cow_file_range().  [FIX] - Clear folio dirty for range [@start, @cur_offset)   Introduce a helper, cleanup_dirty_folios(), which   will find and lock the folio in the range, clear the dirty flag and   start/end the writeback, with the extra handling for the   @locked_folio.  - Introduce a helper to clear folio dirty, start and end writeback  - Introduce a helper to record the last failed COW range end   This is to trace which range we should skip, to avoid double   unlocking.  - Skip the failed COW range for the e ---truncated---

CVE-2024-57976:

        In the Linux kernel, the following vulnerability has been resolved:  btrfs: do proper folio cleanup when cow_file_range() failed  [BUG] When testing with COW fixup marked as BUG_ON() (this is involved with the new pin_user_pages*() change, which should not result new out-of-band dirty pages), I hit a crash triggered by the BUG_ON() from hitting COW fixup path.  This BUG_ON() happens just after a failed btrfs_run_delalloc_range():    BTRFS error (device dm-2): failed to run delalloc range, root 348 ino 405 folio 65536 submit_bitmap 6-15 start 90112 len 106496: -28   ------------[ cut here ]------------   kernel BUG at fs/btrfs/extent_io.c:1444!   Internal error: Oops - BUG: 00000000f2000800 [#1] SMP   CPU: 0 UID: 0 PID: 434621 Comm: kworker/u24:8 Tainted: G           OE      6.12.0-rc7-custom+ #86   Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022   Workqueue: events_unbound btrfs_async_reclaim_data_space [btrfs]   pc : extent_writepage_io+0x2d4/0x308 [btrfs]   lr : extent_writepage_io+0x2d4/0x308 [btrfs]   Call trace:    extent_writepage_io+0x2d4/0x308 [btrfs]    extent_writepage+0x218/0x330 [btrfs]    extent_write_cache_pages+0x1d4/0x4b0 [btrfs]    btrfs_writepages+0x94/0x150 [btrfs]    do_writepages+0x74/0x190    filemap_fdatawrite_wbc+0x88/0xc8    start_delalloc_inodes+0x180/0x3b0 [btrfs]    btrfs_start_delalloc_roots+0x174/0x280 [btrfs]    shrink_delalloc+0x114/0x280 [btrfs]    flush_space+0x250/0x2f8 [btrfs]    btrfs_async_reclaim_data_space+0x180/0x228 [btrfs]    process_one_work+0x164/0x408    worker_thread+0x25c/0x388    kthread+0x100/0x118    ret_from_fork+0x10/0x20   Code: aa1403e1 9402f3ef aa1403e0 9402f36f (d4210000)   ---[ end trace 0000000000000000 ]---  [CAUSE] That failure is mostly from cow_file_range(), where we can hit -ENOSPC.  Although the -ENOSPC is already a bug related to our space reservation code, let's just focus on the error handling.  For example, we have the following dirty range [0, 64K) of an inode, with 4K sector size and 4K page size:     0        16K        32K       48K       64K    |///////////////////////////////////////|    |#######################################|  Where |///| means page are still dirty, and |###| means the extent io tree has EXTENT_DELALLOC flag.  - Enter extent_writepage() for page 0  - Enter btrfs_run_delalloc_range() for range [0, 64K)  - Enter cow_file_range() for range [0, 64K)  - Function btrfs_reserve_extent() only reserved one 16K extent   So we created extent map and ordered extent for range [0, 16K)     0        16K        32K       48K       64K    |////////|//////////////////////////////|    |<- OE ->|##############################|     And range [0, 16K) has its delalloc flag cleared.    But since we haven't yet submit any bio, involved 4 pages are still    dirty.  - Function btrfs_reserve_extent() returns with -ENOSPC   Now we have to run error cleanup, which will clear all   EXTENT_DELALLOC* flags and clear the dirty flags for the remaining   ranges:     0        16K        32K       48K       64K    |////////|                              |    |        |                              |    Note that range [0, 16K) still has its pages dirty.  - Some time later, writeback is triggered again for the range [0, 16K)   since the page range still has dirty flags.  - btrfs_run_delalloc_range() will do nothing because there is no   EXTENT_DELALLOC flag.  - extent_writepage_io() finds page 0 has no ordered flag   Which falls into the COW fixup path, triggering the BUG_ON().  Unfortunately this error handling bug dates back to the introduction of btrfs.  Thankfully with the abuse of COW fixup, at least it won't crash the kernel.  [FIX] Instead of immediately unlocking the extent and folios, we keep the extent and folios locked until either erroring out or the whole delalloc range finished.  When the whole delalloc range finished without error, we just unlock the whole range with PAGE_SET_ORDERED (and PAGE_UNLOCK for !keep_locked cases) ---truncated---

CVE-2024-57982:

        In the Linux kernel, the following vulnerability has been resolved:  xfrm: state: fix out-of-bounds read during lookup  lookup and resize can run in parallel.  The xfrm_state_hash_generation seqlock ensures a retry, but the hash functions can observe a hmask value that is too large for the new hlist array.  rehash does:   rcu_assign_pointer(net->xfrm.state_bydst, ndst) [..]   net->xfrm.state_hmask = nhashmask;  While state lookup does:   h = xfrm_dst_hash(net, daddr, saddr, tmpl->reqid, encap_family);   hlist_for_each_entry_rcu(x, net->xfrm.state_bydst + h, bydst) {  This is only safe in case the update to state_bydst is larger than net->xfrm.xfrm_state_hmask (or if the lookup function gets serialized via state spinlock again).  Fix this by prefetching state_hmask and the associated pointers. The xfrm_state_hash_generation seqlock retry will ensure that the pointer and the hmask will be consistent.  The existing helpers, like xfrm_dst_hash(), are now unsafe for RCU side, add lockdep assertions to document that they are only safe for insert side.  xfrm_state_lookup_byaddr() uses the spinlock rather than RCU. AFAICS this is an oversight from back when state lookup was converted to RCU, this lock should be replaced with RCU in a future patch.

CVE-2024-57984:

        In the Linux kernel, the following vulnerability has been resolved:  i3c: dw: Fix use-after-free in dw_i3c_master driver due to race condition  In dw_i3c_common_probe, &master->hj_work is bound with dw_i3c_hj_work. And dw_i3c_master_irq_handler can call dw_i3c_master_irq_handle_ibis function to start the work.  If we remove the module which will call dw_i3c_common_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows:  CPU0                                      CPU1                                       | dw_i3c_hj_work dw_i3c_common_remove                 | i3c_master_unregister(&master->base) | device_unregister(&master->dev)      | device_release                       | //free master->base                  |                                      | i3c_master_do_daa(&master->base)                                      | //use master->base  Fix it by ensuring that the work is canceled before proceeding with the cleanup in dw_i3c_common_remove.

CVE-2024-57999:

        In the Linux kernel, the following vulnerability has been resolved:  powerpc/pseries/iommu: IOMMU incorrectly marks MMIO range in DDW  Power Hypervisor can possibily allocate MMIO window intersecting with Dynamic DMA Window (DDW) range, which is over 32-bit addressing.  These MMIO pages needs to be marked as reserved so that IOMMU doesn't map DMA buffers in this range.  The current code is not marking these pages correctly which is resulting in LPAR to OOPS while booting. The stack is at below  BUG: Unable to handle kernel data access on read at 0xc00800005cd40000 Faulting instruction address: 0xc00000000005cdac Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries Modules linked in: af_packet rfkill ibmveth(X) lpfc(+) nvmet_fc nvmet nvme_keyring crct10dif_vpmsum nvme_fc nvme_fabrics nvme_core be2net(+) nvme_auth rtc_generic nfsd auth_rpcgss nfs_acl lockd grace sunrpc fuse configfs ip_tables x_tables xfs libcrc32c dm_service_time ibmvfc(X) scsi_transport_fc vmx_crypto gf128mul crc32c_vpmsum dm_mirror dm_region_hash dm_log dm_multipath dm_mod sd_mod scsi_dh_emc scsi_dh_rdac scsi_dh_alua t10_pi crc64_rocksoft_generic crc64_rocksoft sg crc64 scsi_mod Supported: Yes, External CPU: 8 PID: 241 Comm: kworker/8:1 Kdump: loaded Not tainted 6.4.0-150600.23.14-default #1 SLE15-SP6 b44ee71c81261b9e4bab5e0cde1f2ed891d5359b Hardware name: IBM,9080-M9S POWER9 (raw) 0x4e2103 0xf000005 of:IBM,FW950.B0 (VH950_149) hv:phyp pSeries Workqueue: events work_for_cpu_fn NIP:  c00000000005cdac LR: c00000000005e830 CTR: 0000000000000000 REGS: c00001400c9ff770 TRAP: 0300   Not tainted  (6.4.0-150600.23.14-default) MSR:  800000000280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE>  CR: 24228448  XER: 00000001 CFAR: c00000000005cdd4 DAR: c00800005cd40000 DSISR: 40000000 IRQMASK: 0 GPR00: c00000000005e830 c00001400c9ffa10 c000000001987d00 c00001400c4fe800 GPR04: 0000080000000000 0000000000000001 0000000004000000 0000000000800000 GPR08: 0000000004000000 0000000000000001 c00800005cd40000 ffffffffffffffff GPR12: 0000000084228882 c00000000a4c4f00 0000000000000010 0000080000000000 GPR16: c00001400c4fe800 0000000004000000 0800000000000000 c00000006088b800 GPR20: c00001401a7be980 c00001400eff3800 c000000002a2da68 000000000000002b GPR24: c0000000026793a8 c000000002679368 000000000000002a c0000000026793c8 GPR28: 000008007effffff 0000080000000000 0000000000800000 c00001400c4fe800 NIP [c00000000005cdac] iommu_table_reserve_pages+0xac/0x100 LR [c00000000005e830] iommu_init_table+0x80/0x1e0 Call Trace: [c00001400c9ffa10] [c00000000005e810] iommu_init_table+0x60/0x1e0 (unreliable) [c00001400c9ffa90] [c00000000010356c] iommu_bypass_supported_pSeriesLP+0x9cc/0xe40 [c00001400c9ffc30] [c00000000005c300] dma_iommu_dma_supported+0xf0/0x230 [c00001400c9ffcb0] [c00000000024b0c4] dma_supported+0x44/0x90 [c00001400c9ffcd0] [c00000000024b14c] dma_set_mask+0x3c/0x80 [c00001400c9ffd00] [c0080000555b715c] be_probe+0xc4/0xb90 [be2net] [c00001400c9ffdc0] [c000000000986f3c] local_pci_probe+0x6c/0x110 [c00001400c9ffe40] [c000000000188f28] work_for_cpu_fn+0x38/0x60 [c00001400c9ffe70] [c00000000018e454] process_one_work+0x314/0x620 [c00001400c9fff10] [c00000000018f280] worker_thread+0x2b0/0x620 [c00001400c9fff90] [c00000000019bb18] kthread+0x148/0x150 [c00001400c9fffe0] [c00000000000ded8] start_kernel_thread+0x14/0x18  There are 2 issues in the code  1. The index is "int" while the address is "unsigned long". This results in    negative value when setting the bitmap.  2. The DMA offset is page shifted but the MMIO range is used as-is (64-bit    address). MMIO address needs to be page shifted as well.

CVE-2024-58006:

        In the Linux kernel, the following vulnerability has been resolved:  PCI: dwc: ep: Prevent changing BAR size/flags in pci_epc_set_bar()  In commit 4284c88fff0e ("PCI: designware-ep: Allow pci_epc_set_bar() update inbound map address") set_bar() was modified to support dynamically changing the backing physical address of a BAR that was already configured.  This means that set_bar() can be called twice, without ever calling clear_bar() (as calling clear_bar() would clear the BAR's PCI address assigned by the host).  This can only be done if the new BAR size/flags does not differ from the existing BAR configuration. Add these missing checks.  If we allow set_bar() to set e.g. a new BAR size that differs from the existing BAR size, the new address translation range will be smaller than the BAR size already determined by the host, which would mean that a read past the new BAR size would pass the iATU untranslated, which could allow the host to read memory not belonging to the new struct pci_epf_bar.  While at it, add comments which clarifies the support for dynamically changing the physical address of a BAR. (Which was also missing.)

CVE-2024-58012:

        In the Linux kernel, the following vulnerability has been resolved:  ASoC: SOF: Intel: hda-dai: Ensure DAI widget is valid during params  Each cpu DAI should associate with a widget. However, the topology might not create the right number of DAI widgets for aggregated amps. And it will cause NULL pointer deference. Check that the DAI widget associated with the CPU DAI is valid to prevent NULL pointer deference due to missing DAI widgets in topologies with aggregated amps.

CVE-2024-58053:

        In the Linux kernel, the following vulnerability has been resolved:  rxrpc: Fix handling of received connection abort  Fix the handling of a connection abort that we've received.  Though the abort is at the connection level, it needs propagating to the calls on that connection.  Whilst the propagation bit is performed, the calls aren't then woken up to go and process their termination, and as no further input is forthcoming, they just hang.  Also add some tracing for the logging of connection aborts.

CVE-2024-58089:

        In the Linux kernel, the following vulnerability has been resolved:  btrfs: fix double accounting race when btrfs_run_delalloc_range() failed  [BUG] When running btrfs with block size (4K) smaller than page size (64K, aarch64), there is a very high chance to crash the kernel at generic/750, with the following messages: (before the call traces, there are 3 extra debug messages added)    BTRFS warning (device dm-3): read-write for sector size 4096 with page size 65536 is experimental   BTRFS info (device dm-3): checking UUID tree   hrtimer: interrupt took 5451385 ns   BTRFS error (device dm-3): cow_file_range failed, root=4957 inode=257 start=1605632 len=69632: -28   BTRFS error (device dm-3): run_delalloc_nocow failed, root=4957 inode=257 start=1605632 len=69632: -28   BTRFS error (device dm-3): failed to run delalloc range, root=4957 ino=257 folio=1572864 submit_bitmap=8-15 start=1605632 len=69632: -28   ------------[ cut here ]------------   WARNING: CPU: 2 PID: 3020984 at ordered-data.c:360 can_finish_ordered_extent+0x370/0x3b8 [btrfs]   CPU: 2 UID: 0 PID: 3020984 Comm: kworker/u24:1 Tainted: G           OE      6.13.0-rc1-custom+ #89   Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE   Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022   Workqueue: events_unbound btrfs_async_reclaim_data_space [btrfs]   pc : can_finish_ordered_extent+0x370/0x3b8 [btrfs]   lr : can_finish_ordered_extent+0x1ec/0x3b8 [btrfs]   Call trace:    can_finish_ordered_extent+0x370/0x3b8 [btrfs] (P)    can_finish_ordered_extent+0x1ec/0x3b8 [btrfs] (L)    btrfs_mark_ordered_io_finished+0x130/0x2b8 [btrfs]    extent_writepage+0x10c/0x3b8 [btrfs]    extent_write_cache_pages+0x21c/0x4e8 [btrfs]    btrfs_writepages+0x94/0x160 [btrfs]    do_writepages+0x74/0x190    filemap_fdatawrite_wbc+0x74/0xa0    start_delalloc_inodes+0x17c/0x3b0 [btrfs]    btrfs_start_delalloc_roots+0x17c/0x288 [btrfs]    shrink_delalloc+0x11c/0x280 [btrfs]    flush_space+0x288/0x328 [btrfs]    btrfs_async_reclaim_data_space+0x180/0x228 [btrfs]    process_one_work+0x228/0x680    worker_thread+0x1bc/0x360    kthread+0x100/0x118    ret_from_fork+0x10/0x20   ---[ end trace 0000000000000000 ]---   BTRFS critical (device dm-3): bad ordered extent accounting, root=4957 ino=257 OE offset=1605632 OE len=16384 to_dec=16384 left=0   BTRFS critical (device dm-3): bad ordered extent accounting, root=4957 ino=257 OE offset=1622016 OE len=12288 to_dec=12288 left=0   Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008   BTRFS critical (device dm-3): bad ordered extent accounting, root=4957 ino=257 OE offset=1634304 OE len=8192 to_dec=4096 left=0   CPU: 1 UID: 0 PID: 3286940 Comm: kworker/u24:3 Tainted: G        W  OE      6.13.0-rc1-custom+ #89   Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022   Workqueue:  btrfs_work_helper [btrfs] (btrfs-endio-write)   pstate: 404000c5 (nZcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)   pc : process_one_work+0x110/0x680   lr : worker_thread+0x1bc/0x360   Call trace:    process_one_work+0x110/0x680 (P)    worker_thread+0x1bc/0x360 (L)    worker_thread+0x1bc/0x360    kthread+0x100/0x118    ret_from_fork+0x10/0x20   Code: f84086a1 f9000fe1 53041c21 b9003361 (f9400661)   ---[ end trace 0000000000000000 ]---   Kernel panic - not syncing: Oops: Fatal exception   SMP: stopping secondary CPUs   SMP: failed to stop secondary CPUs 2-3   Dumping ftrace buffer:      (ftrace buffer empty)   Kernel Offset: 0x275bb9540000 from 0xffff800080000000   PHYS_OFFSET: 0xffff8fbba0000000   CPU features: 0x100,00000070,00801250,8201720b  [CAUSE] The above warning is triggered immediately after the delalloc range failure, this happens in the following sequence:  - Range [1568K, 1636K) is dirty     1536K  1568K     1600K    1636K  1664K    |      |/////////|////////|      |    Where 1536K, 1600K and 1664K are page boundaries (64K page size)  - Enter extent_writepage() for page 1536K  - Enter run_delalloc_nocow() with locke ---truncated---

CVE-2024-58096:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: ath11k: add srng->lock for ath11k_hal_srng_* in monitor mode  ath11k_hal_srng_* should be used with srng->lock to protect srng data.  For ath11k_dp_rx_mon_dest_process() and ath11k_dp_full_mon_process_rx(), they use ath11k_hal_srng_* for many times but never call srng->lock.  So when running (full) monitor mode, warning will occur: RIP: 0010:ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k] Call Trace:  ? ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k]  ath11k_dp_rx_process_mon_status+0xc45/0x1190 [ath11k]  ? idr_alloc_u32+0x97/0xd0  ath11k_dp_rx_process_mon_rings+0x32a/0x550 [ath11k]  ath11k_dp_service_srng+0x289/0x5a0 [ath11k]  ath11k_pcic_ext_grp_napi_poll+0x30/0xd0 [ath11k]  __napi_poll+0x30/0x1f0  net_rx_action+0x198/0x320  __do_softirq+0xdd/0x319  So add srng->lock for them to avoid such warnings.  Inorder to fetch the srng->lock, should change srng's definition from 'void' to 'struct hal_srng'. And initialize them elsewhere to prevent one line of code from being too long. This is consistent with other ring process functions, such as ath11k_dp_process_rx().  Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30 Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1

CVE-2024-58098:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: track changes_pkt_data property for global functions  When processing calls to certain helpers, verifier invalidates all packet pointers in a current state. For example, consider the following program:      __attribute__((__noinline__))     long skb_pull_data(struct __sk_buff *sk, __u32 len)     {         return bpf_skb_pull_data(sk, len);     }      SEC("tc")     int test_invalidate_checks(struct __sk_buff *sk)     {         int *p = (void *)(long)sk->data;         if ((void *)(p + 1) > (void *)(long)sk->data_end) return TCX_DROP;         skb_pull_data(sk, 0);         *p = 42;         return TCX_PASS;     }  After a call to bpf_skb_pull_data() the pointer 'p' can't be used safely. See function filter.c:bpf_helper_changes_pkt_data() for a list of such helpers.  At the moment verifier invalidates packet pointers when processing helper function calls, and does not traverse global sub-programs when processing calls to global sub-programs. This means that calls to helpers done from global sub-programs do not invalidate pointers in the caller state. E.g. the program above is unsafe, but is not rejected by verifier.  This commit fixes the omission by computing field bpf_subprog_info->changes_pkt_data for each sub-program before main verification pass. changes_pkt_data should be set if: - subprogram calls helper for which bpf_helper_changes_pkt_data   returns true; - subprogram calls a global function,   for which bpf_subprog_info->changes_pkt_data should be set.  The verifier.c:check_cfg() pass is modified to compute this information. The commit relies on depth first instruction traversal done by check_cfg() and absence of recursive function calls: - check_cfg() would eventually visit every call to subprogram S in a   state when S is fully explored; - when S is fully explored:   - every direct helper call within S is explored     (and thus changes_pkt_data is set if needed);   - every call to subprogram S1 called by S was visited with S1 fully     explored (and thus S inherits changes_pkt_data from S1).  The downside of such approach is that dead code elimination is not taken into account: if a helper call inside global function is dead because of current configuration, verifier would conservatively assume that the call occurs for the purpose of the changes_pkt_data computation.

CVE-2024-58100:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: check changes_pkt_data property for extension programs  When processing calls to global sub-programs, verifier decides whether to invalidate all packet pointers in current state depending on the changes_pkt_data property of the global sub-program.  Because of this, an extension program replacing a global sub-program must be compatible with changes_pkt_data property of the sub-program being replaced.  This commit: - adds changes_pkt_data flag to struct bpf_prog_aux:   - this flag is set in check_cfg() for main sub-program;   - in jit_subprogs() for other sub-programs; - modifies bpf_check_attach_btf_id() to check changes_pkt_data flag; - moves call to check_attach_btf_id() after the call to check_cfg(),   because it needs changes_pkt_data flag to be set:      bpf_check:       ...                             ...     - check_attach_btf_id             resolve_pseudo_ldimm64       resolve_pseudo_ldimm64   -->    bpf_prog_is_offloaded       bpf_prog_is_offloaded           check_cfg       check_cfg                     + check_attach_btf_id       ...                             ...  The following fields are set by check_attach_btf_id(): - env->ops - prog->aux->attach_btf_trace - prog->aux->attach_func_name - prog->aux->attach_func_proto - prog->aux->dst_trampoline - prog->aux->mod - prog->aux->saved_dst_attach_type - prog->aux->saved_dst_prog_type - prog->expected_attach_type  Neither of these fields are used by resolve_pseudo_ldimm64() or bpf_prog_offload_verifier_prep() (for netronome and netdevsim drivers), so the reordering is safe.

CVE-2024-58237:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: consider that tail calls invalidate packet pointers  Tail-called programs could execute any of the helpers that invalidate packet pointers. Hence, conservatively assume that each tail call invalidates packet pointers.  Making the change in bpf_helper_changes_pkt_data() automatically makes use of check_cfg() logic that computes 'changes_pkt_data' effect for global sub-programs, such that the following program could be rejected:      int tail_call(struct __sk_buff *sk)     {     	bpf_tail_call_static(sk, &jmp_table, 0);     	return 0;     }      SEC("tc")     int not_safe(struct __sk_buff *sk)     {     	int *p = (void *)(long)sk->data;     	... make p valid ...     	tail_call(sk);     	*p = 42; /* this is unsafe */     	...     }  The tc_bpf2bpf.c:subprog_tc() needs change: mark it as a function that can invalidate packet pointers. Otherwise, it can't be freplaced with tailcall_freplace.c:entry_freplace() that does a tail call.

CVE-2024-58241:

        In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: hci_core: Disable works on hci_unregister_dev  This make use of disable_work_* on hci_unregister_dev since the hci_dev is about to be freed new submissions are not disarable.

CVE-2025-21634:

        In the Linux kernel, the following vulnerability has been resolved:  cgroup/cpuset: remove kernfs active break  A warning was found:  WARNING: CPU: 10 PID: 3486953 at fs/kernfs/file.c:828 CPU: 10 PID: 3486953 Comm: rmdir Kdump: loaded Tainted: G RIP: 0010:kernfs_should_drain_open_files+0x1a1/0x1b0 RSP: 0018:ffff8881107ef9e0 EFLAGS: 00010202 RAX: 0000000080000002 RBX: ffff888154738c00 RCX: dffffc0000000000 RDX: 0000000000000007 RSI: 0000000000000004 RDI: ffff888154738c04 RBP: ffff888154738c04 R08: ffffffffaf27fa15 R09: ffffed102a8e7180 R10: ffff888154738c07 R11: 0000000000000000 R12: ffff888154738c08 R13: ffff888750f8c000 R14: ffff888750f8c0e8 R15: ffff888154738ca0 FS:  00007f84cd0be740(0000) GS:ffff8887ddc00000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000555f9fbe00c8 CR3: 0000000153eec001 CR4: 0000000000370ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace:  kernfs_drain+0x15e/0x2f0  __kernfs_remove+0x165/0x300  kernfs_remove_by_name_ns+0x7b/0xc0  cgroup_rm_file+0x154/0x1c0  cgroup_addrm_files+0x1c2/0x1f0  css_clear_dir+0x77/0x110  kill_css+0x4c/0x1b0  cgroup_destroy_locked+0x194/0x380  cgroup_rmdir+0x2a/0x140  It can be explained by: rmdir 				echo 1 > cpuset.cpus 				kernfs_fop_write_iter // active=0 cgroup_rm_file kernfs_remove_by_name_ns	kernfs_get_active // active=1 __kernfs_remove					  // active=0x80000002 kernfs_drain			cpuset_write_resmask wait_event //waiting (active == 0x80000001) 				kernfs_break_active_protection 				// active = 0x80000001 // continue 				kernfs_unbreak_active_protection 				// active = 0x80000002 ... kernfs_should_drain_open_files // warning occurs 				kernfs_put_active  This warning is caused by 'kernfs_break_active_protection' when it is writing to cpuset.cpus, and the cgroup is removed concurrently.  The commit 3a5a6d0c2b03 ("cpuset: don't nest cgroup_mutex inside get_online_cpus()") made cpuset_hotplug_workfn asynchronous, This change involves calling flush_work(), which can create a multiple processes circular locking dependency that involve cgroup_mutex, potentially leading to a deadlock. To avoid deadlock. the commit 76bb5ab8f6e3 ("cpuset: break kernfs active protection in cpuset_write_resmask()") added 'kernfs_break_active_protection' in the cpuset_write_resmask. This could lead to this warning.  After the commit 2125c0034c5d ("cgroup/cpuset: Make cpuset hotplug processing synchronous"), the cpuset_write_resmask no longer needs to wait the hotplug to finish, which means that concurrent hotplug and cpuset operations are no longer possible. Therefore, the deadlock doesn't exist anymore and it does not have to 'break active protection' now. To fix this warning, just remove kernfs_break_active_protection operation in the 'cpuset_write_resmask'.

CVE-2025-21635:

        In the Linux kernel, the following vulnerability has been resolved:  rds: sysctl: rds_tcp_{rcv,snd}buf: avoid using current->nsproxy  As mentioned in a previous commit of this series, using the 'net' structure via 'current' is not recommended for different reasons:  - Inconsistency: getting info from the reader's/writer's netns vs only   from the opener's netns.  - current->nsproxy can be NULL in some cases, resulting in an 'Oops'   (null-ptr-deref), e.g. when the current task is exiting, as spotted by   syzbot [1] using acct(2).  The per-netns structure can be obtained from the table->data using container_of(), then the 'net' one can be retrieved from the listen socket (if available).

CVE-2025-21656:

        In the Linux kernel, the following vulnerability has been resolved:  hwmon: (drivetemp) Fix driver producing garbage data when SCSI errors occur  scsi_execute_cmd() function can return both negative (linux codes) and positive (scsi_cmnd result field) error codes.  Currently the driver just passes error codes of scsi_execute_cmd() to hwmon core, which is incorrect because hwmon only checks for negative error codes. This leads to hwmon reporting uninitialized data to userspace in case of SCSI errors (for example if the disk drive was disconnected).  This patch checks scsi_execute_cmd() output and returns -EIO if it's error code is positive.  [groeck: Avoid inline variable declaration for portability]

CVE-2025-21658:

        In the Linux kernel, the following vulnerability has been resolved:  btrfs: avoid NULL pointer dereference if no valid extent tree  [BUG] Syzbot reported a crash with the following call trace:    BTRFS info (device loop0): scrub: started on devid 1   BUG: kernel NULL pointer dereference, address: 0000000000000208   #PF: supervisor read access in kernel mode   #PF: error_code(0x0000) - not-present page   PGD 106e70067 P4D 106e70067 PUD 107143067 PMD 0   Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI   CPU: 1 UID: 0 PID: 689 Comm: repro Kdump: loaded Tainted: G           O       6.13.0-rc4-custom+ #206   Tainted: [O]=OOT_MODULE   Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022   RIP: 0010:find_first_extent_item+0x26/0x1f0 [btrfs]   Call Trace:    <TASK>    scrub_find_fill_first_stripe+0x13d/0x3b0 [btrfs]    scrub_simple_mirror+0x175/0x260 [btrfs]    scrub_stripe+0x5d4/0x6c0 [btrfs]    scrub_chunk+0xbb/0x170 [btrfs]    scrub_enumerate_chunks+0x2f4/0x5f0 [btrfs]    btrfs_scrub_dev+0x240/0x600 [btrfs]    btrfs_ioctl+0x1dc8/0x2fa0 [btrfs]    ? do_sys_openat2+0xa5/0xf0    __x64_sys_ioctl+0x97/0xc0    do_syscall_64+0x4f/0x120    entry_SYSCALL_64_after_hwframe+0x76/0x7e    </TASK>  [CAUSE] The reproducer is using a corrupted image where extent tree root is corrupted, thus forcing to use "rescue=all,ro" mount option to mount the image.  Then it triggered a scrub, but since scrub relies on extent tree to find where the data/metadata extents are, scrub_find_fill_first_stripe() relies on an non-empty extent root.  But unfortunately scrub_find_fill_first_stripe() doesn't really expect an NULL pointer for extent root, it use extent_root to grab fs_info and triggered a NULL pointer dereference.  [FIX] Add an extra check for a valid extent root at the beginning of scrub_find_fill_first_stripe().  The new error path is introduced by 42437a6386ff ("btrfs: introduce mount option rescue=ignorebadroots"), but that's pretty old, and later commit b979547513ff ("btrfs: scrub: introduce helper to find and fill sector info for a scrub_stripe") changed how we do scrub.  So for kernels older than 6.6, the fix will need manual backport.

CVE-2025-21673:

        In the Linux kernel, the following vulnerability has been resolved:  smb: client: fix double free of TCP_Server_Info::hostname  When shutting down the server in cifs_put_tcp_session(), cifsd thread might be reconnecting to multiple DFS targets before it realizes it should exit the loop, so @server->hostname can't be freed as long as cifsd thread isn't done.  Otherwise the following can happen:    RIP: 0010:__slab_free+0x223/0x3c0   Code: 5e 41 5f c3 cc cc cc cc 4c 89 de 4c 89 cf 44 89 44 24 08 4c 89   1c 24 e8 fb cf 8e 00 44 8b 44 24 08 4c 8b 1c 24 e9 5f fe ff ff <0f>   0b 41 f7 45 08 00 0d 21 00 0f 85 2d ff ff ff e9 1f ff ff ff 80   RSP: 0018:ffffb26180dbfd08 EFLAGS: 00010246   RAX: ffff8ea34728e510 RBX: ffff8ea34728e500 RCX: 0000000000800068   RDX: 0000000000800068 RSI: 0000000000000000 RDI: ffff8ea340042400   RBP: ffffe112041ca380 R08: 0000000000000001 R09: 0000000000000000   R10: 6170732e31303000 R11: 70726f632e786563 R12: ffff8ea34728e500   R13: ffff8ea340042400 R14: ffff8ea34728e500 R15: 0000000000800068   FS: 0000000000000000(0000) GS:ffff8ea66fd80000(0000)   000000   CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033   CR2: 00007ffc25376080 CR3: 000000012a2ba001 CR4:   PKRU: 55555554   Call Trace:    <TASK>    ? show_trace_log_lvl+0x1c4/0x2df    ? show_trace_log_lvl+0x1c4/0x2df    ? __reconnect_target_unlocked+0x3e/0x160 [cifs]    ? __die_body.cold+0x8/0xd    ? die+0x2b/0x50    ? do_trap+0xce/0x120    ? __slab_free+0x223/0x3c0    ? do_error_trap+0x65/0x80    ? __slab_free+0x223/0x3c0    ? exc_invalid_op+0x4e/0x70    ? __slab_free+0x223/0x3c0    ? asm_exc_invalid_op+0x16/0x20    ? __slab_free+0x223/0x3c0    ? extract_hostname+0x5c/0xa0 [cifs]    ? extract_hostname+0x5c/0xa0 [cifs]    ? __kmalloc+0x4b/0x140    __reconnect_target_unlocked+0x3e/0x160 [cifs]    reconnect_dfs_server+0x145/0x430 [cifs]    cifs_handle_standard+0x1ad/0x1d0 [cifs]    cifs_demultiplex_thread+0x592/0x730 [cifs]    ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs]    kthread+0xdd/0x100    ? __pfx_kthread+0x10/0x10    ret_from_fork+0x29/0x50    </TASK>

CVE-2025-21693:

        In the Linux kernel, the following vulnerability has been resolved:  mm: zswap: properly synchronize freeing resources during CPU hotunplug  In zswap_compress() and zswap_decompress(), the per-CPU acomp_ctx of the current CPU at the beginning of the operation is retrieved and used throughout.  However, since neither preemption nor migration are disabled, it is possible that the operation continues on a different CPU.  If the original CPU is hotunplugged while the acomp_ctx is still in use, we run into a UAF bug as some of the resources attached to the acomp_ctx are freed during hotunplug in zswap_cpu_comp_dead() (i.e.  acomp_ctx.buffer, acomp_ctx.req, or acomp_ctx.acomp).  The problem was introduced in commit 1ec3b5fe6eec ("mm/zswap: move to use crypto_acomp API for hardware acceleration") when the switch to the crypto_acomp API was made.  Prior to that, the per-CPU crypto_comp was retrieved using get_cpu_ptr() which disables preemption and makes sure the CPU cannot go away from under us.  Preemption cannot be disabled with the crypto_acomp API as a sleepable context is needed.  Use the acomp_ctx.mutex to synchronize CPU hotplug callbacks allocating and freeing resources with compression/decompression paths.  Make sure that acomp_ctx.req is NULL when the resources are freed.  In the compression/decompression paths, check if acomp_ctx.req is NULL after acquiring the mutex (meaning the CPU was offlined) and retry on the new CPU.  The initialization of acomp_ctx.mutex is moved from the CPU hotplug callback to the pool initialization where it belongs (where the mutex is allocated).  In addition to adding clarity, this makes sure that CPU hotplug cannot reinitialize a mutex that is already locked by compression/decompression.  Previously a fix was attempted by holding cpus_read_lock() [1].  This would have caused a potential deadlock as it is possible for code already holding the lock to fall into reclaim and enter zswap (causing a deadlock).  A fix was also attempted using SRCU for synchronization, but Johannes pointed out that synchronize_srcu() cannot be used in CPU hotplug notifiers [2].  Alternative fixes that were considered/attempted and could have worked: - Refcounting the per-CPU acomp_ctx. This involves complexity in   handling the race between the refcount dropping to zero in   zswap_[de]compress() and the refcount being re-initialized when the   CPU is onlined. - Disabling migration before getting the per-CPU acomp_ctx [3], but   that's discouraged and is a much bigger hammer than needed, and could   result in subtle performance issues.  [1]https://lkml.kernel.org/20241219212437.2714151-1-yosryahmed@google.com/ [2]https://lkml.kernel.org/20250107074724.1756696-2-yosryahmed@google.com/ [3]https://lkml.kernel.org/20250107222236.2715883-2-yosryahmed@google.com/  [yosryahmed@google.com: remove comment]

CVE-2025-21696:

        In the Linux kernel, the following vulnerability has been resolved:  mm: clear uffd-wp PTE/PMD state on mremap()  When mremap()ing a memory region previously registered with userfaultfd as write-protected but without UFFD_FEATURE_EVENT_REMAP, an inconsistency in flag clearing leads to a mismatch between the vma flags (which have uffd-wp cleared) and the pte/pmd flags (which do not have uffd-wp cleared).  This mismatch causes a subsequent mprotect(PROT_WRITE) to trigger a warning in page_table_check_pte_flags() due to setting the pte to writable while uffd-wp is still set.  Fix this by always explicitly clearing the uffd-wp pte/pmd flags on any such mremap() so that the values are consistent with the existing clearing of VM_UFFD_WP.  Be careful to clear the logical flag regardless of its physical form; a PTE bit, a swap PTE bit, or a PTE marker.  Cover PTE, huge PMD and hugetlb paths.

CVE-2025-21714:

        In the Linux kernel, the following vulnerability has been resolved:  RDMA/mlx5: Fix implicit ODP use after free  Prevent double queueing of implicit ODP mr destroy work by using __xa_cmpxchg() to make sure this is the only time we are destroying this specific mr.  Without this change, we could try to invalidate this mr twice, which in turn could result in queuing a MR work destroy twice, and eventually the second work could execute after the MR was freed due to the first work, causing a user after free and trace below.     refcount_t: underflow; use-after-free.    WARNING: CPU: 2 PID: 12178 at lib/refcount.c:28 refcount_warn_saturate+0x12b/0x130    Modules linked in: bonding ib_ipoib vfio_pci ip_gre geneve nf_tables ip6_gre gre ip6_tunnel tunnel6 ipip tunnel4 ib_umad rdma_ucm mlx5_vfio_pci vfio_pci_core vfio_iommu_type1 mlx5_ib vfio ib_uverbs mlx5_core iptable_raw openvswitch nsh rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm ib_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay zram zsmalloc fuse [last unloaded: ib_uverbs]    CPU: 2 PID: 12178 Comm: kworker/u20:5 Not tainted 6.5.0-rc1_net_next_mlx5_58c644e #1    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014    Workqueue: events_unbound free_implicit_child_mr_work [mlx5_ib]    RIP: 0010:refcount_warn_saturate+0x12b/0x130    Code: 48 c7 c7 38 95 2a 82 c6 05 bc c6 fe 00 01 e8 0c 66 aa ff 0f 0b 5b c3 48 c7 c7 e0 94 2a 82 c6 05 a7 c6 fe 00 01 e8 f5 65 aa ff <0f> 0b 5b c3 90 8b 07 3d 00 00 00 c0 74 12 83 f8 01 74 13 8d 50 ff    RSP: 0018:ffff8881008e3e40 EFLAGS: 00010286    RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000027    RDX: ffff88852c91b5c8 RSI: 0000000000000001 RDI: ffff88852c91b5c0    RBP: ffff8881dacd4e00 R08: 00000000ffffffff R09: 0000000000000019    R10: 000000000000072e R11: 0000000063666572 R12: ffff88812bfd9e00    R13: ffff8881c792d200 R14: ffff88810011c005 R15: ffff8881002099c0    FS:  0000000000000000(0000) GS:ffff88852c900000(0000) knlGS:0000000000000000    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033    CR2: 00007f5694b5e000 CR3: 00000001153f6003 CR4: 0000000000370ea0    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400    Call Trace:     <TASK>     ? refcount_warn_saturate+0x12b/0x130     free_implicit_child_mr_work+0x180/0x1b0 [mlx5_ib]     process_one_work+0x1cc/0x3c0     worker_thread+0x218/0x3c0     kthread+0xc6/0xf0     ret_from_fork+0x1f/0x30     </TASK>

CVE-2025-21723:

        In the Linux kernel, the following vulnerability has been resolved:  scsi: mpi3mr: Fix possible crash when setting up bsg fails  If bsg_setup_queue() fails, the bsg_queue is assigned a non-NULL value. Consequently, in mpi3mr_bsg_exit(), the condition "if(!mrioc->bsg_queue)" will not be satisfied, preventing execution from entering bsg_remove_queue(), which could lead to the following crash:  BUG: kernel NULL pointer dereference, address: 000000000000041c Call Trace:   <TASK>   mpi3mr_bsg_exit+0x1f/0x50 [mpi3mr]   mpi3mr_remove+0x6f/0x340 [mpi3mr]   pci_device_remove+0x3f/0xb0   device_release_driver_internal+0x19d/0x220   unbind_store+0xa4/0xb0   kernfs_fop_write_iter+0x11f/0x200   vfs_write+0x1fc/0x3e0   ksys_write+0x67/0xe0   do_syscall_64+0x38/0x80   entry_SYSCALL_64_after_hwframe+0x78/0xe2

CVE-2025-21729:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: rtw89: fix race between cancel_hw_scan and hw_scan completion  The rtwdev->scanning flag isn't protected by mutex originally, so cancel_hw_scan can pass the condition, but suddenly hw_scan completion unset the flag and calls ieee80211_scan_completed() that will free local->hw_scan_req. Then, cancel_hw_scan raises null-ptr-deref and use-after-free. Fix it by moving the check condition to where protected by mutex.   KASAN: null-ptr-deref in range [0x0000000000000088-0x000000000000008f]  CPU: 2 PID: 6922 Comm: kworker/2:2 Tainted: G           OE  Hardware name: LENOVO 2356AD1/2356AD1, BIOS G7ETB6WW (2.76 ) 09/10/2019  Workqueue: events cfg80211_conn_work [cfg80211]  RIP: 0010:rtw89_fw_h2c_scan_offload_be+0xc33/0x13c3 [rtw89_core]  Code: 00 45 89 6c 24 1c 0f 85 23 01 00 00 48 8b 85 20 ff ff ff 48 8d  RSP: 0018:ffff88811fd9f068 EFLAGS: 00010206  RAX: dffffc0000000000 RBX: ffff88811fd9f258 RCX: 0000000000000001  RDX: 0000000000000011 RSI: 0000000000000001 RDI: 0000000000000089  RBP: ffff88811fd9f170 R08: 0000000000000000 R09: 0000000000000000  R10: ffff88811fd9f108 R11: 0000000000000000 R12: ffff88810e47f960  R13: 0000000000000000 R14: 000000000000ffff R15: 0000000000000000  FS:  0000000000000000(0000) GS:ffff8881d6f00000(0000) knlGS:0000000000000000  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  CR2: 00007531dfca55b0 CR3: 00000001be296004 CR4: 00000000001706e0  Call Trace:   <TASK>   ? show_regs+0x61/0x73   ? __die_body+0x20/0x73   ? die_addr+0x4f/0x7b   ? exc_general_protection+0x191/0x1db   ? asm_exc_general_protection+0x27/0x30   ? rtw89_fw_h2c_scan_offload_be+0xc33/0x13c3 [rtw89_core]   ? rtw89_fw_h2c_scan_offload_be+0x458/0x13c3 [rtw89_core]   ? __pfx_rtw89_fw_h2c_scan_offload_be+0x10/0x10 [rtw89_core]   ? do_raw_spin_lock+0x75/0xdb   ? __pfx_do_raw_spin_lock+0x10/0x10   rtw89_hw_scan_offload+0xb5e/0xbf7 [rtw89_core]   ? _raw_spin_unlock+0xe/0x24   ? __mutex_lock.constprop.0+0x40c/0x471   ? __pfx_rtw89_hw_scan_offload+0x10/0x10 [rtw89_core]   ? __mutex_lock_slowpath+0x13/0x1f   ? mutex_lock+0xa2/0xdc   ? __pfx_mutex_lock+0x10/0x10   rtw89_hw_scan_abort+0x58/0xb7 [rtw89_core]   rtw89_ops_cancel_hw_scan+0x120/0x13b [rtw89_core]   ieee80211_scan_cancel+0x468/0x4d0 [mac80211]   ieee80211_prep_connection+0x858/0x899 [mac80211]   ieee80211_mgd_auth+0xbea/0xdde [mac80211]   ? __pfx_ieee80211_mgd_auth+0x10/0x10 [mac80211]   ? cfg80211_find_elem+0x15/0x29 [cfg80211]   ? is_bss+0x1b7/0x1d7 [cfg80211]   ieee80211_auth+0x18/0x27 [mac80211]   cfg80211_mlme_auth+0x3bb/0x3e7 [cfg80211]   cfg80211_conn_do_work+0x410/0xb81 [cfg80211]   ? __pfx_cfg80211_conn_do_work+0x10/0x10 [cfg80211]   ? __kasan_check_read+0x11/0x1f   ? psi_group_change+0x8bc/0x944   ? __kasan_check_write+0x14/0x22   ? mutex_lock+0x8e/0xdc   ? __pfx_mutex_lock+0x10/0x10   ? __pfx___radix_tree_lookup+0x10/0x10   cfg80211_conn_work+0x245/0x34d [cfg80211]   ? __pfx_cfg80211_conn_work+0x10/0x10 [cfg80211]   ? update_cfs_rq_load_avg+0x3bc/0x3d7   ? sched_clock_noinstr+0x9/0x1a   ? sched_clock+0x10/0x24   ? sched_clock_cpu+0x7e/0x42e   ? newidle_balance+0x796/0x937   ? __pfx_sched_clock_cpu+0x10/0x10   ? __pfx_newidle_balance+0x10/0x10   ? __kasan_check_read+0x11/0x1f   ? psi_group_change+0x8bc/0x944   ? _raw_spin_unlock+0xe/0x24   ? raw_spin_rq_unlock+0x47/0x54   ? raw_spin_rq_unlock_irq+0x9/0x1f   ? finish_task_switch.isra.0+0x347/0x586   ? __schedule+0x27bf/0x2892   ? mutex_unlock+0x80/0xd0   ? do_raw_spin_lock+0x75/0xdb   ? __pfx___schedule+0x10/0x10   process_scheduled_works+0x58c/0x821   worker_thread+0x4c7/0x586   ? __kasan_check_read+0x11/0x1f   kthread+0x285/0x294   ? __pfx_worker_thread+0x10/0x10   ? __pfx_kthread+0x10/0x10   ret_from_fork+0x29/0x6f   ? __pfx_kthread+0x10/0x10   ret_from_fork_asm+0x1b/0x30   </TASK>

CVE-2025-21732:

        In the Linux kernel, the following vulnerability has been resolved:  RDMA/mlx5: Fix a race for an ODP MR which leads to CQE with error  This patch addresses a race condition for an ODP MR that can result in a CQE with an error on the UMR QP.  During the __mlx5_ib_dereg_mr() flow, the following sequence of calls occurs:  mlx5_revoke_mr()  mlx5r_umr_revoke_mr()  mlx5r_umr_post_send_wait()  At this point, the lkey is freed from the hardware's perspective.  However, concurrently, mlx5_ib_invalidate_range() might be triggered by another task attempting to invalidate a range for the same freed lkey.  This task will:  - Acquire the umem_odp->umem_mutex lock.  - Call mlx5r_umr_update_xlt() on the UMR QP.  - Since the lkey has already been freed, this can lead to a CQE error,    causing the UMR QP to enter an error state [1].  To resolve this race condition, the umem_odp->umem_mutex lock is now also acquired as part of the mlx5_revoke_mr() scope.  Upon successful revoke, we set umem_odp->private which points to that MR to NULL, preventing any further invalidation attempts on its lkey.  [1] From dmesg:     infiniband rocep8s0f0: dump_cqe:277:(pid 0): WC error: 6, Message: memory bind operation error    cqe_dump: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    cqe_dump: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    cqe_dump: 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    cqe_dump: 00000030: 00 00 00 00 08 00 78 06 25 00 11 b9 00 0e dd d2     WARNING: CPU: 15 PID: 1506 at drivers/infiniband/hw/mlx5/umr.c:394 mlx5r_umr_post_send_wait+0x15a/0x2b0 [mlx5_ib]    Modules linked in: ip6table_mangle ip6table_natip6table_filter ip6_tables iptable_mangle xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_umad ib_ipoib ib_cm mlx5_ib ib_uverbs ib_core fuse mlx5_core    CPU: 15 UID: 0 PID: 1506 Comm: ibv_rc_pingpong Not tainted 6.12.0-rc7+ #1626    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014    RIP: 0010:mlx5r_umr_post_send_wait+0x15a/0x2b0 [mlx5_ib]    [..]    Call Trace:    <TASK>    mlx5r_umr_update_xlt+0x23c/0x3e0 [mlx5_ib]    mlx5_ib_invalidate_range+0x2e1/0x330 [mlx5_ib]    __mmu_notifier_invalidate_range_start+0x1e1/0x240    zap_page_range_single+0xf1/0x1a0    madvise_vma_behavior+0x677/0x6e0    do_madvise+0x1a2/0x4b0    __x64_sys_madvise+0x25/0x30    do_syscall_64+0x6b/0x140    entry_SYSCALL_64_after_hwframe+0x76/0x7e

CVE-2025-21768:

        In the Linux kernel, the following vulnerability has been resolved:  net: ipv6: fix dst ref loops in rpl, seg6 and ioam6 lwtunnels  Some lwtunnels have a dst cache for post-transformation dst. If the packet destination did not change we may end up recording a reference to the lwtunnel in its own cache, and the lwtunnel state will never be freed.  Discovered by the ioam6.sh test, kmemleak was recently fixed to catch per-cpu memory leaks. I'm not sure if rpl and seg6 can actually hit this, but in principle I don't see why not.

CVE-2025-21801:

        In the Linux kernel, the following vulnerability has been resolved:  net: ravb: Fix missing rtnl lock in suspend/resume path  Fix the suspend/resume path by ensuring the rtnl lock is held where required. Calls to ravb_open, ravb_close and wol operations must be performed under the rtnl lock to prevent conflicts with ongoing ndo operations.  Without this fix, the following warning is triggered: [   39.032969] ============================= [   39.032983] WARNING: suspicious RCU usage [   39.033019] ----------------------------- [   39.033033] drivers/net/phy/phy_device.c:2004 suspicious rcu_dereference_protected() usage! ... [   39.033597] stack backtrace: [   39.033613] CPU: 0 UID: 0 PID: 174 Comm: python3 Not tainted 6.13.0-rc7-next-20250116-arm64-renesas-00002-g35245dfdc62c #7 [   39.033623] Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) [   39.033628] Call trace: [   39.033633]  show_stack+0x14/0x1c (C) [   39.033652]  dump_stack_lvl+0xb4/0xc4 [   39.033664]  dump_stack+0x14/0x1c [   39.033671]  lockdep_rcu_suspicious+0x16c/0x22c [   39.033682]  phy_detach+0x160/0x190 [   39.033694]  phy_disconnect+0x40/0x54 [   39.033703]  ravb_close+0x6c/0x1cc [   39.033714]  ravb_suspend+0x48/0x120 [   39.033721]  dpm_run_callback+0x4c/0x14c [   39.033731]  device_suspend+0x11c/0x4dc [   39.033740]  dpm_suspend+0xdc/0x214 [   39.033748]  dpm_suspend_start+0x48/0x60 [   39.033758]  suspend_devices_and_enter+0x124/0x574 [   39.033769]  pm_suspend+0x1ac/0x274 [   39.033778]  state_store+0x88/0x124 [   39.033788]  kobj_attr_store+0x14/0x24 [   39.033798]  sysfs_kf_write+0x48/0x6c [   39.033808]  kernfs_fop_write_iter+0x118/0x1a8 [   39.033817]  vfs_write+0x27c/0x378 [   39.033825]  ksys_write+0x64/0xf4 [   39.033833]  __arm64_sys_write+0x18/0x20 [   39.033841]  invoke_syscall+0x44/0x104 [   39.033852]  el0_svc_common.constprop.0+0xb4/0xd4 [   39.033862]  do_el0_svc+0x18/0x20 [   39.033870]  el0_svc+0x3c/0xf0 [   39.033880]  el0t_64_sync_handler+0xc0/0xc4 [   39.033888]  el0t_64_sync+0x154/0x158 [   39.041274] ravb 11c30000.ethernet eth0: Link is Down

CVE-2025-21825:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: Cancel the running bpf_timer through kworker for PREEMPT_RT  During the update procedure, when overwrite element in a pre-allocated htab, the freeing of old_element is protected by the bucket lock. The reason why the bucket lock is necessary is that the old_element has already been stashed in htab->extra_elems after alloc_htab_elem() returns. If freeing the old_element after the bucket lock is unlocked, the stashed element may be reused by concurrent update procedure and the freeing of old_element will run concurrently with the reuse of the old_element. However, the invocation of check_and_free_fields() may acquire a spin-lock which violates the lockdep rule because its caller has already held a raw-spin-lock (bucket lock). The following warning will be reported when such race happens:    BUG: scheduling while atomic: test_progs/676/0x00000003   3 locks held by test_progs/676:   #0: ffffffff864b0240 (rcu_read_lock_trace){....}-{0:0}, at: bpf_prog_test_run_syscall+0x2c0/0x830   #1: ffff88810e961188 (&htab->lockdep_key){....}-{2:2}, at: htab_map_update_elem+0x306/0x1500   #2: ffff8881f4eac1b8 (&base->softirq_expiry_lock){....}-{2:2}, at: hrtimer_cancel_wait_running+0xe9/0x1b0   Modules linked in: bpf_testmod(O)   Preemption disabled at:   [<ffffffff817837a3>] htab_map_update_elem+0x293/0x1500   CPU: 0 UID: 0 PID: 676 Comm: test_progs Tainted: G ... 6.12.0+ #11   Tainted: [W]=WARN, [O]=OOT_MODULE   Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)...   Call Trace:   <TASK>   dump_stack_lvl+0x57/0x70   dump_stack+0x10/0x20   __schedule_bug+0x120/0x170   __schedule+0x300c/0x4800   schedule_rtlock+0x37/0x60   rtlock_slowlock_locked+0x6d9/0x54c0   rt_spin_lock+0x168/0x230   hrtimer_cancel_wait_running+0xe9/0x1b0   hrtimer_cancel+0x24/0x30   bpf_timer_delete_work+0x1d/0x40   bpf_timer_cancel_and_free+0x5e/0x80   bpf_obj_free_fields+0x262/0x4a0   check_and_free_fields+0x1d0/0x280   htab_map_update_elem+0x7fc/0x1500   bpf_prog_9f90bc20768e0cb9_overwrite_cb+0x3f/0x43   bpf_prog_ea601c4649694dbd_overwrite_timer+0x5d/0x7e   bpf_prog_test_run_syscall+0x322/0x830   __sys_bpf+0x135d/0x3ca0   __x64_sys_bpf+0x75/0xb0   x64_sys_call+0x1b5/0xa10   do_syscall_64+0x3b/0xc0   entry_SYSCALL_64_after_hwframe+0x4b/0x53   ...   </TASK>  It seems feasible to break the reuse and refill of per-cpu extra_elems into two independent parts: reuse the per-cpu extra_elems with bucket lock being held and refill the old_element as per-cpu extra_elems after the bucket lock is unlocked. However, it will make the concurrent overwrite procedures on the same CPU return unexpected -E2BIG error when the map is full.  Therefore, the patch fixes the lock problem by breaking the cancelling of bpf_timer into two steps for PREEMPT_RT: 1) use hrtimer_try_to_cancel() and check its return value 2) if the timer is running, use hrtimer_cancel() through a kworker to    cancel it again Considering that the current implementation of hrtimer_cancel() will try to acquire a being held softirq_expiry_lock when the current timer is running, these steps above are reasonable. However, it also has downside. When the timer is running, the cancelling of the timer is delayed when releasing the last map uref. The delay is also fixable (e.g., break the cancelling of bpf timer into two parts: one part in locked scope, another one in unlocked scope), it can be revised later if necessary.  It is a bit hard to decide the right fix tag. One reason is that the problem depends on PREEMPT_RT which is enabled in v6.12. Considering the softirq_expiry_lock lock exists since v5.4 and bpf_timer is introduced in v5.15, the bpf_timer commit is used in the fixes tag and an extra depends-on tag is added to state the dependency on PREEMPT_RT.  Depends-on: v6.12+ with PREEMPT_RT enabled

CVE-2025-21831:

        In the Linux kernel, the following vulnerability has been resolved:  PCI: Avoid putting some root ports into D3 on TUXEDO Sirius Gen1  commit 9d26d3a8f1b0 ("PCI: Put PCIe ports into D3 during suspend") sets the policy that all PCIe ports are allowed to use D3.  When the system is suspended if the port is not power manageable by the platform and won't be used for wakeup via a PME this sets up the policy for these ports to go into D3hot.  This policy generally makes sense from an OSPM perspective but it leads to problems with wakeup from suspend on the TUXEDO Sirius 16 Gen 1 with a specific old BIOS. This manifests as a system hang.  On the affected Device + BIOS combination, add a quirk for the root port of the problematic controller to ensure that these root ports are not put into D3hot at suspend.  This patch is based on    https://lore.kernel.org/linux-pci/20230708214457.1229-2-mario.limonciello@amd.com  but with the added condition both in the documentation and in the code to apply only to the TUXEDO Sirius 16 Gen 1 with a specific old BIOS and only the affected root ports.

CVE-2025-21836:

        In the Linux kernel, the following vulnerability has been resolved:  io_uring/kbuf: reallocate buf lists on upgrade  IORING_REGISTER_PBUF_RING can reuse an old struct io_buffer_list if it was created for legacy selected buffer and has been emptied. It violates the requirement that most of the field should stay stable after publish. Always reallocate it instead.

CVE-2025-21870:

        In the Linux kernel, the following vulnerability has been resolved:  ASoC: SOF: ipc4-topology: Harden loops for looking up ALH copiers  Other, non DAI copier widgets could have the same  stream name (sname) as the ALH copier and in that case the copier->data is NULL, no alh_data is attached, which could lead to NULL pointer dereference. We could check for this NULL pointer in sof_ipc4_prepare_copier_module() and avoid the crash, but a similar loop in sof_ipc4_widget_setup_comp_dai() will miscalculate the ALH device count, causing broken audio.  The correct fix is to harden the matching logic by making sure that the 1. widget is a DAI widget - so dai = w->private is valid 2. the dai (and thus the copier) is ALH copier

CVE-2025-21872:

        In the Linux kernel, the following vulnerability has been resolved:  efi: Don't map the entire mokvar table to determine its size  Currently, when validating the mokvar table, we (re)map the entire table on each iteration of the loop, adding space as we discover new entries. If the table grows over a certain size, this fails due to limitations of early_memmap(), and we get a failure and traceback:    ------------[ cut here ]------------   WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:139 __early_ioremap+0xef/0x220   ...   Call Trace:    <TASK>    ? __early_ioremap+0xef/0x220    ? __warn.cold+0x93/0xfa    ? __early_ioremap+0xef/0x220    ? report_bug+0xff/0x140    ? early_fixup_exception+0x5d/0xb0    ? early_idt_handler_common+0x2f/0x3a    ? __early_ioremap+0xef/0x220    ? efi_mokvar_table_init+0xce/0x1d0    ? setup_arch+0x864/0xc10    ? start_kernel+0x6b/0xa10    ? x86_64_start_reservations+0x24/0x30    ? x86_64_start_kernel+0xed/0xf0    ? common_startup_64+0x13e/0x141    </TASK>   ---[ end trace 0000000000000000 ]---   mokvar: Failed to map EFI MOKvar config table pa=0x7c4c3000, size=265187.  Mapping the entire structure isn't actually necessary, as we don't ever need more than one entry header mapped at once.  Changes efi_mokvar_table_init() to only map each entry header, not the entire table, when determining the table size.  Since we're not mapping any data past the variable name, it also changes the code to enforce that each variable name is NUL terminated, rather than attempting to verify it in place.

CVE-2025-21885:

        In the Linux kernel, the following vulnerability has been resolved:  RDMA/bnxt_re: Fix the page details for the srq created by kernel consumers  While using nvme target with use_srq on, below kernel panic is noticed.  [  549.698111] bnxt_en 0000:41:00.0 enp65s0np0: FEC autoneg off encoding: Clause 91 RS(544,514) [  566.393619] Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI .. [  566.393799]  <TASK> [  566.393807]  ? __die_body+0x1a/0x60 [  566.393823]  ? die+0x38/0x60 [  566.393835]  ? do_trap+0xe4/0x110 [  566.393847]  ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re] [  566.393867]  ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re] [  566.393881]  ? do_error_trap+0x7c/0x120 [  566.393890]  ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re] [  566.393911]  ? exc_divide_error+0x34/0x50 [  566.393923]  ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re] [  566.393939]  ? asm_exc_divide_error+0x16/0x20 [  566.393966]  ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re] [  566.393997]  bnxt_qplib_create_srq+0xc9/0x340 [bnxt_re] [  566.394040]  bnxt_re_create_srq+0x335/0x3b0 [bnxt_re] [  566.394057]  ? srso_return_thunk+0x5/0x5f [  566.394068]  ? __init_swait_queue_head+0x4a/0x60 [  566.394090]  ib_create_srq_user+0xa7/0x150 [ib_core] [  566.394147]  nvmet_rdma_queue_connect+0x7d0/0xbe0 [nvmet_rdma] [  566.394174]  ? lock_release+0x22c/0x3f0 [  566.394187]  ? srso_return_thunk+0x5/0x5f  Page size and shift info is set only for the user space SRQs. Set page size and page shift for kernel space SRQs also.

CVE-2025-21888:

        In the Linux kernel, the following vulnerability has been resolved:  RDMA/mlx5: Fix a WARN during dereg_mr for DM type  Memory regions (MR) of type DM (device memory) do not have an associated umem.  In the __mlx5_ib_dereg_mr() -> mlx5_free_priv_descs() flow, the code incorrectly takes the wrong branch, attempting to call dma_unmap_single() on a DMA address that is not mapped.  This results in a WARN [1], as shown below.  The issue is resolved by properly accounting for the DM type and ensuring the correct branch is selected in mlx5_free_priv_descs().  [1] WARNING: CPU: 12 PID: 1346 at drivers/iommu/dma-iommu.c:1230 iommu_dma_unmap_page+0x79/0x90 Modules linked in: ip6table_mangle ip6table_nat ip6table_filter ip6_tables iptable_mangle xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry ovelay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core fuse mlx5_core CPU: 12 UID: 0 PID: 1346 Comm: ibv_rc_pingpong Not tainted 6.12.0-rc7+ #1631 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:iommu_dma_unmap_page+0x79/0x90 Code: 2b 49 3b 29 72 26 49 3b 69 08 73 20 4d 89 f0 44 89 e9 4c 89 e2 48 89 ee 48 89 df 5b 5d 41 5c 41 5d 41 5e 41 5f e9 07 b8 88 ff <0f> 0b 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 66 0f 1f 44 00 RSP: 0018:ffffc90001913a10 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88810194b0a8 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000001 RBP: ffff88810194b0a8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000 FS:  00007f537abdd740(0000) GS:ffff88885fb00000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f537aeb8000 CR3: 000000010c248001 CR4: 0000000000372eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? __warn+0x84/0x190 ? iommu_dma_unmap_page+0x79/0x90 ? report_bug+0xf8/0x1c0 ? handle_bug+0x55/0x90 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? iommu_dma_unmap_page+0x79/0x90 dma_unmap_page_attrs+0xe6/0x290 mlx5_free_priv_descs+0xb0/0xe0 [mlx5_ib] __mlx5_ib_dereg_mr+0x37e/0x520 [mlx5_ib] ? _raw_spin_unlock_irq+0x24/0x40 ? wait_for_completion+0xfe/0x130 ? rdma_restrack_put+0x63/0xe0 [ib_core] ib_dereg_mr_user+0x5f/0x120 [ib_core] ? lock_release+0xc6/0x280 destroy_hw_idr_uobject+0x1d/0x60 [ib_uverbs] uverbs_destroy_uobject+0x58/0x1d0 [ib_uverbs] uobj_destroy+0x3f/0x70 [ib_uverbs] ib_uverbs_cmd_verbs+0x3e4/0xbb0 [ib_uverbs] ? __pfx_uverbs_destroy_def_handler+0x10/0x10 [ib_uverbs] ? lock_acquire+0xc1/0x2f0 ? ib_uverbs_ioctl+0xcb/0x170 [ib_uverbs] ? ib_uverbs_ioctl+0x116/0x170 [ib_uverbs] ? lock_release+0xc6/0x280 ib_uverbs_ioctl+0xe7/0x170 [ib_uverbs] ? ib_uverbs_ioctl+0xcb/0x170 [ib_uverbs] __x64_sys_ioctl+0x1b0/0xa70 do_syscall_64+0x6b/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f537adaf17b Code: 0f 1e fa 48 8b 05 1d ad 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ed ac 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007ffff218f0b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffff218f1d8 RCX: 00007f537adaf17b RDX: 00007ffff218f1c0 RSI: 00000000c0181b01 RDI: 0000000000000003 RBP: 00007ffff218f1a0 R08: 00007f537aa8d010 R09: 0000561ee2e4f270 R10: 00007f537aace3a8 R11: 0000000000000246 R12: 00007ffff218f190 R13: 000000000000001c R14: 0000561ee2e4d7c0 R15: 00007ffff218f450 </TASK>

CVE-2025-21892:

        In the Linux kernel, the following vulnerability has been resolved:  RDMA/mlx5: Fix the recovery flow of the UMR QP  This patch addresses an issue in the recovery flow of the UMR QP, ensuring tasks do not get stuck, as highlighted by the call trace [1].  During recovery, before transitioning the QP to the RESET state, the software must wait for all outstanding WRs to complete.  Failing to do so can cause the firmware to skip sending some flushed CQEs with errors and simply discard them upon the RESET, as per the IB specification.  This race condition can result in lost CQEs and tasks becoming stuck.  To resolve this, the patch sends a final WR which serves only as a barrier before moving the QP state to RESET.  Once a CQE is received for that final WR, it guarantees that no outstanding WRs remain, making it safe to transition the QP to RESET and subsequently back to RTS, restoring proper functionality.  Note: For the barrier WR, we simply reuse the failed and ready WR. Since the QP is in an error state, it will only receive IB_WC_WR_FLUSH_ERR. However, as it serves only as a barrier we don't care about its status.  [1] INFO: task rdma_resource_l:1922 blocked for more than 120 seconds. Tainted: G        W          6.12.0-rc7+ #1626 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:rdma_resource_l state:D stack:0  pid:1922 tgid:1922  ppid:1369      flags:0x00004004 Call Trace: <TASK> __schedule+0x420/0xd30 schedule+0x47/0x130 schedule_timeout+0x280/0x300 ? mark_held_locks+0x48/0x80 ? lockdep_hardirqs_on_prepare+0xe5/0x1a0 wait_for_completion+0x75/0x130 mlx5r_umr_post_send_wait+0x3c2/0x5b0 [mlx5_ib] ? __pfx_mlx5r_umr_done+0x10/0x10 [mlx5_ib] mlx5r_umr_revoke_mr+0x93/0xc0 [mlx5_ib] __mlx5_ib_dereg_mr+0x299/0x520 [mlx5_ib] ? _raw_spin_unlock_irq+0x24/0x40 ? wait_for_completion+0xfe/0x130 ? rdma_restrack_put+0x63/0xe0 [ib_core] ib_dereg_mr_user+0x5f/0x120 [ib_core] ? lock_release+0xc6/0x280 destroy_hw_idr_uobject+0x1d/0x60 [ib_uverbs] uverbs_destroy_uobject+0x58/0x1d0 [ib_uverbs] uobj_destroy+0x3f/0x70 [ib_uverbs] ib_uverbs_cmd_verbs+0x3e4/0xbb0 [ib_uverbs] ? __pfx_uverbs_destroy_def_handler+0x10/0x10 [ib_uverbs] ? __lock_acquire+0x64e/0x2080 ? mark_held_locks+0x48/0x80 ? find_held_lock+0x2d/0xa0 ? lock_acquire+0xc1/0x2f0 ? ib_uverbs_ioctl+0xcb/0x170 [ib_uverbs] ? __fget_files+0xc3/0x1b0 ib_uverbs_ioctl+0xe7/0x170 [ib_uverbs] ? ib_uverbs_ioctl+0xcb/0x170 [ib_uverbs] __x64_sys_ioctl+0x1b0/0xa70 do_syscall_64+0x6b/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f99c918b17b RSP: 002b:00007ffc766d0468 EFLAGS: 00000246 ORIG_RAX:      0000000000000010 RAX: ffffffffffffffda RBX: 00007ffc766d0578 RCX:      00007f99c918b17b RDX: 00007ffc766d0560 RSI: 00000000c0181b01 RDI:      0000000000000003 RBP: 00007ffc766d0540 R08: 00007f99c8f99010 R09:      000000000000bd7e R10: 00007f99c94c1c70 R11: 0000000000000246 R12:      00007ffc766d0530 R13: 000000000000001c R14: 0000000040246a80 R15:      0000000000000000 </TASK>

CVE-2025-21894:

        In the Linux kernel, the following vulnerability has been resolved:  net: enetc: VFs do not support HWTSTAMP_TX_ONESTEP_SYNC  Actually ENETC VFs do not support HWTSTAMP_TX_ONESTEP_SYNC because only ENETC PF can access PMa_SINGLE_STEP registers. And there will be a crash if VFs are used to test one-step timestamp, the crash log as follows.  [  129.110909] Unable to handle kernel paging request at virtual address 00000000000080c0 [  129.287769] Call trace: [  129.290219]  enetc_port_mac_wr+0x30/0xec (P) [  129.294504]  enetc_start_xmit+0xda4/0xe74 [  129.298525]  enetc_xmit+0x70/0xec [  129.301848]  dev_hard_start_xmit+0x98/0x118

CVE-2025-21907:

        In the Linux kernel, the following vulnerability has been resolved:  mm: memory-failure: update ttu flag inside unmap_poisoned_folio  Patch series "mm: memory_failure: unmap poisoned folio during migrate properly", v3.  Fix two bugs during folio migration if the folio is poisoned.   This patch (of 3):  Commit 6da6b1d4a7df ("mm/hwpoison: convert TTU_IGNORE_HWPOISON to TTU_HWPOISON") introduce TTU_HWPOISON to replace TTU_IGNORE_HWPOISON in order to stop send SIGBUS signal when accessing an error page after a memory error on a clean folio.  However during page migration, anon folio must be set with TTU_HWPOISON during unmap_*().  For pagecache we need some policy just like the one in hwpoison_user_mappings to set this flag.  So move this policy from hwpoison_user_mappings to unmap_poisoned_folio to handle this warning properly.  Warning will be produced during unamp poison folio with the following log:    ------------[ cut here ]------------   WARNING: CPU: 1 PID: 365 at mm/rmap.c:1847 try_to_unmap_one+0x8fc/0xd3c   Modules linked in:   CPU: 1 UID: 0 PID: 365 Comm: bash Tainted: G        W          6.13.0-rc1-00018-gacdb4bbda7ab #42   Tainted: [W]=WARN   Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015   pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)   pc : try_to_unmap_one+0x8fc/0xd3c   lr : try_to_unmap_one+0x3dc/0xd3c   Call trace:    try_to_unmap_one+0x8fc/0xd3c (P)    try_to_unmap_one+0x3dc/0xd3c (L)    rmap_walk_anon+0xdc/0x1f8    rmap_walk+0x3c/0x58    try_to_unmap+0x88/0x90    unmap_poisoned_folio+0x30/0xa8    do_migrate_range+0x4a0/0x568    offline_pages+0x5a4/0x670    memory_block_action+0x17c/0x374    memory_subsys_offline+0x3c/0x78    device_offline+0xa4/0xd0    state_store+0x8c/0xf0    dev_attr_store+0x18/0x2c    sysfs_kf_write+0x44/0x54    kernfs_fop_write_iter+0x118/0x1a8    vfs_write+0x3a8/0x4bc    ksys_write+0x6c/0xf8    __arm64_sys_write+0x1c/0x28    invoke_syscall+0x44/0x100    el0_svc_common.constprop.0+0x40/0xe0    do_el0_svc+0x1c/0x28    el0_svc+0x30/0xd0    el0t_64_sync_handler+0xc8/0xcc    el0t_64_sync+0x198/0x19c   ---[ end trace 0000000000000000 ]---  [mawupeng1@huawei.com: unmap_poisoned_folio(): remove shadowed local `mapping', per Miaohe]

CVE-2025-21927:

        In the Linux kernel, the following vulnerability has been resolved:  nvme-tcp: fix potential memory corruption in nvme_tcp_recv_pdu()  nvme_tcp_recv_pdu() doesn't check the validity of the header length. When header digests are enabled, a target might send a packet with an invalid header length (e.g. 255), causing nvme_tcp_verify_hdgst() to access memory outside the allocated area and cause memory corruptions by overwriting it with the calculated digest.  Fix this by rejecting packets with an unexpected header length.

CVE-2025-21949:

        In the Linux kernel, the following vulnerability has been resolved:  LoongArch: Set hugetlb mmap base address aligned with pmd size  With ltp test case "testcases/bin/hugefork02", there is a dmesg error report message such as:   kernel BUG at mm/hugetlb.c:5550!  Oops - BUG[#1]:  CPU: 0 UID: 0 PID: 1517 Comm: hugefork02 Not tainted 6.14.0-rc2+ #241  Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022  pc 90000000004eaf1c ra 9000000000485538 tp 900000010edbc000 sp 900000010edbf940  a0 900000010edbfb00 a1 9000000108d20280 a2 00007fffe9474000 a3 00007ffff3474000  a4 0000000000000000 a5 0000000000000003 a6 00000000003cadd3 a7 0000000000000000  t0 0000000001ffffff t1 0000000001474000 t2 900000010ecd7900 t3 00007fffe9474000  t4 00007fffe9474000 t5 0000000000000040 t6 900000010edbfb00 t7 0000000000000001  t8 0000000000000005 u0 90000000004849d0 s9 900000010edbfa00 s0 9000000108d20280  s1 00007fffe9474000 s2 0000000002000000 s3 9000000108d20280 s4 9000000002b38b10  s5 900000010edbfb00 s6 00007ffff3474000 s7 0000000000000406 s8 900000010edbfa08     ra: 9000000000485538 unmap_vmas+0x130/0x218    ERA: 90000000004eaf1c __unmap_hugepage_range+0x6f4/0x7d0   PRMD: 00000004 (PPLV0 +PIE -PWE)   EUEN: 00000007 (+FPE +SXE +ASXE -BTE)   ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)  ESTAT: 000c0000 [BRK] (IS= ECode=12 EsubCode=0)  PRID: 0014c010 (Loongson-64bit, Loongson-3A5000)  Process hugefork02 (pid: 1517, threadinfo=00000000a670eaf4, task=000000007a95fc64)  Call Trace:  [<90000000004eaf1c>] __unmap_hugepage_range+0x6f4/0x7d0  [<9000000000485534>] unmap_vmas+0x12c/0x218  [<9000000000494068>] exit_mmap+0xe0/0x308  [<900000000025fdc4>] mmput+0x74/0x180  [<900000000026a284>] do_exit+0x294/0x898  [<900000000026aa30>] do_group_exit+0x30/0x98  [<900000000027bed4>] get_signal+0x83c/0x868  [<90000000002457b4>] arch_do_signal_or_restart+0x54/0xfa0  [<90000000015795e8>] irqentry_exit_to_user_mode+0xb8/0x138  [<90000000002572d0>] tlb_do_page_fault_1+0x114/0x1b4  The problem is that base address allocated from hugetlbfs is not aligned with pmd size. Here add a checking for hugetlbfs and align base address with pmd size. After this patch the test case "testcases/bin/hugefork02" passes to run.  This is similar to the commit 7f24cbc9c4d42db8a3c8484d1 ("mm/mmap: teach generic_get_unmapped_area{_topdown} to handle hugetlb mappings").

CVE-2025-21955:

        In the Linux kernel, the following vulnerability has been resolved:  ksmbd: prevent connection release during oplock break notification  ksmbd_work could be freed when after connection release. Increment r_count of ksmbd_conn to indicate that requests are not finished yet and to not release the connection.

CVE-2025-21961:

        In the Linux kernel, the following vulnerability has been resolved:  eth: bnxt: fix truesize for mb-xdp-pass case  When mb-xdp is set and return is XDP_PASS, packet is converted from xdp_buff to sk_buff with xdp_update_skb_shared_info() in bnxt_xdp_build_skb(). bnxt_xdp_build_skb() passes incorrect truesize argument to xdp_update_skb_shared_info(). The truesize is calculated as BNXT_RX_PAGE_SIZE * sinfo->nr_frags but the skb_shared_info was wiped by napi_build_skb() before. So it stores sinfo->nr_frags before bnxt_xdp_build_skb() and use it instead of getting skb_shared_info from xdp_get_shared_info_from_buff().  Splat looks like:  ------------[ cut here ]------------  WARNING: CPU: 2 PID: 0 at net/core/skbuff.c:6072 skb_try_coalesce+0x504/0x590  Modules linked in: xt_nat xt_tcpudp veth af_packet xt_conntrack nft_chain_nat xt_MASQUERADE nf_conntrack_netlink xfrm_user xt_addrtype nft_coms  CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.14.0-rc2+ #3  RIP: 0010:skb_try_coalesce+0x504/0x590  Code: 4b fd ff ff 49 8b 34 24 40 80 e6 40 0f 84 3d fd ff ff 49 8b 74 24 48 40 f6 c6 01 0f 84 2e fd ff ff 48 8d 4e ff e9 25 fd ff ff <0f> 0b e99  RSP: 0018:ffffb62c4120caa8 EFLAGS: 00010287  RAX: 0000000000000003 RBX: ffffb62c4120cb14 RCX: 0000000000000ec0  RDX: 0000000000001000 RSI: ffffa06e5d7dc000 RDI: 0000000000000003  RBP: ffffa06e5d7ddec0 R08: ffffa06e6120a800 R09: ffffa06e7a119900  R10: 0000000000002310 R11: ffffa06e5d7dcec0 R12: ffffe4360575f740  R13: ffffe43600000000 R14: 0000000000000002 R15: 0000000000000002  FS:  0000000000000000(0000) GS:ffffa0755f700000(0000) knlGS:0000000000000000  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  CR2: 00007f147b76b0f8 CR3: 00000001615d4000 CR4: 00000000007506f0  PKRU: 55555554  Call Trace:   <IRQ>   ? __warn+0x84/0x130   ? skb_try_coalesce+0x504/0x590   ? report_bug+0x18a/0x1a0   ? handle_bug+0x53/0x90   ? exc_invalid_op+0x14/0x70   ? asm_exc_invalid_op+0x16/0x20   ? skb_try_coalesce+0x504/0x590   inet_frag_reasm_finish+0x11f/0x2e0   ip_defrag+0x37a/0x900   ip_local_deliver+0x51/0x120   ip_sublist_rcv_finish+0x64/0x70   ip_sublist_rcv+0x179/0x210   ip_list_rcv+0xf9/0x130  How to reproduce: <Node A> ip link set $interface1 xdp obj xdp_pass.o ip link set $interface1 mtu 9000 up ip a a 10.0.0.1/24 dev $interface1 <Node B> ip link set $interfac2 mtu 9000 up ip a a 10.0.0.2/24 dev $interface2 ping 10.0.0.1 -s 65000  Following ping.py patch adds xdp-mb-pass case. so ping.py is going to be able to reproduce this issue.

CVE-2025-21967:

        In the Linux kernel, the following vulnerability has been resolved:  ksmbd: fix use-after-free in ksmbd_free_work_struct  ->interim_entry of ksmbd_work could be deleted after oplock is freed. We don't need to manage it with linked list. The interim request could be immediately sent whenever a oplock break wait is needed.

CVE-2025-21969:

        In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: L2CAP: Fix slab-use-after-free Read in l2cap_send_cmd  After the hci sync command releases l2cap_conn, the hci receive data work queue references the released l2cap_conn when sending to the upper layer. Add hci dev lock to the hci receive data work queue to synchronize the two.  [1] BUG: KASAN: slab-use-after-free in l2cap_send_cmd+0x187/0x8d0 net/bluetooth/l2cap_core.c:954 Read of size 8 at addr ffff8880271a4000 by task kworker/u9:2/5837  CPU: 0 UID: 0 PID: 5837 Comm: kworker/u9:2 Not tainted 6.13.0-rc5-syzkaller-00163-gab75170520d4 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: hci1 hci_rx_work Call Trace:  <TASK>  __dump_stack lib/dump_stack.c:94 [inline]  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120  print_address_description mm/kasan/report.c:378 [inline]  print_report+0x169/0x550 mm/kasan/report.c:489  kasan_report+0x143/0x180 mm/kasan/report.c:602  l2cap_build_cmd net/bluetooth/l2cap_core.c:2964 [inline]  l2cap_send_cmd+0x187/0x8d0 net/bluetooth/l2cap_core.c:954  l2cap_sig_send_rej net/bluetooth/l2cap_core.c:5502 [inline]  l2cap_sig_channel net/bluetooth/l2cap_core.c:5538 [inline]  l2cap_recv_frame+0x221f/0x10db0 net/bluetooth/l2cap_core.c:6817  hci_acldata_packet net/bluetooth/hci_core.c:3797 [inline]  hci_rx_work+0x508/0xdb0 net/bluetooth/hci_core.c:4040  process_one_work kernel/workqueue.c:3229 [inline]  process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310  worker_thread+0x870/0xd30 kernel/workqueue.c:3391  kthread+0x2f0/0x390 kernel/kthread.c:389  ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244  </TASK>  Allocated by task 5837:  kasan_save_stack mm/kasan/common.c:47 [inline]  kasan_save_track+0x3f/0x80 mm/kasan/common.c:68  poison_kmalloc_redzone mm/kasan/common.c:377 [inline]  __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394  kasan_kmalloc include/linux/kasan.h:260 [inline]  __kmalloc_cache_noprof+0x243/0x390 mm/slub.c:4329  kmalloc_noprof include/linux/slab.h:901 [inline]  kzalloc_noprof include/linux/slab.h:1037 [inline]  l2cap_conn_add+0xa9/0x8e0 net/bluetooth/l2cap_core.c:6860  l2cap_connect_cfm+0x115/0x1090 net/bluetooth/l2cap_core.c:7239  hci_connect_cfm include/net/bluetooth/hci_core.h:2057 [inline]  hci_remote_features_evt+0x68e/0xac0 net/bluetooth/hci_event.c:3726  hci_event_func net/bluetooth/hci_event.c:7473 [inline]  hci_event_packet+0xac2/0x1540 net/bluetooth/hci_event.c:7525  hci_rx_work+0x3f3/0xdb0 net/bluetooth/hci_core.c:4035  process_one_work kernel/workqueue.c:3229 [inline]  process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310  worker_thread+0x870/0xd30 kernel/workqueue.c:3391  kthread+0x2f0/0x390 kernel/kthread.c:389  ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244  Freed by task 54:  kasan_save_stack mm/kasan/common.c:47 [inline]  kasan_save_track+0x3f/0x80 mm/kasan/common.c:68  kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582  poison_slab_object mm/kasan/common.c:247 [inline]  __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264  kasan_slab_free include/linux/kasan.h:233 [inline]  slab_free_hook mm/slub.c:2353 [inline]  slab_free mm/slub.c:4613 [inline]  kfree+0x196/0x430 mm/slub.c:4761  l2cap_connect_cfm+0xcc/0x1090 net/bluetooth/l2cap_core.c:7235  hci_connect_cfm include/net/bluetooth/hci_core.h:2057 [inline]  hci_conn_failed+0x287/0x400 net/bluetooth/hci_conn.c:1266  hci_abort_conn_sync+0x56c/0x11f0 net/bluetooth/hci_sync.c:5603  hci_cmd_sync_work+0x22b/0x400 net/bluetooth/hci_sync.c:332  process_one_work kernel/workqueue.c:3229 [inline]  process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310  worker_thread+0x870/0xd30 kernel/workqueue.c:3391  kthread+0x2f0/0x390 kernel/kthread.c:389  ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entr ---truncated---

CVE-2025-21972:

        In the Linux kernel, the following vulnerability has been resolved:  net: mctp: unshare packets when reassembling  Ensure that the frag_list used for reassembly isn't shared with other packets. This avoids incorrect reassembly when packets are cloned, and prevents a memory leak due to circular references between fragments and their skb_shared_info.  The upcoming MCTP-over-USB driver uses skb_clone which can trigger the problem - other MCTP drivers don't share SKBs.  A kunit test is added to reproduce the issue.

CVE-2025-21976:

        In the Linux kernel, the following vulnerability has been resolved:  fbdev: hyperv_fb: Allow graceful removal of framebuffer  When a Hyper-V framebuffer device is unbind, hyperv_fb driver tries to release the framebuffer forcefully. If this framebuffer is in use it produce the following WARN and hence this framebuffer is never released.  [   44.111220] WARNING: CPU: 35 PID: 1882 at drivers/video/fbdev/core/fb_info.c:70 framebuffer_release+0x2c/0x40 < snip > [   44.111289] Call Trace: [   44.111290]  <TASK> [   44.111291]  ? show_regs+0x6c/0x80 [   44.111295]  ? __warn+0x8d/0x150 [   44.111298]  ? framebuffer_release+0x2c/0x40 [   44.111300]  ? report_bug+0x182/0x1b0 [   44.111303]  ? handle_bug+0x6e/0xb0 [   44.111306]  ? exc_invalid_op+0x18/0x80 [   44.111308]  ? asm_exc_invalid_op+0x1b/0x20 [   44.111311]  ? framebuffer_release+0x2c/0x40 [   44.111313]  ? hvfb_remove+0x86/0xa0 [hyperv_fb] [   44.111315]  vmbus_remove+0x24/0x40 [hv_vmbus] [   44.111323]  device_remove+0x40/0x80 [   44.111325]  device_release_driver_internal+0x20b/0x270 [   44.111327]  ? bus_find_device+0xb3/0xf0  Fix this by moving the release of framebuffer and assosiated memory to fb_ops.fb_destroy function, so that framebuffer framework handles it gracefully.  While we fix this, also replace manual registrations/unregistration of framebuffer with devm_register_framebuffer.

CVE-2025-21985:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Fix out-of-bound accesses  [WHAT & HOW] hpo_stream_to_link_encoder_mapping has size MAX_HPO_DP2_ENCODERS(=4), but location can have size up to 6. As a result, it is necessary to check location against MAX_HPO_DP2_ENCODERS.  Similiarly, disp_cfg_stream_location can be used as an array index which should be 0..5, so the ASSERT's conditions should be less without equal.

CVE-2025-22028:

        In the Linux kernel, the following vulnerability has been resolved:  media: vimc: skip .s_stream() for stopped entities  Syzbot reported [1] a warning prompted by a check in call_s_stream() that checks whether .s_stream() operation is warranted for unstarted or stopped subdevs.  Add a simple fix in vimc_streamer_pipeline_terminate() ensuring that entities skip a call to .s_stream() unless they have been previously properly started.  [1] Syzbot report: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 5933 at drivers/media/v4l2-core/v4l2-subdev.c:460 call_s_stream+0x2df/0x350 drivers/media/v4l2-core/v4l2-subdev.c:460 Modules linked in: CPU: 0 UID: 0 PID: 5933 Comm: syz-executor330 Not tainted 6.13.0-rc2-syzkaller-00362-g2d8308bf5b67 #0 ... Call Trace:  <TASK>  vimc_streamer_pipeline_terminate+0x218/0x320 drivers/media/test-drivers/vimc/vimc-streamer.c:62  vimc_streamer_pipeline_init drivers/media/test-drivers/vimc/vimc-streamer.c:101 [inline]  vimc_streamer_s_stream+0x650/0x9a0 drivers/media/test-drivers/vimc/vimc-streamer.c:203  vimc_capture_start_streaming+0xa1/0x130 drivers/media/test-drivers/vimc/vimc-capture.c:256  vb2_start_streaming+0x15f/0x5a0 drivers/media/common/videobuf2/videobuf2-core.c:1789  vb2_core_streamon+0x2a7/0x450 drivers/media/common/videobuf2/videobuf2-core.c:2348  vb2_streamon drivers/media/common/videobuf2/videobuf2-v4l2.c:875 [inline]  vb2_ioctl_streamon+0xf4/0x170 drivers/media/common/videobuf2/videobuf2-v4l2.c:1118  __video_do_ioctl+0xaf0/0xf00 drivers/media/v4l2-core/v4l2-ioctl.c:3122  video_usercopy+0x4d2/0x1620 drivers/media/v4l2-core/v4l2-ioctl.c:3463  v4l2_ioctl+0x1ba/0x250 drivers/media/v4l2-core/v4l2-dev.c:366  vfs_ioctl fs/ioctl.c:51 [inline]  __do_sys_ioctl fs/ioctl.c:906 [inline]  __se_sys_ioctl fs/ioctl.c:892 [inline]  __x64_sys_ioctl+0x190/0x200 fs/ioctl.c:892  do_syscall_x64 arch/x86/entry/common.c:52 [inline]  do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f2b85c01b19 ...

CVE-2025-22037:

        In the Linux kernel, the following vulnerability has been resolved:  ksmbd: fix null pointer dereference in alloc_preauth_hash()  The Client send malformed smb2 negotiate request. ksmbd return error response. Subsequently, the client can send smb2 session setup even thought conn->preauth_info is not allocated. This patch add KSMBD_SESS_NEED_SETUP status of connection to ignore session setup request if smb2 negotiate phase is not complete.

CVE-2025-22043:

        In the Linux kernel, the following vulnerability has been resolved:  ksmbd: add bounds check for durable handle context  Add missing bounds check for durable handle context.

CVE-2025-22048:

        In the Linux kernel, the following vulnerability has been resolved:  LoongArch: BPF: Don't override subprog's return value  The verifier test `calls: div by 0 in subprog` triggers a panic at the ld.bu instruction. The ld.bu insn is trying to load byte from memory address returned by the subprog. The subprog actually set the correct address at the a5 register (dedicated register for BPF return values). But at commit 73c359d1d356 ("LoongArch: BPF: Sign-extend return values") we also sign extended a5 to the a0 register (return value in LoongArch). For function call insn, we later propagate the a0 register back to a5 register. This is right for native calls but wrong for bpf2bpf calls which expect zero-extended return value in a5 register. So only move a0 to a5 for native calls (i.e. non-BPF_PSEUDO_CALL).

CVE-2025-22053:

        In the Linux kernel, the following vulnerability has been resolved:  net: ibmveth: make veth_pool_store stop hanging  v2: - Created a single error handling unlock and exit in veth_pool_store - Greatly expanded commit message with previous explanatory-only text  Summary: Use rtnl_mutex to synchronize veth_pool_store with itself, ibmveth_close and ibmveth_open, preventing multiple calls in a row to napi_disable.  Background: Two (or more) threads could call veth_pool_store through writing to /sys/devices/vio/30000002/pool*/*. You can do this easily with a little shell script. This causes a hang.  I configured LOCKDEP, compiled ibmveth.c with DEBUG, and built a new kernel. I ran this test again and saw:      Setting pool0/active to 0     Setting pool1/active to 1     [   73.911067][ T4365] ibmveth 30000002 eth0: close starting     Setting pool1/active to 1     Setting pool1/active to 0     [   73.911367][ T4366] ibmveth 30000002 eth0: close starting     [   73.916056][ T4365] ibmveth 30000002 eth0: close complete     [   73.916064][ T4365] ibmveth 30000002 eth0: open starting     [  110.808564][  T712] systemd-journald[712]: Sent WATCHDOG=1 notification.     [  230.808495][  T712] systemd-journald[712]: Sent WATCHDOG=1 notification.     [  243.683786][  T123] INFO: task stress.sh:4365 blocked for more than 122 seconds.     [  243.683827][  T123]       Not tainted 6.14.0-01103-g2df0c02dab82-dirty #8     [  243.683833][  T123] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.     [  243.683838][  T123] task:stress.sh       state:D stack:28096 pid:4365  tgid:4365  ppid:4364   task_flags:0x400040 flags:0x00042000     [  243.683852][  T123] Call Trace:     [  243.683857][  T123] [c00000000c38f690] [0000000000000001] 0x1 (unreliable)     [  243.683868][  T123] [c00000000c38f840] [c00000000001f908] __switch_to+0x318/0x4e0     [  243.683878][  T123] [c00000000c38f8a0] [c000000001549a70] __schedule+0x500/0x12a0     [  243.683888][  T123] [c00000000c38f9a0] [c00000000154a878] schedule+0x68/0x210     [  243.683896][  T123] [c00000000c38f9d0] [c00000000154ac80] schedule_preempt_disabled+0x30/0x50     [  243.683904][  T123] [c00000000c38fa00] [c00000000154dbb0] __mutex_lock+0x730/0x10f0     [  243.683913][  T123] [c00000000c38fb10] [c000000001154d40] napi_enable+0x30/0x60     [  243.683921][  T123] [c00000000c38fb40] [c000000000f4ae94] ibmveth_open+0x68/0x5dc     [  243.683928][  T123] [c00000000c38fbe0] [c000000000f4aa20] veth_pool_store+0x220/0x270     [  243.683936][  T123] [c00000000c38fc70] [c000000000826278] sysfs_kf_write+0x68/0xb0     [  243.683944][  T123] [c00000000c38fcb0] [c0000000008240b8] kernfs_fop_write_iter+0x198/0x2d0     [  243.683951][  T123] [c00000000c38fd00] [c00000000071b9ac] vfs_write+0x34c/0x650     [  243.683958][  T123] [c00000000c38fdc0] [c00000000071bea8] ksys_write+0x88/0x150     [  243.683966][  T123] [c00000000c38fe10] [c0000000000317f4] system_call_exception+0x124/0x340     [  243.683973][  T123] [c00000000c38fe50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec     ...     [  243.684087][  T123] Showing all locks held in the system:     [  243.684095][  T123] 1 lock held by khungtaskd/123:     [  243.684099][  T123]  #0: c00000000278e370 (rcu_read_lock){....}-{1:2}, at: debug_show_all_locks+0x50/0x248     [  243.684114][  T123] 4 locks held by stress.sh/4365:     [  243.684119][  T123]  #0: c00000003a4cd3f8 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x88/0x150     [  243.684132][  T123]  #1: c000000041aea888 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x154/0x2d0     [  243.684143][  T123]  #2: c0000000366fb9a8 (kn->active#64){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x160/0x2d0     [  243.684155][  T123]  #3: c000000035ff4cb8 (&dev->lock){+.+.}-{3:3}, at: napi_enable+0x30/0x60     [  243.684166][  T123] 5 locks held by stress.sh/4366:     [  243.684170][  T123]  #0: c00000003a4cd3f8 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x88/0x150     [  243. ---truncated---

CVE-2025-22057:

        In the Linux kernel, the following vulnerability has been resolved:  net: decrease cached dst counters in dst_release  Upstream fix ac888d58869b ("net: do not delay dst_entries_add() in dst_release()") moved decrementing the dst count from dst_destroy to dst_release to avoid accessing already freed data in case of netns dismantle. However in case CONFIG_DST_CACHE is enabled and OvS+tunnels are used, this fix is incomplete as the same issue will be seen for cached dsts:    Unable to handle kernel paging request at virtual address ffff5aabf6b5c000   Call trace:    percpu_counter_add_batch+0x3c/0x160 (P)    dst_release+0xec/0x108    dst_cache_destroy+0x68/0xd8    dst_destroy+0x13c/0x168    dst_destroy_rcu+0x1c/0xb0    rcu_do_batch+0x18c/0x7d0    rcu_core+0x174/0x378    rcu_core_si+0x18/0x30  Fix this by invalidating the cache, and thus decrementing cached dst counters, in dst_release too.

CVE-2025-22070:

        In the Linux kernel, the following vulnerability has been resolved:  fs/9p: fix NULL pointer dereference on mkdir  When a 9p tree was mounted with option 'posixacl', parent directory had a default ACL set for its subdirectories, e.g.:    setfacl -m default:group:simpsons:rwx parentdir  then creating a subdirectory crashed 9p client, as v9fs_fid_add() call in function v9fs_vfs_mkdir_dotl() sets the passed 'fid' pointer to NULL (since dafbe689736) even though the subsequent v9fs_set_create_acl() call expects a valid non-NULL 'fid' pointer:    [   37.273191] BUG: kernel NULL pointer dereference, address: 0000000000000000   ...   [   37.322338] Call Trace:   [   37.323043]  <TASK>   [   37.323621] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434)   [   37.324448] ? page_fault_oops (arch/x86/mm/fault.c:714)   [   37.325532] ? search_module_extables (kernel/module/main.c:3733)   [   37.326742] ? p9_client_walk (net/9p/client.c:1165) 9pnet   [   37.328006] ? search_bpf_extables (kernel/bpf/core.c:804)   [   37.329142] ? exc_page_fault (./arch/x86/include/asm/paravirt.h:686 arch/x86/mm/fault.c:1488 arch/x86/mm/fault.c:1538)   [   37.330196] ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:574)   [   37.331330] ? p9_client_walk (net/9p/client.c:1165) 9pnet   [   37.332562] ? v9fs_fid_xattr_get (fs/9p/xattr.c:30) 9p   [   37.333824] v9fs_fid_xattr_set (fs/9p/fid.h:23 fs/9p/xattr.c:121) 9p   [   37.335077] v9fs_set_acl (fs/9p/acl.c:276) 9p   [   37.336112] v9fs_set_create_acl (fs/9p/acl.c:307) 9p   [   37.337326] v9fs_vfs_mkdir_dotl (fs/9p/vfs_inode_dotl.c:411) 9p   [   37.338590] vfs_mkdir (fs/namei.c:4313)   [   37.339535] do_mkdirat (fs/namei.c:4336)   [   37.340465] __x64_sys_mkdir (fs/namei.c:4354)   [   37.341455] do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)   [   37.342447] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)  Fix this by simply swapping the sequence of these two calls in v9fs_vfs_mkdir_dotl(), i.e. calling v9fs_set_create_acl() before v9fs_fid_add().

CVE-2025-22109:

        In the Linux kernel, the following vulnerability has been resolved:  ax25: Remove broken autobind  Binding AX25 socket by using the autobind feature leads to memory leaks in ax25_connect() and also refcount leaks in ax25_release(). Memory leak was detected with kmemleak:  ================================================================ unreferenced object 0xffff8880253cd680 (size 96): backtrace: __kmalloc_node_track_caller_noprof (./include/linux/kmemleak.h:43) kmemdup_noprof (mm/util.c:136) ax25_rt_autobind (net/ax25/ax25_route.c:428) ax25_connect (net/ax25/af_ax25.c:1282) __sys_connect_file (net/socket.c:2045) __sys_connect (net/socket.c:2064) __x64_sys_connect (net/socket.c:2067) do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) ================================================================  When socket is bound, refcounts must be incremented the way it is done in ax25_bind() and ax25_setsockopt() (SO_BINDTODEVICE). In case of autobind, the refcounts are not incremented.  This bug leads to the following issue reported by Syzkaller:  ================================================================ ax25_connect(): syz-executor318 uses autobind, please contact jreuter@yaina.de ------------[ cut here ]------------ refcount_t: decrement hit 0; leaking memory. WARNING: CPU: 0 PID: 5317 at lib/refcount.c:31 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:31 Modules linked in: CPU: 0 UID: 0 PID: 5317 Comm: syz-executor318 Not tainted 6.14.0-rc4-syzkaller-00278-gece144f151ac #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:31 ... Call Trace:  <TASK>  __refcount_dec include/linux/refcount.h:336 [inline]  refcount_dec include/linux/refcount.h:351 [inline]  ref_tracker_free+0x6af/0x7e0 lib/ref_tracker.c:236  netdev_tracker_free include/linux/netdevice.h:4302 [inline]  netdev_put include/linux/netdevice.h:4319 [inline]  ax25_release+0x368/0x960 net/ax25/af_ax25.c:1080  __sock_release net/socket.c:647 [inline]  sock_close+0xbc/0x240 net/socket.c:1398  __fput+0x3e9/0x9f0 fs/file_table.c:464  __do_sys_close fs/open.c:1580 [inline]  __se_sys_close fs/open.c:1565 [inline]  __x64_sys_close+0x7f/0x110 fs/open.c:1565  do_syscall_x64 arch/x86/entry/common.c:52 [inline]  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  ...  </TASK> ================================================================  Considering the issues above and the comments left in the code that say: "check if we can remove this feature. It is broken."; "autobinding in this may or may not work"; - it is better to completely remove this feature than to fix it because it is broken and leads to various kinds of memory bugs.  Now calling connect() without first binding socket will result in an error (-EINVAL). Userspace software that relies on the autobind feature might get broken. However, this feature does not seem widely used with this specific driver as it was not reliable at any point of time, and it is already broken anyway. E.g. ax25-tools and ax25-apps packages for popular distributions do not use the autobind feature for AF_AX25.  Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

CVE-2025-22113:

        In the Linux kernel, the following vulnerability has been resolved:  ext4: avoid journaling sb update on error if journal is destroying  Presently we always BUG_ON if trying to start a transaction on a journal marked with JBD2_UNMOUNT, since this should never happen. However, while ltp running stress tests, it was observed that in case of some error handling paths, it is possible for update_super_work to start a transaction after the journal is destroyed eg:  (umount) ext4_kill_sb   kill_block_super     generic_shutdown_super       sync_filesystem /* commits all txns */       evict_inodes         /* might start a new txn */       ext4_put_super 	flush_work(&sbi->s_sb_upd_work) /* flush the workqueue */         jbd2_journal_destroy           journal_kill_thread             journal->j_flags |= JBD2_UNMOUNT;           jbd2_journal_commit_transaction             jbd2_journal_get_descriptor_buffer               jbd2_journal_bmap                 ext4_journal_bmap                   ext4_map_blocks                     ...                     ext4_inode_error                       ext4_handle_error                         schedule_work(&sbi->s_sb_upd_work)                                                 /* work queue kicks in */                                                update_super_work                                                  jbd2_journal_start                                                    start_this_handle                                                      BUG_ON(journal->j_flags &                                                             JBD2_UNMOUNT)  Hence, introduce a new mount flag to indicate journal is destroying and only do a journaled (and deferred) update of sb if this flag is not set. Otherwise, just fallback to an un-journaled commit.  Further, in the journal destroy path, we have the following sequence:    1. Set mount flag indicating journal is destroying   2. force a commit and wait for it   3. flush pending sb updates  This sequence is important as it ensures that, after this point, there is no sb update that might be journaled so it is safe to update the sb outside the journal. (To avoid race discussed in 2d01ddc86606)  Also, we don't need a similar check in ext4_grp_locked_error since it is only called from mballoc and AFAICT it would be always valid to schedule work here.

CVE-2025-22115:

        In the Linux kernel, the following vulnerability has been resolved:  btrfs: fix block group refcount race in btrfs_create_pending_block_groups()  Block group creation is done in two phases, which results in a slightly unintuitive property: a block group can be allocated/deallocated from after btrfs_make_block_group() adds it to the space_info with btrfs_add_bg_to_space_info(), but before creation is completely completed in btrfs_create_pending_block_groups(). As a result, it is possible for a block group to go unused and have 'btrfs_mark_bg_unused' called on it concurrently with 'btrfs_create_pending_block_groups'. This causes a number of issues, which were fixed with the block group flag 'BLOCK_GROUP_FLAG_NEW'.  However, this fix is not quite complete. Since it does not use the unused_bg_lock, it is possible for the following race to occur:  btrfs_create_pending_block_groups            btrfs_mark_bg_unused                                            if list_empty // false         list_del_init         clear_bit                                            else if (test_bit) // true                                                 list_move_tail  And we get into the exact same broken ref count and invalid new_bgs state for transaction cleanup that BLOCK_GROUP_FLAG_NEW was designed to prevent.  The broken refcount aspect will result in a warning like:    [1272.943527] refcount_t: underflow; use-after-free.   [1272.943967] WARNING: CPU: 1 PID: 61 at lib/refcount.c:28 refcount_warn_saturate+0xba/0x110   [1272.944731] Modules linked in: btrfs virtio_net xor zstd_compress raid6_pq null_blk [last unloaded: btrfs]   [1272.945550] CPU: 1 UID: 0 PID: 61 Comm: kworker/u32:1 Kdump: loaded Tainted: G        W          6.14.0-rc5+ #108   [1272.946368] Tainted: [W]=WARN   [1272.946585] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014   [1272.947273] Workqueue: btrfs_discard btrfs_discard_workfn [btrfs]   [1272.947788] RIP: 0010:refcount_warn_saturate+0xba/0x110   [1272.949532] RSP: 0018:ffffbf1200247df0 EFLAGS: 00010282   [1272.949901] RAX: 0000000000000000 RBX: ffffa14b00e3f800 RCX: 0000000000000000   [1272.950437] RDX: 0000000000000000 RSI: ffffbf1200247c78 RDI: 00000000ffffdfff   [1272.950986] RBP: ffffa14b00dc2860 R08: 00000000ffffdfff R09: ffffffff90526268   [1272.951512] R10: ffffffff904762c0 R11: 0000000063666572 R12: ffffa14b00dc28c0   [1272.952024] R13: 0000000000000000 R14: ffffa14b00dc2868 R15: 000001285dcd12c0   [1272.952850] FS:  0000000000000000(0000) GS:ffffa14d33c40000(0000) knlGS:0000000000000000   [1272.953458] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033   [1272.953931] CR2: 00007f838cbda000 CR3: 000000010104e000 CR4: 00000000000006f0   [1272.954474] Call Trace:   [1272.954655]  <TASK>   [1272.954812]  ? refcount_warn_saturate+0xba/0x110   [1272.955173]  ? __warn.cold+0x93/0xd7   [1272.955487]  ? refcount_warn_saturate+0xba/0x110   [1272.955816]  ? report_bug+0xe7/0x120   [1272.956103]  ? handle_bug+0x53/0x90   [1272.956424]  ? exc_invalid_op+0x13/0x60   [1272.956700]  ? asm_exc_invalid_op+0x16/0x20   [1272.957011]  ? refcount_warn_saturate+0xba/0x110   [1272.957399]  btrfs_discard_cancel_work.cold+0x26/0x2b [btrfs]   [1272.957853]  btrfs_put_block_group.cold+0x5d/0x8e [btrfs]   [1272.958289]  btrfs_discard_workfn+0x194/0x380 [btrfs]   [1272.958729]  process_one_work+0x130/0x290   [1272.959026]  worker_thread+0x2ea/0x420   [1272.959335]  ? __pfx_worker_thread+0x10/0x10   [1272.959644]  kthread+0xd7/0x1c0   [1272.959872]  ? __pfx_kthread+0x10/0x10   [1272.960172]  ret_from_fork+0x30/0x50   [1272.960474]  ? __pfx_kthread+0x10/0x10   [1272.960745]  ret_from_fork_asm+0x1a/0x30   [1272.961035]  </TASK>   [1272.961238] ---[ end trace 0000000000000000 ]---  Though we have seen them in the async discard workfn as well. It is most likely to happen after a relocation finishes which cancels discard, tears down the block group, etc.  Fix this fully by taking the lock arou ---truncated---

CVE-2025-22125:

        In the Linux kernel, the following vulnerability has been resolved:  md/raid1,raid10: don't ignore IO flags  If blk-wbt is enabled by default, it's found that raid write performance is quite bad because all IO are throttled by wbt of underlying disks, due to flag REQ_IDLE is ignored. And turns out this behaviour exist since blk-wbt is introduced.  Other than REQ_IDLE, other flags should not be ignored as well, for example REQ_META can be set for filesystems, clearing it can cause priority reverse problems; And REQ_NOWAIT should not be cleared as well, because io will wait instead of failing directly in underlying disks.  Fix those problems by keep IO flags from master bio.  Fises: f51d46d0e7cb ("md: add support for REQ_NOWAIT")

CVE-2025-22127:

        In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix potential deadloop in prepare_compress_overwrite()  Jan Prusakowski reported a kernel hang issue as below:  When running xfstests on linux-next kernel (6.14.0-rc3, 6.12) I encountered a problem in generic/475 test where fsstress process gets blocked in __f2fs_write_data_pages() and the test hangs. The options I used are:  MKFS_OPTIONS  -- -O compression -O extra_attr -O project_quota -O quota /dev/vdc MOUNT_OPTIONS -- -o acl,user_xattr -o discard,compress_extension=* /dev/vdc /vdc  INFO: task kworker/u8:0:11 blocked for more than 122 seconds.       Not tainted 6.14.0-rc3-xfstests-lockdep #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u8:0    state:D stack:0     pid:11    tgid:11    ppid:2      task_flags:0x4208160 flags:0x00004000 Workqueue: writeback wb_workfn (flush-253:0) Call Trace:  <TASK>  __schedule+0x309/0x8e0  schedule+0x3a/0x100  schedule_preempt_disabled+0x15/0x30  __mutex_lock+0x59a/0xdb0  __f2fs_write_data_pages+0x3ac/0x400  do_writepages+0xe8/0x290  __writeback_single_inode+0x5c/0x360  writeback_sb_inodes+0x22f/0x570  wb_writeback+0xb0/0x410  wb_do_writeback+0x47/0x2f0  wb_workfn+0x5a/0x1c0  process_one_work+0x223/0x5b0  worker_thread+0x1d5/0x3c0  kthread+0xfd/0x230  ret_from_fork+0x31/0x50  ret_from_fork_asm+0x1a/0x30  </TASK>  The root cause is: once generic/475 starts toload error table to dm device, f2fs_prepare_compress_overwrite() will loop reading compressed cluster pages due to IO error, meanwhile it has held .writepages lock, it can block all other writeback tasks.  Let's fix this issue w/ below changes: - add f2fs_handle_page_eio() in prepare_compress_overwrite() to detect IO error. - detect cp_error earler in f2fs_read_multi_pages().

CVE-2025-23130:

        In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to avoid panic once fallocation fails for pinfile  syzbot reports a f2fs bug as below:  ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2746! CPU: 0 UID: 0 PID: 5323 Comm: syz.0.0 Not tainted 6.13.0-rc2-syzkaller-00018-g7cb1b4663150 #0 RIP: 0010:get_new_segment fs/f2fs/segment.c:2746 [inline] RIP: 0010:new_curseg+0x1f52/0x1f70 fs/f2fs/segment.c:2876 Call Trace:  <TASK>  __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3210  f2fs_allocate_new_section fs/f2fs/segment.c:3224 [inline]  f2fs_allocate_pinning_section+0xfa/0x4e0 fs/f2fs/segment.c:3238  f2fs_expand_inode_data+0x696/0xca0 fs/f2fs/file.c:1830  f2fs_fallocate+0x537/0xa10 fs/f2fs/file.c:1940  vfs_fallocate+0x569/0x6e0 fs/open.c:327  do_vfs_ioctl+0x258c/0x2e40 fs/ioctl.c:885  __do_sys_ioctl fs/ioctl.c:904 [inline]  __se_sys_ioctl+0x80/0x170 fs/ioctl.c:892  do_syscall_x64 arch/x86/entry/common.c:52 [inline]  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  Concurrent pinfile allocation may run out of free section, result in panic in get_new_segment(), let's expand pin_sem lock coverage to include f2fs_gc(), so that we can make sure to reclaim enough free space for following allocation.  In addition, do below changes to enhance error path handling: - call f2fs_bug_on() only in non-pinfile allocation path in get_new_segment(). - call reset_curseg_fields() to reset all fields of curseg in new_curseg()

CVE-2025-23132:

        In the Linux kernel, the following vulnerability has been resolved:  f2fs: quota: fix to avoid warning in dquot_writeback_dquots()  F2FS-fs (dm-59): checkpoint=enable has some unwritten data.  ------------[ cut here ]------------ WARNING: CPU: 6 PID: 8013 at fs/quota/dquot.c:691 dquot_writeback_dquots+0x2fc/0x308 pc : dquot_writeback_dquots+0x2fc/0x308 lr : f2fs_quota_sync+0xcc/0x1c4 Call trace: dquot_writeback_dquots+0x2fc/0x308 f2fs_quota_sync+0xcc/0x1c4 f2fs_write_checkpoint+0x3d4/0x9b0 f2fs_issue_checkpoint+0x1bc/0x2c0 f2fs_sync_fs+0x54/0x150 f2fs_do_sync_file+0x2f8/0x814 __f2fs_ioctl+0x1960/0x3244 f2fs_ioctl+0x54/0xe0 __arm64_sys_ioctl+0xa8/0xe4 invoke_syscall+0x58/0x114  checkpoint and f2fs_remount may race as below, resulting triggering warning in dquot_writeback_dquots().  atomic write                                    remount                                                 - do_remount                                                  - down_write(&sb->s_umount);                                                   - f2fs_remount - ioctl  - f2fs_do_sync_file   - f2fs_sync_fs    - f2fs_write_checkpoint     - block_operations      - locked = down_read_trylock(&sbi->sb->s_umount)        : fail to lock due to the write lock was held by remount                                                  - up_write(&sb->s_umount);      - f2fs_quota_sync       - dquot_writeback_dquots        - WARN_ON_ONCE(!rwsem_is_locked(&sb->s_umount))        : trigger warning because s_umount lock was unlocked by remount  If checkpoint comes from mount/umount/remount/freeze/quotactl, caller of checkpoint has already held s_umount lock, calling dquot_writeback_dquots() in the context should be safe.  So let's record task to sbi->umount_lock_holder, so that checkpoint can know whether the lock has held in the context or not by checking current w/ it.  In addition, in order to not misrepresent caller of checkpoint, we should not allow to trigger async checkpoint for those callers: mount/umount/remount/ freeze/quotactl.

CVE-2025-23133:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: ath11k: update channel list in reg notifier instead reg worker  Currently when ath11k gets a new channel list, it will be processed according to the following steps: 1. update new channel list to cfg80211 and queue reg_work. 2. cfg80211 handles new channel list during reg_work. 3. update cfg80211's handled channel list to firmware by ath11k_reg_update_chan_list().  But ath11k will immediately execute step 3 after reg_work is just queued. Since step 2 is asynchronous, cfg80211 may not have completed handling the new channel list, which may leading to an out-of-bounds write error: BUG: KASAN: slab-out-of-bounds in ath11k_reg_update_chan_list Call Trace:     ath11k_reg_update_chan_list+0xbfe/0xfe0 [ath11k]     kfree+0x109/0x3a0     ath11k_regd_update+0x1cf/0x350 [ath11k]     ath11k_regd_update_work+0x14/0x20 [ath11k]     process_one_work+0xe35/0x14c0  Should ensure step 2 is completely done before executing step 3. Thus Wen raised patch[1]. When flag NL80211_REGDOM_SET_BY_DRIVER is set, cfg80211 will notify ath11k after step 2 is done.  So enable the flag NL80211_REGDOM_SET_BY_DRIVER then cfg80211 will notify ath11k after step 2 is done. At this time, there will be no KASAN bug during the execution of the step 3.  [1] https://patchwork.kernel.org/project/linux-wireless/patch/20230201065313.27203-1-quic_wgong@quicinc.com/  Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3

CVE-2025-37747:

        In the Linux kernel, the following vulnerability has been resolved:  perf: Fix hang while freeing sigtrap event  Perf can hang while freeing a sigtrap event if a related deferred signal hadn't managed to be sent before the file got closed:  perf_event_overflow()    task_work_add(perf_pending_task)  fput()    task_work_add(____fput())  task_work_run()     ____fput()         perf_release()             perf_event_release_kernel()                 _free_event()                     perf_pending_task_sync()                         task_work_cancel() -> FAILED                         rcuwait_wait_event()  Once task_work_run() is running, the list of pending callbacks is removed from the task_struct and from this point on task_work_cancel() can't remove any pending and not yet started work items, hence the task_work_cancel() failure and the hang on rcuwait_wait_event().  Task work could be changed to remove one work at a time, so a work running on the current task can always cancel a pending one, however the wait / wake design is still subject to inverted dependencies when remote targets are involved, as pictured by Oleg:  T1                                                      T2  fd = perf_event_open(pid => T2->pid);                  fd = perf_event_open(pid => T1->pid); close(fd)                                              close(fd)     <IRQ>                                                  <IRQ>     perf_event_overflow()                                  perf_event_overflow()        task_work_add(perf_pending_task)                        task_work_add(perf_pending_task)     </IRQ>                                                 </IRQ>     fput()                                                 fput()         task_work_add(____fput())                              task_work_add(____fput())      task_work_run()                                        task_work_run()         ____fput()                                             ____fput()             perf_release()                                         perf_release()                 perf_event_release_kernel()                            perf_event_release_kernel()                     _free_event()                                          _free_event()                         perf_pending_task_sync()                               perf_pending_task_sync()                             rcuwait_wait_event()                                   rcuwait_wait_event()  Therefore the only option left is to acquire the event reference count upon queueing the perf task work and release it from the task work, just like it was done before 3a5465418f5f ("perf: Fix event leak upon exec and file release") but without the leaks it fixed.  Some adjustments are necessary to make it work:  * A child event might dereference its parent upon freeing. Care must be   taken to release the parent last.  * Some places assuming the event doesn't have any reference held and   therefore can be freed right away must instead put the reference and   let the reference counting to its job.

CVE-2025-37750:

        In the Linux kernel, the following vulnerability has been resolved:  smb: client: fix UAF in decryption with multichannel  After commit f7025d861694 ("smb: client: allocate crypto only for primary server") and commit b0abcd65ec54 ("smb: client: fix UAF in async decryption"), the channels started reusing AEAD TFM from primary channel to perform synchronous decryption, but that can't done as there could be multiple cifsd threads (one per channel) simultaneously accessing it to perform decryption.  This fixes the following KASAN splat when running fstest generic/249 with 'vers=3.1.1,multichannel,max_channels=4,seal' against Windows Server 2022:  BUG: KASAN: slab-use-after-free in gf128mul_4k_lle+0xba/0x110 Read of size 8 at addr ffff8881046c18a0 by task cifsd/986 CPU: 3 UID: 0 PID: 986 Comm: cifsd Not tainted 6.15.0-rc1 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc41 04/01/2014 Call Trace:  <TASK>  dump_stack_lvl+0x5d/0x80  print_report+0x156/0x528  ? gf128mul_4k_lle+0xba/0x110  ? __virt_addr_valid+0x145/0x300  ? __phys_addr+0x46/0x90  ? gf128mul_4k_lle+0xba/0x110  kasan_report+0xdf/0x1a0  ? gf128mul_4k_lle+0xba/0x110  gf128mul_4k_lle+0xba/0x110  ghash_update+0x189/0x210  shash_ahash_update+0x295/0x370  ? __pfx_shash_ahash_update+0x10/0x10  ? __pfx_shash_ahash_update+0x10/0x10  ? __pfx_extract_iter_to_sg+0x10/0x10  ? ___kmalloc_large_node+0x10e/0x180  ? __asan_memset+0x23/0x50  crypto_ahash_update+0x3c/0xc0  gcm_hash_assoc_remain_continue+0x93/0xc0  crypt_message+0xe09/0xec0 [cifs]  ? __pfx_crypt_message+0x10/0x10 [cifs]  ? _raw_spin_unlock+0x23/0x40  ? __pfx_cifs_readv_from_socket+0x10/0x10 [cifs]  decrypt_raw_data+0x229/0x380 [cifs]  ? __pfx_decrypt_raw_data+0x10/0x10 [cifs]  ? __pfx_cifs_read_iter_from_socket+0x10/0x10 [cifs]  smb3_receive_transform+0x837/0xc80 [cifs]  ? __pfx_smb3_receive_transform+0x10/0x10 [cifs]  ? __pfx___might_resched+0x10/0x10  ? __pfx_smb3_is_transform_hdr+0x10/0x10 [cifs]  cifs_demultiplex_thread+0x692/0x1570 [cifs]  ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs]  ? rcu_is_watching+0x20/0x50  ? rcu_lockdep_current_cpu_online+0x62/0xb0  ? find_held_lock+0x32/0x90  ? kvm_sched_clock_read+0x11/0x20  ? local_clock_noinstr+0xd/0xd0  ? trace_irq_enable.constprop.0+0xa8/0xe0  ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs]  kthread+0x1fe/0x380  ? kthread+0x10f/0x380  ? __pfx_kthread+0x10/0x10  ? local_clock_noinstr+0xd/0xd0  ? ret_from_fork+0x1b/0x60  ? local_clock+0x15/0x30  ? lock_release+0x29b/0x390  ? rcu_is_watching+0x20/0x50  ? __pfx_kthread+0x10/0x10  ret_from_fork+0x31/0x60  ? __pfx_kthread+0x10/0x10  ret_from_fork_asm+0x1a/0x30  </TASK>

CVE-2025-37776:

        In the Linux kernel, the following vulnerability has been resolved:  ksmbd: fix use-after-free in smb_break_all_levII_oplock()  There is a room in smb_break_all_levII_oplock that can cause racy issues when unlocking in the middle of the loop. This patch use read lock to protect whole loop.

CVE-2025-37777:

        In the Linux kernel, the following vulnerability has been resolved:  ksmbd: fix use-after-free in __smb2_lease_break_noti()  Move tcp_transport free to ksmbd_conn_free. If ksmbd connection is referenced when ksmbd server thread terminates, It will not be freed, but conn->tcp_transport is freed. __smb2_lease_break_noti can be performed asynchronously when the connection is disconnected. __smb2_lease_break_noti calls ksmbd_conn_write, which can cause use-after-free when conn->ksmbd_transport is already freed.

CVE-2025-37800:

        In the Linux kernel, the following vulnerability has been resolved:  driver core: fix potential NULL pointer dereference in dev_uevent()  If userspace reads "uevent" device attribute at the same time as another threads unbinds the device from its driver, change to dev->driver from a valid pointer to NULL may result in crash. Fix this by using READ_ONCE() when fetching the pointer, and take bus' drivers klist lock to make sure driver instance will not disappear while we access it.  Use WRITE_ONCE() when setting the driver pointer to ensure there is no tearing.

CVE-2025-37802:

        In the Linux kernel, the following vulnerability has been resolved:  ksmbd: fix WARNING "do not call blocking ops when !TASK_RUNNING"  wait_event_timeout() will set the state of the current task to TASK_UNINTERRUPTIBLE, before doing the condition check. This means that ksmbd_durable_scavenger_alive() will try to acquire the mutex while already in a sleeping state. The scheduler warns us by giving the following warning:  do not call blocking ops when !TASK_RUNNING; state=2 set at  [<0000000061515a6f>] prepare_to_wait_event+0x9f/0x6c0 WARNING: CPU: 2 PID: 4147 at kernel/sched/core.c:10099 __might_sleep+0x12f/0x160  mutex lock is not needed in ksmbd_durable_scavenger_alive().

CVE-2025-37806:

        In the Linux kernel, the following vulnerability has been resolved:  fs/ntfs3: Keep write operations atomic  syzbot reported a NULL pointer dereference in __generic_file_write_iter. [1]  Before the write operation is completed, the user executes ioctl[2] to clear the compress flag of the file, which causes the is_compressed() judgment to return 0, further causing the program to enter the wrong process and call the wrong ops ntfs_aops_cmpr, which triggers the null pointer dereference of write_begin.  Use inode lock to synchronize ioctl and write to avoid this case.  [1] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info:   ESR = 0x0000000086000006   EC = 0x21: IABT (current EL), IL = 32 bits   SET = 0, FnV = 0   EA = 0, S1PTW = 0   FSC = 0x06: level 2 translation fault user pgtable: 4k pages, 48-bit VAs, pgdp=000000011896d000 [0000000000000000] pgd=0800000118b44403, p4d=0800000118b44403, pud=0800000117517403, pmd=0000000000000000 Internal error: Oops: 0000000086000006 [#1] PREEMPT SMP Modules linked in: CPU: 0 UID: 0 PID: 6427 Comm: syz-executor347 Not tainted 6.13.0-rc3-syzkaller-g573067a5a685 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0x0 lr : generic_perform_write+0x29c/0x868 mm/filemap.c:4055 sp : ffff80009d4978a0 x29: ffff80009d4979c0 x28: dfff800000000000 x27: ffff80009d497bc8 x26: 0000000000000000 x25: ffff80009d497960 x24: ffff80008ba71c68 x23: 0000000000000000 x22: ffff0000c655dac0 x21: 0000000000001000 x20: 000000000000000c x19: 1ffff00013a92f2c x18: ffff0000e183aa1c x17: 0004060000000014 x16: ffff800083275834 x15: 0000000000000001 x14: 0000000000000000 x13: 0000000000000001 x12: ffff0000c655dac0 x11: 0000000000ff0100 x10: 0000000000ff0100 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffff80009d497980 x4 : ffff80009d497960 x3 : 0000000000001000 x2 : 0000000000000000 x1 : ffff0000e183a928 x0 : ffff0000d60b0fc0 Call trace:  0x0 (P)  __generic_file_write_iter+0xfc/0x204 mm/filemap.c:4156  ntfs_file_write_iter+0x54c/0x630 fs/ntfs3/file.c:1267  new_sync_write fs/read_write.c:586 [inline]  vfs_write+0x920/0xcf4 fs/read_write.c:679  ksys_write+0x15c/0x26c fs/read_write.c:731  __do_sys_write fs/read_write.c:742 [inline]  __se_sys_write fs/read_write.c:739 [inline]  __arm64_sys_write+0x7c/0x90 fs/read_write.c:739  __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]  invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49  el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132  do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151  el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744  el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762  [2] ioctl$FS_IOC_SETFLAGS(r0, 0x40086602, &(0x7f00000000c0)=0x20)

CVE-2025-37807:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: Fix kmemleak warning for percpu hashmap  Vlad Poenaru reported the following kmemleak issue:    unreferenced object 0x606fd7c44ac8 (size 32):     backtrace (crc 0):       pcpu_alloc_noprof+0x730/0xeb0       bpf_map_alloc_percpu+0x69/0xc0       prealloc_init+0x9d/0x1b0       htab_map_alloc+0x363/0x510       map_create+0x215/0x3a0       __sys_bpf+0x16b/0x3e0       __x64_sys_bpf+0x18/0x20       do_syscall_64+0x7b/0x150       entry_SYSCALL_64_after_hwframe+0x4b/0x53  Further investigation shows the reason is due to not 8-byte aligned store of percpu pointer in htab_elem_set_ptr():   *(void __percpu **)(l->key + key_size) = pptr;  Note that the whole htab_elem alignment is 8 (for x86_64). If the key_size is 4, that means pptr is stored in a location which is 4 byte aligned but not 8 byte aligned. In mm/kmemleak.c, scan_block() scans the memory based on 8 byte stride, so it won't detect above pptr, hence reporting the memory leak.  In htab_map_alloc(), we already have          htab->elem_size = sizeof(struct htab_elem) +                           round_up(htab->map.key_size, 8);         if (percpu)                 htab->elem_size += sizeof(void *);         else                 htab->elem_size += round_up(htab->map.value_size, 8);  So storing pptr with 8-byte alignment won't cause any problem and can fix kmemleak too.  The issue can be reproduced with bpf selftest as well:   1. Enable CONFIG_DEBUG_KMEMLEAK config   2. Add a getchar() before skel destroy in test_hash_map() in prog_tests/for_each.c.      The purpose is to keep map available so kmemleak can be detected.   3. run './test_progs -t for_each/hash_map &' and a kmemleak should be reported.

CVE-2025-37834:

        In the Linux kernel, the following vulnerability has been resolved:  mm/vmscan: don't try to reclaim hwpoison folio  Syzkaller reports a bug as follows:  Injecting memory failure for pfn 0x18b00e at process virtual address 0x20ffd000 Memory failure: 0x18b00e: dirty swapcache page still referenced by 2 users Memory failure: 0x18b00e: recovery action for dirty swapcache page: Failed page: refcount:2 mapcount:0 mapping:0000000000000000 index:0x20ffd pfn:0x18b00e memcg:ffff0000dd6d9000 anon flags: 0x5ffffe00482011(locked|dirty|arch_1|swapbacked|hwpoison|node=0|zone=2|lastcpupid=0xfffff) raw: 005ffffe00482011 dead000000000100 dead000000000122 ffff0000e232a7c9 raw: 0000000000020ffd 0000000000000000 00000002ffffffff ffff0000dd6d9000 page dumped because: VM_BUG_ON_FOLIO(!folio_test_uptodate(folio)) ------------[ cut here ]------------ kernel BUG at mm/swap_state.c:184! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP Modules linked in: CPU: 0 PID: 60 Comm: kswapd0 Not tainted 6.6.0-gcb097e7de84e #3 Hardware name: linux,dummy-virt (DT) pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : add_to_swap+0xbc/0x158 lr : add_to_swap+0xbc/0x158 sp : ffff800087f37340 x29: ffff800087f37340 x28: fffffc00052c0380 x27: ffff800087f37780 x26: ffff800087f37490 x25: ffff800087f37c78 x24: ffff800087f377a0 x23: ffff800087f37c50 x22: 0000000000000000 x21: fffffc00052c03b4 x20: 0000000000000000 x19: fffffc00052c0380 x18: 0000000000000000 x17: 296f696c6f662865 x16: 7461646f7470755f x15: 747365745f6f696c x14: 6f6621284f494c4f x13: 0000000000000001 x12: ffff600036d8b97b x11: 1fffe00036d8b97a x10: ffff600036d8b97a x9 : dfff800000000000 x8 : 00009fffc9274686 x7 : ffff0001b6c5cbd3 x6 : 0000000000000001 x5 : ffff0000c25896c0 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff0000c25896c0 x0 : 0000000000000000 Call trace:  add_to_swap+0xbc/0x158  shrink_folio_list+0x12ac/0x2648  shrink_inactive_list+0x318/0x948  shrink_lruvec+0x450/0x720  shrink_node_memcgs+0x280/0x4a8  shrink_node+0x128/0x978  balance_pgdat+0x4f0/0xb20  kswapd+0x228/0x438  kthread+0x214/0x230  ret_from_fork+0x10/0x20  I can reproduce this issue with the following steps:  1) When a dirty swapcache page is isolated by reclaim process and the    page isn't locked, inject memory failure for the page.     me_swapcache_dirty() clears uptodate flag and tries to delete from lru,    but fails.  Reclaim process will put the hwpoisoned page back to lru.  2) The process that maps the hwpoisoned page exits, the page is deleted    the page will never be freed and will be in the lru forever.  3) If we trigger a reclaim again and tries to reclaim the page,    add_to_swap() will trigger VM_BUG_ON_FOLIO due to the uptodate flag is    cleared.  To fix it, skip the hwpoisoned page in shrink_folio_list().  Besides, the hwpoison folio may not be unmapped by hwpoison_user_mappings() yet, unmap it in shrink_folio_list(), otherwise the folio will fail to be unmaped by hwpoison_user_mappings() since the folio isn't in lru list.

CVE-2025-37842:

        In the Linux kernel, the following vulnerability has been resolved:  spi: fsl-qspi: use devm function instead of driver remove  Driver use devm APIs to manage clk/irq/resources and register the spi controller, but the legacy remove function will be called first during device detach and trigger kernel panic. Drop the remove function and use devm_add_action_or_reset() for driver cleanup to ensure the release sequence.  Trigger kernel panic on i.MX8MQ by echo 30bb0000.spi >/sys/bus/platform/drivers/fsl-quadspi/unbind

CVE-2025-37853:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdkfd: debugfs hang_hws skip GPU with MES  debugfs hang_hws is used by GPU reset test with HWS, for MES this crash the kernel with NULL pointer access because dqm->packet_mgr is not setup for MES path.  Skip GPU with MES for now, MES hang_hws debugfs interface will be supported later.

CVE-2025-37856:

        In the Linux kernel, the following vulnerability has been resolved:  btrfs: harden block_group::bg_list against list_del() races  As far as I can tell, these calls of list_del_init() on bg_list cannot run concurrently with btrfs_mark_bg_unused() or btrfs_mark_bg_to_reclaim(), as they are in transaction error paths and situations where the block group is readonly.  However, if there is any chance at all of racing with mark_bg_unused(), or a different future user of bg_list, better to be safe than sorry.  Otherwise we risk the following interleaving (bg_list refcount in parens)  T1 (some random op)                       T2 (btrfs_mark_bg_unused)                                         !list_empty(&bg->bg_list); (1) list_del_init(&bg->bg_list); (1)                                         list_move_tail (1) btrfs_put_block_group (0)                                         btrfs_delete_unused_bgs                                              bg = list_first_entry                                              list_del_init(&bg->bg_list);                                              btrfs_put_block_group(bg); (-1)  Ultimately, this results in a broken ref count that hits zero one deref early and the real final deref underflows the refcount, resulting in a WARNING.

CVE-2025-37860:

        In the Linux kernel, the following vulnerability has been resolved:  sfc: fix NULL dereferences in ef100_process_design_param()  Since cited commit, ef100_probe_main() and hence also  ef100_check_design_params() run before efx->net_dev is created;  consequently, we cannot netif_set_tso_max_size() or _segs() at this  point. Move those netif calls to ef100_probe_netdev(), and also replace  netif_err within the design params code with pci_err.

CVE-2025-37861:

        In the Linux kernel, the following vulnerability has been resolved:  scsi: mpi3mr: Synchronous access b/w reset and tm thread for reply queue  When the task management thread processes reply queues while the reset thread resets them, the task management thread accesses an invalid queue ID (0xFFFF), set by the reset thread, which points to unallocated memory, causing a crash.  Add flag 'io_admin_reset_sync' to synchronize access between the reset, I/O, and admin threads. Before a reset, the reset handler sets this flag to block I/O and admin processing threads. If any thread bypasses the initial check, the reset thread waits up to 10 seconds for processing to finish. If the wait exceeds 10 seconds, the controller is marked as unrecoverable.

CVE-2025-37880:

        In the Linux kernel, the following vulnerability has been resolved:  um: work around sched_yield not yielding in time-travel mode  sched_yield by a userspace may not actually cause scheduling in time-travel mode as no time has passed. In the case seen it appears to be a badly implemented userspace spinlock in ASAN. Unfortunately, with time-travel it causes an extreme slowdown or even deadlock depending on the kernel configuration (CONFIG_UML_MAX_USERSPACE_ITERATIONS).  Work around it by accounting time to the process whenever it executes a sched_yield syscall.

CVE-2025-37893:

        In the Linux kernel, the following vulnerability has been resolved:  LoongArch: BPF: Fix off-by-one error in build_prologue()  Vincent reported that running BPF progs with tailcalls on LoongArch causes kernel hard lockup. Debugging the issues shows that the JITed image missing a jirl instruction at the end of the epilogue.  There are two passes in JIT compiling, the first pass set the flags and the second pass generates JIT code based on those flags. With BPF progs mixing bpf2bpf and tailcalls, build_prologue() generates N insns in the first pass and then generates N+1 insns in the second pass. This makes epilogue_offset off by one and we will jump to some unexpected insn and cause lockup. Fix this by inserting a nop insn.

CVE-2025-37952:

        In the Linux kernel, the following vulnerability has been resolved:  ksmbd: Fix UAF in __close_file_table_ids  A use-after-free is possible if one thread destroys the file via __ksmbd_close_fd while another thread holds a reference to it. The existing checks on fp->refcount are not sufficient to prevent this.  The fix takes ft->lock around the section which removes the file from the file table. This prevents two threads acquiring the same file pointer via __close_file_table_ids, as well as the other functions which retrieve a file from the IDR and which already use this same lock.

CVE-2025-37956:

        In the Linux kernel, the following vulnerability has been resolved:  ksmbd: prevent rename with empty string  Client can send empty newname string to ksmbd server. It will cause a kernel oops from d_alloc. This patch return the error when attempting to rename a file or directory with an empty new name string.

CVE-2025-37957:

        In the Linux kernel, the following vulnerability has been resolved:  KVM: SVM: Forcibly leave SMM mode on SHUTDOWN interception  Previously, commit ed129ec9057f ("KVM: x86: forcibly leave nested mode on vCPU reset") addressed an issue where a triple fault occurring in nested mode could lead to use-after-free scenarios. However, the commit did not handle the analogous situation for System Management Mode (SMM).  This omission results in triggering a WARN when KVM forces a vCPU INIT after SHUTDOWN interception while the vCPU is in SMM. This situation was reprodused using Syzkaller by:    1) Creating a KVM VM and vCPU   2) Sending a KVM_SMI ioctl to explicitly enter SMM   3) Executing invalid instructions causing consecutive exceptions and      eventually a triple fault  The issue manifests as follows:    WARNING: CPU: 0 PID: 25506 at arch/x86/kvm/x86.c:12112   kvm_vcpu_reset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112   Modules linked in:   CPU: 0 PID: 25506 Comm: syz-executor.0 Not tainted   6.1.130-syzkaller-00157-g164fe5dde9b6 #0   Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),   BIOS 1.12.0-1 04/01/2014   RIP: 0010:kvm_vcpu_reset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112   Call Trace:    <TASK>    shutdown_interception+0x66/0xb0 arch/x86/kvm/svm/svm.c:2136    svm_invoke_exit_handler+0x110/0x530 arch/x86/kvm/svm/svm.c:3395    svm_handle_exit+0x424/0x920 arch/x86/kvm/svm/svm.c:3457    vcpu_enter_guest arch/x86/kvm/x86.c:10959 [inline]    vcpu_run+0x2c43/0x5a90 arch/x86/kvm/x86.c:11062    kvm_arch_vcpu_ioctl_run+0x50f/0x1cf0 arch/x86/kvm/x86.c:11283    kvm_vcpu_ioctl+0x570/0xf00 arch/x86/kvm/../../../virt/kvm/kvm_main.c:4122    vfs_ioctl fs/ioctl.c:51 [inline]    __do_sys_ioctl fs/ioctl.c:870 [inline]    __se_sys_ioctl fs/ioctl.c:856 [inline]    __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:856    do_syscall_x64 arch/x86/entry/common.c:51 [inline]    do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81    entry_SYSCALL_64_after_hwframe+0x6e/0xd8  Architecturally, INIT is blocked when the CPU is in SMM, hence KVM's WARN() in kvm_vcpu_reset() to guard against KVM bugs, e.g. to detect improper emulation of INIT.  SHUTDOWN on SVM is a weird edge case where KVM needs to do _something_ sane with the VMCB, since it's technically undefined, and INIT is the least awful choice given KVM's ABI.  So, double down on stuffing INIT on SHUTDOWN, and force the vCPU out of SMM to avoid any weirdness (and the WARN).  Found by Linux Verification Center (linuxtesting.org) with Syzkaller.  [sean: massage changelog, make it clear this isn't architectural behavior]

CVE-2025-37977:

        In the Linux kernel, the following vulnerability has been resolved:  scsi: ufs: exynos: Disable iocc if dma-coherent property isn't set  If dma-coherent property isn't set then descriptors are non-cacheable and the iocc shareability bits should be disabled. Without this UFS can end up in an incompatible configuration and suffer from random cache related stability issues.

CVE-2025-38006:

        In the Linux kernel, the following vulnerability has been resolved:  net: mctp: Don't access ifa_index when missing  In mctp_dump_addrinfo, ifa_index can be used to filter interfaces, but only when the struct ifaddrmsg is provided. Otherwise it will be comparing to uninitialised memory - reproducible in the syzkaller case from dhcpd, or busybox "ip addr show".  The kernel MCTP implementation has always filtered by ifa_index, so existing userspace programs expecting to dump MCTP addresses must already be passing a valid ifa_index value (either 0 or a real index).  BUG: KMSAN: uninit-value in mctp_dump_addrinfo+0x208/0xac0 net/mctp/device.c:128  mctp_dump_addrinfo+0x208/0xac0 net/mctp/device.c:128  rtnl_dump_all+0x3ec/0x5b0 net/core/rtnetlink.c:4380  rtnl_dumpit+0xd5/0x2f0 net/core/rtnetlink.c:6824  netlink_dump+0x97b/0x1690 net/netlink/af_netlink.c:2309

CVE-2025-38014:

        In the Linux kernel, the following vulnerability has been resolved:  dmaengine: idxd: Refactor remove call with idxd_cleanup() helper  The idxd_cleanup() helper cleans up perfmon, interrupts, internals and so on. Refactor remove call with the idxd_cleanup() helper to avoid code duplication. Note, this also fixes the missing put_device() for idxd groups, enginces and wqs.

CVE-2025-38029:

        In the Linux kernel, the following vulnerability has been resolved:  kasan: avoid sleepable page allocation from atomic context  apply_to_pte_range() enters the lazy MMU mode and then invokes kasan_populate_vmalloc_pte() callback on each page table walk iteration.  However, the callback can go into sleep when trying to allocate a single page, e.g.  if an architecutre disables preemption on lazy MMU mode enter.  On s390 if make arch_enter_lazy_mmu_mode() -> preempt_enable() and arch_leave_lazy_mmu_mode() -> preempt_disable(), such crash occurs:  [    0.663336] BUG: sleeping function called from invalid context at ./include/linux/sched/mm.h:321 [    0.663348] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2, name: kthreadd [    0.663358] preempt_count: 1, expected: 0 [    0.663366] RCU nest depth: 0, expected: 0 [    0.663375] no locks held by kthreadd/2. [    0.663383] Preemption disabled at: [    0.663386] [<0002f3284cbb4eda>] apply_to_pte_range+0xfa/0x4a0 [    0.663405] CPU: 0 UID: 0 PID: 2 Comm: kthreadd Not tainted 6.15.0-rc5-gcc-kasan-00043-gd76bb1ebb558-dirty #162 PREEMPT [    0.663408] Hardware name: IBM 3931 A01 701 (KVM/Linux) [    0.663409] Call Trace: [    0.663410]  [<0002f3284c385f58>] dump_stack_lvl+0xe8/0x140 [    0.663413]  [<0002f3284c507b9e>] __might_resched+0x66e/0x700 [    0.663415]  [<0002f3284cc4f6c0>] __alloc_frozen_pages_noprof+0x370/0x4b0 [    0.663419]  [<0002f3284ccc73c0>] alloc_pages_mpol+0x1a0/0x4a0 [    0.663421]  [<0002f3284ccc8518>] alloc_frozen_pages_noprof+0x88/0xc0 [    0.663424]  [<0002f3284ccc8572>] alloc_pages_noprof+0x22/0x120 [    0.663427]  [<0002f3284cc341ac>] get_free_pages_noprof+0x2c/0xc0 [    0.663429]  [<0002f3284cceba70>] kasan_populate_vmalloc_pte+0x50/0x120 [    0.663433]  [<0002f3284cbb4ef8>] apply_to_pte_range+0x118/0x4a0 [    0.663435]  [<0002f3284cbc7c14>] apply_to_pmd_range+0x194/0x3e0 [    0.663437]  [<0002f3284cbc99be>] __apply_to_page_range+0x2fe/0x7a0 [    0.663440]  [<0002f3284cbc9e88>] apply_to_page_range+0x28/0x40 [    0.663442]  [<0002f3284ccebf12>] kasan_populate_vmalloc+0x82/0xa0 [    0.663445]  [<0002f3284cc1578c>] alloc_vmap_area+0x34c/0xc10 [    0.663448]  [<0002f3284cc1c2a6>] __get_vm_area_node+0x186/0x2a0 [    0.663451]  [<0002f3284cc1e696>] __vmalloc_node_range_noprof+0x116/0x310 [    0.663454]  [<0002f3284cc1d950>] __vmalloc_node_noprof+0xd0/0x110 [    0.663457]  [<0002f3284c454b88>] alloc_thread_stack_node+0xf8/0x330 [    0.663460]  [<0002f3284c458d56>] dup_task_struct+0x66/0x4d0 [    0.663463]  [<0002f3284c45be90>] copy_process+0x280/0x4b90 [    0.663465]  [<0002f3284c460940>] kernel_clone+0xd0/0x4b0 [    0.663467]  [<0002f3284c46115e>] kernel_thread+0xbe/0xe0 [    0.663469]  [<0002f3284c4e440e>] kthreadd+0x50e/0x7f0 [    0.663472]  [<0002f3284c38c04a>] __ret_from_fork+0x8a/0xf0 [    0.663475]  [<0002f3284ed57ff2>] ret_from_fork+0xa/0x38  Instead of allocating single pages per-PTE, bulk-allocate the shadow memory prior to applying kasan_populate_vmalloc_pte() callback on a page range.

CVE-2025-38038:

        In the Linux kernel, the following vulnerability has been resolved:  cpufreq: amd-pstate: Remove unnecessary driver_lock in set_boost  set_boost is a per-policy function call, hence a driver wide lock is unnecessary. Also this mutex_acquire can collide with the mutex_acquire from the mode-switch path in status_store(), which can lead to a deadlock. So, remove it.

CVE-2025-38039:

        In the Linux kernel, the following vulnerability has been resolved:  net/mlx5e: Avoid WARN_ON when configuring MQPRIO with HTB offload enabled  When attempting to enable MQPRIO while HTB offload is already configured, the driver currently returns `-EINVAL` and triggers a `WARN_ON`, leading to an unnecessary call trace.  Update the code to handle this case more gracefully by returning `-EOPNOTSUPP` instead, while also providing a helpful user message.

CVE-2025-38041:

        In the Linux kernel, the following vulnerability has been resolved:  clk: sunxi-ng: h616: Reparent GPU clock during frequency changes  The H616 manual does not state that the GPU PLL supports dynamic frequency configuration, so we must take extra care when changing the frequency. Currently any attempt to do device DVFS on the GPU lead to panfrost various ooops, and GPU hangs.  The manual describes the algorithm for changing the PLL frequency, which the CPU PLL notifier code already support, so we reuse that to reparent the GPU clock to GPU1 clock during frequency changes.

CVE-2025-38042:

        In the Linux kernel, the following vulnerability has been resolved:  dmaengine: ti: k3-udma-glue: Drop skip_fdq argument from k3_udma_glue_reset_rx_chn  The user of k3_udma_glue_reset_rx_chn() e.g. ti_am65_cpsw_nuss can run on multiple platforms having different DMA architectures. On some platforms there can be one FDQ for all flows in the RX channel while for others there is a separate FDQ for each flow in the RX channel.  So far we have been relying on the skip_fdq argument of k3_udma_glue_reset_rx_chn().  Instead of relying on the user to provide this information, infer it based on DMA architecture during k3_udma_glue_request_rx_chn() and save it in an internal flag 'single_fdq'. Use that flag at k3_udma_glue_reset_rx_chn() to deicide if the FDQ needs to be cleared for every flow or just for flow 0.  Fixes the below issue on ti_am65_cpsw_nuss driver on AM62-SK.  > ip link set eth1 down > ip link set eth0 down > ethtool -L eth0 rx 8 > ip link set eth0 up > modprobe -r ti_am65_cpsw_nuss  [  103.045726] ------------[ cut here ]------------ [  103.050505] k3_knav_desc_pool size 512000 != avail 64000 [  103.050703] WARNING: CPU: 1 PID: 450 at drivers/net/ethernet/ti/k3-cppi-desc-pool.c:33 k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool] [  103.068810] Modules linked in: ti_am65_cpsw_nuss(-) k3_cppi_desc_pool snd_soc_hdmi_codec crct10dif_ce snd_soc_simple_card snd_soc_simple_card_utils display_connector rtc_ti_k3 k3_j72xx_bandgap tidss drm_client_lib snd_soc_davinci_mcas p drm_dma_helper tps6598x phylink snd_soc_ti_udma rti_wdt drm_display_helper snd_soc_tlv320aic3x_i2c typec at24 phy_gmii_sel snd_soc_ti_edma snd_soc_tlv320aic3x sii902x snd_soc_ti_sdma sa2ul omap_mailbox drm_kms_helper authenc cfg80211 r fkill fuse drm drm_panel_orientation_quirks backlight ip_tables x_tables ipv6 [last unloaded: k3_cppi_desc_pool] [  103.119950] CPU: 1 UID: 0 PID: 450 Comm: modprobe Not tainted 6.13.0-rc7-00001-g9c5e3435fa66 #1011 [  103.119968] Hardware name: Texas Instruments AM625 SK (DT) [  103.119974] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [  103.119983] pc : k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool] [  103.148007] lr : k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool] [  103.154709] sp : ffff8000826ebbc0 [  103.158015] x29: ffff8000826ebbc0 x28: ffff0000090b6300 x27: 0000000000000000 [  103.165145] x26: 0000000000000000 x25: 0000000000000000 x24: ffff0000019df6b0 [  103.172271] x23: ffff0000019df6b8 x22: ffff0000019df410 x21: ffff8000826ebc88 [  103.179397] x20: 000000000007d000 x19: ffff00000a3b3000 x18: 0000000000000000 [  103.186522] x17: 0000000000000000 x16: 0000000000000000 x15: 000001e8c35e1cde [  103.193647] x14: 0000000000000396 x13: 000000000000035c x12: 0000000000000000 [  103.200772] x11: 000000000000003a x10: 00000000000009c0 x9 : ffff8000826eba20 [  103.207897] x8 : ffff0000090b6d20 x7 : ffff00007728c180 x6 : ffff00007728c100 [  103.215022] x5 : 0000000000000001 x4 : ffff000000508a50 x3 : ffff7ffff6146000 [  103.222147] x2 : 0000000000000000 x1 : e300b4173ee6b200 x0 : 0000000000000000 [  103.229274] Call trace: [  103.231714]  k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool] (P) [  103.238408]  am65_cpsw_nuss_free_rx_chns+0x28/0x4c [ti_am65_cpsw_nuss] [  103.244942]  devm_action_release+0x14/0x20 [  103.249040]  release_nodes+0x3c/0x68 [  103.252610]  devres_release_all+0x8c/0xdc [  103.256614]  device_unbind_cleanup+0x18/0x60 [  103.260876]  device_release_driver_internal+0xf8/0x178 [  103.266004]  driver_detach+0x50/0x9c [  103.269571]  bus_remove_driver+0x6c/0xbc [  103.273485]  driver_unregister+0x30/0x60 [  103.277401]  platform_driver_unregister+0x14/0x20 [  103.282096]  am65_cpsw_nuss_driver_exit+0x18/0xff4 [ti_am65_cpsw_nuss] [  103.288620]  __arm64_sys_delete_module+0x17c/0x25c [  103.293404]  invoke_syscall+0x44/0x100 [  103.297149]  el0_svc_common.constprop.0+0xc0/0xe0 [  103.301845]  do_el0_svc+0x1c/0x28 [  103.305155]  el0_svc+0x28/0x98 ---truncated---

CVE-2025-38045:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: iwlwifi: fix debug actions order  The order of actions taken for debug was implemented incorrectly. Now we implemented the dump split and do the FW reset only in the middle of the dump (rather than the FW killing itself on error.) As a result, some of the actions taken when applying the config will now crash the device, so we need to fix the order.

CVE-2025-38059:

        In the Linux kernel, the following vulnerability has been resolved:  btrfs: avoid NULL pointer dereference if no valid csum tree  [BUG] When trying read-only scrub on a btrfs with rescue=idatacsums mount option, it will crash with the following call trace:    BUG: kernel NULL pointer dereference, address: 0000000000000208   #PF: supervisor read access in kernel mode   #PF: error_code(0x0000) - not-present page   CPU: 1 UID: 0 PID: 835 Comm: btrfs Tainted: G           O        6.15.0-rc3-custom+ #236 PREEMPT(full)   Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022   RIP: 0010:btrfs_lookup_csums_bitmap+0x49/0x480 [btrfs]   Call Trace:    <TASK>    scrub_find_fill_first_stripe+0x35b/0x3d0 [btrfs]    scrub_simple_mirror+0x175/0x290 [btrfs]    scrub_stripe+0x5f7/0x6f0 [btrfs]    scrub_chunk+0x9a/0x150 [btrfs]    scrub_enumerate_chunks+0x333/0x660 [btrfs]    btrfs_scrub_dev+0x23e/0x600 [btrfs]    btrfs_ioctl+0x1dcf/0x2f80 [btrfs]    __x64_sys_ioctl+0x97/0xc0    do_syscall_64+0x4f/0x120    entry_SYSCALL_64_after_hwframe+0x76/0x7e  [CAUSE] Mount option "rescue=idatacsums" will completely skip loading the csum tree, so that any data read will not find any data csum thus we will ignore data checksum verification.  Normally call sites utilizing csum tree will check the fs state flag NO_DATA_CSUMS bit, but unfortunately scrub does not check that bit at all.  This results in scrub to call btrfs_search_slot() on a NULL pointer and triggered above crash.  [FIX] Check both extent and csum tree root before doing any tree search.

CVE-2025-38064:

        In the Linux kernel, the following vulnerability has been resolved:  virtio: break and reset virtio devices on device_shutdown()  Hongyu reported a hang on kexec in a VM. QEMU reported invalid memory accesses during the hang.  	Invalid read at addr 0x102877002, size 2, region '(null)', reason: rejected 	Invalid write at addr 0x102877A44, size 2, region '(null)', reason: rejected 	...  It was traced down to virtio-console. Kexec works fine if virtio-console is not in use.  The issue is that virtio-console continues to write to the MMIO even after underlying virtio-pci device is reset.  Additionally, Eric noticed that IOMMUs are reset before devices, if devices are not reset on shutdown they continue to poke at guest memory and get errors from the IOMMU. Some devices get wedged then.  The problem can be solved by breaking all virtio devices on virtio bus shutdown, then resetting them.

CVE-2025-38069:

        In the Linux kernel, the following vulnerability has been resolved:  PCI: endpoint: pci-epf-test: Fix double free that causes kernel to oops  Fix a kernel oops found while testing the stm32_pcie Endpoint driver with handling of PERST# deassertion:  During EP initialization, pci_epf_test_alloc_space() allocates all BARs, which are further freed if epc_set_bar() fails (for instance, due to no free inbound window).  However, when pci_epc_set_bar() fails, the error path:    pci_epc_set_bar() ->     pci_epf_free_space()  does not clear the previous assignment to epf_test->reg[bar].  Then, if the host reboots, the PERST# deassertion restarts the BAR allocation sequence with the same allocation failure (no free inbound window), creating a double free situation since epf_test->reg[bar] was deallocated and is still non-NULL.  Thus, make sure that pci_epf_alloc_space() and pci_epf_free_space() invocations are symmetric, and as such, set epf_test->reg[bar] to NULL when memory is freed.  [kwilczynski: commit log]

CVE-2025-38080:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Increase block_sequence array size  [Why] It's possible to generate more than 50 steps in hwss_build_fast_sequence, for example with a 6-pipe asic where all pipes are in one MPC chain. This overflows the block_sequence buffer and corrupts block_sequence_steps, causing a crash.  [How] Expand block_sequence to 100 items. A naive upper bound on the possible number of steps for a 6-pipe asic, ignoring the potential for steps to be mutually exclusive, is 91 with current code, therefore 100 is sufficient.

CVE-2025-38081:

        In the Linux kernel, the following vulnerability has been resolved:  spi-rockchip: Fix register out of bounds access  Do not write native chip select stuff for GPIO chip selects. GPIOs can be numbered much higher than native CS. Also, it makes no sense.

CVE-2025-38096:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: iwlwifi: don't warn when if there is a FW error  iwl_trans_reclaim is warning if it is called when the FW is not alive. But if it is called when there is a pending restart, i.e. after a FW error, there is no need to warn, instead - return silently.

CVE-2025-38127:

        In the Linux kernel, the following vulnerability has been resolved:  ice: fix Tx scheduler error handling in XDP callback  When the XDP program is loaded, the XDP callback adds new Tx queues. This means that the callback must update the Tx scheduler with the new queue number. In the event of a Tx scheduler failure, the XDP callback should also fail and roll back any changes previously made for XDP preparation.  The previous implementation had a bug that not all changes made by the XDP callback were rolled back. This caused the crash with the following call trace:  [  +9.549584] ice 0000:ca:00.0: Failed VSI LAN queue config for XDP, error: -5 [  +0.382335] Oops: general protection fault, probably for non-canonical address 0x50a2250a90495525: 0000 [#1] SMP NOPTI [  +0.010710] CPU: 103 UID: 0 PID: 0 Comm: swapper/103 Not tainted 6.14.0-net-next-mar-31+ #14 PREEMPT(voluntary) [  +0.010175] Hardware name: Intel Corporation M50CYP2SBSTD/M50CYP2SBSTD, BIOS SE5C620.86B.01.01.0005.2202160810 02/16/2022 [  +0.010946] RIP: 0010:__ice_update_sample+0x39/0xe0 [ice]  [...]  [  +0.002715] Call Trace: [  +0.002452]  <IRQ> [  +0.002021]  ? __die_body.cold+0x19/0x29 [  +0.003922]  ? die_addr+0x3c/0x60 [  +0.003319]  ? exc_general_protection+0x17c/0x400 [  +0.004707]  ? asm_exc_general_protection+0x26/0x30 [  +0.004879]  ? __ice_update_sample+0x39/0xe0 [ice] [  +0.004835]  ice_napi_poll+0x665/0x680 [ice] [  +0.004320]  __napi_poll+0x28/0x190 [  +0.003500]  net_rx_action+0x198/0x360 [  +0.003752]  ? update_rq_clock+0x39/0x220 [  +0.004013]  handle_softirqs+0xf1/0x340 [  +0.003840]  ? sched_clock_cpu+0xf/0x1f0 [  +0.003925]  __irq_exit_rcu+0xc2/0xe0 [  +0.003665]  common_interrupt+0x85/0xa0 [  +0.003839]  </IRQ> [  +0.002098]  <TASK> [  +0.002106]  asm_common_interrupt+0x26/0x40 [  +0.004184] RIP: 0010:cpuidle_enter_state+0xd3/0x690  Fix this by performing the missing unmapping of XDP queues from q_vectors and setting the XDP rings pointer back to NULL after all those queues are released. Also, add an immediate exit from the XDP callback in case of ring preparation failure.

CVE-2025-38132:

        In the Linux kernel, the following vulnerability has been resolved:  coresight: holding cscfg_csdev_lock while removing cscfg from csdev  There'll be possible race scenario for coresight config:  CPU0                                          CPU1 (perf enable)                                 load module                                               cscfg_load_config_sets()                                               activate config. // sysfs                                               (sys_active_cnt == 1) ... cscfg_csdev_enable_active_config()   lock(csdev->cscfg_csdev_lock)                                               deactivate config // sysfs                                               (sys_activec_cnt == 0)                                               cscfg_unload_config_sets()   <iterating config_csdev_list>               cscfg_remove_owned_csdev_configs()   // here load config activate by CPU1   unlock(csdev->cscfg_csdev_lock)  iterating config_csdev_list could be raced with config_csdev_list's entry delete.  To resolve this race , hold csdev->cscfg_csdev_lock() while cscfg_remove_owned_csdev_configs()

CVE-2025-38140:

        In the Linux kernel, the following vulnerability has been resolved:  dm: limit swapping tables for devices with zone write plugs  dm_revalidate_zones() only allowed new or previously unzoned devices to call blk_revalidate_disk_zones(). If the device was already zoned, disk->nr_zones would always equal md->nr_zones, so dm_revalidate_zones() returned without doing any work. This would make the zoned settings for the device not match the new table. If the device had zone write plug resources, it could run into errors like bdev_zone_is_seq() reading invalid memory because disk->conv_zones_bitmap was the wrong size.  If the device doesn't have any zone write plug resources, calling blk_revalidate_disk_zones() will always correctly update device.  If blk_revalidate_disk_zones() fails, it can still overwrite or clear the current disk->nr_zones value. In this case, DM must restore the previous value of disk->nr_zones, so that the zoned settings will continue to match the previous value that it fell back to.  If the device already has zone write plug resources, blk_revalidate_disk_zones() will not correctly update them, if it is called for arbitrary zoned device changes.  Since there is not much need for this ability, the easiest solution is to disallow any table reloads that change the zoned settings, for devices that already have zone plug resources.  Specifically, if a device already has zone plug resources allocated, it can only switch to another zoned table that also emulates zone append.  Also, it cannot change the device size or the zone size. A device can switch to an error target.

CVE-2025-38182:

        In the Linux kernel, the following vulnerability has been resolved:  ublk: santizize the arguments from userspace when adding a device  Sanity check the values for queue depth and number of queues we get from userspace when adding a device.

CVE-2025-38195:

        In the Linux kernel, the following vulnerability has been resolved:  LoongArch: Fix panic caused by NULL-PMD in huge_pte_offset()  ERROR INFO:  CPU 25 Unable to handle kernel paging request at virtual address 0x0          ...  Call Trace:  [<900000000023c30c>] huge_pte_offset+0x3c/0x58  [<900000000057fd4c>] hugetlb_follow_page_mask+0x74/0x438  [<900000000051fee8>] __get_user_pages+0xe0/0x4c8  [<9000000000522414>] faultin_page_range+0x84/0x380  [<9000000000564e8c>] madvise_vma_behavior+0x534/0xa48  [<900000000056689c>] do_madvise+0x1bc/0x3e8  [<9000000000566df4>] sys_madvise+0x24/0x38  [<90000000015b9e88>] do_syscall+0x78/0x98  [<9000000000221f18>] handle_syscall+0xb8/0x158  In some cases, pmd may be NULL and rely on NULL as the return value for processing, so it is necessary to determine this situation here.

CVE-2025-38204:

        In the Linux kernel, the following vulnerability has been resolved:  jfs: fix array-index-out-of-bounds read in add_missing_indices  stbl is s8 but it must contain offsets into slot which can go from 0 to 127.  Added a bound check for that error and return -EIO if the check fails. Also make jfs_readdir return with error if add_missing_indices returns with an error.

CVE-2025-38207:

        In the Linux kernel, the following vulnerability has been resolved:  mm: fix uprobe pte be overwritten when expanding vma  Patch series "Fix uprobe pte be overwritten when expanding vma".   This patch (of 4):  We encountered a BUG alert triggered by Syzkaller as follows:    BUG: Bad rss-counter state mm:00000000b4a60fca type:MM_ANONPAGES val:1  And we can reproduce it with the following steps: 1. register uprobe on file at zero offset 2. mmap the file at zero offset:    addr1 = mmap(NULL, 2 * 4096, PROT_NONE, MAP_PRIVATE, fd, 0); 3. mremap part of vma1 to new vma2:    addr2 = mremap(addr1, 4096, 2 * 4096, MREMAP_MAYMOVE); 4. mremap back to orig addr1:    mremap(addr2, 4096, 4096, MREMAP_MAYMOVE | MREMAP_FIXED, addr1);  In step 3, the vma1 range [addr1, addr1 + 4096] will be remap to new vma2 with range [addr2, addr2 + 8192], and remap uprobe anon page from the vma1 to vma2, then unmap the vma1 range [addr1, addr1 + 4096].  In step 4, the vma2 range [addr2, addr2 + 4096] will be remap back to the addr range [addr1, addr1 + 4096].  Since the addr range [addr1 + 4096, addr1 + 8192] still maps the file, it will take vma_merge_new_range to expand the range, and then do uprobe_mmap in vma_complete.  Since the merged vma pgoff is also zero offset, it will install uprobe anon page to the merged vma.  However, the upcomming move_page_tables step, which use set_pte_at to remap the vma2 uprobe pte to the merged vma, will overwrite the newly uprobe pte in the merged vma, and lead that pte to be orphan.  Since the uprobe pte will be remapped to the merged vma, we can remove the unnecessary uprobe_mmap upon merged vma.  This problem was first found in linux-6.6.y and also exists in the community syzkaller: https://lore.kernel.org/all/000000000000ada39605a5e71711@google.com/T/

CVE-2025-38234:

        In the Linux kernel, the following vulnerability has been resolved:  sched/rt: Fix race in push_rt_task  Overview ======== When a CPU chooses to call push_rt_task and picks a task to push to another CPU's runqueue then it will call find_lock_lowest_rq method which would take a double lock on both CPUs' runqueues. If one of the locks aren't readily available, it may lead to dropping the current runqueue lock and reacquiring both the locks at once. During this window it is possible that the task is already migrated and is running on some other CPU. These cases are already handled. However, if the task is migrated and has already been executed and another CPU is now trying to wake it up (ttwu) such that it is queued again on the runqeue (on_rq is 1) and also if the task was run by the same CPU, then the current checks will pass even though the task was migrated out and is no longer in the pushable tasks list.  Crashes ======= This bug resulted in quite a few flavors of crashes triggering kernel panics with various crash signatures such as assert failures, page faults, null pointer dereferences, and queue corruption errors all coming from scheduler itself.  Some of the crashes: -> kernel BUG at kernel/sched/rt.c:1616! BUG_ON(idx >= MAX_RT_PRIO)    Call Trace:    ? __die_body+0x1a/0x60    ? die+0x2a/0x50    ? do_trap+0x85/0x100    ? pick_next_task_rt+0x6e/0x1d0    ? do_error_trap+0x64/0xa0    ? pick_next_task_rt+0x6e/0x1d0    ? exc_invalid_op+0x4c/0x60    ? pick_next_task_rt+0x6e/0x1d0    ? asm_exc_invalid_op+0x12/0x20    ? pick_next_task_rt+0x6e/0x1d0    __schedule+0x5cb/0x790    ? update_ts_time_stats+0x55/0x70    schedule_idle+0x1e/0x40    do_idle+0x15e/0x200    cpu_startup_entry+0x19/0x20    start_secondary+0x117/0x160    secondary_startup_64_no_verify+0xb0/0xbb  -> BUG: kernel NULL pointer dereference, address: 00000000000000c0    Call Trace:    ? __die_body+0x1a/0x60    ? no_context+0x183/0x350    ? __warn+0x8a/0xe0    ? exc_page_fault+0x3d6/0x520    ? asm_exc_page_fault+0x1e/0x30    ? pick_next_task_rt+0xb5/0x1d0    ? pick_next_task_rt+0x8c/0x1d0    __schedule+0x583/0x7e0    ? update_ts_time_stats+0x55/0x70    schedule_idle+0x1e/0x40    do_idle+0x15e/0x200    cpu_startup_entry+0x19/0x20    start_secondary+0x117/0x160    secondary_startup_64_no_verify+0xb0/0xbb  -> BUG: unable to handle page fault for address: ffff9464daea5900    kernel BUG at kernel/sched/rt.c:1861! BUG_ON(rq->cpu != task_cpu(p))  -> kernel BUG at kernel/sched/rt.c:1055! BUG_ON(!rq->nr_running)    Call Trace:    ? __die_body+0x1a/0x60    ? die+0x2a/0x50    ? do_trap+0x85/0x100    ? dequeue_top_rt_rq+0xa2/0xb0    ? do_error_trap+0x64/0xa0    ? dequeue_top_rt_rq+0xa2/0xb0    ? exc_invalid_op+0x4c/0x60    ? dequeue_top_rt_rq+0xa2/0xb0    ? asm_exc_invalid_op+0x12/0x20    ? dequeue_top_rt_rq+0xa2/0xb0    dequeue_rt_entity+0x1f/0x70    dequeue_task_rt+0x2d/0x70    __schedule+0x1a8/0x7e0    ? blk_finish_plug+0x25/0x40    schedule+0x3c/0xb0    futex_wait_queue_me+0xb6/0x120    futex_wait+0xd9/0x240    do_futex+0x344/0xa90    ? get_mm_exe_file+0x30/0x60    ? audit_exe_compare+0x58/0x70    ? audit_filter_rules.constprop.26+0x65e/0x1220    __x64_sys_futex+0x148/0x1f0    do_syscall_64+0x30/0x80    entry_SYSCALL_64_after_hwframe+0x62/0xc7  -> BUG: unable to handle page fault for address: ffff8cf3608bc2c0    Call Trace:    ? __die_body+0x1a/0x60    ? no_context+0x183/0x350    ? spurious_kernel_fault+0x171/0x1c0    ? exc_page_fault+0x3b6/0x520    ? plist_check_list+0x15/0x40    ? plist_check_list+0x2e/0x40    ? asm_exc_page_fault+0x1e/0x30    ? _cond_resched+0x15/0x30    ? futex_wait_queue_me+0xc8/0x120    ? futex_wait+0xd9/0x240    ? try_to_wake_up+0x1b8/0x490    ? futex_wake+0x78/0x160    ? do_futex+0xcd/0xa90    ? plist_check_list+0x15/0x40    ? plist_check_list+0x2e/0x40    ? plist_del+0x6a/0xd0    ? plist_check_list+0x15/0x40    ? plist_check_list+0x2e/0x40    ? dequeue_pushable_task+0x20/0x70    ? __schedule+0x382/0x7e0    ? asm_sysvec_reschedule_i ---truncated---

CVE-2025-38244:

        In the Linux kernel, the following vulnerability has been resolved:  smb: client: fix potential deadlock when reconnecting channels  Fix cifs_signal_cifsd_for_reconnect() to take the correct lock order and prevent the following deadlock from happening  ====================================================== WARNING: possible circular locking dependency detected 6.16.0-rc3-build2+ #1301 Tainted: G S      W ------------------------------------------------------ cifsd/6055 is trying to acquire lock: ffff88810ad56038 (&tcp_ses->srv_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x134/0x200  but task is already holding lock: ffff888119c64330 (&ret_buf->chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200  which lock already depends on the new lock.  the existing dependency chain (in reverse order) is:  -> #2 (&ret_buf->chan_lock){+.+.}-{3:3}:        validate_chain+0x1cf/0x270        __lock_acquire+0x60e/0x780        lock_acquire.part.0+0xb4/0x1f0        _raw_spin_lock+0x2f/0x40        cifs_setup_session+0x81/0x4b0        cifs_get_smb_ses+0x771/0x900        cifs_mount_get_session+0x7e/0x170        cifs_mount+0x92/0x2d0        cifs_smb3_do_mount+0x161/0x460        smb3_get_tree+0x55/0x90        vfs_get_tree+0x46/0x180        do_new_mount+0x1b0/0x2e0        path_mount+0x6ee/0x740        do_mount+0x98/0xe0        __do_sys_mount+0x148/0x180        do_syscall_64+0xa4/0x260        entry_SYSCALL_64_after_hwframe+0x76/0x7e  -> #1 (&ret_buf->ses_lock){+.+.}-{3:3}:        validate_chain+0x1cf/0x270        __lock_acquire+0x60e/0x780        lock_acquire.part.0+0xb4/0x1f0        _raw_spin_lock+0x2f/0x40        cifs_match_super+0x101/0x320        sget+0xab/0x270        cifs_smb3_do_mount+0x1e0/0x460        smb3_get_tree+0x55/0x90        vfs_get_tree+0x46/0x180        do_new_mount+0x1b0/0x2e0        path_mount+0x6ee/0x740        do_mount+0x98/0xe0        __do_sys_mount+0x148/0x180        do_syscall_64+0xa4/0x260        entry_SYSCALL_64_after_hwframe+0x76/0x7e  -> #0 (&tcp_ses->srv_lock){+.+.}-{3:3}:        check_noncircular+0x95/0xc0        check_prev_add+0x115/0x2f0        validate_chain+0x1cf/0x270        __lock_acquire+0x60e/0x780        lock_acquire.part.0+0xb4/0x1f0        _raw_spin_lock+0x2f/0x40        cifs_signal_cifsd_for_reconnect+0x134/0x200        __cifs_reconnect+0x8f/0x500        cifs_handle_standard+0x112/0x280        cifs_demultiplex_thread+0x64d/0xbc0        kthread+0x2f7/0x310        ret_from_fork+0x2a/0x230        ret_from_fork_asm+0x1a/0x30  other info that might help us debug this:  Chain exists of:   &tcp_ses->srv_lock --> &ret_buf->ses_lock --> &ret_buf->chan_lock   Possible unsafe locking scenario:         CPU0                    CPU1        ----                    ----   lock(&ret_buf->chan_lock);                                lock(&ret_buf->ses_lock);                                lock(&ret_buf->chan_lock);   lock(&tcp_ses->srv_lock);   *** DEADLOCK ***  3 locks held by cifsd/6055:  #0: ffffffff857de398 (&cifs_tcp_ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x7b/0x200  #1: ffff888119c64060 (&ret_buf->ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x9c/0x200  #2: ffff888119c64330 (&ret_buf->chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200

CVE-2025-38246:

        In the Linux kernel, the following vulnerability has been resolved:  bnxt: properly flush XDP redirect lists  We encountered following crash when testing a XDP_REDIRECT feature in production:  [56251.579676] list_add corruption. next->prev should be prev (ffff93120dd40f30), but was ffffb301ef3a6740. (next=ffff93120dd 40f30). [56251.601413] ------------[ cut here ]------------ [56251.611357] kernel BUG at lib/list_debug.c:29! [56251.621082] Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [56251.632073] CPU: 111 UID: 0 PID: 0 Comm: swapper/111 Kdump: loaded Tainted: P           O       6.12.33-cloudflare-2025.6. 3 #1 [56251.653155] Tainted: [P]=PROPRIETARY_MODULE, [O]=OOT_MODULE [56251.663877] Hardware name: MiTAC GC68B-B8032-G11P6-GPU/S8032GM-HE-CFR, BIOS V7.020.B10-sig 01/22/2025 [56251.682626] RIP: 0010:__list_add_valid_or_report+0x4b/0xa0 [56251.693203] Code: 0e 48 c7 c7 68 e7 d9 97 e8 42 16 fe ff 0f 0b 48 8b 52 08 48 39 c2 74 14 48 89 f1 48 c7 c7 90 e7 d9 97 48  89 c6 e8 25 16 fe ff <0f> 0b 4c 8b 02 49 39 f0 74 14 48 89 d1 48 c7 c7 e8 e7 d9 97 4c 89 [56251.725811] RSP: 0018:ffff93120dd40b80 EFLAGS: 00010246 [56251.736094] RAX: 0000000000000075 RBX: ffffb301e6bba9d8 RCX: 0000000000000000 [56251.748260] RDX: 0000000000000000 RSI: ffff9149afda0b80 RDI: ffff9149afda0b80 [56251.760349] RBP: ffff9131e49c8000 R08: 0000000000000000 R09: ffff93120dd40a18 [56251.772382] R10: ffff9159cf2ce1a8 R11: 0000000000000003 R12: ffff911a80850000 [56251.784364] R13: ffff93120fbc7000 R14: 0000000000000010 R15: ffff9139e7510e40 [56251.796278] FS:  0000000000000000(0000) GS:ffff9149afd80000(0000) knlGS:0000000000000000 [56251.809133] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [56251.819561] CR2: 00007f5e85e6f300 CR3: 00000038b85e2006 CR4: 0000000000770ef0 [56251.831365] PKRU: 55555554 [56251.838653] Call Trace: [56251.845560]  <IRQ> [56251.851943]  cpu_map_enqueue.cold+0x5/0xa [56251.860243]  xdp_do_redirect+0x2d9/0x480 [56251.868388]  bnxt_rx_xdp+0x1d8/0x4c0 [bnxt_en] [56251.877028]  bnxt_rx_pkt+0x5f7/0x19b0 [bnxt_en] [56251.885665]  ? cpu_max_write+0x1e/0x100 [56251.893510]  ? srso_alias_return_thunk+0x5/0xfbef5 [56251.902276]  __bnxt_poll_work+0x190/0x340 [bnxt_en] [56251.911058]  bnxt_poll+0xab/0x1b0 [bnxt_en] [56251.919041]  ? srso_alias_return_thunk+0x5/0xfbef5 [56251.927568]  ? srso_alias_return_thunk+0x5/0xfbef5 [56251.935958]  ? srso_alias_return_thunk+0x5/0xfbef5 [56251.944250]  __napi_poll+0x2b/0x160 [56251.951155]  bpf_trampoline_6442548651+0x79/0x123 [56251.959262]  __napi_poll+0x5/0x160 [56251.966037]  net_rx_action+0x3d2/0x880 [56251.973133]  ? srso_alias_return_thunk+0x5/0xfbef5 [56251.981265]  ? srso_alias_return_thunk+0x5/0xfbef5 [56251.989262]  ? __hrtimer_run_queues+0x162/0x2a0 [56251.996967]  ? srso_alias_return_thunk+0x5/0xfbef5 [56252.004875]  ? srso_alias_return_thunk+0x5/0xfbef5 [56252.012673]  ? bnxt_msix+0x62/0x70 [bnxt_en] [56252.019903]  handle_softirqs+0xcf/0x270 [56252.026650]  irq_exit_rcu+0x67/0x90 [56252.032933]  common_interrupt+0x85/0xa0 [56252.039498]  </IRQ> [56252.044246]  <TASK> [56252.048935]  asm_common_interrupt+0x26/0x40 [56252.055727] RIP: 0010:cpuidle_enter_state+0xb8/0x420 [56252.063305] Code: dc 01 00 00 e8 f9 79 3b ff e8 64 f7 ff ff 49 89 c5 0f 1f 44 00 00 31 ff e8 a5 32 3a ff 45 84 ff 0f 85 ae  01 00 00 fb 45 85 f6 <0f> 88 88 01 00 00 48 8b 04 24 49 63 ce 4c 89 ea 48 6b f1 68 48 29 [56252.088911] RSP: 0018:ffff93120c97fe98 EFLAGS: 00000202 [56252.096912] RAX: ffff9149afd80000 RBX: ffff9141d3a72800 RCX: 0000000000000000 [56252.106844] RDX: 00003329176c6b98 RSI: ffffffe36db3fdc7 RDI: 0000000000000000 [56252.116733] RBP: 0000000000000002 R08: 0000000000000002 R09: 000000000000004e [56252.126652] R10: ffff9149afdb30c4 R11: 071c71c71c71c71c R12: ffffffff985ff860 [56252.136637] R13: 00003329176c6b98 R14: 0000000000000002 R15: 0000000000000000 [56252.146667]  ? cpuidle_enter_state+0xab/0x420 [56252.153909]  cpuidle_enter+0x2d/0x40 [56252.160360]  do_idle+0x176/0x1c0 [56252.166456 ---truncated---

CVE-2025-38248:

        In the Linux kernel, the following vulnerability has been resolved:  bridge: mcast: Fix use-after-free during router port configuration  The bridge maintains a global list of ports behind which a multicast router resides. The list is consulted during forwarding to ensure multicast packets are forwarded to these ports even if the ports are not member in the matching MDB entry.  When per-VLAN multicast snooping is enabled, the per-port multicast context is disabled on each port and the port is removed from the global router port list:   # ip link add name br1 up type bridge vlan_filtering 1 mcast_snooping 1  # ip link add name dummy1 up master br1 type dummy  # ip link set dev dummy1 type bridge_slave mcast_router 2  $ bridge -d mdb show | grep router  router ports on br1: dummy1  # ip link set dev br1 type bridge mcast_vlan_snooping 1  $ bridge -d mdb show | grep router  However, the port can be re-added to the global list even when per-VLAN multicast snooping is enabled:   # ip link set dev dummy1 type bridge_slave mcast_router 0  # ip link set dev dummy1 type bridge_slave mcast_router 2  $ bridge -d mdb show | grep router  router ports on br1: dummy1  Since commit 4b30ae9adb04 ("net: bridge: mcast: re-implement br_multicast_{enable, disable}_port functions"), when per-VLAN multicast snooping is enabled, multicast disablement on a port will disable the per-{port, VLAN} multicast contexts and not the per-port one. As a result, a port will remain in the global router port list even after it is deleted. This will lead to a use-after-free [1] when the list is traversed (when adding a new port to the list, for example):   # ip link del dev dummy1  # ip link add name dummy2 up master br1 type dummy  # ip link set dev dummy2 type bridge_slave mcast_router 2  Similarly, stale entries can also be found in the per-VLAN router port list. When per-VLAN multicast snooping is disabled, the per-{port, VLAN} contexts are disabled on each port and the port is removed from the per-VLAN router port list:   # ip link add name br1 up type bridge vlan_filtering 1 mcast_snooping 1 mcast_vlan_snooping 1  # ip link add name dummy1 up master br1 type dummy  # bridge vlan add vid 2 dev dummy1  # bridge vlan global set vid 2 dev br1 mcast_snooping 1  # bridge vlan set vid 2 dev dummy1 mcast_router 2  $ bridge vlan global show dev br1 vid 2 | grep router        router ports: dummy1  # ip link set dev br1 type bridge mcast_vlan_snooping 0  $ bridge vlan global show dev br1 vid 2 | grep router  However, the port can be re-added to the per-VLAN list even when per-VLAN multicast snooping is disabled:   # bridge vlan set vid 2 dev dummy1 mcast_router 0  # bridge vlan set vid 2 dev dummy1 mcast_router 2  $ bridge vlan global show dev br1 vid 2 | grep router        router ports: dummy1  When the VLAN is deleted from the port, the per-{port, VLAN} multicast context will not be disabled since multicast snooping is not enabled on the VLAN. As a result, the port will remain in the per-VLAN router port list even after it is no longer member in the VLAN. This will lead to a use-after-free [2] when the list is traversed (when adding a new port to the list, for example):   # ip link add name dummy2 up master br1 type dummy  # bridge vlan add vid 2 dev dummy2  # bridge vlan del vid 2 dev dummy1  # bridge vlan set vid 2 dev dummy2 mcast_router 2  Fix these issues by removing the port from the relevant (global or per-VLAN) router port list in br_multicast_port_ctx_deinit(). The function is invoked during port deletion with the per-port multicast context and during VLAN deletion with the per-{port, VLAN} multicast context.  Note that deleting the multicast router timer is not enough as it only takes care of the temporary multicast router states (1 or 3) and not the permanent one (2).  [1] BUG: KASAN: slab-out-of-bounds in br_multicast_add_router.part.0+0x3f1/0x560 Write of size 8 at addr ffff888004a67328 by task ip/384 [...] Call Trace:  <TASK>  dump_stack ---truncated---

CVE-2025-38261:

        In the Linux kernel, the following vulnerability has been resolved:  riscv: save the SR_SUM status over switches  When threads/tasks are switched we need to ensure the old execution's SR_SUM state is saved and the new thread has the old SR_SUM state restored.  The issue was seen under heavy load especially with the syz-stress tool running, with crashes as follows in schedule_tail:  Unable to handle kernel access to user memory without uaccess routines at virtual address 000000002749f0d0 Oops [#1] Modules linked in: CPU: 1 PID: 4875 Comm: syz-executor.0 Not tainted 5.12.0-rc2-syzkaller-00467-g0d7588ab9ef9 #0 Hardware name: riscv-virtio,qemu (DT) epc : schedule_tail+0x72/0xb2 kernel/sched/core.c:4264  ra : task_pid_vnr include/linux/sched.h:1421 [inline]  ra : schedule_tail+0x70/0xb2 kernel/sched/core.c:4264 epc : ffffffe00008c8b0 ra : ffffffe00008c8ae sp : ffffffe025d17ec0  gp : ffffffe005d25378 tp : ffffffe00f0d0000 t0 : 0000000000000000  t1 : 0000000000000001 t2 : 00000000000f4240 s0 : ffffffe025d17ee0  s1 : 000000002749f0d0 a0 : 000000000000002a a1 : 0000000000000003  a2 : 1ffffffc0cfac500 a3 : ffffffe0000c80cc a4 : 5ae9db91c19bbe00  a5 : 0000000000000000 a6 : 0000000000f00000 a7 : ffffffe000082eba  s2 : 0000000000040000 s3 : ffffffe00eef96c0 s4 : ffffffe022c77fe0  s5 : 0000000000004000 s6 : ffffffe067d74e00 s7 : ffffffe067d74850  s8 : ffffffe067d73e18 s9 : ffffffe067d74e00 s10: ffffffe00eef96e8  s11: 000000ae6cdf8368 t3 : 5ae9db91c19bbe00 t4 : ffffffc4043cafb2  t5 : ffffffc4043cafba t6 : 0000000000040000 status: 0000000000000120 badaddr: 000000002749f0d0 cause: 000000000000000f Call Trace: [<ffffffe00008c8b0>] schedule_tail+0x72/0xb2 kernel/sched/core.c:4264 [<ffffffe000005570>] ret_from_exception+0x0/0x14 Dumping ftrace buffer:    (ftrace buffer empty) ---[ end trace b5f8f9231dc87dda ]---  The issue comes from the put_user() in schedule_tail (kernel/sched/core.c) doing the following:  asmlinkage __visible void schedule_tail(struct task_struct *prev) { ...         if (current->set_child_tid)                 put_user(task_pid_vnr(current), current->set_child_tid); ... }  the put_user() macro causes the code sequence to come out as follows:  1:	__enable_user_access() 2:	reg = task_pid_vnr(current); 3:	*current->set_child_tid = reg; 4:	__disable_user_access()  The problem is that we may have a sleeping function as argument which could clear SR_SUM causing the panic above. This was fixed by evaluating the argument of the put_user() macro outside the user-enabled section in commit 285a76bb2cf5 ("riscv: evaluate put_user() arg before enabling user access")"  In order for riscv to take advantage of unsafe_get/put_XXX() macros and to avoid the same issue we had with put_user() and sleeping functions we must ensure code flow can go through switch_to() from within a region of code with SR_SUM enabled and come back with SR_SUM still enabled. This patch addresses the problem allowing future work to enable full use of unsafe_get/put_XXX() macros without needing to take a CSR bit flip cost on every access. Make switch_to() save and restore SR_SUM.

CVE-2025-38264:

        In the Linux kernel, the following vulnerability has been resolved:  nvme-tcp: sanitize request list handling  Validate the request in nvme_tcp_handle_r2t() to ensure it's not part of any list, otherwise a malicious R2T PDU might inject a loop in request list processing.

CVE-2025-38272:

        In the Linux kernel, the following vulnerability has been resolved:  net: dsa: b53: do not enable EEE on bcm63xx  BCM63xx internal switches do not support EEE, but provide multiple RGMII ports where external PHYs may be connected. If one of these PHYs are EEE capable, we may try to enable EEE for the MACs, which then hangs the system on access of the (non-existent) EEE registers.  Fix this by checking if the switch actually supports EEE before attempting to configure it.

CVE-2025-38283:

        In the Linux kernel, the following vulnerability has been resolved:  hisi_acc_vfio_pci: bugfix live migration function without VF device driver  If the VF device driver is not loaded in the Guest OS and we attempt to perform device data migration, the address of the migrated data will be NULL. The live migration recovery operation on the destination side will access a null address value, which will cause access errors.  Therefore, live migration of VMs without added VF device drivers does not require device data migration. In addition, when the queue address data obtained by the destination is empty, device queue recovery processing will not be performed.

CVE-2025-38311:

        In the Linux kernel, the following vulnerability has been resolved:  iavf: get rid of the crit lock  Get rid of the crit lock. That frees us from the error prone logic of try_locks.  Thanks to netdev_lock() by Jakub it is now easy, and in most cases we were protected by it already - replace crit lock by netdev lock when it was not the case.  Lockdep reports that we should cancel the work under crit_lock [splat1], and that was the scheme we have mostly followed since [1] by Slawomir. But when that is done we still got into deadlocks [splat2]. So instead we should look at the bigger problem, namely "weird locking/scheduling" of the iavf. The first step to fix that is to remove the crit lock. I will followup with a -next series that simplifies scheduling/tasks.  Cancel the work without netdev lock (weird unlock+lock scheme), to fix the [splat2] (which would be totally ugly if we would kept the crit lock).  Extend protected part of iavf_watchdog_task() to include scheduling more work.  Note that the removed comment in iavf_reset_task() was misplaced, it belonged to inside of the removed if condition, so it's gone now.  [splat1] - w/o this patch - The deadlock during VF removal:      WARNING: possible circular locking dependency detected      sh/3825 is trying to acquire lock:       ((work_completion)(&(&adapter->watchdog_task)->work)){+.+.}-{0:0}, at: start_flush_work+0x1a1/0x470           but task is already holding lock:       (&adapter->crit_lock){+.+.}-{4:4}, at: iavf_remove+0xd1/0x690 [iavf]           which lock already depends on the new lock.  [splat2] - when cancelling work under crit lock, w/o this series, 	   see [2] for the band aid attempt     WARNING: possible circular locking dependency detected     sh/3550 is trying to acquire lock:     ((wq_completion)iavf){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x26/0x90         but task is already holding lock:     (&dev->lock){+.+.}-{4:4}, at: iavf_remove+0xa6/0x6e0 [iavf]         which lock already depends on the new lock.  [1] fc2e6b3b132a ("iavf: Rework mutexes for better synchronisation") [2] https://github.com/pkitszel/linux/commit/52dddbfc2bb60294083f5711a158a

CVE-2025-38333:

        In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to bail out in get_new_segment()  ------------[ cut here ]------------ WARNING: CPU: 3 PID: 579 at fs/f2fs/segment.c:2832 new_curseg+0x5e8/0x6dc pc : new_curseg+0x5e8/0x6dc Call trace:  new_curseg+0x5e8/0x6dc  f2fs_allocate_data_block+0xa54/0xe28  do_write_page+0x6c/0x194  f2fs_do_write_node_page+0x38/0x78  __write_node_page+0x248/0x6d4  f2fs_sync_node_pages+0x524/0x72c  f2fs_write_checkpoint+0x4bc/0x9b0  __checkpoint_and_complete_reqs+0x80/0x244  issue_checkpoint_thread+0x8c/0xec  kthread+0x114/0x1bc  ret_from_fork+0x10/0x20  get_new_segment() detects inconsistent status in between free_segmap and free_secmap, let's record such error into super block, and bail out get_new_segment() instead of continue using the segment.

CVE-2025-38359:

        In the Linux kernel, the following vulnerability has been resolved:  s390/mm: Fix in_atomic() handling in do_secure_storage_access()  Kernel user spaces accesses to not exported pages in atomic context incorrectly try to resolve the page fault. With debug options enabled call traces like this can be seen:  BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1523 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 419074, name: qemu-system-s39 preempt_count: 1, expected: 0 RCU nest depth: 0, expected: 0 INFO: lockdep is turned off. Preemption disabled at: [<00000383ea47cfa2>] copy_page_from_iter_atomic+0xa2/0x8a0 CPU: 12 UID: 0 PID: 419074 Comm: qemu-system-s39 Tainted: G        W           6.16.0-20250531.rc0.git0.69b3a602feac.63.fc42.s390x+debug #1 PREEMPT Tainted: [W]=WARN Hardware name: IBM 3931 A01 703 (LPAR) Call Trace:  [<00000383e990d282>] dump_stack_lvl+0xa2/0xe8  [<00000383e99bf152>] __might_resched+0x292/0x2d0  [<00000383eaa7c374>] down_read+0x34/0x2d0  [<00000383e99432f8>] do_secure_storage_access+0x108/0x360  [<00000383eaa724b0>] __do_pgm_check+0x130/0x220  [<00000383eaa842e4>] pgm_check_handler+0x114/0x160  [<00000383ea47d028>] copy_page_from_iter_atomic+0x128/0x8a0 ([<00000383ea47d016>] copy_page_from_iter_atomic+0x116/0x8a0)  [<00000383e9c45eae>] generic_perform_write+0x16e/0x310  [<00000383e9eb87f4>] ext4_buffered_write_iter+0x84/0x160  [<00000383e9da0de4>] vfs_write+0x1c4/0x460  [<00000383e9da123c>] ksys_write+0x7c/0x100  [<00000383eaa7284e>] __do_syscall+0x15e/0x280  [<00000383eaa8417e>] system_call+0x6e/0x90 INFO: lockdep is turned off.  It is not allowed to take the mmap_lock while in atomic context. Therefore handle such a secure storage access fault as if the accessed page is not mapped: the uaccess function will return -EFAULT, and the caller has to deal with this. Usually this means that the access is retried in process context, which allows to resolve the page fault (or in this case export the page).

CVE-2025-38369:

        In the Linux kernel, the following vulnerability has been resolved:  dmaengine: idxd: Check availability of workqueue allocated by idxd wq driver before using  Running IDXD workloads in a container with the /dev directory mounted can trigger a call trace or even a kernel panic when the parent process of the container is terminated.  This issue occurs because, under certain configurations, Docker does not properly propagate the mount replica back to the original mount point.  In this case, when the user driver detaches, the WQ is destroyed but it still calls destroy_workqueue() attempting to completes all pending work. It's necessary to check wq->wq and skip the drain if it no longer exists.

CVE-2025-38426:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu: Add basic validation for RAS header  If RAS header read from EEPROM is corrupted, it could result in trying to allocate huge memory for reading the records. Add some validation to header fields.

CVE-2025-38429:

        In the Linux kernel, the following vulnerability has been resolved:  bus: mhi: ep: Update read pointer only after buffer is written  Inside mhi_ep_ring_add_element, the read pointer (rd_offset) is updated before the buffer is written, potentially causing race conditions where the host sees an updated read pointer before the buffer is actually written. Updating rd_offset prematurely can lead to the host accessing an uninitialized or incomplete element, resulting in data corruption.  Invoke the buffer write before updating rd_offset to ensure the element is fully written before signaling its availability.

CVE-2025-38438:

        In the Linux kernel, the following vulnerability has been resolved:  ASoC: SOF: Intel: hda: Use devm_kstrdup() to avoid memleak.  sof_pdata->tplg_filename can have address allocated by kstrdup() and can be overwritten. Memory leak was detected with kmemleak:  unreferenced object 0xffff88812391ff60 (size 16):   comm "kworker/4:1", pid 161, jiffies 4294802931   hex dump (first 16 bytes):     73 6f 66 2d 68 64 61 2d 67 65 6e 65 72 69 63 00  sof-hda-generic.   backtrace (crc 4bf1675c):     __kmalloc_node_track_caller_noprof+0x49c/0x6b0     kstrdup+0x46/0xc0     hda_machine_select.cold+0x1de/0x12cf [snd_sof_intel_hda_generic]     sof_init_environment+0x16f/0xb50 [snd_sof]     sof_probe_continue+0x45/0x7c0 [snd_sof]     sof_probe_work+0x1e/0x40 [snd_sof]     process_one_work+0x894/0x14b0     worker_thread+0x5e5/0xfb0     kthread+0x39d/0x760     ret_from_fork+0x31/0x70     ret_from_fork_asm+0x1a/0x30

CVE-2025-38449:

        In the Linux kernel, the following vulnerability has been resolved:  drm/gem: Acquire references on GEM handles for framebuffers  A GEM handle can be released while the GEM buffer object is attached to a DRM framebuffer. This leads to the release of the dma-buf backing the buffer object, if any. [1] Trying to use the framebuffer in further mode-setting operations leads to a segmentation fault. Most easily happens with driver that use shadow planes for vmap-ing the dma-buf during a page flip. An example is shown below.  [  156.791968] ------------[ cut here ]------------ [  156.796830] WARNING: CPU: 2 PID: 2255 at drivers/dma-buf/dma-buf.c:1527 dma_buf_vmap+0x224/0x430 [...] [  156.942028] RIP: 0010:dma_buf_vmap+0x224/0x430 [  157.043420] Call Trace: [  157.045898]  <TASK> [  157.048030]  ? show_trace_log_lvl+0x1af/0x2c0 [  157.052436]  ? show_trace_log_lvl+0x1af/0x2c0 [  157.056836]  ? show_trace_log_lvl+0x1af/0x2c0 [  157.061253]  ? drm_gem_shmem_vmap+0x74/0x710 [  157.065567]  ? dma_buf_vmap+0x224/0x430 [  157.069446]  ? __warn.cold+0x58/0xe4 [  157.073061]  ? dma_buf_vmap+0x224/0x430 [  157.077111]  ? report_bug+0x1dd/0x390 [  157.080842]  ? handle_bug+0x5e/0xa0 [  157.084389]  ? exc_invalid_op+0x14/0x50 [  157.088291]  ? asm_exc_invalid_op+0x16/0x20 [  157.092548]  ? dma_buf_vmap+0x224/0x430 [  157.096663]  ? dma_resv_get_singleton+0x6d/0x230 [  157.101341]  ? __pfx_dma_buf_vmap+0x10/0x10 [  157.105588]  ? __pfx_dma_resv_get_singleton+0x10/0x10 [  157.110697]  drm_gem_shmem_vmap+0x74/0x710 [  157.114866]  drm_gem_vmap+0xa9/0x1b0 [  157.118763]  drm_gem_vmap_unlocked+0x46/0xa0 [  157.123086]  drm_gem_fb_vmap+0xab/0x300 [  157.126979]  drm_atomic_helper_prepare_planes.part.0+0x487/0xb10 [  157.133032]  ? lockdep_init_map_type+0x19d/0x880 [  157.137701]  drm_atomic_helper_commit+0x13d/0x2e0 [  157.142671]  ? drm_atomic_nonblocking_commit+0xa0/0x180 [  157.147988]  drm_mode_atomic_ioctl+0x766/0xe40 [...] [  157.346424] ---[ end trace 0000000000000000 ]---  Acquiring GEM handles for the framebuffer's GEM buffer objects prevents this from happening. The framebuffer's cleanup later puts the handle references.  Commit 1a148af06000 ("drm/gem-shmem: Use dma_buf from GEM object instance") triggers the segmentation fault easily by using the dma-buf field more widely. The underlying issue with reference counting has been present before.  v2: - acquire the handle instead of the BO (Christian) - fix comment style (Christian) - drop the Fixes tag (Christian) - rename err_ gotos - add missing Link tag

CVE-2025-38507:

        In the Linux kernel, the following vulnerability has been resolved:  HID: nintendo: avoid bluetooth suspend/resume stalls  Ensure we don't stall or panic the kernel when using bluetooth-connected controllers. This was reported as an issue on android devices using kernel 6.6 due to the resume hook which had been added for usb joycons.  First, set a new state value to JOYCON_CTLR_STATE_SUSPENDED in a newly-added nintendo_hid_suspend. This makes sure we will not stall out the kernel waiting for input reports during led classdev suspend. The stalls could happen if connectivity is unreliable or lost to the controller prior to suspend.  Second, since we lose connectivity during suspend, do not try joycon_init() for bluetooth controllers in the nintendo_hid_resume path.  Tested via multiple suspend/resume flows when using the controller both in USB and bluetooth modes.

CVE-2025-38524:

        In the Linux kernel, the following vulnerability has been resolved:  rxrpc: Fix recv-recv race of completed call  If a call receives an event (such as incoming data), the call gets placed on the socket's queue and a thread in recvmsg can be awakened to go and process it.  Once the thread has picked up the call off of the queue, further events will cause it to be requeued, and once the socket lock is dropped (recvmsg uses call->user_mutex to allow the socket to be used in parallel), a second thread can come in and its recvmsg can pop the call off the socket queue again.  In such a case, the first thread will be receiving stuff from the call and the second thread will be blocked on call->user_mutex.  The first thread can, at this point, process both the event that it picked call for and the event that the second thread picked the call for and may see the call terminate - in which case the call will be "released", decoupling the call from the user call ID assigned to it (RXRPC_USER_CALL_ID in the control message).  The first thread will return okay, but then the second thread will wake up holding the user_mutex and, if it sees that the call has been released by the first thread, it will BUG thusly:  	kernel BUG at net/rxrpc/recvmsg.c:474!  Fix this by just dequeuing the call and ignoring it if it is seen to be already released.  We can't tell userspace about it anyway as the user call ID has become stale.

CVE-2025-38531:

        In the Linux kernel, the following vulnerability has been resolved:  iio: common: st_sensors: Fix use of uninitialize device structs  Throughout the various probe functions &indio_dev->dev is used before it is initialized. This caused a kernel panic in st_sensors_power_enable() when the call to devm_regulator_bulk_get_enable() fails and then calls dev_err_probe() with the uninitialized device.  This seems to only cause a panic with dev_err_probe(), dev_err(), dev_warn() and dev_info() don't seem to cause a panic, but are fixed as well.  The issue is reported and traced here: [1]

CVE-2025-38544:

        In the Linux kernel, the following vulnerability has been resolved:  rxrpc: Fix bug due to prealloc collision  When userspace is using AF_RXRPC to provide a server, it has to preallocate incoming calls and assign to them call IDs that will be used to thread related recvmsg() and sendmsg() together.  The preallocated call IDs will automatically be attached to calls as they come in until the pool is empty.  To the kernel, the call IDs are just arbitrary numbers, but userspace can use the call ID to hold a pointer to prepared structs.  In any case, the user isn't permitted to create two calls with the same call ID (call IDs become available again when the call ends) and EBADSLT should result from sendmsg() if an attempt is made to preallocate a call with an in-use call ID.  However, the cleanup in the error handling will trigger both assertions in rxrpc_cleanup_call() because the call isn't marked complete and isn't marked as having been released.  Fix this by setting the call state in rxrpc_service_prealloc_one() and then marking it as being released before calling the cleanup function.

CVE-2025-38582:

        In the Linux kernel, the following vulnerability has been resolved:  RDMA/hns: Fix double destruction of rsv_qp  rsv_qp may be double destroyed in error flow, first in free_mr_init(), and then in hns_roce_exit(). Fix it by moving the free_mr_init() call into hns_roce_v2_init().  list_del corruption, ffff589732eb9b50->next is LIST_POISON1 (dead000000000100) WARNING: CPU: 8 PID: 1047115 at lib/list_debug.c:53 __list_del_entry_valid+0x148/0x240 ... Call trace:  __list_del_entry_valid+0x148/0x240  hns_roce_qp_remove+0x4c/0x3f0 [hns_roce_hw_v2]  hns_roce_v2_destroy_qp_common+0x1dc/0x5f4 [hns_roce_hw_v2]  hns_roce_v2_destroy_qp+0x22c/0x46c [hns_roce_hw_v2]  free_mr_exit+0x6c/0x120 [hns_roce_hw_v2]  hns_roce_v2_exit+0x170/0x200 [hns_roce_hw_v2]  hns_roce_exit+0x118/0x350 [hns_roce_hw_v2]  __hns_roce_hw_v2_init_instance+0x1c8/0x304 [hns_roce_hw_v2]  hns_roce_hw_v2_reset_notify_init+0x170/0x21c [hns_roce_hw_v2]  hns_roce_hw_v2_reset_notify+0x6c/0x190 [hns_roce_hw_v2]  hclge_notify_roce_client+0x6c/0x160 [hclge]  hclge_reset_rebuild+0x150/0x5c0 [hclge]  hclge_reset+0x10c/0x140 [hclge]  hclge_reset_subtask+0x80/0x104 [hclge]  hclge_reset_service_task+0x168/0x3ac [hclge]  hclge_service_task+0x50/0x100 [hclge]  process_one_work+0x250/0x9a0  worker_thread+0x324/0x990  kthread+0x190/0x210  ret_from_fork+0x10/0x18

CVE-2025-38585:

        In the Linux kernel, the following vulnerability has been resolved:  staging: media: atomisp: Fix stack buffer overflow in gmin_get_var_int()  When gmin_get_config_var() calls efi.get_variable() and the EFI variable is larger than the expected buffer size, two behaviors combine to create a stack buffer overflow:  1. gmin_get_config_var() does not return the proper error code when    efi.get_variable() fails. It returns the stale 'ret' value from    earlier operations instead of indicating the EFI failure.  2. When efi.get_variable() returns EFI_BUFFER_TOO_SMALL, it updates    *out_len to the required buffer size but writes no data to the output    buffer. However, due to bug #1, gmin_get_var_int() believes the call    succeeded.  The caller gmin_get_var_int() then performs: - Allocates val[CFG_VAR_NAME_MAX + 1] (65 bytes) on stack - Calls gmin_get_config_var(dev, is_gmin, var, val, &len) with len=64 - If EFI variable is >64 bytes, efi.get_variable() sets len=required_size - Due to bug #1, thinks call succeeded with len=required_size - Executes val[len] = 0, writing past end of 65-byte stack buffer  This creates a stack buffer overflow when EFI variables are larger than 64 bytes. Since EFI variables can be controlled by firmware or system configuration, this could potentially be exploited for code execution.  Fix the bug by returning proper error codes from gmin_get_config_var() based on EFI status instead of stale 'ret' value.  The gmin_get_var_int() function is called during device initialization for camera sensor configuration on Intel Bay Trail and Cherry Trail platforms using the atomisp camera stack.

CVE-2025-38590:

        In the Linux kernel, the following vulnerability has been resolved:  net/mlx5e: Remove skb secpath if xfrm state is not found  Hardware returns a unique identifier for a decrypted packet's xfrm state, this state is looked up in an xarray. However, the state might have been freed by the time of this lookup.  Currently, if the state is not found, only a counter is incremented. The secpath (sp) extension on the skb is not removed, resulting in sp->len becoming 0.  Subsequently, functions like __xfrm_policy_check() attempt to access fields such as xfrm_input_state(skb)->xso.type (which dereferences sp->xvec[sp->len - 1]) without first validating sp->len. This leads to a crash when dereferencing an invalid state pointer.  This patch prevents the crash by explicitly removing the secpath extension from the skb if the xfrm state is not found after hardware decryption. This ensures downstream functions do not operate on a zero-length secpath.   BUG: unable to handle page fault for address: ffffffff000002c8  #PF: supervisor read access in kernel mode  #PF: error_code(0x0000) - not-present page  PGD 282e067 P4D 282e067 PUD 0  Oops: Oops: 0000 [#1] SMP  CPU: 12 UID: 0 PID: 0 Comm: swapper/12 Not tainted 6.15.0-rc7_for_upstream_min_debug_2025_05_27_22_44 #1 NONE  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014  RIP: 0010:__xfrm_policy_check+0x61a/0xa30  Code: b6 77 7f 83 e6 02 74 14 4d 8b af d8 00 00 00 41 0f b6 45 05 c1 e0 03 48 98 49 01 c5 41 8b 45 00 83 e8 01 48 98 49 8b 44 c5 10 <0f> b6 80 c8 02 00 00 83 e0 0c 3c 04 0f 84 0c 02 00 00 31 ff 80 fa  RSP: 0018:ffff88885fb04918 EFLAGS: 00010297  RAX: ffffffff00000000 RBX: 0000000000000002 RCX: 0000000000000000  RDX: 0000000000000002 RSI: 0000000000000002 RDI: 0000000000000000  RBP: ffffffff8311af80 R08: 0000000000000020 R09: 00000000c2eda353  R10: ffff88812be2bbc8 R11: 000000001faab533 R12: ffff88885fb049c8  R13: ffff88812be2bbc8 R14: 0000000000000000 R15: ffff88811896ae00  FS:  0000000000000000(0000) GS:ffff8888dca82000(0000) knlGS:0000000000000000  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  CR2: ffffffff000002c8 CR3: 0000000243050002 CR4: 0000000000372eb0  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400  Call Trace:   <IRQ>   ? try_to_wake_up+0x108/0x4c0   ? udp4_lib_lookup2+0xbe/0x150   ? udp_lib_lport_inuse+0x100/0x100   ? __udp4_lib_lookup+0x2b0/0x410   __xfrm_policy_check2.constprop.0+0x11e/0x130   udp_queue_rcv_one_skb+0x1d/0x530   udp_unicast_rcv_skb+0x76/0x90   __udp4_lib_rcv+0xa64/0xe90   ip_protocol_deliver_rcu+0x20/0x130   ip_local_deliver_finish+0x75/0xa0   ip_local_deliver+0xc1/0xd0   ? ip_protocol_deliver_rcu+0x130/0x130   ip_sublist_rcv+0x1f9/0x240   ? ip_rcv_finish_core+0x430/0x430   ip_list_rcv+0xfc/0x130   __netif_receive_skb_list_core+0x181/0x1e0   netif_receive_skb_list_internal+0x200/0x360   ? mlx5e_build_rx_skb+0x1bc/0xda0 [mlx5_core]   gro_receive_skb+0xfd/0x210   mlx5e_handle_rx_cqe_mpwrq+0x141/0x280 [mlx5_core]   mlx5e_poll_rx_cq+0xcc/0x8e0 [mlx5_core]   ? mlx5e_handle_rx_dim+0x91/0xd0 [mlx5_core]   mlx5e_napi_poll+0x114/0xab0 [mlx5_core]   __napi_poll+0x25/0x170   net_rx_action+0x32d/0x3a0   ? mlx5_eq_comp_int+0x8d/0x280 [mlx5_core]   ? notifier_call_chain+0x33/0xa0   handle_softirqs+0xda/0x250   irq_exit_rcu+0x6d/0xc0   common_interrupt+0x81/0xa0   </IRQ>

CVE-2025-38595:

        In the Linux kernel, the following vulnerability has been resolved:  xen: fix UAF in dmabuf_exp_from_pages()  [dma_buf_fd() fixes; no preferences regarding the tree it goes through - up to xen folks]  As soon as we'd inserted a file reference into descriptor table, another thread could close it.  That's fine for the case when all we are doing is returning that descriptor to userland (it's a race, but it's a userland race and there's nothing the kernel can do about it).  However, if we follow fd_install() with any kind of access to objects that would be destroyed on close (be it the struct file itself or anything destroyed by its ->release()), we have a UAF.  dma_buf_fd() is a combination of reserving a descriptor and fd_install(). gntdev dmabuf_exp_from_pages() calls it and then proceeds to access the objects destroyed on close - starting with gntdev_dmabuf itself.  Fix that by doing reserving descriptor before anything else and do fd_install() only when everything had been set up.

CVE-2025-38597:

        In the Linux kernel, the following vulnerability has been resolved:  drm/rockchip: vop2: fail cleanly if missing a primary plane for a video-port  Each window of a vop2 is usable by a specific set of video ports, so while binding the vop2, we look through the list of available windows trying to find one designated as primary-plane and usable by that specific port.  The code later wants to use drm_crtc_init_with_planes with that found primary plane, but nothing has checked so far if a primary plane was actually found.  For whatever reason, the rk3576 vp2 does not have a usable primary window (if vp0 is also in use) which brought the issue to light and ended in a null-pointer dereference further down.  As we expect a primary-plane to exist for a video-port, add a check at the end of the window-iteration and fail probing if none was found.

CVE-2025-38615:

        In the Linux kernel, the following vulnerability has been resolved:  fs/ntfs3: cancle set bad inode after removing name fails  The reproducer uses a file0 on a ntfs3 file system with a corrupted i_link. When renaming, the file0's inode is marked as a bad inode because the file name cannot be deleted.  The underlying bug is that make_bad_inode() is called on a live inode. In some cases it's "icache lookup finds a normal inode, d_splice_alias() is called to attach it to dentry, while another thread decides to call make_bad_inode() on it - that would evict it from icache, but we'd already found it there earlier". In some it's outright "we have an inode attached to dentry - that's how we got it in the first place; let's call make_bad_inode() on it just for shits and giggles".

CVE-2025-38636:

        In the Linux kernel, the following vulnerability has been resolved:  rv: Use strings in da monitors tracepoints  Using DA monitors tracepoints with KASAN enabled triggers the following warning:   BUG: KASAN: global-out-of-bounds in do_trace_event_raw_event_event_da_monitor+0xd6/0x1a0  Read of size 32 at addr ffffffffaada8980 by task ...  Call Trace:   <TASK>  [...]   do_trace_event_raw_event_event_da_monitor+0xd6/0x1a0   ? __pfx_do_trace_event_raw_event_event_da_monitor+0x10/0x10   ? trace_event_sncid+0x83/0x200   trace_event_sncid+0x163/0x200  [...]  The buggy address belongs to the variable:   automaton_snep+0x4e0/0x5e0  This is caused by the tracepoints reading 32 bytes __array instead of __string from the automata definition. Such strings are literals and reading 32 bytes ends up in out of bound memory accesses (e.g. the next automaton's data in this case). The error is harmless as, while printing the string, we stop at the null terminator, but it should still be fixed.  Use the __string facilities while defining the tracepoints to avoid reading out of bound memory.

CVE-2025-38692:

        In the Linux kernel, the following vulnerability has been resolved:  exfat: add cluster chain loop check for dir  An infinite loop may occur if the following conditions occur due to file system corruption.  (1) Condition for exfat_count_dir_entries() to loop infinitely.     - The cluster chain includes a loop.     - There is no UNUSED entry in the cluster chain.  (2) Condition for exfat_create_upcase_table() to loop infinitely.     - The cluster chain of the root directory includes a loop.     - There are no UNUSED entry and up-case table entry in the cluster       chain of the root directory.  (3) Condition for exfat_load_bitmap() to loop infinitely.     - The cluster chain of the root directory includes a loop.     - There are no UNUSED entry and bitmap entry in the cluster chain       of the root directory.  (4) Condition for exfat_find_dir_entry() to loop infinitely.     - The cluster chain includes a loop.     - The unused directory entries were exhausted by some operation.  (5) Condition for exfat_check_dir_empty() to loop infinitely.     - The cluster chain includes a loop.     - The unused directory entries were exhausted by some operation.     - All files and sub-directories under the directory are deleted.  This commit adds checks to break the above infinite loop.

CVE-2025-38705:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/pm: fix null pointer access  Writing a string without delimiters (' ', '\n', '\0') to the under gpu_od/fan_ctrl sysfs or pp_power_profile_mode for the CUSTOM profile will result in a null pointer dereference.

CVE-2025-38709:

        In the Linux kernel, the following vulnerability has been resolved:  loop: Avoid updating block size under exclusive owner  Syzbot came up with a reproducer where a loop device block size is changed underneath a mounted filesystem. This causes a mismatch between the block device block size and the block size stored in the superblock causing confusion in various places such as fs/buffer.c. The particular issue triggered by syzbot was a warning in __getblk_slow() due to requested buffer size not matching block device block size.  Fix the problem by getting exclusive hold of the loop device to change its block size. This fails if somebody (such as filesystem) has already an exclusive ownership of the block device and thus prevents modifying the loop device under some exclusive owner which doesn't expect it.

CVE-2025-38716:

        In the Linux kernel, the following vulnerability has been resolved:  hfs: fix general protection fault in hfs_find_init()  The hfs_find_init() method can trigger the crash if tree pointer is NULL:  [   45.746290][ T9787] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000008: 0000 [#1] SMP KAI [   45.747287][ T9787] KASAN: null-ptr-deref in range [0x0000000000000040-0x0000000000000047] [   45.748716][ T9787] CPU: 2 UID: 0 PID: 9787 Comm: repro Not tainted 6.16.0-rc3 #10 PREEMPT(full) [   45.750250][ T9787] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [   45.751983][ T9787] RIP: 0010:hfs_find_init+0x86/0x230 [   45.752834][ T9787] Code: c1 ea 03 80 3c 02 00 0f 85 9a 01 00 00 4c 8d 6b 40 48 c7 45 18 00 00 00 00 48 b8 00 00 00 00 00 fc [   45.755574][ T9787] RSP: 0018:ffffc90015157668 EFLAGS: 00010202 [   45.756432][ T9787] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff819a4d09 [   45.757457][ T9787] RDX: 0000000000000008 RSI: ffffffff819acd3a RDI: ffffc900151576e8 [   45.758282][ T9787] RBP: ffffc900151576d0 R08: 0000000000000005 R09: 0000000000000000 [   45.758943][ T9787] R10: 0000000080000000 R11: 0000000000000001 R12: 0000000000000004 [   45.759619][ T9787] R13: 0000000000000040 R14: ffff88802c50814a R15: 0000000000000000 [   45.760293][ T9787] FS:  00007ffb72734540(0000) GS:ffff8880cec64000(0000) knlGS:0000000000000000 [   45.761050][ T9787] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [   45.761606][ T9787] CR2: 00007f9bd8225000 CR3: 000000010979a000 CR4: 00000000000006f0 [   45.762286][ T9787] Call Trace: [   45.762570][ T9787]  <TASK> [   45.762824][ T9787]  hfs_ext_read_extent+0x190/0x9d0 [   45.763269][ T9787]  ? submit_bio_noacct_nocheck+0x2dd/0xce0 [   45.763766][ T9787]  ? __pfx_hfs_ext_read_extent+0x10/0x10 [   45.764250][ T9787]  hfs_get_block+0x55f/0x830 [   45.764646][ T9787]  block_read_full_folio+0x36d/0x850 [   45.765105][ T9787]  ? __pfx_hfs_get_block+0x10/0x10 [   45.765541][ T9787]  ? const_folio_flags+0x5b/0x100 [   45.765972][ T9787]  ? __pfx_hfs_read_folio+0x10/0x10 [   45.766415][ T9787]  filemap_read_folio+0xbe/0x290 [   45.766840][ T9787]  ? __pfx_filemap_read_folio+0x10/0x10 [   45.767325][ T9787]  ? __filemap_get_folio+0x32b/0xbf0 [   45.767780][ T9787]  do_read_cache_folio+0x263/0x5c0 [   45.768223][ T9787]  ? __pfx_hfs_read_folio+0x10/0x10 [   45.768666][ T9787]  read_cache_page+0x5b/0x160 [   45.769070][ T9787]  hfs_btree_open+0x491/0x1740 [   45.769481][ T9787]  hfs_mdb_get+0x15e2/0x1fb0 [   45.769877][ T9787]  ? __pfx_hfs_mdb_get+0x10/0x10 [   45.770316][ T9787]  ? find_held_lock+0x2b/0x80 [   45.770731][ T9787]  ? lockdep_init_map_type+0x5c/0x280 [   45.771200][ T9787]  ? lockdep_init_map_type+0x5c/0x280 [   45.771674][ T9787]  hfs_fill_super+0x38e/0x720 [   45.772092][ T9787]  ? __pfx_hfs_fill_super+0x10/0x10 [   45.772549][ T9787]  ? snprintf+0xbe/0x100 [   45.772931][ T9787]  ? __pfx_snprintf+0x10/0x10 [   45.773350][ T9787]  ? do_raw_spin_lock+0x129/0x2b0 [   45.773796][ T9787]  ? find_held_lock+0x2b/0x80 [   45.774215][ T9787]  ? set_blocksize+0x40a/0x510 [   45.774636][ T9787]  ? sb_set_blocksize+0x176/0x1d0 [   45.775087][ T9787]  ? setup_bdev_super+0x369/0x730 [   45.775533][ T9787]  get_tree_bdev_flags+0x384/0x620 [   45.775985][ T9787]  ? __pfx_hfs_fill_super+0x10/0x10 [   45.776453][ T9787]  ? __pfx_get_tree_bdev_flags+0x10/0x10 [   45.776950][ T9787]  ? bpf_lsm_capable+0x9/0x10 [   45.777365][ T9787]  ? security_capable+0x80/0x260 [   45.777803][ T9787]  vfs_get_tree+0x8e/0x340 [   45.778203][ T9787]  path_mount+0x13de/0x2010 [   45.778604][ T9787]  ? kmem_cache_free+0x2b0/0x4c0 [   45.779052][ T9787]  ? __pfx_path_mount+0x10/0x10 [   45.779480][ T9787]  ? getname_flags.part.0+0x1c5/0x550 [   45.779954][ T9787]  ? putname+0x154/0x1a0 [   45.780335][ T9787]  __x64_sys_mount+0x27b/0x300 [   45.780758][ T9787]  ? __pfx___x64_sys_mount+0x10/0x10 [   45.781232][ T9787]  ---truncated---

CVE-2025-38717:

        In the Linux kernel, the following vulnerability has been resolved:  net: kcm: Fix race condition in kcm_unattach()  syzbot found a race condition when kcm_unattach(psock) and kcm_release(kcm) are executed at the same time.  kcm_unattach() is missing a check of the flag kcm->tx_stopped before calling queue_work().  If the kcm has a reserved psock, kcm_unattach() might get executed between cancel_work_sync() and unreserve_psock() in kcm_release(), requeuing kcm->tx_work right before kcm gets freed in kcm_done().  Remove kcm->tx_stopped and replace it by the less error-prone disable_work_sync().

CVE-2025-38722:

        In the Linux kernel, the following vulnerability has been resolved:  habanalabs: fix UAF in export_dmabuf()  As soon as we'd inserted a file reference into descriptor table, another thread could close it.  That's fine for the case when all we are doing is returning that descriptor to userland (it's a race, but it's a userland race and there's nothing the kernel can do about it).  However, if we follow fd_install() with any kind of access to objects that would be destroyed on close (be it the struct file itself or anything destroyed by its ->release()), we have a UAF.  dma_buf_fd() is a combination of reserving a descriptor and fd_install(). habanalabs export_dmabuf() calls it and then proceeds to access the objects destroyed on close.  In particular, it grabs an extra reference to another struct file that will be dropped as part of ->release() for ours; that "will be" is actually "might have already been".  Fix that by reserving descriptor before anything else and do fd_install() only when everything had been set up.  As a side benefit, we no longer have the failure exit with file already created, but reference to underlying file (as well as ->dmabuf_export_cnt, etc.) not grabbed yet; unlike dma_buf_fd(), fd_install() can't fail.

CVE-2025-38734:

        In the Linux kernel, the following vulnerability has been resolved:  net/smc: fix UAF on smcsk after smc_listen_out()  BPF CI testing report a UAF issue:    [   16.446633] BUG: kernel NULL pointer dereference, address: 000000000000003  0   [   16.447134] #PF: supervisor read access in kernel mod  e   [   16.447516] #PF: error_code(0x0000) - not-present pag  e   [   16.447878] PGD 0 P4D   0   [   16.448063] Oops: Oops: 0000 [#1] PREEMPT SMP NOPT  I   [   16.448409] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Tainted: G           OE      6.13.0-rc3-g89e8a75fda73-dirty #4  2   [   16.449124] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODUL  E   [   16.449502] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/201  4   [   16.450201] Workqueue: smc_hs_wq smc_listen_wor  k   [   16.450531] RIP: 0010:smc_listen_work+0xc02/0x159  0   [   16.452158] RSP: 0018:ffffb5ab40053d98 EFLAGS: 0001024  6   [   16.452526] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 000000000000030  0   [   16.452994] RDX: 0000000000000280 RSI: 00003513840053f0 RDI: 000000000000000  0   [   16.453492] RBP: ffffa097808e3800 R08: ffffa09782dba1e0 R09: 000000000000000  5   [   16.453987] R10: 0000000000000000 R11: 0000000000000000 R12: ffffa0978274640  0   [   16.454497] R13: 0000000000000000 R14: 0000000000000000 R15: ffffa09782d4092  0   [   16.454996] FS:  0000000000000000(0000) GS:ffffa097bbc00000(0000) knlGS:000000000000000  0   [   16.455557] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003  3   [   16.455961] CR2: 0000000000000030 CR3: 0000000102788004 CR4: 0000000000770ef  0   [   16.456459] PKRU: 5555555  4   [   16.456654] Call Trace  :   [   16.456832]  <TASK  >   [   16.456989]  ? __die+0x23/0x7  0   [   16.457215]  ? page_fault_oops+0x180/0x4c  0   [   16.457508]  ? __lock_acquire+0x3e6/0x249  0   [   16.457801]  ? exc_page_fault+0x68/0x20  0   [   16.458080]  ? asm_exc_page_fault+0x26/0x3  0   [   16.458389]  ? smc_listen_work+0xc02/0x159  0   [   16.458689]  ? smc_listen_work+0xc02/0x159  0   [   16.458987]  ? lock_is_held_type+0x8f/0x10  0   [   16.459284]  process_one_work+0x1ea/0x6d  0   [   16.459570]  worker_thread+0x1c3/0x38  0   [   16.459839]  ? __pfx_worker_thread+0x10/0x1  0   [   16.460144]  kthread+0xe0/0x11  0   [   16.460372]  ? __pfx_kthread+0x10/0x1  0   [   16.460640]  ret_from_fork+0x31/0x5  0   [   16.460896]  ? __pfx_kthread+0x10/0x1  0   [   16.461166]  ret_from_fork_asm+0x1a/0x3  0   [   16.461453]  </TASK  >   [   16.461616] Modules linked in: bpf_testmod(OE) [last unloaded: bpf_testmod(OE)  ]   [   16.462134] CR2: 000000000000003  0   [   16.462380] ---[ end trace 0000000000000000 ]---   [   16.462710] RIP: 0010:smc_listen_work+0xc02/0x1590  The direct cause of this issue is that after smc_listen_out_connected(), newclcsock->sk may be NULL since it will releases the smcsk. Therefore, if the application closes the socket immediately after accept, newclcsock->sk can be NULL. A possible execution order could be as follows:  smc_listen_work                                 | userspace ----------------------------------------------------------------- lock_sock(sk)                                   | smc_listen_out_connected()                      | | \- smc_listen_out                             | |    | \- release_sock                          |      | |- sk->sk_data_ready()                   |                                                 | fd = accept();                                                 | close(fd);                                                 |  \- socket->sk = NULL; /* newclcsock->sk is NULL now */ SMC_STAT_SERV_SUCC_INC(sock_net(newclcsock->sk))  Since smc_listen_out_connected() will not fail, simply swapping the order of the code can easily fix this issue.

CVE-2025-39677:

        In the Linux kernel, the following vulnerability has been resolved:  net/sched: Fix backlog accounting in qdisc_dequeue_internal  This issue applies for the following qdiscs: hhf, fq, fq_codel, and fq_pie, and occurs in their change handlers when adjusting to the new limit. The problem is the following in the values passed to the subsequent qdisc_tree_reduce_backlog call given a tbf parent:     When the tbf parent runs out of tokens, skbs of these qdiscs will    be placed in gso_skb. Their peek handlers are qdisc_peek_dequeued,    which accounts for both qlen and backlog. However, in the case of    qdisc_dequeue_internal, ONLY qlen is accounted for when pulling    from gso_skb. This means that these qdiscs are missing a    qdisc_qstats_backlog_dec when dropping packets to satisfy the    new limit in their change handlers.     One can observe this issue with the following (with tc patched to    support a limit of 0):     export TARGET=fq    tc qdisc del dev lo root    tc qdisc add dev lo root handle 1: tbf rate 8bit burst 100b latency 1ms    tc qdisc replace dev lo handle 3: parent 1:1 $TARGET limit 1000    echo ''; echo 'add child'; tc -s -d qdisc show dev lo    ping -I lo -f -c2 -s32 -W0.001 127.0.0.1 2>&1 >/dev/null    echo ''; echo 'after ping'; tc -s -d qdisc show dev lo    tc qdisc change dev lo handle 3: parent 1:1 $TARGET limit 0    echo ''; echo 'after limit drop'; tc -s -d qdisc show dev lo    tc qdisc replace dev lo handle 2: parent 1:1 sfq    echo ''; echo 'post graft'; tc -s -d qdisc show dev lo     The second to last show command shows 0 packets but a positive    number (74) of backlog bytes. The problem becomes clearer in the    last show command, where qdisc_purge_queue triggers    qdisc_tree_reduce_backlog with the positive backlog and causes an    underflow in the tbf parent's backlog (4096 Mb instead of 0).  To fix this issue, the codepath for all clients of qdisc_dequeue_internal has been simplified: codel, pie, hhf, fq, fq_pie, and fq_codel. qdisc_dequeue_internal handles the backlog adjustments for all cases that do not directly use the dequeue handler.  The old fq_codel_change limit adjustment loop accumulated the arguments to the subsequent qdisc_tree_reduce_backlog call through the cstats field. However, this is confusing and error prone as fq_codel_dequeue could also potentially mutate this field (which qdisc_dequeue_internal calls in the non gso_skb case), so we have unified the code here with other qdiscs.

CVE-2025-39705:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: fix a Null pointer dereference vulnerability  [Why] A null pointer dereference vulnerability exists in the AMD display driver's (DC module) cleanup function dc_destruct(). When display control context (dc->ctx) construction fails (due to memory allocation failure), this pointer remains NULL. During subsequent error handling when dc_destruct() is called, there's no NULL check before dereferencing the perf_trace member (dc->ctx->perf_trace), causing a kernel null pointer dereference crash.  [How] Check if dc->ctx is non-NULL before dereferencing.  (Updated commit text and removed unnecessary error message) (cherry picked from commit 9dd8e2ba268c636c240a918e0a31e6feaee19404)

CVE-2025-39707:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu: check if hubbub is NULL in debugfs/amdgpu_dm_capabilities  HUBBUB structure is not initialized on DCE hardware, so check if it is NULL to avoid null dereference while accessing amdgpu_dm_capabilities file in debugfs.

CVE-2025-39720:

        In the Linux kernel, the following vulnerability has been resolved:  ksmbd: fix refcount leak causing resource not released  When ksmbd_conn_releasing(opinfo->conn) returns true,the refcount was not decremented properly, causing a refcount leak that prevents the count from reaching zero and the memory from being released.

CVE-2025-39726:

        In the Linux kernel, the following vulnerability has been resolved:  s390/ism: fix concurrency management in ism_cmd()  The s390x ISM device data sheet clearly states that only one request-response sequence is allowable per ISM function at any point in time.  Unfortunately as of today the s390/ism driver in Linux does not honor that requirement. This patch aims to rectify that.  This problem was discovered based on Aliaksei's bug report which states that for certain workloads the ISM functions end up entering error state (with PEC 2 as seen from the logs) after a while and as a consequence connections handled by the respective function break, and for future connection requests the ISM device is not considered -- given it is in a dysfunctional state. During further debugging PEC 3A was observed as well.  A kernel message like [ 1211.244319] zpci: 061a:00:00.0: Event 0x2 reports an error for PCI function 0x61a is a reliable indicator of the stated function entering error state with PEC 2. Let me also point out that a kernel message like [ 1211.244325] zpci: 061a:00:00.0: The ism driver bound to the device does not support error recovery is a reliable indicator that the ISM function won't be auto-recovered because the ISM driver currently lacks support for it.  On a technical level, without this synchronization, commands (inputs to the FW) may be partially or fully overwritten (corrupted) by another CPU trying to issue commands on the same function. There is hard evidence that this can lead to DMB token values being used as DMB IOVAs, leading to PEC 2 PCI events indicating invalid DMA. But this is only one of the failure modes imaginable. In theory even completely losing one command and executing another one twice and then trying to interpret the outputs as if the command we intended to execute was actually executed and not the other one is also possible.  Frankly, I don't feel confident about providing an exhaustive list of possible consequences.

CVE-2025-39732:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: ath11k: fix sleeping-in-atomic in ath11k_mac_op_set_bitrate_mask()  ath11k_mac_disable_peer_fixed_rate() is passed as the iterator to ieee80211_iterate_stations_atomic(). Note in this case the iterator is required to be atomic, however ath11k_mac_disable_peer_fixed_rate() does not follow it as it might sleep. Consequently below warning is seen:  BUG: sleeping function called from invalid context at wmi.c:304 Call Trace:  <TASK>  dump_stack_lvl  __might_resched.cold  ath11k_wmi_cmd_send  ath11k_wmi_set_peer_param  ath11k_mac_disable_peer_fixed_rate  ieee80211_iterate_stations_atomic  ath11k_mac_op_set_bitrate_mask.cold  Change to ieee80211_iterate_stations_mtx() to fix this issue.  Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30

CVE-2025-39744:

        In the Linux kernel, the following vulnerability has been resolved:  rcu: Fix rcu_read_unlock() deadloop due to IRQ work  During rcu_read_unlock_special(), if this happens during irq_exit(), we can lockup if an IPI is issued. This is because the IPI itself triggers the irq_exit() path causing a recursive lock up.  This is precisely what Xiongfeng found when invoking a BPF program on the trace_tick_stop() tracepoint As shown in the trace below. Fix by managing the irq_work state correctly.  irq_exit()   __irq_exit_rcu()     /* in_hardirq() returns false after this */     preempt_count_sub(HARDIRQ_OFFSET)     tick_irq_exit()       tick_nohz_irq_exit() 	    tick_nohz_stop_sched_tick() 	      trace_tick_stop()  /* a bpf prog is hooked on this trace point */ 		   __bpf_trace_tick_stop() 		      bpf_trace_run2() 			    rcu_read_unlock_special()                               /* will send a IPI to itself */ 			      irq_work_queue_on(&rdp->defer_qs_iw, rdp->cpu);  A simple reproducer can also be obtained by doing the following in tick_irq_exit(). It will hang on boot without the patch:    static inline void tick_irq_exit(void)   {  +	rcu_read_lock();  +	WRITE_ONCE(current->rcu_read_unlock_special.b.need_qs, true);  +	rcu_read_unlock();  +  [neeraj: Apply Frederic's suggested fix for PREEMPT_RT]

CVE-2025-39746:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: ath10k: shutdown driver when hardware is unreliable  In rare cases, ath10k may lose connection with the PCIe bus due to some unknown reasons, which could further lead to system crashes during resuming due to watchdog timeout:  ath10k_pci 0000:01:00.0: wmi command 20486 timeout, restarting hardware ath10k_pci 0000:01:00.0: already restarting ath10k_pci 0000:01:00.0: failed to stop WMI vdev 0: -11 ath10k_pci 0000:01:00.0: failed to stop vdev 0: -11 ieee80211 phy0: PM: **** DPM device timeout **** Call Trace:  panic+0x125/0x315  dpm_watchdog_set+0x54/0x54  dpm_watchdog_handler+0x57/0x57  call_timer_fn+0x31/0x13c  At this point, all WMI commands will timeout and attempt to restart device. So set a threshold for consecutive restart failures. If the threshold is exceeded, consider the hardware is unreliable and all ath10k operations should be skipped to avoid system crash.  fail_cont_count and pending_recovery are atomic variables, and do not involve complex conditional logic. Therefore, even if recovery check and reconfig complete are executed concurrently, the recovery mechanism will not be broken.  Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00288-QCARMSWPZ-1

CVE-2025-39747:

        In the Linux kernel, the following vulnerability has been resolved:  drm/msm: Add error handling for krealloc in metadata setup  Function msm_ioctl_gem_info_set_metadata() now checks for krealloc failure and returns -ENOMEM, avoiding potential NULL pointer dereference. Explicitly avoids __GFP_NOFAIL due to deadlock risks and allocation constraints.  Patchwork: https://patchwork.freedesktop.org/patch/661235/

CVE-2025-39754:

        In the Linux kernel, the following vulnerability has been resolved:  mm/smaps: fix race between smaps_hugetlb_range and migration  smaps_hugetlb_range() handles the pte without holdling ptl, and may be concurrenct with migration, leaing to BUG_ON in pfn_swap_entry_to_page().  The race is as follows.  smaps_hugetlb_range              migrate_pages   huge_ptep_get                                    remove_migration_ptes 				   folio_unlock   pfn_swap_entry_folio     BUG_ON  To fix it, hold ptl lock in smaps_hugetlb_range().

CVE-2025-39762:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: add null check  [WHY] Prevents null pointer dereferences to enhance function robustness  [HOW] Adds early null check and return false if invalid.

CVE-2025-39767:

        In the Linux kernel, the following vulnerability has been resolved:  LoongArch: Optimize module load time by optimizing PLT/GOT counting  When enabling CONFIG_KASAN, CONFIG_PREEMPT_VOLUNTARY_BUILD and CONFIG_PREEMPT_VOLUNTARY at the same time, there will be soft deadlock, the relevant logs are as follows:  rcu: INFO: rcu_sched self-detected stall on CPU ... Call Trace: [<900000000024f9e4>] show_stack+0x5c/0x180 [<90000000002482f4>] dump_stack_lvl+0x94/0xbc [<9000000000224544>] rcu_dump_cpu_stacks+0x1fc/0x280 [<900000000037ac80>] rcu_sched_clock_irq+0x720/0xf88 [<9000000000396c34>] update_process_times+0xb4/0x150 [<90000000003b2474>] tick_nohz_handler+0xf4/0x250 [<9000000000397e28>] __hrtimer_run_queues+0x1d0/0x428 [<9000000000399b2c>] hrtimer_interrupt+0x214/0x538 [<9000000000253634>] constant_timer_interrupt+0x64/0x80 [<9000000000349938>] __handle_irq_event_percpu+0x78/0x1a0 [<9000000000349a78>] handle_irq_event_percpu+0x18/0x88 [<9000000000354c00>] handle_percpu_irq+0x90/0xf0 [<9000000000348c74>] handle_irq_desc+0x94/0xb8 [<9000000001012b28>] handle_cpu_irq+0x68/0xa0 [<9000000001def8c0>] handle_loongarch_irq+0x30/0x48 [<9000000001def958>] do_vint+0x80/0xd0 [<9000000000268a0c>] kasan_mem_to_shadow.part.0+0x2c/0x2a0 [<90000000006344f4>] __asan_load8+0x4c/0x120 [<900000000025c0d0>] module_frob_arch_sections+0x5c8/0x6b8 [<90000000003895f0>] load_module+0x9e0/0x2958 [<900000000038b770>] __do_sys_init_module+0x208/0x2d0 [<9000000001df0c34>] do_syscall+0x94/0x190 [<900000000024d6fc>] handle_syscall+0xbc/0x158  After analysis, this is because the slow speed of loading the amdgpu module leads to the long time occupation of the cpu and then the soft deadlock.  When loading a module, module_frob_arch_sections() tries to figure out the number of PLTs/GOTs that will be needed to handle all the RELAs. It will call the count_max_entries() to find in an out-of-order date which counting algorithm has O(n^2) complexity.  To make it faster, we sort the relocation list by info and addend. That way, to check for a duplicate relocation, it just needs to compare with the previous entry. This reduces the complexity of the algorithm to O(n  log n), as done in commit d4e0340919fb ("arm64/module: Optimize module load time by optimizing PLT counting"). This gives sinificant reduction in module load time for modules with large number of relocations.  After applying this patch, the soft deadlock problem has been solved, and the kernel starts normally without "Call Trace".  Using the default configuration to test some modules, the results are as follows:  Module              Size ip_tables           36K fat                 143K radeon              2.5MB amdgpu              16MB  Without this patch: Module              Module load time (ms)	Count(PLTs/GOTs) ip_tables           18				59/6 fat                 0				162/14 radeon              54				1221/84 amdgpu              1411			4525/1098  With this patch: Module              Module load time (ms)	Count(PLTs/GOTs) ip_tables           18				59/6 fat                 0				162/14 radeon              22				1221/84 amdgpu              45				4525/1098

CVE-2025-39779:

        In the Linux kernel, the following vulnerability has been resolved:  btrfs: subpage: keep TOWRITE tag until folio is cleaned  btrfs_subpage_set_writeback() calls folio_start_writeback() the first time a folio is written back, and it also clears the PAGECACHE_TAG_TOWRITE tag even if there are still dirty blocks in the folio. This can break ordering guarantees, such as those required by btrfs_wait_ordered_extents().  That ordering breakage leads to a real failure. For example, running generic/464 on a zoned setup will hit the following ASSERT. This happens because the broken ordering fails to flush existing dirty pages before the file size is truncated.    assertion failed: !list_empty(&ordered->list) :: 0, in fs/btrfs/zoned.c:1899   ------------[ cut here ]------------   kernel BUG at fs/btrfs/zoned.c:1899!   Oops: invalid opcode: 0000 [#1] SMP NOPTI   CPU: 2 UID: 0 PID: 1906169 Comm: kworker/u130:2 Kdump: loaded Not tainted 6.16.0-rc6-BTRFS-ZNS+ #554 PREEMPT(voluntary)   Hardware name: Supermicro Super Server/H12SSL-NT, BIOS 2.0 02/22/2021   Workqueue: btrfs-endio-write btrfs_work_helper [btrfs]   RIP: 0010:btrfs_finish_ordered_zoned.cold+0x50/0x52 [btrfs]   RSP: 0018:ffffc9002efdbd60 EFLAGS: 00010246   RAX: 000000000000004c RBX: ffff88811923c4e0 RCX: 0000000000000000   RDX: 0000000000000000 RSI: ffffffff827e38b1 RDI: 00000000ffffffff   RBP: ffff88810005d000 R08: 00000000ffffdfff R09: ffffffff831051c8   R10: ffffffff83055220 R11: 0000000000000000 R12: ffff8881c2458c00   R13: ffff88811923c540 R14: ffff88811923c5e8 R15: ffff8881c1bd9680   FS:  0000000000000000(0000) GS:ffff88a04acd0000(0000) knlGS:0000000000000000   CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033   CR2: 00007f907c7a918c CR3: 0000000004024000 CR4: 0000000000350ef0   Call Trace:    <TASK>    ? srso_return_thunk+0x5/0x5f    btrfs_finish_ordered_io+0x4a/0x60 [btrfs]    btrfs_work_helper+0xf9/0x490 [btrfs]    process_one_work+0x204/0x590    ? srso_return_thunk+0x5/0x5f    worker_thread+0x1d6/0x3d0    ? __pfx_worker_thread+0x10/0x10    kthread+0x118/0x230    ? __pfx_kthread+0x10/0x10    ret_from_fork+0x205/0x260    ? __pfx_kthread+0x10/0x10    ret_from_fork_asm+0x1a/0x30    </TASK>  Consider process A calling writepages() with WB_SYNC_NONE. In zoned mode or for compressed writes, it locks several folios for delalloc and starts writing them out. Let's call the last locked folio folio X. Suppose the write range only partially covers folio X, leaving some pages dirty. Process A calls btrfs_subpage_set_writeback() when building a bio. This function call clears the TOWRITE tag of folio X, whose size = 8K and the block size = 4K. It is following state.     0     4K    8K    |/////|/////|  (flag: DIRTY, tag: DIRTY)    <-----> Process A will write this range.  Now suppose process B concurrently calls writepages() with WB_SYNC_ALL. It calls tag_pages_for_writeback() to tag dirty folios with PAGECACHE_TAG_TOWRITE. Since folio X is still dirty, it gets tagged. Then, B collects tagged folios using filemap_get_folios_tag() and must wait for folio X to be written before returning from writepages().     0     4K    8K    |/////|/////|  (flag: DIRTY, tag: DIRTY|TOWRITE)  However, between tagging and collecting, process A may call btrfs_subpage_set_writeback() and clear folio X's TOWRITE tag.    0     4K    8K    |     |/////|  (flag: DIRTY|WRITEBACK, tag: DIRTY)  As a result, process B won't see folio X in its batch, and returns without waiting for it. This breaks the WB_SYNC_ALL ordering requirement.  Fix this by using btrfs_subpage_set_writeback_keepwrite(), which retains the TOWRITE tag. We now manually clear the tag only after the folio becomes clean, via the xas operation.

CVE-2025-39789:

        In the Linux kernel, the following vulnerability has been resolved:  crypto: x86/aegis - Add missing error checks  The skcipher_walk functions can allocate memory and can fail, so checking for errors is necessary.

CVE-2025-39797:

        In the Linux kernel, the following vulnerability has been resolved:  xfrm: Duplicate SPI Handling  The issue originates when Strongswan initiates an XFRM_MSG_ALLOCSPI Netlink message, which triggers the kernel function xfrm_alloc_spi(). This function is expected to ensure uniqueness of the Security Parameter Index (SPI) for inbound Security Associations (SAs). However, it can return success even when the requested SPI is already in use, leading to duplicate SPIs assigned to multiple inbound SAs, differentiated only by their destination addresses.  This behavior causes inconsistencies during SPI lookups for inbound packets. Since the lookup may return an arbitrary SA among those with the same SPI, packet processing can fail, resulting in packet drops.  According to RFC 4301 section 4.4.2 , for inbound processing a unicast SA is uniquely identified by the SPI and optionally protocol.  Reproducing the Issue Reliably: To consistently reproduce the problem, restrict the available SPI range in charon.conf : spi_min = 0x10000000 spi_max = 0x10000002 This limits the system to only 2 usable SPI values. Next, create more than 2 Child SA. each using unique pair of src/dst address. As soon as the 3rd Child SA is initiated, it will be assigned a duplicate SPI, since the SPI pool is already exhausted. With a narrow SPI range, the issue is consistently reproducible. With a broader/default range, it becomes rare and unpredictable.  Current implementation: xfrm_spi_hash() lookup function computes hash using daddr, proto, and family. So if two SAs have the same SPI but different destination addresses, then they will: a. Hash into different buckets b. Be stored in different linked lists (byspi + h) c. Not be seen in the same hlist_for_each_entry_rcu() iteration. As a result, the lookup will result in NULL and kernel allows that Duplicate SPI  Proposed Change: xfrm_state_lookup_spi_proto() does a truly global search - across all states, regardless of hash bucket and matches SPI and proto.

CVE-2025-39810:

        In the Linux kernel, the following vulnerability has been resolved:  bnxt_en: Fix memory corruption when FW resources change during ifdown  bnxt_set_dflt_rings() assumes that it is always called before any TC has been created.  So it doesn't take bp->num_tc into account and assumes that it is always 0 or 1.  In the FW resource or capability change scenario, the FW will return flags in bnxt_hwrm_if_change() that will cause the driver to reinitialize and call bnxt_cancel_reservations().  This will lead to bnxt_init_dflt_ring_mode() calling bnxt_set_dflt_rings() and bp->num_tc may be greater than 1.  This will cause bp->tx_ring[] to be sized too small and cause memory corruption in bnxt_alloc_cp_rings().  Fix it by properly scaling the TX rings by bp->num_tc in the code paths mentioned above.  Add 2 helper functions to determine bp->tx_nr_rings and bp->tx_nr_rings_per_tc.

CVE-2025-39829:

        In the Linux kernel, the following vulnerability has been resolved:  trace/fgraph: Fix the warning caused by missing unregister notifier  This warning was triggered during testing on v6.16:  notifier callback ftrace_suspend_notifier_call already registered WARNING: CPU: 2 PID: 86 at kernel/notifier.c:23 notifier_chain_register+0x44/0xb0 ... Call Trace:  <TASK>  blocking_notifier_chain_register+0x34/0x60  register_ftrace_graph+0x330/0x410  ftrace_profile_write+0x1e9/0x340  vfs_write+0xf8/0x420  ? filp_flush+0x8a/0xa0  ? filp_close+0x1f/0x30  ? do_dup2+0xaf/0x160  ksys_write+0x65/0xe0  do_syscall_64+0xa4/0x260  entry_SYSCALL_64_after_hwframe+0x77/0x7f  When writing to the function_profile_enabled interface, the notifier was not unregistered after start_graph_tracing failed, causing a warning the next time function_profile_enabled was written.  Fixed by adding unregister_pm_notifier in the exception path.

CVE-2025-39850:

        In the Linux kernel, the following vulnerability has been resolved:  vxlan: Fix NPD in {arp,neigh}_reduce() when using nexthop objects  When the "proxy" option is enabled on a VXLAN device, the device will suppress ARP requests and IPv6 Neighbor Solicitation messages if it is able to reply on behalf of the remote host. That is, if a matching and valid neighbor entry is configured on the VXLAN device whose MAC address is not behind the "any" remote (0.0.0.0 / ::).  The code currently assumes that the FDB entry for the neighbor's MAC address points to a valid remote destination, but this is incorrect if the entry is associated with an FDB nexthop group. This can result in a NPD [1][3] which can be reproduced using [2][4].  Fix by checking that the remote destination exists before dereferencing it.  [1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 4 UID: 0 PID: 365 Comm: arping Not tainted 6.17.0-rc2-virtme-g2a89cb21162c #2 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:vxlan_xmit+0xb58/0x15f0 [...] Call Trace:  <TASK>  dev_hard_start_xmit+0x5d/0x1c0  __dev_queue_xmit+0x246/0xfd0  packet_sendmsg+0x113a/0x1850  __sock_sendmsg+0x38/0x70  __sys_sendto+0x126/0x180  __x64_sys_sendto+0x24/0x30  do_syscall_64+0xa4/0x260  entry_SYSCALL_64_after_hwframe+0x4b/0x53  [2]  #!/bin/bash   ip address add 192.0.2.1/32 dev lo   ip nexthop add id 1 via 192.0.2.2 fdb  ip nexthop add id 10 group 1 fdb   ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 4789 proxy   ip neigh add 192.0.2.3 lladdr 00:11:22:33:44:55 nud perm dev vx0   bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10   arping -b -c 1 -s 192.0.2.1 -I vx0 192.0.2.3  [3] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 13 UID: 0 PID: 372 Comm: ndisc6 Not tainted 6.17.0-rc2-virtmne-g6ee90cb26014 #3 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1v996), BIOS 1.17.0-4.fc41 04/01/2x014 RIP: 0010:vxlan_xmit+0x803/0x1600 [...] Call Trace:  <TASK>  dev_hard_start_xmit+0x5d/0x1c0  __dev_queue_xmit+0x246/0xfd0  ip6_finish_output2+0x210/0x6c0  ip6_finish_output+0x1af/0x2b0  ip6_mr_output+0x92/0x3e0  ip6_send_skb+0x30/0x90  rawv6_sendmsg+0xe6e/0x12e0  __sock_sendmsg+0x38/0x70  __sys_sendto+0x126/0x180  __x64_sys_sendto+0x24/0x30  do_syscall_64+0xa4/0x260  entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x7f383422ec77  [4]  #!/bin/bash   ip address add 2001:db8:1::1/128 dev lo   ip nexthop add id 1 via 2001:db8:1::1 fdb  ip nexthop add id 10 group 1 fdb   ip link add name vx0 up type vxlan id 10010 local 2001:db8:1::1 dstport 4789 proxy   ip neigh add 2001:db8:1::3 lladdr 00:11:22:33:44:55 nud perm dev vx0   bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10   ndisc6 -r 1 -s 2001:db8:1::1 -w 1 2001:db8:1::3 vx0

CVE-2025-39851:

        In the Linux kernel, the following vulnerability has been resolved:  vxlan: Fix NPD when refreshing an FDB entry with a nexthop object  VXLAN FDB entries can point to either a remote destination or an FDB nexthop group. The latter is usually used in EVPN deployments where learning is disabled.  However, when learning is enabled, an incoming packet might try to refresh an FDB entry that points to an FDB nexthop group and therefore does not have a remote. Such packets should be dropped, but they are only dropped after dereferencing the non-existent remote, resulting in a NPD [1] which can be reproduced using [2].  Fix by dropping such packets earlier. Remove the misleading comment from first_remote_rcu().  [1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:vxlan_snoop+0x98/0x1e0 [...] Call Trace:  <TASK>  vxlan_encap_bypass+0x209/0x240  encap_bypass_if_local+0xb1/0x100  vxlan_xmit_one+0x1375/0x17e0  vxlan_xmit+0x6b4/0x15f0  dev_hard_start_xmit+0x5d/0x1c0  __dev_queue_xmit+0x246/0xfd0  packet_sendmsg+0x113a/0x1850  __sock_sendmsg+0x38/0x70  __sys_sendto+0x126/0x180  __x64_sys_sendto+0x24/0x30  do_syscall_64+0xa4/0x260  entry_SYSCALL_64_after_hwframe+0x4b/0x53  [2]  #!/bin/bash   ip address add 192.0.2.1/32 dev lo  ip address add 192.0.2.2/32 dev lo   ip nexthop add id 1 via 192.0.2.3 fdb  ip nexthop add id 10 group 1 fdb   ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass  ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning   bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020  bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10   mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q

CVE-2025-39859:

        In the Linux kernel, the following vulnerability has been resolved:  ptp: ocp: fix use-after-free bugs causing by ptp_ocp_watchdog  The ptp_ocp_detach() only shuts down the watchdog timer if it is pending. However, if the timer handler is already running, the timer_delete_sync() is not called. This leads to race conditions where the devlink that contains the ptp_ocp is deallocated while the timer handler is still accessing it, resulting in use-after-free bugs. The following details one of the race scenarios.  (thread 1)                           | (thread 2) ptp_ocp_remove()                     |   ptp_ocp_detach()                   | ptp_ocp_watchdog()     if (timer_pending(&bp->watchdog))|   bp = timer_container_of()       timer_delete_sync()            |                                      |   devlink_free(devlink) //free       |                                      |   bp-> //use  Resolve this by unconditionally calling timer_delete_sync() to ensure the timer is reliably deactivated, preventing any access after free.

CVE-2025-39886:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: Tell memcg to use allow_spinning=false path in bpf_timer_init()  Currently, calling bpf_map_kmalloc_node() from __bpf_async_init() can cause various locking issues; see the following stack trace (edited for style) as one example:  ...  [10.011566]  do_raw_spin_lock.cold  [10.011570]  try_to_wake_up             (5) double-acquiring the same  [10.011575]  kick_pool                      rq_lock, causing a hardlockup  [10.011579]  __queue_work  [10.011582]  queue_work_on  [10.011585]  kernfs_notify  [10.011589]  cgroup_file_notify  [10.011593]  try_charge_memcg           (4) memcg accounting raises an  [10.011597]  obj_cgroup_charge_pages        MEMCG_MAX event  [10.011599]  obj_cgroup_charge_account  [10.011600]  __memcg_slab_post_alloc_hook  [10.011603]  __kmalloc_node_noprof ...  [10.011611]  bpf_map_kmalloc_node  [10.011612]  __bpf_async_init  [10.011615]  bpf_timer_init             (3) BPF calls bpf_timer_init()  [10.011617]  bpf_prog_xxxxxxxxxxxxxxxx_fcg_runnable  [10.011619]  bpf__sched_ext_ops_runnable  [10.011620]  enqueue_task_scx           (2) BPF runs with rq_lock held  [10.011622]  enqueue_task  [10.011626]  ttwu_do_activate  [10.011629]  sched_ttwu_pending         (1) grabs rq_lock ...  The above was reproduced on bpf-next (b338cf849ec8) by modifying ./tools/sched_ext/scx_flatcg.bpf.c to call bpf_timer_init() during ops.runnable(), and hacking the memcg accounting code a bit to make a bpf_timer_init() call more likely to raise an MEMCG_MAX event.  We have also run into other similar variants (both internally and on bpf-next), including double-acquiring cgroup_file_kn_lock, the same worker_pool::lock, etc.  As suggested by Shakeel, fix this by using __GFP_HIGH instead of GFP_ATOMIC in __bpf_async_init(), so that e.g. if try_charge_memcg() raises an MEMCG_MAX event, we call __memcg_memory_event() with @allow_spinning=false and avoid calling cgroup_file_notify() there.  Depends on mm patch "memcg: skip cgroup_file_notify if spinning is not allowed": https://lore.kernel.org/bpf/20250905201606.66198-1-shakeel.butt@linux.dev/  v0 approach s/bpf_map_kmalloc_node/bpf_mem_alloc/ https://lore.kernel.org/bpf/20250905061919.439648-1-yepeilin@google.com/ v1 approach: https://lore.kernel.org/bpf/20250905234547.862249-1-yepeilin@google.com/

CVE-2025-39910:

        In the Linux kernel, the following vulnerability has been resolved:  mm/vmalloc, mm/kasan: respect gfp mask in kasan_populate_vmalloc()  kasan_populate_vmalloc() and its helpers ignore the caller's gfp_mask and always allocate memory using the hardcoded GFP_KERNEL flag.  This makes them inconsistent with vmalloc(), which was recently extended to support GFP_NOFS and GFP_NOIO allocations.  Page table allocations performed during shadow population also ignore the external gfp_mask.  To preserve the intended semantics of GFP_NOFS and GFP_NOIO, wrap the apply_to_page_range() calls into the appropriate memalloc scope.  xfs calls vmalloc with GFP_NOFS, so this bug could lead to deadlock.  There was a report here https://lkml.kernel.org/r/686ea951.050a0220.385921.0016.GAE@google.com  This patch:  - Extends kasan_populate_vmalloc() and helpers to take gfp_mask;  - Passes gfp_mask down to alloc_pages_bulk() and __get_free_page();  - Enforces GFP_NOFS/NOIO semantics with memalloc_*_save()/restore()    around apply_to_page_range();  - Updates vmalloc.c and percpu allocator call sites accordingly.

CVE-2025-39927:

        In the Linux kernel, the following vulnerability has been resolved:  ceph: fix race condition validating r_parent before applying state  Add validation to ensure the cached parent directory inode matches the directory info in MDS replies. This prevents client-side race conditions where concurrent operations (e.g. rename) cause r_parent to become stale between request initiation and reply processing, which could lead to applying state changes to incorrect directory inodes.  [ idryomov: folded a kerneldoc fixup and a follow-up fix from Alex to   move CEPH_CAP_PIN reference when r_parent is updated:    When the parent directory lock is not held, req->r_parent can become   stale and is updated to point to the correct inode.  However, the   associated CEPH_CAP_PIN reference was not being adjusted.  The   CEPH_CAP_PIN is a reference on an inode that is tracked for   accounting purposes.  Moving this pin is important to keep the   accounting balanced. When the pin was not moved from the old parent   to the new one, it created two problems: The reference on the old,   stale parent was never released, causing a reference leak.   A reference for the new parent was never acquired, creating the risk   of a reference underflow later in ceph_mdsc_release_request().  This   patch corrects the logic by releasing the pin from the old parent and   acquiring it for the new parent when r_parent is switched.  This   ensures reference accounting stays balanced. ]

CVE-2025-39932:

        In the Linux kernel, the following vulnerability has been resolved:  smb: client: let smbd_destroy() call disable_work_sync(&info->post_send_credits_work)  In smbd_destroy() we may destroy the memory so we better wait until post_send_credits_work is no longer pending and will never be started again.  I actually just hit the case using rxe:  WARNING: CPU: 0 PID: 138 at drivers/infiniband/sw/rxe/rxe_verbs.c:1032 rxe_post_recv+0x1ee/0x480 [rdma_rxe] ... [ 5305.686979] [    T138]  smbd_post_recv+0x445/0xc10 [cifs] [ 5305.687135] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687149] [    T138]  ? __kasan_check_write+0x14/0x30 [ 5305.687185] [    T138]  ? __pfx_smbd_post_recv+0x10/0x10 [cifs] [ 5305.687329] [    T138]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 5305.687356] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687368] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687378] [    T138]  ? _raw_spin_unlock_irqrestore+0x11/0x60 [ 5305.687389] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687399] [    T138]  ? get_receive_buffer+0x168/0x210 [cifs] [ 5305.687555] [    T138]  smbd_post_send_credits+0x382/0x4b0 [cifs] [ 5305.687701] [    T138]  ? __pfx_smbd_post_send_credits+0x10/0x10 [cifs] [ 5305.687855] [    T138]  ? __pfx___schedule+0x10/0x10 [ 5305.687865] [    T138]  ? __pfx__raw_spin_lock_irq+0x10/0x10 [ 5305.687875] [    T138]  ? queue_delayed_work_on+0x8e/0xa0 [ 5305.687889] [    T138]  process_one_work+0x629/0xf80 [ 5305.687908] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5 [ 5305.687917] [    T138]  ? __kasan_check_write+0x14/0x30 [ 5305.687933] [    T138]  worker_thread+0x87f/0x1570 ...  It means rxe_post_recv was called after rdma_destroy_qp(). This happened because put_receive_buffer() was triggered by ib_drain_qp() and called: queue_work(info->workqueue, &info->post_send_credits_work);

CVE-2025-39933:

        In the Linux kernel, the following vulnerability has been resolved:  smb: client: let recv_done verify data_offset, data_length and remaining_data_length  This is inspired by the related server fixes.

CVE-2025-39940:

        In the Linux kernel, the following vulnerability has been resolved:  dm-stripe: fix a possible integer overflow  There's a possible integer overflow in stripe_io_hints if we have too large chunk size. Test if the overflow happened, and if it did, don't set limits->io_min and limits->io_opt;

CVE-2025-39947:

        In the Linux kernel, the following vulnerability has been resolved:  net/mlx5e: Harden uplink netdev access against device unbind  The function mlx5_uplink_netdev_get() gets the uplink netdevice pointer from mdev->mlx5e_res.uplink_netdev. However, the netdevice can be removed and its pointer cleared when unbound from the mlx5_core.eth driver. This results in a NULL pointer, causing a kernel panic.   BUG: unable to handle page fault for address: 0000000000001300  at RIP: 0010:mlx5e_vport_rep_load+0x22a/0x270 [mlx5_core]  Call Trace:   <TASK>   mlx5_esw_offloads_rep_load+0x68/0xe0 [mlx5_core]   esw_offloads_enable+0x593/0x910 [mlx5_core]   mlx5_eswitch_enable_locked+0x341/0x420 [mlx5_core]   mlx5_devlink_eswitch_mode_set+0x17e/0x3a0 [mlx5_core]   devlink_nl_eswitch_set_doit+0x60/0xd0   genl_family_rcv_msg_doit+0xe0/0x130   genl_rcv_msg+0x183/0x290   netlink_rcv_skb+0x4b/0xf0   genl_rcv+0x24/0x40   netlink_unicast+0x255/0x380   netlink_sendmsg+0x1f3/0x420   __sock_sendmsg+0x38/0x60   __sys_sendto+0x119/0x180   do_syscall_64+0x53/0x1d0   entry_SYSCALL_64_after_hwframe+0x4b/0x53  Ensure the pointer is valid before use by checking it for NULL. If it is valid, immediately call netdev_hold() to take a reference, and preventing the netdevice from being freed while it is in use.

CVE-2025-39952:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: wilc1000: avoid buffer overflow in WID string configuration  Fix the following copy overflow warning identified by Smatch checker.   drivers/net/wireless/microchip/wilc1000/wlan_cfg.c:184 wilc_wlan_parse_response_frame()         error: '__memcpy()' 'cfg->s[i]->str' copy overflow (512 vs 65537)  This patch introduces size check before accessing the memory buffer. The checks are base on the WID type of received data from the firmware. For WID string configuration, the size limit is determined by individual element size in 'struct wilc_cfg_str_vals' that is maintained in 'len' field of 'struct wilc_cfg_str'.

CVE-2025-39961:

        In the Linux kernel, the following vulnerability has been resolved:  iommu/amd/pgtbl: Fix possible race while increase page table level  The AMD IOMMU host page table implementation supports dynamic page table levels (up to 6 levels), starting with a 3-level configuration that expands based on IOVA address. The kernel maintains a root pointer and current page table level to enable proper page table walks in alloc_pte()/fetch_pte() operations.  The IOMMU IOVA allocator initially starts with 32-bit address and onces its exhuasted it switches to 64-bit address (max address is determined based on IOMMU and device DMA capability). To support larger IOVA, AMD IOMMU driver increases page table level.  But in unmap path (iommu_v1_unmap_pages()), fetch_pte() reads pgtable->[root/mode] without lock. So its possible that in exteme corner case, when increase_address_space() is updating pgtable->[root/mode], fetch_pte() reads wrong page table level (pgtable->mode). It does compare the value with level encoded in page table and returns NULL. This will result is iommu_unmap ops to fail and upper layer may retry/log WARN_ON.  CPU 0                                         CPU 1 ------                                       ------ map pages                                    unmap pages alloc_pte() -> increase_address_space()      iommu_v1_unmap_pages() -> fetch_pte()   pgtable->root = pte (new root value)                                              READ pgtable->[mode/root] 					       Reads new root, old mode   Updates mode (pgtable->mode += 1)  Since Page table level updates are infrequent and already synchronized with a spinlock, implement seqcount to enable lock-free read operations on the read path.

CVE-2025-39981:

        In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: MGMT: Fix possible UAFs  This attemps to fix possible UAFs caused by struct mgmt_pending being freed while still being processed like in the following trace, in order to fix mgmt_pending_valid is introduce and use to check if the mgmt_pending hasn't been removed from the pending list, on the complete callbacks it is used to check and in addtion remove the cmd from the list while holding mgmt_pending_lock to avoid TOCTOU problems since if the cmd is left on the list it can still be accessed and freed.  BUG: KASAN: slab-use-after-free in mgmt_add_adv_patterns_monitor_sync+0x35/0x50 net/bluetooth/mgmt.c:5223 Read of size 8 at addr ffff8880709d4dc0 by task kworker/u11:0/55  CPU: 0 UID: 0 PID: 55 Comm: kworker/u11:0 Not tainted 6.16.4 #2 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 Workqueue: hci0 hci_cmd_sync_work Call Trace:  <TASK>  dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120  print_address_description mm/kasan/report.c:378 [inline]  print_report+0xca/0x240 mm/kasan/report.c:482  kasan_report+0x118/0x150 mm/kasan/report.c:595  mgmt_add_adv_patterns_monitor_sync+0x35/0x50 net/bluetooth/mgmt.c:5223  hci_cmd_sync_work+0x210/0x3a0 net/bluetooth/hci_sync.c:332  process_one_work kernel/workqueue.c:3238 [inline]  process_scheduled_works+0xade/0x17b0 kernel/workqueue.c:3321  worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402  kthread+0x711/0x8a0 kernel/kthread.c:464  ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148  ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16.4/arch/x86/entry/entry_64.S:245  </TASK>  Allocated by task 12210:  kasan_save_stack mm/kasan/common.c:47 [inline]  kasan_save_track+0x3e/0x80 mm/kasan/common.c:68  poison_kmalloc_redzone mm/kasan/common.c:377 [inline]  __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394  kasan_kmalloc include/linux/kasan.h:260 [inline]  __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4364  kmalloc_noprof include/linux/slab.h:905 [inline]  kzalloc_noprof include/linux/slab.h:1039 [inline]  mgmt_pending_new+0x65/0x1e0 net/bluetooth/mgmt_util.c:269  mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296  __add_adv_patterns_monitor+0x130/0x200 net/bluetooth/mgmt.c:5247  add_adv_patterns_monitor+0x214/0x360 net/bluetooth/mgmt.c:5364  hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719  hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839  sock_sendmsg_nosec net/socket.c:714 [inline]  __sock_sendmsg+0x219/0x270 net/socket.c:729  sock_write_iter+0x258/0x330 net/socket.c:1133  new_sync_write fs/read_write.c:593 [inline]  vfs_write+0x5c9/0xb30 fs/read_write.c:686  ksys_write+0x145/0x250 fs/read_write.c:738  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]  do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94  entry_SYSCALL_64_after_hwframe+0x77/0x7f  Freed by task 12221:  kasan_save_stack mm/kasan/common.c:47 [inline]  kasan_save_track+0x3e/0x80 mm/kasan/common.c:68  kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576  poison_slab_object mm/kasan/common.c:247 [inline]  __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264  kasan_slab_free include/linux/kasan.h:233 [inline]  slab_free_hook mm/slub.c:2381 [inline]  slab_free mm/slub.c:4648 [inline]  kfree+0x18e/0x440 mm/slub.c:4847  mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline]  mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257  __mgmt_power_off+0x169/0x350 net/bluetooth/mgmt.c:9444  hci_dev_close_sync+0x754/0x1330 net/bluetooth/hci_sync.c:5290  hci_dev_do_close net/bluetooth/hci_core.c:501 [inline]  hci_dev_close+0x108/0x200 net/bluetooth/hci_core.c:526  sock_do_ioctl+0xd9/0x300 net/socket.c:1192  sock_ioctl+0x576/0x790 net/socket.c:1313  vfs_ioctl fs/ioctl.c:51 [inline]  __do_sys_ioctl fs/ioctl.c:907 [inline]  __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]  do_syscall_64+0xf ---truncated---

CVE-2025-39989:

        In the Linux kernel, the following vulnerability has been resolved:  x86/mce: use is_copy_from_user() to determine copy-from-user context  Patch series "mm/hwpoison: Fix regressions in memory failure handling", v4.  ## 1. What am I trying to do:  This patchset resolves two critical regressions related to memory failure handling that have appeared in the upstream kernel since version 5.17, as compared to 5.10 LTS.      - copyin case: poison found in user page while kernel copying from user space     - instr case: poison found while instruction fetching in user space  ## 2. What is the expected outcome and why  - For copyin case:  Kernel can recover from poison found where kernel is doing get_user() or copy_from_user() if those places get an error return and the kernel return -EFAULT to the process instead of crashing.  More specifily, MCE handler checks the fixup handler type to decide whether an in kernel #MC can be recovered.  When EX_TYPE_UACCESS is found, the PC jumps to recovery code specified in _ASM_EXTABLE_FAULT() and return a -EFAULT to user space.  - For instr case:  If a poison found while instruction fetching in user space, full recovery is possible.  User process takes #PF, Linux allocates a new page and fills by reading from storage.   ## 3. What actually happens and why  - For copyin case: kernel panic since v5.17  Commit 4c132d1d844a ("x86/futex: Remove .fixup usage") introduced a new extable fixup type, EX_TYPE_EFAULT_REG, and later patches updated the extable fixup type for copy-from-user operations, changing it from EX_TYPE_UACCESS to EX_TYPE_EFAULT_REG.  It breaks previous EX_TYPE_UACCESS handling when posion found in get_user() or copy_from_user().  - For instr case: user process is killed by a SIGBUS signal due to #CMCI   and #MCE race  When an uncorrected memory error is consumed there is a race between the CMCI from the memory controller reporting an uncorrected error with a UCNA signature, and the core reporting and SRAR signature machine check when the data is about to be consumed.  ### Background: why *UN*corrected errors tied to *C*MCI in Intel platform [1]  Prior to Icelake memory controllers reported patrol scrub events that detected a previously unseen uncorrected error in memory by signaling a broadcast machine check with an SRAO (Software Recoverable Action Optional) signature in the machine check bank.  This was overkill because it's not an urgent problem that no core is on the verge of consuming that bad data.  It's also found that multi SRAO UCE may cause nested MCE interrupts and finally become an IERR.  Hence, Intel downgrades the machine check bank signature of patrol scrub from SRAO to UCNA (Uncorrected, No Action required), and signal changed to #CMCI.  Just to add to the confusion, Linux does take an action (in uc_decode_notifier()) to try to offline the page despite the UC*NA* signature name.  ### Background: why #CMCI and #MCE race when poison is consuming in     Intel platform [1]  Having decided that CMCI/UCNA is the best action for patrol scrub errors, the memory controller uses it for reads too.  But the memory controller is executing asynchronously from the core, and can't tell the difference between a "real" read and a speculative read.  So it will do CMCI/UCNA if an error is found in any read.  Thus:  1) Core is clever and thinks address A is needed soon, issues a    speculative read.  2) Core finds it is going to use address A soon after sending the read    request  3) The CMCI from the memory controller is in a race with MCE from the    core that will soon try to retire the load from address A.  Quite often (because speculation has got better) the CMCI from the memory controller is delivered before the core is committed to the instruction reading address A, so the interrupt is taken, and Linux offlines the page (marking it as poison).   ## Why user process is killed for instr case  Commit 046545a661af ("mm/hwpoison: fix error page recovered but reported "not ---truncated---

CVE-2025-39990:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: Check the helper function is valid in get_helper_proto  kernel test robot reported verifier bug [1] where the helper func pointer could be NULL due to disabled config option.  As Alexei suggested we could check on that in get_helper_proto directly. Marking tail_call helper func with BPF_PTR_POISON, because it is unused by design.    [1] https://lore.kernel.org/oe-lkp/202507160818.68358831-lkp@intel.com

CVE-2025-40003:

        In the Linux kernel, the following vulnerability has been resolved:  net: mscc: ocelot: Fix use-after-free caused by cyclic delayed work  The origin code calls cancel_delayed_work() in ocelot_stats_deinit() to cancel the cyclic delayed work item ocelot->stats_work. However, cancel_delayed_work() may fail to cancel the work item if it is already executing. While destroy_workqueue() does wait for all pending work items in the work queue to complete before destroying the work queue, it cannot prevent the delayed work item from being rescheduled within the ocelot_check_stats_work() function. This limitation exists because the delayed work item is only enqueued into the work queue after its timer expires. Before the timer expiration, destroy_workqueue() has no visibility of this pending work item. Once the work queue appears empty, destroy_workqueue() proceeds with destruction. When the timer eventually expires, the delayed work item gets queued again, leading to the following warning:  workqueue: cannot queue ocelot_check_stats_work on wq ocelot-switch-stats WARNING: CPU: 2 PID: 0 at kernel/workqueue.c:2255 __queue_work+0x875/0xaf0 ... RIP: 0010:__queue_work+0x875/0xaf0 ... RSP: 0018:ffff88806d108b10 EFLAGS: 00010086 RAX: 0000000000000000 RBX: 0000000000000101 RCX: 0000000000000027 RDX: 0000000000000027 RSI: 0000000000000004 RDI: ffff88806d123e88 RBP: ffffffff813c3170 R08: 0000000000000000 R09: ffffed100da247d2 R10: ffffed100da247d1 R11: ffff88806d123e8b R12: ffff88800c00f000 R13: ffff88800d7285c0 R14: ffff88806d0a5580 R15: ffff88800d7285a0 FS:  0000000000000000(0000) GS:ffff8880e5725000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe18e45ea10 CR3: 0000000005e6c000 CR4: 00000000000006f0 Call Trace:  <IRQ>  ? kasan_report+0xc6/0xf0  ? __pfx_delayed_work_timer_fn+0x10/0x10  ? __pfx_delayed_work_timer_fn+0x10/0x10  call_timer_fn+0x25/0x1c0  __run_timer_base.part.0+0x3be/0x8c0  ? __pfx_delayed_work_timer_fn+0x10/0x10  ? rcu_sched_clock_irq+0xb06/0x27d0  ? __pfx___run_timer_base.part.0+0x10/0x10  ? try_to_wake_up+0xb15/0x1960  ? _raw_spin_lock_irq+0x80/0xe0  ? __pfx__raw_spin_lock_irq+0x10/0x10  tmigr_handle_remote_up+0x603/0x7e0  ? __pfx_tmigr_handle_remote_up+0x10/0x10  ? sched_balance_trigger+0x1c0/0x9f0  ? sched_tick+0x221/0x5a0  ? _raw_spin_lock_irq+0x80/0xe0  ? __pfx__raw_spin_lock_irq+0x10/0x10  ? tick_nohz_handler+0x339/0x440  ? __pfx_tmigr_handle_remote_up+0x10/0x10  __walk_groups.isra.0+0x42/0x150  tmigr_handle_remote+0x1f4/0x2e0  ? __pfx_tmigr_handle_remote+0x10/0x10  ? ktime_get+0x60/0x140  ? lapic_next_event+0x11/0x20  ? clockevents_program_event+0x1d4/0x2a0  ? hrtimer_interrupt+0x322/0x780  handle_softirqs+0x16a/0x550  irq_exit_rcu+0xaf/0xe0  sysvec_apic_timer_interrupt+0x70/0x80  </IRQ> ...  The following diagram reveals the cause of the above warning:  CPU 0 (remove)             | CPU 1 (delayed work callback) mscc_ocelot_remove()       |   ocelot_deinit()          | ocelot_check_stats_work()     ocelot_stats_deinit()  |       cancel_delayed_work()|   ...                            |   queue_delayed_work()       destroy_workqueue()  | (wait a time)                            | __queue_work() //UAF  The above scenario actually constitutes a UAF vulnerability.  The ocelot_stats_deinit() is only invoked when initialization failure or resource destruction, so we must ensure that any delayed work items cannot be rescheduled.  Replace cancel_delayed_work() with disable_delayed_work_sync() to guarantee proper cancellation of the delayed work item and ensure completion of any currently executing work before the workqueue is deallocated.  A deadlock concern was considered: ocelot_stats_deinit() is called in a process context and is not holding any locks that the delayed work item might also need. Therefore, the use of the _sync() variant is safe here.  This bug was identified through static analysis. To reproduce the issue and validate the fix, I simulated ocelot-swit ---truncated---

CVE-2025-40025:

        In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to do sanity check on node footer for non inode dnode  As syzbot reported below:  ------------[ cut here ]------------ kernel BUG at fs/f2fs/file.c:1243! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 5354 Comm: syz.0.0 Not tainted 6.17.0-rc1-syzkaller-00211-g90d970cade8e #0 PREEMPT(full) RIP: 0010:f2fs_truncate_hole+0x69e/0x6c0 fs/f2fs/file.c:1243 Call Trace:  <TASK>  f2fs_punch_hole+0x2db/0x330 fs/f2fs/file.c:1306  f2fs_fallocate+0x546/0x990 fs/f2fs/file.c:2018  vfs_fallocate+0x666/0x7e0 fs/open.c:342  ksys_fallocate fs/open.c:366 [inline]  __do_sys_fallocate fs/open.c:371 [inline]  __se_sys_fallocate fs/open.c:369 [inline]  __x64_sys_fallocate+0xc0/0x110 fs/open.c:369  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]  do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94  entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f1e65f8ebe9  w/ a fuzzed image, f2fs may encounter panic due to it detects inconsistent truncation range in direct node in f2fs_truncate_hole().  The root cause is: a non-inode dnode may has the same footer.ino and footer.nid, so the dnode will be parsed as an inode, then ADDRS_PER_PAGE() may return wrong blkaddr count which may be 923 typically, by chance, dn.ofs_in_node is equal to 923, then count can be calculated to 0 in below statement, later it will trigger panic w/ f2fs_bug_on(, count == 0 || ...).  	count = min(end_offset - dn.ofs_in_node, pg_end - pg_start);  This patch introduces a new node_type NODE_TYPE_NON_INODE, then allowing passing the new_type to sanity_check_node_footer in f2fs_get_node_folio() to detect corruption that a non-inode dnode has the same footer.ino and footer.nid.  Scripts to reproduce: mkfs.f2fs -f /dev/vdb mount /dev/vdb /mnt/f2fs touch /mnt/f2fs/foo touch /mnt/f2fs/bar dd if=/dev/zero of=/mnt/f2fs/foo bs=1M count=8 umount /mnt/f2fs inject.f2fs --node --mb i_nid --nid 4 --idx 0 --val 5 /dev/vdb mount /dev/vdb /mnt/f2fs xfs_io /mnt/f2fs/foo -c "fpunch 6984k 4k"

CVE-2025-40057:

        In the Linux kernel, the following vulnerability has been resolved:  ptp: Add a upper bound on max_vclocks  syzbot reported WARNING in max_vclocks_store.  This occurs when the argument max is too large for kcalloc to handle.  Extend the guard to guard against values that are too large for kcalloc

CVE-2025-40065:

        In the Linux kernel, the following vulnerability has been resolved:  RISC-V: KVM: Write hgatp register with valid mode bits  According to the RISC-V Privileged Architecture Spec, when MODE=Bare is selected,software must write zero to the remaining fields of hgatp.  We have detected the valid mode supported by the HW before, So using a valid mode to detect how many vmid bits are supported.

CVE-2025-40071:

        In the Linux kernel, the following vulnerability has been resolved:  tty: n_gsm: Don't block input queue by waiting MSC  Currently gsm_queue() processes incoming frames and when opening a DLC channel it calls gsm_dlci_open() which calls gsm_modem_update(). If basic mode is used it calls gsm_modem_upd_via_msc() and it cannot block the input queue by waiting the response to come into the same input queue.  Instead allow sending Modem Status Command without waiting for remote end to respond. Define a new function gsm_modem_send_initial_msc() for this purpose. As MSC is only valid for basic encoding, it does not do anything for advanced or when convergence layer type 2 is used.

CVE-2025-40075:

        In the Linux kernel, the following vulnerability has been resolved:  tcp_metrics: use dst_dev_net_rcu()  Replace three dst_dev() with a lockdep enabled helper.

CVE-2025-40077:

        In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to avoid overflow while left shift operation  Should cast type of folio->index from pgoff_t to loff_t to avoid overflow while left shift operation.

CVE-2025-40136:

        In the Linux kernel, the following vulnerability has been resolved:  crypto: hisilicon/qm - request reserved interrupt for virtual function  The device interrupt vector 3 is an error interrupt for physical function and a reserved interrupt for virtual function. However, the driver has not registered the reserved interrupt for virtual function. When allocating interrupts, the number of interrupts is allocated based on powers of two, which includes this interrupt. When the system enables GICv4 and the virtual function passthrough to the virtual machine, releasing the interrupt in the driver triggers a warning.  The WARNING report is: WARNING: CPU: 62 PID: 14889 at arch/arm64/kvm/vgic/vgic-its.c:852 its_free_ite+0x94/0xb4  Therefore, register a reserved interrupt for VF and set the IRQF_NO_AUTOEN flag to avoid that warning.

CVE-2025-40137:

        In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to truncate first page in error path of f2fs_truncate()  syzbot reports a bug as below:  loop0: detected capacity change from 0 to 40427 F2FS-fs (loop0): Wrong SSA boundary, start(3584) end(4096) blocks(3072) F2FS-fs (loop0): Can't find valid F2FS filesystem in 1th superblock F2FS-fs (loop0): invalid crc value F2FS-fs (loop0): f2fs_convert_inline_folio: corrupted inline inode ino=3, i_addr[0]:0x1601, run fsck to fix. ------------[ cut here ]------------ kernel BUG at fs/inode.c:753! RIP: 0010:clear_inode+0x169/0x190 fs/inode.c:753 Call Trace:  <TASK>  evict+0x504/0x9c0 fs/inode.c:810  f2fs_fill_super+0x5612/0x6fa0 fs/f2fs/super.c:5047  get_tree_bdev_flags+0x40e/0x4d0 fs/super.c:1692  vfs_get_tree+0x8f/0x2b0 fs/super.c:1815  do_new_mount+0x2a2/0x9e0 fs/namespace.c:3808  do_mount fs/namespace.c:4136 [inline]  __do_sys_mount fs/namespace.c:4347 [inline]  __se_sys_mount+0x317/0x410 fs/namespace.c:4324  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]  do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94  entry_SYSCALL_64_after_hwframe+0x77/0x7f  During f2fs_evict_inode(), clear_inode() detects that we missed to truncate all page cache before destorying inode, that is because in below path, we will create page #0 in cache, but missed to drop it in error path, let's fix it.  - evict  - f2fs_evict_inode   - f2fs_truncate    - f2fs_convert_inline_inode     - f2fs_grab_cache_folio     : create page #0 in cache     - f2fs_convert_inline_folio     : sanity check failed, return -EFSCORRUPTED   - clear_inode detects that inode->i_data.nrpages is not zero

CVE-2025-40146:

        In the Linux kernel, the following vulnerability has been resolved:  blk-mq: fix potential deadlock while nr_requests grown  Allocate and free sched_tags while queue is freezed can deadlock[1], this is a long term problem, hence allocate memory before freezing queue and free memory after queue is unfreezed.  [1] https://lore.kernel.org/all/0659ea8d-a463-47c8-9180-43c719e106eb@linux.ibm.com/

CVE-2025-40158:

        In the Linux kernel, the following vulnerability has been resolved:  ipv6: use RCU in ip6_output()  Use RCU in ip6_output() in order to use dst_dev_rcu() to prevent possible UAF.  We can remove rcu_read_lock()/rcu_read_unlock() pairs from ip6_finish_output2().

CVE-2025-40160:

        In the Linux kernel, the following vulnerability has been resolved:  xen/events: Return -EEXIST for bound VIRQs  Change find_virq() to return -EEXIST when a VIRQ is bound to a different CPU than the one passed in.  With that, remove the BUG_ON() from bind_virq_to_irq() to propogate the error upwards.  Some VIRQs are per-cpu, but others are per-domain or global.  Those must be bound to CPU0 and can then migrate elsewhere.  The lookup for per-domain and global will probably fail when migrated off CPU 0, especially when the current CPU is tracked.  This now returns -EEXIST instead of BUG_ON().  A second call to bind a per-domain or global VIRQ is not expected, but make it non-fatal to avoid trying to look up the irq, since we don't know which per_cpu(virq_to_irq) it will be in.

CVE-2025-40170:

        In the Linux kernel, the following vulnerability has been resolved:  net: use dst_dev_rcu() in sk_setup_caps()  Use RCU to protect accesses to dst->dev from sk_setup_caps() and sk_dst_gso_max_size().  Also use dst_dev_rcu() in ip6_dst_mtu_maybe_forward(), and ip_dst_mtu_maybe_forward().  ip4_dst_hoplimit() can use dst_dev_net_rcu().

CVE-2025-40180:

        In the Linux kernel, the following vulnerability has been resolved:  mailbox: zynqmp-ipi: Fix out-of-bounds access in mailbox cleanup loop  The cleanup loop was starting at the wrong array index, causing out-of-bounds access. Start the loop at the correct index for zero-indexed arrays to prevent accessing memory beyond the allocated array bounds.

CVE-2025-40247:

        In the Linux kernel, the following vulnerability has been resolved:  drm/msm: Fix pgtable prealloc error path  The following splat was reported:      Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010     Mem abort info:       ESR = 0x0000000096000004       EC = 0x25: DABT (current EL), IL = 32 bits       SET = 0, FnV = 0       EA = 0, S1PTW = 0       FSC = 0x04: level 0 translation fault     Data abort info:       ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000       CM = 0, WnR = 0, TnD = 0, TagAccess = 0       GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0     user pgtable: 4k pages, 48-bit VAs, pgdp=00000008d0fd8000     [0000000000000010] pgd=0000000000000000, p4d=0000000000000000     Internal error: Oops: 0000000096000004 [#1]  SMP     CPU: 5 UID: 1000 PID: 149076 Comm: Xwayland Tainted: G S                  6.16.0-rc2-00809-g0b6974bb4134-dirty #367 PREEMPT     Tainted: [S]=CPU_OUT_OF_SPEC     Hardware name: Qualcomm Technologies, Inc. SM8650 HDK (DT)     pstate: 83400005 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)     pc : build_detached_freelist+0x28/0x224     lr : kmem_cache_free_bulk.part.0+0x38/0x244     sp : ffff000a508c7a20     x29: ffff000a508c7a20 x28: ffff000a508c7d50 x27: ffffc4e49d16f350     x26: 0000000000000058 x25: 00000000fffffffc x24: 0000000000000000     x23: ffff00098c4e1450 x22: 00000000fffffffc x21: 0000000000000000     x20: ffff000a508c7af8 x19: 0000000000000002 x18: 00000000000003e8     x17: ffff000809523850 x16: ffff000809523820 x15: 0000000000401640     x14: ffff000809371140 x13: 0000000000000130 x12: ffff0008b5711e30     x11: 00000000001058fa x10: 0000000000000a80 x9 : ffff000a508c7940     x8 : ffff000809371ba0 x7 : 781fffe033087fff x6 : 0000000000000000     x5 : ffff0008003cd000 x4 : 781fffe033083fff x3 : ffff000a508c7af8     x2 : fffffdffc0000000 x1 : 0001000000000000 x0 : ffff0008001a6a00     Call trace:      build_detached_freelist+0x28/0x224 (P)      kmem_cache_free_bulk.part.0+0x38/0x244      kmem_cache_free_bulk+0x10/0x1c      msm_iommu_pagetable_prealloc_cleanup+0x3c/0xd0      msm_vma_job_free+0x30/0x240      msm_ioctl_vm_bind+0x1d0/0x9a0      drm_ioctl_kernel+0x84/0x104      drm_ioctl+0x358/0x4d4      __arm64_sys_ioctl+0x8c/0xe0      invoke_syscall+0x44/0x100      el0_svc_common.constprop.0+0x3c/0xe0      do_el0_svc+0x18/0x20      el0_svc+0x30/0x100      el0t_64_sync_handler+0x104/0x130      el0t_64_sync+0x170/0x174     Code: aa0203f5 b26287e2 f2dfbfe2 aa0303f4 (f8737ab6)     ---[ end trace 0000000000000000 ]---  Since msm_vma_job_free() is called directly from the ioctl, this looks like an error path cleanup issue.  Which I think results from prealloc_cleanup() called without a preceding successful prealloc_allocate() call.  So handle that case better.  Patchwork: https://patchwork.freedesktop.org/patch/678677/

CVE-2025-40266:

        In the Linux kernel, the following vulnerability has been resolved:  KVM: arm64: Check the untrusted offset in FF-A memory share  Verify the offset to prevent OOB access in the hypervisor FF-A buffer in case an untrusted large enough value [U32_MAX - sizeof(struct ffa_composite_mem_region) + 1, U32_MAX] is set from the host kernel.

CVE-2025-40268:

        In the Linux kernel, the following vulnerability has been resolved:  cifs: client: fix memory leak in smb3_fs_context_parse_param  The user calls fsconfig twice, but when the program exits, free() only frees ctx->source for the second fsconfig, not the first. Regarding fc->source, there is no code in the fs context related to its memory reclamation.  To fix this memory leak, release the source memory corresponding to ctx or fc before each parsing.  syzbot reported: BUG: memory leak unreferenced object 0xffff888128afa360 (size 96):   backtrace (crc 79c9c7ba):     kstrdup+0x3c/0x80 mm/util.c:84     smb3_fs_context_parse_param+0x229b/0x36c0 fs/smb/client/fs_context.c:1444  BUG: memory leak unreferenced object 0xffff888112c7d900 (size 96):   backtrace (crc 79c9c7ba):     smb3_fs_context_fullpath+0x70/0x1b0 fs/smb/client/fs_context.c:629     smb3_fs_context_parse_param+0x2266/0x36c0 fs/smb/client/fs_context.c:1438

CVE-2025-40289:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu: hide VRAM sysfs attributes on GPUs without VRAM  Otherwise accessing them can cause a crash.

CVE-2025-40303:

        In the Linux kernel, the following vulnerability has been resolved:  btrfs: ensure no dirty metadata is written back for an fs with errors  [BUG] During development of a minor feature (make sure all btrfs_bio::end_io() is called in task context), I noticed a crash in generic/388, where metadata writes triggered new works after btrfs_stop_all_workers().  It turns out that it can even happen without any code modification, just using RAID5 for metadata and the same workload from generic/388 is going to trigger the use-after-free.  [CAUSE] If btrfs hits an error, the fs is marked as error, no new transaction is allowed thus metadata is in a frozen state.  But there are some metadata modifications before that error, and they are still in the btree inode page cache.  Since there will be no real transaction commit, all those dirty folios are just kept as is in the page cache, and they can not be invalidated by invalidate_inode_pages2() call inside close_ctree(), because they are dirty.  And finally after btrfs_stop_all_workers(), we call iput() on btree inode, which triggers writeback of those dirty metadata.  And if the fs is using RAID56 metadata, this will trigger RMW and queue new works into rmw_workers, which is already stopped, causing warning from queue_work() and use-after-free.  [FIX] Add a special handling for write_one_eb(), that if the fs is already in an error state, immediately mark the bbio as failure, instead of really submitting them.  Then during close_ctree(), iput() will just discard all those dirty tree blocks without really writing them back, thus no more new jobs for already stopped-and-freed workqueues.  The extra discard in write_one_eb() also acts as an extra safenet. E.g. the transaction abort is triggered by some extent/free space tree corruptions, and since extent/free space tree is already corrupted some tree blocks may be allocated where they shouldn't be (overwriting existing tree blocks). In that case writing them back will further corrupting the fs.

CVE-2025-40311:

        In the Linux kernel, the following vulnerability has been resolved:  accel/habanalabs: support mapping cb with vmalloc-backed coherent memory  When IOMMU is enabled, dma_alloc_coherent() with GFP_USER may return addresses from the vmalloc range. If such an address is mapped without VM_MIXEDMAP, vm_insert_page() will trigger a BUG_ON due to the VM_PFNMAP restriction.  Fix this by checking for vmalloc addresses and setting VM_MIXEDMAP in the VMA before mapping. This ensures safe mapping and avoids kernel crashes. The memory is still driver-allocated and cannot be accessed directly by userspace.

CVE-2025-40325:

        In the Linux kernel, the following vulnerability has been resolved:  md/raid10: wait barrier before returning discard request with REQ_NOWAIT  raid10_handle_discard should wait barrier before returning a discard bio which has REQ_NOWAIT. And there is no need to print warning calltrace if a discard bio has REQ_NOWAIT flag. Quality engineer usually checks dmesg and reports error if dmesg has warning/error calltrace.

CVE-2025-40328:

        In the Linux kernel, the following vulnerability has been resolved:  smb: client: fix potential UAF in smb2_close_cached_fid()  find_or_create_cached_dir() could grab a new reference after kref_put() had seen the refcount drop to zero but before cfid_list_lock is acquired in smb2_close_cached_fid(), leading to use-after-free.  Switch to kref_put_lock() so cfid_release() is called with cfid_list_lock held, closing that gap.

CVE-2025-40333:

        In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix infinite loop in __insert_extent_tree()  When we get wrong extent info data, and look up extent_node in rb tree, it will cause infinite loop (CONFIG_F2FS_CHECK_FS=n). Avoiding this by return NULL and print some kernel messages in that case.

CVE-2025-40337:

        In the Linux kernel, the following vulnerability has been resolved:  net: stmmac: Correctly handle Rx checksum offload errors  The stmmac_rx function would previously set skb->ip_summed to CHECKSUM_UNNECESSARY if hardware checksum offload (CoE) was enabled and the packet was of a known IP ethertype.  However, this logic failed to check if the hardware had actually reported a checksum error. The hardware status, indicating a header or payload checksum failure, was being ignored at this stage. This could cause corrupt packets to be passed up the network stack as valid.  This patch corrects the logic by checking the `csum_none` status flag, which is set when the hardware reports a checksum error. If this flag is set, skb->ip_summed is now correctly set to CHECKSUM_NONE, ensuring the kernel's network stack will perform its own validation and properly handle the corrupt packet.

CVE-2025-40338:

        In the Linux kernel, the following vulnerability has been resolved:  ASoC: Intel: avs: Do not share the name pointer between components  By sharing 'name' directly, tearing down components may lead to use-after-free errors. Duplicate the name to avoid that.  At the same time, update the order of operations - since commit cee28113db17 ("ASoC: dmaengine_pcm: Allow passing component name via config") the framework does not override component->name if set before invoking the initializer.

CVE-2025-40339:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu: fix nullptr err of vm_handle_moved  If a amdgpu_bo_va is fpriv->prt_va, the bo of this one is always NULL. So, such kind of amdgpu_bo_va should be updated separately before amdgpu_vm_handle_moved.

CVE-2025-40354:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: increase max link count and fix link->enc NULL pointer access  [why] 1.) dc->links[MAX_LINKS] array size smaller than actual requested. max_connector + max_dpia + 4 virtual = 14. increase from 12 to 14.  2.) hw_init() access null LINK_ENC for dpia non display_endpoint.  (cherry picked from commit d7f5a61e1b04ed87b008c8d327649d184dc5bb45)

CVE-2025-40355:

        In the Linux kernel, the following vulnerability has been resolved:  sysfs: check visibility before changing group attribute ownership  Since commit 0c17270f9b92 ("net: sysfs: Implement is_visible for phys_(port_id, port_name, switch_id)"), __dev_change_net_namespace() can hit WARN_ON() when trying to change owner of a file that isn't visible. See the trace below:   WARNING: CPU: 6 PID: 2938 at net/core/dev.c:12410 __dev_change_net_namespace+0xb89/0xc30  CPU: 6 UID: 0 PID: 2938 Comm: incusd Not tainted 6.17.1-1-mainline #1 PREEMPT(full)  4b783b4a638669fb644857f484487d17cb45ed1f  Hardware name: Framework Laptop 13 (AMD Ryzen 7040Series)/FRANMDCP07, BIOS 03.07 02/19/2025  RIP: 0010:__dev_change_net_namespace+0xb89/0xc30  [...]  Call Trace:   <TASK>   ? if6_seq_show+0x30/0x50   do_setlink.isra.0+0xc7/0x1270   ? __nla_validate_parse+0x5c/0xcc0   ? security_capable+0x94/0x1a0   rtnl_newlink+0x858/0xc20   ? update_curr+0x8e/0x1c0   ? update_entity_lag+0x71/0x80   ? sched_balance_newidle+0x358/0x450   ? psi_task_switch+0x113/0x2a0   ? __pfx_rtnl_newlink+0x10/0x10   rtnetlink_rcv_msg+0x346/0x3e0   ? sched_clock+0x10/0x30   ? __pfx_rtnetlink_rcv_msg+0x10/0x10   netlink_rcv_skb+0x59/0x110   netlink_unicast+0x285/0x3c0   ? __alloc_skb+0xdb/0x1a0   netlink_sendmsg+0x20d/0x430   ____sys_sendmsg+0x39f/0x3d0   ? import_iovec+0x2f/0x40   ___sys_sendmsg+0x99/0xe0   __sys_sendmsg+0x8a/0xf0   do_syscall_64+0x81/0x970   ? __sys_bind+0xe3/0x110   ? syscall_exit_work+0x143/0x1b0   ? do_syscall_64+0x244/0x970   ? sock_alloc_file+0x63/0xc0   ? syscall_exit_work+0x143/0x1b0   ? do_syscall_64+0x244/0x970   ? alloc_fd+0x12e/0x190   ? put_unused_fd+0x2a/0x70   ? do_sys_openat2+0xa2/0xe0   ? syscall_exit_work+0x143/0x1b0   ? do_syscall_64+0x244/0x970   ? exc_page_fault+0x7e/0x1a0   entry_SYSCALL_64_after_hwframe+0x76/0x7e  [...]   </TASK>  Fix this by checking is_visible() before trying to touch the attribute.

CVE-2025-68183:

        In the Linux kernel, the following vulnerability has been resolved:  ima: don't clear IMA_DIGSIG flag when setting or removing non-IMA xattr  Currently when both IMA and EVM are in fix mode, the IMA signature will be reset to IMA hash if a program first stores IMA signature in security.ima and then writes/removes some other security xattr for the file.  For example, on Fedora, after booting the kernel with "ima_appraise=fix evm=fix ima_policy=appraise_tcb" and installing rpm-plugin-ima, installing/reinstalling a package will not make good reference IMA signature generated. Instead IMA hash is generated,      # getfattr -m - -d -e hex /usr/bin/bash     # file: usr/bin/bash     security.ima=0x0404...  This happens because when setting security.selinux, the IMA_DIGSIG flag that had been set early was cleared. As a result, IMA hash is generated when the file is closed.  Similarly, IMA signature can be cleared on file close after removing security xattr like security.evm or setting/removing ACL.  Prevent replacing the IMA file signature with a file hash, by preventing the IMA_DIGSIG flag from being reset.  Here's a minimal C reproducer which sets security.selinux as the last step which can also replaced by removing security.evm or setting ACL,      #include <stdio.h>     #include <sys/xattr.h>     #include <fcntl.h>     #include <unistd.h>     #include <string.h>     #include <stdlib.h>      int main() {         const char* file_path = "/usr/sbin/test_binary";         const char* hex_string = "030204d33204490066306402304";         int length = strlen(hex_string);         char* ima_attr_value;         int fd;          fd = open(file_path, O_WRONLY|O_CREAT|O_EXCL, 0644);         if (fd == -1) {             perror("Error opening file");             return 1;         }          ima_attr_value = (char*)malloc(length / 2 );         for (int i = 0, j = 0; i < length; i += 2, j++) {             sscanf(hex_string + i, "%2hhx", &ima_attr_value[j]);         }          if (fsetxattr(fd, "security.ima", ima_attr_value, length/2, 0) == -1) {             perror("Error setting extended attribute");             close(fd);             return 1;         }          const char* selinux_value= "system_u:object_r:bin_t:s0";         if (fsetxattr(fd, "security.selinux", selinux_value, strlen(selinux_value), 0) == -1) {             perror("Error setting extended attribute");             close(fd);             return 1;         }          close(fd);          return 0;     }

CVE-2025-68188:

        In the Linux kernel, the following vulnerability has been resolved:  tcp: use dst_dev_rcu() in tcp_fastopen_active_disable_ofo_check()  Use RCU to avoid a pair of atomic operations and a potential UAF on dst_dev()->flags.

CVE-2025-68209:

        In the Linux kernel, the following vulnerability has been resolved:  mlx5: Fix default values in create CQ  Currently, CQs without a completion function are assigned the mlx5_add_cq_to_tasklet function by default. This is problematic since only user CQs created through the mlx5_ib driver are intended to use this function.  Additionally, all CQs that will use doorbells instead of polling for completions must call mlx5_cq_arm. However, the default CQ creation flow leaves a valid value in the CQ's arm_db field, allowing FW to send interrupts to polling-only CQs in certain corner cases.  These two factors would allow a polling-only kernel CQ to be triggered by an EQ interrupt and call a completion function intended only for user CQs, causing a null pointer exception.  Some areas in the driver have prevented this issue with one-off fixes but did not address the root cause.  This patch fixes the described issue by adding defaults to the create CQ flow. It adds a default dummy completion function to protect against null pointer exceptions, and it sets an invalid command sequence number by default in kernel CQs to prevent the FW from sending an interrupt to the CQ until it is armed. User CQs are responsible for their own initialization values.  Callers of mlx5_core_create_cq are responsible for changing the completion function and arming the CQ per their needs.

CVE-2025-68219:

        In the Linux kernel, the following vulnerability has been resolved:  cifs: fix memory leak in smb3_fs_context_parse_param error path  Add proper cleanup of ctx->source and fc->source to the cifs_parse_mount_err error handler. This ensures that memory allocated for the source strings is correctly freed on all error paths, matching the cleanup already performed in the success path by smb3_cleanup_fs_context_contents(). Pointers are also set to NULL after freeing to prevent potential double-free issues.  This change fixes a memory leak originally detected by syzbot. The leak occurred when processing Opt_source mount options if an error happened after ctx->source and fc->source were successfully allocated but before the function completed.  The specific leak sequence was: 1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory 2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory 3. A subsequent error jumps to cifs_parse_mount_err 4. The old error handler freed passwords but not the source strings, causing the memory to leak.  This issue was not addressed by commit e8c73eb7db0a ("cifs: client: fix memory leak in smb3_fs_context_parse_param"), which only fixed leaks from repeated fsconfig() calls but not this error path.  Patch updated with minor change suggested by kernel test robot

CVE-2025-68236:

        In the Linux kernel, the following vulnerability has been resolved:  scsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3)  According to UFS specifications, the power-off sequence for a UFS device includes:   - Sending an SSU command with Power_Condition=3 and await a response.   - Asserting RST_N low.   - Turning off REF_CLK.   - Turning off VCC.   - Turning off VCCQ/VCCQ2.  As part of ufs shutdown, after the SSU command completion, asserting hardware reset (HWRST) triggers the device firmware to wake up and execute its reset routine. This routine initializes hardware blocks and takes a few milliseconds to complete. During this time, the ICCQ draws a large current.  This large ICCQ current may cause issues for the regulator which is supplying power to UFS, because the turn off request from UFS driver to the regulator framework will be immediately followed by low power mode(LPM) request by regulator framework. This is done by framework because UFS which is the only client is requesting for disable. So if the rail is still in the process of shutting down while ICCQ exceeds LPM current thresholds, and LPM mode is activated in hardware during this state, it may trigger an overcurrent protection (OCP) fault in the regulator.  To prevent this, a 10ms delay is added after asserting HWRST. This allows the reset operation to complete while power rails remain active and in high-power mode.  Currently there is no way for Host to query whether the reset is completed or not and hence this the delay is based on experiments with Qualcomm UFS controllers across multiple UFS vendors.

CVE-2025-68296:

        In the Linux kernel, the following vulnerability has been resolved:  drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup  Protect vga_switcheroo_client_fb_set() with console lock. Avoids OOB access in fbcon_remap_all(). Without holding the console lock the call races with switching outputs.  VGA switcheroo calls fbcon_remap_all() when switching clients. The fbcon function uses struct fb_info.node, which is set by register_framebuffer(). As the fb-helper code currently sets up VGA switcheroo before registering the framebuffer, the value of node is -1 and therefore not a legal value. For example, fbcon uses the value within set_con2fb_map() [1] as an index into an array.  Moving vga_switcheroo_client_fb_set() after register_framebuffer() can result in VGA switching that does not switch fbcon correctly.  Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(), which already holds the console lock. Fbdev calls fbcon_fb_registered() from within register_framebuffer(). Serializes the helper with VGA switcheroo's call to fbcon_remap_all().  Although vga_switcheroo_client_fb_set() takes an instance of struct fb_info as parameter, it really only needs the contained fbcon state. Moving the call to fbcon initialization is therefore cleaner than before. Only amdgpu, i915, nouveau and radeon support vga_switcheroo. For all other drivers, this change does nothing.

CVE-2025-68304:

        In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: hci_core: lookup hci_conn on RX path on protocol side  The hdev lock/lookup/unlock/use pattern in the packet RX path doesn't ensure hci_conn* is not concurrently modified/deleted. This locking appears to be leftover from before conn_hash started using RCU commit bf4c63252490b ("Bluetooth: convert conn hash to RCU") and not clear if it had purpose since then.  Currently, there are code paths that delete hci_conn* from elsewhere than the ordered hdev->workqueue where the RX work runs in. E.g. commit 5af1f84ed13a ("Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync") introduced some of these, and there probably were a few others before it.  It's better to do the locking so that even if these run concurrently no UAF is possible.  Move the lookup of hci_conn and associated socket-specific conn to protocol recv handlers, and do them within a single critical section to cover hci_conn* usage and lookup.  syzkaller has reported a crash that appears to be this issue:      [Task hdev->workqueue]          [Task 2]                                     hci_disconnect_all_sync     l2cap_recv_acldata(hcon)                                       hci_conn_get(hcon)                                       hci_abort_conn_sync(hcon)                                         hci_dev_lock       hci_dev_lock                                         hci_conn_del(hcon)       v-------------------------------- hci_dev_unlock                                       hci_conn_put(hcon)       conn = hcon->l2cap_data (UAF)

CVE-2025-68320:

        In the Linux kernel, the following vulnerability has been resolved:  lan966x: Fix sleeping in atomic context  The following warning was seen when we try to connect using ssh to the device.  BUG: sleeping function called from invalid context at kernel/locking/mutex.c:575 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 104, name: dropbear preempt_count: 1, expected: 0 INFO: lockdep is turned off. CPU: 0 UID: 0 PID: 104 Comm: dropbear Tainted: G        W           6.18.0-rc2-00399-g6f1ab1b109b9-dirty #530 NONE Tainted: [W]=WARN Hardware name: Generic DT based system Call trace:  unwind_backtrace from show_stack+0x10/0x14  show_stack from dump_stack_lvl+0x7c/0xac  dump_stack_lvl from __might_resched+0x16c/0x2b0  __might_resched from __mutex_lock+0x64/0xd34  __mutex_lock from mutex_lock_nested+0x1c/0x24  mutex_lock_nested from lan966x_stats_get+0x5c/0x558  lan966x_stats_get from dev_get_stats+0x40/0x43c  dev_get_stats from dev_seq_printf_stats+0x3c/0x184  dev_seq_printf_stats from dev_seq_show+0x10/0x30  dev_seq_show from seq_read_iter+0x350/0x4ec  seq_read_iter from seq_read+0xfc/0x194  seq_read from proc_reg_read+0xac/0x100  proc_reg_read from vfs_read+0xb0/0x2b0  vfs_read from ksys_read+0x6c/0xec  ksys_read from ret_fast_syscall+0x0/0x1c Exception stack(0xf0b11fa8 to 0xf0b11ff0) 1fa0:                   00000001 00001000 00000008 be9048d8 00001000 00000001 1fc0: 00000001 00001000 00000008 00000003 be905920 0000001e 00000000 00000001 1fe0: 0005404c be9048c0 00018684 b6ec2cd8  It seems that we are using a mutex in a atomic context which is wrong. Change the mutex with a spinlock.

CVE-2025-68322:

        In the Linux kernel, the following vulnerability has been resolved:  parisc: Avoid crash due to unaligned access in unwinder  Guenter Roeck reported this kernel crash on his emulated B160L machine:  Starting network: udhcpc: started, v1.36.1  Backtrace:   [<104320d4>] unwind_once+0x1c/0x5c   [<10434a00>] walk_stackframe.isra.0+0x74/0xb8   [<10434a6c>] arch_stack_walk+0x28/0x38   [<104e5efc>] stack_trace_save+0x48/0x5c   [<105d1bdc>] set_track_prepare+0x44/0x6c   [<105d9c80>] ___slab_alloc+0xfc4/0x1024   [<105d9d38>] __slab_alloc.isra.0+0x58/0x90   [<105dc80c>] kmem_cache_alloc_noprof+0x2ac/0x4a0   [<105b8e54>] __anon_vma_prepare+0x60/0x280   [<105a823c>] __vmf_anon_prepare+0x68/0x94   [<105a8b34>] do_wp_page+0x8cc/0xf10   [<105aad88>] handle_mm_fault+0x6c0/0xf08   [<10425568>] do_page_fault+0x110/0x440   [<10427938>] handle_interruption+0x184/0x748   [<11178398>] schedule+0x4c/0x190   BUG: spinlock recursion on CPU#0, ifconfig/2420   lock: terminate_lock.2+0x0/0x1c, .magic: dead4ead, .owner: ifconfig/2420, .owner_cpu: 0  While creating the stack trace, the unwinder uses the stack pointer to guess the previous frame to read the previous stack pointer from memory.  The crash happens, because the unwinder tries to read from unaligned memory and as such triggers the unalignment trap handler which then leads to the spinlock recursion and finally to a deadlock.  Fix it by checking the alignment before accessing the memory.

CVE-2025-68324:

        In the Linux kernel, the following vulnerability has been resolved:  scsi: imm: Fix use-after-free bug caused by unfinished delayed work  The delayed work item 'imm_tq' is initialized in imm_attach() and scheduled via imm_queuecommand() for processing SCSI commands.  When the IMM parallel port SCSI host adapter is detached through imm_detach(), the imm_struct device instance is deallocated.  However, the delayed work might still be pending or executing when imm_detach() is called, leading to use-after-free bugs when the work function imm_interrupt() accesses the already freed imm_struct memory.  The race condition can occur as follows:  CPU 0(detach thread)   | CPU 1                        | imm_queuecommand()                        |   imm_queuecommand_lck() imm_detach()           |     schedule_delayed_work()   kfree(dev) //FREE    | imm_interrupt()                        |   dev = container_of(...) //USE                            dev-> //USE  Add disable_delayed_work_sync() in imm_detach() to guarantee proper cancellation of the delayed work item before imm_struct is deallocated.

CVE-2025-68334:

        In the Linux kernel, the following vulnerability has been resolved:  platform/x86/amd/pmc: Add support for Van Gogh SoC  The ROG Xbox Ally (non-X) SoC features a similar architecture to the Steam Deck. While the Steam Deck supports S3 (s2idle causes a crash), this support was dropped by the Xbox Ally which only S0ix suspend.  Since the handler is missing here, this causes the device to not suspend and the AMD GPU driver to crash while trying to resume afterwards due to a power hang.

CVE-2025-68342:

        In the Linux kernel, the following vulnerability has been resolved:  can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing data  The URB received in gs_usb_receive_bulk_callback() contains a struct gs_host_frame. The length of the data after the header depends on the gs_host_frame hf::flags and the active device features (e.g. time stamping).  Introduce a new function gs_usb_get_minimum_length() and check that we have at least received the required amount of data before accessing it. Only copy the data to that skb that has actually been received.  [mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()]

CVE-2025-68378:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: Fix stackmap overflow check in __bpf_get_stackid()  Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid() when copying stack trace data. The issue occurs when the perf trace  contains more stack entries than the stack map bucket can hold,  leading to an out-of-bounds write in the bucket's data array.

CVE-2025-68379:

        In the Linux kernel, the following vulnerability has been resolved:  RDMA/rxe: Fix null deref on srq->rq.queue after resize failure  A NULL pointer dereference can occur in rxe_srq_chk_attr() when ibv_modify_srq() is invoked twice in succession under certain error conditions. The first call may fail in rxe_queue_resize(), which leads rxe_srq_from_attr() to set srq->rq.queue = NULL. The second call then triggers a crash (null deref) when accessing srq->rq.queue->buf->index_mask.  Call Trace: <TASK> rxe_modify_srq+0x170/0x480 [rdma_rxe] ? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe] ? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs] ? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs] ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs] ? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs] ? tryinc_node_nr_active+0xe6/0x150 ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs] ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs] ? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs] ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs] ? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs] ? __pfx___raw_spin_lock_irqsave+0x10/0x10 ? __pfx_do_vfs_ioctl+0x10/0x10 ? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0 ? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10 ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs] ? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs] __x64_sys_ioctl+0x138/0x1c0 do_syscall_64+0x82/0x250 ? fdget_pos+0x58/0x4c0 ? ksys_write+0xf3/0x1c0 ? __pfx_ksys_write+0x10/0x10 ? do_syscall_64+0xc8/0x250 ? __pfx_vm_mmap_pgoff+0x10/0x10 ? fget+0x173/0x230 ? fput+0x2a/0x80 ? ksys_mmap_pgoff+0x224/0x4c0 ? do_syscall_64+0xc8/0x250 ? do_user_addr_fault+0x37b/0xfe0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 ? clear_bhb_loop+0x50/0xa0 entry_SYSCALL_64_after_hwframe+0x76/0x7e

CVE-2025-68745:

        In the Linux kernel, the following vulnerability has been resolved:  scsi: qla2xxx: Clear cmds after chip reset  Commit aefed3e5548f ("scsi: qla2xxx: target: Fix offline port handling and host reset handling") caused two problems:  1. Commands sent to FW, after chip reset got stuck and never freed as FW    is not going to respond to them anymore.  2. BUG_ON(cmd->sg_mapped) in qlt_free_cmd().  Commit 26f9ce53817a    ("scsi: qla2xxx: Fix missed DMA unmap for aborted commands")    attempted to fix this, but introduced another bug under different    circumstances when two different CPUs were racing to call    qlt_unmap_sg() at the same time: BUG_ON(!valid_dma_direction(dir)) in    dma_unmap_sg_attrs().  So revert "scsi: qla2xxx: Fix missed DMA unmap for aborted commands" and partially revert "scsi: qla2xxx: target: Fix offline port handling and host reset handling" at __qla2x00_abort_all_cmds.

CVE-2025-68755:

        In the Linux kernel, the following vulnerability has been resolved:  staging: most: remove broken i2c driver  The MOST I2C driver has been completely broken for five years without anyone noticing so remove the driver from staging.  Specifically, commit 723de0f9171e ("staging: most: remove device from interface structure") started requiring drivers to set the interface device pointer before registration, but the I2C driver was never updated which results in a NULL pointer dereference if anyone ever tries to probe it.

CVE-2025-68768:

        In the Linux kernel, the following vulnerability has been resolved:  inet: frags: flush pending skbs in fqdir_pre_exit()  We have been seeing occasional deadlocks on pernet_ops_rwsem since September in NIPA. The stuck task was usually modprobe (often loading a driver like ipvlan), trying to take the lock as a Writer. lockdep does not track readers for rwsems so the read wasn't obvious from the reports.  On closer inspection the Reader holding the lock was conntrack looping forever in nf_conntrack_cleanup_net_list(). Based on past experience with occasional NIPA crashes I looked thru the tests which run before the crash and noticed that the crash follows ip_defrag.sh. An immediate red flag. Scouring thru (de)fragmentation queues reveals skbs sitting around, holding conntrack references.  The problem is that since conntrack depends on nf_defrag_ipv6, nf_defrag_ipv6 will load first. Since nf_defrag_ipv6 loads first its netns exit hooks run _after_ conntrack's netns exit hook.  Flush all fragment queue SKBs during fqdir_pre_exit() to release conntrack references before conntrack cleanup runs. Also flush the queues in timer expiry handlers when they discover fqdir->dead is set, in case packet sneaks in while we're running the pre_exit flush.  The commit under Fixes is not exactly the culprit, but I think previously the timer firing would eventually unblock the spinning conntrack.

CVE-2025-68781:

        In the Linux kernel, the following vulnerability has been resolved:  usb: phy: fsl-usb: Fix use-after-free in delayed work during device removal  The delayed work item otg_event is initialized in fsl_otg_conf() and scheduled under two conditions: 1. When a host controller binds to the OTG controller. 2. When the USB ID pin state changes (cable insertion/removal).  A race condition occurs when the device is removed via fsl_otg_remove(): the fsl_otg instance may be freed while the delayed work is still pending or executing. This leads to use-after-free when the work function fsl_otg_event() accesses the already freed memory.  The problematic scenario:  (detach thread)            | (delayed work) fsl_otg_remove()           |   kfree(fsl_otg_dev) //FREE| fsl_otg_event()                            |   og = container_of(...) //USE                            |   og-> //USE  Fix this by calling disable_delayed_work_sync() in fsl_otg_remove() before deallocating the fsl_otg structure. This ensures the delayed work is properly canceled and completes execution prior to memory deallocation.  This bug was identified through static analysis.

CVE-2025-68809:

        In the Linux kernel, the following vulnerability has been resolved:  ksmbd: vfs: fix race on m_flags in vfs_cache  ksmbd maintains delete-on-close and pending-delete state in ksmbd_inode->m_flags. In vfs_cache.c this field is accessed under inconsistent locking: some paths read and modify m_flags under ci->m_lock while others do so without taking the lock at all.  Examples:   - ksmbd_query_inode_status() and __ksmbd_inode_close() use    ci->m_lock when checking or updating m_flags.  - ksmbd_inode_pending_delete(), ksmbd_set_inode_pending_delete(),    ksmbd_clear_inode_pending_delete() and ksmbd_fd_set_delete_on_close()    used to read and modify m_flags without ci->m_lock.  This creates a potential data race on m_flags when multiple threads open, close and delete the same file concurrently. In the worst case delete-on-close and pending-delete bits can be lost or observed in an inconsistent state, leading to confusing delete semantics (files that stay on disk after delete-on-close, or files that disappear while still in use).  Fix it by:   - Making ksmbd_query_inode_status() look at m_flags under ci->m_lock    after dropping inode_hash_lock.  - Adding ci->m_lock protection to all helpers that read or modify    m_flags (ksmbd_inode_pending_delete(), ksmbd_set_inode_pending_delete(),    ksmbd_clear_inode_pending_delete(), ksmbd_fd_set_delete_on_close()).  - Keeping the existing ci->m_lock protection in __ksmbd_inode_close(),    and moving the actual unlink/xattr removal outside the lock.  This unifies the locking around m_flags and removes the data race while preserving the existing delete-on-close behaviour.

CVE-2025-68822:

        In the Linux kernel, the following vulnerability has been resolved:  Input: alps - fix use-after-free bugs caused by dev3_register_work  The dev3_register_work delayed work item is initialized within alps_reconnect() and scheduled upon receipt of the first bare PS/2 packet from an external PS/2 device connected to the ALPS touchpad. During device detachment, the original implementation calls flush_workqueue() in psmouse_disconnect() to ensure completion of dev3_register_work. However, the flush_workqueue() in psmouse_disconnect() only blocks and waits for work items that were already queued to the workqueue prior to its invocation. Any work items submitted after flush_workqueue() is called are not included in the set of tasks that the flush operation awaits. This means that after flush_workqueue() has finished executing, the dev3_register_work could still be scheduled. Although the psmouse state is set to PSMOUSE_CMD_MODE in psmouse_disconnect(), the scheduling of dev3_register_work remains unaffected.  The race condition can occur as follows:  CPU 0 (cleanup path)     | CPU 1 (delayed work) psmouse_disconnect()     |   psmouse_set_state()    |   flush_workqueue()      | alps_report_bare_ps2_packet()   alps_disconnect()      |   psmouse_queue_work()     kfree(priv); // FREE | alps_register_bare_ps2_mouse()                          |   priv = container_of(work...); // USE                          |   priv->dev3 // USE  Add disable_delayed_work_sync() in alps_disconnect() to ensure that dev3_register_work is properly canceled and prevented from executing after the alps_data structure has been deallocated.  This bug is identified by static analysis.

CVE-2025-71065:

        In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to avoid potential deadlock  As Jiaming Zhang and syzbot reported, there is potential deadlock in f2fs as below:  Chain exists of:   &sbi->cp_rwsem --> fs_reclaim --> sb_internal#2   Possible unsafe locking scenario:         CPU0                    CPU1        ----                    ----   rlock(sb_internal#2);                                lock(fs_reclaim);                                lock(sb_internal#2);   rlock(&sbi->cp_rwsem);   *** DEADLOCK ***  3 locks held by kswapd0/73:  #0: ffffffff8e247a40 (fs_reclaim){+.+.}-{0:0}, at: balance_pgdat mm/vmscan.c:7015 [inline]  #0: ffffffff8e247a40 (fs_reclaim){+.+.}-{0:0}, at: kswapd+0x951/0x2800 mm/vmscan.c:7389  #1: ffff8880118400e0 (&type->s_umount_key#50){.+.+}-{4:4}, at: super_trylock_shared fs/super.c:562 [inline]  #1: ffff8880118400e0 (&type->s_umount_key#50){.+.+}-{4:4}, at: super_cache_scan+0x91/0x4b0 fs/super.c:197  #2: ffff888011840610 (sb_internal#2){.+.+}-{0:0}, at: f2fs_evict_inode+0x8d9/0x1b60 fs/f2fs/inode.c:890  stack backtrace: CPU: 0 UID: 0 PID: 73 Comm: kswapd0 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace:  <TASK>  dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120  print_circular_bug+0x2ee/0x310 kernel/locking/lockdep.c:2043  check_noncircular+0x134/0x160 kernel/locking/lockdep.c:2175  check_prev_add kernel/locking/lockdep.c:3165 [inline]  check_prevs_add kernel/locking/lockdep.c:3284 [inline]  validate_chain+0xb9b/0x2140 kernel/locking/lockdep.c:3908  __lock_acquire+0xab9/0xd20 kernel/locking/lockdep.c:5237  lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868  down_read+0x46/0x2e0 kernel/locking/rwsem.c:1537  f2fs_down_read fs/f2fs/f2fs.h:2278 [inline]  f2fs_lock_op fs/f2fs/f2fs.h:2357 [inline]  f2fs_do_truncate_blocks+0x21c/0x10c0 fs/f2fs/file.c:791  f2fs_truncate_blocks+0x10a/0x300 fs/f2fs/file.c:867  f2fs_truncate+0x489/0x7c0 fs/f2fs/file.c:925  f2fs_evict_inode+0x9f2/0x1b60 fs/f2fs/inode.c:897  evict+0x504/0x9c0 fs/inode.c:810  f2fs_evict_inode+0x1dc/0x1b60 fs/f2fs/inode.c:853  evict+0x504/0x9c0 fs/inode.c:810  dispose_list fs/inode.c:852 [inline]  prune_icache_sb+0x21b/0x2c0 fs/inode.c:1000  super_cache_scan+0x39b/0x4b0 fs/super.c:224  do_shrink_slab+0x6ef/0x1110 mm/shrinker.c:437  shrink_slab_memcg mm/shrinker.c:550 [inline]  shrink_slab+0x7ef/0x10d0 mm/shrinker.c:628  shrink_one+0x28a/0x7c0 mm/vmscan.c:4955  shrink_many mm/vmscan.c:5016 [inline]  lru_gen_shrink_node mm/vmscan.c:5094 [inline]  shrink_node+0x315d/0x3780 mm/vmscan.c:6081  kswapd_shrink_node mm/vmscan.c:6941 [inline]  balance_pgdat mm/vmscan.c:7124 [inline]  kswapd+0x147c/0x2800 mm/vmscan.c:7389  kthread+0x70e/0x8a0 kernel/kthread.c:463  ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245  </TASK>  The root cause is deadlock among four locks as below:  kswapd - fs_reclaim				--- Lock A  - shrink_one   - evict    - f2fs_evict_inode     - sb_start_intwrite			--- Lock B  - iput  - evict   - f2fs_evict_inode    - sb_start_intwrite			--- Lock B    - f2fs_truncate     - f2fs_truncate_blocks      - f2fs_do_truncate_blocks       - f2fs_lock_op			--- Lock C  ioctl - f2fs_ioc_commit_atomic_write  - f2fs_lock_op				--- Lock C   - __f2fs_commit_atomic_write    - __replace_atomic_write_block     - f2fs_get_dnode_of_data      - __get_node_folio       - f2fs_check_nid_range        - f2fs_handle_error         - f2fs_record_errors          - f2fs_down_write		--- Lock D  open - do_open  - do_truncate   - security_inode_need_killpriv    - f2fs_getxattr     - lookup_all_xattrs      - f2fs_handle_error       - f2fs_record_errors        - f2fs_down_write		--- Lock D         - f2fs_commit_super          - read_mapping_folio           - filemap_alloc_folio_noprof            - prepare_alloc_pages             - fs_reclaim_acquire	--- Lock A  In order to a ---truncated---

CVE-2025-71068:

        In the Linux kernel, the following vulnerability has been resolved:  svcrdma: bound check rq_pages index in inline path  svc_rdma_copy_inline_range indexed rqstp->rq_pages[rc_curpage] without verifying rc_curpage stays within the allocated page array. Add guards before the first use and after advancing to a new page.

CVE-2025-71073:

        In the Linux kernel, the following vulnerability has been resolved:  Input: lkkbd - disable pending work before freeing device  lkkbd_interrupt() schedules lk->tq via schedule_work(), and the work handler lkkbd_reinit() dereferences the lkkbd structure and its serio/input_dev fields.  lkkbd_disconnect() and error paths in lkkbd_connect() free the lkkbd structure without preventing the reinit work from being queued again until serio_close() returns. This can allow the work handler to run after the structure has been freed, leading to a potential use-after-free.  Use disable_work_sync() instead of cancel_work_sync() to ensure the reinit work cannot be re-queued, and call it both in lkkbd_disconnect() and in lkkbd_connect() error paths after serio_open().

CVE-2025-71074:

        In the Linux kernel, the following vulnerability has been resolved:  functionfs: fix the open/removal races  ffs_epfile_open() can race with removal, ending up with file->private_data pointing to freed object.  There is a total count of opened files on functionfs (both ep0 and dynamic ones) and when it hits zero, dynamic files get removed. Unfortunately, that removal can happen while another thread is in ffs_epfile_open(), but has not incremented the count yet. In that case open will succeed, leaving us with UAF on any subsequent read() or write().  The root cause is that ffs->opened is misused; atomic_dec_and_test() vs. atomic_add_return() is not a good idea, when object remains visible all along.  To untangle that 	* serialize openers on ffs->mutex (both for ep0 and for dynamic files) 	* have dynamic ones use atomic_inc_not_zero() and fail if we had zero ->opened; in that case the file we are opening is doomed. 	* have the inodes of dynamic files marked on removal (from the callback of simple_recursive_removal()) - clear ->i_private there. 	* have open of dynamic ones verify they hadn't been already removed, along with checking that state is FFS_ACTIVE.

CVE-2025-71109:

        In the Linux kernel, the following vulnerability has been resolved:  MIPS: ftrace: Fix memory corruption when kernel is located beyond 32 bits  Since commit e424054000878 ("MIPS: Tracing: Reduce the overhead of dynamic Function Tracer"), the macro UASM_i_LA_mostly has been used, and this macro can generate more than 2 instructions. At the same time, the code in ftrace assumes that no more than 2 instructions can be generated, which is why it stores them in an int[2] array. However, as previously noted, the macro UASM_i_LA_mostly (and now UASM_i_LA) causes a buffer overflow when _mcount is beyond 32 bits. This leads to corruption of the variables located in the __read_mostly section.  This corruption was observed because the variable __cpu_primary_thread_mask was corrupted, causing a hang very early during boot.  This fix prevents the corruption by avoiding the generation of instructions if they could exceed 2 instructions in length. Fortunately, insn_la_mcount is only used if the instrumented code is located outside the kernel code section, so dynamic ftrace can still be used, albeit in a more limited scope. This is still preferable to corrupting memory and/or crashing the kernel.

CVE-2025-71129:

        In the Linux kernel, the following vulnerability has been resolved:  LoongArch: BPF: Sign extend kfunc call arguments  The kfunc calls are native calls so they should follow LoongArch calling conventions. Sign extend its arguments properly to avoid kernel panic. This is done by adding a new emit_abi_ext() helper. The emit_abi_ext() helper performs extension in place meaning a value already store in the target register (Note: this is different from the existing sign_extend() helper and thus we can't reuse it).

CVE-2025-71138:

        In the Linux kernel, the following vulnerability has been resolved:  drm/msm/dpu: Add missing NULL pointer check for pingpong interface  It is checked almost always in dpu_encoder_phys_wb_setup_ctl(), but in a single place the check is missing. Also use convenient locals instead of phys_enc->* where available.  Patchwork: https://patchwork.freedesktop.org/patch/693860/

CVE-2025-71152:

        In the Linux kernel, the following vulnerability has been resolved:  net: dsa: properly keep track of conduit reference  Problem description -------------------  DSA has a mumbo-jumbo of reference handling of the conduit net device and its kobject which, sadly, is just wrong and doesn't make sense.  There are two distinct problems.  1. The OF path, which uses of_find_net_device_by_node(), never releases    the elevated refcount on the conduit's kobject. Nominally, the OF and    non-OF paths should result in objects having identical reference    counts taken, and it is already suspicious that    dsa_dev_to_net_device() has a put_device() call which is missing in    dsa_port_parse_of(), but we can actually even verify that an issue    exists. With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command    "before" and "after" applying this patch:  (unbind the conduit driver for net device eno2) echo 0000:00:00.2 > /sys/bus/pci/drivers/fsl_enetc/unbind  we see these lines in the output diff which appear only with the patch applied:  kobject: 'eno2' (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000) kobject: '109' (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000)  2. After we find the conduit interface one way (OF) or another (non-OF),    it can get unregistered at any time, and DSA remains with a long-lived,    but in this case stale, cpu_dp->conduit pointer. Holding the net    device's underlying kobject isn't actually of much help, it just    prevents it from being freed (but we never need that kobject    directly). What helps us to prevent the net device from being    unregistered is the parallel netdev reference mechanism (dev_hold()    and dev_put()).  Actually we actually use that netdev tracker mechanism implicitly on user ports since commit 2f1e8ea726e9 ("net: dsa: link interfaces with the DSA master to get rid of lockdep warnings"), via netdev_upper_dev_link(). But time still passes at DSA switch probe time between the initial of_find_net_device_by_node() code and the user port creation time, time during which the conduit could unregister itself and DSA wouldn't know about it.  So we have to run of_find_net_device_by_node() under rtnl_lock() to prevent that from happening, and release the lock only with the netdev tracker having acquired the reference.  Do we need to keep the reference until dsa_unregister_switch() / dsa_switch_shutdown()? 1: Maybe yes. A switch device will still be registered even if all user    ports failed to probe, see commit 86f8b1c01a0a ("net: dsa: Do not    make user port errors fatal"), and the cpu_dp->conduit pointers    remain valid.  I haven't audited all call paths to see whether they    will actually use the conduit in lack of any user port, but if they    do, it seems safer to not rely on user ports for that reference. 2. Definitely yes. We support changing the conduit which a user port is    associated to, and we can get into a situation where we've moved all    user ports away from a conduit, thus no longer hold any reference to    it via the net device tracker. But we shouldn't let it go nonetheless    - see the next change in relation to dsa_tree_find_first_conduit()    and LAG conduits which disappear.    We have to be prepared to return to the physical conduit, so the CPU    port must explicitly keep another reference to it. This is also to    say: the user ports and their CPU ports may not always keep a    reference to the same conduit net device, and both are needed.  As for the conduit's kobject for the /sys/class/net/ entry, we don't care about it, we can release it as soon as we hold the net device object itself.  History and blame attribution -----------------------------  The code has been refactored so many times, it is very difficult to follow and properly attribute a blame, but I'll try to make a short history which I hope to be correct.  We have two distinct probing paths: - one for OF, introduced in 2016 i ---truncated---

CVE-2025-71160:

        In the Linux kernel, the following vulnerability has been resolved:  netfilter: nf_tables: avoid chain re-validation if possible  Hamza Mahfooz reports cpu soft lock-ups in nft_chain_validate():   watchdog: BUG: soft lockup - CPU#1 stuck for 27s! [iptables-nft-re:37547] [..]  RIP: 0010:nft_chain_validate+0xcb/0x110 [nf_tables] [..]   nft_immediate_validate+0x36/0x50 [nf_tables]   nft_chain_validate+0xc9/0x110 [nf_tables]   nft_immediate_validate+0x36/0x50 [nf_tables]   nft_chain_validate+0xc9/0x110 [nf_tables]   nft_immediate_validate+0x36/0x50 [nf_tables]   nft_chain_validate+0xc9/0x110 [nf_tables]   nft_immediate_validate+0x36/0x50 [nf_tables]   nft_chain_validate+0xc9/0x110 [nf_tables]   nft_immediate_validate+0x36/0x50 [nf_tables]   nft_chain_validate+0xc9/0x110 [nf_tables]   nft_immediate_validate+0x36/0x50 [nf_tables]   nft_chain_validate+0xc9/0x110 [nf_tables]   nft_table_validate+0x6b/0xb0 [nf_tables]   nf_tables_validate+0x8b/0xa0 [nf_tables]   nf_tables_commit+0x1df/0x1eb0 [nf_tables] [..]  Currently nf_tables will traverse the entire table (chain graph), starting from the entry points (base chains), exploring all possible paths (chain jumps).  But there are cases where we could avoid revalidation.  Consider: 1  input -> j2 -> j3 2  input -> j2 -> j3 3  input -> j1 -> j2 -> j3  Then the second rule does not need to revalidate j2, and, by extension j3, because this was already checked during validation of the first rule. We need to validate it only for rule 3.  This is needed because chain loop detection also ensures we do not exceed the jump stack: Just because we know that j2 is cycle free, its last jump might now exceed the allowed stack size.  We also need to update all reachable chains with the new largest observed call depth.  Care has to be taken to revalidate even if the chain depth won't be an issue: chain validation also ensures that expressions are not called from invalid base chains.  For example, the masquerade expression can only be called from NAT postrouting base chains.  Therefore we also need to keep record of the base chain context (type, hooknum) and revalidate if the chain becomes reachable from a different hook location.

CVE-2025-71184:

        In the Linux kernel, the following vulnerability has been resolved:  btrfs: fix NULL dereference on root when tracing inode eviction  When evicting an inode the first thing we do is to setup tracing for it, which implies fetching the root's id. But in btrfs_evict_inode() the root might be NULL, as implied in the next check that we do in btrfs_evict_inode().  Hence, we either should set the ->root_objectid to 0 in case the root is NULL, or we move tracing setup after checking that the root is not NULL. Setting the rootid to 0 at least gives us the possibility to trace this call even in the case when the root is NULL, so that's the solution taken here.

CVE-2025-71193:

        In the Linux kernel, the following vulnerability has been resolved:  phy: qcom-qusb2: Fix NULL pointer dereference on early suspend  Enabling runtime PM before attaching the QPHY instance as driver data can lead to a NULL pointer dereference in runtime PM callbacks that expect valid driver data. There is a small window where the suspend callback may run after PM runtime enabling and before runtime forbid. This causes a sporadic crash during boot:  ``` Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a1 [...] CPU: 0 UID: 0 PID: 11 Comm: kworker/0:1 Not tainted 6.16.7+ #116 PREEMPT Workqueue: pm pm_runtime_work pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : qusb2_phy_runtime_suspend+0x14/0x1e0 [phy_qcom_qusb2] lr : pm_generic_runtime_suspend+0x2c/0x44 [...] ```  Attach the QPHY instance as driver data before enabling runtime PM to prevent NULL pointer dereference in runtime PM callbacks.  Reorder pm_runtime_enable() and pm_runtime_forbid() to prevent a short window where an unnecessary runtime suspend can occur.  Use the devres-managed version to ensure PM runtime is symmetrically disabled during driver removal for proper cleanup.

CVE-2025-71198:

        In the Linux kernel, the following vulnerability has been resolved:  iio: imu: st_lsm6dsx: fix iio_chan_spec for sensors without event detection  The st_lsm6dsx_acc_channels array of struct iio_chan_spec has a non-NULL event_spec field, indicating support for IIO events. However, event detection is not supported for all sensors, and if userspace tries to configure accelerometer wakeup events on a sensor device that does not support them (e.g. LSM6DS0), st_lsm6dsx_write_event() dereferences a NULL pointer when trying to write to the wakeup register. Define an additional struct iio_chan_spec array whose members have a NULL event_spec field, and use this array instead of st_lsm6dsx_acc_channels for sensors without event detection capability.

CVE-2025-71202:

        In the Linux kernel, the following vulnerability has been resolved:  iommu/sva: invalidate stale IOTLB entries for kernel address space  Introduce a new IOMMU interface to flush IOTLB paging cache entries for the CPU kernel address space.  This interface is invoked from the x86 architecture code that manages combined user and kernel page tables, specifically before any kernel page table page is freed and reused.  This addresses the main issue with vfree() which is a common occurrence and can be triggered by unprivileged users.  While this resolves the primary problem, it doesn't address some extremely rare case related to memory unplug of memory that was present as reserved memory at boot, which cannot be triggered by unprivileged users.  The discussion can be found at the link below.  Enable SVA on x86 architecture since the IOMMU can now receive notification to flush the paging cache before freeing the CPU kernel page table pages.

CVE-2025-71225:

        In the Linux kernel, the following vulnerability has been resolved:  md: suspend array while updating raid_disks via sysfs  In raid1_reshape(), freeze_array() is called before modifying the r1bio memory pool (conf->r1bio_pool) and conf->raid_disks, and unfreeze_array() is called after the update is completed.  However, freeze_array() only waits until nr_sync_pending and (nr_pending - nr_queued) of all buckets reaches zero. When an I/O error occurs, nr_queued is increased and the corresponding r1bio is queued to either retry_list or bio_end_io_list. As a result, freeze_array() may unblock before these r1bios are released.  This can lead to a situation where conf->raid_disks and the mempool have already been updated while queued r1bios, allocated with the old raid_disks value, are later released. Consequently, free_r1bio() may access memory out of bounds in put_all_bios() and release r1bios of the wrong size to the new mempool, potentially causing issues with the mempool as well.  Since only normal I/O might increase nr_queued while an I/O error occurs, suspending the array avoids this issue.  Note: Updating raid_disks via ioctl SET_ARRAY_INFO already suspends the array. Therefore, we suspend the array when updating raid_disks via sysfs to avoid this issue too.

CVE-2025-71227:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: mac80211: don't WARN for connections on invalid channels  It's not clear (to me) how exactly syzbot managed to hit this, but it seems conceivable that e.g. regulatory changed and has disabled a channel between scanning (channel is checked to be usable by cfg80211_get_ies_channel_number) and connecting on the channel later.  With one scenario that isn't covered elsewhere described above, the warning isn't good, replace it with a (more informative) error message.

CVE-2025-71272:

        In the Linux kernel, the following vulnerability has been resolved:  most: core: fix resource leak in most_register_interface error paths  The function most_register_interface() did not correctly release resources if it failed early (before registering the device). In these cases, it returned an error code immediately, leaking the memory allocated for the interface.  Fix this by initializing the device early via device_initialize() and calling put_device() on all error paths.  The most_register_interface() is expected to call put_device() on error which frees the resources allocated in the caller. The put_device() either calls release_mdev() or dim2_release(), depending on the caller.  Switch to using device_add() instead of device_register() to handle the split initialization.

CVE-2025-71273:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: rtw88: Use devm_kmemdup() in rtw_set_supported_band()  Simplify the code by using device managed memory allocations.  This also fixes a memory leak in rtw_register_hw(). The supported bands were not freed in the error path.  Copied from commit 145df52a8671 ("wifi: rtw89: Convert rtw89_core_set_supported_band to use devm_*").

CVE-2025-71285:

        In the Linux kernel, the following vulnerability has been resolved:  net: qrtr: Drop the MHI auto_queue feature for IPCR DL channels  MHI stack offers the 'auto_queue' feature, which allows the MHI stack to auto queue the buffers for the RX path (DL channel). Though this feature simplifies the client driver design, it introduces race between the client drivers and the MHI stack. For instance, with auto_queue, the 'dl_callback' for the DL channel may get called before the client driver is fully probed. This means, by the time the dl_callback gets called, the client driver's structures might not be initialized, leading to NULL ptr dereference.  Currently, the drivers have to workaround this issue by initializing the internal structures before calling mhi_prepare_for_transfer_autoqueue(). But even so, there is a chance that the client driver's internal code path may call the MHI queue APIs before mhi_prepare_for_transfer_autoqueue() is called, leading to similar NULL ptr dereference. This issue has been reported on the Qcom X1E80100 CRD machines affecting boot.  So to properly fix all these races, drop the MHI 'auto_queue' feature altogether and let the client driver (QRTR) manage the RX buffers manually. In the QRTR driver, queue the RX buffers based on the ring length during probe and recycle the buffers in 'dl_callback' once they are consumed. This also warrants removing the setting of 'auto_queue' flag from controller drivers.  Currently, this 'auto_queue' feature is only enabled for IPCR DL channel. So only the QRTR client driver requires the modification.

CVE-2025-71289:

        In the Linux kernel, the following vulnerability has been resolved:  fs/ntfs3: handle attr_set_size() errors when truncating files  If attr_set_size() fails while truncating down, the error is silently ignored and the inode may be left in an inconsistent state.

CVE-2025-71313:

        In the Linux kernel, the following vulnerability has been resolved:  PCI: endpoint: Add missing NULL check for alloc_workqueue()  alloc_workqueue() can return NULL on memory allocation failure. Without proper error checking, this may lead to a NULL pointer dereference when queue_work() is later called with the NULL workqueue pointer in epf_ntb_epc_init().  Add a NULL check immediately after alloc_workqueue() and return -ENOMEM on failure to prevent the driver from loading with an invalid workqueue pointer.

CVE-2025-71315:

        In the Linux kernel, the following vulnerability has been resolved:  drm/vkms: Convert to DRM's vblank timer  Replace vkms' vblank timer with the DRM implementation. The DRM code is identical in concept, but differs in implementation.  Vblank timers are covered in vblank helpers and initializer macros, so remove the corresponding hrtimer in struct vkms_output. The vblank timer calls vkms' custom timeout code via handle_vblank_timeout in struct drm_crtc_helper_funcs.

CVE-2026-22996:

        In the Linux kernel, the following vulnerability has been resolved:  net/mlx5e: Don't store mlx5e_priv in mlx5e_dev devlink priv  mlx5e_priv is an unstable structure that can be memset(0) if profile attaching fails, mlx5e_priv in mlx5e_dev devlink private is used to reference the netdev and mdev associated with that struct. Instead, store netdev directly into mlx5e_dev and get mdev from the containing mlx5_adev aux device structure.  This fixes a kernel oops in mlx5e_remove when switchdev mode fails due to change profile failure.  $ devlink dev eswitch set pci/0000:00:03.0 mode switchdev Error: mlx5_core: Failed setting eswitch to offloads. dmesg: workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12 mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12 workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12 mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12  $ devlink dev reload pci/0000:00:03.0 ==> oops  BUG: kernel NULL pointer dereference, address: 0000000000000520  #PF: supervisor read access in kernel mode  #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 3 UID: 0 PID: 521 Comm: devlink Not tainted 6.18.0-rc5+ #117 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:mlx5e_remove+0x68/0x130 RSP: 0018:ffffc900034838f0 EFLAGS: 00010246 RAX: ffff88810283c380 RBX: ffff888101874400 RCX: ffffffff826ffc45 RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000 RBP: ffff888102d789c0 R08: ffff8881007137f0 R09: ffff888100264e10 R10: ffffc90003483898 R11: ffffc900034838a0 R12: ffff888100d261a0 R13: ffff888100d261a0 R14: ffff8881018749a0 R15: ffff888101874400 FS:  00007f8565fea740(0000) GS:ffff88856a759000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000520 CR3: 000000010b11a004 CR4: 0000000000370ef0 Call Trace:  <TASK>  device_release_driver_internal+0x19c/0x200  bus_remove_device+0xc6/0x130  device_del+0x160/0x3d0  ? devl_param_driverinit_value_get+0x2d/0x90  mlx5_detach_device+0x89/0xe0  mlx5_unload_one_devl_locked+0x3a/0x70  mlx5_devlink_reload_down+0xc8/0x220  devlink_reload+0x7d/0x260  devlink_nl_reload_doit+0x45b/0x5a0  genl_family_rcv_msg_doit+0xe8/0x140

CVE-2026-23000:

        In the Linux kernel, the following vulnerability has been resolved:  net/mlx5e: Fix crash on profile change rollback failure  mlx5e_netdev_change_profile can fail to attach a new profile and can fail to rollback to old profile, in such case, we could end up with a dangling netdev with a fully reset netdev_priv. A retry to change profile, e.g. another attempt to call mlx5e_netdev_change_profile via switchdev mode change, will crash trying to access the now NULL priv->mdev.  This fix allows mlx5e_netdev_change_profile() to handle previous failures and an empty priv, by not assuming priv is valid.  Pass netdev and mdev to all flows requiring mlx5e_netdev_change_profile() and avoid passing priv. In mlx5e_netdev_change_profile() check if current priv is valid, and if not, just attach the new profile without trying to access the old one.  This fixes the following oops, when enabling switchdev mode for the 2nd time after first time failure:   ## Enabling switchdev mode first time:  mlx5_core 0012:03:00.1: E-Switch: Supported tc chains and prios offload workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12 mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12 workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12 mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12                                                                          ^^^^^^^^ mlx5_core 0000:00:03.0: E-Switch: Disable: mode(LEGACY), nvfs(0), necvfs(0), active vports(0)   ## retry: Enabling switchdev mode 2nd time:  mlx5_core 0000:00:03.0: E-Switch: Supported tc chains and prios offload BUG: kernel NULL pointer dereference, address: 0000000000000038  #PF: supervisor read access in kernel mode  #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 520 Comm: devlink Not tainted 6.18.0-rc4+ #91 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:mlx5e_detach_netdev+0x3c/0x90 Code: 50 00 00 f0 80 4f 78 02 48 8b bf e8 07 00 00 48 85 ff 74 16 48 8b 73 78 48 d1 ee 83 e6 01 83 f6 01 40 0f b6 f6 e8 c4 42 00 00 <48> 8b 45 38 48 85 c0 74 08 48 89 df e8 cc 47 40 1e 48 8b bb f0 07 RSP: 0018:ffffc90000673890 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8881036a89c0 RCX: 0000000000000000 RDX: ffff888113f63800 RSI: ffffffff822fe720 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000002dcd R09: 0000000000000000 R10: ffffc900006738e8 R11: 00000000ffffffff R12: 0000000000000000 R13: 0000000000000000 R14: ffff8881036a89c0 R15: 0000000000000000 FS:  00007fdfb8384740(0000) GS:ffff88856a9d6000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000038 CR3: 0000000112ae0005 CR4: 0000000000370ef0 Call Trace:  <TASK>  mlx5e_netdev_change_profile+0x45/0xb0  mlx5e_vport_rep_load+0x27b/0x2d0  mlx5_esw_offloads_rep_load+0x72/0xf0  esw_offloads_enable+0x5d0/0x970  mlx5_eswitch_enable_locked+0x349/0x430  ? is_mp_supported+0x57/0xb0  mlx5_devlink_eswitch_mode_set+0x26b/0x430  devlink_nl_eswitch_set_doit+0x6f/0xf0  genl_family_rcv_msg_doit+0xe8/0x140  genl_rcv_msg+0x18b/0x290  ? __pfx_devlink_nl_pre_doit+0x10/0x10  ? __pfx_devlink_nl_eswitch_set_doit+0x10/0x10  ? __pfx_devlink_nl_post_doit+0x10/0x10  ? __pfx_genl_rcv_msg+0x10/0x10  netlink_rcv_skb+0x52/0x100  genl_rcv+0x28/0x40  netlink_unicast+0x282/0x3e0  ? __alloc_skb+0xd6/0x190  netlink_sendmsg+0x1f7/0x430  __sys_sendto+0x213/0x220  ? __sys_recvmsg+0x6a/0xd0  __x64_sys_sendto+0x24/0x30  do_syscall_64+0x50/0x1f0  entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fdfb8495047

CVE-2026-23004:

        In the Linux kernel, the following vulnerability has been resolved:  dst: fix races in rt6_uncached_list_del() and rt_del_uncached_list()  syzbot was able to crash the kernel in rt6_uncached_list_flush_dev() in an interesting way [1]  Crash happens in list_del_init()/INIT_LIST_HEAD() while writing list->prev, while the prior write on list->next went well.  static inline void INIT_LIST_HEAD(struct list_head *list) { 	WRITE_ONCE(list->next, list); // This went well 	WRITE_ONCE(list->prev, list); // Crash, @list has been freed. }  Issue here is that rt6_uncached_list_del() did not attempt to lock ul->lock, as list_empty(&rt->dst.rt_uncached) returned true because the WRITE_ONCE(list->next, list) happened on the other CPU.  We might use list_del_init_careful() and list_empty_careful(), or make sure rt6_uncached_list_del() always grabs the spinlock whenever rt->dst.rt_uncached_list has been set.  A similar fix is neeed for IPv4.  [1]   BUG: KASAN: slab-use-after-free in INIT_LIST_HEAD include/linux/list.h:46 [inline]  BUG: KASAN: slab-use-after-free in list_del_init include/linux/list.h:296 [inline]  BUG: KASAN: slab-use-after-free in rt6_uncached_list_flush_dev net/ipv6/route.c:191 [inline]  BUG: KASAN: slab-use-after-free in rt6_disable_ip+0x633/0x730 net/ipv6/route.c:5020 Write of size 8 at addr ffff8880294cfa78 by task kworker/u8:14/3450  CPU: 0 UID: 0 PID: 3450 Comm: kworker/u8:14 Tainted: G             L      syzkaller #0 PREEMPT_{RT,(full)} Tainted: [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 Workqueue: netns cleanup_net Call Trace:  <TASK>   dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120   print_address_description mm/kasan/report.c:378 [inline]   print_report+0xca/0x240 mm/kasan/report.c:482   kasan_report+0x118/0x150 mm/kasan/report.c:595   INIT_LIST_HEAD include/linux/list.h:46 [inline]   list_del_init include/linux/list.h:296 [inline]   rt6_uncached_list_flush_dev net/ipv6/route.c:191 [inline]   rt6_disable_ip+0x633/0x730 net/ipv6/route.c:5020   addrconf_ifdown+0x143/0x18a0 net/ipv6/addrconf.c:3853  addrconf_notify+0x1bc/0x1050 net/ipv6/addrconf.c:-1   notifier_call_chain+0x19d/0x3a0 kernel/notifier.c:85   call_netdevice_notifiers_extack net/core/dev.c:2268 [inline]   call_netdevice_notifiers net/core/dev.c:2282 [inline]   netif_close_many+0x29c/0x410 net/core/dev.c:1785   unregister_netdevice_many_notify+0xb50/0x2330 net/core/dev.c:12353   ops_exit_rtnl_list net/core/net_namespace.c:187 [inline]   ops_undo_list+0x3dc/0x990 net/core/net_namespace.c:248   cleanup_net+0x4de/0x7b0 net/core/net_namespace.c:696   process_one_work kernel/workqueue.c:3257 [inline]   process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340   worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421   kthread+0x711/0x8a0 kernel/kthread.c:463   ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158   ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246  </TASK>  Allocated by task 803:   kasan_save_stack mm/kasan/common.c:57 [inline]   kasan_save_track+0x3e/0x80 mm/kasan/common.c:78   unpoison_slab_object mm/kasan/common.c:340 [inline]   __kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:366   kasan_slab_alloc include/linux/kasan.h:253 [inline]   slab_post_alloc_hook mm/slub.c:4953 [inline]   slab_alloc_node mm/slub.c:5263 [inline]   kmem_cache_alloc_noprof+0x18d/0x6c0 mm/slub.c:5270   dst_alloc+0x105/0x170 net/core/dst.c:89   ip6_dst_alloc net/ipv6/route.c:342 [inline]   icmp6_dst_alloc+0x75/0x460 net/ipv6/route.c:3333   mld_sendpack+0x683/0xe60 net/ipv6/mcast.c:1844   mld_send_cr net/ipv6/mcast.c:2154 [inline]   mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693   process_one_work kernel/workqueue.c:3257 [inline]   process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340   worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421   kthread+0x711/0x8a0 kernel/kthread.c:463   ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158   ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entr ---truncated---

CVE-2026-23035:

        In the Linux kernel, the following vulnerability has been resolved:  net/mlx5e: Pass netdev to mlx5e_destroy_netdev instead of priv  mlx5e_priv is an unstable structure that can be memset(0) if profile attaching fails.  Pass netdev to mlx5e_destroy_netdev() to guarantee it will work on a valid netdev.  On mlx5e_remove: Check validity of priv->profile, before attempting to cleanup any resources that might be not there.  This fixes a kernel oops in mlx5e_remove when switchdev mode fails due to change profile failure.  $ devlink dev eswitch set pci/0000:00:03.0 mode switchdev Error: mlx5_core: Failed setting eswitch to offloads. dmesg: workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12 mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12 workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12 mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12  $ devlink dev reload pci/0000:00:03.0 ==> oops  BUG: kernel NULL pointer dereference, address: 0000000000000370 PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 15 UID: 0 PID: 520 Comm: devlink Not tainted 6.18.0-rc5+ #115 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:mlx5e_dcbnl_dscp_app+0x23/0x100 RSP: 0018:ffffc9000083f8b8 EFLAGS: 00010286 RAX: ffff8881126fc380 RBX: ffff8881015ac400 RCX: ffffffff826ffc45 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8881035109c0 RBP: ffff8881035109c0 R08: ffff888101e3e838 R09: ffff888100264e10 R10: ffffc9000083f898 R11: ffffc9000083f8a0 R12: ffff888101b921a0 R13: ffff888101b921a0 R14: ffff8881015ac9a0 R15: ffff8881015ac400 FS:  00007f789a3c8740(0000) GS:ffff88856aa59000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000370 CR3: 000000010b6c0001 CR4: 0000000000370ef0 Call Trace:  <TASK>  mlx5e_remove+0x57/0x110  device_release_driver_internal+0x19c/0x200  bus_remove_device+0xc6/0x130  device_del+0x160/0x3d0  ? devl_param_driverinit_value_get+0x2d/0x90  mlx5_detach_device+0x89/0xe0  mlx5_unload_one_devl_locked+0x3a/0x70  mlx5_devlink_reload_down+0xc8/0x220  devlink_reload+0x7d/0x260  devlink_nl_reload_doit+0x45b/0x5a0  genl_family_rcv_msg_doit+0xe8/0x140

CVE-2026-23050:

        In the Linux kernel, the following vulnerability has been resolved:  pNFS: Fix a deadlock when returning a delegation during open()  Ben Coddington reports seeing a hang in the following stack trace:   0 [ffffd0b50e1774e0] __schedule at ffffffff9ca05415   1 [ffffd0b50e177548] schedule at ffffffff9ca05717   2 [ffffd0b50e177558] bit_wait at ffffffff9ca061e1   3 [ffffd0b50e177568] __wait_on_bit at ffffffff9ca05cfb   4 [ffffd0b50e1775c8] out_of_line_wait_on_bit at ffffffff9ca05ea5   5 [ffffd0b50e177618] pnfs_roc at ffffffffc154207b [nfsv4]   6 [ffffd0b50e1776b8] _nfs4_proc_delegreturn at ffffffffc1506586 [nfsv4]   7 [ffffd0b50e177788] nfs4_proc_delegreturn at ffffffffc1507480 [nfsv4]   8 [ffffd0b50e1777f8] nfs_do_return_delegation at ffffffffc1523e41 [nfsv4]   9 [ffffd0b50e177838] nfs_inode_set_delegation at ffffffffc1524a75 [nfsv4]  10 [ffffd0b50e177888] nfs4_process_delegation at ffffffffc14f41dd [nfsv4]  11 [ffffd0b50e1778a0] _nfs4_opendata_to_nfs4_state at ffffffffc1503edf [nfsv4]  12 [ffffd0b50e1778c0] _nfs4_open_and_get_state at ffffffffc1504e56 [nfsv4]  13 [ffffd0b50e177978] _nfs4_do_open at ffffffffc15051b8 [nfsv4]  14 [ffffd0b50e1779f8] nfs4_do_open at ffffffffc150559c [nfsv4]  15 [ffffd0b50e177a80] nfs4_atomic_open at ffffffffc15057fb [nfsv4]  16 [ffffd0b50e177ad0] nfs4_file_open at ffffffffc15219be [nfsv4]  17 [ffffd0b50e177b78] do_dentry_open at ffffffff9c09e6ea  18 [ffffd0b50e177ba8] vfs_open at ffffffff9c0a082e  19 [ffffd0b50e177bd0] dentry_open at ffffffff9c0a0935  The issue is that the delegreturn is being asked to wait for a layout return that cannot complete because a state recovery was initiated. The state recovery cannot complete until the open() finishes processing the delegations it was given.  The solution is to propagate the existing flags that indicate a non-blocking call to the function pnfs_roc(), so that it knows not to wait in this situation.

CVE-2026-23088:

        In the Linux kernel, the following vulnerability has been resolved:  tracing: Fix crash on synthetic stacktrace field usage  When creating a synthetic event based on an existing synthetic event that had a stacktrace field and the new synthetic event used that field a kernel crash occurred:   ~# cd /sys/kernel/tracing  ~# echo 's:stack unsigned long stack[];' > dynamic_events  ~# echo 'hist:keys=prev_pid:s0=common_stacktrace if prev_state & 3' >> events/sched/sched_switch/trigger  ~# echo 'hist:keys=next_pid:s1=$s0:onmatch(sched.sched_switch).trace(stack,$s1)' >> events/sched/sched_switch/trigger  The above creates a synthetic event that takes a stacktrace when a task schedules out in a non-running state and passes that stacktrace to the sched_switch event when that task schedules back in. It triggers the "stack" synthetic event that has a stacktrace as its field (called "stack").   ~# echo 's:syscall_stack s64 id; unsigned long stack[];' >> dynamic_events  ~# echo 'hist:keys=common_pid:s2=stack' >> events/synthetic/stack/trigger  ~# echo 'hist:keys=common_pid:s3=$s2,i0=id:onmatch(synthetic.stack).trace(syscall_stack,$i0,$s3)' >> events/raw_syscalls/sys_exit/trigger  The above makes another synthetic event called "syscall_stack" that attaches the first synthetic event (stack) to the sys_exit trace event and records the stacktrace from the stack event with the id of the system call that is exiting.  When enabling this event (or using it in a historgram):   ~# echo 1 > events/synthetic/syscall_stack/enable  Produces a kernel crash!   BUG: unable to handle page fault for address: 0000000000400010  #PF: supervisor read access in kernel mode  #PF: error_code(0x0000) - not-present page  PGD 0 P4D 0  Oops: Oops: 0000 [#1] SMP PTI  CPU: 6 UID: 0 PID: 1257 Comm: bash Not tainted 6.16.3+deb14-amd64 #1 PREEMPT(lazy)  Debian 6.16.3-1  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014  RIP: 0010:trace_event_raw_event_synth+0x90/0x380  Code: c5 00 00 00 00 85 d2 0f 84 e1 00 00 00 31 db eb 34 0f 1f 00 66 66 2e 0f 1f 84 00 00 00 00 00 66 66 2e 0f 1f 84 00 00 00 00 00 <49> 8b 04 24 48 83 c3 01 8d 0c c5 08 00 00 00 01 cd 41 3b 5d 40 0f  RSP: 0018:ffffd2670388f958 EFLAGS: 00010202  RAX: ffff8ba1065cc100 RBX: 0000000000000000 RCX: 0000000000000000  RDX: 0000000000000001 RSI: fffff266ffda7b90 RDI: ffffd2670388f9b0  RBP: 0000000000000010 R08: ffff8ba104e76000 R09: ffffd2670388fa50  R10: ffff8ba102dd42e0 R11: ffffffff9a908970 R12: 0000000000400010  R13: ffff8ba10a246400 R14: ffff8ba10a710220 R15: fffff266ffda7b90  FS:  00007fa3bc63f740(0000) GS:ffff8ba2e0f48000(0000) knlGS:0000000000000000  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  CR2: 0000000000400010 CR3: 0000000107f9e003 CR4: 0000000000172ef0  Call Trace:   <TASK>   ? __tracing_map_insert+0x208/0x3a0   action_trace+0x67/0x70   event_hist_trigger+0x633/0x6d0   event_triggers_call+0x82/0x130   trace_event_buffer_commit+0x19d/0x250   trace_event_raw_event_sys_exit+0x62/0xb0   syscall_exit_work+0x9d/0x140   do_syscall_64+0x20a/0x2f0   ? trace_event_raw_event_sched_switch+0x12b/0x170   ? save_fpregs_to_fpstate+0x3e/0x90   ? _raw_spin_unlock+0xe/0x30   ? finish_task_switch.isra.0+0x97/0x2c0   ? __rseq_handle_notify_resume+0xad/0x4c0   ? __schedule+0x4b8/0xd00   ? restore_fpregs_from_fpstate+0x3c/0x90   ? switch_fpu_return+0x5b/0xe0   ? do_syscall_64+0x1ef/0x2f0   ? do_fault+0x2e9/0x540   ? __handle_mm_fault+0x7d1/0xf70   ? count_memcg_events+0x167/0x1d0   ? handle_mm_fault+0x1d7/0x2e0   ? do_user_addr_fault+0x2c3/0x7f0   entry_SYSCALL_64_after_hwframe+0x76/0x7e  The reason is that the stacktrace field is not labeled as such, and is treated as a normal field and not as a dynamic event that it is.  In trace_event_raw_event_synth() the event is field is still treated as a dynamic array, but the retrieval of the data is considered a normal field, and the reference is just the meta data:  // Meta data is retrieved instead of a dynamic array ---truncated---

CVE-2026-23118:

        In the Linux kernel, the following vulnerability has been resolved:  rxrpc: Fix data-race warning and potential load/store tearing  Fix the following:          BUG: KCSAN: data-race in rxrpc_peer_keepalive_worker / rxrpc_send_data_packet  which is reporting an issue with the reads and writes to ->last_tx_at in:          conn->peer->last_tx_at = ktime_get_seconds();  and:          keepalive_at = peer->last_tx_at + RXRPC_KEEPALIVE_TIME;  The lockless accesses to these to values aren't actually a problem as the read only needs an approximate time of last transmission for the purposes of deciding whether or not the transmission of a keepalive packet is warranted yet.  Also, as ->last_tx_at is a 64-bit value, tearing can occur on a 32-bit arch.  Fix both of these by switching to an unsigned int for ->last_tx_at and only storing the LSW of the time64_t.  It can then be reconstructed at need provided no more than 68 years has elapsed since the last transmission.

CVE-2026-23137:

        In the Linux kernel, the following vulnerability has been resolved:  of: unittest: Fix memory leak in unittest_data_add()  In unittest_data_add(), if of_resolve_phandles() fails, the allocated unittest_data is not freed, leading to a memory leak.  Fix this by using scope-based cleanup helper __free(kfree) for automatic resource cleanup. This ensures unittest_data is automatically freed when it goes out of scope in error paths.  For the success path, use retain_and_null_ptr() to transfer ownership of the memory to the device tree and prevent double freeing.

CVE-2026-23138:

        In the Linux kernel, the following vulnerability has been resolved:  tracing: Add recursion protection in kernel stack trace recording  A bug was reported about an infinite recursion caused by tracing the rcu events with the kernel stack trace trigger enabled. The stack trace code called back into RCU which then called the stack trace again.  Expand the ftrace recursion protection to add a set of bits to protect events from recursion. Each bit represents the context that the event is in (normal, softirq, interrupt and NMI).  Have the stack trace code use the interrupt context to protect against recursion.  Note, the bug showed an issue in both the RCU code as well as the tracing stacktrace code. This only handles the tracing stack trace side of the bug. The RCU fix will be handled separately.

CVE-2026-23171:

        In the Linux kernel, the following vulnerability has been resolved:  bonding: fix use-after-free due to enslave fail after slave array update  Fix a use-after-free which happens due to enslave failure after the new slave has been added to the array. Since the new slave can be used for Tx immediately, we can use it after it has been freed by the enslave error cleanup path which frees the allocated slave memory. Slave update array is supposed to be called last when further enslave failures are not expected. Move it after xdp setup to avoid any problems.  It is very easy to reproduce the problem with a simple xdp_pass prog:  ip l add bond1 type bond mode balance-xor  ip l set bond1 up  ip l set dev bond1 xdp object xdp_pass.o sec xdp_pass  ip l add dumdum type dummy  Then run in parallel:  while :; do ip l set dumdum master bond1 1>/dev/null 2>&1; done;  mausezahn bond1 -a own -b rand -A rand -B 1.1.1.1 -c 0 -t tcp "dp=1-1023, flags=syn"  The crash happens almost immediately:  [  605.602850] Oops: general protection fault, probably for non-canonical address 0xe0e6fc2460000137: 0000 [#1] SMP KASAN NOPTI  [  605.602916] KASAN: maybe wild-memory-access in range [0x07380123000009b8-0x07380123000009bf]  [  605.602946] CPU: 0 UID: 0 PID: 2445 Comm: mausezahn Kdump: loaded Tainted: G    B               6.19.0-rc6+ #21 PREEMPT(voluntary)  [  605.602979] Tainted: [B]=BAD_PAGE  [  605.602998] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014  [  605.603032] RIP: 0010:netdev_core_pick_tx+0xcd/0x210  [  605.603063] Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 3e 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b 6b 08 49 8d 7d 30 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 25 01 00 00 49 8b 45 30 4c 89 e2 48 89 ee 48 89  [  605.603111] RSP: 0018:ffff88817b9af348 EFLAGS: 00010213  [  605.603145] RAX: dffffc0000000000 RBX: ffff88817d28b420 RCX: 0000000000000000  [  605.603172] RDX: 00e7002460000137 RSI: 0000000000000008 RDI: 07380123000009be  [  605.603199] RBP: ffff88817b541a00 R08: 0000000000000001 R09: fffffbfff3ed8c0c  [  605.603226] R10: ffffffff9f6c6067 R11: 0000000000000001 R12: 0000000000000000  [  605.603253] R13: 073801230000098e R14: ffff88817d28b448 R15: ffff88817b541a84  [  605.603286] FS:  00007f6570ef67c0(0000) GS:ffff888221dfa000(0000) knlGS:0000000000000000  [  605.603319] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  [  605.603343] CR2: 00007f65712fae40 CR3: 000000011371b000 CR4: 0000000000350ef0  [  605.603373] Call Trace:  [  605.603392]  <TASK>  [  605.603410]  __dev_queue_xmit+0x448/0x32a0  [  605.603434]  ? __pfx_vprintk_emit+0x10/0x10  [  605.603461]  ? __pfx_vprintk_emit+0x10/0x10  [  605.603484]  ? __pfx___dev_queue_xmit+0x10/0x10  [  605.603507]  ? bond_start_xmit+0xbfb/0xc20 [bonding]  [  605.603546]  ? _printk+0xcb/0x100  [  605.603566]  ? __pfx__printk+0x10/0x10  [  605.603589]  ? bond_start_xmit+0xbfb/0xc20 [bonding]  [  605.603627]  ? add_taint+0x5e/0x70  [  605.603648]  ? add_taint+0x2a/0x70  [  605.603670]  ? end_report.cold+0x51/0x75  [  605.603693]  ? bond_start_xmit+0xbfb/0xc20 [bonding]  [  605.603731]  bond_start_xmit+0x623/0xc20 [bonding]

CVE-2026-23207:

        In the Linux kernel, the following vulnerability has been resolved:  spi: tegra210-quad: Protect curr_xfer check in IRQ handler  Now that all other accesses to curr_xfer are done under the lock, protect the curr_xfer NULL check in tegra_qspi_isr_thread() with the spinlock. Without this protection, the following race can occur:    CPU0 (ISR thread)              CPU1 (timeout path)   ----------------               -------------------   if (!tqspi->curr_xfer)     // sees non-NULL                                  spin_lock()                                  tqspi->curr_xfer = NULL                                  spin_unlock()   handle_*_xfer()     spin_lock()     t = tqspi->curr_xfer  // NULL!     ... t->len ...        // NULL dereference!  With this patch, all curr_xfer accesses are now properly synchronized.  Although all accesses to curr_xfer are done under the lock, in tegra_qspi_isr_thread() it checks for NULL, releases the lock and reacquires it later in handle_cpu_based_xfer()/handle_dma_based_xfer(). There is a potential for an update in between, which could cause a NULL pointer dereference.  To handle this, add a NULL check inside the handlers after acquiring the lock. This ensures that if the timeout path has already cleared curr_xfer, the handler will safely return without dereferencing the NULL pointer.

CVE-2026-23208:

        In the Linux kernel, the following vulnerability has been resolved:  ALSA: usb-audio: Prevent excessive number of frames  In this case, the user constructed the parameters with maxpacksize 40 for rate 22050 / pps 1000, and packsize[0] 22 packsize[1] 23. The buffer size for each data URB is maxpacksize * packets, which in this example is 40 * 6 = 240; When the user performs a write operation to send audio data into the ALSA PCM playback stream, the calculated number of frames is packsize[0] * packets = 264, which exceeds the allocated URB buffer size, triggering the out-of-bounds (OOB) issue reported by syzbot [1].  Added a check for the number of single data URB frames when calculating the number of frames to prevent [1].  [1] BUG: KASAN: slab-out-of-bounds in copy_to_urb+0x261/0x460 sound/usb/pcm.c:1487 Write of size 264 at addr ffff88804337e800 by task syz.0.17/5506 Call Trace:  copy_to_urb+0x261/0x460 sound/usb/pcm.c:1487  prepare_playback_urb+0x953/0x13d0 sound/usb/pcm.c:1611  prepare_outbound_urb+0x377/0xc50 sound/usb/endpoint.c:333

CVE-2026-23213:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/pm: Disable MMIO access during SMU Mode 1 reset  During Mode 1 reset, the ASIC undergoes a reset cycle and becomes temporarily inaccessible via PCIe. Any attempt to access MMIO registers during this window (e.g., from interrupt handlers or other driver threads) can result in uncompleted PCIe transactions, leading to NMI panics or system hangs.  To prevent this, set the `no_hw_access` flag to true immediately after triggering the reset. This signals other driver components to skip register accesses while the device is offline.  A memory barrier `smp_mb()` is added to ensure the flag update is globally visible to all cores before the driver enters the sleep/wait state.  (cherry picked from commit 7edb503fe4b6d67f47d8bb0dfafb8e699bb0f8a4)

CVE-2026-23214:

        In the Linux kernel, the following vulnerability has been resolved:  btrfs: reject new transactions if the fs is fully read-only  [BUG] There is a bug report where a heavily fuzzed fs is mounted with all rescue mount options, which leads to the following warnings during unmount:    BTRFS: Transaction aborted (error -22)   Modules linked in:   CPU: 0 UID: 0 PID: 9758 Comm: repro.out Not tainted   6.19.0-rc5-00002-gb71e635feefc #7 PREEMPT(full)   Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014   RIP: 0010:find_free_extent_update_loop fs/btrfs/extent-tree.c:4208 [inline]   RIP: 0010:find_free_extent+0x52f0/0x5d20 fs/btrfs/extent-tree.c:4611   Call Trace:    <TASK>    btrfs_reserve_extent+0x2cd/0x790 fs/btrfs/extent-tree.c:4705    btrfs_alloc_tree_block+0x1e1/0x10e0 fs/btrfs/extent-tree.c:5157    btrfs_force_cow_block+0x578/0x2410 fs/btrfs/ctree.c:517    btrfs_cow_block+0x3c4/0xa80 fs/btrfs/ctree.c:708    btrfs_search_slot+0xcad/0x2b50 fs/btrfs/ctree.c:2130    btrfs_truncate_inode_items+0x45d/0x2350 fs/btrfs/inode-item.c:499    btrfs_evict_inode+0x923/0xe70 fs/btrfs/inode.c:5628    evict+0x5f4/0xae0 fs/inode.c:837    __dentry_kill+0x209/0x660 fs/dcache.c:670    finish_dput+0xc9/0x480 fs/dcache.c:879    shrink_dcache_for_umount+0xa0/0x170 fs/dcache.c:1661    generic_shutdown_super+0x67/0x2c0 fs/super.c:621    kill_anon_super+0x3b/0x70 fs/super.c:1289    btrfs_kill_super+0x41/0x50 fs/btrfs/super.c:2127    deactivate_locked_super+0xbc/0x130 fs/super.c:474    cleanup_mnt+0x425/0x4c0 fs/namespace.c:1318    task_work_run+0x1d4/0x260 kernel/task_work.c:233    exit_task_work include/linux/task_work.h:40 [inline]    do_exit+0x694/0x22f0 kernel/exit.c:971    do_group_exit+0x21c/0x2d0 kernel/exit.c:1112    __do_sys_exit_group kernel/exit.c:1123 [inline]    __se_sys_exit_group kernel/exit.c:1121 [inline]    __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1121    x64_sys_call+0x2210/0x2210 arch/x86/include/generated/asm/syscalls_64.h:232    do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]    do_syscall_64+0xe8/0xf80 arch/x86/entry/syscall_64.c:94    entry_SYSCALL_64_after_hwframe+0x77/0x7f   RIP: 0033:0x44f639   Code: Unable to access opcode bytes at 0x44f60f.   RSP: 002b:00007ffc15c4e088 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7   RAX: ffffffffffffffda RBX: 00000000004c32f0 RCX: 000000000044f639   RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001   RBP: 0000000000000001 R08: ffffffffffffffc0 R09: 0000000000000000   R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004c32f0   R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001    </TASK>  Since rescue mount options will mark the full fs read-only, there should be no new transaction triggered.  But during unmount we will evict all inodes, which can trigger a new transaction, and triggers warnings on a heavily corrupted fs.  [CAUSE] Btrfs allows new transaction even on a read-only fs, this is to allow log replay happen even on read-only mounts, just like what ext4/xfs do.  However with rescue mount options, the fs is fully read-only and cannot be remounted read-write, thus in that case we should also reject any new transactions.  [FIX] If we find the fs has rescue mount options, we should treat the fs as error, so that no new transaction can be started.

CVE-2026-23226:

        In the Linux kernel, the following vulnerability has been resolved:  ksmbd: add chann_lock to protect ksmbd_chann_list xarray  ksmbd_chann_list xarray lacks synchronization, allowing use-after-free in multi-channel sessions (between lookup_chann_list() and ksmbd_chann_del).  Adds rw_semaphore chann_lock to struct ksmbd_session and protects all xa_load/xa_store/xa_erase accesses.

CVE-2026-23239:

        In the Linux kernel, the following vulnerability has been resolved:  espintcp: Fix race condition in espintcp_close()  This issue was discovered during a code audit.  After cancel_work_sync() is called from espintcp_close(), espintcp_tx_work() can still be scheduled from paths such as the Delayed ACK handler or ksoftirqd. As a result, the espintcp_tx_work() worker may dereference a freed espintcp ctx or sk.  The following is a simple race scenario:             cpu0                             cpu1    espintcp_close()     cancel_work_sync(&ctx->work);                                      espintcp_write_space()                                        schedule_work(&ctx->work);  To prevent this race condition, cancel_work_sync() is replaced with disable_work_sync().

CVE-2026-23240:

        In the Linux kernel, the following vulnerability has been resolved:  tls: Fix race condition in tls_sw_cancel_work_tx()  This issue was discovered during a code audit.  After cancel_delayed_work_sync() is called from tls_sk_proto_close(), tx_work_handler() can still be scheduled from paths such as the Delayed ACK handler or ksoftirqd. As a result, the tx_work_handler() worker may dereference a freed TLS object.  The following is a simple race scenario:            cpu0                         cpu1  tls_sk_proto_close()   tls_sw_cancel_work_tx()                                  tls_write_space()                                    tls_sw_write_space()                                      if (!test_and_set_bit(BIT_TX_SCHEDULED, &tx_ctx->tx_bitmask))     set_bit(BIT_TX_SCHEDULED, &ctx->tx_bitmask);     cancel_delayed_work_sync(&ctx->tx_work.work);                                      schedule_delayed_work(&tx_ctx->tx_work.work, 0);  To prevent this race condition, cancel_delayed_work_sync() is replaced with disable_delayed_work_sync().

CVE-2026-23247:

        In the Linux kernel, the following vulnerability has been resolved:  tcp: secure_seq: add back ports to TS offset  This reverts 28ee1b746f49 ("secure_seq: downgrade to per-host timestamp offsets")  tcp_tw_recycle went away in 2017.  Zhouyan Deng reported off-path TCP source port leakage via SYN cookie side-channel that can be fixed in multiple ways.  One of them is to bring back TCP ports in TS offset randomization.  As a bonus, we perform a single siphash() computation to provide both an ISN and a TS offset.

CVE-2026-23265:

        In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to do sanity check on node footer in {read,write}_end_io  -----------[ cut here ]------------ kernel BUG at fs/f2fs/data.c:358! Call Trace:  <IRQ>  blk_update_request+0x5eb/0xe70 block/blk-mq.c:987  blk_mq_end_request+0x3e/0x70 block/blk-mq.c:1149  blk_complete_reqs block/blk-mq.c:1224 [inline]  blk_done_softirq+0x107/0x160 block/blk-mq.c:1229  handle_softirqs+0x283/0x870 kernel/softirq.c:579  __do_softirq kernel/softirq.c:613 [inline]  invoke_softirq kernel/softirq.c:453 [inline]  __irq_exit_rcu+0xca/0x1f0 kernel/softirq.c:680  irq_exit_rcu+0x9/0x30 kernel/softirq.c:696  instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1050 [inline]  sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1050  </IRQ>  In f2fs_write_end_io(), it detects there is inconsistency in between node page index (nid) and footer.nid of node page.  If footer of node page is corrupted in fuzzed image, then we load corrupted node page w/ async method, e.g. f2fs_ra_node_pages() or f2fs_ra_node_page(), in where we won't do sanity check on node footer, once node page becomes dirty, we will encounter this bug after node page writeback.

CVE-2026-23276:

        In the Linux kernel, the following vulnerability has been resolved:  net: add xmit recursion limit to tunnel xmit functions  Tunnel xmit functions (iptunnel_xmit, ip6tunnel_xmit) lack their own recursion limit. When a bond device in broadcast mode has GRE tap interfaces as slaves, and those GRE tunnels route back through the bond, multicast/broadcast traffic triggers infinite recursion between bond_xmit_broadcast() and ip_tunnel_xmit()/ip6_tnl_xmit(), causing kernel stack overflow.  The existing XMIT_RECURSION_LIMIT (8) in the no-qdisc path is not sufficient because tunnel recursion involves route lookups and full IP output, consuming much more stack per level. Use a lower limit of 4 (IP_TUNNEL_RECURSION_LIMIT) to prevent overflow.  Add recursion detection using dev_xmit_recursion helpers directly in iptunnel_xmit() and ip6tunnel_xmit() to cover all IPv4/IPv6 tunnel paths including UDP encapsulated tunnels (VXLAN, Geneve, etc.).  Move dev_xmit_recursion helpers from net/core/dev.h to public header include/linux/netdevice.h so they can be used by tunnel code.   BUG: KASAN: stack-out-of-bounds in blake2s.constprop.0+0xe7/0x160  Write of size 32 at addr ffff88810033fed0 by task kworker/0:1/11  Workqueue: mld mld_ifc_work  Call Trace:   <TASK>   __build_flow_key.constprop.0 (net/ipv4/route.c:515)   ip_rt_update_pmtu (net/ipv4/route.c:1073)   iptunnel_xmit (net/ipv4/ip_tunnel_core.c:84)   ip_tunnel_xmit (net/ipv4/ip_tunnel.c:847)   gre_tap_xmit (net/ipv4/ip_gre.c:779)   dev_hard_start_xmit (net/core/dev.c:3887)   sch_direct_xmit (net/sched/sch_generic.c:347)   __dev_queue_xmit (net/core/dev.c:4802)   bond_dev_queue_xmit (drivers/net/bonding/bond_main.c:312)   bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5279)   bond_start_xmit (drivers/net/bonding/bond_main.c:5530)   dev_hard_start_xmit (net/core/dev.c:3887)   __dev_queue_xmit (net/core/dev.c:4841)   ip_finish_output2 (net/ipv4/ip_output.c:237)   ip_output (net/ipv4/ip_output.c:438)   iptunnel_xmit (net/ipv4/ip_tunnel_core.c:86)   gre_tap_xmit (net/ipv4/ip_gre.c:779)   dev_hard_start_xmit (net/core/dev.c:3887)   sch_direct_xmit (net/sched/sch_generic.c:347)   __dev_queue_xmit (net/core/dev.c:4802)   bond_dev_queue_xmit (drivers/net/bonding/bond_main.c:312)   bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5279)   bond_start_xmit (drivers/net/bonding/bond_main.c:5530)   dev_hard_start_xmit (net/core/dev.c:3887)   __dev_queue_xmit (net/core/dev.c:4841)   ip_finish_output2 (net/ipv4/ip_output.c:237)   ip_output (net/ipv4/ip_output.c:438)   iptunnel_xmit (net/ipv4/ip_tunnel_core.c:86)   ip_tunnel_xmit (net/ipv4/ip_tunnel.c:847)   gre_tap_xmit (net/ipv4/ip_gre.c:779)   dev_hard_start_xmit (net/core/dev.c:3887)   sch_direct_xmit (net/sched/sch_generic.c:347)   __dev_queue_xmit (net/core/dev.c:4802)   bond_dev_queue_xmit (drivers/net/bonding/bond_main.c:312)   bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5279)   bond_start_xmit (drivers/net/bonding/bond_main.c:5530)   dev_hard_start_xmit (net/core/dev.c:3887)   __dev_queue_xmit (net/core/dev.c:4841)   mld_sendpack   mld_ifc_work   process_one_work   worker_thread   </TASK>

CVE-2026-23327:

        In the Linux kernel, the following vulnerability has been resolved:  cxl/mbox: validate payload size before accessing contents in cxl_payload_from_user_allowed()  cxl_payload_from_user_allowed() casts and dereferences the input payload without first verifying its size. When a raw mailbox command is sent with an undersized payload (ie: 1 byte for CXL_MBOX_OP_CLEAR_LOG, which expects a 16-byte UUID), uuid_equal() reads past the allocated buffer, triggering a KASAN splat:  BUG: KASAN: slab-out-of-bounds in memcmp+0x176/0x1d0 lib/string.c:683 Read of size 8 at addr ffff88810130f5c0 by task syz.1.62/2258  CPU: 2 UID: 0 PID: 2258 Comm: syz.1.62 Not tainted 6.19.0-dirty #3 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 Call Trace:  <TASK>  __dump_stack lib/dump_stack.c:94 [inline]  dump_stack_lvl+0xab/0xe0 lib/dump_stack.c:120  print_address_description mm/kasan/report.c:378 [inline]  print_report+0xce/0x650 mm/kasan/report.c:482  kasan_report+0xce/0x100 mm/kasan/report.c:595  memcmp+0x176/0x1d0 lib/string.c:683  uuid_equal include/linux/uuid.h:73 [inline]  cxl_payload_from_user_allowed drivers/cxl/core/mbox.c:345 [inline]  cxl_mbox_cmd_ctor drivers/cxl/core/mbox.c:368 [inline]  cxl_validate_cmd_from_user drivers/cxl/core/mbox.c:522 [inline]  cxl_send_cmd+0x9c0/0xb50 drivers/cxl/core/mbox.c:643  __cxl_memdev_ioctl drivers/cxl/core/memdev.c:698 [inline]  cxl_memdev_ioctl+0x14f/0x190 drivers/cxl/core/memdev.c:713  vfs_ioctl fs/ioctl.c:51 [inline]  __do_sys_ioctl fs/ioctl.c:597 [inline]  __se_sys_ioctl fs/ioctl.c:583 [inline]  __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]  do_syscall_64+0xa8/0x330 arch/x86/entry/syscall_64.c:94  entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fdaf331ba79 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fdaf1d77038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007fdaf3585fa0 RCX: 00007fdaf331ba79 RDX: 00002000000001c0 RSI: 00000000c030ce02 RDI: 0000000000000003 RBP: 00007fdaf33749df R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fdaf3586038 R14: 00007fdaf3585fa0 R15: 00007ffced2af768  </TASK>  Add 'in_size' parameter to cxl_payload_from_user_allowed() and validate the payload is large enough.

CVE-2026-23330:

        In the Linux kernel, the following vulnerability has been resolved:  nfc: nci: complete pending data exchange on device close  In nci_close_device(), complete any pending data exchange before closing. The data exchange callback (e.g. rawsock_data_exchange_complete) holds a socket reference.  NIPA occasionally hits this leak:  unreferenced object 0xff1100000f435000 (size 2048):   comm "nci_dev", pid 3954, jiffies 4295441245   hex dump (first 32 bytes):     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................     27 00 01 40 00 00 00 00 00 00 00 00 00 00 00 00  '..@............   backtrace (crc ec2b3c5):     __kmalloc_noprof+0x4db/0x730     sk_prot_alloc.isra.0+0xe4/0x1d0     sk_alloc+0x36/0x760     rawsock_create+0xd1/0x540     nfc_sock_create+0x11f/0x280     __sock_create+0x22d/0x630     __sys_socket+0x115/0x1d0     __x64_sys_socket+0x72/0xd0     do_syscall_64+0x117/0xfc0     entry_SYSCALL_64_after_hwframe+0x4b/0x53

CVE-2026-23346:

        In the Linux kernel, the following vulnerability has been resolved:  arm64: io: Extract user memory type in ioremap_prot()  The only caller of ioremap_prot() outside of the generic ioremap() implementation is generic_access_phys(), which passes a 'pgprot_t' value determined from the user mapping of the target 'pfn' being accessed by the kernel. On arm64, the 'pgprot_t' contains all of the non-address bits from the pte, including the permission controls, and so we end up returning a new user mapping from ioremap_prot() which faults when accessed from the kernel on systems with PAN:    | Unable to handle kernel read from unreadable memory at virtual address ffff80008ea89000   | ...   | Call trace:   |   __memcpy_fromio+0x80/0xf8   |   generic_access_phys+0x20c/0x2b8   |   __access_remote_vm+0x46c/0x5b8   |   access_remote_vm+0x18/0x30   |   environ_read+0x238/0x3e8   |   vfs_read+0xe4/0x2b0   |   ksys_read+0xcc/0x178   |   __arm64_sys_read+0x4c/0x68  Extract only the memory type from the user 'pgprot_t' in ioremap_prot() and assert that we're being passed a user mapping, to protect us against any changes in future that may require additional handling. To avoid falsely flagging users of ioremap(), provide our own ioremap() macro which simply wraps __ioremap_prot().

CVE-2026-23348:

        In the Linux kernel, the following vulnerability has been resolved:  cxl: Fix race of nvdimm_bus object when creating nvdimm objects  Found issue during running of cxl-translate.sh unit test. Adding a 3s sleep right before the test seems to make the issue reproduce fairly consistently. The cxl_translate module has dependency on cxl_acpi and causes orphaned nvdimm objects to reprobe after cxl_acpi is removed. The nvdimm_bus object is registered by the cxl_nvb object when cxl_acpi_probe() is called. With the nvdimm_bus object missing, __nd_device_register() will trigger NULL pointer dereference when accessing the dev->parent that points to &nvdimm_bus->dev.  [  192.884510] BUG: kernel NULL pointer dereference, address: 000000000000006c [  192.895383] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20250812-19.fc42 08/12/2025 [  192.897721] Workqueue: cxl_port cxl_bus_rescan_queue [cxl_core] [  192.899459] RIP: 0010:kobject_get+0xc/0x90 [  192.924871] Call Trace: [  192.925959]  <TASK> [  192.926976]  ? pm_runtime_init+0xb9/0xe0 [  192.929712]  __nd_device_register.part.0+0x4d/0xc0 [libnvdimm] [  192.933314]  __nvdimm_create+0x206/0x290 [libnvdimm] [  192.936662]  cxl_nvdimm_probe+0x119/0x1d0 [cxl_pmem] [  192.940245]  cxl_bus_probe+0x1a/0x60 [cxl_core] [  192.943349]  really_probe+0xde/0x380  This patch also relies on the previous change where devm_cxl_add_nvdimm_bridge() is called from drivers/cxl/pmem.c instead of drivers/cxl/core.c to ensure the dependency of cxl_acpi on cxl_pmem.  1. Set probe_type of cxl_nvb to PROBE_FORCE_SYNCHRONOUS to ensure the    driver is probed synchronously when add_device() is called. 2. Add a check in __devm_cxl_add_nvdimm_bridge() to ensure that the    cxl_nvb driver is attached during cxl_acpi_probe(). 3. Take the cxl_root uport_dev lock and the cxl_nvb->dev lock in    devm_cxl_add_nvdimm() before checking nvdimm_bus is valid. 4. Set cxl_nvdimm flag to CXL_NVD_F_INVALIDATED so cxl_nvdimm_probe()    will exit with -EBUSY.  The removal of cxl_nvdimm devices should prevent any orphaned devices from probing once the nvdimm_bus is gone.  [ dj: Fixed 0-day reported kdoc issue. ] [ dj: Fix cxl_nvb reference leak on error. Gregory (kreview-0811365) ]

CVE-2026-23361:

        In the Linux kernel, the following vulnerability has been resolved:  PCI: dwc: ep: Flush MSI-X write before unmapping its ATU entry  Endpoint drivers use dw_pcie_ep_raise_msix_irq() to raise an MSI-X interrupt to the host using a writel(), which generates a PCI posted write transaction.  There's no completion for posted writes, so the writel() may return before the PCI write completes.  dw_pcie_ep_raise_msix_irq() also unmaps the outbound ATU entry used for the PCI write, so the write races with the unmap.  If the PCI write loses the race with the ATU unmap, the write may corrupt host memory or cause IOMMU errors, e.g., these when running fio with a larger queue depth against nvmet-pci-epf:    arm-smmu-v3 fc900000.iommu:      0x0000010000000010   arm-smmu-v3 fc900000.iommu:      0x0000020000000000   arm-smmu-v3 fc900000.iommu:      0x000000090000f040   arm-smmu-v3 fc900000.iommu:      0x0000000000000000   arm-smmu-v3 fc900000.iommu: event: F_TRANSLATION client: 0000:01:00.0 sid: 0x100 ssid: 0x0 iova: 0x90000f040 ipa: 0x0   arm-smmu-v3 fc900000.iommu: unpriv data write s1 "Input address caused fault" stag: 0x0  Flush the write by performing a readl() of the same address to ensure that the write has reached the destination before the ATU entry is unmapped.  The same problem was solved for dw_pcie_ep_raise_msi_irq() in commit 8719c64e76bf ("PCI: dwc: ep: Cache MSI outbound iATU mapping"), but there it was solved by dedicating an outbound iATU only for MSI. We can't do the same for MSI-X because each vector can have a different msg_addr and the msg_addr may be changed while the vector is masked.  [bhelgaas: commit log]

CVE-2026-23371:

        In the Linux kernel, the following vulnerability has been resolved:  sched/deadline: Fix missing ENQUEUE_REPLENISH during PI de-boosting  Running stress-ng --schedpolicy 0 on an RT kernel on a big machine might lead to the following WARNINGs (edited).   sched: DL de-boosted task PID 22725: REPLENISH flag missing   WARNING: CPU: 93 PID: 0 at kernel/sched/deadline.c:239 dequeue_task_dl+0x15c/0x1f8  ... (running_bw underflow)  Call trace:   dequeue_task_dl+0x15c/0x1f8 (P)   dequeue_task+0x80/0x168   deactivate_task+0x24/0x50   push_dl_task+0x264/0x2e0   dl_task_timer+0x1b0/0x228   __hrtimer_run_queues+0x188/0x378   hrtimer_interrupt+0xfc/0x260   ...  The problem is that when a SCHED_DEADLINE task (lock holder) is changed to a lower priority class via sched_setscheduler(), it may fail to properly inherit the parameters of potential DEADLINE donors if it didn't already inherit them in the past (shorter deadline than donor's at that time). This might lead to bandwidth accounting corruption, as enqueue_task_dl() won't recognize the lock holder as boosted.  The scenario occurs when: 1. A DEADLINE task (donor) blocks on a PI mutex held by another    DEADLINE task (holder), but the holder doesn't inherit parameters    (e.g., it already has a shorter deadline) 2. sched_setscheduler() changes the holder from DEADLINE to a lower    class while still holding the mutex 3. The holder should now inherit DEADLINE parameters from the donor    and be enqueued with ENQUEUE_REPLENISH, but this doesn't happen  Fix the issue by introducing __setscheduler_dl_pi(), which detects when a DEADLINE (proper or boosted) task gets setscheduled to a lower priority class. In case, the function makes the task inherit DEADLINE parameters of the donoer (pi_se) and sets ENQUEUE_REPLENISH flag to ensure proper bandwidth accounting during the next enqueue operation.

CVE-2026-23374:

        In the Linux kernel, the following vulnerability has been resolved:  blktrace: fix __this_cpu_read/write in preemptible context  tracing_record_cmdline() internally uses __this_cpu_read() and __this_cpu_write() on the per-CPU variable trace_cmdline_save, and trace_save_cmdline() explicitly asserts preemption is disabled via lockdep_assert_preemption_disabled(). These operations are only safe when preemption is off, as they were designed to be called from the scheduler context (probe_wakeup_sched_switch() / probe_wakeup()).  __blk_add_trace() was calling tracing_record_cmdline(current) early in the blk_tracer path, before ring buffer reservation, from process context where preemption is fully enabled. This triggers the following using blktests/blktrace/002:  blktrace/002 (blktrace ftrace corruption with sysfs trace)   [failed]     runtime  0.367s  ...  0.437s     something found in dmesg:     [   81.211018] run blktests blktrace/002 at 2026-02-25 22:24:33     [   81.239580] null_blk: disk nullb1 created     [   81.357294] BUG: using __this_cpu_read() in preemptible [00000000] code: dd/2516     [   81.362842] caller is tracing_record_cmdline+0x10/0x40     [   81.362872] CPU: 16 UID: 0 PID: 2516 Comm: dd Tainted: G                 N  7.0.0-rc1lblk+ #84 PREEMPT(full)     [   81.362877] Tainted: [N]=TEST     [   81.362878] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014     [   81.362881] Call Trace:     [   81.362884]  <TASK>     [   81.362886]  dump_stack_lvl+0x8d/0xb0     ...     (See '/mnt/sda/blktests/results/nodev/blktrace/002.dmesg' for the entire message)  [   81.211018] run blktests blktrace/002 at 2026-02-25 22:24:33 [   81.239580] null_blk: disk nullb1 created [   81.357294] BUG: using __this_cpu_read() in preemptible [00000000] code: dd/2516 [   81.362842] caller is tracing_record_cmdline+0x10/0x40 [   81.362872] CPU: 16 UID: 0 PID: 2516 Comm: dd Tainted: G                 N  7.0.0-rc1lblk+ #84 PREEMPT(full) [   81.362877] Tainted: [N]=TEST [   81.362878] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 [   81.362881] Call Trace: [   81.362884]  <TASK> [   81.362886]  dump_stack_lvl+0x8d/0xb0 [   81.362895]  check_preemption_disabled+0xce/0xe0 [   81.362902]  tracing_record_cmdline+0x10/0x40 [   81.362923]  __blk_add_trace+0x307/0x5d0 [   81.362934]  ? lock_acquire+0xe0/0x300 [   81.362940]  ? iov_iter_extract_pages+0x101/0xa30 [   81.362959]  blk_add_trace_bio+0x106/0x1e0 [   81.362968]  submit_bio_noacct_nocheck+0x24b/0x3a0 [   81.362979]  ? lockdep_init_map_type+0x58/0x260 [   81.362988]  submit_bio_wait+0x56/0x90 [   81.363009]  __blkdev_direct_IO_simple+0x16c/0x250 [   81.363026]  ? __pfx_submit_bio_wait_endio+0x10/0x10 [   81.363038]  ? rcu_read_lock_any_held+0x73/0xa0 [   81.363051]  blkdev_read_iter+0xc1/0x140 [   81.363059]  vfs_read+0x20b/0x330 [   81.363083]  ksys_read+0x67/0xe0 [   81.363090]  do_syscall_64+0xbf/0xf00 [   81.363102]  entry_SYSCALL_64_after_hwframe+0x76/0x7e [   81.363106] RIP: 0033:0x7f281906029d [   81.363111] Code: 31 c0 e9 c6 fe ff ff 50 48 8d 3d 66 63 0a 00 e8 59 ff 01 00 66 0f 1f 84 00 00 00 00 00 80 3d 41 33 0e 00 00 74 17 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 5b c3 66 2e 0f 1f 84 00 00 00 00 00 48 83 ec [   81.363113] RSP: 002b:00007ffca127dd48 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [   81.363120] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f281906029d [   81.363122] RDX: 0000000000001000 RSI: 0000559f8bfae000 RDI: 0000000000000000 [   81.363123] RBP: 0000000000001000 R08: 0000002863a10a81 R09: 00007f281915f000 [   81.363124] R10: 00007f2818f77b60 R11: 0000000000000246 R12: 0000559f8bfae000 [   81.363126] R13: 0000000000000000 R14: 0000000000000000 R15: 000000000000000a [   81.363142]  </TASK>  The same BUG fires from blk_add_trace_plug(), blk_add_trace_unplug(), and blk_add_trace_rq() paths as well.  The purpose of tracin ---truncated---

CVE-2026-23383:

        In the Linux kernel, the following vulnerability has been resolved:  bpf, arm64: Force 8-byte alignment for JIT buffer to prevent atomic tearing  struct bpf_plt contains a u64 target field. Currently, the BPF JIT allocator requests an alignment of 4 bytes (sizeof(u32)) for the JIT buffer.  Because the base address of the JIT buffer can be 4-byte aligned (e.g., ending in 0x4 or 0xc), the relative padding logic in build_plt() fails to ensure that target lands on an 8-byte boundary.  This leads to two issues: 1. UBSAN reports misaligned-access warnings when dereferencing the    structure. 2. More critically, target is updated concurrently via WRITE_ONCE() in    bpf_arch_text_poke() while the JIT'd code executes ldr. On arm64,    64-bit loads/stores are only guaranteed to be single-copy atomic if    they are 64-bit aligned. A misaligned target risks a torn read,    causing the JIT to jump to a corrupted address.  Fix this by increasing the allocation alignment requirement to 8 bytes (sizeof(u64)) in bpf_jit_binary_pack_alloc(). This anchors the base of the JIT buffer to an 8-byte boundary, allowing the relative padding math in build_plt() to correctly align the target field.

CVE-2026-23393:

        In the Linux kernel, the following vulnerability has been resolved:  bridge: cfm: Fix race condition in peer_mep deletion  When a peer MEP is being deleted, cancel_delayed_work_sync() is called on ccm_rx_dwork before freeing. However, br_cfm_frame_rx() runs in softirq context under rcu_read_lock (without RTNL) and can re-schedule ccm_rx_dwork via ccm_rx_timer_start() between cancel_delayed_work_sync() returning and kfree_rcu() being called.  The following is a simple race scenario:             cpu0                                     cpu1  mep_delete_implementation()   cancel_delayed_work_sync(ccm_rx_dwork);                                            br_cfm_frame_rx()                                              // peer_mep still in hlist                                              if (peer_mep->ccm_defect)                                                ccm_rx_timer_start()                                                  queue_delayed_work(ccm_rx_dwork)   hlist_del_rcu(&peer_mep->head);   kfree_rcu(peer_mep, rcu);                                            ccm_rx_work_expired()                                              // on freed peer_mep  To prevent this, cancel_delayed_work_sync() is replaced with disable_delayed_work_sync() in both peer MEP deletion paths, so that subsequent queue_delayed_work() calls from br_cfm_frame_rx() are silently rejected.  The cc_peer_disable() helper retains cancel_delayed_work_sync() because it is also used for the CC enable/disable toggle path where the work must remain re-schedulable.

CVE-2026-23419:

        In the Linux kernel, the following vulnerability has been resolved:  net/rds: Fix circular locking dependency in rds_tcp_tune  syzbot reported a circular locking dependency in rds_tcp_tune() where sk_net_refcnt_upgrade() is called while holding the socket lock:  ====================================================== WARNING: possible circular locking dependency detected ====================================================== kworker/u10:8/15040 is trying to acquire lock: ffffffff8e9aaf80 (fs_reclaim){+.+.}-{0:0}, at: __kmalloc_cache_noprof+0x4b/0x6f0  but task is already holding lock: ffff88805a3c1ce0 (k-sk_lock-AF_INET6){+.+.}-{0:0}, at: rds_tcp_tune+0xd7/0x930  The issue occurs because sk_net_refcnt_upgrade() performs memory allocation (via get_net_track() -> ref_tracker_alloc()) while the socket lock is held, creating a circular dependency with fs_reclaim.  Fix this by moving sk_net_refcnt_upgrade() outside the socket lock critical section. This is safe because the fields modified by the sk_net_refcnt_upgrade() call (sk_net_refcnt, ns_tracker) are not accessed by any concurrent code path at this point.  v2:   - Corrected fixes tag   - check patch line wrap nits   - ai commentary nits

CVE-2026-23465:

        In the Linux kernel, the following vulnerability has been resolved:  btrfs: log new dentries when logging parent dir of a conflicting inode  If we log the parent directory of a conflicting inode, we are not logging the new dentries of the directory, so when we finish we have the parent directory's inode marked as logged but we did not log its new dentries. As a consequence if the parent directory is explicitly fsynced later and it does not have any new changes since we logged it, the fsync is a no-op and after a power failure the new dentries are missing.  Example scenario:    $ mkdir foo    $ sync    $rmdir foo    $ mkdir dir1   $ mkdir dir2    # A file with the same name and parent as the directory we just deleted   # and was persisted in a past transaction. So the deleted directory's   # inode is a conflicting inode of this new file's inode.   $ touch foo    $ ln foo dir2/link    # The fsync on dir2 will log the parent directory (".") because the   # conflicting inode (deleted directory) does not exists anymore, but it   # it does not log its new dentries (dir1).   $ xfs_io -c "fsync" dir2    # This fsync on the parent directory is no-op, since the previous fsync   # logged it (but without logging its new dentries).   $ xfs_io -c "fsync" .    <power failure>    # After log replay dir1 is missing.  Fix this by ensuring we log new dir dentries whenever we log the parent directory of a no longer existing conflicting inode.  A test case for fstests will follow soon.

CVE-2026-23472:

        In the Linux kernel, the following vulnerability has been resolved:  serial: core: fix infinite loop in handle_tx() for PORT_UNKNOWN  uart_write_room() and uart_write() behave inconsistently when xmit_buf is NULL (which happens for PORT_UNKNOWN ports that were never properly initialized):  - uart_write_room() returns kfifo_avail() which can be > 0 - uart_write() checks xmit_buf and returns 0 if NULL  This inconsistency causes an infinite loop in drivers that rely on tty_write_room() to determine if they can write:    while (tty_write_room(tty) > 0) {       written = tty->ops->write(...);       // written is always 0, loop never exits   }  For example, caif_serial's handle_tx() enters an infinite loop when used with PORT_UNKNOWN serial ports, causing system hangs.  Fix by making uart_write_room() also check xmit_buf and return 0 if it's NULL, consistent with uart_write().  Reproducer: https://gist.github.com/mrpre/d9a694cc0e19828ee3bc3b37983fde13

CVE-2026-31410:

        In the Linux kernel, the following vulnerability has been resolved:  ksmbd: use volume UUID in FS_OBJECT_ID_INFORMATION  Use sb->s_uuid for a proper volume identifier as the primary choice. For filesystems that do not provide a UUID, fall back to stfs.f_fsid obtained from vfs_statfs().

CVE-2026-31432:

        In the Linux kernel, the following vulnerability has been resolved:  ksmbd: fix OOB write in QUERY_INFO for compound requests  When a compound request such as READ + QUERY_INFO(Security) is received, and the first command (READ) consumes most of the response buffer, ksmbd could write beyond the allocated buffer while building a security descriptor.  The root cause was that smb2_get_info_sec() checked buffer space using ppntsd_size from xattr, while build_sec_desc() often synthesized a significantly larger descriptor from POSIX ACLs.  This patch introduces smb_acl_sec_desc_scratch_len() to accurately compute the final descriptor size beforehand, performs proper buffer checking with smb2_calc_max_out_buf_len(), and uses exact-sized allocation + iov pinning.

CVE-2026-31458:

        In the Linux kernel, the following vulnerability has been resolved:  mm/damon/sysfs: check contexts->nr before accessing contexts_arr[0]  Multiple sysfs command paths dereference contexts_arr[0] without first verifying that kdamond->contexts->nr == 1.  A user can set nr_contexts to 0 via sysfs while DAMON is running, causing NULL pointer dereferences.  In more detail, the issue can be triggered by privileged users like below.  First, start DAMON and make contexts directory empty (kdamond->contexts->nr == 0).      # damo start     # cd /sys/kernel/mm/damon/admin/kdamonds/0     # echo 0 > contexts/nr_contexts  Then, each of below commands will cause the NULL pointer dereference.      # echo update_schemes_stats > state     # echo update_schemes_tried_regions > state     # echo update_schemes_tried_bytes > state     # echo update_schemes_effective_quotas > state     # echo update_tuned_intervals > state  Guard all commands (except OFF) at the entry point of damon_sysfs_handle_cmd().

CVE-2026-31462:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu: prevent immediate PASID reuse case  PASID resue could cause interrupt issue when process immediately runs into hw state left by previous process exited with the same PASID, it's possible that page faults are still pending in the IH ring buffer when the process exits and frees up its PASID. To prevent the case, it uses idr cyclic allocator same as kernel pid's.  (cherry picked from commit 8f1de51f49be692de137c8525106e0fce2d1912d)

CVE-2026-31486:

        In the Linux kernel, the following vulnerability has been resolved:  hwmon: (pmbus/core) Protect regulator operations with mutex  The regulator operations pmbus_regulator_get_voltage(), pmbus_regulator_set_voltage(), and pmbus_regulator_list_voltage() access PMBus registers and shared data but were not protected by the update_lock mutex. This could lead to race conditions.  However, adding mutex protection directly to these functions causes a deadlock because pmbus_regulator_notify() (which calls regulator_notifier_call_chain()) is often called with the mutex already held (e.g., from pmbus_fault_handler()). If a regulator callback then calls one of the now-protected voltage functions, it will attempt to acquire the same mutex.  Rework pmbus_regulator_notify() to utilize a worker function to send notifications outside of the mutex protection. Events are stored as atomics in a per-page bitmask and processed by the worker.  Initialize the worker and its associated data during regulator registration, and ensure it is cancelled on device removal using devm_add_action_or_reset().  While at it, remove the unnecessary include of linux/of.h.

CVE-2026-31487:

        In the Linux kernel, the following vulnerability has been resolved:  spi: use generic driver_override infrastructure  When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF.  Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally.  Note that calling match() from __driver_attach() without the device lock held is intentional. [1]  Also note that we do not enable the driver_override feature of struct bus_type, as SPI - in contrast to most other buses - passes "" to sysfs_emit() when the driver_override pointer is NULL. Thus, printing "\n" instead of "(null)\n".

CVE-2026-31493:

        In the Linux kernel, the following vulnerability has been resolved:  RDMA/efa: Fix use of completion ctx after free  On admin queue completion handling, if the admin command completed with error we print data from the completion context. The issue is that we already freed the completion context in polling/interrupts handler which means we print data from context in an unknown state (it might be already used again). Change the admin submission flow so alloc/dealloc of the context will be symmetric and dealloc will be called after any potential use of the context.

CVE-2026-31502:

        In the Linux kernel, the following vulnerability has been resolved:  team: fix header_ops type confusion with non-Ethernet ports  Similar to commit 950803f72547 ("bonding: fix type confusion in bond_setup_by_slave()") team has the same class of header_ops type confusion.  For non-Ethernet ports, team_setup_by_port() copies port_dev->header_ops directly. When the team device later calls dev_hard_header() or dev_parse_header(), these callbacks can run with the team net_device instead of the real lower device, so netdev_priv(dev) is interpreted as the wrong private type and can crash.  The syzbot report shows a crash in bond_header_create(), but the root cause is in team: the topology is gre -> bond -> team, and team calls the inherited header_ops with its own net_device instead of the lower device, so bond_header_create() receives a team device and interprets netdev_priv() as bonding private data, causing a type confusion crash.  Fix this by introducing team header_ops wrappers for create/parse, selecting a team port under RCU, and calling the lower device callbacks with port->dev, so each callback always sees the correct net_device context.  Also pass the selected lower device to the lower parse callback, so recursion is bounded in stacked non-Ethernet topologies and parse callbacks always run with the correct device context.

CVE-2026-31505:

        In the Linux kernel, the following vulnerability has been resolved:  iavf: fix out-of-bounds writes in iavf_get_ethtool_stats()  iavf incorrectly uses real_num_tx_queues for ETH_SS_STATS. Since the value could change in runtime, we should use num_tx_queues instead.  Moreover iavf_get_ethtool_stats() uses num_active_queues while iavf_get_sset_count() and iavf_get_stat_strings() use real_num_tx_queues, which triggers out-of-bounds writes when we do "ethtool -L" and "ethtool -S" simultaneously [1].  For example when we change channels from 1 to 8, Thread 3 could be scheduled before Thread 2, and out-of-bounds writes could be triggered in Thread 3:  Thread 1 (ethtool -L)       Thread 2 (work)        Thread 3 (ethtool -S) iavf_set_channels() ... iavf_alloc_queues() -> num_active_queues = 8 iavf_schedule_finish_config()                                                    iavf_get_sset_count()                                                    real_num_tx_queues: 1                                                    -> buffer for 1 queue                                                    iavf_get_ethtool_stats()                                                    num_active_queues: 8                                                    -> out-of-bounds!                             iavf_finish_config()                             -> real_num_tx_queues = 8  Use immutable num_tx_queues in all related functions to avoid the issue.  [1]  BUG: KASAN: vmalloc-out-of-bounds in iavf_add_one_ethtool_stat+0x200/0x270  Write of size 8 at addr ffffc900031c9080 by task ethtool/5800   CPU: 1 UID: 0 PID: 5800 Comm: ethtool Not tainted 6.19.0-enjuk-08403-g8137e3db7f1c #241 PREEMPT(full)  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014  Call Trace:   <TASK>   dump_stack_lvl+0x6f/0xb0   print_report+0x170/0x4f3   kasan_report+0xe1/0x180   iavf_add_one_ethtool_stat+0x200/0x270   iavf_get_ethtool_stats+0x14c/0x2e0   __dev_ethtool+0x3d0c/0x5830   dev_ethtool+0x12d/0x270   dev_ioctl+0x53c/0xe30   sock_do_ioctl+0x1a9/0x270   sock_ioctl+0x3d4/0x5e0   __x64_sys_ioctl+0x137/0x1c0   do_syscall_64+0xf3/0x690   entry_SYSCALL_64_after_hwframe+0x77/0x7f  RIP: 0033:0x7f7da0e6e36d  ...   </TASK>   The buggy address belongs to a 1-page vmalloc region starting at 0xffffc900031c9000 allocated at __dev_ethtool+0x3cc9/0x5830  The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000  index:0xffff88813a013de0 pfn:0x13a013  flags: 0x200000000000000(node=0|zone=2)  raw: 0200000000000000 0000000000000000 dead000000000122 0000000000000000  raw: ffff88813a013de0 0000000000000000 00000001ffffffff 0000000000000000  page dumped because: kasan: bad access detected   Memory state around the buggy address:   ffffc900031c8f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8   ffffc900031c9000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  >ffffc900031c9080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8                     ^   ffffc900031c9100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8   ffffc900031c9180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8

CVE-2026-31516:

        In the Linux kernel, the following vulnerability has been resolved:  xfrm: prevent policy_hthresh.work from racing with netns teardown  A XFRM_MSG_NEWSPDINFO request can queue the per-net work item policy_hthresh.work onto the system workqueue.  The queued callback, xfrm_hash_rebuild(), retrieves the enclosing struct net via container_of(). If the net namespace is torn down before that work runs, the associated struct net may already have been freed, and xfrm_hash_rebuild() may then dereference stale memory.  xfrm_policy_fini() already flushes policy_hash_work during teardown, but it does not synchronize policy_hthresh.work.  Synchronize policy_hthresh.work in xfrm_policy_fini() as well, so the queued work cannot outlive the net namespace teardown and access a freed struct net.

CVE-2026-31527:

        In the Linux kernel, the following vulnerability has been resolved:  driver core: platform: use generic driver_override infrastructure  When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF.  Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally.  Note that calling match() from __driver_attach() without the device lock held is intentional. [1]

CVE-2026-31531:

        In the Linux kernel, the following vulnerability has been resolved:  ipv4: nexthop: allocate skb dynamically in rtm_get_nexthop()  When querying a nexthop object via RTM_GETNEXTHOP, the kernel currently allocates a fixed-size skb using NLMSG_GOODSIZE. While sufficient for single nexthops and small Equal-Cost Multi-Path groups, this fixed allocation fails for large nexthop groups like 512 nexthops.  This results in the following warning splat:   WARNING: net/ipv4/nexthop.c:3395 at rtm_get_nexthop+0x176/0x1c0, CPU#20: rep/4608  [...]  RIP: 0010:rtm_get_nexthop (net/ipv4/nexthop.c:3395)  [...]  Call Trace:   <TASK>   rtnetlink_rcv_msg (net/core/rtnetlink.c:6989)   netlink_rcv_skb (net/netlink/af_netlink.c:2550)   netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344)   netlink_sendmsg (net/netlink/af_netlink.c:1894)   ____sys_sendmsg (net/socket.c:721 net/socket.c:736 net/socket.c:2585)   ___sys_sendmsg (net/socket.c:2641)   __sys_sendmsg (net/socket.c:2671)   do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)   entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)   </TASK>  Fix this by allocating the size dynamically using nh_nlmsg_size() and using nlmsg_new(), this is consistent with nexthop_notify() behavior. In addition, adjust nh_nlmsg_size_grp() so it calculates the size needed based on flags passed. While at it, also add the size of NHA_FDB for nexthop group size calculation as it was missing too.  This cannot be reproduced via iproute2 as the group size is currently limited and the command fails as follows:  addattr_l ERROR: message exceeded bound of 1048

CVE-2026-31536:

        In the Linux kernel, the following vulnerability has been resolved:  smb: server: let send_done handle a completion without IB_SEND_SIGNALED  With smbdirect_send_batch processing we likely have requests without IB_SEND_SIGNALED, which will be destroyed in the final request that has IB_SEND_SIGNALED set.  If the connection is broken all requests are signaled even without explicit IB_SEND_SIGNALED.

CVE-2026-31537:

        In the Linux kernel, the following vulnerability has been resolved:  smb: server: make use of smbdirect_socket.send_io.bcredits  It turns out that our code will corrupt the stream of reassabled data transfer messages when we trigger an immendiate (empty) send.  In order to fix this we'll have a single 'batch' credit per connection. And code getting that credit is free to use as much messages until remaining_length reaches 0, then the batch credit it given back and the next logical send can happen.

CVE-2026-31557:

        In the Linux kernel, the following vulnerability has been resolved:  nvmet: move async event work off nvmet-wq  For target nvmet_ctrl_free() flushes ctrl->async_event_work. If nvmet_ctrl_free() runs on nvmet-wq, the flush re-enters workqueue completion for the same worker:-  A. Async event work queued on nvmet-wq (prior to disconnect):   nvmet_execute_async_event()      queue_work(nvmet_wq, &ctrl->async_event_work)    nvmet_add_async_event()      queue_work(nvmet_wq, &ctrl->async_event_work)  B. Full pre-work chain (RDMA CM path):   nvmet_rdma_cm_handler()      nvmet_rdma_queue_disconnect()        __nvmet_rdma_queue_disconnect()          queue_work(nvmet_wq, &queue->release_work)            process_one_work()              lock((wq_completion)nvmet-wq)  <--------- 1st              nvmet_rdma_release_queue_work()  C. Recursive path (same worker):   nvmet_rdma_release_queue_work()      nvmet_rdma_free_queue()        nvmet_sq_destroy()          nvmet_ctrl_put()            nvmet_ctrl_free()              flush_work(&ctrl->async_event_work)                __flush_work()                  touch_wq_lockdep_map()                  lock((wq_completion)nvmet-wq) <--------- 2nd  Lockdep splat:    ============================================   WARNING: possible recursive locking detected   6.19.0-rc3nvme+ #14 Tainted: G                 N   --------------------------------------------   kworker/u192:42/44933 is trying to acquire lock:   ffff888118a00948 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x26/0x90    but task is already holding lock:   ffff888118a00948 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x53e/0x660    3 locks held by kworker/u192:42/44933:    #0: ffff888118a00948 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0x53e/0x660    #1: ffffc9000e6cbe28 ((work_completion)(&queue->release_work)){+.+.}-{0:0}, at: process_one_work+0x1c5/0x660    #2: ffffffff82d4db60 (rcu_read_lock){....}-{1:3}, at: __flush_work+0x62/0x530    Workqueue: nvmet-wq nvmet_rdma_release_queue_work [nvmet_rdma]   Call Trace:    __flush_work+0x268/0x530    nvmet_ctrl_free+0x140/0x310 [nvmet]    nvmet_cq_put+0x74/0x90 [nvmet]    nvmet_rdma_free_queue+0x23/0xe0 [nvmet_rdma]    nvmet_rdma_release_queue_work+0x19/0x50 [nvmet_rdma]    process_one_work+0x206/0x660    worker_thread+0x184/0x320    kthread+0x10c/0x240    ret_from_fork+0x319/0x390  Move async event work to a dedicated nvmet-aen-wq to avoid reentrant flush on nvmet-wq.

CVE-2026-31560:

        In the Linux kernel, the following vulnerability has been resolved:  spi: spi-dw-dma: fix print error log when wait finish transaction  If an error occurs, the device may not have a current message. In this case, the system will crash.  In this case, it's better to use dev from the struct ctlr (struct spi_controller*).

CVE-2026-31568:

        In the Linux kernel, the following vulnerability has been resolved:  s390/mm: Add missing secure storage access fixups for donated memory  There are special cases where secure storage access exceptions happen in a kernel context for pages that don't have the PG_arch_1 bit set. That bit is set for non-exported guest secure storage (memory) but is absent on storage donated to the Ultravisor since the kernel isn't allowed to export donated pages.  Prior to this patch we would try to export the page by calling arch_make_folio_accessible() which would instantly return since the arch bit is absent signifying that the page was already exported and no further action is necessary. This leads to secure storage access exception loops which can never be resolved.  With this patch we unconditionally try to export and if that fails we fixup.

CVE-2026-31579:

        In the Linux kernel, the following vulnerability has been resolved:  wireguard: device: use exit_rtnl callback instead of manual rtnl_lock in pre_exit  wg_netns_pre_exit() manually acquires rtnl_lock() inside the pernet .pre_exit callback.  This causes a hung task when another thread holds rtnl_mutex - the cleanup_net workqueue (or the setup_net failure rollback path) blocks indefinitely in wg_netns_pre_exit() waiting to acquire the lock.  Convert to .exit_rtnl, introduced in commit 7a60d91c690b ("net: Add ->exit_rtnl() hook to struct pernet_operations."), where the framework already holds RTNL and batches all callbacks under a single rtnl_lock()/rtnl_unlock() pair, eliminating the contention window.  The rcu_assign_pointer(wg->creating_net, NULL) is safe to move from .pre_exit to .exit_rtnl (which runs after synchronize_rcu()) because all RCU readers of creating_net either use maybe_get_net() - which returns NULL for a dying namespace with zero refcount - or access net->user_ns which remains valid throughout the entire ops_undo_list sequence.  [ Jason: added __net_exit and __read_mostly annotations that were missing. ]

CVE-2026-31592:

        In the Linux kernel, the following vulnerability has been resolved:  KVM: SEV: Protect *all* of sev_mem_enc_register_region() with kvm->lock  Take and hold kvm->lock for before checking sev_guest() in sev_mem_enc_register_region(), as sev_guest() isn't stable unless kvm->lock is held (or KVM can guarantee KVM_SEV_INIT{2} has completed and can't rollack state).  If KVM_SEV_INIT{2} fails, KVM can end up trying to add to a not-yet-initialized sev->regions_list, e.g. triggering a #GP    Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI   KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]   CPU: 110 UID: 0 PID: 72717 Comm: syz.15.11462 Tainted: G     U  W  O        6.16.0-smp-DEV #1 NONE   Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE   Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.52.0-0 10/28/2024   RIP: 0010:sev_mem_enc_register_region+0x3f0/0x4f0 ../include/linux/list.h:83   Code: <41> 80 3c 04 00 74 08 4c 89 ff e8 f1 c7 a2 00 49 39 ed 0f 84 c6 00   RSP: 0018:ffff88838647fbb8 EFLAGS: 00010256   RAX: dffffc0000000000 RBX: 1ffff92015cf1e0b RCX: dffffc0000000000   RDX: 0000000000000000 RSI: 0000000000001000 RDI: ffff888367870000   RBP: ffffc900ae78f050 R08: ffffea000d9e0007 R09: 1ffffd4001b3c000   R10: dffffc0000000000 R11: fffff94001b3c001 R12: 0000000000000000   R13: ffff8982ab0bde00 R14: ffffc900ae78f058 R15: 0000000000000000   FS:  00007f34e9dc66c0(0000) GS:ffff89ee64d33000(0000) knlGS:0000000000000000   CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033   CR2: 00007fe180adef98 CR3: 000000047210e000 CR4: 0000000000350ef0   Call Trace:    <TASK>    kvm_arch_vm_ioctl+0xa72/0x1240 ../arch/x86/kvm/x86.c:7371    kvm_vm_ioctl+0x649/0x990 ../virt/kvm/kvm_main.c:5363    __se_sys_ioctl+0x101/0x170 ../fs/ioctl.c:51    do_syscall_x64 ../arch/x86/entry/syscall_64.c:63 [inline]    do_syscall_64+0x6f/0x1f0 ../arch/x86/entry/syscall_64.c:94    entry_SYSCALL_64_after_hwframe+0x76/0x7e   RIP: 0033:0x7f34e9f7e9a9   Code: <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48   RSP: 002b:00007f34e9dc6038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010   RAX: ffffffffffffffda RBX: 00007f34ea1a6080 RCX: 00007f34e9f7e9a9   RDX: 0000200000000280 RSI: 000000008010aebb RDI: 0000000000000007   RBP: 00007f34ea000d69 R08: 0000000000000000 R09: 0000000000000000   R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000   R13: 0000000000000000 R14: 00007f34ea1a6080 R15: 00007ffce77197a8    </TASK>  with a syzlang reproducer that looks like:    syz_kvm_add_vcpu$x86(0x0, &(0x7f0000000040)={0x0, &(0x7f0000000180)=ANY=[], 0x70}) (async)   syz_kvm_add_vcpu$x86(0x0, &(0x7f0000000080)={0x0, &(0x7f0000000180)=ANY=[@ANYBLOB="..."], 0x4f}) (async)   r0 = openat$kvm(0xffffffffffffff9c, &(0x7f0000000200), 0x0, 0x0)   r1 = ioctl$KVM_CREATE_VM(r0, 0xae01, 0x0)   r2 = openat$kvm(0xffffffffffffff9c, &(0x7f0000000240), 0x0, 0x0)   r3 = ioctl$KVM_CREATE_VM(r2, 0xae01, 0x0)   ioctl$KVM_SET_CLOCK(r3, 0xc008aeba, &(0x7f0000000040)={0x1, 0x8, 0x0, 0x5625e9b0}) (async)   ioctl$KVM_SET_PIT2(r3, 0x8010aebb, &(0x7f0000000280)={[...], 0x5}) (async)   ioctl$KVM_SET_PIT2(r1, 0x4070aea0, 0x0) (async)   r4 = ioctl$KVM_CREATE_VM(0xffffffffffffffff, 0xae01, 0x0)   openat$kvm(0xffffffffffffff9c, 0x0, 0x0, 0x0) (async)   ioctl$KVM_SET_USER_MEMORY_REGION(r4, 0x4020ae46, &(0x7f0000000400)={0x0, 0x0, 0x0, 0x2000, &(0x7f0000001000/0x2000)=nil}) (async)   r5 = ioctl$KVM_CREATE_VCPU(r4, 0xae41, 0x2)   close(r0) (async)   openat$kvm(0xffffffffffffff9c, &(0x7f0000000000), 0x8000, 0x0) (async)   ioctl$KVM_SET_GUEST_DEBUG(r5, 0x4048ae9b, &(0x7f0000000300)={0x4376ea830d46549b, 0x0, [0x46, 0x0, 0x0, 0x0, 0x0, 0x1000]}) (async)   ioctl$KVM_RUN(r5, 0xae80, 0x0)  Opportunistically use guard() to avoid having to define a new error label and goto usage.

CVE-2026-31606:

        In the Linux kernel, the following vulnerability has been resolved:  usb: gadget: f_hid: don't call cdev_init while cdev in use  When calling unbind, then bind again, cdev_init reinitialized the cdev, even though there may still be references to it. That's the case when the /dev/hidg* device is still opened. This obviously unsafe behavior like oopes.  This fixes this by using cdev_alloc to put the cdev on the heap. That way, we can simply allocate a new one in hidg_bind.

CVE-2026-31648:

        In the Linux kernel, the following vulnerability has been resolved:  mm: filemap: fix nr_pages calculation overflow in filemap_map_pages()  When running stress-ng on my Arm64 machine with v7.0-rc3 kernel, I encountered some very strange crash issues showing up as "Bad page state":  " [  734.496287] BUG: Bad page state in process stress-ng-env  pfn:415735fb [  734.496427] page: refcount:0 mapcount:1 mapping:0000000000000000 index:0x4cf316 pfn:0x415735fb [  734.496434] flags: 0x57fffe000000800(owner_2|node=1|zone=2|lastcpupid=0x3ffff) [  734.496439] raw: 057fffe000000800 0000000000000000 dead000000000122 0000000000000000 [  734.496440] raw: 00000000004cf316 0000000000000000 0000000000000000 0000000000000000 [  734.496442] page dumped because: nonzero mapcount "  After analyzing this page’s state, it is hard to understand why the mapcount is not 0 while the refcount is 0, since this page is not where the issue first occurred.  By enabling the CONFIG_DEBUG_VM config, I can reproduce the crash as well and captured the first warning where the issue appears:  " [  734.469226] page: refcount:33 mapcount:0 mapping:00000000bef2d187 index:0x81a0 pfn:0x415735c0 [  734.469304] head: order:5 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [  734.469315] memcg:ffff000807a8ec00 [  734.469320] aops:ext4_da_aops ino:100b6f dentry name(?):"stress-ng-mmaptorture-9397-0-2736200540" [  734.469335] flags: 0x57fffe400000069(locked|uptodate|lru|head|node=1|zone=2|lastcpupid=0x3ffff) ...... [  734.469364] page dumped because: VM_WARN_ON_FOLIO((_Generic((page + nr_pages - 1), const struct page *: (const struct folio *)_compound_head(page + nr_pages - 1), struct page *: (struct folio *)_compound_head(page + nr_pages - 1))) != folio) [  734.469390] ------------[ cut here ]------------ [  734.469393] WARNING: ./include/linux/rmap.h:351 at folio_add_file_rmap_ptes+0x3b8/0x468, CPU#90: stress-ng-mlock/9430 [  734.469551]  folio_add_file_rmap_ptes+0x3b8/0x468 (P) [  734.469555]  set_pte_range+0xd8/0x2f8 [  734.469566]  filemap_map_folio_range+0x190/0x400 [  734.469579]  filemap_map_pages+0x348/0x638 [  734.469583]  do_fault_around+0x140/0x198 ...... [  734.469640]  el0t_64_sync+0x184/0x188 "  The code that triggers the warning is: "VM_WARN_ON_FOLIO(page_folio(page + nr_pages - 1) != folio, folio)", which indicates that set_pte_range() tried to map beyond the large folio’s size.  By adding more debug information, I found that 'nr_pages' had overflowed in filemap_map_pages(), causing set_pte_range() to establish mappings for a range exceeding the folio size, potentially corrupting fields of pages that do not belong to this folio (e.g., page->_mapcount).  After above analysis, I think the possible race is as follows:  CPU 0                                                  CPU 1 filemap_map_pages()                                   ext4_setattr()    //get and lock folio with old inode->i_size    next_uptodate_folio()                                                            .......                                                           //shrink the inode->i_size                                                           i_size_write(inode, attr->ia_size);     //calculate the end_pgoff with the new inode->i_size    file_end = DIV_ROUND_UP(i_size_read(mapping->host), PAGE_SIZE) - 1;    end_pgoff = min(end_pgoff, file_end);     ......    //nr_pages can be overflowed, cause xas.xa_index > end_pgoff    end = folio_next_index(folio) - 1;    nr_pages = min(end, end_pgoff) - xas.xa_index + 1;     ......    //map large folio    filemap_map_folio_range()                                                           ......                                                           //truncate folios                                                           truncate_pagecache(inode, inode->i_size);  To fix this issue, move the 'end_pgoff' calculation before next_uptodate_folio(), so the retrieved folio stays consistent with the file end to avoid  ---truncated---

CVE-2026-31655:

        In the Linux kernel, the following vulnerability has been resolved:  pmdomain: imx8mp-blk-ctrl: Keep the NOC_HDCP clock enabled  Keep the NOC_HDCP clock always enabled to fix the potential hang caused by the NoC ADB400 port power down handshake.

CVE-2026-31663:

        In the Linux kernel, the following vulnerability has been resolved:  xfrm: hold dev ref until after transport_finish NF_HOOK  After async crypto completes, xfrm_input_resume() calls dev_put() immediately on re-entry before the skb reaches transport_finish. The skb->dev pointer is then used inside NF_HOOK and its okfn, which can race with device teardown.  Remove the dev_put from the async resumption entry and instead drop the reference after the NF_HOOK call in transport_finish, using a saved device pointer since NF_HOOK may consume the skb. This covers NF_DROP, NF_QUEUE and NF_STOLEN paths that skip the okfn.  For non-transport exits (decaps, gro, drop) and secondary async return points, release the reference inline when async is set.

CVE-2026-31675:

        In the Linux kernel, the following vulnerability has been resolved:  net/sched: sch_netem: fix out-of-bounds access in packet corruption  In netem_enqueue(), the packet corruption logic uses get_random_u32_below(skb_headlen(skb)) to select an index for modifying skb->data. When an AF_PACKET TX_RING sends fully non-linear packets over an IPIP tunnel, skb_headlen(skb) evaluates to 0.  Passing 0 to get_random_u32_below() takes the variable-ceil slow path which returns an unconstrained 32-bit random integer. Using this unconstrained value as an offset into skb->data results in an out-of-bounds memory access.  Fix this by verifying skb_headlen(skb) is non-zero before attempting to corrupt the linear data area. Fully non-linear packets will silently bypass the corruption logic.

CVE-2026-31677:

        In the Linux kernel, the following vulnerability has been resolved:  crypto: af_alg - limit RX SG extraction by receive buffer budget  Make af_alg_get_rsgl() limit each RX scatterlist extraction to the remaining receive buffer budget.  af_alg_get_rsgl() currently uses af_alg_readable() only as a gate before extracting data into the RX scatterlist. Limit each extraction to the remaining af_alg_rcvbuf(sk) budget so that receive-side accounting matches the amount of data attached to the request.  If skcipher cannot obtain enough RX space for at least one chunk while more data remains to be processed, reject the recvmsg call instead of rounding the request length down to zero.

CVE-2026-31692:

        In the Linux kernel, the following vulnerability has been resolved:  rtnetlink: add missing netlink_ns_capable() check for peer netns  rtnl_newlink() lacks a CAP_NET_ADMIN capability check on the peer network namespace when creating paired devices (veth, vxcan, netkit). This allows an unprivileged user with a user namespace to create interfaces in arbitrary network namespaces, including init_net.  Add a netlink_ns_capable() check for CAP_NET_ADMIN in the peer namespace before allowing device creation to proceed.

CVE-2026-31706:

        In the Linux kernel, the following vulnerability has been resolved:  ksmbd: validate num_aces and harden ACE walk in smb_inherit_dacl()  smb_inherit_dacl() trusts the on-disk num_aces value from the parent directory's DACL xattr and uses it to size a heap allocation:    aces_base = kmalloc(sizeof(struct smb_ace) * num_aces * 2, ...);  num_aces is a u16 read from le16_to_cpu(parent_pdacl->num_aces) without checking that it is consistent with the declared pdacl_size. An authenticated client whose parent directory's security.NTACL is tampered (e.g. via offline xattr corruption or a concurrent path that bypasses parse_dacl()) can present num_aces = 65535 with minimal actual ACE data.  This causes a ~8 MB allocation (not kzalloc, so uninitialized) that the subsequent loop only partially populates, and may also overflow the three-way size_t multiply on 32-bit kernels.  Additionally, the ACE walk loop uses the weaker offsetof(struct smb_ace, access_req) minimum size check rather than the minimum valid on-wire ACE size, and does not reject ACEs whose declared size is below the minimum.  Reproduced on UML + KASAN + LOCKDEP against the real ksmbd code path. A legitimate mount.cifs client creates a parent directory over SMB (ksmbd writes a valid security.NTACL xattr), then the NTACL blob on the backing filesystem is rewritten to set num_aces = 0xFFFF while keeping the posix_acl_hash bytes intact so ksmbd_vfs_get_sd_xattr()'s hash check still passes.  A subsequent SMB2 CREATE of a child under that parent drives smb2_open() into smb_inherit_dacl() (share has "vfs objects = acl_xattr" set), which fails the page allocator:    WARNING: mm/page_alloc.c:5226 at __alloc_frozen_pages_noprof+0x46c/0x9c0   Workqueue: ksmbd-io handle_ksmbd_work    __alloc_frozen_pages_noprof+0x46c/0x9c0    ___kmalloc_large_node+0x68/0x130    __kmalloc_large_node_noprof+0x24/0x70    __kmalloc_noprof+0x4c9/0x690    smb_inherit_dacl+0x394/0x2430    smb2_open+0x595d/0xabe0    handle_ksmbd_work+0x3d3/0x1140  With the patch applied the added guard rejects the tampered value with -EINVAL before any large allocation runs, smb2_open() falls back to smb2_create_sd_buffer(), and the child is created with a default SD.  No warning, no splat.  Fix by:    1. Validating num_aces against pdacl_size using the same formula      applied in parse_dacl().    2. Replacing the raw kmalloc(sizeof * num_aces * 2) with      kmalloc_array(num_aces * 2, sizeof(...)) for overflow-safe      allocation.    3. Tightening the per-ACE loop guard to require the minimum valid      ACE size (offsetof(smb_ace, sid) + CIFS_SID_BASE_SIZE) and      rejecting under-sized ACEs, matching the hardening in      smb_check_perm_dacl() and parse_dacl().  v1 -> v2:   - Replace the synthetic test-module splat in the changelog with a     real-path UML + KASAN reproduction driven through mount.cifs and     SMB2 CREATE; Namjae flagged the kcifs3_test_inherit_dacl_old name     in v1 since it does not exist in ksmbd.   - Drop the commit-hash citation from the code comment per Namjae's     review; keep the parse_dacl() pointer.

CVE-2026-31707:

        In the Linux kernel, the following vulnerability has been resolved:  ksmbd: validate response sizes in ipc_validate_msg()  ipc_validate_msg() computes the expected message size for each response type by adding (or multiplying) attacker-controlled fields from the daemon response to a fixed struct size in unsigned int arithmetic.  Three cases can overflow:    KSMBD_EVENT_RPC_REQUEST:       msg_sz = sizeof(struct ksmbd_rpc_command) + resp->payload_sz;   KSMBD_EVENT_SHARE_CONFIG_REQUEST:       msg_sz = sizeof(struct ksmbd_share_config_response) +                resp->payload_sz;   KSMBD_EVENT_LOGIN_REQUEST_EXT:       msg_sz = sizeof(struct ksmbd_login_response_ext) +                resp->ngroups * sizeof(gid_t);  resp->payload_sz is __u32 and resp->ngroups is __s32.  Each addition can wrap in unsigned int; the multiplication by sizeof(gid_t) mixes signed and size_t, so a negative ngroups is converted to SIZE_MAX before the multiply.  A wrapped value of msg_sz that happens to equal entry->msg_sz bypasses the size check on the next line, and downstream consumers (smb2pdu.c:6742 memcpy using rpc_resp->payload_sz, kmemdup in ksmbd_alloc_user using resp_ext->ngroups) then trust the unverified length.  Use check_add_overflow() on the RPC_REQUEST and SHARE_CONFIG_REQUEST paths to detect integer overflow without constraining functional payload size; userspace ksmbd-tools grows NDR responses in 4096-byte chunks for calls like NetShareEnumAll, so a hard transport cap is unworkable on the response side.  For LOGIN_REQUEST_EXT, reject resp->ngroups outside the signed [0, NGROUPS_MAX] range up front and report the error from ipc_validate_msg() so it fires at the IPC boundary; with that bound the subsequent multiplication and addition stay well below UINT_MAX.  The now-redundant ngroups check and pr_err in ksmbd_alloc_user() are removed.  This is the response-side analogue of aab98e2dbd64 ("ksmbd: fix integer overflows on 32 bit systems"), which hardened the request side.

CVE-2026-31722:

        In the Linux kernel, the following vulnerability has been resolved:  usb: gadget: f_rndis: Fix net_device lifecycle with device_move  The net_device is allocated during function instance creation and registered during the bind phase with the gadget device as its sysfs parent. When the function unbinds, the parent device is destroyed, but the net_device survives, resulting in dangling sysfs symlinks:    console:/ # ls -l /sys/class/net/usb0   lrwxrwxrwx ... /sys/class/net/usb0 ->   /sys/devices/platform/.../gadget.0/net/usb0   console:/ # ls -l /sys/devices/platform/.../gadget.0/net/usb0   ls: .../gadget.0/net/usb0: No such file or directory  Use device_move() to reparent the net_device between the gadget device tree and /sys/devices/virtual across bind and unbind cycles. During the final unbind, calling device_move(NULL) moves the net_device to the virtual device tree before the gadget device is destroyed. On rebinding, device_move() reparents the device back under the new gadget, ensuring proper sysfs topology and power management ordering.  To maintain compatibility with legacy composite drivers (e.g., multi.c), the borrowed_net flag is used to indicate whether the network device is shared and pre-registered during the legacy driver's bind phase.

CVE-2026-31723:

        In the Linux kernel, the following vulnerability has been resolved:  usb: gadget: f_subset: Fix net_device lifecycle with device_move  The net_device is allocated during function instance creation and registered during the bind phase with the gadget device as its sysfs parent. When the function unbinds, the parent device is destroyed, but the net_device survives, resulting in dangling sysfs symlinks:    console:/ # ls -l /sys/class/net/usb0   lrwxrwxrwx ... /sys/class/net/usb0 ->   /sys/devices/platform/.../gadget.0/net/usb0   console:/ # ls -l /sys/devices/platform/.../gadget.0/net/usb0   ls: .../gadget.0/net/usb0: No such file or directory  Use device_move() to reparent the net_device between the gadget device tree and /sys/devices/virtual across bind and unbind cycles. During the final unbind, calling device_move(NULL) moves the net_device to the virtual device tree before the gadget device is destroyed. On rebinding, device_move() reparents the device back under the new gadget, ensuring proper sysfs topology and power management ordering.  To maintain compatibility with legacy composite drivers (e.g., multi.c), the bound flag is used to indicate whether the network device is shared and pre-registered during the legacy driver's bind phase.

CVE-2026-31724:

        In the Linux kernel, the following vulnerability has been resolved:  usb: gadget: f_eem: Fix net_device lifecycle with device_move  The net_device is allocated during function instance creation and registered during the bind phase with the gadget device as its sysfs parent. When the function unbinds, the parent device is destroyed, but the net_device survives, resulting in dangling sysfs symlinks:  console:/ # ls -l /sys/class/net/usb0 lrwxrwxrwx ... /sys/class/net/usb0 -> /sys/devices/platform/.../gadget.0/net/usb0 console:/ # ls -l /sys/devices/platform/.../gadget.0/net/usb0 ls: .../gadget.0/net/usb0: No such file or directory  Use device_move() to reparent the net_device between the gadget device tree and /sys/devices/virtual across bind and unbind cycles. During the final unbind, calling device_move(NULL) moves the net_device to the virtual device tree before the gadget device is destroyed. On rebinding, device_move() reparents the device back under the new gadget, ensuring proper sysfs topology and power management ordering.  To maintain compatibility with legacy composite drivers (e.g., multi.c), the bound flag is used to indicate whether the network device is shared and pre-registered during the legacy driver's bind phase.

CVE-2026-31725:

        In the Linux kernel, the following vulnerability has been resolved:  usb: gadget: f_ecm: Fix net_device lifecycle with device_move  The net_device is allocated during function instance creation and registered during the bind phase with the gadget device as its sysfs parent. When the function unbinds, the parent device is destroyed, but the net_device survives, resulting in dangling sysfs symlinks:    console:/ # ls -l /sys/class/net/usb0   lrwxrwxrwx ... /sys/class/net/usb0 ->   /sys/devices/platform/.../gadget.0/net/usb0   console:/ # ls -l /sys/devices/platform/.../gadget.0/net/usb0   ls: .../gadget.0/net/usb0: No such file or directory  Use device_move() to reparent the net_device between the gadget device tree and /sys/devices/virtual across bind and unbind cycles. During the final unbind, calling device_move(NULL) moves the net_device to the virtual device tree before the gadget device is destroyed. On rebinding, device_move() reparents the device back under the new gadget, ensuring proper sysfs topology and power management ordering.  To maintain compatibility with legacy composite drivers (e.g., multi.c), the bound flag is used to indicate whether the network device is shared and pre-registered during the legacy driver's bind phase.

CVE-2026-31729:

        In the Linux kernel, the following vulnerability has been resolved:  usb: typec: ucsi: validate connector number in ucsi_notify_common()  The connector number extracted from CCI via UCSI_CCI_CONNECTOR() is a 7-bit field (0-127) that is used to index into the connector array in ucsi_connector_change(). However, the array is only allocated for the number of connectors reported by the device (typically 2-4 entries).  A malicious or malfunctioning device could report an out-of-range connector number in the CCI, causing an out-of-bounds array access in ucsi_connector_change().  Add a bounds check in ucsi_notify_common(), the central point where CCI is parsed after arriving from hardware, so that bogus connector numbers are rejected before they propagate further.

CVE-2026-31767:

        In the Linux kernel, the following vulnerability has been resolved:  drm/i915/dsi: Don't do DSC horizontal timing adjustments in command mode  Stop adjusting the horizontal timing values based on the compression ratio in command mode. Bspec seems to be telling us to do this only in video mode, and this is also how the Windows driver does things.  This should also fix a div-by-zero on some machines because the adjusted htotal ends up being so small that we end up with line_time_us==0 when trying to determine the vtotal value in command mode.  Note that this doesn't actually make the display on the Huawei Matebook E work, but at least the kernel no longer explodes when the driver loads.  (cherry picked from commit 0b475e91ecc2313207196c6d7fd5c53e1a878525)

CVE-2026-31771:

        In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: hci_event: move wake reason storage into validated event handlers  hci_store_wake_reason() is called from hci_event_packet() immediately after stripping the HCI event header but before hci_event_func() enforces the per-event minimum payload length from hci_ev_table. This means a short HCI event frame can reach bacpy() before any bounds check runs.  Rather than duplicating skb parsing and per-event length checks inside hci_store_wake_reason(), move wake-address storage into the individual event handlers after their existing event-length validation has succeeded. Convert hci_store_wake_reason() into a small helper that only stores an already-validated bdaddr while the caller holds hci_dev_lock(). Use the same helper after hci_event_func() with a NULL address to preserve the existing unexpected-wake fallback semantics when no validated event handler records a wake address.  Annotate the helper with __must_hold(&hdev->lock) and add lockdep_assert_held(&hdev->lock) so future call paths keep the lock contract explicit.  Call the helper from hci_conn_request_evt(), hci_conn_complete_evt(), hci_sync_conn_complete_evt(), le_conn_complete_evt(), hci_le_adv_report_evt(), hci_le_ext_adv_report_evt(), hci_le_direct_adv_report_evt(), hci_le_pa_sync_established_evt(), and hci_le_past_received_evt().

CVE-2026-31777:

        In the Linux kernel, the following vulnerability has been resolved:  ALSA: ctxfi: Check the error for index mapping  The ctxfi driver blindly assumed a proper value returned from daio_device_index(), but it's not always true.  Add a proper error check to deal with the error from the function.

CVE-2026-43009:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: Fix incorrect pruning due to atomic fetch precision tracking  When backtrack_insn encounters a BPF_STX instruction with BPF_ATOMIC and BPF_FETCH, the src register (or r0 for BPF_CMPXCHG) also acts as a destination, thus receiving the old value from the memory location.  The current backtracking logic does not account for this. It treats atomic fetch operations the same as regular stores where the src register is only an input. This leads the backtrack_insn to fail to propagate precision to the stack location, which is then not marked as precise!  Later, the verifier's path pruning can incorrectly consider two states equivalent when they differ in terms of stack state. Meaning, two branches can be treated as equivalent and thus get pruned when they should not be seen as such.  Fix it as follows: Extend the BPF_LDX handling in backtrack_insn to also cover atomic fetch operations via is_atomic_fetch_insn() helper. When the fetch dst register is being tracked for precision, clear it, and propagate precision over to the stack slot. For non-stack memory, the precision walk stops at the atomic instruction, same as regular BPF_LDX. This covers all fetch variants.  Before:    0: (b7) r1 = 8                        ; R1=8   1: (7b) *(u64 *)(r10 -8) = r1         ; R1=8 R10=fp0 fp-8=8   2: (b7) r2 = 0                        ; R2=0   3: (db) r2 = atomic64_fetch_add((u64 *)(r10 -8), r2)          ; R2=8 R10=fp0 fp-8=mmmmmmmm   4: (bf) r3 = r10                      ; R3=fp0 R10=fp0   5: (0f) r3 += r2   mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1   mark_precise: frame0: regs=r2 stack= before 4: (bf) r3 = r10   mark_precise: frame0: regs=r2 stack= before 3: (db) r2 = atomic64_fetch_add((u64 *)(r10 -8), r2)   mark_precise: frame0: regs=r2 stack= before 2: (b7) r2 = 0   6: R2=8 R3=fp8   6: (b7) r0 = 0                        ; R0=0   7: (95) exit  After:    0: (b7) r1 = 8                        ; R1=8   1: (7b) *(u64 *)(r10 -8) = r1         ; R1=8 R10=fp0 fp-8=8   2: (b7) r2 = 0                        ; R2=0   3: (db) r2 = atomic64_fetch_add((u64 *)(r10 -8), r2)          ; R2=8 R10=fp0 fp-8=mmmmmmmm   4: (bf) r3 = r10                      ; R3=fp0 R10=fp0   5: (0f) r3 += r2   mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1   mark_precise: frame0: regs=r2 stack= before 4: (bf) r3 = r10   mark_precise: frame0: regs=r2 stack= before 3: (db) r2 = atomic64_fetch_add((u64 *)(r10 -8), r2)   mark_precise: frame0: regs= stack=-8 before 2: (b7) r2 = 0   mark_precise: frame0: regs= stack=-8 before 1: (7b) *(u64 *)(r10 -8) = r1   mark_precise: frame0: regs=r1 stack= before 0: (b7) r1 = 8   6: R2=8 R3=fp8   6: (b7) r0 = 0                        ; R0=0   7: (95) exit

CVE-2026-43010:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: Reject sleepable kprobe_multi programs at attach time  kprobe.multi programs run in atomic/RCU context and cannot sleep. However, bpf_kprobe_multi_link_attach() did not validate whether the program being attached had the sleepable flag set, allowing sleepable helpers such as bpf_copy_from_user() to be invoked from a non-sleepable context.  This causes a "sleeping function called from invalid context" splat:    BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:169   in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1787, name: sudo   preempt_count: 1, expected: 0   RCU nest depth: 2, expected: 0  Fix this by rejecting sleepable programs early in bpf_kprobe_multi_link_attach(), before any further processing.

CVE-2026-43016:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: sockmap: Fix use-after-free of sk->sk_socket in sk_psock_verdict_data_ready().  syzbot reported use-after-free of AF_UNIX socket's sk->sk_socket in sk_psock_verdict_data_ready(). [0]  In unix_stream_sendmsg(), the peer socket's ->sk_data_ready() is called after dropping its unix_state_lock().  Although the sender socket holds the peer's refcount, it does not prevent the peer's sock_orphan(), and the peer's sk_socket might be freed after one RCU grace period.  Let's fetch the peer's sk->sk_socket and sk->sk_socket->ops under RCU in sk_psock_verdict_data_ready().  [0]: BUG: KASAN: slab-use-after-free in sk_psock_verdict_data_ready+0xec/0x590 net/core/skmsg.c:1278 Read of size 8 at addr ffff8880594da860 by task syz.4.1842/11013  CPU: 1 UID: 0 PID: 11013 Comm: syz.4.1842 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2026 Call Trace:  <TASK>  dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120  print_address_description mm/kasan/report.c:378 [inline]  print_report+0xba/0x230 mm/kasan/report.c:482  kasan_report+0x117/0x150 mm/kasan/report.c:595  sk_psock_verdict_data_ready+0xec/0x590 net/core/skmsg.c:1278  unix_stream_sendmsg+0x8a3/0xe80 net/unix/af_unix.c:2482  sock_sendmsg_nosec net/socket.c:721 [inline]  __sock_sendmsg net/socket.c:736 [inline]  ____sys_sendmsg+0x972/0x9f0 net/socket.c:2585  ___sys_sendmsg+0x2a5/0x360 net/socket.c:2639  __sys_sendmsg net/socket.c:2671 [inline]  __do_sys_sendmsg net/socket.c:2676 [inline]  __se_sys_sendmsg net/socket.c:2674 [inline]  __x64_sys_sendmsg+0x1bd/0x2a0 net/socket.c:2674  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]  do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94  entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7facf899c819 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007facf9827028 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007facf8c15fa0 RCX: 00007facf899c819 RDX: 0000000000000000 RSI: 0000200000000500 RDI: 0000000000000004 RBP: 00007facf8a32c91 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007facf8c16038 R14: 00007facf8c15fa0 R15: 00007ffd41b01c78  </TASK>  Allocated by task 11013:  kasan_save_stack mm/kasan/common.c:57 [inline]  kasan_save_track+0x3e/0x80 mm/kasan/common.c:78  unpoison_slab_object mm/kasan/common.c:340 [inline]  __kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:366  kasan_slab_alloc include/linux/kasan.h:253 [inline]  slab_post_alloc_hook mm/slub.c:4538 [inline]  slab_alloc_node mm/slub.c:4866 [inline]  kmem_cache_alloc_lru_noprof+0x2b8/0x640 mm/slub.c:4885  sock_alloc_inode+0x28/0xc0 net/socket.c:316  alloc_inode+0x6a/0x1b0 fs/inode.c:347  new_inode_pseudo include/linux/fs.h:3003 [inline]  sock_alloc net/socket.c:631 [inline]  __sock_create+0x12d/0x9d0 net/socket.c:1562  sock_create net/socket.c:1656 [inline]  __sys_socketpair+0x1c4/0x560 net/socket.c:1803  __do_sys_socketpair net/socket.c:1856 [inline]  __se_sys_socketpair net/socket.c:1853 [inline]  __x64_sys_socketpair+0x9b/0xb0 net/socket.c:1853  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]  do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94  entry_SYSCALL_64_after_hwframe+0x77/0x7f  Freed by task 15:  kasan_save_stack mm/kasan/common.c:57 [inline]  kasan_save_track+0x3e/0x80 mm/kasan/common.c:78  kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:584  poison_slab_object mm/kasan/common.c:253 [inline]  __kasan_slab_free+0x5c/0x80 mm/kasan/common.c:285  kasan_slab_free include/linux/kasan.h:235 [inline]  slab_free_hook mm/slub.c:2685 [inline]  slab_free mm/slub.c:6165 [inline]  kmem_cache_free+0x187/0x630 mm/slub.c:6295  rcu_do_batch kernel/rcu/tree.c: ---truncated---

CVE-2026-43022:

        In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: hci_sync: hci_cmd_sync_queue_once() return -EEXIST if exists  hci_cmd_sync_queue_once() needs to indicate whether a queue item was added, so caller can know if callbacks are called, so it can avoid leaking resources.  Change the function to return -EEXIST if queue item already exists.  Modify all callsites to handle that.

CVE-2026-43036:

        In the Linux kernel, the following vulnerability has been resolved:  net: use skb_header_pointer() for TCPv4 GSO frag_off check  Syzbot reported a KMSAN uninit-value warning in gso_features_check() called from netif_skb_features() [1].  gso_features_check() reads iph->frag_off to decide whether to clear mangleid_features. Accessing the IPv4 header via ip_hdr()/inner_ip_hdr() can rely on skb header offsets that are not always safe for direct dereference on packets injected from PF_PACKET paths.  Use skb_header_pointer() for the TCPv4 frag_off check so the header read is robust whether data is already linear or needs copying.  [1] https://syzkaller.appspot.com/bug?extid=1543a7d954d9c6d00407

CVE-2026-43042:

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

CVE-2026-43048:

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

CVE-2026-43049:

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

CVE-2026-43053:

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

CVE-2026-43073:

        In the Linux kernel, the following vulnerability has been resolved:  x86-64: rename misleadingly named '__copy_user_nocache()' function  This function was a masterclass in bad naming, for various historical reasons.  It claimed to be a non-cached user copy.  It is literally _neither_ of those things.  It's a specialty memory copy routine that uses non-temporal stores for the destination (but not the source), and that does exception handling for both source and destination accesses.  Also note that while it works for unaligned targets, any unaligned parts (whether at beginning or end) will not use non-temporal stores, since only words and quadwords can be non-temporal on x86.  The exception handling means that it _can_ be used for user space accesses, but not on its own - it needs all the normal "start user space access" logic around it.  But typically the user space access would be the source, not the non-temporal destination.  That was the original intention of this, where the destination was some fragile persistent memory target that needed non-temporal stores in order to catch machine check exceptions synchronously and deal with them gracefully.  Thus that non-descriptive name: one use case was to copy from user space into a non-cached kernel buffer.  However, the existing users are a mix of that intended use-case, and a couple of random drivers that just did this as a performance tweak.  Some of those random drivers then actively misused the user copying version (with STAC/CLAC and all) to do kernel copies without ever even caring about the exception handling, _just_ for the non-temporal destination.  Rename it as a first small step to actually make it halfway sane, and change the prototype to be more normal: it doesn't take a user pointer unless the caller has done the proper conversion, and the argument size is the full size_t (it still won't actually copy more than 4GB in one go, but there's also no reason to silently truncate the size argument in the caller).  Finally, use this now sanely named function in the NTB code, which mis-used a user copy version (with STAC/CLAC and all) of this interface despite it not actually being a user copy at all.

CVE-2026-43083:

        In the Linux kernel, the following vulnerability has been resolved:  net: ioam6: fix OOB and missing lock  When trace->type.bit6 is set:      if (trace->type.bit6) {         ...         queue = skb_get_tx_queue(dev, skb);         qdisc = rcu_dereference(queue->qdisc);  This code can lead to an out-of-bounds access of the dev->_tx[] array when is_input is true. In such a case, the packet is on the RX path and skb->queue_mapping contains the RX queue index of the ingress device. If the ingress device has more RX queues than the egress device (dev) has TX queues, skb_get_queue_mapping(skb) will exceed dev->num_tx_queues. Add a check to avoid this situation since skb_get_tx_queue() does not clamp the index. This issue has also revealed that per queue visibility cannot be accurate and will be replaced later as a new feature.  While at it, add missing lock around qdisc_qstats_qlen_backlog(). The function __ioam6_fill_trace_data() is called from both softirq and process contexts, hence the use of spin_lock_bh() here.

CVE-2026-43091:

        In the Linux kernel, the following vulnerability has been resolved:  xfrm: Wait for RCU readers during policy netns exit  xfrm_policy_fini() frees the policy_bydst hash tables after flushing the policy work items and deleting all policies, but it does not wait for concurrent RCU readers to leave their read-side critical sections first.  The policy_bydst tables are published via rcu_assign_pointer() and are looked up through rcu_dereference_check(), so netns teardown must also wait for an RCU grace period before freeing the table memory.  Fix this by adding synchronize_rcu() before freeing the policy hash tables.

CVE-2026-43101:

        In the Linux kernel, the following vulnerability has been resolved:  ipv6: ioam: fix potential NULL dereferences in __ioam6_fill_trace_data()  We need to check __in6_dev_get() for possible NULL value, as suggested by Yiming Qian.  Also add skb_dst_dev_rcu() instead of skb_dst_dev(), and two missing READ_ONCE().  Note that @dev can't be NULL.

CVE-2026-43107:

        In the Linux kernel, the following vulnerability has been resolved:  xfrm: account XFRMA_IF_ID in aevent size calculation  xfrm_get_ae() allocates the reply skb with xfrm_aevent_msgsize(), then build_aevent() appends attributes including XFRMA_IF_ID when x->if_id is set.  xfrm_aevent_msgsize() does not include space for XFRMA_IF_ID. For states with if_id, build_aevent() can fail with -EMSGSIZE and hit BUG_ON(err < 0) in xfrm_get_ae(), turning a malformed netlink interaction into a kernel panic.  Account XFRMA_IF_ID in the size calculation unconditionally and replace the BUG_ON with normal error unwinding.

CVE-2026-43115:

        In the Linux kernel, the following vulnerability has been resolved:  srcu: Use irq_work to start GP in tiny SRCU  Tiny SRCU's srcu_gp_start_if_needed() directly calls schedule_work(), which acquires the workqueue pool->lock.  This causes a lockdep splat when call_srcu() is called with a scheduler lock held, due to:    call_srcu() [holding pi_lock]     srcu_gp_start_if_needed()       schedule_work() -> pool->lock    workqueue_init() / create_worker() [holding pool->lock]     wake_up_process() -> try_to_wake_up() -> pi_lock  Also add irq_work_sync() to cleanup_srcu_struct() to prevent a use-after-free if a queued irq_work fires after cleanup begins.  Tested with rcutorture SRCU-T and no lockdep warnings.  [ Thanks to Boqun for similar fix in patch "rcu: Use an intermediate irq_work to start process_srcu()" ]

CVE-2026-43118:

        In the Linux kernel, the following vulnerability has been resolved:  btrfs: fix zero size inode with non-zero size after log replay  When logging that an inode exists, as part of logging a new name or logging new dir entries for a directory, we always set the generation of the logged inode item to 0. This is to signal during log replay (in overwrite_item()), that we should not set the i_size since we only logged that an inode exists, so the i_size of the inode in the subvolume tree must be preserved (as when we log new names or that an inode exists, we don't log extents).  This works fine except when we have already logged an inode in full mode or it's the first time we are logging an inode created in a past transaction, that inode has a new i_size of 0 and then we log a new name for the inode (due to a new hardlink or a rename), in which case we log an i_size of 0 for the inode and a generation of 0, which causes the log replay code to not update the inode's i_size to 0 (in overwrite_item()).  An example scenario:    mkdir /mnt/dir   xfs_io -f -c "pwrite 0 64K" /mnt/dir/foo    sync    xfs_io -c "truncate 0" -c "fsync" /mnt/dir/foo    ln /mnt/dir/foo /mnt/dir/bar    xfs_io -c "fsync" /mnt/dir    <power fail>  After log replay the file remains with a size of 64K. This is because when we first log the inode, when we fsync file foo, we log its current i_size of 0, and then when we create a hard link we log again the inode in exists mode (LOG_INODE_EXISTS) but we set a generation of 0 for the inode item we add to the log tree, so during log replay overwrite_item() sees that the generation is 0 and i_size is 0 so we skip updating the inode's i_size from 64K to 0.  Fix this by making sure at fill_inode_item() we always log the real generation of the inode if it was logged in the current transaction with the i_size we logged before. Also if an inode created in a previous transaction is logged in exists mode only, make sure we log the i_size stored in the inode item located from the commit root, so that if we log multiple times that the inode exists we get the correct i_size.  A test case for fstests will follow soon.

CVE-2026-43119:

        In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: hci_sync: annotate data-races around hdev->req_status  __hci_cmd_sync_sk() sets hdev->req_status under hdev->req_lock:      hdev->req_status = HCI_REQ_PEND;  However, several other functions read or write hdev->req_status without holding any lock:    - hci_send_cmd_sync() reads req_status in hci_cmd_work (workqueue)   - hci_cmd_sync_complete() reads/writes from HCI event completion   - hci_cmd_sync_cancel() / hci_cmd_sync_cancel_sync() read/write   - hci_abort_conn() reads in connection abort path  Since __hci_cmd_sync_sk() runs on hdev->req_workqueue while hci_send_cmd_sync() runs on hdev->workqueue, these are different workqueues that can execute concurrently on different CPUs. The plain C accesses constitute a data race.  Add READ_ONCE()/WRITE_ONCE() annotations on all concurrent accesses to hdev->req_status to prevent potential compiler optimizations that could affect correctness (e.g., load fusing in the wait_event condition or store reordering).

CVE-2026-43125:

        In the Linux kernel, the following vulnerability has been resolved:  dlm: validate length in dlm_search_rsb_tree  The len parameter in dlm_dump_rsb_name() is not validated and comes from network messages. When it exceeds DLM_RESNAME_MAXLEN, it can cause out-of-bounds write in dlm_search_rsb_tree().  Add length validation to prevent potential buffer overflow.

CVE-2026-43126:

        In the Linux kernel, the following vulnerability has been resolved:  ALSA: mixer: oss: Add card disconnect checkpoints  ALSA OSS mixer layer calls the kcontrol ops rather individually, and pending calls might be not always caught at disconnecting the device.  For avoiding the potential UAF scenarios, add sanity checks of the card disconnection at each entry point of OSS mixer accesses.  The rwsem is taken just before that check, hence the rest context should be covered by that properly.

CVE-2026-43129:

        In the Linux kernel, the following vulnerability has been resolved:  ima: verify the previous kernel's IMA buffer lies in addressable RAM  Patch series "Address page fault in ima_restore_measurement_list()", v3.  When the second-stage kernel is booted via kexec with a limiting command line such as "mem=<size>" we observe a pafe fault that happens.      BUG: unable to handle page fault for address: ffff97793ff47000     RIP: ima_restore_measurement_list+0xdc/0x45a     #PF: error_code(0x0000)  not-present page  This happens on x86_64 only, as this is already fixed in aarch64 in commit: cbf9c4b9617b ("of: check previous kernel's ima-kexec-buffer against memory bounds")   This patch (of 3):  When the second-stage kernel is booted with a limiting command line (e.g.  "mem=<size>"), the IMA measurement buffer handed over from the previous kernel may fall outside the addressable RAM of the new kernel.  Accessing such a buffer can fault during early restore.  Introduce a small generic helper, ima_validate_range(), which verifies that a physical [start, end] range for the previous-kernel IMA buffer lies within addressable memory: 	- On x86, use pfn_range_is_mapped(). 	- On OF based architectures, use page_is_ram().

CVE-2026-43137:

        In the Linux kernel, the following vulnerability has been resolved:  ASoC: SOF: Intel: hda: Fix NULL pointer dereference  If there's a mismatch between the DAI links in the machine driver and the topology, it is possible that the playback/capture widget is not set, especially in the case of loopback capture for echo reference where we use the dummy DAI link. Return the error when the widget is not set to avoid a null pointer dereference like below when the topology is broken.  RIP: 0010:hda_dai_get_ops.isra.0+0x14/0xa0 [snd_sof_intel_hda_common]

CVE-2026-43153:

        In the Linux kernel, the following vulnerability has been resolved:  xfs: remove xfs_attr_leaf_hasname  The calling convention of xfs_attr_leaf_hasname() is problematic, because it returns a NULL buffer when xfs_attr3_leaf_read fails, a valid buffer when xfs_attr3_leaf_lookup_int returns -ENOATTR or -EEXIST, and a non-NULL buffer pointer for an already released buffer when xfs_attr3_leaf_lookup_int fails with other error values.  Fix this by simply open coding xfs_attr_leaf_hasname in the callers, so that the buffer release code is done by each caller of xfs_attr3_leaf_read.

CVE-2026-43161:

        In the Linux kernel, the following vulnerability has been resolved:  iommu/vt-d: Skip dev-iotlb flush for inaccessible PCIe device without scalable mode  PCIe endpoints with ATS enabled and passed through to userspace (e.g., QEMU, DPDK) can hard-lock the host when their link drops, either by surprise removal or by a link fault.  Commit 4fc82cd907ac ("iommu/vt-d: Don't issue ATS Invalidation request when device is disconnected") adds pci_dev_is_disconnected() to devtlb_invalidation_with_pasid() so ATS invalidation is skipped only when the device is being safely removed, but it applies only when Intel IOMMU scalable mode is enabled.  With scalable mode disabled or unsupported, a system hard-lock occurs when a PCIe endpoint's link drops because the Intel IOMMU waits indefinitely for an ATS invalidation that cannot complete.  Call Trace:  qi_submit_sync  qi_flush_dev_iotlb  __context_flush_dev_iotlb.part.0  domain_context_clear_one_cb  pci_for_each_dma_alias  device_block_translation  blocking_domain_attach_dev  iommu_deinit_device  __iommu_group_remove_device  iommu_release_device  iommu_bus_notifier  blocking_notifier_call_chain  bus_notify  device_del  pci_remove_bus_device  pci_stop_and_remove_bus_device  pciehp_unconfigure_device  pciehp_disable_slot  pciehp_handle_presence_or_link_change  pciehp_ist  Commit 81e921fd3216 ("iommu/vt-d: Fix NULL domain on device release") adds intel_pasid_teardown_sm_context() to intel_iommu_release_device(), which calls qi_flush_dev_iotlb() and can also hard-lock the system when a PCIe endpoint's link drops.  Call Trace:  qi_submit_sync  qi_flush_dev_iotlb  __context_flush_dev_iotlb.part.0  intel_context_flush_no_pasid  device_pasid_table_teardown  pci_pasid_table_teardown  pci_for_each_dma_alias  intel_pasid_teardown_sm_context  intel_iommu_release_device  iommu_deinit_device  __iommu_group_remove_device  iommu_release_device  iommu_bus_notifier  blocking_notifier_call_chain  bus_notify  device_del  pci_remove_bus_device  pci_stop_and_remove_bus_device  pciehp_unconfigure_device  pciehp_disable_slot  pciehp_handle_presence_or_link_change  pciehp_ist  Sometimes the endpoint loses connection without a link-down event (e.g., due to a link fault); killing the process (virsh destroy) then hard-locks the host.  Call Trace:  qi_submit_sync  qi_flush_dev_iotlb  __context_flush_dev_iotlb.part.0  domain_context_clear_one_cb  pci_for_each_dma_alias  device_block_translation  blocking_domain_attach_dev  __iommu_attach_device  __iommu_device_set_domain  __iommu_group_set_domain_internal  iommu_detach_group  vfio_iommu_type1_detach_group  vfio_group_detach_container  vfio_group_fops_release  __fput  pci_dev_is_disconnected() only covers safe-removal paths; pci_device_is_present() tests accessibility by reading vendor/device IDs and internally calls pci_dev_is_disconnected(). On a ConnectX-5 (8 GT/s, x2) this costs ~70 µs.  Since __context_flush_dev_iotlb() is only called on {attach,release}_dev paths (not hot), add pci_device_is_present() there to skip inaccessible devices and avoid the hard-lock.

CVE-2026-43167:

        In the Linux kernel, the following vulnerability has been resolved:  xfrm: always flush state and policy upon NETDEV_UNREGISTER event  syzbot is reporting that "struct xfrm_state" refcount is leaking.    unregister_netdevice: waiting for netdevsim0 to become free. Usage count = 2   ref_tracker: netdev@ffff888052f24618 has 1/1 users at        __netdev_tracker_alloc include/linux/netdevice.h:4400 [inline]        netdev_tracker_alloc include/linux/netdevice.h:4412 [inline]        xfrm_dev_state_add+0x3a5/0x1080 net/xfrm/xfrm_device.c:316        xfrm_state_construct net/xfrm/xfrm_user.c:986 [inline]        xfrm_add_sa+0x34ff/0x5fa0 net/xfrm/xfrm_user.c:1022        xfrm_user_rcv_msg+0x58e/0xc00 net/xfrm/xfrm_user.c:3507        netlink_rcv_skb+0x158/0x420 net/netlink/af_netlink.c:2550        xfrm_netlink_rcv+0x71/0x90 net/xfrm/xfrm_user.c:3529        netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline]        netlink_unicast+0x5aa/0x870 net/netlink/af_netlink.c:1344        netlink_sendmsg+0x8c8/0xdd0 net/netlink/af_netlink.c:1894        sock_sendmsg_nosec net/socket.c:727 [inline]        __sock_sendmsg net/socket.c:742 [inline]        ____sys_sendmsg+0xa5d/0xc30 net/socket.c:2592        ___sys_sendmsg+0x134/0x1d0 net/socket.c:2646        __sys_sendmsg+0x16d/0x220 net/socket.c:2678        do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]        do_syscall_64+0xcd/0xf80 arch/x86/entry/syscall_64.c:94        entry_SYSCALL_64_after_hwframe+0x77/0x7f  This is because commit d77e38e612a0 ("xfrm: Add an IPsec hardware offloading API") implemented xfrm_dev_unregister() as no-op despite xfrm_dev_state_add() from xfrm_state_construct() acquires a reference to "struct net_device". I guess that that commit expected that NETDEV_DOWN event is fired before NETDEV_UNREGISTER event fires, and also assumed that xfrm_dev_state_add() is called only if (dev->features & NETIF_F_HW_ESP) != 0.  Sabrina Dubroca identified steps to reproduce the same symptoms as below.    echo 0 > /sys/bus/netdevsim/new_device   dev=$(ls -1 /sys/bus/netdevsim/devices/netdevsim0/net/)   ip xfrm state add src 192.168.13.1 dst 192.168.13.2 proto esp \      spi 0x1000 mode tunnel aead 'rfc4106(gcm(aes))' $key 128   \      offload crypto dev $dev dir out   ethtool -K $dev esp-hw-offload off   echo 0 > /sys/bus/netdevsim/del_device  Like these steps indicate, the NETIF_F_HW_ESP bit can be cleared after xfrm_dev_state_add() acquired a reference to "struct net_device". Also, xfrm_dev_state_add() does not check for the NETIF_F_HW_ESP bit when acquiring a reference to "struct net_device".  Commit 03891f820c21 ("xfrm: handle NETDEV_UNREGISTER for xfrm device") re-introduced the NETDEV_UNREGISTER event to xfrm_dev_event(), but that commit for unknown reason chose to share xfrm_dev_down() between the NETDEV_DOWN event and the NETDEV_UNREGISTER event. I guess that that commit missed the behavior in the previous paragraph.  Therefore, we need to re-introduce xfrm_dev_unregister() in order to release the reference to "struct net_device" by unconditionally flushing state and policy.

CVE-2026-43170:

        In the Linux kernel, the following vulnerability has been resolved:  usb: dwc3: gadget: Move vbus draw to workqueue context  Currently dwc3_gadget_vbus_draw() can be called from atomic context, which in turn invokes power-supply-core APIs. And some these PMIC APIs have operations that may sleep, leading to kernel panic.  Fix this by moving the vbus_draw into a workqueue context.

CVE-2026-43172:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: iwlwifi: fix 22000 series SMEM parsing  If the firmware were to report three LMACs (which doesn't exist in hardware) then using "fwrt->smem_cfg.lmac[2]" is an overrun of the array. Reject such and use IWL_FW_CHECK instead of WARN_ON in this function.

CVE-2026-43173:

        In the Linux kernel, the following vulnerability has been resolved:  net: ethernet: xscale: Check for PTP support properly  In ixp4xx_get_ts_info() ixp46x_ptp_find() is called unconditionally despite this feature only existing on ixp46x, leading to the following splat from tcpdump:  root@OpenWrt:~# tcpdump -vv -X -i eth0 (...) Unable to handle kernel NULL pointer dereference at virtual address   00000238 when read (...) Call trace:  ptp_clock_index from ixp46x_ptp_find+0x1c/0x38  ixp46x_ptp_find from ixp4xx_get_ts_info+0x4c/0x64  ixp4xx_get_ts_info from __ethtool_get_ts_info+0x90/0x108  __ethtool_get_ts_info from __dev_ethtool+0xa00/0x2648  __dev_ethtool from dev_ethtool+0x160/0x234  dev_ethtool from dev_ioctl+0x2cc/0x460  dev_ioctl from sock_ioctl+0x1ec/0x524  sock_ioctl from sys_ioctl+0x51c/0xa94  sys_ioctl from ret_fast_syscall+0x0/0x44  (...) Segmentation fault  Check for ixp46x in ixp46x_ptp_find() before trying to set up PTP to avoid this.  To avoid altering the returned error code from ixp4xx_hwtstamp_set() which before this patch was -EOPNOTSUPP, we return -EOPNOTSUPP from ixp4xx_hwtstamp_set() if ixp46x_ptp_find() fails no matter the error code. The helper function ixp46x_ptp_find() helper returns -ENODEV.

CVE-2026-43185:

        In the Linux kernel, the following vulnerability has been resolved:  ksmbd: fix signededness bug in smb_direct_prepare_negotiation()  smb_direct_prepare_negotiation() casts an unsigned __u32 value from sp->max_recv_size and req->preferred_send_size to a signed int before computing min_t(int, ...). A maliciously provided preferred_send_size of 0x80000000 will return as smaller than max_recv_size, and then be used to set the maximum allowed alowed receive size for the next message.  By sending a second message with a large value (>1420 bytes) the attacker can then achieve a heap buffer overflow.  This fix replaces min_t(int, ...) with min_t(u32)

CVE-2026-43204:

        In the Linux kernel, the following vulnerability has been resolved:  ASoC: qcom: q6asm: drop DSP responses for closed data streams  'Commit a354f030dbce ("ASoC: qcom: q6asm: handle the responses after closing")' attempted to ignore DSP responses arriving after a stream had been closed.  However, those responses were still handled, causing lockups.  Fix this by unconditionally dropping all DSP responses associated with closed data streams.

CVE-2026-43213:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: rtw89: pci: validate sequence number of TX release report  Hardware rarely reports abnormal sequence number in TX release report, which will access out-of-bounds of wd_ring->pages array, causing NULL pointer dereference.    BUG: kernel NULL pointer dereference, address: 0000000000000000   #PF: supervisor read access in kernel mode   #PF: error_code(0x0000) - not-present page   PGD 0 P4D 0   Oops: 0000 [#1] PREEMPT SMP NOPTI   CPU: 1 PID: 1085 Comm: irq/129-rtw89_p Tainted: G S   U              6.1.145-17510-g2f3369c91536 #1 (HASH:69e8 1)   Call Trace:    <IRQ>    rtw89_pci_release_tx+0x18f/0x300 [rtw89_pci (HASH:4c83 2)]    rtw89_pci_napi_poll+0xc2/0x190 [rtw89_pci (HASH:4c83 2)]    net_rx_action+0xfc/0x460 net/core/dev.c:6578 net/core/dev.c:6645 net/core/dev.c:6759    handle_softirqs+0xbe/0x290 kernel/softirq.c:601    ? rtw89_pci_interrupt_threadfn+0xc5/0x350 [rtw89_pci (HASH:4c83 2)]    __local_bh_enable_ip+0xeb/0x120 kernel/softirq.c:499 kernel/softirq.c:423    </IRQ>    <TASK>    rtw89_pci_interrupt_threadfn+0xf8/0x350 [rtw89_pci (HASH:4c83 2)]    ? irq_thread+0xa7/0x340 kernel/irq/manage.c:0    irq_thread+0x177/0x340 kernel/irq/manage.c:1205 kernel/irq/manage.c:1314    ? thaw_kernel_threads+0xb0/0xb0 kernel/irq/manage.c:1202    ? irq_forced_thread_fn+0x80/0x80 kernel/irq/manage.c:1220    kthread+0xea/0x110 kernel/kthread.c:376    ? synchronize_irq+0x1a0/0x1a0 kernel/irq/manage.c:1287    ? kthread_associate_blkcg+0x80/0x80 kernel/kthread.c:331    ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295    </TASK>  To prevent crash, validate rpp_info.seq before using.

CVE-2026-43215:

        In the Linux kernel, the following vulnerability has been resolved:  cifs: Fix locking usage for tcon fields  We used to use the cifs_tcp_ses_lock to protect a lot of objects that are not just the server, ses or tcon lists. We later introduced srv_lock, ses_lock and tc_lock to protect fields within the corresponding structs. This was done to provide a more granular protection and avoid unnecessary serialization.  There were still a couple of uses of cifs_tcp_ses_lock to provide tcon fields. In this patch, I've replaced them with tc_lock.

CVE-2026-43234:

        In the Linux kernel, the following vulnerability has been resolved:  team: avoid NETDEV_CHANGEMTU event when unregistering slave  syzbot is reporting    unregister_netdevice: waiting for netdevsim0 to become free. Usage count = 3   ref_tracker: netdev@ffff88807dcf8618 has 1/2 users at        __netdev_tracker_alloc include/linux/netdevice.h:4400 [inline]        netdev_hold include/linux/netdevice.h:4429 [inline]        inetdev_init+0x201/0x4e0 net/ipv4/devinet.c:286        inetdev_event+0x251/0x1610 net/ipv4/devinet.c:1600        notifier_call_chain+0x19d/0x3a0 kernel/notifier.c:85        call_netdevice_notifiers_mtu net/core/dev.c:2318 [inline]        netif_set_mtu_ext+0x5aa/0x800 net/core/dev.c:9886        netif_set_mtu+0xd7/0x1b0 net/core/dev.c:9907        dev_set_mtu+0x126/0x260 net/core/dev_api.c:248        team_port_del+0xb07/0xcb0 drivers/net/team/team_core.c:1333        team_del_slave drivers/net/team/team_core.c:1936 [inline]        team_device_event+0x207/0x5b0 drivers/net/team/team_core.c:2929        notifier_call_chain+0x19d/0x3a0 kernel/notifier.c:85        call_netdevice_notifiers_extack net/core/dev.c:2281 [inline]        call_netdevice_notifiers net/core/dev.c:2295 [inline]        __dev_change_net_namespace+0xcb7/0x2050 net/core/dev.c:12592        do_setlink+0x2ce/0x4590 net/core/rtnetlink.c:3060        rtnl_changelink net/core/rtnetlink.c:3776 [inline]        __rtnl_newlink net/core/rtnetlink.c:3935 [inline]        rtnl_newlink+0x15a9/0x1be0 net/core/rtnetlink.c:4072        rtnetlink_rcv_msg+0x7d5/0xbe0 net/core/rtnetlink.c:6958        netlink_rcv_skb+0x232/0x4b0 net/netlink/af_netlink.c:2550        netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline]        netlink_unicast+0x80f/0x9b0 net/netlink/af_netlink.c:1344        netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1894  problem. Ido Schimmel found steps to reproduce    ip link add name team1 type team   ip link add name dummy1 mtu 1499 master team1 type dummy   ip netns add ns1   ip link set dev dummy1 netns ns1   ip -n ns1 link del dev dummy1  and also found that the same issue was fixed in the bond driver in commit f51048c3e07b ("bonding: avoid NETDEV_CHANGEMTU event when unregistering slave").  Let's do similar thing for the team driver, with commit ad7c7b2172c3 ("net: hold netdev instance lock during sysfs operations") and commit 303a8487a657 ("net: s/__dev_set_mtu/__netif_set_mtu/") also applied.

CVE-2026-43239:

        In the Linux kernel, the following vulnerability has been resolved:  smb: client: prevent races in ->query_interfaces()  It was possible for two query interface works to be concurrently trying to update the interfaces.  Prevent this by checking and updating iface_last_update under iface_lock.

CVE-2026-43244:

        In the Linux kernel, the following vulnerability has been resolved:  kcm: fix zero-frag skb in frag_list on partial sendmsg error  Syzkaller reported a warning in kcm_write_msgs() when processing a message with a zero-fragment skb in the frag_list.  When kcm_sendmsg() fills MAX_SKB_FRAGS fragments in the current skb, it allocates a new skb (tskb) and links it into the frag_list before copying data. If the copy subsequently fails (e.g. -EFAULT from user memory), tskb remains in the frag_list with zero fragments:    head skb (msg being assembled, NOT yet in sk_write_queue)   +-----------+   | frags[17] |  (MAX_SKB_FRAGS, all filled with data)   | frag_list-+--> tskb   +-----------+    +----------+                    | frags[0] |  (empty! copy failed before filling)                    +----------+  For SOCK_SEQPACKET with partial data already copied, the error path saves this message via partial_message for later completion. For SOCK_SEQPACKET, sock_write_iter() automatically sets MSG_EOR, so a subsequent zero-length write(fd, NULL, 0) completes the message and queues it to sk_write_queue. kcm_write_msgs() then walks the frag_list and hits:    WARN_ON(!skb_shinfo(skb)->nr_frags)  TCP has a similar pattern where skbs are enqueued before data copy and cleaned up on failure via tcp_remove_empty_skb(). KCM was missing the equivalent cleanup.  Fix this by tracking the predecessor skb (frag_prev) when allocating a new frag_list entry. On error, if the tail skb has zero frags, use frag_prev to unlink and free it in O(1) without walking the singly-linked frag_list. frag_prev is safe to dereference because the entire message chain is only held locally (or in kcm->seq_skb) and is not added to sk_write_queue until MSG_EOR, so the send path cannot free it underneath us.  Also change the WARN_ON to WARN_ON_ONCE to avoid flooding the log if the condition is somehow hit repeatedly.  There are currently no KCM selftests in the kernel tree; a simple reproducer is available at [1].  [1] https://gist.github.com/mrpre/a94d431c757e8d6f168f4dd1a3749daa

CVE-2026-43248:

        In the Linux kernel, the following vulnerability has been resolved:  vhost: move vdpa group bound check to vhost_vdpa  Remove duplication by consolidating these here.  This reduces the posibility of a parent driver missing them.  While we're at it, fix a bug in vdpa_sim where a valid ASID can be assigned to a group equal to ngroups, causing an out of bound write.

CVE-2026-43249:

        In the Linux kernel, the following vulnerability has been resolved:  9p/xen: protect xen_9pfs_front_free against concurrent calls  The xenwatch thread can race with other back-end change notifications and call xen_9pfs_front_free() twice, hitting the observed general protection fault due to a double-free. Guard the teardown path so only one caller can release the front-end state at a time, preventing the crash.  This is a fix for the following double-free:  [   27.052347] Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b6b: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI [   27.052357] CPU: 0 UID: 0 PID: 32 Comm: xenwatch Not tainted 6.18.0-02087-g51ab33fc0a8b-dirty #60 PREEMPT(none) [   27.052363] RIP: e030:xen_9pfs_front_free+0x1d/0x150 [   27.052368] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 41 55 41 54 55 48 89 fd 48 c7 c7 48 d0 92 85 53 e8 cb cb 05 00 48 8b 45 08 48 8b 55 00 <48> 3b 28 0f 85 f9 28 35 fe 48 3b 6a 08 0f 85 ef 28 35 fe 48 89 42 [   27.052377] RSP: e02b:ffffc9004016fdd0 EFLAGS: 00010246 [   27.052381] RAX: 6b6b6b6b6b6b6b6b RBX: ffff88800d66e400 RCX: 0000000000000000 [   27.052385] RDX: 6b6b6b6b6b6b6b6b RSI: 0000000000000000 RDI: 0000000000000000 [   27.052389] RBP: ffff88800a887040 R08: 0000000000000000 R09: 0000000000000000 [   27.052393] R10: 0000000000000000 R11: 0000000000000000 R12: ffff888009e46b68 [   27.052397] R13: 0000000000000200 R14: 0000000000000000 R15: ffff88800a887040 [   27.052404] FS:  0000000000000000(0000) GS:ffff88808ca57000(0000) knlGS:0000000000000000 [   27.052408] CS:  e030 DS: 0000 ES: 0000 CR0: 0000000080050033 [   27.052412] CR2: 00007f9714004360 CR3: 0000000004834000 CR4: 0000000000050660 [   27.052418] Call Trace: [   27.052420]  <TASK> [   27.052422]  xen_9pfs_front_changed+0x5d5/0x720 [   27.052426]  ? xenbus_otherend_changed+0x72/0x140 [   27.052430]  ? __pfx_xenwatch_thread+0x10/0x10 [   27.052434]  xenwatch_thread+0x94/0x1c0 [   27.052438]  ? __pfx_autoremove_wake_function+0x10/0x10 [   27.052442]  kthread+0xf8/0x240 [   27.052445]  ? __pfx_kthread+0x10/0x10 [   27.052449]  ? __pfx_kthread+0x10/0x10 [   27.052452]  ret_from_fork+0x16b/0x1a0 [   27.052456]  ? __pfx_kthread+0x10/0x10 [   27.052459]  ret_from_fork_asm+0x1a/0x30 [   27.052463]  </TASK> [   27.052465] Modules linked in: [   27.052471] ---[ end trace 0000000000000000 ]---

CVE-2026-43250:

        In the Linux kernel, the following vulnerability has been resolved:  usb: chipidea: udc: fix DMA and SG cleanup in _ep_nuke()  The ChipIdea UDC driver can encounter "not page aligned sg buffer" errors when a USB device is reconnected after being disconnected during an active transfer. This occurs because _ep_nuke() returns requests to the gadget layer without properly unmapping DMA buffers or cleaning up scatter-gather bounce buffers.  Root cause: When a disconnect happens during a multi-segment DMA transfer, the request's num_mapped_sgs field and sgt.sgl pointer remain set with stale values. The request is returned to the gadget driver with status -ESHUTDOWN but still has active DMA state. If the gadget driver reuses this request on reconnect without reinitializing it, the stale DMA state causes _hardware_enqueue() to skip DMA mapping (seeing non-zero num_mapped_sgs) and attempt to use freed/invalid DMA addresses, leading to alignment errors and potential memory corruption.  The normal completion path via _hardware_dequeue() properly calls usb_gadget_unmap_request_by_dev() and sglist_do_debounce() before returning the request. The _ep_nuke() path must do the same cleanup to ensure requests are returned in a clean, reusable state.  Fix: Add DMA unmapping and bounce buffer cleanup to _ep_nuke() to mirror the cleanup sequence in _hardware_dequeue(): - Call usb_gadget_unmap_request_by_dev() if num_mapped_sgs is set - Call sglist_do_debounce() with copy=false if bounce buffer exists  This ensures that when requests are returned due to endpoint shutdown, they don't retain stale DMA mappings. The 'false' parameter to sglist_do_debounce() prevents copying data back (appropriate for shutdown path where transfer was aborted).

CVE-2026-43253:

        In the Linux kernel, the following vulnerability has been resolved:  iommu/amd: move wait_on_sem() out of spinlock  With iommu.strict=1, the existing completion wait path can cause soft lockups under stressed environment, as wait_on_sem() busy-waits under the spinlock with interrupts disabled.  Move the completion wait in iommu_completion_wait() out of the spinlock. wait_on_sem() only polls the hardware-updated cmd_sem and does not require iommu->lock, so holding the lock during the busy wait unnecessarily increases contention and extends the time with interrupts disabled.

CVE-2026-43258:

        In the Linux kernel, the following vulnerability has been resolved:  alpha: fix user-space corruption during memory compaction  Alpha systems can suffer sporadic user-space crashes and heap corruption when memory compaction is enabled.  Symptoms include SIGSEGV, glibc allocator failures (e.g. "unaligned tcache chunk"), and compiler internal errors. The failures disappear when compaction is disabled or when using global TLB invalidation.  The root cause is insufficient TLB shootdown during page migration. Alpha relies on ASN-based MM context rollover for instruction cache coherency, but this alone is not sufficient to prevent stale data or instruction translations from surviving migration.  Fix this by introducing a migration-specific helper that combines:   - MM context invalidation (ASN rollover),   - immediate per-CPU TLB invalidation (TBI),   - synchronous cross-CPU shootdown when required.  The helper is used only by migration/compaction paths to avoid changing global TLB semantics.  Additionally, update flush_tlb_other(), pte_clear(), to use READ_ONCE()/WRITE_ONCE() for correct SMP memory ordering.  This fixes observed crashes on both UP and SMP Alpha systems.

CVE-2026-43271:

        In the Linux kernel, the following vulnerability has been resolved:  md-cluster: fix NULL pointer dereference in process_metadata_update  The function process_metadata_update() blindly dereferences the 'thread' pointer (acquired via rcu_dereference_protected) within the wait_event() macro.  While the code comment states "daemon thread must exist", there is a valid race condition window during the MD array startup sequence (md_run):  1. bitmap_load() is called, which invokes md_cluster_ops->join(). 2. join() starts the "cluster_recv" thread (recv_daemon). 3. At this point, recv_daemon is active and processing messages. 4. However, mddev->thread (the main MD thread) is not initialized until    later in md_run().  If a METADATA_UPDATED message is received from a remote node during this specific window, process_metadata_update() will be called while mddev->thread is still NULL, leading to a kernel panic.  To fix this, we must validate the 'thread' pointer. If it is NULL, we release the held lock (no_new_dev_lockres) and return early, safely ignoring the update request as the array is not yet fully ready to process it.

CVE-2026-43299:

        In the Linux kernel, the following vulnerability has been resolved:  btrfs: do not ASSERT() when the fs flips RO inside btrfs_repair_io_failure()  [BUG] There is a bug report that when btrfs hits ENOSPC error in a critical path, btrfs flips RO (this part is expected, although the ENOSPC bug still needs to be addressed).  The problem is after the RO flip, if there is a read repair pending, we can hit the ASSERT() inside btrfs_repair_io_failure() like the following:    BTRFS info (device vdc): relocating block group 30408704 flags metadata|raid1   ------------[ cut here ]------------   BTRFS: Transaction aborted (error -28)   WARNING: fs/btrfs/extent-tree.c:3235 at __btrfs_free_extent.isra.0+0x453/0xfd0, CPU#1: btrfs/383844   Modules linked in: kvm_intel kvm irqbypass   [...]   ---[ end trace 0000000000000000 ]---   BTRFS info (device vdc state EA): 2 enospc errors during balance   BTRFS info (device vdc state EA): balance: ended with status: -30   BTRFS error (device vdc state EA): parent transid verify failed on logical 30556160 mirror 2 wanted 8 found 6   BTRFS error (device vdc state EA): bdev /dev/nvme0n1 errs: wr 0, rd 0, flush 0, corrupt 10, gen 0   [...]   assertion failed: !(fs_info->sb->s_flags & SB_RDONLY) :: 0, in fs/btrfs/bio.c:938   ------------[ cut here ]------------   assertion failed: !(fs_info->sb->s_flags & SB_RDONLY) :: 0, in fs/btrfs/bio.c:938   kernel BUG at fs/btrfs/bio.c:938!   Oops: invalid opcode: 0000 [#1] SMP NOPTI   CPU: 0 UID: 0 PID: 868 Comm: kworker/u8:13 Tainted: G        W        N  6.19.0-rc6+ #4788 PREEMPT(full)   Tainted: [W]=WARN, [N]=TEST   Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014   Workqueue: btrfs-endio simple_end_io_work   RIP: 0010:btrfs_repair_io_failure.cold+0xb2/0x120   RSP: 0000:ffffc90001d2bcf0 EFLAGS: 00010246   RAX: 0000000000000051 RBX: 0000000000001000 RCX: 0000000000000000   RDX: 0000000000000000 RSI: ffffffff8305cf42 RDI: 00000000ffffffff   RBP: 0000000000000002 R08: 00000000fffeffff R09: ffffffff837fa988   R10: ffffffff8327a9e0 R11: 6f69747265737361 R12: ffff88813018d310   R13: ffff888168b8a000 R14: ffffc90001d2bd90 R15: ffff88810a169000   FS:  0000000000000000(0000) GS:ffff8885e752c000(0000) knlGS:0000000000000000   CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033   ------------[ cut here ]------------  [CAUSE] The cause of -ENOSPC error during the test case btrfs/124 is still unknown, although it's known that we still have cases where metadata can be over-committed but can not be fulfilled correctly, thus if we hit such ENOSPC error inside a critical path, we have no choice but abort the current transaction.  This will mark the fs read-only.  The problem is inside the btrfs_repair_io_failure() path that we require the fs not to be mount read-only. This is normally fine, but if we are doing a read-repair meanwhile the fs flips RO due to a critical error, we can enter btrfs_repair_io_failure() with super block set to read-only, thus triggering the above crash.  [FIX] Just replace the ASSERT() with a proper return if the fs is already read-only.

CVE-2026-43308:

        In the Linux kernel, the following vulnerability has been resolved:  btrfs: don't BUG() on unexpected delayed ref type in run_one_delayed_ref()  There is no need to BUG(), we can just return an error and log an error message.

CVE-2026-43309:

        In the Linux kernel, the following vulnerability has been resolved:  md raid: fix hang when stopping arrays with metadata through dm-raid  When using device-mapper's dm-raid target, stopping a RAID array can cause the system to hang under specific conditions.  This occurs when:  - A dm-raid managed device tree is suspended from top to bottom    (the top-level RAID device is suspended first, followed by its     underlying metadata and data devices)  - The top-level RAID device is then removed  Removing the top-level device triggers a hang in the following sequence: the dm-raid destructor calls md_stop(), which tries to flush the write-intent bitmap by writing to the metadata sub-devices. However, these devices are already suspended, making them unable to complete the write-intent operations and causing an indefinite block.  Fix:  - Prevent bitmap flushing when md_stop() is called from dm-raid destructor context   and avoid a quiescing/unquescing cycle which could also cause I/O  - Still allow write-intent bitmap flushing when called from dm-raid suspend context  This ensures that RAID array teardown can complete successfully even when the underlying devices are in a suspended state.  This second patch uses md_is_rdwr() to distinguish between suspend and destructor paths as elaborated on above.

CVE-2026-43310:

        In the Linux kernel, the following vulnerability has been resolved:  media: verisilicon: Avoid G2 bus error while decoding H.264 and HEVC  For the i.MX8MQ platform, there is a hardware limitation: the g1 VPU and g2 VPU cannot decode simultaneously; otherwise, it will cause below bus error and produce corrupted pictures, even potentially lead to system hang.  [  110.527986] hantro-vpu 38310000.video-codec: frame decode timed out. [  110.583517] hantro-vpu 38310000.video-codec: bus error detected.  Therefore, it is necessary to ensure that g1 and g2 operate alternately. This allows for successful multi-instance decoding of H.264 and HEVC.  To achieve this, g1 and g2 share the same v4l2_m2m_dev, and then the v4l2_m2m_dev can handle the scheduling.

CVE-2026-43317:

        In the Linux kernel, the following vulnerability has been resolved:  most: core: fix leak on early registration failure  A recent commit fixed a resource leak on early registration failures but for some reason left out the first error path which still leaks the resources associated with the interface.  Fix up also the first error path so that the interface is always released on errors.

CVE-2026-43318:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu: fix sync handling in amdgpu_dma_buf_move_notify  Invalidating a dmabuf will impact other users of the shared BO. In the scenario where process A moves the BO, it needs to inform process B about the move and process B will need to update its page table.  The commit fixes a synchronisation bug caused by the use of the ticket: it made amdgpu_vm_handle_moved behave as if updating the page table immediately was correct but in this case it's not.  An example is the following scenario, with 2 GPUs and glxgears running on GPU0 and Xorg running on GPU1, on a system where P2P PCI isn't supported:  glxgears:   export linear buffer from GPU0 and import using GPU1   submit frame rendering to GPU0   submit tiled->linear blit Xorg:   copy of linear buffer  The sequence of jobs would be:   drm_sched_job_run                       # GPU0, frame rendering   drm_sched_job_queue                     # GPU0, blit   drm_sched_job_done                      # GPU0, frame rendering   drm_sched_job_run                       # GPU0, blit   move linear buffer for GPU1 access      #   amdgpu_dma_buf_move_notify -> update pt # GPU0  It this point the blit job on GPU0 is still running and would likely produce a page fault.

CVE-2026-43338:

        In the Linux kernel, the following vulnerability has been resolved:  btrfs: reserve enough transaction items for qgroup ioctls  Currently our qgroup ioctls don't reserve any space, they just do a transaction join, which does not reserve any space, neither for the quota tree updates nor for the delayed refs generated when updating the quota tree. The quota root uses the global block reserve, which is fine most of the time since we don't expect a lot of updates to the quota root, or to be too close to -ENOSPC such that other critical metadata updates need to resort to the global reserve.  However this is not optimal, as not reserving proper space may result in a transaction abort due to not reserving space for delayed refs and then abusing the use of the global block reserve.  For example, the following reproducer (which is unlikely to model any real world use case, but just to illustrate the problem), triggers such a transaction abort due to -ENOSPC when running delayed refs:    $ cat test.sh   #!/bin/bash    DEV=/dev/nullb0   MNT=/mnt/nullb0    umount $DEV &> /dev/null   # Limit device to 1G so that it's much faster to reproduce the issue.   mkfs.btrfs -f -b 1G $DEV   mount -o commit=600 $DEV $MNT    fallocate -l 800M $MNT/filler   btrfs quota enable $MNT    for ((i = 1; i <= 400000; i++)); do       btrfs qgroup create 1/$i $MNT   done    umount $MNT  When running this, we can see in dmesg/syslog that a transaction abort happened:    [436.490] BTRFS error (device nullb0): failed to run delayed ref for logical 30408704 num_bytes 16384 type 176 action 1 ref_mod 1: -28   [436.493] ------------[ cut here ]------------   [436.494] BTRFS: Transaction aborted (error -28)   [436.495] WARNING: fs/btrfs/extent-tree.c:2247 at btrfs_run_delayed_refs+0xd9/0x110 [btrfs], CPU#4: umount/2495372   [436.497] Modules linked in: btrfs loop (...)   [436.508] CPU: 4 UID: 0 PID: 2495372 Comm: umount Tainted: G        W           6.19.0-rc8-btrfs-next-225+ #1 PREEMPT(full)   [436.510] Tainted: [W]=WARN   [436.511] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014   [436.513] RIP: 0010:btrfs_run_delayed_refs+0xdf/0x110 [btrfs]   [436.514] Code: 0f 82 ea (...)   [436.518] RSP: 0018:ffffd511850b7d78 EFLAGS: 00010292   [436.519] RAX: 00000000ffffffe4 RBX: ffff8f120dad37e0 RCX: 0000000002040001   [436.520] RDX: 0000000000000002 RSI: 00000000ffffffe4 RDI: ffffffffc090fd80   [436.522] RBP: 0000000000000000 R08: 0000000000000001 R09: ffffffffc04d1867   [436.523] R10: ffff8f18dc1fffa8 R11: 0000000000000003 R12: ffff8f173aa89400   [436.524] R13: 0000000000000000 R14: ffff8f173aa89400 R15: 0000000000000000   [436.526] FS:  00007fe59045d840(0000) GS:ffff8f192e22e000(0000) knlGS:0000000000000000   [436.527] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033   [436.528] CR2: 00007fe5905ff2b0 CR3: 000000060710a002 CR4: 0000000000370ef0   [436.530] Call Trace:   [436.530]  <TASK>   [436.530]  btrfs_commit_transaction+0x73/0xc00 [btrfs]   [436.531]  ? btrfs_attach_transaction_barrier+0x1e/0x70 [btrfs]   [436.532]  sync_filesystem+0x7a/0x90   [436.533]  generic_shutdown_super+0x28/0x180   [436.533]  kill_anon_super+0x12/0x40   [436.534]  btrfs_kill_super+0x12/0x20 [btrfs]   [436.534]  deactivate_locked_super+0x2f/0xb0   [436.534]  cleanup_mnt+0xea/0x180   [436.535]  task_work_run+0x58/0xa0   [436.535]  exit_to_user_mode_loop+0xed/0x480   [436.536]  ? __x64_sys_umount+0x68/0x80   [436.536]  do_syscall_64+0x2a5/0xf20   [436.537]  entry_SYSCALL_64_after_hwframe+0x76/0x7e   [436.537] RIP: 0033:0x7fe5906b6217   [436.538] Code: 0d 00 f7 (...)   [436.540] RSP: 002b:00007ffcd87a61f8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6   [436.541] RAX: 0000000000000000 RBX: 00005618b9ecadc8 RCX: 00007fe5906b6217   [436.541] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00005618b9ecb100   [436.542] RBP: 0000000000000000 R08: 00007ffcd87a4fe0 R09: 00000000ffffffff   [436.544] R10: 0000000000000103 R11:  ---truncated---

CVE-2026-43344:

        In the Linux kernel, the following vulnerability has been resolved:  perf/x86/intel/uncore: Fix die ID init and look up bugs  In snbep_pci2phy_map_init(), in the nr_node_ids > 8 path, uncore_device_to_die() may return -1 when all CPUs associated with the UBOX device are offline.  Remove the WARN_ON_ONCE(die_id == -1) check for two reasons:  - The current code breaks out of the loop. This is incorrect because   pci_get_device() does not guarantee iteration in domain or bus order,   so additional UBOX devices may be skipped during the scan.  - Returning -EINVAL is incorrect, since marking offline buses with   die_id == -1 is expected and should not be treated as an error.  Separately, when NUMA is disabled on a NUMA-capable platform, pcibus_to_node() returns NUMA_NO_NODE, causing uncore_device_to_die() to return -1 for all PCI devices.  As a result, spr_update_device_location(), used on Intel SPR and EMR, ignores the corresponding PMON units and does not add them to the RB tree.  Fix this by using uncore_pcibus_to_dieid(), which retrieves topology from the UBOX GIDNIDMAP register and works regardless of whether NUMA is enabled in Linux.  This requires snbep_pci2phy_map_init() to be added in spr_uncore_pci_init().  Keep uncore_device_to_die() only for the nr_node_ids > 8 case, where NUMA is expected to be enabled.

CVE-2026-43352:

        In the Linux kernel, the following vulnerability has been resolved:  i3c: mipi-i3c-hci: Correct RING_CTRL_ABORT handling in DMA dequeue  The logic used to abort the DMA ring contains several flaws:   1. The driver unconditionally issues a ring abort even when the ring has     already stopped.  2. The completion used to wait for abort completion is never     re-initialized, resulting in incorrect wait behavior.  3. The abort sequence unintentionally clears RING_CTRL_ENABLE, which     resets hardware ring pointers and disrupts the controller state.  4. If the ring is already stopped, the abort operation should be     considered successful without attempting further action.  Fix the abort handling by checking whether the ring is running before issuing an abort, re-initializing the completion when needed, ensuring that RING_CTRL_ENABLE remains asserted during abort, and treating an already stopped ring as a successful condition.

CVE-2026-43353:

        In the Linux kernel, the following vulnerability has been resolved:  i3c: mipi-i3c-hci: Fix race in DMA ring dequeue  The HCI DMA dequeue path (hci_dma_dequeue_xfer()) may be invoked for multiple transfers that timeout around the same time.  However, the function is not serialized and can race with itself.  When a timeout occurs, hci_dma_dequeue_xfer() stops the ring, processes incomplete transfers, and then restarts the ring.  If another timeout triggers a parallel call into the same function, the two instances may interfere with each other - stopping or restarting the ring at unexpected times.  Add a mutex so that hci_dma_dequeue_xfer() is serialized with respect to itself.

CVE-2026-43362:

        In the Linux kernel, the following vulnerability has been resolved:  smb: client: fix in-place encryption corruption in SMB2_write()  SMB2_write() places write payload in iov[1..n] as part of rq_iov. smb3_init_transform_rq() pointer-shares rq_iov, so crypt_message() encrypts iov[1] in-place, replacing the original plaintext with ciphertext. On a replayable error, the retry sends the same iov[1] which now contains ciphertext instead of the original data, resulting in corruption.  The corruption is most likely to be observed when connections are unstable, as reconnects trigger write retries that re-send the already-encrypted data.  This affects SFU mknod, MF symlinks, etc. On kernels before 6.10 (prior to the netfs conversion), sync writes also used this path and were similarly affected. The async write path wasn't unaffected as it uses rq_iter which gets deep-copied.  Fix by moving the write payload into rq_iter via iov_iter_kvec(), so smb3_init_transform_rq() deep-copies it before encryption.

CVE-2026-43409:

        In the Linux kernel, the following vulnerability has been resolved:  kprobes: avoid crash when rmmod/insmod after ftrace killed  After we hit ftrace is killed by some errors, the kernel crash if we remove modules in which kprobe probes.  BUG: unable to handle page fault for address: fffffbfff805000d PGD 817fcc067 P4D 817fcc067 PUD 817fc8067 PMD 101555067 PTE 0 Oops: Oops: 0000 [#1] SMP KASAN PTI CPU: 4 UID: 0 PID: 2012 Comm: rmmod Tainted: G        W  OE Tainted: [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE RIP: 0010:kprobes_module_callback+0x89/0x790 RSP: 0018:ffff88812e157d30 EFLAGS: 00010a02 RAX: 1ffffffff805000d RBX: dffffc0000000000 RCX: ffffffff86a8de90 RDX: ffffed1025c2af9b RSI: 0000000000000008 RDI: ffffffffc0280068 RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed1025c2af9a R10: ffff88812e157cd7 R11: 205d323130325420 R12: 0000000000000002 R13: ffffffffc0290488 R14: 0000000000000002 R15: ffffffffc0280040 FS:  00007fbc450dd740(0000) GS:ffff888420331000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: fffffbfff805000d CR3: 000000010f624000 CR4: 00000000000006f0 Call Trace:  <TASK>  notifier_call_chain+0xc6/0x280  blocking_notifier_call_chain+0x60/0x90  __do_sys_delete_module.constprop.0+0x32a/0x4e0  do_syscall_64+0x5d/0xfa0  entry_SYSCALL_64_after_hwframe+0x76/0x7e  This is because the kprobe on ftrace does not correctly handles the kprobe_ftrace_disabled flag set by ftrace_kill().  To prevent this error, check kprobe_ftrace_disabled in __disarm_kprobe_ftrace() and skip all ftrace related operations.

CVE-2026-43413:

        In the Linux kernel, the following vulnerability has been resolved:  scsi: hisi_sas: Fix NULL pointer exception during user_scan()  user_scan() invokes updated sas_user_scan() for channel 0, and if successful, iteratively scans remaining channels (1 to shost->max_channel) via scsi_scan_host_selected() in commit 37c4e72b0651 ("scsi: Fix sas_user_scan() to handle wildcard and multi-channel scans"). However, hisi_sas supports only one channel, and the current value of max_channel is 1. sas_user_scan() for channel 1 will trigger the following NULL pointer exception:  [  441.554662] Unable to handle kernel NULL pointer dereference at virtual address 00000000000008b0 [  441.554699] Mem abort info: [  441.554710]   ESR = 0x0000000096000004 [  441.554718]   EC = 0x25: DABT (current EL), IL = 32 bits [  441.554723]   SET = 0, FnV = 0 [  441.554726]   EA = 0, S1PTW = 0 [  441.554730]   FSC = 0x04: level 0 translation fault [  441.554735] Data abort info: [  441.554737]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [  441.554742]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [  441.554747]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [  441.554752] user pgtable: 4k pages, 48-bit VAs, pgdp=00000828377a6000 [  441.554757] [00000000000008b0] pgd=0000000000000000, p4d=0000000000000000 [  441.554769] Internal error: Oops: 0000000096000004 [#1]  SMP [  441.629589] Modules linked in: arm_spe_pmu arm_smmuv3_pmu tpm_tis_spi hisi_uncore_sllc_pmu hisi_uncore_pa_pmu hisi_uncore_l3c_pmu hisi_uncore_hha_pmu hisi_uncore_ddrc_pmu hisi_uncore_cpa_pmu hns3_pmu hisi_ptt hisi_pcie_pmu tpm_tis_core spidev spi_hisi_sfc_v3xx hisi_uncore_pmu spi_dw_mmio fuse hclge hclge_common hisi_sec2 hisi_hpre hisi_zip hisi_qm hns3 hisi_sas_v3_hw sm3_ce sbsa_gwdt hnae3 hisi_sas_main uacce hisi_dma i2c_hisi dm_mirror dm_region_hash dm_log dm_mod [  441.670819] CPU: 46 UID: 0 PID: 6994 Comm: bash Kdump: loaded Not tainted 7.0.0-rc2+ #84 PREEMPT [  441.691327] pstate: 81400009 (Nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [  441.698277] pc : sas_find_dev_by_rphy+0x44/0x118 [  441.702896] lr : sas_find_dev_by_rphy+0x3c/0x118 [  441.707502] sp : ffff80009abbba40 [  441.710805] x29: ffff80009abbba40 x28: ffff082819a40008 x27: ffff082810c37c08 [  441.717930] x26: ffff082810c37c28 x25: ffff082819a40290 x24: ffff082810c37c00 [  441.725054] x23: 0000000000000000 x22: 0000000000000001 x21: ffff082819a40000 [  441.732179] x20: ffff082819a40290 x19: 0000000000000000 x18: 0000000000000020 [  441.739304] x17: 0000000000000000 x16: ffffb5dad6bda690 x15: 00000000ffffffff [  441.746428] x14: ffff082814c3b26c x13: 00000000ffffffff x12: ffff082814c3b26a [  441.753553] x11: 00000000000000c0 x10: 000000000000003a x9 : ffffb5dad5ea94f4 [  441.760678] x8 : 000000000000003a x7 : ffff80009abbbab0 x6 : 0000000000000030 [  441.767802] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [  441.774926] x2 : ffff08280f35a300 x1 : ffffb5dad7127180 x0 : 0000000000000000 [  441.782053] Call trace: [  441.784488]  sas_find_dev_by_rphy+0x44/0x118 (P) [  441.789095]  sas_target_alloc+0x24/0xb0 [  441.792920]  scsi_alloc_target+0x290/0x330 [  441.797010]  __scsi_scan_target+0x88/0x258 [  441.801096]  scsi_scan_channel+0x74/0xb8 [  441.805008]  scsi_scan_host_selected+0x170/0x188 [  441.809615]  sas_user_scan+0xfc/0x148 [  441.813267]  store_scan+0x10c/0x180 [  441.816743]  dev_attr_store+0x20/0x40 [  441.820398]  sysfs_kf_write+0x84/0xa8 [  441.824054]  kernfs_fop_write_iter+0x130/0x1c8 [  441.828487]  vfs_write+0x2c0/0x370 [  441.831880]  ksys_write+0x74/0x118 [  441.835271]  __arm64_sys_write+0x24/0x38 [  441.839182]  invoke_syscall+0x50/0x120 [  441.842919]  el0_svc_common.constprop.0+0xc8/0xf0 [  441.847611]  do_el0_svc+0x24/0x38 [  441.850913]  el0_svc+0x38/0x158 [  441.854043]  el0t_64_sync_handler+0xa0/0xe8 [  441.858214]  el0t_64_sync+0x1ac/0x1b0 [  441.861865] Code: aa1303e0 97ff70a8 34ffff80 d10a4273 (f9445a75) [  441.867946] ---[ end trace 0000000000000000 ]---  Therefore ---truncated---

CVE-2026-43414:

        In the Linux kernel, the following vulnerability has been resolved:  scsi: qla2xxx: Completely fix fcport double free  In qla24xx_els_dcmd_iocb() sp->free is set to qla2x00_els_dcmd_sp_free(). When an error happens, this function is called by qla2x00_sp_release(), when kref_put() releases the first and the last reference.  qla2x00_els_dcmd_sp_free() frees fcport by calling qla2x00_free_fcport(). Doing it one more time after kref_put() is a bad idea.

CVE-2026-43416:

        In the Linux kernel, the following vulnerability has been resolved:  powerpc, perf: Check that current->mm is alive before getting user callchain  It may happen that mm is already released, which leads to kernel panic. This adds the NULL check for current->mm, similarly to commit 20afc60f892d ("x86, perf: Check that current->mm is alive before getting user callchain").  I was getting this panic when running a profiling BPF program (profile.py from bcc-tools):      [26215.051935] Kernel attempted to read user page (588) - exploit attempt? (uid: 0)     [26215.051950] BUG: Kernel NULL pointer dereference on read at 0x00000588     [26215.051952] Faulting instruction address: 0xc00000000020fac0     [26215.051957] Oops: Kernel access of bad area, sig: 11 [#1]     [...]     [26215.052049] Call Trace:     [26215.052050] [c000000061da6d30] [c00000000020fc10] perf_callchain_user_64+0x2d0/0x490 (unreliable)     [26215.052054] [c000000061da6dc0] [c00000000020f92c] perf_callchain_user+0x1c/0x30     [26215.052057] [c000000061da6de0] [c0000000005ab2a0] get_perf_callchain+0x100/0x360     [26215.052063] [c000000061da6e70] [c000000000573bc8] bpf_get_stackid+0x88/0xf0     [26215.052067] [c000000061da6ea0] [c008000000042258] bpf_prog_16d4ab9ab662f669_do_perf_event+0xf8/0x274     [...]  In addition, move storing the top-level stack entry to generic perf_callchain_user to make sure the top-evel entry is always captured, even if current->mm is NULL.  [Maddy: fixed message to avoid checkpatch format style error]

CVE-2026-43419:

        In the Linux kernel, the following vulnerability has been resolved:  ceph: fix memory leaks in ceph_mdsc_build_path()  Add __putname() calls to error code paths that did not free the "path" pointer obtained by __getname().  If ownership of this pointer is not passed to the caller via path_info.path, the function must free it before returning.

CVE-2026-43443:

        In the Linux kernel, the following vulnerability has been resolved:  ASoC: amd: acp-mach-common: Add missing error check for clock acquisition  The acp_card_rt5682_init() and acp_card_rt5682s_init() functions did not check the return values of clk_get(). This could lead to a kernel crash when the invalid pointers are later dereferenced by clock core functions.  Fix this by: 1. Changing clk_get() to the device-managed devm_clk_get(). 2. Adding IS_ERR() checks immediately after each clock acquisition.

CVE-2026-43456:

        In the Linux kernel, the following vulnerability has been resolved:  bonding: fix type confusion in bond_setup_by_slave()  kernel BUG at net/core/skbuff.c:2306! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI RIP: 0010:pskb_expand_head+0xa08/0xfe0 net/core/skbuff.c:2306 RSP: 0018:ffffc90004aff760 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff88807e3c8780 RCX: ffffffff89593e0e RDX: ffff88807b7c4900 RSI: ffffffff89594747 RDI: ffff88807b7c4900 RBP: 0000000000000820 R08: 0000000000000005 R09: 0000000000000000 R10: 00000000961a63e0 R11: 0000000000000000 R12: ffff88807e3c8780 R13: 00000000961a6560 R14: dffffc0000000000 R15: 00000000961a63e0 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fe1a0ed8df0 CR3: 000000002d816000 CR4: 00000000003526f0 Call Trace:  <TASK>  ipgre_header+0xdd/0x540 net/ipv4/ip_gre.c:900  dev_hard_header include/linux/netdevice.h:3439 [inline]  packet_snd net/packet/af_packet.c:3028 [inline]  packet_sendmsg+0x3ae5/0x53c0 net/packet/af_packet.c:3108  sock_sendmsg_nosec net/socket.c:727 [inline]  __sock_sendmsg net/socket.c:742 [inline]  ____sys_sendmsg+0xa54/0xc30 net/socket.c:2592  ___sys_sendmsg+0x190/0x1e0 net/socket.c:2646  __sys_sendmsg+0x170/0x220 net/socket.c:2678  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]  do_syscall_64+0x106/0xf80 arch/x86/entry/syscall_64.c:94  entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fe1a0e6c1a9  When a non-Ethernet device (e.g. GRE tunnel) is enslaved to a bond, bond_setup_by_slave() directly copies the slave's header_ops to the bond device:      bond_dev->header_ops = slave_dev->header_ops;  This causes a type confusion when dev_hard_header() is later called on the bond device. Functions like ipgre_header(), ip6gre_header(),all use netdev_priv(dev) to access their device-specific private data. When called with the bond device, netdev_priv() returns the bond's private data (struct bonding) instead of the expected type (e.g. struct ip_tunnel), leading to garbage values being read and kernel crashes.  Fix this by introducing bond_header_ops with wrapper functions that delegate to the active slave's header_ops using the slave's own device. This ensures netdev_priv() in the slave's header functions always receives the correct device.  The fix is placed in the bonding driver rather than individual device drivers, as the root cause is bond blindly inheriting header_ops from the slave without considering that these callbacks expect a specific netdev_priv() layout.  The type confusion can be observed by adding a printk in ipgre_header() and running the following commands:      ip link add dummy0 type dummy     ip addr add 10.0.0.1/24 dev dummy0     ip link set dummy0 up     ip link add gre1 type gre local 10.0.0.1     ip link add bond1 type bond mode active-backup     ip link set gre1 master bond1     ip link set gre1 up     ip link set bond1 up     ip addr add fe80::1/64 dev bond1

CVE-2026-43490:

        In the Linux kernel, the following vulnerability has been resolved:  ksmbd: validate inherited ACE SID length  smb_inherit_dacl() walks the parent directory DACL loaded from the security descriptor xattr. It verifies that each ACE contains the fixed SID header before using it, but does not verify that the variable-length SID described by sid.num_subauth is fully contained in the ACE.  A malformed inheritable ACE can advertise more subauthorities than are present in the ACE. compare_sids() may then read past the ACE. smb_set_ace() also clamps the copied destination SID, but used the unchecked source SID count to compute the inherited ACE size. That could advance the temporary inherited ACE buffer pointer and nt_size accounting past the allocated buffer.  Fix this by validating the parent ACE SID count and SID length before using the SID during inheritance. Compute the inherited ACE size from the copied SID so the size matches the bounded destination SID. Reject the inherited DACL if size accumulation would overflow smb_acl.size or the security descriptor allocation size.

CVE-2026-45855:

        In the Linux kernel, the following vulnerability has been resolved:  ata: libata-scsi: avoid Non-NCQ command starvation  When a non-NCQ command is issued while NCQ commands are being executed, ata_scsi_qc_issue() indicates to the SCSI layer that the command issuing should be deferred by returning SCSI_MLQUEUE_XXX_BUSY.  This command deferring is correct and as mandated by the ACS specifications since NCQ and non-NCQ commands cannot be mixed.  However, in the case of a host adapter using multiple submission queues, when the target device is under a constant load of NCQ commands, there are no guarantees that requeueing the non-NCQ command will be executed later and it may be deferred again repeatedly as other submission queues can constantly issue NCQ commands from different CPUs ahead of the non-NCQ command. This can lead to very long delays for the execution of non-NCQ commands, and even complete starvation for these commands in the worst case scenario.  Since the block layer and the SCSI layer do not distinguish between queueable (NCQ) and non queueable (non-NCQ) commands, libata-scsi SAT implementation must ensure forward progress for non-NCQ commands in the presence of NCQ command traffic. This is similar to what SAS HBAs with a hardware/firmware based SAT implementation do.  Implement such forward progress guarantee by limiting requeueing of non-NCQ commands from ata_scsi_qc_issue(): when a non-NCQ command is received and NCQ commands are in-flight, do not force a requeue of the non-NCQ command by returning SCSI_MLQUEUE_XXX_BUSY and instead return 0 to indicate that the command was accepted but hold on to the qc using the new deferred_qc field of struct ata_port.  This deferred qc will be issued using the work item deferred_qc_work running the function ata_scsi_deferred_qc_work() once all in-flight commands complete, which is checked with the port qc_defer() callback return value indicating that no further delay is necessary. This check is done using the helper function ata_scsi_schedule_deferred_qc() which is called from ata_scsi_qc_complete(). This thus excludes this mechanism from all internal non-NCQ commands issued by ATA EH.  When a port deferred_qc is non NULL, that is, the port has a command waiting for the device queue to drain, the issuing of all incoming commands (both NCQ and non-NCQ) is deferred using the regular busy mechanism. This simplifies the code and also avoids potential denial of service problems if a user issues too many non-NCQ commands.  Finally, whenever ata EH is scheduled, regardless of the reason, a deferred qc is always requeued so that it can be retried once EH completes. This is done by calling the function ata_scsi_requeue_deferred_qc() from ata_eh_set_pending(). This avoids the need for any special processing for the deferred qc in case of NCQ error, link or device reset, or device timeout.

CVE-2026-45858:

        In the Linux kernel, the following vulnerability has been resolved:  ext4: don't zero the entire extent if EXT4_EXT_DATA_PARTIAL_VALID1  When allocating initialized blocks from a large unwritten extent, or when splitting an unwritten extent during end I/O and converting it to initialized, there is currently a potential issue of stale data if the extent needs to be split in the middle.         0  A      B  N        [UUUUUUUUUUUU]    U: unwritten extent        [--DDDDDDDD--]    D: valid data           |<-  ->| ----> this range needs to be initialized  ext4_split_extent() first try to split this extent at B with EXT4_EXT_DATA_ENTIRE_VALID1 and EXT4_EXT_MAY_ZEROOUT flag set, but ext4_split_extent_at() failed to split this extent due to temporary lack of space. It zeroout B to N and mark the entire extent from 0 to N as written.         0  A      B  N        [WWWWWWWWWWWW]    W: written extent        [SSDDDDDDDDZZ]    Z: zeroed, S: stale data  ext4_split_extent() then try to split this extent at A with EXT4_EXT_DATA_VALID2 flag set. This time, it split successfully and left a stale written extent from 0 to A.         0  A      B   N        [WW|WWWWWWWWWW]        [SS|DDDDDDDDZZ]  Fix this by pass EXT4_EXT_DATA_PARTIAL_VALID1 to ext4_split_extent_at() when splitting at B, don't convert the entire extent to written and left it as unwritten after zeroing out B to N. The remaining work is just like the standard two-part split. ext4_split_extent() will pass the EXT4_EXT_DATA_VALID2 flag when it calls ext4_split_extent_at() for the second time, allowing it to properly handle the split. If the split is successful, it will keep extent from 0 to A as unwritten.

CVE-2026-45859:

        In the Linux kernel, the following vulnerability has been resolved:  netfilter: nfnetlink_queue: do shared-unconfirmed check before segmentation  Ulrich reports a regression with nfqueue:  If an application did not set the 'F_GSO' capability flag and a gso packet with an unconfirmed nf_conn entry is received all packets are now dropped instead of queued, because the check happens after skb_gso_segment().  In that case, we did have exclusive ownership of the skb and its associated conntrack entry.  The elevated use count is due to skb_clone happening via skb_gso_segment().  Move the check so that its peformed vs. the aggregated packet.  Then, annotate the individual segments except the first one so we can do a 2nd check at reinject time.  For the normal case, where userspace does in-order reinjects, this avoids packet drops: first reinjected segment continues traversal and confirms entry, remaining segments observe the confirmed entry.  While at it, simplify nf_ct_drop_unconfirmed(): We only care about unconfirmed entries with a refcnt > 1, there is no need to special-case dying entries.  This only happens with UDP.  With TCP, the only unconfirmed packet will be the TCP SYN, those aren't aggregated by GRO.  Next patch adds a udpgro test case to cover this scenario.

CVE-2026-45877:

        In the Linux kernel, the following vulnerability has been resolved:  HID: intel-ish-hid: fix NULL-ptr-deref in ishtp_bus_remove_all_clients  During a warm reset flow, the cl->device pointer may be NULL if the reset occurs while clients are still being enumerated. Accessing cl->device->reference_count without a NULL check leads to a kernel panic.  This issue was identified during multi-unit warm reboot stress clycles. Add a defensive NULL check for cl->device to ensure stability under such intensive testing conditions.  KASAN: null-ptr-deref in range [0000000000000000-0000000000000007] Workqueue: ish_fw_update_wq fw_reset_work_fn  Call Trace:  ishtp_bus_remove_all_clients+0xbe/0x130 [intel_ishtp]  ishtp_reset_handler+0x85/0x1a0 [intel_ishtp]  fw_reset_work_fn+0x8a/0xc0 [intel_ish_ipc]

CVE-2026-45892:

        In the Linux kernel, the following vulnerability has been resolved:  ext4: drop extent cache after doing PARTIAL_VALID1 zeroout  When splitting an unwritten extent in the middle and converting it to initialized in ext4_split_extent() with the EXT4_EXT_MAY_ZEROOUT and EXT4_EXT_DATA_VALID2 flags set, it could leave a stale unwritten extent.  Assume we have an unwritten file and buffered write in the middle of it without dioread_nolock enabled, it will allocate blocks as written extent.         0  A      B  N        [UUUUUUUUUUUU] on-disk extent      U: unwritten extent        [UUUUUUUUUUUU] extent status tree        [--DDDDDDDD--]                     D: valid data           |<-  ->| ----> this range needs to be initialized  ext4_split_extent() first try to split this extent at B with EXT4_EXT_DATA_PARTIAL_VALID1 and EXT4_EXT_MAY_ZEROOUT flag set, but ext4_split_extent_at() failed to split this extent due to temporary lack of space. It zeroout B to N and leave the entire extent as unwritten.         0  A      B  N        [UUUUUUUUUUUU] on-disk extent        [UUUUUUUUUUUU] extent status tree        [--DDDDDDDDZZ]                     Z: zeroed data  ext4_split_extent() then try to split this extent at A with EXT4_EXT_DATA_VALID2 flag set. This time, it split successfully and leave an written extent from A to N.         0  A      B  N        [UUWWWWWWWWWW] on-disk extent      W: written extent        [UUUUUUUUUUUU] extent status tree        [--DDDDDDDDZZ]  Finally ext4_map_create_blocks() only insert extent A to B to the extent status tree, and leave an stale unwritten extent in the status tree.         0  A      B  N        [UUWWWWWWWWWW] on-disk extent      W: written extent        [UUWWWWWWWWUU] extent status tree        [--DDDDDDDDZZ]  Fix this issue by always cached extent status entry after zeroing out the second part.

CVE-2026-45893:

        In the Linux kernel, the following vulnerability has been resolved:  apparmor: Fix & Optimize table creation from possibly unaligned memory  Source blob may come from userspace and might be unaligned. Try to optize the copying process by avoiding unaligned memory accesses.  - Added Fixes tag - Added "Fix &" to description as this doesn't just optimize but fixes         a potential unaligned memory access [jj: remove duplicate word "convert" in comment trigger checkpatch warning]

CVE-2026-45894:

        In the Linux kernel, the following vulnerability has been resolved:  iommu/vt-d: Clear Present bit before tearing down PASID entry  The Intel VT-d Scalable Mode PASID table entry consists of 512 bits (64 bytes). When tearing down an entry, the current implementation zeros the entire 64-byte structure immediately using multiple 64-bit writes.  Since the IOMMU hardware may fetch these 64 bytes using multiple internal transactions (e.g., four 128-bit bursts), updating or zeroing the entire entry while it is active (P=1) risks a "torn" read. If a hardware fetch occurs simultaneously with the CPU zeroing the entry, the hardware could observe an inconsistent state, leading to unpredictable behavior or spurious faults.  Follow the "Guidance to Software for Invalidations" in the VT-d spec (Section 6.5.3.3) by implementing the recommended ownership handshake:  1. Clear only the 'Present' (P) bit of the PASID entry. 2. Use a dma_wmb() to ensure the cleared bit is visible to hardware    before proceeding. 3. Execute the required invalidation sequence (PASID cache, IOTLB, and    Device-TLB flush) to ensure the hardware has released all cached    references. 4. Only after the flushes are complete, zero out the remaining fields    of the PASID entry.  Also, add a dma_wmb() in pasid_set_present() to ensure that all other fields of the PASID entry are visible to the hardware before the Present bit is set.

CVE-2026-45899:

        In the Linux kernel, the following vulnerability has been resolved:  ext4: drop extent cache when splitting extent fails  When the split extent fails, we might leave some extents still being processed and return an error directly, which will result in stale extent entries remaining in the extent status tree. So drop all of the remaining potentially stale extents if the splitting fails.

CVE-2026-45901:

        In the Linux kernel, the following vulnerability has been resolved:  netfilter: nf_tables: revert commit_mutex usage in reset path  It causes circular lock dependency between commit_mutex, nfnl_subsys_ipset and nlk_cb_mutex when nft reset, ipset list, and iptables-nft with '-m set' rule run at the same time.  Previous patches made it safe to run individual reset handlers concurrently so commit_mutex is no longer required to prevent this.

CVE-2026-45917:

        In the Linux kernel, the following vulnerability has been resolved:  ipvs: do not keep dest_dst if dev is going down  There is race between the netdev notifier ip_vs_dst_event() and the code that caches dst with dev that is going down. As the FIB can be notified for the closed device after our handler finishes, it is possible valid route to be returned and cached resuling in a leaked dev reference until the dest is not removed.  To prevent new dest_dst to be attached to dest just after the handler dropped the old one, add a netif_running() check to make sure the notifier handler is not currently running for device that is closing.

CVE-2026-45934:

        In the Linux kernel, the following vulnerability has been resolved:  btrfs: fix EEXIST abort due to non-consecutive gaps in chunk allocation  I have been observing a number of systems aborting at insert_dev_extents() in btrfs_create_pending_block_groups(). The following is a sample stack trace of such an abort coming from forced chunk allocation (typically behind CONFIG_BTRFS_EXPERIMENTAL) but this can theoretically happen to any DUP chunk allocation.    [81.801] ------------[ cut here ]------------   [81.801] BTRFS: Transaction aborted (error -17)   [81.801] WARNING: fs/btrfs/block-group.c:2876 at btrfs_create_pending_block_groups+0x721/0x770 [btrfs], CPU#1: bash/319   [81.802] Modules linked in: virtio_net btrfs xor zstd_compress raid6_pq null_blk   [81.803] CPU: 1 UID: 0 PID: 319 Comm: bash Kdump: loaded Not tainted 6.19.0-rc6+ #319 NONE   [81.803] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014   [81.804] RIP: 0010:btrfs_create_pending_block_groups+0x723/0x770 [btrfs]   [81.806] RSP: 0018:ffffa36241a6bce8 EFLAGS: 00010282   [81.806] RAX: 000000000000000d RBX: ffff8e699921e400 RCX: 0000000000000000   [81.807] RDX: 0000000002040001 RSI: 00000000ffffffef RDI: ffffffffc0608bf0   [81.807] RBP: 00000000ffffffef R08: ffff8e69830f6000 R09: 0000000000000007   [81.808] R10: ffff8e699921e5e8 R11: 0000000000000000 R12: ffff8e6999228000   [81.808] R13: ffff8e6984d82000 R14: ffff8e69966a69c0 R15: ffff8e69aa47b000   [81.809] FS:  00007fec6bdd9740(0000) GS:ffff8e6b1b379000(0000) knlGS:0000000000000000   [81.809] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033   [81.810] CR2: 00005604833670f0 CR3: 0000000116679000 CR4: 00000000000006f0   [81.810] Call Trace:   [81.810]  <TASK>   [81.810]  __btrfs_end_transaction+0x3e/0x2b0 [btrfs]   [81.811]  btrfs_force_chunk_alloc_store+0xcd/0x140 [btrfs]   [81.811]  kernfs_fop_write_iter+0x15f/0x240   [81.812]  vfs_write+0x264/0x500   [81.812]  ksys_write+0x6c/0xe0   [81.812]  do_syscall_64+0x66/0x770   [81.812]  entry_SYSCALL_64_after_hwframe+0x76/0x7e   [81.813] RIP: 0033:0x7fec6be66197   [81.814] RSP: 002b:00007fffb159dd30 EFLAGS: 00000202 ORIG_RAX: 0000000000000001   [81.815] RAX: ffffffffffffffda RBX: 00007fec6bdd9740 RCX: 00007fec6be66197   [81.815] RDX: 0000000000000002 RSI: 0000560483374f80 RDI: 0000000000000001   [81.816] RBP: 0000560483374f80 R08: 0000000000000000 R09: 0000000000000000   [81.816] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000002   [81.817] R13: 00007fec6bfb85c0 R14: 00007fec6bfb5ee0 R15: 00005604833729c0   [81.817]  </TASK>   [81.817] irq event stamp: 20039   [81.818] hardirqs last  enabled at (20047): [<ffffffff99a68302>] __up_console_sem+0x52/0x60   [81.818] hardirqs last disabled at (20056): [<ffffffff99a682e7>] __up_console_sem+0x37/0x60   [81.819] softirqs last  enabled at (19470): [<ffffffff999d2b46>] __irq_exit_rcu+0x96/0xc0   [81.819] softirqs last disabled at (19463): [<ffffffff999d2b46>] __irq_exit_rcu+0x96/0xc0   [81.820] ---[ end trace 0000000000000000 ]---   [81.820] BTRFS: error (device dm-7 state A) in btrfs_create_pending_block_groups:2876: errno=-17 Object already exists  Inspecting these aborts with drgn, I observed a pattern of overlapping chunk_maps. Note how stripe 1 of the first chunk overlaps in physical address with stripe 0 of the second chunk.  Physical Start     Physical End       Length       Logical            Type                 Stripe ---------------------------------------------------------------------------------------------------- 0x0000000102500000 0x0000000142500000 1.0G         0x0000000641d00000 META|DUP             0/2 0x0000000142500000 0x0000000182500000 1.0G         0x0000000641d00000 META|DUP             1/2 0x0000000142500000 0x0000000182500000 1.0G         0x0000000601d00000 META|DUP             0/2 0x0000000182500000 0x00000001c2500000 1.0G         0x0000000601d00000 META|DUP             1/2  Now how could this possibly happen? All chunk allocation is ---truncated---

CVE-2026-45940:

        In the Linux kernel, the following vulnerability has been resolved:  net: stmmac: fix oops when split header is enabled  For GMAC4, when split header is enabled, in some rare cases, the hardware does not fill buf2 of the first descriptor with payload. Thus we cannot assume buf2 is always fully filled if it is not the last descriptor. Otherwise, the length of buf2 of the second descriptor will be calculated wrong and cause an oops:  Unable to handle kernel paging request at virtual address ffff00019246bfc0 ... x2 : 0000000000000040 x1 : ffff00019246bfc0 x0 : ffff00009246c000 Call trace:  dcache_inval_poc+0x28/0x58 (P)  dma_direct_sync_single_for_cpu+0x38/0x6c  __dma_sync_single_for_cpu+0x34/0x6c  stmmac_napi_poll_rx+0x8f0/0xb60  __napi_poll.constprop.0+0x30/0x144  net_rx_action+0x160/0x274  handle_softirqs+0x1b8/0x1fc ...  To fix this, the PL bit-field in RDES3 register is used for all descriptors, whether it is the last descriptor or not.

CVE-2026-45942:

        In the Linux kernel, the following vulnerability has been resolved:  ext4: fix e4b bitmap inconsistency reports  A bitmap inconsistency issue was observed during stress tests under mixed huge-page workloads. Ext4 reported multiple e4b bitmap check failures like:  ext4_mb_complex_scan_group:2508: group 350, 8179 free clusters as per group info. But got 8192 blocks  Analysis and experimentation confirmed that the issue is caused by a race condition between page migration and bitmap modification. Although this timing window is extremely narrow, it is still hit in practice:  folio_lock                        ext4_mb_load_buddy __migrate_folio   check ref count   folio_mc_copy                     __filemap_get_folio                                       folio_try_get(folio)                                   ......                                   mb_mark_used                                   ext4_mb_unload_buddy   __folio_migrate_mapping     folio_ref_freeze folio_unlock  The root cause of this issue is that the fast path of load_buddy only increments the folio's reference count, which is insufficient to prevent concurrent folio migration. We observed that the folio migration process acquires the folio lock. Therefore, we can determine whether to take the fast path in load_buddy by checking the lock status. If the folio is locked, we opt for the slow path (which acquires the lock) to close this concurrency window.  Additionally, this change addresses the following issues:  When the DOUBLE_CHECK macro is enabled to inspect bitmap-related issues, the following error may be triggered:  corruption in group 324 at byte 784(6272): f in copy != ff on disk/prealloc  Analysis reveals that this is a false positive. There is a specific race window where the bitmap and the group descriptor become momentarily inconsistent, leading to this error report:  ext4_mb_load_buddy                   ext4_mb_load_buddy   __filemap_get_folio(create|lock)     folio_lock   ext4_mb_init_cache     folio_mark_uptodate                                      __filemap_get_folio(no lock)                                      ......                                      mb_mark_used                                        mb_mark_used_double   mb_cmp_bitmaps                                        mb_set_bits(e4b->bd_bitmap)   folio_unlock  The original logic assumed that since mb_cmp_bitmaps is called when the bitmap is newly loaded from disk, the folio lock would be sufficient to prevent concurrent access. However, this overlooks a specific race condition: if another process attempts to load buddy and finds the folio is already in an uptodate state, it will immediately begin using it without holding folio lock.

CVE-2026-45943:

        In the Linux kernel, the following vulnerability has been resolved:  erofs: fix inline data read failure for ztailpacking pclusters  Compressed folios for ztailpacking pclusters must be valid before adding these pclusters to I/O chains. Otherwise, z_erofs_decompress_pcluster() may assume they are already valid and then trigger a NULL pointer dereference.  It is somewhat hard to reproduce because the inline data is in the same block as the tail of the compressed indexes, which are usually read just before. However, it may still happen if a fatal signal arrives while read_mapping_folio() is running, as shown below:   erofs: (device dm-1): z_erofs_pcluster_begin: failed to get inline data -4  Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008   ...   pc : z_erofs_decompress_queue+0x4c8/0xa14  lr : z_erofs_decompress_queue+0x160/0xa14  sp : ffffffc08b3eb3a0  x29: ffffffc08b3eb570 x28: ffffffc08b3eb418 x27: 0000000000001000  x26: ffffff8086ebdbb8 x25: ffffff8086ebdbb8 x24: 0000000000000001  x23: 0000000000000008 x22: 00000000fffffffb x21: dead000000000700  x20: 00000000000015e7 x19: ffffff808babb400 x18: ffffffc089edc098  x17: 00000000c006287d x16: 00000000c006287d x15: 0000000000000004  x14: ffffff80ba8f8000 x13: 0000000000000004 x12: 00000006589a77c9  x11: 0000000000000015 x10: 0000000000000000 x9 : 0000000000000000  x8 : 0000000000000000 x7 : 0000000000000000 x6 : 000000000000003f  x5 : 0000000000000040 x4 : ffffffffffffffe0 x3 : 0000000000000020  x2 : 0000000000000008 x1 : 0000000000000000 x0 : 0000000000000000  Call trace:   z_erofs_decompress_queue+0x4c8/0xa14   z_erofs_runqueue+0x908/0x97c   z_erofs_read_folio+0x128/0x228   filemap_read_folio+0x68/0x128   filemap_get_pages+0x44c/0x8b4   filemap_read+0x12c/0x5b8   generic_file_read_iter+0x4c/0x15c   do_iter_readv_writev+0x188/0x1e0   vfs_iter_read+0xac/0x1a4   backing_file_read_iter+0x170/0x34c   ovl_read_iter+0xf0/0x140   vfs_read+0x28c/0x344   ksys_read+0x80/0xf0   __arm64_sys_read+0x24/0x34   invoke_syscall+0x60/0x114   el0_svc_common+0x88/0xe4   do_el0_svc+0x24/0x30   el0_svc+0x40/0xa8   el0t_64_sync_handler+0x70/0xbc   el0t_64_sync+0x1bc/0x1c0  Fix this by reading the inline data before allocating and adding the pclusters to the I/O chains.

CVE-2026-45944:

        In the Linux kernel, the following vulnerability has been resolved:  iommu/vt-d: Clear Present bit before tearing down context entry  When tearing down a context entry, the current implementation zeros the entire 128-bit entry using multiple 64-bit writes. This creates a window where the hardware can fetch a "torn" entry — where some fields are already zeroed while the 'Present' bit is still set — leading to unpredictable behavior or spurious faults.  While x86 provides strong write ordering, the compiler may reorder writes to the two 64-bit halves of the context entry. Even without compiler reordering, the hardware fetch is not guaranteed to be atomic with respect to multiple CPU writes.  Align with the "Guidance to Software for Invalidations" in the VT-d spec (Section 6.5.3.3) by implementing the recommended ownership handshake:  1. Clear only the 'Present' (P) bit of the context entry first to    signal the transition of ownership from hardware to software. 2. Use dma_wmb() to ensure the cleared bit is visible to the IOMMU. 3. Perform the required cache and context-cache invalidation to ensure    hardware no longer has cached references to the entry. 4. Fully zero out the entry only after the invalidation is complete.  Also, add a dma_wmb() to context_set_present() to ensure the entry is fully initialized before the 'Present' bit becomes visible.

CVE-2026-45949:

        In the Linux kernel, the following vulnerability has been resolved:  hwrng: core - use RCU and work_struct to fix race condition  Currently, hwrng_fill is not cleared until the hwrng_fillfn() thread exits. Since hwrng_unregister() reads hwrng_fill outside the rng_mutex lock, a concurrent hwrng_unregister() may call kthread_stop() again on the same task.  Additionally, if hwrng_unregister() is called immediately after hwrng_register(), the stopped thread may have never been executed. Thus, hwrng_fill remains dirty even after hwrng_unregister() returns. In this case, subsequent calls to hwrng_register() will fail to start new threads, and hwrng_unregister() will call kthread_stop() on the same freed task. In both cases, a use-after-free occurs:  refcount_t: addition on 0; use-after-free. WARNING: ... at lib/refcount.c:25 refcount_warn_saturate+0xec/0x1c0 Call Trace:  kthread_stop+0x181/0x360  hwrng_unregister+0x288/0x380  virtrng_remove+0xe3/0x200  This patch fixes the race by protecting the global hwrng_fill pointer inside the rng_mutex lock, so that hwrng_fillfn() thread is stopped only once, and calls to kthread_run() and kthread_stop() are serialized with the lock held.  To avoid deadlock in hwrng_fillfn() while being stopped with the lock held, we convert current_rng to RCU, so that get_current_rng() can read current_rng without holding the lock. To remove the lock from put_rng(), we also delay the actual cleanup into a work_struct.  Since get_current_rng() no longer returns ERR_PTR values, the IS_ERR() checks are removed from its callers.  With hwrng_fill protected by the rng_mutex lock, hwrng_fillfn() can no longer clear hwrng_fill itself. Therefore, if hwrng_fillfn() returns directly after current_rng is dropped, kthread_stop() would be called on a freed task_struct later. To fix this, hwrng_fillfn() calls schedule() now to keep the task alive until being stopped. The kthread_stop() call is also moved from hwrng_unregister() to drop_current_rng(), ensuring kthread_stop() is called on all possible paths where current_rng becomes NULL, so that the thread would not wait forever.

CVE-2026-45957:

        In the Linux kernel, the following vulnerability has been resolved:  rcu: Fix rcu_read_unlock() deadloop due to softirq  Commit 5f5fa7ea89dc ("rcu: Don't use negative nesting depth in __rcu_read_unlock()") removes the recursion-protection code from __rcu_read_unlock(). Therefore, we could invoke the deadloop in raise_softirq_irqoff() with ftrace enabled as follows:  WARNING: CPU: 0 PID: 0 at kernel/trace/trace.c:3021 __ftrace_trace_stack.constprop.0+0x172/0x180 Modules linked in: my_irq_work(O) CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G O 6.18.0-rc7-dirty #23 PREEMPT(full) Tainted: [O]=OOT_MODULE Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:__ftrace_trace_stack.constprop.0+0x172/0x180 RSP: 0018:ffffc900000034a8 EFLAGS: 00010002 RAX: 0000000000000000 RBX: 0000000000000004 RCX: 0000000000000000 RDX: 0000000000000003 RSI: ffffffff826d7b87 RDI: ffffffff826e9329 RBP: 0000000000090009 R08: 0000000000000005 R09: ffffffff82afbc4c R10: 0000000000000008 R11: 0000000000011d7a R12: 0000000000000000 R13: ffff888003874100 R14: 0000000000000003 R15: ffff8880038c1054 FS:  0000000000000000(0000) GS:ffff8880fa8ea000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055b31fa7f540 CR3: 00000000078f4005 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace:  <IRQ>  trace_buffer_unlock_commit_regs+0x6d/0x220  trace_event_buffer_commit+0x5c/0x260  trace_event_raw_event_softirq+0x47/0x80  raise_softirq_irqoff+0x6e/0xa0  rcu_read_unlock_special+0xb1/0x160  unwind_next_frame+0x203/0x9b0  __unwind_start+0x15d/0x1c0  arch_stack_walk+0x62/0xf0  stack_trace_save+0x48/0x70  __ftrace_trace_stack.constprop.0+0x144/0x180  trace_buffer_unlock_commit_regs+0x6d/0x220  trace_event_buffer_commit+0x5c/0x260  trace_event_raw_event_softirq+0x47/0x80  raise_softirq_irqoff+0x6e/0xa0  rcu_read_unlock_special+0xb1/0x160  unwind_next_frame+0x203/0x9b0  __unwind_start+0x15d/0x1c0  arch_stack_walk+0x62/0xf0  stack_trace_save+0x48/0x70  __ftrace_trace_stack.constprop.0+0x144/0x180  trace_buffer_unlock_commit_regs+0x6d/0x220  trace_event_buffer_commit+0x5c/0x260  trace_event_raw_event_softirq+0x47/0x80  raise_softirq_irqoff+0x6e/0xa0  rcu_read_unlock_special+0xb1/0x160  unwind_next_frame+0x203/0x9b0  __unwind_start+0x15d/0x1c0  arch_stack_walk+0x62/0xf0  stack_trace_save+0x48/0x70  __ftrace_trace_stack.constprop.0+0x144/0x180  trace_buffer_unlock_commit_regs+0x6d/0x220  trace_event_buffer_commit+0x5c/0x260  trace_event_raw_event_softirq+0x47/0x80  raise_softirq_irqoff+0x6e/0xa0  rcu_read_unlock_special+0xb1/0x160  __is_insn_slot_addr+0x54/0x70  kernel_text_address+0x48/0xc0  __kernel_text_address+0xd/0x40  unwind_get_return_address+0x1e/0x40  arch_stack_walk+0x9c/0xf0  stack_trace_save+0x48/0x70  __ftrace_trace_stack.constprop.0+0x144/0x180  trace_buffer_unlock_commit_regs+0x6d/0x220  trace_event_buffer_commit+0x5c/0x260  trace_event_raw_event_softirq+0x47/0x80  __raise_softirq_irqoff+0x61/0x80  __flush_smp_call_function_queue+0x115/0x420  __sysvec_call_function_single+0x17/0xb0  sysvec_call_function_single+0x8c/0xc0  </IRQ>  Commit b41642c87716 ("rcu: Fix rcu_read_unlock() deadloop due to IRQ work") fixed the infinite loop in rcu_read_unlock_special() for IRQ work by setting a flag before calling irq_work_queue_on(). We fix this issue by setting the same flag before calling raise_softirq_irqoff() and rename the flag to defer_qs_pending for more common.

CVE-2026-45961:

        In the Linux kernel, the following vulnerability has been resolved:  gfs2: fix memory leaks in gfs2_fill_super error path  Fix two memory leaks in the gfs2_fill_super() error handling path when transitioning a filesystem to read-write mode fails.  First leak: kthread objects (thread_struct, task_struct, etc.) When gfs2_freeze_lock_shared() fails after init_threads() succeeds, the created kernel threads (logd and quotad) are never destroyed. This occurs because the fail_per_node label doesn't call gfs2_destroy_threads().  Second leak: quota bitmap buffer (8192 bytes) When gfs2_make_fs_rw() fails after gfs2_quota_init() succeeds but before other operations complete, the allocated quota bitmap is never freed.  The fix moves thread cleanup to the fail_per_node label to handle all error paths uniformly. gfs2_destroy_threads() is safe to call unconditionally as it checks for NULL pointers. Quota cleanup is added in gfs2_make_fs_rw() to properly handle the withdrawal case where quota initialization succeeds but the filesystem is then withdrawn.  Thread leak backtrace (gfs2_freeze_lock_shared failure):   unreferenced object 0xffff88801d7bca80 (size 4480):     copy_process+0x3a1/0x4670 kernel/fork.c:2422     kernel_clone+0xf3/0x6e0 kernel/fork.c:2779     kthread_create_on_node+0x100/0x150 kernel/kthread.c:478     init_threads+0xab/0x350 fs/gfs2/ops_fstype.c:611     gfs2_fill_super+0xe5c/0x1240 fs/gfs2/ops_fstype.c:1265  Quota leak backtrace (gfs2_make_fs_rw failure):   unreferenced object 0xffff88812de7c000 (size 8192):     gfs2_quota_init+0xe5/0x820 fs/gfs2/quota.c:1409     gfs2_make_fs_rw+0x7a/0xe0 fs/gfs2/super.c:149     gfs2_fill_super+0xfbb/0x1240 fs/gfs2/ops_fstype.c:1275

CVE-2026-45981:

        In the Linux kernel, the following vulnerability has been resolved:  s390/cio: Fix device lifecycle handling in css_alloc_subchannel()  `css_alloc_subchannel()` calls `device_initialize()` before setting up the DMA masks. If `dma_set_coherent_mask()` or `dma_set_mask()` fails, the error path frees the subchannel structure directly, bypassing the device model reference counting.  Once `device_initialize()` has been called, the embedded struct device must be released via `put_device()`, allowing the release callback to free the container structure.  Fix the error path by dropping the initial device reference with `put_device()` instead of calling `kfree()` directly.  This ensures correct device lifetime handling and avoids potential use-after-free or double-free issues.

CVE-2026-45985:

        In the Linux kernel, the following vulnerability has been resolved:  ext4: don't set EXT4_GET_BLOCKS_CONVERT when splitting before submitting I/O  When allocating blocks during within-EOF DIO and writeback with dioread_nolock enabled, EXT4_GET_BLOCKS_PRE_IO was set to split an existing large unwritten extent. However, EXT4_GET_BLOCKS_CONVERT was set when calling ext4_split_convert_extents(), which may potentially result in stale data issues.  Assume we have an unwritten extent, and then DIO writes the second half.     [UUUUUUUUUUUUUUUU] on-disk extent        U: unwritten extent    [UUUUUUUUUUUUUUUU] extent status tree             |<-   ->| ----> dio write this range  First, ext4_iomap_alloc() call ext4_map_blocks() with EXT4_GET_BLOCKS_PRE_IO, EXT4_GET_BLOCKS_UNWRIT_EXT and EXT4_GET_BLOCKS_CREATE flags set. ext4_map_blocks() find this extent and call ext4_split_convert_extents() with EXT4_GET_BLOCKS_CONVERT and the above flags set.  Then, ext4_split_convert_extents() calls ext4_split_extent() with EXT4_EXT_MAY_ZEROOUT, EXT4_EXT_MARK_UNWRIT2 and EXT4_EXT_DATA_VALID2 flags set, and it calls ext4_split_extent_at() to split the second half with EXT4_EXT_DATA_VALID2, EXT4_EXT_MARK_UNWRIT1, EXT4_EXT_MAY_ZEROOUT and EXT4_EXT_MARK_UNWRIT2 flags set. However, ext4_split_extent_at() failed to insert extent since a temporary lack -ENOSPC. It zeroes out the first half but convert the entire on-disk extent to written since the EXT4_EXT_DATA_VALID2 flag set, but left the second half as unwritten in the extent status tree.     [0000000000SSSSSS]  data                S: stale data, 0: zeroed    [WWWWWWWWWWWWWWWW]  on-disk extent      W: written extent    [WWWWWWWWWWUUUUUU]  extent status tree  Finally, if the DIO failed to write data to the disk, the stale data in the second half will be exposed once the cached extent entry is gone.  Fix this issue by not passing EXT4_GET_BLOCKS_CONVERT when splitting an unwritten extent before submitting I/O, and make ext4_split_convert_extents() to zero out the entire extent range to zero for this case, and also mark the extent in the extent status tree for consistency.

CVE-2026-45988:

        In the Linux kernel, the following vulnerability has been resolved:  rxrpc: Fix re-decryption of RESPONSE packets  If a RESPONSE packet gets a temporary failure during processing, it may end up in a partially decrypted state - and then get requeued for a retry.  Fix this by just discarding the packet; we will send another CHALLENGE packet and thereby elicit a further response.  Similarly, discard an incoming CHALLENGE packet if we get an error whilst generating a RESPONSE; the server will send another CHALLENGE.

CVE-2026-46000:

        In the Linux kernel, the following vulnerability has been resolved:  rxrpc: Fix conn-level packet handling to unshare RESPONSE packets  The security operations that verify the RESPONSE packets decrypt bits of it in place - however, the sk_buff may be shared with a packet sniffer, which would lead to the sniffer seeing an apparently corrupt packet (actually decrypted).  Fix this by handing a copy of the packet off to the specific security handler if the packet was cloned.

CVE-2026-46012:

        In the Linux kernel, the following vulnerability has been resolved:  rxrpc: Fix memory leaks in rxkad_verify_response()  Fix rxkad_verify_response() to free the ticket and the server key under all circumstances by initialising the ticket pointer to NULL and then making all paths through the function after the first allocation has been done go through a single common epilogue that just releases everything - where all the releases skip on a NULL pointer.

CVE-2026-46014:

        In the Linux kernel, the following vulnerability has been resolved:  KVM: SVM: Add missing save/restore handling of LBR MSRs  MSR_IA32_DEBUGCTLMSR and LBR MSRs are currently not enumerated by KVM_GET_MSR_INDEX_LIST, and LBR MSRs cannot be set with KVM_SET_MSRS. So save/restore is completely broken.  Fix it by adding the MSRs to msrs_to_save_base, and allowing writes to LBR MSRs from userspace only (as they are read-only MSRs) if LBR virtualization is enabled.  Additionally, to correctly restore L1's LBRs while L2 is running, make sure the LBRs are copied from the captured VMCB01 save area in svm_copy_vmrun_state().  Note, for VMX, this also fixes a flaw where MSR_IA32_DEBUGCTLMSR isn't reported as an MSR to save/restore.  Note #2, over-reporting MSR_IA32_LASTxxx on Intel is ok, as KVM already handles unsupported reads and writes thanks to commit b5e2fec0ebc3 ("KVM: Ignore DEBUGCTL MSRs with no effect") (kvm_do_msr_access() will morph the unsupported userspace write into a nop).  [sean: guard with lbrv checks, massage changelog]

CVE-2026-46017:

        In the Linux kernel, the following vulnerability has been resolved:  mm: fix deferred split queue races during migration  migrate_folio_move() records the deferred split queue state from src and replays it on dst.  Replaying it after remove_migration_ptes(src, dst, 0) makes dst visible before it is requeued, so a concurrent rmap-removal path can mark dst partially mapped and trip the WARN in deferred_split_folio().  Move the requeue before remove_migration_ptes() so dst is back on the deferred split queue before it becomes visible again.  Because migration still holds dst locked at that point, teach deferred_split_scan() to requeue a folio when folio_trylock() fails.  Otherwise a fully mapped underused folio can be dequeued by the shrinker and silently lost from split_queue.  [ziy@nvidia.com: move the comment]

CVE-2026-46032:

        In the Linux kernel, the following vulnerability has been resolved:  KVM: nSVM: Triple fault if restore host CR3 fails on nested #VMEXIT  If loading L1's CR3 fails on a nested #VMEXIT, nested_svm_vmexit() returns an error code that is ignored by most callers, and continues to run L1 with corrupted state. A sane recovery is not possible in this case, and HW behavior is to cause a shutdown. Inject a triple fault instead, and do not return early from nested_svm_vmexit(). Continue cleaning up the vCPU state (e.g. clear pending exceptions), to handle the failure as gracefully as possible.  From the APM:    Upon #VMEXIT, the processor performs the following actions in order to   return to the host execution context:    ...    if (illegal host state loaded, or exception while loading host state)       shutdown   else       execute first host instruction following the VMRUN  Remove the return value of nested_svm_vmexit(), which is mostly unchecked anyway.

CVE-2026-46054:

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

CVE-2026-46059:

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

CVE-2026-46068:

        In the Linux kernel, the following vulnerability has been resolved:  crypto: nx - fix bounce buffer leaks in nx842_crypto_{alloc,free}_ctx  The bounce buffers are allocated with __get_free_pages() using BOUNCE_BUFFER_ORDER (order 2 = 4 pages), but both the allocation error path and nx842_crypto_free_ctx() release the buffers with free_page(). Use free_pages() with the matching order instead.

CVE-2026-46071:

        In the Linux kernel, the following vulnerability has been resolved:  KVM: nSVM: Avoid clearing VMCB_LBR in vmcb12  svm_copy_lbrs() always marks VMCB_LBR dirty in the destination VMCB. However, nested_svm_vmexit() uses it to copy LBRs to vmcb12, and clearing clean bits in vmcb12 is not architecturally defined.  Move vmcb_mark_dirty() to callers and drop it for vmcb12.  This also facilitates incoming refactoring that does not pass the entire VMCB to svm_copy_lbrs().

CVE-2026-46130:

        In the Linux kernel, the following vulnerability has been resolved:  dm-verity-fec: fix reading parity bytes split across blocks (take 3)  fec_decode_bufs() assumes that the parity bytes of the first RS codeword it decodes are never split across parity blocks.  This assumption is false.  Consider v->fec->block_size == 4096 && v->fec->roots == 17 && fio->nbufs == 1, for example.  In that case, each call to fec_decode_bufs() consumes v->fec->roots * (fio->nbufs << DM_VERITY_FEC_BUF_RS_BITS) = 272 parity bytes.  Considering that the parity data for each message block starts on a block boundary, the byte alignment in the parity data will iterate through 272*i mod 4096 until the 3 parity blocks have been consumed.  On the 16th call (i=15), the alignment will be 4080 bytes into the first block.  Only 16 bytes remain in that block, but 17 parity bytes will be needed.  The code reads out-of-bounds from the parity block buffer.  Fortunately this doesn't normally happen, since it can occur only for certain non-default values of fec_roots *and* when the maximum number of buffers couldn't be allocated due to low memory.  For example with block_size=4096 only the following cases are affected:      fec_roots=17: nbufs in [1, 3, 5, 15]     fec_roots=19: nbufs in [1, 229]     fec_roots=21: nbufs in [1, 3, 5, 13, 15, 39, 65, 195]     fec_roots=23: nbufs in [1, 89]  Regardless, fix it by refactoring how the parity blocks are read.

CVE-2026-46147:

        In the Linux kernel, the following vulnerability has been resolved:  KVM: arm64: Fix pin leak and publication ordering in __pkvm_init_vcpu()  Two bugs exist in the vCPU initialisation path:  1. If a check fails after hyp_pin_shared_mem() succeeds, the cleanup    path jumps to 'unlock' without calling unpin_host_vcpu() or    unpin_host_sve_state(), permanently leaking pin references on the    host vCPU and SVE state pages.     Extract a register_hyp_vcpu() helper that performs the checks and    the store. When register_hyp_vcpu() returns an error, call    unpin_host_vcpu() and unpin_host_sve_state() inline before falling    through to the existing 'unlock' label.  2. register_hyp_vcpu() publishes the new vCPU pointer into    'hyp_vm->vcpus[]' with a bare store, allowing a concurrent caller    of pkvm_load_hyp_vcpu() to observe a partially initialised vCPU    object.     Ensure the store uses smp_store_release() and the load uses    smp_load_acquire(). While 'vm_table_lock' currently serialises the    store and the load, these barriers ensure the reader sees the fully    initialised 'hyp_vcpu' object even if there were a lockless path or    if the lock's own ordering guarantees were insufficient for nested    object initialization.

CVE-2026-46148:

        In the Linux kernel, the following vulnerability has been resolved:  spi: microchip-core-qspi: control built-in cs manually  The coreQSPI IP supports only a single chip select, which is automagically operated by the hardware - set low when the transmit buffer first gets written to and set high when the number of bytes written to the TOTALBYTES field of the FRAMES register have been sent on the bus. Additional devices must use GPIOs for their chip selects. It was reported to me that if there are two devices attached to this QSPI controller that the in-built chip select is set low while linux tries to access the device attached to the GPIO.  This went undetected as the boards that connected multiple devices to the SPI controller all exclusively used GPIOs for chip selects, not relying on the built-in chip select at all. It turns out that this was because the built-in chip select, when controlled automagically, is set low when active and high when inactive, thereby ruling out its use for active-high devices or devices that need to transmit with the chip select disabled.  Modify the driver so that it controls chip select directly, retaining the behaviour for mem_ops of setting the chip select active for the entire duration of the transfer in the exec_op callback. For regular transfers, implement the set_cs callback for the core to use.  As part of this, the existing setup callback, mchp_coreqspi_setup_op(), is removed. Modifying the CLKIDLE field is not safe to do during operation when there are multiple devices, so this code is removed entirely. Setting the MASTER and ENABLE fields is something that can be done once at probe, it doesn't need to be re-run for each device. Instead the new setup callback sets the built-in chip select to its inactive state for active-low devices, as the reset value of the chip select in software controlled mode is low.

CVE-2026-46153:

        In the Linux kernel, the following vulnerability has been resolved:  8021q: delete cleared egress QoS mappings  vlan_dev_set_egress_priority() currently keeps cleared egress priority mappings in the hash as tombstones. Repeated set/clear cycles with distinct skb priorities therefore accumulate mapping nodes until device teardown and leak memory.  Delete mappings when vlan_prio is cleared instead of keeping tombstones. Now that the egress mapping lists are RCU protected, the node can be unlinked safely and freed after a grace period.

CVE-2026-46157:

        In the Linux kernel, the following vulnerability has been resolved:  ALSA: pcm: oss: Fix data race at accessing runtime.oss.trigger  Currently the runtime.oss.trigger field may be accessed concurrently without protection, which may lead to the data race.  And, in this case, it may lead to more severe problem because it's a bit field; as writing the data, it may overwrite other bit fields as well, which confuses the operation completely, as spotted by fuzzing.  Fix it by covering runtime.oss.trigger bit fled also with the existing params_lock mutex in both snd_pcm_oss_get_trigger() and snd_pcm_oss_poll().

CVE-2026-46175:

        In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix fsck inconsistency caused by FGGC of node block  During FGGC node block migration, fsck may incorrectly treat the migrated node block as fsync-written data.  The reproduction scenario: root@vm:/mnt/f2fs# seq 1 2048 | xargs -n 1 ./test_sync // write inline inode and sync root@vm:/mnt/f2fs# rm -f 1 root@vm:/mnt/f2fs# sync root@vm:/mnt/f2fs# f2fs_io gc_range // move data block in sync mode and not write CP   SPO, "fsck --dry-run" find inode has already checkpointed but still   with DENT_BIT_SHIFT set  The root cause is that GC does not clear the dentry mark and fsync mark during node block migration, leading fsck to misinterpret them as user-issued fsync writes.  In BGGC mode, node block migration is handled by f2fs_sync_node_pages(), which guarantees the dentry and fsync marks are cleared before writing.  This patch move the set/clear of the fsync|dentry marks into __write_node_folio to make the logic clearer, and ensures the fsync|dentry mark is cleared in FGGC.

CVE-2026-46181:

        In the Linux kernel, the following vulnerability has been resolved:  RDMA/mlx4: Fix mis-use of RCU in mlx4_srq_event()  Sashiko points out the radix_tree itself is RCU safe, but nothing ever frees the mlx4_srq struct with RCU, and it isn't even accessed within the RCU critical section. It also will crash if an event is delivered before the srq object is finished initializing.  Use the spinlock since it isn't easy to make RCU work, use refcount_inc_not_zero() to protect against partially initialized objects, and order the refcount_set() to be after the srq is fully initialized.

CVE-2026-46200:

        In the Linux kernel, the following vulnerability has been resolved:  spi: mpc52xx: fix controller deregistration  Make sure to deregister the controller before disabling and releasing underlying resources like interrupts and gpios during driver unbind.

CVE-2026-46204:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu/vcn4: Prevent OOB reads when parsing IB  Rewrite the IB parsing to use amdgpu_ib_get_value() which handles the bounds checks.

CVE-2026-46225:

        In the Linux kernel, the following vulnerability has been resolved:  spi: rspi: fix controller deregistration  Make sure to deregister the controller before releasing underlying resources like DMA during driver unbind.

CVE-2026-46226:

        In the Linux kernel, the following vulnerability has been resolved:  spi: fsl: fix controller deregistration  Make sure to deregister the controller before releasing underlying resources like DMA during driver unbind.

CVE-2026-46229:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdkfd: Clear VRAM on allocation to prevent stale data exposure  KFD VRAM allocations set AMDGPU_GEM_CREATE_VRAM_WIPE_ON_RELEASE but not AMDGPU_GEM_CREATE_VRAM_CLEARED, leaving freshly allocated VRAM with stale data from prior use observable by compute kernels.  The GEM ioctl path already sets VRAM_CLEARED for all userspace allocations via amdgpu_gem_create_ioctl() and amdgpu_mode_dumb_create(). The KFD path was missing this flag, allowing stale page table remnants to leak into user buffers.  This causes crashes in RCCL P2P transport where non-zero data in ptrExchange/head/tail fields corrupts the protocol handshake.

CVE-2026-46241:

        In the Linux kernel, the following vulnerability has been resolved:  spi: mpc52xx: fix use-after-free on registration failure  Make sure to disable and free the interrupts in case controller registration fails to avoid a potential use-after-free and resource leak.  This issue was flagged by Sashiko when reviewing a controller deregistration fix.

CVE-2026-46245:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Fix dc_link NULL handling in HPD init  amdgpu_dm_hpd_init() may see connectors without a valid dc_link.  The code already checks dc_link for the polling decision, but later unconditionally dereferences it when setting up HPD interrupts.  Assign dc_link early and skip connectors where it is NULL.  Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_irq.c:940 amdgpu_dm_hpd_init() error: we previously assumed 'dc_link' could be null (see line 931)  drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_irq.c     923                 /*     924                  * Analog connectors may be hot-plugged unlike other connector     925                  * types that don't support HPD. Only poll analog connectors.     926                  */     927                 use_polling |=     928                         amdgpu_dm_connector->dc_link &&                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The patch adds this NULL check but hopefully it can be removed      929                         dc_connector_supports_analog(amdgpu_dm_connector->dc_link->link_id.id);     930     931                 dc_link = amdgpu_dm_connector->dc_link;  dc_link assigned here.      932     933                 /*     934                  * Get a base driver irq reference for hpd ints for the lifetime     935                  * of dm. Note that only hpd interrupt types are registered with     936                  * base driver; hpd_rx types aren't. IOW, amdgpu_irq_get/put on     937                  * hpd_rx isn't available. DM currently controls hpd_rx     938                  * explicitly with dc_interrupt_set()     939                  */ --> 940                 if (dc_link->irq_source_hpd != DC_IRQ_SOURCE_INVALID) {                             ^^^^^^^^^^^^^^^^^^^^^^^ If it's NULL then we are trouble because we dereference it here.      941                         irq_type = dc_link->irq_source_hpd - DC_IRQ_SOURCE_HPD1;     942                         /*     943                          * TODO: There's a mismatch between mode_info.num_hpd     944                          * and what bios reports as the # of connectors with hpd

CVE-2026-46254:

        In the Linux kernel, the following vulnerability has been resolved:  AppArmor: Allow apparmor to handle unaligned dfa tables  The dfa tables can originate from kernel or userspace and 8-byte alignment isn't always guaranteed and as such may trigger unaligned memory accesses on various architectures. Resulting in the following  [   73.901376] WARNING: CPU: 0 PID: 341 at security/apparmor/match.c:316 aa_dfa_unpack+0x6cc/0x720 [   74.015867] Modules linked in: binfmt_misc evdev flash sg drm drm_panel_orientation_quirks backlight i2c_core configfs nfnetlink autofs4 ext4 crc16 mbcache jbd2 hid_generic usbhid sr_mod hid cdrom sd_mod ata_generic ohci_pci ehci_pci ehci_hcd ohci_hcd pata_ali libata sym53c8xx scsi_transport_spi tg3 scsi_mod usbcore libphy scsi_common mdio_bus usb_common [   74.428977] CPU: 0 UID: 0 PID: 341 Comm: apparmor_parser Not tainted 6.18.0-rc6+ #9 NONE [   74.536543] Call Trace: [   74.568561] [<0000000000434c24>] dump_stack+0x8/0x18 [   74.633757] [<0000000000476438>] __warn+0xd8/0x100 [   74.696664] [<00000000004296d4>] warn_slowpath_fmt+0x34/0x74 [   74.771006] [<00000000008db28c>] aa_dfa_unpack+0x6cc/0x720 [   74.843062] [<00000000008e643c>] unpack_pdb+0xbc/0x7e0 [   74.910545] [<00000000008e7740>] unpack_profile+0xbe0/0x1300 [   74.984888] [<00000000008e82e0>] aa_unpack+0xe0/0x6a0 [   75.051226] [<00000000008e3ec4>] aa_replace_profiles+0x64/0x1160 [   75.130144] [<00000000008d4d90>] policy_update+0xf0/0x280 [   75.201057] [<00000000008d4fc8>] profile_replace+0xa8/0x100 [   75.274258] [<0000000000766bd0>] vfs_write+0x90/0x420 [   75.340594] [<00000000007670cc>] ksys_write+0x4c/0xe0 [   75.406932] [<0000000000767174>] sys_write+0x14/0x40 [   75.472126] [<0000000000406174>] linux_sparc_syscall+0x34/0x44 [   75.548802] ---[ end trace 0000000000000000 ]--- [   75.609503] dfa blob stream 0xfff0000008926b96 not aligned. [   75.682695] Kernel unaligned access at TPC[8db2a8] aa_dfa_unpack+0x6e8/0x720  Work around it by using the get_unaligned_xx() helpers.

CVE-2026-46274:

        In the Linux kernel, the following vulnerability has been resolved:  io-wq: check that the predecessor is hashed in io_wq_remove_pending()  io_wq_remove_pending() needs to fix up wq->hash_tail[] if the cancelled work was the tail of its hash bucket. When doing this, it checks whether the preceding entry in acct->work_list has the same hash value, but never checks that the predecessor is hashed at all. io_get_work_hash() is simply atomic_read(&work->flags) >> IO_WQ_HASH_SHIFT, and the hash bits are never set for non-hashed work, so it returns 0. Thus, when a hashed bucket-0 work is cancelled while a non-hashed work is its list predecessor, the check spuriously passes and a pointer to the non-hashed io_kiocb is stored in wq->hash_tail[0].  Because non-hashed work is dequeued via the fast path in io_get_next_work(), which never touches hash_tail[], the stale pointer is never cleared. Therefore, after the non-hashed io_kiocb completes and is freed back to req_cachep, wq->hash_tail[0] is a dangling pointer. The io_wq is per-task (tctx->io_wq) and survives ring open/close, so the dangling pointer persists for the lifetime of the task; the next hashed bucket-0 enqueue dereferences it in io_wq_insert_work() and wq_list_add_after() writes through freed memory.  Add the missing io_wq_is_hashed() check so a non-hashed predecessor never inherits a hash_tail[] slot.

CVE-2026-46282:

        In the Linux kernel, the following vulnerability has been resolved:  iio: frequency: admv1013: fix NULL pointer dereference on str  When device_property_read_string() fails, str is left uninitialized but the code falls through to strcmp(str, ...), dereferencing a garbage pointer. Replace manual read/strcmp with device_property_match_property_string() and consolidate the SE mode enums into a single sequential enum, mapping to hardware register values via a switch consistent with other bitfields in the driver.  Several cleanup patches have been applied to this driver recently so this will need a manual backport.

CVE-2026-46302:

        In the Linux kernel, the following vulnerability has been resolved:  selinux: allow multiple opens of /sys/fs/selinux/policy  Currently there can only be a single open of /sys/fs/selinux/policy at any time. This allows any process to block any other process from reading the kernel policy. The original motivation seems to have been a mix of preventing an inconsistent view of the policy size and preventing userspace from allocating kernel memory without bound, but this is arguably equally bad. Eliminate the policy_opened flag and shrink the critical section that the policy mutex is held. While we are making changes here, drop a couple of extraneous BUG_ONs.

CVE-2026-46312:

        In the Linux kernel, the following vulnerability has been resolved:  media: videobuf2: Set vma_flags in vb2_dma_sg_mmap  vb2_dma_contig sets VMA flags VM_DONTEXPAND and VM_DONTDUMP and I do not see a reason why vb2_dma_sg should behave differently. This avoids hitting `WARN_ON(!(vma->vm_flags & VM_DONTEXPAND));` in drm_gem_mmap_obj() during mmap() of an imported dma-buf from the out of tree Apple ISP camera capture driver which uses vb2_dma_sg_memops.  gst-launch-1.0 v4l2src ! gtk4paintablesink  [   38.201528] ------------[ cut here ]------------ [   38.202135] WARNING: CPU: 7 PID: 2362 at drivers/gpu/drm/drm_gem.c:1144 drm_gem_mmap_obj+0x1f8/0x210 [   38.203278] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device uinput nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables qrtr bnep nls_ascii i2c_dev loop fuse dm_multipath nfnetlink brcmfmac_wcc hid_magicmouse hci_bcm4377 brcmfmac brcmutil bluetooth ecdh_generic cfg80211 ecc btrfs xor xor_neon rfkill hid_apple raid6_pq joydev aop_als apple_nvmem_spmi industrialio snd_soc_aop apple_z2 snd_soc_cs42l84 tps6598x snd_soc_tas2764 macsmc_reboot spi_nor macsmc_hwmon rtc_macsmc gpio_macsmc macsmc_power regmap_spmi macsmc_input dockchannel_hid panel_summit appledrm nvme_apple dwc3 snd_soc_macaudio drm_client_lib nvme_core phy_apple_atc hwmon apple_sart apple_dockchannel macsmc apple_rtkit_helper spmi_apple_controller aop apple_wdt mfd_core nvmem_apple_efuses pinctrl_apple_gpio apple_isp apple_dcp videobuf2_dma_sg mux_core spi_apple [   38.203300]  videobuf2_memops i2c_pasemi_platform snd_soc_apple_mca videobuf2_v4l2 videodev clk_apple_nco videobuf2_common snd_pcm_dmaengine adpdrm asahi apple_admac adpdrm_mipi drm_dma_helper pwm_apple i2c_pasemi_core drm_display_helper mc cec apple_dart ofpart apple_soc_cpufreq leds_pwm phram [   38.217677] CPU: 7 UID: 1000 PID: 2362 Comm: gst-launch-1.0 Tainted: G        W           6.17.6+ #asahi-dev PREEMPT(full) [   38.219040] Tainted: [W]=WARN [   38.219398] Hardware name: Apple MacBook Pro (13-inch, M2, 2022) (DT) [   38.220213] pstate: 21400005 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [   38.221088] pc : drm_gem_mmap_obj+0x1f8/0x210 [   38.221643] lr : drm_gem_mmap_obj+0x78/0x210 [   38.222178] sp : ffffc0008dc678e0 [   38.222579] x29: ffffc0008dc678e0 x28: 0000000000042a97 x27: ffff8000b701b480 [   38.223465] x26: 00000000000000fb x25: ffffc0008dc67d20 x24: ffffc0008dc67968 [   38.224402] x23: ffff8000e3ca5600 x22: ffff8000265b7800 x21: ffff80003000c0c0 [   38.225279] x20: 0000000000000000 x19: ffff8000b68c5200 x18: ffffc0008dc67968 [   38.226151] x17: 0000000000000000 x16: 0000000000000000 x15: ffffc000810a30a8 [   38.227042] x14: 00007fff637effff x13: 00005555de91ffff x12: 00007fff63293fff [   38.227942] x11: 0000000000000000 x10: ffff8000184ecf08 x9 : ffffc0007a1900c8 [   38.228824] x8 : ffffc0008dc67968 x7 : 0000000000000012 x6 : ffffc0015cf1c000 [   38.229703] x5 : ffffc0008dc676a0 x4 : ffffc00081a27dc0 x3 : 0000000000000038 [   38.230607] x2 : 0000000000000003 x1 : 0000000000000003 x0 : 00000000100000fb [   38.231488] Call trace: [   38.231806]  drm_gem_mmap_obj+0x1f8/0x210 (P) [   38.232342]  drm_gem_mmap+0x140/0x260 [   38.232813]  __mmap_region+0x488/0x9a0 [   38.233277]  mmap_region+0xd0/0x148 [   38.233703]  do_mmap+0x350/0x5c0 [   38.234148]  vm_mmap_pgoff+0x14c/0x200 [   38.234612]  ksys_mmap_pgoff+0x150/0x208 [   38.235107]  __arm64_sys_mmap+0x34/0x50 [   38.235611]  invoke_syscall+0x50/0x120 [   38.236075]  el0_svc_common.constprop.0+0x48/0xf0 [   38.236680]  do_el0_svc+0x24/0x38 [   38.237113]  el0_svc+0x38/0x168 [   38.237507]  el0t_64_sync_handler+0xa0/0xe8 [   38.238034]  el0t_64_sync+0x198/0x1a0 [   38.238491] ---[ end trace 0000000000000000 ]---  There were discussions in [1] at the end of 2023 that mmap() on imported ---truncated---

CVE-2026-46324:

        In the Linux kernel, the following vulnerability has been resolved:  netfilter: nf_tables: use list_del_rcu for netlink hooks  nft_netdev_unregister_hooks and __nft_unregister_flowtable_net_hooks need to use list_del_rcu(), this list can be walked by concurrent dumpers.  Add a new helper and use it consistently.

CVE-2026-46330:

        In the Linux kernel, the following vulnerability has been resolved:  Revert "net/smc: Introduce TCP ULP support"  This reverts commit d7cd421da9da2cc7b4d25b8537f66db5c8331c40.  As reported by Al Viro, the TCP ULP support for SMC is fundamentally broken. The implementation attempts to convert an active TCP socket into an SMC socket by modifying the underlying `struct file`, dentry, and inode in-place, which violates core VFS invariants that assume these structures are immutable for an open file, creating a risk of use after free errors and general system instability.  Given the severity of this design flaw and the fact that cleaner alternatives (e.g., LD_PRELOAD, BPF) exist for legacy application transparency, the correct course of action is to remove this feature entirely.

CVE-2026-52936:

        In the Linux kernel, the following vulnerability has been resolved:  crypto: jitterentropy - replace long-held spinlock with mutex  jent_kcapi_random() serializes the shared jitterentropy state, but it currently holds a spinlock across the jent_read_entropy() call. That path performs expensive jitter collection and SHA3 conditioning, so parallel readers can trigger stalls as contending waiters spin for the same lock.  To prevent non-preemptible lock hold, replace rng->jent_lock with a mutex so contended readers sleep instead of spinning on a shared lock held across expensive entropy generation.

CVE-2026-52937:

        In the Linux kernel, the following vulnerability has been resolved:  tap: fix stack info leak in tap_ioctl() SIOCGIFHWADDR  In the SIOCGIFHWADDR path, tap_ioctl() copies 16 bytes of an uninitialised on-stack struct sockaddr_storage to userspace via ifr_hwaddr, but netif_get_mac_address() only writes sa_family and dev->addr_len (6 for Ethernet) bytes, leaving sa_data[6..13] uninitialised.  Those 8 trailing bytes leak kernel stack contents; SIOCGIFHWADDR on a macvtap chardev returns kernel .text and direct-map pointers, defeating KASLR.  Initialise ss at declaration.

CVE-2026-52956:

        In the Linux kernel, the following vulnerability has been resolved:  libceph: Fix potential out-of-bounds access in __ceph_x_decrypt()  In __ceph_x_decrypt(), a part of the buffer p is interpreted as a ceph_x_encrypt_header, and the magic field of this struct is accessed. This happens without any guarantee that the buffer is large enough to hold this struct. The function parameter ciphertext_len represents the length of the ciphertext to decrypt and is guaranteed to be at most the remaining size of the allocated buffer p. However, this value is not necessarily greater than sizeof(ceph_x_encrypt_header). E.g., a message frame of type FRAME_TAG_AUTH_REPLY_MORE, that is just as long to hold the ciphertext at its end with a ciphertext_len of 8 or less, can trigger an out-of-bounds memory access when accessing hdr->magic.  This patch fixes the issue by adding a check to ensure that the decrypted plaintext in the buffer is large enough to represent at least the ceph_x_encrypt_header.

CVE-2026-52961:

        In the Linux kernel, the following vulnerability has been resolved:  ceph: fix BUG_ON in __ceph_build_xattrs_blob() due to stale blob size  The generic/642 test-case can reproduce the kernel crash:  [40243.605254] ------------[ cut here ]------------ [40243.605956] kernel BUG at fs/ceph/xattr.c:918! [40243.607142] Oops: invalid opcode: 0000 [#1] SMP PTI [40243.608067] CPU: 7 UID: 0 PID: 498762 Comm: kworker/7:1 Not tainted 7.0.0-rc7+ #3 PREEMPT(full) [40243.609700] Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [40243.611820] Workqueue: ceph-msgr ceph_con_workfn [40243.612715] RIP: 0010:__ceph_build_xattrs_blob+0x1b8/0x1e0 [40243.613731] Code: 0f 84 82 fe ff ff e9 cf 8e 56 ff 48 8d 65 e8 31 c0 5b 41 5c 41 5d 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 c3 cc cc cc cc <0f> 0b 4c 8b 62 08 41 8b 85 24 07 00 00 49 83 c4 04 41 89 44 24 fc [40243.616888] RSP: 0018:ffffcc80c4d4b688 EFLAGS: 00010287 [40243.617773] RAX: 0000000000010026 RBX: 0000000000000001 RCX: 0000000000000000 [40243.618928] RDX: ffff8a773798dee0 RSI: 0000000000000000 RDI: 0000000000000000 [40243.620158] RBP: ffffcc80c4d4b6a0 R08: 0000000000000000 R09: 0000000000000000 [40243.621573] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8a75f3b58000 [40243.622907] R13: ffff8a75f3b58000 R14: 0000000000000080 R15: 000000000000bffd [40243.624054] FS:  0000000000000000(0000) GS:ffff8a787d1b4000(0000) knlGS:0000000000000000 [40243.625331] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [40243.626269] CR2: 000072f390b623c0 CR3: 000000011c02a003 CR4: 0000000000372ef0 [40243.627408] Call Trace: [40243.627839]  <TASK> [40243.628188]  __prep_cap+0x3fd/0x4a0 [40243.628789]  ? do_raw_spin_unlock+0x4e/0xe0 [40243.629474]  ceph_check_caps+0x46a/0xc80 [40243.630094]  ? __lock_acquire+0x4a2/0x2650 [40243.630773]  ? find_held_lock+0x31/0x90 [40243.631347]  ? handle_cap_grant+0x79f/0x1060 [40243.632068]  ? lock_release+0xd9/0x300 [40243.632696]  ? __mutex_unlock_slowpath+0x3e/0x340 [40243.633429]  ? lock_release+0xd9/0x300 [40243.634052]  handle_cap_grant+0xcf6/0x1060 [40243.634745]  ceph_handle_caps+0x122b/0x2110 [40243.635415]  mds_dispatch+0x5bd/0x2160 [40243.636034]  ? ceph_con_process_message+0x65/0x190 [40243.636828]  ? lock_release+0xd9/0x300 [40243.637431]  ceph_con_process_message+0x7a/0x190 [40243.638184]  ? kfree+0x311/0x4f0 [40243.638749]  ? kfree+0x311/0x4f0 [40243.639268]  process_message+0x16/0x1a0 [40243.639915]  ? sg_free_table+0x39/0x90 [40243.640572]  ceph_con_v2_try_read+0xf58/0x2120 [40243.641255]  ? lock_acquire+0xc8/0x300 [40243.641863]  ceph_con_workfn+0x151/0x820 [40243.642493]  process_one_work+0x22f/0x630 [40243.643093]  ? process_one_work+0x254/0x630 [40243.643770]  worker_thread+0x1e2/0x400 [40243.644332]  ? __pfx_worker_thread+0x10/0x10 [40243.645020]  kthread+0x109/0x140 [40243.645560]  ? __pfx_kthread+0x10/0x10 [40243.646125]  ret_from_fork+0x3f8/0x480 [40243.646752]  ? __pfx_kthread+0x10/0x10 [40243.647316]  ? __pfx_kthread+0x10/0x10 [40243.647919]  ret_from_fork_asm+0x1a/0x30 [40243.648556]  </TASK> [40243.648902] Modules linked in: overlay hctr2 libpolyval chacha libchacha adiantum libnh libpoly1305 essiv intel_rapl_msr intel_rapl_common intel_uncore_frequency_common skx_edac_common nfit kvm_intel kvm irqbypass joydev ghash_clmulni_intel aesni_intel rapl input_leds mac_hid psmouse vga16fb serio_raw vgastate floppy i2c_piix4 pata_acpi bochs qemu_fw_cfg i2c_smbus sch_fq_codel rbd dm_crypt msr parport_pc ppdev lp parport efi_pstore [40243.654766] ---[ end trace 0000000000000000 ]---  Commit d93231a6bc8a ("ceph: prevent a client from exceeding the MDS maximum xattr size") moved the required_blob_size computation to before the __build_xattrs() call, introducing a race.  __build_xattrs() releases and reacquires i_ceph_lock during execution. In that window, handle_cap_grant() may update i_xattrs.blob with a newer MDS-provided blob and bump i_xattrs.version.  When __bui ---truncated---

CVE-2026-52990:

        In the Linux kernel, the following vulnerability has been resolved:  fsnotify: fix inode reference leak in fsnotify_recalc_mask()  fsnotify_recalc_mask() fails to handle the return value of __fsnotify_recalc_mask(), which may return an inode pointer that needs to be released via fsnotify_drop_object() when the connector's HAS_IREF flag transitions from set to cleared.  This manifests as a hung task with the following call trace:    INFO: task umount:1234 blocked for more than 120 seconds.   Call Trace:    __schedule    schedule    fsnotify_sb_delete    generic_shutdown_super    kill_anon_super    cleanup_mnt    task_work_run    do_exit    do_group_exit  The race window that triggers the iref leak:    Thread A (adding mark)              Thread B (removing mark)   ──────────────────────              ────────────────────────   fsnotify_add_mark_locked():     fsnotify_add_mark_list():       spin_lock(conn->lock)       add mark_B(evictable) to list       spin_unlock(conn->lock)     return      /* ---- gap: no lock held ---- */                                        fsnotify_detach_mark(mark_A):                                         spin_lock(mark_A->lock)                                         clear ATTACHED flag on mark_A                                         spin_unlock(mark_A->lock)                                         fsnotify_put_mark(mark_A)      fsnotify_recalc_mask():       spin_lock(conn->lock)       __fsnotify_recalc_mask():         /* mark_A skipped: ATTACHED cleared */         /* only mark_B(evictable) remains */         want_iref = false         has_iref = true  /* not yet cleared */         -> HAS_IREF transitions true -> false         -> returns inode pointer       spin_unlock(conn->lock)       /* BUG: return value discarded!        * iput() and fsnotify_put_sb_watched_objects()        * are never called */  Fix this by deferring the transition true -> false of HAS_IREF flag from fsnotify_recalc_mask() (Thread A) to fsnotify_put_mark() (thread B).

CVE-2026-52991:

        In the Linux kernel, the following vulnerability has been resolved:  sched/psi: fix race between file release and pressure write  A potential race condition exists between pressure write and cgroup file release regarding the priv member of struct kernfs_open_file, which triggers the uaf reported in [1].  Consider the following scenario involving execution on two separate CPUs:     CPU0					CPU1    ====					==== 					vfs_rmdir() 					kernfs_iop_rmdir() 					cgroup_rmdir() 					cgroup_kn_lock_live() 					cgroup_destroy_locked() 					cgroup_addrm_files() 					cgroup_rm_file() 					kernfs_remove_by_name() 					kernfs_remove_by_name_ns()  vfs_write()				__kernfs_remove()  new_sync_write()			kernfs_drain()  kernfs_fop_write_iter()		kernfs_drain_open_files()  cgroup_file_write()			kernfs_release_file()  pressure_write()			cgroup_file_release()  ctx = of->priv; 					kfree(ctx);  					of->priv = NULL; 					cgroup_kn_unlock()  cgroup_kn_lock_live()  cgroup_get(cgrp)  cgroup_kn_unlock()  if (ctx->psi.trigger)  // here, trigger uaf for ctx, that is of->priv  The cgroup_rmdir() is protected by the cgroup_mutex, it also safeguards the memory deallocation of of->priv performed within cgroup_file_release(). However, the operations involving of->priv executed within pressure_write() are not entirely covered by the protection of cgroup_mutex. Consequently, if the code in pressure_write(), specifically the section handling the ctx variable executes after cgroup_file_release() has completed, a uaf vulnerability involving of->priv is triggered.  Therefore, the issue can be resolved by extending the scope of the cgroup_mutex lock within pressure_write() to encompass all code paths involving of->priv, thereby properly synchronizing the race condition occurring between cgroup_file_release() and pressure_write().  And, if an live kn lock can be successfully acquired while executing the pressure write operation, it indicates that the cgroup deletion process has not yet reached its final stage; consequently, the priv pointer within open_file cannot be NULL. Therefore, the operation to retrieve the ctx value must be moved to a point *after* the live kn lock has been successfully acquired.  In another situation, specifically after entering cgroup_kn_lock_live() but before acquiring cgroup_mutex, there exists a different class of race condition:  CPU0: write memory.pressure               CPU1: write cgroup.pressure=0 ===========================		  =============================  kernfs_fop_write_iter()  kernfs_get_active_of(of)  pressure_write()    cgroup_kn_lock_live(memory.pressure)      cgroup_tryget(cgrp)      kernfs_break_active_protection(kn)      ... blocks on cgroup_mutex                                       	  cgroup_pressure_write()                                      	  cgroup_kn_lock_live(cgroup.pressure)                                      	  cgroup_file_show(memory.pressure, false)                                      	    kernfs_show(false)                                      	      kernfs_drain_open_files()                                      	        cgroup_file_release(of)                                      	          kfree(ctx)                                      	            of->priv = NULL                                      	  cgroup_kn_unlock()     ... acquires cgroup_mutex    ctx = of->priv;        // may now be NULL    if (ctx->psi.trigger)  // NULL dereference  Consequently, there is a possibility that of->priv is NULL, the pressure write needs to check for this.  Now that the scope of the cgroup_mutex has been expanded, the original explicit cgroup_get/put operations are no longer necessary, this is because acquiring/releasing the live kn lock inherently executes a cgroup get/put operation.  [1] BUG: KASAN: slab-use-after-free in pressure_write+0xa4/0x210 kernel/cgroup/cgroup.c:4011 Call Trace:  pressure_write+0xa4/0x210 kernel/cgroup/cgroup.c:4011  cgroup_file_write+0x36f/0x790 kernel/cgroup/cgroup.c:43 ---truncated---

CVE-2026-53000:

        In the Linux kernel, the following vulnerability has been resolved:  netfilter: nat: use kfree_rcu to release ops  Florian Westphal says:  "Historically this is not an issue, even for normal base hooks: the data path doesn't use the original nf_hook_ops that are used to register the callbacks.  However, in v5.14 I added the ability to dump the active netfilter hooks from userspace.  This code will peek back into the nf_hook_ops that are available at the tail of the pointer-array blob used by the datapath.  The nat hooks are special, because they are called indirectly from the central nat dispatcher hook. They are currently invisible to the nfnl hook dump subsystem though.  But once that changes the nat ops structures have to be deferred too."  Update nf_nat_register_fn() to deal with partial exposition of the hooks from error path which can be also an issue for nfnetlink_hook.

CVE-2026-53009:

        In the Linux kernel, the following vulnerability has been resolved:  ice: fix double-free of tx_buf skb  If ice_tso() or ice_tx_csum() fail, the error path in ice_xmit_frame_ring() frees the skb, but the 'first' tx_buf still points to it and is marked as valid (ICE_TX_BUF_SKB). 'next_to_use' remains unchanged, so the potential problem will likely fix itself when the next packet is transmitted and the tx_buf gets overwritten. But if there is no next packet and the interface is brought down instead, ice_clean_tx_ring() -> ice_unmap_and_free_tx_buf() will find the tx_buf and free the skb for the second time.  The fix is to reset the tx_buf type to ICE_TX_BUF_EMPTY in the error path, so that ice_unmap_and_free_tx_buf(). Move the initialization of 'first' up, to ensure it's already valid in case we hit the linearization error path.  The bug was spotted by AI while I had it looking for something else. It also proposed an initial version of the patch.  I reproduced the bug and tested the fix by adding code to inject failures, on a build with KASAN.  I looked for similar bugs in related Intel drivers and did not find any.

CVE-2026-53015:

        In the Linux kernel, the following vulnerability has been resolved:  erofs: unify lcn as u64 for 32-bit platforms  As sashiko reported [1], `lcn` was typed as `unsigned long` (or `unsigned int` sometimes), which is only 32 bits wide on 32-bit platforms, which causes `(lcn << lclusterbits)` to be truncated at 4 GiB.  In order to consolidate the logic, just use `u64` consistently around the codebase.  [1] https://sashiko.dev/r/20260420034612.1899973-1-hsiangkao%40linux.alibaba.com

CVE-2026-53017:

        In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix data loss caused by incorrect use of nat_entry flag  Data loss can occur when fsync is performed on a newly created file (before any checkpoint has been written) concurrently with a checkpoint operation. The scenario is as follows:  create & write & fsync 'file A'                 write checkpoint - f2fs_do_sync_file // inline inode  - f2fs_write_inode // inode folio is dirty                                                 - f2fs_write_checkpoint                                                  - f2fs_flush_merged_writes                                                  - f2fs_sync_node_pages                                                  - f2fs_flush_nat_entries  - f2fs_fsync_node_pages // no dirty node  - f2fs_need_inode_block_update // return false  SPO and lost 'file A'  f2fs_flush_nat_entries() sets the IS_CHECKPOINTED and HAS_LAST_FSYNC flags for the nat_entry, but this does not mean that the checkpoint has actually completed successfully. However, f2fs_need_inode_block_update() checks these flags and incorrectly assumes that the checkpoint has finished.  The root cause is that the semantics of IS_CHECKPOINTED and HAS_LAST_FSYNC are only guaranteed after the checkpoint write fully completes.  This patch modifies f2fs_need_inode_block_update() to acquire the sbi->node_write lock before reading the nat_entry flags, ensuring that once IS_CHECKPOINTED and HAS_LAST_FSYNC are observed to be set, the checkpoint operation has already completed.

CVE-2026-53018:

        In the Linux kernel, the following vulnerability has been resolved:  f2fs: avoid reading already updated pages during GC  We found the following issue during fuzz testing:  page: refcount:3 mapcount:0 mapping:00000000b6e89c65 index:0x18b2dc pfn:0x161ba9 memcg:f8ffff800e269c00 aops:f2fs_meta_aops ino:2 flags: 0x52880000000080a9(locked|waiters|uptodate|lru|private|zone=1|kasantag=0x4a) raw: 52880000000080a9 fffffffec6e17588 fffffffec0ccc088 a7ffff8067063618 raw: 000000000018b2dc 0000000000000009 00000003ffffffff f8ffff800e269c00 page dumped because: VM_BUG_ON_FOLIO(folio_test_uptodate(folio)) page_owner tracks the page as allocated  post_alloc_hook+0x58c/0x5ec  prep_new_page+0x34/0x284  get_page_from_freelist+0x2dcc/0x2e8c  __alloc_pages_noprof+0x280/0x76c  __folio_alloc_noprof+0x18/0xac  __filemap_get_folio+0x6bc/0xdc4  pagecache_get_page+0x3c/0x104  do_garbage_collect+0x5c78/0x77a4  f2fs_gc+0xd74/0x25f0  gc_thread_func+0xb28/0x2930  kthread+0x464/0x5d8  ret_from_fork+0x10/0x20 ------------[ cut here ]------------ kernel BUG at mm/filemap.c:1563!  folio_end_read+0x140/0x168  f2fs_finish_read_bio+0x5c4/0xb80  f2fs_read_end_io+0x64c/0x708  bio_endio+0x85c/0x8c0  blk_update_request+0x690/0x127c  scsi_end_request+0x9c/0xb8c  scsi_io_completion+0xf0/0x250  scsi_finish_command+0x430/0x45c  scsi_complete+0x178/0x6d4  blk_mq_complete_request+0xcc/0x104  scsi_done_internal+0x214/0x454  scsi_done+0x24/0x34  which is similar to the problem reported by syzbot: https://syzkaller.appspot.com/bug?extid=3686758660f980b402dc  This case is consistent with the description in commit 9bf1a3f ("f2fs: avoid GC causing encrypted file corrupted"): Page 1 is moved from blkaddr A to blkaddr B by move_data_block, and after being written it is marked as uptodate. Then, Page 1 is moved from blkaddr B to blkaddr C, VM_BUG_ON_FOLIO was triggered in the endio initiated by ra_data_block.  There is no need to read Page 1 again from blkaddr B, since it has already been updated. Therefore, avoid initiating I/O in this case.

CVE-2026-53024:

        In the Linux kernel, the following vulnerability has been resolved:  greybus: raw: fix use-after-free if write is called after disconnect  If a user writes to the chardev after disconnect has been called, the kernel panics with the following trace (with CONFIG_INIT_ON_FREE_DEFAULT_ON=y):          BUG: kernel NULL pointer dereference, address: 0000000000000218          ...         Call Trace:          <TASK>          gb_operation_create_common+0x61/0x180          gb_operation_create_flags+0x28/0xa0          gb_operation_sync_timeout+0x6f/0x100          raw_write+0x7b/0xc7 [gb_raw]          vfs_write+0xcf/0x420          ? task_mm_cid_work+0x136/0x220          ksys_write+0x63/0xe0          do_syscall_64+0xa4/0x290          entry_SYSCALL_64_after_hwframe+0x77/0x7f  Disconnect calls gb_connection_destroy, which ends up freeing the connection object. When gb_operation_sync is called in the write file operations, its gets a freed connection as parameter and the kernel panics.  The gb_connection_destroy cannot be moved out of the disconnect function, as the Greybus subsystem expect all connections belonging to a bundle to be destroyed when disconnect returns.  To prevent this bug, use a rw lock to synchronize access between write and disconnect. This guarantees that the write function doesn't try to use a disconnected connection.

CVE-2026-53025:

        In the Linux kernel, the following vulnerability has been resolved:  greybus: raw: fix use-after-free on cdev close  This addresses a use-after-free bug when a raw bundle is disconnected but its chardev is still opened by an application. When the application releases the cdev, it causes the following panic when init on free is enabled (CONFIG_INIT_ON_FREE_DEFAULT_ON=y):          refcount_t: underflow; use-after-free.         WARNING: CPU: 0 PID: 139 at lib/refcount.c:28 refcount_warn_saturate+0xd0/0x130          ...         Call Trace:          <TASK>          cdev_put+0x18/0x30          __fput+0x255/0x2a0          __x64_sys_close+0x3d/0x80          do_syscall_64+0xa4/0x290          entry_SYSCALL_64_after_hwframe+0x77/0x7f  The cdev is contained in the "gb_raw" structure, which is freed in the disconnect operation. When the cdev is released at a later time, cdev_put gets an address that points to freed memory.  To fix this use-after-free, convert the struct device from a pointer to being embedded, that makes the lifetime of the cdev and of this device the same. Then, use cdev_device_add, which guarantees that the device won't be released until all references to the cdev have been released. Finally, delegate the freeing of the structure to the device release function, instead of freeing immediately in the disconnect callback.

CVE-2026-53027:

        In the Linux kernel, the following vulnerability has been resolved:  fs/ntfs3: fix missing run load for vcn0 in attr_data_get_block_locked()  When a compressed or sparse attribute has its clusters frame-aligned, vcn is rounded down to the frame start using cmask, which can result in vcn != vcn0. In this case, vcn and vcn0 may reside in different attribute segments.  The code already handles the case where vcn is in a different segment by loading its runs before allocation. However, it fails to load runs for vcn0 when vcn0 resides in a different segment than vcn. This causes run_lookup_entry() to return SPARSE_LCN for vcn0 since its segment was never loaded into the in-memory run list, triggering the WARN_ON(1).  Fix this by adding a missing check for vcn0 after the existing vcn segment check. If vcn0 falls outside the current segment range [svcn, evcn1), find and load the attribute segment containing vcn0 before performing the run lookup.  The following scenario triggers the bug:   attr_data_get_block_locked()     vcn = vcn0 & cmask        <- vcn != vcn0 after frame alignment     load runs for vcn segment <- vcn0 segment not loaded!     attr_allocate_clusters()  <- allocation succeeds     run_lookup_entry(vcn0)    <- vcn0 not in run -> SPARSE_LCN     WARN_ON(1)                <- bug fires here!

CVE-2026-53053:

        In the Linux kernel, the following vulnerability has been resolved:  iommu/amd: Fix clone_alias() to use the original device's devid  Currently clone_alias() assumes first argument (pdev) is always the original device pointer. This function is called by pci_for_each_dma_alias() which based on topology decides to send original or alias device details in first argument.  This meant that the source devid used to look up and copy the DTE may be incorrect, leading to wrong or stale DTE entries being propagated to alias device.  Fix this by passing the original pdev as the opaque data argument to both the direct clone_alias() call and pci_for_each_dma_alias(). Inside clone_alias(), retrieve the original device from data and compute devid from it.

CVE-2026-53070:

        In the Linux kernel, the following vulnerability has been resolved:  sctp: disable BH before calling udp_tunnel_xmit_skb()  udp_tunnel_xmit_skb() / udp_tunnel6_xmit_skb() are expected to run with BH disabled.  After commit 6f1a9140ecda ("add xmit recursion limit to tunnel xmit functions"), on the path:    udp(6)_tunnel_xmit_skb() -> ip(6)tunnel_xmit()  dev_xmit_recursion_inc()/dec() must stay balanced on the same CPU.  Without local_bh_disable(), the context may move between CPUs, which can break the inc/dec pairing. This may lead to incorrect recursion level detection and cause packets to be dropped in ip(6)_tunnel_xmit() or __dev_queue_xmit().  Fix it by disabling BH around both IPv4 and IPv6 SCTP UDP xmit paths.  In my testing, after enabling the SCTP over UDP:    # ip net exec ha sysctl -w net.sctp.udp_port=9899   # ip net exec ha sysctl -w net.sctp.encap_port=9899   # ip net exec hb sysctl -w net.sctp.udp_port=9899   # ip net exec hb sysctl -w net.sctp.encap_port=9899    # ip net exec ha iperf3 -s  - without this patch:    # ip net exec hb iperf3 -c 192.168.0.1 --sctp   [  5]   0.00-10.00  sec  37.2 MBytes  31.2 Mbits/sec  sender   [  5]   0.00-10.00  sec  37.1 MBytes  31.1 Mbits/sec  receiver  - with this patch:    # ip net exec hb iperf3 -c 192.168.0.1 --sctp   [  5]   0.00-10.00  sec  3.14 GBytes  2.69 Gbits/sec  sender   [  5]   0.00-10.00  sec  3.14 GBytes  2.69 Gbits/sec  receiver

CVE-2026-53076:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: Fix OOB in pcpu_init_value  An out-of-bounds read occurs when copying element from a BPF_MAP_TYPE_CGROUP_STORAGE map to another pcpu map with the same value_size that is not rounded up to 8 bytes.  The issue happens when: 1. A CGROUP_STORAGE map is created with value_size not aligned to    8 bytes (e.g., 4 bytes) 2. A pcpu map is created with the same value_size (e.g., 4 bytes) 3. Update element in 2 with data in 1  pcpu_init_value assumes that all sources are rounded up to 8 bytes, and invokes copy_map_value_long to make a data copy, However, the assumption doesn't stand since there are some cases where the source may not be rounded up to 8 bytes, e.g., CGROUP_STORAGE, skb->data. the verifier verifies exactly the size that the source claims, not the size rounded up to 8 bytes by kernel, an OOB happens when the source has only 4 bytes while the copy size(4) is rounded up to 8.

CVE-2026-53083:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: Fix RCU stall in bpf_fd_array_map_clear()  Add a missing cond_resched() in bpf_fd_array_map_clear() loop.  For PROG_ARRAY maps with many entries this loop calls prog_array_map_poke_run() per entry which can be expensive, and without yielding this can cause RCU stalls under load:    rcu: Stack dump where RCU GP kthread last ran:   CPU: 0 UID: 0 PID: 30932 Comm: kworker/0:2 Not tainted 6.14.0-13195-g967e8def1100 #2 PREEMPT(undef)   Workqueue: events prog_array_map_clear_deferred   RIP: 0010:write_comp_data+0x38/0x90 kernel/kcov.c:246   Call Trace:    <TASK>    prog_array_map_poke_run+0x77/0x380 kernel/bpf/arraymap.c:1096    __fd_array_map_delete_elem+0x197/0x310 kernel/bpf/arraymap.c:925    bpf_fd_array_map_clear kernel/bpf/arraymap.c:1000 [inline]    prog_array_map_clear_deferred+0x119/0x1b0 kernel/bpf/arraymap.c:1141    process_one_work+0x898/0x19d0 kernel/workqueue.c:3238    process_scheduled_works kernel/workqueue.c:3319 [inline]    worker_thread+0x770/0x10b0 kernel/workqueue.c:3400    kthread+0x465/0x880 kernel/kthread.c:464    ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:153    ret_from_fork_asm+0x19/0x30 arch/x86/entry/entry_64.S:245    </TASK>

CVE-2026-53091:

        In the Linux kernel, the following vulnerability has been resolved:  net: pull headers in qdisc_pkt_len_segs_init()  Most ndo_start_xmit() methods expects headers of gso packets to be already in skb->head.  net/core/tso.c users are particularly at risk, because tso_build_hdr() does a memcpy(hdr, skb->data, hdr_len);  qdisc_pkt_len_segs_init() already does a dissection of gso packets.  Use pskb_may_pull() instead of skb_header_pointer() to make sure drivers do not have to reimplement this.  Some malicious packets could be fed, detect them so that we can drop them sooner with a new SKB_DROP_REASON_SKB_BAD_GSO drop_reason.

CVE-2026-53102:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: mt76: Fix memory leak after mt76_connac_mcu_alloc_sta_req()  mt76_connac_mcu_alloc_sta_req() allocates an skb which is expected to be freed eventually by mt76_mcu_skb_send_msg(). However, currently if an intermediate function fails before sending, the allocated skb is leaked.  Specifically, mt76_connac_mcu_sta_wed_update() and mt76_connac_mcu_sta_key_tlv() may fail, leading to an immediate memory leak in the error path.  Fix this by explicitly freeing the skb in these error paths. Commit 7c0f63fe37a5 ("wifi: mt76: mt7996: fix memory leak on mt7996_mcu_sta_key_tlv error") made a similar change.  Compile tested only. Issue found using a prototype static analysis tool and code review.

CVE-2026-53106:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: Do not allow deleting local storage in NMI  Currently, local storage may deadlock when deferring freeing selem or local storage through kfree_rcu(), call_rcu() or call_rcu_tasks_trace() in NMI or reentrant. Since deleting selem in NMI is an unlikely use case, partially mitigate it by returning error when calling from bpf_xxx_storage_delete() helpers in NMI. Note that, it is still possible to deadlock through reentrant. A full mitigation requires returning error when irqs_disabled() is true, which, however is too heavy-handed for bpf_xxx_storage_delete().  The long-term solution requires _nolock versions of call_rcu. Another possible solution is to defer the free through irq_work [0], but it would grow the size of selem, which is non-ideal.  The check is only needed in bpf_selem_unlink(), which is used by helpers and syscalls. bpf_selem_unlink_nofail() is fine as it is called during map and owner tear down that never run in NMI or reentrant.  [0] https://lore.kernel.org/bpf/20260205190233.912-1-alexei.starovoitov@gmail.com/

CVE-2026-53107:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: libertas: don't kill URBs in interrupt context  Serialization for the TX path was enforced by calling usb_kill_urb()/usb_kill_anchored_urbs(), to prevent transmission before a previous URB was completed. usb_tx_block() can be called from interrupt context (e.g. in the HCD giveback path), so we can't always use it to kill in-flight URBs.  Prevent sleeping during interrupt context by checking the tx_submitted anchor for existing URBs. We now return -EBUSY, to indicate there's a pending request.

CVE-2026-53108:

        In the Linux kernel, the following vulnerability has been resolved:  powerpc/64s: Fix unmap race with PMD migration entries  The following race is possible with migration swap entries or device-private THP entries. e.g. when move_pages is called on a PMD THP page, then there maybe an intermediate state, where PMD entry acts as a migration swap entry (pmd_present() is true). Then if an munmap happens at the same time, then this VM_BUG_ON() can happen in pmdp_huge_get_and_clear_full().  This patch fixes that.  Thread A: move_pages() syscall   add_folio_for_migration()     mmap_read_lock(mm)     folio_isolate_lru(folio)     mmap_read_unlock(mm)    do_move_pages_to_node()     migrate_pages()       try_to_migrate_one()         spin_lock(ptl)         set_pmd_migration_entry()           pmdp_invalidate()     # PMD: _PAGE_INVALID | _PAGE_PTE | pfn           set_pmd_at()          # PMD: migration swap entry (pmd_present=0)         spin_unlock(ptl)         [page copy phase]       # <--- RACE WINDOW -->  Thread B: munmap()   mmap_write_downgrade(mm)   unmap_vmas() -> zap_pmd_range()     zap_huge_pmd()       __pmd_trans_huge_lock()         pmd_is_huge():          # !pmd_present && !pmd_none -> TRUE (swap entry)         pmd_lock() -> 		# spin_lock(ptl), waits for Thread A to release ptl       pmdp_huge_get_and_clear_full()         VM_BUG_ON(!pmd_present(*pmdp))  # HITS!  [  287.738700][ T1867] ------------[ cut here ]------------ [  287.743843][ T1867] kernel BUG at arch/powerpc/mm/book3s64/pgtable.c:187! cpu 0x0: Vector: 700 (Program Check) at [c00000044037f4f0]     pc: c000000000094ca4: pmdp_huge_get_and_clear_full+0x6c/0x23c     lr: c000000000645dec: zap_huge_pmd+0xb0/0x868     sp: c00000044037f790    msr: 800000000282b033   current = 0xc0000004032c1a00   paca    = 0xc000000004fe0000   irqmask: 0x03   irq_happened: 0x09     pid   = 1867, comm = a.out kernel BUG at :187! Linux version 6.19.0-12136-g14360d4f917c-dirty (powerpc64le-linux-gnu-gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #27 SMP PREEMPT Sun Feb 22 10:38:56 IST 2026 enter ? for help [link register   ] c000000000645dec zap_huge_pmd+0xb0/0x868 [c00000044037f790] c00000044037f7d0 (unreliable) [c00000044037f7d0] c000000000645dcc zap_huge_pmd+0x90/0x868 [c00000044037f840] c0000000005724cc unmap_page_range+0x176c/0x1f40 [c00000044037fa00] c000000000572ea0 unmap_vmas+0xb0/0x1d8 [c00000044037fa90] c0000000005af254 unmap_region+0xb4/0x128 [c00000044037fb50] c0000000005af400 vms_complete_munmap_vmas+0x138/0x310 [c00000044037fbe0] c0000000005b0f1c do_vmi_align_munmap+0x1ec/0x238 [c00000044037fd30] c0000000005b3688 __vm_munmap+0x170/0x1f8 [c00000044037fdf0] c000000000587f74 sys_munmap+0x2c/0x40 [c00000044037fe10] c000000000032668 system_call_exception+0x128/0x350 [c00000044037fe50] c00000000000d05c system_call_vectored_common+0x15c/0x2ec ---- Exception: 3000 (System Call Vectored) at 0000000010064a2c SP (7fff9b1ee9c0) is in userspace 0:mon> zh  commit a30b48bf1b24 ("mm/migrate_device: implement THP migration of zone device pages"), enabled migration for device-private PMD entries. Hence this is one other path where this warning could get trigger from.   ------------[ cut here ]------------  WARNING: arch/powerpc/mm/book3s64/hash_pgtable.c:199 at hash__pmd_hugepage_update+0x48/0x284, CPU#3: hmm-tests/1905  Modules linked in: test_hmm  CPU: 3 UID: 0 PID: 1905 Comm: hmm-tests Tainted: G    B   W    L   N  7.0.0-rc1-01438-g7e2f0ee7581c #21 PREEMPT  Tainted: [B]=BAD_PAGE, [W]=WARN, [L]=SOFTLOCKUP, [N]=TEST  Hardware name: IBM pSeries (emulated by qemu) POWER10 (architected) 0x801200 0xf000006 of:SLOF,git-ee03ae pSeries  NIP [c000000000096b70] hash__pmd_hugepage_update+0x48/0x284  LR [c000000000096e7c] hash__pmdp_huge_get_and_clear+0xd0/0xd4  Call Trace:  [c000000604707670] [c000000004e102b8] 0xc000000004e102b8 (unreliable)  [c000000604707700] [c00000000064ec3c] set_pmd_migration_entry+0x414/0x498  [c000000604707760] [c00000000063e5a4] migrate_vma_col ---truncated---

CVE-2026-53115:

        In the Linux kernel, the following vulnerability has been resolved:  bus: fsl-mc: use generic driver_override infrastructure  When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF.  Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally.  Note that calling match() from __driver_attach() without the device lock held is intentional. [1]

CVE-2026-53117:

        In the Linux kernel, the following vulnerability has been resolved:  s390/cio: use generic driver_override infrastructure  When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF.  Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally.  Note that calling match() from __driver_attach() without the device lock held is intentional. [1]

CVE-2026-53118:

        In the Linux kernel, the following vulnerability has been resolved:  vdpa: use generic driver_override infrastructure  When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF.  Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally.  Note that calling match() from __driver_attach() without the device lock held is intentional. [1]

CVE-2026-53120:

        In the Linux kernel, the following vulnerability has been resolved:  PCI: use generic driver_override infrastructure  When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF.  Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally.  Note that calling match() from __driver_attach() without the device lock held is intentional. [1]

CVE-2026-53122:

        In the Linux kernel, the following vulnerability has been resolved:  btrfs: fix deadlock between reflink and transaction commit when using flushoncommit  When using the flushoncommit mount option, we can have a deadlock between a transaction commit and a reflink operation that copied an inline extent to an offset beyond the current i_size of the destination node.  The deadlock happens like this:  1) Task A clones an inline extent from inode X to an offset of inode Y    that is beyond Y's current i_size. This means we copied the inline    extent's data to a folio of inode Y that is beyond its EOF, using a    call to copy_inline_to_page();  2) Task B starts a transaction commit and calls    btrfs_start_delalloc_flush() to flush delalloc;  3) The delalloc flushing sees the new dirty folio of inode Y and when it    attempts to flush it, it ends up at extent_writepage() and sees that    the offset of the folio is beyond the i_size of inode Y, so it attempts    to invalidate the folio by calling folio_invalidate(), which ends up at    btrfs' folio invalidate callback - btrfs_invalidate_folio(). There it    tries to lock the folio's range in inode Y's extent io tree, but it    blocks since it's currently locked by task A - during a reflink we lock    the inodes and the source and destination ranges after flushing all    delalloc and waiting for ordered extent completion - after that we    don't expect to have dirty folios in the ranges, the exception is if    we have to copy an inline extent's data (because the destination offset    is not zero);  4) Task A then attempts to start a transaction to update the inode item,    and then it's blocked since the current transaction is in the    TRANS_STATE_COMMIT_START state. Therefore task A has to wait for the    current transaction to become unblocked (its state >=    TRANS_STATE_UNBLOCKED).     So task A is waiting for the transaction commit done by task B, and    the later waiting on the extent lock of inode Y that is currently    held by task A.  Syzbot recently reported this with the following stack traces:    INFO: task kworker/u8:7:1053 blocked for more than 143 seconds.         Not tainted syzkaller #0   "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.   task:kworker/u8:7    state:D stack:23520 pid:1053  tgid:1053  ppid:2      task_flags:0x4208060 flags:0x00080000   Workqueue: writeback wb_workfn (flush-btrfs-46)   Call Trace:    <TASK>    context_switch kernel/sched/core.c:5298 [inline]    __schedule+0x1553/0x5240 kernel/sched/core.c:6911    __schedule_loop kernel/sched/core.c:6993 [inline]    schedule+0x164/0x360 kernel/sched/core.c:7008    wait_extent_bit fs/btrfs/extent-io-tree.c:811 [inline]    btrfs_lock_extent_bits+0x59c/0x700 fs/btrfs/extent-io-tree.c:1914    btrfs_lock_extent fs/btrfs/extent-io-tree.h:152 [inline]    btrfs_invalidate_folio+0x43d/0xc40 fs/btrfs/inode.c:7704    extent_writepage fs/btrfs/extent_io.c:1852 [inline]    extent_write_cache_pages fs/btrfs/extent_io.c:2580 [inline]    btrfs_writepages+0x12ff/0x2440 fs/btrfs/extent_io.c:2713    do_writepages+0x32e/0x550 mm/page-writeback.c:2554    __writeback_single_inode+0x133/0x11a0 fs/fs-writeback.c:1750    writeback_sb_inodes+0x995/0x19d0 fs/fs-writeback.c:2042    wb_writeback+0x456/0xb70 fs/fs-writeback.c:2227    wb_do_writeback fs/fs-writeback.c:2374 [inline]    wb_workfn+0x41a/0xf60 fs/fs-writeback.c:2414    process_one_work kernel/workqueue.c:3276 [inline]    process_scheduled_works+0xb6e/0x18c0 kernel/workqueue.c:3359    worker_thread+0xa53/0xfc0 kernel/workqueue.c:3440    kthread+0x388/0x470 kernel/kthread.c:436    ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158    ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245    </TASK>   INFO: task syz.4.64:6910 blocked for more than 143 seconds.         Not tainted syzkaller #0   "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.   task:syz.4.64        state:D stack:22752 pid:6910  tgid: ---truncated---

CVE-2026-53129:

        In the Linux kernel, the following vulnerability has been resolved:  fs/mbcache: cancel shrink work before destroying the cache  mb_cache_destroy() calls shrinker_free() and then frees all cache entries and the cache itself, but it does not cancel the pending c_shrink_work work item first.  If mb_cache_entry_create() schedules c_shrink_work via schedule_work() and the work item is still pending or running when mb_cache_destroy() runs, mb_cache_shrink_worker() will access the cache after its memory has been freed, causing a use-after-free.  This is only reachable by a privileged user (root or CAP_SYS_ADMIN) who can trigger the last put of a mounted ext2/ext4/ocfs2 filesystem.  Cancel the work item with cancel_work_sync() before calling shrinker_free(), ensuring the worker has finished and will not be rescheduled before the cache is torn down.

CVE-2026-53132:

        In the Linux kernel, the following vulnerability has been resolved:  vsock/virtio: fix potential unbounded skb queue  virtio_transport_inc_rx_pkt() checks vvs->rx_bytes + len > vvs->buf_alloc.  virtio_transport_recv_enqueue() skips coalescing for packets with VIRTIO_VSOCK_SEQ_EOM.  If fed with packets with len == 0 and VIRTIO_VSOCK_SEQ_EOM, a very large number of packets can be queued because vvs->rx_bytes stays at 0.  Fix this by estimating the skb metadata size:  	(Number of skbs in the queue) * SKB_TRUESIZE(0)

CVE-2026-53143:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdkfd: Fix buffer overflow in SDMA queue checkpoint/restore on GFX11  The v11 MQD manager incorrectly assigned the CP-compute variants of checkpoint_mqd/restore_mqd for KFD_MQD_TYPE_SDMA queues. These functions use sizeof(struct v11_compute_mqd) (2048 bytes) instead of sizeof(struct v11_sdma_mqd) (512 bytes), causing a 1536-byte overflow.  During CRIU checkpoint of an SDMA queue on Navi3x: - checkpoint_mqd() reads 2048 bytes from a 512-byte SDMA MQD buffer,   leaking 1536 bytes of adjacent GTT memory to userspace  During CRIU restore: - restore_mqd() writes 2048 bytes into a 512-byte SDMA MQD buffer,   corrupting 1536 bytes of adjacent GTT memory (often the ring buffer   or neighboring MQDs)  This is a copy-paste regression unique to v11. All other ASIC backends (cik, vi, v9, v10, v12) correctly use the SDMA-specific variants.  Add checkpoint_mqd_sdma() and restore_mqd_sdma() functions that properly handle the smaller v11_sdma_mqd structure, matching the pattern used in other MQD managers.  (cherry picked from commit 6fa41db7ffdec97d62433adf03b7b9b759af8c2c)

CVE-2026-53156:

        In the Linux kernel, the following vulnerability has been resolved:  nvmem: core: fix use-after-free bugs in error paths  Fix several instances of error paths in which we call __nvmem_device_put() - which may end up freeing the underlying memory and other resources - and then keep on using the nvmem structure. Always put the reference to the nvmem device as the last step before returning the error code.

CVE-2026-53178:

        In the Linux kernel, the following vulnerability has been resolved:  staging: rtl8723bs: rtw_mlme: add bounds checks before ie_length subtraction  Add guards to ensure ie_length is large enough before subtracting fixed IE offsets to prevent unsigned integer underflow.

CVE-2026-53179:

        In the Linux kernel, the following vulnerability has been resolved:  staging: rtl8723bs: fix buffer over-read in rtw_update_protection  rtw_update_protection() is called with a pointer offset into the ies buffer but the full ie_length is passed, causing a potential buffer over-read.

CVE-2026-53185:

        In the Linux kernel, the following vulnerability has been resolved:  zram: fix use-after-free in zram_bvec_write_partial()  zram_read_page() picks the sync or async backing device read path based on whether the parent bio is NULL.  zram_bvec_write_partial() passes its parent bio down, so for ZRAM_WB slots the read is dispatched asynchronously and zram_read_page() returns 0 while the bio is still in flight.  The caller then runs memcpy_from_bvec(), zram_write_page() and __free_page() on the buffer, leaving the async read to write into a freed page.  zram_bvec_read_partial() was switched to NULL in commit 4e3c87b9421d ("zram: fix synchronous reads") for the same reason; the write_partial counterpart was missed.

CVE-2026-53220:

        In the Linux kernel, the following vulnerability has been resolved:  netfilter: revalidate bridge ports  ebt_redirect_tg() dereferences br_port_get_rcu() return without a NULL check, causing a kernel panic when the bridge port has been removed between the original hook invocation and an NFQUEUE reinject.  A mere NULL check isn't sufficient, however.  As sashiko review points out userspace can not only remove the port from the bridge, it could also place the device in a different virtual device, e.g. macvlan.  If this happens, we must drop the packet, there is no way for us to reinject it into the bridge path.  Switch to _upper API, we don't need the bridge port structure. Also, this fix keeps another bug intact:  Both nfnetlink_log and nfnetlink_queue use CONFIG_BRIDGE_NETFILTER too aggressive, which prevents certain logging features when queueing in bridge family: NETFILTER_FAMILY_BRIDGE can be enabled while the old CONFIG_BRIDGE_NETFILTER cruft is off.  Fixes tag is a common ancestor, this was always broken.

CVE-2026-53224:

        In the Linux kernel, the following vulnerability has been resolved:  sctp: validate embedded INIT chunk and address list lengths in cookie  sctp_unpack_cookie() only checked that the embedded INIT chunk length did not exceed the remaining cookie payload, but did not ensure that the INIT chunk is large enough to contain a complete INIT header.  A malformed COOKIE_ECHO can therefore carry a truncated INIT chunk whose length field is smaller than sizeof(struct sctp_init_chunk).  Later, sctp_process_init() accesses INIT parameters unconditionally, which may lead to out-of-bounds reads.  In addition, raw_addr_list_len is not fully validated against the remaining cookie payload. When cookie authentication is disabled, an attacker can supply an oversized raw_addr_list_len and cause sctp_raw_to_bind_addrs() to read beyond the end of the cookie. The address parser also lacks sufficient bounds checks for parameter headers and lengths, allowing malformed address parameters to trigger out-of-bounds reads.  Fix this by:  - requiring the embedded INIT chunk length to be at least sizeof(struct   sctp_init_chunk); - validating that the INIT chunk and raw address list together fit   within the cookie payload; - verifying sufficient data exists for each address parameter header and   payload before parsing it.  Note that sctp_verify_init() must be called after sctp_unpack_cookie() and before sctp_process_init() when cookie authentication is disabled. This will be addressed in a separate patch.

CVE-2026-53226:

        In the Linux kernel, the following vulnerability has been resolved:  gpio: rockchip: fix generic IRQ chip leak on remove  The driver allocates domain generic chips using irq_alloc_domain_generic_chips() during probe. However, on driver remove/teardown, the generic chips are not automatically freed when the IRQ domain is removed because the domain flags do not include IRQ_DOMAIN_FLAG_DESTROY_GC.  This causes both the domain generic chips structure and the associated generic chips to be leaked. Additionally, the generic chips remain on the global gc_list and may later be visited by generic IRQ chip suspend, resume, or shutdown callbacks after the GPIO bank has been removed, potentially resulting in a use-after-free and kernel crash.  Fix the resource leak by explicitly calling irq_domain_remove_generic_chips() before removing the IRQ domain in rockchip_gpio_remove().

CVE-2026-53229:

        In the Linux kernel, the following vulnerability has been resolved:  net/mlx5e: xsk: Fix DMA and xdp_frame leak on XDP_TX xmit failure  In the XSK branch of mlx5e_xmit_xdp_buff(), when sq->xmit_xdp_frame() returns false (e.g. XDPSQ is full), the function returns without unmapping the DMA address or freeing the xdp_frame allocated by xdp_convert_zc_to_xdp_frame(). The xdpi_fifo push only happens on success, so the completion path cannot recover these entries.  With CONFIG_DMA_API_DEBUG=y, the leak surfaces on driver unbind:    DMA-API: pci 0000:08:00.0: device driver has pending DMA   allocations while released from device [count=1116]   One of leaked entries details: [device address=0x000000010ffd7028]   [size=1534 bytes] [mapped with DMA_TO_DEVICE] [mapped as phy]   WARNING: kernel/dma/debug.c:881 at dma_debug_device_change+0x127/0x180   ...   DMA-API: Mapped at:    debug_dma_map_phys+0x4b/0xd0    dma_map_phys+0xfd/0x2d0    mlx5e_xdp_handle+0x5ae/0xac0 [mlx5_core]    mlx5e_xsk_skb_from_cqe_mpwrq_linear+0xc4/0x170 [mlx5_core]    mlx5e_handle_rx_cqe_mpwrq+0xc1/0x290 [mlx5_core]  Add the missing unmap + xdp_return_frame, matching the cleanup already done in mlx5e_xdp_xmit(). has_frags is rejected earlier in this branch, so no per-frag unmap is needed.

CVE-2026-53230:

        In the Linux kernel, the following vulnerability has been resolved:  net/mlx5: Fix slab-out-of-bounds in mlx5_query_nic_vport_mac_list  mlx5_query_nic_vport_mac_list() sizes its firmware command buffer using the PF's log_max_current_uc/mc_list capabilities. When querying a VF vport with a larger configured max (via devlink), the firmware response can overflow this buffer:   BUG: KASAN: slab-out-of-bounds in mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core]  Read of size 4 at addr ff1100013ffc8a12 by task kworker/u96:2/385   CPU: 12 UID: 0 PID: 385 Comm: kworker/u96:2 Not tainted 7.0.0-rc6+ #1 PREEMPT  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009)  Workqueue: mlx5_esw_wq esw_vport_change_handler [mlx5_core]  Call Trace:   <TASK>   dump_stack_lvl+0x69/0xa0   print_report+0x176/0x4e4   kasan_report+0xc8/0x100   mlx5_query_nic_vport_mac_list+0x453/0x4c0 [mlx5_core]   esw_update_vport_addr_list+0x2e3/0xda0 [mlx5_core]   esw_vport_change_handle_locked+0xa1f/0x1060 [mlx5_core]   esw_vport_change_handler+0x6a/0x90 [mlx5_core]   process_one_work+0x87f/0x15e0   worker_thread+0x62b/0x1020   kthread+0x375/0x490   ret_from_fork+0x4dc/0x810   ret_from_fork_asm+0x11/0x20   </TASK>  Fix by querying the vport's own HCA caps to size the buffer correctly. Refactor the function to allocate and return the MAC list internally, removing the caller's dependency on knowing the correct max.

CVE-2026-53232:

        In the Linux kernel, the following vulnerability has been resolved:  net: phy: clean the sfp upstream if phy probing fails  Sashiko reported that we don't call sfp_bus_del_upstream() in the probe failure path, so let's add it, otherwise the sfp-bus is left with a dangling 'upstream' field, that may be used later on during SFP events.  This issue existed before the generic phylib sfp support, back when drivers were calling phy_sfp_probe themselves.

CVE-2026-53237:

        In the Linux kernel, the following vulnerability has been resolved:  gpio: mvebu: fix NULL pointer dereference in suspend/resume  mvebu_pwm_suspend() and mvebu_pwm_resume() are called for all GPIO banks during suspend/resume, but not all banks have PWM functionality. GPIO banks without PWM have mvchip->mvpwm set to NULL.  Calling mvebu_pwm_suspend() with mvpwm == NULL causes a NULL pointer dereference when it tries to access mvpwm->blink_select.    Unable to handle kernel NULL pointer dereference at virtual address 00000020 when write   [00000020] *pgd=00000000   Internal error: Oops: 815 [#1] PREEMPT ARM   Modules linked in:   CPU: 0 UID: 0 PID: 406 Comm: sh Not tainted 6.12.74-rt12-yocto-standard-g4e96f98fb7db-dirty #353   Hardware name: Marvell Armada 370/XP (Device Tree)   PC is at regmap_mmio_read+0x38/0x54   LR is at regmap_mmio_read+0x38/0x54   pc : [<c05fd2ac>]    lr : [<c05fd2ac>]    psr: 200f0013   sp : f0c11d10  ip : 00000000  fp : c100d2f0   r10: c14fb854  r9 : 00000000  r8 : 00000000   r7 : c1799c00  r6 : 00000020  r5 : 00000020  r4 : c179c7c0   r3 : f0a231a0  r2 : 00000020  r1 : 00000020  r0 : 00000000   Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none   Control: 10c5387d  Table: 135ec059  DAC: 00000051   Call trace:    regmap_mmio_read from _regmap_bus_reg_read+0x78/0xac    _regmap_bus_reg_read from _regmap_read+0x60/0x154    _regmap_read from regmap_read+0x3c/0x60    regmap_read from mvebu_gpio_suspend+0xa4/0x14c    mvebu_gpio_suspend from dpm_run_callback+0x54/0x180    dpm_run_callback from device_suspend+0x124/0x630    device_suspend from dpm_suspend+0x124/0x270    dpm_suspend from dpm_suspend_start+0x64/0x6c    dpm_suspend_start from suspend_devices_and_enter+0x140/0x8e8    suspend_devices_and_enter from pm_suspend+0x2fc/0x308    pm_suspend from state_store+0x6c/0xc8    state_store from kernfs_fop_write_iter+0x10c/0x1f8    kernfs_fop_write_iter from vfs_write+0x270/0x468    vfs_write from ksys_write+0x70/0xf0    ksys_write from ret_fast_syscall+0x0/0x54  Add a NULL check for mvchip->mvpwm before calling the PWM suspend/resume functions.

CVE-2026-53246:

        In the Linux kernel, the following vulnerability has been resolved:  sctp: validate cached peer INIT chunk length in COOKIE_ECHO processing  When a listening SCTP server processes a COOKIE_ECHO chunk, the cached peer INIT chunk embedded after the cookie is parsed and its parameters are later walked by sctp_process_init() using sctp_walk_params().  However, the chunk header length of this cached INIT chunk was not validated against the remaining buffer in the COOKIE_ECHO payload. If the length field is inflated, the parameter walk can run beyond the actual received data, leading to out-of-bounds reads and potential memory corruption during later parameter handling (e.g. STATE_COOKIE processing and kmemdup() copies).  Add a bounds check in sctp_unpack_cookie() to ensure the cached INIT chunk length does not exceed the available data in the COOKIE_ECHO buffer before it is used.

CVE-2026-53258:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: fix leak if split 6 GHz scanning fails  rdev->int_scan_req is leaked if cfg80211_scan() fails.  Note that it's supposed to be released at ___cfg80211_scan_done() but this doesn't happen as rdev->scan_req is NULL at that point, too, leading to the early return from the freeing function.  unreferenced object 0xffff8881161d0800 (size 512):   comm "wpa_supplicant", pid 379, jiffies 4294749765   hex dump (first 32 bytes):     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................     00 00 00 00 00 00 00 00 f0 81 13 16 81 88 ff ff  ................   backtrace (crc c867fdb6):     kmemleak_alloc+0x89/0x90     __kmalloc_noprof+0x2fd/0x410     cfg80211_scan+0x133/0x730     nl80211_trigger_scan+0xc69/0x1cc0     genl_family_rcv_msg_doit+0x204/0x2f0     genl_rcv_msg+0x431/0x6b0     netlink_rcv_skb+0x143/0x3f0     genl_rcv+0x27/0x40     netlink_unicast+0x4f6/0x820     netlink_sendmsg+0x797/0xce0     __sock_sendmsg+0xc4/0x160     ____sys_sendmsg+0x5e4/0x890     ___sys_sendmsg+0xf8/0x180     __sys_sendmsg+0x136/0x1e0     __x64_sys_sendmsg+0x76/0xc0     x64_sys_call+0x13f0/0x17d0  Found by Linux Verification Center (linuxtesting.org).

CVE-2026-53262:

        In the Linux kernel, the following vulnerability has been resolved:  l2tp: pppol2tp: hold reference to session in pppol2tp_ioctl()  pppol2tp_ioctl() read sock->sk->sk_user_data directly without any locks or reference counting.  If a controllable sleep was induced during copy_from_user() (e.g. via a userfaultfd page fault sleep), a concurrent socket close could trigger pppol2tp_session_close() asynchronously.  This frees the l2tp_session structure via the l2tp_session_del_work workqueue. Upon resuming, the ioctl thread dereferences the stale session pointer, resulting in a Use-After-Free (UAF).  Fix this by securely fetching the session reference using the RCU-safe, refcounted helper pppol2tp_sock_to_session(sk) on entry.  This locks the session's refcount across the sleep.  We structured the function to exit via standard err breaks, guaranteeing that l2tp_session_put() is cleanly called on all return paths to drop the reference.  To preserve existing behavior we validate the session and its magic signature only for the specific L2TP commands that require it.  This ensures that generic/unknown ioctls called on an unconnected socket still return -ENOIOCTLCMD and correctly fall back to generic handlers (e.g. in sock_do_ioctl()).

CVE-2026-53265:

        In the Linux kernel, the following vulnerability has been resolved:  dm cache policy smq: check allocation under invalidate lock  commit 2d1f7b65f5de ("dm cache policy smq: fix missing locks in invalidating cache blocks") added mq->lock around the destructive part of smq_invalidate_mapping(), but left the e->allocated check outside the critical section.  That leaves a check-then-act race. Two concurrent invalidators can both observe e->allocated as true before either of them takes mq->lock. The first invalidator that acquires the lock removes the entry from the queues and hash table and then calls free_entry(), which clears e->allocated and puts the entry back on the free list. The second invalidator can then acquire mq->lock and continue with the stale result of the unlocked check.  This can corrupt the SMQ queues or hash table by deleting an entry that is no longer on those structures. It can also hit the allocation check in free_entry() when the same entry is freed again.  Move the allocation check under mq->lock so the predicate and the destructive operations are serialized by the same lock.

CVE-2026-53267:

        In the Linux kernel, the following vulnerability has been resolved:  netfilter: nft_ct: bail out on template ct in get eval  I noticed this issue while looking at a historic syzbot report [1].  A rule like the one below is enough to trigger the bug:      table ip t {         chain pre {             type filter hook prerouting priority raw;             ct zone set 1             ct original saddr 1.2.3.4 accept         }     }  The first expression attaches a per-cpu template ct via nft_ct_set_zone_eval() (nf_ct_tmpl_alloc -> kzalloc, tuple is all zero, nf_ct_l3num(ct) == 0). The next expression then calls nft_ct_get_eval() on the same skb, treats the template as a real ct and hits the 16-byte memcpy path. With dreg at NFT_REG32_15 this overflows past struct nft_regs on the kernel stack; with smaller dreg values it silently clobbers adjacent registers.  Reject template ct at the eval entry and in nft_ct_get_fast_eval(), mirroring the check nft_ct_set_eval() already has. Additionally, bound the address copy in NFT_CT_SRC / NFT_CT_DST by priv->len instead of by nf_ct_l3num(ct): nf_ct_get_tuple() zeroes the tuple before pkt_to_tuple() fills in only the protocol-relevant leading bytes, so the trailing bytes of tuple->{src,dst}.u3.all are well-defined zero. priv->len is validated at rule load, so the copy size is now bounded by the destination register rather than by an untrusted field on the conntrack.  [1]: https://syzkaller.appspot.com/bug?id=389cf09cb72926114fce90dc85a2c3231dcb647c

CVE-2026-53272:

        In the Linux kernel, the following vulnerability has been resolved:  erofs: fix use-after-free on sbi->sync_decompress  z_erofs_decompress_kickoff() can race with filesystem unmount, causing a use-after-free on sbi->sync_decompress.  When I/O completes, z_erofs_endio() calls z_erofs_decompress_kickoff() to queue z_erofs_decompressqueue_work() asynchronously. Then, after all folios are unlocked, unmount workflow can proceed and sbi will be freed before accessing to sbi->sync_decompress.  Thread (unmount)        I/O completion        kworker                         queue_work                                               z_erofs_decompressqueue_work                                                (all folios are unlocked) cleanup_mnt  ..  erofs_kill_sb   erofs_sb_free    kfree(sbi)                         access sbi->sync_decompress  // UAF!!

CVE-2026-53284:

        In the Linux kernel, the following vulnerability has been resolved:  btrfs: only release the dirty pages io tree after successful writes  [WARNING] With extra warning on dirty extent buffers at umount (aka, the next patch in the series), test case generic/388 can trigger the following warning about dirty extent buffers at unmount time:    BTRFS critical (device dm-2 state E): emergency shutdown   BTRFS error (device dm-2 state E): error while writing out transaction: -30   BTRFS warning (device dm-2 state E): Skipping commit of aborted transaction.   BTRFS error (device dm-2 state EA): Transaction 9 aborted (error -30)   BTRFS: error (device dm-2 state EA) in cleanup_transaction:2068: errno=-30 Readonly filesystem   BTRFS info (device dm-2 state EA): forced readonly   BTRFS info (device dm-2 state EA): last unmount of filesystem 4fbf2e15-f941-49a0-bc7c-716315d2777c   ------------[ cut here ]------------   WARNING: disk-io.c:3311 at invalidate_and_check_btree_folios+0xfd/0x1ca [btrfs], CPU#8: umount/914368   CPU: 8 UID: 0 PID: 914368 Comm: umount Tainted: G           OE       7.1.0-rc1-custom+ #372 PREEMPT(full)  2de38db8d1deae71fde295430a0ff3ab98ccf596   Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022   RIP: 0010:invalidate_and_check_btree_folios+0xfd/0x1ca [btrfs]   Call Trace:    <TASK>    close_ctree+0x52e/0x574 [btrfs d2f0b1cd330d1287e7a9919d112eadfc0e914efd]    generic_shutdown_super+0x89/0x1a0    kill_anon_super+0x16/0x40    btrfs_kill_super+0x16/0x20 [btrfs d2f0b1cd330d1287e7a9919d112eadfc0e914efd]    deactivate_locked_super+0x2d/0xb0    cleanup_mnt+0xdc/0x140    task_work_run+0x5a/0xa0    exit_to_user_mode_loop+0x123/0x4b0    do_syscall_64+0x243/0x7c0    entry_SYSCALL_64_after_hwframe+0x4b/0x53    </TASK>   ---[ end trace 0000000000000000 ]---   BTRFS warning (device dm-2 state EA): unable to release extent buffer 30539776 owner 9 gen 9 refs 2 flags 0x7   BTRFS warning (device dm-2 state EA): unable to release extent buffer 30621696 owner 257 gen 9 refs 2 flags 0x7   BTRFS warning (device dm-2 state EA): unable to release extent buffer 30638080 owner 258 gen 9 refs 2 flags 0x7   BTRFS warning (device dm-2 state EA): unable to release extent buffer 30654464 owner 7 gen 9 refs 2 flags 0x7   BTRFS warning (device dm-2 state EA): unable to release extent buffer 30703616 owner 2 gen 9 refs 2 flags 0x7   BTRFS warning (device dm-2 state EA): unable to release extent buffer 30720000 owner 10 gen 9 refs 2 flags 0x7   BTRFS warning (device dm-2 state EA): unable to release extent buffer 30736384 owner 4 gen 9 refs 2 flags 0x7   BTRFS warning (device dm-2 state EA): unable to release extent buffer 30752768 owner 11 gen 9 refs 2 flags 0x7  I'm using a stripped down version, which seems to trigger the warning more reliably:    _fsstress_pid=""   workload()   {   	dmesg -C   	mkfs.btrfs -f -K $dev > /dev/null   	echo 1 > /sys/kernel/debug/clear_warn_once   	mount $dev $mnt   	$fsstress -w -n 1024 -p 4 -d $mnt &   	_fsstress_pid=$!   	sleep 0   	$godown $mnt   	pkill --echo -PIPE fsstress > /dev/null   	wait $_fsstress_pid   	unset _fsstress_pid   	umount $mnt    	if dmesg | grep -q "WARNING"; then   		fail   	fi   }    for (( i = 0; i < $runtime; i++ )); do   	echo "=== $i/$runtime ==="   	workload   done  [CAUSE] Inside btrfs_write_and_wait_transaction(), we first try to write all dirty ebs, then wait for them to finish.  After that we call btrfs_extent_io_tree_release() to free all extent states from dirty_pages io tree.  However if we hit an error from btrfs_write_marked_extent(), then we still call btrfs_extent_io_tree_release() to clear that dirty_pages io tree, which may contain dirty records that we haven't yet submitted.  Furthermore, the later transaction cleanup path will utilize that dirty_pages io tree to properly cleanup those dirty ebs, but since it's already empty, no dirty ebs are properly cleaned up, thus will later trigger the warnings inside invalidate_btree_folios(). ---truncated---

CVE-2026-53285:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Wrap DCN32 phantom-plane allocation in DC_RUN_WITH_PREEMPTION_ENABLED  [Why] dcn32_validate_bandwidth() wraps dcn32_internal_validate_bw() with DC_FP_START()/DC_FP_END(). In x86 non-RT, DC_FP_START takes fpregs_lock(), which disables local softirqs.  The DML1 path through dcn32_enable_phantom_plane() calls kvzalloc() to allocate ~335 KiB for dc_plane_state. This triggers the vmalloc path, which calls BUG_ON(in_interrupt()) because it's invoked within the FPU-enabled (softirq disabled) region, leading to a kernel crash.  [How] Wrap the dc_state_create_phantom_plane() call with the DC_RUN_WITH_PREEMPTION_ENABLED() macro to allow preemption during this memory allocation.  (cherry picked from commit 885ccbef7b94a8b38f69c4211c679021aa27ad11)

CVE-2026-53292:

        In the Linux kernel, the following vulnerability has been resolved:  net: phonet: do not BUG_ON() in pn_socket_autobind() on failed bind  syzbot reported a kernel BUG triggered from pn_socket_sendmsg() via pn_socket_autobind():    kernel BUG at net/phonet/socket.c:213!   RIP: 0010:pn_socket_autobind net/phonet/socket.c:213 [inline]   RIP: 0010:pn_socket_sendmsg+0x240/0x250 net/phonet/socket.c:421   Call Trace:    sock_sendmsg_nosec+0x112/0x150 net/socket.c:797    __sock_sendmsg net/socket.c:812 [inline]    __sys_sendto+0x402/0x590 net/socket.c:2280    ...  pn_socket_autobind() calls pn_socket_bind() with port 0 and, on -EINVAL, assumes the socket was already bound and asserts that the port is non-zero:    err = pn_socket_bind(sock, ..., sizeof(struct sockaddr_pn));   if (err != -EINVAL)           return err;   BUG_ON(!pn_port(pn_sk(sock->sk)->sobject));   return 0; /* socket was already bound */  However pn_socket_bind() also returns -EINVAL when sk->sk_state is not TCP_CLOSE, even when the socket has never been bound and pn_port() is still 0.  In that case the BUG_ON() fires and panics the kernel from a user-triggerable path.  Treat the "bind returned -EINVAL but pn_port() is still 0" case as a regular error and propagate -EINVAL to the caller instead of crashing. Existing callers already translate a non-zero return from pn_socket_autobind() into -ENOBUFS/-EAGAIN, so returning -EINVAL here only changes behaviour from panic to a normal errno.

CVE-2026-53297:

        In the Linux kernel, the following vulnerability has been resolved:  net: mana: Guard mana_remove against double invocation  If PM resume fails (e.g., mana_attach() returns an error), mana_probe() calls mana_remove(), which tears down the device and sets gd->gdma_context = NULL and gd->driver_data = NULL.  However, a failed resume callback does not automatically unbind the driver. When the device is eventually unbound, mana_remove() is invoked a second time. Without a NULL check, it dereferences gc->dev with gc == NULL, causing a kernel panic.  Add an early return if gdma_context or driver_data is NULL so the second invocation is harmless. Move the dev = gc->dev assignment after the guard so it cannot dereference NULL.

CVE-2026-53313:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Avoid NULL dereference in dc_dmub_srv error paths  In dc_dmub_srv_log_diagnostic_data() and dc_dmub_srv_enable_dpia_trace().  Both functions check:    if (!dc_dmub_srv || !dc_dmub_srv->dmub)  and then call DC_LOG_ERROR() inside that block.  DC_LOG_ERROR() uses dc_dmub_srv->ctx internally. So if dc_dmub_srv is NULL, the logging itself can dereference a NULL pointer and cause a crash.  Fix this by splitting the checks.  First check if dc_dmub_srv is NULL and return immediately. Then check dc_dmub_srv->dmub and log the error only when dc_dmub_srv is valid.  Fixes the below: ../display/dc/dc_dmub_srv.c:962 dc_dmub_srv_log_diagnostic_data() error: we previously assumed 'dc_dmub_srv' could be null (see line 961) ../display/dc/dc_dmub_srv.c:1167 dc_dmub_srv_enable_dpia_trace() error: we previously assumed 'dc_dmub_srv' could be null (see line 1166)

CVE-2026-53317:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: mt76: mt7921: Place upper limit on station AID  Any station configured with an AID over 20 causes a firmware crash. This situation occurred in our testing using an AP interface on 7922 hardware, with a modified hostapd, sourced from Mediatek's OpenWRT feeds.  In stock hostapd, station AIDs begin counting at 1, and this configuration is prevented with an upper limit on associated stations. However, the modified hostapd began allocation at 65, which caused the firmware to crash. This fix does not allow these AIDs to work, but will prevent the firmware crash.  This crash was only seen on IFTYPE_AP interfaces, and the fix does not appear to have an effect on IFTYPE_STATION behavior.

CVE-2026-53330:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Fix out-of-bounds read in dp_get_eq_aux_rd_interval()  [Why & How] The aux_rd_interval array in struct dc_lttpr_caps is declared with MAX_REPEATER_CNT - 1 (7) elements, indexed 0..6. However, the offset parameter passed to dp_get_eq_aux_rd_interval() can be as large as MAX_REPEATER_CNT (8) when a sink reports 8 LTTPR repeaters via DPCD. This leads to an out-of-bounds read of aux_rd_interval[7] when offset is 8.  Fix this by growing aux_rd_interval to MAX_REPEATER_CNT elements to accommodate the full range of valid repeater counts defined by the DP spec.  (cherry picked from commit a55a458a8df37a65ffda5cf721d554a8f74f6b04)

CVE-2026-53345:

        In the Linux kernel, the following vulnerability has been resolved:  KVM: Don't WARN if memory is dirtied without a vCPU when the VM is dying  When marking a page dirty, complain about not having a running/loaded vCPU if and only if the VM is still alive, i.e. its refcount is non-zero.  This will allow fixing a memory leak for x86 SEV-ES guests without hitting what is effectively a false positive on the WARN.  For some SEV-ES VM-Exits, KVM keeps a writable mapping of a guest page across an exit to userspace, and typically unmaps the page on the next KVM_RUN.  But if userspace never calls KVM_RUN after such an exit, then KVM needs to unmap the page when the vCPU is destroyed, which in turn triggers the WARN about not having a running vCPU.  Alternatively, SEV-ES could temporarily load the vCPU to suppress the WARN, as is done in nested_vmx_free_vcpu() (but for completely unrelated reasons; suppressing WARN from nested_put_vmcs12_pages() is pure happenstance).  But loading a vCPU during destruction is gross (ideally nVMX code would be cleaned up), risks complicating the SEV-ES code (KVM would need to ensure the temporarily load()+put() only runs when the vCPU isn't already loaded), and is ultimately pointless.  The motivation for the WARN is to guard against KVM dirtying guest memory without pushing the corresponding GFN to the active vCPU's dirty ring, e.g. to ensure userspace doesn't miss a dirty page.  But for the VM's refcount to reach zero, there can't be _any_ userspace mappings to the dirty ring, as mapping the dirty ring requires doing mmap() on the vCPU FD.  I.e. if userspace had a valid mapping for the dirty ring, then the vCPU file and thus the owning VM would still be alive.  And so since userspace can't possibly reach the dirty ring, whether or not KVM technically "misses" a push to the dirty ring is irrelevant.

CVE-2026-53353:

        In the Linux kernel, the following vulnerability has been resolved:  hsr: Remove WARN_ONCE() in hsr_addr_is_self().  syzbot reported the warning [0] in hsr_addr_is_self(), whose assumption is simply wrong.  hsr->self_node is cleared in hsr_del_self_node(), which is called from hsr_dellink().  Since dev->rtnl_link_ops->dellink() is called before unregister_netdevice_many(), there is a window when user can find the device but without hsr->self_node.  Let's remove WARN_ONCE() in hsr_addr_is_self().  [0]: HSR: No self node WARNING: net/hsr/hsr_framereg.c:39 at hsr_addr_is_self+0x211/0x3f0 net/hsr/hsr_framereg.c:39, CPU#0: syz.4.16848/17220 Modules linked in: CPU: 0 UID: 0 PID: 17220 Comm: syz.4.16848 Tainted: G             L      syzkaller #0 PREEMPT_{RT,(full)} Tainted: [L]=SOFTLOCKUP Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/18/2026 RIP: 0010:hsr_addr_is_self+0x211/0x3f0 net/hsr/hsr_framereg.c:39 Code: 33 2f 41 0f b7 dd 89 ee 09 de 31 ff e8 c8 b4 c6 f6 09 dd 74 54 e8 0f b0 c6 f6 31 ed eb 53 e8 06 b0 c6 f6 48 8d 3d 2f 50 9c 04 <67> 48 0f b9 3a 31 ed eb 42 e8 c1 13 1f 00 89 c5 31 ff 89 c6 e8 96 RSP: 0018:ffffc900041c70e0 EFLAGS: 00010283 RAX: ffffffff8afdc6ca RBX: ffffffff8afdc4e6 RCX: 0000000000080000 RDX: ffffc90010493000 RSI: 0000000000000948 RDI: ffffffff8f9a1700 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: ffffc900041c71e8 R11: fffff52000838e3f R12: dffffc0000000000 R13: ffff888041f9e3c0 R14: ffff888086ee3802 R15: 0000000000000000 FS:  00007f6fe985d6c0(0000) GS:ffff888126176000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f80bd437dac CR3: 0000000025096000 CR4: 00000000003526f0 DR0: ffffffffffffffff DR1: 00000000000001f8 DR2: 0000000000000002 DR3: ffffffffefffff15 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Call Trace:  <TASK>  check_local_dest net/hsr/hsr_forward.c:592 [inline]  fill_frame_info net/hsr/hsr_forward.c:728 [inline]  hsr_forward_skb+0xa11/0x2a80 net/hsr/hsr_forward.c:739  hsr_dev_xmit+0x253/0x370 net/hsr/hsr_device.c:236  __netdev_start_xmit include/linux/netdevice.h:5368 [inline]  netdev_start_xmit include/linux/netdevice.h:5377 [inline]  xmit_one net/core/dev.c:3888 [inline]  dev_hard_start_xmit+0x2df/0x860 net/core/dev.c:3904  __dev_queue_xmit+0x1428/0x3900 net/core/dev.c:4870  neigh_output include/net/neighbour.h:556 [inline]  ip_finish_output2+0xcec/0x10b0 net/ipv4/ip_output.c:237  ip_send_skb net/ipv4/ip_output.c:1510 [inline]  ip_push_pending_frames+0x8b/0x110 net/ipv4/ip_output.c:1530  raw_sendmsg+0x1547/0x1a50 net/ipv4/raw.c:659  sock_sendmsg_nosec net/socket.c:787 [inline]  __sock_sendmsg net/socket.c:802 [inline]  ____sys_sendmsg+0x7da/0x9c0 net/socket.c:2698  ___sys_sendmsg+0x2a5/0x360 net/socket.c:2752  __sys_sendmsg net/socket.c:2784 [inline]  __do_sys_sendmsg net/socket.c:2789 [inline]  __se_sys_sendmsg net/socket.c:2787 [inline]  __x64_sys_sendmsg+0x1c3/0x2a0 net/socket.c:2787  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]  do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94  entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f6feb62ce59 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f6fe985d028 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f6feb8a6090 RCX: 00007f6feb62ce59 RDX: 0000000000000000 RSI: 0000200000000000 RDI: 0000000000000004 RBP: 00007f6feb6c2d6f R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f6feb8a6128 R14: 00007f6feb8a6090 R15: 00007ffcf01cc488  </TASK>

CVE-2026-53358:

        In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen()  l2cap_chan_close() removes the channel from conn->chan_l, which must be done under conn->lock.  cleanup_listen() runs under the parent sk_lock, so acquiring conn->lock would invert the established conn->lock -> chan->lock -> sk_lock order.  Instead of calling l2cap_chan_close() directly, schedule l2cap_chan_timeout with delay 0 to close the channel asynchronously.  The timeout handler already acquires conn->lock and chan->lock in the correct order.  The timer is only armed when chan->conn is still set: if it is already NULL, l2cap_conn_del() has already processed this channel (l2cap_chan_del + l2cap_sock_teardown_cb + l2cap_sock_close_cb), so there is nothing left to do.  If l2cap_conn_del() races in after the timer is armed, __clear_chan_timer() inside l2cap_chan_del() cancels it; if the timer has already fired, the handler returns harmlessly because chan->conn was cleared.

CVE-2026-53368:

        In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix fsck inconsistency caused by incorrect nat_entry flag usage  f2fs_need_dentry_mark() reads nat_entry flags without mutual exclusion with the checkpoint path, which can result in an incorrect inode block marking state. The scenario is as follows:  create & write & fsync 'file A'                 write checkpoint - f2fs_do_sync_file // inline inode  - f2fs_write_inode // inode folio is dirty                                                 - f2fs_write_checkpoint                                                  - f2fs_flush_merged_writes                                                  - f2fs_sync_node_pages  - f2fs_fsync_node_pages // no dirty node  - f2fs_need_inode_block_update // return true  - f2fs_fsync_node_pages // inode dirtied   - f2fs_need_dentry_mark //return true                                                  - f2fs_flush_nat_entries                                                 - f2fs_write_checkpoint end   - __write_node_folio // inode with DENT_BIT_SHIFT set   SPO, "fsck --dry-run" find inode has already checkpointed but still   with DENT_BIT_SHIFT set  The state observed by f2fs_need_dentry_mark() can differ from the state observed in __write_node_folio() after acquiring sbi->node_write. The root cause is that the semantics of IS_CHECKPOINTED and HAS_FSYNCED_INODE are only guaranteed after the checkpoint write has fully completed.  This patch moves set_dentry_mark() into __write_node_folio() and protects it with the sbi->node_write lock.

CVE-2026-53376:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdkfd: Add upper bound check for num_of_nodes  drm/amdkfd: Add upper bound check for num_of_nodes in kfd_ioctl_get_process_apertures_new.  (cherry picked from commit 98ff46a5ea090c14d2cdb4f5b993b05d74f3949f)

CVE-2026-53377:

        In the Linux kernel, the following vulnerability has been resolved:  drm/msm: always recover the gpu  Previously, in case there was no more work to do, recover worker wouldn't trigger recovery and would instead rely on the gpu going to sleep and then resuming when more work is submitted.  Recover_worker will first increment the fence of the hung ring so, if there's only one job submitted to a ring and that causes an hang, it will early out.  There's no guarantee that the gpu will suspend and resume before more work is submitted and if the gpu is in a hung state it will stay in that state and probably trigger a timeout again.  Just stop checking and always recover the gpu.  Patchwork: https://patchwork.freedesktop.org/patch/704066/

CVE-2026-53401:

        In the Linux kernel, the following vulnerability has been resolved:  fbdev: omap2: fix use-after-free in omapfb_mmap  omapfb_mmap() has a race condition with OMAPFB_SETUP_PLANE ioctl that can lead to use-after-free:  The fb_mmap() entry point holds mm_lock but not lock (fb_info->lock), while ioctl handlers like OMAPFB_SETUP_PLANE hold lock but not mm_lock. This allows concurrent execution.  In omapfb_mmap(): 1. rg = omapfb_get_mem_region(ofbi->region);      // Get old region ref 2. start = omapfb_get_region_paddr(ofbi);          // Read from NEW region 3. len = fix->smem_len;                             // Read from NEW region 4. vm_iomap_memory(vma, start, len);               // Map NEW region memory 5. atomic_inc(&rg->map_count);                      // Increment OLD region!  Concurrently, OMAPFB_SETUP_PLANE can: - Reassign ofbi->region = new_rg - Update fix->smem_len - OMAPFB_SETUP_MEM then checks NEW region's map_count (0!) and frees it  This leaves userspace with a mapping to freed physical memory.  The fix is to read all required values (start, len) from the same region reference (rg) that will have its map_count incremented, preventing the region from being freed while still mapped.

CVE-2026-63805:

        In the Linux kernel, the following vulnerability has been resolved:  crypto: nx - fix nx_crypto_ctx_exit argument  nx_crypto_ctx_shash_exit calls nx_crypto_ctx_exit with crypto_shash_ctx(...) but crypto_shash_ctx gives a nx_crypto_ctx *, not a crypto_tfm *.  Fix the type in nx_crypto_ctx_exit and drop the bogus crypto_tfm_ctx call.  This fixes the following oops:    BUG: Unable to handle kernel data access at 0xc0403effffffffc8   Faulting instruction address: 0xc000000000396cb4   Oops: Kernel access of bad area, sig: 11 [#15]   Call Trace:    nx_crypto_ctx_shash_exit+0x24/0x60    crypto_shash_exit_tfm+0x28/0x40    crypto_destroy_tfm+0x98/0x140    crypto_exit_ahash_using_shash+0x20/0x40    crypto_destroy_tfm+0x98/0x140    hash_release+0x1c/0x30    alg_sock_destruct+0x38/0x60    __sk_destruct+0x48/0x2b0    af_alg_release+0x58/0xb0    __sock_release+0x68/0x150    sock_close+0x20/0x40    __fput+0x110/0x3a0    sys_close+0x48/0xa0    system_call_exception+0x140/0x2d0    system_call_common+0xf4/0x258  .. which came from hardlink(1) opportunistically using AF_ALG.  The same problem exists with nx_crypto_ctx_skcipher_exit getting a context it wasn't expecting, but apparently nobody hit that for years.

CVE-2026-63816:

        In the Linux kernel, the following vulnerability has been resolved:  f2fs: atomic: fix UAF issue on f2fs_inode_info.atomic_inode  - ioctl(F2FS_IOC_GARBAGE_COLLECT_RANGE)		- shrink  - f2fs_gc   - gc_data_segment    - ra_data_block(cow_inode)     - mapping = F2FS_I(inode)->atomic_inode->i_mapping     : f2fs_is_cow_file(cow_inode) is true 						 - f2fs_evict_inode(atomic_inode) 						  - clear_inode_flag(fi->cow_inode, FI_COW_FILE) 						  - F2FS_I(fi->cow_inode)->atomic_inode = NULL 						  ... 						  - truncate_inode_pages_final(atomic_inode)     - f2fs_grab_cache_folio(mapping)     : create folio in atomic_inode->mapping 						  - clear_inode(atomic_inode) 						   - BUG_ON(atomic_inode->i_data.nrpages)  We need to add a reference on fi->atomic_inode before using its mapping field during garbage collection, otherwise, it will cause UAF issue.

CVE-2026-63819:

        In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to do sanity check on f2fs_get_node_folio_ra()  kernel BUG at fs/f2fs/file.c:845! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 5336 Comm: syz.0.0 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:f2fs_do_truncate_blocks+0x1115/0x1140 fs/f2fs/file.c:845 Code: fc fc 90 0f 0b e8 8b 9d 9a fd 90 0f 0b e8 83 9d 9a fd 48 89 df 48 c7 c6 60 d1 1a 8c e8 54 f1 fc fc 90 0f 0b e8 6c 9d 9a fd 90 <0f> 0b e8 64 9d 9a fd 90 0f 0b 90 e9 93 fd ff ff e8 56 9d 9a fd 90 RSP: 0018:ffffc9000e4474c0 EFLAGS: 00010283 RAX: ffffffff842b1d34 RBX: 0000000000000003 RCX: 0000000000100000 RDX: ffffc9000f03a000 RSI: 0000000000035503 RDI: 0000000000035504 RBP: ffffc9000e447608 R08: ffff8880123b0000 R09: 0000000000000002 R10: 00000000fffffffe R11: 0000000000000002 R12: 0000000000000001 R13: 0000000000000000 R14: 1ffff92001c88ea0 R15: 00000000ffff039c FS:  00007f7e02ee36c0(0000) GS:ffff88808c887000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ff0305c4000 CR3: 0000000012d4c000 CR4: 0000000000352ef0 Call Trace:  <TASK>  f2fs_truncate_blocks+0x10a/0x300 fs/f2fs/file.c:882  f2fs_truncate+0x471/0x7c0 fs/f2fs/file.c:940  f2fs_evict_inode+0xa3f/0x1ac0 fs/f2fs/inode.c:907  evict+0x61e/0xb10 fs/inode.c:841  f2fs_fill_super+0x5f43/0x78f0 fs/f2fs/super.c:5224  get_tree_bdev_flags+0x431/0x4f0 fs/super.c:1694  vfs_get_tree+0x92/0x2a0 fs/super.c:1754  fc_mount fs/namespace.c:1193 [inline]  do_new_mount_fc fs/namespace.c:3758 [inline]  do_new_mount+0x341/0xd30 fs/namespace.c:3834  do_mount fs/namespace.c:4167 [inline]  __do_sys_mount fs/namespace.c:4383 [inline]  __se_sys_mount+0x31d/0x420 fs/namespace.c:4360  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]  do_syscall_64+0x15f/0xf80 arch/x86/entry/syscall_64.c:94  entry_SYSCALL_64_after_hwframe+0x77/0x7f  	count = ADDRS_PER_PAGE(dn.node_folio, inode);  	count -= dn.ofs_in_node; 	f2fs_bug_on(sbi, count < 0);  The fuzz test will trigger above bug_on in f2fs.  The root cause should be: in the corrupted inode, there is a direct node which has the same ino and nid in its footer, so in f2fs_do_truncate_blocks(), after f2fs_get_dnode_of_data() finds such dnode: 1) ADDRS_PER_PAGE(dn.node_folio, inode) will return 923 2) once dn.ofs_in_node points to addr[923, 1017] Then it will trigger the system panic.  Let's introduce NODE_TYPE_NON_IXNODE to indicate current node should not be an inode or xattr node, and then use it in below path to detect inconsistent node chain in inode mapping table:  - f2fs_do_truncate_blocks  - f2fs_get_dnode_of_data   - f2fs_get_node_folio_ra    -  __get_node_folio     - f2fs_sanity_check_node_footer      - case NODE_TYPE_NON_IXNODE -> check whether it is inode|xnode

CVE-2026-63825:

        In the Linux kernel, the following vulnerability has been resolved:  gcov: use atomic counter updates to fix concurrent access crashes  GCC's GCOV instrumentation can merge global branch counters with loop induction variables as an optimization.  In inflate_fast(), the inner copy loops get transformed so that the GCOV counter value is loaded multiple times to compute the loop base address, start index, and end bound.  Since GCOV counters are global (not per-CPU), concurrent execution on different CPUs causes the counter to change between loads, producing inconsistent values and out-of-bounds memory writes.  The crash manifests during IPComp (IP Payload Compression) processing when inflate_fast() runs concurrently on multiple CPUs:    BUG: unable to handle page fault for address: ffffd0a3c0902ffa   RIP: inflate_fast+1431   Call Trace:    zlib_inflate    __deflate_decompress    crypto_comp_decompress    ipcomp_decompress [xfrm_ipcomp]    ipcomp_input [xfrm_ipcomp]    xfrm_input  At the crash point, the compiler generated three loads from the same global GCOV counter (__gcov0.inflate_fast+216) to compute base, start, and end for an indexed loop.  Another CPU modified the counter between loads, making the values inconsistent - the write went 3.4 MB past a 65 KB buffer.  Add -fprofile-update=prefer-atomic to CFLAGS_GCOV at the global level in the top-level Makefile, guarded by a try-run compile test.  The test compiles a minimal program with and without -fprofile-update=prefer-atomic using the full KBUILD_CFLAGS, then compares undefined symbols in the resulting object files.  If prefer-atomic introduces new undefined references (such as __atomic_fetch_add_8 on i386 or __aarch64_ldadd8_relax on arm64 with outline-atomics), the flag is not added -- the kernel does not link against libatomic.  On architectures where GCC inlines 64-bit atomic counter updates (x86_64, s390, ...) the test passes and the flag is enabled, preventing the compiler from merging counters with loop induction variables and fixing the observed concurrent-access crash.  On architectures where the flag would introduce libatomic dependencies, it is silently omitted and behaviour is no worse than before this patch.  Move the CFLAGS_GCOV block from its original position (before the arch Makefile include) to after the core KBUILD_CFLAGS assignments but before the scripts/Makefile.gcc-plugins include.  This placement ensures the try-run test sees arch-specific flags (-m32, -march=, -mno-outline-atomics) while avoiding GCC plugin flags (-fplugin=) that would break the test on clean builds when plugin shared objects do not yet exist.

CVE-2026-63826:

        In the Linux kernel, the following vulnerability has been resolved:  fbdev: fix use-after-free in store_modes()  store_modes() replaces a framebuffer's modelist with modes from userspace. On success it frees the old modelist with fb_destroy_modelist(). Two fields still point into that freed list.  One pointer is fb_display[i].mode, the mode a console is using. fbcon_new_modelist() moves these pointers to the new list. It only does so for consoles still mapped to the framebuffer. An unmapped console is skipped and keeps its stale pointer. Unbinding fbcon, for example, sets con2fb_map[i] to -1 but leaves fb_display[i].mode set. An FBIOPUT_VSCREENINFO ioctl with FB_ACTIVATE_INV_MODE later reaches fbcon_mode_deleted(). That function reads the stale fb_display[i].mode through fb_mode_is_equal(). The read is a use-after-free.  The other pointer is fb_info->mode, the current mode. It is set through the mode sysfs attribute. store_modes() does not update fb_info->mode, so it is left pointing into the freed list. show_mode(), the attribute's read handler, dereferences the stale fb_info->mode through mode_string(). The read is a use-after-free.  Clear both pointers before freeing the list. Commit a1f305893074 ("fbcon: Set fb_display[i]->mode to NULL when the mode is released") added the helper fbcon_delete_modelist(). It clears every fb_display[i].mode that points into a given list. So far it is called only from the unregister path. Call it from store_modes() too, and set fb_info->mode to NULL.

CVE-2026-63845:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu/jpeg: set no_user_fence for JPEG v4.0 ring  JPEG rings do not support 64-bit user fence writes, reject CS submissions with user fences.  (cherry picked from commit 8d0cac9478a3f046279c657d6a2545de49ae675a)

CVE-2026-63846:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu/jpeg: set no_user_fence for JPEG v3.0 ring  JPEG rings do not support 64-bit user fence writes, reject CS submissions with user fences.  (cherry picked from commit 4d7d774f100efb5089c86a1fb8c5bf47c63fc9ef)

CVE-2026-63847:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu/jpeg: set no_user_fence for JPEG v2.5 ring  JPEG rings do not support 64-bit user fence writes, reject CS submissions with user fences.  (cherry picked from commit 3216a7f4e2642bda5fd14f57586e835ae9202587)

CVE-2026-63848:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu/jpeg: set no_user_fence for JPEG v2.0 ring  JPEG rings do not support 64-bit user fence writes, reject CS submissions with user fences.  (cherry picked from commit 96179da0c6b059eb31706a0abe8dd6381c533143)

CVE-2026-63853:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu/vcn: set no_user_fence for VCN v4.0 enc ring  VCN encoder and decoder rings do not support 64-bit user fence writes, reject CS submissions with user fences.  (cherry picked from commit fd852c048b46f9825e904a4f3f4538fe9d8827d9)

CVE-2026-63854:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu/vcn: set no_user_fence for VCN v3.0 enc/dec rings  VCN encoder and decoder rings do not support 64-bit user fence writes, reject CS submissions with user fences.  (cherry picked from commit 663bed3c7b8b9a7624b0d95d300ddae034ad0614)

CVE-2026-63855:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu/vcn: set no_user_fence for VCN v2.5 enc/dec rings  VCN encoder and decoder rings do not support 64-bit user fence writes, reject CS submissions with user fences.  (cherry picked from commit efc9dd5590894109bce9a0bfe1fa5592dd6b20b1)

CVE-2026-63856:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu/vcn: set no_user_fence for VCN v2.0 enc/dec rings  VCN encoder and decoder rings do not support 64-bit user fence writes, reject CS submissions with user fences.  (cherry picked from commit e2b5499fca55f1a32960a311bbb62e35891eaf73)

CVE-2026-63858:

        In the Linux kernel, the following vulnerability has been resolved:  netfilter: nf_tables: add hook transactions for device deletions  Restore the flag that indicates that the hook is going away, ie. NFT_HOOK_REMOVE, but add a new transaction object to track deletion of hooks without altering the basechain/flowtable hook_list during the preparation phase.  The existing approach that moves the hook from the basechain/flowtable hook_list to transaction hook_list breaks netlink dump path readers of this RCU-protected list.  It should be possible use an array for nft_trans_hook to store the deleted hooks to compact the representation but I am not expecting many hook object, specially now that wildcard support for devices is in place.  Note that the nft_trans_chain_hooks() list contains a list of struct nft_trans_hook objects for DELCHAIN and DELFLOWTABLE commands, while this list stores struct nft_hook objects for NEWCHAIN and NEWFLOWTABLE. Note that new commands can be updated to use nft_trans_hook for consistency.  This patch also adapts the event notification path to deal with the list of hook transactions.

CVE-2026-63871:

        In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: ISO: Fix data-race on iso_pi fields in hci_get_route calls  iso_connect_bis(), iso_connect_cis(), iso_listen_bis(), and iso_conn_big_sync() call hci_get_route() using iso_pi(sk)->dst, iso_pi(sk)->src, and iso_pi(sk)->src_type without holding lock_sock().  These fields may be modified concurrently by connect() or setsockopt() on the same socket, resulting in data-races reported by KCSAN.  Fix this by snapshotting the required fields under lock_sock() before calling hci_get_route().  BUG: KCSAN: data-race in memcmp+0x45/0xb0  race at unknown origin, with read to 0xffff8880122135cf of 1 bytes by task 333 on cpu 1:  memcmp+0x45/0xb0  hci_get_route+0x27e/0x490  iso_connect_cis+0x4c/0xa10  iso_sock_connect+0x60e/0xb30  __sys_connect_file+0xbd/0xe0  __sys_connect+0xe0/0x110  __x64_sys_connect+0x40/0x50  x64_sys_call+0xcad/0x1c60  do_syscall_64+0x133/0x590  entry_SYSCALL_64_after_hwframe+0x77/0x7f

CVE-2026-63940:

        In the Linux kernel, the following vulnerability has been resolved:  KVM: SEV: Ignore Port I/O requests of length '0'  Explicitly ignore Port I/O requests of length '0' (or count '0'), so that setting up the software scratch area (and other code) doesn't have to worry about underflowing the length, and to allow for WARNing on trying to configure the scratch area with len==0.

CVE-2026-63959:

        In the Linux kernel, the following vulnerability has been resolved:  usb: typec: tcpm/tcpci_maxim: validate header NDO against RX_BYTE_CNT  A broken/malicious port can transmit a CRC-valid frame whose header advertises up to seven data objects but whose body carries fewer than that.  Check for this, and rightfully reject the message, instead of reading from uninitialized stack memory.

CVE-2026-63962:

        In the Linux kernel, the following vulnerability has been resolved:  usb: typec: tcpm: bound altmode_desc[] per iteration in svdm_consume_modes()  svdm_consume_modes() checks pmdata->altmodes against the array size once before the loop over the count, but forgot to check the bound at every point in the loop.  In the well-behaved SVDM discovery flow this is harmless because each of at most SVID_DISCOVERY_MAX SVIDs contributes at most MODE_DISCOVERY_MAX modes, exactly filling altmode_desc[ALTMODE_DISCOVERY_MAX].  But the CMDT_RSP_ACK handler in tcpm_pd_svdm() does not correlate an incoming ACK with any request the port actually sent.  Once port->partner is set, an unsolicited Discover Modes ACK is consumed unconditionally.  A broken or malicious port partner can therefore drive altmodes to ALTMODE_DISCOVERY_MAX - 1 via the normal flow, and then send one extra Discover Modes ACK with seven VDOs.  Because the pre-loop check passes, the loop could then writes up to five entries past altmode_desc[].  For mode_data_prime the next field in struct tcpm_port is the partner_altmode[] pointer array, which then receives partner-chosen SVID/VDO bytes.  Move the bound check inside the loop so the array can never be indexed past ALTMODE_DISCOVERY_MAX regardless of how many VDOs the partner supplies or how the function was reached.

CVE-2026-63963:

        In the Linux kernel, the following vulnerability has been resolved:  usb: typec: tcpm: validate VDO count in Discover Identity ACK handlers  Properly validate the count passed from a device when calling svdm_consume_identity() or svdm_consume_identity_sop_prime() as the device-controlled value could index off of the static arrays, which could leak data.

CVE-2026-63974:

        In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: hci_sync: Set HCI_CMD_DRAIN_WORKQUEUE during device close  Since hci_dev_close_sync() can now be called during the reset path, we should also set HCI_CMD_DRAIN_WORKQUEUE. This avoids queuing timeouts while the hdev workqueue is being drained.

CVE-2026-63983:

        In the Linux kernel, the following vulnerability has been resolved:  net/sched: fix packet loop on netem when duplicate is on  When netem duplicates a packet it re-enqueues the copy at the root qdisc. If another netem sits in the tree the copy can be duplicated again, recursing until the stack or memory is exhausted.  The original duplication guard temporarily zeroed q->duplicate around the re-enqueue, but that does not cover all cases because it is per-qdisc state shared across all concurrent enqueue paths and is not safe without additional locking.  Use the skb tc_depth field introduced in an earlier patch:  - increment it on the duplicate before re-enqueue  - skip duplication for any skb whose tc_depth is already non-zero.  This marks the packet itself rather than mutating qdisc state, therefore it is safe regardless of tree topology or concurrency.

CVE-2026-63999:

        In the Linux kernel, the following vulnerability has been resolved:  ethtool: rss: fix indir_table and hkey leak on get_rxfh failure  rss_prepare_get() allocates the indirection table and hash key buffer via rss_get_data_alloc(), then calls ops->get_rxfh() to populate them. If get_rxfh() fails, the function returns an error without freeing the allocation.

CVE-2026-64001:

        In the Linux kernel, the following vulnerability has been resolved:  ALSA: pcm: oss: Fix setup list UAF on proc write error  snd_pcm_oss_proc_write() links a newly allocated setup entry into the OSS setup list before duplicating the task name. If the task-name allocation fails, the error path frees the already linked entry and leaves setup_list pointing at freed memory.  A later OSS device open can then walk the stale list entry in snd_pcm_oss_look_for_setup() and dereference freed memory.  Allocate the task name and initialize the setup entry before publishing the entry on setup_list. Also fetch the initial proc read iterator only after taking setup_mutex, so all setup_list traversal follows the same list lifetime rules.

CVE-2026-64006:

        In the Linux kernel, the following vulnerability has been resolved:  netfilter: nf_tables: fix dst corruption in same register operation  For lshift and rshift, the shift operations are performed in a loop over 32-bit words. The loop calculates the shifted value and write it to dst, and then immediately reads from src to calculate the carry for the next iteration. Because src and dst could point to the same memory location, the carry is incorrectly calculated using the newly modified dst value instead of the original src value.  Adding a temporary local variable to cache the original value before writing to dst and using it for the carry calculation solves the problem. In addition, partial overlap is rejected from control plane for all kind of operations including byteorder. This was tested with the following bytecode:  table test_table ip flags 0 use 1 handle 1 ip test_table test_chain use 3 type filter hook input prio 0 policy accept packets 0 bytes 0 flags 1 ip test_table test_chain 2   [ immediate reg 1 0x44332211 0x88776655 ]   [ bitwise reg 1 = ( reg 1 << 0x08000000 ) ]   [ cmp eq reg 1 0x66443322 0x00887766 ]   [ counter pkts 0 bytes 0 ] ip test_table test_chain 4 3   [ immediate reg 1 0x44332211 0x88776655 ]   [ bitwise reg 1 = ( reg 1 << 0x08000000 ) ]   [ cmp eq reg 1 0x55443322 0x00887766 ]   [ counter pkts 21794 bytes 1917798 ]

CVE-2026-64017:

        In the Linux kernel, the following vulnerability has been resolved:  blk-mq: pop cached request if it is usable  When submitting a bio to blk-mq, if the task should sleep after peeking a cached request, but before it pops it, the plug flushes and calls blk_mq_free_plug_rqs, freeing the cached_rqs. This creates a use-after-free bug. Fix this by popping the cached request before any possible blocking calls if it is suitable for use.  Popping this request first holds a queue reference, so avoid any serialization races with queue freezes and can safely proceed with dispatching that request to the driver. This potentially increases a timing window from when a driver wants to freeze its queue to when requests stop being dispatched. That scenario is off the fast path though, and drivers need to appropriately handle requests during a freeze request anyway.  The downside is the popped element needs to be individually freed when we performed a bio plug merge. The cached request would have had to be freed later anyway, but this patch does it inline with building the plug list instead of after flushing it.

CVE-2026-64025:

        In the Linux kernel, the following vulnerability has been resolved:  bpf, skmsg: fix verdict sk_data_ready racing with ktls rx  sk_psock_strp_data_ready() already checks tls_sw_has_ctx_rx() and defers to psock->saved_data_ready when a TLS RX context is present, avoiding a conflict with the TLS strparser's ownership of the receive queue (commit e91de6afa81c, "bpf: Fix running sk_skb program types with ktls").  sk_psock_verdict_data_ready() has no equivalent guard.  When a socket is inserted into a sockmap (BPF_SK_SKB_VERDICT) before TLS RX is configured, tls_sw_strparser_arm() saves sk_psock_verdict_data_ready as rx_ctx->saved_data_ready.  On data arrival:    tls_data_ready -> tls_strp_data_ready -> tls_rx_msg_ready     -> saved_data_ready() = sk_psock_verdict_data_ready()       -> tcp_read_skb() drains sk_receive_queue via __skb_unlink()          without calling tcp_eat_skb(), so copied_seq is not advanced.  tls_strp_msg_load() then finds tcp_inq() >= full_len (stale), calls tcp_recv_skb() on the now-empty queue, hits WARN_ON_ONCE(!first), and returns with rx_ctx->strp.anchor.frag_list pointing at a psock-owned (potentially freed) skb.  tls_decrypt_sg() subsequently walks that frag_list: use-after-free.  Apply the same fix as sk_psock_strp_data_ready(): if a TLS RX context is present, call psock->saved_data_ready (sock_def_readable) to wake recv() waiters and return immediately, leaving the receive queue untouched.  TLS retains sole ownership of the queue and decrypts the record normally through tls_sw_recvmsg().

CVE-2026-64026:

        In the Linux kernel, the following vulnerability has been resolved:  rxrpc: Fix DATA decrypt vs splice() by copying data to buffer in recvmsg  This improves the fix for CVE-2026-43500.  Fix the pagecache corruption from in-place decryption of a DATA packet transmitted locally by splice() by getting rid of the packet sharing in the I/O thread and unconditionally extracting the packet content into a bounce buffer in which the buffer is decrypted.  recvmsg() (or the kernel equivalent) then copies the data from the bounce buffer to the destination buffer.  The sk_buff then remains unmodified.  This has an additional advantage in that the packet is then arranged in the buffer with the correct alignment required for the crypto algorithms to process directly.  The performance of the crypto does seem to be a little faster and, surprisingly, the unencrypted performance doesn't seem to change much - possibly due to removing complexity from the I/O thread.  Yet another advantage is that the I/O thread doesn't have to copy packets which would slow down packet distribution, ACK generation, etc..  The buffer belongs to the call and is allocated initially at 2K, sufficiently large to hold a whole jumbo subpacket, but the buffer will be increased in size if needed.  However, to take this work, MSG_PEEK may cause a later packet to be decrypted into the buffer, in which case the earlier one will need re-decrypting for a subsequent recvmsg().  Note that rx_pkt_offset may legitimately see 0 as a valid offset now, so switch to using USHRT_MAX to indicate an invalid offset.  Note also that I would generally prefer to replace the buffers of the current sk_buff with a new kmalloc'd buffer of the right size, ditching the old data and frags as this makes the handling of MSG_PEEK easier and removes the re-decryption issue, but this looks like quite a complicated thing to achieve.  skb_morph() looks half way to what I want, but I don't want to have to allocate a new sk_buff.

CVE-2026-64036:

        In the Linux kernel, the following vulnerability has been resolved:  cgroup/rstat: validate cpu before css_rstat_cpu() access  css_rstat_updated() is exposed as a BPF kfunc and accepts a caller-provided cpu argument. The function uses cpu for per-cpu rstat lookups without checking whether it refers to a valid possible CPU.  A BPF iter/cgroup program with CAP_BPF and CAP_PERFMON can pass an invalid cpu value. On an unfixed UBSCAN_BOUNDS test kernel, cpu == 0x7fffffff triggers:    UBSAN: array-index-out-of-bounds in kernel/cgroup/rstat.c:31:9   index 2147483647 is out of range for type 'long unsigned int [64]'   Call Trace:     css_rstat_updated     bpf_iter_run_prog     cgroup_iter_seq_show     bpf_seq_read  Add cpu validation to the BPF-facing css_rstat_updated() kfunc and move the common implementation to __css_rstat_updated() for in-kernel callers.

CVE-2026-64038:

        In the Linux kernel, the following vulnerability has been resolved:  hwmon: (lm90) Stop work before releasing hwmon device  Sashiko reports:  In lm90_probe(), the devm action to cancel the alert_work and report_work (lm90_restore_conf) is registered in lm90_init_client() before devm_hwmon_device_register_with_info() is called.  Because devm executes cleanup actions in reverse order during module unbind or probe failure, the hwmon device is unregistered and freed first.  If lm90_alert_work() or lm90_report_alarms() runs in the window between the hwmon device being freed and the delayed works being cancelled, lm90_update_alarms() will dereference the freed data->hwmon_dev here.  Fix the problem by canceling the workers separately after registering the hwmon device and before registering the interrupt handler. This ensures that the workers are canceled after interrupts are disabled and before the hwmon device is released. Add "shutdown" flag to indicate that device shutdown is in progress to prevent workers from being re-armed.

CVE-2026-64060:

        In the Linux kernel, the following vulnerability has been resolved:  netfs: Fix leak of request in netfs_write_begin() error handling  Fix netfs_write_begin() to not leak our ref on the request in the event that we get an error from netfs_wait_for_read().

CVE-2026-64076:

        In the Linux kernel, the following vulnerability has been resolved:  netfilter: bridge: eb_tables: close module init race  sashiko reports for unrelated patch:  Does the core ebtables initialization in ebtables.c suffer from a similar race?  Once nf_register_sockopt() completes, the sockopts are exposed globally.  sockopt has to be registered last, just like in ip/ip6/arptables.

CVE-2026-64077:

        In the Linux kernel, the following vulnerability has been resolved:  netfilter: ebtables: move to two-stage removal scheme  Like previous patches for x_tables, follow same pattern in ebtables. We can't reuse xt helpers: ebt_table struct layout is incompatible.  table->ops assignment is now done while still holding the ebt mutex to make sure we never expose partially-filled table struct.

CVE-2026-64078:

        In the Linux kernel, the following vulnerability has been resolved:  netfilter: x_tables: add and use xtables_unregister_table_exit  Previous change added xtables_unregister_table_pre_exit to detach the table from the packetpath and to unlink it from the active table list. In case of rmmod, userspace that is doing set/getsockopt for this table will not be able to re-instantiate the table:  1. The larval table has been removed already  2. existing instantiated table is no longer on the xt pernet table list.  This adds the second stage helper:  unlink the table from the dying list, free the hook ops (if any) and do the audit notification.  It replaces xt_unregister_table().

CVE-2026-64079:

        In the Linux kernel, the following vulnerability has been resolved:  netfilter: x_tables: allocate hook ops while under mutex  arp/ip(6)t_register_table() add the table to the per-netns list via xt_register_table() before allocating the per-netns hook ops copy via kmemdup_array().  This leaves a window where the table is visible in the list with ops=NULL.  If the pernet exit happens runs concurrently the pre_exit callback finds the table via xt_find_table() and passes the NULL ops pointer to nf_unregister_net_hooks(), causing a NULL dereference:    general protection fault in nf_unregister_net_hooks+0xbc/0x150   RIP: nf_unregister_net_hooks (net/netfilter/core.c:613)   Call Trace:     ipt_unregister_table_pre_exit     iptable_mangle_net_pre_exit     ops_pre_exit_list     cleanup_net  Fix by moving the ops allocation into the xtables core so the table is never in the list without valid ops.  Also ensure the table is no longer processing packets before its torn down on error unwind. nf_register_net_hooks might have published at least one hook; call synchronize_rcu() if there was an error.  audit log register message gets deferred until all operations have passed, this avoids need to emit another ureg message in case of error unwinding.  Based on earlier patch by Tristan Madani.

CVE-2026-64109:

        In the Linux kernel, the following vulnerability has been resolved:  af_unix: Fix UAF read of tail->len in unix_stream_data_wait()  unix_stream_data_wait() does skb_peek_tail(&sk->sk_receive_queue) without holding any lock that prevents SKBs on that queue from being dequeued and freed. This has been the case since commit 79f632c71bea ("unix/stream: fix peeking with an offset larger than data in queue"). The first consequence of this is that the pointer comparison `tail != last` can be false even if `last` semantically refers to an already-freed SKB while `tail` is a new SKB allocated at the same address; which can cause unix_stream_data_wait() to wrongly keep blocking after new data has arrived, but only in a weird scenario where a peeking recv() and a normal recv() on the same socket are racing, which is probably not a real problem.  But since commit 2b514574f7e8 ("net: af_unix: implement splice for stream af_unix sockets"), `tail` is actually dereferenced, which can cause UAF in the following race scenario (where test_setup() runs single-threaded, and afterwards, test_thread1() and test_thread2() run concurrently in two threads: ``` static int socks[2]; void test_setup(void) {   socketpair(AF_UNIX, SOCK_STREAM, 0, socks);   send(socks[1], "A", 1, 0);   int peekoff = 1;   setsockopt(socks[0], SOL_SOCKET, SO_PEEK_OFF, &peekoff, sizeof(peekoff)); } void test_thread1(void) {   char dummy;   recv(socks[0], &dummy, 1, MSG_PEEK); } void test_thread2(void) {   char dummy;   recv(socks[0], &dummy, 1, 0);   shutdown(socks[1], SHUT_WR); } ```  when racing like this: ``` thread1                       thread2 unix_stream_read_generic   mutex_lock(&u->iolock)   skb_peek(&sk->sk_receive_queue)   skb_peek_next(skb, &sk->sk_receive_queue)   mutex_unlock(&u->iolock)                               unix_stream_read_generic                                 unix_state_lock(sk)                                 skb_peek(&sk->sk_receive_queue)                                 unix_state_unlock(sk)   unix_stream_data_wait     unix_state_lock(sk)     tail = skb_peek_tail(&sk->sk_receive_queue)                                 spin_lock(&sk->sk_receive_queue.lock)                                 __skb_unlink(skb, &sk->sk_receive_queue)                                 spin_unlock(&sk->sk_receive_queue.lock)                                 consume_skb(skb) [frees the SKB]     `tail != last`: false     `tail`: true     `tail->len != last_len` ***UAF*** ```  Fix the UAF by removing the read of tail->len; checking tail->len would only make sense if SKBs in the receive queue of a UNIX socket could grow, which can no longer happen.  Kuniyuki explained:  > When commit 869e7c62486e ("net: af_unix: implement stream sendpage > support") added sendpage() support, data could be appended to the last > skb in the receiver's queue. > > That's why we needed to check if the length of the last skb was changed > while waiting for new data in unix_stream_data_wait(). > > However, commit a0dbf5f818f9 ("af_unix: Support MSG_SPLICE_PAGES") and > commit 57d44a354a43 ("unix: Convert unix_stream_sendpage() to use > MSG_SPLICE_PAGES") refactored sendmsg(), and now data is always added > to a new skb.  That means this fix is not suitable for kernels before 6.5.

CVE-2026-64112:

        In the Linux kernel, the following vulnerability has been resolved:  rbd: eliminate a race in lock_dwork draining on unmap  Given how rbd_lock_add_request() and rbd_img_exclusive_lock() are written, lock_dwork may be (re)queued more than it's actually needed: for example in case a new I/O request comes in while we are in the middle of rbd_acquire_lock() on behalf of another I/O request.  This is expected and with rbd_release_lock() preemptively canceling lock_dwork is benign under normal operation.  A more problematic example is maybe_kick_acquire():      if (have_requests || delayed_work_pending(&rbd_dev->lock_dwork)) {             dout("%s rbd_dev %p kicking lock_dwork\n", __func__, rbd_dev);             mod_delayed_work(rbd_dev->task_wq, &rbd_dev->lock_dwork, 0);     }  It's not unrealistic for lock_dwork to get canceled right after delayed_work_pending() returns true and for mod_delayed_work() to requeue it right there anyway.  This is a classic TOCTOU race.  When it comes to unmapping the image, there is an implicit assumption of no self-initiated exclusive lock activity past the point of return from rbd_dev_image_unlock() which unlocks the lock if it happens to be held.  This unlock is assumed to be final and lock_dwork (as well as all other exclusive lock tasks, really) isn't expected to get queued again.  However, lock_dwork is canceled only in cancel_tasks_sync() (i.e. later in the unmap sequence) and on top of that the cancellation can get in effect nullified by maybe_kick_acquire().  This may result in rbd_acquire_lock() executing after rbd_dev_device_release() and rbd_dev_image_release() run and free and/or reset a bunch of things. One of the possible failure modes then is a violated      rbd_assert(rbd_image_format_valid(rbd_dev->image_format));  in rbd_dev_header_info() which is called via rbd_dev_refresh() from rbd_post_acquire_action().  Redo exclusive lock task draining to provide saner semantics and try to meet the assumptions around rbd_dev_image_unlock().

CVE-2026-64138:

        In the Linux kernel, the following vulnerability has been resolved:  ksmbd: validate SID in parent security descriptor during ACL inheritance  Introduce smb_validate_ntsd_sid() helper to safely validate Owner SID and Group SID inside the NT Security Descriptor (smb_ntsd) retrieved from the parent directory.

CVE-2026-64144:

        In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: btmtk: fix urb->setup_packet leak in error paths  The setup_packet of control urb is not freed if usb_submit_urb fails or the submitted urb is killed. Add free in these two paths.

CVE-2026-64146:

        In the Linux kernel, the following vulnerability has been resolved:  erofs: fix metabuf leak in inode xattr initialization  commit bb88e8da0025 ("erofs: use meta buffers for xattr operations") converted xattr operations to use on-stack erofs_buf instances. erofs_init_inode_xattrs() uses such a metabuf while reading the inline xattr header and shared xattr id array.  Some error paths after erofs_read_metabuf() leave through out_unlock without dropping the metabuf, so the folio reference can leak.  Consolidate the cleanup at out_unlock. erofs_put_metabuf() is a no-op if no folio has been acquired, and this keeps all paths after taking EROFS_I_BL_XATTR_BIT covered by a single cleanup site.

CVE-2026-64160:

        In the Linux kernel, the following vulnerability has been resolved:  netfs: Fix potential for tearing in ->remote_i_size and ->zero_point  Fix potential tearing in using ->remote_i_size and ->zero_point by copying i_size_read() and i_size_write() and using the same seqcount as for i_size.  We need to make sure that netfslib and the filesystems that use it always hold i_lock whilst updating any of the sizes to prevent i_size_seqcount from getting corrupted.

CVE-2026-64163:

        In the Linux kernel, the following vulnerability has been resolved:  test_kprobes: clear kprobes between test runs  Running the kprobes sanity tests twice makes all tests fail and eventually crashes the kernel.  [root@martin-riscv-1 ~]# echo 1 > /sys/kernel/debug/kunit/kprobes_test/run ...    # Totals: pass:5 fail:0 skip:0 total:5    ok 1 kprobes_test [root@martin-riscv-1 ~]# echo 1 > /sys/kernel/debug/kunit/kprobes_test/run ...   # test_kprobe: EXPECTATION FAILED at lib/tests/test_kprobes.c:64   Expected 0 == register_kprobe(&kp), but       register_kprobe(&kp) == -22 (0xffffffffffffffea) ...   Unable to handle kernel paging request ...  The testsuite defines several kprobes and kretprobes as static variables that are preserved across test runs.  After register_kprobe and unregister_kprobe, a kprobe contains some leftover data that must be cleared before the kprobe can be registered again. The tests are setting symbol_name to define the probe location. Address and flags must be cleared.  The existing code clears some of the probes between subsequent tests, but not between two test runs. The leftover data from a previous test run makes the registrations fail in the next run.  Move the cleanups for all kprobes into kprobes_test_init, this function is called before each single test (including the first test of a test run).

CVE-2026-64190:

        In the Linux kernel, the following vulnerability has been resolved:  net: team: fix NULL pointer dereference in team_xmit during mode change  __team_change_mode() clears team->ops with memset() before restoring safe dummy handlers via team_adjust_ops(). A concurrent team_xmit() running under RCU on another CPU can read team->ops.transmit during this window and call a NULL function pointer, crashing the kernel.  The race requires a mode change (CAP_NET_ADMIN) concurrent with transmit on the team device.   BUG: kernel NULL pointer dereference, address: 0000000000000000  Oops: 0010 [#1] SMP KASAN NOPTI  RIP: 0010:0x0  Call Trace:   team_xmit (drivers/net/team/team_core.c:1853)   dev_hard_start_xmit (net/core/dev.c:3904)   __dev_queue_xmit (net/core/dev.c:4871)   packet_sendmsg (net/packet/af_packet.c:3109)   __sys_sendto (net/socket.c:2265)  The original code assumed that no ports means no traffic, so mode changes could freely memset()/memcpy() the ops.  AF_PACKET with forced carrier breaks that assumption.  Prevent the race instead of making it safe: replace memset()/memcpy() with per-field updates that never touch transmit or receive.  Those two handlers are managed solely by team_adjust_ops(), which already installs dummies when tx_en_port_count == 0 (always true during mode change since no ports are present).  WRITE_ONCE/READ_ONCE prevent store/load tearing on the handler pointers.  synchronize_net() before exit_op() drains in-flight readers that may still reference old mode state from before port removal switched the handlers to dummies.

CVE-2026-64212:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: iwlwifi: mld: don't dereference a pointer before NULL checking it  In iwl_mld_remove_link, the link->fw_id is saved at the beginning of the function so we have it after we freed the link.  But the link pointer can be NULL, and is not checked when the fw_id is stored.  Fix it by simply freeing the link at the end of the function.  fFixes: 0e66a39f4f0e ("wifi: iwlwifi: fix potential use after free in iwl_mld_remove_link()")

CVE-2026-64213:

        In the Linux kernel, the following vulnerability has been resolved:  hwmon: (lm90) Add lock protection to lm90_alert  Sashiko reports:  lm90_alert() executes in the smbus alert context and calls lm90_update_confreg() to disable the hardware alert line, without acquiring hwmon_lock.  Concurrently, sysfs write operations (such as lm90_write_convrate) hold the hwmon_lock, temporarily modify data->config, and then restore it.  If an alert interrupt occurs concurrently with a sysfs write, the sysfs path will overwrite the alert handler's modifications to data->config and the hardware register.  This unintentionally re-enables the hardware alert line while the alarm is still active, causing an interrupt storm.  Add the missing lock to lm90_alert() to solve the problem.

CVE-2026-64241:

        In the Linux kernel, the following vulnerability has been resolved:  gpio: rockchip: teardown bugs and resource leaks  Address several teardown issues and resource leaks in the driver's remove path and error handling:  1. Debounce clock reference leak: The debounce clock (bank->db_clk) is    obtained using of_clk_get() which increments the clock's reference    count, but clk_put() is never called. Register a devm action to    cleanly release it on unbind. Note that of_clk_get(..., 1) remains    necessary over devm_clk_get() because the DT binding does not define    clock-names, precluding name-based lookup.  2. Unregistered chained IRQ handler: The chained IRQ handler is not    disconnected in remove(). If a stray interrupt fires after the driver    is removed, the kernel attempts to execute a stale handler, leading    to a panic. Fix this by clearing the handler in remove().  3. IRQ domain leak: The linear IRQ domain and its generic chips are    allocated manually during probe but never removed. Remove the IRQ    domain during driver teardown to free the associated generic chips    and mappings.  [Bartosz: don't emit an error message on devres allocation failure]

CVE-2026-64305:

        In the Linux kernel, the following vulnerability has been resolved:  crypto: qat - protect service table iterations with service_lock  The service_table list is protected by service_lock when entries are added or removed (in adf_service_add() and adf_service_remove()), but several functions iterate over the list without holding this lock.  A concurrent adf_service_register() or adf_service_unregister() call could modify the list during traversal, leading to list corruption or a use-after-free.  Fix this by holding service_lock across all list_for_each_entry() iterations of service_table in adf_dev_init(), adf_dev_start(), adf_dev_stop(), adf_dev_shutdown(), adf_dev_restarting_notify(), adf_dev_restarted_notify(), and adf_error_notifier().  The lock ordering is safe: callers of the static helpers (adf_dev_up() and adf_dev_down()) acquire state_lock before service_lock, and no event_hld callback or service_lock holder ever acquires state_lock in the reverse order.

CVE-2026-64319:

        In the Linux kernel, the following vulnerability has been resolved:  nvmet-auth: validate reply message payload bounds against transfer length  nvmet_auth_reply() accesses the variable-length rval[] array using attacker-controlled hl (hash length) and dhvlen (DH value length) fields without verifying they fit within the allocated buffer of tl bytes.  A malicious NVMe-oF initiator can craft a DHCHAP_REPLY message with a small transfer length but large hl/dhvlen values, causing out-of-bounds heap reads when the target processes the DH public key (rval + 2*hl) or performs the host response memcmp.  With DH authentication configured, the OOB pointer is passed directly to sg_init_one() and read by crypto_kpp_compute_shared_secret(), reaching up to 526 bytes past the buffer. This is exploitable pre-authentication.  Add bounds validation ensuring sizeof(*data) + 2*hl + dhvlen <= tl before any access to the variable-length fields.  Discovered by Atuin - Automated Vulnerability Discovery Engine.

CVE-2026-64320:

        In the Linux kernel, the following vulnerability has been resolved:  nvmet: fix pre-auth out-of-bounds heap read in Discovery Get Log Page  nvmet_execute_disc_get_log_page() validates only the dword alignment of the host-supplied Log Page Offset (lpo).  The 64-bit offset is then added to a small kzalloc'd buffer that holds the discovery log page and the result is passed straight to nvmet_copy_to_sgl(), which memcpy()s data_len bytes out to the host with no source-side bound check:      u64 offset      = nvmet_get_log_page_offset(req->cmd);  /* 64-bit host */     size_t data_len = nvmet_get_log_page_len(req->cmd);     /* 32-bit host */     ...     if (offset & 0x3) { ... }                               /* only check */     ...     alloc_len = sizeof(*hdr) + entry_size * discovery_log_entries(req);     buffer = kzalloc(alloc_len, GFP_KERNEL);     ...     status = nvmet_copy_to_sgl(req, 0, buffer + offset, data_len);  The Discovery controller is unauthenticated -- nvmet_host_allowed() returns true unconditionally for the discovery subsystem -- so the call is reachable pre-authentication by any TCP/RDMA/FC peer that can reach the nvmet target.  With a discovery log page of ~1 KiB, an attacker requesting up to 4 KiB starting at offset == alloc_len reads the next slab page out and gets its content returned over the fabric (an empirical run on a default nvmet-tcp loopback target leaked 81 canonical kernel pointers in one Get Log Page response).  Pointing the offset at unmapped kernel memory faults the in-kernel memcpy and crashes (or panics, on panic_on_oops=1) the target host instead.  The attacker-controlled source-side offset pattern "nvmet_copy_to_sgl(req, 0, buffer + ATTACKER_OFFSET, ...)" is unique to nvmet_execute_disc_get_log_page in the entire nvmet codebase: every other Get Log Page handler in admin-cmd.c either ignores lpo (and silently starts every response at offset 0) or tracks a local destination offset with a fixed source pointer.  Validate the host-supplied offset against the log page size, cap the copy length to what is actually available, and zero-fill any remainder of the host transfer buffer.  The zero-fill matches the existing short-response pattern in nvmet_execute_get_log_changed_ns() (admin-cmd.c) and prevents leaking transport SGL contents when the host asks for more bytes than the log page contains.

CVE-2026-64341:

        In the Linux kernel, the following vulnerability has been resolved:  USB: iowarrior: fix use-after-free on disconnect race  mutex_unlock() may access the mutex structure after releasing the lock and therefore cannot be used to manage lifetime of objects directly (unlike spinlocks and refcounts). [1][2]  Use a kref to release the driver data to avoid use-after-free in mutex_unlock() when release() races with disconnect().  [1] a51749ab34d9 ("locking/mutex: Document that mutex_unlock() is non-atomic") [2] 2b9d9e0a9ba0 ("locking/mutex: Clarify that mutex_unlock(), and most                    other sleeping locks, can still use the lock object                    after it's unlocked")

CVE-2026-64345:

        In the Linux kernel, the following vulnerability has been resolved:  usb: gadget: f_printer: take kref only for successful open  printer_open() returns -EBUSY when the character device is already open, but it increments dev->kref regardless of the return value. VFS does not call ->release() for a failed open, so every rejected second open permanently leaks one reference.  Move kref_get() into the successful-open branch.

CVE-2026-64348:

        In the Linux kernel, the following vulnerability has been resolved:  usb: free iso schedules on failed submit  EHCI and FOTG210 isochronous submits build an ehci_iso_sched before linking the URB to the endpoint queue, and keep the staged schedule in urb->hcpriv until iso_stream_schedule() and the link helpers consume it. If the controller is no longer accessible, or usb_hcd_link_urb_to_ep() fails, submit jumps to done_not_linked before that handoff happens and leaks the staged schedule still attached to urb->hcpriv.  Free the staged schedule from done_not_linked when submit fails before the URB is linked and clear urb->hcpriv after the free.  The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1.1.  An x86_64 allyesconfig build showed no new warnings. As we do not have an EHCI host controller with a USB isochronous device to test with, no runtime testing was able to be performed.

CVE-2026-64388:

        In the Linux kernel, the following vulnerability has been resolved:  smb/client: fix chown/chgrp with SMB3 POSIX Extensions  Ownership (chown) and group (chgrp) modifications were being ignored when mounting with SMB3 POSIX Extensions unless CIFS_MOUNT_CIFS_ACL or CIFS_MOUNT_MODE_FROM_SID were also explicitly set.  Fix this by checking for posix_extensions in cifs_setattr_nounix() when updating UID and GID, ensuring that id_mode_to_cifs_acl() is called to map and set the ownership/group information on the server.

CVE-2026-64389:

        In the Linux kernel, the following vulnerability has been resolved:  ksmbd: validate NTLMv2 response before updating session key  ksmbd_auth_ntlmv2() derives the NTLMv2 session key into sess->sess_key before it verifies the NTLMv2 response. ksmbd_decode_ntlmssp_auth_blob() then continues into KEY_XCH even when ksmbd_auth_ntlmv2() failed.  With SMB3 multichannel binding, the failed authentication operates on an existing session and the session setup error path does not expire binding sessions. A client can send a binding session setup with a bad NT proof and KEY_XCH and still modify sess->sess_key before STATUS_LOGON_FAILURE is returned.  Relevant path:    smb2_sess_setup()     -> conn->binding = true     -> ntlm_authenticate()        -> session_user()        -> ksmbd_decode_ntlmssp_auth_blob()           -> ksmbd_auth_ntlmv2()              -> calc_ntlmv2_hash()              -> hmac_md5_usingrawkey(..., sess->sess_key)              -> crypto_memneq() returns mismatch           -> KEY_XCH arc4_crypt(..., sess->sess_key, ...)     -> out_err without expiring the binding session  Derive the base session key into a local buffer and copy it to sess->sess_key only after the proof matches. Return immediately on authentication failure so KEY_XCH is only processed after successful authentication.

CVE-2026-64391:

        In the Linux kernel, the following vulnerability has been resolved:  ksmbd: use opener credentials for ADS I/O  Alternate data streams are stored as xattrs. Unlike regular file I/O, their read and write paths therefore call VFS xattr helpers which recheck inode permissions and LSM policy using the current task credentials.  Run ADS I/O with the credentials captured when the SMB handle was opened.

CVE-2026-64392:

        In the Linux kernel, the following vulnerability has been resolved:  ksmbd: use opener credentials for delete-on-close  Delete-on-close can be completed by deferred or durable handle teardown, where no request work is available. Both the base-file unlink and the ADS xattr removal consequently run with the ksmbd worker credentials and can bypass filesystem permission checks.  Run both operations with the credentials captured in struct file when the handle was opened. This preserves the authenticated user's fsuid, fsgid, supplementary groups and capability restrictions at final close.

CVE-2026-64400:

        In the Linux kernel, the following vulnerability has been resolved:  ksmbd: prevent path traversal bypass by restricting caseless retry  ksmbd_vfs_path_lookup() enforces LOOKUP_BENEATH to restrict path resolution within the share root. When a crafted path attempts to escape the share boundary using parent-directory components ('..'), vfs_path_parent_lookup() detects this and immediately fails, returning -EXDEV.  However, a bug exists in __ksmbd_vfs_kern_path() under caseless mode. The function fails to intercept the -EXDEV error and erroneously falls through to the caseless retry logic, which is intended only for genuinely missing files. During this retry process, the path is reconstructed, leading to an unintended LOOKUP_BENEATH bypass that allows write-capable users to create zero-length files or directories outside the exported share.  Fix this by ensuring that the execution only proceeds to the caseless lookup retry when the error is specifically -ENOENT. Any other errors, such as -EXDEV from a path traversal attempt, must be returned immediately.

CVE-2026-64424:

        In the Linux kernel, the following vulnerability has been resolved:  netpoll: fix a use-after-free on shutdown path  There is a use-after-free error on netpoll, which is clearly detected by KASAN.        BUG: KASAN: slab-use-after-free in _raw_spin_lock_irqsave+0x3b/0x80       Read of size 1 at addr ... by task kworker/9:1       Workqueue: events queue_process       Call Trace:        skb_dequeue+0x1e/0xb0        queue_process+0x2c/0x600        process_scheduled_works+0x4b6/0x850        worker_thread+0x414/0x5a0       Allocated by task 242:        __netpoll_setup+0x201/0x4a0        netpoll_setup+0x249/0x550        enabled_store+0x32f/0x380       Freed by task 0:        kfree+0x1b7/0x540        rcu_core+0x3f8/0x7a0  The problem happens when there is a pending TX worker running in parallel with the cleanup path.  This is what happens on netpoll shutdown path:  1) __netpoll_cleanup() is called 2) set dev->npinfo to NULL 3) call_rcu() with rcu_cleanup_netpoll_info()   3.1) rcu_cleanup_netpoll_info() tries to cancel all workers with        cancel_delayed_work(), but doesn't wait for the worker to finish 4) and kfree(npinfo);  Because 3.1) doesn't really cancel the work, as the comment says "we can't call cancel_delayed_work_sync here, as we are in softirq", the TX worker can run after 4).  Tl;DR: queue_process() is not an RCU reader, it reaches npinfo through the work item via container_of().  Use disable_delayed_work_sync() to ensure the worker is completely stopped and prevent any future re-arming attempts. Once npinfo is set to NULL, senders will bail out and not queue new work. The disable flag ensures any in-flight re-arming attempts also fail silently.  In the future, we can do the cleanup inline here without needing the npinfo->rcu rcu_head, but that is net-next material.

CVE-2026-64463:

        In the Linux kernel, the following vulnerability has been resolved:  usb: typec: tcpci_rt1711h: unregister TCPCI port with devres  rt1711h_probe() registers the TCPCI port before requesting the interrupt and enabling alert interrupts. If either of those later steps fails, the probe function returns without unregistering the TCPCI port. The explicit unregister currently only happens from the remove callback.  Register a devres action immediately after tcpci_register_port() succeeds, so tcpci_unregister_port() runs on later probe failures and on driver detach. Drop the remove callback to avoid unregistering the same port twice.  This issue was identified during our ongoing static-analysis research while reviewing kernel code.

CVE-2026-64481:

        In the Linux kernel, the following vulnerability has been resolved:  ALSA: hda/cs35l41: Fix firmware load work teardown  cs35l41_hda creates ALSA controls whose private data points at the cs35l41_hda object. The firmware load control can also queue fw_load_work.  Those controls are not removed on component unbind, and device remove only cancels fw_load_work through cs35l41_remove_dsp(). That helper is skipped when halo_initialized is false. With firmware_autostart disabled, a firmware load can be requested before the DSP has been initialized. If the component or device is removed before the queued work runs, the worker can run after teardown and dereference driver state that is no longer valid.  Track the created controls and remove them on unbind so no new control callback can reach the driver data or queue more work. Then cancel fw_load_work to drain any request that was already queued. Also cancel the work unconditionally during device remove before runtime PM teardown.

CVE-2026-64513:

        In the Linux kernel, the following vulnerability has been resolved:  KVM: x86: Unconditionally recompute CR8 intercept on PPR update  The TPR_THRESHOLD field in the VMCS is used by VMX to induce VM exits when the guest's virtual TPR falls under the specified threshold, allowing KVM to inject previously masked interrupts.  KVM handles these VM exits in handle_tpr_below_threshold(). Commit eb90f3417a0c ("KVM: vmx: speed up TPR below threshold vmexits") optimized this function by calling apic_update_ppr() instead of raising KVM_REQ_EVENT. apic_update_ppr() then raises KVM_REQ_EVENT if there is a pending, deliverable interrupt.  However, if there are no new interrupts pending, apic_update_ppr() does not issue the request. Thus, kvm_lapic_update_cr8_intercept() and vmx_update_cr8_intercept() are not called before VM entry, which results in a high, stale TPR_THRESHOLD. This is problematic due to the following sentence in 28.2.1.1 "VM-Execution Control Fields" in the SDM:    The following check is performed if the “use TPR shadow” VM-execution   control is 1 and the “virtualize APIC accesses” and “virtual-interrupt   delivery” VM-execution controls are both 0: the value of bits 3:0 of   the TPR threshold VM-execution control field should not be greater   than the value of bits 7:4 of VTPR.  This error condition is typically not observed when KVM runs on a bare metal system because modern processors support APICv, which enables virtual-interrupt delivery, and which KVM uses when possible. This causes the processor to no longer generate TPR-below-threshold exits and to no longer check TPR_THRESHOLD on entry. However, when running on older platforms, or under nested virtualization on a hypervisor that does not support virtual-interrupt delivery and enforces this check (like Hyper-V) this can cause a VM entry failure with hardware error 0x7, as seen in [1].  Call kvm_lapic_update_cr8_intercept() if apic_update_ppr() does not find a deliverable interrupt (and thus does not raise KVM_REQ_EVENT). Remove calls to kvm_lapic_update_cr8_intercept() on paths that end up in apic_update_ppr(), as they now become redundant. This ensures that any path that updates the guest's PPR also figures out if KVM needs to wait for a TPR change (using TPR_THRESHOLD on VMX or CR8 intercepts on SVM).

CVE-2026-64556:

        In the Linux kernel, the following vulnerability has been resolved:  perf/core: Detach event groups during remove_on_exec  perf_event_remove_on_exec() removes events by calling perf_event_exit_event(). For top-level events, this removes the event from the context with DETACH_EXIT only.  This can leave inconsistent group state when a removed event is a group leader and the group contains siblings without remove_on_exec. If the group was active, the surviving siblings can remain active and attached to the removed leader's sibling list, but are no longer represented by a valid group leader on the PMU context active lists.  A later close of the removed leader uses DETACH_GROUP and can promote the still-active siblings from this stale group state. The next schedule-in can then add an already-linked active_list entry again, corrupting the PMU context active list.  With DEBUG_LIST enabled, this is caught as a list_add double-add in merge_sched_in().  Fix this by detaching group relationships when remove_on_exec removes an event. This preserves the existing task-exit and revoke behavior, while ensuring surviving siblings are ungrouped before the removed event leaves the context.

CVE-2026-68081:

        In the Linux kernel, the following vulnerability has been resolved:  KVM: nVMX: Put vmcs12 pages if nested VM-Enter fails due to invalid guest state  Put all vmcs12 pages if KVM synthesizes a nested VM-Exit due to invalid guest while emulating VMLAUNCH or VMRESUME.  The invalid guest state path doesn't use nested_vmx_vmexit() as that API is intended to be used if and only if L2 is active, and the open coded equivalent neglects to put the vmcs12 pages.  Failure to put the vmcs12 pages leaks any pinned pages (and/or mappings) if L1 retries VMLAUNCH/VMRESUME.  Note, the !from_vmenter scenario doesn't suffer the same problem, as vmx_get_nested_state_pages() only gets/pins/maps the vmcs12 pages if L2 is active, i.e. if a "full" VM-Exit is guaranteed before KVM will retry getting vmcs12 pages.

CVE-2026-68083:

        In the Linux kernel, the following vulnerability has been resolved:  ksmbd: fix path resolution in ksmbd_vfs_kern_path_create  The SMB2 open lookup is rooted at the share with LOOKUP_BENEATH, but the create/mkdir/hardlink sink is not: ksmbd_vfs_kern_path_create() builds an absolute path with convert_to_unix_name() and resolves it from AT_FDCWD via start_creating_path(), so a ".." component is walked from the real filesystem root and escapes the export.  An authenticated client races a missing path component so the rooted open lookup returns -ENOENT (taking the create branch) while the same component is present (a directory) when the create walk runs; the create then resolves ".." out of the share.  Root the create walk at the share like the lookup and rename paths already are: resolve the parent with vfs_path_parent_lookup(..., LOOKUP_BENEATH, &share_conf->vfs_path) and create the final component with start_creating_noperm(). convert_to_unix_name() then has no callers and is removed.

CVE-2026-68085:

        In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: hci_uart: clear HCI_UART_SENDING when write_work is canceled  HCI_UART_SENDING bit in tx_state means write_work is pending and blocks queueing it again.  Currently this bit is not cleared when canceling the work in hci_uart_close(), which blocks future writes when device is reopened later if write_work was pending.  Fix by clearing HCI_UART_SENDING when canceling the work.  Also make clearing of tx_skb safe by using disable_work_sync + enable_work instead of just cancel_work_sync.  hci_uart_flush() purges the proto tx queue so we can cancel the pending write_work there, instead of doing it just in hci_uart_close().  Re-enable and possibly requeue the work after queue flush.

CVE-2026-68086:

        In the Linux kernel, the following vulnerability has been resolved:  mm/khugepaged: write all dirty file folios when collapsing  [There is no upstream commit, as this code was removed by upstream  commit 044925f9b565 ("mm: fs: remove filemap_nr_thps*() functions and their users")]  As-is, khugepaged and writable-file opening exclude each other. A file cannot be open writeable and have THPs (because the filesystem is not aware of them). khugepaged will never collapse file pages for files that are opened writeable. On an open(O_RDWR/O_WRONLY), the page cache for that particular file is dropped. This is fine because nothing could've been dirtied.  However, there is an edge-case: collapse_file() might not be able to coexist with concurrent writers, but it can coexist with dirty folios (from previous writers). Therefore, the following can happen:  open(file, O_RDWR) write(file) close(file) madvise(file_mapping, MADV_COLLAPSE, some non-dirty range) open(file, O_RDWR)  nr_thps > 0   truncate_inode_pages()     /* THPs are cleared out, but so are the dirty folios */  When this edge-case happens, there is data loss, as the dirty folios are fully discarded.  Fix it by fully writing back the page cache (and waiting) when collapsing file THPs. Doing so provides the guarantee that no dirty folio will be observed while there are active THPs. To fully ensure this is safe, the invalidate_lock needs to be held while doing the writeout, so that do_dentry_open()'s page cache truncation excludes this write-and-wait.  As a side effect, move the nr_thps counter bumping outside the i_pages lock. This is correct since the counter itself is an atomic_t and the producer <-> consumer correctness is provided by a full memory barrier: smp_mb() in collapse_file()/memory barrier implied by full ordering in get_write_access() -> atomic_inc_unless_negative().

CVE-2026-68098:

        In the Linux kernel, the following vulnerability has been resolved:  ksmbd: bound DACL dedup walk to copied ACEs  set_ntacl_dacl() can stop copying ACEs before consuming the full input DACL when size accounting overflows.  When that happens, num_aces reflects only the ACEs that were actually copied into the output DACL, but set_posix_acl_entries_dacl() still receives nt_num_aces and uses it to walk the existing ACE array during dedup.  That makes the dedup walk scan past the copied ACE array and inspect buffer tail that does not contain valid ACEs.  Split the two meanings currently carried by the NT ACE count. Pass the number of copied NT ACEs to bound the dedup walk, and preserve the original "input DACL had NT ACEs" state separately for the Everyone/default ACL fallback.  This keeps the dedup walk aligned with the ACEs that are actually present in the rebuilt DACL.

CVE-2026-68102:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu: fix aperture mapping leak  amdgpu_pci_remove() calls drm_dev_unplug() before invoking the driver fini routines. This causes drm_dev_enter() in amdgpu_ttm_fini() to always return false, so iounmap(aper_base_kaddr) never runs on normal driver unload, leaving an orphaned entry in the x86 PAT interval tree.  On connected_to_cpu hardware, the aperture is mapped write-back (WB) via ioremap_cache(). On reload, IP discovery calls memremap(..., MEMREMAP_WC) over the same range. The WC vs WB conflict causes:    ioremap error for 0x..., requested 0x1, got 0x0   amdgpu: discovery failed: -2  Fix by switching to devres-managed mappings so cleanup is guaranteed regardless of drm_dev_enter() state:  - connected_to_cpu path: devm_memremap(MEMREMAP_WB). For   IORESOURCE_SYSTEM_RAM ranges this takes the try_ram_remap() shortcut,   returning __va(offset) from the existing kernel direct map. No new   ioremap VA or PAT entry is created, so there is nothing to orphan.  - dGPU path: devm_ioremap_wc() registers iounmap() as a devres action,   guaranteeing cleanup at device_del() time.  Also remove iounmap(aper_base_kaddr) from amdgpu_device_unmap_mmio() since the mapping is now devres-owned.  v2: Remove redundant x86_64 guard (Lijo)  (cherry picked from commit d871e99879cb5fd1fa798b006b4888887e63a17a)

CVE-2026-68112:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu/gfx9.4.3: replace BUG_ON() with WARN_ON()  There's no need to crash the kernel for these cases.  (cherry picked from commit 5676593d08998d7a6d9e2d51d6b54b3820e3755c)

CVE-2026-68118:

        In the Linux kernel, the following vulnerability has been resolved:  tcp: challenge ACK for non-exact RST in SYN-RECEIVED  The SYN-RECEIVED request-socket path in tcp_check_req() accepts an in-window RST without requiring SEG.SEQ to exactly match RCV.NXT.  A non-exact RST therefore removes the request instead of eliciting a challenge ACK.  RFC 9293 section 3.10.7.4 applies the RFC 5961 reset check in SYN-RECEIVED: an exact RST resets the connection, while a non-exact in-window RST must trigger a challenge ACK and be dropped.  Apply that check before the ACK-field validation, following the RFC sequence-number, RST, then ACK processing order.  Factor the per-netns challenge ACK quota out of tcp_send_challenge_ack() so request sockets can share it.  Use the request socket's send_ack() callback and its own out-of-window ACK timestamp to send and rate-limit the response.

CVE-2026-68152:

        In the Linux kernel, the following vulnerability has been resolved:  amt: fix use-after-free in AMT delayed works  When an AMT device is removed, pending delayed works can still access the freed amt_dev structure, which may result in kernel crashes or memory corruption.  amt_dev_stop() cancels req_wq and discovery_wq with cancel_delayed_work_sync(), but these works can be scheduled again from event_wq after the cancellation. This allows delayed works to access the freed amt_dev structure after the netdev has been released.  The following is a simple race scenario:  CPU0                         CPU1  amt_dev_stop() cancel_delayed_work_sync()                              amt_event_work()                              mod_delayed_work(req_wq) free netdev                              req_wq accesses freed amt_dev  Use disable_delayed_work_sync() in amt_dev_stop() to prevent req_wq and discovery_wq from being queued again and wait for running work items to complete.  The delayed works are disabled after initialization in amt_newlink() and enabled only when the device is successfully opened. This keeps the delayed work lifecycle synchronized with the lifetime of the AMT device.

CVE-2026-68185:

        In the Linux kernel, the following vulnerability has been resolved:  LoongArch: Move jump_label_init() before parse_early_param()  When enabling both CONFIG_MEM_ALLOC_PROFILING=y and CONFIG_MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT=y, then diabling memory profiling by adding the boot parameter 'sysctl.vm.mem_profiling=0' will cause the kernel failed to boot.  After analysis, this is because jump_label_init() must be called before parse_early_param(), the early param handlers may modify static keys by static_branch_enable/disable().  Fix this by moving jump_label_init() to before parse_early_param(). The solution is similar to other architectures.

CVE-2026-68203:

        In the Linux kernel, the following vulnerability has been resolved:  media: vivid: fix cleanup bugs in vivid_init()  When platform_device_register() fails in vivid_init(), the embedded struct device in vivid_pdev has already been initialized by device_initialize(), but the failure path jumps to free_output_strings without dropping the device reference for the current platform device:    vivid_init()     -> platform_device_register(&vivid_pdev)        -> device_initialize(&vivid_pdev.dev)        -> setup_pdev_dma_masks(&vivid_pdev)        -> platform_device_add(&vivid_pdev)  This leads to a reference leak when platform_device_register() fails. Fix this by calling platform_device_put() before jumping to the common cleanup path.  Also, the unreg_driver label incorrectly calls platform_driver_register() instead of platform_driver_unregister(), which breaks cleanup when workqueue creation fails after successful driver registration. Fix that as well.  The reference leak was identified by a static analysis tool I developed and confirmed by manual review. The incorrect cleanup call was found during code inspection.

CVE-2026-68205:

        In the Linux kernel, the following vulnerability has been resolved:  media: v4l2-fwnode: Fix subdev owner overwritten in v4l2_async_register_subdev_sensor()  The v4l2 helper v4l2_async_register_subdev_sensor() calls v4l2_async_register_subdev(), which is a macro that expands to __v4l2_async_register_subdev(sd,THIS_MODULE). Since the macro is expanded inside v4l2-fwnode.c, THIS_MODULE resolves to the v4l2-fwnode module rather than the sensor driver module that originally set sd->owner. When v4l2-fwnode is built-in, THIS_MODULE evaluates to NULL, which then overwrites the sensor driver's owner with NULL.  This causes the problem that the sensor module's reference count is never incremented during async registration, so the module can be removed while the subdevice is still in use by a notifier (e.g., a CSI-2 receiver bridge driver).  Fix this by renaming v4l2_async_register_subdev_sensor() to __v4l2_async_register_subdev_sensor() with an added explicit module argument and introducing a wrapper macro:     #define v4l2_async_register_subdev_sensor(sd) \         __v4l2_async_register_subdev_sensor(sd, THIS_MODULE)  This ensures the sensor driver module is properly referenced even when the sensor driver does not init the owner field before calling v4l2_async_register_subdev_sensor() and prevents premature module removal.

CVE-2026-68233:

        In the Linux kernel, the following vulnerability has been resolved:  drm/vc4: Shut down BO cache timer before teardown  The BO cache timer callback schedules time_work, and time_work can rearm the timer through vc4_bo_cache_free_old().  vc4_bo_cache_destroy() deletes the timer and then cancels the work, which does not break that cycle: the work being cancelled can rearm the timer, and the timer then queues work again after teardown.  Use timer_shutdown_sync() instead, so the timer cannot be rearmed and the cycle ends with cancel_work_sync().

CVE-2026-68238:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu: Release VFCT ACPI table reference  amdgpu_acpi_vfct_bios() fetches the VFCT table with acpi_get_table() but never releases it. acpi_get_table() takes a reference on the table (incrementing its validation_count and mapping it on the 0->1 transition); without a paired acpi_put_table() the mapping is leaked on every call, whether or not a matching VBIOS image is found.  Route all exit paths after the table is acquired through a common acpi_put_table(). The VBIOS image is copied out with kmemdup() before the table is released, so it remains valid for the caller.  (cherry picked from commit ca5988682b4cba4cd125a0fa99b2de1239164ae4)

CVE-2026-68241:

        In the Linux kernel, the following vulnerability has been resolved:  drm/i915/mst: limit DP MST ESI service loop  The loop in intel_dp_check_mst_status() keeps servicing interrupts originating from the sink without bound. Add an upper bound to the new interrupts occurring during interrupt processing to not get stuck on potentially stuck sink devices. Use arbitrary 32 tries to clear incoming interrupts in one go.  Discovered using AI-assisted static analysis confirmed by Intel Product Security.  Note: The condition likely pre-dates the commit in the Fixes: tag, but this is about as far back as a backport has any chance of succeeding. Before that, the retry had a goto.  (cherry picked from commit b4ea5272133059acb493cc36599071a9e852ec2e)

CVE-2026-68242:

        In the Linux kernel, the following vulnerability has been resolved:  drm/i915/gt: Fix NULL deref on sched_engine alloc failure  Avoid using intel_context_put() before intel_context_init() in execlists_create_virtual() as the kref_put() inside would lead to NULL deref on the IOCTL path when sched_engine allocation fails.  Discovered using AI-assisted static analysis confirmed by Intel Product Security.  (cherry picked from commit 4f2a12f2d50e9f48227656e4dcbd6423506be31d)

CVE-2026-68247:

        In the Linux kernel, the following vulnerability has been resolved:  drm/i915/bios: range check LFP Data Block panel_type2  While the panel_type from LFP Data Block is range checked, panel_type2 is not. Add a few helpers for range checking, and use them to not only check panel_type2, but also improve clarity and correctness in the panel type selection.  Discovered using AI-assisted static analysis confirmed by Intel Product Security.  v2: - Fix commit message typo (Michał) - Add is_panel_type_pnp() (Ville)  (cherry picked from commit c9ebe5d2f25729d6cfbbb1235d640bf67f9275df)

CVE-2026-68258:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdkfd: Check bounds on CRIU restore queue type and mqd size  We weren't checking whether the values provided in the private data in kfd CRIU restore were within bounds.  For queue type, add a KFD_QUEUE_TYPE_MAX and ensure the provided type is less than it.  For mqd_size, add new function mqd_size_from_queue_type and confirm that the provided mqd_size matches expectations.  (cherry picked from commit f19d8086f6644083c913d70bfdeee20e1b6f46a5)

CVE-2026-68273:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu: Fix context pstate override handling  There are several problems in the context pstate handling code.  The most serious ones are potential use-after-free and NULL pointer dereferences at context initialization time. Both are due amdgpu_ctx_init() not holding the adev->pm.stable_pstate_ctx_lock, which is otherwise used from both sysfs and the context code itself for modifying and clearing the stored context pointer.  Second issue is that context fini can trample over the pstate configuration set via sysfs. This is due the restore state (ctx->stable_pstate) being saved at context init time, and not if, or when the context actually changes the pstate. As the context exits it will therefore incorrectly restore to what was set before the sysfs override was requested.  The simplest fix is to drastically simplify how the state is tracked, by clearly defining the points at which pstate ownership is taken and released, and to handle all transitions under the correct lock.  Instead of at context init time, the previous state is saved only at the point the context overrides the current state, and is restored on context exit only if the context is still the owner of the current override state.  (cherry picked from commit 1b5e413713c0a93bc1818394d0ce49aaad21bd27)

CVE-2026-68293:

        In the Linux kernel, the following vulnerability has been resolved:  net/mlx5: Fix MCIA register buffer overflow on 32 dword reads  The MCIA register can return up to 32 dwords (128 bytes) when the device advertises the mcia_32dwords capability, but struct mlx5_ifc_mcia_reg_bits only defines dword_0..11, leaving room for just 12 dwords (48 bytes) of data.  mlx5_query_mcia() clamps the read size to mlx5_mcia_max_bytes() and then memcpy()s that many bytes out of the register, potentially reading past the end of the 'out' buffer. On kernels built with FORTIFY_SOURCE this is caught as a buffer overflow while reading the module EEPROM via ethtool:    detected buffer overflow in memcpy   kernel BUG at lib/string_helpers.c:1048!   RIP: 0010:fortify_panic+0x13/0x20   Call Trace:    mlx5_query_mcia.isra.0+0x200/0x210 [mlx5_core]    mlx5_query_module_eeprom_by_page+0x4a/0xa0 [mlx5_core]    mlx5e_get_module_eeprom_by_page+0xbb/0x120 [mlx5_core]    eeprom_prepare_data+0xf3/0x170    ethnl_default_doit+0xf1/0x3b0  Extend the mcia_reg layout to 32 dwords.

CVE-2026-68303:

        In the Linux kernel, the following vulnerability has been resolved:  drm/vc4: hvs/v3d: Fix null dereference in unbind  The hvs and v3d drivers use dev_get_drvdata(master) in their unbind functions. Since the vc4-drm gets removed before its dependent drivers (vc4_hvs/vc4_v3d) the vc4_hvs_unbind/vc4_v3d_unbind functions try to get drvdata of its master and fails with a null dereference error.  Use the data pointer passed to the unbind functions directly instead of dev_get_drvdata(master). This avoids using potentially freed memory.

CVE-2026-68312:

        In the Linux kernel, the following vulnerability has been resolved:  cifs: fix cifsFileInfo leak on kmalloc failure in deferred close drain paths  In cifs_close_deferred_file(), cifs_close_all_deferred_files(), and cifs_close_deferred_file_under_dentry(), when a pending deferred close is cancelled via cancel_delayed_work(), the subsequent kmalloc_obj() to add the file to the local processing list may fail under memory pressure. The loop breaks immediately, but the cancelled work is no longer pending (it would have called _cifsFileInfo_put()), and the cfile is never added to file_head for processing.  The cifsFileInfo reference and the open server handle both leak.  Fix by saving the cfile that failed allocation in a local variable, breaking as before, and calling _cifsFileInfo_put() on it after releasing the lock.  Any files later in the iteration are unaffected since their deferred work is still pending and will fire normally.

CVE-2026-68323:

        In the Linux kernel, the following vulnerability has been resolved:  tipc: serialize udp bearer replicast list updates  tipc_udp_rcast_add() and cleanup_bearer() both update ub->rcast.list with list_add_rcu() / list_del_rcu(), but nothing serializes them. The add runs from the encap receive softirq (via tipc_udp_rcast_disc()) without rtnl_lock(), so it can race the cleanup delete and corrupt the list:    list_del corruption. prev->next should be ffff8880298d7ab8,     but was ffff88802449ad38. (prev=ffff888027e3ec98)   kernel BUG at lib/list_debug.c:62!   RIP: __list_del_entry_valid_or_report+0x17a/0x200   Workqueue: events cleanup_bearer   Call Trace:    cleanup_bearer (net/tipc/udp_media.c:811)    process_one_work (kernel/workqueue.c:3302)    worker_thread (kernel/workqueue.c:3466)  The bearer can be enabled from an unprivileged user namespace, as the TIPCv2 generic-netlink ops carry no GENL_ADMIN_PERM.  Add a spinlock to struct udp_bearer and take it around the list_add_rcu() in tipc_udp_rcast_add() and the list_del_rcu() loop in cleanup_bearer() so the two writers can no longer corrupt the list.  Reject a duplicate peer under the same lock before allocating, and remove tipc_udp_is_known_peer(). The old lockless pre-check in tipc_udp_rcast_disc() was racy: two softirqs discovering the same peer could both find it absent and add it twice.  cleanup_bearer() runs from a workqueue after tipc_udp_disable() clears the bearer's up bit, so an encap softirq can still reach tipc_udp_rcast_add() and add a peer after cleanup_bearer() has already emptied the list, leaking that entry when the bearer is freed. Mark the bearer disabled under rcast_lock once the list is emptied and refuse further additions.

CVE-2026-68329:

        In the Linux kernel, the following vulnerability has been resolved:  iommu/amd: Wait for completion instead of returning early in iommu_completion_wait()  need_sync is a per-IOMMU flag shared by all domains and devices behind that IOMMU. It is set whenever a command is queued with sync == true and cleared when a completion-wait (CWAIT) command is queued. However, a cleared need_sync only means that a covering CWAIT has been queued, not that all previously queued commands have actually completed in hardware.  iommu_completion_wait() read need_sync locklessly and returned early when it was false. This breaks the "block until all previously queued commands have completed" contract in a multi-CPU scenario:    CPU2: queue inv-B                  => need_sync = true   CPU1: queue CWAIT(N); need_sync = false; then wait_on_sem(N)   CPU2: read need_sync == false      => return 0 (no wait!)  CPU2 returns without waiting for any sequence number even though its inv-B may not have completed yet (CWAIT(N), queued after inv-B, has not been signaled). CPU2 then proceeds to, for example, free page-table pages while the IOMMU can still walk stale translations, opening a use-after-free window. This is a logical race in the meaning of the flag, not a memory-visibility issue, so barriers alone do not help.  Fix it without losing the optimization of avoiding redundant CWAIT commands: take iommu->lock before testing need_sync, and when it is false do not return early but wait for the last allocated sequence number (cmd_sem_val). Since need_sync == false implies no sync command was queued after the last CWAIT, that CWAIT is FIFO-ordered after every not-yet-completed command, so waiting for its sequence number guarantees all prior commands (possibly queued by another CPU) have completed. The common path with pending work is unchanged and no extra hardware command is issued.

CVE-2026-68337:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: Reject redirect helpers without a bpf_net_context  The bpf_redirect*() helpers and skb_do_redirect() obtain the per-task bpf_redirect_info via bpf_net_ctx_get_ri(), which dereferences the current->bpf_net_context unconditionally. That context is established on the paths that run tc BPF such as sch_handle_{ingress,egress}(), *except* for the case where {cls,act}_bpf was attached to a proper qdisc. A program running from there reaches the NULL deref in two ways:  * It calls bpf_redirect() directly, which dereferences the context at   the top of the helper:       tc qdisc add dev eth0 root handle 1: red limit 1MB min 10KB max 20KB \         avpkt 1000 burst 100 qevent early_drop block 10      tc filter add block 10 pref 1 bpf obj redirect.o  * It simply returns TC_ACT_REDIRECT without helper call: tcf_qevent_handle()   then dispatches to skb_do_redirect(), which dereferences the context  Rather than extending bpf_net_context management into the qdisc path, make the redirect helpers refuse to operate when no context exists, and have tcf_qevent_handle() drop a TC_ACT_REDIRECT verdict instead of calling skb_do_redirect(). Previous behaviour was a crash, so nothing regresses by not supporting it.

CVE-2026-68396:

        In the Linux kernel, the following vulnerability has been resolved:  scsi: core: wake eh reliably when using scsi_schedule_eh  Drivers which use the scsi_schedule_eh function to run the error handler currently risk the error handler thread never waking once all commands are timed out or inactive. There is no enforced memory order between setting the host into error recovery state and counting busy commands. This can result in a race with scsi_dec_host_busy where neither CPU sees both conditions of all commands inactive and the host error state to request waking the error handler.  To fix this, run the scsi_schedule_eh's scsi_eh_wakeup from a new work item which will use rcu to ensure scsi_schedule_eh's call to scsi_host_busy will occur after the error state is globally visible and will be seen by any current scsi_dec_host_busy callers.

CVE-2026-68399:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: Fix UAF in sock clone early bailouts  Similar to recent commit 9b51a6155d14 ("bpf,fork: wipe ->bpf_storage before bailouts that access it"), sk_clone() performs an initial shallow copy of the socket field ->sk_bpf_storage via sock_copy() for the cloned socket newsk.  If sk_clone() bails out early (e.g. if sk_filter_charge() fails) prior to calling bpf_sk_storage_clone(), newsk->sk_bpf_storage still points to the parent socket's BPF local storage. When newsk is subsequently freed via sk_free(), the deallocation path (__sk_destruct() -> bpf_sk_storage_free()) destroys the parent socket's BPF local storage, leading to a use-after-free (UAF) on the parent socket.  Fix this by resetting newsk->sk_bpf_storage to NULL immediately after sock_copy() in sk_clone(), and remove the now redundant initialization from bpf_sk_storage_clone().

CVE-2026-68401:

        In the Linux kernel, the following vulnerability has been resolved:  firmware: arm_ffa: Fix out-of-bound writes in ffa_setup_and_transmit()  Sashiko (locally) reports multiple out-of-bound issues in ffa_setup_and_transmit: 1) Writing ep_mem_access->reserved can write out of bounds for FFA    versions < 1.2 as ffa_emad_size_get() returns 16 bytes in that case    while reserved has an offset of 24.    Instead of zeroing fields, memset the struct to zero first based on    the FFA version.  2) Make sure there is enough size to write constituents.  While at it, convert the only sizeof() in the driver that uses a type instead of variable.

CVE-2026-68404:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: cfg80211: use wiphy work for socket owner autodisconnect  nl80211_netlink_notify() walks the cfg80211 wireless device list when a NETLINK_GENERIC socket is released. If the socket owns a connection, the notifier queues the embedded wdev->disconnect_wk work item.  That work is a plain work_struct today. NETDEV_GOING_DOWN cancels it, but a NETLINK_URELEASE notifier that already observed conn_owner_nlportid can queue it after that cancel returns. _cfg80211_unregister_wdev() then removes the wdev from the list and waits for RCU readers, but synchronize_net() does not drain work queued by such a reader.  Make the autodisconnect work a wiphy_work instead. The callback already needs the wiphy mutex, and wiphy_work runs under that mutex. This lets teardown cancel pending autodisconnect work while holding the mutex, without a cancel_work_sync() vs. worker locking concern.  Also cancel the wiphy work after list_del_rcu() and synchronize_net(). Any NETLINK_URELEASE notifier that had already reached the wdev list has then either queued the work and it is removed, or can no longer find the wdev.

CVE-2026-68408:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: cfg80211: convert pmsr_free_wk to wiphy_work to fix deadlock  When a netlink socket that owns a PMSR session is closed, cfg80211_release_pmsr() clears the request's nl_portid and queues pmsr_free_wk to call cfg80211_pmsr_process_abort() asynchronously.  If the interface tears down concurrently, cfg80211_pmsr_wdev_down() is called under wiphy_lock and calls cancel_work_sync(&pmsr_free_wk) to wait for any running work. The work function acquires wiphy_lock via guard(wiphy) before calling process_abort.  This is a deadlock: wdev_down holds wiphy_lock and blocks inside cancel_work_sync(); pmsr_free_wk blocks trying to acquire that same wiphy_lock. Neither thread can proceed.  The same deadlock is reachable from cfg80211_leave_locked(), which calls cfg80211_pmsr_wdev_down() for all interface types under wiphy_lock.  Fix this by converting pmsr_free_wk from a plain work_struct to a wiphy_work. The wiphy_work dispatcher holds wiphy_lock when running work items, so the explicit guard(wiphy) in the work function is no longer needed. wiphy_work_cancel() can be called safely while holding wiphy_lock - since wiphy_lock prevents the work from running concurrently, wiphy_work_cancel() never blocks, eliminating the deadlock.  Remove the cancel_work_sync() for pmsr_free_wk from the NETDEV_GOING_DOWN handler. cfg80211_leave(), called unconditionally just before it, already cancels any pending work under wiphy_lock via wiphy_work_cancel() inside cfg80211_pmsr_wdev_down().

CVE-2026-68409:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: mac80211: defer link RX stats percpu free to RCU  sta_remove_link() frees a removed MLO link's RX stats percpu buffer right away, but defers only the link container to RCU:  	sta_info_free_link(&alloc->info); 	kfree_rcu(alloc, rcu_head);  The RX fast path reads link_sta under rcu_read_lock and writes the percpu stats. A reader that resolved link_sta before the removal keeps the pointer. The container stays alive from the kfree_rcu, so the read still works. But the percpu block it points to is already freed. This needs uses_rss. That is when pcpu_rx_stats exists.  The full STA teardown frees the deflink stats only after synchronize_net(). The link removal path had no such barrier. The race is hard to win in practice, but the free should still wait for RCU.  Free the link together with its data from a single RCU callback, so the percpu block is reclaimed only after readers drain.

CVE-2026-68412:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: cfg80211: Fix an error handling path in cfg80211_wext_siwscan()  If the test against IEEE80211_MAX_SSID_LEN fails, then 'creq' leaks. Use the existing error handling path to fix it.

CVE-2026-68418:

        In the Linux kernel, the following vulnerability has been resolved:  RDMA/irdma: Prevent user-triggered null deref on QP create  Previously, the user QP creation path would only attempt to populate iwqp->iwpbl if the user-provided req.user_wqe_bufs field was non-zero. The problem is that iwqp->iwpbl is unconditionally dereferenced later on in irdma_setup_virt_qp.  While there was a check for iwqp->iwpbl != NULL, this check would only occur if req.user_wqe_bufs was non-zero. The end result is that a user could send a zero user_wqe_bufs value and trigger a null ptr deref.  Fix this by unconditionally calling irdma_get_pbl and bailing if it fails, similar to the CQ and SRQ paths.

CVE-2026-68426:

        In the Linux kernel, the following vulnerability has been resolved:  xfrm: fix stale skb->prev after async crypto steals a GSO segment  skb_gso_segment() leaves the segment list head with ->prev pointing at the last segment, an invariant validate_xmit_skb_list() relies on when it sets its tail pointer (tail = skb->prev).  When validate_xmit_xfrm() walks a GSO list and some segments are stolen by async crypto (->xmit() returns -EINPROGRESS), those segments are unlinked from the list but the head ->prev is never updated.  If the last segment is the one stolen, the returned head still has ->prev pointing at it, even though it is now owned by the crypto engine and may be freed.  validate_xmit_skb_list() later does tail->next = skb, writing through that stale pointer -- a use-after-free.  Repoint skb->prev at the last retained segment before returning.

CVE-2026-68435:

        In the Linux kernel, the following vulnerability has been resolved:  LoongArch: Fix address space mismatch in kexec command line lookup  When searching the loaded segments for the "kexec" command line marker, the kexec_load(2) path (file_mode == 0) passes the user-space segment buffer straight to strncmp() through a bogus (char __user *) cast. This dereferences a user pointer in kernel context, which is wrong and is flagged by sparse:    arch/loongarch/kernel/machine_kexec.c:84:51: sparse: incorrect type in   argument 2 (different address spaces) @@ expected char const * @@ got   char [noderef] __user *  Here copy the marker-sized prefix of each segment into a small on-stack buffer with copy_from_user() before comparing, and skip segments that fault. The subsequent copy_from_user() that stages the full command line into the safe area is left unchanged.

CVE-2026-68441:

        In the Linux kernel, the following vulnerability has been resolved:  net/sched: Handle TC_ACT_REDIRECT from qdisc filter chains  When a TC filter attached to a qdisc filter chain returns TC_ACT_REDIRECT (ex: via an eBPF program calling bpf_redirect() or an act_bpf action), the redirect was silently lost i.e no qdisc classify function handled TC_ACT_REDIRECT, so the packet fell through the switch and was enqueued normally instead of being redirected.  This has been broken since bpf_redirect() was introduced for TC in commit 27b29f63058d ("bpf: add bpf_redirect() helper"). We got lucky for a long time because bpf_net_context was a per-CPU variable that was always available.  commit 401cb7dae813 ("net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.") turned bpf_net_context into a task_struct member that is only set up by explicit callers. Without a caller setting it up, bpf_redirect() itself crashes with a NULL pointer dereference in bpf_net_ctx_get_ri(). However, even with bpf_net_context available, TC_ACT_REDIRECT from qdisc filter chains cannot be honored without adding skb_do_redirect() calls to every qdisc classify function, which would require changes across net/sched/. Isolate it to ebpf core where it belongs.  Instead, add a tcf_classify_qdisc() inline helper in pkt_cls.h, as a wrapper around tcf_classify() for use by qdisc classify functions and tcf_qevent_handle(). When the classify verdict is TC_ACT_REDIRECT, the wrapper converts it to TC_ACT_SHOT, dropping the packet rather than letting it continue silently. Dropping is preferred over letting the packet through because the user immediately sees packet loss. Silently passing the packet through would hide the problem and leave the user wondering why their redirect is not working.  The clsact fast path, tc_run() continues to call tcf_classify() directly and is unaffected: TC_ACT_REDIRECT is returned as-is and handled by sch_handle_egress/ingress() calling skb_do_redirect() as before.

CVE-2026-68445:

        In the Linux kernel, the following vulnerability has been resolved:  drm/vc4: Prevent shader BO mappings from becoming writable  vc4_gem_object_mmap() rejects a writable mapping of a validated shader BO, but leaves VM_MAYWRITE set.  Userspace can map the BO read-only and then turn it writable with mprotect().  Validated shader BOs must stay read-only: the validator checks the instructions once and the GPU trusts them afterwards.  A writable mapping lets userspace rewrite the code after validation, bypassing the validator.  Clear VM_MAYWRITE on the read-only path so the mapping cannot be upgraded, as i915 already does for its read-only objects.

CVE-2026-68447:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdkfd: clamp v9 CRIU control stack checkpoint copy to BO size  CRIU checkpoint copies the MQD control stack using cp_hqd_cntl_stack_size from hardware without bounding it to the allocated BO region. If the HW field is larger than the queue's control stack allocation, memcpy reads past the BO into adjacent GTT memory and can leak kernel data to userspace.  Store the page-aligned control stack BO size in mqd_manager and clamp checkpoint copies and reported checkpoint sizes to min(cp_hqd_cntl_stack_size, mm->ctl_stack_size). Apply the same bound for multi-XCC v9.4.3 checkpoint layout.  (cherry picked from commit 6c2abd0ec09e86c6323010673766f76050e28aa3)

CVE-2026-68448:

        In the Linux kernel, the following vulnerability has been resolved:  ovl: check access to copy_file_range source with src mounter creds  Commit 5dae222a5ff0c ("vfs: allow copy_file_range to copy across devices") allowed filesystems that implement the copy_file_range() f_op to decide if they want to access cross-sb copy from/to the same fs type.  The same commit added checks to verify same sb copy for filesystems that implement ->copy_file_range() and do not support cross-sb copy at the time, namely, to ceph, fuse and nfs.  The two remaining fs which implement ->copy_file_range(), cifs and overlayfs started to support cross-sb copy from this time.  While overlayfs does support cross-sb copy when the two underlying files are on the same base fs, the copy operation on the two real files from two different overalyfs filesystems is performed with the mounter creds of the destination overlayfs and the read permission access hook for the source file was called with the wrong creds.  This could cause either deny of access to copy which would otherwise be allowed (e.g. with splice) or allow read access to file which would otherwise be denied.  Fix the latter case by explicitly verifying read access to source file with the source overlayfs mounter creds.  The former case remains a quirk of cross-sb overlayfs copy, but userspace could fall back to regular copy so no harm done.

CVE-2026-68449:

        In the Linux kernel, the following vulnerability has been resolved:  ata: sata_dwc_460ex: fix infinite loop in NCQ tag completion bit-scanning  The hand-rolled bit-scanning loop in the NCQ completion path has an infinite loop bug.  When tag_mask has only high bits set (e.g. 0x80000000), the inner while loop left-shifts tag_mask until it overflows to 0.  At that point !(0 & 1) is always true and 0 <<= 1 stays 0, causing an infinite loop in hardirq context with a spinlock held.  Replace the open-coded bit-scanning with __ffs() which correctly finds the least significant set bit and is bounded by the width of the argument.

CVE-2026-68453:

        In the Linux kernel, the following vulnerability has been resolved:  s390/zcrypt: Fix buffer over-read in cca_cipher2protkey  Add validation of both the actual key buffer size and token length fields in all the cca_check_sec*token() functions. Additionally check in cca_gencipherkey() for possible underflow with returned key size.  The CCA token structures contain user-controlled len fields that were used in operations without proper validation against both the actual buffer size and minimum token structure size. An attacker could set this field larger than the actual buffer size, leading to reading beyond buffer boundaries. This may result in a kernel crash or exposure of memory via sending this as part of a request down to the crypto card. Also an attacker could have used a very small len value and thus enforce a buffer under-run which may produce similar effects as a over-read.  So now a key must - key buf length must be at least sizeof the token struct - the key len field inside the token must fit into the range of   sizeof key token struct ... key buf length

CVE-2026-68470:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: mac80211: validate extension-frame layout before RX  Extension frames only have the extension header at the regular 802.11 header offset. The generic RX path can still reach helpers and interface dispatch code that read regular header address fields before unsupported extension subtypes are dropped.  mac80211 currently only handles S1G beacon extension frames. Drop other extension subtypes before they can reach regular-header RX processing. For S1G beacons, linearize the SKB with the management-frame path and require the fixed S1G beacon header, including optional fixed fields indicated by frame control, before generic RX dispatch.  Route S1G beacons through the station/default-link RX path without regular-header station lookup. Avoid regular-header address reads in the mac80211 RX paths that process S1G extension beacons, including accept-frame, duplicate-detection, address-copy, and MLO address-translation paths.  Also make ieee80211_get_bssid() length-safe before returning the S1G source-address pointer.

CVE-2026-68471:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: ieee80211: validate MLE common info length  ieee80211_mle_common_size() uses the first common-info octet as the common information length for all known MLE types. However, ieee80211_mle_size_ok() only validates that octet for Basic, Probe Request, and TDLS MLEs.  Reconfiguration MLEs also skipped the length octet when calculating the minimum common size, and Priority Access MLEs skipped validation of the advertised common information length.  Account for the Reconfiguration common-info length octet and validate the advertised common information length for all known MLE types. Keep unknown-type handling unchanged.  [remove now misleading comment]

CVE-2026-72007:

        In the Linux kernel, the following vulnerability has been resolved:  pmdomain: imx: Fix i.MX8MP VC8000E power up sequence  Per errata[1]: ERR050531: VPU_NOC power down handshake may hang during VC8000E/VPUMIX power up/down cycling. Description: VC8000E reset de-assertion edge and AXI clock may have a timing issue. Workaround: Set bit2 (vc8000e_clk_en) of BLK_CLK_EN_CSR to 0 to gate off both AXI clock and VC8000E clock sent to VC8000E and AXI clock sent to VPU_NOC m_v_2 interface during VC8000E power up(VC8000E reset is de-asserted by HW)  Add a bool variable is_errata_err050531 in 'struct imx8m_blk_ctrl_domain_data' to represent whether the workaround is needed. If is_errata_err050531 is true, first clear the clk before powering up gpc, then enable the clk after powering up gpc.  [1] https://www.nxp.com/webapp/Download?colCode=IMX8MP_1P33A

CVE-2026-72009:

        In the Linux kernel, the following vulnerability has been resolved:  pmdomain: imx93-blk-ctrl: Extract PHY as shared domain for DSI/CSI  The MIPI DSI and CSI domains share control bits for clock and reset, which can lead to incorrect behavior if one domain disables the shared resource while the other is still active.  To fix the issue, introduce a shared MIPI PHY power domain to own the common resources and make DSI and CSI its subdomains. This ensures the shared bits are properly managed and not disabled while still in use.

CVE-2026-72028:

        In the Linux kernel, the following vulnerability has been resolved:  riscv: probes: save original sp in rethook trampoline  Reading a word from the stack in a kretprobe crashes a risc-v kernel.  $ cd /sys/kernel/tracing/ $ echo 'r n_tty_write $stack0' > dynamic_events $ echo 1 > events/kprobes/enable Unable to handle kernel paging request at virtual address 0000000200000128 ... [<ffffffff80016d16>] regs_get_kernel_stack_nth+0x26/0x38 [<ffffffff80177196>] process_fetch_insn+0x3ee/0x760 [<ffffffff80177836>] kretprobe_trace_func+0x116/0x1f0 [<ffffffff8017795a>] kretprobe_dispatcher+0x4a/0x58 [<ffffffff8013572e>] kretprobe_rethook_handler+0x5e/0x90 [<ffffffff80180838>] rethook_trampoline_handler+0x70/0x108 [<ffffffff8001ba32>] arch_rethook_trampoline_callback+0x12/0x1c [<ffffffff8001ba84>] arch_rethook_trampoline+0x48/0x94 [<ffffffff8067872a>] tty_write+0x1a/0x30  In regs_get_kernel_stack_nth, regs->sp contains an arbitrary value.  arch_rethook_trampoline saves the registers from the probed function in a struct pt_regs. sp is not saved. Instead, sp is decremented for arch_rethook_trampoline's local stack.  Fix this crash and save the original sp along with the other registers. Use a0 as a temporary register, it is overwritten anyway.  [pjw@kernel.org: added Fixes tag; cc'ed stable]

CVE-2026-72042:

        In the Linux kernel, the following vulnerability has been resolved:  ipmi: Fix user refcount underflow in event delivery  ipmi_alloc_recv_msg(user) takes the temporary user reference owned by the receive message, and ipmi_free_recv_msg() drops it again. If event delivery fails after allocating receive messages for earlier users, handle_read_event_rsp() rolls those messages back with ipmi_free_recv_msg().  That rollback path still drops user->refcount explicitly after freeing each message. The extra put can free a user that remains linked on intf->users, so later event delivery may dereference a freed user or trip refcount_t's addition-on-zero warning when ipmi_alloc_recv_msg() tries to acquire another reference.  Remove the stale explicit put and the now-dead user assignment. Keep the list_del() and ipmi_free_recv_msg() calls; they are the required rollback operations.

CVE-2026-72073:

        In the Linux kernel, the following vulnerability has been resolved:  mmc: vub300: fix use-after-free on probe failure  The vub300 driver lifetime-manages its controller state using vub300->kref, with vub300_delete() freeing the mmc host when the last reference is dropped. The probe error path after the inactivity timer has been armed still bypasses that lifetime rule, however, and falls through to mmc_free_host() directly if mmc_add_host() fails.  The race window is between arming the inactivity timer and reaching the probe error unwind after mmc_add_host() fails:          probe thread                     timer/workqueue         ------------                     ---------------         kref_init(&vub300->kref)         ref = 1         kref_get(&vub300->kref)          ref = 2, timer ref         add_timer(inactivity_timer)      fires after one second         |         |   race window         |<---------------------------------------------------->         |         mmc_add_host(mmc)                                          inactivity timer fires                                          vub300_queue_dead_work()                                            kref_get()          ref = 3                                            queue_work(deadwork)         mmc_add_host() fails         timer_delete_sync()         mmc_free_host(mmc)           frees vub300                                          deadwork runs                                            use-after-free  The inactivity timeout is one second, so this would require mmc_add_host() to both fail and take more than one second to do so. This is unlikely to happen in practice, but the error path is still wrong.  timer_delete_sync() only waits for the timer callback itself. It does not flush deadwork that the callback may already have queued. As a result, queued deadwork can still hold a kref while the probe error path directly frees the backing mmc host, including the vub300 storage.  Fix this by using the same lifetime mechanism as disconnect. Clear vub300->interface so that the timer callback and any queued deadwork return early and drop their references, then drop the initial probe reference and return without falling through to err_free_host.

CVE-2026-72098:

        In the Linux kernel, the following vulnerability has been resolved:  dm-verity: fix buffer overflow in FEC calculation  There's a buffer overflow in dm-verity-fec:  if (neras && *neras <= v->fec->roots) 	fio->erasures[(*neras)++] = i;  This allows *neras to reach roots + 1 (the post-increment pushes it past roots). This value is then passed as no_eras to decode_rs8(). Inside the RS decoder (lib/reed_solomon/decode_rs.c:113-121), the erasure locator polynomial loop writes lambda[j] where j can reach nroots + 1 — one element past the end of lambda[] (which is sized nroots + 1, valid indices 0..nroots). The out-of-bounds write lands on syn[0], corrupting the syndrome buffer.

CVE-2026-72106:

        In the Linux kernel, the following vulnerability has been resolved:  dm-ioctl: fix a possible overflow in list_version_get_info  sizeof(tt->version) is 12 bytes, but the code writes 16 bytes into the output buffer - info->vers->version[0], info->vers->version[1], info->vers->version[2] and info->vers->next. This can cause buffer overflow.  Fix this buffer overflow by replacing "sizeof(tt->version)" with "sizeof(struct dm_target_versions)".

CVE-2026-72130:

        In the Linux kernel, the following vulnerability has been resolved:  nvmet-auth: reject short AUTH_RECEIVE buffers  nvmet_execute_auth_receive() trusts the AUTH_RECEIVE allocation length after checking only that it is nonzero and matches the transfer length. In the SUCCESS1 and FAILURE1/default states, that lets a remote NVMe-oF initiator reach the fixed-size DH-HMAC-CHAP response builders with a kmalloc() buffer shorter than the response, so nvmet_auth_success1() and nvmet_auth_failure1() write past the allocation; both only WARN_ON the short length and then format the message anyway.  Impact: A remote NVMe-oF initiator with access to an auth-enabled target can trigger a 16-byte heap out-of-bounds write via a one-byte AUTH_RECEIVE allocation length.  Compute the minimum response length for the current DH-HMAC-CHAP step in nvmet_auth_receive_data_len() and report a zero data length when the host-supplied allocation length is shorter, so the existing zero-length check in nvmet_execute_auth_receive() rejects the command before any builder runs. The SUCCESS1 minimum is sizeof(struct nvmf_auth_dhchap_success1_data) plus the HMAC hash length, because the response hash is written into the rval[] flexible-array tail, so the minimum is state dependent rather than a flat sizeof. CHALLENGE keeps its existing variable-length guard in nvmet_auth_challenge().  This is reachable only when in-band DH-HMAC-CHAP authentication is configured on the target.

CVE-2026-72144:

        In the Linux kernel, the following vulnerability has been resolved:  platform/x86: dell-laptop: fix missing cleanups in init error path  dell_init() initializes several resources after dell_setup_rfkill(), including the optional touchpad LED, keyboard backlight LED, battery hook, debugfs directory and dell-laptop notifier.  If a later LED or backlight registration fails, the error path only tears down the battery hook and rfkill resources. This leaves the notifier, debugfs directory, keyboard backlight LED and optional touchpad LED registered after dell_init() returns an error.  Add the missing cleanup calls before tearing down rfkill.

CVE-2026-72147:

        In the Linux kernel, the following vulnerability has been resolved:  dmaengine: dw-edma-pcie: Reject devices without driver data  dw_edma_pcie_probe() treats the PCI device ID driver_data as the template for the controller layout and copies it unconditionally. A device bound dynamically via sysfs can match the driver without that data, which leads to a NULL pointer dereference.  Reject such matches before enabling the device.

CVE-2026-72162:

        In the Linux kernel, the following vulnerability has been resolved:  ocfs2: fix UBSAN array-index-out-of-bounds in ocfs2_sum_rightmost_rec  [BUG] On-disk corruption setting l_next_free_rec to 0 in an inode's embedded extent list triggers a UBSAN panic on the next write to that file.  [CAUSE] ocfs2_sum_rightmost_rec() computes i = le16_to_cpu(el->l_next_free_rec) - 1 and accesses el->l_recs[i] without validating i. When l_next_free_rec is 0, i becomes -1; when l_next_free_rec exceeds l_count, i falls past the end of the array. Either case violates the __counted_by_le(l_count) annotation on l_recs[] and triggers UBSAN.  [FIX] Validate the inode's embedded extent list when the inode is read, in ocfs2_validate_inode_block(): l_count must be non-zero and no larger than the inode block can hold, and l_next_free_rec must not exceed l_count. A corrupt list is rejected at read time, before the b-tree code can index l_recs[] out of bounds.

CVE-2026-72168:

        In the Linux kernel, the following vulnerability has been resolved:  mtd: maps: vmu-flash: fix fault in unaligned fixup  Use kzalloc_obj() / kzalloc_objs() to allocate the memcard structs, instead of kmalloc_obj() / kmalloc_objs() to prevent access to uninitialized data.  Fixes runtime error: Fault in unaligned fixup: 0000 [#1] at mtd_get_fact_prot_info.

CVE-2026-72213:

        In the Linux kernel, the following vulnerability has been resolved:  mm/hugetlb: fix hugetlb cgroup rsvd charge/uncharge mismatch  In alloc_hugetlb_folio(), a single h_cg pointer is used for both the rsvd and non-rsvd hugetlb cgroup charges.  When map_chg is set, hugetlb_cgroup_charge_cgroup_rsvd() stores the charged cgroup in h_cg, but the immediately following hugetlb_cgroup_charge_cgroup() overwrites h_cg with the non-rsvd cgroup pointer.  As a result, hugetlb_cgroup_commit_charge_rsvd() stores the wrong (non-rsvd) cgroup pointer into the folio's rsvd slot.  When the folio is later freed, free_huge_folio() unconditionally calls both hugetlb_cgroup_uncharge_folio() and hugetlb_cgroup_uncharge_folio_rsvd().  The rsvd uncharge reads back the wrong cgroup from the folio and decrements a counter that was never charged for that cgroup, causing a page_counter underflow:    page_counter underflow: -512 nr_pages=512   WARNING: mm/page_counter.c:61 at page_counter_cancel  Fix this by introducing a separate h_cg_rsvd pointer exclusively for the rsvd charge path, keeping the rsvd and non-rsvd charges fully independent through their charge, commit, and error uncharge paths.

CVE-2026-72254:

        In the Linux kernel, the following vulnerability has been resolved:  netfilter: nft_fib: reject fib expression on the netdev egress hook  A fib expression in a netdev egress base chain dereferences nft_in(pkt), NULL on the transmit path, causing a NULL pointer dereference at eval. nft_fib_validate() masks the hook with NF_INET_* values, but netdev hook numbers are a separate enum that aliases them (NF_NETDEV_EGRESS == NF_INET_LOCAL_IN), so an egress chain passes validation and then faults.  Add nft_fib_netdev_validate() that limits each result/flag to the netdev hook where the device it reads exists: the input-device cases (OIF, OIFNAME, ADDRTYPE with F_IIF) to ingress, the output-device case (ADDRTYPE with F_OIF) to egress, ADDRTYPE with no device flag to both. Also restrict nft_fib_validate() to NFPROTO_IPV4/IPV6/INET so its NF_INET_* masks are not applied to another family's hooks.

CVE-2026-72288:

        In the Linux kernel, the following vulnerability has been resolved:  KVM: arm64: vgic: Handle race between interrupt affinity change and LPI disabling  Hyunwoo Kim reports some really bad races should the following situation occur:  - LPI-I is pending in vcpu-B's AP list - vcpu-A writes to vcpu-B's RD to disable its LPIs - vcpu-C moves I from B to C  If the last two race nicely enough, vgic_prune_ap_list() can drop the irq and AP list locks, reacquire them, and in the interval the irq has been freed. UAF follows.  The fix is two-fold:  - Before dropping the irq and ap_list locks, take a reference on   the irq  - Do not try to handle migration of the pending bit: there is no   expectation that this state is retained, as per the architecture  With that, we're sure that the interrupt is still around, and we safely remove it from the AP list as it has no target at this stage (unless another interrupt fires, but that's another story).

CVE-2026-72315:

        In the Linux kernel, the following vulnerability has been resolved:  smb: client: fix busy dentry warning on unmount after DIO  Commit c68337442f03 ("cifs: Fix busy dentry used after unmounting") fixed the issue in cifs where deferred close of a file led to a dentry reference count not being released in umount, by flushing deferredclose_wq in cifs_kill_sb() to solve it.  However, the cifs DIO path suffers from the same busy-dentry problem caused by a delayed dentry reference-count release:  	[dio]			[cifsd]			[close + umount] netfs_unbuffered_write_iter_locked ... 				cifs_demultiplex_thread  netfs_unbuffered_write   cifs_issue_write   netfs_wait_for_in_progress_stream [1] 				... 				 netfs_write_subrequest_terminated 				  netfs_subreq_clear_in_progress 				   netfs_wake_collector // wake [1] 				  netfs_put_subrequest  netfs_put_request   queue_work(system_dfl_wq, xxx) [2]  // dio write return					cifs_close 							 _cifsFileInfo_put 							  // cfile->count 2->1 							  --cfile->count [3]  							// umount 							cifs_kill_sb 							 kill_anon_super 							  // warning triggered! 							  shrink_dcache_for_umount [4] [system_dfl_wq] [5] netfs_free_request  ...  _cifsFileInfo_put   // cfile->count 1->0   --cfile->count   queue_work(fileinfo_put_wq, xxx)  [fileinfo_put_wq] [6] cifsFileInfo_put_work  cifsFileInfo_put_final   dput  If the umount path is triggered before [5], it results warning: BUG: Dentry 00000000eab1f070{i=9a917b66ae404fec,n=test}  still in use (1) [unmount of cifs cifs]  The existing per-inode ictx->io_count wait in cifs_evict_inode() does not help: it lives in the inode eviction path, which runs after shrink_dcache_for_umount() has already warned about the busy dentries.  Fix it by adding a per-superblock outstanding-rreq counter that is incremented in cifs_init_request() and decremented in cifs_free_request(). In cifs_kill_sb(), before kill_anon_super(), wait for this counter to reach 0 - which guarantees that all cleanup_work for this sb have run and thus all relevant cfile puts are queued on fileinfo_put_wq or serverclose_wq. Then drain the workqueue so the dentry refs are dropped.  This is a targeted wait, not a flush of the system-wide system_dfl_wq.

CVE-2026-72320:

        In the Linux kernel, the following vulnerability has been resolved:  netfilter: nft_lookup: fix catchall element handling with inverted lookups  nft_lookup_eval() decides whether a lookup matched (`found`) from the direct set lookup and priv->invert before falling back to the catchall element used by interval sets (e.g. nft_set_rbtree) for the open-ended default range. Since `found` is never recomputed after `ext` is replaced by the catchall lookup, inverted lookups (NFT_LOOKUP_F_INV, "!= @set") can wrongly match or wrongly skip the catchall element, producing the wrong verdict. Fold the catchall lookup into `ext` before computing `found`, matching the order already used by nft_objref_map_eval().

CVE-2026-72321:

        In the Linux kernel, the following vulnerability has been resolved:  ipv4: igmp: Fix potential memory leaks in igmp_mod_timer() and igmp_stop_timer()  When a timer is deleted and not re-armed in igmp_mod_timer(), or stopped in igmp_stop_timer(), the code currently decrements the reference counter of the multicast list entry @im using refcount_dec(&im->refcnt).  However, both functions can be called from the RCU reader path: - igmp_mod_timer() via igmp_heard_query() -> for_each_pmc_rcu() - igmp_stop_timer() via igmp_rcv() -> igmp_heard_report()  If the group im was concurrently removed from the list by ip_mc_dec_group(), its reference count might have already been decremented to 1.  In this case, timer_delete() succeeds, and refcount_dec() decrements the refcount from 1 to 0. Since refcount_dec() does not free the object when it hits 0 (unlike ip_ma_put()), the im structure is leaked.  Fix this by using ip_ma_put(im) instead of refcount_dec(&im->refcnt), and deferring the put until after the spinlock is released.

CVE-2026-72324:

        In the Linux kernel, the following vulnerability has been resolved:  gpio: mvebu: free generic chips on unbind  irq_alloc_domain_generic_chips() allocates generic chip data that must be freed via irq_domain_remove_generic_chips(). The devres action mvebu_gpio_remove_irq_domain() only called irq_domain_remove(), which only frees the generic chips if IRQ_DOMAIN_FLAG_DESTROY_GC is set. Call irq_domain_remove_generic_chips() explicitly before irq_domain_remove() instead.

CVE-2026-72325:

        In the Linux kernel, the following vulnerability has been resolved:  perf/x86/amd/core: Avoid enabling BRS from the SVM reload path  Branch Sampling (BRS) and Last Branch Record (LBR) are mutually exclusive hardware features, and users of both are tracked via cpuc->lbr_users.  When SVM is toggled on a CPU, the host perf events are reprogrammed to update the HostOnly filter bit (set when virtualization is enabled, cleared when it is disabled). On PerfMonV2-capable processors, this reprogramming is performed by calling amd_pmu_enable_all() to rewrite the event selectors. However, amd_pmu_enable_all() also calls amd_brs_enable_all(), which enables BRS whenever cpuc->lbr_users > 0. Having active LBR events satisfies this gating on processors that have LBR but not BRS. The kernel then tries to set the BRS enable bit in DebugExtnCfg (MSR 0xc000010f). Since that bit is deprecated on such hardware, the write results in a #GP:    Call Trace:    <IRQ>    amd_pmu_enable_all+0x1d/0x90    amd_pmu_disable_virt+0x62/0xb0    kvm_arch_disable_virtualization_cpu+0xa/0x40 [kvm]    hardware_disable_nolock+0x1a/0x30 [kvm]    __flush_smp_call_function_queue+0x9b/0x410    __sysvec_call_function+0x18/0xc0    sysvec_call_function+0x69/0x90    </IRQ>    <TASK>    asm_sysvec_call_function+0x16/0x20   RIP: 0010:cpuidle_enter_state+0xc4/0x450    ? cpuidle_enter_state+0xb7/0x450    cpuidle_enter+0x29/0x40    cpuidle_idle_call+0xf5/0x160    do_idle+0x7b/0xe0    cpu_startup_entry+0x26/0x30    start_secondary+0x115/0x140    secondary_startup_64_no_verify+0x194/0x19b    </TASK>  Fix this by ensuring that BRS is not enabled from the event selector reprogramming path even when cpuc->lbr_users > 0.

CVE-2026-72329:

        In the Linux kernel, the following vulnerability has been resolved:  net/liquidio: drop cached VF pci_dev LUT  The PF SR-IOV enable path caches VF pci_dev pointers in dpiring_to_vfpcidev_lut[] by iterating with pci_get_device(). Those entries do not own a reference, because the iterator drops the previous device reference on each step. The cached pointer is then dereferenced later when handling OCTEON_VF_FLR_REQUEST.  Replace the cached VF mapping with runtime lookup on the mailbox DPI ring: derive the VF index from q_no, resolve the VF via exported PCI IOV helpers, validate it with the PF pointer and VF ID, then issue pcie_flr() and drop the reference with pci_dev_put(). Remove the unused VF lookup table initialization and cleanup.

CVE-2026-72336:

        In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: 6lowpan: hold L2CAP conn across debugfs control  get_l2cap_conn() looks up an LE hci_conn under hdev protection, but then drops that protection before reading hcon->l2cap_data and before lowpan_control_write() later dereferences conn->hcon.  A disconnect or device close can tear down the same L2CAP connection in that window.  The buggy scenario involves two paths, with each column showing the order within that path:  6LoWPAN control write:              HCI disconnect/device close:   1. get_l2cap_conn() finds hcon      1. hci_disconn_cfm() dispatches      and hcon->l2cap_data.               the L2CAP disconnect callback.   2. get_l2cap_conn() drops hdev      2. l2cap_conn_del() clears      protection and returns conn.        hcon->l2cap_data and drops the                                          L2CAP connection reference.   3. lowpan_control_write() reads     3. hci_conn_del() removes and drops      conn->hcon.                         the HCI connection.  Take a reference to the L2CAP connection with l2cap_conn_hold_unless_zero() while hdev is still locked, and drop that reference after the debugfs command's last use of conn.  This mirrors the existing L2CAP ACL receive-side handoff and keeps the connection dereferenceable after leaving hdev protection.  Export the existing helper so the bluetooth_6lowpan module can use the same lifetime primitive.  Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in lowpan_control_write+0x374/0x520 The buggy address belongs to the object at ffff888111b9d000 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 0 bytes inside of freed 1024-byte region [ffff888111b9d000, ffff888111b9d400) Read of size 8 Call trace:   dump_stack_lvl+0x66/0xa0   print_report+0xce/0x5f0   lowpan_control_write+0x374/0x520 (net/bluetooth/6lowpan.c:1131)   srso_alias_return_thunk+0x5/0xfbef5   __virt_addr_valid+0x19f/0x330   kasan_report+0xe0/0x110   __debugfs_file_get+0xf7/0x400   full_proxy_write+0x9e/0xd0   vfs_write+0x1b0/0x810   ksys_write+0xd2/0x170   dnotify_flush+0x32/0x220   do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87)   entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task stack:   kasan_save_stack+0x33/0x60   kasan_save_track+0x17/0x60   __kasan_kmalloc+0xaa/0xb0   l2cap_conn_add+0x45/0x520   l2cap_chan_connect+0xac6/0xd90   l2cap_sock_connect+0x216/0x350   __sys_connect+0x101/0x130   __x64_sys_connect+0x40/0x50   do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87)   entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task stack:   kasan_save_stack+0x33/0x60   kasan_save_track+0x17/0x60   kasan_save_free_info+0x3b/0x60   __kasan_slab_free+0x5f/0x80   kfree+0x313/0x590   hci_conn_hash_flush+0xc0/0x140   hci_dev_close_sync+0x41a/0xb00   hci_dev_close+0x12f/0x160   hci_sock_ioctl+0x157/0x570   sock_do_ioctl+0xf7/0x210   sock_ioctl+0x32f/0x490   __x64_sys_ioctl+0xc7/0x110   do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87)   entry_SYSCALL_64_after_hwframe+0x77/0x7f   kasan_record_aux_stack+0xa7/0xc0   insert_work+0x32/0x100   __queue_work+0x262/0xa60   queue_work_on+0xad/0xb0   l2cap_connect_cfm+0x4ef/0x670   hci_le_remote_feat_complete_evt+0x247/0x430   hci_event_packet+0x360/0x6f0   hci_rx_work+0x2ae/0x7a0   process_one_work+0x4fd/0xbc0   worker_thread+0x2d8/0x570   kthread+0x1ad/0x1f0   ret_from_fork+0x3c9/0x540   ret_from_fork_asm+0x1a/0x30

CVE-2026-72337:

        In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: 6lowpan: avoid untracked enable work  lowpan_enable_set() allocates a temporary work item and schedules do_enable_set() on system_wq, then returns to debugfs. The debugfs active operation has ended at that point, but the worker still executes module text and manipulates enable_6lowpan and listen_chan.  bt_6lowpan_exit() removes the debugfs files and immediately closes and puts listen_chan. It has no pointer to the queued work item, so it cannot cancel or flush it before tearing down the state that the worker uses.  The buggy scenario involves two paths, with each column showing the order within that path:  debugfs enable write              module exit 1. lowpan_enable_set() allocates  1. bt_6lowpan_exit() removes    set_enable work                   the debugfs file 2. schedule_work() queues         2. bt_6lowpan_exit() closes    do_enable_set()                   and puts listen_chan 3. the write operation returns    3. module teardown can continue 4. do_enable_set() later runs    against stale state  Run the enable state transition synchronously in lowpan_enable_set() instead. The simple debugfs setter can sleep, and this file already handles the 6LoWPAN control write synchronously under the same set_lock. Once the setter returns, debugfs removal covers the whole operation and exit can no longer race with an untracked work item.  Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in do_enable_set+0x113/0x2e0 Workqueue: events do_enable_set [bluetooth_6lowpan] The buggy address belongs to the object at ffff888109cb8000

CVE-2026-72338:

        In the Linux kernel, the following vulnerability has been resolved:  net/sched: act_pedit: fix TOCTOU heap OOB write in tc offload  There is a TOCTOU race condition in flower lockless approach between sizing a flow_rule buffer and filling it. zdi-disclosures@trendmicro.com reports: The cls_flower classifier operates with TCF_PROTO_OPS_DOIT_UNLOCKED (fl_change runs without RTNL), while RTM_NEWACTION holds RTNL, so the independent locking domains make the race reachable in practice.  KASAN confirms:   BUG: KASAN: slab-out-of-bounds in tcf_pedit_offload_act_setup+0x81b/0x930   Write of size 4 at addr ffff888001f27520 by task poc-toctou/312   The buggy address is located 0 bytes to the right of    allocated 288-byte region [ffff888001f27400, ffff888001f27520)    (cache kmalloc-512)  Note: The result is a heap OOB write attacker-controlled content into the adjacent slab object (requires CAP_NET_ADMIN).  The fix introduces reading tcfp_nkeys under act->tcfa_lock in all places using a new tcf_pedit_nkeys_locked() which replaces the old tcf_pedit_nkeys(). Additionally we close the remaining TOCTOU window between the sizing read and the fill reads by more careful accounting. Rather than silently truncating the key count, which leads to incorrect action semantics offloaded to hardware and secondary OOB writes if the remaining capacity is zero or consumed by prior actions, we enforce remaining capacity checks and return -ENOSPC if the required space exceeds the remaining capacity.

CVE-2026-72341:

        In the Linux kernel, the following vulnerability has been resolved:  net/mlx5e: Fix publication race for priv->channel_stats[]  mlx5e_channel_stats_alloc() publishes a new entry to priv->channel_stats[] and then increments priv->stats_nch as a publication token, but neither store carries any memory barrier:  	priv->channel_stats[ix] = kvzalloc_node(...); 	if (!priv->channel_stats[ix]) 		return -ENOMEM; 	priv->stats_nch++;  Concurrent readers compute the loop bound from priv->stats_nch and then dereference priv->channel_stats[i] using plain accesses, e.g.  	for (i = 0; i < priv->stats_nch; i++) { 		struct mlx5e_channel_stats *cs = priv->channel_stats[i]; 		... cs->rq.packets ... 	}  On weakly-ordered architectures (ARM, PowerPC, RISC-V) the writes to channel_stats[ix] and stats_nch may become visible to other CPUs out of program order. A reader can observe stats_nch == N while still seeing channel_stats[N-1] == NULL, leading to a NULL pointer dereference in the channel_stats loop.  This has been observed in production on BlueField-3 DPUs (arm64), where ovs-vswitchd queries netdev statistics over netlink during NIC bringup, racing mlx5e_open_channel() -> mlx5e_channel_stats_alloc() on another CPU:    Unable to handle kernel NULL pointer dereference at virtual address 0x840   Hardware name: BlueField-3 DPU   pc : mlx5e_fold_sw_stats64+0x30/0x180 [mlx5_core]   Call trace:    mlx5e_fold_sw_stats64+0x30/0x180 [mlx5_core]    dev_get_stats+0x50/0xc0    ovs_vport_get_stats+0x38/0xac [openvswitch]    ovs_vport_cmd_fill_info+0x194/0x290 [openvswitch]    ovs_vport_cmd_get+0xbc/0x10c [openvswitch]    genl_family_rcv_msg_doit+0xd0/0x160    genl_rcv_msg+0xec/0x1f0    netlink_rcv_skb+0x64/0x130    genl_rcv+0x40/0x60    netlink_unicast+0x2fc/0x370    netlink_sendmsg+0x1dc/0x454    ...    __arm64_sys_sendmsg+0x2c/0x40  Add mlx5e_stats_nch_write() and mlx5e_stats_nch_read() helpers in en.h that wrap the smp_store_release()/smp_load_acquire() pair on stats_nch. The release/acquire pair establishes the contract:    stats_nch == N  =>  channel_stats[0..N-1] are visible and non-NULL.  Publish the stats_nch increment via mlx5e_stats_nch_write() in the writer (mlx5e_channel_stats_alloc()), and read stats_nch via mlx5e_stats_nch_read() in all readers: mlx5e RX/TX queue stats, mlx5e_get_base_stats(), ethtool channels stats, IPoIB stats, the sw_stats fold and the HV VHCA stats agent.

CVE-2026-72369:

        In the Linux kernel, the following vulnerability has been resolved:  minix: avoid overflow in bitmap block count calculation  minix_check_superblock() uses minix_blocks_needed() to verify that the on-disk imap and zmap block counts are large enough for the advertised inode and zone counts.  The helper currently performs DIV_ROUND_UP() in unsigned int arithmetic. A Minix v3 image can set s_ninodes or s_zones near UINT_MAX so the addition inside DIV_ROUND_UP() wraps to zero. That makes a zero imap/zmap block count look valid, after which minix_fill_super() can dereference s_imap[0] or s_zmap[0] even though no bitmap buffers were allocated.  Impact: mounting a crafted Minix v3 image whose s_ninodes or s_zones is near UINT_MAX makes minix_check_superblock() accept a zero bitmap-block count and minix_fill_super() dereference s_imap[0]/s_zmap[0], panicking the kernel.  The divisor is the bitmap capacity in bits, blocksize * 8, which is always a power of two: minix_fill_super() obtains the block size through sb_set_blocksize(), and blk_validate_block_size() rejects any size that is not a power of two. Use DIV_ROUND_UP_POW2(), which divides before adding the round-up term and so cannot overflow for a power-of-two divisor.

CVE-2026-72373:

        In the Linux kernel, the following vulnerability has been resolved:  afs: Fix missing NULL pointer check in afs_break_some_callbacks()  Fix afs_break_some_callbacks() to check to see if afs_lookup_volume_rcu() returned NULL (e.g. the specified volume is unknown).

CVE-2026-72375:

        In the Linux kernel, the following vulnerability has been resolved:  afs: Fix reinitialisation of the inode, in particular ->lock_work  It seems that initalising afs_vnode::lock_work a single time in the slab's init function isn't sufficient for work_structs.  This results in the DEBUG_OBJECTS debugging stuff producing a warning occasionally when running the generic/131 xfstest:   ODEBUG: activate not available (active state 0) object: 0000000016d8760f object type: work_struct hint: afs_lock_work+0x0/0x220  WARNING: lib/debugobjects.c:629 at debug_print_object+0x4b/0x90, CPU#3: locktest/7695  ...  CPU: 3 UID: 0 PID: 7695 Comm: locktest Tainted: G S                  7.1.0-build3+ #2771 PREEMPT  ...  RIP: 0010:debug_print_object+0x65/0x90  ...  Call Trace:   <TASK>   ? __pfx_afs_lock_work+0x10/0x10   debug_object_activate+0x122/0x170   insert_work+0x25/0x60   __queue_work+0x2e0/0x340   queue_delayed_work_on+0x48/0x70   afs_fl_release_private+0x57/0x70   locks_release_private+0x5c/0xa0   locks_free_lock+0xe/0x20   posix_lock_inode+0x55f/0x5b0   locks_lock_inode_wait+0x81/0x140   ? file_write_and_wait_range+0x50/0x70   afs_lock+0xcd/0x110   fcntl_setlk+0x10d/0x260   do_fcntl+0x24e/0x5b0   __do_sys_fcntl+0x6a/0x90   do_syscall_64+0x11e/0x310   entry_SYSCALL_64_after_hwframe+0x71/0x79  Fix this by reinitialising ->lock_work after allocating an inode.  Also, flush ->lock_work when the inode is being evicted to make sure it's not still running.

CVE-2026-72376:

        In the Linux kernel, the following vulnerability has been resolved:  afs: Fix misplaced inc of net->cells_outstanding  Fix net->cells_outstanding being incremented before the check for failure of idr_alloc_cyclic(), leaving the count incremented on error.

CVE-2026-72379:

        In the Linux kernel, the following vulnerability has been resolved:  fs: refuse O_TMPFILE creation with an unmapped fsuid or fsgid  vfs_tmpfile() never checked that the caller's fsuid and fsgid map into the filesystem.  On an idmapped mount whose idmapping does not cover the caller's fs{u,g}id, the ->tmpfile() instance initializes the new inode through inode_init_owner(), where mapped_fsuid()/mapped_fsgid() return INVALID_UID/INVALID_GID, and the tmpfile ends up owned by (uid_t)-1.  Every other creation path already refuses this: may_o_create() (O_CREAT) and may_create_dentry() (mkdir, mknod, symlink, link) bail out with -EOVERFLOW via fsuidgid_has_mapping() precisely so that an object cannot be created with an owner the filesystem cannot represent.  An O_TMPFILE is no exception: it is created I_LINKABLE and linkat(2) can splice it into the namespace afterwards, so the same guarantee must hold.  Add the missing fsuidgid_has_mapping() check to vfs_tmpfile().  On a non-idmapped mount the caller's fs{u,g}id always map in the superblock's user namespace, so this is a no-op there and only takes effect on an idmapped mount that does not map the caller.  It applies to every filesystem that sets FS_ALLOW_IDMAP and implements ->tmpfile() (tmpfs, ext4, btrfs, xfs, f2fs, ...), and to overlayfs, whose upper-layer tmpfile creation funnels through vfs_tmpfile() via backing_tmpfile_open().

CVE-2026-72380:

        In the Linux kernel, the following vulnerability has been resolved:  xen/pvcalls: bound backend response req_id before indexing rsp[]  pvcalls_front_event_handler() takes req_id directly from the backend-supplied ring response and uses it to index the fixed-size bedata->rsp[] array for a memcpy() and a store, with no range check. A malicious or buggy backend can set req_id past PVCALLS_NR_RSP_PER_RING and drive an out-of-bounds write past the bedata allocation.  req_id was also declared int while the wire field rsp->req_id is u32, so a range check on the signed value alone is insufficient: a backend req_id of 0xffffffff becomes -1, passes a >= PVCALLS_NR_RSP_PER_RING test and indexes bedata->rsp[-1]. Declare req_id as u32 so a single bound covers both ends.  A backend that sends an out-of-range req_id has violated the wire protocol, so rather than silently dropping the response, log once and stop trusting the backend: set bedata->disabled. The event handler then ignores further responses, and the request paths that wait for a response return -EIO instead of blocking forever. This mirrors the fatal-error handling xen-netback uses (xenvif_fatal_tx_err()).  The pvcalls frontend currently trusts its backend, so this is not a classic-Xen security issue, but it matters for hardening PV frontends against malicious backends (confidential and disaggregated deployments).

CVE-2026-72382:

        In the Linux kernel, the following vulnerability has been resolved:  ksmbd: reject undersized DACLs before parsing ACEs  parse_dacl() limits the attacker-controlled ACE count by comparing it with the number of minimal ACEs that fit in the DACL size. The DACL size field is 16 bits, but the expression subtracts sizeof(struct smb_acl). Because sizeof() is unsigned, a DACL size smaller than the ACL header underflows to a large size_t.  A malicious client can reach this with:  SMB2_SET_INFO (InfoType=SMB2_O_INFO_SECURITY)   -> smb2_set_info_sec()   -> set_info_sec()   -> parse_sec_desc()   -> parse_dacl()      -> init_acl_state(..., 0xffff)      -> init_acl_state(..., 0xffff)      -> kmalloc_objs(..., 0xffff)  Thus a malformed security descriptor can make num_aces pass the guard and drive large temporary ACL state and pointer-array allocations.  Reject DACLs smaller than struct smb_acl before doing the subtraction, so the ACE count check cannot be bypassed by the underflow.

CVE-2026-72383:

        In the Linux kernel, the following vulnerability has been resolved:  sctp: fix addr_wq_timer race in sctp_free_addr_wq()  sctp_free_addr_wq() previously removed addr_wq_timer using timer_delete() while holding addr_wq_lock. However, timer_delete() does not guarantee that a currently running timer handler has completed.  This allows a race with sctp_addr_wq_timeout_handler(), where the handler may still run after addr_waitq has been freed, acquire addr_wq_lock, and access freed memory, leading to a use-after-free.  Fix this by calling timer_shutdown_sync() before taking addr_wq_lock.  This guarantees that any in-flight timer handler has finished and prevents the timer from being re-armed during teardown, making subsequent cleanup safe.

CVE-2026-72397:

        In the Linux kernel, the following vulnerability has been resolved:  hwmon: (pmbus/core) honor vrm_version in pmbus_data2reg_vid()  pmbus_data2reg_vid() hardcoded the VR11 encoding regardless of the vrm_version configured by the driver, while pmbus_reg2data_vid() already switched on it. Any driver that selects a non-VR11 VID mode and exposes a regulator (or hwmon vout setter) sent dangerously wrong codes to PMBUS_VOUT_COMMAND -- e.g. an nvidia195mv part asked for 200 mV got the VR11 clamp to 500 mV encoded as 0xB2, which the chip interprets as 1080 mV.  Mirror pmbus_reg2data_vid() so writes round-trip with reads.

CVE-2026-72398:

        In the Linux kernel, the following vulnerability has been resolved:  sctp: add INIT verification after cookie unpacking  In SCTP handshake, the INIT chunk is initially processed by the server and embedded into the cookie carried in INIT-ACK. The client then returns this cookie via COOKIE-ECHO, where the server unpacks it and reconstructs the original INIT chunk.  When cookie authentication is enabled, the cookie contents are protected against tampering, so reusing the unpacked INIT without re-verification is safe.  However, when cookie authentication is disabled, the reconstructed INIT can no longer be trusted. In this case, the INIT must be explicitly validated after unpacking to avoid processing potentially tampered data.  Add sctp_verify_init() checks after cookie unpacking in COOKIE-ECHO processing paths (sctp_sf_do_5_1D_ce() and sctp_sf_do_5_2_4_dupcook()) when cookie_auth_enable is disabled. On failure, the new association is freed and the packet is discarded.  Also tighten cookie validation in sctp_unpack_cookie() by verifying the embedded chunk type is SCTP_CID_INIT before treating it as an INIT chunk.  Finally, update sctp_verify_init() to validate parameter bounds using the actual embedded INIT length instead of chunk->chunk_end, since the INIT stored in COOKIE-ECHO may not span the entire chunk buffer.

CVE-2026-72404:

        In the Linux kernel, the following vulnerability has been resolved:  tipc: fix UAF in cleanup_bearer() due to premature dst_cache_destroy()  TIPC UDP media bearer teardown calls dst_cache_destroy() on its replicast caches before calling synchronize_net() to wait for concurrent RCU readers (transmitters) to finish:  static void cleanup_bearer(struct work_struct *work) { ... 	list_for_each_entry_safe(rcast, tmp, &ub->rcast.list, list) { 		dst_cache_destroy(&rcast->dst_cache); 		list_del_rcu(&rcast->list); 		kfree_rcu(rcast, rcu); 	} ... 	dst_cache_destroy(&ub->rcast.dst_cache); 	udp_tunnel_sock_release(ub->sk); 	synchronize_net(); ... }  This is highly buggy because dst_cache_destroy() immediately frees the per-CPU cache memory (free_percpu()) and releases the cached dst entries without any synchronization.  If a concurrent transmitter (e.g., tipc_udp_xmit()) is running on another CPU under RCU protection, it can call dst_cache_get() concurrently, leading to: 1. Use-After-Free on the per-CPU cache pointer itself (crash). 2. "rcuref - imbalanced put()" warning if it attempts to release a    dst that was concurrently released by dst_cache_destroy().  Furthermore, calling kfree(ub) immediately after synchronize_net() without closing the socket first (or waiting after closing it) leaves a window where a concurrent receiver (tipc_udp_recv()) could start after synchronize_net(), access ub, and suffer a UAF when kfree(ub) runs.  To fix this, we must defer dst_cache_destroy() and kfree(ub) until after we have ensured that no more readers can see the bearer/socket and all existing readers have finished:  1. Defer rcast entry destruction (both dst_cache_destroy() and kfree())    to an RCU callback using call_rcu_hurry().    Using call_rcu_hurry() ensures the dst entries are released quickly.  2. Release the bearer socket using udp_tunnel_sock_release() (stops    new receive readers).  3. Call synchronize_net() to wait for all outstanding RCU readers    (both transmit and receive) to finish.  4. Now that it is safe, call dst_cache_destroy() on the main bearer    cache, and free ub.  Note: 3) and 4) can be changed later in net-next to also use call_rcu_hurry() and get rid of the synchronize_net() latency.

CVE-2026-72405:

        In the Linux kernel, the following vulnerability has been resolved:  net: udp_tunnel: prevent double queueing in udp_tunnel_nic_device_sync  Yue Sun reported a use-after-free and debugobjects warning in udp_tunnel_nic_device_sync_work() during concurrent device operations.  The workqueue core clears the internal pending bit before invoking the worker. At that point, a concurrent thread can queue the work again. When the already running worker eventually clears the work_pending flag to 0, it mistakenly clears the flag for the newly queued instance. udp_tunnel_nic_unregister() then observes work_pending as 0 and frees the structure while the second work item is still active in the queue, leading to UAF.  Fix this by returning early in udp_tunnel_nic_device_sync() if work_pending is already set, preventing redundant work queueing.

CVE-2026-72416:

        In the Linux kernel, the following vulnerability has been resolved:  netfilter: nft_compat: ebtables emulation must reject non-bridge targets  xtables targets return netfilter verdicts: NF_ACCEPT, NF_DROP, and so on.  ebtables targets return incompatible verdicts: EBT_ACCEPT, EBT_DROP, ...   We cannot allow fallback to NFPROTO_UNSPEC.  ebtables doesn't permit this since 11ff7288beb2 ("netfilter: ebtables: reject non-bridge targets") but that commit missed the nft_compat layer.

CVE-2026-72420:

        In the Linux kernel, the following vulnerability has been resolved:  md/raid5: avoid R5_Overlap races while breaking stripe batches  KCSAN report a race in break_stripe_batch_list() vs. raid5_make_request() on sh->dev[i].flags (plain word write vs. atomic bit op)..  and .. one possible scenario is:  CPU1                            CPU2 break_stripe_batch_list(sh1) -> handle sh2 -> lock(sh2) -> sh2->batch_head = NULL -> unlock(sh2) -> test_and_clear_bit(R5_Overlap, sh2->dev[i].flags) -> wake_up_bit(sh2->dev[i].flags)                                 raid5_make_request()                                 -> add_all_stripe_bios(sh2)                                 -> lock(sh2)                                 -> stripe_bio_overlaps(sh2) returns true 				   batch_head is NULL, so new bio overlap 				   exist bio on sh2 -> true                                 -> set_bit(R5_Overlap, sh2->dev[i].flags)                                 -> unlock(sh2)                                 -> wait_on_bit(sh2->dev[i].flags) -> sh2->dev[i].flags = sh1->dev[i].flags & ~R5_Overlap  No wait_up_bit(), CPU2 could be wait_on_bit() forever...  Fix by : - Expand the protect zone. - Use batch_head's device flag's snaphot when no held head_sh->stripe_lock. - Move sh/head_sh->batch_head = NULL to the end of protected zone , and ,   any concurrent add_all_stripe_bios() grabs sh->stripe_lock now either: 	- see batch_head != null, and , is rejected by stripe_bio_overlaps() 	  under the lock (no R5_Overlap wait ) , or , 	- sees batch_head == NULL, only after dev[i].flags has already been 	  set and the prior R5_Overlap waiters worken.  KCSAN report: ================================================   BUG: KCSAN: data-race in break_stripe_batch_list / raid5_make_request    write (marked) to 0xffff8e89c8117548 of 8 bytes by task 4042 on cpu 0:     raid5_make_request+0xea0/0x2930     md_handle_request+0x4a2/0xa40     md_submit_bio+0x109/0x1a0     __submit_bio+0x2ec/0x390     submit_bio_noacct_nocheck+0x457/0x710     submit_bio_noacct+0x2a7/0xc20     submit_bio+0x56/0x250     blkdev_direct_IO+0x54c/0xda0     blkdev_write_iter+0x38f/0x570     aio_write+0x22b/0x490     io_submit_one+0xa51/0xf70     __x64_sys_io_submit+0xf7/0x220     x64_sys_call+0x1907/0x1c60     do_syscall_64+0x130/0x570     entry_SYSCALL_64_after_hwframe+0x76/0x7e    read to 0xffff8e89c8117548 of 8 bytes by task 4010 on cpu 5:     break_stripe_batch_list+0x249/0x480     handle_stripe_clean_event+0x720/0x9b0     handle_stripe+0x32fb/0x4500     handle_active_stripes.isra.0+0x6e0/0xa50     raid5d+0x7e0/0xba0     md_thread+0x15a/0x2d0     kthread+0x1e3/0x220     ret_from_fork+0x37a/0x410     ret_from_fork_asm+0x1a/0x30    value changed: 0x0000000000000019 -> 0x0000000000000099 --> R5_Overlap

CVE-2026-72423:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: Guard conntrack opts error writes  The conntrack lookup and allocation kfuncs take an opts pointer together with an opts__sz argument. The verifier checks only the memory range described by opts__sz, but the wrappers unconditionally write opts->error whenever the internal lookup or allocation helper returns an error.  For an invalid size smaller than the end of opts->error, that write can land outside the verifier-checked range. Keep returning NULL for invalid arguments, but only report the error through opts->error when the supplied size includes the field.  This preserves error reporting for the supported 12-byte and 16-byte layouts, and for other invalid sizes that still include opts->error.

CVE-2026-72434:

        In the Linux kernel, the following vulnerability has been resolved:  netfilter: ipset: make sure gc is properly stopped  Sashiko noticed that when destroying a set, cancel_delayed_work_sync() was called while gc calls queue_delayed_work() unconditionally which can lead not to properly shutting down the gc.

CVE-2026-72438:

        In the Linux kernel, the following vulnerability has been resolved:  md/raid10: fix writes_pending and barrier reference leaks on discard failures  raid10_make_request() acquires a writes_pending reference with md_write_start() before calling raid10_handle_discard(). Several failure paths in raid10_handle_discard() complete the bio and return without releasing the corresponding reference, causing md_write_end() to be skipped.  Call md_write_end() before returning from these failure paths to keep writes_pending accounting balanced.  Additionally, discard split allocation failures can occur after wait_barrier() succeeds. Those paths return without calling allow_barrier(), leaking the associated barrier reference.  Release the barrier before returning from those paths.

CVE-2026-72439:

        In the Linux kernel, the following vulnerability has been resolved:  md/raid10: fix writes_pending leak on write request failures  raid10_make_request() acquires a writes_pending reference with md_write_start() before dispatching write requests. Several failure paths in raid10_write_request() complete the bio and return without reaching the normal write completion path, causing the corresponding md_write_end() to be skipped.  Make raid10_write_request() return a status indicating whether the write request was successfully queued. This allows raid10_make_request() to release the writes_pending reference with md_write_end() when a write request fails.

CVE-2026-72440:

        In the Linux kernel, the following vulnerability has been resolved:  md/raid1: fix writes_pending and barrier reference leaks on write failures  raid1_make_request() acquires a writes_pending reference with md_write_start() before calling raid1_write_request(). Several failure paths in raid1_write_request() complete the bio and return without reaching the normal write completion path, causing the corresponding md_write_end() to be skipped.  Make raid1_write_request() return a status indicating whether the write request was successfully queued. This allows raid1_make_request() to call md_write_end() when raid1_write_request() fails.  Additionally, if wait_blocked_rdev() fails after wait_barrier() succeeds, the associated barrier reference is not released.  Call allow_barrier() before returning from that path to keep the barrier accounting balanced.

CVE-2026-72454:

        In the Linux kernel, the following vulnerability has been resolved:  i3c: mipi-i3c-hci: Fix race in i3c_hci_addr_to_dev()  i3c_hci_addr_to_dev() walks bus->devs.i3c, which is protected by bus.lock (rwsem).  However, it is invoked from the MIPI I3C HCI IRQ handler, which cannot take bus.lock.  This allows concurrent device addition/removal in the I3C core to modify the list while it is being traversed, potentially leading to use-after-free or crashes.  Remove the dependency on the bus device list and introduce a dedicated lookup table.  Add an ibi_devs[] array indexed by DAT entry, maintained under hci->lock.  Update the array when IBIs are enabled or disabled, so that it always reflects the set of devices allowed to generate IBIs. Also update when IBIs are freed, to cover the corner case when an IBI is freed without first being disabled (e.g. oldedev in i3c_master_add_i3c_dev_locked()).  Move i3c_hci_addr_to_dev() into core.c, reimplement it using the new array, and add a lockdep assertion to enforce that hci->lock is held by callers.  Demote a message in PIO and DMA IBI handling, from an error to a debug message, because there is a race window when the condition can arise normally.

CVE-2026-72469:

        In the Linux kernel, the following vulnerability has been resolved:  xprtrdma: Fix ep kref imbalance on ADDR_CHANGE  rpcrdma_cm_event_handler() falls through to the disconnected: label on RDMA_CM_EVENT_ADDR_CHANGE and calls rpcrdma_ep_put() with no matching get when the event arrives before RDMA_CM_EVENT_ESTABLISHED. The kref then underflows during connect teardown and rpcrdma_xprt_disconnect() operates on a freed ep.  Reference counts across a normal connection lifecycle:      rpcrdma_ep_create()             kref_init     ->1     rpcrdma_xprt_connect()          ep_get        ->2  (before post_recvs)     RDMA_CM_EVENT_ESTABLISHED       ep_get        ->3     RDMA_CM_EVENT_DISCONNECTED      ep_put        ->2     rpcrdma_xprt_drain()            ep_put        ->1     rpcrdma_xprt_disconnect() tail  ep_put        ->0  (ep_destroy)  The connect-time get in rpcrdma_xprt_connect(), taken just before rpcrdma_post_recvs() "while there are outstanding Receives," is balanced by rpcrdma_xprt_drain. ADDR_CHANGE before ESTABLISHED has no get to consume, so its put drops the count to 1 and the drain put then frees the ep while rpcrdma_xprt_disconnect() still holds a pointer to it.  Fix by dispatching on the prior re_connect_status via xchg(): for prev == 0 (pre-ESTABLISHED) wake the connect waiter and return with no put; for prev == 1 call rpcrdma_force_disconnect() and return. The case-1 arm relies on the subsequent RDMA_CM_EVENT_DISCONNECTED event -- reliably delivered when rdma_disconnect() is called on a still-connected cm_id -- to balance the ESTABLISHED get; rpcrdma_xprt_drain() continues to balance only that connect-time get. Any other prior value means teardown is already in flight.

CVE-2026-72470:

        In the Linux kernel, the following vulnerability has been resolved:  fs/ntfs3: resize log->one_page_buf when adopting on-disk page size  log_replay() allocates log->one_page_buf using the page size that was chosen from the host PAGE_SIZE:  	log->one_page_buf = kmalloc(log->page_size, GFP_NOFS);  Later, when a restart area is found, the log page size recorded on disk is adopted:  	t32 = le32_to_cpu(log->rst_info.r_page->sys_page_size); 	if (log->page_size != t32) { 		log->l_size = log->orig_file_size; 		log->page_size = norm_file_page(t32, &log->l_size, 						t32 == DefaultLogPageSize); 	}  If the on-disk page size is larger than the size used for the initial allocation, log->page_size grows but one_page_buf is left at its original, smaller size. A subsequent unaligned read_log_page() then reads log->page_size bytes into the undersized scratch buffer:  	page_buf = page_off ? log->one_page_buf : *buffer; 	err = ntfs_read_run_nb_ra(ni->mi.sbi, &ni->file.run, page_vbo, page_buf, 				  log->page_size, NULL, &log->read_ahead);  overflowing the allocation. This is reachable when mounting a dirty NTFS volume whose log was formatted with a page size larger than the buffer initially allocated on the mounting host (for example a 64K-log volume mounted on a host that allocated a 4K scratch buffer).  Grow one_page_buf when the adopted on-disk page size exceeds the size used for the initial allocation. On krealloc() failure the original buffer is left intact and freed by the existing error path.

CVE-2026-72472:

        In the Linux kernel, the following vulnerability has been resolved:  nfs: use nfsi->rwsem to protect traversal of the file lock list  Lingfeng identified a bug and suggested two solutions, but both appear to have issues.  Generally, we cannot release flc_lock while iterating over the file lock list to avoid use-after-free (UAF) problems with file locks. However, functions like nfs_delegation_claim_locks and nfs4_reclaim_locks cannot adhere to this rule because recover_lock or nfs4_lock_delegation_recall may take a long time. To resolve this, NFS switches to using nfsi->rwsem for the same protection, and nfs_reclaim_locks follows this approach. Although nfs_delegation_claim_locks uses so_delegreturn_mutex instead, this is inadequate since a single inode can have multiple nfs4_state instances. Therefore, the fix is to also use nfsi->rwsem in this case.  Furthermore, after commit c69899a17ca4 ("NFSv4: Update of VFS byte range lock must be atomic with the stateid update"), the functions nfs4_locku_done and nfs4_lock_done also break this rule because they call locks_lock_inode_wait without holding nfsi->rwsem. Simply adding this protection could cause many deadlocks, so instead, the call to locks_lock_inode_wait is moved into _nfs4_proc_setlk. Regarding the bug fixed by commit c69899a17ca4 ("NFSv4: Update of VFS byte range lock must be atomic with the stateid update"), it has been resolved after commit 0460253913e5 ("NFSv4: nfs4_do_open() is incorrectly triggering state recovery") because all slots are drained before calling nfs4_do_reclaim, which prevents concurrent stateid changes along this path. Also, nfs_delegation_claim_locks does not cause this concurrency either since when _nfs4_proc_setlk is called with NFS_DELEGATED_STATE, no RPC is sent, so nfs4_lock_done is not called. Therefore, nfs4_lock_delegation_recall from nfs_delegation_claim_locks is the first time the stateid is set.

CVE-2026-72488:

        In the Linux kernel, the following vulnerability has been resolved:  soundwire: fix bug in sdw_add_element_group_count found by syzkaller  The original implementation caused an out-of-bounds memory access in the sdw_add_element_group_count for-loop when i == num.  for (i = 0; i <= num; i++) {     if (rate == group->rates[i] && lane == group->lanes[i])         ...  To fix this error, the function now checks for existing rate/lane entries in the group(a function parameter) using a for-loop before adding them.  No functional changes apart from this fix.

CVE-2026-72493:

        In the Linux kernel, the following vulnerability has been resolved:  net: serialize netif_running() check in enqueue_to_backlog()  Syzbot reported a KASAN slab-use-after-free in fib_rules_lookup().  The root cause is a race condition where packets can escape the backlog flushing during device unregistration (e.g., during netns exit).  Commit e9e4dd3267d0 ("net: do not process device backlog during unregistration") introduced a lockless netif_running() check in enqueue_to_backlog() to prevent queuing packets to an unregistering device.  However, this creates a TOCTOU race window.  A lockless transmitter (like veth_xmit) can pass the check before dev_close() clears IFF_UP. If the transmitter is then delayed, flush_all_backlogs() can run and finish before the transmitter grabs the backlog lock and queues the packet. The packet then escapes the flush and triggers UAF later when processed.  Fix this by moving the netif_running() check inside the backlog lock. This serializes the check with the flush work (which also grabs the lock). We then either queue the packet before the flush runs (so it gets flushed), or check netif_running() after the flush/close completes (so it gets dropped).

CVE-2026-72494:

        In the Linux kernel, the following vulnerability has been resolved:  RDMA/irdma: Replace waitqueue and flag with completion  The driver previously used a waitqueue along with an explicit request_done flag, but without proper barriers around request_done.  An earlier patch by Gui-Dong Han <hanguidong02@gmail.com> attempted to fix this by adding the missing memory barriers. Rather than adding the barriers, this patch replaces the waitqueue+flag with a completion, which is designed for this exact purpose.

CVE-2026-74257:

        In the Linux kernel, the following vulnerability has been resolved:  sockmap: Fix use-after-free in udp_bpf_recvmsg()  syzbot reported use-after-free of struct sk_msg in sk_msg_recvmsg(). [0]  sk_msg_recvmsg() peeks sk_msg from psock->ingress_msg under a lock, but its processing is lockless.  Thus, sk_msg_recvmsg() must be serialised by callers, otherwise multiple threads could touch the same sk_msg.  For example, TCP uses lock_sock(), and AF_UNIX uses unix_sk(sk)->iolock.  Initially, udp_bpf_recvmsg() had used lock_sock(), but the cited commit removed it.  Let's serialise sk_msg_recvmsg() with lock_sock() in udp_bpf_recvmsg().  Note that holding spin_lock_bh(&sk->sk_receive_queue.lock) is not an option due to copy_page_to_iter() in sk_msg_recvmsg().  [0]: BUG: KASAN: slab-use-after-free in sk_msg_recvmsg+0xb54/0xc30 net/core/skmsg.c:428 Read of size 4 at addr ffff88814cdcf000 by task syz.0.24/6020  CPU: 1 UID: 0 PID: 6020 Comm: syz.0.24 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 01/13/2026 Call Trace:  <TASK>  dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120  print_address_description mm/kasan/report.c:378 [inline]  print_report+0xba/0x230 mm/kasan/report.c:482  kasan_report+0x117/0x150 mm/kasan/report.c:595  sk_msg_recvmsg+0xb54/0xc30 net/core/skmsg.c:428  udp_bpf_recvmsg+0x4bd/0xe00 net/ipv4/udp_bpf.c:84  inet_recvmsg+0x260/0x270 net/ipv4/af_inet.c:891  sock_recvmsg_nosec net/socket.c:1078 [inline]  sock_recvmsg+0x1a8/0x270 net/socket.c:1100  ____sys_recvmsg+0x1e6/0x4a0 net/socket.c:2812  ___sys_recvmsg+0x215/0x590 net/socket.c:2854  do_recvmmsg+0x334/0x800 net/socket.c:2949  __sys_recvmmsg net/socket.c:3023 [inline]  __do_sys_recvmmsg net/socket.c:3046 [inline]  __se_sys_recvmmsg net/socket.c:3039 [inline]  __x64_sys_recvmmsg+0x198/0x250 net/socket.c:3039  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]  do_syscall_64+0xe2/0xf80 arch/x86/entry/syscall_64.c:94  entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fb319f9aeb9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fb31ad97028 EFLAGS: 00000246 ORIG_RAX: 000000000000012b RAX: ffffffffffffffda RBX: 00007fb31a216090 RCX: 00007fb319f9aeb9 RDX: 0000000000000001 RSI: 0000200000000400 RDI: 0000000000000004 RBP: 00007fb31a008c1f R08: 0000000000000000 R09: 0000000000000000 R10: 0000000040000021 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fb31a216128 R14: 00007fb31a216090 R15: 00007ffe21dd0a98  </TASK>  Allocated by task 6019:  kasan_save_stack mm/kasan/common.c:57 [inline]  kasan_save_track+0x3e/0x80 mm/kasan/common.c:78  poison_kmalloc_redzone mm/kasan/common.c:398 [inline]  __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:415  kasan_kmalloc include/linux/kasan.h:263 [inline]  __kmalloc_cache_noprof+0x3d1/0x6e0 mm/slub.c:5780  kmalloc_noprof include/linux/slab.h:957 [inline]  kzalloc_noprof include/linux/slab.h:1094 [inline]  alloc_sk_msg net/core/skmsg.c:510 [inline]  sk_psock_skb_ingress_self+0x60/0x350 net/core/skmsg.c:612  sk_psock_verdict_apply net/core/skmsg.c:1038 [inline]  sk_psock_verdict_recv+0x7d9/0x8d0 net/core/skmsg.c:1236  udp_read_skb+0x73e/0x7e0 net/ipv4/udp.c:2045  sk_psock_verdict_data_ready+0x12d/0x550 net/core/skmsg.c:1257  __udp_enqueue_schedule_skb+0xc54/0x10b0 net/ipv4/udp.c:1789  __udp_queue_rcv_skb net/ipv4/udp.c:2346 [inline]  udp_queue_rcv_one_skb+0xac5/0x19c0 net/ipv4/udp.c:2475  __udp4_lib_mcast_deliver+0xc06/0xcf0 net/ipv4/udp.c:2585  __udp4_lib_rcv+0x10f6/0x2620 net/ipv4/udp.c:2724  ip_protocol_deliver_rcu+0x282/0x440 net/ipv4/ip_input.c:207  ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:241  NF_HOOK+0x336/0x3c0 include/linux/netfilter.h:318  dst_input include/net/dst.h:474 [inline]  ip_sublist_rcv_finish+0x221/0x2a0 net/ipv4/ip_input.c:584  ip_list_rcv_finish net/ipv4/ip_inp ---truncated---

CVE-2026-74261:

        In the Linux kernel, the following vulnerability has been resolved:  ALSA: seq: avoid stale FIFO cells during resize  snd_seq_fifo_resize() still needs to publish the replacement pool before it waits for FIFO users. A blocking snd_seq_read() holds f->use_lock while it sleeps, so concurrent senders must be able to queue to the new pool and wake that reader instead of failing against a closing old pool.  However, snd_seq_fifo_event_in() duplicates an event before it takes f->lock, and snd_seq_read() can dequeue a cell and later call snd_seq_fifo_cell_putback() if copy_to_user() or snd_seq_expand_var_event() fails. If resize swaps f->pool and detaches oldhead in between, either path can relink an old-pool cell after the snapshot. That stale cell sits outside the drained oldhead list, keeps oldpool->counter elevated, and can leave snd_seq_pool_delete() waiting for the retired pool to drain.  Keep the existing swap-before-wait ordering in snd_seq_fifo_resize(), but reject stale cells before any FIFO relink. Revalidate event-in cells under f->lock and retry them against the published replacement pool, and free stale putback cells instead of linking them back into the FIFO.  The buggy scenario involves two paths, with each column showing the order within that path:  resize path:                    relink path: 1. Allocate newpool.             1. Take f->use_lock. 2. Swap f->pool to newpool and   2. Duplicate or dequeue an old-pool    detach oldhead.                  cell before oldpool closes. 3. Mark oldpool closing and      3. Reach a later relink point after    wait for FIFO users.             resize published newpool. 4. Free oldhead and delete       4. Relink the old-pool cell after    oldpool.                         resize detached oldhead.                                  5. Drop f->use_lock.  The reproducer reports a resize ioctl blocked in the expected pool teardown path:  signal: resize iteration=98 target_pool=4 exceeded 250ms         (elapsed=251ms) diagnostic: resize_tid=651 wchan=snd_seq_pool_done diagnostic: resize_tid=651 stack=   snd_seq_pool_done+0x5b/0x140   snd_seq_pool_delete+0x7a/0x90   snd_seq_fifo_resize+0x193/0x1e0   snd_seq_ioctl_set_client_pool+0x214/0x260   snd_seq_ioctl+0x119/0x540   __x64_sys_ioctl+0xd1/0x120   do_syscall_64+0xbb/0x2f0   entry_SYSCALL_64_after_hwframe+0x77/0x7f  A second run with larger pools hit the same target path:  signal: resize iteration=32 target_pool=64 exceeded 250ms         (elapsed=251ms) diagnostic: resize_tid=663 wchan=snd_seq_pool_done diagnostic: resize_tid=663 stack=   snd_seq_pool_done+0x5b/0x140   snd_seq_pool_delete+0x7a/0x90   snd_seq_fifo_resize+0x193/0x1e0   snd_seq_ioctl_set_client_pool+0x214/0x260   snd_seq_ioctl+0x119/0x540   __x64_sys_ioctl+0xd1/0x120   do_syscall_64+0xbb/0x2f0   entry_SYSCALL_64_after_hwframe+0x77/0x7f

CVE-2026-74264:

        In the Linux kernel, the following vulnerability has been resolved:  net: watchdog: fix refcount tracking races  Blamed commit converted the untracked dev_hold()/dev_put() calls in the watchdog code to use the tracked dev_hold_track()/dev_put_track() (which were later renamed/interfaced to netdev_hold() and netdev_put()).  By introducing dev->watchdog_dev_tracker to store the reference tracking information without adding synchronization between netdev_watchdog_up() and dev_watchdog(), it enabled the race condition where this pointer could be overwritten or freed concurrently, leading to the list corruption crash syzbot reported:  list_del corruption, ffff888114a18c00->next is NULL  kernel BUG at lib/list_debug.c:52 ! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 1 UID: 0 PID: 91 Comm: kworker/u8:5 Not tainted syzkaller #0 PREEMPT(lazy) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/09/2026 Workqueue: events_unbound linkwatch_event  RIP: 0010:__list_del_entry_valid_or_report.cold+0x22/0x2a lib/list_debug.c:52 Call Trace:  <TASK>   __list_del_entry_valid include/linux/list.h:132 [inline]   __list_del_entry include/linux/list.h:246 [inline]   list_move_tail include/linux/list.h:341 [inline]   ref_tracker_free+0x1a7/0x6c0 lib/ref_tracker.c:329   netdev_tracker_free include/linux/netdevice.h:4491 [inline]   netdev_put include/linux/netdevice.h:4508 [inline]   netdev_put include/linux/netdevice.h:4504 [inline]   netdev_watchdog_down net/sched/sch_generic.c:600 [inline]   dev_deactivate_many+0x28c/0xfe0 net/sched/sch_generic.c:1363   dev_deactivate+0x109/0x1d0 net/sched/sch_generic.c:1397   linkwatch_do_dev net/core/link_watch.c:184 [inline]   linkwatch_do_dev+0xd3/0x120 net/core/link_watch.c:166   __linkwatch_run_queue+0x3a5/0x810 net/core/link_watch.c:240   linkwatch_event+0x8f/0xc0 net/core/link_watch.c:314   process_one_work+0xa0e/0x1980 kernel/workqueue.c:3314   process_scheduled_works kernel/workqueue.c:3397 [inline]   worker_thread+0x5ef/0xe50 kernel/workqueue.c:3478   kthread+0x370/0x450 kernel/kthread.c:436   ret_from_fork+0x69a/0xc80 arch/x86/kernel/process.c:158   ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245  This patch has three coordinated parts:  1) Add dev->watchdog_lock and dev->watchdog_ref_held to serialize watchdog operations.  2) Remove netdev_watchdog_up() call from netif_carrier_on():    This ensures netdev_watchdog_up() is only called from process/BH context    (via linkwatch workqueue dev_activate()), allowing us to use    spin_lock_bh() for synchronization.  3) Synchronize watchdog up and watchdog timer:    Protect netdev_watchdog_up() with tx_global_lock and watchdog_lock.    Only allocate a new tracker in netdev_watchdog_up() if one is    not already present.    In dev_watchdog(), ensure we don't release the tracker if the    timer was rescheduled either by dev_watchdog() itself or concurrently    by netdev_watchdog_up().

CVE-2026-74269:

        In the Linux kernel, the following vulnerability has been resolved:  bnxt: fix head underflow on XDP head-grow  The xdp.py test test_xdp_native_adjst_head_grow_data crashes when run on a bnxt machine (and also crashes in NIPA).  It seems that the bug is an underflow in bnxt_rx_multi_page_skb, which builds the skb head:    napi_build_skb(data_ptr - bp->rx_offset, rxr->rx_page_size);  The problem with this expression is that in page mode, rx_offset is:    bp->rx_offset = NET_IP_ALIGN + XDP_PACKET_HEADROOM;  Which evaluates (at least on x86_64) to 258.  The test test_xdp_native_adjst_head_grow_data tests a case where the head is adjusted by -256.  When this test runs, data_ptr is shifted to frag_start + 2 (where frag_start = page_address(page) + offset).  Then, bnxt_rx_multi_page_skb is invoked and the napi_build_skb expression subtracts 258, landing at an address before frag_start. This could be either the previous fragment or the previous physical page when the offset is < 256 (e.g. if the fragment started at offset 0).  When the skb is freed, the page pool fragment reference is dropped on either the wrong page or the wrong frag of the right page. In either case, the corrupted reference count can lead to the page being prematurely recycled while still in use. Once (incorrectly) recycled, it can be handed out again and on driver teardown this would result in a double free.  The commit under fixes updated this code to handle the case where the native page size is >= 64k, but it unintentionally broke the head grow case.  To fix this, add an offset field to struct bnxt_sw_rx_bd, mirroring the existing offset field in struct bnxt_sw_rx_agg_bd. Populate it on allocation and preserve it on reuse.  In bnxt_rx_multi_page_skb, use the newly added offset field to compute the fragment start and pass that to napi_build_skb. Adjust the layout with skb_reserve.  There are two cases, the non-adjustment case and the adjustment case.  In both cases, the skb is built at page_address(page) + offset to account for the case where the native page size >= 64K and skb_reserve is called with data_ptr - (page_address(page) + offset). That difference equals bp->rx_offset when data_ptr was not moved, or bp->rx_offset + xdp_adjust when XDP adjusted the head.  Re-running the failing test with this commit applied causes the test to run successfully to completion.  The other rx_skb_func implementations don't have this issue.

CVE-2026-74272:

        In the Linux kernel, the following vulnerability has been resolved:  cxl/region: Resolve region deletion races  Sungwoo noticed that the sysfs trigger to delete a region may try to delete a region multiple times. It also has no exclusion relative to the kernel releasing the region via CXL root device teardown.  Instead of installing new cxl root devres actions per region, use the existing root decoder unregistration event to remove all remaining regions. An xarray of regions replaces a devres list of regions.  This handles 3 separate issues with the old approach:  1/ sysfs users racing to delete the same region: no longer possible now    that the regions_lock is held over the lookup and deletion.  2/ multiple actions triggering deletion of the same region: solved by    erasing regions while holding @regions_lock, and only proceeding on    successful erasure.  3/ userspace racing devres_release_all() to trigger the devres not found    warning: solved by sysfs unregistration not requiring a release action

CVE-2026-74278:

        In the Linux kernel, the following vulnerability has been resolved:  ALSA: seq: Fix kernel heap address leak in bounce_error_event()  The comment above bounce_error_event() documents that user clients should receive SNDRV_SEQ_EVENT_BOUNCE with the original event embedded as variable-length data, while kernel clients should receive SNDRV_SEQ_EVENT_KERNEL_ERROR with a quoted kernel pointer.  However, the implementation unconditionally uses SNDRV_SEQ_EVENT_KERNEL_ERROR with data.quote.event set to the raw struct snd_seq_event pointer for all clients.  When a bounce error event is delivered to a USER_CLIENT via snd_seq_read(), the kernel heap address in data.quote.event is exposed to userspace through copy_to_user() in the fixed-length branch.  This is a distinct leak path from the one addressed by commit 705dd6dcbc0e ("ALSA: seq: Clear variable event pointer on read"), which sanitizes data.ext.ptr in the variable-length branch of snd_seq_read().  The bounce_error_event() leak uses fixed-length events that take the else branch where no sanitization occurs.  Differentiate the bounce event by client type.  For USER_CLIENT, send SNDRV_SEQ_EVENT_BOUNCE with SNDRV_SEQ_EVENT_LENGTH_VARIABLE and data.ext pointing to the original event.  The variable-length path in snd_seq_event_dup() copies the event data into chained cells, and snd_seq_expand_var_event() copies only the content -- never the pointer -- to userspace.  For KERNEL_CLIENT, keep the existing SNDRV_SEQ_EVENT_KERNEL_ERROR behavior with the quoted pointer.

CVE-2026-74291:

        In the Linux kernel, the following vulnerability has been resolved:  ASoC: topology: Check PCM and DAI name strings before use  Topology objects store several PCM and DAI names in fixed-size UAPI arrays. Other topology parser paths validate these fields with bounded strnlen() checks before using them as C strings, but the PCM and DAI paths still pass some fixed-size arrays directly to strlen(), devm_kstrdup(), DAI lookup, and diagnostic prints.  A malformed topology blob with a non-NUL-terminated PCM, DAI, or stream capability name can therefore make the parser read past the end of the fixed-size field.  Reject unterminated PCM and DAI name fields before consuming them as C strings.

CVE-2026-74302:

        In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: hci_core: Fix UAF in hci_unregister_dev()  hci_unregister_dev() does not disable cmd_timer and ncmd_timer before the hci_dev structure is freed. If a timeout fires during device teardown, the callback dereferences freed memory (including the hdev->reset function pointer), leading to a use-after-free.  Add disable_delayed_work_sync() calls alongside the existing disable_work_sync() calls to ensure both timers are fully quiesced before teardown proceeds.

CVE-2026-74307:

        In the Linux kernel, the following vulnerability has been resolved:  ext4: validate donor file superblock early in EXT4_IOC_MOVE_EXT  Reject the EXT4_IOC_MOVE_EXT ioctl early if the donor file does not belong to the same superblock as the original file.  Currently, this validation is performed inside ext4_move_extents() by mext_check_validity(), but only after lock_two_nondirectories() has already acquired the inode locks.  When the donor fd refers to a file on a different filesystem (e.g., overlayfs), this late validation creates a circular lock dependency:    CPU0 (overlayfs write)            CPU1 (ext4 ioctl)   ----                              ----   inode_lock(ovl_inode)                                     mnt_want_write_file(filp)                                       sb_start_write(ext4_sb)   [sb_writers]     backing_file_write_iter()       vfs_iter_write(real_file)         file_start_write(real_file)           sb_start_write(ext4_sb)   [blocked by freeze]                                     lock_two_nondirectories()                                       inode_lock(ovl_inode)     [blocked]  With a concurrent freeze operation holding sb_writers write side, this forms a deadlock cycle: CPU0 waits for freeze to complete, freeze waits for CPU1's sb_writers reader to exit, CPU1 waits for CPU0's inode lock.  Since EXT4_IOC_MOVE_EXT exchanges physical extents between two files, it fundamentally requires both files to reside on the same ext4 filesystem.  Moving the superblock check before any lock acquisition is both semantically correct and eliminates the circular dependency by ensuring that cross-filesystem donor fds are rejected before sb_writers or inode locks are taken.

CVE-2026-74308:

        In the Linux kernel, the following vulnerability has been resolved:  ext4: fix kernel BUG in ext4_write_inline_data_end  When the data=journal mount option is used, the ext4_journalled_write_end() function incorrectly calls ext4_write_inline_data_end() without checking if the EXT4_STATE_MAY_INLINE_DATA flag is still set on the inode.  If a previous attempt to convert the inline data to an extent failed (e.g. due to ENOSPC), the EXT4_STATE_MAY_INLINE_DATA flag is cleared, but the EXT4_INODE_INLINE_DATA flag remains set. In this scenario, the next call to ext4_write_begin() will not prepare the inline data xattr for writing, but ext4_journalled_write_end() will incorrectly attempt to write to it, triggering a BUG_ON(pos + len > EXT4_I(inode)->i_inline_size) in ext4_write_inline_data() since i_inline_size was not expanded.  Fix this by ensuring that ext4_journalled_write_end() only calls ext4_write_inline_data_end() if the EXT4_STATE_MAY_INLINE_DATA flag is set, mirroring the behavior of ext4_write_end() and ext4_da_write_end().

CVE-2026-74314:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: Cancel special fields on map value recycle  Map update and delete paths currently call bpf_obj_free_fields() when a value is being replaced or recycled. That makes field destruction depend on the context of the update/delete operation. For tracing programs this can include NMI context, where referenced kptr destructors, uptr unpinning, and graph root destruction are not generally safe.  Introduce bpf_obj_cancel_fields() for the reusable-value path. It only performs NMI-safe cleanup for timer, workqueue, and task_work fields. Fields that need full destruction are left attached to the recycled value and are destroyed by the final cleanup path instead.  Switch array and hashtab update/delete/recycle paths to this cancel helper. Keep bpf_obj_free_fields() for final map destruction and for bpf_mem_alloc destructors. Preallocated hashtabs do not have allocator destructors, so teardown continues to walk the normal and extra elements and fully destroy their fields.  This deliberately relaxes the eager-free semantics of map update/delete for special fields. Programs that relied on a recycled map slot becoming empty immediately after update/delete were relying on behavior that cannot be implemented safely from every BPF execution context without offloading arbitrary destructors.  There is a chance this change breaks programs making assumptions regarding the eager freeing of fields. If so, we can relax semantics to cancellation only when irqs_disabled() is true in the future. However, theoretically, map values that get reused eagerly already have weaker guarantees as parallel users can recreate freed fields before the new element becomes visible again.

CVE-2026-74317:

        In the Linux kernel, the following vulnerability has been resolved:  ixgbe: do not configure xps for XDP queues  netif_set_xps_queue() should not be called for an XDP Tx queue, since such queues are not netdev-exposed. On systems with number of CPUs >=64, on E610 adapter, netdev is configured with maximum number queue pairs being 63 (due to MSI-X assignment), but configuring XDP results in 64 XDP queues.  So, during XDP program load, when netif_set_xps_queue() is called for the last XDP queue, we get a WARNING with a call trace and KASAN report afterwards (if enabled).  [ 2012.699800] WARNING: net/core/dev.c:2854 at __netif_set_xps_queue+0x116a/0x1e40, CPU#36: xdpsock/103668 [...] [ 2012.700029] RIP: 0010:__netif_set_xps_queue+0x116a/0x1e40 [ 2012.700035] Code: b6 34 06 48 89 f8 83 e0 07 83 c0 01 40 38 f0 7c 09 40 84 f6 0f 85 03 0a 00 00 0f b7 44 24 40 66 43 89 44 6a 18 e9 01 fb ff ff <0f> 0b e9 f2 ee ff ff 44 8b 44 24 44 45 85 c0 74 50 4d 85 e4 0f 84 [ 2012.700040] RSP: 0018:ffff8882369aeb28 EFLAGS: 00010246 [ 2012.700046] RAX: 0000000000000000 RBX: 000000000000003f RCX: 0000000000000000 [ 2012.700050] RDX: 1ffff1111da3d891 RSI: ffff888120e34250 RDI: ffff8888ed1ec488 [ 2012.700054] RBP: ffff888913281560 R08: 0000000000000000 R09: ffff8888ed1ec000 [ 2012.700058] R10: ffff8888a2e83180 R11: 0000000000000000 R12: 0000000000007fa8 [ 2012.700061] R13: 000000000000003f R14: ffff888120e34854 R15: ffff8889132817c8 [ 2012.700065] FS:  00007fc8ea9ff740(0000) GS:ffff88884cefe000(0000) knlGS:0000000000000000 [ 2012.700069] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 2012.700073] CR2: 00007f81c8000020 CR3: 00000002299f8006 CR4: 00000000007726f0 [ 2012.700077] PKRU: 55555554 [ 2012.700080] Call Trace: [ 2012.700084]  <TASK> [ 2012.700087]  ? ktime_get+0x61/0x150 [ 2012.700097]  ? usleep_range_state+0x133/0x1b0 [ 2012.700108]  ? __pfx_usleep_range_state+0x10/0x10 [ 2012.700114]  netif_set_xps_queue+0x31/0x50 [ 2012.700119]  ixgbe_configure_tx_ring+0x472/0x920 [ixgbe] [...] [ 2012.700486]  ixgbe_xdp+0x38f/0x750 [ixgbe]  [...]  [ 2012.701094] BUG: KASAN: slab-out-of-bounds in __netif_set_xps_queue+0x1ac5/0x1e40 [ 2012.701100] Write of size 4 at addr ffff88888d43cff8 by task xdpsock/103668  Skip XPS configuration for XDP Tx queues.

CVE-2026-74318:

        In the Linux kernel, the following vulnerability has been resolved:  btrfs: fix deadlock cloning inline extent when using flushoncommit  In commit b48c980b6a7e ("btrfs: fix deadlock between reflink and transaction commit when using flushoncommit") a deadlock was fixed between reflinks and transaction commits when the fs is mounted with the flushoncommit option. This happened when we had to copy an inline extent's data to the destination file. However the issue was fixed only for the case where the destination offset is 0, it missed the case when the offset is greater than zero.  Fix this by ensuring we get i_size update whenever we copied an inline extent's data into the destination file.  Syzbot reported this with the following trace:     INFO: task kworker/u8:3:57 blocked for more than 143 seconds.          Not tainted syzkaller #0    "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.    task:kworker/u8:3    state:D stack:21600 pid:57    tgid:57    ppid:2      task_flags:0x4208160 flags:0x00080000    Workqueue: writeback wb_workfn (flush-btrfs-129)    Call Trace:     <TASK>     context_switch kernel/sched/core.c:5402 [inline]     __schedule+0x16f9/0x5500 kernel/sched/core.c:7204     __schedule_loop kernel/sched/core.c:7283 [inline]     schedule+0x164/0x360 kernel/sched/core.c:7298     wait_extent_bit fs/btrfs/extent-io-tree.c:905 [inline]     btrfs_lock_extent_bits+0x59c/0x700 fs/btrfs/extent-io-tree.c:2008     btrfs_lock_extent fs/btrfs/extent-io-tree.h:152 [inline]     btrfs_invalidate_folio+0x440/0xc00 fs/btrfs/inode.c:7718     extent_writepage fs/btrfs/extent_io.c:1848 [inline]     extent_write_cache_pages fs/btrfs/extent_io.c:2552 [inline]     btrfs_writepages+0x12f3/0x2410 fs/btrfs/extent_io.c:2684     do_writepages+0x32e/0x550 mm/page-writeback.c:2571     __writeback_single_inode+0x133/0x10e0 fs/fs-writeback.c:1764     writeback_sb_inodes+0x97f/0x1980 fs/fs-writeback.c:2056     wb_writeback+0x445/0xb00 fs/fs-writeback.c:2241     wb_do_writeback fs/fs-writeback.c:2388 [inline]     wb_workfn+0x3fd/0xf20 fs/fs-writeback.c:2428     process_one_work+0x98b/0x1630 kernel/workqueue.c:3318     process_scheduled_works kernel/workqueue.c:3401 [inline]     worker_thread+0xb49/0x1140 kernel/workqueue.c:3482     kthread+0x388/0x470 kernel/kthread.c:436     ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158     ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245     </TASK>    INFO: task syz.0.145:8523 blocked for more than 143 seconds.          Not tainted syzkaller #0    "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.    task:syz.0.145       state:D stack:22752 pid:8523  tgid:8522  ppid:5850   task_flags:0x400140 flags:0x00080002    Call Trace:     <TASK>     context_switch kernel/sched/core.c:5402 [inline]     __schedule+0x16f9/0x5500 kernel/sched/core.c:7204     __schedule_loop kernel/sched/core.c:7283 [inline]     schedule+0x164/0x360 kernel/sched/core.c:7298     wb_wait_for_completion+0x3e8/0x790 fs/fs-writeback.c:227     __writeback_inodes_sb_nr+0x24c/0x2d0 fs/fs-writeback.c:2847     try_to_writeback_inodes_sb+0x9a/0xc0 fs/fs-writeback.c:2895     btrfs_start_delalloc_flush fs/btrfs/transaction.c:2182 [inline]     btrfs_commit_transaction+0x813/0x2fc0 fs/btrfs/transaction.c:2371     btrfs_sync_file+0xdf4/0x1230 fs/btrfs/file.c:1822     generic_write_sync include/linux/fs.h:2663 [inline]     btrfs_do_write_iter+0x6a9/0x840 fs/btrfs/file.c:1473     new_sync_write fs/read_write.c:595 [inline]     vfs_write+0x629/0xba0 fs/read_write.c:688     ksys_write+0x156/0x270 fs/read_write.c:740     do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]     do_syscall_64+0x15f/0x560 arch/x86/entry/syscall_64.c:94     entry_SYSCALL_64_after_hwframe+0x77/0x7f    RIP: 0033:0x7f5a0bdece59    RSP: 002b:00007f5a0b446028 EFLAGS: 00000246 ORIG_RAX: 0000000000000001    RAX: ffffffffffffffda RBX: 00007f5a0c065fa0 RCX: 00007f5a0bdece59    RDX: 000000000000029f RSI: 0000200000 ---truncated---

CVE-2026-74337:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: Fix NMI/tracepoint re-entry deadlock on lru locks  NMI and tracepoint BPF programs can re-enter the per-CPU or global LRU lock that bpf_lru_pop_free()/push_free() already hold on the same CPU, AA-deadlocking. Lockdep reports "inconsistent {INITIAL USE} -> {IN-NMI}" on &l->lock (syzbot c69a0a2c816716f1e0d5) and "possible recursive locking detected" on &loc_l->lock (syzbot 18b26edb69b2e19f3b33).  Prior trylock and rqspinlock based fixes (see links) were nacked because compromised on reliability.  This patch converts every LRU lock site to rqspinlock_t and adds a recovery path for some failure windows to avoid node leaks.  Failure recovery:   - *_pop_free top-level: return NULL; prealloc_lru_pop() already    treats that as no-free-element (-ENOMEM).   - Cross-CPU steal: skip the victim's locked loc_l, try next CPU.   - Post-steal local lock fail: publish stolen node to lockless    per-CPU free_llist; next pop on this CPU picks it up.   - push_free fail: mark node pending_free=1. __local_list_flush(),    __local_list_pop_pending() reclaim the node from pending_list.    __bpf_lru_list_shrink_inactive() reclaims the node from inactive    list. Nodes from active list are reclaimed by __bpf_lru_list_shrink()    or after __bpf_lru_list_rotate_active() demotes it to the inactive.

CVE-2026-74338:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: Reject sleepable BPF_LSM_CGROUP programs at load time  The cgroup shim runs under rcu_read_lock_dont_migrate(), so we should not attach any sleepable BPF programs there. Add support to the verifier to explicitly reject attempts to load sleepable BPF programs destined for LSM cgroup attachment.  Without this, we get the following splat from a BPF_LSM_CGROUP program marked BPF_F_SLEEPABLE attached to file_open when it calls bpf_get_dentry_xattr():    BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1567   in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 34317, name: load   preempt_count: 0, expected: 0   RCU nest depth: 2, expected: 0   Call Trace:    down_read+0x76/0x480    ext4_xattr_get+0x11f/0x700    __vfs_getxattr+0xf0/0x150    bpf_get_dentry_xattr+0xbb/0xf0    bpf_prog_e76a298dac9218c6_test_open+0x6a/0x85    __cgroup_bpf_run_lsm_current+0x326/0x840    bpf_trampoline_6442534646+0x62/0x14d    security_file_open+0x34/0x60    do_dentry_open+0x340/0x1260    vfs_open+0x7a/0x440    path_openat+0x1bac/0x30a0  libbpf provides a .s named section variant for every sleepable program type except lsm_cgroup, reflecting that per-cgroup LSM programs are intended to only run in a non-sleepable context.  The above splat was obtained by bypassing libbpf by using bpf(2) directly.

CVE-2026-74342:

        In the Linux kernel, the following vulnerability has been resolved:  kernfs: link kn to its parent before the LSM init hook  After commit 12e9e3cd03b5 ("simpe_xattr: use per-sb cache"), kernfs_xattr_set() and kernfs_xattr_get() compute the cache via kernfs_root(kn) before any other check.  kernfs_root(kn) walks kn->__parent first and falls back to kn->dir.root, both of which are NULL on a freshly kmem_cache_zalloc()'d kn. kn->__parent was being set in kernfs_new_node() after __kernfs_new_node() returned, and kn->dir.root is set even later by kernfs_create_dir_ns() / kernfs_create_empty_dir().  The LSM kernfs_init_security hook is invoked from inside __kernfs_new_node(), before either field has been initialized. selinux_kernfs_init_security() ends with kernfs_xattr_set(kn, XATTR_NAME_SELINUX, ...).  kernfs_root(kn) then returns NULL, and &((struct kernfs_root *)NULL)->xa_cache evaluates to offsetof(struct kernfs_root, xa_cache) which faults:    BUG: kernel NULL pointer dereference, address: 00000000000000e0   RIP: 0010:simple_xattr_set+0x27/0x8b0   Call Trace:    kernfs_xattr_set+0x63/0xb0    selinux_kernfs_init_security+0x13b/0x270    security_kernfs_init_security+0x36/0xc0    __kernfs_new_node+0x182/0x290    kernfs_new_node+0x80/0xc0    kernfs_create_dir_ns+0x2b/0xa0    cgroup_create+0x116/0x380    cgroup_mkdir+0x7c/0x1a0  Reproduces deterministically at PID 1 (systemd) on an SELinux-enabled distro. The first cgroup mkdir under /sys/fs/cgroup with a labelled parent panics the kernel.  The LSM hook's contract is that the kn_dir argument is the parent of the new kn, so kn->__parent should already point at kn_dir when the hook runs.  Move kernfs_get(parent) and rcu_assign_pointer of kn->__parent from kernfs_new_node() into __kernfs_new_node() right before the security hook, and unwind the parent reference on the err_out4 path.  kernfs_root(kn) then takes its parent branch during the hook and returns parent->dir.root, which is the correct root.  This also closes the same-shape latent bug in kernfs_xattr_get() (which today is hidden only by kernfs_iattrs_noalloc() returning NULL on a fresh kn).

CVE-2026-74345:

        In the Linux kernel, the following vulnerability has been resolved:  RDMA/siw: Fix endpoint/socket association handling  Disassociating a socket from an endpoint via siw_socket_disassoc() may release the last reference on that endpoint and free it. Therefore, don't clear the endpoints socket pointer after calling that function, but within.  This fixes a:    BUG: KASAN: slab-use-after-free in siw_cm_work_handler (drivers/infiniband/sw/siw/siw_cm.c:1053 drivers/infiniband/sw/siw/siw_cm.c:1075)  which occurred after processing a malformed MPA request during connection establishment, causing the new endpoint to be closed.

CVE-2026-74347:

        In the Linux kernel, the following vulnerability has been resolved:  netfilter: cttimeout: detach dataplane timeout policy and repurpose refcount  Add a refcount for struct nf_ct_timeout which is used by ct extension to set the custom ct timeout policy, this tells us that the ct timeout is being used by a conntrack entry. When the last conntrack entry drops the refcount on the ct timeout, the ct timeout is released.  Remove the refcount for control plane which controls if the ruleset refers to the timeout policy. After this update, it is possible to remove the ct timeout policy from nfnetlink_cttimeout immediately. This is for simplicity not to handle two refcounts on a single object.  Remove nf_queue_nf_hook_drop(): a packet sitting in nfqueue will just hold a reference to the nf_ct_timeout object until packet is reinjected, since this is part of the ct extension, this will be released by the time the conntrack is freed.  nf_ct_untimeout() is still called to clean up in a best effort basis: the ct timeout on existing entries gets removed when the ct timeout goes away, but as long as the iptables ruleset still refers to the ct timeout through a template, new conntracks may keep attaching it and extend its lifetime until the rule is removed.  nf_ct_untimeout() is not called anymore from module removal path, this is unlikely to find timeouts give module refcount is bumped, and the new refcount already tracks the ct timeout policy use so it is released when unused.

CVE-2026-74350:

        In the Linux kernel, the following vulnerability has been resolved:  ocfs2: validate fast symlink target during inode read  ocfs2_validate_inode_block() already rejects several inconsistent self-contained dinodes before they are exposed to the rest of the filesystem.  Fast symlinks need the same treatment.  A zero-cluster symlink is treated as a fast symlink and later read through page_get_link() and ocfs2_fast_symlink_read_folio().  That path uses strnlen() on the inline payload and then copies len + 1 bytes into the folio.  If a corrupt dinode stores an i_size that does not fit the inline area or omits the terminating NUL at i_size, that copy reads past the end of the inode block buffer.  Reject zero-cluster symlink dinodes whose i_size exceeds the inline fast-symlink capacity or whose inline payload is not NUL-terminated exactly at i_size when the inode block is validated.  This keeps malformed fast symlinks from reaching the read path.  Validation reproduced this kernel report: KASAN use-after-free in ocfs2_fast_symlink_read_folio+0x12c/0x1f0 RIP: 0033:0x7f5c6d859aa7 Read of size 3905 Call trace:   dump_stack_lvl+0x66/0xa0 (?:?)   print_report+0xce/0x630 (?:?)   ocfs2_fast_symlink_read_folio+0x12c/0x1f0 (fs/ocfs2/inode.c:?)   srso_alias_return_thunk+0x5/0xfbef5 (?:?)   __virt_addr_valid+0x19f/0x330 (?:?)   kasan_report+0xe0/0x110 (?:?)   kasan_check_range+0x105/0x1b0 (?:?)   __asan_memcpy+0x23/0x60 (?:?)   filemap_read_folio+0x27/0xe0 (?:?)   filemap_read_folio+0x35/0xe0 (?:?)   do_read_cache_folio+0x138/0x230 (?:?)   __page_get_link+0x26/0x110 (?:?)   page_get_link+0x2e/0x70 (?:?)   vfs_readlink+0x15e/0x250 (?:?)   touch_atime+0x4d/0x370 (?:?)   do_readlinkat+0x186/0x200 (?:?)   do_user_addr_fault+0x65a/0x890 (?:?)   __x64_sys_readlink+0x46/0x60 (?:?)   do_syscall_64+0x115/0x6a0 (arch/x86/entry/syscall_64.c:87)   entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)

CVE-2026-74356:

        In the Linux kernel, the following vulnerability has been resolved:  vhost: fix vhost_get_avail_idx for a non empty ring  vhost_get_avail_idx is supposed to report whether it has updated vq->avail_idx. Instead, it returns whether all entries have been consumed, which is usually the same. But not always - in drivers/vhost/net.c and when mergeable buffers have been enabled, the driver checks whether the combined entries are big enough to store an incoming packet. If not, the driver re-enables notifications with available entries still in the ring. The incorrect return value from vhost_get_avail_idx propagates through vhost_enable_notify and causes the host to livelock if the guest is not making progress, as vhost will immediately disable notifications and retry using the available entries.  This goes back to commit d3bb267bbdcb ("vhost: cache avail index in vhost_enable_notify()") which changed vhost_enable_notify() to compare the freshly read avail index against vq->last_avail_idx instead of the previously cached vq->avail_idx. Commit 7ad472397667 ("vhost: move smp_rmb() into vhost_get_avail_idx()") then carried over the same comparison when refactoring vhost_enable_notify() to call the unified vhost_get_avail_idx().  The obvious fix is to make vhost_get_avail_idx do what the comment says it does and report whether new entries have been added.

CVE-2026-74374:

        In the Linux kernel, the following vulnerability has been resolved:  md/raid1,raid10: fix error-path detection with md_cloned_bio()  Detect the error path using md_cloned_bio() instead of relying on r1_bio in raid1 or r10_bio->read_slot in raid10, which may be NULL or -1 after splitting and resubmitting a failed bio.  As a result, the error path may not be recognized and memory allocations can incorrectly use GFP_NOIO instead of (GFP_NOIO | __GFP_HIGH), which can lead to a deadlock under memory pressure.

CVE-2026-74386:

        In the Linux kernel, the following vulnerability has been resolved:  nvmet-tcp: fix page fragment cache leak in error path  In nvmet_tcp_alloc_queue(), when a connection is closed during the allocation process (e.g., nvmet_tcp_set_queue_sock() returns -ENOTCONN), the error handling jumps to out_destroy_sq and then to out_ida_remove without draining the page fragment cache.  Although nvmet_tcp_free_cmd() is called in some error paths to release individual page fragments, the underlying page cache reference held by queue->pf_cache is never released. The first allocation using pf_cache is the call to nvmet_tcp_alloc_cmd() for queue->connect, which happens after ida_alloc() returns successfully. This results in a page leak each time a connection fails during allocation, which could lead to memory exhaustion over time if connections are repeatedly opened and closed.  Fix this by calling page_frag_cache_drain() before freeing the queue structure in the out_ida_remove label.

CVE-2026-74388:

        In the Linux kernel, the following vulnerability has been resolved:  ALSA: seq: oss: Fix UAF at handling events with embedded SysEx data  The OSS sequencer processes the input MIDI bytes into a sequencer event to be dispatched later (in snd_seq_oss_midi_putc() called from snd_seq_oss_process_event()).  When it's a SysEx data, the event record contains data.ext.ptr pointer to the original SysEx bytes, and the referred data is copied into the pool afterwards at dispatching. The problem is that, if the sequencer port gets closed concurrently before the dispatch, the OSS sequencer core also releases the resources (in snd_seq_oss_midi_check_exit_port()), while the pending event may hold a stale pointer, eventually leading to a UAF at a later dispatch.  Fortunately, there is already a refcounting mechanism (snd_use_lock_t) for the OSS MIDI device access, and for addressing the issue above, we just need to extend the refcount until the event gets dispatched.  This patch extends snd_seq_oss_process_event() to give back the refcount object, which is in turn released after calling the sequencer dispatcher with the given event in the caller side.  According to the original report, KASAN report as below:  KASAN slab-use-after-free in snd_seq_event_dup+0x40c/0x470 RIP: 0033:0x7f2cb66a6340 Read of size 6 Call trace:   dump_stack_lvl+0x73/0xb0 (?:?)   print_report+0xd1/0x650 (?:?)   srso_alias_return_thunk+0x5/0xfbef5 (?:?)   __virt_addr_valid+0x1a7/0x340 (?:?)   kasan_complete_mode_report_info+0x64/0x200 (?:?)   kasan_report+0xf7/0x130 (?:?)   snd_seq_event_dup+0x40c/0x470 (?:?)   kasan_check_range+0x10c/0x1c0 (?:?)   __asan_memcpy+0x27/0x70 (?:?)   snd_seq_event_dup+0x9/0x470 (?:?)   snd_seq_client_enqueue_event+0x139/0x240 (?:?)   _raw_spin_unlock_irqrestore+0x4b/0x60 (?:?)   snd_seq_kernel_client_enqueue+0x102/0x120 (?:?)   snd_seq_oss_write+0x416/0x4e0 (?:?)   apparmor_file_permission+0x20/0x30 (?:?)   odev_write+0x3b/0x60 (?:?)   vfs_write+0x1ce/0x850 (?:?)   lock_release+0xc8/0x2a0 (?:?)   __kasan_check_write+0x18/0x20 (?:?)   __mutex_unlock_slowpath+0x129/0x510 (?:?)   ksys_write+0xe1/0x180 (?:?)   mutex_unlock+0x16/0x20 (?:?)   odev_ioctl+0x65/0xc0 (?:?)   __x64_sys_write+0x46/0x60 (?:?)   x64_sys_call+0x7d/0x20d0 (?:?)   do_syscall_64+0xc1/0x360 (arch/x86/entry/syscall_64.c:87)   entry_SYSCALL_64_after_hwframe+0x77/0x7f (?:?)

CVE-2026-74389:

        In the Linux kernel, the following vulnerability has been resolved:  RDMA/hns: Fix log flood after cmd_mbox failure  hns_roce_cmd_mbox() is the command interface between driver and hardware. When hardware is abnormal, the unlimited error printings after hns_roce_cmd_mbox() failure will cause log flood and even system crash.  Replace ibdev_err() and ibdev_warn() with their ratelimited versions in the error handling path after hns_roce_cmd_mbox() (and its wrappers hns_roce_create_hw_ctx/hns_roce_destroy_hw_ctx) fails.

CVE-2026-74391:

        In the Linux kernel, the following vulnerability has been resolved:  tracing: Bound synthetic-field strings with seq_buf  The synthetic field helpers build a prefixed synthetic variable name and a generated hist command in fixed MAX_FILTER_STR_VAL buffers. The current code appends those strings with raw strcat(), so long key lists, field names, or saved filters can run past the end of the staging buffers.  Build both strings with seq_buf and propagate -E2BIG if either the synthetic variable name or the generated command exceeds MAX_FILTER_STR_VAL. This keeps the existing tracing-side limit while using the helper intended for bounded command construction.  [ sdr: Moved struct seq_buf *s for upside-down x-mas tree formatting ]

CVE-2026-74397:

        In the Linux kernel, the following vulnerability has been resolved:  IB/mlx5: Fix transport-domain rollback and initialize lb mutex earlier  mlx5_ib_alloc_transport_domain() allocates a transport domain and then may fail in mlx5_ib_enable_lb(). In that case, the allocated TD is leaked.  Fix this by deallocating the TD when mlx5_ib_enable_lb() returns an error. Also return 0 explicitly in the no-loopback-capability success branch, and move dev->lb.mutex initialization to mlx5_ib_stage_init_init().

CVE-2026-74401:

        In the Linux kernel, the following vulnerability has been resolved:  dlm: fix add msg handle in send_queue ordered  In a benchmark scenario triggering a lot of requests that triggers a lot of DLM messages on the network it can be that the mh->seq is not ordered according the oldest seq number. This ordering is required by dlm_receive_ack as "before(mh->seq, seq)" will stop to check for older sequence numbers that are ordered in the tail of "node->send_queue".  The side effects of not having it correct ordered regarding "before(mh->seq, seq)" are refcounting issues and use-after free.  I only was able to reproduce this issue in a experimental DLM branch and a user space DLM benchmark that uses io_uring. After changing this I don't experienced any refcounting with the sending buffer issues anymore.

CVE-2026-74405:

        In the Linux kernel, the following vulnerability has been resolved:  OPP: Fix race between OPP addition and lookup  A race exists between dev_pm_opp_add_dynamic() and dev_pm_opp_find_freq_exact():    CPU0 (add)                          CPU1 (lookup)   -------------------------------     ------------------------------   _opp_add()     mutex_lock()     list_add(&new_opp->node, head)     mutex_unlock()                    _opp_table_find_key()                                         mutex_lock()                                         dev_pm_opp_get(opp)                                           kref_get()                                         mutex_unlock()     kref_init(&new_opp->kref)                                       dev_pm_opp_put()                                         kref_put_mutex()  The newly added OPP is inserted into the list before its kref is initialized. A concurrent lookup can find this OPP and increment its reference count while it is still uninitialized, leading to refcount corruption and a potential premature free.  Fix this by initializing ->kref and ->opp_table before making the OPP visible via list_add(). This ensures any concurrent lookup observes a fully initialized object.  [ Viresh: Updated commit log ]

CVE-2026-74407:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: ath11k: cancel SSR work items during PCI shutdown  A reboot can crash the kernel if it overlaps with WLAN firmware crash recovery (SSR). The crash is a NULL pointer dereference in the MHI teardown path while freeing DMA-backed MHI contexts.  Simplified trace:   dma_free_attrs   mhi_deinit_dev_ctxt [mhi]   ath11k_pci_power_down [ath11k_pci]   ath11k_pci_shutdown [ath11k_pci]   device_shutdown   kernel_restart  On the host side, SSR is driven by the MHI RDDM callback, which queues reset_work to perform device recovery. reset_work power-cycles the device by calling ath11k_hif_power_down() followed by ath11k_hif_power_up(). The power-down phase deinitializes MHI and frees DMA resources.  Shutdown/reboot runs fully asynchronously with this RDDM-driven SSR recovery flow. As a result, the shutdown path (ath11k_pci_shutdown() -> ath11k_pci_power_down()) can race with the SSR recovery sequence.  Fix this by canceling SSR-related work items during PCI shutdown, marking the device as unregistering, and serializing the RDDM callback path that checks and queues reset_work. This ensures that no new SSR recovery work can be queued once teardown has started, and that any in-flight recovery work is fully synchronized before device power-down, preventing MHI teardown and DMA resource freeing from running more than once.  Note: This issue only affects PCI/MHI-based devices. AHB-based ath11k devices do not queue reset_work in normal SSR flows.  Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-04866.5-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1

CVE-2026-74417:

        In the Linux kernel, the following vulnerability has been resolved:  drm/radeon: fix integer overflow in radeon_align_pitch()  radeon_align_pitch() has the same kind of overflow issue as the old amdgpu helper: both the alignment round-up add and the final 'aligned * cpp' calculation can overflow signed int.  If that wraps, radeon_mode_dumb_create() can end up returning an invalid pitch or creating a zero-sized dumb buffer.  Fix this by using check_add_overflow() for the alignment round-up and check_mul_overflow() for the final pitch calculation, returning 0 on overflow. Also reject zero pitch and size in radeon_mode_dumb_create().  Found via AST-based call-graph analysis using sqry.

CVE-2026-74445:

        In the Linux kernel, the following vulnerability has been resolved:  drm/vmwgfx: reject DX_BIND_QUERY without a DX context  vmw_cmd_dx_bind_query() unconditionally dereferences sw_context->dx_ctx_node->ctx.  Userspace can trigger a NULL pointer dereference from any render-node fd by submitting an execbuf with dx_context_handle == SVGA3D_INVALID_ID and a SVGA_3D_CMD_DX_BIND_QUERY opcode in the command stream: dx_ctx_node is left NULL and the kernel oopses on the assignment.  The same NULL is then re-read in vmw_resources_reserve() via vmw_context_get_dx_query_mob().  All sibling DX handlers fail-close on a missing dx_ctx_node using VMW_GET_CTX_NODE().  Use the same pattern here, returning -EINVAL up front before any relocation state is published.

CVE-2026-74466:

        In the Linux kernel, the following vulnerability has been resolved:  s390/zcrypt: Close speculative mem read possibility  The domain value is extracted from a given CCA or EP11 ioctl struct when a CPRB is about to be sent. Thus this is a user controlled value. Under some special conditions (custom device node used, administrative load) this value is used as an array index after bounds checking, but without speculation barrier.  Add the missing array_index_nospec() call to prevent speculative execution where this domain value is used.

CVE-2026-74506:

        In the Linux kernel, the following vulnerability has been resolved:  afs: Fix UAF when sending a message  In afs_make_call(), there's a race with async call reception and destruction.  If a call is dispatched that doesn't have call->write_iter set (used to specify the data content for FS.StoreData), then the first rxrpc_kernel_send_data() will not set MSG_MORE in the msghdr.  Once rxrpc_send_data() queues the last request packet, the response could come in at any time and cause the call to be completed and put.  However, afs_make_call() will look at the call again to see it ->write_iter should be handled - something it's only allowed to do if it has its own ref on the call.  Whilst this is the case for synchronous calls, it isn't true for async calls such as FS.FetchData.  There's also a potential UAF in afs_make_call() in the event that an asynchronous call is being sent, but the call fails in some way (e.g. it gets aborted from the server).  The problem there is that afs_make_call() tries to abort a call if the rxrpc send fails, but the asynchronous notification from rxrpc may have caused the afs_call to be torn down.  generic/650 plays games with randomly taking CPUs offline, and can interject a significant delay such that the call is deallocated before afs_make_call() gets to check call->write_iter - and a UAF ensues (caught by KASAN).     BUG: KASAN: slab-use-after-free in afs_make_call+0x1c90/0x2210 [kafs]    Read of size 8 at addr ffff888035e050e8 by task fsstress/1409  Fix this by making afs_make_op_call() give the op->call its own ref rather than transferring the caller's ref to it and then dropping the ref when afs_make_call() returns.  This also means that the afs_make_call() func never loses its ref on the call now.

CVE-2026-74527:

        In the Linux kernel, the following vulnerability has been resolved:  octeontx2-af: Block VFs from clobbering special CGX PKIND state  PF and VF NIX LFs that share a CGX LMAC reuse the same hardware PKIND programming. When HiGig2 or EDSA parsing is enabled, a VF NIX LF alloc must not reset the LMAC RX PKIND or default TX parse config over the PF setup.  Add cgx_get_pkind() and rvu_cgx_is_pkind_config_permitted() so VFs skip cgx_set_pkind(), rvu_npc_set_pkind(), and NIX_AF_LFX_TX_PARSE_CFG updates when the LMAC is using NPC_RX_HIGIG_PKIND or NPC_RX_EDSA_PKIND.

CVE-2026-74536:

        In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: ISO: fix leaking sk after socket release  iso_sock_kill() tests !sock_flag(sk, SOCK_ZAPPED) || sk->sk_socket || sock_flag(sk, SOCK_DEAD) for early return, but this is always true since sock_orphan(sk) sets SOCK_DEAD, so the sk reference released by socket always leaks, iso_sock_destruct is never called.  The socket reference also leaks when __iso_sock_close() does not set SOCK_ZAPPED, since iso_conn_del() does not call iso_sock_kill() after zapping.  Fix by replacing SOCK_DEAD by BT_SK_KILLED flag that is not used for something else, and lock_sock to ensure iso_sock_kill() puts sk only after socket release only once. Release and iso_conn_del may run concurrently. Call iso_sock_kill() from iso_conn_del() to clean sk up after zapping.  Remove call to iso_sock_kill() from iso_sock_close(), as it's generally no-op there.

CVE-2026-74537:

        In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: ISO: hold sk properly in iso_conn_ready  sk deref in iso_conn_ready must be done either under conn->lock, or holding a refcount, to avoid concurrent close. conn->sk is currently accessed without either:      [Task 1]            [Task 2]                         iso_sock_release     iso_conn_ready       sk = conn->sk                           lock_sock(sk)                             conn->sk = NULL       lock_sock(sk)                           release_sock(sk)                           iso_sock_kill(sk)        UAF on sk deref  Fix possible UAF by holding sk refcount in iso_conn_ready().  Also recheck after lock_sock that the socket is still valid.  Adjust locking so conn->sk is cleared only under lock_sock.

CVE-2026-74543:

        In the Linux kernel, the following vulnerability has been resolved:  net: udp_tunnel: fix memory leak in udp_tunnel_nic_unregister()  syzbot reported a memory leak [1] in the UDP tunnel NIC offload code.  When device registration fails (e.g. in register_netdevice()), netdev core unwinds by sending a single NETDEV_UNREGISTER notification. If work was queued during NETDEV_REGISTER (utn->work_pending is set), udp_tunnel_nic_unregister() returns early:  	if (utn->work_pending) 		return;  Because failed registrations do not enter netdev_wait_allrefs_any(), no subsequent NETDEV_UNREGISTER rebroadcast will ever occur. As a result, the struct udp_tunnel_nic allocated in udp_tunnel_nic_alloc() is leaked permanently.  Fix this by removing the early return. Instead, synchronously cancel any pending work with cancel_delayed_work_sync() before freeing @utn.  To be able to call cancel_delayed_work_sync() while holding RTNL (the work also needs RTNL), switch udp_tunnel_nic_device_sync_work() to rtnl_trylock(). If RTNL is contended, requeue the work with a 1 jiffy delay (via queue_delayed_work()) to prevent high CPU contention while waiting for RTNL lock.  The utn->work_pending bookkeeping is no longer needed and is removed, as the workqueue core already tracks the pending/running state of the work.  [1] BUG: memory leak unreferenced object 0xffff888127d5f840 (size 96):   comm "syz-executor", pid 5806, jiffies 4294942188   backtrace (crc 99fdb6c8):     __kmalloc_noprof+0x3bf/0x550     udp_tunnel_nic_alloc net/ipv4/udp_tunnel_nic.c:756 [inline]     udp_tunnel_nic_register net/ipv4/udp_tunnel_nic.c:833 [inline]     udp_tunnel_nic_netdevice_event+0x804/0xab0 net/ipv4/udp_tunnel_nic.c:931     notifier_call_chain+0x59/0x160 kernel/notifier.c:85     call_netdevice_notifiers_info+0x7d/0xb0 net/core/dev.c:2250     register_netdevice+0xc10/0xeb0 net/core/dev.c:11478

CVE-2026-74544:

        In the Linux kernel, the following vulnerability has been resolved:  net/sched: cls_u32: validate offshift to prevent shift-out-of-bounds  u32_change() copies the user-provided tc_u32_sel.offshift (unsigned char, 0-255) into the kernel knode object without bounds validation. When a packet later hits u32_classify() with TC_U32_VAROFFSET set, it evaluates `ntohs(offmask & *data) >> offshift` where the left operand is a 16-bit value promoted to a 32-bit int. Any offshift >= 32 is undefined behavior per C11 6.5.7p3, triggerable by an unprivileged user via user/network namespaces.  UBSAN: shift-out-of-bounds in net/sched/cls_u32.c:236:43 shift exponent 32 is too large for 32-bit type int  Fix this by rejecting offshift >= 16 during filter creation in u32_change().

CVE-2026-74571:

        In the Linux kernel, the following vulnerability has been resolved:  btrfs: skip global block reserve accounting for rescue mounts  [BUG] Mounting with rescue=ibadroots after corrupting the block group tree root triggers a NULL pointer dereference:    BUG: kernel NULL pointer dereference, address: 0000000000000100   RIP: 0010:btrfs_update_global_block_rsv+0x9d/0x1c0 [btrfs]   Call Trace:    fill_dummy_bgs+0xd4/0x120 [btrfs]    open_ctree+0xc6e/0x1ca0 [btrfs]    btrfs_get_tree+0x50d/0xa40 [btrfs]  The same crash occurs with a corrupted raid stripe tree root, via btrfs_read_block_groups() instead of fill_dummy_bgs().  [CAUSE] With rescue=ibadroots, btrfs_read_roots() allows the mount to continue when either root cannot be read, leaving the corresponding root pointer NULL while its on-disk feature bit remains set.  btrfs_update_global_block_rsv() then dereferences the missing root based on the feature bit alone.  [FIX] Rescue mounts are fully read-only and cannot start transactions, so the global reserve is never consumed. Under btrfs_is_full_ro(), mark the reserve as full and return before performing the accounting.  And since we need to check if the fs is mount fully RO, export fs_is_full_ro() as btrfs_is_full_ro(), and move it to fs.h.  [ Squash the fs_is_full_ro() export commit into this one. ]

CVE-2026-74592:

        In the Linux kernel, the following vulnerability has been resolved:  ima: Instantiate file_truncate and path_truncate hooks  Instantiate the file_truncate and path_truncate LSM hooks to reset the action cache flags (IMA_DONE_MASK) as soon as truncation is requested, so the file, based on policy, is re-collected, re-measured, re-audited, and re-appraised on next access.

CVE-2026-74599:

        In the Linux kernel, the following vulnerability has been resolved:  mm/ptdump: always stabilise against page table freeing using init_mm  Previous commits have established the invariant that kernel page table freeing is performed while an mmap read lock on init_mm is held, which fixes races between ptdump and kernel page table freeing over init_mm.  However, x86 and arm64 can perform a ptdump over an mm other than init_mm via ptdump_walk_pgd() and since kernel memory ranges are shared across non-kernel mm's, this means that the race still exists for these cases.  Fix this by acquiring a nested mmap write lock for init_mm in ptdump_walk_pgd().  This is safe as we take this after mmap write locking the mm, and nothing acquires the init_mm lock first before locking an arbitrary mm, so no deadlock is possible.  Also update walk_page_range_debug() to assert that init_mm is write locked, add a comment explaining why and remove some redundant code, and eliminate the unnecessary and confusing invocation of walk_kernel_page_table_range().  We can safely remove the non-NULL check for walk.mm, as the mmap lock asserts would NULL pointer deref if it was (and of course no callers do this).  The first point at which ptdump can race kernel page table freeing is commit b6bdb7517c3d ("mm/vmalloc: add interfaces to free unmapped page table"), so we target this in the Fixes tag.

CVE-2026-74600:

        In the Linux kernel, the following vulnerability has been resolved:  mm/page_table_check: skip special zero mappings  page_table_check_set() and page_table_check_clear() account mappings based on PageAnon().  Shared zero-page PTEs and huge zero PMDs are special mappings, but page_table_check can still account them as file-backed pages.  An unprivileged process can populate enough zero mappings to overflow file_map_count and hit the existing BUG_ON().  The PTE path can do this with the shared zero page, and the PMD path can do the same with huge zero mappings.  Skip special zero mappings in the user page-table accounting paths.  Keep the PTE-side pte_special() check, and identify huge zero PMDs from the mapped folio instead of pmd_special().  That covers architectures where pmd_special() is a no-op without adding huge_zero_pfn checks to the generic counter helpers.

CVE-2026-74611:

        In the Linux kernel, the following vulnerability has been resolved:  tls: rx: restore msg_iter before TLS 1.3 optimistic retry  tls_decrypt_sg() advances msg->msg_iter when it maps user pages for the optimistic TLS 1.3 zero-copy path. If the decrypted record turns out not to be unpadded application data, tls_decrypt_sw() retries into a kernel skb, but leaves the iterator advanced.  The subsequent copy from the skb then writes decrypted bytes again at a later point in the caller iovecs while recvmsg() reports only the post-retry length. A TLS peer can trigger this after the receiver enables TLS_RX_EXPECT_NO_PAD.  Revert the iterator by the number of bytes consumed by the optimistic mapping before retrying without zero-copy.  Add a selftest which sends a TLS 1.3 control record with TLS_RX_EXPECT_NO_PAD enabled and verifies that recvmsg() does not overwrite later iovecs beyond the returned length.

CVE-2026-74638:

        In the Linux kernel, the following vulnerability has been resolved:  drm/v3d: Serialize the scheduler timeout handlers  V3D exposes several independent hardware queues (BIN, RENDER, TFU and CSD) but has only a single, global reset. A timeout on any one queue therefore has to stop, reset and restart the schedulers of every other queue as well. That makes concurrent timeout handlers unsafe.  `reset_lock` was never able to make them safe, as a driver-side lock can only cover the driver's &drm_sched_backend_ops.timedout_job callback. The scheduler handles the timed out job and its pending list around that callback, outside of the driver's control, so a global reset triggered by one queue can still interfere with another queue that is in the middle of handling a timeout of its own.  Consequently, if a reset happens in the CSD queue while a CL-intensive application is running, the global reset stops and restarts the CL queue's scheduler while that queue is handling a timeout of its own. As drm_sched_stop() and drm_sched_start() subtract and add the credits of every job sitting on the pending list of the scheduler they are called on, and as the CL queue's handler concurrently takes its job off that same list and puts it back, the stop and the start no longer see the same set of jobs. The CL queue is left with more credits in flight than its limit:  [  327.302739] ------------[ cut here ]------------ [  327.302744] WARNING: CPU: 2 PID: 43 at drivers/gpu/drm/scheduler/sched_main.c:102 drm_sched_run_job_work+0x238/0x4d0 [gpu_sched] [  327.302884] CPU: 2 UID: 0 PID: 43 Comm: kworker/u16:1 Not tainted 6.18.39-v8-16k+ #3 PREEMPT [  327.302889] Hardware name: Raspberry Pi 5 Model B Rev 1.0 (DT) [  327.302893] Workqueue: v3d_bin drm_sched_run_job_work [gpu_sched] [  327.302984] Call trace: [  327.302987]  drm_sched_run_job_work+0x238/0x4d0 [gpu_sched] (P) [  327.302997]  process_scheduled_works+0x180/0x3d0 [  327.303010]  worker_thread+0x268/0x3e8 [  327.303016]  kthread+0x140/0x250 [  327.303022]  ret_from_fork+0x10/0x20 [  327.303031] ---[ end trace 0000000000000000 ]---  From that point on, the credit count of the CL queue is broken, causing a complete GPU hang and UI freeze.  The DRM scheduler already provides a mechanism to serialize the timeout handlers of different schedulers: an ordered workqueue passed as drm_sched_init()'s @timeout_wq parameter. By default, each scheduler queues its timeout work on the system workqueue, which runs the handlers concurrently. Give all of the queues a shared ordered workqueue instead, as recommended by the DRM scheduler documentation for hardware that has distinct queues but resets globally.

CVE-2026-74653:

        In the Linux kernel, the following vulnerability has been resolved:  serial: 8250_of: clear stuck empty-FIFO RX-timeout on LPC32xx  The NXP LPC32xx UART (PORT_LPC3220) can latch an RX character-timeout interrupt while the RX FIFO is empty: IIR reports UART_IIR_RX_TIMEOUT (0x0c) but LSR.DR is clear. A character timeout is only cleared by reading RHR, but serial8250_rx_chars() reads RHR only when LSR.DR is set, so nothing ever clears the condition. The interrupt is level-triggered and re-fires immediately, so on a single-core ARM926 the resulting interrupt storm livelocks the CPU.  It is reproducible when userspace repeatedly opens the front-panel port (ttyS1): serial8250_do_set_termios() re-enables interrupts on unlock and the handler then spins forever with iir=0xcc lsr=0x60 ier=0x05, tripping the soft-lockup detector in serial8250_handle_irq_locked().  LPC32xx has no dedicated 8250 glue driver, it's driven by the generic 8250_of. Add a hardware specific handle_irq for PORT_LPC3220, wired up in of_platform_serial_setup() the same way fsl8250_handle_irq is installed. The handler follows dw8250_handle_irq(): on an RX timeout with an empty FIFO (LSR.DR and LSR.BI clear) it does one throwaway RHR read to clear the condition, then calls serial8250_handle_irq_locked(). No real received data is ever discarded, and it is a no-op on healthy UARTs which never report a timeout with DR clear.  This is the same class of bug already worked around in other 8250 drivers; see commit 424d79183af0 ("serial: 8250_dw: Avoid "too much work" from bogus rx timeout interrupt") which reports the identical iir=0xcc/lsr=0x60. See also UART_RX_TIMEOUT_QUIRK in 8250_omap, and the note in 8250_bcm7271.

CVE-2026-74677:

        In the Linux kernel, the following vulnerability has been resolved:  net: usb: ipheth: fix carrier_work UAF on disconnect  ipheth_sndbulk_callback() re-arms the carrier-check work on any non-zero URB status:  	else 		schedule_delayed_work(&dev->carrier_work, 0);  Nothing ties that to the interface being up, so the work can be armed again after ipheth_close() has already drained it, and stay armed until the netdev whose private area embeds it is freed.  On unplug with a TX URB in flight, ipheth_disconnect() drains the work through unregister_netdev() -> ipheth_close() -> cancel_delayed_work_sync() and only then calls ipheth_kill_urbs(). usb_kill_urb() completes the in-flight TX URB with -ENOENT, so ipheth_sndbulk_callback() runs after the drain and re-arms carrier_work.  The same completion also re-arms the work if the interface is only brought down while a TX URB is in flight, and ipheth_carrier_check_work() then keeps re-queueing itself once a second. unregister_netdev() does not call ipheth_close() for an already-down interface, so nothing drains it on the later unplug either.  In both cases free_netdev() frees the netdev while carrier_work is still pending, and ipheth_carrier_check_work() dereferences freed memory.  Tie the work to the interface state instead of chasing the completion: disable it in ipheth_close() and enable it in ipheth_open(), so a schedule_delayed_work() from the URB completion is a no-op whenever the interface is not up. disable_delayed_work_sync() also waits for a running instance, so it fully replaces the cancel_delayed_work_sync() it takes the place of. The work starts out disabled in ipheth_probe() so the enable/disable counts balance from the first open.  Reproduced under KASAN on linux-next (next-20260731) with dummy_hcd and raw-gadget standing in for the device, driving the second path above (the interface is already down, so unregister_netdev() does not call ipheth_close()): 15 of 15 unpatched boots report a slab-use-after-free in __run_timers(), freed by ipheth_disconnect() and re-armed from ipheth_sndbulk_callback() via queue_delayed_work_on(). The same trigger on a kernel differing only by this patch reports 0 of 15, and the carrier check still functions across open/close cycles.  The reproducer needs an attached USB device that stops draining bulk OUT, plus a link down and unplug, driven as root. It is not a privilege boundary crossing and no exploit primitive was developed.  Found by 0sec (https://0sec.ai).

CVE-2026-74684:

        In the Linux kernel, the following vulnerability has been resolved:  net: tap: set skb->dev before parsing virtio net header in tap_get_user_xdp()  The commit 4f61f133f354 ("net: tap: NULL pointer derefence in dev_parse_header_protocol when skb->dev is null") fixed a crash in tap_get_user() by assigning skb->dev before calling tun_vnet_hdr_to_skb(). This is required because virtio_net_hdr_to_skb() may invoke dev_parse_header_protocol(), which dereferences skb->dev. Without the assignment, a NULL pointer dereference can occur.  However, tap_get_user_xdp() still parses the virtio-net header before assigning skb->dev. When the vhost TX path passes an XDP buffer containing a GSO virtio-net header but the protocol is set to zero on purpose, tun_vnet_hdr_to_skb() can reach dev_parse_header_protocol() while skb->dev is still NULL, resulting in a crash.  Fix this by looking up the tap device and assigning skb->dev before calling tun_vnet_hdr_to_skb(), matching the ordering already used in tap_get_user(). Preserve the existing RCU read-side critical section across dev_queue_xmit().

CVE-2026-74687:

        In the Linux kernel, the following vulnerability has been resolved:  watchdog: at91sam9_wdt: prevent timer rearm during teardown  at91_ping() rearms the watchdog timer from its callback. timer_delete() neither waits for a running callback nor prevents it from rearming the timer, so probe failure or driver removal can leave the timer accessing the devm-allocated at91wdt after it has been freed.  Use timer_shutdown_sync() on both teardown paths. It waits for a running callback and rejects any attempt by the callback to rearm the timer.

CVE-2026-74690:

        In the Linux kernel, the following vulnerability has been resolved:  s390/ism: Fix UAF of sba and ieq during ism_dev_exit()  A ism interrupt handler can be active in parallel with ism_dev_exit(), accessing freed data structures.  No new interrupts will be generated after unregister_ieq(). Drain ongoing interrupt handlers by free_irq(), before freeing ism data structures.

CVE-2026-74695:

        In the Linux kernel, the following vulnerability has been resolved:  netfilter: nf_flow_table: drop existing skb dst before skb_dst_set_noref()  Incoming skbs passing through netfilter flowtable offload hooks (or XFRM offload path) might already carry a ref-counted dst_entry assigned during earlier RX or routing steps.  Calling skb_dst_set_noref() when skb already holds a ref-counted dst overwrites skb->_skb_refdst, leaking the previous dst_entry reference count and triggering a DEBUG_NET_WARN_ON_ONCE assertion in skb_dst_check_unset():    WARNING: at skb_dst_check_unset include/linux/skbuff.h:1170   WARNING: at skb_dst_set_noref include/linux/skbuff.h:1234   WARNING: at nf_flow_offload_ip_hook+0xf6c/0x2b60 net/netfilter/nf_flow_table_ip.c:864  Drop any existing dst_entry reference with skb_dst_drop(skb) before setting the non-referenced flowtable destination.

CVE-2026-74700:

        In the Linux kernel, the following vulnerability has been resolved:  net/sched: cls_api: Always acquire rtnl_lock when destroying locked classifiers  Another challenge with unlocked filters. There is a short window in tc_new_tfilter where a tcf_proto can be found and briefly referenced by a totally unrelated, unlocked classifier's request and cause a race.  Feng created a poc which created this race with two threads, one creating a u32 filter and other a flower filter in the same chain/prio:  1. Both threads enter tc_new_tfilter, both find the chain empty, both    drop filter_chain_lock 2. u32 finishes tcf_proto_create("u32") first, calls    tcf_chain_tp_insert_unique() -> inserts u32_tp into the chain 3. flower finishes tcf_proto_create("flower") later, calls    tcf_chain_tp_insert_unique() -> tcf_chain_tp_find() now sees u32_tp    already there, takes a reference on it, destroys flower's own tp_new    and returns u32_tp to the caller.  Flower then hits the kind mismatch check (because it requested for kind "flower" but tp->ops->kind is "u32") and goes through the errout path which calls tcf_proto_put() on u32_tp. If the u32 thread has already gone through its own errout (its change() call failed on the PoC's empty options) and dropped its create and insert refs, flower's put is the last one and drops u32_tp's refcnt to zero.  At this point tp->ops->destroy() runs in a context that never took rtnl_lock. When that happens, it might cause a UAF like the following (illustrated by the PoC):  [  +0.000710] BUG: KASAN: slab-use-after-free in u32_init (net/sched/cls_u32.c:393) [  +0.000281] Read of size 8 at addr ffff888120022f00 by task poc_feng_xue/524    Call Trace:    u32_init (net/sched/cls_u32.c:393)    tc_new_tfilter (net/sched/cls_api.c:2378)    Allocated by task 526:    u32_init (net/sched/cls_u32.c:378)    tc_new_tfilter (net/sched/cls_api.c:2378)    Freed by task 522:    kfree    u32_destroy (net/sched/cls_u32.c:662)    tcf_proto_destroy (net/sched/cls_api.c:446)    tcf_proto_put (net/sched/cls_api.c:459)    tc_new_tfilter (net/sched/cls_api.c:2459)  Fix this by having tcf_proto_destroy() take rtnl_lock around tp->ops->destroy() for locked classifiers whenever rtnl is not held.  To explain why I used a temp variable "not_lockless" I'd like to point to a semi-related note on rtnl_held vs TCF_PROTO_OPS_DOIT_UNLOCKED (adding here for future cleanup if deemed necessary): The rtnl_held parameter and the TCF_PROTO_OPS_DOIT_UNLOCKED flag are redundant sources of truth for whether rtnl_lock is held. Among the nine classifier destroy(..rtnl_held..) callbacks, only flower consults the rtnl_held parameter which it propagates to tc_setup_cb_destroy() and tc_setup_cb_call(). The other eight (u32, flow, bpf, cgroup, route, basic, fw, mall) ignore it entirely;-> those that call tc_setup_cb_destroy() (u32, bpf, mall) hardcode true always instead of forwarding the parameter.  A future cleanup should remove the rtnl_held parameter from the destroy callback signature entirely and have callers rely solely on their knowledge whether they are running in an unlocked context.

CVE-2026-74713:

        In the Linux kernel, the following vulnerability has been resolved:  vhost_iotlb: bound map allocation in add_range  vhost_iotlb_add_range_ctx() only retires an old entry when the table has a non-zero limit, has exactly reached that limit and has VHOST_IOTLB_FLAG_RETIRE set. Non-retiring tables can keep allocating entries after reaching their configured limit.  Existing vhost devices allocate their IOTLB with max_iotlb_entries from vhost.c, which defaults to 2048 and is tunable by module parameter. Use the caller-provided limit at the allocation point instead of adding a separate default in the common IOTLB helper, and reject non-positive values in vhost paths that can report an error.  Other vhost IOTLB users should not create zero-limit tables when entries can be populated from userspace or guest-controlled requests. Add caller-side max_iotlb_entries parameters for mlx5 vDPA, VDUSE and vhost-vDPA. Reject non-positive VDUSE and vhost-vDPA values, and require at least two entries for vdpa_sim and mlx5 vDPA paths that install full-range mappings, since those mappings are split into two IOTLB entries.  Handle full-range mappings in the common helper by checking that the IOTLB can hold both split entries before inserting the first half. This avoids returning an error after leaving a half mapping behind.  When the table is full, keep the existing retire behavior for retiring tables and return -ENOSPC for non-retiring tables. Reuse the retired map node instead of freeing it and allocating a replacement, so a stream of IOTLB updates cannot keep forcing GFP_ATOMIC allocations after the table has reached its limit. If a zero-limit IOTLB still reaches the common helper, treat it as a configuration error and return -EINVAL.  I found this bug myself, though the patch was written with AI assistance.

CVE-2026-74715:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: Fix netns reference imbalance in conntrack kfuncs  The opts argument of the BPF conntrack kfuncs can point to a shared map value.  __bpf_nf_ct_lookup() and __bpf_nf_ct_alloc_entry() read opts->netns_id separately when acquiring and releasing the network namespace reference.  The reference imbalance can occur as follows:    CPU 0                                  CPU 1   read opts->netns_id (-1)   skip get_net_ns_by_id()                                          write opts->netns_id (id)   read opts->netns_id (id)   put_net(net) /* no matching get */  The reverse transition leaks the reference.  Repeating the unmatched put can destroy a live namespace and crash later users.  The kernel reported:    Oops: general protection fault, probably for non-canonical address   KASAN: null-ptr-deref in range [0x00000000000000e8-0x00000000000000ef]   RIP: 0010:bpf_prog_test_run_xdp+0x52c/0x1700   Call Trace:    __sys_bpf+0x1662/0x50c0    __x64_sys_bpf+0x73/0xb0    do_syscall_64+0xf9/0x540    entry_SYSCALL_64_after_hwframe+0x77/0x7f   Kernel panic - not syncing: Fatal exception  Snapshot every input field of opts with READ_ONCE() before validating or using it.  The netns_id snapshot keeps the namespace get/put pair balanced, while the other snapshots keep the remaining options from changing partway through an invocation.  The individual reads can still observe an inconsistent combination during a concurrent update, but each selected field value remains stable for that invocation.

CVE-2026-74723:

        In the Linux kernel, the following vulnerability has been resolved:  btrfs: lzo: reject inline extents without valid headers  [BUG] For a crafted btrfs image, the following KASAN can be triggered when reading an inline lzo compressed file extent:    BUG: KASAN: slab-out-of-bounds in lzo_decompress+0x57d/0x700   Read of size 4 at addr ffff888006f2e644 by task btrfs_lzo_inlin/77    Call Trace:    <TASK>    dump_stack_lvl+0x5b/0x70    print_report+0xd1/0x610    kasan_report+0xe0/0x110    __asan_report_load_n_noabort+0x13/0x20    lzo_decompress+0x57d/0x700    btrfs_decompress+0x140/0x1c0    uncompress_inline+0x147/0x1b0    btrfs_get_extent+0xb23/0x10a0    btrfs_do_readpage.constprop.0+0x538/0x1ac0    btrfs_readahead+0x32f/0x5f0    read_pages+0x16f/0x850    page_cache_ra_unbounded+0x296/0x490    do_page_cache_ra+0xd9/0x130    page_cache_sync_ra+0x3ee/0x6f0    filemap_get_pages+0x306/0x15c0    filemap_read+0x329/0xd00    btrfs_file_read_iter+0x1f8/0x2b0    vfs_read+0x4ef/0x720    ksys_read+0xf8/0x1d0    __x64_sys_read+0x71/0xb0    x64_sys_call+0x1ab0/0x1b70    do_syscall_64+0x61/0x470    entry_SYSCALL_64_after_hwframe+0x4b/0x53    </TASK>  [CAUSE] For an inline lzo compressed file extent, there should always be one lzo header, recording the total length of the compressed data, followed by one segment header, recording the compressed lzo payload.  But if a crafted inline lzo compressed file extent contains only an lzo header, without the segment header or payload, lzo_decompress() will still try to read the segment header, causing a read beyond the item boundary.  Furthermore if the inline lzo compressed file extent is the first item of the leaf, it will be at the extent buffer boundary. The above out-of-boundary read will go beyond the extent buffer boundary, triggering the above KASAN report.  [FIX] Validate the total length of the inlined lzo compressed file extent, to make sure there is at least one LZO header and one segment header, and a non-zero payload.  [ Rework the commit message to remove slop ]

CVE-2026-74725:

        In the Linux kernel, the following vulnerability has been resolved:  enic: fix tx_hang_reset use-after-free on device removal  enic_remove() cancels the reset and change_mtu_work items but does not cancel tx_hang_reset. A TX timeout that fires while the device is being removed can schedule enic_tx_hang_reset() so that it runs after free_netdev(), resulting in a use-after-free.  cancel_work_sync() alone is not sufficient here: the still-live watchdog and notify paths can re-schedule these work items in the window between the cancel and unregister_netdev(). Use disable_work_sync(), which cancels the work and blocks any subsequent schedule_work() from requeuing it, and apply it to the reset and change_mtu_work items as well so the same requeue race is closed for all teardown work.

CVE-2026-74729:

        In the Linux kernel, the following vulnerability has been resolved:  soc: aspeed: lpc-snoop: Fix usercopy overflow in snoop_file_read  put_fifo_with_discard() acts as both producer and consumer on the kfifo: it calls kfifo_skip() (advances out) and kfifo_put() (advances in) from the IRQ handler without synchronizing with snoop_file_read(), which also consumes via kfifo_to_user(). On SMP systems this concurrent access can leave (in - out) larger than the ring buffer, so __kfifo_to_user()'s clamp to (in - out) is ineffective and kfifo_copy_to_user() can attempt a copy_to_user() past the kmalloc-2k backing store:    usercopy: Kernel memory exposure attempt detected from SLUB object   'kmalloc-2k' (offset 0, size 2049)!   kernel BUG at mm/usercopy.c!   Call trace:    usercopy_abort    __check_heap_object    __check_object_size    kfifo_copy_to_user    __kfifo_to_user    snoop_file_read    vfs_read  Serialize kfifo access with a per-channel spinlock shared between the IRQ handler (producer) and the file reader (consumer).  Annotate @fifo with __guarded_by(&lock) and opt the driver into context analysis so the compiler enforces that all fifo access holds the lock.

CVE-2026-74733:

        In the Linux kernel, the following vulnerability has been resolved:  gpio: pca953x: fix pca953x_irq_bus_sync_unlock regmap lock  Locking is disabled in the regmap config as this driver uses its own lock. This means that all calls to regmap functions (read or write) must hold the i2c_lock. The function pca953x_irq_bus_sync_unlock() did not do this, and it was therefore possible that multiple threads could cause an incorrect register to be read/written.  A previous patch partly fixed this, but only protected the write to the interrupt mask register, and not the read from the direction register.

CVE-2026-74735:

        In the Linux kernel, the following vulnerability has been resolved:  l2tp: fix tunnel and session refcount leak on seq_file release  In pppol2tp_proc_open() and l2tp_dfs_seq_open(), iteration state (pd->tunnel and pd->session) is kept in seq_file private data to allow iteration across multiple read() system calls.  However, if userspace closes /proc/net/pppol2tp or /sys/kernel/debug/l2tp/tunnels before reading to end-of-file (EOF), any tunnel or session reference stored in pd->tunnel / pd->session is left un-dropped when seq_file private data is freed.  Fix this by dropping any remaining pd->tunnel and pd->session references in pppol2tp_proc_release() and l2tp_dfs_seq_release() when closing the file.

CVE-2026-74740:

        In the Linux kernel, the following vulnerability has been resolved:  net/sched: act_api: fix TOCTOU NULL deref on a->goto_chain  tcf_action_exec() handles TC_ACT_GOTO_CHAIN by first checking rcu_access_pointer(a->goto_chain) and then calling tcf_action_goto_chain_exec(), which does a second, independent rcu_dereference_bh(a->goto_chain) read and immediately dereferences chain->filter_chain. A concurrent tcf_action_set_ctrlact() (e.g. the gact replace path) can clear a->goto_chain between the two reads, so the second read returns NULL and tcf_action_goto_chain_exec() dereferences NULL.  Fix the race by doing a single rcu_dereference_bh() read of a->goto_chain in tcf_action_exec(), checking it once for NULL, and passing the resulting chain pointer into tcf_action_goto_chain_exec(). This turns the split check/use into a single check/use on one value.

CVE-2026-74747:

        In the Linux kernel, the following vulnerability has been resolved:  ipvs: revalidate ihl to prevent out-of-bounds access  While the outer IP header is already pulled into the skb head, we must be careful and revalidate the embedded headers after reading them from the skb frags to prevent out-of-bounds access.  One such place reported by Sashiko is ip_vs_nat_icmp() where local process can change the ihl field and after skb_ensure_writable() we can see larger value which is a problem for the ip_send_check(cih) calls.  Add check to drop the packet if the ihl field is changed.

CVE-2026-74752:

        In the Linux kernel, the following vulnerability has been resolved:  sctp: validate cookie AUTH state before use  When cookie authentication is disabled, COOKIE_ECHO restores fixed-size AUTH fields directly from peer-controlled cookie bytes.  A forged RANDOM length, HMAC list, or CHUNKS list can then reach association consumers with lengths or identifiers that were never validated against the local backing arrays.  A forged RANDOM length can cause out-of-bounds reads during key-vector construction.  A forged HMAC identifier also caused a 32-byte write past a zero-length AUTH chunk, providing a primitive for a local privilege escalation chain.  Validate the cookie's RANDOM, HMACS, and CHUNKS parameters at the cookie trust boundary before copying them into the association.  Reject invalid types, malformed lengths, unsupported HMAC identifiers, HMAC lists without SHA1, and forbidden chunk ids.

CVE-2026-74754:

        In the Linux kernel, the following vulnerability has been resolved:  scsi: core: pair EH runtime PM get and put  shost->eh_noresume is currently consulted twice in one error handling iteration: once before scsi_autopm_get_host() and once again before scsi_autopm_put_host().  That is racy when a PM-triggered error path flips shost->eh_noresume while the SCSI EH thread is still running.  The problem flow looks like this: PM path   ufshcd_set_dev_pwr_mode()     shost->eh_noresume = 1     ufshcd_execute_start_stop  <-- trigger EH     ...     shost->eh_noresume = 0  EH path   scsi_error_handler()     if (!shost->eh_noresume)       scsi_autopm_get_host()  <-- skipped     ...     if (!shost->eh_noresume)        scsi_autopm_put_host()  <-- executed later  In that case one EH iteration can skip autoresume on entry and still drop a runtime PM reference on exit. That leaves an unmatched runtime PM put and can trigger a runtime PM usage count underflow.  Fix this by making eh_noresume a regular bool so it can be accessed with READ_ONCE() and WRITE_ONCE(). Snapshot it once per EH iteration and use that snapshot for both runtime PM get and put decisions.

CVE-2026-80526:

        In the Linux kernel, the following vulnerability has been resolved:  ASoC: tas2562: Validate values for volume writes  tas2562_volume_control_put() does not do any validation of the control value written by userspace, it uses it to look up a value in a fixed size array which can easily be overflowed and then writes whatever value it gets back to the device.  Add validation that we are loading a value we have in the array.

CVE-2026-80551:

        In the Linux kernel, the following vulnerability has been resolved:  s390/vfio_ccw: Ensure first IDAW remains constant  The first IDAW in a list does not need to be on a 2K/4K boundary like all others, and so is read separately to accurately calculate the size of the buffer needed to read the full IDAL.  Verify that the address found in the first IDAW is unchanged between reads, to ensure a consistent set of IDAWs being worked with.

CVE-2026-80554:

        In the Linux kernel, the following vulnerability has been resolved:  s390/vfio_ccw: Limit the number of channel program segments  The processing of channel programs, and the CCWs within them, is done recursively. As such, there is an arbitrary (but not architectural) limit to the number of CCWs that can exist in a single channel program.  The vfio-ccw logic breaks these channel programs into segments whenever it encounters a Transfer-In-Channel (TIC) CCW, and the combined number of segments count towards the global limit. Impose an equivalent limit to the number of segments until such logic can be made non-recursive.

CVE-2026-80556:

        In the Linux kernel, the following vulnerability has been resolved:  mmc: atmel-mci: Fix use-after-free in atmci_remove due to race condition  In atmci_probe, &host->bh_work is bound with atmci_work_func, and atmci_interrupt, atmci_timeout_timer and atmci_dma_complete can all queue this work on system_bh_wq.  If we remove the module, atmci_remove makes cleanup and the memory allocated for host with devm_kzalloc() is released after the remove callback returns, while the work mentioned above may still be pending or running. The sequence of operations that may lead to a UAF bug is as follows:  CPU0                                      CPU1                                            | atmci_interrupt                                           | queue_work(system_bh_wq,                                           |            &host->bh_work) atmci_remove                              | atmci_cleanup_slot(...)                   | atmci_writel(host, ATMCI_IDR, ~0UL)       | timer_delete_sync(&host->timer)           | dma_release_channel(host->dma.chan)       | free_irq(platform_get_irq(pdev, 0), host) |                                           | atmci_work_func                                           | // use host // devm resources released after          | // remove returns, host is freed          |                                           | // use host (use-after-free)  Fix it by canceling the work after all the sources that can schedule it (IRQ handler, timeout timer and DMA completion callback) have been stopped, and before proceeding with the remaining cleanup in atmci_remove.

CVE-2026-80576:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu: reject oversized IBs with per-ring packet limits  On GFX rings, amdgpu_cs_p2_ib() passed user-supplied ib_bytes through to ib->length_dw without a limit, while ring_emit_ib() encodes length into packet fields. Oversized values can corrupt adjacent control bits and destabilize command submission.  Add a per-ring IB packet size limit helper and reject command submissions exceeding the corresponding dword limit before IB allocation. Use the documented 20-bit limit for GFX/compute/SDMA/VPE, and apply the MM fallback limit for other ring types.  (cherry picked from commit 7f48fa2cf62e3fa6c9c3870aa74988f773247e52)

CVE-2026-80579:

        In the Linux kernel, the following vulnerability has been resolved:  fbdev: clear fb_info->mode before deleting a videomode  fb_set_var() can delete a mode from info->modelist when userspace passes FB_ACTIVATE_INV_MODE through FBIOPUT_VSCREENINFO. The code checks that the mode being deleted is not the current info->var and that fbcon is not using it, but it does not check fb_info->mode.  fb_info->mode may still point into the modelist entry being deleted. If the entry is freed, later mode sysfs reads through show_mode() can dereference a stale pointer.  Clear fb_info->mode before calling fb_delete_videomode() when it matches the mode being removed.

CVE-2026-80580:

        In the Linux kernel, the following vulnerability has been resolved:  fbdev: bound mode sysfs output to the sysfs buffer  mode_string() uses snprintf() which can return a value larger than the remaining buffer space. show_modes() accumulates the return value into i without checking whether i has reached PAGE_SIZE, causing the offset to advance past the sysfs buffer if the modelist is long enough.  Add a size parameter to mode_string() and use scnprintf() to return only the bytes actually written. Add an early return when offset already exceeds the buffer. In show_modes(), stop accumulating once the buffer is full.

CVE-2026-80587:

        In the Linux kernel, the following vulnerability has been resolved:  mptcp: avoid combining some incoming suboptions  Some MPTCP suboptions are mutually exclusive according to the RFC8684, but also because in different places, the code doesn't expect some combinations to be present. That's specially true for suboptions that would be present twice, but with different attributes.  The new restrictions are the same as the ones applied on the output side, with mptcp_write_options. The same rules can be reused with a small fix: an MP_FASTCLOSE can be used with a DSS when the sender picks this option [1], which is not the case on Linux. Here are the rules:    Which options can be used together?    X: mutually exclusive   O: often used together   C: can be used together in some cases   P: could be used together but we prefer not to (optimisations)    | Opt: | MPC  | MPJ  | DSS  | ADD  |  RM  | PRIO | FAIL |  FC  |   |------|------|------|------|------|------|------|------|------|   | MPC  |------|------|------|------|------|------|------|------|   | MPJ  |  X   |------|------|------|------|------|------|------|   | DSS  |  X   |  X   |------|------|------|------|------|------|   | ADD  |  X   |  X   |  P   |------|------|------|------|------|   | RM   |  C   |  C   |  C   |  P   |------|------|------|------|   | PRIO |  X   |  C   |  C   |  C   |  C   |------|------|------|   | FAIL |  X   |  X   |  C   |  X   |  X   |  X   |------|------|   | FC   |  X   |  X   |  P   |  X   |  X   |  X   |  X   |------|   | RST  |  X   |  X   |  X   |  X   |  X   |  X   |  O   |  O   |   |------|------|------|------|------|------|------|------|------|  The only difference is with the 'P': another stack could send and ADD_ADDR with other suboptions (DSS, RM_ADDR), and this should be allowed.  A few points of attention:   - In theory, an MP_CAPABLE could be used with a RM_ADDR, but there is    no reason to add it with a SYN. Note that even with a 4th ACK, it    doesn't seem to be useful, except when IDs are known in advance via    another channel. Better not to break that.   - Now, combining both an MP_CAPABLE and an MP_JOIN will no longer    result to a reject of the two options, but only the second suboption    is ignored. That seems OK to do that for this unexpected error. At    least now all inconsistent combinations are handled the same way.    This could change later in next. This also means the explicit checks    for having both MPC + MPJ in subflow.c will now be unreachable.    That's fine, they will be removed in a follow-up patch.   - In case of conflicting combinations, the extra suboption(s) is/are    ignored: having such combinations either means the remote peer is    buggy, or is evil. The simplest action is then taken in this case:    stop processing the current suboption.   - In mp_opt->suboptions, there is also a bit reserved to the checksum,    which can be used in an MP_CAPABLE and a DSS. Each time a DSS option    can be used in parallel with another option, the checksum can be set,    so the verification is combined into a new OPTIONS_MPTCP_DSS macro.   - An MP_CAPABLE ACK can carry a Data-Level Length, and an optional    Checksum: they are the same as the ones found in a DSS, because a DSS    cannot be used in parallel to an MP_CAPABLE. Similarly, even if there    is room, a DSS cannot be used with an MP_JOIN.

CVE-2026-80602:

        In the Linux kernel, the following vulnerability has been resolved:  perf/x86/amd/lbr: Fix kernel address leakage  A user-only branch stack can contain branches that originate from the kernel. As a result, kernel addresses are exposed to user space even when PERF_SAMPLE_BRANCH_USER is requested. On AMD processors supporting X86_FEATURE_AMD_LBR_V2, perf can still report SYSRET/ERET entries for which the branch-from addresses are in the kernel.  E.g.    $ perf record -e cycles -o - -j any,save_type,u -- \         perf bench syscall basic --loop 1000 | \         perf script -i - -F brstack|tr ' ' '\n'| \         grep -E '0x[89a-f][0-9a-f]{15}'    ...   0xffffffff81001268/0x717a90a38f1a/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH   0xffffffff81001268/0x717a90a39157/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH   0xffffffff81001268/0x717a90a2c628/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH   0xffffffff81001268/0x717a90a41b60/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH   0xffffffff81001268/0x717a90a260db/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH   0xffffffff81001268/0x717a90a260db/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH   0xffffffff81001268/0x717a8bef1c30/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH   0xffffffff81001268/0x717a8e4d3c90/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH   ...  The reason is that the hardware filter only considers the privilege level applicable to the branch target. Extend software filtering to also validate the branch-from addresses against br_sel, so that any branch record whose branch-from address is in the kernel is dropped when PERF_SAMPLE_BRANCH_USER is requested.

CVE-2026-80611:

        In the Linux kernel, the following vulnerability has been resolved:  ACPI: processor_idle: Mark LPI enter functions as __cpuidle  When function tracing or Kprobes is enabled, entering an ACPI Low Power Idle (LPI) state triggers the following RCU splat:    RCU not on for: acpi_idle_lpi_enter+0x4/0xd8   WARNING: CPU: 8 PID: 0 at include/linux/trace_recursion.h:162 function_trace_call+0x1e8/0x228  The acpi_idle_lpi_enter() function is invoked within the cpuidle path after RCU has already been disabled for the current local CPU. Consequently, ftrace's function_trace_call() expects RCU to be actively watching before recording trace data, emitting a warning if it is not.  Fix this by annotating acpi_idle_lpi_enter(), the generic __weak stub, and the RISC-V implementation of acpi_processor_ffh_lpi_enter() with __cpuidle. This moves these functions into the '.cpuidle.text' section, implicitly disabling ftrace instrumentation (notrace) along this sensitive path and preventing trace-induced RCU warnings during idle entry.

CVE-2026-80616:

        In the Linux kernel, the following vulnerability has been resolved:  ieee802154: Avoid calling WARN_ON() on -ENOMEM in cfg802154_switch_netns()  It's pointless to call WARN_ON() in case of an allocation failure in dev_change_net_namespace() and device_rename(), since it only leads to useless splats caused by deliberate fault injections, so avoid it.  Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

CVE-2026-80623:

        In the Linux kernel, the following vulnerability has been resolved:  coresight: ete: Always save state on power down  System register ETMs and ETE are unlikely to be preserved on CPU power down. The ETE DT binding also never documented "arm,coresight-loses-context-with-cpu" so nobody would have legitimately been able to use that binding to fix it and ACPI has no such binding at all.  Fix it by hard coding the setting for sysreg ETMs (ETE is always sysreg) or ACPI boots. Use a local variable when setting up save_state so that it's immune to concurrent probing when devices have different configurations which is an issue with modifying the global.  This fixes the following error when using Coresight with ACPI on the FVP which supports CPU PM:    coresight ete0: External agent took claim tag   WARNING: drivers/hwtracing/coresight/coresight-core.c:248 at coresight_disclaim_device_unlocked+0xe0/0xe8, CPU#0: perf/117

CVE-2026-80628:

        In the Linux kernel, the following vulnerability has been resolved:  ALSA: seq: oss: Serialize readq reset state with q->lock  snd_seq_oss_readq_clear() resets qlen, head, and tail without q->lock even though the normal reader and producer paths serialize the same ring state under that spinlock. A reset can therefore race snd_seq_oss_readq_free() or snd_seq_oss_readq_put_event() and leave stale records in the queue, drop freshly queued ones, or report the wrong readiness after wakeup. KCSAN reports a data race between snd_seq_oss_readq_clear() and snd_seq_oss_readq_free().  Take q->lock while clearing the ring and resetting input_time. Factor the enqueue logic into a caller-locked helper so snd_seq_oss_readq_put_timestamp() updates its suppression state under the same lock instead of racing the reset path.  The buggy scenario involves two paths, with each column showing the order within that path:  reset path:                      locked readq updater: 1. snd_seq_oss_reset() or        1. A reader or callback producer    release reaches                  takes q->lock on the same queue.    snd_seq_oss_readq_clear(). 2. snd_seq_oss_readq_clear()     2. The updater tests or modifies    resets qlen, head, tail,         qlen, head, and tail.    and input_time. 3. snd_seq_oss_readq_clear()     3. The updater completes its    wakes sleepers on                read-modify-write sequence.    q->midi_sleep. 4. Without q->lock, the reset    4. The resulting ring state drives    can overlap the locked           later reads and readiness.    update.  KCSAN reports:  BUG: KCSAN: data-race in snd_seq_oss_readq_clear / snd_seq_oss_readq_free  write to 0xffff8881069fe608 of 4 bytes by task 120516 on cpu 0:   snd_seq_oss_readq_free+0x6c/0x80   snd_seq_oss_read+0xcb/0x250   odev_read+0x38/0x60   vfs_read+0xff/0x600   ksys_read+0xb4/0x140   __x64_sys_read+0x46/0x60   do_syscall_64+0xbb/0x2f0   entry_SYSCALL_64_after_hwframe+0x77/0x7f  read to 0xffff8881069fe608 of 4 bytes by task 120517 on cpu 1:   snd_seq_oss_readq_clear+0x1f/0x90   snd_seq_oss_reset+0xa7/0xf0   snd_seq_oss_ioctl+0x6f6/0x7e0   odev_ioctl+0x56/0xc0   __x64_sys_ioctl+0xd1/0x120   do_syscall_64+0xbb/0x2f0   entry_SYSCALL_64_after_hwframe+0x77/0x7f  value changed: 0x00000001 -> 0x00000000

CVE-2026-80629:

        In the Linux kernel, the following vulnerability has been resolved:  octeontx2-af: npc: Fix size of entry2cntr_map  KASAN prints below splat. This is caused by allocating counter for reserved mcam entry for cpt 2nd pass entry. But mcam->entry2cntr_map is not allocated for reserved entries.  BUG: KASAN: slab-out-of-bounds in npc_map_mcam_entry_and_cntr+0xb0/0x1a0 Write of size 2 at addr ffff0001033e7ffe by task kworker/0:1/14  CPU: 0 PID: 14 Comm: kworker/0:1 Not tainted 6.1.67 #1 Hardware name: Marvell CN106XX board (DT) Workqueue: events work_for_cpu_fn Call trace:  dump_backtrace.part.0+0xe4/0xf0  show_stack+0x18/0x30  dump_stack_lvl+0x88/0xb4  print_report+0x154/0x458  kasan_report+0xb8/0x194  __asan_store2+0x7c/0xa0  npc_map_mcam_entry_and_cntr+0xb0/0x1a0  rvu_mbox_handler_npc_mcam_write_entry+0x268/0x280  npc_install_flow+0x840/0xfe0  rvu_npc_install_cpt_pass2_entry+0x138/0x190  rvu_nix_init+0x148c/0x2880  rvu_probe+0x1800/0x30b0  local_pci_probe+0x78/0xe0  work_for_cpu_fn+0x30/0x50  process_one_work+0x4cc/0x97c  worker_thread+0x360/0x630  kthread+0x1a0/0x1b0  ret_from_fork+0x10/0x20

CVE-2026-80631:

        In the Linux kernel, the following vulnerability has been resolved:  btrfs: lzo: reject compressed segment that overflows the compressed input  lzo_decompress_bio() validates each on-disk segment length seg_len only against the workspace cbuf size, not against the compressed input size (compressed_len, the total folio bytes of the bio).  A crafted extent can carry a segment whose seg_len passes the cbuf check but runs past the end of the bio, so copy_compressed_segment() walks off the last folio: get_current_folio() then returns the NULL folio from bio_next_folio(), and with CONFIG_BTRFS_ASSERT disabled (default) folio_size(NULL) faults.   BUG: KASAN: null-ptr-deref in lzo_decompress_bio (fs/btrfs/lzo.c:383)  Read of size 8 at addr 0000000000000000 by task kworker/u8:1/29  Workqueue: btrfs-endio simple_end_io_work   kasan_report (mm/kasan/report.c:590)   lzo_decompress_bio (fs/btrfs/lzo.c:383)   end_bbio_compressed_read (fs/btrfs/compression.c:1065)   btrfs_bio_end_io (fs/btrfs/bio.c:135)   btrfs_check_read_bio (fs/btrfs/bio.c:180 fs/btrfs/bio.c:285)   simple_end_io_work   process_one_work   worker_thread  Reject any segment whose payload would extend beyond compressed_len before copying it, treating it as corruption like the other on-disk validation failures in this function.

CVE-2026-80634:

        In the Linux kernel, the following vulnerability has been resolved:  netfilter: flowtable: avoid num_encaps underflow on bridge VLAN untag  The DEV_PATH_BR_VLAN_UNTAG case post-decrements info->num_encaps inside WARN_ON_ONCE(). num_encaps is u8, so if it's already 0 the decrement still happens and wraps it to 255. The break only leaves the inner switch -- a later path entry can set info->indev back to a real device, and we end up returning with num_encaps == 255.  nft_dev_forward_path() then walks info.encap[] (size 2) up to num_encaps, which means an OOB stack read and a bogus count copied into the route descriptor.  Should only happen on a malformed bridge path stack, hence the WARN, but worth handling sanely. Move the decrement out of the WARN.  [ While at this, remove the WARN_ON_ONCE since this can only happen   with a buggy bridge path stack --pablo ].

CVE-2026-80636:

        In the Linux kernel, the following vulnerability has been resolved:  netfilter: conntrack: revert ct extension genid infrastructure  This infrastructure is not used anymore after moving ct timeout and helper to use datapath refcount to track object use.  Revert commit c56716c69ce1 ("netfilter: extensions: introduce extension genid count") this patch disables all ct extensions (leading to NULL) for unconfirmed conntracks, when this is only targeted at ct helper and ct timeout. There is also codebase that dereferences the ct extension without checking for NULL which could lead to crash.

CVE-2026-80637:

        In the Linux kernel, the following vulnerability has been resolved:  netfilter: synproxy: fix unaligned memory access in timestamp adjustment  Use get_unaligned_be32() and put_unaligned_be32() to safely read and write the timestamp fields. This prevents performance degradation due to unaligned memory access or even a crash on strict alignment architectures.  This follows the implementation of timestamp parsing in the networking stack at tcp_parse_options() and synproxy_parse_options().

CVE-2026-80643:

        In the Linux kernel, the following vulnerability has been resolved:  EDAC/igen6: Fix call trace due to missing release()  When unloading the igen6_edac driver, there is a call trace:    Device '(null)' does not have a release() function, it is broken and must be fixed.   See Documentation/core-api/kobject.rst.   WARNING: drivers/base/core.c:2567 at device_release+0x84/0x90, CPU#5: rmmod/127209   ...   RIP: 0010:device_release+0x84/0x90   Call Trace:    <TASK>    kobject_put+0x8c/0x220    put_device+0x17/0x30    igen6_unregister_mcis+0xa2/0xe0 [igen6_edac]    igen6_remove+0x82/0xb0 [igen6_edac]    ...  Fix the call trace by providing empty release() functions for the memory controller devices.

CVE-2026-80650:

        In the Linux kernel, the following vulnerability has been resolved:  media: atomisp: gc2235: fix UAF and memory leak  gc2235_probe() handles its error paths incorrectly.  If media_entity_pads_init() fails, gc2235_remove() is called, which tears down the subdev and frees dev, but then still falls through to atomisp_register_i2c_module(). This results in use-after-free.  If atomisp_register_i2c_module() fails, the media entity and control handler are left initialized and dev is leaked.  gc2235_remove() unconditionally calls media_entity_cleanup() and v4l2_ctrl_handler_free(), but these are not initialized at every error path in gc2235_probe().  Replace gc2235_remove() calls in the probe error paths with explicit unwind labels that free only the resources initialized at each point of failure, in reverse order of initialization.

CVE-2026-80653:

        In the Linux kernel, the following vulnerability has been resolved:  scsi: hisi_sas: Add slave_destroy interface for v3 hw  WARNING is triggered when executing link reset of remote PHY and rmmod SAS driver simultaneously. Following is the WARNING log:  WARNING: CPU: 61 PID: 21818 at drivers/base/core.c:1347 __device_links_no_driver+0xb4/0xc0  Call trace:   __device_links_no_driver+0xb4/0xc0   device_links_driver_cleanup+0xb0/0xfc   __device_release_driver+0x198/0x23c   device_release_driver+0x38/0x50   bus_remove_device+0x130/0x140   device_del+0x184/0x434   __scsi_remove_device+0x118/0x150   scsi_remove_target+0x1bc/0x240   sas_rphy_remove+0x90/0x94   sas_rphy_delete+0x24/0x3c   sas_destruct_devices+0x64/0xa0 [libsas]   sas_revalidate_domain+0xe4/0x150 [libsas]   process_one_work+0x1e0/0x46c   worker_thread+0x15c/0x464   kthread+0x160/0x170   ret_from_fork+0x10/0x20  ---[ end trace 71e059eb58f85d4a ]---  During SAS phy up, link->status is set to DL_STATE_AVAILABLE in device_links_driver_bound, then this setting influences __device_links_no_driver() before driver rmmod and caused WARNING.  Add the slave_destroy interface to make sure link is removed after flush workque.

CVE-2026-80654:

        In the Linux kernel, the following vulnerability has been resolved:  soc: xilinx: Shutdown and free rx mailbox channel  A mbox rx channel is requested using mbox_request_channel_byname() in probe. In remove callback, the rx mailbox channel is cleaned up when the rx_chan is NULL due to incorrect condition check. The mailbox channel is not shutdown and it can receive messages even after the device removal. This leads to use after free. Also the channel resources are not freed. Fix this by checking the rx_chan correctly.

CVE-2026-80668:

        In the Linux kernel, the following vulnerability has been resolved:  netfilter: nf_conntrack_expect: use conntrack GC to reap expectations  This patch replaces the timer API by GC worker approach for expectations, as it already happened in many other subsystems.  Use the existing conntrack GC worker to iterate over the local list of expectations in the master conntrack to reap expired expectations. Check IPS_HELPER_BIT to run GC for expectations, set it on for nft_ct expectation which nevers sets it. Hold the expectation spinlock while iterating over the master conntrack expectation list to synchronize with nf_ct_remove_expectations(). This also performs runtime packet path garbage collection through the expectation insertion and lookup functions while walking over one of the chains of the global expectation hashtables. Unconfirmed conntrack entries are skipped since ct->ext can be reallocated and dying are skipped since those will be gone soon. Set on IPS_HELPER_BIT if the helper ct extension is added, then the new GC worker does not need to bump the ct refcount to check if the ct->ext helper is available.  This removes the extra bump on the refcount for expectation timers, this allows to remove several nf_ct_expect_put() calls after the unlink, after this update only refcount remains at 1 while on the expectation hashes.  This patch implicitly addresses a race with the existing timer API allowing an expectation to access a stale exp->master pointer which has been already released when expectation removal loses races with an expiring timer, ie. timer_del() reporting false.  Add a new NF_CT_EXPECT_DEAD flag to reap this expectation via GC. This is needed by nf_conntrack_unexpect_related() which is called in error paths to invalidate newly created expectations that has been added into the hashes. These expectactions cannot be inmediately released as GC or nf_ct_remove_expectations() could race to make it. On expectation insert, the runtime GC reaps stale expectations before checking the expectation limit set by policy.  Set current timestamp in nf_ct_expect_alloc(), then add the expectation policy timeout (or custom timeout specified added on top of this) to specify the expectation lifetime.

CVE-2026-80670:

        In the Linux kernel, the following vulnerability has been resolved:  perf tools: Use perf_env__get_cpu_topology() in machine__resolve()  machine__resolve() accesses env->cpu[al->cpu].socket_id after checking al->cpu >= 0 and env->cpu != NULL, but without validating al->cpu against env->nr_cpus_avail.  Since al->cpu comes from the untrusted perf.data sample, a crafted file with a large CPU index causes an out-of-bounds heap read.  Use perf_env__get_cpu_topology() which validates both NULL and bounds. Also bounds-check al->cpu before the cast to struct perf_cpu (int16_t): without this, values like 65536 silently truncate to 0, bypassing the accessor's internal check and returning CPU 0's topology.

CVE-2026-80676:

        In the Linux kernel, the following vulnerability has been resolved:  Drivers: hv: vmbus: use generic driver_override infrastructure  When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF.  Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally.  Note that calling match() from __driver_attach() without the device lock held is intentional. [1]

CVE-2026-80694:

        In the Linux kernel, the following vulnerability has been resolved:  net: ethernet: mtk_eth_soc: pass eth to mtk_handle_irq_rx in poll_controller  mtk_handle_irq_rx expects a struct mtk_eth * (matching the request_irq cookie), but mtk_poll_controller incorrectly passed the net_device *. Calling ndo_poll_controller with CONFIG_NET_POLL_CONTROLLER enabled would then crash.

CVE-2026-80695:

        In the Linux kernel, the following vulnerability has been resolved:  hwmon: (sht3x) Fix unaligned accesses  Sashiko reports:  In sht3x_update_client(), the 16-bit temperature and humidity values are extracted from a stack-allocated byte array using be16_to_cpup(). The pointers passed to this function are calculated as buf and buf + 3. Since the difference between the two pointers is an odd number of bytes, at least one of them is guaranteed to be at an unaligned offset.  This will trigger an alignment fault on strict-alignment architectures such as ARMv5 or SPARC, resulting in a kernel panic.  Fix the problem by using get_unaligned_be16() instead of be16_to_cpup(), and put_unaligned_be16() instead of cpu_to_be16().

CVE-2026-80698:

        In the Linux kernel, the following vulnerability has been resolved:  dmaengine: idxd: fix double free of wq, engine, and group structs  The release callbacks for wq, engine, and group devices (idxd_conf_wq_release, idxd_conf_engine_release, idxd_conf_group_release) each call kfree() on the enclosing struct. The setup error paths and cleanup functions also call kfree() explicitly after put_device(), producing a double free whenever put_device() drops the reference count to zero and fires the release.  In the setup functions, device_initialize() is called before device_add(), so the reference count is exactly 1 at the error sites. put_device() unconditionally fires the release, which frees the struct; the subsequent explicit kfree() then operates on freed memory.  For idxd_setup_wqs(), the wq release callback also owns opcap_bmap and wqcfg. The error unwind additionally freed those fields explicitly before calling put_device(), causing further double frees on both.  Remove the redundant explicit kfree() calls from all setup error paths and cleanup functions for wq, engine, and group structs, delegating sole ownership of those allocations to the release callbacks.

CVE-2026-80704:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: use proper context for logging  The same as the rest of the code, get_ss_info_from_atombios() uses calc_pll_cs->ctx->logger for logging. But calc_pll_cs->ctx is initialized only later in calc_pll_max_vco_construct(). Therefore, any output using DC_LOG_SYNC() leads to a NULL pointer deference in get_ss_info_from_atombios().  According to Sashiko, the very same problem exists in dce112_get_pix_clk_dividers() and dcn3_get_pix_clk_dividers() too.  To avoid accessing the NULL context, use clk_src->base.ctx->logger everywhere. That context in base is initialized earlier in dce110_clk_src_construct() and dce112_clk_src_construct(). Before get_ss_info_from_atombios() or Sashiko's get_pix_clk_dividers functions above are actually called. This is done by redefining DC_LOGGER to CTX->logger.  Before: dce110_clk_src_construct() did:  -> sets clk_src->base.ctx = ctx;  -> ss_info_from_atombios_create()    -> get_ss_info_from_atombios()   <- uses calc_pll_cs->ctx  # BOOM  -> calc_pll_max_vco_construct()    <- sets calc_pll_cs->ctx  After: dce110_clk_src_construct() does:  -> sets clk_src->base.ctx = ctx;  -> ss_info_from_atombios_create()    -> get_ss_info_from_atombios()   <- uses clk_src->base.ctx  (cherry picked from commit 6f16fcbb0c46a87e3d9685407e906573d60104b0)

CVE-2026-80710:

        In the Linux kernel, the following vulnerability has been resolved:  s390/dasd: Fix undersized format-check buffer  fmt_buffer_size in dasd_eckd_check_device_format() is declared as int, even though one of the multiplicands, sizeof(struct eckd_count), is a size_t. The expression      trkcount * rpt_max * sizeof(struct eckd_count)  is therefore correctly evaluated at 64-bit width, but the result is silently truncated when it is stored back into the 32-bit fmt_buffer_size variable. For a sufficiently large track range (start_unit/stop_unit are caller-controlled) this truncation yields a buffer size far smaller than the number of tracks actually requested. kzalloc() then succeeds with an undersized allocation, while the subsequent channel program build still operates on the untruncated track count and writes past the end of that buffer.  Compute the buffer size with check_mul_overflow() and keep it in a size_t, so that a value that no longer fits results in -EINVAL instead of a silently truncated allocation size.

CVE-2026-80738:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: Check sk_state before sk_protocol in bpf_tcp_*_syncookie  bpf_tcp_gen_syncookie and bpf_tcp_check_syncookie accept a socket pointer 'sk' with argument type ARG_PTR_TO_BTF_ID_SOCK_COMMON. However, they access sk->sk_protocol without validating whether 'sk' represents a full socket.  Fix this issue by checking sk->sk_state != TCP_LISTEN before inspecting sk->sk_protocol in both bpf_tcp_gen_syncookie and bpf_tcp_check_syncookie. Since mini-sockets are never in the TCP_LISTEN state, the condition short-circuits and prevents dereferencing fullsock-specific fields.

CVE-2026-80739:

        In the Linux kernel, the following vulnerability has been resolved:  net/mlx5e: TC, Check if flow is PEER before acquiring devcom lock  In case __mlx5e_add_fdb_flow() fails in lower levels, the flow is deleted via mlx5e_tc_del_flow(), and mlx5e_tc_del_flow() is acquiring ESW devcom lock without condition. In addition, in case of peer_flow, __mlx5e_add_fdb_flow() is called while holding ESW devcom comp lock. This results in an AA deadlock.  To fix this, introduce a new PEER flag that is set on flows created as peer flows (the duplicate flows on peer devices), and check it in mlx5e_tc_del_flow() before acquiring ESW devcom lock.  Lockdep splat: ============================================ WARNING: possible recursive locking detected ============================================  Possible unsafe locking scenario:        CPU0        ----   lock(&comp->lock_key#2);   lock(&comp->lock_key#2);  *** DEADLOCK *** Call Trace:  <TASK>  dump_stack_lvl+0x69/0xa0  print_deadlock_bug.cold+0xbd/0xca  __lock_acquire+0x1671/0x2ec0  lock_acquire+0x10e/0x2e0  down_read+0x95/0x430  mlx5_devcom_for_each_peer_begin+0x4e/0xe0 [mlx5_core]  mlx5e_tc_del_flow+0x11d/0xa70 [mlx5_core]  mlx5e_flow_put+0x99/0x100 [mlx5_core]  __mlx5e_add_fdb_flow+0x409/0xf00 [mlx5_core]  mlx5e_configure_flower+0x2a86/0x4100 [mlx5_core]  mlx5e_rep_setup_tc_cls_flower+0x12f/0x1b0 [mlx5_core]  mlx5e_rep_setup_tc_cb+0x153/0x750 [mlx5_core]  tc_setup_cb_add+0x1dc/0x470  fl_change+0x2f4d/0x626d [cls_flower]  tc_new_tfilter+0x79b/0x2310  rtnetlink_rcv_msg+0x778/0xad0  do_syscall_64+0x70/0x960  entry_SYSCALL_64_after_hwframe+0x4b/0x53  </TASK>

CVE-2026-80747:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdkfd: Add bounds check for CRAT subtype length  The CRAT parser validates that the subtype header fits within the image, but does not verify that the advertised subtype length fits. A malformed CRAT table with an oversized length field causes out-of-bounds reads when kfd_parse_subtype() casts the header to specific subtype structures.  Add validation that sub_type_hdr + length does not exceed the image boundary before parsing the subtype contents.  (cherry picked from commit 48e1d1e6e8798aef0312e68d8e586021b5b3cf4d)

CVE-2026-80755:

        In the Linux kernel, the following vulnerability has been resolved:  selinux: reject a permission value exceeding the class permission count  perm_read() bounds a permission value by SEL_VEC_MAX but never by the nprim of the owning class or common, which is taken verbatim from the policy image.  security_get_permissions() then writes perms[value - 1] into an nprim-sized kcalloc() array, so a class declaring fewer permissions than its largest permission value drives an out-of-bounds heap write.  The top-level symbol tables are validated this way; the nested per-class permission table is not.  Reject a permission whose value exceeds nprim, which is already set when perm_read() runs.  Well-formed policies are unaffected.  [PM: tweak comment for line length]

CVE-2026-80761:

        In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: ISO: zero the sockaddr before returning it in getname  iso_sock_getname() fills a struct sockaddr_iso in place and returns its size without clearing it first, so bytes it does not write are copied to user space from the kernel stack. The getsockname(2) and getpeername(2) paths both run through do_getsockname(), which hands getname() an uninitialized sockaddr_storage on the stack and copies back up to the number of bytes getname() returns, so the driver has to initialize every byte it accounts for.  Two ranges are left uninitialized:    - struct sockaddr_iso is 10 bytes but only 9 are written (family,     iso_bdaddr, iso_bdaddr_type), leaking the trailing pad byte on every     call.    - for a broadcast peer (BIS_LINK or PA_LINK) the returned length grows     by sizeof(struct sockaddr_iso_bc), but only bc_sid, bc_num_bis and     bc_bis are filled; bc_bdaddr and bc_bdaddr_type, the first 7 bytes of     that structure, are never written.  An unprivileged process can open a BTPROTO_ISO socket and reach the pad leak with getsockname(); the broadcast leak needs an established BIS/PA connection. l2cap and rfcomm already memset their sockaddr in getname for the same reason; do the same here.

CVE-2026-80771:

        In the Linux kernel, the following vulnerability has been resolved:  HID: nintendo: register input device after capabilities are set  input_register_device() exposes the device to userspace immediately. In joycon_input_create() it was called before joycon_config_rumble() configures the FF_RUMBLE capability and the memless force-feedback device, so a concurrent EVIOCSFF could dereference a NULL dev->ff.  Registering early also means the initial udev event lacks button and axis information, which can make input managers ignore the device.  Move input_register_device() to the end of joycon_input_create(), after all capabilities, the IMU input device and the force-feedback callbacks have been configured.

CVE-2026-80785:

        In the Linux kernel, the following vulnerability has been resolved:  fbdev: serialize mode sysfs access with lock_fb_info()  show_mode(), show_modes(), and store_mode() access fb_info->modelist and fb_info->mode without holding lock_fb_info(). store_modes() takes lock_fb_info() while replacing the modelist and freeing the old one.  A concurrent reader or writer can load a pointer to an old modelist entry before store_modes() frees it, then dereference freed memory or store a stale freed pointer in fb_info->mode.  Take lock_fb_info() in show_mode(), show_modes(), and store_mode() to serialize with store_modes(). In show_mode(), copy the mode to the stack and format after dropping the lock. In store_mode(), split activate() into a _locked variant to avoid double-locking, and hold the locks for the modelist walk, mode conversion, activation, and fb_info->mode assignment together.

CVE-2026-80786:

        In the Linux kernel, the following vulnerability has been resolved:  fbdev: Wrap user-invoked calls to fb_set_var() in helper  Handle fbcon during display updates in fb_set_var_from_user(). Check with fbcon if the mode change is possible, update hardware state and finally update fbcon. Update all callers.  Only the FBIOPUT_VSCREENINFO ioctl currently does all steps. Other mode-changes callers in sysfs and driver code are missing fbcon-related steps.  With the new helper, ps3fb and sh_mobile_lcdcfb no longer maintain fbcon state themselves.

CVE-2026-80820:

        In the Linux kernel, the following vulnerability has been resolved:  xfs: don't livelock in scrub on a circular unlinked list  LOLLM points out that online fsck can livelock if an unlinked inode list contains a loop.  Use a bitmap to detect cycles.

CVE-2026-80836:

        In the Linux kernel, the following vulnerability has been resolved:  crypto: virtio - bound the akcipher result length  virtio_crypto_dataq_akcipher_callback() sets the result length from the device-reported response length without bounding it to the destination buffer, which was allocated for the original request length. sg_copy_from_buffer() then reads that many bytes from the destination buffer; a backend reporting a larger length over-reads adjacent kernel heap into the caller's scatterlist (an out-of-bounds read).  Clamp the reported length to the originally requested destination length. A conforming device reports no more than that, so valid results are unaffected.

CVE-2026-80837:

        In the Linux kernel, the following vulnerability has been resolved:  netfilter: nf_tables: don't queue packet path object notifications  All file:line references below are against v7.2-rc4 (ac5b0e5651b1). The trace was captured on 7.2.0-rc6-kasan72rc6 (075b74841bd0), where the same lines apply.  nft_obj_notify() is exported and reached from the packet path. Its only in-tree caller is nft_quota_obj_eval() (net/netfilter/nft_quota.c:68), which notifies with GFP_ATOMIC while evaluating a rule for a transiting packet, holding no mutex.  Since commit 67cc570edaa0 ("netfilter: nf_tables: coalesce multiple notifications into one skbuff") that notification is no longer sent immediately. __nft_obj_notify() queues it onto nft_net->notify_list via nft_notify_enqueue() (net/netfilter/nf_tables_api.c:1211), which is a bare list_add_tail(). notify_list has no lock of its own (include/net/netfilter/nf_tables.h:1951), it is serialised by commit_mutex: the six other enqueue sites all run inside a netlink transaction, and the drain in nft_commit_notify() (net/netfilter/nf_tables_api.c:10746) does list_del() + kfree_skb() from nf_tables_commit() with commit_mutex held.  Sending packets through a chain that references a depleted quota object therefore races an unlocked list_add_tail() against list_del() + kfree_skb() on another CPU. The WRITE_ONCE(prev->next, new) in __list_add() then stores through an sk_buff that has already been freed:    BUG: KASAN: slab-use-after-free in __nft_obj_notify+0x2c5/0x2d0   Write of size 8 at addr ff110001047183c0 by task poc/76   CPU: 0 UID: 1000 PID: 76 Comm: poc Tainted: G  W  7.2.0-rc6-kasan72rc6 #4   Call Trace:    <IRQ>    __nft_obj_notify (include/linux/list.h:164 include/linux/list.h:191                      net/netfilter/nf_tables_api.c:1211                      net/netfilter/nf_tables_api.c:8743)    nft_quota_obj_eval (net/netfilter/nft_quota.c:68)    nft_do_chain_inet    nf_hook_slow    __ip_local_out    ip_push_pending_frames    udp_send_skb    udp_sendmsg    __x64_sys_sendto    Allocated by task 77:    __alloc_skb (net/core/skbuff.c:704)    __nft_obj_notify (include/net/netlink.h:1055                      net/netfilter/nf_tables_api.c:8731)    nft_quota_obj_eval (net/netfilter/nft_quota.c:68)    nft_do_chain    Freed by task 79:    nf_tables_commit (include/linux/skbuff.h:1332                      net/netfilter/nf_tables_api.c:10759                      net/netfilter/nf_tables_api.c:11185)    nfnetlink_rcv_batch (net/netfilter/nfnetlink.c:574)    netlink_unicast    netlink_sendmsg    The buggy address belongs to the cache skbuff_head_cache of size 232  Queueing from the packet path is wrong even leaving the race aside: notify_list is only drained by nft_commit_notify() from nf_tables_commit() (:11185), so a notification enqueued outside a transaction is not sent until some later netlink batch commits, if one ever does.  The gfp argument that nft_obj_notify() still takes is a leftover of the pre-67cc570edaa0 behaviour, where this path called nfnetlink_send() directly. Restore that: split the message construction out into nft_obj_notify_alloc() and let each caller decide what to do with the skb. nft_obj_notify(), the exported one reached from the packet path, sends it straight away; nf_tables_obj_notify(), which runs under commit_mutex, keeps queueing it, so transaction notifications are still coalesced.

CVE-2026-80841:

        In the Linux kernel, the following vulnerability has been resolved:  net/packet: defer vmalloc TX_RING free until skbs finish  AF_PACKET TX_RING skbs keep a raw pointer to their ring frame. The skb page references preserve page-backed ring blocks after pg_vec is freed, but they do not preserve a vmalloc mapping.  tpacket_destruct_skb() currently drops the pending reference before writing the timestamp and TP_STATUS_AVAILABLE to the frame. Move the decrement after those stores. The smp_wmb() in __packet_set_status() orders the frame stores before the decrement.  Also recheck pending TX frames under pg_vec_lock before non-closing ring replacement, so a racing send cannot add a pending skb between the initial check and the ring swap.  Ring allocation can produce a mixture of page-backed and vmalloc-backed blocks. Allocate deferred-work storage during TX ring setup when the first vmalloc-backed block is encountered, and keep its pointer in the pg_vec allocation header. If allocation fails, return -ENOMEM from ring setup. On socket close, a non-NULL pointer identifies a vmalloc-backed vector without a scan. If TX skbs remain, defer the whole vector to system_long_wq.  After pg_vec is detached, a late destructor can skip the pending decrement. Use socket write-memory accounting as the deferred lifetime gate instead: an skb remains charged through its final sock_wfree(), after all ring-frame accesses. The delayed work retains a socket reference and reschedules itself until no TX skbs remain.  Move pending_refcnt release to packet_sock_destruct() so late skb destructors and deferred cleanup can safely use it after packet_release(). Page-backed teardown remains synchronous, and no lock is added to the TX completion hot path.

CVE-2026-80847:

        In the Linux kernel, the following vulnerability has been resolved:  tcp: clamp route advmss to TCP_MIN_MSS  tcp_select_initial_window() assumes that callers never pass an MSS smaller than 1, but route-derived advmss values can violate that assumption.  A too-small explicit RTAX_ADVMSS is one way to get there, but it is not the only one. The same divide-by-zero can also be reached through the "default advmss" path when RTAX_ADVMSS is left at 0 and the effective advmss is later driven down by route MTU and min_adv_mss.  Introduce a tcp_dst_advmss() helper that clamps route advmss to TCP_MIN_MSS before TCP consumes it, and use it in the TCP paths that derive advmss from dst metrics. This keeps the effective MSS from dropping to zero before tcp_select_initial_window() rounds the receive window.

CVE-2026-80851:

        In the Linux kernel, the following vulnerability has been resolved:  gtp: serialize PDP context updates  PDP contexts can be deleted through GTP_CMD_DELPDP or while the GTP network device is being unregistered. The latter is serialized by RTNL, but the generic-netlink delete path only holds RCU.  Running both paths concurrently can therefore make both paths delete the same PDP context. The issue was found through static analysis and reproduced on a KASAN-enabled kernel by a simple two-thread program racing GTP_CMD_DELPDP against RTM_DELLINK:    Oops: general protection fault, probably for non-canonical address   KASAN: maybe wild-memory-access in range          [0xdead000000000120-0xdead000000000127]   RIP: gtp_genl_del_pdp+0x1c1/0x420 [gtp]   RBP: dead000000000122  The second deletion dereferenced the poisoned hlist pprev pointer.  Serialize gtp_pdp_add(), gtp_genl_del_pdp(), and gtp_dellink() with a shared mutex. Keep the mutex held until the final use of a PDP context in the NEWPDP path, and keep the RCU read-side section around the complete PDP context use in the DELPDP path.

CVE-2026-80861:

        In the Linux kernel, the following vulnerability has been resolved:  usb: xhci: bail out of setup if the controller is inaccessible  xhci_gen_setup() locates the operational registers using the capability length read from the very first register:  	xhci->op_regs = hcd->regs + 		HC_LENGTH(readl(&xhci->cap_regs->hc_capbase));  If the controller is dead or has dropped off the bus, that read returns ~0, HC_LENGTH() truncates it to 0xff, and op_regs ends up 0xff bytes past the page-aligned MMIO base, i.e. unaligned. The first access through it, xhci_halt() -> xhci_handshake() reading op_regs->status, is then an unaligned readl() on device memory. arm64 faults on unaligned device accesses, so instead of xhci_handshake() catching the all-ones value and returning -ENODEV, setup oopses:    xhci-pci-renesas 0005:08:00.0: Unable to change power state from D3cold to D0, device inaccessible   xhci-pci-renesas 0005:08:00.0: xHCI Host Controller   xhci-pci-renesas 0005:08:00.0: new USB bus registered, assigned bus number 1   Unable to handle kernel paging request at virtual address ffff80030a770103     ESR = 0x0000000096000021     FSC = 0x21: alignment fault   Internal error: Oops: 0000000096000021 [#1]  SMP   pc : xhci_halt [xhci_hcd]   Call trace:    xhci_halt    xhci_gen_setup    xhci_pci_setup    usb_add_hcd    usb_hcd_pci_probe    xhci_pci_common_probe    xhci_pci_renesas_probe  This was hit with a Renesas uPD720201 that failed to power up ("Unable to change power state from D3cold to D0, device inaccessible") yet still reached the HCD probe path.  Read the capability register once, and if it reads back the all-ones value (as xhci_handshake() and xhci_reset() already test for), abort setup with -ENODEV before op_regs is derived from it. Reading it once also avoids re-reading a register that may change under a concurrent hot-removal.

CVE-2026-80864:

        In the Linux kernel, the following vulnerability has been resolved:  RDMA/rxe: Fix responder UAF on IB_QP_MAX_DEST_RD_ATOMIC modify_qp  rxe_qp_from_attr() handles IB_QP_MAX_DEST_RD_ATOMIC outside the IB_QP_STATE path, so it holds no state_lock and runs while the responder task rxe_receiver() (recv_task on rxe_wq) is live. A modify_qp() setting only that attribute calls free_rd_atomic_resources() then alloc_rd_atomic_resources(), swapping qp->resp.resources[] while rxe_prepare_res()/find_resource() walk it; free_rd_atomic_resources() also leaves the cached pointer qp->resp.res dangling. A local unprivileged user can race the free/realloc into a use-after-free in rxe_receiver() (local DoS).  Drain recv_task around the swap with rxe_disable_task()/rxe_enable_task(), as rxe_qp_reset() already does when tearing this array down, re-enabling only after alloc_rd_atomic_resources() succeeds so the responder never resumes against a NULL qp->resp.resources on the ENOMEM path. Also clear qp->resp.res in free_rd_atomic_resources(), like the rxe_resp.c completion paths.  Reproduced under KASAN; the slab-use-after-free in rxe_receiver() is gone.

CVE-2026-80866:

        In the Linux kernel, the following vulnerability has been resolved:  tipc: avoid busy looping in tipc_exit_net()  Blamed commit introduced a busy-wait loop in tipc_exit_net() to wait for pending UDP bearer cleanup works to complete:         while (atomic_read(&tn->wq_count))                cond_resched();  This loop can busy-wait for a long time if cond_resched() is a NOP. This typically happens if the netns exit is executed by a high priority task, or under kernels configured without preemption (CONFIG_PREEMPT_NONE). In such cases, it wastes CPU cycles and can lead to soft lockups.  Fix this by replacing the busy loop with wait_var_event(), allowing the thread to sleep properly until the work queue count reaches zero.  Accordingly, update cleanup_bearer() to use atomic_dec_and_test() and wake_up_var() to wake up the waiter when the count drops to zero.  This uses the global wait queue hash table, avoiding the need to bloat struct tipc_net with a wait_queue_head_t. The atomic_dec_and_test() provides the necessary memory barrier to ensure the wakeup is not missed.

CVE-2026-80883:

        In the Linux kernel, the following vulnerability has been resolved:  drm/tegra: gr2d/gr3d: Initialize address register map before HOST1X client is registered  The host1x_client_register() function is called just prior to register map initialization loop, making the device available to userspace. This may result in userspace attempting to submits a job before the register map is initialized. Address this by moving register initialization before host1x client registration.

CVE-2026-80884:

        In the Linux kernel, the following vulnerability has been resolved:  ntb: Store original DMA address for future release  The DMA API requires that dma_free_attrs receive the exact dma_handle originally returned by the allocation function. Do not modify it.

CVE-2026-80905:

        In the Linux kernel, the following vulnerability has been resolved:  net: tap: fix wrong transport_header when sending VLAN-tagged frame  In tap_get_user_xdp(), when processing a VLAN-tagged frame (e.g. ETH_P_8021Q), skb_set_network_header() is called first to advance network_header past the VLAN tag to the inner protocol header. skb_probe_transport_header() is then called with skb->protocol still set to ETH_P_8021Q, while nhoff (derived from skb_network_offset()) already points past the VLAN tag to the inner protocol header.  In __skb_flow_dissect(), proto is initialized to ETH_P_8021Q and nhoff points past the VLAN tag. When the dissector hits case ETH_P_8021Q, it reads a struct vlan_hdr at the current nhoff via __skb_header_pointer(), but that offset contains the inner protocol header (e.g. an IP header). The bytes are misinterpreted as a VLAN header, yielding a garbage encapsulated EtherType that matches no known protocol. The dissector returns false, so skb_probe_transport_header() never calls skb_set_transport_header(), leaving transport_header at its uninitialized sentinel value (~0U).  Move skb_set_network_header() to after skb_probe_transport_header(). At the time skb_probe_transport_header() is called, network_header still points to the VLAN header (offset ETH_HLEN), so nhoff is correct and the flow dissector can parse the VLAN header, extract the inner EtherType, and advance nhoff to the inner protocol header, allowing transport_header to be set correctly.

CVE-2026-80907:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu: Fix UVD dpb min size calculation for H264  This should use actual number of references from the decode message, instead of maximum derived from level.  (cherry picked from commit 64b525edb7e7bdfcdc77883c5e413804e2396856)

CVE-2026-80920:

        In the Linux kernel, the following vulnerability has been resolved:  io_uring: defer eventfd signaling when queued from a wakeup handler  io_req_local_work_add() signals the CQ ring eventfd inline when it is the one to push the first entry onto ->work_list. For DEFER_TASKRUN rings that add is frequently done from a waitqueue wakeup handler, where an arbitrary waitqueue lock is held.  eventfd_signal_mask() only refuses to recurse when current->in_eventfd is set, but that bit is set by eventfd_signal_mask() itself. If the wake chain starts somewhere else, signal goes out inline and can feed back into epoll.  Add IOU_F_TWQ_IN_WAKE, set it on the task_work add done from the three waitqueue callbacks, and use it to force io_eventfd_signal() down the existing call_rcu_hurry() deferral instead of signaling inline.

CVE-2026-80925:

        In the Linux kernel, the following vulnerability has been resolved:  vlan: fix skb_under_panic and races when toggling HW VLAN offload  Toggling hardware VLAN TX offload (NETIF_F_HW_VLAN_CTAG_TX or NETIF_F_HW_VLAN_STAG_TX) on a lower device invokes vlan_transfer_features(), which dynamically changed vlandev->hard_header_len.  This causes two issues: 1. Lockless TX paths (e.g. packet_snd in af_packet.c, ip6_finish_output2)    read dev->hard_header_len without holding RTNL lock. Mutating    hard_header_len dynamically under RTNL creates a data race where upper    layers reserve insufficient headroom based on a stale hard_header_len,    resulting in skb_under_panic when vlan_dev_hard_header() is called. 2. In addition, vlan_transfer_features() updated hard_header_len without    updating header_ops, causing a mismatch between allocated headroom    and header creation.  Always setting dev->hard_header_len = real_dev->hard_header_len and dev->needed_headroom = real_dev->needed_headroom + VLAN_HLEN unconditionally ensures: - dev->hard_header_len remains 100% static and immutable at real_dev->hard_header_len,   eliminating all dynamic runtime updates and data races on hard_header_len. - Upper layers allocating skbs via LL_RESERVED_SPACE() will always reserve   sufficient headroom for software VLAN tag insertion (real_dev->hard_header_len +   real_dev->needed_headroom + VLAN_HLEN). - vlandev inherits real_dev->needed_tailroom so underlying trailer/padding/ICV   requirements are honored. - AF_PACKET SOCK_RAW network header offsets remain correctly aligned at   real_dev->hard_header_len. - vlan_header_ops is used unconditionally.  Note to stable teams: Make sure to backport these commits:  e16e960d55a4 ("ipvlan: inherit needed_headroom and needed_tailroom from phy_dev") cef51860becd ("macvlan: inherit needed_headroom and needed_tailroom from lowerdev")

CVE-2026-80937:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: mt76: mt7915: bound the device EEPROM address before the EFUSE copy  mt7915_mcu_get_eeprom() copies a fixed EFUSE block into the driver's dev->mt76.eeprom.data buffer at the offset reported by the MCU response (res->addr, a device-controlled __le32) without checking it against the buffer size. A malicious or malfunctioning device can report an arbitrary address and drive a 16-byte out-of-bounds write past eeprom.data.  Reject a response whose address would place the copy outside eeprom.data before deriving the destination pointer. Devices that echo the requested in-bounds offset are unaffected.

CVE-2026-80947:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: rtl8xxxu: fix use-after-free from rx_urb_wq on stop  rtl8xxxu arms rx_urb_wq from the RX completion path: rtl8xxxu_rx_complete() hands the URB to rtl8xxxu_queue_rx_urb(), which queues it on rx_urb_pending_list and, once the list grows past RTL8XXXU_RX_URB_PENDING_WATER, schedules rx_urb_wq.  The worker rtl8xxxu_rx_urb_work() drains rx_urb_pending_list, recovers priv through container_of, and resubmits each URB through rtl8xxxu_submit_rx_urb(), which anchors it on rx_anchor and dereferences priv->udev.  rtl8xxxu_stop() cancels the sibling work items (c2hcmd_work, ra_watchdog, update_beacon_work) but never cancels rx_urb_wq, so a worker armed during the last burst of RX traffic can run rtl8xxxu_rx_urb_work() after rtl8xxxu_disconnect() has called ieee80211_free_hw(), which frees priv, producing a use-after-free.  The window opens under active RX traffic (pending count above the watermark) followed by a disconnect.  There are two teardown races to close:    * rtl8xxxu_queue_rx_urb() decided whether to enqueue under rx_urb_lock     but called schedule_work() after dropping the lock.  A completion     that observed shutdown == false and released the lock could then call     schedule_work() after rtl8xxxu_stop() had set shutdown and     cancel_work_sync() had already returned, arming the worker to run     after the teardown.  Move schedule_work() under the same !shutdown     branch so the arming decision is atomic with the shutdown check.    * rtl8xxxu_rx_urb_work() anchors every URB it drained back onto     rx_anchor through rtl8xxxu_submit_rx_urb().  A worker still running     when usb_kill_anchored_urbs(&priv->rx_anchor) returned would submit a     URB that escaped the kill.  In rtl8xxxu_stop(), call     cancel_work_sync(&priv->rx_urb_wq) before the kill so the worker is     drained first.  After priv->shutdown is set under rx_urb_lock, completions can no longer queue rx_urb_wq. cancel_work_sync() then drains the last queued or running worker, and the following usb_kill_anchored_urbs() kills the URBs it may have submitted.  rtl8xxxu_disconnect() is covered because ieee80211_unregister_hw() guarantees .stop() runs for a live interface before ieee80211_free_hw() frees priv.  The probe error path needs no cancel: rx_urb_wq is INIT_WORK()'d there but cannot have been scheduled, since no URB is submitted before ieee80211_register_hw() succeeds.  This bug was found by static analysis.

CVE-2026-80948:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: iwlwifi: dvm: fix memory leak in iwl_op_mode_dvm_start()  In iwl_op_mode_dvm_start(), jumping to out_free_eeprom currently bypasses the out_free_eeprom_blob label. Consequently, error paths triggered after successfully parsing the EEPROM free priv->nvm_data but leak priv->eeprom_blob.  Fix this memory leak by reordering the error handling labels so that out_free_eeprom falls through to out_free_eeprom_blob.  The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc6.  An x86_64 allyesconfig build showed no new warnings. As we do not have supported Intel DVM wireless hardware and firmware to test with, no runtime testing was able to be performed.

CVE-2026-80974:

        In the Linux kernel, the following vulnerability has been resolved:  mfd: sm501: Fix potential memory leaks during remove  The memory allocated for struct sm501_devdata in sm501_pci_probe() and sm501_plat_probe() is not freed by the corresponding remove functions sm501_pci_remove() and sm501_plat_remove(). Fix that by adding a call to kfree().

CVE-2026-80980:

        In the Linux kernel, the following vulnerability has been resolved:  net/smc: stop killed, freed and out_of_sync sharing a byte  The three connection state flags are single-bit bitfields, so they occupy one byte of struct smc_connection and every store to one is a read-modify-write of the other two:      u8  killed : 1;     u8  freed : 1;     u8  out_of_sync : 1;  They are not written under a common lock. smc_cdc_msg_validate() sets out_of_sync from the receive tasklet, while smc_conn_kill() sets killed from process context under lock_sock(), and the receive path does not defer to the backlog when the socket is owned -- smc_cdc_msg_recv() takes only bh_lock_sock().  Give each flag its own byte so a store no longer touches its neighbours. All readers test them as booleans and are unchanged. struct smc_connection grows by two bytes.

CVE-2026-80989:

        In the Linux kernel, the following vulnerability has been resolved:  net: thunderbolt: Mark the connection down when bringing it up fails  Every failure path in tbnet_connected_work() undoes its own work and returns without clearing login_sent, so the connection still looks established. The next tbnet_tear_down() therefore takes its main branch and repeats a teardown that already happened: it stops rings that are already stopped, which is a dev_WARN() and fatal under panic_on_warn, and it releases net->remote_transmit_path even on the HopID mismatch path, where this connection never owned that id, silently freeing one that someone else is still using.  Clear login_sent on those paths. That is enough for tbnet_tear_down() to leave the unwound state alone, and login_received has to stay set: it records that the peer has logged in and carries the transmit path it gave us, which nothing on this side can make the peer send again. Two things change beyond keeping the teardown out of the way: the logout request in that block is no longer sent, and the peer's next login request now re-queues our login work rather than connected_work, giving the connection a fresh login instead of a retry on stale state.

CVE-2026-80990:

        In the Linux kernel, the following vulnerability has been resolved:  net: thunderbolt: Release the Rx HopID that was handed out on mismatch  tb_xdomain_alloc_in_hopid() passes the wanted HopID to ida_alloc_range() as the lower bound, so a taken id is not an error there: the allocator returns the next free one above it. tbnet_connected_work() asks for the peer's transmit path, treats any other id as a failure and returns without releasing what it got, so that allocation stays live for the rest of the XDomain connection with nothing left holding a reference to it.  Release the id when it is not the one we asked for, the same way the error unwind at the end of the function releases the expected one.

CVE-2026-80991:

        In the Linux kernel, the following vulnerability has been resolved:  net: ravb: serialize PTP clock teardown  ravb_ptp_interrupt() can race with ravb_ptp_stop() and pass the clock to ptp_clock_event() while ptp_clock_unregister() is freeing it. This can lead to a use-after-free.  Use READ_ONCE() and WRITE_ONCE() for lockless access to the clock pointer. Atomically detach it with xchg() before disabling PTP interrupts, then synchronize all IRQs which can invoke ravb_ptp_interrupt() before unregistering the detached clock.  A handler which read the old pointer completes before the clock is unregistered, while later handlers read NULL and skip the event.

CVE-2026-80996:

        In the Linux kernel, the following vulnerability has been resolved:  net: l2tp: do not propagate multicast notification errors  The tunnel create, tunnel modify, session create, and session modify netlink handlers send multicast notifications through helpers that can fail while allocating or encoding a message, or while multicasting it.  For tunnel and session create/modify, a notification is sent after the live operation has completed. Returning a best-effort notification error as the command result can therefore report failure for an operation that already committed and can cause callers to retry and accumulate live objects.  Keep sending notifications for listener visibility, but do not propagate their best-effort status as the command result. This also keeps the tunnel modify command consistent with the other notification-only paths.

CVE-2026-80999:

        In the Linux kernel, the following vulnerability has been resolved:  net: dsa: realtek: use gpiod_set_value_cansleep for reset GPIO  rtl83xx_reset_assert() and rtl83xx_reset_deassert() are only called from the probe path, which may sleep and is not timing-critical.  When the reset GPIO is provided by a sleeping controller such as an I2C I/O expander, gpiod_set_value() warns:    WARNING: drivers/gpio/gpiolib.c:4030 at gpiod_set_value+0x44/0x80, CPU#1: kworker/u16:4/61   Hardware name: B&O MAP CA33 Rev f (UNKNOWN) (DT)   Workqueue: events_unbound deferred_probe_work_func   pc : gpiod_set_value+0x44/0x80   lr : rtl83xx_probe+0x1d8/0x3a0   Call trace:    gpiod_set_value+0x44/0x80 (P)    rtl83xx_probe+0x1d8/0x3a0    realtek_mdio_probe+0x24/0xa0    mdio_probe+0x38/0x78    really_probe+0xc4/0x3e0    __driver_probe_device+0x15c/0x1b8    driver_probe_device+0xb4/0x120    __device_attach_driver+0xb8/0x1a0    bus_for_each_drv+0x88/0xf0    __device_attach+0xa0/0x1d8    device_initial_probe+0x54/0x68    bus_probe_device+0x38/0xa0    deferred_probe_work_func+0xb8/0x120    process_one_work+0x184/0x4e8    worker_thread+0x188/0x308    kthread+0x130/0x150    ret_from_fork+0x10/0x20  Switch both helpers to gpiod_set_value_cansleep() so such a reset GPIO can be used without triggering the warning.  The reset GPIO has been driven with the non-sleeping gpiod_set_value() since the driver was added in v4.19.  The call has since been refactored across several files - from realtek-smi.c / realtek-mdio.c into the common rtl83xx.c module and then into the rtl83xx_reset_assert() and rtl83xx_reset_deassert() helpers (both in v6.9).  This patch therefore applies as-is only to kernels that carry those helpers (v6.9+); older stable kernels need the same gpiod_set_value_cansleep() conversion at the corresponding open-coded call sites.

CVE-2026-81016:

        In the Linux kernel, the following vulnerability has been resolved:  platform/x86/amd/pmc: Propagate SMU errors and validate S2D address  amd_stb_s2d_init() discards the return value of several S2D SMU commands. When the SMU refuses a command (e.g. "SMU cmd failed. err: 0xff") the failure is only noticed indirectly - if at all - and reported as -EIO, masking the real error.  More seriously, the S2D_PHYS_ADDR_LOW/HIGH return values are ignored, so on failure phys_addr_low/hi are left uninitialised and the assembled address is passed straight to devm_ioremap().  When the SMU leaves them at zero this maps physical address 0 and trips the ioremap-on-RAM warning:    amd_pmc AMDI000B:00: SMU cmd failed. err: 0xff   ioremap on RAM at 0x0000000000000000 - 0x0000000000ffffff   WARNING: CPU: 13 PID: 4592 at arch/x86/mm/ioremap.c:...  Check the return value of each SMU command and propagate it, and reject a zero physical address before calling devm_ioremap().

CVE-2026-89437:

        In the Linux kernel, the following vulnerability has been resolved:  platform/x86: int1092: Fix potential memory leak in sar_probe()  The memory allocated for device_mode_info in parse_package() called by sar_get_data() is not freed in some of the error paths in sar_probe(). Fix that by converting to use device managed allocations.

CVE-2026-89441:

        In the Linux kernel, the following vulnerability has been resolved:  mmc: via-sdmmc: cancel card-detect work on remove  Disabling the device interrupt and freeing the IRQ prevents new card-detect work from being queued, but carddet_work already queued by the handler can still run after via_sd_remove() returns. via_sdc_card_detect() recovers the host through container_of() and dereferences its MMIO base; once remove() returns the host can be freed, so that work would touch freed memory.  Cancel carddet_work after freeing the IRQ and before cancelling finish_bh_work, which the card-detect handler can also queue. carddet_work can re-enable the interrupt through via_reset_pcictrl(); mask it again afterwards.  This issue was found by an in-house static analysis tool and confirmed by manual code review.

CVE-2026-89448:

        In the Linux kernel, the following vulnerability has been resolved:  iommu/vt-d: Force requesting ACS when tboot is enabled  Currently the conditions of requesting ACS in detect_intel_iommu() don't include tboot, leading to a possible misconfiguration with ACS disabled (e.g. due to user opts) while iommu is later forced on by tboot_force_iommu().  Fix it by checking tboot in detect_intel_iommu().

CVE-2026-89452:

        In the Linux kernel, the following vulnerability has been resolved:  iommu/msm: Unwind probe state on registration failure  msm_iommu_probe() adds its devm-managed IOMMU object to qcom_iommu_devices before adding the IOMMU sysfs device and registering it with the IOMMU core.  If iommu_device_sysfs_add() fails, probe returns with the object still on qcom_iommu_devices. The driver core then releases the devm allocation, leaving a dangling list entry that later list walks may dereference.  If iommu_device_register() fails, the same dangling list entry remains and the sysfs device is left registered as well.  Unwind the sysfs device and global list entry in reverse setup order on the corresponding failure paths.

CVE-2026-89462:

        In the Linux kernel, the following vulnerability has been resolved:  power: supply: max17040: propagate register read errors  max17040_get_vcell() and max17040_get_soc() ignore errors returned by regmap_read().  When an I2C transfer fails, the uninitialized register value is converted and reported to userspace as a valid voltage or state of charge.  The polling worker can also replace the cached state of charge with the bogus value and emit a spurious change event.  Propagate read errors through the power supply get_property callback and keep the last valid cached state of charge when polling fails.

CVE-2026-89465:

        In the Linux kernel, the following vulnerability has been resolved:  power: supply: rt9455: quiesce delayed work before teardown  The threaded IRQ handler can queue pwr_rdy_work, max_charging_time_work and batt_presence_work.  pwr_rdy_work and batt_presence_work can also queue max_charging_time_work, while batt_presence_work can requeue itself.  rt9455_remove() cancels max_charging_time_work before batt_presence_work.  The latter can therefore queue max_charging_time_work after it has already been cancelled:    rt9455_remove()                   workqueue     cancel pwr_rdy_work     cancel max_charging_time_work                                       batt_presence_work queues                                         max_charging_time_work     cancel batt_presence_work     return     devres frees rt9455_info                                       max_charging_time_work dereferences                                         rt9455_info  The IRQ also remains registered until devres cleanup and can queue more work after any of the cancellation calls.  If rt9455_hw_init() fails after the IRQ has been requested, probe returns without cancelling work that may already have been queued.  A pending callback can then access rt9455_info after it has been freed.  Register rt9455_cancel_all_delayed_works() through devm_add_action_or_reset() right after devm_power_supply_register(). devres invokes the action in reverse registration order, after the managed IRQ has been freed and before rt9455_info is released, so the delayed works are drained in both rt9455_remove() and the probe error path.  Cancel pwr_rdy_work and batt_presence_work before max_charging_time_work because both can queue the latter.  This issue was found by an in-house static analysis tool.

CVE-2026-89468:

        In the Linux kernel, the following vulnerability has been resolved:  power: supply: lp8788-charger: fix use-after-free on remove  lp8788_charger_remove() flushes charger_work before unregistering the IRQs. An IRQ thread can queue charger_work after flush_work() has returned. The work can then run after devres frees pchg and dereference it in lp8788_charger_event().  Unregister the IRQs first. free_irq() waits for any running threaded handler, so no handler can queue more work afterwards. Then use cancel_work_sync() to cancel pending work or wait for running work to finish.  This issue was found by an in-house static analysis tool.

CVE-2026-89472:

        In the Linux kernel, the following vulnerability has been resolved:  power: supply: charger-manager: register regulators before exposing sysfs  charger_manager_remove() and the err_reg_extcon probe error path free each charger regulator with regulator_put() before tearing down the power_supply sysfs entries (power_supply_unregister()). charger_manager_remove() also calls try_charger_enable(cm, false) after the regulator_put() loop. A concurrent write to a charger's externally_control sysfs attribute that lands between regulator_put() and power_supply_unregister() can run charger_externally_control_store() and call try_charger_enable(), which, when charging is enabled, dereferences the already-freed consumer handle. When charging is enabled, try_charger_enable(cm, false) in .remove() also dereferences the freed handles directly. Both leave use-after-free windows. Symmetrically, probe registers the sysfs entries (power_supply_register) before acquiring the regulators (regulator_get, inside charger_manager_register_extcon), so userspace can reach externally_control before the regulators are available.  Split charger_manager_register_extcon() on the sync/async boundary: charger_manager_get_regulators() (regulator_get only, no async producer) now runs before power_supply_register() so sysfs is not live before regulators are available, and charger_manager_register_extcon() keeps only the extcon notifier/work setup, still after power_supply_register() so a power_supply_register() failure cannot reach extcon setup. This keeps the sysfs setup/teardown ordering symmetric without introducing an asynchronous producer on the earlier probe-error path.  Move power_supply_unregister() and try_charger_enable(cm, false) ahead of the regulator_put() loop on both teardown paths, and adjust err_reg_extcon (power_supply_unregister() then fall through err_regulator for regulator_put(); get_regulators self-rolls back on its own failure).  This does not address the separate extcon-notifier-driven deref of the same handles, which needs its own synchronization design.  Found by an in-house static analysis tool.

CVE-2026-89484:

        In the Linux kernel, the following vulnerability has been resolved:  lockd: fix NULL dereference on lockowner allocation failure  nlmclnt_locks_init_private() installs NLM file lock operations even when nlmclnt_find_lockowner() fails to allocate a lockowner. nlmclnt_proc() then returns -ENOMEM, but the VFS still tears down the partially initialized file_lock and calls locks_release_private().  That invokes nlmclnt_locks_release_private(), which dereferences fl->fl_u.nfs_fl.owner and crashes because the owner was never installed.  Clear fl_ops before attempting to initialize the NLM private state, and install the NLM lock operations only after a lockowner has been allocated successfully.

CVE-2026-89492:

        In the Linux kernel, the following vulnerability has been resolved:  ocfs2: validate directory-index entry counts when reading metadata  ocfs2_validate_dx_leaf() and ocfs2_validate_dx_root() check the ECC and signature of an indexed-directory block before it reaches higher-level callers, but neither validator bounds the ocfs2_dx_entry_list counts against the capacity of the block that holds them.  ocfs2_dx_dir_search() then walks  	for (i = 0; i < le16_to_cpu(entry_list->de_num_used); i++) 		dx_entry = &entry_list->de_entries[i];  over de_num_used entries with no bounds check.  entry_list is either dx_leaf->dl_list (from ocfs2_read_dx_leaf) or, for an inline root, dx_root->dr_entries.  A crafted on-disk image can set de_num_used (and de_count, which is the __counted_by_le() bound of de_entries) to 0xffff and make the walk read far past the end of the 4KB metadata block, giving a slab out-of-bounds read reachable from any path lookup, stat() or open() on an indexed directory once the image is mounted.  Commit 775c17386a6f ("ocfs2: validate dx_root extent list fields during block read") already bounds dr_list for the non-inline dx_root, but left the inline dr_entries path and the dx_leaf dl_list unchecked.  Add the same read-time validation for both entry lists: de_count must equal the capacity of the block (ocfs2_dx_entries_per_leaf()/per_root()) and de_num_used must not exceed de_count, rejecting corrupted metadata with -EFSCORRUPTED before ocfs2_dx_dir_search() can walk an out-of-range entry array.  de_count is always written as exactly the block capacity when a leaf or inline root is formatted, so the equality check does not reject any valid image.  Found by 0sec automated security-research tooling (https://0sec.ai).

CVE-2026-89520:

        In the Linux kernel, the following vulnerability has been resolved:  sched/core: Make core-sched flips wait for in-flight selections  Core scheduling's pick_next_task() operates on all sibling rqs under one acquisition of the shared core-wide lock. A ->pick_task() that releases the rq lock leaves every sibling __lock momentarily free, letting __sched_core_flip(false) complete mid-selection and rebind rq_lockp() under it. The selection resumes on the split locks, touching sibling state it no longer protects, and __schedule() finally releases a lock that was never taken while leaking the one that was.  Count in-flight core-wide selections in the leader's rq->core_pick_in_flight and make __sched_core_flip() wait for the count to drain. The count only changes under the shared lock, which the flip holds while sampling, so no other ordering is needed. The wait can repeat while selections overlap, but the flip backs off between samples and flips are rare cookie-lifetime events.  sched_core_cpu_deactivate() moves the count to the new leader - a stale copy left behind would bias it forever if that CPU later returns as its own leader.

CVE-2026-89526:

        In the Linux kernel, the following vulnerability has been resolved:  svcrdma: Validate Read chunk positions before reconstruction  The RPC/RDMA Read chunk position field is supplied by the remote client and stored verbatim in the parsed chunk list. xdr_count_read_segments() checks only 4-byte alignment; it never compares the position against the received inline body length.  In the single-chunk path, svc_rdma_read_complete_one() splits the head and tail kvecs at ch_position. A position past the inline body underflows the tail length, exposing adjacent slab memory to the upper XDR decoder.  In the multi-chunk path, svc_rdma_read_multiple_chunks() computes gap lengths between chunks as unsigned subtractions from ch_position. Overlapping Read chunks cause these subtractions to underflow. A final position past the inline body likewise underflows the trailing gap length. svc_rdma_copy_inline_range() then copies past the receive buffer into request pages that are returned to the client through the Reply channel.  Bound inline-range copies in svc_rdma_copy_inline_range() against the decoded inline RPC body saved in rc_saved_arg. Reject a single Read chunk positioned beyond that body, and reject multi-chunk lists where accumulated read bytes exceed the next chunk's position. Apply the same position and overlap checks in the call-chunk interleaving path.

CVE-2026-89527:

        In the Linux kernel, the following vulnerability has been resolved:  svcrdma: Use svc_xprt_put to free listener on create failure  svc_rdma_create() calls kfree(cma_xprt) when svc_rdma_create_listen_id() fails. svc_xprt_init() has already acquired a net namespace reference via get_net_track(); kfree bypasses svc_xprt_free() which releases it.  Replace the kfree() with svc_xprt_put() so the kref_init birth reference drops to zero and svc_xprt_free() dispatches svc_rdma_free() to clean up properly. sc_cm_id is still NULL at that point; the preceding patch added the necessary NULL guard in svc_rdma_free().  svc_xprt_free() also drops the module reference via module_put(), but the caller _svc_xprt_create() does the same on xpo_create failure, double-putting the single try_module_get() it acquired. Take a compensating __module_get() before the svc_xprt_put() to keep the count balanced, matching the convention in svc_rdma_accept()'s error path.

CVE-2026-89528:

        In the Linux kernel, the following vulnerability has been resolved:  svcrdma: Reject Read lists that exceed the page budget  Individual Read segment lengths are validated at decode time, but nothing prevents a requester from sending multiple segments whose cumulative length exceeds the rq_pages array budget. When one segment fills the page array exactly, the runtime guard in svc_rdma_build_read_segment() is bypassed because len reaches zero. A subsequent segment then accesses the NULL sentinel slot at rq_pages[rq_maxpages], resulting in a NULL pointer dereference during DMA mapping.  Accumulate pages across all Read segments and reject the message at decode time when the total would overflow the page budget.

CVE-2026-89530:

        In the Linux kernel, the following vulnerability has been resolved:  svcrdma: Reject inline replies that overflow the pull-up buffer  An RPC-over-RDMA client can request a reply, such as an NFS READ payload, without providing a Write list or a Reply chunk to carry it. When such a reply needs more scatter/gather entries than the device's Send Queue supports, svc_rdma_pull_up_needed() selects pull-up and svc_rdma_pull_up_reply_msg() linearizes the whole reply into sctxt->sc_xprt_buf. That buffer is only sc_max_req_size bytes, while the reply on this path is bounded only by the client's request, so svc_rdma_xb_linearize() copies past the end of the buffer and corrupts adjacent slab memory. The oversized length is then stored in sc_sges[0].length and posted, so the device also reads beyond the mapped region.  The SGE-exhaustion branch is the only pull-up path that can exceed the buffer: the threshold branch pulls up only replies smaller than RPCRDMA_PULLUP_THRESH, and replies that fit the device's SGE budget are sent directly without linearization. Make svc_rdma_pull_up_needed() report -E2BIG when the reply it would pull up cannot fit sc_max_req_size, and fail the request with ERR_CHUNK as RFC 8166 Section 4.5.3 directs rather than dropping the connection.  The helper no longer answers a simple yes/no question: it now reports pull-up, no pull-up, or -E2BIG for a reply too large to linearize. Rename svc_rdma_pull_up_needed() to svc_rdma_check_pull_up() so its name no longer implies a boolean predicate.

CVE-2026-89531:

        In the Linux kernel, the following vulnerability has been resolved:  svcrdma: Reject connection when transport allocation fails  handle_connect_req() returns without action when svc_rdma_create_xprt() fails to allocate the new transport. The CM core returns 0 for CONNECT_REQUEST events, so it does not destroy the new rdma_cm_id. Each allocation failure under memory pressure leaks one rdma_cm_id, and a remote peer driving connection attempts can amplify this.  Reject the connection by returning a non-zero status from the CM event handler, which tells the CM core to destroy the orphaned cm_id.

CVE-2026-89537:

        In the Linux kernel, the following vulnerability has been resolved:  SUNRPC: Reject short RFC 4121 MIC tokens in gss_krb5_verify_mic_v2  gss_krb5_verify_mic_v2() reads the token ID at ptr[0..1], the flags byte at ptr[2], and padding at ptr[3..7], then passes ptr + GSS_KRB5_TOK_HDR_LEN and cksum_len to gss_krb5_mic_build_sg(). None of these accesses check read_token->len first.  The minimum safe token size is GSS_KRB5_TOK_HDR_LEN (16) plus ctx->krb5e->cksum_len (12-24, depending on the enctype).  All callers accept shorter tokens from the wire:   - gss_unwrap_resp_integ() enforces only an upper bound    (offset + len <= rcv_buf->len) before allocating    mic.data = kmalloc(len) and passing it to gss_verify_mic().    A malicious NFS server can therefore supply a short checksum    opaque, producing a small slab allocation that the Kerberos MIC    verifier reads past.   - gss_validate() enforces only len <= RPC_MAX_AUTH_SIZE (400)    before passing the wire-supplied length to    gss_validate_seqno_mic(), which constructs a mic xdr_netobj    and calls gss_verify_mic().   - svcauth_gss_verify_header() enforces only    checksum.len >= XDR_UNIT (4 bytes) before dispatching to    gss_verify_mic().   - svcauth_gss_unwrap_integ() checks only that the checksum fits    in gsd->gsd_scratch.  Add a length guard at the top of gss_krb5_verify_mic_v2(), before any ptr[] access or scatterlist construction.  Well-formed MIC tokens from gss_krb5_get_mic_v2() already have exactly GSS_KRB5_TOK_HDR_LEN + cksum_len bytes, so valid traffic is unaffected.

CVE-2026-89539:

        In the Linux kernel, the following vulnerability has been resolved:  SUNRPC: reject duplicate CREDS_VALUE options  gssx_dec_option_array() walks the wire-supplied option array and, for every entry whose name matches CREDS_VALUE, calls gssx_dec_linux_creds() on the same struct svc_cred. That helper unconditionally installs a fresh groups_alloc() result into creds->cr_group_info without releasing whatever pointer was already there:      for (i = 0; i < count; i++) {         ... decode name ...         if (length == sizeof(CREDS_VALUE) &&             memcmp(p, CREDS_VALUE, sizeof(CREDS_VALUE)) == 0) {             err = gssx_dec_linux_creds(xdr, creds);             ...         }     }  A reply that carries two CREDS_VALUE entries therefore overwrites cr_group_info on the second iteration and orphans the group_info allocated by the first call. The earlier free_creds path only releases the last cr_group_info via free_svc_cred(), so the first allocation's refcount stays at one and its kvmalloc-backed storage is leaked. No in-tree caller of gssp_accept_sec_context_upcall() expects more than one CREDS_VALUE per reply.  Fix by tracking whether a CREDS_VALUE option has already been decoded and returning -EINVAL on any subsequent match, so the free_creds path releases the single group_info that was installed.

CVE-2026-89543:

        In the Linux kernel, the following vulnerability has been resolved:  sunrpc: fix use-after-free in __rpc_clnt_handle_event and __rpc_clnt_remove_pipedir  Normal client creation goes through rpc_setup_pipedir(), which records clnt->pipefs_sb, but the mount-event path in __rpc_clnt_handle_event() calls rpc_setup_pipedir_sb() directly and never refreshes that field. The umount path also removes the directory without clearing clnt->pipefs_sb.  After a late pipefs mount or any remount, rpc_clnt_remove_pipedir() compares the current superblock against a stale pipefs_sb pointer and skips cleanup, leaving pipefs dentries whose inode private data still points at a freed rpc_clnt, leading to a potential use-after-free during subsequent rpc_info_open() or rpc_show_info() calls.  Fix this by properly updating clnt->pipefs_sb upon mount events and clearing it during unmount or failure paths.

CVE-2026-89544:

        In the Linux kernel, the following vulnerability has been resolved:  SUNRPC: fix gssx_dec_option_array error path bugs  Four coupled defects in the gssx XDR option-array decoder make the error paths unsafe: a NULL deref in the caller, a refcount leak on the decoded group_info, and a latent use-after-free that the leak fix would otherwise expose.  gssx_dec_option_array() sets oa->count = 1 before allocating oa->data.  If that allocation fails, -ENOMEM is returned with oa->count == 1 and oa->data == NULL.  All other error paths jump to free_oa: which frees oa->data and NULLs it but also leaves oa->count == 1.  The caller trusts the count:      gssp_accept_sec_context_upcall()       gssx_dec_accept_sec_context()         gssx_dec_option_array()        /* fails, count=1 data=NULL */       data = res.options.data[0].value /* NULL deref */  Independently, free_creds: releases the partially decoded svc_cred with a bare kfree(creds).  gssx_dec_linux_creds() installs a groups_alloc() result into creds->cr_group_info; that object is kvmalloc-backed and refcounted, and only put_group_info() reaches kvfree().  A plain kfree(creds) drops the wrapper and leaks the group_info allocation.  The natural fix for the leak is to call free_svc_cred(creds) before kfree(creds), but free_svc_cred() invokes put_group_info() on creds->cr_group_info unconditionally when non-NULL.  The existing out_free_groups: path in gssx_dec_linux_creds() already called groups_free() on that pointer without clearing it, so once free_svc_cred() is wired in, the subsequent put_group_info() would touch freed memory.  Fix all four together:    - Move the oa->count = 1 assignment below the oa->data allocation     so it is never set when oa->data is NULL.   - Reset oa->count to 0 at free_oa: so count and data stay     coherent and the caller sees an empty option array.   - Call free_svc_cred(creds) before kfree(creds) at free_creds:     so the refcounted cr_group_info is released.  free_svc_cred()     either NULL-guards each field explicitly (cr_group_info has     an if() check) or delegates to a helper that is NULL-safe     itself (kfree for the string fields, gss_mech_put() which     guards with if(gm) at gss_mech_switch.c:342), so it is safe     to call on a partially decoded svc_cred where only     cr_uid/cr_gid/cr_group_info have been written and everything     else is zero from kzalloc.   - In gssx_dec_linux_creds()'s out_free_groups: path, release     cr_group_info with put_group_info() rather than groups_free()     so the teardown matches free_svc_cred()'s refcount-aware path,     and clear the pointer so a later free_svc_cred() on the same     creds does not release it a second time.

CVE-2026-89545:

        In the Linux kernel, the following vulnerability has been resolved:  sunrpc: defer rq_argp and rq_resp free until after RCU grace period  svc_rqst_free() frees rqstp->rq_argp and rqstp->rq_resp synchronously via kfree(), but defers the rqstp struct free via kfree_rcu().  After svc_exit_thread() calls list_del_rcu() and svc_rqst_free(), there is a window where RCU readers that started before list_del_rcu() can still traverse the thread list and find the rqstp.  These readers (e.g. nfsd_nl_rpc_status_get_dumpit()) dereference rqstp->rq_argp, which has already been freed — a use-after-free.  Fix this by moving the kfree of rq_argp and rq_resp into an explicit call_rcu() callback alongside the struct free.  Resources not accessed by RCU readers (bvec, buffer pages, scratch folio, auth_data) remain synchronously freed.

CVE-2026-89550:

        In the Linux kernel, the following vulnerability has been resolved:  SUNRPC: svcauth_gss: enforce krb5 token minimum length  svcauth_gss_unwrap_priv() validates only an upper bound on the wire-supplied opaque length before handing the buffer to gss_unwrap():      if (len > xdr_stream_remaining(xdr))             goto unwrap_failed;     offset = xdr_stream_pos(xdr);     ...     maj_stat = gss_unwrap(ctx, offset, offset + len, buf);  The wire value `len` flows unchanged as the upper bound into the krb5 unwrap path, so a len in [0, 16] passes this check and is handed to gss_unwrap(). For a krb5 v2 context that lands in gss_krb5_unwrap_v2(), which reads the 16-byte RFC 4121 token header fields at ptr+4 and ptr+6 and then calls rotate_left() before any integrity check. With a sub-header length the header reads run past the token, and _rotate_left()'s `shift %= buf->len` path can divide by zero when buf->len has been driven to zero by the truncated token. A header-only token (len == 16) is equally invalid: with a non-zero RRC field and the opaque blob ending at the XDR buffer boundary, rotate_left() builds a zero-length subbuffer, reaching the same division.  Reject the token at the server entry point before it reaches the krb5 unwrap core. A valid sealed RFC 4121 token must contain the 16-byte header plus at least some encrypted payload.  Fix by adding a minimum-length check immediately after the existing upper-bound check:      if (len <= GSS_KRB5_TOK_HDR_LEN)             goto unwrap_failed;

CVE-2026-89552:

        In the Linux kernel, the following vulnerability has been resolved:  params: fix charp corruption on allocation failure  param_set_charp() stores charp parameters in allocated memory after slab is available, and releases the previous value when the parameter is updated.  The previous value is released before the replacement allocation succeeds. If kmalloc_parameter() fails, the setter returns -ENOMEM with the parameter left as NULL.  Failing zswap's compressor update before zswap is initialized can later trigger:    BUG: kernel NULL pointer dereference, address: 0000000000000000   RIP: 0010:strcmp+0x10/0x30   Call Trace:     zswap_setup+0x3b1/0x490     zswap_enabled_param_set+0x5b/0xa0     param_attr_store+0x93/0xe0     module_attr_store+0x1c/0x30     kernfs_fop_write_iter+0x116/0x1f0  Allocate and copy the replacement first, then replace the parameter value only after allocation succeeds.

CVE-2026-89553:

        In the Linux kernel, the following vulnerability has been resolved:  nouveau/gem: reserve the bo in the info ioctl around the vma lookup  In the non-uvmm path, there could be a race between the info lookup finding the vma, and the gem close path closing the vma leading to a use-after-free.  Spotted with the help of Opus 4.6.

CVE-2026-89561:

        In the Linux kernel, the following vulnerability has been resolved:  ipv6: rpl: fix NULL dereference of idev in ipv6_rpl_srh_rcv()  ipv6_rpl_srh_rcv() dereferences idev from __in6_dev_get() without a NULL check when reading idev->cnf.rpl_seg_enabled.  When the device's MTU drops below IPV6_MIN_MTU, addrconf_ifdown() clears dev->ip6_ptr through RCU_INIT_POINTER(). A packet that passed the idev check in ip6_rcv_core() can then reach ipv6_rpl_srh_rcv() with dev->ip6_ptr already NULL.  Reproduced by flooding the receiving interface with ping6 traffic while flapping its MTU between 1500 and 1200:   BUG: KASAN: null-ptr-deref in ipv6_rpl_srh_rcv+0xb3/0x1070  Read of size 4 at addr 00000000000006b4 by task ping6/394   CPU: 2 UID: 0 PID: 394 Comm: ping6 Not tainted 7.2.0-rc7-micro-vm-dev-00095-g24ef02f934ee #240 PREEMPT(full)  Call Trace:   <IRQ>   kasan_report+0xc6/0x100   ipv6_rpl_srh_rcv+0xb3/0x1070   ip6_protocol_deliver_rcu+0x759/0x9a0   ip6_input_finish+0xa8/0x1b0   ip6_input+0xe1/0x490   ipv6_rcv+0x33d/0x460   __netif_receive_skb_one_core+0xd6/0x130   process_backlog+0x2cc/0xa00   __napi_poll.constprop.0+0x56/0x270   net_rx_action+0x327/0x730   handle_softirqs+0x11e/0x630   do_softirq+0xb3/0xf0   </IRQ>  Both ipv6_rpl_srh_rcv() and ipv6_srh_rcv() are called only from ipv6_rthdr_rcv(), which already has an idev lookup.  Fix the NULL dereference on the RPL path by checking idev in ipv6_rthdr_rcv(), before it calls either function. The callees take idev as an argument and no longer call __in6_dev_get(), so the packet is now dropped in one place, with SKB_DROP_REASON_IPV6DISABLED on both paths.

CVE-2026-89564:

        In the Linux kernel, the following vulnerability has been resolved:  ip: orphan prefetched skbs before multicast forwarding  IPv4 and IPv6 input preserve an skb->sk association installed by bpf_sk_assign() so that local delivery can use the selected socket under RCU. Both address families can also prefetch a socket in UDP early demux. In both paths (BPF and UDP early demux) a reference is not guaranteed to be held on the socket.  When a multicast packet is not locally deliverable, IPv6 hands the original skb to ip6_mr_input(). IPv4's ip_mr_input() similarly keeps the original skb when local delivery is not needed. Either path can put the skb on an unresolved multicast route queue or forward it after the receive-side RCU section ends.  After the prefetched socket is destroyed, a later skb free invokes sock_pfree() and dereferences the stale skb->sk. Orphan the skb before each non-local multicast forwarding path. Local delivery retains the original skb; the existing skb_clone() calls provide multicast forwarding with a socket-free clone.

CVE-2026-89566:

        In the Linux kernel, the following vulnerability has been resolved:  jbd2: check need_resched() when skipping busy checkpoint buffers  journal_shrink_one_cp_list() skips busy checkpoint buffers when called with JBD2_SHRINK_BUSY_SKIP.  The continue statement on this path also skips the need_resched() check at the end of the loop body.  Consequently, when a checkpoint list contains mostly busy buffers, the shrinker can walk the entire list while holding journal->j_list_lock, even when a reschedule has been requested.  Large checkpoint lists under memory pressure can therefore cause long lock hold times and leave other CPUs spinning on j_list_lock, resulting in soft lockups or RCU stalls.  Route the busy-buffer path through the need_resched() check so that the shrinker can release j_list_lock and reschedule promptly, restoring parity with the clean-buffer path, which already checks need_resched(). This does not change which checkpoint buffers are eligible for removal.

CVE-2026-89567:

        In the Linux kernel, the following vulnerability has been resolved:  jbd2: bound shrinker scans by examined checkpoint buffers  The jbd2 shrinker currently accounts only checkpoint buffers that it successfully releases against nr_to_scan.  Busy buffers therefore do not consume the scan budget.  If a checkpoint transaction contains mostly busy buffers, the shrinker can scan its entire checkpoint list while holding journal->j_list_lock. Large checkpoint lists can result in excessive lock hold times and leave other CPUs spinning on j_list_lock, causing soft lockups or RCU stalls.  Pass nr_to_scan into journal_shrink_one_cp_list() and decrement it for every buffer examined, including busy buffers.  Pass NULL from checkpoint cleanup paths so their existing full-list behavior is preserved.  This restores the scan-budget semantics that existed before journal_shrink_one_cp_list() was changed to always scan a complete checkpoint list.

CVE-2026-89574:

        In the Linux kernel, the following vulnerability has been resolved:  dm array: validate array block headers on read  array_block_check() validates blocknr and csum and nothing else, while node_check(), next to it, has bounded the structural fields since both were written. dm_array_cursor_next() takes its loop bound from the on-disk nr_entries and element_at() is unguarded pointer arithmetic, so a count larger than the block holds keeps the cursor in one block while the index grows past it and the read walks off the dm-bufio buffer -- dm_cache_load_mappings() drives it once per cache block at activation.  Check the header against itself: reject a zero value_size, require max_entries to equal calc_max_entries() for that value_size and block size, and require nr_entries to fit. Equality rather than an upper bound, since a count below the real capacity trips BUG_ON() in fill_ablock() and trim_ablock(). Metadata dm-array writes satisfies all three.

CVE-2026-89580:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: Disable preemption in __bpf_get_stack  get_perf_callchain() returns a per-CPU perf_callchain_entry buffer and releases its recursion slot via put_callchain_entry() before returning, so nothing keeps the entry reserved while __bpf_get_stack() consumes it below.  A preemptible BPF program (e.g. a non-sleepable raw tracepoint program on a PREEMPT kernel, which runs under migrate_disable() but not preempt_disable()) can be scheduled out between obtaining the entry and the copy. Another task scheduled on the same CPU then reuses the same per-CPU buffer and overwrites trace->nr with a larger value. copy_len is then computed from the inflated trace->nr and can exceed the caller's buffer, causing an out-of-bounds write in the memcpy() and in the build_id path.  The rcu_read_lock() taken here alone does not prevent this. It is only taken on the may_fault path, and under CONFIG_PREEMPT_RCU it does not disable preemption; it merely keeps perf's callchain buffer array alive (freed via call_rcu()) and does nothing to stop another task from reusing the entry.  Disable preemption around obtaining the callchain entry and copying it into the caller's buffer, so the entry cannot be reused underneath us and trace->nr stays bounded by max_depth. Build ID resolution may fault and is therefore deferred until after preemption is re-enabled; by then the instruction pointers have already been copied into buf, so it operates only on that private copy. Note, preempt_disable() also subsumes the buffer-lifetime guarantee the rcu_read_lock() provided, since a preempt-disabled section is an RCU read-side critical section for the callchain buffers' call_rcu() reclaim.   [ changed Fixes: commit ]

CVE-2026-89598:

        In the Linux kernel, the following vulnerability has been resolved:  fbdev: ssd1307fb: defer I2C transfers from damage callbacks  The fbdev damage callbacks may run from fbcon while printk has disabled preemption.  They currently update the display synchronously, which enters the sleeping I2C transfer path from atomic context.  A complete report from an RK3566 system follows:    [  258.129004] watchdog: watchdog0: watchdog did not stop!   [  258.129067] BUG: scheduling while atomic: systemd/1/0x00000003   [  258.129076] Modules linked in: algif_hash algif_skcipher af_alg bnep   binfmt_misc lz4hc lz4 zram snd_soc_hdmi_codec brcmfmac_wcc hci_uart   fb_ssd1306(C) fbtft(C) btqca btrtl btintel btsdio snd_soc_simple_card   motorcomm pwm_fan snd_soc_simple_card_utils ssd130x_spi nls_iso8859_1   ssd130x btbcm drm_shmem_helper display_connector brcmfmac ssd1307fb   brcmutil bluetooth cfg80211 rfkill snd_soc_rockchip_i2s_tdm   snd_soc_rk817 hantro_vpu snd_soc_core snd_compress snd_pcm_dmaengine   v4l2_vp9 snd_pcm v4l2_h264 rockchip_rga snd_timer rk_crypto2   spi_rockchip_sfc videobuf2_dma_contig snd sm3_generic v4l2_mem2mem   videobuf2_dma_sg dwmac_rk sm3 soundcore videobuf2_memops videobuf2_v4l2   stmmac_platform dw_hdmi_cec videodev videobuf2_common dw_hdmi_i2s_audio   stmmac rk817_charger pcs_xpcs mc cpufreq_dt sch_fq_codel ip_tables   x_tables autofs4   [  258.129215] Preemption disabled at:   [  258.129216] [<ffff80008012f96c>] vprintk_emit+0x11c/0x340   [  258.129234] CPU: 0 PID: 1 Comm: systemd Tainted: G         C   6.6.0-rc5-rockchip-rk356x #4   [  258.129239] Hardware name: Rockchip RK3566 OPi 3B (DT)   [  258.129243] Call trace:   [  258.129245]  dump_backtrace+0xa0/0x128   [  258.129252]  show_stack+0x20/0x38   [  258.129256]  dump_stack_lvl+0x60/0xb0   [  258.129265]  dump_stack+0x18/0x28   [  258.129269]  __schedule_bug+0xa0/0xc8   [  258.129274]  __schedule+0x9ac/0xd30   [  258.129279]  schedule+0x60/0x100   [  258.129282]  schedule_timeout+0x194/0x338   [  258.129289]  rk3x_i2c_xfer_common.isra.0+0x384/0x498   [  258.129296]  rk3x_i2c_xfer+0x20/0x60   [  258.129300]  __i2c_transfer+0x194/0x648   [  258.129308]  i2c_transfer+0x9c/0x130   [  258.129313]  i2c_transfer_buffer_flags+0x64/0x98   [  258.129318]  ssd1307fb_update_rect+0x42c/0x560 [ssd1307fb]   [  258.129334]  ssd1307fb_defio_imageblit+0x34/0x50 [ssd1307fb]   [  258.129343]  soft_cursor+0x13c/0x210   [  258.129350]  bit_cursor+0x2dc/0x550   [  258.129354]  fbcon_cursor+0xec/0x108   [  258.129359]  hide_cursor+0x44/0xc8   [  258.129365]  vt_console_print+0x398/0x3b0   [  258.129370]  console_flush_all.isra.0+0x17c/0x410   [  258.129377]  console_unlock+0x4c/0x100   [  258.129382]  vprintk_emit+0x1c8/0x340   [  258.129386]  vprintk_default+0x40/0x58   [  258.129389]  vprintk+0xb8/0xd0   [  258.129392]  _printk+0x68/0x98   [  258.129398]  watchdog_release+0x170/0x230   [  258.129404]  __fput+0xbc/0x288   [  258.129409]  __fput_sync+0x58/0x70   [  258.129413]  __arm64_sys_close+0x40/0x90   [  258.129419]  invoke_syscall+0x4c/0x118   [  258.129426]  el0_svc_common.constprop.0+0x48/0xf0   [  258.129432]  do_el0_svc+0x24/0x38   [  258.129437]  el0_svc+0x48/0x100   [  258.129443]  el0t_64_sync_handler+0xc0/0xc8   [  258.129448]  el0t_64_sync+0x190/0x198   [  258.573087] ------------[ cut here ]------------   [  258.573098] DEBUG_LOCKS_WARN_ON(val > preempt_count())   [  258.573111] WARNING: CPU: 0 PID: 1 at kernel/sched/core.c:5871   preempt_count_sub+0x9c/0x148   [  258.573130] Modules linked in: algif_hash algif_skcipher af_alg bnep   binfmt_misc lz4hc lz4 zram snd_soc_hdmi_codec brcmfmac_wcc hci_uart   fb_ssd1306(C) fbtft(C) btqca btrtl btintel btsdio snd_soc_simple_card   motorcomm pwm_fan snd_soc_simple_card_utils ssd130x_spi nls_iso8859_1   ssd130x btbcm drm_shmem_helper display_connector brcmfmac ssd1307fb   brcmutil bluetooth cfg80211 rfkill snd_soc_rockchip_i2s_tdm   snd_soc_rk817 hantro_vpu snd_soc_core snd_compress snd_pcm_dmaengine   v4l2_vp ---truncated---

CVE-2026-89601:

        In the Linux kernel, the following vulnerability has been resolved:  ext2: Fix lost inode updates for IS_SYNC inodes  ext2_setsize() and ext2_xattr_set2() had a construct like:  	if (IS_SYNC(inode)) { 		sync_inode_metadata(inode, 1); 	} else { 		mark_inode_dirty(inode); 	}  which leads to lost inode updates for IS_SYNC inodes because sync_inode_metadata() does anything only if the inode is already dirty and hence inode updates may be simply lost. Fix the problem by unconditionally marking the inode dirty and *then* call sync_inode_metadata().

CVE-2026-89610:

        In the Linux kernel, the following vulnerability has been resolved:  ntfs: verify run length exceeding volume boundary  The mapping pairs decoder validates that the starting LCN is within the volume but does not check if the run extends beyond the volume boundary.  A malformed NTFS image with a crafted mapping pairs array could cause the kernel to access memory beyond the volume boundary, potentially leading to memory corruption and privilege escalation.  Add validation to ensure lcn + length stays within nr_clusters.

CVE-2026-89611:

        In the Linux kernel, the following vulnerability has been resolved:  ntfs: validate non-resident attribute offsets  ntfs_attr_update_meta() shifts the attribute name when converting between non-sparse and sparse attributes. Converting to sparse also adds the compressed_size field before the name and mapping pairs, requiring eight additional bytes in the attribute record.  However, the validator does not check that name_offset is within safe boundaries for these operations or that the additional space is available. A malicious MFT record could set name_offset such that:  1. The name is positioned at the very end of a non-sparse attribute.    Converting to sparse would shift the name forward by 8 bytes,    writing beyond the attribute boundary.  2. The name overlaps with the mapping pairs, causing corruption during    conversion.  Add validation to ensure: - For named attributes, name_offset is within valid bounds - Name does not extend beyond the attribute or overlap with mapping pairs - For non-sparse, non-compressed attributes, eight bytes are available   after mapping_pairs_offset for the compressed_size field  The space check also covers unnamed attributes, for which name_offset = 0 is valid and no name range needs to be checked.

CVE-2026-89622:

        In the Linux kernel, the following vulnerability has been resolved:  HID: mcp2221: clear rxbuf after I2C/SMBus transfer completes  mcp_i2c_smbus_read() stores the caller-supplied buffer pointer in mcp->rxbuf for the duration of a transfer but never clears it when the transfer finishes or times out. Once the caller frees or reuses the buffer, mcp->rxbuf becomes a dangling pointer. A delayed or spurious MCP2221_I2C_GET_DATA report can then drive mcp2221_raw_event() to memcpy device data into the freed memory, causing a write use-after-free.  Route all return paths through a single exit point that clears mcp->rxbuf and mcp->rxbuf_size, so that the existing !mcp->rxbuf guard in the raw_event handler can reject any report arriving after the transfer has ended.

CVE-2026-89625:

        In the Linux kernel, the following vulnerability has been resolved:  HID: sony: fix UAF of ghl_poke_timer / ghl_urb at driver unbind  For GHL (Guitar Hero Live) dongles, sony_probe() arms a periodic timer: ghl_magic_poke() (the timer callback) submits sc->ghl_urb, and the URB completion ghl_magic_poke_cb() re-arms the timer with mod_timer().  sony_remove() drained the timer with timer_delete_sync() and then freed the URB with usb_free_urb():  	timer_delete_sync(&sc->ghl_poke_timer); 	usb_free_urb(sc->ghl_urb);  timer_delete_sync() does not block re-arming, and while the URB is in flight the timer is not pending, so the sync delete is a no-op. A URB completion that runs after the delete re-arms the timer, and usb_free_urb() only drops a reference -- it does not kill an in-flight URB. sc is allocated with devm_kzalloc() and freed once sony_remove() returns, so the re-armed ghl_poke_timer (embedded in sc) then fires on freed memory, a use-after-free from timer softirq. This is a disconnect/rmmod race.  Poison the URB first, then shut the timer down, before freeing the URB. usb_poison_urb() kills any in-flight URB and permanently rejects further submissions, so a poke timer that is still pending cannot re-submit the URB from ghl_magic_poke() in the window before timer_shutdown_sync() runs. usb_kill_urb() would not suffice: it only cancels the in-flight URB and leaves it submittable once it returns, so the pending timer could re-submit it and put a fresh URB in flight over the freed sc. timer_shutdown_sync() then drains any last callback and blocks re-arming. The probe error path is unaffected: it is only reached before the timer is armed.  Reproduced under KASAN on next-20260710 via dummy_hcd + raw-gadget emulation of the GHL PS4 dongle (VID 0x1430 / PID 0x07bb): hid-sony binds and arms the poke timer, the poke URB is held in flight, the driver is unbound (freeing sc), then the URB is released. The completion re-arms the timer on the freed sc, and the re-armed timer fires ~8 s later:    BUG: KASAN: slab-use-after-free in ghl_magic_poke+0x98/0xb0   Read of size 8 at addr ffff88810b02fd50 by task swapper/0/0    ghl_magic_poke+0x98/0xb0    call_timer_fn+0x35/0x2b0    __run_timers+0x69c/0x9a0    run_timer_softirq+0x173/0x2a0   Allocated by task 169:  sony_probe   Freed by task 338:      devres_release_group <- hid_device_remove (sony_remove)  Found by 0sec (https://0sec.ai) using automated source analysis.

CVE-2026-89631:

        In the Linux kernel, the following vulnerability has been resolved:  smb: client: reject a tree connect response whose byte count is too small  CIFSTCon() bounds its strnlen() over the byte area with the server's ByteCount minus two, which for ByteCount 0 or 1 goes negative as an int and converts to a huge size_t.  The later subtraction wraps the __u16 bytes_left, and that is what bounds cifs_strndup_from_utf16(): a bound of up to 65535 against a ~16 KB cifs_req_poolp object runs off the end of the slab object, and the bytes reach userspace through tcon->nativeFileSystem in /proc/fs/cifs/DebugData.  Reject a byte area too small for what the parser consumes.  Two bytes is the least it can consume, and no conformant response carries fewer.  The new trace point is the 129th smb_eio_trace entry, which __mode(byte) cannot represent, so the attribute goes with it.

CVE-2026-89633:

        In the Linux kernel, the following vulnerability has been resolved:  smb: client: fix OOB read/write from unvalidated DataOffset in coalesce_t2()  coalesce_t2() computes data pointers directly from server-supplied DataOffset fields with no validation against buffer bounds:    data_area_of_tgt = (char *)&pSMBt->hdr.Protocol +                      get_unaligned_le16(&pSMBt->t2_rsp.DataOffset);   data_area_of_src = (char *)&pSMBs->hdr.Protocol +                      get_unaligned_le16(&pSMBs->t2_rsp.DataOffset);   data_area_of_tgt += total_in_tgt;   ...   memcpy(data_area_of_tgt, data_area_of_src, total_in_src);  A small DataOffset can push a pointer below the actual byte area, overwriting header fields; a large one can push it past the buffer end, causing out-of-bounds heap reads (source) or writes (target). The BCC overflow guard does not prevent this: BCC reflects how much data is present, while DataOffset controls where in the buffer it starts.  The "validate target area" comment present since the function was first written in 2005 was a placeholder that was never implemented.  Add lower- and upper-bound checks for both data pointers before the memcpy, and before any target header fields are modified.

CVE-2026-89637:

        In the Linux kernel, the following vulnerability has been resolved:  smb: client: fix UAF and buffer leak in cifs_check_trans2() for malformed secondary T2  When a valid primary TRANSACT2 response has been received (mid->resp_buf set, mid->multiRsp true) and a subsequent secondary response causes cifs_check_trans2() to return false -- either because the SMB header is invalid (malformed != 0) or because check2ndT2() rejects the PDU -- handle_mid() overwrites mid->resp_buf with the new buffer (leaking the primary buffer) and, because mid->multiRsp is set, skips the server->smallbuf/bigbuf NULL-out.  When the user thread frees mid->resp_buf, server->smallbuf or server->bigbuf is left dangling; the demux thread reuses it for the next packet, resulting in a use-after-free.  Combine both early-exit conditions and, when mid->multiRsp is already set, abort the pending transaction inline: set multiEnd, call dequeue_mid() with malformed=true, and return true so handle_mid() exits without touching mid->resp_buf or the server buffer pointers.

CVE-2026-89638:

        In the Linux kernel, the following vulnerability has been resolved:  smb: client: clear setuid/setgid bit on write with cifsacl/modefromsid/posix extensions  When a file has the setuid or setgid bit set and is written to, the VFS strips those bits and issues a setattr with ATTR_KILL_SUID/ATTR_KILL_SGID together with an ATTR_MODE carrying the already-cleared mode.  Both cifs_setattr_unix() and cifs_setattr_nounix() unconditionally dropped ATTR_MODE in that case:  	/* skip mode change if it's just for clearing setuid/setgid */ 	if (attrs->ia_valid & (ATTR_KILL_SUID|ATTR_KILL_SGID)) 		attrs->ia_valid &= ~ATTR_MODE;  This is fine for the default mount, where the mode is only emulated via the DOS read-only attribute and cannot represent the setuid/setgid bits anyway.  However, with the "cifsacl" or "modefromsid" mount options the mode is stored on the server through an ACL (id_mode_to_cifs_acl()), with the SMB3.1.1 POSIX extensions the mode is sent to the server directly, and with the SMB1 Unix extensions (cifs_setattr_unix) the mode is sent via CIFSSMBUnixSetPathInfo().  In all those cases dropping ATTR_MODE means the cleared mode is never pushed to the server, so the setuid/setgid bit survives the write.  This is a security issue: on local filesystems the setuid bit is stripped when a file is written, but over these cifs.ko mounts the bit persists on the server, potentially allowing an unexpected privilege escalation on subsequent execution.  Fix this in two places:    1. cifs_setattr_nounix(): only take the "skip mode change" shortcut      when the mode is emulated via the DOS read-only attribute (i.e.      neither cifsacl/modefromsid nor the SMB3.1.1 POSIX extensions are      in effect), so that the cleared mode is propagated to the server      in the ACL / POSIX cases.    2. cifs_setattr_unix(): this function is only called when Unix      extensions are in effect, so the mode is always stored on the      server.  Remove the shortcut entirely so that the cleared mode is      always pushed.

CVE-2026-89642:

        In the Linux kernel, the following vulnerability has been resolved:  cifs: call pagecache_isize_extended() in cifs_setsize() when extending  cifs_setsize() calls truncate_pagecache() but skips pagecache_isize_extended() on extension.  truncate_setsize() shows the correct pattern:    i_size_write(inode, newsize);   if (newsize > oldsize)       pagecache_isize_extended(inode, oldsize, newsize);   truncate_pagecache(inode, newsize);  pagecache_isize_extended() zeroes the tail of the page straddling old EOF.  Without it, dirty bytes in that region can be written back to the server, exposing stale data in the newly extended range.

CVE-2026-89644:

        In the Linux kernel, the following vulnerability has been resolved:  btrfs: fix extent map leak in NOCOW direct I/O write  btrfs_dio_iomap_begin() calls btrfs_get_extent(), which returns an extent map reference that must be dropped on all exit paths.  For direct writes into a NOCOW range, btrfs_get_blocks_direct_write() keeps using that extent map and asks btrfs_create_dio_extent() to allocate the ordered extent. If that fails, for example because btrfs_alloc_ordered_extent() fails, the function returns the error without dropping the input extent map. The PREALLOC path avoided this by dropping the input extent map before replacing it with the newly created one.  Check the error from btrfs_create_dio_extent() before replacing the map and drop the input extent map on failure.

CVE-2026-89645:

        In the Linux kernel, the following vulnerability has been resolved:  btrfs: drop recovered reloc root refs on recovery failure  During relocation recovery, each fs root gets a reference to its relocation root. If loading or adding a later root fails, or if the first transaction commit fails, btrfs_recover_relocation() jumps to out_unset before merge_reloc_roots() and clean_dirty_subvols().  put_reloc_control() drops the list-owned relocation root references, but it does not clear fs_root->reloc_root or drop the references owned by those pointers. Mount cleanup only drops them when BTRFS_FS_ERROR is set, so an error such as -ENOMEM while processing a later root can leave references behind.  Keep temporary references to the fs roots associated during recovery. On failure, clear their reloc_root pointers and drop the corresponding references. Once the first transaction commit succeeds, drop only the temporary fs root references and let the normal merge and cleanup paths handle the relocation roots.  Fault injection on a pending-relocation image confirmed the cleanup gap. With an injected first-commit failure, 25 fs roots had reloc_root set with fs_error=0. With this fix, the same failure path drops that count to 0 before mount fails.

CVE-2026-89647:

        In the Linux kernel, the following vulnerability has been resolved:  ceph: do not repeat ceph_trim_dentries() if no progress possible  ceph_cap_reclaim_work() re-queues itself for as long as ceph_trim_dentries() returns -EAGAIN, which happens whenever a lease walk exhausts its `nr_to_scan` budget.  This creates a busy loop that consumes CPU without making any progress when there is nothing to reclaim: with no cap pressure (`count==0`) and every scanned lease still valid, each pass runs the full scan budget down to zero and returns `-EAGAIN`, only to be queued again immediately.  The dir-lease walk made this worse.  When `expire_dir_lease` is `false` (i.e. we have no intention of reclaiming dir leases), __dir_lease_check() returned `TOUCH` for every valid lease.  `TOUCH` moves the dentry to the tail of the list and resets `di->time` via __dentry_dir_lease_touch(), so a walk over N valid leases pointlessly rewrote the list, refreshed the timestamps (preventing them from ever aging out) and always drained `nr_to_scan`, guaranteeing the `-EAGAIN` requeue.  Fix this in three steps:   - Return `KEEP` instead of `TOUCH` when `expire_dir_lease` is    `false`.  If we are not going to reclaim the lease, leave it in    place instead of churning the list and resetting its timestamp; the    walk then terminates naturally (or via `STOP` at the first fresh    lease).   - Only return `-EAGAIN` from the first (dentry-lease) walk when something    was actually freed.  A full batch that frees nothing means retrying    the same list immediately is futile; fall through to the dir-lease    walk instead.   - After both walks, bail out with success (0) when nothing was freed    and there is no cap pressure (`count==0`).  There is no reason to    keep retrying when we are not over the cap limit and made no    progress.  Under real cap pressure (`count>0`) the reclaim path is unchanged and still retries via `-EAGAIN`.  Without this patch, I saw 500 ceph_trim_dentries() calls per second on our web servers.  This is very visible in `/proc/lock_stat` (5 minute capture):                class name    con-bounces    contentions   waittime-min   waittime-max waittime-total   waittime-avg    acq-bounces   acquisitions   holdtime-min   holdtime-max holdtime-total   holdtime-avg   &mdsc->dentry_list_lock:        126180         128218           0.04        8063.44    15986965.20         124.69        1573354        5296812           0.04        8291.28    74164526.48          14.00  -----------------------  &mdsc->dentry_list_lock         111736          [<000000007b11e319>] __ceph_dentry_dir_lease_touch+0x7c/0xa8  &mdsc->dentry_list_lock           2631          [<0000000050597999>] __dentry_leases_walk+0x64/0x2c8  &mdsc->dentry_list_lock           3878          [<00000000c0022f62>] __ceph_dentry_lease_touch+0x5c/0xa8  &mdsc->dentry_list_lock           9973          [<000000002f27cb6f>] __dentry_lease_unlist+0x50/0xa0  -----------------------  &mdsc->dentry_list_lock         123621          [<0000000050597999>] __dentry_leases_walk+0x64/0x2c8  &mdsc->dentry_list_lock           1822          [<000000007b11e319>] __ceph_dentry_dir_lease_touch+0x7c/0xa8  &mdsc->dentry_list_lock           2720          [<000000002f27cb6f>] __dentry_lease_unlist+0x50/0xa0  &mdsc->dentry_list_lock             55          [<00000000c0022f62>] __ceph_dentry_lease_touch+0x5c/0xa8  With this patch:                class name    con-bounces    contentions   waittime-min   waittime-max waittime-total   waittime-avg    acq-bounces   acquisitions   holdtime-min   holdtime-max holdtime-total   holdtime-avg   &mdsc->dentry_list_lock:          1203           1215           0.16         408.88       33082.88          27.23        4320501        7357389           0.04         500.64     1961578.00           0.27  -----------------------  &mdsc->dentry_list_lock           1029          [<000000003c9aea8a>] __ceph_dentry_dir_lease_touch+0x7c/0xa8  &mdsc->dentry_list_lock            1 ---truncated---

CVE-2026-89648:

        In the Linux kernel, the following vulnerability has been resolved:  ceph: cap delegated inode count in ceph_parse_deleg_inos()  ceph_parse_deleg_inos() decodes interval sets of delegated inode numbers from an MDS create-with-delegation reply. For each set it reads a 64-bit start and a 64-bit len with ceph_decode_64_safe(), which only validates that the eight bytes are present in the message, not the value, and then loops over len while inserting entries into s_delegated_inos.  len is fully attacker controlled. A malicious or compromised MDS can send one huge interval, many intervals in one reply, duplicate intervals, or repeated replies that accumulate delegated inodes on the same session. The original code bounded none of these and could spin the insert loop or grow the xarray without limit.  Bound both dimensions with a single enforcement point. Track the number of delegated inodes held by each MDS session in an atomic counter and grow it only in ceph_insert_deleg_ino(), which uses atomic_add_unless() to refuse to push the count past CEPH_MAX_DELEG_INOS. Because that helper is the only place the counter grows, the per-session population can never exceed the cap, so no separate per-session pre-check is needed. The counter is decremented when async create consumes a delegated inode or when an insert fails, incremented when a delegated inode is restored, initialized with the session xarray, and reset when reconnect destroys the xarray.  A per-session cap alone still lets one reply spin the insert loop on duplicate ranges without growing the counter, so also cap the aggregate interval length accepted from a single reply. Together these bound both the loop trip count per reply and the xarray population across replies.  The cap is a fixed, client-chosen constant rather than a value derived from the MDS. mds_client_prealloc_inos is a userspace MDS configuration option; it is never sent to the kernel client on the wire, and a server-supplied bound could not be trusted for a defensive limit in any case. The constant is set well above that option's documented default of 1000 (a generous multiple), so legitimate refill behavior is unaffected while the CPU and xarray memory a malformed delegation stream can consume stays bounded.  Impact: a malicious or compromised Ceph MDS can no longer make a client spin through an unbounded delegated-inode interval or grow one session's delegated-inode xarray without limit.

CVE-2026-89652:

        In the Linux kernel, the following vulnerability has been resolved:  ceph: bound copied dentry name length in NFS export get_name  ceph_get_name() copies the MDS-supplied name into the caller's NAME_MAX-sized buffer with memcpy(name, rinfo->dname, rinfo->dname_len) and then writes name[rinfo->dname_len] = 0, without checking dname_len against NAME_MAX. A malicious or buggy MDS that returns a LOOKUPNAME reply with dname_len > NAME_MAX overflows the buffer. __get_snap_name() copies rde->name / rde->name_len the same unchecked way.  Impact: a malicious or compromised Ceph MDS overflows the NAME_MAX name buffer in a client's NFS-export get_name path, a slab out-of-bounds write reported by KASAN. Reachable when a CephFS mount is re-exported over NFS.  Add ceph_export_copy_name(), which rejects lengths above NAME_MAX with -ENAMETOOLONG before the copy, and use it in both ceph_get_name() and __get_snap_name().

CVE-2026-89654:

        In the Linux kernel, the following vulnerability has been resolved:  ceph: fix UAF in check_new_map() on session freed during unlock  check_new_map() iterates mdsc->sessions[] and for each active session drops mdsc->mutex to perform per-session operations.  The forced-close path (rank removed from map) correctly takes a reference on s via ceph_get_mds_session() before releasing mdsc->mutex, but three other paths do not:    Path A (address changed):  mutex_unlock → mutex_lock(&s->s_mutex)   Path B (reconnect):        mutex_unlock → send_mds_reconnect(mdsc, s)   Path C (active transition): mutex_unlock → mutex_lock(&s->s_mutex)  Without the extra reference, another thread can acquire mdsc->mutex during the unlock window, call __unregister_session() which drops the last reference on s, and free it.  The original thread then accesses freed memory via s->s_mutex.  Fix by adding ceph_get_mds_session(s) before each mutex_unlock and ceph_put_mds_session(s) after the corresponding mutex_lock, matching the pattern already used in the forced-close path.  Race timeline (Path A):    Thread A (check_new_map)             Thread B (another map update     holds mdsc->mutex                      or session teardown)   --------------------------           --------------------------   s = mdsc->sessions[i]   (refcount == 1, held only by    sessions[] array)    mutex_unlock(&mdsc->mutex)                                --->    acquires mdsc->mutex                                        __unregister_session(mdsc, s)                                          sessions[i] = NULL                                          ceph_put_mds_session(s)                                            refcount: 1 -> 0                                            kfree(s)  <--- freed!    mutex_lock(&s->s_mutex)   UAF on freed s->s_mutex

CVE-2026-89659:

        In the Linux kernel, the following vulnerability has been resolved:  NFSD: Prevent client use-after-free during delegation revoke  A delegation stateid holds only a bare pointer to its owning nfs4_client and does not keep it alive.  The client survives its stateids only because __destroy_client() drains cl_delegations and cl_revoked before free_client() runs.  nfs4_laundromat() breaks that invariant: it unhashes an expired delegation from cl_delegations, drops deleg_lock, then revoke_delegation() relinks it onto cl_revoked under cl_lock.  In that window the delegation is on neither list, so client_has_state() can report no remaining state.  Every teardown path first requires cl_rpc_users to be zero, but the laundromat holds no such reference.  A client whose recalled delegation has just timed out can therefore reach free_client() while revoke_delegation() is still about to dereference cl_lock, a use-after-free.  Pin the client with cl_rpc_users across the revoke so teardown blocks until it completes, then reap the delegation from cl_revoked.  A client already expiring reaps its own, so skip it and leave the delegation on del_recall_lru.

CVE-2026-89666:

        In the Linux kernel, the following vulnerability has been resolved:  nfsd: reject out-of-range nseconds in NFSv3 SETATTR and create ops  A client can send an NFSv3 SETATTR, CREATE, MKDIR, SYMLINK or MKNOD carrying an atime or mtime whose nseconds field is out of range. The value is well-formed on the wire and decodes cleanly into a valid uint32, but it is not a valid timespec64: tv_nsec must be less than NSEC_PER_SEC.  Nothing in the setattr path clamps it. notify_change() runs the time through timestamp_truncate(), which does not reduce tv_nsec below NSEC_PER_SEC when the filesystem supports nanosecond granularity (s_time_gran == 1), and the inode atime/mtime setters store it verbatim (only ctime is normalized, via inode_set_ctime_to_ts()). The un-normalized value then corrupts on-disk metadata: ext4's ext4_encode_extra_time() shifts tv_nsec left by EXT4_EPOCH_BITS, which overflows the 32-bit extra field and clobbers the seconds-epoch bits, so the stored seconds (and thus the year) are wrong on read-back. XFS with bigtime mis-stores the timestamp for the same reason.  Validate the client-supplied atime/mtime in the proc handlers and return NFS3ERR_INVAL before anything is changed. RFC 1813 lists NFS3ERR_INVAL for SETATTR and describes it as the error for a value the server 'can not store ... in its own representation'; the client maps it to EINVAL.  Checking in the proc handlers, rather than in nfsd_setattr(), keeps the rejection in front of object creation. The create operations create the object before nfsd_create_setattr() runs, so a late failure would leave the new object behind and turn a non-idempotent request into a namespace change that reports failure. The check is therefore done up front, for the create operations before the object is created.  tv_nsec is a long, so the comparison casts it to unsigned long (the same width) rather than to u32, matching timespec64_valid(). A u32 cast would truncate on 64-bit; the unsigned long cast also rejects a value that became negative when an out-of-range u32 wire nseconds was assigned to a 32-bit long.  Only client-supplied times are checked: SET_TO_SERVER_TIME requests carry no client value. The sattrguard3 ctime is deliberately left alone: an out-of-range guard simply never matches the object's ctime and yields NFS3ERR_NOT_SYNC via the existing guardtime comparison, which is the protocol-correct outcome rather than rejecting the request.

CVE-2026-89671:

        In the Linux kernel, the following vulnerability has been resolved:  nfsd: gate nfs3 setacl by argp->mask  nfsd3_proc_setacl() calls set_posix_acl() unconditionally for both ACL_TYPE_ACCESS and ACL_TYPE_DEFAULT, passing argp->acl_access and argp->acl_default verbatim. The NFSv3 ACL decoder only populates those pointers when the corresponding mask bit is set:      nfs3svc_decode_setaclargs()       if (args->mask & NFS_ACL)    decode into acl_access       if (args->mask & NFS_DFACL)  decode into acl_default       /* otherwise the pointer stays NULL (pc_argzero) */      nfsd3_proc_setacl()       set_posix_acl(.., ACL_TYPE_ACCESS,  argp->acl_access)       set_posix_acl(.., ACL_TYPE_DEFAULT, argp->acl_default)  set_posix_acl(idmap, dentry, type, NULL) is the VFS "remove this ACL type" operation. A NULL pointer that means "the client did not send this arm" is therefore indistinguishable from "the client asked to remove this ACL". A SETACL with mask=NFS_ACL silently drops the directory's default ACL; mask=0 drops both.  The sibling nfsd3_proc_getacl() already consults argp->mask before touching each arm; mirror that in setacl.  Fix by wrapping each set_posix_acl() call in the matching mask bit check and initializing error to 0 before inode_lock so that a request with neither bit set leaves the on-disk ACLs untouched and returns nfs_ok. The out_drop_lock path and the unconditional posix_acl_release() at out: are preserved; both NULL-tolerate the skipped arms.

CVE-2026-89672:

        In the Linux kernel, the following vulnerability has been resolved:  nfsd: gate nfs2 setacl by argp->mask  The NFSACL v2 SETACL path shares the decoder convention used by its v3 sibling: nfsaclsvc_decode_setaclargs() fills in argp->acl_access only when NFS_ACL is set in the request mask and argp->acl_default only when NFS_DFACL is set, leaving the other pointer NULL because the argument buffer is zeroed up to pc_argzero before decode.  nfsacld_proc_setacl() then hands both pointers to set_posix_acl() unconditionally. set_posix_acl(idmap, dentry, type, NULL) is the VFS "remove this ACL type" operation, so an omitted arm is indistinguishable from an explicit request to delete that ACL. A SETACL carrying only NFS_ACL silently strips the directory's default ACL; mask=0 strips both.  This is the same defect just fixed in nfsd3_proc_setacl(); apply the same remedy. Gate each set_posix_acl() call on its mask bit and initialize error to 0 so that a request with neither bit set leaves the on-disk ACLs untouched and returns success. The out_drop_lock path and the unconditional posix_acl_release() in nfsaclsvc_release_setacl() already tolerate the skipped arms.

CVE-2026-89675:

        In the Linux kernel, the following vulnerability has been resolved:  nfsd: fix UAF in async copy cancel and shutdown  An async copy could be freed or used after free while a teardown caller (OFFLOAD_CANCEL, nfsd4_shutdown_copy, nfsd4_cancel_copy_by_sb) raced the copy kthread:    - find_async_copy() bumped copy->refcount but left the copy on     clp->async_copies, so the reaper's cleanup_async_copy() could run     release_copy_files() concurrently with a cancel/shutdown caller. Both     put and NULL nf_src/nf_dst without a common lock, double-putting the     nfsd_file and freeing it early.    - nfsd4_do_async_copy() set NFSD4_COPY_F_STOPPED before its final uses     of the copy (nfsd_update_cmtime_attr() on copy->nf_dst,     nfsd4_send_cb_offload()). nfsd4_stop_copy() treats a set STOPPED bit     as "kthread done, skip kthread_stop()", so a teardown caller ran     release_copy_files() -- which puts and NULLs nf_dst -- while the     kthread still dereferenced it (NULL/UAF).    - copy->copy_task was never pinned. The one-shot kthread self-reaps on     return, so kthread_stop()'s get_task_struct() could touch a freed     task_struct.    - co_cb is embedded in the copy, but nfsd4_send_cb_offload() held a     reference only on the client, so a concurrent teardown could free     the copy while the CB_OFFLOAD callback was in flight.  Fix the teardown lifetime as a whole:    - find_async_copy() unlinks the copy (clear cp_clp, list_del_init)     under async_lock; the cancel, shutdown, and sb-cancel paths drop the     list-membership reference via nfs4_put_copy() after nfsd4_stop_copy().     Drop the now-redundant list_del fixup from cleanup_async_copy().    - Because unlinking hides the copy from the reaper, its     cleanup_async_copy() can no longer remove the copy's s2s_cp_stateids     entry; the cancel/shutdown/sb-cancel paths now call     nfs4_free_copy_state() themselves (while cp_clp is still valid) so     the entry does not dangle at freed memory for the laundromat and     manage_cpntf_state() to dereference.    - Give the kthread its own reference, taken in nfsd4_copy() before     wake_up_process() and dropped at the end of nfsd4_do_async_copy();     call wake_up_process() before list_add().    - Pin the task_struct with get_task_struct() in nfsd4_copy(), released     in nfs4_put_copy(), so kthread_stop() is safe whenever the kthread     exits. Set NFSD4_COPY_F_STOPPED only in nfsd4_stop_copy(), which now     always kthread_stop()s before release_copy_files(); completion is     still reported via NFSD4_COPY_F_COMPLETED, so     nfsd4_has_active_async_copies() is unaffected. Each teardown caller     removes the copy from clp->async_copies first, so kthread_stop() runs     exactly once.    - Take a copy reference in nfsd4_send_cb_offload(), dropped in     nfsd4_cb_offload_release(). The kthread still holds its own reference     there, so the refcount_inc() cannot race the final free.    - Read cp_clp with smp_load_acquire() to pair with the unordered     set_bit()/clear_bit() writers (Documentation/atomic_bitops.rst).

CVE-2026-89676:

        In the Linux kernel, the following vulnerability has been resolved:  nfsd: fix stale s2s_cp_stateids IDR entry for async COPY  For an async COPY, nfsd4_copy() called nfs4_init_copy_state() before dup_copy_fields(), so the s2s_cp_stateids IDR was pointed at &u->copy->cp_stateid -- memory in the per-rqstp COMPOUND buffer that is reused by the next request. dup_copy_fields() copies only the value into async_copy, so the IDR slot dangled at the transient buffer for the whole background copy. Any IDR walker then dereferences reused request memory: the laundromat reads cs_type from it and, if the bytes look like an expired NFS4_COPYNOTIFY_STID, follows into refcount_dec()/idr_remove()/kfree() on garbage; manage_cpntf_state() has the same exposure via idr_find().  Duplicate the fields first, then register the stateid on the stable async_copy. result->cb_stateid is unchanged.

CVE-2026-89680:

        In the Linux kernel, the following vulnerability has been resolved:  nfsd: fix nfsd_file leak on inter-server COPY setup failure  When nfsd4_setup_inter_ssc() fails, nfsd4_copy() returns nfserr_offload_denied directly, bypassing the out: label where release_copy_files() would drop the nf_dst reference taken by nfs4_preprocess_stateid_op(). Each failed inter-server COPY leaks one nfsd_file, pinning file/inode/dentry/vfsmount.  Fix by setting status and jumping to out: instead of returning directly.

CVE-2026-89682:

        In the Linux kernel, the following vulnerability has been resolved:  nfsd: fix fcache_disposal UAF by inlining dispose state into nfsd_net  nfsd_file_dispose_list_delayed() defers fput() to nfsd service threads via a per-net freeme queue, preventing the shrinker and GC worker from bearing the cost of closing files (see ffb402596147).  However, the queue lives in a separately-allocated struct nfsd_fcache_disposal that is freed by nfsd_free_fcache_disposal_net() during per-net teardown. The global shrinker, laundrette, and fsnotify callbacks can still be inside nfsd_file_dispose_list_delayed() dereferencing that pointer, causing a use-after-free.  Inline the spinlock and freeme list directly into struct nfsd_net (as fcache_dispose_lock and fcache_dispose_list), eliminating the separately allocated struct nfsd_fcache_disposal entirely.  These fields now have the same lifetime as the net namespace itself, so there is no dangling pointer to chase.  nfsd_file_cache_start_net() now just initializes the inline fields and cannot fail due to allocation.  nfsd_file_cache_shutdown_net() drains the inline list directly instead of freeing a separate struct.  The alloc/free helpers are removed.

CVE-2026-89685:

        In the Linux kernel, the following vulnerability has been resolved:  nfsd: fix clock domain mismatch in clients_still_reclaiming()  clients_still_reclaiming() computes a deadline from nn->boot_time (CLOCK_REALTIME, ~1.7 billion) but compares it against ktime_get_boottime_seconds() (CLOCK_BOOTTIME, seconds since boot). The comparison is always false — it would take ~54 years of uptime for BOOTTIME to exceed the REALTIME-derived deadline.  This means any client can hold the server in grace indefinitely by sending CLAIM_PREVIOUS OPEN requests, blocking all non-reclaim operations for all other clients.  Add boot_time_bt (CLOCK_BOOTTIME) alongside the existing boot_time and use it for the deadline computation. boot_time (CLOCK_REALTIME) is preserved for its cl_boot clientid-nonce role.

CVE-2026-89686:

        In the Linux kernel, the following vulnerability has been resolved:  nfsd: fix BUG_ON in nfsd4_alloc_layout_stateid on racing delegation revoke  nfsd4_alloc_layout_stateid reads fp->fi_deleg_file without holding fi_lock when the parent stateid is a delegation. A concurrent delegation revoke via the laundromat can clear fi_deleg_file under fi_lock, causing nfsd_file_get() to return NULL and triggering the BUG_ON.  This race is client-reachable: two NFS clients can trigger it by having one hold a delegation while another opens the same file to force a recall. When the first client doesn't respond to the recall, the laundromat revokes it. A concurrent LAYOUTGET from any client using the delegation stateid hits the race window.  Fix this by taking fi_lock around the fi_deleg_file read in the SC_TYPE_DELEG path, matching the locking discipline of the find_any_file() arm, and replacing the BUG_ON with a graceful error return that cleans up the partially-initialized layout stateid.

CVE-2026-89693:

        In the Linux kernel, the following vulnerability has been resolved:  nfsd: check nfsd4_acl_to_attr() return value in nfsd4_create()  nfsd4_create() stores the return value of nfsd4_acl_to_attr() in status, but the switch(create->cr_type) block unconditionally overwrites it in every branch. ACL translation errors are silently discarded, and the CREATE proceeds without the requested ACL.  Add an early exit check after nfsd4_acl_to_attr(), matching the pattern already used in nfsd4_setattr().  [ cel: prefer NFS4ERR_BADTYPE over NFS4ERR_ATTRNOTSUPP ]

CVE-2026-89702:

        In the Linux kernel, the following vulnerability has been resolved:  nfsd: size fh_verify server sockaddr slot by xpt_locallen  The nfsd_fh_verify and nfsd_fh_verify_err tracepoints declare the server sockaddr slot sized by xpt_remotelen but fill it from xpt_local using xpt_locallen:      TP_STRUCT__entry(             ...             __sockaddr(server, rqstp->rq_xprt->xpt_remotelen)             ...     )     TP_fast_assign(             ...             __assign_sockaddr(server, &rqstp->rq_xprt->xpt_local,                               rqstp->rq_xprt->xpt_locallen);             ...     )  When xpt_locallen exceeds xpt_remotelen, __assign_sockaddr's memcpy writes past the reserved ring-buffer slot. In the reverse direction (xpt_locallen < xpt_remotelen) the slot is oversized and the unwritten tail leaks prior ring-buffer contents to trace consumers.  The write-past-end case is reachable on NFS/UDP. svc_xprt_set_remote() is only called from svc_tcp_accept() (net/sunrpc/svcsock.c) and from the RDMA connect path; svc_create_socket() for UDP calls only svc_xprt_set_local(), so xpt_remotelen stays 0 for the xprt's lifetime. Every fh_verify trace for an NFSv2/v3-over-UDP request then copies 16 or 28 bytes from xpt_local into a zero-byte slot.  The other NFSD tracepoints that record the server address (NFSD_TRACE_PROC_CALL_FIELDS, NFSD_TRACE_PROC_RES_FIELDS, SVC_RQST_ENDPOINT_FIELDS) already size the server slot by xpt_locallen; nfsd_fh_verify and nfsd_fh_verify_err were the only exceptions.  Fix by sizing the server slot with xpt_locallen so the declared slot matches the copy length. The client slot and its assignment already agree on xpt_remotelen and are left untouched.

CVE-2026-89707:

        In the Linux kernel, the following vulnerability has been resolved:  nfsd: release path refs on follow_down() error  nfsd_cross_mnt() initializes a local struct path with mntget() and dget() before calling follow_down(). On a negative return the error arm jumps to out without releasing those references:      err = follow_down(&path, follow_flags);     if (err < 0)             goto out;  follow_down() never drops the caller's entry-time refs on any error sub-case; for example a pre-cross d_manage() failure leaves path untouched, so the mntget()/dget() taken on entry survive the call.  Every other early-exit arm in nfsd_cross_mnt() (other-namespace return, IS_ERR(exp2), and the success tail after the swap) already calls path_put(&path); the err < 0 arm is the lone omission. The leak inflates mnt_count and d_count on each failed cross-mount, blocking umount and pinning dentries against the shrinker, and is reachable by any authenticated NFS client through nfsd_lookup_dentry or the NFSv4 READDIR encode path.  Fix by calling path_put(&path) before the goto out in the err < 0 arm so the entry-time refs are released on all follow_down() error returns.

CVE-2026-89708:

        In the Linux kernel, the following vulnerability has been resolved:  nfsd: RCU-protect cl_cb_session to fix use-after-free on session teardown  After a DESTROY_SESSION the per-session teardown path can free a session while rpciod still holds an inflight callback rpc_task that dereferences clp->cl_cb_session.  nfsd4_probe_callback_sync() flushes cl_callback_wq, but once nfsd4_run_cb_work() has called rpc_call_async() the rpc_task lives on rpciod; flushing the workqueue does not wait for it.  rpc_shutdown_client() does drain rpciod tasks, but uses a 1-second wait_event_timeout — tasks stuck in rpc_delay() (e.g. 2-second NFS4ERR_DELAY retries) can outlive the drain.      destroy path                       rpciod     ------------                       ------     unhash_session(ses)     nfsd4_probe_callback_sync(clp)       flush_workqueue(cl_callback_wq)       /* returns; rpc_task still live */     nfsd4_put_session_locked(ses)     free_session(ses) -> kfree(ses)                                        nfsd4_cb_sequence_done()                                          reads cb_clp->cl_cb_session                                          /* freed slab */  A second window exists in nfsd4_process_cb_update().  When __nfsd4_find_backchannel() returns NULL because unhash_session() has already removed the destroyed session from cl_sessions, setup_callback_client() takes the v4.1 early return so clp->cl_cb_session = ses never fires and the field retains a pointer to the about-to-be-freed session.  Fix both by converting cl_cb_session to an RCU-protected pointer:    - Move the cl_cb_session = ses assignment in setup_callback_client()     to after rpc_create() succeeds, so it is only published when a     working backchannel exists.  Clear cl_cb_session on the error     return in nfsd4_process_cb_update().  Both stores use     rcu_assign_pointer().    - Annotate cl_cb_session with __rcu.  All rpciod-side readers use     rcu_read_lock()/rcu_dereference() and check for NULL, bailing to     the appropriate error or requeue path:     encode_cb_sequence4args(), decode_cb_sequence4resok(),     nfsd41_cb_get_slot(), nfsd41_cb_release_slot(),     nfsd4_cb_prepare(), and nfsd4_cb_sequence_done().    - Switch __free_session() from kfree() to kfree_rcu() so the     session slab is not reclaimed until after an RCU grace period,     guaranteeing that rpciod readers inside rcu_read_lock() never     dereference freed memory.    - Pass the session pointer to the nfsd_cb_seq_status and     nfsd_cb_free_slot tracepoints instead of having them re-read     cl_cb_session.    - nfsd4_cb_prepare() calls rpc_exit() when the session is NULL,     routing through the done/release path to requeue the callback.

CVE-2026-89709:

        In the Linux kernel, the following vulnerability has been resolved:  lockd, nfsd: RCU-protect nlmsvc_ops dispatch  nlmsvc_ops is published by nfsd_lockd_init() and cleared by nfsd_lockd_shutdown() with plain stores, while lockd dereferences it unguarded from dispatch sites in fs/lockd/svcsubs.c. The pointer targets nfsd's .rodata and the fopen/fclose callbacks live in nfsd's .text, so a stale load after rmmod nfsd results in either a NULL deref or a module-text use-after-free.  Declare nlmsvc_ops as __rcu, publish via rcu_assign_pointer(), clear via RCU_INIT_POINTER() + synchronize_rcu(). Add a struct module *owner field to nlmsvc_binding and pin the module across indirect calls with try_module_get/module_put. When the binding is torn down, fall back to fput() to avoid leaking struct file references.

CVE-2026-89713:

        In the Linux kernel, the following vulnerability has been resolved:  NFSD: check truncate permission under inode lock  nfsd_setattr() checks whether a size update needs NFSD_MAY_TRUNC before it takes inode_lock(). The comparison uses the file size sampled by that unlocked read, but the actual ATTR_SIZE update is applied later under inode_lock() by notify_change().  This leaves a TOCTOU window for append-only files. If a client sends a SETATTR that does not shrink the file at the time of the unlocked sample, a concurrent append can extend the file before nfsd_setattr() takes inode_lock(). notify_change() then applies a real truncation without the NFSD_MAY_TRUNC check that rejects IS_APPEND(inode). The VFS truncate syscall paths perform their own append-only checks before calling notify_change(), so NFSD must make this decision against the locked size it is about to change.  Split the write-count acquisition from the truncation permission check. Keep get_write_access() before the locked setattr work, then recheck whether the requested size is below i_size_read(inode) after inode_lock() has been acquired and before notify_change(ATTR_SIZE). This also avoids the plain unlocked inode->i_size load.

CVE-2026-89718:

        In the Linux kernel, the following vulnerability has been resolved:  zram: fix out-of-bounds access in writeback_store()  Patch series "zram: fix stale scan bounds after reinitialization".  Both writeback_store() and read_block_state() derive their table scan bounds from zram->disksize before acquiring dev_lock.  If the device is reset and reinitialized with a smaller disksize between that read and lock acquisition, the bound can describe the old table while the scan operates on the new one.  This can lead to out-of-bounds slot accesses.  Move both bound calculations under dev_lock so each bound remains consistent with the table throughout its scan.  Keep the fixes separate because the affected interfaces originate from different commits and can be backported independently.   This patch (of 2):  writeback_store() calculates the table scan bounds before taking dev_lock. A reset followed by reconfiguration with a smaller disksize can therefore replace zram->table while writeback_store() is waiting for the lock.  Once it acquires the lock, it sees an initialized device but scans the new table using the old upper bound, resulting in an out-of-bounds access.  Calculate the number of pages while holding dev_lock so the scan bound matches the table protected by the lock.

CVE-2026-89719:

        In the Linux kernel, the following vulnerability has been resolved:  zram: fix out-of-bounds access in read_block_state()  read_block_state() calculates nr_pages before taking dev_lock.  If the device is reset and reinitialized with a smaller disksize before lock acquisition, nr_pages still describes the old table.  The subsequent loop can then call slot_lock() past the end of the newly allocated table.  Read disksize after acquiring dev_lock and checking that the device is initialized.  The read lock then keeps the table and its bound stable for the duration of the scan.

CVE-2026-89722:

        In the Linux kernel, the following vulnerability has been resolved:  PCI/sysfs: Fix out-of-bounds read in pci_write_legacy_io()  pci_write_legacy_io() loads 4 bytes from the kernfs write buffer regardless of how many bytes userspace wrote:    if (count != 1 && count != 2 && count != 4)           return -EINVAL;    return pci_legacy_write(bus, off, *(u32 *)buf, count);  kernfs_fop_write_iter() allocates the buffer with kmalloc(len + 1), so a 1-byte write to the legacy_io sysfs file allocates 2 bytes and the unconditional u32 load reads up to 2 bytes past the end of the allocation, which KASAN reports as a slab-out-of-bounds read. Similarly, a 2-byte write overreads by 1 byte.  Thus, read only the number of bytes requested using get_unaligned_le16() and get_unaligned_le32() for the 2 and 4 byte cases, interpreting the buffer as little-endian to match the byte ordering of PCI I/O port space.  The PowerPC implementation previously compensated for the generic code's native-endian 32-bit load by shifting the value into place for the 1 and 2 byte cases.  The shifts were only correct on big-endian kernels.  On little-endian PowerPC (POWER8 and later), they extracted the wrong bytes, so a 1-byte write wrote an out-of-bounds byte instead of the requested value.  On big-endian, the native load also caused out_le16() and out_le32() to reverse the user's bytes on the wire for 2 and 4 byte writes.  The little-endian helpers resolve both issues, so the shifts are removed.  No changes are needed for the Alpha platform.  The legacy_io file is root-only and exists only on Alpha and PowerPC, the two architectures that define HAVE_PCI_LEGACY.

CVE-2026-89738:

        In the Linux kernel, the following vulnerability has been resolved:  usb: gadget: at91_udc: drain polled-VBUS timer/work before udc is freed  In polled-VBUS mode (board.vbus_pin && board.vbus_polled), probe arms a self-restarting cycle: at91_vbus_timer() schedules vbus_timer_work, and at91_vbus_timer_work() calls at91_vbus_update() and re-arms the timer via mod_timer(). Both recover the same udc through container_of and dereference it on every iteration.  Neither teardown path cancels this cycle. udc is devm-allocated, so it is freed after at91udc_remove() returns, and is likewise freed when probe fails and devres runs. A timer callback or work item that is pending or running at either point dereferences the freed udc.  Add at91_udc_shutdown_vbus_timer() and call it from at91udc_remove() and from the usb_add_gadget_udc() failure path in probe; the remaining probe error paths fail before the timer is armed. timer_shutdown_sync() waits for a running callback and clears timer->function, which makes the work handler's mod_timer() a permanent no-op; cancel_work_sync() then drains any pending or running work whose re-arm attempt now does nothing. The timer must be shut down first, since cancelling the work alone would let the timer re-queue it. The guard mirrors probe: in IRQ mode the timer and work_struct are never initialized.  This does not require a fault; a normal driver unbind can interleave with an already queued work item.  This issue was found by an in-house static analysis tool.

CVE-2026-89740:

        In the Linux kernel, the following vulnerability has been resolved:  serial: imx: serialize imx_uart_ports[] lifetime  imx_uart_probe() publishes its devm-allocated port in imx_uart_ports[] before uart_add_one_port() because console setup uses the table. The entry is not cleared when adding the port fails or after removal, leaving a dangling pointer.  A sibling probe can register the shared console through that stale entry. This was reproduced under KASAN on QEMU mcimx6ul-evk by unbinding a sibling UART, unbinding the console UART and rebinding the sibling.  Keep the entry valid through uart_remove_one_port(), then clear it. Protect port addition and removal together with their table updates so sibling operations cannot interleave. Reject an occupied slot rather than clobbering an active port during a duplicate-line probe.

CVE-2026-89757:

        In the Linux kernel, the following vulnerability has been resolved:  mm/mglru: fix and remove redundant unevictable folio handling  sort_folio() has a shortcut for moving folios that are no longer evictable but are still sitting on a generation list.  However, this shortcut is buggy.  It does not follow the PG_lru usage convention, and it has a more serious issue.  Unevictable folios are not threaded on lists[LRU_UNEVICTABLE], so that folio->lru can be reused to hold folio->mlock_count (see the comment in lruvec_init()).  Hence lruvec_add_folio() skips the list_add() for them, and every other place that turns a folio unevictable initialises mlock_count explicitly: lru_add() sets it to 0, __mlock_folio() and __mlock_new_folio() set it to !!folio_test_mlocked(folio).  sort_folio() sets nothing, and the lru_gen_del_folio() right above it may have already poisoned folio->lru via list_del(), so mlock_count ends up aliasing LIST_POISON2, which reads as 0x122, i.e.  290.  The result is user visible.  On munlock, __munlock_folio() decrements that bogus count, finds it still non-zero and bails out before clearing PG_mlocked, so the folio remains unevictable and the Mlocked accounting stays inflated until the folio is freed.  The shortcut also touches the LRU flags in the wrong order.  It calls lru_gen_del_folio() while PG_lru is still set, so a concurrent folio_test_clear_lru() (e.g.  compaction, folio_isolate_lru()) can succeed on a folio that has already been taken off the generation list, which may lead to unexpected behavior.  So fix it by isolating them as common folios and letting the generic shrink path cull them.  This matches the classical LRU behavior, and there should be no visible effect on the generic eviction or isolation behavior.  There is no performance concern either, such a folio goes through this once, and then it is off the generation lists for good.

CVE-2026-89759:

        In the Linux kernel, the following vulnerability has been resolved:  mm/kmemleak: avoid soft lockup when scanning task stacks  Patch series "mm/kmemleak: avoid soft lockup when scanning task", v3.  kmemleak_scan() scans every task stack under one rcu_read_lock() with no reschedule point, which can trip the soft lockup watchdog on hosts with very many threads.  That prints the following message, depending on the workload+host configuration:        watchdog: BUG: soft lockup - CPU#35 stuck for 22s! [kmemleak:537]        scan_block        kmemleak_scan        kmemleak_scan_thread        kthread  Patch 1 walks the tasks with find_ge_pid() so the scan reschedules between tasks  Patches 2-3 let the scan loops stop early once a scan is interrupted.   This patch (of 3):  kmemleak_scan() walks every thread and scans its kernel stack under a single rcu_read_lock() with no reschedule point.  On a host with very many threads -- amplified by KASAN/lockdep in debug builds -- this loop can hog a CPU long enough to trip the soft lockup watchdog:    watchdog: BUG: soft lockup - CPU#35 stuck for 22s! [kmemleak:537]    scan_block    kmemleak_scan    kmemleak_scan_thread    kthread  A cond_resched() cannot be added directly: the loop runs inside an RCU read-side critical section.  Walk the tasks one PID at a time with find_ge_pid(), taking the RCU read lock only to look up and pin each task.  The stack is then scanned with no lock held, so cond_resched() runs between tasks and the scan stops early on scan_should_stop().  This follows the next_tgid()/task_seq_get_next() iteration pattern and keeps each RCU critical section short.

CVE-2026-89761:

        In the Linux kernel, the following vulnerability has been resolved:  apparmor: fix out-of-bounds write when null terminating a label vec  aa_vec_unique() null terminates at vec[n - dups] when VEC_FLAG_TERMINATE is passed. If the components are all distinct no duplicates are dropped, dups is 0 and the terminator goes to vec[n], so the caller has to provide room for n + 1 entries.  aa_label_strn_parse() sets up its vector with vec_setup(profile, vec, len, gfp) and then calls aa_vec_unique(vec, len, VEC_FLAG_TERMINATE), but vec_setup() does not reserve the terminator entry. Up to LOCAL_VEC_ENTRIES it uses the local array of LOCAL_VEC_ENTRIES pointers, above that it allocates exactly len pointers. The terminator therefore lands one entry past the end of the local array when len is LOCAL_VEC_ENTRIES, and one entry past the end of the allocation when len is larger.  len comes from the number of "//&" separated components in the label name and label_count_strn_entries() does not bound it. An unprivileged task reaches the parse by writing to /proc/self/attr/apparmor/current or through lsm_set_self_attr(2), both of which go through do_setattr(), and the name is parsed before the change_profile permission is checked. The query_label() path behind the securityfs .access file, which is mode 0666, performs no permission check at all. Every component has to resolve to a loaded profile, so a system with policy loaded is required.  The other two VEC_FLAG_TERMINATE users work on a label vec that aa_label_alloc() has already sized with "+ 1 for null terminator entry on vec". Reserve the same entry in vec_setup() and DEFINE_VEC(). Passing len + 1 from the caller instead would move len == LOCAL_VEC_ENTRIES out of the local array and into kzalloc().

CVE-2026-89762:

        In the Linux kernel, the following vulnerability has been resolved:  apparmor: fix cred UAF caused by begin_current_label_crit_section()  AppArmor's begin_current_label_crit_section() is a scary function called from lots of LSM hooks (in particular VFS/socket-related ones) that checks if the label referenced by the current creds is marked FLAG_STALE, and if so, attempts to use aa_replace_current_label() to replace the creds with an updated version that uses a new label.  The first problem with this is that it would directly lead to UAF of `struct cred` if anything in the kernel takes a pointer to the current creds and accesses these past a security hook invocation that replaces creds, like so: ``` const struct cred *cred = current_cred(); alloc_file_pseudo(...); uid_t uid = cred->euid; ``` I don't know if anything in the kernel actually does this, but I think it is very surprising that this pattern could lead to UAF.  The second problem is that things go wrong when aa_replace_current_label() runs with overridden credentials. aa_replace_current_label() bails out if `current_cred() != current_real_cred()` (mirroring the check in proc_pid_attr_write()), but this check can't actually reliably detect overridden credentials because the overridden creds can be the same as the objective creds.  So in approximately the following scenario, things go wrong:  1. task begins with <creds A> (as both objective and subjective creds),    with refcount=2 2. task grabs an extra reference on <creds A> for overriding 3. task calls override_creds(<creds A>), which returns a pointer to the old    subjective creds (<creds A>) 4. task enters AppArmor LSM hook 5. AppArmor checks that objective/subjective creds are equal 6. AppArmor replaces both cred pointers with <creds B> and drops 2 refs on    <creds A> 7. task leaves AppArmor LSM hook 8. task calls revert_creds(<creds A>) 9. now task->cred is <creds A> while task->real_cred is <creds B>, but the    task_struct logically holds two references to <creds B> 10. another task drops the extra reference on <creds A> that was used for     overriding, refcount drops to 0 11. now task->real_cred points to freed creds  At this point, any access to current_cred() will be UAF.  I have a test case where I run aa-disable on a profile while a process using that profile is blocked on splice() from a FUSE passthrough file into a full pipe; after the profile update, the pipe becomes empty, splice() resumes, the credentials go out of sync, and a subsequent getuid() syscall results in a KASAN UAF splat.  To fix this, instead of directly replacing creds, do it via task_work that will run at the end of the current syscall. (The point in time at which the cred replacement happens should have no correctness impact; it is just a performance optimization to avoid unnecessarily touching the refcount of the new label.)  Note that AppArmor still performs direct cred replacements in the sb_pivotroot LSM hook after this change, and that direct cred replacements can still happen in VFS ->write() callbacks via proc_pid_attr_write().  There are two options for what to do with aa_dup_task_ctx(): Either explicitly reset new->label_replacement_pending after the entire aa_task_ctx has been copied, or switch to manually copying members over. I am switching to manually copying members over because that should make bugs more obvious.

CVE-2026-89763:

        In the Linux kernel, the following vulnerability has been resolved:  KEYS: trusted: Fix TPM teardown ordering  trusted_tpm_exit() drops the TPM chip reference and frees the digest array before unregistering the trusted key type. key_type_lookup() holds key_types_sem for reading until the key operation finishes, while unregister_key_type() takes it for writing. It therefore provides the synchronization point that must precede backend teardown.  The current order permits this interleaving:    CPU 0                              CPU 1   trusted_tpm_exit()                 key_type_lookup("trusted")     put_device(&chip->dev)             trusted_tpm_seal()     kfree(digests)                       pcrlock()     unregister_key_type()                  tpm_pcr_extend(..., digests)  CPU 1 can consequently dereference the freed digest array. The chip can also be released before callbacks stop using it.  KASAN reported:    BUG: KASAN: slab-use-after-free in tpm_pcr_extend+0x1f0/0x200   Read of size 2 at addr ffff88810872d000 by task poc/89   Call Trace:     tpm_pcr_extend+0x1f0/0x200     pcrlock+0x42/0x70 [trusted]     trusted_tpm_seal+0x1b6/0x570 [trusted]     trusted_instantiate+0x293/0x340 [trusted]     __key_instantiate_and_link+0xb2/0x2b0     __key_create_or_update+0x61e/0xb50     __do_sys_add_key+0x1b8/0x310   Allocated by task 88:     __kmalloc_noprof+0x1a7/0x490     do_one_initcall+0xa1/0x390     do_init_module+0x2df/0x840   Freed by task 90:     kfree+0x131/0x3c0     trusted_tpm_exit+0x59/0xa0 [trusted]     __do_sys_delete_module+0x346/0x510  Move unregister_key_type() before releasing either resource. This stops new lookups and waits for in-flight key operations to finish before the backend state is destroyed.

CVE-2026-89788:

        In the Linux kernel, the following vulnerability has been resolved:  ksmbd: fix tree connection use-after-free in smb2_tree_connect()  ksmbd_tree_conn_connect() publishes a new tree connection in sess->tree_conns with a single reference and returns its pointer to smb2_tree_connect(). The handler continues to initialize the object and build the response after publication. A concurrent session logoff can erase the connection and drop that reference, freeing the object while the handler still uses it.  BUG: KASAN: slab-use-after-free in smb2_tree_connect+0xe3d/0xf90   smb2_tree_connect (fs/smb/server/smb2pdu.c:2872)   handle_ksmbd_work   process_one_work   worker_thread   kthread  After xa_store() succeeds, take a second reference before releasing tree_conns_lock. The original reference belongs to the xarray entry and the second belongs to the creating smb2_tree_connect() handler.  Keep the references balanced in every path:  - On normal exit or an error after publication, smb2_tree_connect()   drops its creator reference. Error cleanup also calls   ksmbd_tree_conn_disconnect(), which drops the xarray reference only if   it removes the exact entry. - SMB2 TREE_DISCONNECT uses the same helper to remove the entry and drop   its xarray reference. The request's existing lookup reference remains   owned by the request and is released by the existing cleanup. - Session LOGOFF removes each entry and drops its xarray reference. If   it wins the race, later cleanup sees that the entry is gone and does   not drop that reference again.  To enforce this ownership, claim the disconnected state and erase the exact entry atomically under tree_conns_lock. This guarantees one drop for the xarray reference and one drop by each in-flight user, regardless of which teardown path wins. If logoff removes the entry before initialization completes, fail the connect instead of marking the detached object TREE_CONNECTED.

CVE-2026-89793:

        In the Linux kernel, the following vulnerability has been resolved:  ublk: clear VM_MAYWRITE on read-only ublk char device mmap  ublk_ch_mmap() rejects mmap requests with VM_WRITE set, but never clears VM_MAYWRITE on the resulting read-only mapping. This allows a userspace daemon to mmap the per-queue command buffer PROT_READ, then upgrade it to PROT_WRITE via mprotect(), since VM_MAYWRITE was never cleared.  The command buffer holds struct ublksrv_io_desc entries that are kernel-written ABI; a writable mapping lets an unprivileged daemon process corrupt fields such as addr, op_flags, nr_sectors, and start_sector.  Same bug class as the drm/panthor and drm/vc4 VM_MAYWRITE fixes, and the 2026-08-13 ptp/vmclock fix (a5edadbae57e).  Verified via mprotect() PoC: before the fix, a PROT_READ mapping can be upgraded to PROT_READ|PROT_WRITE and a write into the command buffer corrupts io_desc fields (confirmed under KASAN). After the fix, mprotect() returns -EACCES.

CVE-2026-89794:

        In the Linux kernel, the following vulnerability has been resolved:  ksmbd: zero pipe read compound padding  Compound response handling extends the last response iov to an eight-byte boundary.  smb2_read_pipe() allocates only the payload size, so the alignment padding can expose up to seven bytes of uninitialized kernel heap memory.  Allocate the aligned size and clear the unused tail before pinning the response buffer.

CVE-2026-89795:

        In the Linux kernel, the following vulnerability has been resolved:  PCI: Allow per function PCI slots to fix slot reset on s390  On s390 systems, which use a machine level hypervisor, PCI devices are always accessed through a form of PCI pass-through which fundamentally operates on a per PCI function granularity. This is also reflected in the s390 PCI hotplug driver which creates hotplug slots for individual PCI functions. Its reset_slot() function, which is a wrapper for zpci_hot_reset_device(), thus also resets individual functions.  Currently, the pci_create_slot() assigns the same pci_slot object to multifunction devices. This approach worked fine on s390 systems that only exposed virtual functions as individual PCI domains to the operating system.  Since commit 44510d6fa0c0 ("s390/pci: Handling multifunctions") s390 supports exposing the topology of multifunction PCI devices by grouping them in a shared PCI domain. This creates a problem when resetting a function through the hotplug driver's slot_reset() interface.  When attempting to reset a function through the hotplug driver, the shared slot assignment causes the wrong function to be reset instead of the intended one. It also leaks memory as we do create a pci_slot object for the function, but don't correctly free it in pci_slot_release().  Add a flag for struct pci_slot to allow per function PCI slots for functions managed through a hypervisor, which exposes individual PCI functions while retaining the topology. Since we can use all 8 bits for slot 'number' (for ARI devices), change slot 'number' u16 to account for special values PCI_SLOT_PLACEHOLDER and PCI_SLOT_ALL_DEVICES.

CVE-2026-89797:

        In the Linux kernel, the following vulnerability has been resolved:  power: supply: ab8500_fg: fix use-after-free on remove  ab8500_fg_remove() destroys the driver workqueue while the threaded interrupt handlers are still armed; they are devm-managed and freed only after ->remove() returns, so a handler that fires in that window queues work on the freed workqueue.  Tear the workqueue down through devm instead, registering its cleanup after the power supply and before the interrupt requests.  devm then frees the interrupts first, so the handlers can no longer queue work, before disabling the delayed and plain work items and destroying the workqueue.  Disabling the items, rather than cancelling them, keeps them disabled so no producer (including the power-supply external_power_changed callback) can requeue them.  Found by an in-house static analysis tool.

CVE-2026-89799:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: Disable preemption in bpf_get_stackid  The get_perf_callchain call needs disabled preemption plus we need it disabled as long as we access its returned trace entries buffer.  Note the bpf_get_stackid_pe function is executed already with preemption disabled.

CVE-2026-89803:

        In the Linux kernel, the following vulnerability has been resolved:  drm/nouveau: unsubscribe the channel-kill event before the fence context  nouveau_channel_del() tears the fence context down first and only drops the channel-kill subscription later, in the middle of the nvif object teardown:  	if (chan->fence) 		nouveau_fence(chan->cli->drm)->context_del(chan); 	... 	nvif_object_dtor(&chan->vram); 	nvif_event_dtor(&chan->kill);  The subscribed handler is nouveau_channel_killed(), which calls nouveau_channel_kill() and from there nouveau_fence_context_kill() on chan->fence. A kill event delivered in that window takes fctx->lock and walks fctx->pending on a fence context that context_del() has already freed.  Nothing reaches this below Fermi today, because the subscription is gated on FERMI_CHANNEL_GPFIFO and nothing kills a channel there. On Fermi and newer the window is real but narrow, since a kill has to land exactly while the channel is being destroyed. That is reason enough on its own, which is why this carries a Fixes: tag. The last patch in this series subscribes Tesla channels as well; nothing kills those today, so it does not widen the exposure now, but it is the groundwork for a recovery path that would, and the ordering is better fixed before that lands than alongside it.  Drop the subscription before anything it depends on is torn down.

CVE-2026-89808:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdkfd: Fix the case that vm range is hole at svm_migrate_copy_to_vram  When migration vm range is hole at cpu side(MIGRATE_PFN_MIGRATE set + MIGRATE_PFN_VALID unset) driver still allocates device pages. There is no dma map of src pages and migration. j is 0 and svm_migrate_copy_memory_gart() will return an uninitialized r. That can trigger out_free_vram_pages to drop all VRAM just set up.  Initialize r and only call the last svm_migrate_copy_memory_gart if j > 0.  Current code postponed the last page to the final copy. This patch flushes on the last page when reach to the end of current drm_buddy_block; avoids another svm_migrate_copy_memory_gart.

CVE-2026-89810:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdkfd: Fix error path at svm_migrate_copy_to_ram  If page migration from device to sys ram fails for some reasons driver needs release and unlock allocated system pages. To do that driver should use page physical address, or pfn, then get struct page*. Current driver uses dma address(for adev) that is not correct with IOMMU enabled, or even in general.  The patch releases and unlocks allocated system pages based on where migration failed by struct page* of sys ram pages. Also dma_unmap correspodent system ram pages at error path.

CVE-2026-89811:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdkfd: Add TLB flush after MES queue eviction/suspension  MES (Micro Engine Scheduler) does not perform heavy-weight TLB invalidation after unmapping queues, unlike HWS which does this automatically. This causes a race condition where in-flight DMA descriptors can access memory that has been unmapped, leading to page faults and GPU queue hangs during SVM page migration.  The issue manifests as KFDSVMRangeTest.MultiThreadMigrationTest failures on gfx1151 (Strix Point) with XNACK mode 1 enabled - the GPU compute queue hangs with packets submitted but never consumed.  Add kfd_flush_tlb() calls after MES queue removal in two locations: - evict_process_queues_cpsch(): after all queues removed during eviction - suspend_queues(): after debug/criu queue suspension (with mem_fence barrier)  This ensures all in-flight memory accesses from unmapped queues are flushed before memory is freed or migrated.  (cherry picked from commit f5c4f88e0f9c45a8fb9dfac0c1df726c95e41b77)

CVE-2026-89813:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu: force complete the KIQ ring fences on reset  Like the MES scheduler ring, the KIQ ring sets no_scheduler = true and uses a polling fence, so it is skipped by the force-completion loop in amdgpu_device_pre_asic_reset(). Its hw fence value lives in wb (GTT) memory and survives a MODE1 reset while fence_drv.sync_seq keeps advancing, so after a reset the first KIQ submission can poll forever on a seq that is never written back.  Force complete the KIQ ring fences too so their hw fence is realigned to sync_seq.

CVE-2026-89832:

        In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to clear dirty flag on folio in error path  If node block is corrupted due to chksum mismatch or inconsistent footer info, it needs to drop clear flag of node folio, in order to persist inconsistent node data to storage.

CVE-2026-89833:

        In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to avoid potential deadloop in f2fs_fsync_node_pages()  There is potential deadloop in race condition:  Thread A				Thread B - fsync  - f2fs_do_sync_file   - f2fs_fsync_node_pages    - last_fsync_dnode     - folio_get(last_folio) 					- f2fs_setattr 					 - f2fs_truncate 					  - f2fs_truncate_blocks 					   - f2fs_do_truncate_blocks 					    - f2fs_truncate_inode_blocks 					     - truncate_dnode 					      - truncate_node 					       - invalidate_mapping_pages 					        - folio->mapping = NULL    - is_node_folio alwasy return false    - atomic && !marked is always true,      then goto retry

CVE-2026-89834:

        In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to migrate all curseg types during free_segment_range  In free_segment_range(), the curseg evacuation loop only iterates up to NR_CURSEG_PERSIST_TYPE (0..5), missing non-persistent in-memory curseg types such as CURSEG_COLD_DATA_PINNED and CURSEG_ALL_DATA_ATGC.  Even though these in-memory curseg types are not saved in the on-disk checkpoint header, they still occupy active physical segments at runtime. If an active in-memory curseg happens to be allocated within the segment range being truncated during filesystem shrink, failing to evacuate it will cause subsequent writes to the curseg attempting out-of-bounds I/O on the truncated storage range.  Fix this by expanding the curseg evacuation loop upper bound to NR_CURSEG_TYPE to ensure all active curseg types are safely migrated out of the target range.

CVE-2026-89835:

        In the Linux kernel, the following vulnerability has been resolved:  f2fs: avoid NULL checkpoint thread access in sysfs  checkpoint_merge can be enabled even when no checkpoint merge thread is running. A read-only mount is one case: f2fs does not start f2fs_issue_ckpt there, but ckpt_thread_ioprio is still writable through sysfs.  The ckpt_thread_ioprio store path updates the saved ioprio value and, when checkpoint_merge is enabled, calls set_task_ioprio() for the checkpoint thread. If cprc->f2fs_issue_ckpt is NULL, that dereferences a NULL task pointer.  Protect ckpt_thread_ioprio sysfs writes with s_umount as well, so the checkpoint thread cannot disappear under the store path while updating its ioprio.

CVE-2026-89837:

        In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix dentry folio leak in find_in_level  find_in_level() gets a dentry folio with f2fs_find_data_folio() before calling find_in_block().  If find_in_block() returns an error, the function stores the error in res_folio and breaks out of the loop without dropping the dentry folio.  This leaks the folio reference on the find_in_block() error path.  Drop the dentry folio before returning the error to the caller.

CVE-2026-89838:

        In the Linux kernel, the following vulnerability has been resolved:  f2fs: limit recovery filename logging to stored length  F2FS stores recovery filenames as a length plus a fixed-size i_name buffer.  The buffer is not NUL-terminated, but recover_inode() and recover_dentry() print it with %s.  For a 255-byte filename, recovery logging can read past i_name into the following raw inode fields.  Print the name with a precision bounded by i_namelen and F2FS_NAME_LEN.

CVE-2026-89840:

        In the Linux kernel, the following vulnerability has been resolved:  f2fs: validate MOVE_RANGE destination size  F2FS_IOC_MOVE_RANGE checks the source range, but not the destination end before updating i_size. A source hole can expose this: __clone_blkaddrs() skips NULL_ADDR entries and returns success, so the caller can still extend the destination inode with unchecked pos_out + len.  Reject destination overflow and use inode_newsize_ok() before extending the destination inode.

CVE-2026-89848:

        In the Linux kernel, the following vulnerability has been resolved:  scsi: qla2xxx: Quiesce response IRQ before freeing request queue  qla2xxx_delete_qpair() deletes the request queue before the response queue. qla25xx_delete_req_que() frees the request queue memory (kfree(req) in qla25xx_free_req_que()), but the response-queue MSI-X is only released later, in qla25xx_free_rsp_que(). In that window the response interrupt can still fire, qla2xxx_msix_rsp_q() queues qpair->q_work, and qla_do_work() -> qla24xx_process_response_queue() dereferences the now-freed rsp->req (LOGINOUT/CT/ELS entries and the status path), a use-after-free.  The cancel_work_sync() added for the qpair teardown lives in the response free path, which runs after the request queue is already freed, so it does not protect rsp->req.  Release the response-queue interrupt and flush qpair->q_work before deleting the request queue, so no late completion can reach the freed request queue. Clearing have_irq makes the subsequent qla25xx_free_rsp_que() skip its free_irq(), and the firmware queue-delete order (request then response) is preserved; the request-delete mailbox completes on the default vector and is unaffected by dropping the qpair response interrupt early.

CVE-2026-89859:

        In the Linux kernel, the following vulnerability has been resolved:  scsi: qla2xxx: Zero dport diagnostics buffer to avoid info leak  qla2x00_do_dport_diagnostics() allocates the qla_dport_diag response buffer with kmalloc_obj() (non-zeroing) and, on success, copies the full sizeof(*dd) back to user space via sg_copy_from_buffer(). The inbound sg_copy_to_buffer() only fills as many bytes as the user request payload provides, and qla26xx_dport_diagnostics() zeroes only dd->buf. The options and unused[] fields are therefore copied out uninitialized, leaking kernel heap contents to user space.  Allocate with kzalloc_obj(), matching qla2x00_do_dport_diagnostics_v2().

CVE-2026-89860:

        In the Linux kernel, the following vulnerability has been resolved:  scsi: qla2xxx: Initialize NVMe abort_work once at submission  qla_nvme_fcp_abort() and qla_nvme_ls_abort() ran INIT_WORK() on priv->abort_work immediately before schedule_work(). INIT_WORK() reinitializes the work_struct, resetting its list head and clearing the pending bit. If an abort is issued more than once for the same command (for example, concurrent transport teardown and a timeout-driven abort), the second INIT_WORK() reinitializes a work item that is already queued, which can corrupt the workqueue list and lead to crashes or a looping worker.  Initialize priv->abort_work once at command submission, next to the existing per-command spin_lock_init(&priv->cmd_lock), and leave only schedule_work() in the abort paths. schedule_work() already does nothing when the work item is still pending, so a repeated abort no longer disturbs an in-flight work item. The command is not returned to the transport until the final kref_put()/release callback runs after abort_work has completed, so the work item is idle before priv is reused and the single submission-time INIT_WORK() is safe.

CVE-2026-89862:

        In the Linux kernel, the following vulnerability has been resolved:  scsi: qla2xxx: Fix BSG job leak on validate flash image error path  qla28xx_validate_flash_image() returns QLA_SUCCESS (0) unconditionally, telling the FC BSG transport (fc_bsg_host_dispatch()) that the driver owns and will complete the request. But bsg_job_done() is guarded by "if (!rval)", so on the error path (rval == -EINVAL) neither the driver nor the transport completes the job. The request dangles until it times out, leaking block layer resources.  Commit c2c68225b145 ("scsi: qla2xxx: Fix bsg_done() causing double free") added the "if (!rval)" guard to a batch of BSG handlers. That is correct for handlers that also return the error code (the transport then completes the job once via fail_host_msg), but this function returns QLA_SUCCESS unconditionally, so the guard turned a correct single completion into a leak.  Always call bsg_job_done(): bsg_reply->result is DID_OK and the error is reported in vendor_rsp[0], and since the function returns 0 the transport will not complete the job a second time.

CVE-2026-89884:

        In the Linux kernel, the following vulnerability has been resolved:  media: platform: mtk-mdp3: fix NULL deref on failed SCP lookup  Add the missing sanity check after looking up the SCP to avoid dereferencing a NULL-pointer in case its driver has not yet been bound.

CVE-2026-89899:

        In the Linux kernel, the following vulnerability has been resolved:  media: cec: disable delayed work before freeing an interrupted transmit  cec_transmit_msg_fh() drops adap->lock to wait for a blocking transmit in wait_for_completion_killable(). If that wait is interrupted by a signal, cancel_delayed_work_sync() can run before the CEC kthread arms the reply timeout via schedule_delayed_work(&data->work) in cec_transmit_done_ts(). The work is then armed after the cancel, and the data is freed with its delayed_work still pending:    ODEBUG: free active (active state 0) object: ... hint: cec_wait_timeout  Use disable_delayed_work_sync(): it cancels the work and disables it, so the later schedule_delayed_work() becomes a no-op and the work cannot be re-armed. The data is freed right after, so it need not be re-enabled.

CVE-2026-89906:

        In the Linux kernel, the following vulnerability has been resolved:  LoongArch: BPF: Refactor jump offset calculation in tail call  The old macro-based jmp_offset calculation derives the jump distance from a stale prior-pass code stride, which can lead to wrong branch offsets and soft lockups under extra JIT passes.  Fix this by calculating the offset directly on the absolute target: "ctx->offset[insn + 1] - ctx->idx".  To avoid a false 16-bit range check abort during size estimation, add a "ctx->image == NULL" guard to inject a safe dummy offset.

CVE-2026-89912:

        In the Linux kernel, the following vulnerability has been resolved:  KVM: arm64: vgic-its: Don't dereference a NULL collection on ITT save  MAPC with V=0 drops ite->collection but leaves the ITE on the device's ITT list, and vgic_its_save_ite() dereferences it unconditionally. A guest that issues MAPD, MAPTI and then MAPC(V=0) therefore oopses the host when the VMM issues KVM_DEV_ARM_ITS_SAVE_TABLES to migrate it. That sequence is UNPREDICTABLE per the architecture, but KVM already handles the resulting state in the translate, MOVI and DISCARD paths.  Save a zeroed entry, which vgic_its_restore_ite() reads back as invalid. Skipping the ITE instead would leave the ITT slot holding whatever is in guest memory, and restore rejects an entry naming a collection the restored collection table does not have.

CVE-2026-89913:

        In the Linux kernel, the following vulnerability has been resolved:  KVM: arm64: vgic-v3: take an LPI reference in vgic_v3_save_pending_tables  vgic_v3_save_pending_tables() iterates dist->lpi_xa using xa_for_each() and dereferences the returned struct vgic_irq in the loop body without holding a reference on the LPI.  The xarray iterator only provides temporary RCU coverage while looking up the current entry. That is not sufficient for this loop body, which reads fields from struct vgic_irq and performs guest memory accesses before the iteration completes.  A concurrent path can trigger this race: the irqfd cached injection path (vgic_its_inject_cached_translation) obtains a transient LPI reference via vgic_its_check_cache() without holding kvm->lock, vcpu->mutex, config_lock, or its_lock. If guest ITS DISCARD then drops the cache and ITE references under its_lock, the transient inject reference may become the final one. When vgic_put_irq() drops it, the LPI is erased from lpi_xa and freed via kfree_rcu(). Meanwhile, vgic_v3_save_pending_tables() may still hold a stale pointer obtained from the xarray iterator and dereference it after the RCU grace period completes.  Fix this by re-fetching each iterated LPI via vgic_get_irq(), which takes a stable reference, and dropping it with vgic_put_irq() on all paths. This matches the pattern already used by other lpi_xa iterators in the vgic ITS code.

CVE-2026-89920:

        In the Linux kernel, the following vulnerability has been resolved:  KVM: s390: Fix memory corruption by not reinjecting CK machine checks  Channel-subsystem damage machine checks are for the host channel subsystem. The guest channel subsystem is emulated in the userspace VMM. There is no point in forwarding such machine checks into the guest.  This also simplifies the machine check reinjection and avoids kfree of a stack variable as reported by sashiko.  There might be still machine checks that have the ck bit set with another bit (like instruction damage), mask out the CK bit in s390_backup_mcck_info(), like the CP and ED bits already are.

CVE-2026-89921:

        In the Linux kernel, the following vulnerability has been resolved:  KVM: s390: Zero initialize data structures for inject_pfault_token  __kvm_inject_pfault_token() only sets .type and .u.ext.ext_params2 of the on-stack struct kvm_s390_irq but the full ext substructure is copied into the cpu local variable on inject. ext_params and pad contain stale stack values.  Interrupt delivery only uses ext_params2, so nothing leaks to the guest, but a host user can use the migration ioctls to get to the data.  Fix by zero-initializing the irq struct. Do the same for the inti data structure.

CVE-2026-89929:

        In the Linux kernel, the following vulnerability has been resolved:  KVM: nVM: Ensure INVVPID is emulated on the correct physical CPU  When emulating INVVPID, KVM executes INVVPID on the physical CPU using vpid02 (instead of the L1 assigned VPID), after doing some validations on the operands. However, it is possible that the physical CPU KVM executes INVVPID on is different from the CPU L2 is running on.  For example, in the following scenario: - L2 runs on CPU #1 and exits to L1 (vmx->nested.vmcs02.cpu=1) - L1 migrates to CPU #2 and executes INVVPID - KVM executes INVVPID on CPU #2 - L1 migrates back to CPU #1 and runs L2 (vmx->nested.vmcs02.cpu=1)  The TLB entries on CPU #1 are never invalidated, because INVVPID was executed on CPU #2, and vmcs02 never ran on a different pCPU (i.e. vmx_vcpu_load_vmcs() will *not* request KVM_REQ_TLB_FLUSH).  Ensure that INVVPID is being executed on the same pCPU that L2 last ran on, and if not, fallback to clearing last_vpid=0 to trigger a full VPID flush on the next nested VM-Enter (as KVM will detect L1 using a different VPID for L2). If L2 ends up running on a different pCPU, KVM will flush the TLB anyway through vmx_vcpu_load_vmcs().

CVE-2026-89933:

        In the Linux kernel, the following vulnerability has been resolved:  iio: pressure: dps310: fix NULL pointer dereference on ACPI probe  When the device is enumerated through its ACPI HID (IFX3100), i2c_client_get_device_id() returns NULL: the ACPI-derived client name does not match the driver's i2c_device_id table. dps310_probe() then dereferences that NULL pointer in "iio->name = id->name" and crashes the kernel during probe.  The IIO device name is always "dps310", so set it directly and drop the now-unused device-id lookup.

CVE-2026-89934:

        In the Linux kernel, the following vulnerability has been resolved:  iio: light: ltrf216a: fix runtime PM reference leak in error path  ltrf216a_get_lux() acquires a runtime PM reference by calling ltrf216a_set_power_state(data, true). However, if ltrf216a_read_data() fails, the function returns immediately without dropping the reference.  This leaves the runtime PM usage count unbalanced, preventing the device from autosuspending after a failed read.  Fix this by releasing the runtime PM reference before returning from the error path.

CVE-2026-89938:

        In the Linux kernel, the following vulnerability has been resolved:  iio: chemical: atlas-sensor: use iio_trigger_poll_nested() to fix remove UAF  The atlas driver requests its hardware data-ready IRQ with devm_request_threaded_irq(); its threaded handler queues an irq_work, atlas_work_handler(), that calls iio_trigger_poll(data->trig).  The IRQ is devm-managed, so free_irq() runs from the devres unwind after atlas_remove() returns without flushing that irq_work.  Once a buffer is enabled, conversion-complete IRQs keep firing and queueing it; a pending irq_work can therefore run after the unwind has freed atlas_data/indio_dev and the trigger, when atlas_work_handler() derives the atlas_data pointer via container_of() and dereferences data->trig, a use-after-free.  Call iio_trigger_poll_nested() directly from the threaded handler instead of bouncing through irq_work.  free_irq() then drains the threaded handler, closing the window; other iio drivers with a threaded data-ready IRQ do the same (e.g. bmi270).  This issue was found by an in-house static analysis tool.

CVE-2026-89944:

        In the Linux kernel, the following vulnerability has been resolved:  ASoC: hdac_hda: Fix hlink refcount leak on component registration failure  hdac_hda_dev_probe() gets the HDA link with snd_hdac_ext_bus_link_get() before registering the ASoC component. If component registration fails, the function returns without dropping the link reference.  Always call snd_hdac_ext_bus_link_put() after the registration attempt so the reference taken during probe is balanced on both success and failure.

CVE-2026-89955:

        In the Linux kernel, the following vulnerability has been resolved:  s390/vfio-ap: Fix NULL deref in status_show() during queue probe  When vfio_ap_mdev_probe_queue() creates the sysfs attribute group, the queue's driver data has not yet been set. A concurrent read of the 'status' attribute can therefore call dev_get_drvdata() and get NULL, which is then passed directly to vfio_ap_mdev_for_queue() where q->apqn is unconditionally dereferenced, causing a NULL pointer dereference.  Fix this by acquiring the update locks before calling sysfs_create_group(). The status_show() function acquires guests_lock before reading the driver data, so any concurrent read will block until after dev_set_drvdata() has been called and the update locks are released.  As a bonus, the APQN no longer needs to be read from the queue struct after allocation — it can be read directly from apdev before allocation and stored in a local variable, which is then assigned to q->apqn once the allocation succeeds.

CVE-2026-89956:

        In the Linux kernel, the following vulnerability has been resolved:  s390/vfio-ap: Fix missing lock required to access list of ap_matrix_mdev objects  In order to traverse or add/remove ap_matrix_mdev objects in the matrix_dev->mdev_list, the matrix_dev->guests_lock mutex must be held. There are two functions that access the list without holding the mutex:  vfio_ap_mdev_probe function ~~~~~~~~~~~~~~~~~~~~~~~~~~~ The vfio_ap_mdev_probe function uses the matrix_dev->mdevs_lock mutex to guard the add of a newly created ap_matrix_mdev object to the matrix_dev->mdev_list. This mutex does not protect list access; its purpose is to guard against concurrent access to fields contained in an ap_matrix_mdev object. This could lead to kernel memory corruption or use-after-free if another mdev is created or removed concurrently.  The adding of an ap_matrix_mdev object to matrix_dev->mdev_list is now guarded by the matrix_dev->guests_lock which is the correct way to protect against concurrent mdev_list access.  Also removed the following two lines of code because the matrix_mdev is allocated via vfio_alloc_device macro which uses kzalloc, so req_trigger and cfg_chg_trigger are already zero-initialised when the struct is allocated before the call to vfio_register_emulated_iommu_dev. This prevents a window whereby these triggers are set to NULL after the device is exposed to userspace.  matrix_mdev->req_trigger = NULL; matrix_mdev->cfg_chg_trigger = NULL;  vfio_ap_mdev_for_queue function ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The status_show function that supports display of the status attribute of the devices in /sys/bus/ap/devices calls the vfio_ap_mdev_for_queue function which iterates the matrix_dev->mdev_list to find the object representing the queue device whose status is to be displayed. In order to traverse this list, the matrix_dev->guests_lock mutex must be held.  To fix this, the guests_lock mutex is taken prior to taking the matrix_dev->mdevs_lock mutex in the status_show function. It is taken there rather than the vfio_ap_mdev_for_queue function - where it is needed - because it must be taken prior to the mdevs_lock mutex in order to adhere to the proper locking order and prevent a lockdep splat; also because the mdevs_lock is needed there to access fields within the matrix_mdev object in that function.  See the vfio-ap-locking.rst in the linux kernel tree.

CVE-2026-89958:

        In the Linux kernel, the following vulnerability has been resolved:  s390/vfio-ap: Fix dereference matrix_mdev->kvm without checking for NULL  The ap_driver structure has two fields which are function pointers to callbacks:  * .on_config_changed: called at the start of the AP bus scan function to                       notify the device driver that the host AP                       configuration has changed and the associated AP                       devices will be added or removed accordingly. This                       gives the implementor a chance to evaluate the                       configuration changes and respond to them before                       the associated devices are added or removed.  * .on_scan_complete:  Called at the end of the AP bus scan function to                       notify the device driver that the host AP                       configuration has changed and the AP devices have                       been added or removed accordingly. This gives the                       implementor the opportunity to respond to the                       changes after the associated devices are added or                       removed.  These two callbacks are implemented in the vfio_ap device driver via the vfio_ap_on_cfg_changed and vfio_ap_on_scan_complete functions respectively.  Within the call stack of these two callback functions the matrix_mdev->kvm->lock mutex is taken without checking whether matrix_mdev->kvm is NULL or not. If matrix_mdev->kvm has never been set, trying to take the lock will trigger a NULL pointer dereference. This patch adds checks for matrix_mdev->kvm == NULL before taking the matrix_mdev->kvm->lock mutex.  Note that the matrix_mdev->kvm->lock mutex taken in the vfio_ap_mdev_hot_plug_config function is moved to the calling function along with the matrix_dev->mdevs_lock which is needed there to access the fields of the matrix_mdev. It makes little sense to make the change the check for matrix_mdev->kvm there before taking the kvm->lock mutex only to have to move it out via another patch, so it is done in this patch.  It is important to make note of the following: 1. The matrix_dev->guests_lock is acquired at the start of both callback    functions. This ensures that matrix_mdev will not be removed via the    vfio_ap_mdev_remove function because it too takes matrix_dev_guests_lock    before removing the object; so, matrix_mdev will be available for the    duration of the callback functions.  2. The matrix_dev->mdevs_lock mutex must be taken in order to access    fields within the matrix_mdev structure  3. matrix_mdev->kvm->lock mutex must be taken before the    matrix_dev->mdevs_lock to prevent a lockdep splat.  4: The kvm->lock must be held while plugging the guest's AP configuration    into its SIE state description via the vfio_ap_mdev_update_guest_apcb    function.  5. The vfio_ap_mdev_update_guest_apcb checks matrix_mdev->kvm to verify it    is not NULL before doing the hot plug of the guest's AP configuration.

CVE-2026-89960:

        In the Linux kernel, the following vulnerability has been resolved:  s390/vfio-ap: fix stale pqap_hook pointer on error in vfio_ap_mdev_set_kvm()  In vfio_ap_mdev_set_kvm(), kvm->arch.crypto.pqap_hook is set to &matrix_mdev->pqap_hook before the update locks are acquired and the mdev list is checked for a conflicting assignment. If another mdev is already attached to the same KVM instance, the function returns -EPERM without restoring the hook pointer, leaving kvm->arch.crypto.pqap_hook pointing at the failing matrix_mdev instead of the mdev that legitimately owns the KVM.  Since matrix_mdev->kvm is never set on this error path, vfio_ap_mdev_unset_kvm() will not clean up the hook when matrix_mdev is later closed. If matrix_mdev is subsequently freed, any PQAP instruction executed by the guest will dereference the stale pointer through pqap_hook_rwsem, resulting in a use-after-free.  Since kvm->arch.crypto.pqap_hook is only set in the vfio_ap_mdev_set_kvm() function and is cleared in the vfio_ap_mdev_unset_kvm() function, a check for 'kvm->arch.crypto.pqap_hook != NULL' is all that is needed to determine whether it belongs to another mdev. This will alleviate the need to iterate the matrix_dev->mdev_list list to see if the kvm object is assigned to another mdev.This was introduced in v3 to alleviate the need to take the mdevs_lock while iterating the list; however, this did not prevent a potential race condition.  The pqap_hook_rwsem(write) is now performed inside get_update_locks_for_kvm(), which is updated to acquire pqap_hook_rwsem(write) between kvm->lock and mdevs_lock. This ordering is consistent with the PQAP intercept path, which acquires pqap_hook_rwsem in read mode while srcu is held under vcpu->mutex, establishing the dependency: kvm->lock -> vcpu->mutex -> srcu -> pqap_hook_rwsem(read).  The pqap_hook_rwsem is now released inside the release_update_locks_for_kvm(), which is updated to release pqap_hook_rwsem(write) between mdevs_lock and kvm->lock.  Additionally, kvm_put_kvm() in vfio_ap_mdev_unset_kvm() is moved after release_update_locks_for_kvm(). Previously it was called while kvm->lock was held; if it were ever the last reference, kvm_destroy_vm() would run under kvm->lock, which would deadlock.

CVE-2026-89962:

        In the Linux kernel, the following vulnerability has been resolved:  powerpc/kexec_file: Prevent kexec range truncation  Sashiko AI review pointed out the following issue.  The __merge_memory_ranges() function incorrectly handles overlapping memory ranges when merging them. Although sort_memory_ranges() sorts all ranges by their start address in ascending order beforehand, the merge logic remains defective in two ways:  1. It compares the current range's start against the previous element (i-1)    instead of the running target index (idx)  2. It unconditionally overwrites 'ranges[idx].end' with 'ranges[i].end'.  This logic flaw leads to critical memory truncation when a larger memory range completely subsumes subsequent smaller ranges.  For example, consider a sorted input array with three ranges:   Range A (idx=0): [0x1000 - 0x9000]   Range B (i=1):   [0x2000 - 0x5000] (completely inside Range A)   Range C (i=2):   [0x6000 - 0x8000] (completely inside Range A)  1. When i=1 (Range B):    ranges[1].start (0x2000) <= ranges[0].end + 1 (0x9001) is TRUE.    The code executes: ranges[0].end = ranges[1].end, which erroneously    shrinks Range A's end from 0x9000 down to 0x5000.  2. When i=2 (Range C):    ranges[2].start (0x6000) <= ranges[1].end + 1 (0x5001) is FALSE.    The code falls into the else block, creating a broken new range.  As a result, valid memory fragments [0x5001 - 0x5fff] and [0x8001 - 0x9000] are completely lost from the kexec exclude lists, potentially allowing the crash kernel to overwrite active memory, causing data corruption or crashes.  Fix this by ensuring the start of the current range is compared against the end of the active merged range (idx), and use max() to safely prevent the outer boundary from being truncated.

CVE-2026-89972:

        In the Linux kernel, the following vulnerability has been resolved:  nvme: add missing SRCU grace period in error path  nvme_alloc_ns() error path at out_unlink_ns removes ns from the namespace head siblings list with list_del_rcu(&ns->siblings) but does not wait for SRCU readers before freeing the namespace struct. Multipath code iterates the head->list under srcu_read_lock() in nvme_find_path() and nvme_mpath_revalidate_paths(), so a concurrent reader can still hold a reference to ns when kfree(ns) runs.  The normal removal path in nvme_ns_remove() correctly calls synchronize_srcu(&ns->head->srcu) after list_del_rcu() to wait for in-progress readers. Add the same grace period in the error path.

CVE-2026-89975:

        In the Linux kernel, the following vulnerability has been resolved:  nvme-fabrics: fix DHCHAP secret leak on parse failure  nvmf_parse_options() duplicates dhchap_secret and dhchap_ctrl_secret with match_strdup() before validating the DHHC-1: representation.  If validation fails, the parser returns -EINVAL before the temporary string in p is assigned to opts->dhchap_secret or opts->dhchap_ctrl_secret. nvmf_create_ctrl() subsequently frees opts, but nvmf_free_options() cannot release the unassigned temporary string. Each rejected option therefore leaks one allocation.  This is easy to miss because valid secrets transfer ownership to opts and are freed normally, while the malformed-secret path still returns the expected -EINVAL to userspace.  With CONFIG_NVME_HOST_AUTH enabled, the leak is reachable before the required-option checks and transport lookup. No NVMe-oF target or working transport connection is required; for example, repeatedly writing  	dhchap_secret=BAD  or  	dhchap_ctrl_secret=BAD  to /dev/nvme-fabrics deterministically takes the leaking parse path.  Free the temporary string before leaving both validation error paths. Use kfree_sensitive() because the copied option may contain secret material even when its representation is rejected, matching the sensitive cleanup used for stored DHCHAP secrets.

CVE-2026-89987:

        In the Linux kernel, the following vulnerability has been resolved:  mm/huge_memory: transfer the pmd dirty bit to the folio on zap  zap_huge_pmd_folio() propagates the pmd young bit to the folio for the file case, but not the dirty bit.  The pte path does propagate it, in zap_present_folio_ptes() and so does the pmd split path, in __split_huge_pmd_locked().  For most file mappings the omission is harmless, because writing to a shared file mapping goes through page_mkwrite(), which dirties the folio.  tmpfs is different: it has no page_mkwrite(), and vma_wants_writenotify() is false for it, so a *read* fault on a MAP_SHARED tmpfs mapping installs a writable pmd via do_read_fault().  do_read_fault() does not call fault_dirty_shared_page(), so subsequent stores through that mapping set only the hardware dirty bit in the pmd and never call folio_mark_dirty().  A shmem folio allocated by a fault is marked uptodate but not dirty (see the clear: block in shmem_get_folio_gfp()), so PG_dirty is never set at all.  Unmapping such a folio - munmap(), or exit_mmap() when the process dies - then loses the only record that it was written, because zap_huge_pmd() drops the pmd without transferring the dirty bit.  Reclaim afterwards sees a clean shmem folio: the whole swap-out block in shrink_folio_list() is inside "if (folio_test_dirty(folio))", so pageout() is skipped and the folio falls into __remove_mapping().  There, folio_is_file_lru() is false for a swapbacked folio, so no shadow entry is created and __filemap_remove_folio(folio, NULL) simply empties the i_pages slot.  The data is freed without ever being written to swap, and the next fault on that index returns a freshly zeroed folio.  This is silent data loss for any process that keeps state in a MAP_SHARED tmpfs segment across an unmap - for example a cache handed from one process generation to the next through /dev/shm.  It requires the folio to be PMD-mapped, so it only shows up once shmem THP is enabled (which is what we did in Meta fleet and started noticing crashes); with THP off the pte path transfers the dirty bit correctly.  It also only becomes visible when swap is enabled, because with no swap device shmem folios (which are on the anon LRU) are not scanned by reclaim at all, so the clean folio is never dropped.  Reproduced on x86_64 with a tmpfs mounted huge=within_size: read-fault a 2MB-backed region, write a known pattern through the resulting mapping, munmap, force reclaim of the cgroup, then re-map and read back.  Without this patch the region reads back as zeros and vmstat shows zswpout 0 - the data was discarded rather than swapped.  With this patch the region reads back correctly and the pages are swapped out as expected.  With huge=never, or when the first touch is a write, the test passes either way.

CVE-2026-89995:

        In the Linux kernel, the following vulnerability has been resolved:  dma-direct: return struct page from dma_direct_alloc_from_pool()  Commit 5b138c534fda ("dma-direct: factor out a dma_direct_alloc_from_pool helper") changed dma_direct_alloc_from_pool() to return the CPU address from dma_alloc_from_pool(). That fits dma_direct_alloc(), but dma_direct_alloc_pages() also uses the helper and expects a struct page *.  Fix this by making dma_direct_alloc_from_pool() return the struct page * again, and pass the CPU address back through an out-parameter for the dma_direct_alloc() caller.

CVE-2026-89996:

        In the Linux kernel, the following vulnerability has been resolved:  dma-buf: dma-heap: don't publish fd before copy_to_user() succeeds  DMA_HEAP_IOCTL_ALLOC allocates a dma-buf and installs an fd into the caller's fd table via dma_buf_fd() -> fd_install() before dma_heap_ioctl() copies the result back to userspace.  If the trailing copy_to_user() fails, userspace never learns the fd number, but the fd (and the underlying dma-buf reference) are already visible to other threads in the same process and are leaked for the lifetime of the process.  The obvious "close it on the failure path" fix is unsafe: once fd_install() has run, another thread can already dup() the fd, send it via SCM_RIGHTS, or close() it and let its number be reused, so a subsequent close_fd() from the ioctl path can operate on an unrelated file.  This was pointed out by Christian König on v1 [1].  Restructure the allocation path so that fd_install() is the last, unfailable step of a successful ioctl:    1. heap->ops->allocate()      creates the dma_buf.   2. get_unused_fd_flags()      reserves an fd number in the caller's                                 fd table without publishing it, so                                 no other thread can observe it.   3. copy_to_user()             delivers the fd number to userspace;                                 on failure the fd is returned with                                 put_unused_fd() and the dma_buf                                 reference is dropped with                                 dma_buf_put(), leaving no user-                                 visible state behind.   4. dma_buf_fd_install()       publishes the fd and emits the                                 trace_dma_buf_fd tracepoint -- from                                 here on the ioctl cannot fail.  A new dma_buf_fd_install() helper is introduced in dma-buf.c to wrap fd_install() together with the DMA_BUF_TRACE() call, preserving the export tracing that dma_buf_fd() provides.  dma_heap_ioctl_allocate() is refactored to return the struct dma_buf * directly (returning ERR_PTR on failure) so the caller holds the dmabuf reference across steps 3 and 4.  The failure at step 3 is easily reachable from userspace: pass a struct dma_heap_allocation_data that lives in a page whose protection is flipped to PROT_READ between copy_from_user() and copy_to_user() (e.g. via mprotect()).  Before this change each such ioctl leaks one dmabuf fd; after it, the fd table is unchanged on failure and only /dev/dma_heap/<name> remains open.  No UAPI or heap-driver interface change.  [1] https://lore.kernel.org/dri-devel/175e98de-f414-47d7-81c1-c0fe0a8f7f62@amd.com/

CVE-2026-90002:

        In the Linux kernel, the following vulnerability has been resolved:  ftrace: Take trace_array reference before accessing its ftrace_ops  The trace instance files set_ftrace_filter and set_ftrace_notrace was updated to work with specific trace instances (trace_arrays). The issue is that when these files are opened, there is a small race window where it will use the ftrace_ops from the inode->private pointer to get a reference to the trace_array and then take its reference. The problem is that the ftrace_ops itself could be freed. If the rmdir on the instance happens at the same time the set_ftrace_filter file is opened, the rmdir could have also freed the ftrace_ops and referencing it will cause a use-after-free bug and crash the kernel.  Instead, pass in the trace_array as the file private data (NULL for the top level instance), and then pass both the trace_array and the ftrace_ops to the ftrace_regex_open() function. If the trace_array is NULL, then it just uses the ftrace_ops without the need to take its reference (like normal). If the ftrace_ops is NULL, that is only the case for the top level instance and the global_ops can be used.  This allows the trace_array to have its reference incremented before touching the ftrace_ops that could also be freed when the instance is.

CVE-2026-90013:

        In the Linux kernel, the following vulnerability has been resolved:  tracing: Take trace_array reference when opening options file  The options files do not take the trace_array reference for the options they represent. This could cause a use-after-free kernel crash if one of these files is opened by one task and another task removes the instance that the option is for. Because it doesn't take a reference upon opening, it will not stop the removal which will free the options descriptor that is being used.  As the options are somewhat dynamic in their creation at boot up, each file represents a flag in the trace_array. The trace_array has an array of indexes to represent each of these flags that is stored in the trace_flags_index array. The address of the index array element is used to pass to the inode->i_private pointer. Then that element is read which holds the index (which represents the flag) and then the index is used to calculate the trace_array descriptor from its trace_flags_index array.  One issue is that the index element can not be referenced until the trace_array's reference is taken. To handle this, create a new helper function called: trace_array_options_get() that will iterate all the existing trace_arrays in the ftrace_trace_arrays list (under the trace_types_lock), and compare the passed in address of the index element with the entire array of the trace_array's trace_flags_index array. If it matches, then up the corresponding trace_array's reference and return.

CVE-2026-90016:

        In the Linux kernel, the following vulnerability has been resolved:  staging: rtl8723bs: fix OOB read in rtw_restruct_wmm_ie()  rtw_restruct_wmm_ie() scans in_ie for a WMM IE with:  	while (i < in_len) { 		... 		if (i + 5 < in_len && in_ie[i] == 0xDD && ...) { 			... 			break; 		} 		i += (in_ie[i + 1] + 2); /* to the next IE element */ 	}  When the "i + 5 < in_len" match check fails simply because i is within 5 bytes of the end of the buffer (i.e. no WMM IE was found near the tail of in_ie), execution falls through to "i += (in_ie[i + 1] + 2)", which reads in_ie[i + 1]. If i == in_len - 1 at that point, this is a 1-byte out-of-bounds read of an attacker-influenced IE buffer built from association/scan data.  Commit a75281626fc8f ("staging: rtl8723bs: fix potential out-of-bounds read in rtw_restruct_wmm_ie") added the "i + 5 < in_len" guard to the match condition itself, but did not add an equivalent guard before the fallthrough advance, so the same class of OOB read remained reachable through the non-matching path.  Add an explicit bounds check before advancing to the next IE.

CVE-2026-90021:

        In the Linux kernel, the following vulnerability has been resolved:  usb: gadget: f_midi: initialize work in f_midi_alloc()  f_midi_alloc initializes free_ref to 1 and it can only be incremented when a sound card is registered via f_midi_register_card(). f_midi_register_card() is only called in f_midi_bind() which actually performs INIT_WORK. If f_midi_bind() is never run, work is not initialized and the if condition in f_midi_free becomes true, this results in a warning later in __flush_work as work->func = 0. Fix this by moving INIT_WORK from f_midi_bind() to f_midi_alloc().

CVE-2026-90023:

        In the Linux kernel, the following vulnerability has been resolved:  usb: gadget: f_mass_storage: fix null pointer dereference in fsg_common_set_num_buffers()  Previously fsg_num_buffers_validate() was removed as it was not necessary due to Kconfig setting the limits for n from 2 to 256 with default as 2. However, setting the page content in such a way that kstrtou8() reflects n value as either 0 or 1 bypasses these restrictions leading to a null pointer dereference if n is 0. Fix this by adding a check for n < 2 and returning -EINVAL if n is either 0 or 1 consistent with Kconfig logic.

CVE-2026-90029:

        In the Linux kernel, the following vulnerability has been resolved:  usb: storage: realtek_cr: fix use-after-free on disconnect  realtek_cr_destructor() calls timer_delete() before the chip containing the timer is freed. The timer callback may still be running and can rearm itself, resulting in a use-after-free.  Use timer_shutdown_sync() to wait for the callback and prevent further rearming. Do this unconditionally because ss_en may be changed after the timer is armed.  Move timer_setup() into init_realtek_cr() so the timer is initialized before any failure path can invoke the destructor.  Found by static analysis.

CVE-2026-90036:

        In the Linux kernel, the following vulnerability has been resolved:  NFSD: Prevent client use-after-free during blocked-lock reaping  A bare lock owner -- its only remaining reference a blocked lock on nn->blocked_locks_lru -- holds a raw pointer to its nfs4_client but no reference keeping the client alive. When the per-net laundromat reaps such a lock, freeing the nbl drops the owner reference held through flc_owner, and the final nfs4_put_stateowner() takes the client's cl_lock. Because the laundromat detaches the nbl first, __destroy_client() no longer finds it, so a concurrent force_expire_client() can free the client before nfs4_put_stateowner() runs, dereferencing cl_lock in freed memory.  Pin the client with cl_rpc_users before dropping nn->blocked_locks_lock, and skip clients already expiring, whose blocked locks __destroy_client() frees while holding an owner reference. Take nn->client_lock outside nn->blocked_locks_lock. Every other site holds nn->blocked_locks_lock as a leaf, acquiring no further lock, so placing nn->client_lock outside it cannot form a lock-order cycle.

CVE-2026-90037:

        In the Linux kernel, the following vulnerability has been resolved:  NFSD: Prevent client use-after-free during close_lru reaping  An nfs4_openowner left on nn->close_lru after its final CLOSE keeps its last closed stateid in oo_last_closed_stid, holding only a raw pointer to its nfs4_client. The laundromat reaps timed-out entries, drops nn->client_lock, and calls nfs4_put_stid(), which dereferences the client through cl_lock. Nothing pins the client across that window, so a concurrent force_expire_client() can free it and nfs4_put_stid() reads freed memory. __destroy_client() hits the same race, walking clp->cl_openowners without cl_lock.  Pin the client with cl_rpc_users before dropping client_lock, and skip clients already expiring. __destroy_client() then cleans up its own close_lru entries through release_last_closed_stateid(), so teardown no longer races the laundromat.

CVE-2026-90041:

        In the Linux kernel, the following vulnerability has been resolved:  HID: sony: clean up device list on probe failure  sony_input_configured() adds some controllers to sony_device_list before HID core registers their input devices. input_register_device() can fail after the callback returns successfully. sony_probe() then observes that HID_CLAIMED_INPUT is clear and unwinds, but only stops the HID hardware. The devres-managed sony_sc is freed while its list node remains linked, so the next matching controller traverses freed memory.  Initialize the list node and device ID to inactive states. Make list removal idempotent and run the driver-private cleanup on every probe failure path. This also makes a second cleanup safe when sony_input_configured() already unwound a partial initialization before sony_probe() handles the missing input claim.  Found by 0sec (https://0sec.ai) using automated source analysis; verified against the HID input registration and probe unwind paths.

CVE-2026-90044:

        In the Linux kernel, the following vulnerability has been resolved:  usb: gadget: f_fs: Fix Use-After-Free in AIO error path  In ffs_epfile_write_iter() and ffs_epfile_read_iter(), when ffs_epfile_io() fails with an error other than -EIOCBQUEUED, the io_data structure (`p`) is freed. However, for AIO operations, the kiocb cancel function was already armed and kiocb->private was set to `p`.  If a concurrent cancel operation (such as sys_io_cancel()) executes after ffs_epfile_io() fails but before the function frees `p`, a Use-After-Free can occur when the cancellation handler accesses the freed pointer.  To securely fix this race condition, we must properly un-arm the cancellation. Invoking `kiocb->ki_complete()` does exactly this by acquiring `ctx->ctx_lock` and safely removing the kiocb from the active sequence. In doing so, it ensures that a parallel io_cancel can no longer discover the kiocb, effectively closing the race window.  We then return -EIOCBQUEUED to notify the VFS layer that the kiocb has been consumed and it should avoid attempting to complete the request again or triggering subsequent completion handlers.

CVE-2026-90045:

        In the Linux kernel, the following vulnerability has been resolved:  USB: gadget: ffs: fix mm lifetime handling  io_data stores a pointer to the submitting task's mm_struct, but does not currently hold a reference to it while async requests are pending.  This can result in a use-after-free if the task exits before completion handling finishes.  Take a reference with mmgrab() when queuing the read request and release it with mmdrop() on request completion.

CVE-2026-90048:

        In the Linux kernel, the following vulnerability has been resolved:  fs/ntfs3: fix slab-out-of-bounds write in ni_create_attr_list()  ni_create_attr_list() allocates a fixed buffer of al_aligned(record_size) (== record_size) bytes and then walks every attribute of the primary MFT record, writing one ATTR_LIST_ENTRY per attribute and advancing the cursor by le_size(name_len), with no check against the end of the buffer; the total size is only computed after the loop.  A minimum-size resident attribute occupies SIZEOF_RESIDENT (0x18 = 24) bytes on disk, but an unnamed attribute expands to le_size(0) (0x20 = 32) bytes in the list.  Because the number of attributes in a record is not bounded (mi_enum_attr() accepts arbitrarily many equal-type, nameless minimum-size attributes), a crafted record packed with such attributes produces a list larger than record_size and overflows the heap buffer.  This is reachable from a crafted, loop-mounted NTFS image: opening the file and adding an attribute (e.g. via setxattr) drives ntfs_set_ea() -> ni_insert_resident() -> ni_insert_attr() -> ni_ins_attr_ext() -> ni_create_attr_list().    BUG: KASAN: slab-out-of-bounds in ni_create_attr_list+0xc48/0x1058   Write of size 4 at addr ffff000008984c00 by task setfattr/345    ni_create_attr_list+0xc48/0x1058    ni_ins_attr_ext+0x510/0x7c0    ni_insert_attr+0x3f8/0x70c    ni_insert_resident+0xc8/0x3b0    ntfs_set_ea+0x66c/0xd28    ntfs_setxattr+0x4d8/0x5b0    __arm64_sys_setxattr+0xa4/0x124   Allocated by task 345:    ni_create_attr_list+0x188/0x1058   The buggy address belongs to the cache kmalloc-1k of size 1024   (the write lands at object+1024).  Size the buffer from the actual attributes instead of assuming a single record_size is always enough.

CVE-2026-90061:

        In the Linux kernel, the following vulnerability has been resolved:  netfilter: nf_tables: skip double clone set expressions on element insert  Both the dynset and newsetelem path clone the existing set expressions when setting set element expressions if no override expressions are provided. This results in a double clone, once to clone the template set expressions then another clone on the new element. Add a flag to annotate if userspace provides a override expression (ie. expression of the same type of the set but different configuration), otherwise borrow the existing expression from the set. Add conditionals to release expression iif they represent an override. Use this new override_exprs flag to dump the dynset expression override to userspace.  This simplifies the existing logic and it also fixes a bug with the connlimit expression which results in a module refcount imbalance WARNING splat when resorting on the default set expressions.

CVE-2026-90066:

        In the Linux kernel, the following vulnerability has been resolved:  samples/ftrace: Fix kthread_stop() on ERR_PTR in ftrace-direct-multi-modify  ftrace_direct_multi_init() assigns kthread_run()'s return value to simple_tsk without an IS_ERR() check. When kthread_run() fails it returns ERR_PTR(-ENOMEM), but init still returns 0, so the module loads with simple_tsk holding an error pointer. On unload, ftrace_direct_multi_exit() then passes that ERR_PTR to kthread_stop(), leading to a null-pointer-dereference.  Check the return value of kthread_run() with IS_ERR(); on failure, unregister the ftrace direct call and propagate the error code.

CVE-2026-90076:

        In the Linux kernel, the following vulnerability has been resolved:  net/sched: fq: add overflow bounds to quantum and initial quantum  fq_init() computes quantum = 2 * psched_mtu() and initial_quantum = 10 * psched_mtu() with no overflow check. A device with a huge MTU (e.g. dummy with max_mtu == 0 accepting MTU 2147483634) makes psched_mtu() return 0x80000000; the 2 * and 10 * multiplications wrap to 0 in 32-bit arithmetic, so q->quantum == 0. Then in fq_dequeue() the credit-refill loop adds 0 to f->credit (which stays <= 0) and goto begin loops forever under the qdisc lock, creating a soft lockup.  Clamp psched_mtu() to [1, 1 << 20] before multiplying so the product cannot wrap, then cap the result at 1 << 20, matching the bound already enforced on TCA_FQ_QUANTUM in fq_change().  Conditions to recreate the bug: a device whose MTU (plus hard_header_len) is large enough that 2 * psched_mtu() wraps (e.g. a dummy device with max_mtu == 0 accepting MTU 2147483634). Requires CAP_NET_ADMIN in a user namespace.

CVE-2026-90083:

        In the Linux kernel, the following vulnerability has been resolved:  net/sched: act_ife: Only operate on Ethernet frames  act_ife encapsulates/decapsulates the original Ethernet header and uses skb->dev->hard_header_len as the length of that header. That is only correct for Ethernet devices: on a device where hard_header_len does not match the L2 header that was actually pulled (PPP reports PPP_HDRLEN while nothing is stripped on ingress), the ingress skb_push()/skb_pull() use the wrong length and can hit skb_under_panic when headroom is tight.  IFE is Ethernet-only by design - it builds an outer ethhdr, rewrites h_source/h_dest/h_proto, and calls eth_type_trans() on decode - so instead of trying to make the offsets work for arbitrary link types, simply drop packets that do not carry an Ethernet header.  Checking skb->dev->type alone is not enough. We have to cater for a corner case where mirred can redirect an skb from a non-Ethernet device to an Ethernet one, and skb->dev then says nothing about the framing the skb actually has: an skb redirected from ppp0 reaches the target's ingress hook with mac_len 0 and no Ethernet header at all. So at ingress also require mac_len to be ETH_HLEN. On egress mac_len is not maintained, so the device type is all we have; a bogus redirect there yields a malformed frame rather than an out-of-bounds push, and it would be malformed with or without IFE.  That corner case is not theoretical - redirecting from ppp0 into a veth that has an ife encode action on its ingress hook panics without this patch:    skbuff: skb_under_panic: len:98 put:14 head:ffff88800e410000           data:ffff88800e40fff5 tail:0x57 end:0x640 dev:veth3   kernel BUG at net/core/skbuff.c:214!   Call Trace:    skb_push (net/core/skbuff.c:224 net/core/skbuff.c:2657)    tcf_ife_act (net/sched/act_ife.c:829 net/sched/act_ife.c:874)    tc_run (net/core/dev.c:4463)    netif_receive_skb (net/core/dev.c:6463 net/core/dev.c:6522)    tcf_mirred_to_dev (net/sched/act_mirred.c:248 net/sched/act_mirred.c:328)    tcf_mirred_act (net/sched/act_mirred.c:489)    tc_run (net/core/dev.c:4463)    process_backlog (net/core/dev.c:6728)  With Ethernet framing guaranteed, use ETH_HLEN instead of hard_header_len.

CVE-2026-90084:

        In the Linux kernel, the following vulnerability has been resolved:  octeontx2-vf: fix workqueue and netdev race in probe/remove  Initialize the VF workqueue before register_netdev() so ndo_set_rx_mode does not queue work on a NULL workqueue. Unregister the netdev before destroying the workqueue, and add proper probe error cleanup.

CVE-2026-90087:

        In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: do not leak an hci_conn when a second LE connect is rejected  create_le_conn_complete() decides whether the failed connection is still pending by comparing it against hci_lookup_le_connect(), which returns the first LE connection in BT_CONNECT. That is the same connection only while at most one is pending.  Two can be pending. Connections created on the passive scan path sit in BT_CONNECT with HCI_CONN_SCANNING set and are invisible to hci_lookup_le_connect() until hci_le_create_conn_sync() clears the flag when their command is issued, so the -EBUSY guard in hci_connect_le() does not prevent a second connection from being queued while the first is still on the scan path. Whenever two connections are in BT_CONNECT at once, the lookup may return one connection while create_le_conn_complete() is reporting the failure of the other; the early exit then drops the error and hci_conn_failed() never runs on the connection that failed.  The controller also rejects a second HCI_OP_LE_CREATE_CONN issued while another connection creation is still outstanding, per Core Spec Vol 4, Part E. The spec calls for Command Disallowed there; the bcm43438 observed here answers with an LMP/LL error code instead, which bt_to_errno() maps to the -EPROTO (-71) in the log below.  The leaked connection stays in BT_CONNECT forever, and because hci_connect_le() refuses to dial while hci_lookup_le_connect() finds anything, every subsequent attempt to reach any peer fails with -EBUSY and no command reaches the controller at all.  Seen on a bcm43438 with two BLE peers polled on the same interval (state 5 is BT_CONNECT; both handles are UNSET ones, allocated from the ida above HCI_CONN_HANDLE_MAX):    Bluetooth: hci1: Opcode 0x2013 failed: -71    # hcitool con           < LE 14:9C:EF:03:68:81 handle 3840 state 5 lm CENTRAL           < LE C4:D3:6A:8C:B5:38 handle 3841 state 5 lm CENTRAL  A btmon capture across the next ten minutes of connect attempts contains no HCI_OP_LE_CREATE_CONN at all; outgoing LE connections do not recover until the adapter is reset. With this change the same scenario fails the rejected connection cleanly and further connects to both peers go through.  Ask about the connection itself instead of about the device.

CVE-2026-90093:

        In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: L2CAP: access chan->conn safely in get/setsockopt  Since commit b66774b48dd9 ("Bluetooth: L2CAP: Fix UAF in channel timeout by holding conn ref") l2cap_chan::conn has held reference and remains non-NULL also after the corresponding hci_conn is deleted.  In this state accessing various fields eg. hci_conn::hdev is invalid, which leads to KASAN crash in l2cap_sock_setsockopt() access of conn->hcon->hdev.  Check l2cap_chan::conn.hcon corresponds to an alive hci_conn before trying to use it in l2cap_sock.c.  Hold l2cap_chan_lock() in getsockopt/setsockopt to ensure it stays alive, and to avoid data races in l2cap_chan fields.

CVE-2026-90097:

        In the Linux kernel, the following vulnerability has been resolved:  Drivers: hv: vmbus: Skip VMBus module cleanup for non-nested root partition  The VMBus module initialization function, hv_acpi_init(), currently does nothing when running in the root partition and root is not nested in another VM. But the initialization function reports success, so the VMBus module is indeed loaded. VMBus functionality is not actually needed, but the VMBus module must be loaded so that hv_vmbus_exists() can answer correctly. Furthermore, the mshv_root dependency on the VMBus module is needed as described in the commit message for 840b740a35bf ("mshv: Add conditional VMBus dependency").  Loading the VMBus module without actually initializing it causes failures if the module should later be unloaded. The module unload code tries to clean up things that were never initialized, resulting in memory faults and a panic.  Fix this by having VMBus module exit function perform the same check for non-nested root partition, and do nothing in such a case, just like hv_acpi_init().  In the long run, the code that manages the Hyper-V provided SynIC should be refactored to better coordinate the requirements of root partition scenarios and normal VM scenarios, and to hopefully remove the hv_vmbus_exists() dependnecy between mshv_root and VMBus modules. Preventing the current unload failure scenario is an expediency until such a refactoring is done.

CVE-2026-90098:

        In the Linux kernel, the following vulnerability has been resolved:  net: sparx5: fix sleep in atomic context in MAC table access  sparx5_set_rx_mode() runs with netif_addr_lock_bh held and iterates dev->mc via __dev_mc_sync(), which per address calls sparx5_mc_sync() / sparx5_mc_unsync() -> sparx5_mact_learn() / sparx5_mact_forget().  These take sparx5->lock, a mutex, and then poll the MAC access command register with readx_poll_timeout(). A mutex may block, which is not allowed from atomic context.  Convert the driver to the new .ndo_set_rx_mode_async callback introduced in commit 3554b4345d85 ("net: introduce ndo_set_rx_mode_async and netdev_rx_mode_work"). The async callback is invoked from process context, so the mutex and sleeping completion poll can remain.  Observed with CONFIG_PROVE_LOCKING, CONFIG_DEBUG_SPINLOCK, CONFIG_DEBUG_MUTEXES and CONFIG_DEBUG_ATOMIC_SLEEP enabled:    BUG: sleeping function called from invalid context at kernel/locking/mutex.c:591   in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 217, name: ip   preempt_count: 201, expected: 0   Call trace:    __might_resched+0x144/0x248    __might_sleep+0x48/0x7c    __mutex_lock+0x74/0x850    mutex_lock_nested+0x24/0x30    sparx5_mact_learn+0x78/0x100    sparx5_mc_sync+0x40/0x54    __hw_addr_sync_dev+0xc4/0x170    sparx5_set_rx_mode+0x4c/0x58    __dev_set_rx_mode+0x64/0xa4    __dev_open+0x1ec/0x26c

CVE-2026-90099:

        In the Linux kernel, the following vulnerability has been resolved:  net/sched: account classifier filter allocations to memcg  Allocations in the tc classifier *_change() paths (filter objects, per-CPU counters, and per-filter aux data) use plain GFP_KERNEL without __GFP_ACCOUNT, allowing unprivileged users to pin kernel memory outside memcg charging. The shared tcf_exts_init_ex() action array allocation in cls_api.c was also uncharged; this patch closes it along with the per-classifier filter-object/percpu/aux allocations that remain unaccounted.  Add GFP_KERNEL_ACCOUNT to: - the shared tcf_exts_init_ex() action array (cls_api.c), common to every   filter of every classifier (32 pointers, 256 bytes); - the filter-object, per-CPU-counter, and per-filter aux allocations in   cls_basic, cls_bpf, cls_cgroup, cls_flow, cls_flower, cls_fw,   cls_matchall, cls_route and cls_u32; - the u32_init_knode() replace-path knode allocation (cls_u32.c), which   allocates the same struct tc_u_knode + sel.keys on every replace of an   existing knode and was missed by the create-path-only conversion.  Also fix the cls_basic error path: basic_change() inserts fnew into the IDR before allocating the per-CPU counter. If alloc_percpu() fails the errout path kfree'd fnew without idr_remove, leaving a dangling pointer in the IDR. With GFP_KERNEL_ACCOUNT the percpu alloc becomes failable on demand (memcg at memory.max), making the dead path attacker-reachable and burning the handle permanently. Add the idr_remove on the percpu failure path, matching the basic_set_parms failure-path pattern.  Note: vega@nebusec.ai provided a poc for basic_cls, but it was easy to extend to the other classifiers.  Conditions to recreate the bug: - CONFIG_NET_SCHED, CONFIG_NET_CLS_* (the classifier being used),   CONFIG_NET_CLS_ACT, CONFIG_MEMCG, CONFIG_USER_NS, CONFIG_NET_NS. - Unprivileged user in a fresh user+network namespace (unshare -Urn),   or root with CAP_NET_ADMIN. - Create a large number of tc filters (e.g. tc filter add dev lo   ingress ... <classifier> ...) while watching a memcg-limited cgroup:   system slab grows far faster than memory.current, pinning kernel   memory outside memcg charging.

CVE-2026-90104:

        In the Linux kernel, the following vulnerability has been resolved:  NFSv4.1: zero referring call lists before decoding  decode_cb_sequence_args() allocates csa_rclists with kmalloc_objs(), so each referring_call_list starts uninitialized. decode_rc_list() assigns rcl_refcalls only when rcl_nrefcalls is nonzero. A valid list with zero referring calls therefore leaves the pointer uninitialized, and nfs4_callback_sequence() later passes stale slab contents to kfree().  Allocate csa_rclists with kzalloc_objs() so every rcl_refcalls member is NULL from the beginning, including valid empty referring call lists.

CVE-2026-90105:

        In the Linux kernel, the following vulnerability has been resolved:  vxlan: fix reading neigh ha  Currently arp/neigh_reduce read neigh ha directly which can lead to partial reads while the neigh is being updated. Use neigh_ha_snapshot to take a stable snapshot of the address similar to route_shortcircuit which already does the right thing.

CVE-2026-90106:

        In the Linux kernel, the following vulnerability has been resolved:  net: bridge: arp/nd proxy: fix reading neigh ha  Currently neigh ha address is read directly, but that can result in torn/partial reads if the neigh is being updated. Use neigh_ha_snapshot to take a stable snapshot of the address.

CVE-2026-90109:

        In the Linux kernel, the following vulnerability has been resolved:  net: sched: fix 32-bit backlog wrap in gred, bfifo and plug enqueue  gred_enqueue(), bfifo_enqueue() and plug_enqueue() admit a packet when the current backlog plus the packet length fits within the queue limit:    sch->qstats.backlog + qdisc_pkt_len(skb) <= sch->limit (gred default VQ)   gred_backlog+qdisc_pkt_len(skb) <= q->limit  (gred configured VQ)   sch->qstats.backlog + qdisc_pkt_len(skb) <= sch->limit (bfifo)   sch->qstats.backlog + skb->len <= q->limit             (plug)  sch->qstats.backlog and q->backlog are u32, and qdisc_pkt_len()/skb->len are unsigned int, so all sums are computed in 32 bits and wrap at 2^32. Once the true backlog exceeds 4 GiB the wrapped sum becomes small and admission keeps succeeding, so the queue grows without bound and the kernel can be driven to OOM.  Promote the sums to u64 so admission stops once the true backlog exceeds the limit.  The limit is u32, so the bounded queue stays below 2^32 and the stored u32 backlog never wraps.  The bug can only be reproduced as root (albeit with ridiculous setup):  attach a gred (or bfifo/plug) qdisc with a limit near 4 GiB,  leaving the default VQ unconfigured (for gred), and drive >4 GiB of  queued traffic (e.g. via a size table / stab to inflate qdisc_pkt_len,  or sustained high-rate traffic). The u32 backlog+len sum wraps at 2^32,  admission keeps succeeding, and the queue grows unboundedly to OOM.

CVE-2026-90111:

        In the Linux kernel, the following vulnerability has been resolved:  ip6mr: do not clone dst in ip6mr_cache_report()  IPv6 input attaches a non-refcounted (NOREF) dst to skbs under RCU. When an ingress multicast packet misses MFC lookup, ip6mr_cache_unresolved() places the skb onto the unresolved queue, escaping the receive-side RCU grace period.  If the underlying route is deleted and freed, and the MFC queue is later resolved with a wrong parent interface, ip6_mr_forward() invokes ip6mr_cache_report(..., MRT6MSG_WRONGMIF), which executes dst_clone(skb_dst(pkt)) on the freed dst entry, triggering a slab use-after-free.  Report packets queued to mroute6_sk (a raw socket) and netlink notifications do not require an attached dst entry.  Fix this by: 1. Removing dst_clone() in ip6mr_cache_report() and ensuring report skbs    do not hold a dst. 2. Dropping skb_dst before queuing unresolved skbs in    ip6mr_cache_unresolved(), matching the fact that multicast    forwarding resolves outgoing routes anew via ip6_route_output().

CVE-2026-90112:

        In the Linux kernel, the following vulnerability has been resolved:  net: qlcnic: validate unified ROM sections before loading  The unified ROM parser reads directory, product, and data-descriptor fields from the firmware file.  Existing validation forms table and data ends with unchecked additions and multiplications.  Malformed values can wrap before they are compared with the firmware size.  The parser also dereferences typed pointers at firmware-controlled offsets.  Valid descriptor extents alone are insufficient for the consumers.  The loader reads a fixed-size bootloader regardless of its declared size, the version parser assumes a 17-byte tail, and a partial final firmware word is read as a full u64.  A truncated image can therefore make the driver read beyond the firmware allocation during validation or loading.  Replace the pointer-returning parser with bounded range helpers.  Validate table entry sizes, descriptor indices, section ranges, the fixed bootloader load length, and the version tail before exposing any section. Read all file fields with unaligned little-endian accessors and assemble a partial final word from only the bytes that remain.  Apply the same range checks to the legacy image before reading its fixed fields.

CVE-2026-90116:

        In the Linux kernel, the following vulnerability has been resolved:  ALSA: mtpav: shut down output timer before card teardown  snd_mtpav_output_timer() rearms chip->timer while holding chip->spinlock and accesses the card-private mtpav state.  snd_mtpav_free() currently takes the same lock and calls timer_delete() when the timer is active. This only removes a pending timer; it does not wait for a callback that is already running and does not prevent the callback from rearming the timer.  A callback running on another CPU can therefore continue after snd_mtpav_free() releases the lock and access the card-private state while the card is being torn down. It can also rearm the timer after timer_delete() has returned.  Call timer_shutdown_sync() without holding chip->spinlock. This waits for any running callback to finish and prevents further rearming before the card-private mtpav state is released.

CVE-2026-90119:

        In the Linux kernel, the following vulnerability has been resolved:  ALSA: ice1712: Fix the card leak at probe error with the auto-cleanup  snd_ice1712_probe() performs multiple initialization steps after snd_card_new(), but directly returns on failures from later steps without releasing the ALSA card, causing resource leaks when probing fails.  Use snd_devm_card_new() together with scope-based cleanup via __free(snd_card_unref), and clear the card pointer after successful registration to keep it alive.

CVE-2026-90125:

        In the Linux kernel, the following vulnerability has been resolved:  smb: client: fix request buffer leak in smb2_new_read_req()  smb2_new_read_req() allocates the request buffer with smb2_plain_req_init() but only publishes it to the caller with *buf = req at the very end of the function. Two error returns sit in between:  	rc = smb2_plain_req_init(SMB2_READ, io_parms->tcon, server, 				 (void **) &req, total_len); 	if (rc) 		return rc;  	if (server == NULL) 		return -ECONNABORTED; 	[...] 		rdata->mr = smbd_register_mr(server->smbd_conn, 					     &rdata->subreq.io_iter, 					     true, need_invalidate); 		if (!rdata->mr) 			return -EAGAIN;  On either of them the buffer is neither released nor handed back, so it is leaked. The caller cannot clean up after it: smb2_async_readv() does 'goto out' on a non-zero return, which skips the cifs_small_buf_release(buf) at async_readv_out, and buf has not been assigned at that point in any case.  The write path has never had this problem. smb2_async_writev() registers the memory region inline and jumps to its release label instead of returning:  	wdata->mr = smbd_register_mr(...); 	if (!wdata->mr) { 		rc = -EAGAIN; 		goto async_writev_out; 	}  Commit b7972092199f ("cifs: smbd: Retry on memory registration failure") changed both sides from -ENOBUFS to -EAGAIN in a single patch, which puts the two shapes next to each other.  Only the -EAGAIN return is reachable in practice, because smb2_plain_req_init() calls smb2_reconnect() first and that already fails with -EIO when server is NULL, before anything is allocated. Both returns are given the same treatment here rather than leaving one of them correct only by accident.  Because -EAGAIN is a replayable error, the failure also reaches the retry block at the end of smb2_async_readv(), which marks the subrequest NETFS_SREQ_NEED_RETRY, so a failing registration can be retried rather than ending the I/O, and every attempt that reaches it leaks another buffer. smb2_should_replay() short-circuits on tcon->retry, so on a hard mount the attempt count is not bounded by the retrans setting.  Only the asynchronous read path is affected. The synchronous SMB2_read() caller passes rdata == NULL and the memory registration block is guarded on rdata.  The memory registration failure path was pointed out by the Sashiko AI reviewer while it was reviewing an unrelated patch to smb2_async_readv().

CVE-2026-90135:

        In the Linux kernel, the following vulnerability has been resolved:  net: add missing ref_tracker_dir_exit() to alloc_netdev_mqs()  sashiko is reporting that trying to read /sys/kernel/debug/ref_tracker/* causes use-afer-free crash when either alloc_percpu() or dev_addr_init() in alloc_netdev_mqs() failed, for commit 4d92b95ff2f9 ("net: add net device refcount tracker infrastructure") added ref_tracker_dir_exit() to only free_netdev() path.

CVE-2026-90138:

        In the Linux kernel, the following vulnerability has been resolved:  vsock: don't check the listener's sk_err in vsock_accept()  Syzbot reported an issue which can be reproduced with these steps: 	r0 = socket(AF_VSOCK, SOCK_STREAM, 0) 	bind(r0, {VMADDR_CID_ANY, PORT}) 	connect(r0, {VMADDR_CID_LOCAL, PORT}) -> -1, EPROTO (self-connect) 	listen(r0, backlog)                   -> 0 	r1 = socket(AF_VSOCK, SOCK_STREAM, 0) 	connect(r1, {VMADDR_CID_LOCAL, PORT}) -> 0 	accept(r0)                            -> -1, EPROTO (stale sk_err)  Basically, it creates a socket (r0) and triggers a self-connect after binding it. This self-connect fails with EPROTO because it loops back to r0 while the socket is still in the TCP_SYN_SENT state, causing it to be incorrectly dispatched to the connecting-client path. The unexpected packet type encountered there sets sk_err to EPROTO.  After that, it invokes a listen() call on the same socket. This listen() call succeeds because the kernel's listening path never inspects or clears sk_err. Then, a new socket (r1) is created as a normal client and connects to r0. However, vsock_accept() rejects this incoming connection because the listener's sk_err still holds the EPROTO error from the earlier failed self-connect.  This rejection causes the child socket created for r1's connection to never be freed on virtio or hyperv transports; only the VMCI transport implements pending_work to revisit and clean up a rejected socket.  For a non-blocking connect(), vsock_connect() may return -EINPROGRESS immediately, and vsock_connect_timeout() can later set sk->sk_err asynchronously.  Since no vsock transport ever sets sk_err on a socket while it is in TCP_LISTEN state, checking it in vsock_accept() serves no purpose and only carries forward errors left behind by earlier, unrelated connection attempts on the same socket. Remove the checks so accept() no longer rejects valid incoming connections because of a stale error, which also avoids the resource leak described above.

CVE-2026-90139:

        In the Linux kernel, the following vulnerability has been resolved:  fuse: check for NULL root inode in fuse_fill_super_submount  fuse_iget() can return NULL when its inode allocation fails, but fuse_fill_super_submount() passed the result straight to get_fuse_inode() and decremented fi->nlookup without checking it:          root = fuse_iget(sb, parent_fi->nodeid, ...);         fi = get_fuse_inode(root);         fi->nlookup--;  Inside fuse_iget() the inode allocation can fail and return NULL.  The submount root takes the iget5_locked() path, whose alloc_inode() can fail under memory pressure (the auto-submount branch can fail the same way in new_inode() or fuse_alloc_submount_lookup()):          inode = iget5_locked(sb, nodeid, fuse_inode_eq, fuse_inode_set,                              &nodeid);         if (!inode)                 return NULL;  A NULL root makes get_fuse_inode() a container_of() on NULL and the nlookup decrement a write to a bogus address, oopsing the mount.  With CONFIG_KASAN the following null pointer dereference is reported when the root inode allocation of an auto-submount fails (e.g. under memory pressure):  ================================================================== BUG: KASAN: null-ptr-deref in fuse_get_tree_submount+0x656/0x8b0 Read of size 8 at addr 00000000000002b0 by task ls/942 CPU: 0 PID: 942 Comm: ls Tainted: G W 6.6 #15 Call Trace:  <TASK>  fuse_get_tree_submount+0x656/0x8b0  vfs_get_tree+0x48/0x140  fc_mount+0x13/0x50  fuse_dentry_automount+0x7a/0xb0  __traverse_mounts+0xca/0x330  step_into+0x339/0xac0  path_lookupat+0xc5/0x2f0  filename_lookup+0x163/0x2a0  vfs_statx+0xd5/0x200  do_statx+0x83/0xd0  __x64_sys_statx+0xa0/0xc0  do_syscall_64+0x37/0x90  entry_SYSCALL_64_after_hwframe+0x78/0xe2  </TASK> ==================================================================  Return -ENOMEM instead; the caller tears down the partially built superblock on error, matching the other error returns in this function.

CVE-2026-90146:

        In the Linux kernel, the following vulnerability has been resolved:  bpf, xdp: move offload check into dev_xdp_install()  bpf_xdp_link_update() calls dev_xdp_install() directly and skips dev_xdp_attach(), so the checks in dev_xdp_attach() do not run. A user can make an XDP link with a normal program and then swap in an offloaded or device-bound program with BPF_LINK_UPDATE, which puts it on the software path.  dev_xdp_install() is the one place all three paths go through: "ip link set xdp" and BPF_LINK_CREATE reach it via dev_xdp_attach(), and BPF_LINK_UPDATE calls it directly. So move the program checks (offloaded, bound to another device, device-bound in generic mode, native vs generic, DEVMAP and CPUMAP) there, and keep only the netlink-flag check (XDP_FLAGS_UPDATE_IF_NOEXIST) in dev_xdp_attach().

CVE-2026-90148:

        In the Linux kernel, the following vulnerability has been resolved:  NFSv4: Fix incorrect argument passed to nfs4_delete_lease() in nfs4_add_lease()  When nfs4_add_lease() races with a delegation return, it calls nfs4_delete_lease() to clean up. Previously, it passed priv, which can legitimately be NULL. Passing a NULL priv eventually leads to a NULL pointer dereference in generic_setlease().

CVE-2026-90149:

        In the Linux kernel, the following vulnerability has been resolved:  NFSv4/flexfiles: fix NULL dereference for NFSv4.0 data servers  flexfiles accepts NFSv4.0 data servers, but two NFSv4 code paths assume the data server client has a session. Unlike NFSv4.1+, an NFSv4.0 client has no session (clp->cl_session is NULL; it uses clp->cl_slot_tbl), so I/O to a v4.0 flexfiles DS oopses:    - nfs4_init_ds_session() dereferences clp->cl_session->session_state     while seeding the DS lease. It also only seeds cl_lease_time when     NFS4_SESSION_INITING is set; without a session that never happens, so     cl_lease_time stays 0 and nfs4_renew_state() busy-loops, requeuing     every 5 seconds. Seed the lease whenever there is no session and     return before touching session state.    - ff_layout_async_handle_error_v4() dereferences     clp->cl_session->fc_slot_table on every DS I/O error. Fall back to the     v4.0 transport slot table (clp->cl_slot_tbl) when there is no session.

CVE-2026-90150:

        In the Linux kernel, the following vulnerability has been resolved:  pnfs/blocklayout: Fix device leaks on parse failure  bl_parse_concat() and bl_parse_stripe() allocate a child device array and then parse each child in turn.  If parsing a child fails, the failed child is not counted in nr_children and the parent may be left with a children array that bl_free_device() will not release when nr_children is zero.  Release the failed child and the already parsed children before returning the error.  Also make bl_free_device() release the child array whenever the children pointer is set, so that partially initialised concat or stripe devices are cleaned up correctly.  bl_parse_scsi() can also fail after assigning d->bdev_file and dropping the file reference.  Clear the pointer after fput() so that an outer cleanup path does not put it again.

CVE-2026-90152:

        In the Linux kernel, the following vulnerability has been resolved:  smb/server: fix session leak in ksmbd_session_register()  See the procedure below:    smb2_sess_setup     ksmbd_smb2_session_create       __session_create         atomic_set(&sess->refcnt, 2)         hash_add(sessions_table, &sess->hlist, sess->id)     ksmbd_session_register       xa_store(&conn->sessions, sess->id, sess) // fail     ksmbd_user_session_put       atomic_dec(&sess->refcnt) // refcnt is 1, session is not freed  Remove the session from sessions_table and drop its table reference if xa_store() fails.

CVE-2026-90153:

        In the Linux kernel, the following vulnerability has been resolved:  ksmbd: bound smb_check_perm_dacl() ACE walks by DACL size  smb_check_perm_dacl() validates that the DACL fits inside the NT security descriptor, but then bounds its two ACE walks by the remaining NTSD length (acl_size) rather than the DACL's declared size (pdacl_size).  When pdacl->size is smaller than the trailing NTSD buffer, bytes after the declared DACL boundary - still inside the stored security descriptor - are parsed as ACEs during access checks.  A crafted DACL can place an access-granting ACE beyond pdacl->size, and the current code accepts it during SMB2_CREATE access validation, while parse_dacl() and smb_inherit_dacl() stop at pdacl_size.  Bound both ACE walks by pdacl_size to match the DACL boundary semantics used elsewhere in the server.  Validation: - semantic KUnit harness shows the post-boundary ACE is selected   before the fix and rejected (EACCES) after it - linux master (7.2-rc6), x86_64

CVE-2026-90154:

        In the Linux kernel, the following vulnerability has been resolved:  ksmbd: scope session state changes to bound connections  ksmbd_all_conn_set_status() treats every connection whose transient binding flag is set as belonging to the target SessionId.  A logoff or session replacement can consequently move an unrelated connection to NEED_RECONNECT or NEED_SETUP.  Pass the target session itself and select connections using either the connection-local session xarray or the session's permanent channel list. Use the same association test while waiting for requests to drain.  Serialize session-wide status changes under request_lock and do not overwrite EXITING or RELEASING. Protect the shutdown transition with the same lock so a concurrent session update cannot revive a closing connection.

CVE-2026-90155:

        In the Linux kernel, the following vulnerability has been resolved:  ksmbd: detach blocked lock requests before freeing  A file_lock retained by ksmbd for byte-range lock bookkeeping can still be part of the VFS blocked-request graph. In particular, the VFS can chain a new waiter below an already blocked request through flc_blocked_requests. The ksmbd_file reference count does not cover that graph.  Both __ksmbd_close_fd() and the cross-request unlock path free these retained file_lock objects directly. If a dependent waiter is still attached, locks_release_private() hits BUG_ON(!list_empty(&flc->flc_blocked_requests)). The same lifetime mismatch can leave a freed ksmbd_lock reachable through its request-local llist.  Detach the file_lock from the blocked-request graph before freeing it in the close, cross-request unlock, and rollback paths. locks_delete_block() also wakes requests chained below the object. Remove llist when a completed lock is published so a globally visible ksmbd_lock no longer points into the submitting worker's stack.

CVE-2026-90156:

        In the Linux kernel, the following vulnerability has been resolved:  ksmbd: safely discard unregistered deferred locks  When vfs_lock_file() defers a lock, smb2_lock() puts its ksmbd_lock on rollback_list before allocating and registering the asynchronous work. If either operation fails, rollback assumes that smb_lock->conn is initialized and dereferences NULL. The deferred file_lock also remains linked into the VFS blocked-lock state while it is freed.  Keep the lock off rollback_list until async setup succeeds. On setup failures, explicitly unblock and wake the deferred lock before freeing it and its ksmbd wrapper.

CVE-2026-90161:

        In the Linux kernel, the following vulnerability has been resolved:  erofs: fix interlaced ztailpacking pclusters  On-disk sizes of interlaced pclusters should be block-aligned, and ztailpacking interlaced pclusters should be invalid at all.  Currently, mkfs.erofs won't generate any interlaced pcluster with ztailpacking enabled, so this doesn't affect any existing valid filesystems.  However, crafted images can contain invalid interlaced ztailpacking pclusters, resulting in an out-of-bounds read from a kmap'd page and copying irrelevant kernel memory into userspace-visible page cache.

CVE-2026-90162:

        In the Linux kernel, the following vulnerability has been resolved:  ksmbd: defer publishing granted locks to prevent UAF/double-free race  In smb2_lock(), mid-batch granted locks are published to connection-wide (conn->lock_list) and file-wide (fp->lock_list) lists immediately upon vfs_lock_file() success, while also remaining tracked on the stack-local rollback_list.  If a subsequent element in the same SMB2_LOCK request array fails validation or execution, the thread jumps to out: and walks rollback_list to undo previously granted locks. However, because the granted lock was already published to conn->lock_list, a concurrent UNLOCK request on the same connection can find the lock object and kfree() it before the rollback loop executes.  When the granting thread subsequently walks rollback_list, it dereferences and frees the already-freed ksmbd_lock structure, resulting in a Use-After-Free and Double-Free (on both ksmbd_lock and struct file_lock).  Fix this by deferring the publication of granted locks to conn->lock_list and fp->lock_list until after the entire array of lock elements has been processed without error. Mid-batch grants remain tracked exclusively on the request-local rollback_list until the whole batch succeeds, eliminating the race window.

CVE-2026-90166:

        In the Linux kernel, the following vulnerability has been resolved:  smb/server: fix null-ptr-deref in ksmbd_ipc_tree_connect_request()  See the procedure below:    ksmbd_tree_conn_connect     ksmbd_share_config_get       share->name = kstrdup() // fail       if (!test_share_config_flag(share, KSMBD_SHARE_FLAG_PIPE)) // false       // do not check `share->name`     ksmbd_ipc_tree_connect_request       strlen(share->name) // null-ptr-deref

CVE-2026-90167:

        In the Linux kernel, the following vulnerability has been resolved:  ksmbd: serialize oplock close with pending break ownership  close may abort an in-flight oplock break while another breaker already holds an opinfo reference. Releasing pending_break wakes that waiter, but without serializing the close transition with bit acquisition it can become a new break owner through the test_and_set_bit() fast path. It can then overwrite OPLOCK_CLOSING with OPLOCK_ACK_WAIT and continue a break for a dying opinfo.  Make OPLOCK_CLOSING terminal once the opinfo is removed from the inode list. Serialize that transition, pending_break acquisition, and OPLOCK_ACK_WAIT setup with an opinfo state lock. A breaker which loses the race releases its ownership and returns -ENOENT. Explicitly wake pending_break waiters during close so they can observe the terminal state.  Also prevent ACK and timeout paths from replacing OPLOCK_CLOSING with OPLOCK_STATE_NONE.

CVE-2026-90169:

        In the Linux kernel, the following vulnerability has been resolved:  ksmbd: free preauth sessions on connection teardown  SMB3.1.1 multichannel binding preserves the preauthentication hash in a preauth_session between the NTLM negotiate and authenticate requests. The binding NTLM negotiate allocates this object and returns STATUS_MORE_PROCESSING_REQUIRED. If the client disconnects before it sends the authenticate request, neither the authenticate nor error cleanup paths free the object.  Release any remaining preauthentication sessions when tearing down the connection. Initialize the list when allocating the connection so that this cleanup is safe regardless of the negotiated dialect.

CVE-2026-90174:

        In the Linux kernel, the following vulnerability has been resolved:  ksmbd: fix slab-out-of-bounds read in ksmbd_alloc_user()  ksmbd_alloc_user() copies resp->hash_sz bytes out of the mountd IPC login response with  	user->passkey_sz = resp->hash_sz; 	user->passkey = kmalloc(resp->hash_sz, KSMBD_DEFAULT_GFP); 	if (user->passkey) 		memcpy(user->passkey, resp->hash, resp->hash_sz);  resp->hash_sz is a __u16 supplied by the response, but resp->hash[] is only KSMBD_REQ_MAX_HASH_SZ bytes.  A malformed or malicious login response can set hash_sz well beyond that (up to 65535), so the memcpy() reads past the end of the response object.  ipc_validate_msg() does not bound hash_sz, so reject any response whose hash_sz exceeds the on-stack hash[] buffer before allocating and copying.  [ 2030.238706] BUG: KASAN: slab-out-of-bounds in ksmbd_alloc_user+0x278/0x680 [ 2030.240549] Read of size 65535 at addr ffff888121bb6680 by task kworker/4:1/18611 [ 2030.242296] [ 2030.242710] CPU: 4 UID: 0 PID: 18611 Comm: kworker/4:1 Not tainted 7.1.0-next-20260623-virtme #96 PREEMPT(lazy) [ 2030.242732] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 [ 2030.242743] Workqueue: ksmbd-io handle_ksmbd_work [ 2030.242763] Call Trace: [ 2030.242769]  <TASK> [ 2030.242776]  dump_stack_lvl+0xa2/0xd0 [ 2030.242794]  print_address_description+0x77/0x200 [ 2030.242815]  ? ksmbd_alloc_user+0x278/0x680 [ 2030.242831]  print_report+0x58/0x70 [ 2030.242848]  kasan_report+0x117/0x150 [ 2030.242869]  ? ksmbd_alloc_user+0x278/0x680 [ 2030.242888]  kasan_check_range+0x3c7/0x3f0 [ 2030.242908]  ? ksmbd_alloc_user+0x278/0x680 [ 2030.242925]  __asan_memcpy+0x29/0x70 [ 2030.242942]  ksmbd_alloc_user+0x278/0x680 [ 2030.242960]  ksmbd_login_user+0xc3/0x120 [ 2030.242978]  ntlm_authenticate+0x5e6/0x1b00 [ 2030.243017]  ? __pfx_ntlm_authenticate+0x10/0x10 [ 2030.243035]  ? ksmbd_session_lookup+0x188/0x1d0 [ 2030.243054]  ? __pfx_ksmbd_session_lookup+0x10/0x10 [ 2030.243090]  ? __sanitizer_cov_trace_switch+0x7b/0x140 [ 2030.243108]  smb2_sess_setup+0x1e4a/0x27b0 [ 2030.243126]  ? copy_from_kernel_nofault+0x199/0x300 [ 2030.243156]  ? __pfx_smb2_sess_setup+0x10/0x10 [ 2030.243173]  ? get_smb2_cmd_val+0xe3/0x1c0 [ 2030.243208]  handle_ksmbd_work+0x954/0x1280 [ 2030.243230]  ? __pfx_handle_ksmbd_work+0x10/0x10 [ 2030.243249]  ? process_scheduled_works+0xa07/0x1490 [ 2030.243270]  ? process_scheduled_works+0xa07/0x1490 [ 2030.243291]  process_scheduled_works+0xa70/0x1490 [ 2030.243320]  ? __pfx_process_scheduled_works+0x10/0x10 [ 2030.243340]  ? do_raw_spin_lock+0x130/0x300 [ 2030.243358]  ? lock_is_held_type+0x7b/0x110 [ 2030.243388]  worker_thread+0x932/0xe20 [ 2030.243415]  kthread+0x38a/0x470 [ 2030.243431]  ? __pfx_worker_thread+0x10/0x10 [ 2030.243451]  ? __pfx_kthread+0x10/0x10 [ 2030.243467]  ret_from_fork+0x484/0x910 [ 2030.243485]  ? __pfx_ret_from_fork+0x10/0x10 [ 2030.243501]  ? __switch_to+0xc77/0x12c0 [ 2030.243523]  ? __pfx_kthread+0x10/0x10 [ 2030.243540]  ret_from_fork_asm+0x1a/0x30 [ 2030.243564]  </TASK> [ 2030.243570] [ 2030.290164] Allocated by task 19279: [ 2030.290911]  kasan_save_track+0x3e/0x80 [ 2030.292179]  __kasan_kmalloc+0x72/0x90 [ 2030.293217]  __kvmalloc_node_noprof+0x3ff/0x6b0 [ 2030.294467]  handle_generic_event+0x59b/0x750 [ 2030.295345]  genl_family_rcv_msg_doit+0x238/0x340 [ 2030.296553]  genl_rcv_msg+0x606/0x7b0 [ 2030.297129]  netlink_rcv_skb+0x22b/0x4a0 [ 2030.298500]  genl_rcv+0x2d/0x40 [ 2030.299273]  netlink_unicast+0x7ba/0x930 [ 2030.300019]  netlink_sendmsg+0x8c3/0xb00 [ 2030.301073]  __sock_sendmsg+0xec/0x140 [ 2030.301579]  __sys_sendto+0x357/0x470 [ 2030.302255]  __x64_sys_sendto+0xe3/0x100 [ 2030.303425]  do_syscall_64+0x135/0x460 [ 2030.304763]  entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 2030.305594] [ 2030.305819] The buggy address belongs to the object at ffff888121bb6640 [ 2030.305819]  which belongs to the cache kmalloc-192 of size 192 [ 2030.309595] The buggy address  ---truncated---

CVE-2026-90179:

        In the Linux kernel, the following vulnerability has been resolved:  apparmor: fix deadlock in complain-mode change_hat  The use of change_hat when in complain mode can cause a deadlock when the hat doesn't exist and a new learning profile is created for the missing profile. This is because change_hat() has taken the lock to search the hat list and creating the new learning profile needs to take the lock to add it to the list.  From the bug report:  Originally found in 7.0.0 in LTS ubuntu 26.04 with pam_apparmor + su in complain mode set to change hats.  Then verified in newest available vanilla kernel I've compiled to see if still present:  7.2-rc7 vanilla -> affected  checked also some other kernels: 6.18.44 vanilla -> affected 6.12.95 with debian patches -> unaffected  On systems without bug (for example 6.12.95 debian) it just prints:  aa_change_hat rc=0  On systems with bug, the executable always hangs, prints nothing and becomes unkillable.  (And once stuck this way, it will cause any further hat changes to also cause the changing process to get stuck)  Then in syslog you can find hint about cause:  kernel: INFO: task hat:3409 blocked for more than 483 seconds. kernel:       Not tainted 7.2.0-rc7 #1 kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kernel: task:hat             state:D stack:0     pid:3409  tgid:3409  ppid:2605   task_flags:0x400000 flags:0x00080800 kernel: Call Trace: kernel:  <TASK> kernel:  __schedule+0x48f/0xfe0 kernel:  schedule+0x27/0xa0 kernel:  schedule_preempt_disabled+0x15/0x30 kernel:  __mutex_lock.constprop.0+0x569/0xa10 kernel:  aa_new_learning_profile+0x15f/0x210 kernel:  build_change_hat+0x19f/0x3b0 kernel:  change_hat.isra.0+0x5dd/0xd60 kernel:  aa_change_hat+0x2f3/0x710 kernel:  aa_setprocattr_changehat+0x121/0x1f0 kernel:  do_setattr+0x28c/0x340 kernel:  apparmor_setselfattr+0x20/0x50 kernel:  security_setselfattr+0xf6/0x110 kernel:  __x64_sys_lsm_set_self_attr+0x53/0x90 kernel:  do_syscall_64+0xdd/0x5e0 kernel:  ? __mod_memcg_lruvec_state+0xfd/0x260 kernel:  ? lruvec_stat_mod_folio+0x8d/0xd0 kernel:  ? __folio_mod_stat+0x2d/0x90 kernel:  ? map_anon_folio_pte_nopf+0xd1/0x1f0 kernel:  ? do_anonymous_page+0x184/0xa10 kernel:  ? __handle_mm_fault+0x805/0x870 kernel:  ? count_memcg_events+0xef/0x230 kernel:  ? handle_mm_fault+0x1f0/0x2f0 kernel:  ? do_user_addr_fault+0x2bb/0x7b0 kernel:  ? do_syscall_64+0x94/0x5e0 kernel:  ? exc_page_fault+0x75/0x160 kernel:  entry_SYSCALL_64_after_hwframe+0x76/0x7e kernel: RIP: 0033:0x7f815e134c8d kernel: RSP: 002b:00007fff6df94ea8 EFLAGS: 00000246 ORIG_RAX: 00000000000001cc kernel: RAX: ffffffffffffffda RBX: 0000556d8c81d040 RCX: 00007f815e134c8d kernel: RDX: 0000000000000046 RSI: 0000556d8c81d040 RDI: 0000000000000064 kernel: RBP: 00007fff6df94ef0 R08: 00007f815e212ac8 R09: 000000000000000c kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 0000556d8c81d010 kernel: R13: 0000000000000026 R14: 0000000000000046 R15: 0000000000000064 kernel:  </TASK> kernel: INFO: task hat:3409 is blocked on a mutex likely owned by task hat:3409.  To fix the issue, lift the locking out of the core of aa_new_learning_profile(), introduce a wrapper function that takes the lock where needed, and have build_change_hat() call the core function that no longer takes the lock.  In addition fix 4 other issues introduced by commit 32e92764d6f8d ("apparmor: grab ns lock and refresh when looking up changehat child profiles") - aa_get_profile_rcu() was replaced-by: aa_get_profile without the   accompanying rcu_dereference_protected() - an extra aa_get_label(label) was introduced at the start of   change_hat() without an accompanying aa_put_label() causing a   reference count leak. - a reference count leak was introduced in the label_is_stale(label)   case, where the newest profile would be leaked instead of the   label passed to the function. - a potential UAF when the lookup walks up the tree with new_ns != ns   the new label refere ---truncated---

CVE-2026-90182:

        In the Linux kernel, the following vulnerability has been resolved:  blk-iocost: clear delay state when freeing policy data  iocg_kick_delay() turns sufficiently large debt into an explicit block-cgroup delay with blkcg_set_delay(), setting blkg->use_delay to -1 and incrementing blkcg->congestion_count.  Clearing it again depends on iocg_kick_delay() running from the period timer, the waitq timer or the issue path.  ioc_pd_free() removes the iocg from active_iocgs and cancels its waitq timer, and no further bios can arrive, so once it has run nothing is left which can reduce the debt and clear the delay.  The blkcg stays marked congested for the rest of its life.  blk_cgroup_congested() then returns true for every task in that cgroup and its descendants: page_cache_sync_ra() cuts readahead to a single page, page_cache_async_ra() skips it altogether, and __folio_throttle_swaprate() takes swap_avail_lock and schedules a throttle on anonymous folio allocation.  Clear it explicitly, after the list removal and the synchronous hrtimer_cancel() so that neither timer processing nor an I/O path can re-arm it.  The free callback can also see policy data which was never attached to a blkg, hence the pd->blkg check.

CVE-2026-90183:

        In the Linux kernel, the following vulnerability has been resolved:  blk-iolatency: clear delay state when freeing policy data  io.latency can throttle a group which has no latency target of its own. When a sibling misses its target, check_scale_change() scales down its peers, and a peer that reaches queue depth one gets blkcg_use_delay() called on it on every further scale-down, even with min_lat_nsec == 0.  iolatency_pd_offline() resets the target through iolatency_set_min_lat_nsec(), which clears the delay only on a nonzero to zero transition, so it never clears such a peer.  Freeing the policy data then leaves blkg->use_delay set and blkcg->congestion_count elevated with nothing left that can drop it.  blk_cgroup_congested() then returns true for every task in that cgroup and its descendants for as long as the cgroup lives: page_cache_sync_ra() cuts readahead to a single page, page_cache_async_ra() skips it altogether, and __folio_throttle_swaprate() takes swap_avail_lock and schedules a throttle on anonymous folio allocation.  Clear the delay in iolatency_pd_free().  By then bio-held blkg references have drained, or the queue is frozen for policy deactivation, so check_scale_change() cannot re-arm it.  The free callback can also see policy data which was never attached to a blkg, hence the pd->blkg check.

CVE-2026-90187:

        In the Linux kernel, the following vulnerability has been resolved:  null_blk: free zones array on device power-off  null_init_zoned_dev() allocates dev->zones when a zoned device is powered on, but null_del_dev() never frees it on power-off; dev->zones is only freed later in null_free_dev(), when the configfs directory is removed. If the device is powered off and then on again, null_init_zoned_dev() allocates a new array and overwrites the dev->zones pointer, leaking the previous allocation each power cycle.  Free dev->zones in null_del_dev() via null_free_zoned_dev() to solve it. And calling null_free_zoned_dev() in null_free_dev() is no longer necessary because every caller already invokes null_del_dev() first: via nullb_group_drop_item() before nullb_device_release(), in the null_add_dev() error path of null_create_dev(), and in null_destroy_dev(). Remove the redundant call.  And take &lock around zone_cond_store() in the two store wrappers to serialize dev->zones check-and-deref against its alloc/free, which already run under &lock. The reason there was no problem before is that only nullb_device_release() or null_exit() frees the dev->zones, which guarantees that subsequent users won't access the configfs interface.

CVE-2026-90199:

        In the Linux kernel, the following vulnerability has been resolved:  fs/ntfs3: reject out-of-range evcn in mi_enum_attr()  In mi_enum_attr(), the start/end VCN validation for non-resident attributes is:  	if (svcn > evcn + 1) goto out;  When evcn is U64_MAX the "evcn + 1" expression wraps to 0 and any svcn passes the check. For evcn values close to U64_MAX (but not equal to it) the right-hand side is still a meaningless near-wrap upper bound, so a malformed on-disk attribute with svcn == 0 and evcn near U64_MAX can pass mi_enum_attr() unrejected.  VCN (virtual cluster number) is a cluster index, so any valid evcn is bounded by the volume's total cluster count, which ntfs3 holds in sbi->used.bitmap.nbits (set up in ntfs_init_from_boot() before any caller of mi_enum_attr() runs). Reject evcn values that fall outside this range.  However, an empty non-resident attribute (no allocated clusters) is legitimately encoded with svcn == 0 and evcn == -1 (U64_MAX), e.g. via attr->nres.evcn = cpu_to_le64((u64)vcn - 1) with vcn == 0. That sentinel must keep passing, so exclude evcn == U64_MAX from the range check. The existing "svcn > evcn + 1" test still tolerates the sentinel ("0 > 0" is false) and continues to require svcn == 0 for it, while the range check rejects every other out-of-range evcn and thereby also defuses the "evcn + 1" wraparound.  svcn does not need its own bound: once evcn < nbits, "svcn > evcn + 1" implies svcn <= nbits.  [almaz.alexandrovich@paragon-software.com: fixed evcn check]

CVE-2026-90200:

        In the Linux kernel, the following vulnerability has been resolved:  fs/ntfs3: fix integer overflow in MFT cluster validation  In ntfs_init_from_boot(), the boot sector's MFT cluster numbers are validated against the volume size with:  	if (mlcn  * sct_per_clst >= sectors || 	    mlcn2 * sct_per_clst >= sectors) 		goto out;  mlcn and mlcn2 are u64 fields read directly from the boot sector. sct_per_clst is bounded above by 4096 (true_sectors_per_clst() plus the is_power_of_2() check below it), but the multiplication is done in u64 and wraps when mlcn (or mlcn2) is large enough -- e.g. mlcn near 2^62 with sct_per_clst == 4 wraps to 0, which compares below any non-zero 'sectors', so the check is bypassed and the malformed record is accepted.  The accepted mlcn is then used unchanged in  	sbi->mft.lbo = mlcn << cluster_bits;  In practice the resulting reads fail at the block layer (sb_bread() returns NULL via grow_buffers()'s check_mul_overflow() guard), so today this manifests as mount failing in odd places rather than as something more dangerous, but the validation step is still wrong and there is no reason for callers to rely on the block layer to catch a value that should never have been accepted in the first place.  Use check_mul_overflow() to compute the two sector positions and fail the mount if either multiplication wraps; this preserves the existing semantics (mlcn * sct_per_clst >= sectors) instead of switching to division (mlcn >= sectors / sct_per_clst), which would tighten the check at edge cases where 'sectors' is not a multiple of sct_per_clst.  The check_*_overflow() style is the one ntfs3 already uses for similar on-disk arithmetic in fs/ntfs3/run.c.

CVE-2026-90204:

        In the Linux kernel, the following vulnerability has been resolved:  ocfs2: validate DIO orphan slot during inode read  [BUG] A corrupted append-DIO dinode (high byte at offset 0xa1 corrupted from 0 to 1) can carry an i_dio_orphaned_slot outside the mounted filesystem slot range and trigger a use-after-free error:  BUG: KASAN: slab-use-after-free in ocfs2_get_system_file_inode+0x780/0x820 fs/ocfs2/sysfile.c:102 Read of size 8 at addr ffff88800b767c00 by task kworker/u8:3/85 Call Trace:  ...  ocfs2_get_system_file_inode+0x780/0x820 fs/ocfs2/sysfile.c:102  ocfs2_wipe_inode+0x292/0xf70 fs/ocfs2/inode.c:840  ocfs2_delete_inode fs/ocfs2/inode.c:1155 [inline]  ocfs2_evict_inode+0x6c9/0x1170 fs/ocfs2/inode.c:1295  evict+0x38e/0x8f0 fs/inode.c:810  iput_final fs/inode.c:1914 [inline]  iput fs/inode.c:1966 [inline]  iput+0x55b/0x8b0 fs/inode.c:1926  ocfs2_recover_orphans+0x610/0xe40 fs/ocfs2/journal.c:2374  ocfs2_complete_recovery+0x5af/0xd00 fs/ocfs2/journal.c:1373  ...  [CAUSE] ocfs2_del_inode_from_orphan() uses i_dio_orphaned_slot to index the slot-local system inode cache. The dinode validator does not check this active slot, so an out-of-range value produces an invalid cache entry pointer that is dereferenced as an inode pointer.  [FIX] Reject an active i_dio_orphaned_slot outside the slot range during dinode validation, before DIO orphan recovery can consume it.

CVE-2026-90205:

        In the Linux kernel, the following vulnerability has been resolved:  ocfs2: validate orphan slot during inode read  Patch series "ocfs2: validate active orphan slots during inode read".  OCFS2 trusts active ordinary and append-DIO orphan slots read from dinodes. A corrupted slot can therefore index osb_orphan_wipes or the slot-local system-inode cache outside their allocations before the corruption is reported.  Patch 1 validates the ordinary orphan slot used by inode wipe processing. Patch 2 validates the append-DIO orphan slot used by DIO completion and orphan recovery.  Both checks reject corrupt metadata at the existing inode validation boundary.   This patch (of 2):  [BUG] A corrupted dinode with OCFS2_ORPHANED_FL can carry an i_orphaned_slot outside the mounted filesystem slot range. ocfs2_wipe_inode() uses it to index osb_orphan_wipes before looking up the orphan directory, causing an out-of-bounds memory access.  BUG: KASAN: slab-use-after-free in ocfs2_get_system_file_inode+0x780/0x820 fs/ocfs2/sysfile.c:102 Read of size 8 at addr ffff88800b767c00 by task kworker/u8:3/85 Call Trace:  ...  ocfs2_get_system_file_inode+0x780/0x820 fs/ocfs2/sysfile.c:102  ocfs2_wipe_inode+0x292/0xf70 fs/ocfs2/inode.c:840  ocfs2_delete_inode fs/ocfs2/inode.c:1155 [inline]  ocfs2_evict_inode+0x6c9/0x1170 fs/ocfs2/inode.c:1295  evict+0x38e/0x8f0 fs/inode.c:810  iput_final fs/inode.c:1914 [inline]  iput fs/inode.c:1966 [inline]  iput+0x55b/0x8b0 fs/inode.c:1926  ocfs2_recover_orphans+0x610/0xe40 fs/ocfs2/journal.c:2374  ocfs2_complete_recovery+0x5af/0xd00 fs/ocfs2/journal.c:1373  ...  [CAUSE] ocfs2_validate_inode_block() validates i_suballoc_slot but leaves the active ordinary orphan slot unchecked. Downstream consumers assume that the value is smaller than osb->max_slots.  [FIX] Reject an active i_orphaned_slot outside the slot range during dinode validation, before the inode reaches orphan wipe processing.

CVE-2026-90206:

        In the Linux kernel, the following vulnerability has been resolved:  nvmet: fix max_qid race between configfs and controller allocation  The function nvmet_subsys_attr_qid_max_store() can race against nvmet_alloc_ctrl() when a subsystem's max_qid limit is modified.  Suppose max_qid is currently 64. If nvmet_alloc_ctrl() executes: ctrl->sqs = kzalloc_objs(struct nvmet_sq *, subsys->max_qid + 1); and at this exact point, a userspace process changes max_qid to 128, nvmet_subsys_attr_qid_max_store() will set the new max_qid value. It attempts to delete active controllers to force a reconnect, but the new controller won't be deleted because it hasn't been added to the subsys->ctrls list yet.  nvmet_alloc_ctrl() then proceeds and adds the new controller to the subsys->ctrls list. Later, when nvmet_install_queue() is called, it will see max_qid set to 128, but the memory allocated for sqs is only sized for 64 entries. This results in a KASAN out-of-bounds warning and potential memory corruptions.  Fix this by protecting the queue allocations and list insertion in nvmet_alloc_ctrl() with down_read(&nvmet_config_sem). Because nvmet_subsys_attr_qid_max_store() acquires down_write(&nvmet_config_sem) to modify the attribute, this safely prevents the configfs writer from modifying max_qid during controller creation.  Copy the max_qid from the subsystem to the controller's structure during the allocation; ctrl->max_qid never changes as long as the controller remains in LIVE state, so this will prevent similar race conditions.

CVE-2026-90208:

        In the Linux kernel, the following vulnerability has been resolved:  clocksource/drivers/samsung_pwm: Switch to raw_spinlock_t type  Samsung PWM timer might be used as a clock source on some legacy systems. When PREEMPT_RT is enabled on ARM, regular spinlock is converted to a sleeping lock (mutex-based), which must not be used in atomic context such as hard interrupt handlers. Switch the samsung_pwm_lock to the raw_spinlock, which remains a true non-sleeping spinlock even under PREEMPT_RT.

CVE-2026-90213:

        In the Linux kernel, the following vulnerability has been resolved:  firewire: core: fix memory leak in error path of build_tree()  In the error path of build_tree(), node instances can remain in the local linked list when the function returns.  Whenever an invalid value is detected in the self ID sequence, each allocated node instance is either an entry in the linked list or an entry in the ports array of its parent node. Therefore, the allocate node instances can be safely released by traversing the linked list from its head.  Release the remaining node instances with for_each_fw_node() before returning to the caller.

CVE-2026-90227:

        In the Linux kernel, the following vulnerability has been resolved:  nvme/ioctl: check SUBMIT_IO with nvme_cmd_allowed()  Unlike IO_CMD / IO64_CMD, NVME_IOCTL_SUBMIT_IO never calls nvme_cmd_allowed(). Unprivileged callers can thus issue I/O on a partition device or write through a read-only file descriptor.  Pass flags and open_for_write through and reject disallowed commands with -EACCES.

CVE-2026-90229:

        In the Linux kernel, the following vulnerability has been resolved:  nvme-apple: Destroy the admin queue on removal  The admin queue is allocated with blk_mq_alloc_queue() but never destroyed. nvme_free_ctrl() only drops the last reference and blk_mq_exit_queue() and blk_sync_queue() never run: the hctx is never moved to q->unused_hctx_list and the timeout timer and work stay armed on a queue that is about to be freed which will eventually oops inside blk_mq_timeout_work().  This can only be triggered when the controller fails to come up and is then immediately torn down again which is why no one ever ran into this before.  Let's just copy what the pcie driver does: unquiesce and destroy the admin queue before nvme_uninit_ctrl().  With this the following WARN followed by a panic no longer happens:    WARNING: block/blk-mq.c:4390 at blk_mq_release+0x194/0x238, CPU#4: kworker/u34:4/119   CPU: 4 UID: 0 PID: 119 Comm: kworker/u34:4 Not tainted 7.2.0-rc1-dirty #248 PREEMPT   Hardware name: Apple Mac mini (M1, 2020) (DT)   Workqueue: nvme-wq apple_nvme_remove_dead_ctrl_work   pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)   pc : blk_mq_release+0x194/0x238   lr : blk_mq_release+0x58/0x238   sp : ffffc000833a3b50   x29: ffffc000833a3b50 x28: ffff80001d0450f8 x27: ffff800020c95200   x26: 0000000000000088 x25: 0000000000000000 x24: ffff800020f36805   x23: 0000000000000000 x22: ffffc00081a86878 x21: ffff800020be9c60   x20: 0000000000000000 x19: ffff800022501698 x18: 000000000000000a   x17: 7365757165722066 x16: 666f7265776f7020 x15: 0000000000000000   x14: 0000000000000028 x13: 0000000000004def x12: 0000000000000003   x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc000805b4fc8   x8 : ffffc00081915820 x7 : ffffc00081c4f3c8 x6 : 0000000000000001   x5 : 0000000000000004 x4 : ffff800022498d80 x3 : ffffc000833a3b14   x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff800022501698   Call trace:    blk_mq_release+0x194/0x238 (P)    blk_put_queue+0x8c/0xf0    nvme_free_ctrl+0x4c/0x260    device_release+0x44/0x128    kobject_put+0xa0/0x120    put_device+0x1c/0x40    nvme_uninit_ctrl+0x48/0x60    apple_nvme_remove+0x54/0xb0    platform_remove+0x28/0x40    device_remove+0x54/0x98    device_release_driver_internal+    device_release_driver+0x20/0x38    apple_nvme_remove_dead_ctrl_wor    process_one_work+0x1f4/0x770    worker_thread+0x1b8/0x360    kthread+0x140/0x160    ret_from_fork+0x10/0x20   irq event stamp: 448   hardirqs last  enabled at (447):in_unlock_irqrestore+0x74/0x80   hardirqs last disabled at (448): [<ffffc000811cf5c0>] el1_brk64+0x20/0x60   softirqs last  enabled at (0): [ess+0xb28/0x2698   softirqs last disabled at (0): [<0000000000000000>] 0x0   ---[ end trace 0000000000000000   Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000   Mem abort info:     ESR = 0x0000000096000005     EC = 0x25: DABT (current EL),     SET = 0, FnV = 0     EA = 0, S1PTW = 0     FSC = 0x05: level 1 translation fault   Data abort info:     ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000     CM = 0, WnR = 0, TnD = 0, TagA     GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0   [0000000000000000] user address   Internal error: Oops: 0000000096000005 [#1]  SMP   CPU: 7 UID: 0 PID: 54 Comm: kwor          7.2.0-rc1-dirty #248PREEMPT   Tainted: [W]=WARN   Hardware name: Apple Mac mini (M1, 2020) (DT)   Workqueue: kblockd blk_mq_timeou   pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)   pc : percpu_ref_tryget_many.cons   lr : percpu_ref_tryget_many.constprop.0+0xc0/0x168   sp : ffffc000829cbce0   x29: ffffc000829cbce0 x28: ffff800020be9f48 x27: ffff800013e503c0   x26: 0000000000000108 x25: 000009c05   x23: 0000000000000000 x22: ffffc000819f5000 x21: ffff800020be9f48   x20: ffff8001deda4808 x19: ffff8000a   x17: 00000000580e1fac x16: ffffc00082bbbb7c x15: 0000000000000000   x14: 0000000000000028 x13: 000000001   x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc000829cbc20   x8 :  ---truncated---

CVE-2026-90230:

        In the Linux kernel, the following vulnerability has been resolved:  nvmet: fix heap out-of-bounds read in nvmet_auth_negotiate()  nvmet_execute_auth_send() allocates the DH-HMAC-CHAP message buffer with the host-supplied transfer length (tl) and hands it to nvmet_auth_negotiate() without passing tl along. nvmet_auth_negotiate() then reads the negotiate header and, for each of the halen hash identifiers and dhlen DH group identifiers, indexes into the fixed idlist[60] array (hashes at idlist[0..halen), groups at idlist[30..]).  Neither the transfer length nor halen/dhlen is validated. A malicious or non-conformant host can report a tl smaller than the negotiate structure, or a halen/dhlen larger than the array (both are u8, up to 255), making the loops read past the end of the allocated buffer (heap out-of-bounds read). The sibling nvmet_auth_reply() already validates tl against the structure size; the negotiate path did not.  Pass tl into nvmet_auth_negotiate(), reject a tl that does not cover the negotiate data plus one full protocol descriptor, and reject halen/dhlen larger than NVME_AUTH_DHCHAP_MAX_DH_IDS.

CVE-2026-90232:

        In the Linux kernel, the following vulnerability has been resolved:  amt: Don't support cross-netns setup.  When a lower device is unregistered, amt_device_event() tries to unregister its upper AMT device, but it has two problems.    1. amt_lookup_upper_dev() looks up an upper device in the       lower device's netns only    2. amt_device_event() unregisters a single upper device only  If AMT device is created on a lower device in another netns, removing the lower device triggers the splat below and gets stuck until all upper devices are removed. [0]  The cross-netns setup seems unintentional considering 1. and the following points:    * amt_link_setup() sets dev->netns_immutable to true   * skb_scrub_packet() is not called in the fast path   * iproute2 binary fails to find cross-netns lower device via     link-netns:       # ip -n ns1 link add amt0 link-netns ns2 type amt dev veth1       Cannot find device "veth1"  Instead of supporting it properly and preparing for per-netns netdev unreg, let's forbid cross-netns setup.  Note that the problem 2. needs a separate fix.  [0]: WARNING: net/core/dev.c:12518 at unregister_netdevice_many_notify+0x1cce/0x2250, CPU#48: ip/2031 Modules linked in: CPU: 48 UID: 0 PID: 2031 Comm: ip Not tainted 7.2.0-rc5+ #27 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:unregister_netdevice_many_notify (net/core/dev.c:12518) Code: 89 ef e8 d5 52 ae fe e9 d0 f4 ff ff 48 8d 3d f9 3b 9c 02 48 c7 c6 c0 0b 63 84 ba ab 1f 00 00 67 48 0f b9 3a e9 65 ff ff ff 90 <0f> 0b 90 eb 81 48 8d 3d f6 3b 9c 02 48 c7 c6 c0 0b 63 84 ba e2 1f RSP: 0018:ffffc90004abf160 EFLAGS: 00010212 RAX: ffff888104d38260 RBX: ffff88800b0911b8 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffff85b9f880 RBP: ffffc90004abf2d0 R08: ffffffff85b9f887 R09: 1ffffffff0b73f10 R10: dffffc0000000000 R11: fffffbfff0b73f11 R12: ffff88800b091d08 R13: ffff88800b091178 R14: dffffc0000000000 R15: ffff88800b091000 FS:  00007f555b86c600(0000) GS:ffff8881942a0000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000562107d489c0 CR3: 0000000109a40002 CR4: 0000000000372ef0 Call Trace:  <TASK>  rtnl_dellink (net/core/rtnetlink.c:3632 net/core/rtnetlink.c:3674)  rtnetlink_rcv_msg (net/core/rtnetlink.c:7112)  netlink_rcv_skb (net/netlink/af_netlink.c:2556)  netlink_unicast (net/netlink/af_netlink.c:1319)  netlink_sendmsg (net/netlink/af_netlink.c:1900)  ____sys_sendmsg (net/socket.c:775)  __sys_sendmsg (net/socket.c:2738)  do_syscall_64 (arch/x86/entry/syscall_64.c:63)  entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) ... unregister_netdevice: waiting for veth0 to become free. Usage count = 7 ref_tracker: netdev@ffff88800d7496d8 has 3/3 users at      __netdev_adjacent_dev_insert (./include/linux/netdevice.h:4525 ./include/linux/netdevice.h:4554 net/core/dev.c:8791)      __netdev_upper_dev_link (net/core/dev.c:8879 net/core/dev.c:8963)      netdev_upper_dev_link (net/core/dev.c:9009)      amt_newlink (drivers/net/amt.c:3321)

CVE-2026-90234:

        In the Linux kernel, the following vulnerability has been resolved:  NFS: Return a delegation the client fails to record  When an NFS server grants a delegation in an OPEN reply, nfs_inode_set_delegation() records it on the client. However, three of its error flows return without sending DELEGRETURN.  A delegation can be relinquished only by DELEGRETURN (RFC 8881 Section 20.2.4), so dropping one silently leaves the server believing the client still holds it. If the server happens to recall that delegation, the client answers CB_RECALL with NFS4ERR_BADHANDLE because it has no record of the stateid. The server revokes the delegation and moves it onto its cl_revoked list, because the client never sends the FREE_STATEID that would drain it. Every subsequent SEQUENCE reply then carries SEQ4_STATUS_RECALLABLE_STATE_REVOKED, and the client's state manager loops issuing TEST_STATEID across its delegations without ever clearing the condition.  The window is easy to reach now that a server offers a write delegation on any write OPEN: a delegation recalled for one opener races a re-open that the server answers with a fresh write delegation.  Instead of dropping it, hand the delegation back during these error flows.

CVE-2026-90235:

        In the Linux kernel, the following vulnerability has been resolved:  sunrpc: xprtsock: annotate shared socket callbacks with READ_ONCE/WRITE_ONCE  xprtsock replaces and restores sk->sk_data_ready and sk->sk_write_space on live sockets with plain stores, and xs_udp_do_set_buffer_size() invokes sk->sk_write_space via a plain load. These callback pointers are shared with generic socket and protocol paths that may read or invoke them concurrently, so xprtsock needs the same READ_ONCE()/WRITE_ONCE() callback visibility contract that the validated 4022 family applied elsewhere.  When SUNRPC takes over an AF_LOCAL, UDP, or TCP socket and later restores the lower-socket callbacks during teardown, another CPU may still hold an earlier callback snapshot. The plain replace/restore pattern leaves the same visibility hole as the validated 4022 family, so a stale snapshot can still invoke xs_data_ready() or xs_udp_write_space() after the live callback fields have already been restored to the lower-socket handlers.  Use WRITE_ONCE() for the shared sk_data_ready and sk_write_space stores in xs_local_finish_connecting(), xs_udp_finish_connecting(), xs_tcp_finish_connecting(), and xs_restore_old_callbacks(). Use READ_ONCE() for the direct sk_write_space invocation in xs_udp_do_set_buffer_size(). This matches the required callback visibility contract while leaving adjacent sk_state_change and sk_error_report handling unchanged.

CVE-2026-90237:

        In the Linux kernel, the following vulnerability has been resolved:  netfilter: nft_ct: move custom expectation support to helper  Originally, the ct expectation support called nf_ct_helper_ext_add() for confirmed conntracks, which is invalid, triggering a splat. This was fixed by commit 1710eb913bdc ("netfilter: nft_ct: skip expectations for confirmed conntrack") which restricted it to unconfirmed conntracks.  However, early insertion of expectations into the expectations list when the conntrack is unconfirmed leads to stale entries pointing to the wrong hlist_head through .pprev due to ct extension reallocation.  Commit 7c9664351980 ("netfilter: move nat hlist_head to nf_conn") moved the nat hlist_head to nf_conn for this reason:       1. ...      2. When reallocation of extension area occurs we need to fixup the         bysource hash head via hlist_replace_rcu.  I'd rather not increase the size of the struct nf_conn for this feature has very limited scope: only one expectation can be created at a time given expect_clash() will make nf_ct_expect_related() reports EBUSY. For this reason, relax nf_ct_expect_related() not to drop packets in case expectation creation fails, therefore, expectation creation becomes best effort.  To address this issue, add an internal ct helper and attach it to the conntrack entry to streamline the custom ct expectation support with existing ct helpers.  Expose a new nf_conntrack_helper_release() function to release the internal helper that is allocated and attached to the conntrack entry to create the custom expectations. The nft_ct module removal always waits for rcu grace period, then the NULL helper callback is observed after this.  This patch also restricts the creation of expectations to different helpers other than this custom helper that is created for this type of expectations.

CVE-2026-90247:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: Fix mmap_lock leak in irq_work path  stack_map_get_build_id_offset() introduced a per-CPU irq_work to defer mmap_read_unlock() from NMI context, and bpf_find_vma() later reused the same mmap_unlock_work. Both callers only check whether the work is busy before taking mmap_lock, so a nested caller can reuse the slot before the first caller queues it. Two read locks may then be acquired while only one deferred unlock runs, leaking a read lock and blocking exit_mmap().  Reserve the per-CPU slot before mmap_read_trylock(). Use the same wrapper in stackmap and bpf_find_vma() so both callers release the reservation on trylock failure. Keep rejecting the slot while the irq_work remains busy. Release it after the irq_work callback unlocks the mm.

CVE-2026-90250:

        In the Linux kernel, the following vulnerability has been resolved:  bpf, cgroup: Fix storage null-ptr-deref after replacing prog  Syzkaller reported a storage null-ptr-deref issue after replacing prog. This occurs in the following scenario: 1. prog A, an empty prog, is attached to a cgrp. 2. prog B uses BPF_MAP_TYPE_PERCPU_CGROUP_STORAGE and calls the    bpf_get_local_storage helper. 3. link_update is called to replace prog A with prog B.  The reason is that __cgroup_bpf_replace fails to alloc and assign the required cgrp storage for the incoming replacement prog. Consequently, the new prog inherits an uninit storage, leading to null-ptr-deref panic when kick the new prog.  Fix this by rejecting a link update if new_prog's cgroup storage is incompatible with link->prog.

CVE-2026-90259:

        In the Linux kernel, the following vulnerability has been resolved:  btrfs: qgroup: fix a wrong length calculation in qgroup_free_reserved_data()  In that function, we round down the start position and round up the ending position.  But during the calculation of @len, we use "round_up(start + len, sectorsize)", which is the rounded up end position, not the rounded up length.  Which results a much larger length, and later we are still using "start + len", which is completely incorrect.  Fix it by declaring a local @aligned_start and @aligned_len and use them instead.

CVE-2026-90263:

        In the Linux kernel, the following vulnerability has been resolved:  btrfs: check if root is readonly when setting posix acl  For a filesystem which has btrfs read-only property set to true, all write operations including acl and xattr should be denied. However, acl can still be set even if btrfs ro property is true.  This happens because no function on the set_acl code path checks the root is readonly or not. It was checked in btrfs_setxattr_trans() but got removed in commit 353c2ea735e4 ("btrfs: remove redundant readonly root check in btrfs_setxattr_trans")  That commit didn't check if all the callers properly check the root's read-only flag. A previous fix is commit b51111271b03 ("btrfs: check if root is readonly while setting security xattr").  Always check if the root is read-only before performing the set acl operation.

CVE-2026-90264:

        In the Linux kernel, the following vulnerability has been resolved:  btrfs: always wait for ordered extents to avoid OE races  [BUG] Syzbot reported a bug that there can be conflicting OEs for the same range:    BTRFS critical (device loop4): panic in insert_ordered_extent:264: overlapping ordered extents, existing oe file_offset 16384 num_bytes 430080 flags 0x1089, new oe file_offset 16384 num_bytes 430080 flags 0x80 (errno=-17 Object alrea[  179.162726][ T6897] BTRFS critical (device loop4): panic in insert_ordered_extent:264: overlapping ordered extents, existing oe file_offset 16384 num_bytes 430080 flags 0x1089, new oe file_offset 16384 num_bytes 430080 flags 0x80 (errno=-17 Object already exists)   ------------[ cut here ]------------   kernel BUG at fs/btrfs/ordered-data.c:264!   Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/09/2026   RIP: 0010:btrfs_alloc_ordered_extent+0x943/0xad0   Call Trace:    <TASK>    cow_file_range+0x744/0x12a0    fallback_to_cow+0x5ea/0xa00    run_delalloc_nocow+0x110c/0x17a0    btrfs_run_delalloc_range+0xbe4/0x1c20    writepage_delalloc+0x104d/0x1ba0    btrfs_writepages+0x1667/0x28b0    do_writepages+0x338/0x560    filemap_fdatawrite_range+0x1f2/0x300    btrfs_fdatawrite_range+0x54/0xf0    btrfs_direct_write+0x6a0/0xc30    btrfs_do_write_iter+0x329/0x790    do_iter_readv_writev+0x624/0x8d0    vfs_writev+0x34c/0x990    __se_sys_pwritev2+0x17a/0x2a0    do_syscall_64+0x174/0x580    entry_SYSCALL_64_after_hwframe+0x77/0x7f    </TASK>   ---[ end trace 0000000000000000 ]---  [CAUSE] Since commit ff66fe666233 ("btrfs: fix incorrect buffered IO fallback for append direct writes"), if the direct IO finished short, we will revert the isize back to the original one, so that append writes can be respected during the buffered fallback.  Normally we rely on lock_and_cleanup_extent_if_need() function during buffered writeback to wait for any existing ordered extents.  But that ordered extent waiting only happens if the start_pos is inside the isize. Since we have reverted the isize during failed direct IO, we will not wait for any ordered extents.  This means we can have a race where the direct IO OE is still in the tree, finished but not yet removed, then we're inserting the OE for the buffered write, causing the above crash.  [FIX] Make the OE wait to be unconditional, to handle the reverted isize situation.  And since lock_and_cleanup_extent_if_need() now either lock the extents or return -EAGAIN, also remove the branches that handles no-extent-locked cases, and rename it to remove the "_if_need" suffix.  The following micro benchmark shows the runtime difference for btrfs_buffered_write(), doing `xfs_io -f -c "pwrite 0 1m"` workload, all values are the average runtime in nano seconds.        function runtime              |   before    |     after  -----------------------------------+-------------+---------------  lock_and_cleanup_extent_if_need()  |     58.2    |    183.0  btrfs_buffered_write()             |   2115.6    |   2973.3  The overall runtime of btrfs_buffered_write() is still pretty tiny (still less than 3 micro seconds), I'd say the extra cost is still acceptable.  An alternative to fix this problem is to wait ordered extents during iomap_end() where the isize revert is done.  But that solution will break nowait requirement, as if a nowait direct IO finished short, we have to wait for the OEs unconditionally or the next append buffered IO can still hit the same problem.  So here we have to move the wait cost to buffered write, but at least the code is slightly more streamline.

CVE-2026-90265:

        In the Linux kernel, the following vulnerability has been resolved:  btrfs: defrag: fix deadlock between defrag and delalloc space reservation  While running fsstress with autodefrag and flushoncommit, hit a deadlock due to the fact that defrag reserves delalloc space while it's holding dirty and locked folios, besides the extent range lock. The stack traces are the following:     [958.624] task:kworker/u50:3   state:D stack:0     pid:20365 tgid:20365 ppid:2      task_flags:0x4208060 flags:0x00080000    [958.626] Workqueue: events_unbound btrfs_async_reclaim_metadata_space [btrfs]    [958.627] Call Trace:    [958.628]  <TASK>    [958.628]  __schedule+0x4be/0x10f0    [958.629]  ? preempt_count_add+0x69/0xa0    [958.630]  schedule+0x26/0xd0    [958.631]  wait_current_trans+0x102/0x160 [btrfs]    [958.632]  ? __pfx_autoremove_wake_function+0x10/0x10    [958.633]  start_transaction+0x374/0x900 [btrfs]    [958.634]  btrfs_commit_current_transaction+0x1d/0x70 [btrfs]    [958.635]  flush_space+0xca/0x5e0 [btrfs]    [958.636]  ? _raw_spin_unlock+0x15/0x30    [958.637]  ? btrfs_reduce_alloc_profile+0x8c/0x190 [btrfs]    [958.639]  ? _raw_spin_unlock+0x15/0x30    [958.640]  ? calc_available_free_space.isra.0+0x6f/0x110 [btrfs]    [958.641]  do_async_reclaim_metadata_space+0x84/0x190 [btrfs]    [958.642]  btrfs_async_reclaim_metadata_space+0x64/0x80 [btrfs]    [958.644]  process_one_work+0x19d/0x3a0    [958.644]  worker_thread+0x1c4/0x330    [958.645]  ? __pfx_worker_thread+0x10/0x10    [958.646]  kthread+0xfc/0x130    [958.647]  ? __pfx_kthread+0x10/0x10    [958.648]  ret_from_fork+0x1f7/0x2c0    [958.648]  ? __pfx_kthread+0x10/0x10    [958.649]  ret_from_fork_asm+0x1a/0x30    [958.650]  </TASK>    [958.651] task:kworker/u49:7   state:D stack:0     pid:52990 tgid:52990 ppid:2      task_flags:0x4208060 flags:0x00080000    [958.653] Workqueue: writeback wb_workfn (flush-btrfs-334)    [958.655] Call Trace:    [958.655]  <TASK>    [958.656]  __schedule+0x4be/0x10f0    [958.657]  ? __blk_flush_plug+0xe9/0x140    [958.658]  schedule+0x26/0xd0    [958.658]  io_schedule+0x42/0x70    [958.659]  folio_wait_bit_common+0x12b/0x330    [958.660]  ? folio_wait_bit_common+0x100/0x330    [958.662]  ? __pfx_wake_page_function+0x10/0x10    [958.663]  extent_write_cache_pages+0x599/0x830 [btrfs]    [958.664]  ? acpi_fwnode_get_reference_args+0x1fa/0x270    [958.665]  btrfs_writepages+0x77/0x130 [btrfs]    [958.666]  ? __pfx_end_bbio_data_write+0x10/0x10 [btrfs]    [958.667]  do_writepages+0xc6/0x160    [958.668]  __writeback_single_inode+0x42/0x310    [958.669]  writeback_sb_inodes+0x231/0x570    [958.670]  wb_writeback+0x8a/0x340    [958.671]  wb_workfn+0xbf/0x450    [958.672]  ? finish_task_switch.isra.0+0xc1/0x350    [958.673]  process_one_work+0x19d/0x3a0    [958.673]  worker_thread+0x1c4/0x330    [958.674]  ? __pfx_worker_thread+0x10/0x10    [958.675]  kthread+0xfc/0x130    [958.676]  ? __pfx_kthread+0x10/0x10    [958.676]  ret_from_fork+0x1f7/0x2c0    [958.677]  ? __pfx_kthread+0x10/0x10    [958.678]  ret_from_fork_asm+0x1a/0x30    [958.679]  </TASK>    [958.679] task:btrfs-cleaner   state:D stack:0     pid:296750 tgid:296750 ppid:2      task_flags:0x208040 flags:0x00080000    [958.681] Call Trace:    [958.682]  <TASK>    [958.682]  __schedule+0x4be/0x10f0    [958.683]  schedule+0x26/0xd0    [958.684]  handle_reserve_ticket+0x1b9/0x2c0 [btrfs]    [958.685]  ? __pfx_autoremove_wake_function+0x10/0x10    [958.686]  reserve_bytes+0x283/0x4c0 [btrfs]    [958.687]  btrfs_reserve_metadata_bytes+0x18/0xb0 [btrfs]    [958.688]  btrfs_delalloc_reserve_metadata+0x121/0x320 [btrfs]    [958.690]  btrfs_delalloc_reserve_space+0x46/0xb0 [btrfs]    [958.691]  btrfs_defrag_file+0x903/0x1110 [btrfs]    [958.692]  btrfs_run_defrag_inodes+0x334/0x430 [btrfs]    [958.694]  cleaner_kthread+0x97/0x1c0 [btrfs]    [958.694]  ? __pfx_cleaner_kthread+0x10/0x10 [btrfs]    [958.696]  kthread+0xfc/0x130    [958.696]  ? __pfx_kthread+0x10/0x10    [958.697]  ret_ ---truncated---

CVE-2026-90267:

        In the Linux kernel, the following vulnerability has been resolved:  scsi: sd: Fix special_vec mempool leak when scsi_alloc_sgtables() fails  sd_set_special_bvec() allocates a special payload page for UNMAP and WRITE SAME commands. If scsi_alloc_sgtables() fails afterward in sd_setup_unmap_cmnd() or sd_setup_write_same{10,16}_cmnd(), the SCSI midlayer does not call uninit_command() because RQF_DONTPREP is not set yet, leaking the page.  Call sd_uninit_command() on error, and clear RQF_SPECIAL_PAYLOAD after freeing the page.

CVE-2026-90273:

        In the Linux kernel, the following vulnerability has been resolved:  coresight: etm4x: missing cscfg_csdev_disable_active_config() in perf enable  In the perf enable path, there are missing cases where cscfg_csdev_disable_active_config() is not called:    - Branch broadcast is selected but not supported by the hardware   - etm4_enable_hw() fails  This can lead to a leak of config_desc->active_cnt. Fix this by properly calling cscfg_csdev_disable_active_config() in these error paths.

CVE-2026-90289:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Resize MST HDCP per-connector arrays to 32  AMDGPU_DM_MAX_DISPLAY_INDEX is 31. It suggest a maximum number of 32 connectors. But the way it's used is like MAX_DISPLAY_COUNT. Hence we're off by one with DRM core, which supports a max of 32 connectors.  Rename AMDGPU_DM_MAX_DISPLAY_INDEX to AMDGPU_DM_MAX_DISPLAY_COUNT to match its actual use, and increase the size to 32 to match the originally intended size.

CVE-2026-90300:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: Clear buf on error in __bpf_get_task_stack  Both bpf_get_task_stack and bpf_get_task_stack_sleepable helpers that use __bpf_get_task_stack have buf defined as ARG_PTR_TO_UNINIT_MEM argument and we should initialize the buf on every return path.  Adding missing buf memset for __bpf_get_task_stack fail paths. This provides deterministic buffer contents, which is useful when the buffer is used directly as a map key.

CVE-2026-90301:

        In the Linux kernel, the following vulnerability has been resolved:  ocfs2: o2hb: quiesce negotiate handlers and timeout work  Heartbeat regions publish struct o2hb_region as the private data for the NEGO_TIMEOUT and NEGO_APPROVE o2net handlers as soon as make_item() creates the configfs region.  The approve handler can call o2hb_arm_timeout(), so a peer can touch the region timeout work before dev_store() has finished building the heartbeat runtime, or after teardown has started to shut that runtime back down.  The final configfs put also has to keep reg alive until the last in-flight o2net callback drops its handler reference.  o2net_unregister_handler_list() blocks future handler lookups, but it does not wait for sc_rx_work that already passed o2net_handler_get().  That drain needs to cover local listener teardown as well, where the o2net ordered workqueue may already be inside destroy_workqueue().  Fix the lifetime rule in both directions.  Initialize the region delayed works before publishing reg through the o2net handler table, keep new or stopping regions non-armable with hr_stopping, and quiesce both delayed works on failed-start and teardown paths even when no heartbeat thread is left to call o2hb_disarm_timeout().  Then unregister handlers before tearing down handler-visible region state and make the drain wait for the active or destroying o2net ordered workqueue before release frees reg.  The buggy scenario involves two paths, with each column showing the order within that path:  region lifecycle:                late negotiate callback: 1. make_item() registers the     1. o2net_process_message() gets a    region handlers before           heartbeat handler for reg.    dev_store() has built a       2. The callback runs after the lookup    runnable heartbeat context.      lock is dropped and dereferences reg. 2. A failed start or rmdir       3. An approve or timeout path tries to    stops the heartbeat thread,      queue reg's delayed work, or release    quiesces existing work, and      races the callback body after handler    drops the final configfs ref.    unregister. 3. region_release() must drain   4. The callback or delayed work can    handler-visible o2net rx work    outlive reg unless lifecycle code    before freeing reg.              keeps the region non-armable and                                     drains the active-or-destroying                                     o2net workqueue.  Validation reproduced this kernel report: KASAN slab-use-after-free in __run_timers+0x22c/0x5b0 Write of size 8 Call trace:   dump_stack_lvl+0x66/0xa0   print_report+0xce/0x630   __run_timers+0x22c/0x5b0   kasan_report+0xe0/0x110   _raw_spin_unlock_irqrestore+0x27/0x60   try_to_wake_up+0x191/0xf70   timer_expire_remote+0xae/0xf0   run_timer_softirq+0x19b/0x1a0   handle_softirqs+0x156/0x660   __irq_exit_rcu+0xc4/0x160   irq_exit_rcu+0xe/0x20   sysvec_apic_timer_interrupt+0x6c/0x80   asm_sysvec_apic_timer_interrupt+0x1a/0x20  Allocated by task stack:   kasan_save_stack+0x33/0x60   kasan_save_track+0x14/0x30   __kasan_kmalloc+0xaa/0xb0   o2hb_heartbeat_group_make_item+0x3c/0x600

CVE-2026-90308:

        In the Linux kernel, the following vulnerability has been resolved:  RDMA/erdma: Hold QP references for AE and CM processing  AE QP fatal events and iWARP CM paths load QPs from dev->qp_xa and then use or reference them outside the xarray lock. erdma_destroy_qp() can drop the destroy-path reference and free QP resources while such a lookup is in flight.  Add erdma_qp_get_by_qpn() to acquire a kref under the xarray lock with kref_get_unless_zero(). Remove the QP from the xarray before dropping the destroy-path reference so no new lookup can acquire it while destruction waits for existing users.

CVE-2026-90311:

        In the Linux kernel, the following vulnerability has been resolved:  thermal: hwmon: Remove hwmon class device along with its parent  The current code creates one hwmon device per thermal zone type and that device is registered under the first thermal zone of the given type.  That turns out to be problematic when the thermal zone holding the hwmon device is removed.  For example, say that there are two ACPI thermal zones on a system   /sys/devices/virtual/thermal/thermal_zone0/  /sys/devices/virtual/thermal/thermal_zone1/  The current code registers a hwmon class device for thermal_zone0 only:   /sys/devices/virtual/thermal/thermal_zone0/hwmon0/  because the type is "acpitz" for both of them, but it adds a sysfs attribute that belongs to thermal_zone1 under it:   /sys/devices/virtual/thermal/thermal_zone0/hwmon0/temp2_input  There is also   /sys/devices/virtual/thermal/thermal_zone0/hwmon0/temp1_input  which belongs to thermal_zone0.  When thermal_zone0 is removed, say because the ACPI thermal driver is unbound from the underlying platform device, thermal_remove_hwmon_sysfs() skips the removal of hwmon0 because of the temp2_input attribute belonging to thermal_zone1 which effectively prevents thermal_zone0 removal from making progress.  Address this by making thermal_remove_hwmon_sysfs() remove the entire hwmon class device interface for the given thermal zone type when the thermal zone device holding it is removed.  To prevent races with thermal_add_hwmon_sysfs() that may interfere with this, carry out the entire addition and removal of hwmon sysfs interfaces for thermal zones under thermal_hwmon_list_lock.  Also adjust the layout of the labels in thermal_add_hwmon_sysfs() to the current kernel coding style to align with the new "unlock" label.

CVE-2026-90313:

        In the Linux kernel, the following vulnerability has been resolved:  bpf, cgroup: Fix invalid storage access after __cgroup_bpf_attach failed  A potential invalid storage access issue can occur after replacing a cgroup bpf prog.  This occurs in the following scenario: 1. prog1 with storage is attached to a cgroup in multi-attach mode. 2. prog1 is replaced with prog2 using BPF_F_REPLACE in multi-attach    mode, but fails midway (e.g. in bpf_trampoline_link_cgroup_shim or    update_effective_progs). 3. A new prog3 is attached to the cgroup in multi-attach mode.  The reason is that __cgroup_bpf_attach overwrites pl->storage with the new storage prior to attachment completion. When attachment fails midway, the cleanup path calls bpf_cgroup_storages_free(new_storage) to free the newly allocated storage, but fails to restore pl->storage back to old_storage.  Consequently, the still-active prog1 holds invalid or dangling storage pointers, leading to an invalid memory access when prog1 executes and calls bpf_get_local_storage. Additionally, original pl->flags and cgrp->bpf.flags[atype] are left unrestored.  Fix this by saving old_pl_flags, old_storage, and old_flags prior to the update, and properly restoring all of them in the cleanup path on error.

CVE-2026-90315:

        In the Linux kernel, the following vulnerability has been resolved:  PCI/sysfs: Add lockdown checks to legacy I/O and memory handlers  Currently, the legacy I/O and memory sysfs handlers do not check security_locked_down(LOCKDOWN_PCI_ACCESS), leaving the legacy_io and legacy_mem files unprotected when the kernel is locked down.  Commit eb627e17727e ("PCI: Lock down BAR access when the kernel is locked down") added the check to pci_write_config(), pci_mmap_resource(), and pci_write_resource_io() to prevent userspace from programming DMA-capable hardware that could be used to modify kernel code, but did not cover the legacy handlers.  As a result, root can still write arbitrary I/O ports and map the legacy I/O and memory spaces while the kernel is locked down, which is the same capability the lockdown is meant to remove.  Add the same check to pci_write_legacy_io(), pci_mmap_legacy_mem(), and pci_mmap_legacy_io().  These generic handlers cover both architectures that define HAVE_PCI_LEGACY (such as Alpha and PowerPC).  [bhelgaas: add Link]

CVE-2026-90320:

        In the Linux kernel, the following vulnerability has been resolved:  ocfs2: validate external xattr entries when reading metadata  ocfs2_validate_xattr_block() checks the xattr block header before the block reaches higher-level xattr users, but it does not verify that a non-indexed block's xh_count and entry offsets fit inside the block.  Indexed buckets likewise reach list/get consumers after ECC without an entry-bounds check.  Use the flat xattr entry validator for non-indexed external xattr blocks, and use a bucket-specific validator for indexed buckets at metadata read time.  The bucket validator keeps the entry array bounded by the first bucket block while checking name/value offsets against the bucket block they target.  Reject corrupted external xattr metadata before listxattr() or getxattr() can walk out-of-range entry arrays or name/value offsets.  Validation reproduced this kernel report: BUG: KASAN: use-after-free in ocfs2_xattr_list_entries+0xd7/0x190 Read of size 1 at addr ffff88810a654007 by task ocfs2_xattr_lis/630 Call Trace:   dump_stack_lvl+0x66/0xa0   print_report+0xce/0x630   kasan_report+0xe0/0x110   ocfs2_xattr_list_entries+0xd7/0x190   ocfs2_listxattr+0x3f6/0x610   listxattr+0x90/0xe0   path_listxattrat+0xed/0x220   do_syscall_64+0x115/0x6a0   entry_SYSCALL_64_after_hwframe+0x77/0x7f

CVE-2026-90321:

        In the Linux kernel, the following vulnerability has been resolved:  ocfs2: validate inline xattrs during inode block validation  Patch series "ocfs2: validate xattr entry bounds", v7.  This series validates OCFS2 xattr entry name/value bounds when xattr metadata is read and validated, before getxattr() or listxattr() can walk out-of-range entry arrays or offsets from corrupted metadata.   This patch (of 2):  ocfs2_validate_inode_block() verifies a dinode before OCFS2 users walk metadata from it, but inline xattr metadata is still checked only in operation-specific consumers.  The existing ibody lookup helper validates inline header placement and entry count, but inode block validation does not reject entry name/value bounds.  Add a flat xattr entry validator and call it from inode block validation for inline xattrs.  Keep the operation paths on their existing header/count lookup checks; the full entry bounds check now runs when the inode block is validated at read time.  Reject corrupted inline xattr metadata before ocfs2_xattr_ibody_get() or listxattr() can walk past the inline storage.  Validation reproduced this kernel report: BUG: KASAN: use-after-free in ocfs2_xattr_find_entry+0x5a/0x170 Read of size 2 at addr ffff8881242a2000 by task python3/529 Call Trace:   dump_stack_lvl+0x66/0xa0   print_report+0xce/0x630   kasan_report+0xe0/0x110   ocfs2_xattr_find_entry+0x5a/0x170   ocfs2_xattr_get_nolock+0x20a/0x820   ocfs2_xattr_get+0x10c/0x1e0   __vfs_getxattr+0xe2/0x130   vfs_getxattr+0x185/0x1b0

CVE-2026-90322:

        In the Linux kernel, the following vulnerability has been resolved:  ocfs2/cluster: keep heartbeat local node stable  o2nm_node_local_store() handles local=0 by stopping o2net and setting cl_local_node to O2NM_INVALID_NODE_NUM, but it leaves cl_has_local set.  That stale state makes o2nm_this_node() return 255, blocks a later local=1 attempt with -EBUSY, and can feed 255 to heartbeat users that call o2nm_this_node() dynamically.  Clearing cl_has_local is required when the local node is reset.  But heartbeat threads can still be running at that point.  They pin the local node config item at startup, yet o2hb_do_disk_heartbeat() and thread teardown re-read o2nm_this_node() for the local slot and for o2nm_undepend_this_node().  Once local=0 has cleared the live local-node state, those dynamic reads return O2NM_MAX_NODES, which is also the invalid node number 255.  Store the local node number in the heartbeat region when the region starts.  Use that stable node for heartbeat slot writes/checks, negotiation messages, and the final configfs undepend.  Stop the heartbeat loop when the current local node no longer matches the stored node, and clear cl_has_local together with cl_local_node in the local=0 path so nodemanager state matches node removal.  Validation reproduced this kernel report: KASAN slab-out-of-bounds in o2hb_do_disk_heartbeat+0x372/0xb30 RIP: 0010:memset+0xf/0x20 Read of size 8 Call trace:   dump_stack_lvl+0x66/0xa0   print_report+0xd0/0x630   o2hb_do_disk_heartbeat+0x372/0xb30 (fs/ocfs2/cluster/heartbeat.c:1079)   srso_alias_return_thunk+0x5/0xfbef5   __virt_addr_valid+0x188/0x2f0   kasan_report+0xe4/0x120   o2hb_do_disk_heartbeat+0x5/0xb30 (fs/ocfs2/cluster/heartbeat.c:1079)   o2hb_thread+0x14e/0x770   kthread_affine_node+0x139/0x180   lockdep_hardirqs_on_prepare+0xda/0x190   trace_hardirqs_on+0x18/0x130   kthread+0x19d/0x1e0   ret_from_fork+0x37a/0x4d0   __switch_to+0x2d5/0x6f0   ret_from_fork_asm+0x1a/0x30

CVE-2026-90325:

        In the Linux kernel, the following vulnerability has been resolved:  blk-cgroup: skip dying blkg in blkcg_activate_policy()  When switching IO schedulers on a block device, blkcg_activate_policy() can race with concurrent blkcg deletion, leading to a use-after-free in rcu_accelerate_cbs.  T1:                               T2:                                   blkg_destroy                                   kill(&blkg->refcnt) // blkg->refcnt=1->0                                   blkg_release // call_rcu(__blkg_release)                                   ...                                   blkg_free_workfn                                   ->pd_free_fn(pd) elv_iosched_store elevator_switch ... iterate blkg list blkg_get(blkg) // blkg->refcnt=0->1                                   list_del_init(&blkg->q_node) blkg_put(pinned_blkg) // blkg->refcnt=1->0 blkg_release // call_rcu again rcu_accelerate_cbs // uaf  Fix this by checking hlist_unhashed(&blkg->blkcg_node) before getting a reference to the blkg. This is the same check used in blkg_destroy() to detect if a blkg has already been destroyed. If the blkg is already unhashed, skip processing it since it's being destroyed.

CVE-2026-90326:

        In the Linux kernel, the following vulnerability has been resolved:  blk-cgroup: fix race between policy activation and blkg destruction  When switching an IO scheduler on a block device, blkcg_activate_policy() allocates blkg_policy_data (pd) for all blkgs attached to the queue. However, blkcg_activate_policy() may race with concurrent blkcg deletion, leading to use-after-free and memory leak issues.  The use-after-free occurs in the following race:  T1 (blkcg_activate_policy):   - Successfully allocates pd for blkg1 (loop0->queue, blkcgA)   - Fails to allocate pd for blkg2 (loop0->queue, blkcgB)   - Enters the enomem rollback path to release blkg1 resources  T2 (blkcg deletion):   - blkcgA is deleted concurrently   - blkg1 is freed via blkg_free_workfn()   - blkg1->pd is freed  T1 (continued):   - Rollback path accesses blkg1->pd->online after pd is freed   - Triggers use-after-free  In addition, blkg_free_workfn() frees pd before removing the blkg from q->blkg_list. This allows blkcg_activate_policy() to allocate a new pd for a blkg that is being destroyed, leaving the newly allocated pd unreachable when the blkg is finally freed.  Fix these races by extending blkcg_mutex coverage to serialize blkcg_activate_policy() rollback and blkg destruction, ensuring pd lifecycle is synchronized with blkg list visibility.

CVE-2026-90328:

        In the Linux kernel, the following vulnerability has been resolved:  HID: steam: Reject short reads  Steam Controller FEATURE reports encode the size of the message in the message itself. Previously we were trusting that the size reported matched the size we actually read, leading to a potential issue with short reads. Instead, we should actually verify the length of the read.

CVE-2026-90330:

        In the Linux kernel, the following vulnerability has been resolved:  HID: logitech-hidpp: Fix FF device cleanup on init failure  hidpp_ff_init() creates the input force-feedback device with input_ff_create(), then allocates the HID++ FF private data, effect ID array, and workqueue.  If any of those allocations fail after input_ff_create() succeeds, the function returns an error without destroying the FF device. Add an unwind path that frees the private allocations made by hidpp_ff_init() and calls input_ff_destroy() for failures after input_ff_create() succeeds.

CVE-2026-90333:

        In the Linux kernel, the following vulnerability has been resolved:  dm-integrity: replace forgeable discard filler with a keyed sector marker  The discard-block check in dm_integrity_rw_tag() treats a stored tag of all 0xf6 bytes (DISCARD_FILLER) as proof a block was discarded and skips HMAC verification. allow_discards is only accepted in dm-integrity's standalone mode. An attacker with raw write access to the backing device, but without the integrity key, can stamp any block with an all-0xf6 tag and have it served as authentic.  Add a new "allow_discards_keyed" target argument that marks discarded blocks with a keyed checksum of (salt || sector) instead, computed by integrity_discard_checksum().

CVE-2026-90335:

        In the Linux kernel, the following vulnerability has been resolved:  tty: skip cdev_del() when no cdev is registered  TTY device registration can fail before a cdev is allocated. Serial core keeps the port so setserial can still use it, and later removal passes the NULL cdev slot to cdev_del(), causing a NULL-pointer dereference.  Only delete the cdev when the slot is not NULL.

CVE-2026-90336:

        In the Linux kernel, the following vulnerability has been resolved:  serial: core: clear freed pointers on uart_register_driver() failure  uart_register_driver() leaves drv->state pointing to freed memory when tty_alloc_driver() fails. If tty_register_driver() fails, drv->tty_driver also retains a pointer after its reference is dropped.  Drivers that use drv->state as an "already registered" flag can then skip registration on the next probe and pass the freed state to uart_add_one_port().  This issue was found with failslab on QEMU's raspi1ap board by failing registration and binding the PL011 port again.  Clear both pointers on their failure paths, as uart_unregister_driver() already does.

CVE-2026-90337:

        In the Linux kernel, the following vulnerability has been resolved:  serial: core: do fallible allocations before the console can be registered  serial_core_add_one_port() allocates uport->tty_groups after uart_configure_port(), which may register the console. If the allocation fails, the driver unwinds the port while its console remains registered. The earlier uport->name allocation has a related failure path that leaves state->uart_port linked to a port being freed.  Failslab reproduced a NULL dereference in PL011 console output and a KASAN use-after-free in i.MX console output after failed binds.  Allocate the name and tty_groups before linking the port and configuring it. Reserve space for the optional driver attribute group because config_port() may populate uport->attr_group during configuration.

CVE-2026-90343:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: cfg80211: stop PMSR before P2P and NAN teardown  PMSR request teardown must abort active measurements while the wireless_dev is still present in the driver. cfg80211_leave_locked() and cfg80211_stop_pd() already do this before invoking the driver's stop callback, but cfg80211_stop_p2p_device() and cfg80211_stop_nan() do not.  Those helpers are also called directly by nl80211, rfkill shutdown, and wireless_dev unregister paths. If one of these paths stops a P2P device or NAN interface with a pending request, it removes the mac80211 subinterface from the driver first. Subsequent request cleanup cannot reach the lower driver's abort callback, but cfg80211 frees the request regardless. Driver state can then retain a stale request and use it when it later reports a result.  Call cfg80211_pmsr_wdev_down() before stopping the P2P device or NAN interface. This keeps lower-driver request state and cfg80211 request ownership in sync for all of the helpers' callers.

CVE-2026-90345:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: brcmfmac: fix P2P action frame handling without device vif  Some P2P action frame paths assume the P2P device vif is always available. That is not true when userspace sends non-P2P public action frames through the primary interface, or when action-frame abort runs after the P2P device vif has not been created.  Fall back to the primary vif when aborting an action frame without a P2P device vif, and guard P2P device saved IE access before using it for peer channel search.

CVE-2026-90346:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: nl80211: clean up color-change beacon data on errors  nl80211_color_change() calls nl80211_parse_beacon() for the beacon_next template, which can allocate params.beacon_next.mbssid_ies and .rnr_ies. A parsing failure returned directly instead of using the out: cleanup, leaking any allocations completed before the error.  Allocate the nested attribute table before parsing beacon_next. Its allocation failure can then return before beacon data exists, while a later parsing failure uses out: to release the parsed data.

CVE-2026-90347:

        In the Linux kernel, the following vulnerability has been resolved:  arm64: ptrace: Keep 'orig_x0' in-sync with x0 on syscall entry  Commit e057b9477232 ("arm64: syscall: Ensure saved x0 is kept in-sync with tracer updates") attempted to resolve a long-standing issue with syscall entry tracing, where a tracer is able to manipulate the first syscall argument without being subjected to seccomp or audit checking.  Unfortunately, that fix was incomplete [1], as it failed to update 'orig_x0' between a tracer updating x0 during a seccomp ptrace exit (SECCOMP_RET_TRACE) and the seccomp filter being re-evaluated.  Rather than add hooks to the core seccomp code, instead move the synchronisation code into the ptrace GPR and syscall setting code so that 'orig_x0' is kept up to date with x0 whenever we're stopped on the syscall entry path.

CVE-2026-90358:

        In the Linux kernel, the following vulnerability has been resolved:  bpf, x86: Fix trampoline stack size for 128-bit arguments  btf_distill_func_proto() accepts a function argument up to 16 bytes, so a 128-bit scalar such as __int128 reaches the x86 trampoline with arg_size == 16. But the current implementation assumes an __int128 argument only needs one register, so the register save area is under-allocated and save_args() overwrites adjacent stack slots.  Compute the register count from arg_size for all arguments to fix it.

CVE-2026-90359:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: Reject >8 byte return values on return-reading trampoline paths  btf_distill_func_proto() builds the function model used for the fentry/fexit/fmod_ret/fsession trampolines and struct_ops. It has accepted a 16-byte __int128 return value since the trampoline was introduced: __get_type_size() returns the integer's type size, and the return-type check only rejected ret < 0.  But the BPF trampoline preserves only 8 bytes of the return value (RAX on x86, i.e. R0). For an attach type that reads the target's return value the second half (RDX / R3) is neither saved nor restored, so a program attached to a function returning a 16-byte value corrupts the value seen by the real caller and itself observes only half of it. struct_ops trampolines have the same limitation.  This affects the attach types that read the target's return value: fexit, fmod_ret and fsession (plus the _multi variants of fexit and fsession), and struct_ops. fentry/fentry_multi run before the target returns and are unaffected.  Reject a >8 byte return value for these attach types in bpf_check_attach_target() and bpf_check_attach_btf_id_multi(), and for struct_ops in bpf_struct_ops_desc_init().

CVE-2026-90365:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: mt76: cancel reset and rc work on device unregister  Both drivers cancelled dump_work on unregister but left reset_work and rc_work to be flushed only by destroy_workqueue() in mt76_free_device(), which runs after the hw is unregistered and the hardware stopped. A reset_work that fires in that window calls ieee80211_restart_hw() and re-arms mac_work on an unregistered hw, and rc_work touches station state being torn down. Cancel both up front, alongside dump_work.

CVE-2026-90368:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: mt76: mt7915: unwind state on add_interface failure  When mt76_wcid_alloc() fails, mt7915_add_interface() returned without clearing the vif_mask/omac_mask bits it had already set, without removing the firmware dev info added earlier, and without clearing a monitor_vif pointer to the vif mac80211 is about to free. mac80211 does not call remove_interface() for a failed add, so the indices and firmware dev entry leaked permanently and testmode could dereference the stale monitor_vif. Add a proper error unwind.

CVE-2026-90375:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: mt76: fix non-AQL packet accounting for MLO stations  __mt76_tx_queue_skb() overrides the wcid passed by the driver with sta->drv_priv, so the wcid might incorrectly be changed after TX, causing wcid->non_aql_packets to be counted on the wrong wcid. For example, on the AP side, if a station's setup link is the 5G link and the station uses 2G to transmit a frame, the value of non_aql_packets is increased on the 5G wcid but decreased on the 2G wcid. Once the inflated counter exceeds MT_MAX_NON_AQL_PKT, the TX scheduler permanently refuses to service the station.  Drop the reassignment and account on the wcid used for transmission. This also records the actual wcid in the queue entry.

CVE-2026-90379:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: mt76: mt7921: Add PCIe AER handler support to prevent system crash  When an AER error occurs and the bus is hung, the register reads return 0xFFFFFFFF, causing the DMA queue state to be corrupted and resulting in an invalid memory access when accessing q->desc[] or q->entry[].  Unable to handle kernel paging request at virtual address ffffffc01099eac0 pc : mt76_dma_add_buf+0x124/0x188 [mt76] lr : mt76_dma_rx_fill+0x11c/0x1d8 [mt76] sp : ffffffc016d9bbf0 x29: ffffffc016d9bc10 x28: 0000000000000000 x27: 0000000000000000 x26: ffffffb7855e50b8 x25: ffffffb80d04f000 x24: 0000000000000000 x23: 0000000000000ec0 x22: ffffffb796803648 x21: ffffffb796801f80 x20: ffffffb7968035f8 x19: 0000000000000ec0 x18: 0000000000000000 x17: 000000004ec00000 x16: 000000000ec00000 x15: ffffffc01099eac0 x14: 000000004ec00000 x13: 00000000ffc5a000 x12: ffffffc016d9bc32 x11: 00000000ffffffff x10: 0000000000000002 x9 : 0000000000000000 x8 : 000000000000b4ac x7 : 0000000000000a20 x6 : ffffffb6c1806400 x5 : 0000000000000000 x4 : ffffffb80d04f000 x3 : 0000000000000000 x2 : 0000000000000001 x1 : 000000000ec04000 x0 : ffffffb7968035f8 Call trace:  mt76_dma_add_buf+0x124/0x188 [mt76 (HASH:1029 4)]  mt76_dma_rx_reset+0xe8/0xfc [mt76 (HASH:1029 4)]  mt7921_wpdma_reset+0x188/0x1b0 [mt7921e (HASH:ee48 5)]  mt7921e_mac_reset+0x128/0x418 [mt7921e (HASH:ee48 5)]  mt7921_mac_reset_work+0xac/0x1a8 [mt7921_common (HASH:f721 6)]  process_one_work+0x188/0x514  worker_thread+0x12c/0x300  kthread+0x140/0x1fc  ret_from_fork+0x10/0x30  Fix the invalid memory access by validating the DMA index read from the hardware before it is used as a queue index. An out-of-range value, such as the 0xFFFFFFFF returned while the bus is hung, is now clamped so it can no longer corrupt q->head or q->tail. In addition, check the bus_hung flag in mt7921_mac_reset_work() before attempting the reset sequence, reject MCU messages while the bus is hung, and install no-op bus operations when an unrecoverable AER error is detected, preventing further invalid hardware accesses.  Due to hardware limitations - such as the lack of a connected hardware reset pin or the absence of host re-probe functionality - affected Wi-Fi devices may not fully recover to a normal operational state after certain errors, even with AER enabled.

CVE-2026-90383:

        In the Linux kernel, the following vulnerability has been resolved:  misc: sgi-gru: remove interrupt-context page-table walks  The GRU TLB miss handler walks a process's page tables without holding page-table locks or a reference to the mapped page. It also uses a kernel page-table accessor on user page tables and supports only PMD-level large mappings on x86-64.  Remove the direct walker. Send interrupt faults directly to user polling mode so the existing call-OS fallback retries them in process context.  Remove the mmap-lock failure statistic that can no longer be incremented.

CVE-2026-90385:

        In the Linux kernel, the following vulnerability has been resolved:  md/raid1: create serial pool adding rdev to array with serialize_policy=1  The following bug has been observed with kernel 7.1.3 after adding a new rdev to an existing RAID1 array with serialize_policy enabled:    Oops: 0002 [#1]   CPU: 0 UID: 0 PID: 19639 Comm: ext4lazyinit Not tainted 7.1.3-1-default   RIP: _raw_spin_lock_irqsave+0x27/0x50   CR2: 0000000000004960   Call Trace:    wait_for_serialization+0xb9/0x260 [raid1]    raid1_make_request+0x762/0xaff [raid1]    md_handle_request+0x1c9/0x2e0 [md_mod]  The raid1.c code calls wait_for_serialization() if the MD_SERIALIZE_POLICY is set, and wait_for_serialization assumes that rdev->serial is initialized. Normally this will be the case for arrays that have the serialize_policy sysfs attribute set to 1.  But when a new rdev is added to an existing array in bind_rdev_to_array(), the condition at mddev_create_serial_pool() causes creation of rdev->serial to be skipped. Fix it.

CVE-2026-90389:

        In the Linux kernel, the following vulnerability has been resolved:  md: scope memalloc_noio to allocation critical sections  Storing a memalloc_noio_save() token in mddev->noio_flags lets one task save the token and another task restore it. With concurrent suspend sysfs writes, task A can enter PF_MEMALLOC_NOIO, return to userspace still in that scope, and later task B can restore A's saved token.  Avoid tying the token lifetime to mddev. Keep mddev_suspend() and mddev_resume() only responsible for array suspension, and enter PF_MEMALLOC_NOIO only in the MD paths that allocate memory after the array has been suspended. Restore the token before resuming the array.  A reproducer repeatedly writes suspend_lo and suspend_hi from concurrent workers and checks each worker's /proc/self/stat flags before and after the sysfs write.

CVE-2026-90392:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: Fix potential UAF when reading bpf link info  In bpf_link_show_fdinfo and bpf_link_get_info_by_fd, link->prog is accessed without holding any locks. If the prog is concurrently replaced via bpf_link_update, the old prog can be freed, leading to a potential UAF issue.  Fix this by accessing link->prog under RCU protection to safely fetch the pointer and guarantee its lifetime while reading its fields.

CVE-2026-90398:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: ath11k: fix stride mismatch in mac_phy_caps_parse()  Currently, in ath11k_wmi_tlv_mac_phy_caps_parse(), kcalloc() sizes the mac_phy_caps buffer as tot_phy_id * len, where len is clamped to min(firmware_len, sizeof(struct wmi_mac_phy_capabilities)). The subsequent memcpy() destination advances by sizeof(full struct) per slot via C pointer arithmetic, not by the clamped len. When firmware sends short TLVs, the second and later slots are written past the end of the allocation.  The reader in ath11k_pull_mac_phy_cap_svc_ready_ext() also indexes the buffer with full-struct pointer arithmetic, so the allocation must match that stride.  Fix by using kzalloc_objs(), which derives the element size from the pointer type, making allocation size and pointer stride provably consistent regardless of what len the firmware provides.  Compile tested only.

CVE-2026-90401:

        In the Linux kernel, the following vulnerability has been resolved:  md: remove REQ_NOWAIT support from raid1/10/456  REQ_NOWAIT support in md personalities that can block internally is fundamentally incomplete. While reads can avoid some blocking paths, write requests can still encounter cases where one mirror succeeds while another returns -EAGAIN. At that point md cannot distinguish queue pressure from a real device failure, so it can neither record a bad block nor safely retry the write without REQ_NOWAIT, leaving mirrors with divergent data.  Rather than continue advertising REQ_NOWAIT support for personalities that cannot implement it correctly, remove it from raid1, raid10 and raid456. Keep REQ_NOWAIT for linear and raid0, which only remap bios to their underlying devices; stacked limits will still clear the feature if any component device lacks REQ_NOWAIT support.

CVE-2026-90407:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: ath11k: fix overreads in ath11k_wmi_process_csa_switch_count_event()  There is no policy entry for WMI_TAG_PDEV_CSA_SWITCH_COUNT_STATUS_EVENT, so the parse infrastructure does not enforce a minimum length for the event struct. Additionally, the num_vdevs field is taken directly from firmware and used as a loop bound over the vdev_ids array without checking that it fits within the TLV payload. Either condition can cause an out-of-bounds read.  Add a TLV policy entry for WMI_TAG_PDEV_CSA_SWITCH_COUNT_STATUS_EVENT so the parse infrastructure enforces a minimum length for the fixed-size event struct. Add a helper ath11k_wmi_tlv_data_len() to recover the payload length of a parsed TLV from the header preceding its data pointer. Use it in ath11k_wmi_process_csa_switch_count_event() to bound num_vdevs before the loop.  Compile tested only.

CVE-2026-90410:

        In the Linux kernel, the following vulnerability has been resolved:  spi: davinci: switch to managed controller allocation  The controller is allocated with the non-managed spi_alloc_host() while the interrupt is registered with devm_request_threaded_irq().  During removal, spi_bitbang_stop() only unregisters the controller; the subsequent spi_controller_put() then frees the controller together with its embedded davinci_spi devdata, which is the IRQ handler's dev_id. The devm_request_threaded_irq() release action (free_irq()), which drains the handler, does not run until after .remove() returns.  A late or latched interrupt can therefore reach davinci_spi_irq() and dereference already-freed memory.  Switch to devm_spi_alloc_host() so that the devres LIFO order releases the controller only after free_irq() has drained the handler, and drop the now-redundant spi_controller_put() from .remove().  The probe error path is simplified to direct returns.  The clock is acquired with devm_clk_get_enabled(), which is registered after the IRQ and thus released before it by the devres LIFO order. Drain the interrupt explicitly with devm_free_irq() before disabling the controller so that a late interrupt cannot access the registers of a clock-gated controller.  This issue was found by an in-house static analysis tool.

CVE-2026-90417:

        In the Linux kernel, the following vulnerability has been resolved:  RDMA/cxgb4: Fix dereg_skb leak and double free in write_tpt_entry()  When the device is in the fatal error state, write_tpt_entry() returns -EIO before handing the caller's preallocated skb to the transmit path; its allocation-failure returns do the same. c4iw_dereg_mr() ignores the error and frees mhp, leaking mhp->dereg_skb. c4iw_get_dma_mr() instead frees the skb a second time after dereg_mem() already consumed it, a double free.  Make write_tpt_entry() the sole owner of a non-NULL skb, freeing it on every return preceding handoff to c4iw_ofld_send(): fatal error, tpt and stag allocation failure. c4iw_ofld_send() consumes the skb on success and error alike, so drop the redundant kfree_skb() in c4iw_get_dma_mr() after dereg_mem().

CVE-2026-90418:

        In the Linux kernel, the following vulnerability has been resolved:  nilfs2: fix BUG in nilfs_copy_dirty_pages() on dirty state mismatch  Syzbot reported a kernel BUG triggered within nilfs_copy_dirty_pages(), which copies dirty DAT file folios/pages to its shadow page cache.  The BUG occurs when a retrieved dirty folio/page unexpectedly loses its 'dirty' status.  This issue arises because, since the commit referenced below, the 'dirty' flag of a folio/page can be cleared asynchronously after the filesystem detects metadata corruption and transitions to read-only mode.  Resolve the issue by returning an -EROFS error if the filesystem has transitioned to read-only mode.  Also change the behavior to issue a kernel warning only once instead of triggering a kernel BUG when this unexpected 'dirty' state is detected while the filesystem is not in read-only mode.

CVE-2026-90421:

        In the Linux kernel, the following vulnerability has been resolved:  PCI: Fix UAF when probe runs concurrent to dyn ID removal  Dynamic IDs are only guaranteed to be valid when dynids.lock is held, as remove_id_store() can free the node. Thus, make a copy in pci_match_device(). Also, clarify that the id parameter is only valid during probe.

CVE-2026-90433:

        In the Linux kernel, the following vulnerability has been resolved:  spi: oc-tiny: switch to managed controller allocation  The controller is allocated with the non-managed spi_alloc_host() while the interrupt is registered with devm_request_irq().  During removal, spi_bitbang_stop() only unregisters the controller; the subsequent spi_controller_put() then frees the controller together with its embedded driver-private devdata, which is the IRQ handler's dev_id.  The devm_request_irq() release action (free_irq()), which drains the handler, does not run until after .remove() returns.  A late or latched interrupt can therefore reach tiny_spi_irq() and dereference already-freed memory (e.g. hw->base).  Switch to devm_spi_alloc_host() so that the devres LIFO order releases the controller only after free_irq() has drained the handler, and drop the now-redundant spi_controller_put() from .remove().  The probe error path is simplified to direct returns.  This issue was found by an in-house static analysis tool.

CVE-2026-92480:

        In the Linux kernel, the following vulnerability has been resolved:  scsi: ufs: core: Validate string descriptors  The string descriptor length includes a two-byte header while the UTF-16 payload starts after it. utf16s_to_utf8s() expects a count of UTF-16 code units, not bytes. Passing the payload byte count can make it read beyond the descriptor buffer.  Validate that the payload has an even byte count, pass a code-unit count to the converter, and allocate sufficient UTF-8 output space.  The raw string buffer starts after the descriptor header but its size is bLength. Copying bLength bytes from that pointer can read beyond the response buffer.  Allocate a zeroed bLength-sized buffer and copy only the UTF-16 payload. This preserves the raw buffer size consumed by the RPMB device-ID ABI while avoiding the overread.

CVE-2026-92482:

        In the Linux kernel, the following vulnerability has been resolved:  pinctrl: mediatek: use devm_gpiochip_add_data() for GPIO chip  The gpio_chip is allocated with device-managed memory but registered with the non-managed gpiochip_add_data(). This was harmless while the drivers were built-in, but once they can be built as modules and unbound/rmmod'd, devm frees the gpio_chip's memory while it is still registered, causing a use-after-free.  Register it with devm_gpiochip_add_data() so it shares the same device-managed lifecycle, which also lets the manual gpiochip_remove() error paths go away.

CVE-2026-92485:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: Fix WARNING in bpf_tracing_link_release  The trampoline could be corrupted by the blindly 'tr->flags = BPF_TRAMP_F_TAIL_CALL_CTX' in verifier.  1. A fexit attached to a tail_call_reachable prog. 'tr->flags' became    'BPF_TRAMP_F_CALL_ORIG | BPF_TRAMP_F_TAIL_CALL_CTX'. And, the    trampoline would poke the target prog's nop insn using jmp insn instead    of call insn. 2. Another fexit loaded with the same tail_call_reachable prog target.    'tr->flags' became 'BPF_TRAMP_F_TAIL_CALL_CTX'. 3. Close the first fexit link. Due to no BPF_TRAMP_F_CALL_ORIG in    'tr->flags', the trampoline will fail to restore the prog's nop insn    using call insn.  [    3.410719] WARNING: kernel/bpf/syscall.c:3551 at bpf_tracing_link_release+0x53/0x60, CPU#1: test_progs/98 ... [    3.428793]  bpf_link_free+0x58/0x130 [    3.429293]  bpf_link_release+0x23/0x30  Fix the warning by updating 'tr->flags' with '|=' and lock.

CVE-2026-92488:

        In the Linux kernel, the following vulnerability has been resolved:  RDMA/erdma: complete object teardown when the destroy command fails  erdma_destroy_qp(), erdma_destroy_cq(), erdma_dereg_mr(), and erdma_destroy_ah() returned early when erdma_post_cmd_wait() failed, leaking the queue buffers, MTTs, doorbells and the STAG, QPN, CQN and AHN identifiers. A command timeout clears ERDMA_CMDQ_STATE_OK_BIT and permanently disables the command queue, so no retry can succeed; the RDMA core keeps the object after a failed destructor and forced uverbs cleanup then nulls the pointers, making the resources unreachable.  Warn on failure but release every software-owned resource and return success, since during terminal destruction the hardware command result is only diagnostic.

CVE-2026-92493:

        In the Linux kernel, the following vulnerability has been resolved:  cpufreq: amd-pstate-ut: Skip tests when amd-pstate driver is not active  The crash issue may occur when modprobe amd_pstate_ut on intel platform.     amd_pstate_ut: 1    amd_pstate_ut_acpi_cpc_valid  success!    amd_pstate_ut: 2    amd_pstate_ut_check_enabled   success!    BUG: kernel NULL pointer dereference, address: 0000000000000080    #PF: supervisor read access in kernel mode    #PF: error_code(0x0000) - not-present page    PGD 0 P4D 0    Oops: 0000 [#1] SMP NOPTI    CPU: 0 PID: 20300 Comm: modprobe    Kdump: loaded Tainted: G O 6.6.0-0010.rc1.ctl4.x86_64 #1    Hardware name: FiberHome R2200 V5/Xeon Boards, BIOS 3.1a 02/24/2020    RIP: 0010:amd_pstate_ut_check_perf+0x141/0x280 [amd_pstate_ut]    Call Trace:     <TASK>     amd_pstate_ut_init+0x1b/0xff0 [amd_pstate_ut]     ? __pfx_amd_pstate_ut_init+0x10/0x10 [amd_pstate_ut]     do_one_initcall+0x42/0x2e0     ? kmalloc_trace+0x26/0x90     do_init_module+0x60/0x240     __se_sys_init_module+0x185/0x1c0     do_syscall_64+0x62/0x190     entry_SYSCALL_64_after_hwframe+0x76/0x7e     </TASK>  Add state detection to amd pstate driver to prevent amd_pstate_ut driver from testing on non-AMD platforms.  (ML: adjust title)

CVE-2026-92499:

        In the Linux kernel, the following vulnerability has been resolved:  ext4: validate readdir offset before accessing dirent  A corrupted directory can trigger the following KASAN report when ext4_readdir() resumes from an invalid position:    BUG: KASAN: use-after-free in __ext4_check_dir_entry+0x5ef/0x820   Read of size 2 at addr ffff88810a646000 by task repro_linear/509    Call Trace:    <TASK>    dump_stack_lvl+0x53/0x70    print_report+0xd0/0x630    kasan_report+0xce/0x100    __ext4_check_dir_entry+0x5ef/0x820    ext4_readdir+0xcde/0x2b70    iterate_dir+0x1a1/0x520    __x64_sys_getdents64+0x12b/0x220    do_syscall_64+0xf9/0x540    entry_SYSCALL_64_after_hwframe+0x77/0x7f    </TASK>  KASAN reports use-after-free because the out-of-bounds access lands in an adjacent freed page. The directory buffer itself is still referenced.  ext4_dir_llseek() invalidates the directory cookie so that ext4_readdir() rescans directory entries from the start of the block. The rescan checks only the lower bound of rec_len before advancing. A corrupted rec_len can therefore place the offset where the block has insufficient space for a complete directory entry. The rescan itself may dereference that truncated entry, or the main loop may pass it to __ext4_check_dir_entry(). The latter reads de->rec_len before validating the range. For example:    block offset  0                           4092  4096                 |---- de1.rec_len = 4092 -----|----|                                                de2.inode                                                     | de2.rec_len                                                     ^ OOB, reported as UAF  de2 starts at offset 4092 in this 4 KiB block. Its four-byte inode fits in the block, but its rec_len starts at offset 4096 and crosses the boundary.  The minimum safe length is inode-dependent. Encrypted and casefolded directory entries need eight additional hash bytes, while a valid metadata checksum tail is only 12 bytes.  Cache the metadata checksum feature state and derive the minimum directory entry length from the on-disk format. Use it to bound both the rescan and the offset passed to the main loop. Report an offset in a truncated block tail and skip the remainder of the block, while continuing to accept an offset exactly at the block boundary.

CVE-2026-92500:

        In the Linux kernel, the following vulnerability has been resolved:  ext4: use fsdata to track inline data write state and fix race  Instead of checking the live inode state (ext4_has_inline_data(inode) and ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA)) in the write_end handlers, use the fsdata parameter of the address space operations to explicitly pass down the state in which write_begin prepared the write.  A concurrent thread (such as ext4_page_mkwrite()) can convert the inline data to an extent between write_begin and write_end. If this happens, the write_end handlers would previously miss the inline write_end path and fall through to extent-based write_end logic. However, since block buffers were never allocated in write_begin, this resulted in NULL pointer dereferences or data loss because folio_buffers(folio) was NULL.  Define EXT4_WRITE_DATA_INLINE (4) as a bit flag (Bit 2), treating fsdata as bitwise flags rather than mutually exclusive enums to keep states of the write path independent. Communicate this state via fsdata: 1) ext4_write_begin() and ext4_da_write_begin() set the    EXT4_WRITE_DATA_INLINE bit in *fsdata via bitwise OR when an inline    write is successfully prepared. 2) On entry, ext4_write_begin() clears the EXT4_WRITE_DATA_INLINE bit    to safely handle VFS retries (where generic_perform_write() bypasses    the fsdata initialization on its retry jump). 3) The write_end handlers perform a bitwise AND to check if the    EXT4_WRITE_DATA_INLINE bit is set and invoke the inline write_end    helper accordingly.  Furthermore, during a buffered write, ext4_write_inline_data_end() acquires the xattr lock after preparing the write. If a concurrent page fault (ext4_page_mkwrite()) converts the inline data to an extent after the write_end handlers check the state but before ext4_write_inline_data_end() acquires the xattr write lock, the subsequent check will trigger a kernel panic via BUG_ON(!ext4_has_inline_data(inode)).  To keep git history working and bisectability clean, replace the BUG_ON check in ext4_write_inline_data_end() with a graceful error- handling retry path in this same commit. If the inline data is cleared after locking the xattr, we safely release all resources (releasing iloc.bh, unlocking/putting the folio, stopping the active journal transaction handle) and return 0 (VFS retry) to let the generic write path retry the operation safely.

CVE-2026-92503:

        In the Linux kernel, the following vulnerability has been resolved:  ext4: fix ABBA deadlock in ext4_xattr_inode_cache_find()  Syzbot/stress-ng reported an ABBA deadlock in ext4 when exercising concurrent xattr workloads (using the ea_inode mount/format option).  The deadlock occurs between the running transaction and the eviction thread: - Task 1 (stress-ng): Holds a reference to a shared mbcache_entry (ce)   and calls ext4_xattr_inode_cache_find() -> ext4_iget() to retrieve   the corresponding EA inode. Since the EA inode is currently being   evicted, ext4_iget() blocks in __wait_on_freeing_inode() waiting for   eviction to complete. - Task 2 (eviction thread): Currently evicting the same EA inode in   ext4_evict_ea_inode(). It calls mb_cache_entry_wait_unused(oe) which   blocks waiting for Task 1 to release the reference to the mbcache_entry.  To break this deadlock, implement a new ext4_iget() configuration flag named EXT4_IGET_NOWAIT. When set, perform a non-blocking lookup of the inode via VFS's find_inode_nowait() API.  If the inode is currently being evicted (marked with I_FREEING or I_WILL_FREE) or created (I_CREATING), or if it is not present in the VFS inode cache (cache miss), simply skip it (returning -ENOENT) rather than waiting for eviction/creation to complete, breaking the ABBA cycle.  Since we return -ENOENT immediately on a cache miss, we never attempt to allocate a new inode or call iget_locked(), completely eliminating any TOCTOU race window.  If the returned inode is I_NEW, wait for its initialization to clear via wait_on_new_inode(). If initialization fails and the inode is unhashed during wait_on_new_inode() waking up (e.g., due to an I/O read error in another thread), safely drop the reference and return -ENOENT. This unhashed check is executed unconditionally on all cache-hit pathways to properly handle concurrent initialization failures.  Finally, standard validation checks (including is_bad_inode, EXT4_EA_INODE_FL, file_acl, and xattr flags) are executed as normal inside check_igot_inode() to fully guarantee VFS-layer safety.  In ext4_xattr_inode_cache_find(), invoke ext4_iget() with the new EXT4_IGET_NOWAIT flag to perform the non-blocking cache search.

CVE-2026-92520:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: Zero queue and stack outputs on lock failure  Queue and stack pop/peek helpers accept an uninitialized output buffer because the verifier expects the helper to initialize it. The empty-map error path clears the buffer, but a failed lock acquisition returns -EBUSY without writing it.  Clear the output before returning -EBUSY so BPF programs cannot observe uninitialized stack contents after a failed helper call.

CVE-2026-93042:

        In the Linux kernel, the following vulnerability has been resolved:  dmaengine: dw-edma: Terminate all descriptors without callbacks  The DMA Engine client documentation says in the "Terminate APIs" section of Documentation/driver-api/dmaengine/client.rst:  "No callback functions will be called for any incomplete transfers."  dw-edma instead calls vchan_cookie_complete() when a deferred STOP reaches the interrupt handler. This schedules a callback for the active descriptor and leaves other issued or submitted descriptors queued. A late callback after dmaengine_terminate_sync() can dereference client state that has already been freed, while leftover descriptors may later restart into reused buffers or leak.  Move all issued and submitted descriptors to the terminated list whenever termination completes. For a pending STOP, do this from both the DONE and ABORT paths. Complete their cookies in order without scheduling callbacks.  A STOP can remain pending until the running transfer raises an interrupt. Make device_synchronize() wait for such a pending STOP to complete before releasing terminated descriptors. Reuse it from free_chan_resources(), then release the remaining virt-dma resources. Sleep instead of busy-polling while waiting, and warn if the existing timeout expires.

CVE-2026-93047:

        In the Linux kernel, the following vulnerability has been resolved:  drm/v3d: Associate BOs with every job that accesses them  A submission can expand into a chain of jobs (e.g. bin + render + cache clean). Implicit synchronization in v3d_submit_lock_reservations() is gated on each job's bo[], but the BO list was only ever attached to the last job of the chain. When that last job is a trailing CACHE_CLEAN job, the job that actually consumes the BOs (that is, a RENDER or CSD job) was left with bo_count == 0 and picked up no implicit dependencies. It could therefore be dispatched to the hardware and read a BO while another context was still writing it, leading to data corruption.  Attach the BOs to the job that consumes them, so (1) it acquires the correct implicit dependencies during reservation locking and (2) they are kept mapped until the end of the submission. Give it references to all consuming job's BOs through v3d_job_reference_bos() instead of looking the handles up a second time; that avoids a redundant lookup and guarantees both jobs reference the exact same objects.  As the CACHE_CLEAN job now carries a BO array as well, add a per-job `has_implicit_dep` flag so that only the consuming jobs take implicit dependencies. The CACHE_CLEAN job (a global flush) and the BIN job (binning waiting on another context is not a realistic scenario) are excluded.

CVE-2026-93058:

        In the Linux kernel, the following vulnerability has been resolved:  drm/msm: Only fini scheduler after successful init  msm_ringbuffer_new() destroys a partially initialized ring through msm_ringbuffer_destroy() when an allocation or scheduler setup step fails.  If drm_sched_init() fails before it finishes initializing the scheduler, the failure path still calls drm_sched_fini(). That teardown path assumes the scheduler work items, lists, and workqueue state were initialized.  Track successful scheduler initialization and call drm_sched_fini() only after drm_sched_init() returned 0.  This issue was found by a static analysis checker and confirmed by manual source review.  Patchwork: https://patchwork.freedesktop.org/patch/738905/

CVE-2026-93062:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: iwlwifi: guard against division by zero in iwl_dbg_tlv_alloc_fragments  Make sure we don't end-up with a num_frags = 0 situation. For that, check that the required size is not 0 and put a checker on num_frags as well.

CVE-2026-93072:

        In the Linux kernel, the following vulnerability has been resolved:  irqchip/renesas-irqc: Fix generic interrupt chip leak on remove  The driver allocates domain generic chips probe. However, on driver removal, the generic chips are not automatically freed when the interrupt domain is removed because the domain flags do not include IRQ_DOMAIN_FLAG_DESTROY_GC.  This causes both the domain generic chips structure and the associated generic chips to be leaked. Additionally, the generic chips remain on the global list and may later be accessed by generic interrupt chip suspend, resume, or shutdown callbacks after the driver has been removed, potentially resulting in a use-after-free and kernel crash.  Fix the resource leak by setting IRQ_DOMAIN_FLAG_DESTROY_GC on the interrupt domain; this lets the interrupt domain core automatically release all generic chips when irq_domain_remove() is invoked, removing the need for manual cleanup calls in error paths and remove callback.

CVE-2026-93081:

        In the Linux kernel, the following vulnerability has been resolved:  firmware: arm_scmi: Fix SCMI device destroy lifetimes  scmi_child_dev_find() drops the reference returned by device_find_child() before returning the scmi_device pointer. A concurrent unregister can then release the device while the destroy path is still using the returned pointer.  Make the lookup helper return the device_find_child() reference and keep it until scmi_device_destroy() has finished unregistering the child.  Also split device_unregister() in __scmi_device_destroy() so the SCMI bus ID is not made reusable until after device_del() has removed the old scmi_dev.N name from sysfs. This avoids a new SCMI device reusing the same ID while the old device is still registered.  The final device release callback is also a possible cleanup path when SCMI children are deleted by driver core recursion rather than __scmi_device_destroy(). Release the SCMI bus ID from a common helper used by destroy, register-failure and final-release paths, and clear scmi_dev->id after freeing it so the final release cannot free the same ID again.

CVE-2026-93091:

        In the Linux kernel, the following vulnerability has been resolved:  firmware: arm_scmi: Quiesce notifications before teardown  scmi_notification_exit() clears and releases the notification instance, but transport callbacks can still deliver incoming notifications until the TX/RX channels are freed. During remove, an RX interrupt in that window can enter scmi_notify() while notification state is being torn down and then dereference freed memory. The same ordering exists on the probe error path after notification initialization.  The notification late-init worker has a separate lifetime issue: protocol event registration queues ni->init_work on the system workqueue, so destroying ni->notify_wq does not drain that work. If the devres group is released while init_work is still pending or running, the late-init worker can dereference the freed notification instance.  Quiesce the notification core before TX/RX channels are torn down, then clean up the channels before releasing the notification core resources. Use disable_work_sync() so future late-init queueing is rejected and any already queued or running late-init work has completed before channel teardown starts.

CVE-2026-93093:

        In the Linux kernel, the following vulnerability has been resolved:  firmware: arm_scmi: Publish channel state before callbacks  Transport setup can enable callbacks before the setup routine returns. mailbox_chan_setup() registers the mailbox client with mbox_request_channel(), and the mailbox controller startup path can enable interrupt delivery before SCMI mailbox channel state has been published. Similarly, smc_chan_setup() requests the optional A2P completion IRQ before the SMC transport has made its cinfo pointer visible.  If a pending or spurious callback fires in those windows, the transport RX callback can dereference a NULL transport cinfo pointer. Publishing only the transport-private pointer is not sufficient either: an early callback can enter the SCMI core before scmi_chan_setup() has assigned cinfo->handle. The core derives scmi_info from cinfo->handle in the RX path, so a NULL handle can still fault even when the transport-private cinfo is valid.  Assign cinfo->handle before invoking the transport setup callback. Publish the mailbox and SMC transport-private channel state before requesting the mailbox channels or IRQ, and clear the early-published pointers again on setup failure. Also unwind mailbox setup devres resources on failure so an optional RX setup error that is ignored by the core does not leave stale transport state behind.

CVE-2026-93099:

        In the Linux kernel, the following vulnerability has been resolved:  fs/resctrl: Fix UAF from worker threads when domains are removed  The mbm_handle_overflow() and cqm_handle_limbo() workers read event counters and may sleep while doing so. They are scheduled via delayed_work embedded in struct rdt_l3_mon_domain. Architecture allocates and frees these domains from CPU hotplug callbacks under cpus_write_lock(), and the workers acquire cpus_read_lock() to keep the domain alive across their access.  A use-after-free can occur when a worker is blocked waiting for cpus_read_lock() while the hotplug core holds cpus_write_lock(): the architecture frees the rdt_l3_mon_domain that contains the worker's work_struct. When the worker unblocks, the container_of() it performs on the embedded work pointer dereferences freed memory.  Drop cpus_read_lock() from the workers and instead drain pending and in-flight work synchronously before the architecture can free the domain.  Since architecture offlines the domain under cpus_write_lock() after it has been unlinked from the RCU list and a grace period has elapsed, no new work can be scheduled. The cancel only needs to wait out existing work.  Drop rdtgroup_mutex during CPU offline around cancel_delayed_work_sync() so that a worker waiting on the mutex can complete before re-pinning the work on a different CPU.  When offlining a CPU the architecture may iterate over resources in any order. For example, the MBA control domain may be offlined before or after a corresponding L3 monitor domain. Ensure that resctrl fs cancels the workers no matter what order the architecture offlines the domains.

CVE-2026-93100:

        In the Linux kernel, the following vulnerability has been resolved:  fs/resctrl: Prevent use-after-free in rdtgroup_kn_put()  A struct rdtgroup is reference counted via rdtgroup::waitcount. Callers that need the structure to remain valid across a sleep (while waiting on acquiring rdtgroup_mutex) take a reference with rdtgroup_kn_get() and release it with rdtgroup_kn_put().  The release path is intended to serve as the fallback freer: if the count drops to zero and the group has already been marked RDT_DELETED, rdtgroup_kn_put() frees the structure.  The bulk teardown paths free_all_child_rdtgrp() and rmdir_all_sub() resulting from a resctrl directory remove or resctrl fs unmount act as the primary freer: they hold rdtgroup_mutex and free each rdtgroup whose waitcount is zero, otherwise they set RDT_DELETED and leave the freeing to the last waiter.  These two freers race. rdtgroup_kn_put() commits waitcount == 0 with atomic_dec_and_test() outside rdtgroup_mutex, then reads rdtgroup::flags. Between those two operations a concurrent caller of free_all_child_rdtgrp() or rmdir_all_sub() (which holds the mutex) can observe waitcount == 0 via atomic_read(), call rdtgroup_remove(), and kfree() the structure.  The subsequent read of rdtgroup::flags in rdtgroup_kn_put() is then a use-after-free, and the structure may even be freed twice if the freed memory happens to satisfy the RDT_DELETED flag check.  Replace the bare atomic_dec_and_test() with atomic_dec_and_mutex_lock() so that the decrement-to-zero takes rdtgroup_mutex before the count becomes globally visible. The inspection of rdtgroup::flags then runs under the same mutex held by the bulk freers, making the two paths mutually exclusive.  The common case where the count does not reach zero remains lock-free. Defer kernfs_unbreak_active_protection() until after the mutex is dropped since kernfs active protections functionally wrap rdtgroup_mutex. Remove resource group, which in turn drops its kernfs reference, after kernfs protection is restored.    [ bp: Split the commit messsages into smaller, easier-parseable paragraphs. ]

CVE-2026-93104:

        In the Linux kernel, the following vulnerability has been resolved:  RDMA/rvt: Return NULL after port allocation failure  rvt_alloc_device() deallocates the IB device when its port array cannot be allocated but then returns the pointer to the released allocation. Callers treat any non-NULL value as valid and dereference it, resulting in a use-after-free.  Return NULL immediately after deallocation so callers can propagate the allocation failure.

CVE-2026-93105:

        In the Linux kernel, the following vulnerability has been resolved:  esp: do not unref managed frag pages in esp_ssg_unref()  esp_ssg_unref() releases the page references held on the source scatterlist after the AEAD operation completes.  It calls skb_page_unref() on every frag page for an out-of-place transform (req->src != req->dst), and in the error path of esp_output_tail() (already_unref == true) on the request's own scatterlist.  This is wrong when the skb carries managed frags (SKBFL_MANAGED_FRAG_REFS).  Managed frags are owned by a zerocopy ubuf and the skb does not hold a per-frag page reference; io_uring SEND_ZC with a registered buffer attaches the bvec pages this way via io_sg_from_iter().  The rest of the stack honours this invariant: skb_release_data() skips the per-frag unref when SKBFL_MANAGED_FRAG_REFS is set, and skb_zcopy_managed() is the guard used at the other unref sites.  esp_ssg_unref() is missing that guard, so for a managed-frag skb it drops a page reference the skb never acquired.  This can underflow the page reference count and free a page that is still in use.  Guard the function with skb_zcopy_managed() so both unref paths are skipped for managed-frag skbs, matching skb_release_data().

CVE-2026-93116:

        In the Linux kernel, the following vulnerability has been resolved:  platform/x86: asus-wmi: fix resource leaks on probe failure  During driver initialization in asus_wmi_add(), various subsystems are registered sequentially. However, the error path labels are out of order relative to the registration sequence.  Specifically: 1. If asus_wmi_custom_fan_curve_init() fails, the driver jumps to    fail_custom_fan_curve. Because this label is placed below fail_sysfs,    it bypasses the cleanup calls for the input device and sysfs groups,    which were successfully registered before, leaking those resources. 2. If asus_screenpad_init() fails, the driver jumps to fail_screenpad.    Because fail_screenpad is placed below fail_backlight, it bypasses the    cleanup calls for backlight and rfkill, leaking those resources.  Fix these resource leaks by reordering the error path labels in asus_wmi_add() to match the exact reverse order of the resource allocations.

CVE-2026-93122:

        In the Linux kernel, the following vulnerability has been resolved:  usb: gadget: uac: validate rate list length before storing  UAC1 and UAC2 configfs rate-list attributes parse a comma-separated list of sampling rates and store each parsed value in fixed-size arrays. The arrays have UAC_MAX_RATES entries, but the store paths do not check that the input contains at most that many tokens before writing through opts->name##s[i++].  Writing more than ten rates therefore writes past the end of the p_srates[] or c_srates[] array in struct f_uac1_opts or struct f_uac2_opts.  With CONFIG_UBSAN_BOUNDS enabled, writing an 11-entry rate list to the UAC1 p_srate attribute reports:    UBSAN: array-index-out-of-bounds   drivers/usb/gadget/function/f_uac1.c:1669:1   index 10 is out of range for type 'int [10]'   __ubsan_handle_out_of_bounds.cold   f_uac1_opts_p_srate_store   configfs_write_iter   vfs_write   ksys_write   do_syscall_64  The same reproducer against the UAC2 p_srate attribute reports:    UBSAN: array-index-out-of-bounds   drivers/usb/gadget/function/f_uac2.c:2087:1   index 10 is out of range for type 'int [10]'   __ubsan_handle_out_of_bounds.cold   f_uac2_opts_p_srate_store   configfs_write_iter   vfs_write   ksys_write   do_syscall_64  Reject additional tokens once UAC_MAX_RATES entries have been parsed. Also keep the original kstrdup() pointer for kfree(), because strsep() advances the parsing cursor. Freeing the advanced cursor leaks the original buffer on successful parses and can free an interior pointer on some error paths.

CVE-2026-93125:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: Reject rdonly/rdwr_buf_size kfunc arguments that exceed u32 max  check_kfunc_args() detects a kfunc argument named rdonly_buf_size or rdwr_buf_size and stores reg->var_off.value into meta->r0_size, a u64, and does not bound it. check_kfunc_call() later copies that value into the returned register's mem_size field:    meta->r0_size = reg->var_off.value;   ...   regs[BPF_REG_0].mem_size = meta.r0_size;  regs[BPF_REG_0].mem_size is u32. A constant whose upper 32 bits are set gets truncated instead of causing a load-time rejection, so the verifier records a PTR_TO_MEM register with an approximately 4 GiB mem_size for whatever allocation the kfunc returned. A later access check against that register uses the truncated, wrong bound.  Reject rdonly_buf_size/rdwr_buf_size values that exceed U32_MAX at the point meta->r0_size is set.

CVE-2026-93128:

        In the Linux kernel, the following vulnerability has been resolved:  platform/x86: lg-laptop: Fix LED resource handling  The event notification callback might access kbd_backlight even when it was not successfully registered with the LED subsystem. The same happens inside acpi_remove(), where the LED devices are unregistered unconditionally.  Fix this by tracking the availability of the kbd_backlight LED device and use devm_led_classdev_register() to let devres take care of unregistering the LED devices during removal. For this the parent device of the LED devices is changed to the native platform device.

CVE-2026-93129:

        In the Linux kernel, the following vulnerability has been resolved:  platform/x86: dell-wmi-base: Fix handling of ultra performance key  The commit message of commit 5fbd827eb9c2 ("platform/x86: dell-wmi: Recognise or support new switches") states that the ultra performance key contains additional data after the type and code fields. The event data passed to dell_wmi_process_key() is already parsed, so "buffer" already starts after those two fields.  Use the correct index for accessing the first data field to avoid a potential buffer overread.

CVE-2026-93146:

        In the Linux kernel, the following vulnerability has been resolved:  time/namespace: Validate nanosecond field in proc_timens_set_offset()  The function validates tv_sec to be within [-KTIME_SEC_MAX, KTIME_SEC_MAX] but never validates that tv_nsec is within the valid range of [0, NSEC_PER_SEC-1] before using it in timespec64_add().  timespec64_add() expects both timespec64 structures to have normalized values with tv_nsec in the range [0, 999999999]. If off->val.tv_nsec contains invalid values (negative or >= NSEC_PER_SEC), it could lead to incorrect calculations or unexpected behavior.  Add validation to ensure tv_nsec is within the valid range before performing the addition.

CVE-2026-93150:

        In the Linux kernel, the following vulnerability has been resolved:  cgroup/cpuset: Make nr_deadline_tasks an atomic_t  The nr_deadline_tasks variable in the cpuset structure was introduced by commit 6c24849f5515 ("sched/cpuset: Keep track of SCHED_DEADLINE task in cpusets"). It is reported by sashiko [1] that nr_deadline_tasks can currently be modified by inc_dl_tasks_cs() under rq->lock and by cpuset_attach() under cpuset_mutex. So if both updates happen simultaneously, the nr_deadline_tasks variable can be corrupted leading to incorrect operations down the road.  Fix that by changing its type to atomic_t so that nr_deadline_tasks are always atomically updated. This fix patch is a low hanging fruit. It can handle some of the races between a concurrent sched_setscheduler() and cpuset_can_attach()/cpuset_attach() calls, but not all of them like the other issue raised by sashiko [2]. This will be handled hopefully in a future follow up patch.  [1] https://sashiko.dev/#/patchset/20260626181923.133658-1-longman%40redhat.com [2] https://sashiko.dev/#/patchset/20260630033344.352702-1-longman%40redhat.com

CVE-2026-93154:

        In the Linux kernel, the following vulnerability has been resolved:  RDMA/irdma: Add refcounting to user ring MRs  Prevent userspace from deregistering the MRs that back QP/CQ/SRQ rings by bumping the MR's refcount upon association.

CVE-2026-93155:

        In the Linux kernel, the following vulnerability has been resolved:  crypto: keembay - Fix AEAD unregister count in error path  register_aes_algs() registers the AEAD algorithms before registering the skcipher algorithms.  If skcipher registration fails, the function unwinds the earlier AEAD registration with crypto_engine_unregister_aeads(), but it passes ARRAY_SIZE(algs), which is the skcipher table size.  Use ARRAY_SIZE(algs_aead) for the AEAD unwind path so the unregister helper iterates over the same table that was registered.  Also clarify the nearby comment: the crypto registration helpers clean up algorithms registered within the same call, while this function must still unwind earlier successful registration steps.

CVE-2026-93163:

        In the Linux kernel, the following vulnerability has been resolved:  hwrng: core - fix rng list on registration error  hwrng_register(rng) does the following:  1. Checks if rng has name and read methods set 2. Checks if the name already exists 3. Adds rng to global rng_list 4. May try to set rng to current_rng  If step 4 fails, it returns an error. However, it does not remove the rng from rng_list, causing a dangling reference which can result in use-after-free if the caller frees rng, since registration failed.  Add a list_del_init() cleanup step.

CVE-2026-93168:

        In the Linux kernel, the following vulnerability has been resolved:  dmaengine: xilinx_dma: Fix CPU stall in xilinx_dma_poll_timeout  Currently when calling xilinx_dma_poll_timeout with delay_us=0 and a condition that is never fulfilled, the CPU busy-waits for prolonged time and the timeout triggers only with a massive delay causing a CPU stall.  This happens due to a huge underestimation of wall clock time in poll_timeout_us_atomic. Commit 7349a69cf312 ("iopoll: Do not use timekeeping in read_poll_timeout_atomic()") changed the behavior to no longer use ktime_get at the expense of underestimation of wall clock time which appears to be very large for delay_us=0. Instead of timing out after approximately XILINX_DMA_LOOP_COUNT microseconds, the timeout takes XILINX_DMA_LOOP_COUNT * 1000 * (time that the overhead of the for loop in poll_timeout_us_atomic takes) which is in the range of several minutes for XILINX_DMA_LOOP_COUNT=1000000. Fix this by using a non-zero value for delay_us. Use delay_us=10 to keep the delay in the hot path of starting DMA transfers minimal but still avoid CPU stalls in case of unexpected hardware failures.  One-off measurement with delay_us=0 causes the cpu to busy wait around 7 minutes in the timeout case. After applying this patch with delay_us=10 the measured timeout was 1053428 microseconds which is roughly equivalent to the expected 1000000 microseconds specified in XILINX_DMA_LOOP_COUNT.  Add a constant XILINX_DMA_POLL_DELAY_US for delay_us value.

CVE-2026-93172:

        In the Linux kernel, the following vulnerability has been resolved:  mm/mm_init: handle alloc_percpu failure in free_area_init_core_hotplug  We miss a failed allocation check for pgdat->per_cpu_nodestats, which results in a NULL deref when we offset into the per-cpu area.  Propagate -ENOMEM up the stack and leave per_cpu_nodestats pointing at boot_nodestats so a later online can retry the allocation.  hotadd_init_pgdat() returns NULL on failure, which __try_online_node() already maps to -ENOMEM.  On failure nothing needs to be unwound:   - the node is never marked online   - per_cpu_nodestats is left pointing at boot_nodestats   - __add_memory_resource() cleans up pending memblock resources   - later online attempts retry the per_cpu_nodestats allocation

CVE-2026-93174:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: Copy per-CPU map value padding in copy_map_value_long()  In kernel, per-CPU map elements are stored with round_up(map->value_size, 8) bytes. On UAPI lookup paths, it copies the rounded size for each CPU into a temporary buffer.  However, copy_map_value_long() passes 'map->value_size' to bpf_obj_memcpy(). When the map has special fields, bpf_obj_memcpy() copies around those fields with memcpy(), and does not copy the tail padding between 'map->value_size' and round_up(map->value_size, 8).  The temporary UAPI lookup buffers are allocated without __GFP_ZERO. As a result, when the per-CPU map's value size is not equal to round_up(map->value_size, 8), UAPI LOOKUP_ELEM and its variants can return stale heap contents from that padding to user space. The same issue applies to bpf_iter for per-CPU maps.  Pass round_up(map->value_size, 8) to bpf_obj_memcpy() from copy_map_value_long(), so per-CPU maps both with and without special fields copy the entire per-CPU slot. Remove the now redundant round_up() from bpf_obj_memcpy()'s long_memcpy path.

CVE-2026-93175:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Fix dangling pointer in CRTC reset function  amdgpu_dm_crtc_reset_state() frees the old state before allocating a new one. If kzalloc() fails, the function returns without updating the state pointer, leaving a dangling pointer to already freed memory.  Fix this by allocating the new state first. On allocation failure, the old state remains untouched and the function safely returns.  Found by Linux Verification Center (linuxtesting.org) with SVACE.  [adjust for movement around current amd-staging-drm-next]

CVE-2026-93176:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Fix dangling pointer in plane reset function  amdgpu_dm_plane_drm_plane_reset() frees the old state before allocating a new one. If kzalloc() fails, the function returns without updating the state pointer, leaving a dangling pointer to already freed memory.  Fix this by allocating the new state first. On allocation failure, the old state remains untouched and the function safely returns.  Found by Linux Verification Center (linuxtesting.org) with SVACE.  [adjust for movement around current amd-staging-drm-next]

CVE-2026-93179:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/powerplay: fix VoltageObjectInfo zero-stride loop and OOB read  Reject voltage objects whose usSize is smaller than the header or would advance the cursor past the table end, preventing an infinite loop or heap OOB read when the VBIOS supplies a malformed VoltageObjectInfo table.

CVE-2026-93184:

        In the Linux kernel, the following vulnerability has been resolved:  ASoC: fsl_audmix: rework runtime PM handling in probe  After pm_runtime_enable() the AUDMIX block is powered off and stays suspended until the first runtime resume. Register writes issued between probe() and the first resume (e.g. from DAPM or ALSA control paths) target unpowered hardware and cause a system hang.  Fix this by calling pm_runtime_resume_and_get() immediately after pm_runtime_enable() to power the hardware up and enable its clocks. Release the reference afterwards with pm_runtime_put() to allow the runtime PM framework to suspend the device and switch the regmap to cache-only mode when idle.  When CONFIG_PM is disabled or runtime PM is not enabled, pm_runtime_* calls are stubs that do not power up the hardware. Handle this case explicitly by calling fsl_audmix_runtime_resume() directly so the hardware is always initialised and its clocks are enabled, ensuring register accesses succeed regardless of PM configuration.

CVE-2026-93186:

        In the Linux kernel, the following vulnerability has been resolved:  cxl/mbox: Clamp mailbox output allocation to the payload size  CXL_MEM_SEND_COMMAND bounds the user's in.size to the mailbox payload size but leaves out.size unbounded, then cxl_mbox_cmd_ctor() calls kvzalloc(out.size). A large out.size drives a huge allocation, above INT_MAX it WARNs and taints, and with panic_on_warn=1 it panics.  The transport __cxl_pci_mbox_send_cmd() already clamps the response copy to min(out.size, payload_size, device len), so the output buffer is never written beyond payload_size. Clamp the allocation to payload_size too, matching the RAW path.

CVE-2026-93192:

        In the Linux kernel, the following vulnerability has been resolved:  drm/v3d: Clear queue->active_job when v3d_fence_create() fails  The run_job() callbacks for BIN, RENDER, TFU and CSD assign the incoming job to queue->active_job before calling v3d_fence_create(). If v3d_fence_create() fails, the callback returns NULL without clearing active_job, leaving a dangling pointer.  Create a failure path in all run_job() callbacks that clears the active job before returning NULL. The BIN path takes queue->queue_lock around the clear as it races against v3d_overflow_mem_work(); RENDER, TFU and CSD paths have no concurrent reader, so the clear is lock-free.

CVE-2026-93196:

        In the Linux kernel, the following vulnerability has been resolved:  nvdimm: virtio_pmem: refcount requests for token lifetime  KASAN reports slab-use-after-free in __wake_up_common(): BUG: KASAN: slab-use-after-free in __wake_up_common+0x114/0x160 Read of size 8 at addr ffff88810fdcb710 by task swapper/0/0  CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.19.0-next-20260220-00006-g1eae5f204ec3 #4 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014 Call Trace:  <IRQ>  dump_stack_lvl+0x6d/0xb0  print_report+0x170/0x4e2  ? __pfx__raw_spin_lock_irqsave+0x10/0x10  ? __virt_addr_valid+0x1dc/0x380  kasan_report+0xbc/0xf0  ? __wake_up_common+0x114/0x160  ? __wake_up_common+0x114/0x160  __wake_up_common+0x114/0x160  ? __pfx__raw_spin_lock_irqsave+0x10/0x10  __wake_up+0x36/0x60  virtio_pmem_host_ack+0x11d/0x3b0  ? sched_balance_domains+0x29f/0xb00  ? __pfx_virtio_pmem_host_ack+0x10/0x10  ? _raw_spin_lock_irqsave+0x98/0x100  ? __pfx__raw_spin_lock_irqsave+0x10/0x10  vring_interrupt+0x1c9/0x5e0  ? __pfx_vp_interrupt+0x10/0x10  vp_vring_interrupt+0x87/0x100  ? __pfx_vp_interrupt+0x10/0x10  __handle_irq_event_percpu+0x17f/0x550  ? __pfx__raw_spin_lock+0x10/0x10  handle_irq_event+0xab/0x1c0  handle_fasteoi_irq+0x276/0xae0  __common_interrupt+0x65/0x130  common_interrupt+0x78/0xa0  </IRQ>  virtio_pmem_host_ack() wakes a request that has already been freed by the submitter.  This happens when the request token is still reachable via the virtqueue, but virtio_pmem_flush() returns and frees it.  Fix the token lifetime by refcounting struct virtio_pmem_request. virtio_pmem_flush() holds a submitter reference, and the virtqueue holds an extra reference once the request is queued. The completion path drops the virtqueue reference, and the submitter drops its reference before returning.

CVE-2026-93199:

        In the Linux kernel, the following vulnerability has been resolved:  i3c: master: Do not treat master device as a duplicate target  i3c_master_search_i3c_dev_duplicate() searches the bus for another I3C device with the same PID as the reference device.  The search can match master->this, causing the controller itself to be returned as a duplicate.  Since the controller is not a target device, it cannot be a duplicate of one.  Exclude master->this from matching so that the function only returns real duplicate target devices.

CVE-2026-93200:

        In the Linux kernel, the following vulnerability has been resolved:  i3c: master: Fix use-after-free of master->this  sysfs attribute callbacks for the master controller device dereference master->this.  However, master->this is freed in i3c_master_detach_free_devs() before the master device itself is released.  As a result, sysfs accesses can dereference a freed master->this pointer, leading to a use-after-free.  Keep master->this alive until i3c_masterdev_release(), which is called after the master device and its sysfs state are being torn down. Do not free master->this as part of the normal device detach path.  On the error path in i3c_master_set_info(), reset master->this and bus.cur_master to NULL before freeing the allocated device.

CVE-2026-93202:

        In the Linux kernel, the following vulnerability has been resolved:  i3c: master: Fix recursive locking during device registration  i3c_master_register_new_i3c_devs() registers newly discovered devices while holding i3c_bus_normaluse_lock(), a down_read().  device_register() can immediately probe the device, and probe callbacks typically invoke I3C helpers that take i3c_bus_normaluse_lock() again, leading to a recursive acquisition of the same rwsem.  rwsems do not support recursive read locking and can deadlock when a writer is waiting.  See the "Recursive read locks" section of Documentation/locking/lockdep-design.rst.  For example, with Intel LPSS I3C, LOCKDEP generates a WARNING like:   # echo intel-lpss-i3c.0 > /sys/bus/platform/drivers/mipi-i3c-hci/unbind   # echo intel-lpss-i3c.0 > /sys/bus/platform/drivers/mipi-i3c-hci/bind   WARNING: possible recursive locking detected   kworker/5:1/94 is trying to acquire lock:   ffff88811c810d78 (&i3cbus->lock){++++}-{4:4}, at: i3c_device_match_id+0x45/0x370   but task is already holding lock:   ffff88811c810d78 (&i3cbus->lock){++++}-{4:4}, at: i3c_master_reg_work_fn+0x21/0x5f0  Fix this by separating device creation from device registration. Populate desc->dev under the maintenance lock, collect the devices that still need registration into a local list, then release the lock before calling device_register().  Finally retake the lock and clean up any devices that failed to register.  Use the maintenance lock rather than the normal-use lock while adding device objects.  A write-side maintenance lock prevents readers from observing a partially initialized desc->dev during initial device population, or desc->dev disappearing if registration fails.  The local list requires a list node, so add a list node member to struct i3c_device.

CVE-2026-93205:

        In the Linux kernel, the following vulnerability has been resolved:  iommu/arm-smmu-v3: Manage teardown with devm  arm_smmu_device_remove() manually frees the IOPF queue, destroys the vmid_map and disables the device, while the IRQs and queues are devm managed. devm unwinds only after remove() returns, so the cleanup runs in the wrong order. The IOPF queue is freed before the event-queue IRQ whose handler uses it.  Manage all of it with devm so the unwind order is correct. Free the IOPF queue and vmid_map via devm actions, and disable the device from one registered after arm_smmu_device_reset().  This is also a prerequisite for fixing a Tegra241 CMDQV CMD_SYNC use-after-free in the subsequent patch.

CVE-2026-93208:

        In the Linux kernel, the following vulnerability has been resolved:  kasan: fix cache shrink race with CPU hotplug  kasan_quarantine_remove_cache() first invokes per_cpu_remove_cache() on all online CPUs.  Each callback moves objects belonging to the cache from cpu_quarantine to the CPU's shrink_qlist, where they can later be freed from task context.  kmem_cache_destroy() invokes the quarantine removal path while holding cpus_read_lock(), but kmem_cache_shrink() does not.  The latter can therefore race with CPU offlining as follows:    kmem_cache_shrink()             CPU hotplug   -------------------             -----------   on_each_cpu()     CPU1 moves objects to     CPU1's shrink_qlist   on_each_cpu() returns                                   CPU1 goes offline                                   kasan_cpu_offline()                                     drains cpu_quarantine                                     leaves shrink_qlist untouched   for_each_online_cpu()     skips CPU1  The objects left on CPU1's shrink_qlist are not returned to the slab allocator.  This may prevent kmem_cache_shrink() from releasing slabs that would otherwise become empty.  If CPU1 remains offline, a later kmem_cache_destroy() also skips the list and can report that the cache still contains objects.  An intermittent occurrence was observed with a virtio-9p filesystem.  The mount and umount commands both returned 0, but the kernel logged the following during the userspace-triggered teardown:    [  2994.380134][  T111] BUG 9p-fcall-cache-1 (Tainted: G    B              ): Objects remaining on __kmem_cache_shutdown()   [  2994.381140][  T111] Object 0xff11000004361118 @offset=4376   [  2994.381607][  T111] Allocated in p9_fcall_init+0x201/0x400 age=19564 cpu=1 pid=104   [  2994.382591][  T111]  p9_fcall_init+0x201/0x400   [  2994.382810][  T111]  p9_tag_alloc+0x12f/0x700   [  2994.382982][  T111]  p9_client_prepare_req+0x102/0x3e0   [  2994.383165][  T111]  p9_client_rpc+0x1ab/0xa50   [  2994.383334][  T111]  p9_client_getattr_dotl+0xb0/0x1a0   [  2994.383515][  T111]  v9fs_vfs_getattr_dotl+0x115/0x360   [  2994.383719][  T111]  vfs_getattr_nosec+0x22c/0x3a0   [  2994.383910][  T111]  vfs_statx+0xd7/0x170   [  2994.384062][  T111]  vfs_fstatat+0x45/0x80   [  2994.384215][  T111]  __do_sys_newfstatat+0x84/0xe0   [  2994.384386][  T111]  do_syscall_64+0x115/0x6a0   [  2994.384566][  T111]  entry_SYSCALL_64_after_hwframe+0x77/0x7f   [  2994.399720][  T111] WARNING: mm/slub.c:1244 at __kmem_cache_shutdown+0x363/0x500, CPU#0: busybox/111   [  2994.405655][  T111] Call Trace:   [  2994.406325][  T111]  kmem_cache_destroy+0x73/0x1b0   [  2994.406630][  T111]  p9_client_destroy+0x271/0x3c0   [  2994.407210][  T111]  v9fs_session_close+0x3c/0x260   [  2994.407409][  T111]  v9fs_kill_super+0x48/0x90   [  2994.407584][  T111]  deactivate_locked_super+0xa3/0x160   [  2994.407778][  T111]  cleanup_mnt+0x1dd/0x3e0  Thus, a successful umount left objects in the 9p fcall cache and prevented the cache from being destroyed cleanly.  Per-CPU shrink_qlist storage exists for every possible CPU, and each list is protected by its own raw spinlock.  Iterate over possible CPUs so that a list populated before its CPU went offline is drained as well.  for_each_possible_cpu() can do more work than for_each_online_cpu(), but this change only affects CONFIG_KASAN_GENERIC kernels.  The extra work is limited to cache shrink and cache destruction paths and does not affect the normal allocation/free fast path.  It adds one raw-spinlock-protected scan of each possible CPU's shrink list.  These lists are normally empty; a non-empty list is traversed to remove objects belonging to the cache being shrunk or destroyed.

CVE-2026-93216:

        In the Linux kernel, the following vulnerability has been resolved:  mm/page_owner: use memcg_data snapshot to avoid TOCTOU in print_page_owner_memcg()  print_page_owner_memcg() reads page->memcg_data via READ_ONCE() at the start to guard against tail pages and NULL data.  However, it later re-reads page->memcg_data locklessly in two places:  1: page_memcg_check(page)  2: PageMemcgKmem(page) (via folio_memcg_kmem(), which includes    VM_BUG_ON assertions for tail pages and MEMCG_DATA_OBJEXTS)  If the page is concurrently freed and reallocated as a THP tail page or slab page between these calls, the VM_BUG_ON assertions can trigger on CONFIG_DEBUG_VM=y builds, crashing the kernel.  Fix both TOCTOU issues by using the memcg_data snapshot throughout.

CVE-2026-93221:

        In the Linux kernel, the following vulnerability has been resolved:  nfsd: convert nfsd_net boolean flags to unsigned long flags word  nfsd_net contains several boolean fields that are accessed from concurrent contexts without serialization.  In particular, nfsd4_end_grace() guards its drain path with a plain bool:      if (nn->grace_ended)             return;     nn->grace_ended = true;  The read and the write are independent, and nothing in struct nfsd_net serializes them.  At least two contexts can reach this code with no lock held:      laundromat path       laundry_wq kworker         nfs4_laundromat()           nfsd4_end_grace()      RECLAIM_COMPLETE path       nfsd compound kthread         nfsd4_reclaim_complete()           inc_reclaim_complete()             nfsd4_end_grace()  Both callers can observe grace_ended == false on different CPUs, both store true, and both proceed into nfsd4_record_grace_done(), which invokes the active client_tracking_ops->grace_done callback. For tracking ops that drain reclaim_str_hashtbl (legacy_tracking_ops via nfsd4_recdir_purge_old, and the cld v1+ ops via nfsd4_cld_grace_done), grace_done calls nfs4_release_reclaim(), which walks every bucket of reclaim_str_hashtbl with no lock and calls nfs4_remove_reclaim_record() (list_del + kfree) on each entry.  Two concurrent walkers corrupt the list and double-free every nfs4_client_reclaim.  A concurrent nfsd4_find_reclaim_client() iterating the same bucket reads through freed memory.  A third call site exists in nfs4_state_start_net() on the skip_grace startup path, but it runs under nfsd_mutex before any client has connected and before the laundromat's first delayed work fires, so it cannot race with the two callers above.  Replace the scattered boolean fields in nfsd_net with a single unsigned long flags word and an enum nfsd_net_flag for the bit positions.  The grace_ended race is fixed by using test_and_set_bit(), which is atomic on all architectures.  The remaining flags (grace_end_forced, in_grace, somebody_reclaimed, track_reclaim_completes, nfsd_net_up, lockd_up) are converted to use test_bit/set_bit/clear_bit for consistency.  This avoids sub-word cmpxchg issues on architectures like Hexagon that only support word-sized atomic operations.

CVE-2026-93228:

        In the Linux kernel, the following vulnerability has been resolved:  svcrdma: Reject Write/Reply chunks with segcount 0  A peer can send a Write or Reply chunk whose segcount field is zero. xdr_check_write_chunk() only rejects segcount > rc_maxpages, so zero passes the range check, and xdr_inline_decode(stream, 0) returns the current (non-NULL) cursor without advancing. The function returns true and pcl_alloc_write() then links a struct svc_rdma_chunk with ch_segcount == 0 onto rc_write_pcl or rc_reply_pcl.  An earlier patch in this series made pcl_for_each_segment() safe for ch_segcount == 0, so this no longer drives the memory walk it used to. Rejecting the malformed frame at the decode boundary is still worthwhile as defense in depth: it keeps degenerate zero-segment chunks off the parsed chunk lists entirely, so any future consumer that walks ch_segments directly cannot observe one, and it makes the zero-floor easy to backport to trees where the macro change is more intrusive. RFC 8166 has no meaning for a Write/Reply chunk that describes no remote buffer, so no legitimate client is affected.  xdr_check_reply_chunk() funnels Reply chunks through xdr_check_write_chunk() and inherits the same rejection.  pcl_alloc_write() also links each chunk onto the parsed chunk list before filling its segment array. If a future change weakens the segcount-0 rejection, an incomplete chunk is visible to consumers during the fill loop. Reorder so that list_add_tail() follows the segment fill loop, ensuring only fully-populated chunks appear on the list.

CVE-2026-93231:

        In the Linux kernel, the following vulnerability has been resolved:  lockd: fix swapped arguments in nlmsvc_match_ip()  When releasing locks by server IP address via /proc/fs/nfsd/unlock_ip, nlmsvc_unlock_all_by_ip() calls nlm_traverse_files() with the server sockaddr as the opaque @data argument:  	nlm_traverse_files(server_addr, nlmsvc_match_ip, NULL);  The match callback is later invoked from nlm_traverse_locks() as:  	match(lockhost, host);  where the first argument is the nlm_host that owns the lock, and the second argument is the @data that was originally passed down (here the server sockaddr).  This is the convention every other match callback relies on (nlmsvc_mark_host(), nlmsvc_same_host(), nlmsvc_is_client()): arg1 is the real nlm_host, arg2 is the caller-supplied reference value.  nlmsvc_match_ip() has had these two arguments reversed ever since the unlock-by-IP feature was introduced in commit 4373ea84c84d ("lockd: unlock lockd locks associated with a given server ip"):  	return rpc_cmp_addr(nlm_srcaddr(host), datap);  Here @host is actually the server sockaddr, so nlm_srcaddr(host) dereferences a struct sockaddr as a struct nlm_host and reads garbage at the offset of h_srcaddr; meanwhile @datap is actually the lock owner's nlm_host but is compared as a sockaddr.  As a result the comparison practically never matches and locks are not released for the requested IP.  Swap the arguments so the lock owner's source address is compared against the requested server address:  	return rpc_cmp_addr(nlm_srcaddr(datap), (struct sockaddr *)host);  [ cel: fix the misleading typedef parameter names too ]

CVE-2026-93235:

        In the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to zero post-EOF data when extending file size  generic/794  4s ... - output mismatch (see /share/git/fstests/results//generic/794.out.bad)     --- tests/generic/794.out   2026-06-12 08:46:32.766426241 +0800     +++ /share/git/fstests/results//generic/794.out.bad 2026-07-05 18:32:55.000000000 +0800     @@ -1,4 +1,16 @@      QA output created by 794      append_write     +FAIL: non-zero data in gap [4080,4096) after shutdown+remount     +000000 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a  >ZZZZZZZZZZZZZZZZ<     +*     +001000      truncate_up     ...     (Run 'diff -u /share/git/fstests/tests/generic/794.out /share/git/fstests/results//generic/794.out.bad'  to see the entire diff) Ran: generic/794 Failures: generic/794 Failed 1 of 1 tests  Steps of generic/794: 1. write 4096 bytes to file w/ 0x5a 2. use fiemap to get PBA of first block in file 3. truncate file to 4080 4. umount; write 4096 bytes to file w/ 0x5a directly via PBA; mount 5. extend filesize via    a) append 4096 from offset 4096, or    b) truncate 8192, or    c) fallocate 4096 from offset 4096 6. verify the gap is zeroed in memory [4080,4096) 7. sync range 4096 from offset 4096; shutdown -f (flush meta before shutdown) 8. umount; mount; verify [4080,4096) is zeroed or not.  When extending file size (e.g. via truncate, fallocate, or write) across an unaligned EOF boundary, we need to ensure that post-EOF data in the partial page is zeroed out in pagecache and marked dirty, then writeback the cache to persist zeroed data before committing inode w/ updated i_size.  This help to prevent stale disk data beyond the previous EOF from being exposed after remounting or crash recovery.  Since f2fs is a LFS filesystem, we only support direct write via PBA in pinfile, and pinfile has section-aligned filesize, so in Android, there should no problem, but for other usage in different environment, let's fix this w/ fsync_mode=strict mount option.

CVE-2026-93238:

        In the Linux kernel, the following vulnerability has been resolved:  s390/vfio-ap: fix potential use of uninitialized apm_filtered bitmap  The DECLARE_BITMAP(apm_filtered, AP_DEVICES) macro allocates the bitmap on the stack without zero-initializing it.  In vfio_ap_mdev_hot_plug_cfg(), the vfio_ap_mdev_filter_matrix() function is only called to initialize and populate apm_filtered if either filter_adapters or filter_domains is true. If the hot plug configuration change only adds control domains (meaning filter_cdoms is true, but filter_adapters and filter_domains are both false), vfio_ap_mdev_filter_matrix() is bypassed.  Consequently, apm_filtered is passed to reset_queues_for_apids() with uninitialized stack garbage. This can cause reset_queues_for_apids() to interpret arbitrary stack garbage bits as valid APIDs to reset, potentially performing unintended guest hardware queue resets.  Fix this by zero-initializing the apm_filtered bitmap at the beginning of vfio_ap_mdev_hot_plug_cfg() using bitmap_zero().

CVE-2026-93239:

        In the Linux kernel, the following vulnerability has been resolved:  arm64: mm: Fix the lockless page-table walk in show_pte()  show_pte() walks page tables locklessly and can run with interrupts enabled. A concurrent teardown can free a table page while it is being walked. It can also clear a parent entry after show_pte() checked it; the regular pXd_offset() helpers then reread the cleared entry and can derive a bogus lower-level pointer and fault again.  Use the lockless offset helpers with the saved parent entries, as gup_fast() does, and pass the saved PMD to pte_offset_map().  For task page tables, arm64 selects MMU_GATHER_RCU_TABLE_FREE. Disable local interrupts around the walk to hold off RCU-deferred table frees and block the tlb_remove_table_sync_one() IPI until the walk is finished.  Place the IRQ guard after the header print. This does not make the output a consistent snapshot, but prevents the task page-table walk from dereferencing a released table page or deriving a pointer from a different parent value.

CVE-2026-93243:

        In the Linux kernel, the following vulnerability has been resolved:  mm/secretmem: properly account locked pages  secretmem accounts folios by treating memory as if it were mlock()'d and thus limited by the RLIMIT_MEMLOCK limit.  However the folios are unevictable and remain so until the inode is evicted, eliminating usual mlock() semantics - mapping folios then unmapping them does not clear their unevictable state, since it depends on AS_UNEVICTABLE, not PG_mlocked.  A user can therefore easily work around the RLIMIT_MEMLOCK limit - simply map then unmap and VmLck no longer counts the secretmem range.  Worse, folios are not accounted in the process's RSS, meaning the OOM killer won't know to kill the process.  Repeatedly mapping/unmapping (or forking) can then result in the consumption of all available system memory with unevictable folios and cause system instability.  A secretmem fd can be passed between processes and over fork so a per-process limit simply does not make sense, so follow the precedent set by io_uring, perf, skbuff, iommufd and xdp by tracking the number of locked pages in user_struct->locked_vm.  Since the scope tracked is actually inode lifetime, the RLIMIT_MEMLOCK applies per-user not per-process, so it doesn't make sense to bypass for users with CAP_IPC_LOCK, therefore remove this bypass.  There is simply no reason to carry on marking the mapping as mlock()'d since it's misleading and the lifecycle is now correctly handled, so remove this too.  Note that secretmem does not support any form of truncation (including hole punching) and the folios are unreclaimable, so the folios need only be accounted on fault and unaccounted on inode destruction.  __secretmem_account_pages() is more or less a duplicate of the code that io_uring etc.  use, but since this is a bug fix that needs backporting, defer any de-duplication efforts to a follow-up.  test_mlock_limit() asserts mlock_future_ok() on mmap(), however this has been removed, so remove the test altogether for the fix.  A new test will be sent separately for upstream.

CVE-2026-93244:

        In the Linux kernel, the following vulnerability has been resolved:  drm/sysfb: simpledrm: Improve stride validation  Validate the computed stride against the maximum value INT_MAX.

CVE-2026-93251:

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

CVE-2026-93260:

        In the Linux kernel, the following vulnerability has been resolved:  powerpc/xive: propagate IPI init errors to prevent use-after-free  When xive_init_ipis() fails (e.g. irq_domain_alloc_irqs() fails), the error path frees the global xive_ipis array.  However, xive_smp_probe() previously ignored this failure and proceeded to call xive_setup_cpu_ipi(), which dereferences the already-freed xive_ipis pointer -- a use-after-free.  Now that xive_smp_probe() returns int (previous patch), propagate the error from xive_init_ipis() and xive_setup_cpu_ipi() through xive_smp_probe().  Check the return value in both pnv_smp_probe() and pSeries_smp_probe() so that IPI setup is aborted cleanly on failure, avoiding the use-after-free.

CVE-2026-93269:

        In the Linux kernel, the following vulnerability has been resolved:  ext4: fix circular lock dependency in ext4_ext_migrate  Move iput(tmp_inode) after ext4_writepages_up_write() to avoid a circular lock dependency between s_writepages_rwsem and sb_internal (freeze protection).  The deadlock scenario:    CPU0 (EXT4_IOC_MIGRATE)        CPU1 (orphan cleanup during mount)   ----                           ----   ext4_ext_migrate()     ext4_writepages_down_write()       s_writepages_rwsem (write)                                  ext4_evict_inode()                                    sb_start_intwrite()   [sb_internal]                                    ...                                      ext4_writepages()                                        s_writepages_rwsem (read) [BLOCKED]     iput(tmp_inode)       ext4_evict_inode()         sb_start_intwrite()         [BLOCKED]  The tmp_inode is a temporary inode with nlink=0 created solely for building the extent tree.  Its eviction does not require s_writepages_rwsem protection, so deferring iput() until after releasing the rwsem is safe.

CVE-2026-93272:

        In the Linux kernel, the following vulnerability has been resolved:  remoteproc: qcom_wcnss: Fix handling the lack of PD regulators in v3  The changes introduced to handle single power domain platforms have swapped the info pointer increment from num_pd_vregs to num_pds, which would shift the info pointer past the end of the array for pronto-v3, which does not list power domain regulators in vregs.  This showed up as a difference between GCC- and LLVM-compiled kernels on SDM632 devices, where only with LLVM one would get the "regulator request with no identifier" error, because the out-of-bounds memory ended up being zeroed. Fix by skipping the increment when there are more power domains than regulators.

CVE-2026-93282:

        In the Linux kernel, the following vulnerability has been resolved:  ksmbd: fix maximum allowed access checks  The DACL permission check looks for an ACE matching the current user and falls back to the Everyone ACE. It does not consider an Authenticated Users ACE, even though an authenticated session is a member of that well-known group.  As a result, opening a file whose access is granted through S-1-5-11 can incorrectly fail with STATUS_ACCESS_DENIED. Treat an Authenticated Users ACE as a fallback entry alongside Everyone.  The maximal access calculation also combines access masks from every ACE, regardless of whether its SID applies to the current user. This can grant rights belonging to an unrelated principal. Process only ACEs applying to the user, Everyone, or Authenticated Users, and accumulate allowed and denied masks in ACL order. Preserve explicitly requested access bits so they are validated against the resulting maximal mask.  When ACCESS_SYSTEM_SECURITY is denied, report STATUS_PRIVILEGE_NOT_HELD instead of the generic STATUS_ACCESS_DENIED. Access to the system ACL requires a security privilege that ksmbd does not grant.  For regular files, include FILE_EXECUTE in maximal access when the client requested GENERIC_EXECUTE and the DACL grants the complete file-read set. Keep a direct FILE_EXECUTE request subject to the explicit DACL bit. This matches the POSIX file ACL mapping without broadening specific execute requests.  Do not replace rights from an applicable NT ACE with a POSIX ACL entry. The POSIX ACL is only a fallback when no user, Everyone, or Authenticated Users ACE applies; otherwise it can incorrectly broaden the stored DACL.  This fixes smb2.maximum_allowed.maximum_allowed.

CVE-2026-93285:

        In the Linux kernel, the following vulnerability has been resolved:  f2fs: embed f2fs_gc_kthread in f2fs_sb_info  Instead of allocating f2fs_gc_kthread dynamically, embed it in f2fs_sb_info. This simplifies lifetime management and prepares for fixing race conditions during teardown.  - __sbi_store			- remount|shutdown 				 - f2fs_stop_gc_thread  - access sbi->gc_thread 				  - sbi->gc_thread = NULL  - access sbi->gc_thread->f2fs_gc_task

CVE-2026-93786:

        In the Linux kernel, the following vulnerability has been resolved:  ksmbd: preserve VFS inherited POSIX ACL mask  The VFS initializes a child's POSIX ACL from the parent's default ACL and the requested creation mode. Do not mutate the parent ACL or overwrite the child's VFS-computed access and default ACLs afterwards.  This preserves restrictive ACL_MASK entries and prevents SMB object creation from widening effective permissions.

CVE-2026-93790:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: iwlwifi: mvm: fix out-of-bounds tid_data access in BA notif  mvmsta->tid_data was indexed by the TFD loop counter 'i' instead of the actual TID value 'tid'. This writes lq_color into a random tid_data slot unrelated to the BA entry. Since multi-TID blockack is not really in use, 'i' was always 0 and no harm was done. Add a out-of-bound check before accessing the array.

CVE-2026-93791:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: iwlwifi: mvm: add a check on the tid coming from the firmware  ba_notif->tid is a firmware-controlled u8 that is used directly as an array index into tid_data[] without any validation. Add a bounds check against IWL_MAX_TID_COUNT before dereferencing the array.

CVE-2026-93792:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: iwlwifi: mvm: fix a possible underflow  We shouldn't trust the firmware about the length of the wowlan packet.

CVE-2026-93793:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: iwlwifi: mvm: validate TX_CMD response layout  TX_CMD parsing uses frame_count to walk status entries and then read the trailing SCD SSN. Make the minimum-length check follow that exact runtime layout calculation before parsing the payload.  For new TX API, reject TX_CMD responses with frame_count != 1 and warn/return in the aggregation handler to document that aggregated accounting is expected via BA notifications.

CVE-2026-93794:

        In the Linux kernel, the following vulnerability has been resolved:  smb/client: flush dirty data before punching a hole  Punching a hole after a large buffered write may leave the range reported as data. Reproduce it with:    xfs_io -f \     -c "pwrite -b 3m -S 0x61 0 3m" \     -c "fpunch 1m 1m" \     -c "seek -h 0" \     -c "seek -d 1m" \     /mnt/test/repro  Punching 1 MiB at offset 1 MiB should produce:    0          1 MiB       2 MiB       3 MiB   |  DATA    |   HOLE    |   DATA    | EOF  Instead, the entire file is reported as data. SEEK_HOLE(0) returns EOF, and SEEK_DATA(1M) returns 1M.  This happens because a dirty folio spanning the punched range can be written back after the punch and refill the hole.  Fix this by flushing and waiting for dirty data in the punched range before invalidating the page cache and issuing FSCTL_SET_ZERO_DATA.  The xfstests generic/539 pass against Samba/ksmbd with this change.

CVE-2026-93796:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: iwlwifi: pcie: null RX pointers after free  When iwl_pcie_tx_init() fails after RX init, nic init unwinds via iwl_pcie_rx_free().  The freed RX members stayed non-NULL on the live transport object, so later teardown or retry could touch stale RX state. Set rx_pool, global_table, rxq, and alloc_page to NULL after free to make repeated cleanup and retry paths safe.

CVE-2026-93799:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: iwlwifi: mvm: validate sta_id in BA window status notif  BA_WINDOW_STATUS_NOTIFICATION_ID extracts a 5-bit sta_id from the firmware notification and uses it to index fw_id_to_mac_id[] without bounds checking. Validate sta_id before array access to prevent out-of-bounds indexing.

CVE-2026-93804:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: mac80211: ibss: wait for in-flight TX on disconnect  While leaving an IBSS in ieee80211_ibss_disconnect() mac80211 flushes stations, turns the carrier off and immediately tells the driver to leave as well. While there may be synchronize_net() in station flush and in this code later, packets can still be transmitted due to cross-CPU race conditions after carrier off is set. Therefore, it's possible for a race to happen where a TX to the driver occurs while or after telling it to leave the IBSS. This can be confusing to drivers, and in the case of iwlwifi leads to an attempt to use invalid queues.  Move netif_carrier_off() to occur before sta_info_flush() during IBSS disconnect, and add synchronize_net() if flushing didn't, so that the synchronize_net() always happens between turning the carrier off and telling the driver, avoiding this race.

CVE-2026-93817:

        In the Linux kernel, the following vulnerability has been resolved:  perf: Fix addr_filter_ranges lifetime  Lee Jia Jie reported that since event::addr_filter_ranges is used under RCU, it should be RCU freed.

CVE-2026-93823:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdkfd: Let driver decide buffer size at AMDKFD_IOC_GET_DMABUF_INFO ioctl  amdkfd driver needs allocate buffer to return bo metadata to user space. The buffer size is controlled by user currently. It is a potential security issue that hostile value (e.g. 2 GiB) lets any render-group user trigger order-MAX allocation/OOM in kernel context.  This patch first finds bo metadata size. If the size is smaller than user provided value drive can safely allocate buffer in kernel space and copy to user space buffer. If not, driver will let user know, not allocate and copy. User will redo with new buffer in user space.  This patch lets driver decide buffer allocation size to avoid potential hostile size from user space.  (cherry picked from commit f54ce9e8cbd3abe0eda3a285f54dc4f572fe589a)

CVE-2026-93828:

        In the Linux kernel, the following vulnerability has been resolved:  exfat: fix handling of damaged volume in exfat_create_upcase_table()  When the size of the upcase table is set to zero in the dentry for any reason(e.g. corrupted media or misbehaving device), an integer overflow causes the module to loop indefinitely.  If the size of the upcase table is read zero, do not attempt to load the table. Instead, fallback to loading the default upcase table. If the size of the upcase table is zero or no upcase table is found, raise exfat_fs_error() to mark the volume read-only.

CVE-2026-93829:

        In the Linux kernel, the following vulnerability has been resolved:  smb: client: fix races in cifsd thread creation  The cifsd demultiplex thread can run and access tcp_ses before the parent thread has finished populating tcp_ses, which the worker thread accesses locklessly.  Also, the kthread_run macro may start the thread before returning the thread pointer. Because the pointer is part of the structure that the thread can access, if the kernel is preempted after the thread is spawned, but before the thread pointer is populated and the thread attempts to exit, it will sleep, waiting for a SIGKILL signal.  Fix this by moving creation of the thread to after all of tcp_ses'es fields are populated, and spawning the thread last, using a split kthread_create/wake_up_process logic.

CVE-2026-97409:

        In the Linux kernel, the following vulnerability has been resolved:  nvme-fc: Do not cancel requests in io target before it is initialized  A new nvme-fc controller in CONNECTING state sees admin request timeout schedules ctrl->ioerr_work to abort inflight requests. This ends up calling __nvme_fc_abort_outstanding_ios() which aborts requests in both admin and io tagsets. In case fc_ctrl->tag_set was not initialized we see the warning below. This is because ctrl.queue_count is initialized early in nvme_fc_alloc_ctrl().  nvme nvme0: NVME-FC{0}: starting error recovery Connectivity Loss INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe lpfc 0000:ab:00.0: queue 0 connect admin queue failed (-6). you didn't initialize this object before use? turning off the locking correctness validator. Workqueue: nvme-reset-wq nvme_fc_ctrl_ioerr_work [nvme_fc] Call Trace:  <TASK>  dump_stack_lvl+0x57/0x80  register_lock_class+0x567/0x580  __lock_acquire+0x330/0xb90  lock_acquire.part.0+0xad/0x210  blk_mq_tagset_busy_iter+0xf9/0xc00  __nvme_fc_abort_outstanding_ios+0x23f/0x320 [nvme_fc]  nvme_fc_ctrl_ioerr_work+0x172/0x210 [nvme_fc]  process_one_work+0x82c/0x1450  worker_thread+0x5ee/0xfd0  kthread+0x3a0/0x750  ret_from_fork+0x439/0x670  ret_from_fork_asm+0x1a/0x30  </TASK>  Update the check in __nvme_fc_abort_outstanding_ios() confirm that io tagset was created before iterating over busy requests. Also make sure to cancel ctrl->ioerr_work before removing io tagset.

CVE-2026-97422:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdkfd: fix SMI event cross-process information leak  kfd_smi_ev_enabled() skips the suser privilege check when pid=0. PROCESS_START, PROCESS_END, and VMFAULT events are emitted with pid=0 while carrying another process's PID and command name, so any /dev/kfd user in the render group can monitor all GPU workloads.  Pass the target process PID into kfd_smi_event_add() for these events so the existing per-client filter restricts delivery to the owning process or CAP_SYS_ADMIN subscribers.

CVE-2026-97424:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu/ras: add ras_suspend callback and use it for cp_ecc_error_irq  cp_ecc_error_irq is acquired in amdgpu_gfx_ras_late_init() but released in gfx_v9_0_hw_fini(), so the put site has to query amdgpu_irq_enabled() because the get is skipped on SR-IOV VF.  ras_late_init / ras_fini have no suspend counterpart, so move the put to amdgpu_gfx_ras_suspend() / amdgpu_gfx_ras_fini() and add a matching ras_suspend callback that is invoked from amdgpu_ras_suspend() before disable_all_features().  The get and put now sit in the same place and check the same condition (not VF, funcs registered), no refcount querying needed.  An active flag gates ras_fini so the suspend-then-unload-without-resume path falls into amdgpu_ras_block_late_fini_default() instead of double-releasing what ras_suspend already cleaned up.  Drop the cp_ecc_error_irq put from gfx_v9_0_hw_fini().  gfx_v8_0 manages cp_ecc_error_irq locally and is unaffected; no other GFX generation has this IRQ.

CVE-2026-97425:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu: fix buffer overflow during vBIOS update  Clamp the buffer postion to write by setting the bin attribute to the maximum buffer size so that VFS layer will block the out-of-bounds accessing.

CVE-2026-97477:

        In the Linux kernel, the following vulnerability has been resolved:  RDMA/counter: Fix num_counters leak on bind_qp failure in alloc_and_bind()  When __rdma_counter_bind_qp() fails in alloc_and_bind(), the error path jumps to err_mode which frees the counter without decrementing port_counter->num_counters. The only place that decrements is rdma_counter_free(), which is unreachable since the counter was never successfully bound.  This leak accumulates across repeated failures, permanently preventing the port from switching to AUTO mode (-EBUSY in __counter_set_mode()) and blocking the MANUAL→NONE auto-revert in rdma_counter_free(). When the mode was NONE before the call, the MANUAL mode set by __counter_set_mode() also leaks since the revert logic is never reached.  Add an err_bind label between the num_counters increment and the existing err_mode label. It decrements num_counters and mirrors the MANUAL→NONE revert from rdma_counter_free(), ensuring the port state is fully restored on bind failure.

CVE-2026-97478:

        In the Linux kernel, the following vulnerability has been resolved:  virt: acrn: Fix irqfd use-after-free during eventfd shutdown  acrn_irqfd_deassign() and the eventfd EPOLLHUP wakeup can race and free the same struct hsm_irqfd:    CPU0                                 CPU1   ----                                 ----   eventfd_release()     wake_up_poll(EPOLLHUP)       hsm_irqfd_wakeup()         queue_work(&irqfd->shutdown)                                        acrn_irqfd_deassign()                                          hsm_irqfd_shutdown()                                            list_del_init()                                            eventfd_ctx_remove_wait_queue()                                            eventfd_ctx_put()                                          kfree(irqfd)   hsm_irqfd_shutdown_work()     container_of(work, ..., shutdown)     irqfd->vm                  <-- use-after-free  The deassign path freed the irqfd while a shutdown work item was already queued by EPOLLHUP (or vice versa), so the work item could resurrect a dangling pointer through container_of().  Switch to the lifetime model used by KVM irqfds:   - Deassign/deinit only deactivate the irqfd: remove it from vm->irqfds    under irqfds_lock and queue the cleanup work.  - hsm_irqfd_shutdown_work() becomes the sole owner that unhooks the    eventfd waitqueue entry, drops the eventfd reference and frees the    irqfd.  - A new HSM_IRQFD_FLAG_SHUTDOWN bit guarded by test_and_set_bit()    ensures the cleanup work is queued at most once, no matter how many    of {EPOLLHUP, deassign, deinit} fire concurrently.  This is safe to    call from the waitqueue callback, which runs with wqh->lock held and    IRQs disabled and therefore cannot take irqfds_lock.  - acrn_irqfd_deassign() flushes vm->irqfd_wq before returning so the    eventfd is fully detached on return.  acrn_irqfd_deinit() deactivates    every irqfd, flushes the workqueue and only then destroys it, so no    path can queue_work() onto a torn-down workqueue.  - acrn_irqfd_assign() now installs the eventfd waitqueue entry and    publishes the irqfd to vm->irqfds under irqfds_lock, so the irqfd is    never visible to deassign/deinit before its waitqueue entry is in    place, and any EPOLLHUP that fires in the assign window queues    cleanup work that blocks on irqfds_lock until publication is done.

CVE-2026-97479:

        In the Linux kernel, the following vulnerability has been resolved:  driver core: Avoid warning when removing a device while its supplier is unbinding  During driver removal, the following warning can appear:    WARNING: CPU: 1 PID: 139 at drivers/base/core.c:1497 __device_links_no_driver+0xcc/0xfc    ...    Call trace:      __device_links_no_driver+0xcc/0xfc (P)      device_links_driver_cleanup+0xa8/0xf0      device_release_driver_internal+0x208/0x23c      device_links_unbind_consumers+0xe0/0x108      device_release_driver_internal+0xec/0x23c      device_links_unbind_consumers+0xe0/0x108      device_release_driver_internal+0xec/0x23c      device_links_unbind_consumers+0xe0/0x108      device_release_driver_internal+0xec/0x23c      driver_detach+0xa0/0x12c      bus_remove_driver+0x6c/0xbc      driver_unregister+0x30/0x60      pci_unregister_driver+0x20/0x9c      lan966x_pci_driver_exit+0x18/0xa90 [lan966x_pci]  This warning is triggered when a consumer is removed because the links status of its supplier is not DL_DEV_DRIVER_BOUND and the link flag DL_FLAG_SYNC_STATE_ONLY is not set.  The topology in terms of consumers/suppliers used was the following (consumer ---> supplier):        i2c -----------> OIC ----> PCI device        |                ^        |                |        +---> pinctrl ---+  When the PCI device is removed, the OIC (interrupt controller) has to be removed. In order to remove the OIC, pinctrl and i2c need to be removed and to remove pinctrl, i2c need to be removed. The removal order is:   1) i2c   2) pinctrl   3) OIC   4) PCI device  In details, the removal sequence is the following (with 0000:01:00.0 the PCI device):   driver_detach: call device_release_driver_internal(0000:01:00.0)...     device_links_busy(0000:01:00.0):       links->status = DL_DEV_UNBINDING     device_links_unbind_consumers(0000:01:00.0):       0000:01:00.0--oic link->status = DL_STATE_SUPPLIER_UNBIND       call device_release_driver_internal(oic)...         device_links_busy(oic):           links->status = DL_DEV_UNBINDING         device_links_unbind_consumers(oic):           oic--pinctrl link->status = DL_STATE_SUPPLIER_UNBIND           call device_release_driver_internal(pinctrl)...             device_links_busy(pinctrl):               links->status = DL_DEV_UNBINDING             device_links_unbind_consumers(pinctrl):               pinctrl--i2c link->status = DL_STATE_SUPPLIER_UNBIND               call device_release_driver_internal(i2c)...                 device_links_busy(i2c): links->status = DL_DEV_UNBINDING                 __device_links_no_driver(i2c)...                   pinctrl--i2c link->status is DL_STATE_SUPPLIER_UNBIND                   oic--i2c link->status is DL_STATE_ACTIVE                   oic--i2c link->supplier->links.status is DL_DEV_UNBINDING  The warning is triggered by the i2c removal because the OIC (supplier) links status is not DL_DEV_DRIVER_BOUND. Its links status is indeed set to DL_DEV_UNBINDING.  It is perfectly legit to have the links status set to DL_DEV_UNBINDING in that case. Indeed we had started to unbind the OIC which triggered the consumer unbinding and didn't finish yet when the i2c is unbound.  Avoid the warning when the supplier links status is set to DL_DEV_UNBINDING and thus support this removal sequence without any warnings.

CVE-2026-97480:

        In the Linux kernel, the following vulnerability has been resolved:  tty: serial: 8250: protect against NULL uart->port.dev in register  serial8250_register_8250_port() conditionally copies uart->port.dev from up->port.dev only when up->port.dev is non-NULL:  	if (up->port.dev) { 		uart->port.dev = up->port.dev; 		... 	}  So if both the existing uart slot and up have a NULL ->dev, uart->port.dev remains NULL. The very next ACPI companion check then dereferences it unconditionally:  	if (!has_acpi_companion(uart->port.dev)) {  has_acpi_companion() reads dev->fwnode without a NULL guard (include/linux/acpi.h), so this NULL-derefs the kernel for the remaining no-dev case rather than just skipping the mctrl_gpio_init() initialisation as intended.  smatch flags the inconsistency:    drivers/tty/serial/8250/8250_core.c:767   serial8250_register_8250_port() error: 'uart->port.dev' could be   null (see line 719)  Guard the call with a NULL check so register continues to work for callers that legitimately have no parent device (legacy non-OF/non-ACPI registrations).  No functional change for callers that pass a non-NULL ->dev.

CVE-2026-97493:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu: Bound GPIO I2C table entry count from VBIOS  Reject undersized tables and cap the derived entry count to AMDGPU_MAX_I2C_BUS so we do not overrun adev->i2c_bus[] or walk an absurd number of entries on corrupt size fields.

CVE-2026-97494:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu: validate and share PSP fw_pri_buf copies via psp_copy_fw  Change psp_copy_fw from void to int: return -ENODEV when drm_dev_enter fails, and -EINVAL when the image size is zero or larger than the 1 MiB PSP private buffer.  Replace open-coded memset/memcpy into fw_pri_buf with psp_copy_fw.

CVE-2026-97496:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdkfd: Fix OOB memory exposure in get_wave_state()  The get_wave_state() function for v9 trusts cp_hqd_cntl_stack_size and cp_hqd_cntl_stack_offset values read directly from the MQD, which are written by GPU microcode and fully attacker-controlled on the CRIU-restore path (via AMDKFD_IOC_RESTORE_PROCESS with H3).  this leads to an unbounded copy_to_user() that can leak adjacent GTT/kernel memory. If offset > size, integer underflow produces a ~4 GiB read length, if size is set to 1 MiB against a 4 KiB allocation, we leak 1 MiB of adjacent kernel memory (other queues' MQDs, ring buffers, KASLR pointers).  Fix by clamping both cp_hqd_cntl_stack_size to the actual allocated buffer size (q->ctl_stack_size) and cp_hqd_cntl_stack_offset to the clamped size before performing arithmetic and copy_to_user().  This ensures we never read beyond the allocated kernel BO regardless of attacker-supplied MQD field values.

CVE-2026-97499:

        In the Linux kernel, the following vulnerability has been resolved:  coresight: perf: Retrieve path and source from event data  ETM perf callbacks currently use the per-CPU csdev_src pointer, which can race with updates during device registration and unregistration.  The AUX setup already builds and stores the path in the event data. Use this path to retrieve the source instead of csdev_src to avoid the race.  Export coresight_get_source() and add etm_event_get_ctxt_path() to retrieve the context's path and its source with READ_ONCE() / WRITE_ONCE() accessors. Give the comments to explain why this approach is safe when pause or resume callbacks preempt the disable callback (e.g. via NMI).

CVE-2026-97500:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: rtw89: phy: check length before parsing PHY status IE  Hardware might report PHY status IE with unexpected length, and parser might access out of range. Check the length ahead.

CVE-2026-97501:

        In the Linux kernel, the following vulnerability has been resolved:  pinctrl: mediatek: paris: bypass pinctrl GPIO layer in set GPIO direction  pinctrl_gpio_direction_input() / pinctrl_gpio_direction_output() take the pinctrl mutex. This causes a gpiochip operations to need to sleep. Worse yet, the .can_sleep field in the gpiochip is not set. This causes the shared GPIO proxy to trip over, as it uses gpiod_cansleep() to check whether it can use a spinlock or needs a mutex. In this case, it ends up taking a spinlock, then calls pinctrl_gpio_direction_output(), which takes a mutex. This causes a huge warning.  While this class of Mediatek hardware does not have separate clear/set registers, the pinctrl context has a spinlock that is taken whenever a register read-modify-write is done. Also, once the GPIO function is selected / muxed in, further GPIO operations do not involve pinctrl operations or state. The GPIO direction and level values do not require toggling the pinmux or any other pin config options.  Switch to directly calling mtk_pinmux_gpio_set_direction() in the GPIO set direction callbacks to avoid taking the pinctrl mutex. Drop the .gpio_set_direction field in mtk_pmxops to signal we are no longer using the pinctrl GPIO layer for setting the direction.

CVE-2026-97505:

        In the Linux kernel, the following vulnerability has been resolved:  PCI/sysfs: Add CAP_SYS_ADMIN check to __resource_resize_store()  Currently, the __resource_resize_store() allows writing to the resourceN_resize sysfs attribute to change a BAR's size without checking for capabilities, currently relying only on the file access check.  Resizing a BAR modifies PCI device configuration and can disrupt active drivers.  After the upcoming conversion to static attributes, it will also trigger resource file updates via sysfs_update_groups().  Add a CAP_SYS_ADMIN check to prevent unprivileged users from performing BAR resize operations.

CVE-2026-97512:

        In the Linux kernel, the following vulnerability has been resolved:  spi: spi-qcom-qspi: Fix incomplete error handling in runtime PM  The runtime PM functions had incomplete error handling that could leave the system in an inconsistent state. If any operation failed midway through suspend or resume, some resources would be left in the wrong state while others were already changed, leading to potential clock/power imbalances.  Reorder the suspend/resume sequences to avoid brownout risk by ensuring the performance state is set appropriately before clocks are enabled and clocks are disabled before dropping the performance state.  Fix by adding proper error checking for all operations and using goto-based cleanup to ensure all successfully acquired resources are properly released on any error.

CVE-2026-97515:

        In the Linux kernel, the following vulnerability has been resolved:  i3c: master: svc: Prevent IRQ storm from false SLVSTART on NPCM845  On NPCM845, when a target on the I3C bus gets stuck holding SDA low, the controller reports a false Master Request (MR) in-band interrupt event. The driver handles this by emitting a STOP condition to restore the bus.  However, the hardware quirk SVC_I3C_QUIRK_FALSE_SLVSTART indicates that emitting a STOP condition may spuriously set the SLVSTART interrupt status bit. In the Master Request case, this creates a feedback loop: the STOP triggers a new SLVSTART event, the IRQ handler fires again, the controller still reports an MR type, another STOP is emitted, and the cycle repeats indefinitely, resulting in an IRQ storm that can lock up the CPU.  Clear the SLVSTART status bit explicitly after emitting the STOP in the Master Request IBI handler when the SVC_I3C_QUIRK_FALSE_SLVSTART quirk is set. This breaks the feedback loop without affecting normal SLVSTART processing, which is already guarded in the top-level IRQ handler by checking that MSTATUS is in SLVREQ state.

CVE-2026-97518:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: cfg80211: reject duplicate wiphy cipher suite entries  Duplicate entries in wiphy->cipher_suites do not describe any additional capability, but cfg80211 currently accepts them and leaves individual consumers to deal with them.  One such consumer is the WEXT compatibility code, which appends a WEP key length for each WEP cipher entry it sees. Repeated WEP entries can therefore overflow the fixed iw_range::encoding_size array returned by SIOCGIWRANGE.  Reject duplicate cipher suite entries in wiphy_register() instead. This keeps the cipher suite invariant in one place and makes malformed wiphy descriptions fail early with -EINVAL, rather than relying on a single cfg80211 user to handle duplicates correctly.

CVE-2026-97529:

        In the Linux kernel, the following vulnerability has been resolved:  scsi: qla2xxx: Validate BSG request_len before reading vendor_cmd[]  The FC BSG transport allocates job->request via memdup_user() using the exact user-supplied request_len. For FC_BSG_HST_VENDOR, fc_bsg_host_dispatch() only guarantees request_len covers msgcode and vendor_id; it does not account for the vendor_cmd[] flexible array.  qla2xxx then reads the command selector vendor_cmd[0] and, in several sub-handlers, vendor_cmd[1]/[2] or structures overlaid on the vendor command area without verifying request_len. A caller holding CAP_SYS_RAWIO can submit a short request whose vendor_id matches the host, triggering out-of-bounds heap reads (KASAN-detectable, and able to mis-select a command or panic).  Add a central guard in qla2x00_process_vendor_specific() so the selector is always in bounds, restrict the early vendor_cmd[0] read in qla24xx_bsg_request() to sufficiently long vendor messages, and add request_len checks to the sub-handlers that read further: qla24xx_proc_fcp_prio_cfg_cmd(), qla2x00_process_loopback(), qla84xx_reset(), qla84xx_updatefw(), qla2x00_read_optrom(), qla2x00_update_optrom(), qlafx00_mgmt_cmd() and qla28xx_validate_flash_image().

CVE-2026-97530:

        In the Linux kernel, the following vulnerability has been resolved:  scsi: qla2xxx: Fix soft lockup polling continuation IOCB signature  qla27xx_copy_multiple_pkt() and qla27xx_copy_fpin_pkt() poll rsp_q->ring_ptr->signature for RESPONSE_PROCESSED (0xDEADDEAD) to decide whether the next continuation IOCB has arrived, spinning on cpu_relax() without advancing the ring or decrementing the entry count while it has not. response_t::signature lives at byte offset 60, but a continuation IOCB (sts_cont_entry_t / struct sts_cont_entry_ext) carries raw FC frame payload at that offset (data[56..59]). A received frame whose payload bytes happen to equal 0xDEADDEAD is therefore misread as "not yet arrived", and the loop spins forever in interrupt/DPC context, causing a CPU soft lockup.  The poll is also unnecessary: callers of qla27xx_copy_multiple_pkt() (PT_LS4_UNSOL and the NVMe purls path) already gate on qla_chk_cont_iocb_avail(), which guarantees all entry_count IOCBs are present before copying begins. The sibling helper __qla_copy_purex_to_buffer() already drops the signature poll and relies on the entry_type == STATUS_CONT_TYPE guard instead.  Remove the signature busy-wait from both helpers, keeping the entry_type guard, and gate the FPIN path with qla_chk_cont_iocb_avail() so it defers and re-processes on the next interrupt once all continuation IOCBs have arrived, mirroring the ELS_AUTH_ELS and PT_LS4_UNSOL arms. With this the signature field is never read on a continuation IOCB, eliminating the payload-aliasing lockup.

CVE-2026-97531:

        In the Linux kernel, the following vulnerability has been resolved:  scsi: qla2xxx: Skip vport under deletion in report ID acquisition  qla24xx_report_id_acquisition() format-1 handling walks ha->vp_list under vport_slock, takes a vref_count on the matching vport and calls qla_update_host_map() to register its port id.  A vport teardown via qla24xx_vport_delete() sets VPORT_DELETE, then qla24xx_disable_vp() removes the vport from the host_map btree and zeroes vha->d_id (RESET_AL_PA). The vport is only unlinked from vp_list later, in qla24xx_deallocate_vp_id(), which clears vp_map[idx] (RESET_VP_IDX) but does not touch host_map. In the window in between, report ID acquisition can still find the vport on vp_list and call qla_update_host_map(); with d_id already zeroed it takes the btree_insert32() path and re-inserts the dying vport into host_map. Nothing cleans that entry afterwards, so once scsi_host_put() frees the vha a later host_map lookup dereferences freed memory.  Skip a vport that has VPORT_DELETE set before taking the reference, so it is neither re-registered nor scheduled for DPC re-registration. This mirrors the existing guard in qla2x00_alert_all_vps().

CVE-2026-97532:

        In the Linux kernel, the following vulnerability has been resolved:  scsi: qla2xxx: Null out freed pointers in qla2x00_mem_alloc() error path  When qla2x00_mem_alloc() fails, qla2x00_probe_one() jumps to probe_hw_failed and calls qla2x00_mem_free(). Several error labels in qla2x00_mem_alloc() freed adapter members (elsrej.c, purex_dma_pool, flt, sfp_data, loop_id_map, async_pd, sf_init_cb, ex_init_cb, npiv_info) but left the pointers dangling. qla2x00_mem_free() then freed them a second time. Worse, for the dma_pool members it issued dma_pool_free(ha->s_dma_pool, ...) after s_dma_pool had already been destroyed and set to NULL at fail_s_dma_pool, dereferencing a NULL pool.  Clear each freed pointer (and its DMA handle) in the error labels so the subsequent qla2x00_mem_free() skips them.

CVE-2026-97534:

        In the Linux kernel, the following vulnerability has been resolved:  f2fs: accurately adjust free_sections during free_segment_range  In free_segment_range(), MAIN_SECS(sbi) is temporarily reduced by `secs` to restrict block allocation to the safe remaining main area while valid blocks in the truncated range are evacuated by GC.  However, FREE_I(sbi)->free_sections tracks the total number of free sections across the whole filesystem. If any sections within the truncated range were already free upon entering free_segment_range(), failing to deduct them from free_sections causes the filesystem to overestimate available free sections in the active, reduced main area. This leads to inconsistent free section accounting during GC data migration and can trigger unexpected allocation failures or assertion errors when space is tight.  Fix this by calculating the number of already-free sections in the truncated range, deducting them from free_sections upon entering free_segment_range(), and restoring them on exit.

CVE-2026-97535:

        In the Linux kernel, the following vulnerability has been resolved:  scsi: qla2xxx: Bound VP index against VP_CTRL IOCB bitmap size  The VP control IOCB selects its target virtual port by setting one bit in vp_idx_map, a fixed 16-byte (128-bit) array in both vp_ctrl_entry_24xx and vp_ctrl_entry_24xx_ext. qla25xx_ctrlvp_iocb() computes map = (vp_index - 1) / 8 and writes vce->vp_idx_map[map] without checking that map stays within the array.  max_npiv_vports is taken from firmware and only sanitized to a MIN_MULTI_ID_FABRIC-aligned boundary, so it can legitimately be 191 or 255, and qla24xx_control_vp() only rejects vp_index >= max_npiv_vports. A vp_index above 128 therefore yields map >= 16 and an out-of-bounds write of up to 16 bytes past vp_idx_map, corrupting the trailing IOCB fields (or the adjacent request-ring slot on the 64-byte layout).  Reject a vp_index that cannot be represented in the IOCB bitmap in qla24xx_control_vp(), and add a defensive ARRAY_SIZE() guard in qla25xx_ctrlvp_iocb() before the write. Adapters that report the usual 63 or 127 NPIV vports are unaffected.

CVE-2026-97536:

        In the Linux kernel, the following vulnerability has been resolved:  scsi: qla2xxx: Fix use-after-free of qpair work on queue teardown  The response queue MSI-X handler qla2xxx_msix_rsp_q() schedules qla_do_work() via queue_work(ha->wq, &qpair->q_work). qla_do_work() dereferences the qpair (vha, rsp) and takes qpair->qp_lock.  During teardown, qla2xxx_delete_qpair() deletes the response queue, which calls free_irq() in qla25xx_free_rsp_que(), and then frees the queue and the qpair. free_irq() waits for running hardirq handlers but does not cancel work already placed on ha->wq. A still-pending q_work then runs qla_do_work() against the freed qpair and response queue, causing a use-after-free. This is especially likely during full adapter teardown, where destroy_workqueue(ha->wq) forces pending work to run after the queue pairs have been freed.  Flush the work item with cancel_work_sync() in qla25xx_free_rsp_que() after free_irq() has released the interrupt (so no new work can be queued) and before the response queue and qpair memory are freed (so the flushed handler still sees valid memory). Guard on rsp->qpair and ha->wq to match the INIT_WORK() condition and avoid operating on an uninitialized work_struct.

CVE-2026-97537:

        In the Linux kernel, the following vulnerability has been resolved:  scsi: qla2xxx: Fix queue teardown NULL dma_free and bitmap locking  qla25xx_free_req_que() and qla25xx_free_rsp_que() have two pre-existing bugs exposed on the error path of qla25xx_create_{req,rsp}_que():   1. When dma_alloc_coherent() fails during queue creation, the error     path calls the free function with req->ring / rsp->ring still NULL     (from kzalloc).  The unconditional dma_free_coherent() with a NULL     cpu_addr is undefined behavior and can panic.   2. The free functions clear req_qid_map / rsp_qid_map under vport_lock,     but the create functions protect the same bitmaps with mq_lock.     This provides no mutual exclusion.  Additionally, the create error     path clears the bit and releases mq_lock before calling the free     function, creating a window where another thread can allocate the     same que_id and have its ha->req_q_map entry clobbered by the     subsequent lockless NULL assignment in the free function.  Fix by:   - Guarding dma_free_coherent() with a NULL check on the ring pointer.   - Using mq_lock (the lock held by all creators) in the free functions    to atomically NULL the map entry and clear the bitmap bit.   - Removing the now-redundant clear_bit blocks from the create error    paths since the free functions handle it atomically.

CVE-2026-97554:

        In the Linux kernel, the following vulnerability has been resolved:  smb: client: avoid using uninitialized SIDs in cifs_posix_to_fattr()  cifs_posix_to_fattr() ignores the return value of posix_info_parse(). When a malformed POSIX directory entry is encountered (e.g. invalid SID lengths from an untrusted server), posix_info_parse() returns -1 without populating the 'parsed' struct.  The uninitialized stack memory in parsed.owner and parsed.group is then passed to sid_to_id(), which processes the garbage bytes and passes them to request_key() to construct a SID string, potentially leaking kernel stack contents to the userspace idmap daemon.  Fix this by checking the return value and skipping the SID-to-id mapping when parsing fails.  The remaining fattr fields (timestamps, mode, etc.) are populated directly from the 'info' pointer so they are unaffected.

CVE-2026-97555:

        In the Linux kernel, the following vulnerability has been resolved:  smb: client: fix heap overflow in DACL owner/group rewrite  When id_mode_to_cifs_acl rewrites an existing DACL, it allocates a buffer sized according to the on-disk DACL length reported by dacl_ptr->size. However, replace_sids_and_copy_aces may rewrite each ACE with a new owner/group SID obtained from the cifs.idmap upcall. Those SIDs can have up to SID_MAX_SUB_AUTHORITIES (15) sub-authorities, making each ACE up to 76 bytes (sizeof(struct smb_ace)).  If the original DACL contains short SIDs (e.g., 1 sub-authority) while the replacement SIDs are long, the rewritten ACEs overflow the allocation.  Fix this by always budgeting for worst-case SID expansion: allocate sizeof(struct smb_acl) plus num_aces * sizeof(struct smb_ace), which covers the smb_acl header and room for every ACE at maximum SID size. This replaces the previous split logic that used dacl_ptr->size for cifsacl mounts but num_aces * sizeof(struct smb_ace) for mode_from_sid mounts: both paths can trigger the same rewrite and need the same headroom.  KASAN reports this as:   BUG: KASAN: slab-out-of-bounds in build_sec_desc+0x1e8a/0x2680 [cifs]   Write of size 4 at addr ffff8881a5e25374 by task chown/5298   ...   The buggy address is located 0 bytes to the right of    allocated 884-byte region [ffff8881a5e25000, ffff8881a5e25374)

CVE-2026-97558:

        In the Linux kernel, the following vulnerability has been resolved:  smb: client: fix cifsFileInfo reference leak in deferred close  When cifs_close() defers a close, it hands the cifsFileInfo reference of the closing struct file to the queued work. Each execution of smb2_deferred_work_close() drops one such reference.  deferred_close_scheduled can be false while the work is pending: the workqueue clears PENDING when the callback starts to run, before the callback clears the flag under deferred_lock. A close in that interval requeues the running work, and the callback then clears the flag, leaving the requeued work pending with the flag down. A later cifs_open() can reuse the handle and its cifs_close() reaches the same branch: queue_delayed_work() fails because the work is still pending, but cifs_close() returns without dropping the closing file's reference. The cifsFileInfo count stays pinned and its tlink, dentry and server handle are leaked.  Check the return value and hand off the reference only when work was actually queued. Otherwise, use the shared _cifsFileInfo_put(), like the mod_delayed_work() branch above: the pending execution already owns its reference.  This issue was found by an in-house static analysis tool.

CVE-2026-97559:

        In the Linux kernel, the following vulnerability has been resolved:  smb: client: fail DACL rewrite when the new DACL exceeds 64K  replace_sids_and_copy_aces() and set_chmod_dacl() accumulate the size of the DACL they build in a u16. That accumulator can wrap.  validate_dacl() caps num_aces at (dacl_size - sizeof(struct smb_acl)) / 20, i.e. 3276 for a maximally sized DACL, while each rewritten ACE can grow to sizeof(struct smb_ace) (76 bytes) once its SID is replaced with one carrying SID_MAX_SUB_AUTHORITIES sub-authorities. The worst case is therefore sizeof(struct smb_acl) + 3276 * 76 = 248984 bytes, far beyond what a u16 can hold. A wraparound is reached with 863 ACEs.  After the wraparound, ndacl_ptr->size becomes meaningless and the offset will point anywhere in the ACE array. As a result, we will see corruption of the DACL, which then gets sent to the server. This is not an out-of-bounds write as the allocation now covers the worst-case expansion, so writes will always go into the buffer.  Adjust the code to use a u32 internally and return -EOVERFLOW in the overflow case. The operation must be refused, because a DACL can only hold 2^16-1 bytes on the wire and larger DACLs cannot be represented.  set_chmod_dacl() carries the same pattern and is fixed the same way. It only wraps once the source DACL comes within roughly 380 bytes of the 64K ceiling, but the failure mode is identical.

CVE-2026-97561:

        In the Linux kernel, the following vulnerability has been resolved:  smb: client: honor forceuid/forcegid when mapping SIDs to uid/gid  When the administrator mounts with forceuid or forcegid (uid=/gid= mount options), they expect all files to appear owned by the specified user/group.  However, several code paths unconditionally called sid_to_id() to overwrite cf_uid/cf_gid with server-provided values, ignoring the administrator's explicit override:    - smb311_posix_info_to_fattr() (stat via POSIX extensions)   - cifs_posix_to_fattr() (readdir via POSIX extensions)   - parse_sec_desc() (CIFS ACL ownership mapping)  This allowed an untrusted server to dictate local file ownership even when the mount was configured to force specific uid/gid values.  Fix all three call sites to check CIFS_MOUNT_OVERR_UID and CIFS_MOUNT_OVERR_GID before calling sid_to_id(), following the same pattern already used by cifs_unix_basic_to_fattr() for unix extensions.

CVE-2026-97562:

        In the Linux kernel, the following vulnerability has been resolved:  smb: client: pin DFS superblock in iterator callback  tcon_super_cb() stores a raw superblock pointer, but __cifs_get_super() takes its active reference only after iterate_supers_type() has dropped s_umount and its passive reference. Concurrent DFS automount expiry can therefore free the superblock before cifs_sb_active() uses it.  A deterministic KASAN test reproduces the race as:    BUG: KASAN: slab-use-after-free in cifs_sb_active+0x77/0x80  The same test passes with this change applied.  Take the active reference in the callback while iterate_supers_type() still holds s_umount shared. cifs_put_tcp_super() remains the matching release.

CVE-2026-97563:

        In the Linux kernel, the following vulnerability has been resolved:  smb: client: reject out-of-bounds DataOffset in CIFSSMBRead()  The SMB1 synchronous read helper CIFSSMBRead() validates the server's DataLength against CIFSMaxBufSize and the caller's count, but never validates DataOffset. The copy source is formed as  	&pSMBr->hdr.Protocol + le16_to_cpu(pSMBr->DataOffset)  and memcpy()'d for DataLength bytes with no check that the [DataOffset, DataOffset + DataLength) range lies within the response actually received from the server.  A malicious or compromised SMB1 server can return a response carrying an in-range DataLength and a large DataOffset, driving the source pointer past the end of the response buffer. The memcpy() then copies adjacent kernel heap into the caller's read buffer (information disclosure), or reads unmapped memory and oopses (denial of service). SMB1 is not negotiated by default; reaching this code requires an explicit vers=1.0 mount.  Both DataOffset and the received response length recorded in rsp_iov.iov_len are relative to the start of the SMB header, so reject the response unless DataOffset + DataLength fits within that length, using overflow-safe arithmetic, before forming the source pointer. The response length has been validated by the previous patch, so the DataOffset and DataLength fields can be read safely here.  While here, make data_length unsigned. It holds a length derived from unsigned on-the-wire fields and is only ever compared against unsigned quantities; print it with %u accordingly, and add __func__ to the cifs_dbg() calls in this function.

CVE-2026-97565:

        In the Linux kernel, the following vulnerability has been resolved:  smb: client: reject short READ responses in CIFSSMBRead()  CIFSSMBRead() reads DataLengthHigh, DataLength and DataOffset out of the READ_RSP returned by the server without first checking that a whole READ_RSP was actually received. The length of the response is recorded in rsp_iov.iov_len, but nothing constrains it to be at least read_rsp_size before those fields are dereferenced.  A malicious or compromised SMB1 server can return a response shorter than the READ_RSP header, so that parsing the header itself reads past the end of the receive buffer. SMB1 is not negotiated by default; reaching this code requires an explicit vers=1.0 mount.  Reject the response unless it is at least read_rsp_size bytes long.

CVE-2026-97566:

        In the Linux kernel, the following vulnerability has been resolved:  mptcp: pm: kernel: drop pending ADD_ADDR when removing ID0  The in-kernel MPTCP path manager can leave a stale ADD_ADDR announcement entry alive when removing the id 0 endpoint. This happens because the id 0 removal path does not tear down pending announcements, unlike the non-zero id path.  When the PM later reselects id 0 after adding another signal endpoint, it finds the stale anno_list entry and hits WARN_ON_ONCE(mptcp_pm_is_kernel()) in mptcp_pm_announced_alloc().  Root cause: asymmetry between removal paths. - Non-zero id path: mptcp_nl_remove_subflow_and_signal_addr() calls   mptcp_pm_remove_announced() to clean up. - Id 0 path: mptcp_nl_remove_id_zero_address() skips cleanup entirely.  Fix by making the id 0 path symmetric: call mptcp_pm_announced_remove() and decrement add_addr_signaled before queuing the RM_ADDR.  Subtle detail: signal endpoints are stored in anno_list with port 0, but msk_local carries the connection's local port. In other words, entries linked to ID0 paths should have port == 0. A follow-up patch will ensure that. mptcp_pm_announced_remove() uses use_port=true for comparison. So clear the port before the lookup.

CVE-2026-97567:

        In the Linux kernel, the following vulnerability has been resolved:  mptcp: prevent race between disconnect() and rtx  Sashiko noted that the two event can race, leading to inconsistent status. Prevent the race using the synchronous timer stop operation.

CVE-2026-97587:

        In the Linux kernel, the following vulnerability has been resolved:  perf: RISC-V: store available counter mask as bitmap  The available-counter mask was a single unsigned long, but iteration uses RISCV_MAX_COUNTERS, which is 64. On RV32 that reads past the object. Filling with an unsigned-long bit at index 32 and above is also wrong.  Use DECLARE_BITMAP and set_bit/bitmap helpers. Walk each bitmap word into CFG_MATCH when checking events, when allocating an index, and when stopping all counters. Set the counter base to i times BITS_PER_LONG. Share the CFG_MATCH ecall through a small helper so the 32-bit argument split is not duplicated. On qemu-system-riscv32 the probe bitmap has bits above XLEN set, so the first word alone is not enough.  [pjw@kernel.org: updated to apply; fixed checkpatch.pl issues]

CVE-2026-97594:

        In the Linux kernel, the following vulnerability has been resolved:  landlock: Fix use-after-free of the source's parent directory  current_check_refer_path() reads old_dentry->d_parent without holding a reference nor a lock on it, and then dereferences it in collect_domain_accesses() and in the audit record.  A reference on a child does not pin its parent: __d_move() reassigns dentry->d_parent and drops the reference the child held on its former parent.  hook_path_rename() is not affected because the rename path calls lock_rename() before the hook, so the source cannot be reparented under it.  hook_path_link() has no such protection: filename_linkat() holds a reference on the source dentry but neither locks nor references its parent, so a concurrent rename(2) can reparent the source while security_path_link() runs, and the former parent can then be removed and freed while the hook walks it.  A process can trigger this after entering a Landlock domain that handles at least one filesystem access right.  The process can then race a linkat(2) loop against rename(2) and rmdir(2):    BUG: KASAN: slab-use-after-free in collect_domain_accesses+0x278/0x290   Read of size 4 at addr ffff888160bd53f4 by task llrepro2/549    collect_domain_accesses+0x278/0x290    current_check_refer_path+0x952/0x1120    security_path_link+0x1be/0x320    filename_linkat+0x342/0x6d0    __x64_sys_linkat+0xfa/0x150   Freed by task 562:    kmem_cache_free+0x139/0x4c0    i_callback+0x4b/0x80    rcu_core+0x7dc/0x10a0  Take a reference on the dentry selected as the source parent, using dget() for the common-mount-root case and dget_parent() otherwise. Release it after the hierarchy walk and synchronous audit logging.  [mic: Clarify the caller, reachability, and reference handling]

CVE-2026-97597:

        In the Linux kernel, the following vulnerability has been resolved:  ipv6: flowlabel: cap duplicate leases per socket  ipv6_flowlabel_get() allocates an ipv6_fl_socklist entry for every successful GET. The recheck path for a compatible existing flowlabel links another lease without applying any lease admission check. Repeated GET requests for one shareable label can therefore grow a socket's lease list without bound.  Reject a new unprivileged lease once the socket already holds FL_MAX_PER_SOCK leases. Check this on the shared recheck path so reuse of a globally interned label, including the fl_intern() collision path, is covered as well. New-label admission remains under the existing mem_check() policy.  Use capable(CAP_NET_ADMIN) rather than ns_capable(), matching mem_check(). An unprivileged user must not bypass the cap by creating a user namespace and a netns where they have CAP_NET_ADMIN, which would still consume host memory.  Check the capability only when the socket reaches the limit, so successful unprivileged GET requests below the cap do not generate a capability audit. Do the admission check before updating linger and expires so a rejected GET does not refresh the shared label, matching the existing socket-list allocation failure path.

CVE-2026-97599:

        In the Linux kernel, the following vulnerability has been resolved:  ieee802154: hwsim: serialize pib updates to fix double-free  hwsim_update_pib() does an unserialized read-swap-free of phy->pib:  	pib_old = rtnl_dereference(phy->pib); 	... 	rcu_assign_pointer(phy->pib, pib); 	kfree_rcu(pib_old, rcu);  It assumes the RTNL is held, but ->set_channel is not always called under it: the mac802154 scan worker changes channels via drv_set_channel() without the RTNL. Such an update can race an RTNL-held one on the same phy; both read the same pib_old and both kfree_rcu() it, double-freeing the object. With SLUB percpu sheaves batching kfree_rcu(), this surfaces as a KASAN invalid-free in rcu_free_sheaf().  struct hwsim_phy has no lock for pib. Add one and make the swap atomic with rcu_replace_pointer() under it, dropping the misleading rtnl_dereference().

CVE-2026-97600:

        In the Linux kernel, the following vulnerability has been resolved:  ieee802154: cc2520: fix FIFOP work use-after-free  The FIFOP interrupt handler queues cc2520_fifop_irqwork.  On removal, cc2520_remove() only flushes the work.  The devm-managed FIFOP IRQ remains active until after ->remove() returns and can queue the work again after that flush, allowing it to run after the private data is released.  Disable the work with disable_work_sync() instead of flushing it, so the handler can no longer queue it once removal begins.  Destroy the buffer mutex last, since the worker and the stop callback invoked through ieee802154_unregister_hw() both take it.  Found by an in-house static analysis tool.

CVE-2026-97605:

        In the Linux kernel, the following vulnerability has been resolved:  erofs: preserve LZMA decoders on resize failure  The pool-resize path frees each stream's old decoder before allocating its replacement. If an allocation fails after some streams have already been replaced, the failed stream is put back on the list with state == NULL. z_erofs_lzma_max_dictsize is still advanced as if the whole pool had been resized.  An existing LZMA mount can select the broken stream and pass NULL to xz_dec_microlzma_reset(). A retry at the same size also skip another resize attempt. Since the global maximum was advanced, thus, the invalid state is left unrepaired.  Allocate each replacement before freeing the old decoder, temporarily retaining one old decoder during allocation. Stop at the first failure and advance z_erofs_lzma_max_dictsize only after all streams satisfy the request.  Record each stream's dictionary capacity so retries can skip streams already enlarged before a partial failure.

CVE-2026-97609:

        In the Linux kernel, the following vulnerability has been resolved:  netfilter: cttimeout: prevent UAF during module unload  nf_ct_set_timeout() protects the timeout hook dereference and policy lookup with rcu_read_lock(). cttimeout_exit(), however, unregisters the per-net operations before it clears the hook.  This allows the following interleaving:    CPU 0                              CPU 1   cttimeout_exit()                   nf_ct_set_timeout()     unregister_pernet_subsys()         rcu_read_lock()       kfree(pernet)                     h = nf_ct_timeout_hook                                         h->timeout_find_get()                                           nfct_timeout_pernet()  The hook still points to ctnl_timeout_find_get() when CPU 1 looks up the already freed per-net timeout list. KASAN reported:    BUG: KASAN: slab-use-after-free in ctnl_timeout_find_get   Read of size 8 by task poc/90   Call Trace:    ctnl_timeout_find_get+0x271/0x2a0 [nfnetlink_cttimeout]    nf_ct_set_timeout+0x7b/0x3c0    xt_ct_tg_check+0x724/0xb20    xt_check_target+0x234/0xa90    do_ipt_set_ctl+0x570/0x1270   Allocated by task 89:    __kmalloc_noprof+0x16e/0x460    ops_init+0x6d/0x420    register_pernet_operations+0x2f6/0x670   Freed by task 91:    kfree+0x131/0x390    ops_undo_list+0x3d4/0x730    unregister_pernet_operations+0x232/0x490    unregister_pernet_subsys+0x1c/0x30    cttimeout_exit+0x52/0x970 [nfnetlink_cttimeout]  Clear the hook and wait for existing readers before unregistering the per-net operations. This blocks new policy lookups and ensures readers that observed the hook finish before the per-net storage is freed.

CVE-2026-97613:

        In the Linux kernel, the following vulnerability has been resolved:  net: mana: Reserve extra CQ slot for the fence completion CQE  The RX completion queue is sized to hold exactly one CQE per posted RX WQE. MANA_FENCE_RQ makes hardware post an additional CQE_RX_OBJECT_FENCE after the packet CQEs. The current sizing reserves no extra slot for it and in rare cases, CQ has no guaranteed slot for the fence CQE when it is full of packet CQEs. This can lead to dropping the fence completion while the driver waits holding RTNL lock throughout the timeout duration. Reserve one extra CQE slot for CQE_RX_OBJECT_FENCE. mana_gd_alloc_memory() requires queue_size to be a power-of-two and at least MANA_PAGE_SIZE; the reservation pushes cq_size past a power-of-two, so round up the CQ size in mana_create_rxq().

CVE-2026-97615:

        In the Linux kernel, the following vulnerability has been resolved:  net: bridge: use option bits for CFM/MRP frame handlers  CFM and MRP register a global br_frame_type whose hlist_node is linked into the per-bridge frame_type_list when the first MEP/MRP instance is created. Enabling the protocol on multiple bridges therefore inserts the same node into multiple lists. Unregistering it on one bridge then corrupts list state belonging to another.  These handlers can only be installed once per bridge, and they are uncommon. Track their per-bridge enable state with net_bridge option bits, which already live on the Rx hot cache line, and dispatch the matching handler directly from the receive path. Check both bits together first as an unlikely case.  Remove the generic frame_type_list and br_frame_type helpers, which have had no other users since CFM and MRP were added. That shrinks struct net_bridge by 8 bytes and drops the list walk from the fast path. When neither protocol is compiled in, BR_CFM_MRP_OPTS is 0 and the compiler prunes the branch.

CVE-2026-97616:

        In the Linux kernel, the following vulnerability has been resolved:  net/sched: act_api: release all action references on NEWACTION failure  When a batched RTM_NEWACTION request replaces an existing action, tcf_idr_check_alloc() takes a temporary reference on it. If a later action fails to initialize, tcf_action_destroy() uses strict release semantics to clean up the actions initialized so far. For an action bound to a filter, the strict check returns -EPERM without dropping the temporary reference.  This error also makes tcf_action_destroy() return before releasing subsequent entries. Any new action initialized between the bound action and the failing entry is leaked together with its reserved IDR slot, preventing reuse of its index.  Use tcf_idr_release() to drop each reference held by the batch without rejecting bound actions. This allows cleanup to continue through all initialized entries and preserves the module reference release when an action is destroyed. Explicit action deletion and flushing retain their separate bind-count checks.

CVE-2026-97619:

        In the Linux kernel, the following vulnerability has been resolved:  io_uring/rw: end write accounting from ->ki_complete  Commit b000145e9907 moved both the fsnotify calls and the write accounting out of the kiocb completion handler and into the io_req_rw_complete() task_work. However, only the fsnotify part actually needed to move as it may sleep. Ending the write accounting is just a percpu_up_read() on the superblock writers sem.  Deferring it is a problem, because it makes dropping SB_FREEZE_WRITE protection depend on the ring owner getting to running task_work. But the task may be blocked in freeze_super(), causing it to never get to that:    task                             io-wq worker   --------------------------------------------------------------   io_write()     io_kiocb_start_write()         (takes sb_writers, hidden from                                     lockdep by __sb_writers_release)     write_iter() -> -EIOCBQUEUED   ioctl(FS_IOC_SHUTDOWN)     bdev_freeze()       freeze_super()         percpu_down_write()        <- waits for the reader above                                    io_write()                                      kiocb_start_write()                                        percpu_down_read()  <- queued                                                               behind the                                                               writer   <bio completes>     io_complete_rw()       queues io_req_rw_complete()  <- never runs, task is in D state  End the write from io_complete_rw() instead, and leave only the fsnotify calls in task_work.

CVE-2026-97901:

        In the Linux kernel, the following vulnerability has been resolved:  genetlink: pin family module during policy dump  The generic netlink controller's policy dump keeps pointers to the target family's operation and policy tables in its callback state.  A dump may be split across multiple skbs and remain pending after the initial request.  Netlink pins the module which owns the dump callback, but in this case that is the controller's owner rather than the target family's owner.  The target family can consequently be unregistered and its module unloaded while a policy dump is pending.  Advancing the dump then dereferences policy memory from the unloaded module.  Take a reference to the target family's module when the dump starts. Drop it from the error and done paths.  This matches the lifetime for which the dump context retains the family and policy pointers.

CVE-2026-97906:

        In the Linux kernel, the following vulnerability has been resolved:  bootconfig: Fix integer overflow in initrd size check  Sashiko reported that in get_boot_config_from_initrd(), a crafted initrd with a huge bootconfig size (such as 0xFFFFFFFF) can cause the pointer arithmetic:      data = ((void *)hdr) - size;  to wrap around on 32-bit systems (or when pointer subtraction overflows). Because data wraps around, the subsequent bounds check:      if ((unsigned long)data < initrd_start)  evaluates to false, bypassing the check. The kernel then calls xbc_calc_checksum(data, size), which attempts to read 4GB of memory, hitting unmapped pages and triggering a fatal kernel page fault during early boot. Furthermore, on 64-bit systems with an initrd > 4.29 GB, an unbounded 32-bit size can similarly bypass the initrd_start check.  Fix this by: 1. Ensuring the initrd is at least large enough to contain the bootconfig    footer and verifying hdr is within the initrd bounds. 2. Checking that size does not exceed XBC_DATA_MAX and does not exceed    the available space between initrd_start and hdr before performing    pointer subtraction.

CVE-2026-97908:

        In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: btqcomsmd: destroy RPMsg endpoints before freeing hci_dev  The command and ACL RPMsg endpoints store struct btqcomsmd as their callback private data. The receive callbacks dereference btq->hdev without taking an hci_dev reference.  The current teardown order frees the hci_dev before destroying the RPMsg endpoints in both the hci_register_dev() error path and the driver remove path. If WCNSS delivers data in that window, the endpoint callback can run with an already freed hci_dev and pass it to the Bluetooth core.  For qcom_smd endpoints, rpmsg_destroy_ept() closes the channel and clears the callback under the channel recv_lock. The receive path holds the same lock while invoking the callback, so destroying the endpoints first both prevents new callbacks and serializes with any callback already running.  Destroy the command and ACL endpoints before hci_free_dev(). Keep hci_unregister_dev() first during remove so the HCI core stops issuing operations before the transport endpoints are shut down. In the full registration-error cleanup path, return directly after freeing the hci_dev to avoid falling through to the partial-construction labels and destroying the endpoints twice.

CVE-2026-97918:

        In the Linux kernel, the following vulnerability has been resolved:  tracing: Undo the registration when enabling the histogram trigger fails  Commit 6f86bdeab633 ("tracing: Fix bad hist from corrupting named_triggers list") described how a trigger that is registered but not on file->triggers ends up freed while still on the global named_triggers list, and moved the registration down so that hist_trigger_enable() follows it immediately. One path still gets there. hist_trigger_enable() adds the trigger and takes it straight back out when the event cannot be enabled:  	list_add_tail_rcu(&data->list, &file->triggers);  	update_cond_flag(file);  	if (trace_event_trigger_enable_disable(file, 1) < 0) { 		list_del_rcu(&data->list); 		update_cond_flag(file); 		ret--; 	}  so the list walk in hist_unregister_trigger() matches nothing, test stays NULL, and the ->free() that would call del_named_trigger() is skipped. out_unreg falls through to out_free, which frees the trigger anyway:   BUG: KASAN: slab-use-after-free in find_named_trigger+0xac/0xc0  Read of size 8 at addr ffff8880091d3160 by task init/1   find_named_trigger+0xac/0xc0   hist_register_trigger+0xc1/0xa00   event_hist_trigger_parse+0x3146/0x6af0   event_trigger_write+0xce/0x160  Freed by task 69:   kfree+0x154/0x420   trigger_kthread_fn+0xfd/0x160  Leave the trigger where hist_unregister_trigger() can find it and let that undo the registration, which is the only code that knows all of what cmd_ops->init() took: the named list entry, the hist_pad reference, the reference on the trigger a named histogram is shared with, and the copied cmd_ops. It also pairs the failed trace_event_trigger_enable_disable(), whose sm_ref and buffered event reference are otherwise left behind.  Since ->free() releases trigger_data and, for a trigger that does not share its histogram, hist_data with it, out_unreg can no longer fall through to out_free. For a trigger that does share, hist_register_trigger() has already destroyed the caller's hist_data, so the fall-through was reading freed memory there as well.  Move the enable_timestamps check in hist_unregister_trigger() above the ->free() call for the same reason: hist_data does not outlive it once the trigger being removed is the one that owns it.

CVE-2026-97924:

        In the Linux kernel, the following vulnerability has been resolved:  tracing/user_events: Don't destroy fields when event removal fails  destroy_user_event() destroys the event's fields before attempting to remove the trace event call. If user_event_set_call_visible() fails, e.g. because the event is still enabled and trace_remove_event_call() returns -EBUSY, the event is left registered with an irreversibly destroyed field list. Any subsequent interaction with the event then operates on an empty field list while it is still fully visible in tracefs.  Move the field destruction after the call removal, and splice the field list back onto the event when the removal fails so the event remains in a consistent state.

CVE-2026-97929:

        In the Linux kernel, the following vulnerability has been resolved:  ALSA: usbusx2y: validate URB actual_length in interrupt callback  i_usx2y_in04_int() processes the interrupt URB data without checking urb->actual_length.  A short transfer from a malfunctioning device would cause the handler to process uninitialized heap data from the kmalloc-allocated in04_buf, which is then copied to the mmap-accessible ctl_snapshot[] array.  Fix by using kzalloc() for in04_buf to zero-initialize the buffer, and adding an actual_length check to skip processing on short transfers while still resubmitting the URB.

CVE-2026-97933:

        In the Linux kernel, the following vulnerability has been resolved:  tracing: Take trace_array reference when opening a tracer options file  When a tracer option file is opened, it is passed a descriptor that points to an element on the trace_array's topts array. This element has information to find the trace array and other information. It uses this element to take a reference of the trace_array so that the trace_array does not get removed while this file is opened.  Unfortunately, there's a race condition where the element itself could be freed by the removal of the instance the trace_array represents causing a use-after-free as this element that is used to find the trace_array to increment its reference counter is also freed when the instance is removed.  To solve this, add a trace_array_tracer_options_get() helper function that will take the address of the element that is passed to the open function by the inode->i_private pointer and search all the trace_arrays under a lock to find the one that the element's address is in the range of the trace_arrays topts array elements. When a match happens, that trace_array's reference would be increased.  Note, there's a race where if an admin was deleting and creating trace instances at the same time and the memory of the old trace_array's array matched the memory of the new trace_array that it could in theory open the option from the wrong trace array. But we do not care because it would be stupid to perform that kind of action. As long as the only thing that can happen is that the option from the wrong trace array is used and doesn't crash the kernel it will only make the user confused. But if they are doing something stupid like this, they are already confused, so no harm done.

CVE-2026-97935:

        In the Linux kernel, the following vulnerability has been resolved:  tracing: Set the trace clock before registering the histogram trigger  hist_register_trigger() puts the trigger on the global named_triggers list in cmd_ops->init(), and only then sets the trace clock:  	if (data->cmd_ops->init) { 		ret = data->cmd_ops->init(data); 		if (ret < 0) 			goto out; 	}  	if (hist_data->enable_timestamps) { 		ret = tracing_set_clock(file->tr, hist_data->attrs->clock); 		if (ret) { 			hist_err(tr, HIST_ERR_SET_CLOCK_FAIL, errpos(clock)); 			goto out; 		}  The clock string is not checked anywhere before that call, so a named trigger using common_timestamp with an unknown clock fails after it has already become findable. event_hist_trigger_parse() then frees it without taking it off the list, and the next lookup by name reads the freed object:   ~# cd /sys/kernel/tracing/events/sched/sched_switch  ~# echo 'hist:name=foo:keys=common_pid:ts=common_timestamp:clock=bogus' > trigger  bash: echo: write error: Invalid argument  ~# echo 'hist:name=foo:keys=common_pid' > trigger    BUG: KASAN: slab-use-after-free in find_named_trigger+0xac/0xc0   Read of size 8 at addr ffff88800915d760 by task init/1    find_named_trigger+0xac/0xc0    hist_register_trigger+0xc1/0x900    event_hist_trigger_parse+0x3146/0x6af0    event_trigger_write+0xce/0x160   Freed by task 63:    kfree+0x154/0x420    trigger_kthread_fn+0xfd/0x160  Set the clock before the trigger is registered, so that nothing which can fail runs after it is published, the way commit 6f86bdeab633 ("tracing: Fix bad hist from corrupting named_triggers list") moved the registration below the rest of the setup.  tracing_set_filter_buffering() is reference counted, so the init failure path has to drop the reference that the clock block now takes first.

CVE-2026-97938:

        In the Linux kernel, the following vulnerability has been resolved:  reboot: fix cad_pid use-after-free race  cad_pid is a single kernel-wide struct pid pointer. proc_do_cad_pid() reads it and passes it to pid_vnr() without protecting the lifetime of the referenced struct pid. A concurrent writer can replace cad_pid and drop the final reference to the old struct pid after the reader has loaded the pointer but before pid_vnr() has finished dereferencing it, causing a use-after-free.  kill_cad_pid() has the same lifetime race when it passes cad_pid to kill_pid().  At the time this issue was reported, an unprivileged user could reach the sysctl through user and PID namespaces because cad_pid was registered in pid_table[]. Moving cad_pid back to the global reboot sysctl table corrected that namespace and permission mismatch, but did not fix the underlying lifetime race.  Fix this by treating cad_pid as an RCU-protected pointer at both read sites and by waiting for a grace period before dropping the old reference on the write side.  call_rcu(&old_pid->rcu, ...) cannot be used here because free_pid() also queues pid->rcu; queueing the same rcu_head twice can corrupt the RCU callback list.  Original KASAN crash stack:   kernel/pid.c:545 pid_nr_ns()        # reads freed pid->level   kernel/pid.c:556 pid_vnr()          # calls pid_nr_ns()   kernel/pid.c:775 proc_do_cad_pid()  # calls pid_vnr(cad_pid)

CVE-2026-97939:

        In the Linux kernel, the following vulnerability has been resolved:  ipmr: account multicast table and route memory  A netadmin in a user+net namespace can create many IPv4 and IPv6 multicast routing tables with MRT_TABLE and MRT6_TABLE. Each unseen id allocates an mr_table via the shared mr_table_alloc(), links it into the per-net list, and leaves it until netns teardown. Those objects were not charged to memcg, so the host unreclaimable slab grows with the table count.  Account mr_table allocations with GFP_KERNEL_ACCOUNT and mark the IPv4/IPv6 MFC caches SLAB_ACCOUNT. This matches the established handling of IP addresses, routes and alternate interface names.  Unresolved MFC entries are still allocated from softIRQ with GFP_ATOMIC and are not charged. They expire after 10 seconds and are bounded by the socket receive queue; see commit 0079ad8e8dc3 ("ipmr: remove hard code cache_resolve_queue_len limit").

CVE-2026-97949:

        In the Linux kernel, the following vulnerability has been resolved:  configfs: unhash the dentry before dropping the item in rmdir  configfs_get_config_item() treats a hashed dentry as proof that sd->s_element is a live config_item.  configfs_rmdir() breaks that: simple_rmdir() leaves the dentry hashed, the last reference to the item is dropped right after, and the dentry is only unhashed by d_delete() once ->rmdir() has returned.  configfs_symlink() resolves its target holding no lock on it, so get_target() can land in that window:    BUG: KASAN: slab-use-after-free in config_item_get+0x26/0x90    get_target fs/configfs/symlink.c:128 [inline]    configfs_symlink+0x4ab/0x1030 fs/configfs/symlink.c:185  Unhash in configfs_remove_dir(), while the item is still guaranteed to be there.  A reference obtained just before that stays harmless, as create_link() rechecks CONFIGFS_USET_DROPPING, already set by configfs_detach_prep().  Both configfs_unregister_subsystem() paths d_drop() after detaching, so this only makes rmdir match them.

CVE-2026-97950:

        In the Linux kernel, the following vulnerability has been resolved:  configfs: pin the symlink target's dirent instead of chasing ->ci_dentry  create_link() reads the target's configfs_dirent from item->ci_dentry->d_fsdata, relying on the item reference taken by get_target().  That reference pins the item, not its dentry: the dentry is pinned by DCACHE_PERSISTENT, which configfs_remove_dir() releases via simple_rmdir() while the item is still alive.  A symlink racing with rmdir of its target can therefore find ->ci_dentry freed and its dirent released, triggering WARN_ON(!atomic_read(&sd->s_count)) in configfs_get().  Take the dirent in get_target() as well, under ->d_lock and atomically with the item reference, and pass it down to create_link().  A hashed dentry has not been killed yet, so its ->d_fsdata reference keeps the dirent alive there.

CVE-2026-97953:

        In the Linux kernel, the following vulnerability has been resolved:  net: stmmac: fix TX descriptor availability check for TSO traffic  stmmac_tso_xmit() estimates the number of free TX descriptors required by a TSO skb as:  	(skb->len - proto_hdr_len) / TSO_MAX_BUFF_SIZE + 1  which assumes the payload is split into TSO_MAX_BUFF_SIZE chunks. This underestimates the descriptors actually consumed by stmmac_tso_allocator(), since each fragment is mapped individually and so it needs at least one descriptor regardless of its size. Moreover, one descriptor is used for the L2/L3/L4 headers and, when the MSS changes, one more is consumed for the MSS context descriptor. For a highly fragmented TSO skb the check can therefore pass even when the ring has too few free slots. stmmac_tso_allocator() then writes past the available descriptors, overwriting descriptors still owned by the DMA engine, corrupting the TX ring. Add stmmac_tso_get_num_desc() to compute the exact number of descriptors needed for the header, the linear payload and each fragment, plus the MSS context descriptor when required, and use it in the availability check.

CVE-2026-97965:

        In the Linux kernel, the following vulnerability has been resolved:  vxlan: initialize _md in vxlan_xmit_one()  If a VXLAN device is configured with both VXLAN_F_COLLECT_METADATA and VXLAN_F_GBP, and a packet is transmitted through it using an external ip_tunnel_info that lacks the IP_TUNNEL_VXLAN_OPT_BIT flag, md is left pointing to the uninitialized _md stack variable:                  if (test_bit(IP_TUNNEL_VXLAN_OPT_BIT, info->key.tun_flags)) {                         if (info->options_len < sizeof(*md))                                 goto drop;                         md = ip_tunnel_info_opts(info);                 }  Because IP_TUNNEL_VXLAN_OPT_BIT is not set, md is not updated and remains pointing to _md. Later, vxlan_build_skb() is called with md, which eventually calls vxlan_build_gbp_hdr():          if (vxflags & VXLAN_F_GBP)                 vxlan_build_gbp_hdr(vxh, md);  Inside vxlan_build_gbp_hdr(), md->gbp is read:          if (!md->gbp)                 return;         gbp = (struct vxlanhdr_gbp *)vxh;         ...         if (md->gbp & VXLAN_GBP_DONT_LEARN)                 gbp->dont_learn = 1;  If the stack contains garbage, this causes: 1) VXLAN_HF_GBP flag to be spuriously set in the VXLAN header. 2) gbp->dont_learn and gbp->policy_applied to be set from stack bits. 3) gbp->policy_id to receive 16 bits of uninitialized kernel stack data,    leaking it onto the wire.  Fix this by zero-initializing _md. If IP_TUNNEL_VXLAN_OPT_BIT is not present, md->gbp remains 0, and vxlan_build_gbp_hdr() returns early without modifying the VXLAN header.

CVE-2026-97975:

        In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: hci_sysfs: Fix NULL pointer dereference in device_del()  A NULL pointer dereference in klist_put() occurs when a child device (such as a BNEP network device in bnep_session) is concurrently being unregistered while hci_conn_del_sysfs() reparents child devices.  This is caused by a race condition between hci_conn_del_sysfs() and concurrent child device unregistration (e.g. bnep_session calling unregister_netdev()). During device unregistration, device_del() snapshots a non-NULL parent pointer. Concurrently, hci_conn_del_sysfs() finds the child device using device_find_any_child() and calls device_move() to reparent it to NULL, which removes the node from its parent's klist and clears knode_parent. Subsequently, device_del() calls klist_del(&dev->p->knode_parent) using the stale parent snapshot, causing klist_put() to dereference knode_klist(n)->put on an already removed node, resulting in a NULL pointer dereference.  This race was introduced by commit 27aabf27fd01 ("Bluetooth: fix use-after-free in device_for_each_child()"), which replaced device_find_child(..., __match_tty) with device_find_any_child() in hci_conn_del_sysfs(). That change was intended to avoid a use-after-free where conn->dev outlived its parent hdev->dev when child devices held references to conn->dev, because conn->dev only held a reference to hdev->dev while registered in sysfs.  Fix the issue properly by taking an explicit reference to the parent device with get_device(&hdev->dev) in hci_conn_init_sysfs() and dropping it with put_device(parent) in bt_link_release() when the conn device is freed. This ensures that hdev->dev remains valid for the entire lifecycle of conn->dev, resolving the underlying use-after-free. With the parent reference held properly, restore the __match_tty filter in hci_conn_del_sysfs() so that device_move() is only invoked on persistent RFCOMM TTY devices as originally intended, eliminating the race condition with unregistering network devices.

CVE-2026-97978:

        In the Linux kernel, the following vulnerability has been resolved:  eth: ice: don't dereference pointers from TP_printk()  After forwarding net-next during the v7.3 merge window we started seeing:    TRACE EVENT ERROR: Event ice_tx_dim_work has double dereference in TP_printk: REC->q_vector->tx.tx_ring->q_index   WARNING: kernel/trace/trace_events.c:420 at test_double_dereference.cold+0x39/0x4b  this is due to extra checks added in tracing subsystem in commit b5cc230af5e5 ("tracing: Warn when an event dereferences a pointer in TP_printk()").  Printing happens long after the event was recorded, by which point the pointers may be invalid (the ring or the dim instance). Copy the eight scalars into the event instead.

CVE-2026-97984:

        In the Linux kernel, the following vulnerability has been resolved:  net: ipv6: Fix UDP length overflow with PMTU discover and big MTU  This commit bounds cork->base.fragsize to IP6_MAX_MTU for UDP sockets to avoid a possible overflow of UDP length that triggers a WARN in udp_set_len_short when setsockopt IPV6_MTU_DISCOVER is set to IPV6_PMTUDISC_DO or IPV6_PMTUDISC_PROBE, and a large packet is sent over a netdev with an unusually large MTU.  Steps to reproduce (included in the new selftest):  1. Set device MTU bigger than IP6_MAX_MTU. cork->base.fragsize will be    set to that MTU in ip6_setup_cork. 2. Set IPV6_MTU_DISCOVER to IPV6_PMTUDISC_PROBE or IPV6_PMTUDISC_DO. It    lets maxnonfragsize be set to device MTU (cork->fragsize) in    __ip6_append_data, rather than to IP6_MAX_MTU. 3. Send 65528 bytes of payload (+8 bytes of UDP header, +40 bytes of    IPv6 header). Device MTU allows it (it's only one byte bigger than    IP6_MAX_MTU, and the device MTU is bigger than that). 4. The UDP length in the built packet is 65536, which overflows the    16-bit length field and triggers the WARN in udp_set_len_short.  To avoid breaking sending UDP jumbograms over raw IPv6 sockets, limit the change to UDP sockets only.  The original overflow bug with IPv6 and IPV6_PMTUDISC_DO seems to predate git history (verified reproduction on 2.6.21), was fixed later, and then reappeared in commit 427faee167bc ("net: ipv6: introduce ip6_dst_mtu_maybe_forward"), which is chosen as the Fixes tag here. The overflow with IPV6_PMTUDISC_PROBE reproduces since its introduction in commit 628a5c561890 ("[INET]: Add IP(V6)_PMTUDISC_RPOBE").

CVE-2026-97985:

        In the Linux kernel, the following vulnerability has been resolved:  af_unix: Update last skb marker in manage_oob().  Fahad Alharbi reported that blocking recv(MSG_PEEK) could hog CPU due to OOB skb.  In the following cases, manage_oob() skips OOB skb(s) and returns NULL for the last recv(MSG_PEEK):    socketpair(AF_UNIX, SOCK_STREAM, 0, sk);    1) skb -> OOB skb -> NULL      send(sk[0], "ab", 2, MSG_OOB);      recv(sk[1], buf, 0, MSG_PEEK);    2) skb -> consumed OOB skb -> NULL      send(sk[0], "ab", 2, MSG_OOB);      recv(sk[1], buf, 1, MSG_OOB);      recv(sk[1], buf, 0, MSG_PEEK);    3) consumed OOB skb -> OOB skb -> NULL      send(sk[0], "a", 1, MSG_OOB);      recv(sk[1], buf, 0, MSG_OOB);      send(sk[0], "b", 1, MSG_OOB);      recv(sk[1], buf, 1, MSG_PEEK);  Then, @copied is 0 in unix_stream_read_generic() (zero-length buffer, or non-OOB skb is not yet consumed), and unix_stream_data_wait() is called.  However, it returns immediately because @last is not updated in unix_stream_read_generic(), and the thread busy-waits for a new skb.  Let's update @last in manage_oob().  For MSG_PEEK, @last is updated with the skipped OOB, and for the non-peek case, @last matches the returned value (when !copied) because OOB is unlinked.  Note that manage_oob() is inlined and no stack canary is added.

CVE-2026-97988:

        In the Linux kernel, the following vulnerability has been resolved:  vhost: invalidate vring access on IOTLB transitions  When VIRTIO_F_ACCESS_PLATFORM changes, cached vring pointers and IOTLB metadata are interpreted in a different address space. Keeping them across the transition can leave stale ring mappings in use.  Clearing d->iotlb before taking the VQ locks also lets a worker observe a transient NULL d->iotlb and fall back to d->umem while translating a descriptor.  Add a common vhost_clear_device_iotlb() helper for vhost-net and vhost-vsock. Take all VQ mutexes in index order before dropping the device-wide IOTLB, invalidate each VQ's cached ring access and metadata, clear pending IOTLB messages, and free the old table after the handoff. This serializes the transition with workers and prevents mixed address space mappings.  On the first direct-to-IOTLB transition, invalidate the cached vring addresses. When an existing device IOTLB is replaced, preserve the GIOVA ring addresses and reset only the metadata cache. After clearing ACCESS_PLATFORM, userspace must configure the vring addresses for the new address mode.  vhost_vq_invalidate_access() clears desc, avail, and used together. Treat the VQ as invalidated only when all three are NULL, since a single GIOVA address may legitimately be zero.

CVE-2026-97989:

        In the Linux kernel, the following vulnerability has been resolved:  vduse: validate virtqueue alignment  vduse_validate_config() only checks the upper bound of vq_align. Invalid values can therefore reach vring_create_virtqueue_map(). The split-ring helpers use align - 1 as a bit mask, so the alignment must be a non-zero power of two. A zero value makes vring_size() drop the descriptor and available-ring part and vring_init() leave the used ring pointer NULL.  The VIRTIO spec requires the used ring to start at an address aligned to at least 4 bytes. Reject values below VRING_USED_ALIGN_SIZE as well as non-power-of-two values before they reach the virtio ring helpers.  Opening a virtio-net device created with vq_align=0 triggered:  BUG: KASAN: null-ptr-deref in virtqueue_kick_prepare_split+0xe3/0x100 Read of size 2 at addr 0000000000000000 by task systemd-network/1062  Call Trace (relevant frames):  dump_stack_lvl  print_report  kasan_report  __asan_load2  virtqueue_kick_prepare_split+0xe3/0x100  virtqueue_kick_prepare+0x40/0x60  try_fill_recv+0x857/0x1250  virtnet_open+0x189/0x460  __dev_open+0x225/0x390  __dev_change_flags+0x368/0x3b0  netif_change_flags+0x56/0xc0  do_setlink.isra.0+0x68c/0x1e30  Validate the value before it reaches the virtio ring helpers.

CVE-2026-97990:

        In the Linux kernel, the following vulnerability has been resolved:  vdpa_sim_net: check TX pull result before RX copy  vringh_iov_pull_iotlb() returns a signed byte count.  A failed TX pull is currently added to the unsigned byte counter and then passed as a size_t length to receive_filter() and vringh_iov_push_iotlb().  A negative error can therefore become a large length in the RX path.  Handle non-positive pull results before every length use.  Count the TX error and complete the consumed TX descriptor with zero bytes.  I found this bug myself, though the patch was written with AI assistance.

CVE-2026-97992:

        In the Linux kernel, the following vulnerability has been resolved:  vhost-vdpa: protect config_ctx from being freed under the config callback  vhost_vdpa_config_cb() loads v->config_ctx and signals it without taking a reference and without holding any lock:  	struct eventfd_ctx *config_ctx = v->config_ctx;  	if (config_ctx) 		eventfd_signal(config_ctx);  VHOST_VDPA_SET_CONFIG_CALL replaces that field and drops what is normally the last reference to the old context:  	swap(ctx, v->config_ctx);  	if (ctx) 		eventfd_ctx_put(ctx);  eventfd_ctx_put() drops the last kref and frees the context immediately, with no RCU grace period, so a callback that has already loaded the pointer goes on to dereference freed memory.  The two sides share no lock: the ioctl runs under vhost_dev.mutex, while the parent invokes the callback from its own interrupt or workqueue context.  This is not the reopen refcount underflow fixed by commit f6bbf0010ba0 ("vhost-vdpa: fix use-after-free of v->config_ctx"), which was about vhost_vdpa_config_put() leaving a stale pointer behind.  Here the pointer is maintained correctly and it is the read side that is unprotected.  With VDUSE as the parent this is reachable from userspace with access to /dev/vduse (root by default).  VDUSE_DEV_INJECT_CONFIG_IRQ queues dev->inject, and vduse_dev_irq_inject() runs the callback under VDUSE's own dev->irq_lock, which vhost does not hold.  vduse_dev_reset() does flush_work(&dev->inject), but VHOST_VDPA_SET_CONFIG_CALL never goes through reset, so an inject already in flight is not waited for.  A process that injects config interrupts on the VDUSE fd while another thread swaps the call fd on the vhost-vdpa fd hits it in seconds:    BUG: KASAN: slab-use-after-free in native_queued_spin_lock_slowpath   Read of size 4 at addr ffff888107d21808 by task kworker/u17:1/2993   Workqueue: vduse-irq vduse_dev_irq_inject   Call Trace:    native_queued_spin_lock_slowpath+0x97/0x5b0    _raw_spin_lock_irqsave+0xd4/0xe0    eventfd_signal_mask+0x69/0x120    vhost_vdpa_config_cb+0x34/0x50    vduse_dev_irq_inject+0x46/0x60    process_one_work+0x468/0x950    Allocated by task 2992:    do_eventfd+0x50/0x200    __x64_sys_eventfd2+0x2e/0x40    Freed by task 2992:    eventfd_ctx_put+0xb9/0xc0    vhost_vdpa_unlocked_ioctl+0x116c/0x2190  Add a spinlock covering every access to config_ctx, so the callback either signals a context that is still alive or observes NULL, and the put happens only once no callback can reach the old value.  Clearing the parent's callback before the put would not be enough: of the in-tree set_config_cb() implementations only VDUSE takes a lock, the rest store the pointer unlocked, so that would not order against an in-flight invocation.

CVE-2026-97994:

        In the Linux kernel, the following vulnerability has been resolved:  vhost/vdpa: reject VRING_NUM larger than device max  vhost_vring_set_num() accepts any non-zero power-of-two queue size that fits in 16 bits. vhost-vdpa then passes that value to set_vq_num() without comparing it with get_vq_num_max().  A process with access to /dev/vhost-vdpa-* can therefore configure a queue larger than the device advertises. With vdpa_sim, the worker can walk descriptors beyond the mapped descriptor ring. KASAN reports a 16-byte out-of-bounds read, corresponding to one vring_desc, in the vringh IOTLB path:    BUG: KASAN: out-of-bounds in _copy_from_iter   Read of size 16   copy_from_iotlb   copydesc_iotlb   vringh_getdesc_iotlb   vdpasim_net_work  Cache get_vq_num_max() immediately after reset. Some backends derive it from writable queue-size state, so querying it after SET_NUM may return the current size instead of the device capability. Invalidate the cached value before reset so a failed reset leaves SET_NUM disabled.  For VHOST_SET_VRING_NUM, copy the complete vring state once and use the same index and size for validation, vq->num, and set_vq_num(). This ensures that validation and use operate on the same copied values.

CVE-2026-97997:

        In the Linux kernel, the following vulnerability has been resolved:  virtio_ring: fix stale descriptor flags after a failed packed add  In a packed ring the AVAIL and USED bits sit in the descriptor itself, so writing them makes that descriptor available. Those bit combinations flip meaning on every round of the ring, tracked by a wrap counter, so invalidating or validating a descriptor means inverting both bits.  Commit 1ce9e6055fa0 ("virtio_ring: introduce packed ring support") has virtqueue_add_packed() make every descriptor of a chain available as it maps the chain, and write the head last. The device consumes the ring in order and stops at a head that is not available yet, so it never reaches the rest.  When vring_map_one_sg() fails partway, unmap_release unmaps the segments and restores avail_used_flags, but the descriptors it wrote to in the ring stay marked with AVAIL and USED bits. The head is now the only entry that keeps the device from consuming these stale entries.  For example, the ring would look like this now.    Z - pre-previous command   A - previous command   B - aborted command   C - current command    [A1 DONE] [A2 DONE] <C1 EMPTY> [B2] [B3] [Z1 DONE]  When the driver now attempts to issue the C command, the next add starts at the same head as B. If C spans less descriptors than B, there is no end marker because AVAIL and USED bits were still in place. And that means the device will start interpreting these stale entries (B2/B3) as another command entry, which then blocks the queue.  This effect typically happens in swiotlb configurations under memory pressure, because vring_map_one_sg() can then fail with larger I/O requests which then leads to command abortions.  There are broadly 2 ways to avoid leaving those flags behind:    1) Defer those flags too until the chain is complete.   2) Rewrite those flags for the previous wrap counter.  Implement the second option in both packed add paths. The first option traverses the chain a second time on every successful add. The second option invalidates all added descriptors when any add fails.  With this patch applied, a packed virtqueue keeps completing requests after a failed add.

CVE-2026-98003:

        In the Linux kernel, the following vulnerability has been resolved:  iommu/amd: Do not reallocate GA log buffers on resume  Commit c5e1a1eb9279 ("iommu/amd: Simplify and Consolidate Virtual APIC (AVIC) Enablement") moved the GA log allocation from iommu_init_pci() to enable_iommus_vapic(), which is called on every resume.  iommu_init_ga_log() assigns iommu->ga_log and iommu->ga_log_tail unconditionally. Each resume therefore replaces the boot-time pointers and leaks both old allocations. The function also uses GFP_KERNEL from a syscore resume callback, where interrupts are disabled and the non-boot CPUs are offline.  Return early if both buffers are already allocated. Clear the pointers in free_ga_log() so a partial allocation failure cannot leave ga_log dangling.

CVE-2026-98019:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: mark a NULL call argument precise  check_func_arg() allows bpf_register_is_null() for nullable arguments w/o marking the underlying scalar register precise. Hence a checkpoint created on such a path would prune against arbitrary scalar value.  check_helper_call() enforces second parameter of the bpf_get_local_storage() to be zero, w/o marking the underlying scalar register precise. Hence a checkpoint created on such a path would prune against arbitrary scalar value.  Grouping these two into one patch, as they share the same fixes tag.

CVE-2026-98021:

        In the Linux kernel, the following vulnerability has been resolved:  net: reject oversized tx_queue_len at netlink parse time  rtnl_create_link() assigns IFLA_TXQLEN directly to dev->tx_queue_len without going through netif_change_tx_queue_len(), so a device created with "ip link add ... txqueuelen 500000" bypasses the S16_MAX cap and still triggers the oversized ring allocations in pfifo_fast, tun and tap. The veth peer nest (rtnl_nla_parse_ifinfomsg()) and the RTM_NEWLINK-on-existing-device path reach the same sinks.  Enforce the cap in ifla_policy instead: IFLA_TXQLEN becomes NLA_POLICY_FULL_RANGE(NLA_U32, &txqlen_range) with txqlen_range = { .min = 0, .max = S16_MAX }. All netlink consumers parse against this policy - rtnl_setlink(), rtnl_newlink() (create and change), and the veth peer nest - so every netlink path is capped at parse time and rejects the attribute with -ERANGE plus a proper "integer out of range" extack message before any device state is modified (the RTM_SETLINK half-application wart is gone with it).  Document the bound in the rt-link.yaml netlink spec.  Conditions to recreate the bug: - CONFIG_NET_SCHED=y, CONFIG_VETH=y, CONFIG_USER_NS=y, CONFIG_NET_NS=y. - Unprivileged user in a fresh user+net namespace (unshare -Urn):   ip link add v0 txqueuelen 500000 type veth peer name v1   -> on the fixed kernel this is rejected with -ERANGE ("integer out   of range" extack) instead of installing an oversized tx_queue_len   that later inflates pfifo_fast/tun/tap ring allocations. - ip link set v0 txqueuelen 500000 is likewise rejected at parse time.

CVE-2026-98026:

        In the Linux kernel, the following vulnerability has been resolved:  net: bridge: mcast: properly convert mglist to rcu  Sashiko reported a bug [1] that br_multicast_del_port_group unlists the port group not using proper rcu helper that preserves the next pointer and after that immediately frees the port group without waiting for rcu grace period. The only rcu walker of mglist is br_multicast_list_adjacent() and it turns out that function has always been buggy because mglist was never properly converted to RCU. Fix it by converting it to rcu and moving its initialization after eth_addr's. Initializing p->next can use RCU_INIT_POINTER because we have a barrier from the hlist_add_head_rcu call later, besides we're initializing an unpublished structure anyway.  [1] https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260826014200.362304-1-littleddfu%40gmail.com

CVE-2026-98033:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: Preserve inner map identity in callback frames  Callback frame constructors initialize map-typed argument registers with __mark_reg_known_zero() and then restore map_ptr. This clears map_uid, which is the only field distinguishing inner maps that share an inner_map_meta template.  When a timer callback invokes bpf_for_each_map_elem() on a second inner map, both the saved first map and the second map value can reach the nested callback as the same template with map_uid zero. bpf_timer_init() then accepts pairing the timer from the second map with the first map.  The runtime records the first map in the timer without taking a reference. Freeing that map does not find the timer stored in the second map, so a later timer callback dereferences the freed map.  Copy map_uid from the same caller register as map_ptr when constructing for-each, timer/workqueue, and task-work callback arguments. The existing identity check can then reject mismatched inner maps while allowing a callback value to be paired with its actual map.

CVE-2026-98034:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: Mark NULL kptr stores precise  check_map_kptr_access() permits a scalar store into an untrusted kptr field only when the register is known to contain zero. Unlike other verifier checks whose outcome depends on a scalar value, it does not mark that register precise.  A state checkpoint reached with an imprecise zero can therefore prune a second path that reaches the store with an arbitrary nonzero scalar. The program can write attacker-controlled bits into the kptr field and load them back as a PTR_TO_BTF_ID.  Call mark_chain_precision() before accepting a known-zero register. This forces state equivalence to compare its scalar range and makes the verifier visit and reject a path carrying a nonzero value.

CVE-2026-98041:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: Don't predict JMP32 pointer vs zero comparisons  Consider the following program:          r1 = map_value;      /* low 32 bits are zero at runtime */         r6 = 0xdead000000000000;         if w1 != 0 goto l1;     l0: r1 += r6;         r2 = *(u64 *)(r1 + 0);         exit;     l1: r6 = 0;         goto l0;  At the moment is_branch_taken() reports the jump as always taken, because it does not distinguish between BPF_JMP and BPF_JMP32 comparisons when processing 'if w1 != 0 ...'.

CVE-2026-98043:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: Don't infer non-NULL from a pointer with an unbounded offset  reg_not_null() decides that a register holds a non-NULL value by looking at its type alone. For pointer types that allow arithmetic the type only guarantees a non-NULL base, in case of an unbound offset the runtime offset value might still add up to NULL. Consider the followng program:    r6 = bpf_map_lookup_elem(map, &0);  /* present */   if (r6 == 0) return 0;   r7 = bpf_map_lookup_elem(map, &1);  /* absent, NULL at runtime */   r8 = r7;   r8 -= r6;     /* pointer - pointer: unknown scalar, -r6 */   r8 <<= 1;   r8 >>= 1;     /* any non-negative offset is accepted by */                 /* check_reg_sane_offset_ptr() */   r6 += r8;     /* verifier: map value;    runtime: zero  */   if (r7 != r6) return 0;   *(u8 *)(r7 + 0);  /* r7 is inferred non-NULL, both are zero */  At runtime both registers are zero, the comparison is true and the load faults with NULL pointer dereference.  Require the offset to be within +-BPF_MAX_VAR_OFF in reg_not_null().

CVE-2026-98044:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: Reject legacy packet loads from callbacks  check_ld_abs() models a failed BPF_LD_ABS or BPF_LD_IND in a subprogram as an implicit return with R0 set to zero. It calls prepare_func_exit() to explore this synthesized path.  When the load is reached directly from a synchronous callback, prepare_func_exit() enforces the callback return contract and marks R0 precise. R0 is not derived from a real instruction on this path, so precision backtracking reaches the callback call with R0 still requested and triggers the "callback unexpected regs" verifier bug. A privileged program loader can therefore cause a verifier warning and an -EFAULT BPF_PROG_LOAD.  These legacy packet-load instructions are deprecated. Reject them from callbacks rather than complicating their implicit-return model. Check all active frames before constructing the implicit return so nested static subprograms cannot hide the callback context.  Global functions are verified independently with a fresh frame zero, so an active-frame check cannot identify a global function called from a callback. Also check the complete subprogram call graph during stack-depth validation and reject a function containing a legacy load when any caller is a callback. This covers global and static descendants without making has_ld_abs transitive, preserving its per-function BTF return-type check. Ordinary uses outside callbacks remain supported.

CVE-2026-98056:

        In the Linux kernel, the following vulnerability has been resolved:  nvme: remove stale namespaces by NSID range during scan  nvme_scan_ns_list() drops the stale namespaces in each gap in the reported NSID list one NSID at a time. Every iteration calls nvme_find_get_ns() to look the namespace up and removes it if it is present. The loop runs once per NSID in the gap rather than once per namespace actually present.  NSIDs are 32-bit, so a target with a sparse NSID space can make a single gap spin the loop billions of times with nothing to remove.    watchdog: BUG: soft lockup - CPU#4 stuck for 26s!   Workqueue: nvme-wq nvme_scan_work [nvme_core]   RIP: 0010:__srcu_read_unlock+0xb/0x20   Call Trace:    nvme_find_get_ns+0x7d/0xb0 [nvme_core]    nvme_scan_ns_list+0xe8/0x280 [nvme_core]    nvme_scan_work+0x18a/0x280 [nvme_core]    process_one_work+0x197/0x380    worker_thread+0x2fe/0x410    kthread+0xe0/0x100  Rename nvme_remove_invalid_namespaces() to nvme_remove_nsid_range() and give it an open (start, end) NSID range. ctrl->namespaces is sorted by NSID, so the whole gap is dropped in a single walk that stops once end is reached. This bounds the work by the namespaces that are present instead of by the size of the gap.

CVE-2026-98058:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: Mark syscall helpers as sleepable  bpf_sys_bpf() executes the bpf(2) syscall body, which can take mutexes, allocate with GFP_KERNEL, and wait for an RCU grace period. bpf_sys_close() reaches close_fd() and filp_close(), which can sleep as well.  Both helpers are limited to BPF_PROG_TYPE_SYSCALL, whose main program is sleepable. That does not make every callback sleepable: a syscall program can register a bpf_timer callback, and the verifier checks that callback in a non-sleepable context while retaining the syscall helper set.  Without .might_sleep on the prototypes, such a callback can invoke bpf_sys_bpf() from hrtimer softirq context and trigger a scheduling-while-atomic failure. bpf_sys_close() is exposed through the same missing context check.  Set .might_sleep on both prototypes so the existing helper-context check rejects them from timer callbacks and other atomic regions. Calls from the sleepable main body remain valid.

CVE-2026-98067:

        In the Linux kernel, the following vulnerability has been resolved:  erofs: disable LZ4 rolling decompression for now  LZ4 rolling decompression [1] was introduced to reduce the memory footprint of temporary pages:   For many cases, it is needed for users to read small data within  a compressed extent (pcluster), either due to random small read, or  since uptodate folios (typically order-0) cannot be reused for  decompression again since decompression algorithm refills  already-uptodate folios.  Rolling decompression works because LZ4 is LZ77-based and only refers to the most recent 64 KiB of decompressed data, so in theory only a bounded rolling window of temporary pages is needed when decompressing.  It can save a lot of temporary memory, e.g.  601,960-byte data can be compressed into a 256k LZ4 compressed extent,  which means it needs 146 extra pages per request in the worst case if  rolling decompression is disabled.  However, the upstream LZ4 implementation is not under EROFS' control: For example, the literal copy memmove() may still **copy long literals backward** on x86 based on the address comparison even when the source and destination ranges do not overlap (IOWs, inline decompression doesn't need to be considered here). That breaks the rolling assumption and makes the optimization broken.  Disable it for now to make sure the data correctness first since EROFS is used everywhere now: The rolling window approach can be revived once we either ensure that the official LZ4 code always copies forward for non-overlapping ranges or maintain our own LZ4 implementation in EROFS.  The main impact is a higher runtime memory footprint; However, recent commit 0f6273ab4637 ("erofs: add a reserved buffer pool for lz4 decompression") helps mitigate this when enabled but it's still not perfect.  [1] https://www.usenix.org/conference/atc19/presentation/gao     § 3.3 Decompression

CVE-2026-98073:

        In the Linux kernel, the following vulnerability has been resolved:  net: Remove conflicting altnames for dying netns in __dev_change_net_namespace().  syzbot reported the warning in cfg80211_pernet_exit(). [0]  The repro does the following:    1. create two device in root netns and non-root netns   2. assign the same altname for the two devices   3. remove the non-root netns  Since commit 7663d522099e ("net: check for altname conflicts when changing netdev's netns"), cfg80211_switch_netns() and cfg802154_switch_netns() fail if init_net has a device with the conflicting altname.  default_device_exit_net() had the same issue and commit d09486a04f5d ("net: fix removing a namespace with conflicting altnames") fixed it.  cfg80211_pernet_exit() and cfg802154_pernet_exit() need the same fix.  Let's generalise the fix by removing conflicting altnames for dying netns in __dev_change_net_namespace().  [0]: cfg80211_switch_netns(rdev, &init_net) WARNING: net/wireless/core.c:1871 at cfg80211_pernet_exit+0xd5/0x120 net/wireless/core.c:1871, CPU#1: kworker/u8:9/1160 Modules linked in: CPU: 1 UID: 0 PID: 1160 Comm: kworker/u8:9 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/24/2026 Workqueue: netns cleanup_net RIP: 0010:cfg80211_pernet_exit+0xd5/0x120 net/wireless/core.c:1871 Code: e8 03 42 80 3c 20 00 74 08 4c 89 f7 e8 b4 ef 0e f7 4d 8b 36 49 81 fe 20 10 4a 90 74 12 e8 03 3d 9f f6 eb 85 e8 fc 3c 9f f6 90 <0f> 0b 90 eb cc e8 f1 3c 9f f6 eb 05 e8 ea 3c 9f f6 5b 41 5c 41 5e RSP: 0018:ffffc900057a78f0 EFLAGS: 00010293 RAX: ffffffff8b287154 RBX: ffff88807ba72780 RCX: ffff8880213e8000 RDX: 0000000000000000 RSI: 00000000ffffffef RDI: 0000000000000000 RBP: 00000000ffffffef R08: ffffffff9024cc67 R09: 0000000000000000 R10: fffff52000af4eb0 R11: fffffbfff204998d R12: dffffc0000000000 R13: ffffffff904a1080 R14: ffff888144ed0008 R15: ffff888144ed0e20 FS:  0000000000000000(0000) GS:ffff888124de6000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005642de0a8a70 CR3: 000000007a40c000 CR4: 00000000003526f0 Call Trace:  <TASK>  ops_exit_list net/core/net_namespace.c:200 [inline]  ops_undo_list+0x43d/0x8d0 net/core/net_namespace.c:253  cleanup_net+0x572/0x810 net/core/net_namespace.c:706  process_one_work kernel/workqueue.c:3387 [inline]  process_scheduled_works+0xc3d/0x1630 kernel/workqueue.c:3470  worker_thread+0xa47/0xfb0 kernel/workqueue.c:3551  kthread+0x38b/0x480 kernel/kthread.c:436  ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245  </TASK>

CVE-2026-98079:

        In the Linux kernel, the following vulnerability has been resolved:  btrfs: zstd: fix lost wakeup when waiting for a workspace  A writer can sleep forever in zstd_get_workspace() even though a workspace is free.  When zstd_alloc_workspace() fails, the task is queued on zwsm->wait and schedules unconditionally, never re-testing the pool. zstd_put_workspace() publishes the workspace and then calls cond_wake_up(), which only wakes when a sleeper is already visible, so a workspace returned between the failed allocation and prepare_to_wait() wakes nobody.  The window is wide: zstd_alloc_workspace() goes through kvmalloc() and may enter reclaim.  Only a max level workspace triggers the wakeup and one is deliberately kept allocated as the fallback every waiter waits for, so once its wakeup is lost the writer stays in TASK_UNINTERRUPTIBLE until some other task happens to return one.  Re-check the pool after prepare_to_wait() has published the waiter, and use the workspace if one turned up.

CVE-2026-98081:

        In the Linux kernel, the following vulnerability has been resolved:  btrfs: zoned: finish active block group cleanup if call_zone_finish() fails  do_zone_finish() clears BLOCK_GROUP_FLAG_ZONE_IS_ACTIVE before finishing the zones. If call_zone_finish() then fails it returned early, leaving the now inactive block group on fs_info->zone_active_bgs, leaking its reference, the BTRFS_FS_NEED_ZONE_FINISH waiters are never woken, and as its alloc_offset equals the zone capacity btrfs_zone_finish_one_bg() keeps selecting it, spinning btrfs_zoned_activate_one_bg().  Fall through to the cleanup on failure too and return the error, but keep the block group read-only as its zones are left inconsistent.

CVE-2026-98085:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: backtrack_insn(): Handle ld_{abs,ind} subprog exit edge  Nicholas Carlini reported a bug in precision backtracking mechanism for BPF_LD | BPF_{IND,ABS} instructions. These instructions are modelled as two branches: - fallthrough; - implicit exit from current subprogram.  The implicit exit case was not handled by the backtrack_insn() function. When backtracking such a path backtrack_insn() did not call bt_subprog_enter(), which meant that backtracking continued manipulating precision marks in a caller frame, while looking at instructions in a callee frame.  This lead to segmentation faults during verification (see the selftest), or unsound state pruning.

CVE-2026-98087:

        In the Linux kernel, the following vulnerability has been resolved:  sched/rt,dl: Skip migrate-disabled tasks when picking a push candidate  A migrate_disable()'d RT task cannot be moved to another CPU, but the scheduler still keeps such a task on that CPU's pushable list (rq->rt.pushable_tasks) and still marks the runqueue RT-overloaded (rq->rt.overloaded = 1). So the RT balancer keeps treating this CPU as having a task to move away, and keeps trying to move the task, but the push can never succeed. When the head is pinned, push_rt_task() does not give up either. It falls back to pushing rq->curr instead, using the per-CPU stopper, as added by commit a7c81556ec4d ("sched: Fix migrate_disable() vs rt/dl balancing").  The CPU spends tens of milliseconds in this retry loop. The core is isolated for real-time work, but during the loop nearly half of its time is consumed by pushes that cannot succeed.  An ftrace capture of the affected CPU, with sched_switch enabled and commit 94894c9c477e ("sched/rt: Skip currently executing CPU in rto_next_cpu()") applied, shows where the CPU time went. Two SCHED_FIFO tasks at equal priority shared the CPU, taskA migrate_disable()'d and queued, taskB as rq->curr. In one 89 ms window, taskB got only 52 ms of CPU. The other 37 ms went to the stopper thread.  The scheduler kept trying to push taskA, the pinned head of the pushable list, fell back to pushing taskB instead, and woke the stopper 5204 times. Every one of those pushes failed and no task was moved. taskA stayed runnable and queued the whole time, and never ran.  Pushing taskB fails on a re-check. find_lock_lowest_rq() drops the rq lock to take the target rq lock, then checks again with "task != pick_next_pushable_task(rq)".  The task being pushed is taskB, but the pick returns taskA, the head of the pushable list. taskB is rq->curr, and set_next_task_rt() removes the running task from that list, so taskB can never be the head. The check expects a candidate taken from the pushable list, but the fallback pushes rq->curr, which is never on that list. So the check fails every time.     .--> push-IPI arrives    |          |    |          v    |     pushable head = taskA   ->  pinned, cannot be pushed    |          |    |          v    |     so push taskB instead   ->  wake migration/N, a stop-class    |          |                      thread, so it preempts taskB    |          v    |     re-check compares taskB against the pushable head,    |     which is still taskA                        ->  give up    |          |    |          v    |     nothing moved, taskA still queued, rq still overloaded    |          |    '----------'          repeats every ~17 us, 5204 times, for 89 ms     The loop cannot stop itself. Every round leaves the runqueue    exactly as it was, so the next push-IPI does the same thing. In    the capture it ended only when taskB went to sleep on its own.    taskA was then picked locally and left the pushable list.     CPU time per task in the window, from sched_switch:       taskB         51.95 ms   real work      migration/N   37.18 ms   nothing moved      taskA          0.00 ms   queued the whole time, never picked      idle           0.01 ms     Counts over the same window:        7667  push-IPIs handled on this CPU      17481  pick_next_pushable_task() returned taskA, still pinned       5204  find_lock_lowest_rq() gave up on the re-check          1  push that actually completed          0  migrations of taskA     The CPU times and the window length come from the standard    sched_switch tracepoint. The counts needed tracepoints added inside    the RT balancer for this investigation.  The self-IPI path is closed by the rto_next_cpu() fix above, and that part works. But the runqueue is still marked overloaded, because the pinned task is still advertised as pushable. Other CPUs now send the push-IPIs during their own RT balancing, and the same loop runs again. Closing the self-IPI path did not stop a pinn ---truncated---

CVE-2026-98097:

        In the Linux kernel, the following vulnerability has been resolved:  tipc: Dont send random pad bytes in RESET/ACTIVATE messages  The interface name is passed in a fixed length (TIPC_MAX_IF_NAME) buffer. Replace the strcpy(data, l->if_name) with memcpy() so that the pad bytes are actually written (l->if_name[] is zero padded) rather than sending random bytes from the skb to the remote system.  Replace two other strcpy() with strscpy().

CVE-2026-98099:

        In the Linux kernel, the following vulnerability has been resolved:  ipv6: mcast: use rcu_assign_pointer() for __rcu list updates  Several places in net/ipv6/mcast.c update RCU-protected lists (np->ipv6_mc_list, idev->mc_list, idev->mc_tomb) using direct pointer assignments instead of rcu_assign_pointer():  1. In __ipv6_dev_mc_dec(), unlinking a group from idev->mc_list did:        *map = ma->next;    without rcu_assign_pointer() while concurrent readers traverse    idev->mc_list locklessly under rcu_read_lock(). 2. In ipv6_sock_mc_drop() and __ipv6_sock_mc_close(), unlinking a group    from np->ipv6_mc_list directly assigned *lnk = mc_lst->next and    np->ipv6_mc_list = mc_lst->next without rcu_assign_pointer(), racing    with lockless readers in inet6_mc_check(). 3. In __ipv6_sock_mc_join(), mc_lst->next was initialized to    np->ipv6_mc_list via raw assignment before publishing mc_lst. 4. In mld_del_delrec() and __ipv6_dev_mc_inc(), __rcu source pointers    passed into rcu_assign_pointer() lacked explicit dereference helpers.  Fix these by consistently using rcu_assign_pointer() along with mc_dereference() / sock_dereference().

CVE-2026-98101:

        In the Linux kernel, the following vulnerability has been resolved:  ipv6: mcast: use copy-on-write RCU updates in ip6_mc_source()  pmc->sflist is read locklessly under rcu_read_lock() by inet6_mc_check() during packet reception in the UDP and RAW multicast receive paths.  ip6_mc_source() mutated psl->sl_addr and psl->sl_count in-place when adding or removing a source filter. Additionally, when expanding the filter buffer, newpsl was published via rcu_assign_pointer() before writing the new source into the array.  Because 16-byte struct in6_addr writes are not atomic and array shifting is not synchronized with RCU readers, concurrent readers in inet6_mc_check() could read torn IPv6 addresses or observe duplicated/missed source entries.  Fix this by switching ip6_mc_source() to copy-on-write RCU updates: allocate and fully populate newpsl before publishing it via rcu_assign_pointer(), and reclaim the old filter via kfree_rcu(), matching ip6_mc_msfilter().  Also remove the now unused IP6_SFBLOCK macro.

CVE-2026-98102:

        In the Linux kernel, the following vulnerability has been resolved:  ipv6: mcast: fix RCU list diversion in ip6_mc_del1_src()  When removing a source filter whose count reaches zero, ip6_mc_del1_src() unlinks psf from pmc->mca_sources. If the filter was previously active, the code moved psf directly into pmc->mca_tomb by updating psf->sf_next.  Because pmc->mca_sources is traversed locklessly under RCU (e.g. by ipv6_chk_mcast_addr()), mutating psf->sf_next before a grace period elapses diverts concurrent readers to the tombstone list. Consequently, readers miss remaining active sources in pmc->mca_sources and improperly examine deleted tombstone entries.  Fix this by allocating a new tombstone node for pmc->mca_tomb (as done in sf_setstate()) and retiring the original psf via kfree_rcu().

CVE-2026-98103:

        In the Linux kernel, the following vulnerability has been resolved:  igmp: convert struct ip_sf_list to RCU  Commit 23d2b94043ca ("igmp: Add ip_mc_list lock in ip_check_mc_rcu") added spin_lock_bh(&im->lock) to ip_check_mc_rcu() to prevent a use-after-free while iterating im->sources during concurrent deletions.  However, ip_check_mc_rcu() is called from RCU read-side critical sections in packet receive and route lookup fast paths (e.g. __mkroute_output(), ip_route_input_rcu(), and __udp4_lib_rcv()).  When igmpv3_send_cr() or igmpv3_send_report() holds &pmc->lock and calls add_grec() -> igmpv3_newpack() -> ip_route_output_ports(), an XFRM policy matching a multicast destination triggers xfrm_tmpl_resolve_one() -> xfrm4_get_saddr() -> __mkroute_output() -> ip_check_mc_rcu(). This attempts to acquire &im->lock while &pmc->lock is already held on the same CPU, triggering a lockdep recursive locking warning / deadlock.  Fix this by converting IPv4 struct ip_sf_list to RCU, mirroring the IPv6 implementation in net/ipv6/mcast.c:  1. Add struct rcu_head to struct ip_sf_list and annotate sf_next,    sources, and tomb as __rcu pointers. 2. Use rcu_assign_pointer() and kfree_rcu() for list updates and    deletions. 3. Remove spin_lock_bh(&im->lock) from ip_check_mc_rcu() and traverse    im->sources locklessly with for_each_psf_rcu(), reading and writing    counter fields with READ_ONCE() and WRITE_ONCE().  Note: RCU conversion of /proc/net/mcfilter will be done in a separate patch.

CVE-2026-98107:

        In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: L2CAP: fix out-of-bounds write in l2cap_ecred_connect  l2cap_chan_connect() tries to ensure there are no more than L2CAP_ECRED_CONN_SCID_MAX pending ECRED channels, so they fit in the same L2CAP_ECRED_CONN_REQ that l2cap_ecred_connect() constructs.  However, the check only counts deferred channels.  If 6 L2CAP sockets are connected at the same time in order DDDDND (D=deferred, N=non-deferred), the last can bump the total to max+1.  It results to one __le16 written out of bounds of the scid array, and an invalid ECRED_CONN_REQ being sent.  Fix by leaving room for the non-deferred pending ECRED channels in the counting in l2cap_chan_connect(), so the limit can't be exceeded.  Move counting under same critical section where the channel is added. Although race conditions involving this appear unreachable, it's easier to see.  Also add WARN_ON_ONCE check in l2cap_ecred_defer_connect() to make this less brittle.

CVE-2026-98111:

        In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: btintel: validate version TLV value lengths  btintel_parse_version_tlv() verifies that a complete TLV is present in the response, but it does not ensure that the value is long enough for the specific TLV type. A short value can therefore cause an out-of-bounds read through get_unaligned_le16(), get_unaligned_le32(), or memcpy().  Reject values shorter than the minimum required by each known TLV type. Also reject responses that do not contain the Command Complete Status field.

CVE-2026-98114:

        In the Linux kernel, the following vulnerability has been resolved:  ksmbd: propagate DACL parsing errors  parse_dacl() silently accepts truncated ACEs and allocation failures, allowing set_info_sec() to continue with an incomplete ACL conversion.  Return parsing and allocation errors to parse_sec_desc() so malformed security descriptors are rejected before inode attributes or ACL xattrs are updated.

CVE-2026-98124:

        In the Linux kernel, the following vulnerability has been resolved:  smb/client: invalidate fscache for fallocate range operations  smb3_zero_range(), smb3_punch_hole(), smb3_insert_range(), and smb3_collapse_range() modify file contents through server-side range operations. These operations discard the affected page cache, but leave the FS-Cache cookie valid, so a later read may return data cached before the range operation.  Fix this by invalidating FS-Cache after outstanding I/O has completed and before modifying the file on the server.  Run the following as root on a CIFS mount with fsc enabled and an active CacheFiles backend:          bash -c '                 MNT=/mnt/cifs                 FILE="$MNT/repro"                  # Generate four 1 MiB random blocks: [A][B][C][D].                 dd if=/dev/urandom of=/tmp/src bs=1M count=4 status=none                  # Expected contents after zeroing B: [A][zero][C][D].                 cp /tmp/src /tmp/expected                 dd if=/dev/zero of=/tmp/expected bs=1M seek=1 count=1 \                         conv=notrunc status=none                 cp /tmp/src "$FILE"                  # Populate FS-Cache, then discard the page cache.                 sync                 echo 1 > /proc/sys/vm/drop_caches                 cat "$FILE" > /dev/null                 sync                 echo 1 > /proc/sys/vm/drop_caches                  fallocate --zero-range -o 1M -l 1M "$FILE"                  if cmp -s /tmp/expected "$FILE"; then                         echo "readback: OK"                 else                         echo "readback: STALE DATA"                 fi         '  Before this change, the readback differs from /tmp/expected:          readback: STALE DATA  After this change, it matches:          readback: OK

CVE-2026-98125:

        In the Linux kernel, the following vulnerability has been resolved:  smb/client: fix stale page cache in insert/collapse range  smb3_insert_range() and smb3_collapse_range() use truncate_pagecache_range() to invalidate the affected page cache. However, if off or old_eof is not page-aligned, the boundary pages are only partially zeroed and remain uptodate. As a result, the client may return stale data after a successful insert/collapse range operation.  For example, with 4K pages:      page 0          page 1          page 2     0------4K       4K------8K      8K------12K        ^                                ^     off=2K                       old_eof=10K  Page 1 is removed from the page cache, while the boundary pages are only partially zeroed. After COPYCHUNK moves the data on the server, these cached pages may still return stale data.  This can be reproduced on a CIFS mount:      bash -c '             FILE=/mnt/scratch/repro              # Use a 6 KiB file so EOF is not page-aligned.             dd if=/dev/urandom of=/tmp/src bs=1K count=6 status=none              # Expected: a 4 KiB hole followed by the original data.             rm -f /tmp/expected             truncate -s 4K /tmp/expected             cat /tmp/src >> /tmp/expected              cp /tmp/src "$FILE"              # Prime the page cache before moving data on the server.             cat "$FILE" > /dev/null              fallocate --insert-range -o 0 -l 4K "$FILE"              if cmp -s /tmp/expected "$FILE"; then                     echo "readback: OK"             else                     echo "readback: STALE DATA"             fi     '  Fix this by writing back dirty data and discarding the page cache from the start of the page containing off to EOF before moving data on the server.

CVE-2026-98126:

        In the Linux kernel, the following vulnerability has been resolved:  smb/client: validate new EOF for zero range  When FALLOC_FL_ZERO_RANGE is used without FALLOC_FL_KEEP_SIZE, smb3_zero_range() may extend EOF without checking RLIMIT_FSIZE, allowing the file to grow beyond the caller's file-size limit.  Fix this by calling inode_newsize_ok() before sending the zero-range request when the operation would extend EOF.  Reproducer, using a file on a CIFS mount:  	bash -c ' 	        FILE=/mnt/cifs/repro  	        trap "" SIGXFSZ 	        ulimit -f 3072  	        truncate -s 2M "$FILE" 	        fallocate --zero-range -o 0 -l 4M "$FILE" 	        echo "fallocate rc=$?" 	        stat -c "file size=%s" "$FILE" 	'  Before this change, the operation succeeds despite the 3 MiB limit:  	fallocate rc=0 	file size=4194304  After this change, fallocate fails and leaves the file at 2 MiB.

CVE-2026-98127:

        In the Linux kernel, the following vulnerability has been resolved:  smb/client: validate new EOF for insert range  smb3_insert_range() does not check if the new file size (i_size + len) is valid. This allows FALLOC_FL_INSERT_RANGE to bypass RLIMIT_FSIZE, exceed s_maxbytes, or produce a size outside the loff_t range.  Use check_add_overflow() to calculate the new EOF. Validate it with inode_newsize_ok() before modifying the file.  Reproducer, using a file on a CIFS mount:  	bash -c ' 		FILE=/mnt/cifs/repro  		trap "" SIGXFSZ 		ulimit -f 3072		# RLIMIT_FSIZE = 3 MiB  		# A regular write is stopped at 3 MiB. 		dd if=/dev/zero of="$FILE" bs=1M count=4 status=none 		stat -c "size after write: %s" "$FILE"  		# Insert 2 MiB into a 2 MiB file. 		truncate -s 2M "$FILE" 		fallocate -i -o 0 -l 2M "$FILE" 		stat -c "size after insert: %s" "$FILE" 	'  Before this change, the regular write stops at the 3 MiB limit, but insert range grows the file to 4 MiB:  	dd: error writing '/mnt/cifs/repro': File too large 	size after write: 3145728 	size after insert: 4194304  After this change, insert range also fails at the limit and leaves the 2 MiB file unchanged:  	dd: error writing '/mnt/cifs/repro': File too large 	size after write: 3145728 	fallocate: fallocate failed: File too large 	size after insert: 2097152

CVE-2026-98131:

        In the Linux kernel, the following vulnerability has been resolved:  net: stmmac: fix dma mapping leak in stmmac_tso_xmit()  In stmmac_tso_xmit(), if the DMA mapping of an skb fragment fails, the frame is dropped but the DMA mappings already created for the linear part and for the fragments mapped before the failure are never unmapped, leaking DMA mappings.  Fix the leak by walking back over the descriptors used by the frame and releasing each of them with stmmac_free_tx_buffer(). Moreover, release the descriptors with stmmac_release_tx_desc() unmapping the DMA buffers.

CVE-2026-98142:

        In the Linux kernel, the following vulnerability has been resolved:  drm/cirrus-qemu: Validate BAR0 size during probe  The `cirrus-qemu` driver relies on `CIRRUS_VRAM_SIZE` (4 MB) to validate framebuffer sizes. However, during PCI probe, the driver mapped BAR0 without verifying that its size matches `CIRRUS_VRAM_SIZE`.  If a PCI device with a BAR0 smaller than 4 MB is bound to the driver, the mapped VRAM will be smaller than expected. Because validation checks assume 4 MB VRAM, framebuffers larger than the mapped memory can be created.  When the display plane is updated (e.g. during release), `cirrus_primary_plane_helper_atomic_update()` copies the framebuffer to VRAM using `drm_fb_memcpy()`. Writing past the end of the mapped I/O memory causes a supervisor write page fault:  BUG: unable to handle page fault for address: ffffc9000389c000 ... RIP: 0010:memcpy_toio+0x7c/0xe0 arch/x86/lib/iomem.c:110 ... Call Trace:  <TASK>  iosys_map_memcpy_to include/linux/iosys-map.h:285 [inline]  drm_fb_memcpy+0x325/0x5d0 drivers/gpu/drm/drm_format_helper.c:442  cirrus_primary_plane_helper_atomic_update+0x98a/0xb00  drivers/gpu/drm/tiny/cirrus-qemu.c:358  drm_atomic_helper_commit_planes+0x626/0xea0  drivers/gpu/drm/drm_atomic_helper.c:3038  drm_atomic_helper_commit_tail+0x60/0x510  drivers/gpu/drm/drm_atomic_helper.c:1989  commit_tail+0x2b1/0x3c0 drivers/gpu/drm/drm_atomic_helper.c:2074  drm_atomic_helper_commit+0xa77/0xb10  drivers/gpu/drm/drm_atomic_helper.c:2312  Fix this by validating in `cirrus_pci_probe()` that the PCI BAR0 resource is not less than `CIRRUS_VRAM_SIZE`, returning `-ENODEV` if it is less.

CVE-2026-98148:

        In the Linux kernel, the following vulnerability has been resolved:  drm/gud: validate GUD_ROTATION_0 is present in supported rotations  The rotation argument to drm_plane_create_rotation_property() is set to DRM_MODE_ROTATE_0, and the device reported rotation bitmask is used as the supported_rotations argument. The driver never validates that GUD_ROTATION_0 is present, so a device that omits it from its GUD_PROPERTY_ROTATION triggers the WARN_ON(rotation & ~supported_rotations) in drm_plane_create_rotation_property()  Fix this by skipping the creation of rotation property if the device doesn't have the GUD_ROTATION_0 bit

CVE-2026-98156:

        In the Linux kernel, the following vulnerability has been resolved:  drm/virtio: use the DMA API for resource backing on Xen  On a Xen PV domain page addresses bear no relation to the real machine addresses the host would have to use to reach it. virtio_ring.c handles this correctly, vring_use_map_api() returns true for any xen_domain() regardless of VIRTIO_F_ACCESS_PLATFORM.  virtio-gpu makes the same decision independently, but its copy looks only at the feature bit:  	bool use_dma_api = !virtio_has_dma_quirk(vgdev->vdev);  QEMU does not set iommu_platform on virtio-vga by default, so VIRTIO_F_ACCESS_PLATFORM is not negotiated, use_dma_api is false, and virtio_gpu_object_shmem_init() describes the framebuffer's backing pages to the host with sg_phys().  Those are guest-physical addresses. In a PV domain they resolve, on the host side, to pages belonging to some other domain, so the host scans out unrelated memory.  Move the decision into virtio_gpu_use_dma_api() and give it the xen_domain() check, like vring_use_map_api() has. This additionally enables the dma_sync_sgtable_for_device() calls in virtgpu_vq.c, which are required for correctness whenever swiotlb is in play.  Reproduced with a Xen 4.21 PV dom0 nested inside QEMU 8.2 with virtio-vga, on both a distro 6.8 kernel and 6.18 LTS. A PVH dom0 works fine and doesn't need this fix because it is identity-mapped, only PV dom0s are affected.

CVE-2026-98161:

        In the Linux kernel, the following vulnerability has been resolved:  nvdimm: pmem: keep PREFLUSH before data writes  pmem_submit_bio() records a REQ_PREFLUSH error, but continues to copy the bio data and can later overwrite the error with a successful REQ_FUA flush. That lets data writes run after a failed preflush and can complete the bio successfully despite the failed ordering barrier.  Run the REQ_PREFLUSH flush synchronously before touching the bio data and complete the bio with the flush error if it fails. Keep asynchronous flush chaining for REQ_FUA. At that point, data copy has completed and the parent bio can wait for the chained flush bio.

CVE-2026-98162:

        In the Linux kernel, the following vulnerability has been resolved:  smb/server: fix tree connection leak in smb2_tree_connect()  See the procedure below:    smb2_tree_connect     ksmbd_tree_conn_connect       xa_store(&sess->tree_conns, tree_conn->id, tree_conn)       ksmbd_counter_inc(KSMBD_COUNTER_TREE_CONNS)       ksmbd_share_tree_conn_inc(sc)     ksmbd_iov_pin_rsp // fail     status.ret = KSMBD_TREE_CONN_STATUS_NOMEM     // do not disconnect tree_conn  Disconnect the new tree connection if ksmbd_iov_pin_rsp() fails.

CVE-2026-98170:

        In the Linux kernel, the following vulnerability has been resolved:  smb: client: fix OOB struct field reads in move_smb2_ea_to_cifs()  In move_smb2_ea_to_cifs(), the while (src_size > 0) loop condition is insufficient. It allows iteration to continue even if the remaining src_size is too small to contain a complete smb2_ea_info structure. Consequently, reads of ea_name_length and ea_value_length can occur out-of-bounds.  Fix this by ensuring src_size >= sizeof(*src) before attempting to read any structure fields. Additionally, reject any next_entry_offset that is smaller than sizeof(*src) or that would advance the pointer beyond the available buffer.  Note that for calls where the server returns a malformed EA list, the error returned to userspace changes from -ENODATA (getxattr) or -ERANGE (listxattr) to -EIO. This correctly signals a server protocol error rather than misleadingly indicating "attribute not present" or "output buffer too small".

CVE-2026-98173:

        In the Linux kernel, the following vulnerability has been resolved:  smb: client: fix use-after-free of iface in cifs_try_adding_channels()  cifs_try_adding_channels() iterates ses->iface_list with list_for_each_entry_safe_from(), which captures the next entry (niface) under iface_lock.  The loop body then drops iface_lock for the whole duration of cifs_ses_add_channel().  A concurrent interface refresh (SMB3_request_interfaces() -> parse_server_interfaces()) marks all ifaces inactive and removes and frees any that are not re-advertised via list_del() + kref_put(), where release_iface() is a bare kfree().  Since niface typically has no channel holding a reference, the list reference is its last and it can be freed inside the unlocked window.  On continue, the iterator advance step then dereferences niface->iface_head.next, and the loop body reads iface->rdma_capable/is_active, both on freed memory.  Fix this by never keeping an unreferenced list pointer across the unlocked window.  Each channel attempt now re-scans the list from the head under iface_lock, takes a kref on the selected candidate, and passes only that referenced candidate to cifs_ses_add_channel(). weight_fulfilled still tracks selection progress, so restarting the scan preserves the original weighted distribution and the weight_fulfilled-before-kref_put ordering on the failure path.  Add a per-pass attempts cap so a flapping interface refresh cannot keep the inner loop spinning within a single tries increment.

CVE-2026-98174:

        In the Linux kernel, the following vulnerability has been resolved:  smb: client: fix rlist race and missing initialization  TCP_Server_Info.rlist is allocated via kzalloc which zeros both ->next and ->prev to NULL instead of pointing to itself, making list_empty() always return false and list_add() dereference a NULL ->prev pointer.  Also, cifs_signal_cifsd_for_reconnect() can be called concurrently from multiple cifsd threads, allowing the same server's rlist node to be added twice into the local list, corrupting it.

CVE-2026-98175:

        In the Linux kernel, the following vulnerability has been resolved:  smb: client: cancel reconnect work in clean_demultiplex_info()  clean_demultiplex_info() cancels server->echo delayed work but not server->reconnect, which can cause a use-after-free when the demultiplex thread exits while a reconnect work is still queued:    cifs_demultiplex_thread()     cifs_readv_from_socket()       cifs_reconnect()         __cifs_reconnect()           cifs_queue_server_reconn()             mod_delayed_work(cifsiod_wq, &server->reconnect, 0)     clean_demultiplex_info()       cancel_delayed_work_sync(&server->echo)   // echo canceled                                                  // reconnect NOT canceled       kfree_sensitive(server)                    // server freed    ...later, on cifsiod_wq:    smb2_reconnect_server()     server->srv_count  // UAF read of freed server  Fix this by canceling server->reconnect delayed work in clean_demultiplex_info() before the server is freed, the same way cifs_put_tcp_session() already does.

CVE-2026-98176:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdkfd: Avoid integer underflow with ffs in EOP ring size calc  The low 6 bits of cp_hqd_eop_control store the base-2 logarithm of the EOP ring size. This was calculated as  ffs(q->eop_ring_buffer_size / sizeof(unsigned int)) - 1 - 1  But ffs can in theory return 1 or 0, so this could underflow (although in practice the ring buffer size cannot be less than 4096).  Change this to  ffs(q->eop_ring_buffer_size / sizeof(unsigned int) / 4)  using properties of logarithms.  (cherry picked from commit 4f18c56630383c14bfc6b2d65f88f2f895d2121a)

CVE-2026-98177:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdkfd: Avoid integer underflow in EOP ring size calculation.  The low 6 bits of cp_hqd_eop_control store the base-2 logarithm of the EOP ring size. This was calculated as  order_base_2(q->eop_ring_buffer_size / 4) - 1  But order_base_2 can in theory return 0, so this could underflow (although in practice the ring buffer size cannot be less than 4096).  Change this to  order_base_2(q->eop_ring_buffer_size / 8)  using properties of logarithms.  Also add to the above comment to make the mathematics more clear.  (cherry picked from commit f0f43fcf8b2b3a924cad9444340921c96ed5f634)

CVE-2026-98179:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu: fix rmmio iounmap skipped on device removal  amdgpu_pci_remove() calls drm_dev_unplug() before fini_sw(), so drm_dev_enter() is already false there and the iounmap() guarded by it is skipped. This .remove path runs on both hot-unplug and plain rmmod, so the register BAR ioremap mapping leaks one instance per unload.  Unmap rmmio unconditionally (guard only on non-NULL) and drop the now unused idx.  (cherry picked from commit dd6f86a97260e5207d3329ad03aa89fdad61b1e6)

CVE-2026-98180:

        In the Linux kernel, the following vulnerability has been resolved:  drm/msm: RCU-free the scheduler-containing ring and VM objects  Both struct msm_ringbuffer and struct msm_gem_vm embed a struct drm_gpu_scheduler.  msm_ringbuffer_destroy() and the VM free callback msm_gem_vm_free() call drm_sched_fini() on the embedded scheduler and then free the containing object with plain kfree().  drm_sched_fence_get_timeline_name() returns fence->sched->name, and the scheduler fence keeps a .release callback so it is not ops-detached on signalling.  A finished fence exported to userspace (the submit out-fence, or a VM_BIND fence, via sync_file / drm_syncobj) keeps pointing at the embedded scheduler after the ring/VM is freed, so a later get_timeline_name() -- reachable unprivileged through SYNC_IOC_FILE_INFO -- dereferences freed slab memory (KASAN slab-use-after-free read).  Per the dma-fence lifetime contract the exporter must keep the data backing a signalled fence alive for an RCU grace period.  Free the scheduler-containing objects with kfree_rcu() instead of kfree().  Patchwork: https://patchwork.freedesktop.org/patch/750234/

CVE-2026-98182:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: mac80211: refuse to make a monitor active when it has no queue  A monitor interface only gets a TXQ if it's created active, and one can't be added later. Setting the flag on a down interface is still allowed, so the driver is handed a monitor with no queue. ath9k dereferences it:    BUG: kernel NULL pointer dereference, address: 0000000000000066   RIP: 0010:ath_tx_node_init+0x49/0x170 [ath9k]    ath9k_add_interface+0x10c/0x140 [ath9k]    drv_add_interface+0x54/0x250 [mac80211]    ieee80211_do_open+0x32f/0x800 [mac80211]  Reached with CAP_NET_ADMIN by "iw dev X set monitor active" followed by "ip link set X up". RTNL is held, so netlink operations block behind it.  Refuse the flag when there is no queue to give.

CVE-2026-98192:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: wcn36xx: Fix potential use-after-free in TX ack timer teardown  wcn36xx_dxe_deinit() tears down the TX ack timer with timer_delete(), which only dequeues the timer and does not wait for a callback that is already executing; the preceding free_irq() calls synchronize the interrupt handlers only. The callback, wcn36xx_dxe_tx_timer(), can therefore be running past the teardown and use the wcn freed along with the ieee80211_hw in wcn36xx_remove(): it takes wcn->dxe_lock, reads wcn->tx_ack_skb and passes wcn->hw to ieee80211_tx_status_irqsafe().  Fix this by using timer_shutdown_sync(), which waits for a running callback and also prevents the timer from being rearmed again. The timer is set up again by wcn36xx_dxe_init() on the next start, so the start/stop cycle is unaffected.  This issue was found by an in-house static analysis tool.

CVE-2026-98193:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: libipw: reject TKIP frames without a full MIC  libipw_michael_mic_verify() assumes that an skb contains an eight-byte Michael MIC. A short TKIP frame makes the unsigned payload length wrap, causing michael_mic() to read past the skb.  Check that the MIC is present before verifying it, and use the existing MICHAEL_MIC_LEN constant for all MIC lengths in the verifier.

CVE-2026-98198:

        In the Linux kernel, the following vulnerability has been resolved:  hwmon: (pwm-fan) Stop RPM timer before freeing tach data  sample_timer() rearms the RPM timer and accesses the devm-managed ctx->tachs and ctx->pulses_per_revolution arrays. The cleanup action which stops the timer is registered before those arrays are allocated.  Since devres releases entries in reverse order, driver detach can free the arrays before pwm_fan_cleanup() shuts down the timer. A timer expiry in that window accesses the freed tach data.  With a KASAN kernel, a test-only kprobe delayed entry to pwm_fan_cleanup() while normal sysfs unbind ran. Each of three runs reported three four-byte reads and two four-byte writes in sample_timer() after its backing devm allocations had been freed. The helper did not invoke the timer callback, cleanup actions or free functions.  With the fix, three matching unbind runs completed without KASAN, BUG, WARNING, Oops or panic. Instrumentation confirmed that timer retirement completed before the first timer backing allocation was released.  Split timer retirement from the power cleanup and register its devres action after the timer backing data and IRQ actions are installed. This preserves the early power rollback action while ensuring the timer is retired before its backing data is released. Use timer_shutdown_sync() because the callback can rearm itself.

CVE-2026-98212:

        In the Linux kernel, the following vulnerability has been resolved:  mmc: hsq: Fix use-after-free in retry work  mmc_hsq_pump_requests() queues retry_work when request_atomic() returns -EBUSY; today sdhci-sprd is the only consumer that implements request_atomic(). The work is embedded in a devm-allocated mmc_hsq, but is never cancelled during driver removal. Work still pending at unbind can therefore run after the devm allocation has been released and dereference hsq->mmc and hsq->mrq.  Use devm_work_autocancel() to cancel and drain retry_work before the devm allocation is released. By the time devres cleanup begins, mmc_remove_host() has already stopped the host, so no new requests can arm the work.  This issue was found by an in-house static analysis tool.

CVE-2026-98222:

        In the Linux kernel, the following vulnerability has been resolved:  KEYS: encrypted: fix integer overflow of datablob_len  encrypted_key_alloc() stores datablob_len in a u16. It is computed from multiple string and payload lengths. If the result exceeds U16_MAX, the assignment truncates the allocation size. KASAN reports a 32760-byte slab-out-of-bounds write when __ekey_init() copies the master key description into the undersized buffer.  The total payload length stored in key->datalen is also a u16. Use check_add_overflow() to reject values that do not fit either destination, and use kzalloc_flex() for the flexible-array allocation.

CVE-2026-98229:

        In the Linux kernel, the following vulnerability has been resolved:  xfrm: save input state data before secpath resets  xfrm_input() stores the current xfrm_state in the skb secpath while it continues receive-side processing. Some input paths can reset that secpath before xfrm_input() has finished dereferencing the state.  Receive callback users such as VTI and XFRM interfaces can reset the secpath. The VTI receive path does so before checking whether the packet crosses network namespaces, while the XFRM interface path does so only for cross-network-namespace packets. The XFRM_MAX_DEPTH error path can also reset the secpath before the final drop callback reports the current state's protocol.  If secpath_reset() drops the last state reference while the state is concurrently deleted, xfrm_input() can still dereference the freed state when selecting transport_finish() or reporting the drop callback protocol.  Save the state protocol on the stack while the state is still valid, and use the already saved address family for transport_finish(). A larval XFRM_STATE_ACQ state has no type, so retain nexthdr as its protocol. This preserves the existing drop-path fallback while avoiding the post-reset state dereferences without adding an extra state reference to every received packet.

CVE-2026-98245:

        In the Linux kernel, the following vulnerability has been resolved:  btrfs: take commit root semaphore when iterating in mark_block_group_to_copy()  mark_block_group_to_copy() iterates over the commit root with skip_locking=true. A concurrent transaction commit can swap and free the commit root during iteration, causing use-after-free when accessing extent buffers.  Fix it by using path->need_commit_sem to protect the commit root search.

CVE-2026-98248:

        In the Linux kernel, the following vulnerability has been resolved:  arm64: percpu: Fix LSE operations on {8,16}-bit types  The assembly for __percpu_##name##_case_##sz() and __percpu_##name##_return_case_##sz() doesn't use the 'sfx' macro argument to form the LSE instruction. Without 'sfx', a W register argument will imply a 32-bit memory location, and consequently {8,16}-bit ops will erroneously read and write 32 bits of memory when the LSE instruction is used.  Fix this by appending 'sfx' to 'op_lse' to LSE instruction. It is not necessary (and not valid) to append 'sfx' to 'op_llsc', as 'op_llsc' is a register-register operation which does not access memory (and does not take a size suffix).

CVE-2026-98254:

        In the Linux kernel, the following vulnerability has been resolved:  swiotlb: use the adjusted address for the highmem page lookup  swiotlb_bounce() reads the page frame number from the slot's recorded orig_addr, then advances orig_addr by tlb_offset to reach the address the caller asked about. The highmem branch mixes the two: the offset within the page comes from the adjusted address, the page from the value before it.  Once the adjustment crosses a page boundary the pair no longer describes one location, and the whole copy lands one page below the intended one for a positive tlb_offset, one above for a negative one. DMA_FROM_DEVICE writes the device data over the wrong page and leaves the intended one stale, DMA_TO_DEVICE feeds the device from a page the mapping may not cover. Partial syncs through dma_sync_single_range_for_*() are what make tlb_offset non-zero.  The branch test is picked the same way, so a slot recorded in lowmem can be adjusted into highmem and the lowmem path then hands a highmem address to phys_to_virt().  Take both from orig_addr once it is final and keep pfn in the branch that uses it. PhysHighMem() asks the question straight from the address, as dma-debug already does.

CVE-2026-98265:

        In the Linux kernel, the following vulnerability has been resolved:  ALSA: usb-audio: Clamp implicit feedback packet count to URB capacity  data_ep_set_params() allocates each data URB for exactly u->packets isochronous frames, so urb->iso_frame_desc[] has u->packets slots and ctx->packets is the driver's only record of that limit. For an implicit feedback sink, snd_usb_queue_pending_output_urbs() overwrites it with the sync source's packet count, which is calculated independently from the capture endpoint's parameters. When that count is larger, prepare_playback_urb() and prepare_silent_urb() can write iso_frame_desc[] past the allocation; their existing bounds limit payload bytes, not the descriptor index.  The reproducer uses a high-speed UAC2 device declaring bInterval 1 for implicit feedback capture (8 packets) and bInterval 4 for playback (1 packet). On the first capture completion after the stream starts, it accesses seven descriptors spanning 112 bytes beyond the one-packet URB:    BUG: KASAN: slab-out-of-bounds in prepare_playback_urb (sound/usb/pcm.c:1560)   Write of size 4 at addr ffff88801e696ad0 by task vhci_rx/178    prepare_playback_urb (sound/usb/pcm.c:1560)    prepare_outbound_urb (sound/usb/endpoint.c:340)    snd_usb_queue_pending_output_urbs (sound/usb/endpoint.c:501)    snd_complete_urb (sound/usb/endpoint.c:1834)    __usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1657)    usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1741)    vhci_rx_loop (drivers/usb/usbip/vhci_rx.c:107)    kthread (kernel/kthread.c:436)   The buggy address belongs to the object at ffff88801e696a00    which belongs to the cache kmalloc-256 of size 256   The buggy address is located 0 bytes to the right of    allocated 208-byte region [ffff88801e696a00, ffff88801e696ad0)  Record the allocated packet count per endpoint and clamp both the adopted count and the packet-size copy to it. Fold the Format Type II delimiter into urb_packs before the allocation loop so the recorded limit matches every URB.

CVE-2026-98266:

        In the Linux kernel, the following vulnerability has been resolved:  ALSA: core: Fix potential UAF after asynchronous card release  Usually a sound driver releases the resources assigned to the card via snd_card_free(), and it synchronizes with the whole release procedure. However, when the card is released asynchronously via snd_card_free_when_closed() like USB-audio driver, the situation is slightly different; although the snd_card_disconnect() call at the disconnection guarantees that any newer accesses will be gated, the in-flight tasks might be still accessing to the underlying card->dev device even after the disconnection, which would cause a use-after-free in the end, as reported by fuzzers.  For addressing the bug above, this patch takes the refcount of card->dev at initialization of the card object, and releases at its destructor.   This assures the availability of the card->dev in its whole lifecycle.

CVE-2026-98269:

        In the Linux kernel, the following vulnerability has been resolved:  btrfs: abort transaction on failure to update inode for hole punching and reflinking  If we fail to update the inode we error out without aborting the transaction, which can result in a persistent inconsistency if after the failure the transaction is committed, as we have dropped file extent items from a range and either punched a hole or insert a new file extent item for that range (for reflinks).  So add the missing transaction abort.

CVE-2026-98271:

        In the Linux kernel, the following vulnerability has been resolved:  net: skbuff: do not leave stale header offsets after pskb_carve()  pskb_carve_inside_header() and pskb_carve_inside_nonlinear() remove the first bytes of a packet and reallocate skb->head.  All the headers that were present before the operation are gone, but both functions call skb_headers_offset_update(skb, 0), which is a no-op : skb->mac_header, skb->network_header, skb->transport_header and skb->csum_start keep their old values and now describe bytes which are no longer there.  Both helpers size the new head from the old skb_end_offset(), so the stale offsets still land inside the new allocation. They point past skb_tail_pointer() though, to bytes that were never initialized.  pskb_carve_inside_nonlinear() is the worst case, because it leaves a zombie skb with an empty linear part (skb->data == skb_tail_pointer(skb), skb_headlen(skb) == 0), while skb_mac_header_was_set() is still true and skb->mac_header is way ahead of skb->data.  The only user of pskb_extract() is rds_tcp_data_recv(), and the carved skb is queued on tinc->ti_skb_list. When the RDS incoming message is released, rds_tcp_inc_free() calls skb_queue_purge(), which frees the skbs with SKB_DROP_REASON_QUEUE_PURGE. This is visible from drop_monitor, which then tries to pull back to the (bogus) mac header :  skbuff: __skb_pull(len=234) skb len=6968 data_len=6968 headroom=0 headlen=0 tailroom=0 end-tail=384 mac=(234,14) mac_len=14 net=(248,40) trans=288 shinfo(txflags=0 nr_frags=1 gso(size=1428 type=16 segs=5)) csum(0x100120 start=288 offset=16 ip_summed=3 complete_sw=0 valid=1 level=0) hash(0x7b446c6c sw=0 l4=1) proto=0x86dd pkttype=0 iif=60 kernel BUG at ./include/linux/skbuff.h:2847!  Add skb_carve_reset_headers() to mark the mac and transport headers as not set, reset the network header, clear skb->mac_len, and drop a now meaningless CHECKSUM_PARTIAL (csum_start no longer describes anything).  Invalidate the inner offsets as well. Unlike mac_header and transport_header they have no "unset" sentinel, so a leftover non-zero value still looks like a real header. Zero skb->inner_mac_header, skb->inner_network_header, skb->inner_transport_header, skb->inner_protocol and skb->encapsulation, so that all the header state is invalidated in one place.  v2: fixed an inaccurate changelog. The stale offsets stay inside the     new skb->head, which is never smaller than the old one, they     simply point past skb_tail_pointer() to bytes that are gone.     Thanks to Xuanqiang Luo for insisting on this.     Also invalidate the inner header state, as suggested by the     netdev AI review :     https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260911114922.621937-1-edumazet%40google.com

CVE-2026-98273:

        In the Linux kernel, the following vulnerability has been resolved:  x86/kprobes: Fix crash when probing CS CALL instructions  When using eBPF to probe CS CALL instructions within a function, a crash can be triggered.  The eBPF tool probes offset 257 of the __hrtimer_run_queues() function:  <__hrtimer_run_queues+249>:  nopl   0x0(%rax,%rax,1) <__hrtimer_run_queues+254>:  mov    %r14,%rdi <__hrtimer_run_queues+257>:  cs call <__x86_indirect_thunk_r12> <__hrtimer_run_queues+263>:  mov    %eax,%r12d <__hrtimer_run_queues+266>:  xchg   %ax,%ax <__hrtimer_run_queues+268>:  mov    %r13,%rdi  Which triggers this crash:    BUG: unable to handle page fault for address: 00000000000f41c9   #PF: supervisor write access in kernel mode   #PF: error_code(0x0002) - not-present page   PGD 0 P4D 0   Oops: 0002 [#1] SMP NOPTI   CPU: 1 PID: 0 Comm: swapper/1 Kdump: loaded Tainted: P   RIP: 0010:__hrtimer_run_queues+0x106/0x230  Note that __hrtimer_run_queues+0x106 is __hrtimer_run_queues+262, which is at the 6th byte of the above CS CALL instruction. Since the CS CALL instruction occupies 6 bytes, the exception occurred in the middle of that call instruction.  The root cause is that when using eBPF tools to probe in the middle of a function, a kprobe with INT3 is used as the underlying implementation.  During single-step emulation of the original CALL instruction, int3_emulate_call() assumes that the probed CALL instruction is 5 bytes long. However, the actual CS-prefixed CALL instruction occupies 6 bytes, so it constructs an incorrect exception return address. When the CPU returns from the kprobe handler, the next instruction to be executed is at the address of the last byte of that CS CALL instruction. Coincidentally, starting from that address, the CPU fetches and decodes a completely different instruction, which ultimately triggers a kernel crash.  Fix the issue by using the actual instruction length obtained from the instruction decoder when constructing the exception return address, rather than relying on the hardcoded CALL_INSN_SIZE macro.  [ mingo: Refined the changelog ]

CVE-2026-98279:

        In the Linux kernel, the following vulnerability has been resolved:  btrfs: handle lack of space when cleaning up verity items  When enable_verity() hits the qgroup limit, rollback_verity() needs its own metadata reservation. When the qgroup limit or lack of space refuses the rollback, the whole filesystem is forced read-only even though the qgroup limit was for one subvolume only. Also orphan cleanup at the next mount fails the same way, so the leftover items are never removed: with -EDQUOT the subvolume stays unreachable, and with -ENOSPC on a full filesystem the next read-write mount fails.  Start transactions with btrfs_start_transaction_fallback_global_rsv() in btrfs_orphan_cleanup(), drop_verity_items() and rollback_verity(). Those calls only delete items and free the space in the end, so they may use the global reserve and skip the qgroup limit, which avoids -ENOSPC and -EDQUOT.

CVE-2026-98284:

        In the Linux kernel, the following vulnerability has been resolved:  netlink: do not free nlk->groups while lockless readers can use it  netlink_realloc_groups() uses krealloc() under netlink_table_grab(). Whenever NLGRPSZ(groups) lands in a different kmalloc bucket, the old bitmap is freed immediately.  Two readers of nlk->groups / nlk->ngroups do not hold the netlink table lock:  1) sk_diag_dump_groups(). Hashed (bound) sockets are dumped from the    rhashtable walk in __netlink_diag_dump(), which only holds RCU.    Only the mc_list part of the dump takes nl_table_lock.  2) netlink_native_seq_show() (/proc/net/netlink), whose walk has been    lockless since commit 21e4902aea80 ("netlink: Lockless lookup with    RCU grace period in socket release").  Both can read a freed buffer, and sk_diag_dump_groups() can also read past the end of the old (smaller) buffer if it happens to load the old @groups pointer together with the new @ngroups value, copying the result into a NETLINK_DIAG_GROUPS attribute.  This is the same class of bug that commit f773608026ee ("netlink: access nlk groups safely in netlink bind and getname") fixed for bind() and getname(); these two readers were missed. Simply grabbing the table lock in sk_diag_dump_groups() is not an option, because it is also called with nl_table_lock already held from the mc_list section of the dump.  Make the lockless readers safe instead:  - Allocate a new bitmap and free the old one after an RCU grace period,   instead of relying on the implicit kfree() done by krealloc().  - Publish @groups before @ngroups, both with release semantics, and have   the lockless readers load @ngroups first. A reader can then never pair   the new (bigger) size with the old (smaller) buffer, and a reader   picking up the new pointer while still seeing the old size is   guaranteed to see the initialized bitmap.  netlink_realloc_groups() is called from process context (bind() and setsockopt()), so kfree_rcu_mightsleep() can be used, once the table has been released.

CVE-2026-98285:

        In the Linux kernel, the following vulnerability has been resolved:  net: bridge: vlan: fix bugs caused by switchdev deletion errors  Allowing switchdev to prevent vlan deletion and error out in __vlan_del could cause multiple different issues - inconsistent state, memory leaks when flushing, NULL pointer dereference on bridge error when flushing. It doesn't make sense to allow it to stop __vlan_del, so log the error and continue with software vlan deletion. This is also consistent with 8021q behaviour.

CVE-2026-98286:

        In the Linux kernel, the following vulnerability has been resolved:  drop_monitor: use timer_shutdown_sync() to prevent timer rearming during teardown  In drop_monitor teardown paths (net_dm_trace_off_set(), net_dm_hw_monitor_stop(), and error unwind paths in net_dm_trace_on_set() and net_dm_hw_monitor_start()), per-CPU timers are stopped using timer_delete_sync() followed by cancel_work_sync().  However, there is a circular dependency between send_timer and dm_alert_work: 1) sched_send_work() (timer callback) schedules dm_alert_work. 2) send_dm_alert() / net_dm_hw_summary_work() calls reset_per_cpu_data()    or net_dm_hw_reset_per_cpu_data(). 3) If memory allocation fails under memory pressure in the reset    function, it re-arms the timer via mod_timer(&data->send_timer, ...).  If dm_alert_work is running concurrently while timer_delete_sync() executes on another CPU, an allocation failure in the worker will re-arm the timer after timer_delete_sync() has already returned. Once cancel_work_sync() completes and module_put() is called, the timer remains active in the timer wheel. If the module is then unloaded, the timer will fire and execute sched_send_work() in freed memory, triggering a kernel panic / use-after-free.  Switch from timer_delete_sync() to timer_shutdown_sync(). This guarantees that any in-flight timer handler has finished and prevents subsequent re-arming attempts from running workers from succeeding. When monitoring is restarted later, timer_setup() is invoked, which cleanly re-initializes the timer.

CVE-2026-98288:

        In the Linux kernel, the following vulnerability has been resolved:  net: stmmac: fix TSO header length truncation  stmmac_tso_xmit() stores the protocol header length returned by stmmac_tso_header_size() in a u8. stmmac_tso_valid_packet() admits headers up to 1023 bytes, so a header longer than 255 bytes wraps modulo 256 (486 becomes 230, 256 becomes 0).  A TCP over IPv6 socket carrying a few hundred bytes of sticky destination/hop-by-hop options makes skb_tcp_all_headers() exceed 255 while staying below the 1023-byte limit, so such an skb reaches stmmac_tso_xmit().  Widen proto_hdr_len to unsigned int, which is sufficient since the value is bounded by the hardware limit, and adjust the debug print specifier accordingly.

CVE-2026-98289:

        In the Linux kernel, the following vulnerability has been resolved:  af_unix: Unify scc_index when finalising SCC in __unix_walk_scc().  Commit bfdb01283ee8 ("af_unix: Assign a unique index to SCC.") changed Tarjan's algorithm to update lowlink with lowlink, which is called lowpoint (unix_vertex.scc_index).  unix_vertex_dead() assumes all vertices in an SCC share the same lowpoint, but this is not always true if an SCC has two or more back edges, depending on the order of DFS.  For example, the graph below has two back edges from B to A and from C to B.    A --> B --> C   ^    | ^    |   `----' `----'  If DFS walks through A -> B -> C -> B (-> C -> B) -> A (-> B -> A), each index and scc_index will be updated as follows.    A --> B --> C    C = (3, 3)  (index, scc_index)                    B = (2, 2)                    A = (1, 1)    A ... B ... C    C = (3, 2)<-.          ^    |    B = (2, 2) -'          `----'    A = (1, 1)    A ... B ... C    C = (3, 2)   ^    | .    .    B = (2, 1)<-.   `----'  ....     A = (1, 1) -'  Then, unix_vertex_dead() thinks that B is passed to another SCC with scc_index 2, and the SCC is not garbage-collected.  This does not happen if DFS walks in a different order below or starts from B.      1      3   A --> B --> C   ^    | ^    |   `----' `----'      2      4  Let's unify scc_index across the SCC when finalising it.  Note that updating v->index was previously done in unix_scc_dead(), when called from __unix_walk_scc(), just to save one loop.  Since __unix_walk_scc() now iterates over the SCC anyway, the update is moved back to __unix_walk_scc() and 'fast' argument is dropped.

CVE-2026-98292:

        In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: btmtksdio, btmtkuart: validate WMT event length before struct access  btmtksdio.c and btmtkuart.c cast a received WMT event straight to struct btmtk_hci_wmt_evt and read its op/flag fields without checking the event is long enough to contain them, unlike btmtk.c. The FUNC_CTRL case then further casts to struct btmtk_hci_wmt_evt_funcc and reads its 2-byte status field, again without a length check. Firmware that sends a short or malformed WMT event makes both drivers read past the end of the received SKB.  Mirror btmtk.c: validate the base WMT header with skb_pull_data() before touching any of its fields, and when a FUNC_CTRL event turns out to be the short, header-only form (a plain enable/disable ack with no status word), decode the result from the header's own flag byte instead (0 = success, otherwise failure).  Verified setup on MT7920, MT7921, MT7922 and MT7925: no regression.

CVE-2026-98294:

        In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: hci_qca: Do not write to the serial port after it is closed  hci_uart_close() closes the serdev port if HCI_QUIRK_NON_PERSISTENT_SETUP is set (for example, for the WCN399x family). A failed hci_dev_open_sync() following a successful qca_setup() calls hdev->close() but not hdev->shutdown(), so the port is closed while power->vregs_on is left true. qca_serdev_remove() then passes its power->vregs_on test and calls qca_power_off(), which writes to the closed port unconditionally.  Seen on a WCN3988 by unbinding the driver after a controller failure. The trace below is from a 7.0.0 based kernel, where qca_power_off() was still named qca_power_shutdown():    Unable to handle kernel NULL pointer dereference at virtual address   0000000000000038   Call trace:    tty_set_termios+0x50/0x238 (P)    ttyport_set_baudrate+0x84/0xc0    serdev_device_set_baudrate+0x24/0x40    qca_power_shutdown+0x158/0x1fc [hci_uart]    qca_serdev_remove+0x54/0x68 [hci_uart]    serdev_drv_remove+0x1c/0x2c    device_remove+0x4c/0x80    device_release_driver_internal+0x1cc/0x224    device_driver_detach+0x18/0x24    unbind_store+0xb4/0xc0  Check HCI_UART_PROTO_READY, which hci_uart_close() clears in the same place it closes the port, before writing to it. The regulator disable is left unconditional so the controller is still powered down.  The dangling serport->tty that turns this into a use-after-free is addressed in a separate patch.

CVE-2026-98295:

        In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: coredump: Quiesce dump work on unregister  hci_devcd_handle_pkt_init() arms dump_timeout and coredump producers queue dump_rx without holding an hdev reference. Unregister leaves both works live, so disconnecting during an active dump lets them access hdev after hci_release_dev() frees it.  Shut down coredump processing during unregister. Close the producer gate under dump_q.lock before disabling both works, then free the active buffer and queued packets under hci_dev_lock. Serializing the gate with enqueue prevents controller-specific workers from adding packets after the final purge.

CVE-2026-98304:

        In the Linux kernel, the following vulnerability has been resolved:  net: bcmgenet: restore the hardware filters on open  bcmgenet_hfb_init() runs INIT_LIST_HEAD() on priv->rxnfc_list, which drops every rule off the list, and bcmgenet_open() calls it on each ifup. Every rule the user configured is silently lost:    # ethtool -N eth0 flow-type ether dst $MAC action 0   Added rule with ID 0   # ethtool -n eth0 | grep -c Filter:   1   # ip link set eth0 down && ip link set eth0 up   # ethtool -n eth0 | grep -c Filter:   0  Initialise the lists once at probe and restore the rules on open, as bcmgenet_resume() already does.

CVE-2026-98307:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: ath11k: cleanup arsta in ath11k_mac_peer_cleanup_all()  When mac80211 removes a sta, it calls .sta_state() which in turn calls ath11k_mac_station_remove(). In that function we clean up both peers & arsta related resources.  But when the firmware crashes, ath11k calls ieee80211_restart_hw(), which assumes that all driver related resources are cleaned up beforehand. This cleanup is supposedly done by ath11k_mac_peer_cleanup_all() but does not in fact free arsta->rx_stats / tx_stats.  Extract the arsta cleanup from ath11k_mac_station_remove() into a new ath11k_mac_station_cleanup() and call it from both there and ath11k_mac_peer_cleanup_all().  This should handle kmemleaks reports like: 	unreferenced object 0xffffff801ae66400 (size 1024): 	  comm "hostapd", pid 1306, jiffies 4295011565 	  hex dump (first 32 bytes): 	    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................ 	    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................ 	  backtrace (crc d61c08ec): 	    kmemleak_alloc+0x3c/0x50 	    __kmalloc_cache_noprof+0x2b0/0x3e0 	    ath11k_mac_op_sta_state+0x1dc/0xb10 	    drv_sta_state+0xac/0x6f8 	    sta_info_insert_rcu+0x314/0x5e0 	    sta_info_insert+0x14/0x38 	    ieee80211_add_station+0x10c/0x1a0 	    nl80211_new_station+0x3e8/0x680 	    genl_family_rcv_msg_doit+0xc0/0x120 	    genl_rcv_msg+0x1b4/0x258 	    netlink_rcv_skb+0x4c/0x108 	    genl_rcv+0x38/0x60 	    netlink_unicast+0x190/0x278 	    netlink_sendmsg+0x15c/0x370 	    ____sys_sendmsg+0x120/0x290 	    ___sys_sendmsg+0x70/0xa0  Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.9.0.1-01977-QCAHKSWPL_SILICONZ-1

CVE-2026-98309:

        In the Linux kernel, the following vulnerability has been resolved:  drm/vc4: Use managed KMS polling to fix UAF on unbind  vc4_kms_load() calls drm_kms_helper_poll_init() but the driver provides no matching drm_kms_helper_poll_fini(). The output poll work stays scheduled after unbind and runs on the freed drm_device:    # modprobe vc4; rmmod vc4; sleep 10   BUG: KASAN: slab-use-after-free in delayed_work_timer_fn   BUG: KASAN: slab-use-after-free in drm_client_dev_hotplug [drm]   Workqueue: events output_poll_execute [drm_kms_helper]   Allocated by task 171: __devm_drm_dev_alloc   Freed by task 262 (rmmod): drm_dev_put / component_del  Use drmm_kms_helper_poll_init() so polling is finalized with the device, as other drivers do.

CVE-2026-98313:

        In the Linux kernel, the following vulnerability has been resolved:  drm/msm/dp: skip PUSH_IDLE when the link was never enabled  msm_dp_display_atomic_enable() returns early when link training fails, leaving ->power_on false and the main link down. msm_dp_display_atomic_disable() nevertheless writes DP_STATE_CTRL_PUSH_IDLE and waits for an idle-pattern completion that cannot arrive, so every failed enable is followed by "PUSH_IDLE pattern timedout".  Every other step of the teardown is already gated on that flag: msm_dp_display_disable(), called from .atomic_post_disable(), returns early on !power_on. The PUSH_IDLE write is the only one that is not, so the controller's runtime-PM reference is then dropped without the link having been taken down.  On glymur (Snapdragon X2 Elite) the consequence is not a warning. The SoC does not survive it: TrustZone force-stops the SOCCP and ADSP remote processors and the machine resets silently about 50 ms later, with no oops and no panic. On an ASUS Zenbook A16 (UX3607OA), whose eDP panel does not currently train, this reproduces without any compositor or GPU involvement:    # eDP enable has already failed with "Failed link training (rc=-104)"   echo 1 > /sys/class/graphics/fb0/blank    [535.645455] === marker ===   [535.694833] qcom_q6v5_pas d00000.remoteproc: fatal error received: \                  sys_m_smsm.c:512:TZ force stop   [535.694875] remoteproc remoteproc0: crash detected in soccp: type fatal error   [535.728857] qcom_q6v5_pas 6800000.remoteproc: fatal error received: \                  sys_m_smsm.c:783:err fatal notification received from TZ   <SoC reset>  Gate the PUSH_IDLE write on ->power_on so the disable path is consistent with the rest of the teardown. With this applied the same sequence is harmless and the machine stays up; without it, it resets every time.  The unconditional write dates back to the original DP driver (c943b4948b58 ("drm/msm/dp: add displayPort driver support")), but the surrounding code has been restructured several times since, so no Fixes: tag is offered.  Note that the eDP link-training failure that exposes this on the A16 is a separate problem in the glymur eDP PHY and is reported separately; this change is about not damaging the machine when training fails, for whatever reason.  Tested on ASUS Zenbook A16 (UX3607OA), Snapdragon X2 Elite Extreme, on linux-next next-20260803 and next-20260807. The machine has since been running next-20260807 with this patch as its daily driver.  Patchwork: https://patchwork.freedesktop.org/patch/745167/

CVE-2026-98317:

        In the Linux kernel, the following vulnerability has been resolved:  neighbour: Enforce min/max to NDTPA_INTERVAL_PROBE_TIME_MS.  NDTPA_INTERVAL_PROBE_TIME_MS sets .type and .min but misses .validation_type, so no validation is applied:    # ynl --family rt-neigh --do setneightbl \   --json '{"name": "arp_cache", "parms": {"interval-probe-time-ms": 0}}'    # ynl --family rt-neigh --dump getneightbl --output-json | \   jq '.[] | select(.name == "arp_cache" and has("config"))           | .parms["interval-probe-time-ms"]'   0  Moreover, nla_get_msecs() uses msecs_to_jiffies(), and u64 is silently cast to u32, so a larger value can bypass the min check:    e.g. 4294967296 == 0x100000000    # ynl --family rt-neigh --do setneightbl \   --json '{"name": "arp_cache", "parms": {"interval-probe-time-ms": 4294967296}}'    # ynl --family rt-neigh --dump getneightbl --output-json | \   jq '.[] | select(.name == "arp_cache" and has("config"))           | .parms["interval-probe-time-ms"]'   0  msecs_to_jiffies() returns MAX_JIFFY_OFFSET if the value is larger than INT_MAX.  Also, INT_MAX ms overflows int NEIGH_VAR() when HZ > 1000 (Alpha, MIPS), and passing a negative integer to queue_delayed_work(unsigned long delay) causes sign extension, which wraps around the expiry time to the past, resulting in it being handled as 0 delay in the timer wheel.  Let's use NLA_POLICY_FULL_RANGE() and limit the max to 1 day.  The same max check is applied to sysctl as well.  Note that this controls the probe interval for NTF_MANAGED entries, so the max of 1 day is unlikely to break any deployments.

CVE-2026-98321:

        In the Linux kernel, the following vulnerability has been resolved:  netfilter: nf_nat: unregister and release hooks on error  If nf_hook_entries_insert_raw() fails, the NAT hooks get never released, resulting in a memleak.  Postpone setting nat_proto_net->nat_hook_ops when the hooks are registered to simplify the error path to decide whether the nat hooks need unwinding.

CVE-2026-98327:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: mac80211: mesh: reset the CSA state when leaving  ifmsh->csa is allocated in ieee80211_mesh_csa_beacon() and only freed in ieee80211_mesh_finish_csa(), i.e. when the channel switch completes. Leaving the mesh while a switch is still pending therefore leaks it.  Additionally, ifmsh->csa_role and ifmsh->chsw_ttl have their state leak in this case, so things can get mixed up in addition to the memory leak.  Refactor the reset and call it in ieee80211_stop_mesh() to fix it all.

CVE-2026-98329:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: mac80211: don't allow injecting frames wider than the chanctx  Frames injected on a monitor interface can carry a radiotap field requesting a bandwidth, which mac80211 passes down to the driver regardless of the the actual operational bandwidth.  If the bandwidth requested is too wide, that triggers a warning in hwsim:    WARN_ON(hwsim_get_chanwidth(bw) > hwsim_get_chanwidth(confbw))  Drop such frames entirely instead since they cannot be sent.

CVE-2026-98330:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: cfg80211: get the wiphy out of a dying network namespace  When a network namespace is destroyed, cfg80211_pernet_exit() moves any wiphy back to the initial namespace, and just warns if that fails. But moving an interface can fail (due to allocation failures), and then the wiphy is left behind with a garbage netns pointer:    Kernel mode fault at addr 0x30   genlmsg_multicast_netns.constprop.0+0x46/0xcf [cfg80211]   nl80211_notify_wiphy+0xcd/0xe8 [cfg80211]   wiphy_unregister+0x169/0x3fc [cfg80211]  Note that commit debac3a20dec ("net: Remove conflicting altnames for dying netns in __dev_change_net_namespace().") fixed another path that could reach it without allocation failures.  Remove interfaces that cannot be moved instead of failing the switch, so that the wiphy always ends up in the initial namespace. In this case the netdev core will unregister the interfaces anyway.

CVE-2026-98332:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: mac80211: only operate on TDLS peers in the TDLS code  ieee80211_tdls_oper() can operate on the AP station, which then yields various warnings when the AP station is removed then or at a later point in time after being confused for a TDLS peer.  Always check that the station is a TDLS peer.

CVE-2026-98333:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: mac80211: reset the LED state when ifup fails  When the first interface comes up, the radio LED is turned on. This can start the TPT trigger timer, which continues running.  But if bringing up the interface fails then the timer keeps running and won't be stopped by anything, eventually it can be freed:    ODEBUG: free active (active state 0) object: ffff888127e12130 object type: timer_list hint: tpt_trig_timer+0x0/0x300 net/mac80211/led.c:145   WARNING: CPU: 0 PID: 5923 at lib/debugobjects.c:612 debug_print_object+0x1a2/0x2b0    debug_check_no_obj_freed+0x4b7/0x600 lib/debugobjects.c:1129    kfree+0x436/0x670 mm/slub.c:6818    ieee80211_led_exit+0x162/0x1c0 net/mac80211/led.c:210    ieee80211_unregister_hw+0x27e/0x3a0 net/mac80211/main.c:1706    rt2x00lib_remove_dev+0x55b/0x670  Undo the LED state in the error path.

CVE-2026-98334:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: mac80211: reset state when starting AP fails  ieee80211_start_ap() can set enable_beacon (and beacon_int) and fail later, leaving it set forever. Scanning can then attempt to restore beaconing on such an interface, leading to:    Oops: divide error: 0000 [#1] SMP KASAN NOPTI   RIP: 0010:mac80211_hwsim_link_info_changed+0xca7/0xf00   Call Trace:    drv_link_info_changed+0x413/0x860 net/mac80211/driver-ops.c:495    ieee80211_link_info_change_notify+0x24b/0x3c0 net/mac80211/main.c:427    ieee80211_offchannel_return+0x381/0x580 net/mac80211/offchannel.c:160    __ieee80211_scan_completed+0x993/0xe30 net/mac80211/scan.c:519    ieee80211_scan_work+0x472/0x2010 net/mac80211/scan.c:1193    cfg80211_wiphy_work+0x2b7/0x550 net/wireless/core.c:538  in hwsim. Also, cfg80211 then allows changing the interface type, and the off-channel path getgs confused about beaconing as well, leading to another warning:    WARNING: net/mac80211/driver-ops.c:468 at drv_link_info_changed+0x583/0x880    ieee80211_link_info_change_notify+0x24b/0x3c0 net/mac80211/main.c:427    ieee80211_offchannel_stop_vifs+0x328/0x5c0 net/mac80211/offchannel.c:122    ieee80211_start_sw_scan net/mac80211/scan.c:583 [inline]    __ieee80211_start_scan+0xfb6/0x1af0 net/mac80211/scan.c:882  Reset the state on failures to always have it correct.

CVE-2026-98335:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: mac80211: abort chanswitch when leaving a mesh  The code in ieee80211_stop_mesh() leaves CSA active, but leaving the mesh released the channel context, so the CSA finalize work crashes:    Oops: general protection fault, probably for non-canonical address         0xdffffc0000000003   KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]   RIP: 0010:ieee80211_put_srates_elem+0x42/0x640 net/mac80211/util.c:3272   Call Trace:    ieee80211_mesh_build_beacon+0xa83/0x1b50 net/mac80211/mesh.c:1093    ieee80211_mesh_rebuild_beacon+0xc7/0x170 net/mac80211/mesh.c:1147    ieee80211_mesh_finish_csa+0x131/0x210 net/mac80211/mesh.c:1542    ieee80211_set_after_csa_beacon net/mac80211/cfg.c:4085 [inline]    __ieee80211_csa_finalize net/mac80211/cfg.c:4133 [inline]    ieee80211_csa_finalize+0x633/0x1150 net/mac80211/cfg.c:4155    cfg80211_wiphy_work+0x2ab/0x450 net/wireless/core.c:438  Abort the channel switch properly.

CVE-2026-98337:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: mac80211: don't start a ROC while scanning  The ROC work can be pending when a scan starts (which requires ROC list to be empty, but that's possible), and then a new ROC can be added to the list and the work will pick it up.  Avoid starting that ROC if a scan made it between things, as otherwise we'll hit a warning later:    WARNING: net/mac80211/offchannel.c:404 at ieee80211_start_next_roc+0x256/0x2d0   Workqueue: events_unbound cfg80211_wiphy_work   Call Trace:    __ieee80211_scan_completed+0x4fd/0xe40 net/mac80211/scan.c:537    ieee80211_scan_work+0x472/0x1ff0 net/mac80211/scan.c:1193    cfg80211_wiphy_work+0x410/0x570 net/wireless/core.c:513

CVE-2026-98338:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: cfg80211: ibss: ref BSS entry for joined event  When the IBSS is joined, we only record the BSSID/channel in the event and look up the BSS entry when processing it. However, that's racy, e.g. a new scan with NL80211_SCAN_FLAG_FLUSH can remove it, causing a warning in the event work:    !bss   WARNING: net/wireless/ibss.c:37 at __cfg80211_ibss_joined+0x3d3/0x440   Workqueue: cfg80211 cfg80211_event_work    cfg80211_process_wdev_events+0x39f/0x5b0 net/wireless/util.c:1144    cfg80211_process_rdev_events+0xa1/0x110 net/wireless/util.c:1179    cfg80211_event_work+0x2f/0x40 net/wireless/core.c:393  Do the lookup early (the driver is expected to only join an IBSS that has a BSS entry) and keep a reference to it.

CVE-2026-98341:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: cfg80211: don't free driver-owned scan requests  When an interface goes down while a scan is running, cfg80211 completes the scan towards userspace and frees the scan request. However, the driver can be convinced that it owns the request, since the cancellation is (intended to be) asynchronous.  The WARN_ON() in the netdev notifier was meant to catch this, but it's not actually avoidable, so it triggers and we get a UAF in scan_done().  There doesn't seem to be a great way around it, so just track that the driver is still convinced it owns the request, and then just free it on completion if it was already cancelled. Also remove the warnings since they can trigger in the intended architecture.

CVE-2026-98353:

        In the Linux kernel, the following vulnerability has been resolved:  RDMA/erdma: Use IRQ-safe XArray helpers for QP and CQ tables  Locked QP and CQ lookups from EQ interrupts can deadlock with create-path XArray updates. If an interrupt arrives while the create path holds the plain xa_lock, the lookup spins forever trying to acquire the same lock.  Use IRQ-safe XArray helpers for all QP and CQ create-path updates, including the GSI QP store and error paths. Initialize both arrays with XA_FLAGS_LOCK_IRQ so sleeping allocations preserve interrupt state.

CVE-2026-98355:

        In the Linux kernel, the following vulnerability has been resolved:  RDMA/rtrs: guard against null kobj name  In the client, if `init_path()` errors, the callee tries to clean up with `rtrs_clt_close_conns()`. However, this can lead to calling the event tracing code with `clt_path->kobj->name` being `NULL` and thus causing a null pointer dereference when trying to copy from it.  This just adds a guard to check that the name is not `NULL` before copying from it. The server appears to have a similar pattern.

CVE-2026-98364:

        In the Linux kernel, the following vulnerability has been resolved:  xfrm: hold net_device reference under RCU in bundle creation  xfrm_bundle_create() and xfrm_create_dummy_bundle() read dst->dev into a local pointer without taking a device reference, then pass it to xfrm_fill_dst(). A concurrent RTM_DELLINK replaces dst->dev via dst_dev_put() and frees the old net_device, causing a use-after-free when xfrm6_fill_dst() later dereferences the stale dev pointer.    BUG: KASAN: slab-use-after-free in xfrm6_fill_dst+0x82c/0x860   (net/ipv6/xfrm6_policy.c:86 netdev_hold())   Read of size 8 at addr ffff8880142fe588 by task exploit/153   Call Trace:    xfrm6_fill_dst+0x82c/0x860    xfrm_resolve_and_create_bundle+0x21d4/0x2bd0    xfrm_lookup_with_ifid+0x485/0x1640    ip6_dst_lookup_flow+0x19b/0x1e0    udpv6_sendmsg+0x1443/0x2dd0  Fix this by reading dst->dev via dst_dev_rcu() and keeping the RCU read-side critical section active until xfrm_fill_dst() has taken the required device references.

CVE-2026-98365:

        In the Linux kernel, the following vulnerability has been resolved:  RDMA/rxe: Fix integer overflow in mr_check_range() leading to OOB access  mr_check_range() validates that [iova, iova+length) falls within the registered MR range using wraparound-prone arithmetic:      if (iova < mr->ibmr.iova ||         iova + length > mr->ibmr.iova + mr->ibmr.length)  A remote peer can craft an RDMA-Write/Read RETH so that iova + length wraps to 0 (e.g. iova=0xfffffffffffffff8, length=8), bypassing the check. rxe_mr_iova_to_index() then computes a huge index (int idx, only guarded by WARN_ON) and rxe_mr_copy_xarray() dereferences mr->page_info[huge], causing an out-of-bounds read/write and a kernel oops that is triggerable by an unauthenticated remote peer.  Rewrite the check in overflow-safe form; the first two clauses guarantee that the subsequent subtractions do not underflow:      if (iova < mr->ibmr.iova ||         length > mr->ibmr.length ||         iova - mr->ibmr.iova > mr->ibmr.length - length)  With the fix, mr_check_range() returns -EINVAL for the crafted iova and the responder reports REMOTE_ACCESS_ERROR instead of triggering the OOB.

CVE-2026-98373:

        In the Linux kernel, the following vulnerability has been resolved:  mm/hugetlb: preserve mremap address delta when skipping page tables  move_hugetlb_page_tables() optimizes mremap() by advancing to the last entry in the page table when the source page table does not exist, either initially or after unsharing a PMD table.  The common loop increment then steps to the first entry in the next page table.  However, the code advances both the source and destination addresses to the last entries in their respective page tables, which is wrong.  The destination address must be advanced only by the same amount as the source address.  If the source and destination offsets within their page tables differ, the destination address can be advanced too far, causing follow-up issues.  Fix this by advancing the destination address by the source advance distance.  With a reproducer, we were able to trigger a kernel panic on x86-64.  With this fix in place, we can no longer reproduce the issue.

CVE-2026-98375:

        In the Linux kernel, the following vulnerability has been resolved:  xen/netfront: drop RX packets with a short Ethernet header  handle_incoming_queue() pulls pull_to bytes into the head before calling eth_type_trans().  pull_to is the length of the first RX slot, capped at RX_COPY_THRESHOLD, and that length comes from the backend. Nothing checks it against ETH_HLEN.  If the first slot is shorter than ETH_HLEN and more slots follow, the head ends up shorter than an Ethernet header while skb->len is longer, and eth_type_trans() BUG()s in __skb_pull().  If the whole packet is shorter than ETH_HLEN, eth_type_trans() reads the header past the end of the data instead.  Pull at least ETH_HLEN, and drop the packet if that fails, which also drops packets too short to hold an Ethernet header.  This also checks the return value of the pull, which was ignored.

CVE-2026-98377:

        In the Linux kernel, the following vulnerability has been resolved:  vlan: require the MAC header to be present in __vlan_insert_inner_tag()  __vlan_insert_inner_tag() only guarantees head room via skb_cow_head(), never that mac_len bytes of MAC header are present.  Its ETH_HLEN wrappers - __vlan_insert_tag() under skb_vlan_push(), and vlan_insert_tag() under validate_xmit_vlan() on the generic transmit path - therefore rewrite the first 16 bytes at skb->data: a 12-byte memmove plus two 2-byte stores at +12 and +14.  No caller supplies the bound, while the pop helpers use skb_ensure_writable()/pskb_may_pull().  An IFF_TUN device has hard_header_len == 0, so packet_snd() accepts a one-byte AF_PACKET/SOCK_RAW frame.  The first vlan push only sets a hwaccel tag; the next - clsact "action vlan push" or bpf_skb_vlan_push() - enters the helper with skb->len still 1.  The head comes from skbuff_small_head without __GFP_ZERO, so each push drags bytes from beyond skb->tail into the frame.  After three the one-byte send leaves as 13 bytes carrying 11 bytes of uninitialised slab:    0000: 5a b3 62 12 80 88 ff ff 00 b3 62 12 81            `------------------------------'   only 0x5a was sent; the rest is slab, here the top 56 bits of a   linear-map address  Require the MAC header the helper rewrites to be present, so such a frame is dropped rather than transmitted.

CVE-2026-98386:

        In the Linux kernel, the following vulnerability has been resolved:  scsi: qla2xxx: Use memset_io() to clear QLAFX00 request ring slot  For QLAFX00 the request ring is ioremapped device I/O memory (ha->iobase + req_que_off), not DMA-coherent RAM, which is why the rest of the FX00 path accesses it through memcpy_toio() and the wrt_reg_* helpers. __qla2x00_alloc_iocbs() however zeroed the producer slot with a plain memset(). On architectures such as ARM64 a regular memset() may emit unaligned or block-zeroing instructions (e.g. DC ZVA) that are invalid on Device memory, leading to a synchronous external abort.  Use memset_io() to clear the slot for QLAFX00, matching the I/O accessors used elsewhere on this ring. Other adapters keep the plain memset() on their DMA-coherent rings. The zero-fill is retained for FX00 because its IOCB builders (e.g. qlafx00_fxdisc_iocb()) copy only part of the entry and rely on the unused tail being pre-zeroed.

CVE-2026-98387:

        In the Linux kernel, the following vulnerability has been resolved:  s390/crypto: Fix skcipher_walk return code handling in aes_s390  The return codes from skcipher_walk_virt() were not properly checked before entering the processing loops in ecb_aes_crypt() and ctr_aes_crypt(). If skcipher_walk_virt() fails, the walk structure may be in an undefined state, and attempting to process data could lead to incorrect behavior or accessing uninitialized memory.  Add proper return code checking to ensure correct handling of the walk initialization and walk advance and eventually return to the caller with that return code.

CVE-2026-98389:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu: skip gfx switch_power_profile during GPU reset  During resume from GPU reset, the gfx idle work may invoke switch_power_profile before the reset completes. This causes the following assert error because the register access occurs without first releasing the GPU reset semaphore:  [ 1576.768935] CR2: 0000559ea133ead0 CR3: 00000002e6c42000 CR4: 0000000000350ef0 [ 1576.768940] Call Trace: [ 1576.768944]  <TASK> [ 1576.768953]  amdgpu_device_rreg+0x21/0x50 [amdgpu] [ 1576.769158]  smu_msg_v1_send_msg+0x1a4/0x6e0 [amdgpu] [ 1576.769437]  smu_cmn_send_smc_msg_with_params_ext+0xba/0x120 [amdgpu] [ 1576.769721]  smu_cmn_send_smc_msg_with_param+0x33/0x40 [amdgpu] [ 1576.769993]  smu_v13_0_0_set_power_profile_mode+0x192/0x2b0 [amdgpu] [ 1576.770267]  smu_bump_power_profile_mode+0x5d/0x80 [amdgpu] [ 1576.770538]  smu_switch_power_profile+0xa4/0xf0 [amdgpu] [ 1576.770839]  amdgpu_dpm_switch_power_profile+0x6f/0x90 [amdgpu] [ 1576.771210]  amdgpu_gfx_profile_idle_work_handler+0xe9/0x130 [amdgpu] [ 1576.771460]  process_one_work+0x23e/0x6f0 [ 1576.771491]  worker_thread+0x1c4/0x380 [ 1576.771506]  kthread+0x10c/0x150 [ 1576.771512]  ? __pfx_worker_thread+0x10/0x10 [ 1576.771518]  ? __pfx_kthread+0x10/0x10 [ 1576.771530]  ret_from_fork+0x314/0x390 [ 1576.771537]  ? __pfx_kthread+0x10/0x10 [ 1576.771546]  ret_from_fork_asm+0x1a/0x30  (cherry picked from commit d93b1ff538ce9750c01e0dd0aa62575579c0fc08)

CVE-2026-98393:

        In the Linux kernel, the following vulnerability has been resolved:  net: ipv4: Fix UDP length overflow with PMTU discover and big MTU  This commit bounds cork->base.fragsize to IP_MAX_MTU to avoid a possible overflow of UDP length that triggers a WARN in udp_set_len_short when setsockopt IP_MTU_DISCOVER is set to IP_PMTUDISC_PROBE, and a large packet is sent over a netdev with an unusually large MTU.  Steps to reproduce:  1. Set device MTU bigger than IP_MAX_MTU + 20. cork->base.fragsize will    be set to that MTU in ip_setup_cork. 2. Set IP_MTU_DISCOVER to IP_PMTUDISC_PROBE. It lets maxnonfragsize be    set to device MTU (cork->fragsize) in __ip_append_data, rather than    to IP_MAX_MTU. 3. Send 65528 bytes of payload (+8 bytes of UDP header, +20 bytes of    IPv4 header). Device MTU allows it (it's only one byte bigger than    IP_MAX_MTU + IPv4 header, and the device MTU is bigger than that). 4. The UDP length in the built packet is 65536, which overflows the    16-bit length field and triggers the WARN in udp_set_len_short.  Note: IP_PMTUDISC_DO with IPv4 is safe, because ip_dst_mtu_maybe_forward always clamps at IP_MAX_MTU, unlike ip6_dst_mtu_maybe_forward.  The Fixes tag points at the first commit where I could reproduce the overflow with IPv4 and IP_PMTUDISC_PROBE.

CVE-2026-98394:

        In the Linux kernel, the following vulnerability has been resolved:  af_unix: Return immediately when manage_oob() returns NULL for 0-length buffer.  Fahad Alharbi reported that recv(0, MSG_PEEK) triggers busy-wait in unix_stream_read_generic() if recv() is blocking and the last skb in the queue is MSG_OOB skb.  In such a situation, TCP returns 0 immediately regardless of blocking or non-blocking.  Let's follow the behaviour.

CVE-2026-98399:

        In the Linux kernel, the following vulnerability has been resolved:  s390/ipl: Fix NULL deref in dump_reipl without re-IPL parm block  Unlike kdump, which passes the re-IPL parameter block through os_info, the stand-alone dump passes it through the IPL parm block address and checksum in lowcore.  Some IPL types, like HMC FTP boot or QEMU direct kernel boot, might not provide an IPL parameter block. In this case reipl_type_init() selects IPL_TYPE_UNKNOWN and reipl_block_actual remains NULL. Nevertheless, dump_reipl_run() unconditionally dereferences it when preparing the lowcore fields. This may happen to work by chance when address zero contains readable lowcore data. A zero IPL parameter block address is then stored in lowcore, causing the stand-alone dumper to enter disabled wait after completing the dump.  Explicitly store a zero IPL parameter block address and checksum when no re-IPL parameter block is available. This does not change the behavior: the stand-alone dumper completes the dump and halts, while valid re-IPL parameter blocks continue to be handled as before.

CVE-2026-98400:

        In the Linux kernel, the following vulnerability has been resolved:  s390/ipl: Fix NULL deref in kdump without re-IPL parm block  Some IPL types, like HMC FTP boot or QEMU direct kernel boot, might not provide an IPL parameter block. In this case, reipl_type_init() selects IPL_TYPE_UNKNOWN, and reipl_block_actual remains NULL.  kdump passes the re-IPL parameter block to the dump kernel through os_info. Before commit 3b9678472bab ("s390/ipl: correct kdump reipl block checksum calculation"), the os_info entry was added only for IPL types which initialized reipl_block_actual. That commit moved the os_info update to machine_crash_shutdown(), making it unconditional. As a result, set_os_info_reipl_block() dereferences reipl_block_actual for IPL_TYPE_UNKNOWN. This may happen to work by chance when address zero contains readable lowcore data and the resulting empty os_info entry is ignored by the dump kernel.  Skip the os_info update when no re-IPL parameter block is available. Kdump then collect the dump and reboot without setting re-IPL parameter block.

CVE-2026-98401:

        In the Linux kernel, the following vulnerability has been resolved:  net: iptunnel: fix stale transport header during tunnel decapsulation  Syzbot reported a crash in qdisc_pkt_len_segs_init() caused by a stale transport_header offset after tunnel decapsulation.  BUG: unable to handle page fault for address: ffffed102091a42e Oops: Oops: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 340 Comm: qdisc_uaf_repro Not tainted 7.2.0-rc4-00061-g248951ddc14d #256 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:__asan_load2 <IRQ> qdisc_pkt_len_segs_init (net/core/dev.c:4145) __dev_queue_xmit (net/core/dev.c:4787) br_dev_queue_push_xmit (net/bridge/br_forward.c:53) br_handle_frame_finish (net/bridge/br_input.c:229) br_handle_frame (net/bridge/br_input.c:315) __netif_receive_skb_core.constprop.0 (net/core/dev.c:6099) __netif_receive_skb_list_core (net/core/dev.c:6287) netif_receive_skb_list_internal (net/core/dev.c:6445) napi_complete_done (net/core/dev.c:6813) gro_cell_poll (net/core/gro_cells.c:74) __napi_poll (net/core/dev.c:7735) net_rx_action (net/core/dev.c:7798 net/core/dev.c:7955) handle_softirqs (kernel/softirq.c:622) do_softirq (kernel/softirq.c:523  kernel/softirq.c:510 ) __local_bh_enable_ip (kernel/softirq.c:450) tun_get_user (drivers/net/tun.c:1986 (discriminator 1)) tun_chr_write_iter (drivers/net/tun.c:2032)  The issue is completely latent until qdisc read transport header in commit 7fb4c1967011 ("net: pull headers in qdisc_pkt_len_segs_init()"). The crash requires four conditions to line up:  1. The incoming packet is encapsulated and carries GSO metadata. The outer    transport header offset is stored in skb->transport_header while the    packet is still in the outer tunnel context. 2. The tunnel receiver strips the outer headers. skb->data is advanced to    the inner frame, but skb->transport_header is left pointing to the    now-removed outer L4 header, so it becomes a negative offset relative to    the new data. 3. The inner frame is not delivered to the local IP stack. Instead, it    is forwarded at L2 by a bridge or HSR, so ip_rcv_core() never runs and    the transport header is not reset to the inner L4 offset. 4. The forwarding path calls __dev_queue_xmit(), which enters    qdisc_pkt_len_segs_init(). That function computes the GSO header length    from skb_transport_offset(skb). Because the offset is negative, the    unsigned cast overflows and pskb_may_pull(skb, hdr_len +    sizeof(struct tcphdr)) reads past the end of the skb, triggering a    KASAN fault or page fault.  The issue specifically requires GSO packets (shinfo->gso_size != 0), which are processed/aggregated through gro_cells. Fix this by clearing transport_header to the ~0U sentinel in gro_cell for all tunnnel driver. GTP does not support GRO/GSO, drop the evil GSO packets in GTP directly.

CVE-2026-98403:

        In the Linux kernel, the following vulnerability has been resolved:  s390/boot: Avoid IPL parameter append past command line  A command line may occupy all but the terminating byte of COMMAND_LINE_SIZE. In that case append_ipl_block_parm() passes a zero size to the IPL parameter conversion helpers and points the destination one byte past early_command_line. The helpers subtract one from the unsigned size and write the converted parameter outside the command line buffer.  Convert the IPL parameter in the command line parsing buffer first. A parameter beginning with '=' can then replace the existing command line regardless of its length, while other parameters are appended only when space remains.

CVE-2026-98409:

        In the Linux kernel, the following vulnerability has been resolved:  watchdog: rtd119x: Avoid division by zero  clk_get_rate() could return 0.  Avoid a division by zero panic.

CVE-2026-98420:

        In the Linux kernel, the following vulnerability has been resolved:  ksmbd: follow SMB2 session expiration semantics  ksmbd_session_register() destroys valid sessions after ten seconds of inactivity whenever a client starts another SessionSetup exchange. This confuses Session.IdleTime with Session.ExpirationTime. Windows can create additional authenticated sessions on an existing connection, so deleting the older session invalidates its tree connects and makes mapped drives fail with STATUS_NETWORK_NAME_DELETED.  The session expiration rules require the server to change a valid session to expired only after its credential expiration time passes. A valid or expired session otherwise keeps its connection from being scavenged. Connections that have not negotiated a dialect, have no sessions, or have only InProgress sessions are disconnected after an implementation-specific timeout. Use the Windows-compatible 45 second value and run the expiration check periodically for both TCP and SMB Direct.  Keep zero as an infinite credential expiration time, and count each Valid-to-Expired transition. Set expired sessions to InProgress when they reauthenticate. If authentication fails, remove the session from the global and per-connection tables immediately, including SMB3 multichannel connections.  Retain protection against abandoned SessionId-zero exchanges by allowing only one InProgress authentication per connection. Additional exchanges fail with STATUS_INSUFFICIENT_RESOURCES, and stale InProgress sessions are reaped after the same 45 second setup timeout. This bounds the original unauthenticated memory-exhaustion path without evicting established sessions.

CVE-2026-98424:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: cfg80211: undo netns switch if renaming the wiphy fails  Once all the interfaces have been moved, cfg80211_switch_netns() moves the wiphy itself by setting its network namespace and then renaming it, which makes sysfs move it. The rename can fail (but only on allocation failures), leaving things mixed up and hitting the warning there.  Ignoring it isn't great, undo the move and let the change fail in this case. If undo fails then WARN, then things would again be stuck in two different network namespaces.

CVE-2026-98425:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: mac80211: don't warn when an IBSS has no channel to scan  ieee80211_request_ibss_scan() warns when regulatory leaves no allowed channel, but that can happen as the regdomain can change while IBSS is operating, and it can continue to operate briefly during the 60s grace period until it's shut down.  Just remove the warning in this case.

CVE-2026-98427:

        In the Linux kernel, the following vulnerability has been resolved:  net/sched: codel: bound the dropping loop per dequeue call  The CoDel control law schedules the next drop one interval/sqrt(count) after the previous drop, using the configured interval (codel_params.interval). For very small intervals the scheduled step rounds down to zero, so the dropping loop in codel_dequeue() never advances and drains the entire backlog under the qdisc lock in one call - an unprivileged user can trigger a soft lockup this way.  Fix in the shared codel code used by both codel and fq_codel:  1. Make the control-law step at least 1 tick so the dropping loop    always moves forward.  2. Cap the dropping loop at CODEL_MAX_DROPS_PER_DEQUEUE (256) drops    per codel_dequeue() call, resyncing drop_next to now when the cap    is hit: the catch-up owed to the loop grows with the idle gap and    the backlog, which no interval threshold can bound. This is a    deliberate behaviour change after long idle gaps.  The cap applies to fq_codel (4b549a2ef4be) and the mac80211 TXQ path (fixed interval, cap only).  The target sojourn delay (codel_params.target) is not validated: it does not feed the control law, so a sub-tick value is aggressive rather than deadlock-prone.  Conditions to recreate the bug:   - tc qdisc add dev lo root handle 1: tbf rate 1kbit burst 2kb limit 1000000   - tc qdisc add dev lo parent 1:1 handle 10: codel interval 2us target 1ms noecn limit 1000000 (same for fq_codel)   - unpatched kernel: tc accepts it; a UDP flood under the 1kbit tbf     soft-lockups (watchdog: BUG: soft lockup) while one     codel_dequeue() call drops the backlog under the qdisc lock   - patched kernel: same setup, at most 256 drops per dequeue call,     no soft lockup  Testing: claim reproducer and interval 2us/3us variants run clean; tdc qdisc category passes (see the selftests patch).

CVE-2026-98435:

        In the Linux kernel, the following vulnerability has been resolved:  EDAC/altera: Use parent device for devres in altr_portb_setup()  Anchor the devres group and the devm-managed IRQ requests in altr_portb_setup() to the actual parent device (device->edac->dev) instead of the embedded struct device inside the copied per-port altr_edac_device_dev.  This keeps devres_open_group(), devm_request_irq(), devres_remove_group() and devres_release_group() all referring to the same long-lived device so the group and the resources allocated inside it are torn down together.

CVE-2026-98436:

        In the Linux kernel, the following vulnerability has been resolved:  accel/amdxdna: Disable device buffer exporting  Device buffers are never intended to be exported. Disable exporting support explicitly.

CVE-2026-98439:

        In the Linux kernel, the following vulnerability has been resolved:  smb/server: cancel async requests when closing connection  An async request may still be waiting when a connection is closed. This can stop the connection from closing.  Cancel active async requests before waiting for them to finish.

CVE-2026-98443:

        In the Linux kernel, the following vulnerability has been resolved:  xfs: fix cursor and pointer handling when recovering iunlink buckets  LOLLM pointed out a bug in xlog_recover_iunlink_bucket:  1. We don't null out prev_ip after releasing it, which can lead to UAF    problems if the inodegc flush call in the loop fails.  at which point I noticed even more bugs:  2. If the inodegc flush inside the loop fails, we also leak @ip.  3. We set prev_agino to agino having already advanced agino, which    results in inodes with i_prev_unlinked set to itself.  4. If we exit the bottom of the loop with prev_ip set, then prev_ip    aliases ip and we also set its i_prev_unlinked to itself.  Bugs 3 and 4 introduce loops into the unlinked list, though these loops don't surface because we immediately flush each unlinked inode after loading it.  Fix all of these issues.

CVE-2026-98449:

        In the Linux kernel, the following vulnerability has been resolved:  smb: client: delete compound mids on send failure before unlock  When sending a compound request fails, smb_send_rqst() kicks off a reconnect. compound_send_recv() still has those mids on pending_mid_q, but it unlocks the server without removing them first.  During reconnect, cifs_abort_connection() walks pending_mid_q and runs each mid callback. With no response yet, those callbacks return credits and drop in_flight. Then compound_send_recv()'s send-error path returns the same credits again. in_flight ends up decremented twice and smb2_add_credits() WARNs.  syzbot hits this during SMB2_negotiate when the socket send fails.  cifs_call_async() already calls delete_mid() before unlock on send failure. Do the same for compound chains and set cancelled_mid[] so the out: path does not delete them again.

CVE-2026-98450:

        In the Linux kernel, the following vulnerability has been resolved:  smb: client: close completed creates on compound wait errors  compound_send_recv() waits for responses in order. If a later wait is interrupted, or if a later MID fails during response synchronization, an earlier CREATE may already have opened a remote handle. The earlier mid is then released without invoking handle_cancelled_mid(), leaving the remote handle open because no FID was copied to the caller.  Mark completed earlier mids as cancelled when a compound wait or MID synchronization aborts. Keep their response buffers attached while the MIDs are synchronized, and transfer them only after synchronization of the processed responses, so the release path can inspect successful CREATE responses and queue SMB2_close() after a later failure. Account for a remote open only after the close work is allocated and before it is queued, since the caller has not yet updated num_remote_opens. Mark the create+close compound used by smb2_unlink() so it is not closed again. Non-CREATE responses and compounds that already include a close keep their existing behavior.

CVE-2026-98451:

        In the Linux kernel, the following vulnerability has been resolved:  smb: client: use finish_no_open() for non-regular inodes  An O_CREAT open can find an existing symlink or another non-regular inode. cifs_atomic_open() calls finish_open() on it and attaches a cifsFileInfo. Symlink inodes have no CIFS release operation, so the dentry reference held by cifsFileInfo is leaked. FMODE_OPENED also prevents the VFS from following the symlink.  Track whether cifs_do_create() returned an open server handle. For non-regular inodes, close the handle if present, remove the pending open, and call finish_no_open() so the VFS can continue the lookup. Do not set FMODE_CREATED unless a regular file was opened. For O_NOFOLLOW with __O_REGULAR, return -ELOOP before the VFS's -EFTYPE check.  Defer closing a legacy POSIX handle on a non-regular inode until after inode lookup. This avoids closing it again if lookup fails.

CVE-2026-98452:

        In the Linux kernel, the following vulnerability has been resolved:  smb: client: clean up failed cached directory opens  open_cached_dir() sends CREATE and QUERY_INFO as a compound request. If the CREATE succeeds but a later command returns an error, the function must retain the CREATE FID so common cleanup can issue SMB2_close(). It also must not treat a response error as a valid CREATE.  Validate the CREATE response before using its fields, record the FIDs, and mark the handle open before handling errors from later compound commands. Move the -EREMCHG reconnect handling before response validation so a missing response does not hide the reconnect request. Count the handle when it is marked open; confirmed close responses decrement the counter, while existing close retry behavior remains best effort on transport failures.

CVE-2026-98453:

        In the Linux kernel, the following vulnerability has been resolved:  smb: client: close handle after create-context parsing failure  SMB2_open() accounts a successful CREATE response as a remote open before parsing its create contexts.  If smb2_parse_contexts() rejects malformed context data, SMB2_open() returns without closing the handle, leaving the server-side handle open and num_remote_opens elevated.  Close the handle after a post-CREATE context parsing failure so the error path releases the remote resource and balances the open count.

CVE-2026-98454:

        In the Linux kernel, the following vulnerability has been resolved:  smb: client: fix create context out-of-bounds reads  smb2_parse_contexts() validates the complete create-context area but does not limit each record to its Next field before dispatching it.  A malformed chain can therefore expose bytes beyond the current context to a handler.  The QFid handler also used a full response-structure cast although it only reads DiskFileId.  The SMB2/SMB3 lease parsers made the same layout assumption: they read LeaseState and LeaseFlags at canonical offsets rather than at DataOffset.  A valid non-canonical DataOffset could therefore yield unrelated in-bounds data, while a short DataLength was still accepted.  Limit each context to its Next value, reject offsets before the context header, and reject malformed chains.  Bound the name range by the current context and do not dispatch a known handler when DataLength is zero.  Read the QFid DiskFileId only when the context data covers that field.  Parse the lease context from DataOffset and require DataLength to match the v1 or v2 lease_context size used by ksmbd.  A size mismatch skips lease parsing without failing the open.

CVE-2026-98456:

        In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: mgmt: fix race in read_unconf_index_list()  read_unconf_index_list() counts unconfigured controllers before allocating its response, then checks the device flags again while filling it.  hci_dev_list_lock stabilizes list membership, but it does not serialize the per-device flags. During asynchronous controller setup, the worker can set HCI_UNCONFIGURED and clear HCI_SETUP between the two passes. A controller omitted from the allocation count can then become eligible for the fill pass, causing an out-of-bounds write to rp->index[].  Allocate space for every device on hci_dev_list. Since list membership cannot change while hci_dev_list_lock is held, the response remains large enough regardless of flag transitions. The reported count and response length still include only eligible unconfigured controllers.

CVE-2026-98466:

        In the Linux kernel, the following vulnerability has been resolved:  KVM: arm64: Transfer the hyp stack pages out of the host stage-2  fix_host_ownership() walks only the linear-map alias of each memblock region, and the per-CPU hyp stack, mapped in the private VA range for its guard page, has none.  Walk each stack's VA range with the same walker.

CVE-2026-98471:

        In the Linux kernel, the following vulnerability has been resolved:  KVM: SEV: Do cache maintenance on the source VM during intra-host migration  Manually perform cache maintenance on the source VM during intra-host migration to ensure no stale data is left in CPU caches after the VM is destroyed.  Because the source VM is "converted" to a non-SEV VM, KVM's memory reclaim flows won't trigger cache maintenance, e.g. when all guest memory is reclaimed in response to detaching from the mmu_notifier.  Note, relying on the destination VM to do cache maintenance isn't an option as KVM doesn't require identical guest memory configurations, i.e. the source VM may have access to memory that the destination VM does not. Enforcing equivalent memory configurations is infeasible, as it would require a *deep* comparison of memslots, e.g. to verify that not only are the memslot identical, but what the memslots point at is also identical.

CVE-2026-98484:

        In the Linux kernel, the following vulnerability has been resolved:  netfilter: nf_tables: skip expired catchall elements on insert and delete  nft_setelem_catchall_insert() looks up duplicates with nft_set_elem_active() only, while nft_set_catchall_lookup() and the dump path additionally skip expired elements.  Once a catchall element with a timeout expires, this predicate drift makes it invisible to userspace dumps, yet it still blocks re-insertion: with NLM_F_EXCL the request fails with -EEXIST, and without it the request reports success but silently inserts nothing. The stale entry only goes away when the (user-tunable) gc interval elapses, so the catchall rule may silently stop matching for an arbitrarily long time after its first expiration.  The delete path shows the same drift: nft_setelem_catchall_deactivate() picks the first active-next entry in the catchall list, so with an expired entry still pending GC it retires the stale entry instead of the fresh one, and it deactivates an element that userspace no longer sees instead of failing with -ENOENT.  Align both walks with the lookup and dump predicates: only an element that is active and not expired counts as a duplicate or delete candidate, using the per-netns timestamp taken at transaction start, in line with the set backend .insert/.deactivate and catchall GC sync paths.

CVE-2026-98486:

        In the Linux kernel, the following vulnerability has been resolved:  net: ena: fix MMIO read buffer leak on probe failure  ena_device_init() initializes the MMIO read mechanism with ena_com_mmio_reg_read_request_init(), which allocates a coherent DMA buffer for MMIO read responses.  The normal removal path releases this buffer through ena_com_mmio_reg_read_request_destroy(). However, if ena_probe() fails after ena_device_init() succeeds, the error path destroys the admin resources and eventually frees ena_dev without destroying the MMIO read request, leaving the coherent DMA buffer allocated.  Call ena_com_mmio_reg_read_request_destroy() in the probe error path before releasing the remaining device resources.  This issue was found by manual code inspection.

CVE-2026-98490:

        In the Linux kernel, the following vulnerability has been resolved:  net: openvswitch: conntrack: fix helper UAF due to extensions realloc  While calling the helpers, a raw pointer to the extensions area is wired into expectations list:    -> nf_ct_helper()    -> helper->help()     -> nf_ct_expect_related_report()      -> nf_ct_expect_insert()       -> hlist_add_head_rcu(&exp->lnode, &master_help->expectations)  In case the connection is not confirmed yet, more extensions can be added afterwards with *_ext_add() calls reallocating the extension space and leaving the now invalid pointer in the expectations list that is later accessed while removing the expectation.  Make sure that helpers are called at the end after all the other extensions are already added.  Note that the helper rejection now leaves the mark and labels set, but that's not different from how the NAT was handled before or how the mark and the labels were handled on confirmation failure.  And there are no atomicity guarantees provided by the API anyway.

CVE-2026-98493:

        In the Linux kernel, the following vulnerability has been resolved:  net: ipconfig: bound DHCP option construction  ic_dhcp_init_options() appends the hostname (option 12), vendor-class (option 60) and client-ID (option 61) options into the fixed 312-byte bootp_pkt.exten[] buffer.  Only the client-ID branch checked the remaining space; the hostname and vendor-class writes were unbounded.  A 64-byte hostname together with the maximum 252-byte dhcpclass= identifier needs 18 + (2 + 64) + (2 + 252) = 338 of the 312 available bytes even before the terminating END marker, so the vendor-class memcpy runs past the end of exten[].  With CONFIG_FORTIFY_SOURCE this is reported as a field-spanning write and, when the kernel is booted with panic_on_warn=1, aborts boot with a panic.  Route the optional options through a common helper that makes sure the option, its 2-byte header and the END marker all fit and drops an option that would not.  Configurations with short options keep sending exactly the same bytes as before.

CVE-2026-98502:

        In the Linux kernel, the following vulnerability has been resolved:  HID: alps: unregister DualPoint Stick input device on remove  alps_input_configured() allocates a second input device ("DualPoint Stick") with input_allocate_device() and registers it, but the alps_driver struct has no .remove handler and input2 is not tracked in hdev->inputs.  The default remove path (hid_hw_stop -> hidinput_disconnect) only iterates hdev->inputs, so input2 is never unregistered and leaks on every device removal.  Add a .remove handler that stops the device first (preventing URB callbacks from touching input2 during teardown) and then unregisters input2.

CVE-2026-98503:

        In the Linux kernel, the following vulnerability has been resolved:  packet: use ubuf_info completion for TX_RING packets  tpacket_snd sends skbs with frags pointing into its ring slots. Slots are released when skb->destructor is called.  A call to skb_orphan calls skb->destructor before the skb is freed. This can cause the slot to be reused while still linked into the skb.  Switch to standard zerocopy completion (ubuf_info) so the slot is only released once all references to the payload are freed or copied. Restore skb->destructor to standard sock_wfree.  The ubuf_info completion callback can be called with a NULL skb, but only from net_zcopy_put and related API, used by zerocopy implementations that hold their own reference on the uarg, such as MSG_ZEROCOPY. This uarg is only ever completed from skb_zcopy_clear, so skb is always set.  To prevent userspace from aliasing in-flight state on shared ring slots, allocate tpacket_uarg per packet, rather than per slot. This adds a small allocation to the transmit path. Use standard kmalloc to allow backporting to stable kernels.  The uarg holds an sk_wmem_alloc reference, rather than an sk_refcnt reference. packet_free_tx_ring waits on sk_wmem_alloc before freeing the ring pages. Always allocate vec->deferred for tx_ring so page-backed rings also wait on sk_wmem_alloc when skb_copy_ubufs drops page refs before calling tpacket_ubuf_complete.  Drop the tx_ring.pg_vec test that tpacket_destruct_skb performed before accessing the slot. The sk_wmem_alloc reference now guarantees that the slot is valid. The test is also not sufficient by itself, as it reads pg_vec without pg_vec_lock, so it can race with packet_set_ring.  As a result a slot is released when its payload is copied, which can be before transmission (e.g., in skb_orphan_frags_rx). If copied before skb_tx_timestamp() is called, no slot timestamp is recorded, similar to when skb_orphan() was called early in the datapath before this patch.  Revert the now unused previous skb_zcopy_.._nouarg infra.  Depends on commit 992cc9f94ca9 ("net/packet: defer vmalloc TX_RING free until skbs finish").

CVE-2026-98505:

        In the Linux kernel, the following vulnerability has been resolved:  mm/damon/vaddr: avoid hw-driven pte updates during damon_hugetlb_mkold()  damon_hugetlb_mkold() reads the page table entry into a local variable, unsets the accessed bit in the variable, and updates the page table entry with the updated variable value.  If hardware updates the same page table entry in parallel, the hw updates could be lost.  For example, hardware-updated dirty bits might be lost.  Avoid the parallel updates by clearing the page table entry when reading it together, using huge_ptep_get_and_clear().  If a parallel write to the memory is made after the clearing, the hw will see the page table entry is cleared, trigger page fault and wait until it is handled.  The page fault handling will wait for damon_hugetlb_mkold() due to the page table lock.  Because hugetlbfs is an in-memory file system and hugetlb pages cannot be reclaimed, no critical issue is expected to my best knowledge.  But definitely this is a nasty bug that should be fixed sooner rather than later.  The issue was discovered [1] by Sashiko.

CVE-2026-98506:

        In the Linux kernel, the following vulnerability has been resolved:  mm/hugetlb: do not dissolve gigantic pages without runtime support  dissolve_free_hugetlb_folio() doesn't check hstate_is_gigantic_no_runtime(h) though remove_hugetlb_folio()/ update_and_free_hugetlb_folio() silently bail for such folios, so it frees a still-listed folio and, on vmemmap restore failure, the add_hugetlb_folio() rollback corrupts the free list.

CVE-2026-98507:

        In the Linux kernel, the following vulnerability has been resolved:  mm/rmap: fix missing barrier between anon_vma init and vma->anon_vma publish  On arm64 server, we find that a task trying to grab the anon_vma lock triggers hungtask.  INFO: task main:2354726 blocked for more than 120 seconds.       Tainted: G            E     5.10.0-0021.aarch64 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:main            state:D stack:    0 pid:2354726 ppid:2350673 flags:0x00000a01 Call trace:  __switch_to+0x7c/0xbc  __schedule+0x3b4/0x8a0  schedule+0x50/0xe0  rwsem_down_write_slowpath+0x3cc/0x6cc  down_write+0x60/0x260  __anon_vma_prepare+0x6c/0x210  do_anonymous_page+0x258/0x660  handle_pte_fault+0x188/0x214  __handle_mm_fault+0x1b0/0x380  handle_mm_fault+0xf4/0x284  do_page_fault+0x19c/0x494  do_translation_fault+0xcc/0xf8  do_mem_abort+0x48/0xac  el0_da+0x44/0x80  el0_sync_handler+0x88/0xb4  el0_sync+0x160/0x180  After analyzing the vmcore, we found the anon_vma->root->rwsem.count is -1.  There is another anon_vma whose anon_vma->root->rwsem.count is 1, the anon_vma->root->rwsem.owner shows the lock is held, but the stack of the task shows the task doesn't hold the anon_vma lock.  After adding more debugging info, we found __anon_vma_prepare() reuses anon_vma and triggers the UAF of anon_vma->root due to missing memory barrier, leading to locking and unlocking two different anon_vma->root, thus leading to an anon_vma will never be unlocked, and another anon_vma couldn't be locked anymore.  This race requires two adjacent VMAs that are not merged but are anon_vma-compatible (e.g., they differ in VMA_ACCESS_FLAGS that can be changed by mprotect()).  Two threads fault on each VMA concurrently, both calling __anon_vma_prepare() with only mmap_lock held for reading.      THREAD A                             THREAD B __anon_vma_prepare                __anon_vma_prepare  find_mergeable_anon_vma() -> NULL  anon_vma = anon_vma_alloc();    anon_vma->root = anon_vma;  // the two stores may be reordered  vma->anon_vma = anon_vma;                                    // finds A's anon_vma                                    anon_vma = find_mergeable_anon_vma(vma);                                    anon_vma_lock_write(anon_vma);                                      // may still see the old root                                      down_write(&anon_vma->root->rwsem);                                    anon_vma_unlock_write(anon_vma);                                      // see the new root, never unlock old                                      up_write(&anon_vma->root->rwsem);  thread A triggers page fault and calls __anon_vma_prepare() to prepare anon_vma for the faulting vma.  __anon_vma_prepare() allocates and initializes a new anon_vma, and then publishes it to the vma with a plain store.  anon_vma_prepare() only requires the mmap_lock to be held for reading, so two threads can fault on adjacent VMAs at the same time.  While thread A publishes a new anon_vma, thread B could find the anon_vma via find_mergeable_anon_vma() and then locks anon_vma->root->rwsem.  The store to anon_vma->root in anon_vma_alloc() and the store to vma->anon_vma can be reordered.  The anon_vma_lock_write() and spin_lock() only provide acquire semantics, which do not prevent prior stores from being reordered after them.  The release semantics of the corresponding spin_unlock() and anon_vma_unlock_write() come too late, the store to vma->anon_vma is already published before they take effect.  As a result, thread B can observe the following order:      vma->anon_vma = anon_vma;     anon_vma->root = anon_vma;  The anon_vma slab is SLAB_TYPESAFE_BY_RCU, so a newly allocated anon_vma may reuse memory from a previously freed one.  The constructor (anon_vma_ctor) does not reset anon_vma->root, and __put_anon_vma() doesn't clear it either, so the old root value persists until anon_vma_alloc() overwrites it.  If that store isn't v ---truncated---

CVE-2026-98508:

        In the Linux kernel, the following vulnerability has been resolved:  drm/virtio: fix NULL pointer dereference on fence allocation failure  virtio_gpu_fence_alloc() can fail due to memory pressure and return NULL, but its caller like virtio_gpu_init_submit() never checks it. Later, virtio_gpu_init_submit() passes the NULL fence to virtio_gpu_fence_event_create(), which unconditionally dereferences it.  Found when fuzzing the virtio driver with Syzkaller:  	Oops: general protection fault, probably for non-canonical address 0xdffffc0000000012: 0000 [#1] SMP KASAN NOPTI 	KASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097] 	CPU: 1 UID: 0 PID: 9991 Comm: syz.0.121 Not tainted 7.2.0 #4 PREEMPT(full) 	Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 	RIP: 0010:virtio_gpu_fence_event_create drivers/gpu/drm/virtio/virtgpu_submit.c:295 [inline] 	RIP: 0010:virtio_gpu_init_submit drivers/gpu/drm/virtio/virtgpu_submit.c:398 [inline] 	RIP: 0010:virtio_gpu_execbuffer_ioctl+0xc78/0x1aa0 drivers/gpu/drm/virtio/virtgpu_submit.c:505 	Code: 85 ed 0f 85 21 09 00 00 e8 05 5a c9 fb 48 8b 44 24 10 48 8d b8 90 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 9a 0d 00 00 48 8b 44 24 10 4c 89 b0 90 00 00 00 	RSP: 0018:ffffc900039dfad0 EFLAGS: 00010216 	RAX: dffffc0000000000 RBX: ffffc900039dfdd8 RCX: ffffffff85f6fd3d 	RDX: 0000000000000012 RSI: ffffffff85f6fd4b RDI: 0000000000000090 	RBP: 0000000000000000 R0virtio_gpu_virgl_process_cmd: ctrl 0x102, error 0x1203 	R10: 0000000000000000 R11: 0000000000000000 R12: ffff8880132c4000 	R13: 0000000000000000 R14: ffff888073b6c700 R15: 000000000000003b 	FS:  00007fab480b96c0(0000) GS:ffff8880eb6e9000(0000) knlGS:0000000000000000 	CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 	CR2: 00007effbf5e55a8 CR3: 0000000048d19000 CR4: 0000000000350ef0 	Call Trace: 	<TASK> 	drm_ioctl_kernel+0x1f4/0x3e0 drivers/gpu/drm/drm_ioctl.c:817 	drm_ioctl+0x5f4/0xc70 drivers/gpu/drm/drm_ioctl.c:914 	vfs_ioctl fs/ioctl.c:51 [inline] 	__do_sys_ioctl fs/ioctl.c:597 [inline] 	__se_sys_ioctl fs/ioctl.c:583 [inline] 	__x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583 	do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] 	do_syscall_64+0x116/0x800 arch/x86/entry/syscall_64.c:94 	entry_SYSCALL_64_after_hwframe+0x77/0x7f 	RIP: 0033:0x7fab471a82bd 	Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 	RSP: 002b:00007fab480b9018 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 	RAX: ffffffffffffffda RBX: 00007fab47435fa0 RCX: 00007fab471a82bd 	RDX: 00002000000000c0 RSI: 00000000c0406442 RDI: 0000000000000003 	RBP: 00007fab480b9080 R08: 0000000000000000 R09: 0000000000000000 	R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 	R13: 00007fab47436038 R14: 00007fab47435fa0 R15: 00007ffe85ab0740 	</TASK> 	Modules linked in: 	---[ end trace 0000000000000000 ]--- 	RIP: 0010:virtio_gpu_fence_event_create drivers/gpu/drm/virtio/virtgpu_submit.c:295 [inline] 	RIP: 0010:virtio_gpu_init_submit drivers/gpu/drm/virtio/virtgpu_submit.c:398 [inline] 	RIP: 0010:virtio_gpu_execbuffer_ioctl+0xc78/0x1aa0 drivers/gpu/drm/virtio/virtgpu_submit.c:505 	Code: 85 ed 0f 85 21 09 00 00 e8 05 5a c9 fb 48 8b 44 24 10 48 8d b8 90 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 9a 0d 00 00 48 8b 44 24 10 4c 89 b0 90 00 00 00 	RSP: 0018:ffffc900039dfad0 EFLAGS: 00010216 	RAX: dffffc0000000000 RBX: ffffc900039dfdd8 RCX: ffffffff85f6fd3d 	RDX: 0000000000000012 RSI: ffffffff85f6fd4b RDI: 0000000000000090 	RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000 	R10: 0000000000000000 R11: 0000000000000000 R12: ffff8880132c4000 	R13: 0000000000000000 R14: ffff888073b6c700 R15: 000000000000003b 	FS:  00007fab480b96c0(0000) GS:ffff888098ae9000(0000) knlGS:00000000 ---truncated---

CVE-2026-98509:

        In the Linux kernel, the following vulnerability has been resolved:  drm/virtio: fix memory leak of fence event on execbuffer failure  virtio_gpu_execbuffer_ioctl() reserves a DRM event with drm_event_reserve_init() when VIRTGPU_EXECBUF_RING_IDX selects a ring that userspace has enabled polling for. virtio_gpu_init_submit() does this before the BO handles, the command buffer, the syncobj arrays and the in-fence are processed, so every later error path runs with the event already pending, including plain argument validation failures such as an invalid bo_handle or an in-syncobj that carries no fence.  On those paths, virtio_gpu_cleanup_submit() drops the out-fence without cancelling the event. The fence is freed without ever having been emitted, taking the only driver-side pointer to the event with it. Closing the DRM file does not help. drm_events_release() unlinks pending events but deliberately leaves the freeing to the driver's later drm_send_event(), which never runs for an orphaned event, so the allocation is leaked permanently.  Found when fuzzing the virtio driver with Syzkaller:  	BUG: memory leak 	unreferenced object 0xffff88802c176e80 (size 96): 	comm "syz.1.367", pid 10561, jiffies 4294960122 	hex dump (first 32 bytes): 		00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................ 		c8 6e 17 2c 80 88 ff ff 00 00 00 00 00 00 00 00  .n.,............ 	backtrace (crc e1973c6b): 		kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] 		slab_post_alloc_hook mm/slub.c:4597 [inline] 		slab_alloc_node mm/slub.c:4917 [inline] 		__kmalloc_cache_noprof+0x49d/0x6f0 mm/slub.c:5485 		_kmalloc_noprof include/linux/slab.h:988 [inline] 		_kzalloc_noprof include/linux/slab.h:1309 [inline] 		virtio_gpu_fence_event_create drivers/gpu/drm/virtio/virtgpu_submit.c:282 [inline] 		virtio_gpu_init_submit drivers/gpu/drm/virtio/virtgpu_submit.c:398 [inline] 		virtio_gpu_execbuffer_ioctl+0xbbf/0x1aa0 drivers/gpu/drm/virtio/virtgpu_submit.c:505 		drm_ioctl_kernel+0x1f4/0x3e0 drivers/gpu/drm/drm_ioctl.c:817 		drm_ioctl+0x5f4/0xc70 drivers/gpu/drm/drm_ioctl.c:914 		vfs_ioctl fs/ioctl.c:51 [inline] 		__do_sys_ioctl fs/ioctl.c:597 [inline] 		__se_sys_ioctl fs/ioctl.c:583 [inline] 		__x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583 		do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] 		do_syscall_64+0x116/0x800 arch/x86/entry/syscall_64.c:94 		entry_SYSCALL_64_after_hwframe+0x77/0x7f  Fix by cancelling and freeing the DRM event on the execbuffer error path before dropping the fence. Clear the fence's event pointer after cancellation so it does not retain a dangling pointer.

CVE-2026-98525:

        In the Linux kernel, the following vulnerability has been resolved:  mctp: route: iterate socket tag list in mctp_lookup_prealloc_tag()  When a socket transmits a packet with MCTP_TAG_PREALLOC set, mctp_lookup_prealloc_tag() iterates over the per-netns &mns->keys list and matches netid, req_tag, peer_addr, and manual_alloc, without checking whether tmp->sk == &msk->sk. This allows any MCTP socket in the same network namespace to use and consume another socket's preallocated tag.  Iterate the socket's own tag list (&msk->keys via sklist) instead of the namespace-wide &mns->keys list in mctp_lookup_prealloc_tag(), ensuring that only tags allocated by msk are matched.  Tested in QEMU against Linux 7.3.0-rc3 by allocating a manual tag (0x18) on socket A via SIOCMCTPALLOCTAG for peer EID 9 and sending a 4-byte message with MCTP_TAG_PREALLOC from socket B in the same network namespace. On the unfixed kernel, sendto(sock_b) using socket A's preallocated tag succeeds (ret = 4); with this patch applied, sendto(sock_b) fails with -ENOENT (errno = 2) while sendto(sock_a) succeeds (ret = 4).

CVE-2026-98539:

        In the Linux kernel, the following vulnerability has been resolved:  fs/ntfs3: use d_instantiate_new() in ntfs_create_inode() and murder syzbot's "WARNING in do_new_mount" saga  ntfs_create_inode() creates a new inode via ntfs_new_inode(). It hashes it with insert_inode_locked() and so it's marked as I_NEW until unlock_new_inode().  ntfs 3 calls d_instantiate() in between though... Since the dentry was already hashed by the lookup before the create any path walk finds it without touching the parent's i_rwsem and so can lock the inode.  If the inode is a directory unlock_new_inode() calls lockdep_annotate_inode_mutex_key() and marks i_rwsem with the i_mutex_dir_key class.  That resets the count and the owner of a lock somebody else may already hold by now...  syzbot has been spamming us with the same godforsaken bug    "WARNING in do_new_mount"  since 2023. I can't take it anymore so I went looking. Afaict, syzbot's executor chdirs into a freshly mounted ntfs3 image, creates a directory and then mounts some pseudofs on it. Everytime the mkdir() takes longer than syzbot waits mount() runs concurrently:    mkdir("./sys")                        mount(NULL, "./sys", "sysfs")   ntfs_create_inode()     d_instantiate()                                         user_path_at() finds the dentry                                         do_lock_mount()                                           inode_lock(inode)                                           namespace_lock()     unlock_new_inode()       lockdep_annotate_inode_mutex_key()         init_rwsem(&inode->i_rwsem)                                         unlock_mount()                                           inode_unlock(inode)  The mount side then releases a lock that according to the rwsem nobody holds:    DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) && ...):   count = 0x0, magic = 0xffff888043a854e8, owner = 0x0,   curr 0xffff888000244880, list empty   WARNING: CPU: 0 PID: 5346 at kernel/locking/rwsem.c:1368 __up_write   Call Trace:    inode_unlock include/linux/fs.h:877 [inline]    unlock_mount fs/namespace.c:2892 [inline]    do_new_mount_fc fs/namespace.c:3828 [inline]    do_new_mount+0x777/0xa40 fs/namespace.c:3887  On PREEMPT_RT the same thing shows up as    DEBUG_LOCKS_WARN_ON(rt_mutex_owner(lock) != current)   WARNING: kernel/locking/rtmutex_common.h:193 at rt_mutex_slowunlock  The up_write() underflows the reset count. A following inode_lock() on that directory then never returns. A path walk into the new directory racing with the mkdir() corrupts the lock the same way via inode_lock_shared() in lookup_slow().  Switch to d_instantiate_new() and drop the trailing unlock_new_inode(). All error paths bail out before that point with I_NEW still set and keep using discard_new_inode().  May we never see this fscking bug report again.

CVE-2026-98544:

        In the Linux kernel, the following vulnerability has been resolved:  bna: prevent IOC timer rearm during teardown  bna: prevent IOC timer rearm during teardown  bnad_pci_remove() and the probe disable_ioceth path call timer_delete_sync() for ioc_timer, sem_timer and hb_timer, but not for iocpf_timer.  bnad_iocpf_timeout() then takes bnad->bna_lock after free_netdev() has freed the struct bnad.  Deleting iocpf_timer last does not fix this.  sem_timer and iocpf_timer rearm each other: bnad_iocpf_sem_timeout() can arm iocpf_timer, and bnad_iocpf_timeout() arms sem_timer from bfa_ioc_hw_sem_get() when the semaphore is busy. timer_delete_sync() only waits out its own callback. bnad_ioceth_disable() can time out and leave that callback live.  Shut all four IOC timers down with timer_shutdown_sync() on both paths, so a later mod_timer() is ignored.  This issue was identified during our ongoing static-analysis research while reviewing kernel code.

CVE-2026-98549:

        In the Linux kernel, the following vulnerability has been resolved:  tcp: prevent collapsing skbs across boundary in rtx queue  tcp_write_collapse_fence() sets TCP_SKB_CB(skb)->eor = 1 on tcp_write_queue_tail(sk) to prevent skbs queued after a switch to device encryption from being collapsed into earlier skbs.  The fence is a no-op if all earlier data has already been transmitted when the switch happens: sk->sk_write_queue is empty. The not yet acknowledged earlier skbs wait in sk->tcp_rtx_queue with eor 0.  On a subsequent retransmit or SACK shift, tcp_retrans_try_collapse() or tcp_shift_skb_data() can then merge an skb queued after the switch into one queued before it.  Both users of the fence are affected:  - psp: devices only encrypt skbs with skb->decrypted set. The merged skb   keeps decrypted = 0 from the earlier skb, so merged data sent after   psp_sock_assoc_set_tx() is retransmitted in cleartext.  - tls device offload: the merged skb straddles the start marker set in   tls_set_device_offload(). The software fallback (fill_sg_in() returns   -EINVAL) and the mlx5, nfp and funeth drivers cannot handle such an   skb and drop it. Every retransmit rebuilds the same skb, so the   connection stalls.  Fix this in two places, for defense in depth:  1. Fall back to tcp_rtx_queue_tail(sk) in tcp_write_collapse_fence()    when tcp_write_queue_tail(sk) is NULL.  2. Check !skb_cmp_decrypted(to, from) in tcp_skb_can_collapse(), as    tcp_skb_can_collapse_rx() does on receive. skb_shift(), which both    collapse paths call, already has a DEBUG_NET_WARN_ON_ONCE() for this    condition.

CVE-2026-98551:

        In the Linux kernel, the following vulnerability has been resolved:  perf/core: Fill branch entries with a single assignment  perf_clear_branch_entry_bitfields() clears the bitfields of struct perf_branch_entry one by one and leaves from/to alone, since callers overwrite those straight away. The list has to be kept in sync with the struct by hand and has already fallen behind: new_type and priv were added to perf_branch_entry and never added here.  Only BRBE writes those two, and neither for every record. brbe_set_perf_entry_type() leaves new_type alone for a branch type it does not recognise, and priv is not set for source-only records. arm_pmuv3.c allocates the per-CPU branch stack with kmalloc(), so such a record reaches userspace with whatever the slot held: uninitialised kmalloc() data on the first pass over the buffer, the previous record's values after that. Nothing under arch/x86/events/ writes either field, so only arm64 is affected.  Assign the whole entry at each site instead. Everything not named is then zero, and there is no list to keep in sync. The bitfields add up to exactly 64 bits, so the struct has no padding to leave undefined.  perf_clear_branch_entry_bitfields() has no callers left, so remove it. perf_entry_from_brbe_regset() assigns an empty literal instead, since it fills from/to conditionally. PERF_BR_SPEC_NA is 0, so dropping the explicit spec assignment changes nothing.

CVE-2026-98556:

        In the Linux kernel, the following vulnerability has been resolved:  gve: DQO: reject TSO packets with an out of range MSS  gve_prep_tso() notes that the device requires the MSS to be <= 9728, but does not enforce it, assuming the 9K MTU enforced by the hypervisor and the 64KB limit on TSO sizes are enough.  This does not hold for packets that were not generated locally. A guest behind a tap, or any packet socket user, can provide an arbitrary gso_size in virtio_net_hdr. Layer 2 forwarding does not check the MTU for GSO packets (is_skb_forwardable()), and gso_features_check() only bounds skb->len and gso_segs, never gso_size.  Such a packet reaches gve_tx_fill_tso_ctx_desc(), which puts gso_size into the mss field of the TSO context descriptor. This field is 14 bits wide, so a gso_size of 16384 is silently turned into an MSS of zero.  Drop these packets from gve_prep_tso(), and make sure that gve_features_check_dqo() leaves their GSO bits alone: skb_segment() splits at gso_size regardless of the MTU, so falling back to software segmentation would give the device non TSO packets bigger than the 9728 bytes it supports.  Note that the device can still be given oversized non TSO packets when the stack segments in software for other reasons, for instance after TSO has been disabled with ethtool. This is a generic issue, because the MTU check is skipped for GSO packets in the forwarding path, and is addressed separately.

CVE-2026-98558:

        In the Linux kernel, the following vulnerability has been resolved:  net: flush skb_defer_nodes in dev_cpu_dead()  When a CPU goes offline, dev_cpu_dead() drains its softnet queues (completion_queue, output_queue, poll_list, process_queue, and input_pkt_queue), but leaves net_hotdata.skb_defer_nodes untouched.  If oldcpu goes offline while holding pending skbs in its skb_defer_nodes lists (e.g. below the sysctl_skb_defer_max >> 1 IPI threshold, or if the IPI races with CPU teardown), those skbs remain stranded until oldcpu is brought back online. If any of these skbs hold page_pool fragments, page_pool_destroy() will stall indefinitely waiting for inflight pages to be returned when a netdev or driver is torn down while oldcpu is offline.  Additionally, if smp_call_function_single_async() fails in kick_defer_list_purge() because the target CPU went offline, reset defer_ipi_scheduled to 0 so future IPI kicks are not blocked when the CPU comes back online.  Also, if oldcpu was the last online CPU on its NUMA node, drain that node's slot across all CPUs so no skbs deferred from that node remain stranded on idle remote CPUs (or if the node itself is subsequently offlined).  Finally, in skb_attempt_defer_free(), re-check cpu_online(cpu) and whether the caller migrated CPUs after llist_add(), flushing the node list if so, to close the preemption TOCTOU race against CPU/node teardown.

CVE-2026-98565:

        In the Linux kernel, the following vulnerability has been resolved:  net: dsa: mt7530: fix NULL dereference on unbind of MT7531 and MT7621  The core and io supplies are only requested for ID_MT7530: both the devm_regulator_get() in probe and the regulator_enable() in mt7530_setup() are guarded by the switch id, but mt7530_remove() disables them unconditionally. On an MT7621 or an MT7531 both pointers are still NULL from devm_kzalloc(), so rmmod or a sysfs unbind calls regulator_disable() on NULL.

CVE-2026-98568:

        In the Linux kernel, the following vulnerability has been resolved:  vxlan: use one headroom snapshot for neighbour replies  vxlan_na_create() samples LL_RESERVED_SPACE() to size the reply skb and then samples it again to reserve headroom. A concurrent vxlan_changelink() can update needed_headroom between the two reads, creating a TOCTOU race. The second value can exceed the allocation and make the Ethernet header write out of bounds.  The race is reproducible on the unpatched kernel. It occurred when vxlan_na_create() generated a neighbour reply while vxlan_changelink() changed the link headroom. KASAN caught a four-byte write two bytes beyond a 704-byte skbuff_small_head allocation.  Snapshot the headroom once and use that value for both allocation and reservation.

CVE-2026-98570:

        In the Linux kernel, the following vulnerability has been resolved:  net: ipv6: keep room for the mac header in dst_dev_overhead()  The seg6, ioam6 and rpl lwtunnels size their skb_cow_head() request as the length they are about to push plus dst_dev_overhead(), then push the new headers and rebuild the mac header below them with skb_mac_header_rebuild().  That rebuild needs skb->mac_len of headroom, but dst_dev_overhead() leaves LL_RESERVED_SPACE() of the egress device, 16 bytes for plain Ethernet.  Where the mac header is longer than that, as it is on ingress through a VLAN device with reorder_hdr off, the rebuild runs out of room: skb_set_mac_header(skb, -skb->mac_len) computes a negative offset, stores it unchecked in the u16 skb->mac_header, and the memmove that follows writes skb->mac_len bytes about 64 KB past skb->head. Forwarding plain ping6 traffic through such a device reproduces it on all five seg6 encapsulation modes and on the rpl and ioam6 inline paths; skb->mac_header comes back as 65534 on a 704-byte head.  Return the larger of the two.  The helper already returns skb->mac_len when it has no dst, so this only makes the other branch agree, and it covers every caller rather than each call site in turn.

CVE-2026-98589:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: Reject pkt arguments in mutating subprogs  The verifier tracks changes in how PTR_TO_PACKET registers' bounds are modified across subprog boundaries. PTR_TO_PACKET registers are actually passed as PTR_TO_MEM, which is assumed valid for the entire call. This is not the case with packet memory, where a pskb_* call may invalidate its memory region.  Reject BPF code that passes PTR_TO_PACKET pointers to subprogs that may mutate a packet. We cannot pass the pointer as a true PTR_TO_PACKET because we would also need to somehow pass the PTR_TO_PACKET_META or PTR_TO_PACKET_END to the subprog. Since we cannot avoid representing the pointer in the subprog as PTR_TO_MEM, only permit it if the subprog is guaranteed not to mutate the packet.

CVE-2026-98598:

        In the Linux kernel, the following vulnerability has been resolved:  ipv6: Prevent rt6_insert_exception() for dying fib6_info.  Before the cited commit, fib6_nh_flush_exceptions() always set from->exception_bucket_flushed = 1 under rt6_exception_lock to prevent rt6_insert_exception() from inserting a new exception for a dying fib6_info.  The flag was replaced with the FIB6_EXCEPTION_BUCKET_FLUSHED bit stored in nh->rt6i_exception_bucket.  The problem is that now the bit is only set when the bucket is not NULL and fib6_nh_flush_exceptions() is called from fib6_nh_release() after fib6_ref has already reached zero.  If rt6_insert_exception() is called while the target fib6_info is being removed via fib6_purge_rt(), a new exception could be created successfully because rt6_flush_exceptions() no longer sets the bit.  This creates a reference cycle between the fib6_info and the exception route, leaking the fib6_info, its nexthop device, and all per-CPU routes in fib6_nh->rt6i_pcpu, which stalls netdev unregistration.  [   34.680602] unregister_netdevice: waiting for gre6 to become free. Usage count = 68 [   44.920675] unregister_netdevice: waiting for gre6 to become free. Usage count = 68 [   55.176582] unregister_netdevice: waiting for gre6 to become free. Usage count = 68  Let's call fib6_drop_pcpu_from() before rt6_flush_exceptions(), to set fib6_destroying before rt6_exception_lock, and check f6i->fib6_destroying in rt6_insert_exception().  Note that FIB6_EXCEPTION_BUCKET_FLUSHED logic is dead and we can clean it up in net-next.

CVE-2026-98620:

        In the Linux kernel, the following vulnerability has been resolved:  net: ethernet: mtk_eth_soc: unregister net_devices in case of probe failure  If register_netdev() fails for one of the MTK_MAX_DEVS devices in mtk_probe(), the error path jumps to err_deinit_ppe, skipping mtk_unreg_dev(). The previously registered net_devices are then freed by mtk_free_dev() while still in NETREG_REGISTERED state, hitting the BUG_ON(dev->reg_state != NETREG_UNREGISTERED).  Route the register_netdev() failure to err_unreg_netdev so the net_devices registered so far are properly unregistered before being freed.

CVE-2026-98628:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: Make post-verification instruction rewrites killable  After do_check() returns, the verifier runs several instruction rewrite passes. Some of them patch or remove one instruction at a time. Each operation moves the remaining instruction and auxiliary-data arrays and adjusts all branch offsets, making the overall work quadratic in the program length.  A privileged loader can submit 131072 unconditional jumps by zero followed by a valid return. Verification finishes quickly, but bpf_opt_remove_nops() then spends a long time removing each jump separately. Since this post-verification work neither checks for signals nor reschedules, a pending SIGKILL cannot terminate the task until the rewrite finishes.  Make bpf_patch_insn_data() and verifier_remove_insns() common cancellation and rescheduling points. These helpers run from BPF_PROG_LOAD process context, and bpf_patch_insn_data() can already sleep while reallocating auxiliary data.  Report interrupted constant blinding as -EINTR and propagate it through both JIT paths, including kernels that permit interpreter fallback. Other blinding failures retain the existing fallback behavior.  This does not reduce the quadratic cost of the rewrite passes, but it makes the work preemptible and allows a killed loader to be torn down promptly.

CVE-2026-98634:

        In the Linux kernel, the following vulnerability has been resolved:  scsi: sd_zbc: Reject disks with too many zones  sd_zbc_read_zones() computes the number of zones with 64-bit arithmetic and stores the result in the unsigned int nr_zones field of struct zoned_disk_info, silently truncating counts that exceed 32 bits. The truncated count is later used to size per-zone resources, while the device may still report more zones than fit.  Moreover, sd_zbc_report_zones() counts the reported zones with a signed int zone_idx, which overflows past INT_MAX. Reject devices reporting more than INT_MAX zones at scan time; such a device is not realistic for any medium that exists today, and accepting it produces inconsistent zone bookkeeping.

CVE-2026-98652:

        In the Linux kernel, the following vulnerability has been resolved:  KVM: s390: Add missing srcu in kvm_s390_set_irq_state()  Like kvm_s390_inject_vcpu(), kvm_s390_set_irq_state() also needs the kvm->srcu or the slots lock when performing the Store status operation.  Fix by taking kvm->srcu in kvm_s390_set_irq_state().

CVE-2026-98655:

        In the Linux kernel, the following vulnerability has been resolved:  perf: Require kernel access for text poke events  Perf events with exclude_kernel=1 can be opened without kernel perf access. However, exclude_kernel does not suppress text-poke sideband records. Every PERF_RECORD_TEXT_POKE is marked PERF_RECORD_MISC_KERNEL and contains a raw kernel instruction address.  An unprivileged task can therefore open and mmap a task-local software event with text_poke=1. Both opening a count-only tracepoint event and configuring UDP GRO for ESP-in-UDP cause updates to inline static calls; the observer receives the relocated addresses of the modified instructions. For a known kernel image, any such address reveals the runtime kernel text base despite KASLR.  Call perf_allow_kernel() whenever attr.text_poke is set, regardless of exclude_kernel. Events that neither monitor kernel execution nor request text-poke records retain their existing permissions.

CVE-2026-98656:

        In the Linux kernel, the following vulnerability has been resolved:  iio: trigger: cancel reenable_work before freeing trigger  iio_trigger_notify_done_atomic() defers ->reenable() into trig->reenable_work on the system workqueue, and the worker dereferences the owning trigger through container_of().  Nothing cancels this work before iio_trig_release() frees the trigger, so a worker armed by the last in-flight IRQ can outlive the free and touch freed memory.  Cancel it at the top of iio_trig_release(), which every free path reaches through the device core's final put_device().  Found by an in-house static analysis tool.

CVE-2026-98657:

        In the Linux kernel, the following vulnerability has been resolved:  iio: proximity: pulsedlight: fix iio_device left registered on PM setup failure  pm_runtime_set_active() failing in probe() jumps to error_unreg_buffer, which only calls iio_triggered_buffer_cleanup() -- it does not undo the iio_device_register() that already succeeded a few lines above. probe() then returns the error, the devm-managed indio_dev is freed, but the iio core still has it registered: the sysfs/chardev nodes stay live and point at freed memory.  Add an error_unreg_dev label that unregisters the iio device before falling through to the existing buffer cleanup, mirroring the teardown order already used in lidar_remove().

CVE-2026-98660:

        In the Linux kernel, the following vulnerability has been resolved:  iio: pressure: bmp280: fix out-of-bounds access in sampling frequency lookup  The sampling frequency tables store each frequency as an integer part and a fractional part in micro units. num_sampling_freq_avail is initialized to the number of flattened integer elements because read_avail() returns the table as a flat array.  bmp280_write_sampling_frequency(), however, indexes the same table as a two-dimensional array and uses num_sampling_freq_avail as the number of rows. Convert the flattened element count back to the number of rows before iterating over the table.

CVE-2026-98662:

        In the Linux kernel, the following vulnerability has been resolved:  iio: light: gp2ap020a00f: drain irq_work after free_irq  The threaded IRQ handler queues data->work through irq_work_queue() so the trigger is polled from a per-CPU context.  free_irq() does not flush an irq_work the handler already queued, so after gp2ap020a00f_remove() returns that work may still run and call iio_trigger_poll() on data->trig, which the devm cleanup has already freed, causing a use-after-free.  Add irq_work_sync(&data->work) after free_irq() in remove() and in the probe error path, mirroring commit 78601726d4a5 ("iio: trigger: sysfs: fix use-after-free on remove").  Found by an in-house static analysis tool, confirmed by manual review.

CVE-2026-98663:

        In the Linux kernel, the following vulnerability has been resolved:  iio: imu: adis16480: fix unprotected debugfs reads  The firmware_revision and firmware_date file operations are open coded and never call debugfs_file_get(), which debugfs_create_file_unsafe() requires. debugfs_remove_recursive() therefore does not wait for a read in progress, and unbind frees the iio_dev underneath it.  Use debugfs_create_file() instead.

CVE-2026-98664:

        In the Linux kernel, the following vulnerability has been resolved:  iio: imu: adis16400: fix unprotected debugfs reads  adis16400_serial_number_fops is open coded and never calls debugfs_file_get(), so debugfs_remove_recursive() does not wait for a read in progress and unbind frees the iio_dev underneath it.  Commit ae1d37a9bb4b ("iio: imu: adis16400: use DEFINE_DEBUGFS_ATTRIBUTE instead of DEFINE_SIMPLE_ATTRIBUTE") converted product_id and flash_count to DEFINE_DEBUGFS_ATTRIBUTE, which protects itself, but moved all three files to debugfs_create_file_unsafe().  serial_number prints three registers as "%.4x-%.4x-%.4x" and DEFINE_DEBUGFS_ATTRIBUTE() formats a single u64, so it cannot be converted without changing what the file returns. adis16475 and adis16550 already use debugfs_create_file() for their open coded files. Use it here too.

CVE-2026-98665:

        In the Linux kernel, the following vulnerability has been resolved:  iio: health: max30102: fix NULL dereference in interrupt handler  The interrupt is requested in max30102_probe() and stays enabled for the lifetime of the device, but indio_dev->active_scan_mask is only valid while a buffer is enabled. When an interrupt arrives while no buffer is enabled, the handler dereferences the NULL active_scan_mask:    Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000   Call trace:    __bitmap_weight+0x64/0x98 (P)    max30102_interrupt_handler+0x48/0x160 [max30102]  Call max30102_fifo_count() at the top of the handler and return early unless it reports a FIFO sample is ready. Because FIFO_RDY is the only interrupt source enabled in max30102_chip_init(), an invocation of max30102_interrupt_handler() without the FIFO_RDY interrupt status bit set carries no data to read and can return before touching active_scan_mask. A negative return from max30102_fifo_count() indicates a failed interrupt status read and is treated the same way.

CVE-2026-98666:

        In the Linux kernel, the following vulnerability has been resolved:  iio: gyro: adis16136: fix unprotected debugfs reads  The serial_number file operations are open coded and never call debugfs_file_get(), which debugfs_create_file_unsafe() requires. debugfs_remove_recursive() therefore does not wait for a read in progress, and unbind frees the iio_dev underneath it.  Use debugfs_create_file() instead.

CVE-2026-98668:

        In the Linux kernel, the following vulnerability has been resolved:  iio: buffer: Ensure bounce buffer used for unaligned case is zeroed.  iio_push_to_buffers_with_ts_unaligned() leaks uninitialized heap memory to userspace if the data passed in is not a multiple of 8 bytes and the timestamp is enabled. Specify __GFP_ZERO for the devm_krealloc() to ensure any extra space is cleared.

CVE-2026-98669:

        In the Linux kernel, the following vulnerability has been resolved:  iio: buffer: serialize buffer teardown with mode claims  Buffer-mode claims hold mlock to guarantee that the device remains in buffer mode until the claim is released. Normal buffer updates take info_exist_lock followed by mlock in iio_update_buffers().  However, iio_device_unregister() disables and deactivates all buffers without taking mlock. This can invalidate buffer state, including active_scan_mask, while a buffer-mode claim is held.  Take mlock in iio_disable_all_buffers() so that unregister honors the mode-claim lifetime guarantee. The info_exist_lock -> mlock ordering matches iio_update_buffers().

CVE-2026-98670:

        In the Linux kernel, the following vulnerability has been resolved:  iio: adc: xilinx-xadc: free IRQ before cancelling the unmask worker on unbind  The ZYNQ XADC alarm IRQ handler queues zynq_unmask_work via schedule_delayed_work(); that work is cleared by a devm callback. Register the devm callback before devm_request_irq() so the devres LIFO teardown frees the IRQ first, ensuring the handler can no longer queue work by the time the workqueue is cleared. Otherwise the handler could re-arm the work and run it after the xadc structure has been freed.  This issue was found by an in-house static analysis tool.

CVE-2026-98671:

        In the Linux kernel, the following vulnerability has been resolved:  iio: adc: sun4i-gpadc-iio: clean up on thermal zone registration failure  If devm_thermal_of_zone_register() fails, probe returns without unregistering the IIO map array or disabling runtime PM.  Jump to err_map to release them.

CVE-2026-98672:

        In the Linux kernel, the following vulnerability has been resolved:  iio: adc: stm32-adc: fix possible division by zero in processed channel  In case the conversion has failed or returned zero, processing *val can lead to a division by zero. Need to check for errors, or converted value is zero, before processing the data. In case the converted value is zero, e.g. the Vrefint channel, this should be considered as invalid in all cases.

CVE-2026-98677:

        In the Linux kernel, the following vulnerability has been resolved:  iio: adc: ad_sigma_delta: fix use-after-free on unbind  ad_sd_buffer_postenable() allocates sigma_delta->samples_buf with devm_krealloc() at runtime, so its devres entry sits after all probe-time entries of the driver. devm resources are released in reverse allocation order, which means unbind frees samples_buf before iio_device_unregister() disables the buffers and detaches the trigger pollfunc. The data ready IRQ is still enabled at that point, so ad_sd_trigger_handler() can still run and memcpy() incoming samples into the freed samples_buf.  Fix this by preallocating the buffer in devm_ad_sd_setup_buffer_and_trigger(), before the triggered buffer and the IRQ are set up, so it is freed only after iio_device_unregister() has drained the trigger handler via free_irq(). Size it for the worst case of all sequencer slots being active; ad_sd_validate_scan_mask() already caps the number of active channels at num_slots.  This issue was found by an in-house static analysis tool.

CVE-2026-98679:

        In the Linux kernel, the following vulnerability has been resolved:  iio: accel: kxcjk-1013: reject duplicate event disable  The IIO core does not filter duplicate writes to the event enable attribute. kxcjk1013_write_event_config() already ignores repeated enable requests, but a repeated disable request still calls kxcjk1013_set_power_state(data, false), dropping a runtime PM reference that was not acquired for this request. This can underflow the runtime PM usage count and trigger a "Runtime PM usage count underflow" warning.  Return early when the requested state already matches ev_enable_state.

CVE-2026-98681:

        In the Linux kernel, the following vulnerability has been resolved:  smb: client: split cifsFileInfo bitfields to avoid shared-byte RMW races  The invalidHandle, swapfile, oplock_break_cancelled, offload, and status_file_deleted fields are stored in the same bitfield byte in struct cifsFileInfo, but are updated in different code paths that may run simultaneously, and are protected by different locks.  Since bitfield assignments generate byte-level read-modify-write operations, a modification to one flag can overwrite a concurrent modification to another flag.  To avoid these races, convert these flags from a bitfield to separate bool fields.

CVE-2026-98682:

        In the Linux kernel, the following vulnerability has been resolved:  smb: client: drain and invalidate before server-side copy/clone  cifs_file_copychunk_range() and the clone (FICLONE) path of cifs_remap_file_range() do not serialise the destination page cache against the server-side copy the way the other server-side range operations (smb3_zero_range(), smb3_punch_hole(), smb3_collapse_range() and smb3_insert_range()) do.  cifs_file_copychunk_range() invalidates the destination range with filemap_invalidate_inode(), which takes and drops the mapping's invalidate_lock internally, so the lock is no longer held when the copychunk ioctl is issued.  It also never drains in-flight netfs I/O on the target.  The clone path never takes the invalidate_lock at all (only i_rwsem), uses a bare truncate_inode_pages_range() and likewise does not drain outstanding I/O.  As a result an asynchronous destination writeback can complete after the server-side copy/clone has run and reinstate stale data over the region just written by the server, corrupting the file.  This is the same class of corruption as commit d7d2adcd022b ("smb/client: flush dirty data before punching a hole") and has been seen randomly in generic/363 against Windows Server.  Fix both paths to follow the established ordering: hold the target mapping's invalidate_lock across the flush and invalidation of the destination and the server ioctl, and call netfs_wait_for_outstanding_io() on the target to drain in-flight writes before the ioctl is issued.  Only the target inode's invalidate_lock is required, as the source is merely flushed and not invalidated; i_rwsem (already held via lock_two_nondirectories()) is acquired before the invalidate_lock, matching the VFS lock ordering.  Since filemap_invalidate_inode() takes that same lock internally, replace it with its own unmap/flush/invalidate steps instead of calling it, and return early on a zero-length copy to avoid a range underflow.

CVE-2026-98683:

        In the Linux kernel, the following vulnerability has been resolved:  smb: client: flush dirty data before zeroing a range  smb3_zero_range() emulates FALLOC_FL_ZERO_RANGE by invalidating the page cache over the target range with truncate_pagecache_range() and then issuing FSCTL_SET_ZERO_DATA to the server.  Dirty data was only flushed conditionally, when the range reached or extended EOF.  For a purely interior zero range that does not reach EOF, no flush happened, so a dirty folio overlapping the range could be written back to the server after the FSCTL and refill the range that was just zeroed with stale data.  Fix this by unconditionally flushing and waiting for dirty data in the range before invalidating the page cache and issuing FSCTL_SET_ZERO_DATA, exactly as was done for smb3_punch_hole() in commit d7d2adcd022b ("smb/client: flush dirty data before punching a hole"); the two paths are structurally identical here.  This is observed as generic/363 randomly reading stale data where a zeroed range is expected against Windows Server.

CVE-2026-98684:

        In the Linux kernel, the following vulnerability has been resolved:  smb: client: flush and commit data before querying allocated ranges  The mode 0 / FALLOC_FL_KEEP_SIZE fallocate emulation for small interior ranges in smb3_simple_fallocate_range() issues FSCTL_QUERY_ALLOCATED_RANGES and zero-fills any sub-range the server reports as an unallocated hole, to force block allocation without changing file contents.  This is unsafe against Windows servers.  Per the Win32 documentation, FSCTL_QUERY_ALLOCATED_RANGES only reports ranges that *may* contain nonzero data and is explicitly not coherent with recently written data:    "a call to FSCTL_QUERY_ALLOCATED_RANGES [after writing to a network    file] would not necessarily return a correct list of allocated    regions.  To ensure coherency [...] flush the data to the file"  fsx (generic/363) reproduces the resulting corruption against Windows Server 2022: a range is written, an uncached read returns the data, yet the next FSCTL_QUERY_ALLOCATED_RANGES on that range reports it as a whole hole, so the emulation overwrites live data with zeroes.  A network trace confirmed the WRITE, the READ returning data and the query returning an empty range list within microseconds.  Samba does not exhibit this; its query is coherent with the written data.  Write back the dirty pages, drain any outstanding I/O and issue an SMB2 FLUSH to force the server to commit the data before querying the allocated ranges, so the query reflects the data actually present.  With this, generic/363 passes against both Windows Server 2022 and Samba over 100000 fsx operations.

CVE-2026-98685:

        In the Linux kernel, the following vulnerability has been resolved:  smb: client: discard post-EOF pagecache when extending a file via clone range  cifs_remap_file_range() discarded the pagecache only for the folios overlapping the destination region, so when a clone extends the file the folio straddling the old EOF - which may hold data dirtied past EOF through an mmap - was never dropped and became visible as file content once the file was extended.  Start the discard at the smaller of fstart and the old EOF.  i_size is still old here, so nothing past the old EOF is flushed to the server.

CVE-2026-98686:

        In the Linux kernel, the following vulnerability has been resolved:  smb: client: discard post-EOF pagecache when extending a file via zero range  smb3_zero_range() removed the pagecache only for the range being zeroed, so when it extends the file the folio straddling the old EOF - which may hold data dirtied past EOF through an mmap - was never dropped and became visible as file content once the file was extended.  Lower the discard boundary to the smaller of the zero-range offset and the old EOF.

CVE-2026-98687:

        In the Linux kernel, the following vulnerability has been resolved:  thunderbolt: Reject oversized XDomain properties responses  tb_xdp_properties_request() allocates room for 45 data dwords in its 252-byte response buffer.  The XDomain length field is six bits wide, however, and a malicious peer can set it to 63.  After the fixed response fields are subtracted, the driver treats this as 48 data dwords.  Commit 322e93448d90 ("thunderbolt: Clamp XDomain response data copy to allocation size") only bounds the copy against data_len.  If data_len is at least 48, memcpy() reads 192 bytes from the 180-byte res->data array, causing a 12-byte heap out-of-bounds read.  Commit 4db2bd2ed478 ("thunderbolt: Limit XDomain response copy to actual frame size") limits the earlier copy but does not constrain this header-derived length.  Reject response data lengths that exceed the allocated source buffer before copying them into the assembled property block.

CVE-2026-98694:

        In the Linux kernel, the following vulnerability has been resolved:  thunderbolt: Fix KASAN reported use-after-free when request is canceled  Alan reported that when doing stress testing sometimes KASAN notices use-after-free during control channel operation (stripped down keeping the relevant parts):   BUG: KASAN: slab-use-after-free in tb_cfg_request_sync+0x240/0x250 [thunderbolt]  Read of size 24 at addr ffff88811067f290 by task kworker/u40:2/1760   <TASK>   tb_cfg_request_sync+0x240/0x250 [thunderbolt]   tb_cfg_read_raw+0x367/0x510 [thunderbolt]   tb_cfg_read+0xec/0x240 [thunderbolt]   tb_port_get_link_generation+0x258/0x420 [thunderbolt]   tb_usb3_consumed_bandwidth+0x1c1/0x2c0 [thunderbolt]   tb_tunnel_consumed_bandwidth+0xfd/0x910 [thunderbolt]   tb_available_bandwidth+0x5f2/0xeb0 [thunderbolt]   tb_recalc_estimated_bandwidth+0x2a0/0x1bc0 [thunderbolt]   tb_handle_dp_bandwidth_request+0x1897/0x5e20 [thunderbolt]   process_one_work+0x675/0x1230   worker_thread+0x5e6/0xf70   kthread+0x365/0x470   ret_from_fork+0x54d/0x710   ret_from_fork_asm+0x1a/0x30   </TASK>   Allocated by task 1760:   __kmalloc_cache_noprof+0x1ee/0x550   tb_cfg_read_raw+0x1d3/0x510 [thunderbolt]   tb_cfg_read+0xec/0x240 [thunderbolt]   tb_port_get_link_generation+0x258/0x420 [thunderbolt]   tb_usb3_consumed_bandwidth+0x1c1/0x2c0 [thunderbolt]   tb_tunnel_consumed_bandwidth+0xfd/0x910 [thunderbolt]   tb_available_bandwidth+0x5f2/0xeb0 [thunderbolt]   tb_recalc_estimated_bandwidth+0x2a0/0x1bc0 [thunderbolt]   tb_handle_dp_bandwidth_request+0x1897/0x5e20 [thunderbolt]   process_one_work+0x675/0x1230   worker_thread+0x5e6/0xf70   kthread+0x365/0x470   ret_from_fork+0x54d/0x710   ret_from_fork_asm+0x1a/0x30   Freed by task 926:   kfree+0x18f/0x4a0   tb_cfg_request_put+0xb7/0xe0 [thunderbolt]   tb_cfg_request_work+0x82/0x120 [thunderbolt]   process_one_work+0x675/0x1230   worker_thread+0x5e6/0xf70   kthread+0x365/0x470   ret_from_fork+0x54d/0x710   ret_from_fork_asm+0x1a/0x30   Second to last potentially related work creation:   __queue_work+0x575/0xd00   queue_work_on+0x77/0x80   tb_cfg_request_cancel+0xc7/0x260 [thunderbolt]   tb_cfg_request_sync+0x1f6/0x250 [thunderbolt]   tb_cfg_read_raw+0x367/0x510 [thunderbolt]   tb_cfg_read+0xec/0x240 [thunderbolt]   tb_port_get_link_generation+0x258/0x420 [thunderbolt]   tb_usb3_consumed_bandwidth+0x1c1/0x2c0 [thunderbolt]   tb_tunnel_consumed_bandwidth+0xfd/0x910 [thunderbolt]   tb_available_bandwidth+0x5f2/0xeb0 [thunderbolt]   tb_recalc_estimated_bandwidth+0x2a0/0x1bc0 [thunderbolt]   tb_handle_dp_bandwidth_request+0x1897/0x5e20 [thunderbolt]   process_one_work+0x675/0x1230   worker_thread+0x5e6/0xf70   kthread+0x365/0x470   ret_from_fork+0x54d/0x710   ret_from_fork_asm+0x1a/0x30  The last stack trace is helpful because it shows that we are cancelling a request and looking at tb_cfg_request_cancel() what might happen is that tb_cfg_request_work() completes right before tb_cfg_request_cancel() starts and because of this it will call schedule_work() queueing the same work to run again. However, it is already removed from the request_queue and reference count is dropped so when tb_cfg_request_work() triggers again it will access memory that is already released.  Fix this so that we first make sure a cancelled request is not handed away from tb_cfg_request_find() or scheduled to run. Then instead of relying on the worker to clean up the request we will do it in tb_cfg_request_cancel() after the work is canceled from running. Make tb_cfg_request_dequeue() release the request only if it was actually removed from the queue.

CVE-2026-98695:

        In the Linux kernel, the following vulnerability has been resolved:  USB: serial: fix ioctl hangup race  The tty ioctls can race with hangup and end up calling into a tty driver for a device that is already gone or powered down.  Serialise the callbacks using the tty port mutex and add the missing checks to make sure the port has not been hung up before accessing port driver data or hardware.  This specifically avoids dereferencing a NULL-pointer if a device is disconnected during lengthy break signalling.  Note that TIOCGICOUNT and TIOCMIWAIT do not access port driver data or hardware and are therefore not affected by the race.

CVE-2026-98696:

        In the Linux kernel, the following vulnerability has been resolved:  USB: serial: fix driver deregistration order  USB serial driver modules register one driver for the USB bus and one or more drivers for the ports on the USB serial bus.  When unloading a driver module, the USB driver must be deregistered before the USB serial bus drivers so that I/O is stopped before unbinding the ports to avoid use-after-free in completion handlers accessing port data.  Note that the "new_id" attributes must first be removed to prevent new ids from being added and triggering a probe of the USB driver after it has been deregistered.

CVE-2026-98697:

        In the Linux kernel, the following vulnerability has been resolved:  USB: serial: fix dynamic id driver deregistration race  Only free the dynamic ids after having deregistered the driver and removed the "new_id" attribute to avoid leaking any id added by a racing write to the attribute.

CVE-2026-98698:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: mac80211: handle empty FILS association request payload  fils_encrypt_assoc_req() accepts a (Re)Association Request frame whose last element is the FILS Session element.  crypt_len is then zero and aes_siv_encrypt() is called with an empty plaintext.  kmemdup() returns ZERO_SIZE_PTR for a zero-length allocation, so the unconditional sg_init_one() puts an invalid page into the scatterlist. With CONFIG_DEBUG_SG this triggers a kernel BUG in sg_set_buf(); without the debug check the bogus page is handed to the crypto backend.  AES-SIV is defined for empty plaintext and the S2V result is then the complete output, so handle this case before the CTR step, which has nothing to encrypt.

CVE-2026-98700:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: mac80211: set info->band for 802.3 encap offload frames  Unlike the 802.11 TX paths, ieee80211_8023_xmit() does not set info->band from the channel context on non-MLD interfaces. It stays at 0, so ieee80211_get_tx_rates() uses the wrong band for these frames.  Set it the same way as ieee80211_build_hdr(): drop the frame if there is no channel context, and leave the band at 0 on MLD interfaces.

CVE-2026-98701:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: mac80211: release mesh path quota on failed additions  Repeated failed or duplicate mesh path additions can exhaust MESH_MAX_MPATHS while the path table holds fewer paths, which stops new paths to reachable destinations from being created.  mesh_path_add() reserves a slot before allocating and inserting a path. If allocation fails, the function returns without releasing the slot. If the rhashtable insertion reports an error or an existing destination, the function discards its candidate but retains the reservation. No new path is installed in any of these cases.  Release the reservation whenever the candidate is not installed.

CVE-2026-98703:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: mac80211: minstrel_ht: validate fixed rate index  The fixed_rate_idx debugfs file is a plain u32 attribute, so any value can be written to it.  minstrel_ht_update_stats() then copies the value into mi->max_tp_rate[] and mi->max_prob_rate, and minstrel_ht_set_rate() uses MI_RATE_GROUP()/MI_RATE_IDX() to index minstrel_mcs_groups[] (42 entries) and mi->groups[].rates[] (10 entries) with it.  Writing e.g. 65535 selects group 4095 and rate index 15, far outside both arrays.  The out-of-bounds entries are dereferenced and updated as struct minstrel_rate_stats (retry counts, etc.), so the invalid index corrupts adjacent kernel memory.  With CONFIG_UBSAN_BOUNDS the access is reported as an array-index-out-of-bounds in minstrel_ht_set_rate().  Only a valid group/rate pair, or U32_MAX to disable fixed rate processing, can be used safely, so reject any other value when the debugfs file is written.  The file is only reachable through a root-only debugfs mount, so this is not a privilege boundary.  The out-of-bounds access is still a bug that must not be reachable through a writable debugfs attribute.

CVE-2026-98704:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: mac80211: keep fallback association elements alive  Associating to a non-transmitted MBSSID profile reads freed memory while determining the operating channel and applying HT capabilities.  When an association response omits WMM, HT, or VHT information, ieee80211_assoc_config_link() parses the cached BSS IEs and copies the missing element pointers out of that fallback parse. For a non-transmitted MBSSID profile those pointers refer to merged-profile storage owned by the parse object, and the fallback block frees that object at its end. The copied pointers are used afterwards to determine the operating channel, configure bandwidth, and apply HT capabilities.  Keep the fallback parse result alive until association setup finishes.  [reorder variable declaration]

CVE-2026-98705:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: mac80211: account proxy paths against the mesh path limit  Proxy-path churn can drive the interface path counter negative and let later mesh path additions exceed MESH_MAX_MPATHS.  mesh_path_free_rcu() decrements the interface mpaths counter for entries from both the mesh and proxy path tables, but mpp_path_add() never reserves a slot in that counter. Removing or expiring a proxy path therefore returns a slot that was never charged.  mesh_path_add() uses the same counter to enforce MESH_MAX_MPATHS, so once it falls below the number of installed paths the limit no longer holds.  Reserve the shared quota before allocating a proxy path and release it on every unsuccessful addition. Mesh and proxy paths now share one 1024-entry budget, so mpp_path_add() can return -ENOSPC at that limit.

CVE-2026-98706:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: mac80211: drain PS delivery work during station teardown  Removing an AP or mesh station can notify the driver and wake TXQs after the station has already been removed from the driver, and can update num_sta_ps and the power-save queues after station cleanup has purged them.  sta_deliver_ps_frames() tests sta->dead only before it starts delivery. A worker that passes that test can be delayed while teardown sets sta->dead and removes the station from the driver; when it resumes it still runs the full delivery.  The existing cancel_work_sync() sits near the end of __cleanup_single_sta(), after the final driver state transition and after PS accounting and queue purging, so it drains the worker only once the state it has to protect has already changed. Before commit d34ba2168a3c ("mac80211: don't delay station destruction") cleanup was deferred through the same ordered workqueue as the delivery work, which kept the two ordered.  Cancel the work after setting sta->dead and before moving the driver state, and move the existing cancellation to the start of __cleanup_single_sta(). The first drain closes the driver-lifetime window; driver callbacks during the remaining state transitions can still queue drv_deliver_wk through ieee80211_sta_block_awake(), so retain the second drain at the start of __cleanup_single_sta(). That drain also covers insertion failures, which reach cleanup without setting sta->dead.

CVE-2026-98707:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: mac80211: shut down RX BA session timer on teardown  Tearing down an RX BA session can leave the session timer queued on a freed tid_rx. Later timer-wheel processing and the timer callback itself then run against freed memory.  An RX BAR handler can dereference tid_rx under RCU before teardown unpublishes it and stay in its read-side critical section while teardown deletes the session timer. The stale handler can then rearm the timer after timer_delete_sync() returns and before the RCU callback frees tid_rx.  Use timer_shutdown_sync() so rearm attempts become ineffective once teardown starts. Keep reorder_timer unchanged: teardown marks the session removed under reorder_lock and its release path checks that state before rearming. session_timer has no equivalent guard because ieee80211_rx_h_ctrl() rearms it before taking reorder_lock.

CVE-2026-98708:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: mac80211: keep paired old chanctx alive  An in-place replacement keeps reciprocal replace_ctx pointers between the old WILL_BE_REPLACED chanctx and the new REPLACES_OTHER chanctx. However, the early free paths only consider assigned and reserved link users when deciding whether to free the old chanctx.  That lets the old chanctx be freed too early while the replacement partner still points back to it, either when the last assigned link is released or when that link successfully reassigns to another existing context. Later unreserve and switch-finalization paths can then follow a stale replace_ctx pointer.  Keep a paired old chanctx alive until the replacement pair has been torn down. Apply the same check to both __ieee80211_link_release_channel() and ieee80211_link_use_reserved_reassign(). If the replacement is later abandoned, ieee80211_link_unreserve_chanctx() already tears down the pairing before freeing the old chanctx once no users remain.

CVE-2026-98709:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: mac80211: count only matching reservations in reserved switch  ieee80211_vif_use_reserved_switch() validates a replacement by counting assigned links on ctx->replace_ctx and treating reservations too broadly. A link can still be assigned to the old channel context while holding a reservation that belongs to a different replacement operation.  That can make the current replacement appear complete too early. If another link finalizes first, the function can free the WILL_BE_REPLACED chanctx while the unmatched link and driver still use it, leading to a use-after-free in later beacon generation.  Require an in-place reservation to point at the current replacement context, and require the reserved and assigned contexts to be the matching replacement pair, before counting or moving the link.

CVE-2026-98710:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: iwlegacy: 3945: free EEPROM data on remove  il3945_pci_probe() calls il_eeprom_init(), which allocates memory for the EEPROM data. The probe failure paths release this allocation with il_eeprom_free(), but the remove path does not free it after a successful probe.  As a result, the EEPROM data is leaked when the PCI device is removed.  Free the EEPROM data in il3945_pci_remove() before releasing the mac80211 hardware structure.  This issue was found by manual code inspection.

CVE-2026-98711:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: cw1200: fix TX padding OOB read leaking heap data to device  The TX path rounds the transfer size up to the bus alignment (align_size(), up to 511 bytes for SDIO, 1 byte for SPI) but sends the padded length straight from the frame buffer, which has no room reserved for the padding.  cw1200_data_write() therefore reads past the end of the frame and the bus transfer carries those bytes to the device.  A bogus device can collect up to 511 bytes of kernel heap data per TX frame.  The RX path does not have this problem: it allocates the skb with the aligned length (alloc_len) before reading.  Compute the exact padding with the bus align_size() callback, make sure queued TX frames have tailroom for it, and zero the padding bytes before the transfer so nothing past the frame is exposed.  This is not expected to change driver behavior on most cases: frame contents and transfer sizes are unchanged, only the content of the padding bytes (previously undefined stale memory, now zero), which the device never reads since the WSM header carries the real frame length.  The skb expansion can only fail under memory exhaustion, in which case the frame is dropped like on the existing error paths of cw1200_tx().  Discovered by Atuin - Automated Vulnerability Discovery Engine.

CVE-2026-98714:

        In the Linux kernel, the following vulnerability has been resolved:  KVM: SVM: Update control fields on #VMEXIT if and only if VMRUN succeeded  Leave control.erap_ctl and control.clean as-is in the VMCS if VMRUN fails, because as per AMD:    there's no explicit architectural guarantee about the behavior in the   presence of VMRUN failures. So the best thing to do would be to assume   that if VMRUN fails, the actions requested in the control fields may not   have been performed.

CVE-2026-98715:

        In the Linux kernel, the following vulnerability has been resolved:  KVM: SVM: Preserve TLB control (i.e. pending TLB flush) on failed VMRUN  Don't reset the VMCB's TLB control back to "do nothing" on a failed VMRUN, as empirical testing shows that the CPU performs the requested TLB flush if and only if VMRUN is successful, i.e. clearing TLB control on a failed VMRUN effectively drops a TLB flush.  Explicitly track the need to flush all ASIDs on a per-CPU basis, as the ASID reuse condition is tied to the pCPU, not to the vCPU.  As a bonus, this also obviates the need to avoid clobbering FLUSH_ALL_ASID with TLB_CONTROL_FLUSH_ASID, e.g. in svm_flush_tlb_asid().  Deliberately don't bother saving/restoring the "old" tlb_ctl on failure, in quotes because it's not exactly the old tlb_ctl, it's the tlb_ctl from after pre_svm_run(), but before updating tlb_ctl for flush_all_asids.  If VMRUN fails and TLB_CONTROL_FLUSH_ALL_ASID is forced, then the next successful run of the VMCB *may* unnecessarily flush all ASIDs, which strictly speaking could result in noisy neighbor issues.  However, the fact that new_asid() is already guest-triggerable, because of KVM's flawed behavior of clearing the ASID on emulated INIT, means that a guest can already trigger a flush of all ASIDs at roughly the same rate.  And once KVM stops clobbering the ASID on emulated INIT, *or* assigns a static ASID to each vCPU, this flaw goes away.

CVE-2026-98716:

        In the Linux kernel, the following vulnerability has been resolved:  KVM: SVM: Use the active VMCB's MSR bitmap when checking if MSR is intercepted  Use the MSR permission bitmap of the active VMCB instead of assuming that KVM is always using vmcb02's bitmap when L2 is active, as KVM uses msrpm02 if and only if L1 wants to intercept MSR accesses, i.e. if and only if KVM needs to merge msprm01 with msrpm12.  Don't bother tracking the virtual address of the bitmap that's being used, as __va() is cheap on x86, and caching the virtual address would introduce yet another source of potentially stale information.

CVE-2026-98720:

        In the Linux kernel, the following vulnerability has been resolved:  KVM: nVMX: Force MSR bitmap refresh if runtime eVMCS controls are modified  Force a refresh of the vmcs02 MSR bitmap during nested VM-Enter if the runtime eVMCS controls (pin, primary, secondary, etc.) are being updated. If L1 isn't intercepting TPR writes, runs L2 with TPR virtualization, and then runs the same L2 with TPR virtualization disabled, KVM will fail to refresh msr_bitmap02 and leave TPR in passthrough mode even though TPR virtualization is disabled.  I.e. failure to refresh the bitmap lets L2 (or L1 by proxy) read and write L0's TPR.

CVE-2026-98721:

        In the Linux kernel, the following vulnerability has been resolved:  mtd: rawnand: cadence: Initialize IRQ state before requesting IRQ  The Cadence NAND interrupt handler uses both the IRQ lock and completion object. Registering the IRQ before initializing them leaves a window in which a pending interrupt can access uninitialized synchronization state.  Initialize them before registering the handler.

CVE-2026-98722:

        In the Linux kernel, the following vulnerability has been resolved:  mtd: block2mtd: Fix divide error when erase_size is zero  The erase size is parsed from the "block2mtd" module parameter and can be set to zero. add_device() then evaluates          if (size % erase_size)  with a zero divisor, which triggers a divide error:  divide error: 0000 [#1] PREEMPT SMP PTI RIP: 0010:add_device drivers/mtd/devices/block2mtd.c:296 [inline] RIP: 0010:block2mtd_setup2+0x592/0xda0 drivers/mtd/devices/block2mtd.c:459 Call Trace: block2mtd_setup+0x27/0xe0 drivers/mtd/devices/block2mtd.c:476 param_attr_store+0x214/0x310 kernel/params.c:589 module_attr_store+0x65/0x90 kernel/params.c:904 kernfs_fop_write_iter+0x3a4/0x540 fs/kernfs/file.c:345 ...  Reject a zero erase size before performing the modulo operation so the existing "erasesize must be a divisor of device size" error path reports the invalid argument and frees the device.

CVE-2026-98725:

        In the Linux kernel, the following vulnerability has been resolved:  nvmet-auth: fix out-of-bounds write in nvmet_auth_challenge()  nvmet_auth_challenge() receives its output buffer as a void pointer. sizeof(*d) therefore evaluates to one with GCC and undercounts the fixed challenge header by 15 bytes.  A short AUTH_RECEIVE buffer can pass the check before the challenge is copied past the end of its allocation.  Use the typed challenge pointer when calculating the response size.    BUG: KASAN: slab-out-of-bounds in nvmet_execute_auth_receive (drivers/nvme/target/fabrics-cmd-auth.c:442 drivers/nvme/target/fabrics-cmd-auth.c:569)   Write of size 32 by task kworker/1:1H/64   Workqueue: nvmet_tcp_wq nvmet_tcp_io_work   Call Trace:   nvmet_execute_auth_receive (drivers/nvme/target/fabrics-cmd-auth.c:442 drivers/nvme/target/fabrics-cmd-auth.c:569)   nvmet_tcp_try_recv_pdu (drivers/nvme/target/tcp.c:1119 drivers/nvme/target/tcp.c:1243)   nvmet_tcp_io_work (drivers/nvme/target/tcp.c:1350 drivers/nvme/target/tcp.c:1382 drivers/nvme/target/tcp.c:1445)   process_one_work (kernel/workqueue.c:3322)   worker_thread (kernel/workqueue.c:3405 kernel/workqueue.c:3486)   kthread (kernel/kthread.c:436)   ret_from_fork (arch/x86/kernel/process.c:158)   ret_from_fork_asm (arch/x86/entry/entry_64.S:245)   The buggy address is located 16 bytes inside of    allocated 33-byte region [ffff888000554e80, ffff888000554ea1)   Kernel panic - not syncing: KASAN: panic_on_warn set ...

CVE-2026-98726:

        In the Linux kernel, the following vulnerability has been resolved:  nvme-multipath: fix underflow in ANA log bounds checks  The number of ANA groups advertised through Identify Controller sizes the ANA log buffer. The ANA log header and group descriptors independently supply the number of groups and namespace IDs to parse.  Both bounds checks subtract an untrusted object size from ana_log_size before comparing the current offset. If the object is larger than the buffer, the size_t subtraction underflows and lets the parser read beyond ana_log_buf.  Check the current offset before the first subtraction and compare each object size with the remaining buffer instead. This rejects inconsistent ANA data before dereferencing a truncated group descriptor or walking an oversized namespace ID array.

CVE-2026-98732:

        In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: btintel: fix buffer over-read in btintel_hw_error()  The "Exception info %s" print uses skb->data + 1, but the 12-byte payload is not guaranteed to be NUL-terminated and can be read past its end.  Bound the print with "%.*s" and skb->len - 1.

CVE-2026-98733:

        In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: hci_core: Serialize fragmented ISO packet queueing  The fragmented path in hci_queue_iso() calls __skb_queue_tail() without holding conn->data_q.lock. The socket lock serializes senders, but the transmit worker can concurrently remove packets from this queue using skb_dequeue().  After an insertion saves the old tail pointer, hci_sched_iso() can dequeue that packet and pass it to the driver. The driver can free the packet before the insertion resumes and writes to the old tail's next pointer, causing a use-after-free. Concurrent updates can also corrupt the queue.  KASAN reported:    BUG: KASAN: slab-use-after-free in hci_send_iso+0xc7d/0xe10   Call Trace:    hci_send_iso+0xc7d/0xe10    iso_sock_sendmsg+0x710/0x900    __sys_sendto+0x34a/0x3a0    Allocated by task 86:    __alloc_skb+0xdd/0x820    alloc_skb_with_frags+0x7e/0x770    sock_alloc_send_pskb+0x67a/0x820    bt_skb_sendmsg.constprop.0+0xc0/0x6c0    iso_sock_sendmsg+0x44e/0x900    Freed by task 90:    kmem_cache_free+0xcb/0x3d0    vhci_read+0x33f/0x4d0    vfs_read+0x177/0xa20  Hold the queue lock across the entire fragment batch, as hci_queue_acl() does, to serialize insertion against dequeue while preserving fragment ordering.

CVE-2026-98734:

        In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: hci_core: Serialize SCO and ISO scheduling with teardown  hci_low_sent() selects a connection under RCU but drops the read lock before calculating its quota and returning it to the scheduler. The connection is then used without lifetime protection by hci_sched_iso() and hci_sched_sco().  After the TX worker drops the RCU read lock, hci_abort_conn_sync() on hdev->req_workqueue can remove the connection from the hash, complete synchronize_rcu(), purge its queues and release it. The TX worker on hdev->workqueue can then access the freed connection in hci_quote_sent() or while dequeuing packets and updating conn->sent.  KASAN reported:    BUG: KASAN: slab-use-after-free in hci_low_sent+0x730/0x840   Workqueue: hci0 hci_tx_work   Call Trace:    hci_low_sent+0x730/0x840    hci_sched_iso+0x25e/0x4d0    hci_tx_work+0x239/0xcb0    Allocated by task 93:    __hci_conn_add+0x16f/0x1b40    hci_bind_bis+0x782/0x17b0    hci_connect_bis+0xa0/0x510    iso_sock_connect+0x589/0x1050    Freed by task 88:    kfree+0x131/0x3c0    device_release+0xc8/0x240    kobject_put+0x14d/0x280    hci_conn_del+0x55a/0xe80    hci_disconnect_sync+0x156/0x180    hci_abort_conn_sync+0x3e7/0x940    hci_cmd_sync_work+0x13c/0x290  Hold hci_dev_lock() across connection selection and transmission in both SCO and ISO scheduling, serializing them with connection teardown. This also prevents queuing completion timestamps after the connection queues have been purged. Extending RCU across transmission would be unsafe because the transmit path can sleep. Keep the ISO timeout check outside the mutex since hci_link_tx_to() takes it itself.  The preceding channel fix already holds this mutex in the ACL and LE schedulers, which call the SCO scheduler between packets. Move the SCO body to __hci_sched_sco(), assert that its caller holds the mutex, and use it directly from these locked paths. Keep a locking hci_sched_sco() wrapper for the direct calls from hci_tx_work(). This avoids recursively acquiring the device mutex while preserving the scheduling order.  Remove the obsolete claim that connection removal disables TX.

CVE-2026-98735:

        In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: hci_core: Serialize ACL scheduling with channel deletion  hci_chan_sent() selects a channel under RCU but drops the read lock before accessing chan->conn and returning the channel. The ACL and LE schedulers then use its packet queue and update its transmit counters without any protection against channel deletion.  After TX selects a channel and releases RCU, a disconnect command timeout on the separate request workqueue can run hci_conn_failed() and l2cap_conn_del(). hci_chan_del() can then unlink the channel, complete synchronize_rcu(), purge its queue and free it before TX resumes. This causes use-after-free both in hci_chan_sent() and in its callers.  KASAN reported:    BUG: KASAN: slab-use-after-free in hci_chan_sent+0x892/0x9b0   Workqueue: hci0 hci_tx_work   Call Trace:    hci_chan_sent+0x892/0x9b0    hci_tx_work+0x5e6/0xb70   Allocated by task 91:    hci_chan_create+0xe3/0x350    l2cap_conn_add.part.0+0x12/0xa30    l2cap_chan_connect+0x110d/0x1b60    l2cap_sock_connect+0x310/0x530   Freed by task 99:    hci_chan_del+0x11f/0x170    l2cap_conn_del+0x4f1/0x800    l2cap_connect_cfm+0x88c/0xd30    hci_conn_failed+0x150/0x250    hci_abort_conn_sync+0x3e3/0x800    hci_cmd_sync_run+0x7e/0xc0    hci_abort_conn+0x105/0x1f0    disconnect_sync+0x157/0x290    hci_cmd_sync_work+0x13c/0x290  Hold the existing device mutex across channel selection and transmission in both schedulers to serialize them with channel teardown. Keep timeout handling outside the critical sections because hci_link_tx_to() acquires the same mutex. This also permits the transmit path to sleep, unlike extending the RCU read-side critical section across packet submission.

CVE-2026-98736:

        In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: hci_conn: Lock parent access during enhanced SCO setup  Bluetooth: hci_conn: Lock parent access during enhanced SCO setup  hci_enhanced_setup_sync() runs on the request workqueue without the hci_dev_lock held by its caller when setup was queued. Its CVSD capability check and find_next_esco_param() dereference conn->parent while the receive workqueue can unlink and release that parent.  The following interleaving can cause a use-after-free:    hci_enhanced_setup_sync()       hci_disconn_complete_evt()   load conn->parent                                  hci_dev_lock()                                  hci_conn_del(ACL parent)                                    unlink SCO child                                    drop link's parent reference                                    clear child->parent                                    release ACL parent                                      bt_link_release()                                        kfree(parent)                                  hci_dev_unlock()   read parent->features[0][3]  The reference held for the queued SCO child does not keep its ACL parent alive after unlinking. Commit 42de40abe25d ("Bluetooth: hci_conn: fix the SCO setup context lifetime") protects the child stored in the queued context, but leaves these parent accesses unprotected.  With a 40 ms diagnostic delay after loading conn->parent, an instrumented kernel based on fd179f8a05be, which already contains 42de40abe25d,    BUG: KASAN: slab-use-after-free in hci_enhanced_setup_sync+0xda5/0xdf0   Read of size 1 at addr ffff888102204047 by task kworker/u17:0/93   Call Trace:    hci_enhanced_setup_sync+0xda5/0xdf0    hci_cmd_sync_work+0x13c/0x290    process_one_work+0x6b4/0x10e0    Allocated by task 92:    __hci_conn_add+0x304/0x1df0    hci_connect_acl+0x349/0x3e0    hci_connect_sco+0x3b/0x9a0    sco_sock_connect+0x475/0xca0    Freed by task 94:    kfree+0x121/0x3c0    bt_link_release+0x79/0xa0    device_release+0xc8/0x240    kobject_put+0x14d/0x280    hci_conn_del+0x524/0xe30    hci_disconn_complete_evt+0x403/0x8c0    hci_event_packet+0x71b/0xb20    hci_rx_work+0x293/0x730  The accessed address is 71 bytes into the freed ACL parent, at its features[0][3] byte; the queued SCO child is a different object. The diagnostic preserves the loaded parent across the delay, matching the unmodified compiled capability check, and does not change the parent references or teardown path.  Hold hci_dev_lock() across the codec switch, including every call to find_next_esco_param(), and release it on all selection errors. Keep configure_datapath_sync() outside the critical section because it waits for HCI events. Preserve parameter selection and existing return values.

CVE-2026-98737:

        In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: hci_sync: Fix inquiry cache use-after-free  The sync command worker holds hdev->req_lock, but inquiry-cache updates and flushes use hdev->lock. Both hci_acl_create_conn_sync() and hci_stop_discovery_sync() look up entries and read their fields without taking hdev->lock.  After either lookup returns, a concurrent HCIINQUIRY ioctl can acquire hdev->lock and flush the cache, freeing the entry. The worker then reads the freed entry while preparing a create-connection or remote-name-cancel command. The list traversal also races with cache updates and removal.  KASAN reported these accesses:    BUG: KASAN: slab-use-after-free in hci_acl_create_conn_sync+0x5f1/0x650   Workqueue: hci0 hci_cmd_sync_work   Call Trace:    hci_acl_create_conn_sync+0x5f1/0x650    hci_cmd_sync_work+0x13c/0x290    Allocated by task 90:    hci_inquiry_cache_update+0x3e6/0x7d0    hci_inquiry_result_evt+0x3cb/0x560    Freed by task 93:    hci_inquiry_cache_flush+0x111/0x2b0    hci_inquiry+0x2f2/0x780    hci_sock_ioctl+0x269/0x5f0    BUG: KASAN: slab-use-after-free in hci_stop_discovery_sync+0x3b1/0x3c0   Workqueue: hci0 hci_cmd_sync_work   Call Trace:    hci_stop_discovery_sync+0x3b1/0x3c0    hci_cmd_sync_work+0x173/0x300    Allocated by task 86:    hci_inquiry_cache_update+0x483/0x940    hci_inquiry_result_evt+0x3cb/0x560    Freed by task 91:    hci_inquiry_cache_flush+0x13e/0x2f0    hci_inquiry+0x2f2/0x780    hci_sock_ioctl+0x269/0x5f0  Hold hdev->lock across each lookup and all reads from its result. Copy the remote address before unlocking so discovery cancellation does not retain a cache entry pointer. Release the lock before sending synchronous HCI commands, since their completion handlers may need the same lock.

CVE-2026-98738:

        In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: Serialize SMP remote OOB data access  build_pairing_cmd() looks up remote OOB data and copies its contents without holding hdev->lock, which serializes the list's writers. After SMP finds an entry, a concurrent management Remove Remote OOB Data command can unlink and free it before SMP reads its present flag or copies its random and confirmation values. Removal can also invalidate an entry while the lookup is still traversing the list.  KASAN reported:    BUG: KASAN: slab-use-after-free in build_pairing_cmd+0x948/0x9b0   Call Trace:    build_pairing_cmd+0x948/0x9b0    smp_recv_cb+0x459f/0x8110    l2cap_recv_frame+0xf14/0x9190    l2cap_recv_acldata+0xa64/0xd40    hci_rx_work+0x4ca/0x730    Allocated by task 87:    hci_add_remote_oob_data+0x11d/0x530    add_remote_oob_data+0x282/0x400    hci_sock_sendmsg+0x1033/0x1ea0    Freed by task 93:    hci_remote_oob_data_clear+0x108/0x1c0    remove_remote_oob_data+0x198/0x220    hci_sock_sendmsg+0x1033/0x1ea0  Taking hdev->lock in build_pairing_cmd() would recurse for callers that already hold it and invert the device-to-L2CAP lock order on the receive path. Add a per-device remote_oob_lock instead, held across the SMP lookup and copies and by the add, remove and clear helpers. Cover initialization and in-place updates as well, so SMP cannot read partially initialized or updated OOB values. Release the mutex on allocation failure, preserving the existing error return.  The new critical sections acquire no device, connection or channel locks. Writers retain their existing hdev->lock protection, which continues to serialize the other readers without changing their locking or behavior.

CVE-2026-98739:

        In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: RFCOMM: Fix initial port reference race  For RFCOMM_RELEASE_ONHUP devices, rfcomm_tty_install() and __rfcomm_release_dev() both use RFCOMM_TTY_OWNED to decide who drops the initial tty_port reference. The release path tests the bit separately from the install path setting it, so both can drop that reference.  The synchronous hangup does not prevent this race: port->tty is not assigned until tty_port_open(), after installation. The following interleaving is possible:    1. Install and release each obtain a reference with rfcomm_dev_get().   2. Release observes RFCOMM_TTY_OWNED clear.   3. Install sets RFCOMM_TTY_OWNED and drops the initial reference.   4. Release drops the same initial reference again.   5. TTY cleanup drops its reference and frees the device.   6. Release performs its final tty_port_put() on the freed port.  KASAN reported:    BUG: KASAN: slab-use-after-free in tty_port_put+0x22/0x190   Write of size 4 at addr ffff8881001d3d5c by task poc/92    Call Trace:    tty_port_put+0x22/0x190    rfcomm_dev_ioctl+0x1d4/0x1930    sock_do_ioctl+0x110/0x260    sock_ioctl+0x380/0x590    __x64_sys_ioctl+0x134/0x1c0    Allocated by task 88:    rfcomm_dev_ioctl+0x8f6/0x1930    sock_do_ioctl+0x110/0x260    sock_ioctl+0x380/0x590    __x64_sys_ioctl+0x134/0x1c0    Freed by task 65:    kfree+0x131/0x3c0    rfcomm_dev_destruct+0x23b/0x2f0    release_one_tty+0xc1/0x370    process_one_work+0x661/0x1090  Use test_and_set_bit() in both paths so that only the caller that changes RFCOMM_TTY_OWNED from clear to set drops the initial reference. Each path keeps its own lookup reference until release or TTY cleanup, preserving the existing callback ordering and error handling.

CVE-2026-98740:

        In the Linux kernel, the following vulnerability has been resolved:  EDAC/altera: Drop __init from ECC setup paths for re-probe safety  Sashiko reports:  "Does suppressing sysfs unbinding fully prevent the execution of freed __init memory? If altr_sysmgr_regmap_lookup_by_phandle() returns -EPROBE_DEFER, the probe is deferred until after __init memory is freed."  The a10 EDAC .setup callbacks (sdmmc, ethernet, nand, dma, usb, qspi) and their helpers (altr_init_a10_ecc_device_type, altr_init_a10_ecc_block) were marked __init. These run from the probe path, which may execute after init memory is freed -- e.g. a probe deferred via -EPROBE_DEFER that only succeeds once a late/module dependency appears, or a manual unbind/rebind. Calling __init code then dereferences freed memory. Remove __init so these functions remain valid at runtime.

CVE-2026-98741:

        In the Linux kernel, the following vulnerability has been resolved:  ALSA: ua101: reject mismatched capture/playback packet sizes  detect_usb_format() cross-checks bSubframeSize, bBitResolution and tSamFreq between the capture and playback interfaces, but never relates the two endpoints' wMaxPacketSize and bNrChannels.  Each playback URB gets a buffer of ua->playback.max_packet_bytes, while the number of bytes written into it is derived from the capture stream: capture_urb_complete() computes frames from the received capture packet and capture.frame_bytes, and start_usb_playback() and playback_work() multiply that by playback.frame_bytes.  A device declaring a large capture wMaxPacketSize with few capture channels and a small playback wMaxPacketSize with many playback channels therefore memset()s and memcpy()s past the end of the playback buffer, in open() of the PCM node the driver registers during probe. usb_submit_urb() rejects the over-long iso_frame_desc[0].length with -EMSGSIZE, but only after the write.  Reject such descriptors at probe time.  Genuine UA-101/UA-1000 hardware declares proportional packet sizes and is unaffected.    BUG: KASAN: slab-out-of-bounds in start_usb_playback (sound/usb/misc/ua101.c:586)   Write of size 2048 at addr ffff8881098f3c00 by task exploit/5021   Call Trace:    __asan_memset (mm/kasan/shadow.c:84)    start_usb_playback (sound/usb/misc/ua101.c:586)    playback_pcm_open (sound/usb/misc/ua101.c:679)    snd_pcm_open_substream (sound/core/pcm_native.c:2829)    snd_pcm_open (sound/core/pcm_native.c:2865 sound/core/pcm_native.c:2932)    snd_pcm_playback_open (sound/core/pcm_native.c:2891)    snd_open (sound/core/sound.c:166)    chrdev_open (fs/char_dev.c:411)    do_dentry_open (fs/open.c:996)    vfs_open (fs/open.c:1101)    path_openat (fs/namei.c:4837 fs/namei.c:5000)    do_file_open (fs/namei.c:5029)    do_sys_openat2 (fs/open.c:1417)    __x64_sys_openat (fs/open.c:1423 fs/open.c:1439 fs/open.c:1434)    do_syscall_64 (arch/x86/entry/syscall_64.c:61 arch/x86/entry/syscall_64.c:84)    entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)    The buggy address belongs to the object at ffff8881098f3c00    which belongs to the cache kmalloc-192 of size 192   The buggy address is located 0 bytes inside of    allocated 168-byte region [ffff8881098f3c00, ffff8881098f3ca8)

CVE-2026-98742:

        In the Linux kernel, the following vulnerability has been resolved:  ALSA: seq: Serialize compat port-info ioctls  The native sequencer ioctl path serializes handler calls with client->ioctl_mutex, but the translated port-info compat path invokes the same handlers through snd_seq_kernel_client_ctl() without taking that mutex.  This lets concurrent compat CREATE_PORT requests pass the port-count check before any request reaches the serialized insertion. The computed integer port index can then exceed the address field range and wrap to an existing index. Subsequent subscriber teardown can resolve the duplicate address to the wrong port and access a freed subscriber.  Take ioctl_mutex while dispatching converted port-info requests, matching the native ioctl path. All translated port-info commands share this helper, so their accesses to the client port state are serialized as well.

CVE-2026-98745:

        In the Linux kernel, the following vulnerability has been resolved:  arm64/fpsimd: signal: Forbid non-streaming SVE payload on SME-only systems  When system_supports_sme() is true but system_supports_sve() is false, restoring a specifically crafted SVE signal context can result in the task erroneously having non-streaming SVE state. Subsequent attempts to manipulate the task's FPSIMD/SVE/SME state can result in a variety of problems, including fatal EL1 UNDEFs.  In such configurations, the kernel always creates an SVE signal context when delivering a signal, and this can only be in one of two states:  (1) SVE_SIG_FLAG_SM is set, and an SVE payload is present containing     streaming mode SVE state. The recorded VL is the task's live     streaming VL.  (2) SVE_SIG_FLAG_SM is clear, and an SVE payload is not present. The     FPSIMD context contains the non-streaming mode FPSIMD state. The     recorded VL is 0.  Currently restore_sve_fpsimd_context() correctly rejects cases where SVE_SIG_FLAG_SM is set and an SVE payload is not present, but fails to reject cases where SVE_SIG_FLAG_SM is clear and an SVE payload is present. Consequently, restore_sve_fpsimd_context() can place the task in a state where it has non-streaming SVE state even when this is not supported by HW.  For example, this can cause a later EL1 UNDEF when the kernel attempts to restore the task's ZCR_EL1 value:  | # ./sme-sigcontext-to-sve | Internal error: Oops - Undefined instruction: 0000000002000000 [#1]  SMP | Modules linked in: | CPU: 0 UID: 0 PID: 131 Comm: sme-sigcontext- Not tainted 7.3.0-rc1 #1 PREEMPT | Hardware name: linux,dummy-virt (DT) | pstate: 61402009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) | pc : fpsimd_restore_current_state+0x258/0x458 | lr : exit_to_user_mode_loop+0xb8/0x188 | sp : ffff80008056be40 | x29: ffff80008056be40 x28: fff00000c1670000 x27: 0000000000000000 | x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 | x23: ffff80008056bec0 x22: 0000000000000008 x21: 0000000000000040 | x20: 0000000000000081 x19: 0000000008800010 x18: 0000000000000000 | x17: 0000fffffd412570 x16: 0000000000001000 x15: 0000fffffd4123b0 | x14: 0000fffffd412780 x13: 0000fffffd412be8 x12: 0000000047435300 | x11: 0000fffffd412570 x10: 0000000000000000 x9 : 0000000045585401 | x8 : fff00000c18a6c44 x7 : 0000000000000000 x6 : 0000000000000002 | x5 : 0000000000000002 x4 : ffff800080568000 x3 : 0000000000000001 | x2 : 0000000008800010 x1 : fff00000c1670000 x0 : 0000000008800000 | Call trace: |  fpsimd_restore_current_state+0x258/0x458 (P) |  exit_to_user_mode_loop+0xb8/0x188 |  el0_svc+0x1cc/0x1d0 |  el0t_64_sync_handler+0xa0/0xe4 |  el0t_64_sync+0x198/0x19c | Code: d5384101 f9400020 53175c03 36b80de0 (d5381202) | ---[ end trace 0000000000000000 ]--- | Kernel panic - not syncing: Oops - Undefined instruction: Fatal exception in interrupt | Kernel Offset: 0x291fb1000000 from 0xffff800080000000 | PHYS_OFFSET: 0x40000000 | CPU features: 0x0,00000000,0052802f,ffb88f43,3afcf73f | Memory Limit: none  Rework restore_sve_fpsimd_context() to reject cases where SVE_SIG_FLAG_SM is clear and an SVE payload is not present. As parse_user_sigframe() rejects SVE signal frames when neither SVE nor SME are supported, it isn't necessary for restore_sve_fpsimd_context() to handle the case where neither are supported.

CVE-2026-98748:

        In the Linux kernel, the following vulnerability has been resolved:  serial: 8250_bcm7271: fix use-after-free in brcmuart_remove()  brcmuart_handle_irq() starts priv->hrt to work around a receive-timeout quirk of the 8250 core when hardware flow control is enabled; the timer callback brcmuart_hrtimer_func() dereferences priv.  brcmuart_remove() cancels the hrtimer before it unregisters the port, so a receive-timeout interrupt that arrives in between re-arms the timer. After devm frees priv, the callback runs on freed memory.  Unregister the port before cancelling the hrtimer. serial8250_unregister_port() shuts the port down and frees its IRQ, so brcmuart_handle_irq() can no longer restart the timer, and the final hrtimer_cancel() drains any timer that was armed before or during the unregister.  This issue was found by an in-house static analysis tool.

CVE-2026-98749:

        In the Linux kernel, the following vulnerability has been resolved:  tty: serial: max3100: shut down timer before freeing port  max3100_shutdown() stops the polling timer but returns early during system suspend. If the SPI device is unbound before resume, the serial core does not call max3100_shutdown() again, so max3100_remove() frees the port while the timer remains armed. max3100_timeout() may then access the freed port and re-arm the timer.  Add final timer teardown to max3100_remove() and use timer_shutdown_sync() to prevent a racing callback from re-arming it. Also free the IRQ and destroy the workqueue there before freeing the port. Keep timer_delete_sync() in max3100_shutdown() so that a subsequent open() can re-arm the timer.  The workqueue is created before request_irq() and destroyed on both request_irq() failure and normal shutdown. Its presence at remove thus identifies the IRQ left registered when suspend bypasses shutdown.  Free the IRQ before destroying the workqueue, in both max3100_shutdown() and max3100_remove(), and cancel the pending work in between. free_irq() waits for a running interrupt handler to finish and no new handler can start afterwards, so a racing handler cannot queue work on a workqueue that is being destroyed; the force_end_work check in max3100_dowork() only narrows that window, as a handler delayed between the check and queue_work() could still run after the teardown has cleared the workqueue pointer. Cancelling the work also keeps destroy_workqueue() from waiting on a queued work item in case remove() ever runs while the freezable workqueue is still frozen, e.g. device removal during the resume window, before workqueues are thawed.  This issue was found by an in-house static analysis tool.

CVE-2026-98750:

        In the Linux kernel, the following vulnerability has been resolved:  tty: fix saved termios reset race  Resetting saved termios state on device registration is needed where a minor number can be reused for an entirely different device and where the old settings may prevent the port from even being opened (e.g. when CLOCAL is not set).  Not all TTY drivers guarantee that the minor number is no longer in use when registering devices however, something which can lead to a use-after-free when closing a TTY (and saving its termios) races with re-registration.  Add a new TTY_DRIVER_RESET_SAVED_TERMIOS flag to request that any saved termios state is reset on registration and only set it for drivers that make sure that the minor number is no longer in use.

CVE-2026-98751:

        In the Linux kernel, the following vulnerability has been resolved:  tty: abort break signalling on hangup  The break ioctls can race with hangup and end up calling into a tty driver for a device that is already gone or powered down.  Drivers must handle this race, but TCSBRK and TCSBRKP should still be aborted to avoid calling back into the driver after a user-controlled timeout (possibly even after the tty has been reopened).  Note that drivers should disable any break state on shutdown so just return on hangup (calling break_ctl() again is racy and will most likely fail for drivers handling the race).

CVE-2026-98752:

        In the Linux kernel, the following vulnerability has been resolved:  tty: port: fix tty_port_tty_vhangup() race  Drivers rely on tty_port_tty_vhangup() to synchronously hang up their ports before tearing down resources as part of deregistration (e.g. on physical disconnect).  If tty_port_tty_vhangup() races with another hangup it may however return before the port has been shut down. This is in turn can lead to use-after-free and NULL-pointer dereferences in racing ioctls (including a synchronous hangup) and in processing of racing asynchronous hangups (carrier loss).  Add the missing serialisation to tty_port_tty_vhangup() and tty_port_hangup() so that the former does not return until the port has been shut down also when there is a racing hangup.  Note that serial core does not use tty_port_hangup(), but it already holds the port mutex when clearing port->tty and shutting down the port in uart_hangup().

CVE-2026-98753:

        In the Linux kernel, the following vulnerability has been resolved:  tty: tty_port: restore TTY_IO_ERROR on activation failure  Make sure to restore the TTY_IO_ERROR flag if activation fails to prevent I/O attempts on a port that is gone or powered down.  This specifically avoids issues like kernel panic due to unclocked accesses or NULL-pointer dereferences when accessing powered down or deregistered ports when a TTY ioctl races with hangup and open.  Note that the flag is set again in tty_port_close() but not restoring it on activation failure leaves a window where drivers fail to handle the ioctl-hangup race.

CVE-2026-98754:

        In the Linux kernel, the following vulnerability has been resolved:  tty: vcc: hold port lock when clearing tty pointer in vcc_cleanup  vcc_cleanup() sets port->tty to NULL without holding port->lock, racing with vcc_event() LDC callbacks that read port->tty under port->lock and then use tty->port. This can cause a use-after-free when the callback dereferences tty->port after cleanup has already destroyed and freed it.

CVE-2026-98755:

        In the Linux kernel, the following vulnerability has been resolved:  tty: vcc: zero-initialize control packet in vcc_send_ctl()  The stack-allocated struct vio_vcc pkt was partially initialized, leaving the tag.stype_env field uninitialized before being sent via ldc_write(), potentially leaking kernel stack data to the LDC peer.

CVE-2026-98756:

        In the Linux kernel, the following vulnerability has been resolved:  usb: cdns3: Fix NULL pointer dereference in cdns3_pci_probe  The Cadence USBSS controller is a two-function PCI device. The first probed function allocates the driver data and stores it with pci_set_drvdata(), while the second function reuses it via pci_get_drvdata() when pci_is_enabled() reports that the first function has already been probed.  When the second function is probed while the first one has been enabled but has not yet set its driver data, pci_get_drvdata() returns NULL, and the subsequent wrap->devfn assignment dereferences a NULL pointer and crashes the kernel. logs: Call trace:   cdns3_pci_probe+0xa4/0x300   local_pci_probe+0x44/0xa8   pci_call_probe+0x54/0x158   pci_device_probe+0x84/0x100   really_probe+0x184/0x3d0   __driver_probe_device+0x80/0x178   driver_probe_device+0x44/0xe8   __driver_attach+0xec/0x1f8   bus_for_each_dev+0x7c/0xe0   driver_attach+0x28/0x38   bus_add_driver+0x110/0x238   driver_register+0x64/0x128   __pci_register_driver+0x50/0x60   cdns3_pci_driver_init+0x28/0x38   do_one_initcall+0x5c/0x280   do_initcalls+0x104/0x1d8   kernel_init_freeable+0x140/0x218   kernel_init+0x28/0x1f8   ret_from_fork+0x10/0x20  Return -EPROBE_DEFER in this case so that probing is retried after the first function has completed its probe.

CVE-2026-98757:

        In the Linux kernel, the following vulnerability has been resolved:  usb: cdns3: fix use-after-free in cdns3_gadget_exit()  cdns3_gadget_start() arms two works on system_freezable_wq: pending_status_wq for the deferred ep0 status stage and aligned_buf_wq for realigned request buffers. Both handlers use the cdns3_device the works are embedded in, and cdns3_pending_setup_status_handler() also calls the ep0 request completion.  cdns3_gadget_exit() does not wait for these works. It frees all endpoints and aligned buffers and drops the last reference to the gadget device, which frees priv_dev, so a work queued before the exit can run after the free.  Fix this by waiting for both works after the gadget driver is unbound and the IRQ is freed, when no new work can be queued, and before the endpoints and buffers are released.  This issue was found by an in-house static analysis tool.

CVE-2026-98760:

        In the Linux kernel, the following vulnerability has been resolved:  usb: typec: tipd: fix uninitialized typec_partner_desc in tps6598x_connect()  tps6598x_connect() passes a stack-allocated typec_partner_desc to typec_register_partner() after initializing only usb_pd, accessory and identity.  typec_register_partner() copies attach and deattach from the descriptor into the partner. With those fields left unset, garbage function pointers may be stored and later invoked from typec_partner_link_device() when a USB device is linked to the port. Uninitialized pd_revision and usb_capability similarly leak stack data through partner sysfs.  Zero-initialize the descriptor so optional callbacks remain NULL and the remaining fields are zero.

CVE-2026-98761:

        In the Linux kernel, the following vulnerability has been resolved:  usb: typec: tcpm: recover after failure to start the frs ams  Reset the port if the tcpm fails to start the FAST_ROLE_SWAP AMS by initiating error recovery on it.  This helps in cases where some cables (incorrectly) signal an FRS to an FRS capable port during disconnection. The TCPC autonomously starts sourcing VBUS on detecting the FRS signal. However, the VBUS sourcing is left on when the FAST_ROLE_SWAP AMS fails to start (as tcpm_sink_tx_ok is 0 as CC is open due to the cable disconnect). This is because the code sets the state to INVALID_STATE without resetting the port state.  Log snippet before changes: [  101.401960] AMS FAST_ROLE_SWAP start [  101.401971] Sink TX No Go [  101.401982] sourcing vbus [  101.401987] VBUS on [  101.402159] VBUS on [  109.257809] CC1: 0 -> 0, CC2: 5 -> 0 [state SNK_READY, polarity 1, disconnected] [  111.267442] VBUS on  After changes: [   70.541211] AMS FAST_ROLE_SWAP start [   70.541220] Sink TX No Go [   70.541228] state change SNK_READY -> ERROR_RECOVERY [rev3 NONE_AMS] [   70.541362] VBUS on [   70.541365] sourcing vbus [   70.541367] VBUS on [   70.541374] state change ERROR_RECOVERY -> PORT_RESET [rev3 NONE_AMS] [   70.541410] disable vbus discharge ret:0 [   70.543028] Setting usb_comm capable false [   70.544009] Setting voltage/current limit 0 mV 0 mA [   70.544034] polarity 0 [   70.544239] Requesting mux state 0, usb-role 0, orientation 0 [   70.555550] cc:=0 [   70.555595] pending state change PORT_RESET -> PORT_RESET_WAIT_OFF @ 100 ms [rev3 NONE_AMS] [   70.555697] VBUS off [   70.555702] VBUS VSAFE0V [   70.555762] CC1: 5 -> 0, CC2: 0 -> 0 [state PORT_RESET, polarity 0, disconnected] [   70.587794] VBUS off [   70.587799] VBUS VSAFE0V [   70.655672] state change PORT_RESET -> PORT_RESET_WAIT_OFF [delayed 100 ms] [   70.655682] state change PORT_RESET_WAIT_OFF -> SNK_UNATTACHED [rev3 NONE_AMS] [   70.655686] Start toggling [   70.656274] CC1: 0 -> 0, CC2: 0 -> 0 [state TOGGLING, polarity 0, disconnected]

CVE-2026-98762:

        In the Linux kernel, the following vulnerability has been resolved:  USB: dwc2: shut down wakeup timer before freeing HCD state  dwc2_wakeup_detected() accesses the DWC2 host state and can rearm the wakeup timer.  dwc2_hcd_free() currently deletes the timer only after freeing host-owned state, and timer_delete() does not synchronize a callback or prevent it from being queued again.  Stop and shut down the timer in dwc2_hcd_release(), before the HCD resources are freed.  This covers both the HCD initialization error path and normal HCD removal.

CVE-2026-98763:

        In the Linux kernel, the following vulnerability has been resolved:  usb: core: clear both ep_in and ep_out for non-ep0 control endpoints  In usb_enable_endpoint(), non-zero control endpoints (where usb_endpoint_xfer_control(&ep->desc) is true) populate both dev->ep_in[epnum] and dev->ep_out[epnum] with the same struct usb_host_endpoint pointer.  However, usb_disable_endpoint() only clears either dev->ep_out[epnum] or dev->ep_in[epnum] depending on the direction bit of epaddr when reset_hardware is set, leaving the opposite direction's array slot pointing to the disabled/freed endpoint.  Clear both dev->ep_out[epnum] and dev->ep_in[epnum] when disabling a non-ep0 control endpoint with reset_hardware set, and update the function kerneldoc accordingly.  Tested in QEMU against Linux 7.3.0-rc3 using dummy_hcd and raw-gadget to enumerate a USB device with a non-zero control endpoint (bEndpointAddress 0x01, bmAttributes USB_ENDPOINT_XFER_CONTROL), verifying that both dev->ep_in[1] and dev->ep_out[1] are cleared when the interface is disabled.

CVE-2026-98764:

        In the Linux kernel, the following vulnerability has been resolved:  usb: gadget: f_fs: Fix NULL pointer dereference in FUNCTIONFS_ENDPOINT_DESC  When user space sets up FunctionFS with only full-speed descriptors (e.g., flags = FUNCTIONFS_HAS_FS_DESC) and the gadget operates at a higher speed (such as USB_SPEED_HIGH or USB_SPEED_SUPER), config_ep_by_speed() detects that the function lacks descriptors for the current speed, logs a warning, and falls back to full-speed descriptors. The endpoint is then successfully enabled via usb_ep_enable(), and epfile->ep becomes valid.  However, when user space subsequently issues the FUNCTIONFS_ENDPOINT_DESC ioctl to query the endpoint descriptor, ffs_epfile_ioctl() selects the descriptor index solely based on gadget->speed:  	switch (epfile->ffs->gadget->speed) { 	case USB_SPEED_SUPER: 	case USB_SPEED_SUPER_PLUS: 		desc_idx = 2; 		break; 	case USB_SPEED_HIGH: 		desc_idx = 1; 		break; 	default: 		desc_idx = 0; 	} 	desc = epfile->ep->descs[desc_idx]; 	memcpy(&desc1, desc, desc->bLength);  Because user space only supplied full-speed descriptors, epfile->ep->descs[1] is NULL. Dereferencing desc->bLength triggers an immediate kernel NULL pointer dereference panic.  Fix this by falling back through lower speed descriptors if the current speed descriptor was not supplied, matching the fallback logic in config_ep_by_speed() and historical f_fs behavior. If still missing, fall back to epfile->ep->ep->desc (the active descriptor), and return -EINVAL safely if no valid descriptor is found. In addition, mark desc as const to match struct usb_ep::desc and avoid discarding qualifiers.

CVE-2026-98765:

        In the Linux kernel, the following vulnerability has been resolved:  USB: gadget: dummy-hcd: Fix wait for outstanding request completions  The dummy-hcd driver emulates synchronize_irq() by waiting until its private callback_usage counter drops to 0 (with the private lock not held).  This counter is incremented whenever a gadget driver callback occurs (which requires the private lock to be dropped), but not when a request completion handler is called.  This is an oversight.  Request completion is triggered by timer interrupts (emulating device IRQs in a real UDC), and the interrupt handlers are supposed to have completed when the synchronize_irq() emulation routine returns -- they aren't supposed to be in the middle of a completion callback.  If this happens it can lead to a gadget driver's unbind routine running before all outstanding request completions have finished, maybe even allowing the gadget driver's module to be unloaded while a completion handler is still running.  Fix the oversight by incrementing the callback_usage value across request completion callbacks.

CVE-2026-98766:

        In the Linux kernel, the following vulnerability has been resolved:  usb: gadget: aspeed-vhub: cancel wake work on device removal  wake_work is armed from the gadget .wakeup callback to resume suspended downstream ports, and it is never cancelled in ast_vhub_remove(), so a work item queued before or during removal can run after devm has freed vhub and its ports, a use-after-free.  Cancelling the work alone is not sufficient: usb_gadget_wakeup() takes no lock and the unbind path never clears wakeup_en, so a remote-wakeup request in flight on another CPU can re-arm the work after the cancel and before vhub is freed.  ast_vhub_del_dev() already clears d->registered under vhub->lock before unregistering the gadget. Refuse the wakeup in ast_vhub_udc_wakeup() once d->registered is clear: the check and the schedule_work() are then atomic against the unbind, so a wakeup that passed before the flag was cleared is drained by the cancel_work_sync() after the del_dev loop, and one that arrives later returns without arming. Also move INIT_WORK() to the top of ast_vhub_probe(), since the probe error path reuses ast_vhub_remove() and would otherwise cancel a never-initialized work item.  This issue was found by an in-house static analysis tool.

CVE-2026-98767:

        In the Linux kernel, the following vulnerability has been resolved:  usb: dwc3: gadget: fix IRQ storm on invalid event buffer count  When dwc3_check_event_buf() reads a GEVNTCOUNT value exceeding the event buffer length, commit 63ccd26cd1f6 ("usb: dwc3: gadget: check that event count does not exceed event buffer length") returns IRQ_NONE without writing back GEVNTCOUNT. Since the DWC3 interrupt is level-triggered, the uncleared IRQ source keeps the line asserted, causing a tight IRQ storm that accumulates 99,900 unhandled interrupts and triggers spurious.c:184 BUG -> kernel panic.  The resulting call stack:   __report_bad_irq+0xac/0xc8   note_interrupt+0x340/0x468   handle_irq_event+0xac/0xc0   handle_fasteoi_irq+0x120/0x228   gic_handle_irq+0x68/0x108   ...   kernel BUG at kernel/irq/spurious.c:184  To reproduce, write a bogus value exceeding the event buffer length directly to the GEVNTCOUNT register:    devmem <DWC3_BASE + 0xc40c> 4 0x1004  Write the bogus count back to GEVNTCOUNT to clear the IRQ source, consistent with the stale event clearing pattern in dwc3_event_buffers_setup(), and schedule error recovery to reinitialize the controller.

CVE-2026-98768:

        In the Linux kernel, the following vulnerability has been resolved:  usb: typec: anx7411 - stop the IRQ before destroying the workqueue  The IRQ is devm-managed, so it can still queue plat->work while remove() is tearing the queue down. Disable it first.

CVE-2026-98769:

        In the Linux kernel, the following vulnerability has been resolved:  usb: gadget: f_uac1_legacy: validate bRequest index in generic_{set,get}_cmd  generic_set_cmd() and generic_get_cmd() use the low nibble of ctrl->bRequest as an index into con->data[]:      u8 cmd = (ctrl->bRequest & 0x0F);  /* 0 .. 15 */     ...     con->data[cmd] = value;            /* OOB when cmd >= 5 */  struct usb_audio_control (include/linux/usb/audio.h) declares data as a 5-element array, so indices 5 through 15 write (or read) up to 44 bytes past the end of the array on the heap.  A malicious USB host can craft a class-specific SET_CUR / GET_CUR request with an arbitrary bRequest value, triggering the out-of-bounds access from an IRQ completion handler with no further preconditions.  Add an ARRAY_SIZE() guard to both functions.

CVE-2026-98771:

        In the Linux kernel, the following vulnerability has been resolved:  usb: storage: sierra_ms: reject short SWoC info transfers  sierra_get_swoc_info() requests sizeof(struct swoc_info) (60) bytes from the device via usb_control_msg(), but its callers only treat a negative return value as failure. A device that answers the vendor-specific GetSwocInfo request with a short IN transfer is therefore accepted, leaving the tail of the freshly allocated (kmalloc(), non-zeroing) swoc_info buffer uninitialized.  truinst_show() subsequently prints swocInfo->rev, swocInfo->LinuxSKU and swocInfo->LinuxVer from that buffer into the world-readable (0444) "truinst" sysfs attribute. An emulated/malicious USB device (VID 0x1199, PID 0x0fff) can exploit this to disclose up to 5 bytes of stale kernel heap memory (kmalloc-64) to unprivileged userspace, once per sysfs read, indefinitely. On kernels built without init_on_alloc this leaks recently freed heap contents.  Only accept the transfer when the full structure was received. sierra_ms_init() already retries failed queries, so well-behaved devices are unaffected.

CVE-2026-98772:

        In the Linux kernel, the following vulnerability has been resolved:  USB: serial: fix port tear down use-after-free  Some drivers for multiport devices access port driver data from completion handlers of shared URBs submitted at attach() or first open() and stopped at disconnect() or last close(), respectively.  A simple NULL check before accessing the driver data makes sure that a port state container has at least been allocated, but a completion handler can still race with port tear down.  Reorder the disconnect handling so that ports are not deregistered (and their driver data freed) until after all ports have been hung up and the driver disconnect() callback has run so that all I/O has been stopped.

CVE-2026-98773:

        In the Linux kernel, the following vulnerability has been resolved:  USB: cdc-acm: skip URB restart in port_shutdown if disconnected  acm_port_shutdown() is called from the tty-port machinery whenever the last user closes the port.  acm_disconnect() sets acm->disconnected and calls tty_port_tty_vhangup(), which eventually triggers port_shutdown(). At that point acm_disconnect() has already called acm_poison_urbs() and is about to free the control and read URBs.  However, acm_port_shutdown() unconditionally calls acm_unpoison_urbs() and, when the ALWAYS_POLL_CTRL quirk is set, immediately re-submits the ctrlurb and all read URBs.  If the concurrent acm_disconnect() then frees those URBs and their DMA buffers while they are in-flight, the result is a use-after-free in acm_ctrl_irq() or acm_read_bulk_callback() accessing the freed DMA memory.  Fix by checking acm->disconnected after draining the delayed anchor and returning early: if we are in a disconnect path the URBs must remain poisoned and must not be resubmitted.  The early return is placed after the delayed-anchor drain loop because that loop only cancels write-side accounting (wb->use = false and autopm counter) and does not touch the hardware path.

CVE-2026-98775:

        In the Linux kernel, the following vulnerability has been resolved:  nitro_enclaves: fix use-after-free on SLOT_ALLOC failure  When ne_create_vm_ioctl() fails the SLOT_ALLOC request after anon_inode_getfile() has succeeded, the error path calls fput(enclave_file) and then frees ne_enclave.  In normal userspace context, fput() defers the final __fput() via task_work. ne_enclave_release() therefore runs after ne_enclave has already been freed and dereferences ne_enclave->slot_uid, causing a use-after-free: KASAN: slab-use-after-free in ne_enclave_release.  The enclave has no slot allocated and is not yet linked into the enclaves list on this error path, so ne_enclave_release() is expected to return early when slot_uid is zero. However, reading slot_uid already accesses the freed object.  Clear enclave_file->private_data before fput() on the error path. ne_enclave_release() then returns immediately when private_data is NULL, leaving the ioctl error path as the sole owner of ne_enclave. This is safe because the file has not been fd_install()'d yet.  Tested on an AWS EC2 m5.2xlarge with CONFIG_KASAN=y. Without the patch, the reproducer triggers a KASAN slab-use-after-free on every SLOT_ALLOC failure. With the patch, no KASAN report is produced and the SLOT_ALLOC error is still returned. Normal enclave creation and teardown are unaffected.

CVE-2026-98777:

        In the Linux kernel, the following vulnerability has been resolved:  binder: fix leaked fd fixups on TF_UPDATE_TXN supersede  When a TF_UPDATE_TXN transaction supersedes a pending async transaction in a frozen process, the outdated transaction is freed with kfree() directly. This skips binder_free_txn_fixups(), leaking all binder_txn_fd_fixup entries and their fget()'d struct file references.  The leaked file refcounts never reach zero, so the struct file objects are permanently pinned in memory. They survive process exit and accumulate across invocations until file-max exhaustion.  Every other transaction cleanup path (binder_free_transaction(), binder_transaction() error paths, binder_release_work()) correctly calls binder_free_txn_fixups(). Add the missing call before kfree() in the t_outdated cleanup block.

CVE-2026-98778:

        In the Linux kernel, the following vulnerability has been resolved:  binder: fix is_failure flag for superseded transaction cleanup  When a TF_UPDATE_TXN transaction supersedes a pending async transaction, binder_release_entire_buffer() is called with is_failure=false. Since the superseded transaction was never delivered, binder_apply_fd_fixups() was never called and no fds were installed in the target process.  With is_failure=false, the BINDER_TYPE_FDA cleanup handler interprets stale buffer contents as installed fd numbers and passes them to binder_deferred_fd_close(), closing unrelated file descriptors.  Pass is_failure=true since the transaction was never delivered to the target, matching the semantics of all other undelivered-transaction cleanup paths.

CVE-2026-98779:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu: fix ACP MFD device leak on init failure  acp_hw_init() registers ACP child devices with mfd_add_devices() before attaching them to the ACP power domain and initializing the hardware.  If attaching a child to the power domain fails, or if the ACP reset or clock enable operation times out, the failure path frees only the source cell, resource, and platform-data allocations. The child platform devices already registered by mfd_add_devices() remain registered and are never released.  Remove the children from the power domain and unregister the MFD devices on failures that occur after mfd_add_devices() succeeds. Keep mfd_add_devices() failures on the existing cleanup path since the MFD core already rolls back partially registered children itself.  The issue was identified by a static analysis tool I developed and confirmed by manual review.  (cherry picked from commit 63da68d6a2279ec945581c990c5a59a5ae8b5560)

CVE-2026-98780:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu: fix IP instance memory leak on kobject add failure  amdgpu_discovery_sysfs_ips() allocates ip_hw_instance with kzalloc_flex() and initializes its embedded kobject before calling kobject_add().  If kobject_add() fails, the return value is ignored and execution continues without dropping the initial kobject reference. The failed kobject is not retained in the kset list, so the normal sysfs teardown path cannot find it. As a result, ip_hw_instance_release() is never called and the ip_hw_instance allocation is leaked.  Call kobject_put() when kobject_add() fails so the initial reference is dropped and ip_hw_instance_release() can free the allocation. Keep the existing best-effort sysfs behavior by continuing with the remaining IP entries after the failed registration.  The issue was identified by a static analysis tool I developed and confirmed by manual review.  (cherry picked from commit 5c75fbcca8af1096d8d9415b91d8ea6212c22ee1)

CVE-2026-98784:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amdgpu/gfx6: fix firmware leak on teardown  The firmware requested in gfx_v6_0_init_microcode() is not released when the GFX block is torn down, leaking the firmware resources.  Add gfx_v6_0_free_microcode() and call it from gfx_v6_0_sw_fini() to release the PFP, ME, CE and RLC firmware.  (cherry picked from commit 386e81346f95ab0be5a82c5535de932e7a456924)

CVE-2026-98785:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: check dc_state_create_copy() for NULL in dm_suspend  dc_state_create_copy() can return NULL on allocation failure. dm_suspend() only conditionally skips dm_gpureset_toggle_interrupts() and continues execution, returning success.  dm_resume() then dereferences the NULL cached_dc_state in link_enc_cfg_copy() and the following dc_state->stream_count loop, crashing during GPU reset recovery.  Return -ENOMEM immediately if the copy fails, so the caller aborts suspend instead of leaving a NULL cached state for resume.  (cherry picked from commit 84b6d7932fdd2857795a257f9f258562a3cddcab)

CVE-2026-98786:

        In the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: guard dc_sink dereferences in MST mode validation  dm_dp_mst_is_port_support_mode() reads aconnector->dc_sink->dsc_caps... for the DSC branch-throughput check, and get_conv_frl_bw()'s HDMI-PCON FRL-bandwidth path reads aconnector->dc_sink->edid_caps.max_frl_rate, both without a NULL check. dc_sink is cleared asynchronously on MST unplug, and both functions run from paths that the driver's own comments document as racing that teardown: the connector probe worker's ->mode_valid callback and a compositor's atomic check, neither of which holds the MST manager lock that the teardown path uses. The former does have an existing dsc_aux NULL check, but dsc_aux isn't reliably cleared in every path that clears dc_sink, so it doesn't cover this.  Fail the port-support check and skip the FRL conversion path when the sink is already gone.  (cherry picked from commit 7c3db8da4e039698ae198c870712428644e965c7)

CVE-2026-98789:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: Fix objects stuck in free_by_rcu_ttrace  do_call_rcu_ttrace() returns early when call_rcu_ttrace_in_progress is set and leaves the objects in free_by_rcu_ttrace. __free_rcu() frees waiting_for_gp_ttrace only and clears the flag. Hence the objects that free_bulk() or __free_by_rcu() added while RCU tasks trace GP was in flight stay in free_by_rcu_ttrace until free_bulk() or alloc_bulk() is called for the same bpf_mem_cache again, which may never happen. The number of such objects is not bounded.  Turn call_rcu_ttrace_in_progress into three states: 0 - idle 1 - __free_rcu() is queued 2 - __free_rcu() is queued and free_by_rcu_ttrace got more objects since  do_call_rcu_ttrace() sets 2. __free_rcu() does cmpxchg(1 -> 0) and starts the next GP when it fails. It cannot clear the flag first and check free_by_rcu_ttrace later, since bpf_mem_alloc_destroy() frees bpf_mem_cache without waiting for RCU callbacks when the flag is zero.  Now __free_rcu() queues itself, so the one that didn't see 'draining' may do call_rcu_tasks_trace() after rcu_barrier_tasks_trace() in free_mem_alloc(). Queue it under rcu_read_lock() and do synchronize_rcu() before the barriers. Calling rcu_barrier_tasks_trace() twice works too, but creating and destroying hash maps in a loop on many cpus slows down to one free_mem_alloc() per GP and kworkers pile up.

CVE-2026-98790:

        In the Linux kernel, the following vulnerability has been resolved:  perf: Fix race between perf_event_exit_task() and perf_pending_task()  A race condition exists between perf_event_exit_task() and perf_pending_task() during begin_new_exec().  During begin_new_exec(), perf_event_exit_task() may be called, and the PF_EXITING flag is not set on task. So perf_sigtrap() continues to execute and triggers WARN_ON_ONCE(event->ctx->task != current).  Since both task exit and exec paths can call perf_event_exit_task() which sets ctx->task to TASK_TOMBSTONE, fix this by explicitly checking if event->ctx->task equals TASK_TOMBSTONE and dropping the redundant PF_EXITING check.

CVE-2026-98792:

        In the Linux kernel, the following vulnerability has been resolved:  netfilter: flowtable: generalize pending status bit  Rename NF_FLOW_HW_PENDING to NF_FLOW_PENDING and use it to inhibit the flowtable GC worker until pending hw offload work has been completed.  Apparently, nf_flow_offload_stats() can schedule work to retrieve stats while the flow is being removed by GC.  And this bit can also be used in a follow up patch to disable GC until the flow has been fully added in both directions.  Revert the reordering done in commit d644b23afe1e ("netfilter: flowtable: publish HW_DEAD after worker is done") to prevent a race between GC and hw offload handler.

CVE-2026-98793:

        In the Linux kernel, the following vulnerability has been resolved:  netfilter: bpf: reject invalid NAT manipulation types  As bpf_ct_set_nat_info() is not validating the NAT manipulation type a wrong value can be passed directly to nf_nat_setup_info(). This triggers the WARN_ON() at nf_nat_setup_info() and if panic_on_warn isn't set, then IPS_SRC_NAT_DONE is set without adding nat_bysource and conntrack cleanup tries to unlink an uninitialized hlist node.  Fix this by checking that NAT manipulation type is correct before calling nf_nat_setup_info(). In addition, if the WARN_ON is hit, return NF_DROP instead of continuing with the processing to avoid similar situations in the future.

CVE-2026-98794:

        In the Linux kernel, the following vulnerability has been resolved:  ipvs: filter some flags received in the backup server  While the IPVS SYNC protocol is not secure by design we can still protect the backup server from messages that can wreak havoc.  This commit addresses problems from received connection flags or their combinations. We now drop messages as follows:  1. the NO_CPORT+TEMPLATE combination allows lookups for normal connections to hit template which can break in many ways. While the master does not sync connections with NO_CPORT flag, i.e. before they are established, we still accept NO_CPORT without TEMPLATE.  2. ONE_PACKET: it is not sent by master, so we do not expect it in backup. Before now it was ignored by IP_VS_CONN_F_BACKUP_MASK for protocol v1 while protocol v0 created connections that are not hashed and dropped immediately. Better to apply the IP_VS_CONN_F_BACKUP_MASK also to the flags from v0 messages for consistency with v1.

CVE-2026-98795:

        In the Linux kernel, the following vulnerability has been resolved:  net: sparx5: skip ptp deinit if init was skipped  sparx5_ptp_init() returns early on the base lan969x variants because they do not have the SPX5_FEATURE_PTP flag. It also returns early when no "ptp" interrupt is described. Unbinding the driver then causes a NULL pointer dereference when cleaning up uninitialized tx_skbs queues:      Unable to handle kernel NULL pointer dereference at virtual address     0000000000000008     Call trace:     skb_queue_purge_reason+0x68/0x120 (P)     sparx5_ptp_deinit+0x64/0xc0     mchp_sparx5_remove+0x38/0x70     platform_remove+0x20/0x30     device_remove+0x4c/0x80  Before per-port tx_skbs were added, a NULL dereference would have happened when calling ptp_clock_unregister() on the never-registered PTP clocks.  Fix by returning early in sparx5_ptp_deinit() if PTP is not used.

CVE-2026-98796:

        In the Linux kernel, the following vulnerability has been resolved:  net: ethernet: mtk_eth_soc: allocate dummy netdev sooner  The RX rings and the shared NAPI are carried by an internal "dummy" netdev (eth->dummy_dev). mtk_probe() creates that dummy device, and adds the shared tx/rx NAPI to it, only after the MAC netdevs have been registered. That order has been there since the MT7623 support was added and leaves a window in which the netdevs are visible to the network core before the shared NAPI and the dummy device exist.  If anything brings the first netdev up during that window (e.g. netifd opening the WAN link the instant the interface is registered), the first-open path runs without them. On NETSYS v2 and later SoCs mtk_rx_alloc() -> __xdp_rxq_info_reg() then dereferences eth->dummy_dev == NULL:    WARNING: CPU: ... Missing net_device from driver  in net/core/xdp.c and mtk_open() fails with -ENODEV. On NETSYS v1 SoCs (MT7621/MT7622/MT7623/MT7629) there is no page pool, so the same open instead calls napi_enable() on a napi_struct that netif_napi_add() has not initialised yet and dereferences a NULL napi->dev.  Allocate the dummy netdev and add the shared tx/rx NAPI to it before the register_netdev() loop. Both the dummy-allocation failure and a register_netdev() failure now unwind through mtk_unreg_dev(), which unregisters the net_device notifiers and the netdevs registered so far, stopping a concurrently-opened netdev (ndo_stop) and its NAPI before the dummy carrier is freed.  A netdev that opened during the window can also have queued the frame-engine reset worker (via the tx watchdog or phylink), so the probe error path now cancels eth->pending_work before freeing the shared state, as mtk_cleanup() already does on remove.

CVE-2026-98797:

        In the Linux kernel, the following vulnerability has been resolved:  net: cap skb->queue_mapping when the tx queue is picked  skbedit can set skb->queue_mapping and raise the per-CPU skip_txqueue flag so __dev_queue_xmit() honours the mapping. __dev_queue_xmit() cleared the flag before sch_handle_egress() and only read it afterwards, so the flag was not confined to the xmit that set it: a nested xmit (mirred redirect or mirror, or a drop after skbedit) could set the flag and the outer xmit would consume it for an skb that never went through skbedit.  A forwarded packet still carries the ingress NIC's rx_queue + 1 in skb->queue_mapping, so the outer device then indexes its tx queue state with that stale value. Taprio's child array q->qdiscs[] is sized to the device's queue count, so taprio_enqueue() indexes past its allocation and dereferences the result as a struct Qdisc *.  We (ab)use the skb->nf_skip_egress which means "skip netfilter egress for this packet" to tag to "am I in tc egress?". Despite the overload I dont see it as a conflict since the marker is set only around the single sch_handle_egress() call and ingress path is guarded by tc_at_ingress. I will send a followup(net-next) patch once this hits net-next to rename the skb->nf_skip_egress bit/flag to skb->skip_egress  Arm the flag only from the egress classifier that can use it: raise skip_txqueue from tcf_skbedit_act() only when it runs inside sch_handle_egress(), thanks to skb->nf_skip_egress. An egress qdisc classifier runs in q->enqueue(), after the tx queue has been picked, so a mapping it sets cannot affect the current packet; arming the flag there only pollutes it for a later xmit. Then own the flag for the xmit frame the egress hook runs in: save the incoming value and clear it just before sch_handle_egress(), and restore it after the hook - on the consumed (drop) path, or, in the same call that reads it, on the surviving path. The save and the restores stay inside the egress_needed_key static branch, so a packet pays for them only when egress hooks are active (2f1e85b1aee4).  Store the value netdev_cap_txqueue() selected back into skb->queue_mapping in netdev_tx_queue_mapping(), as netdev_core_pick_tx() already does, so the skip_txqueue path never hands a later reader on the xmit path a mapping the device cannot serve. A store made still later in the same frame, by a tc BPF program attached to a transmit qdisc, is outside this path and is not re-capped; a separate followup will resolve that path.  netdev_xmit_skip_txqueue() returns the previous flag value so the save-and-clear is one call, and a no-op stub is provided when CONFIG_NET_EGRESS is disabled. skb->nf_skip_egress is compiled under CONFIG_NET_EGRESS rather than CONFIG_NETFILTER_SKIP_EGRESS, so skb_at_tc_egress() is valid whenever the egress path is built.  A local user in a network namespace can redirect a packet from a device with more TX queues to one with fewer after setting a mapping valid only on the larger device. That reaches these reads and, under KASAN, faults with "slab-out-of-bounds in taprio_enqueue".  Conditions to recreate the bug: the report's own trigger is a local user with CAP_NET_ADMIN in a network namespace, so no eBPF program is needed. With CONFIG_NET_SCH_TAPRIO=y, CONFIG_NET_ACT_SKBEDIT=y, CONFIG_NET_ACT_MIRRED=y, CONFIG_NET_CLS_MATCHALL=y, CONFIG_NET_SCH_PRIO=y and KASAN enabled, create qa (3 queues), qb (2 queues) and qc (1 queue) as dummy devices; put a taprio root on qb (num_tc 1, queues 2@0) and clsact on all three; then add an egress matchall filter on every device. On qa: "action skbedit queue_mapping 2 pipe action mirred egress redirect dev qb". On qb: "action mirred egress mirror dev qc". On qc: "action skbedit queue_mapping 0 pipe". Send one packet out qa. qc's skbedit sets the flag while qb's outer xmit is in flight; without the fix qb consumes it and reads its two-entry taprio child array with the forwarded packet's stale mapping. A qc whose skb ---truncated---

CVE-2026-98798:

        In the Linux kernel, the following vulnerability has been resolved:  net: bcmgenet: fix NULL dereference in set_coalesce before first open  The Rx ring priv and index are only set in bcmgenet_init_rx_ring(), which runs at open. Setting the Rx coalescing parameters on an interface that was never opened, e.g. "ethtool -C eth0 rx-usecs 50", dereferences a NULL ring->priv. The oops happens with RTNL held, so networking stays stuck until a reboot:    Unable to handle kernel paging request at virtual address 0000000000002788   pc : bcmgenet_set_rx_coalesce.isra.0+0x10/0x88   lr : bcmgenet_set_coalesce+0xe8/0x180   Call trace:    bcmgenet_set_rx_coalesce.isra.0+0x10/0x88 (P)    __ethnl_set_coalesce.isra.0+0x490/0x570    ethnl_set_coalesce+0x48/0xc0    ethnl_default_set_doit+0xf4/0x230    genl_family_rcv_msg_doit+0xe8/0x160    genl_rcv_msg+0x220/0x2a0    netlink_rcv_skb+0x68/0x140    genl_rcv+0x40/0x60    netlink_unicast+0x338/0x3c0    netlink_sendmsg+0x19c/0x3f8    __sock_sendmsg+0x64/0xc0    __sys_sendto+0x124/0x198    __arm64_sys_sendto+0x30/0x48  Set priv and index at probe. Writing the registers while the interface is down is harmless because open resets the MAC and bcmgenet_init_rx_coalesce() reapplies the stored values.  It was observed on a Raspberry Pi CM4, but should apply to all other genet devices.

CVE-2026-98799:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: Skip detached progs in trampoline images that are still in use  bpf_tramp_image_put() makes sure a trampoline image is not freed while a task may still be running in it, but nothing similar is done for the progs called by that image. Detach drops the last prog reference right away and the prog is freed after grace periods, on the basis that a task still in the traced function skips the fexit progs once the nop at ip_after_call is patched to a jump.  That leaves out a task sleeping in a sleepable prog that runs before the detached one, which no grace period waits for:    CPU 0                               CPU 1   in image I, sleeping in prog S                                       detach P from I's trampoline                                        -> new image, bpf_tramp_image_put(I)                                       bpf_prog_put(P), last ref                                       grace periods, P freed   back from S   __bpf_prog_enter(P)   call P->bpf_func  If S and P are fexit progs the task is already past the patched jump, and fentry only images don't have one. On x86 this is an int3 in poisoned bpf_prog_pack memory:    Oops: int3: 0000 [#1] SMP NOPTI   CPU: 18 UID: 0 PID: 94573 Comm: x169 Not tainted 6.18.44 #1 PREEMPT(lazy)   RIP: 0010:0xffffffffc0601d8d   Call Trace:    <TASK>    ? bpf_trampoline_6442515411+0x1a4/0x21b    bpf_lsm_bprm_committed_creds+0x5/0x10    security_bprm_committed_creds+0x5f/0x70    begin_new_exec+0x2d6/0x410    ...  We hit this in production when progs attached through trampolines got detached while their hooks were busy, and it was independently found with a fuzzer and KASAN.  Have the JITs emit a patchable nop in front of each prog call sequence and record it in the image. When a prog is detached, patch its nop to a jump over the call sequence. Progs that stay attached keep running for the tasks that are in the image, and ip_after_call isn't needed anymore.  The task can be in any image that isn't freed yet, not only in the current one. It sleeps in image I1 that calls S, P and Q, then P is detached and the trampoline moves to image I2, then Q is detached and its call is still in I1. So the trampoline keeps a list of its images until they are freed, and detaching a prog patches its nop in all of them. Images hold a reference on the trampoline for that long.  On riscv and loongarch a jump of any range takes several instructions, and a task preempted in the middle of them could resume into half of the new sequence. The nop is a single instruction there, patched to a near branch through arch_bpf_trampoline_skip().  With the extra nops, BPF_MAX_TRAMP_LINKS progs no longer fit in a page on x86 and arm64 (and already didn't on powerpc), so lower the limit there like s390 does.

CVE-2026-98800:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: Wait for an RCU tasks grace period before freeing trampoline progs  When a prog is detached from a trampoline, it is freed after an RCU grace period, or an RCU tasks trace one if it is sleepable. This covers the tasks that are running the prog, since the prog's enter helper takes the matching read lock before the prog is called. On a preemptible kernel, it doesn't cover a task that was preempted in the trampoline just before the enter helper. That task holds no lock yet, and it calls the prog after it was freed:    BUG: KASAN: vmalloc-out-of-bounds in __bpf_prog_enter_recur+0x3a5/0x3f0   Read of size 8 at addr ffffc90000055040 by task candidate/110   CPU: 1 UID: 0 PID: 110 Comm: candidate Not tainted 7.3.0-rc2-00014-g15071f2a1263-dirty #2 PREEMPT(full)   Call Trace:    <TASK>    __bpf_prog_enter_recur+0x3a5/0x3f0    bpf_trampoline_6442509193+0x37/0xf1    __x64_sys_futex+0x9/0x410    do_syscall_64+0xb0/0x530    ...  Wait for an RCU tasks grace period before the existing one when freeing a prog that was linked to a trampoline. An RCU tasks grace period only ends once the tasks that were preempted have run again, and bpf_tramp_image_put() already relies on it to free the image. It doesn't wait for tasks that sleep in the trampoline, the next commit takes care of those.  Only progs that were linked to a trampoline can be called this way, so bpf_trampoline_add_prog() marks them and other progs are still freed as before.

CVE-2026-98801:

        In the Linux kernel, the following vulnerability has been resolved:  net: restrict SO_RESERVE_MEM to TCP sockets and cap max value  Commit 2bb2f5fb21b0 ("net: add new socket option SO_RESERVE_MEM") and commit d00c8ee31729 ("net: fix possible NULL deref in sock_reserve_memory") only checked sk_has_account(sk), which is true for both TCP and UDP sockets.  However, SO_RESERVE_MEM and sk_unused_reserved_mem() are currently only supported by TCP: - On UDP sockets, sk->sk_forward_alloc is protected by   sk->sk_receive_queue.lock, whereas sock_reserve_memory() and   sock_release_reserved_memory() only acquire lock_sock(sk). Concurrent   UDP packet reception/release and setsockopt(SO_RESERVE_MEM) corrupt   sk_forward_alloc and memcg accounting. - udp_rmem_release() reclaims excess sk_forward_alloc without   accounting for sk_unused_reserved_mem(sk).  Restrict sock_reserve_memory() to TCP sockets (sk_is_tcp(sk)) for now. Supporting SO_RESERVE_MEM for UDP (acquiring sk_receive_queue.lock and honoring sk_unused_reserved_mem() in udp_rmem_release()) can be done in a future net-next series if needed.  In addition, reject val > SZ_1G with -EINVAL in sk_setsockopt(SO_RESERVE_MEM). Without an upper bound, values near INT_MAX cause sk_mem_pages(delta) and (pages << PAGE_SHIFT) to overflow 32-bit signed int, corrupting sk->sk_forward_alloc and sk->sk_reserved_mem. Using a page-aligned cap (SZ_1G) ensures that the page-rounded sk->sk_reserved_mem reported by getsockopt(SO_RESERVE_MEM) can always be passed back to setsockopt(SO_RESERVE_MEM).

CVE-2026-98802:

        In the Linux kernel, the following vulnerability has been resolved:  seg6: ensure packet data is writable before modifying SRH and IPv6 DA  advance_nextseg() modifies the SRH Segments Left field and the IPv6 destination address without ensuring the packet data is writable. seg6_next_csid_advance_arg() has the same problem when it advances the NEXT-C-SID argument in the destination address.  The skb may be cloned, for example by an AF_PACKET socket receiving on the ingress device. advance_nextseg() and seg6_next_csid_advance_arg() then write into the packet data shared with the clone. A read from that socket can return the modified packet instead of the received one. The simplified path below shows this for advance_nextseg():  __netif_receive_skb_one_core   __netif_receive_skb_core     deliver_skb               [orig: users=2, cloned=0]       packet_rcv         skb_clone             clone queued to the AF_PACKET socket         consume_skb(orig)     [orig: users=1, cloned=1]   ipv6_rcv     ip6_rcv_core              skb_share_check: no-op [orig: users=1]     [...]       input_action_end_core         advance_nextseg       writes into the data shared with the clone  Call skb_ensure_writable() in advance_nextseg() and in seg6_next_csid_advance_arg() before they modify the packet data. skb_ensure_writable() may reallocate skb->head, which invalidates the pointers into the packet data taken before the call. advance_nextseg() now returns a valid SRH pointer, or NULL if skb_ensure_writable() fails. seg6_next_csid_advance_arg() takes the pointer to the destination address from the skb after skb_ensure_writable(). On failure, the callers drop the packet with SKB_DROP_REASON_NOMEM.

CVE-2026-98803:

        In the Linux kernel, the following vulnerability has been resolved:  net: stmmac: fix rx Scatter-Gather support  When a received frame is larger than dma_buf_sz, the DMA scatters it across multiple RX descriptors (rx Scatter-Gather). The secondary RX buffer (sec_page) was only allocated and programmed when split-header (SPH) was active, so for regular frames buffer2 was neither allocated nor backed by a valid mapping. As soon as an incoming frame overflowed buffer1, the DMA wrote the overflow into the unmapped secondary-buffer address, triggering an SMMU translation fault on IOMMU-based platforms:  arm-smmu 15000000.iommu: Unhandled context fault: fsr=0x402, iova=0x00000000, fsynr=0x7f0011, cbfrsynra=0x1c90, cb=11 arm-smmu 15000000.iommu: FSR    = 00000402 [Format=2 TF], SID=0x1c90 arm-smmu 15000000.iommu: FSYNR0 = 007f0011 [S1CBNDX=127 WNR PLVL=1]  Enable scatter-gather for non-SPH frames on cores that can program an independent secondary RX buffer (GMAC4/XGMAC): allocate and mark buffer2 as valid in stmmac_init_rx_buffers() and stmmac_rx_refill(), and account for it in the buffer length computation. Legacy cores have no set_sec_addr op, so they keep buffer2 disabled.  Since buffer2 is handed to the DMA at page offset 0, the page pool sync window is widened to cover both buffers in every mode: offset is set to 0 and max_len to dma_buf_sz + stmmac_rx_offset().  The FCS can straddle the buffer1/buffer2 boundary and a descriptor boundary, so it is now stripped from the tail of the assembled frame with pskb_trim() instead of from a single buffer, avoiding an unsigned underflow for frames that overflow a buffer by 1..3 bytes. For single-buffer frames the XDP program must not see the FCS, so it is removed from the XDP buffer before the program runs.  Native XDP currently only supports single-buffer (linear) frames. An oversized frame accepted by the MAC (jumbo enabled) is received via buffer2; the XDP program only sees buffer1, so on a TX/REDIRECT verdict the frame is forwarded truncated. XDP multi-buffer support to handle this case is planned as a follow-up.  AF_XDP zero-copy RX is not covered by this change: a ZC queue still programs buffer2 at DMA address 0 (and XGMAC has no buffer2-valid bit), so an oversized frame overflowing buffer1 can still trigger the same SMMU translation fault. Handling is planned as a follow-up.

CVE-2026-98805:

        In the Linux kernel, the following vulnerability has been resolved:  tipc: prevent GCM nonce reuse on peer key changes  TIPC can encrypt traffic between nodes using a different transmit key for each node. In this mode, the AES-GCM nonce for a packet sent to a known peer consists of a 32-bit prefix (a per-key salt XOR the peer's address) followed by a 64-bit counter. That counter is stored in the peer's RX crypto object. When the peer reports a change in which key it uses to receive packets, TIPC resets this counter. The sender can still be using the same TX key and salt, so subsequent packets reuse earlier nonces. This nonce reuse breaks confidentiality and exposes GCM's authentication key. This makes forgeries trivial: an attacker can exploit CTR malleability to alter captured ciphertexts and use the recovered authentication key to compute a valid tag for the modified ciphertext, under the same key and nonce.  Use the TX key's existing aead->seqno counter instead. All encryptions using that key object share the same atomic counter, so concurrent encryptions get distinct nonce counter values. The counter survives key activation and peer reconnection, and peer key-status reports cannot reset it. This prevents those transitions from causing nonce reuse while the same TX key remains installed.  The nonce format is unchanged, and receivers do not require consecutive counter values, so sharing the counter across peers remains compatible with existing receivers. A pre-existing check still invokes key revocation in the unlikely event that the counter wraps to zero.

CVE-2026-98807:

        In the Linux kernel, the following vulnerability has been resolved:  net/mlx5: Fix slab-out-of-bounds when handling team device events  The mlx5_handle_changeupper_event() and mlx5_handle_changeinfodata_event() functions check for LAG masters (which includes both bonding and team devices) but only call bonding-specific APIs. When processing team device events, calling bond_slave_get_rcu() and bond_is_slave_inactive() on team_port structures causes KASAN to detect an out-of-bounds memory access since team_port is smaller than bond slave.  Fix this by wrapping the bond-specific API calls with a check for bonding devices. This allows the function to still process LAG events for both bonding and teams but only calls bond-specific functions when dealing with actual bonding devices.  For mlx5_handle_changeinfodata_event(), keep the explicit bond check as mlx5 doesn't handle state information for team ports anyway.  Tested with Mellanox ConnectX-5 on Linux 7.2.0-rc6: - Bonding: PASS (no regressions) - Team device: PASS (no KASAN errors)

CVE-2026-98808:

        In the Linux kernel, the following vulnerability has been resolved:  net: systemport: Fix buffer overflow in bcm_sysport_get_stats()  When running on SYSTEMPORT Lite, certain statistics are unsupported and skipped during bcm_sysport_get_stats(). The variable 'j' tracks the compacted index into the destination data buffer, whereas 'i' iterates over all elements in bcm_sysport_gstrings_stats.  Because the buffer allocated by ethtool is sized only according to bcm_sysport_get_sset_count(), storing values at data[i] instead of data[j] writes past the allocated array bounds, leading to memory corruption.  Fix this by writing to data[j] instead of data[i].

CVE-2026-98809:

        In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: hci_sync: don't drain cmd_sync backlog on unregister  hci_unregister_dev() disables cmd_work and cmd_timer, then calls hci_cmd_sync_clear(), whose cancel_work_sync() waits for hci_cmd_sync_work() to return. That worker dequeues and runs every entry on cmd_sync_work_list. With cmd_work disabled nothing reaches the controller, so each queued HCI command waits the full HCI_CMD_TIMEOUT (2s).  The backlog has no bound. Userspace can keep queuing MGMT commands such as MGMT_OP_GET_CLOCK_INFO against a controller that doesn't answer. Closing /dev/vhci then blocks in vhci_release() for backlog * 2s:    INFO: task syz-executor:5749 blocked for more than 143 seconds.    cancel_work_sync    hci_cmd_sync_clear    hci_unregister_dev    vhci_release  In a local reproduction the backlog held more than 5000 entries, which comes to hours of hang.  Stop the worker from taking new entries once HCI_UNREGISTER is set, and wake any request still waiting with -ENODEV before cancelling the work. The entries left over are destroyed with -ECANCELED by the existing sweep in hci_cmd_sync_clear(). They stay on the list until the work has stopped, so hci_cmd_sync_dequeue() and friends still see them. A callback already running may still issue another command, which delays unregister by at most one timeout per remaining command, not by the whole backlog.

CVE-2026-98810:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: mac80211: fix slab-out-of-bounds read in ieee80211_monitor_select_queue()  ieee80211_monitor_select_queue() validates the skb length using skb->len before dereferencing pointers into skb->data to access the 802.11 header. However, skb->len includes data in both the linear head buffer and non-linear fragments/pages. When AF_PACKET sends a packet large enough to become non-linear, the 802.11 header at skb->data + len_rthdr may extend past the linear head buffer even though skb->len appears sufficient.  This leads to a slab-out-of-bounds read when accessing hdr->frame_control, as the kernel reads beyond the allocated skb head buffer:    BUG: KASAN: slab-out-of-bounds in ieee80211_monitor_select_queue+0x1ed/0x220  syzbot has hit the same issues.  Fix this by checking skb_headlen(skb) (which gives the length of the linear data region) instead of skb->len before dereferencing skb->data pointers. This ensures the required bytes are actually present in the linear portion of the skb.  Apply the same fix to ieee80211_validate_radiotap_len() which has the same class of bug: it uses skb->len to validate accesses to skb->data, and to the corresponding checks in ieee80211_monitor_start_xmit(): for drivers advertising NETIF_F_SG the skb is not linearized before ndo_start_xmit, so the 802.11 header can be read past the linear buffer there as well.

CVE-2026-98811:

        In the Linux kernel, the following vulnerability has been resolved:  net/sched: cls_api: reclaim an empty proto on the error path  Two racing tc filter add requests on the same chain/prio of an unlocked classifier both run change() on the shared proto and both can fail: the winner's tcf_chain_tp_delete_empty() attempt gives up because the loser's handle is still in the idr, and the loser's error path drops only its own reference without a second reclamation attempt. The empty proto stays linked in the chain, holding the chain reference, a block reference and the classifier module reference until the chain or block is torn down.  Reclaim the proto on the error path of any failed request that holds a proto reference. The reclamation is emptiness-gated: tcf_chain_tp_delete_empty() unlinks the proto only when delete_empty() admits it is empty, so a live shared proto is never unlinked. A proto the request created is reclaimed unconditionally - it is the only owner, so marking it for deletion is safe even without a delete_empty callback. Classifiers without one (the check marks the proto unconditionally) are rtnl-serialized, so the raced window this guard closes cannot arise for them.  This is a follow-up to commit d4e359b3608a ("net/sched: cls_api: fix teardown of an adopted proto on insert-race loss"), which stopped the loser of the insert race from unlinking the winner's live proto but left the empty-proto residual in place.  Conditions to recreate: - CONFIG_NET_CLS_FLOWER=y; veth pair - tc qdisc add dev veth0 ingress - two concurrent `tc filter add dev veth0 ingress protocol ip pref 1   flower skip_sw ... action drop` (both fail in fl_hw_replace_filter   after publishing their handle in the idr); repeat in a loop - an empty flower tp stays linked after both requests fail; visible   as a bare `filter protocol ip pref 1 flower chain 0` header in   `tc filter show` with no filter entries - CAP_NET_ADMIN (namespace-local via unshare -Urn suffices)

CVE-2026-98812:

        In the Linux kernel, the following vulnerability has been resolved:  net/mctp: publish the mctp_dev only after it is initialised  mctp_add_dev() links the new mctp_dev into dev->mctp_ptr before mdev->dev is assigned, so a reader that picks the device up in that window dereferences a net_device pointer that is still NULL:  KASAN: null-ptr-deref in range [0x00000000000000b0-0x00000000000000b7] Call Trace:  <TASK>  ? __pfx_mctp_sendmsg (./include/linux/sockptr.h:49)  ? __pfx_mctp_dst_output (net/mctp/route.c:41)  ? selinux_socket_sendmsg (security/selinux/hooks.c:5278)  ____sys_sendmsg (net/socket.c:775 (discriminator 1) net/socket.c:790  (discriminator 1) net/socket.c:2684 (discriminator 1))  ? __pfx_____sys_sendmsg (net/socket.c:1131)  ? __pfx_copy_msghdr_from_user (net/socket.c:2590)  ? update_cfs_rq_load_avg (kernel/sched/fair.c:5478)  ___sys_sendmsg (net/socket.c:2738)  ? __pfx____sys_sendmsg (net/socket.c:2625)  ? perf_event_task_tick (./include/linux/rcupdate.h:838)  ? sched_tick (kernel/sched/core.c:5818)  ? clockevents_program_event (kernel/time/clockevents.c:372)  ? fdget (./include/linux/rcupdate.h:873 fs/file.c:1100)  __sys_sendmsg (net/socket.c:2770)  ? __pfx___sys_sendmsg (net/socket.c:2751)  do_syscall_64 (arch/x86/entry/syscall_64.c:63)  entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)  </TASK>  Fix by publishing only once the object is fully initialised: __mctp_dev_get() runs under rcu_read_lock() only and hands this object to readers as soon as mctp_ptr is assigned, so they must never observe mdev->dev == NULL.

CVE-2026-98814:

        In the Linux kernel, the following vulnerability has been resolved:  nvme: fix command effects log lifetime for multipath heads  KASAN reported a use-after-free when an I/O passthrough command was sent through a multipath namespace head after the controller path that first created the head had been removed:    BUG: KASAN: slab-use-after-free in nvme_command_effects+0x192/0x200 [nvme_core]   Read of size 4 at addr ffff888141b14400 by task nvme/19811   nvme_command_effects+0x192/0x200 [nvme_core]   nvme_cmd_allowed+0x7e/0x1b0 [nvme_core]   nvme_user_cmd.constprop.0+0x1b5/0x450 [nvme_core]   nvme_ns_head_chr_ioctl+0xf4/0x2a0 [nvme_core]  Move the log cache to the subsystem, with one entry per command set. Both controllers and namespace heads hold subsystem references, keeping their log pointers valid until subsystem release.

CVE-2026-98815:

        In the Linux kernel, the following vulnerability has been resolved:  nvme: fix cdev lifetime  Sashiko bot reported a potential problem for the cdev lifetime in [0] - the code there is heavily based on the NVMe code.  Currently the NS head .open and .release file_operations methods take and put a reference to the nvme_ns_head to ensure that this structure does not disappear while we open fds for that cdev.  In multipath mode, when we teardown the NS head, we call nvme_cdev_del() -> cdev_device_del() -> cdev_del(). However after cdev_del() returns, cdevs already open will remain and their fops will still be callable. As such, we can still reference the cdev after the nvme_ns_head reference count drops to 0 (and is freed).  This can be shown with an application which delays between opening the cdev and issuing the ioctl while the NS head is being torn down:  # ./ioctl_file /dev/ng1n1 & # waiting 10 seconds ....  # ./ini_nvme_teardown.sh [   21.221718] nvme nvme1: Removing ctrl: NQN "nvme-test-target" [   21.274609] nvme nvme2: Removing ctrl: NQN "nvme-test-target" # now going to issue ioctl .... [   26.549285] ================================================================== [   26.550841] BUG: KASAN: slab-use-after-free in cdev_put.part.0+0x3d/0x40 [   26.552352] Read of size 8 at addr ffff88811e7fa170 by task ioctl_file/237 [   26.553805] [   26.554227] CPU: 3 UID: 0 PID: 237 Comm: ioctl_file Not tainted 7.2.0-rc1-00004-g6852a10e32d4 #921 PREEMPT(lazy) [   26.554236] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [   26.554241] Call Trace: [   26.554245]  <TASK> [   26.554248]  dump_stack_lvl+0x68/0xa0 [   26.554266]  print_report+0x10d/0x5d0 [   26.554276]  ? __virt_addr_valid+0x21d/0x3f0 [   26.554287]  ? cdev_put.part.0+0x3d/0x40 [   26.554292]  kasan_report+0x96/0xd0 [   26.554300]  ? cdev_put.part.0+0x3d/0x40 [   26.554307]  cdev_put.part.0+0x3d/0x40 [   26.554313]  __fput+0x7bc/0xa70 [   26.554322]  fput_close_sync+0xd8/0x190 [   26.554328]  ? __pfx_fput_close_sync+0x10/0x10 [   26.554337]  __x64_sys_close+0x79/0xd0 [   26.554344]  do_syscall_64+0x117/0x6b0 [   26.554351]  entry_SYSCALL_64_after_hwframe+0x77/0x7f [   26.554358] RIP: 0033:0x7f938c067727 [   26.554364] Code: 48 89 fa 4c 89 df e8 28 ad 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5bf [   26.554369] RSP: 002b:00007fff49f05980 EFLAGS: 00000202 ORIG_RAX: 0000000000000003 [   26.554376] RAX: ffffffffffffffda RBX: 00007f938bfd7780 RCX: 00007f938c067727 [   26.554380] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 [   26.554383] RBP: 00007fff49f05a10 R08: 0000000000000000 R09: 0000000000000000 [   26.554386] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000 [   26.554389] R13: 00007fff49f05b40 R14: 00007f938c207000 R15: 000055c148471d78 [   26.554397]  </TASK> [   26.554399] [   26.575612] Allocated by task 100: [   26.575871]  kasan_save_stack+0x24/0x50 [   26.576157]  kasan_save_track+0x14/0x30 [   26.576418]  __kasan_kmalloc+0x7f/0x90 [   26.576668]  __kmalloc_noprof+0x281/0x6c0 [   26.576938]  nvme_alloc_ns+0x7f7/0x3170 [   26.577206]  nvme_scan_ns+0x508/0x880 [   26.577449]  async_run_entry_fn+0x8c/0x350 [   26.577723]  process_scheduled_works+0xb6f/0x1a00 [   26.578034]  worker_thread+0x4ad/0xb40 [   26.578283]  kthread+0x34f/0x450 [   26.578501]  ret_from_fork+0x563/0x800 [   26.578752]  ret_from_fork_asm+0x1a/0x30 [   26.579012] [   26.579124] Freed by task 237: [   26.579335]  kasan_save_stack+0x24/0x50 [   26.579596]  kasan_save_track+0x14/0x30 [   26.579855]  kasan_save_free_info+0x3a/0x60 [   26.580131]  __kasan_slab_free+0x43/0x70 [   26.580388]  kfree+0x321/0x500 [   26.580591]  nvme_ns_head_chr_release+0x39/0x50 [   26.580883]  __fput+0x352/0xa70 [   26.581095]  fput_close_sync+0xd8/0x190 [   26.581350]  __x64_sys_close+0x79/0xd0 [   26.581595]  do_syscall_64+0x117/0x6b0 [   26.581842]  entry_SYSCAL ---truncated---

CVE-2026-98816:

        In the Linux kernel, the following vulnerability has been resolved:  bpf: Fix overflow of jump offset in constant blinding  bpf_jit_blind_insn() rewrites 'if rX op imm goto off' into:    AX = imm ^ rnd   AX ^= rnd   if rX op AX goto off  and subtracts 2 from off when the jump is backward. off is s16, so -32767 and -32768 wrap and the jump goes 32767 insns forward, past the end of the prog. The jump is inside the patch, hence bpf_adj_branches() doesn't check it. The kernel crashes when such prog runs with bpf_jit_harden=2.  Return -ERANGE in such case. bpf_jit_blind_constants() fails the same way when blinding of other insns moves a jump out of range.

CVE-2026-98819:

        In the Linux kernel, the following vulnerability has been resolved:  Bluetooth: btintel: validate DDC record lengths  Parse DDC record lengths in unsigned storage so 0xFF does not wrap. Reject records smaller than the mandatory three-byte header, records exceeding U8_MAX, and records exceeding remaining firmware bytes before issuing Intel_Write_DDC.  This issue was reported by Claude Mythos.

CVE-2026-98820:

        In the Linux kernel, the following vulnerability has been resolved:  blk-mq: set RQF_USE_SCHED when the operation is known  The cached requests are allocated for one operation but can be handed out for another. A passthrough command has RQF_USE_SCHED cleared, so using those flags for a subsequent read/write bio will insert it into the scheduler without ->prepare_request() and frees it without ->finish_request(). For kyber, this leaks the domain token acquired at dispatch and stalls the queue.  Don't set RQF_USE_SCHED based on the first operation the batch happened to be allocated for. Instead, set it after the request is claimed by an operation. Introduce a helper function, blk_mq_rq_late_init() for this, and absorb blk_mq_rq_time_init() since the two run together.

CVE-2026-98822:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: mac80211: prevent AP VLAN tx from other interfaces  Since the station lookup was factored out of ieee80211_build_hdr(), ieee80211_lookup_ra_sta() uses sta_info_get_bss() for all AP and AP VLAN frames, not only for control port frames. A unicast frame sent on one interface thus matches a station of a different VLAN of the same BSS and is transmitted to it.  Only match stations of the interface the frame is sent on, except for control port frames, since those may be sent for VLAN stations directly on the BSS interface.

CVE-2026-98823:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: cfg80211: preserve hidden-group beacon IE ownership  A hidden-group probe-response entry borrows its beacon IEs from the group's beacon entry. cfg80211_update_assoc_bss_entry() can pass such an entry to cfg80211_update_known_bss() when merging scan entries after a channel switch.  Copying the borrowed beacon_ies into the associated entry gives the same allocation two owners. Releasing the group's beacon entry can then leave the associated entry pointing to freed IEs, which are freed again when that entry is released.  Skip beacon IE replacement when the source entry belongs to a hidden group. Preserve probe-response processing, the subsequent metadata updates, and the existing rejection path for conflicting hidden beacon updates.

CVE-2026-98824:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: mac80211: validate TX status rate metadata  minstrel_ht_tx_status() converts the HT/VHT rate reported in a TX status into a group and rate index and uses those to index the minstrel_ht rate tables.  The existing validation only checked that an entry was present and had tries recorded; it did not check that the reported MCS, spatial stream count and bandwidth are representable by the tables, so malformed metadata passed to minstrel_ht_get_stats() or minstrel_ht_ri_get_stats() could be used as an out-of-bounds index.  Validate the rate metadata in the common TX status path instead of only in minstrel_ht, since the values are used by more than rate control. The legacy ieee80211_tx_rate array and the rate_info based entries are sanitized in ieee80211_tx_status_ext() and ieee80211_tx_rate_update() before any consumer runs: an entry that does not describe a valid rate for its encoding is dropped.  minstrel_ht keeps the checks that depend on its own tables, i.e. the supported number of spatial streams, the MCS group size and the supported bandwidths.  This does not take away the driver's responsibility to report sane values, it only prevents a single bad report from corrupting mac80211 state.  No WARN_ON() is added: with panic_on_warn a driver bug would otherwise turn into a denial of service.

CVE-2026-98825:

        In the Linux kernel, the following vulnerability has been resolved:  rtc: mpfs: fix unchecked devm_clk_get() error pointer in probe()  devm_clk_get(&pdev->dev, "rtcref")'s return value was passed straight into clk_get_rate() without checking it for an error first, unlike the "rtc" clock a few lines above which is correctly checked with IS_ERR(). clk_get_rate() only guards against a NULL clk, not an error pointer:  	if (!clk) 		return 0; 	... 	rate = clk_core_get_rate_recalc(clk->core);  so if devm_clk_get() ever returns an error pointer here (for example ERR_PTR(-EPROBE_DEFER), which is the normal, expected outcome if the clkcfg clock-provider this RTC depends on has not registered its clocks yet by the time this driver probes), clk_get_rate() dereferences that error pointer instead of returning 0, crashing instead of letting probe defer.  Capture the clock in the existing 'clk' local and check it with IS_ERR() before calling clk_get_rate(), matching the handling already used for the "rtc" clock in this same function.

CVE-2026-98826:

        In the Linux kernel, the following vulnerability has been resolved:  rtc: ac100: Fix clock provider use-after-free on probe failure  ac100_rtc_register_clks() registers the RTC-32k clock with clk_hw_register_fixed_rate() and the clock provider with of_clk_add_hw_provider(). Neither is device managed, and both are released only from ac100_rtc_remove(). The driver core does not call remove() when probe() fails: really_probe() reaches probe_failed below the device_remove() call and goes straight to releasing the device's managed resources.  ac100_rtc_probe() ends with  	return devm_rtc_register_device(chip->rtc);  so if that fails after the clocks have been registered, the provider is left on the global of_clk_providers list holding chip->clk_data, which was allocated with devm_kzalloc() and is freed while probe() unwinds. A later lookup on this device tree node then reads freed memory in of_clk_hw_onecell_get(). Consumers that do exactly that exist in tree: the wifi power sequence nodes on sun8i-a83t-bananapi-m3 and sun8i-a83t-cubietruck-plus take <&ac100_rtc 1>, and the sun9i-a80 boards route osc32k through <&ac100_rtc 0>. The window is narrow, as devm_rtc_register_device() can only fail with -ENOMEM here, but the provider is left dangling whenever it does.  The RTC-32k clock is leaked on the same path. Since clk_core_lookup() searches a global list that is not scoped per device, __clk_register() rejects the duplicate name with -EEXIST, so the leak also makes a later probe of the same device fail.  The error path that returns -EINVAL when the ADDA 4M parent clock cannot be found leaks the RTC-32k clock in the same way. No provider has been registered at that point, so that one is a leak rather than a use-after-free.  Register both with devm_clk_hw_register_fixed_rate() and devm_of_clk_add_hw_provider() so that they are released whenever the device goes away, on a failed probe as well as on unbind. Devres releases in reverse order of acquisition, so the provider is removed before chip->clk_data is freed, and the clkout children are now unregistered before their parent rather than after it. ac100_rtc_unregister_clks() and the remove callback then have nothing left to do and are removed.

CVE-2026-98827:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: ath9k_htc: bound TX aggregation to MAX_TX_BUF_SIZE  __hif_usb_tx() dequeues up to MAX_TX_AGGR_NUM (20) frames into a single tx_buf of MAX_TX_BUF_SIZE (32768) bytes, limiting the batch by record count but never by cumulative byte length.  With large frames (MTU 2304), 20 aggregated frames of 2292 bytes each exceed the allocation (20 * 2296 = 45920 bytes), so the memcpy() in the loop writes up to 13152 bytes past tx_buf->buf before usb_submit_urb().  Peek the queue head and stop before copying any record that would cross MAX_TX_BUF_SIZE, then dispatch the current batch. Leftover skbs remain queued and are drained on the next URB completion.  The byte bound changes the loop's exit semantics: it can now exit before i == tx_skb_cnt - 1. Stock only finalized tx_buf->len on that last index (len += offset), so an early break would submit a URB holding only the last record's length while every dequeued skb is freed on completion, silently dropping frames. Make tx_buf->len a running total and advance tx_buf->offset per record instead; the stride round_up(nskb->len + 4, 4) is identical to the stock stride when the loop runs to completion.  Tested on hardware with an MTU 2304 flood: the loop stops at record 15 (len = 32144, offset = 32144, within 32768), no oversized URB is submitted, and MTU 1500 pings pass 20/20.

CVE-2026-98828:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: ath9k: reject short WMI command responses  ath9k_wmi_rsp_callback() removes the validated WMI header and copies the number of bytes expected by the waiting command into its response buffer. A device response shorter than that expectation can therefore be read beyond the skb payload.  Record -EMSGSIZE for a short response, complete the waiter, and return the stored status from the command path. This also prevents callers from consuming stale response bytes as a successful reply.

CVE-2026-98829:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: mac80211: drop oversized fragments to avoid extra_len overflow  In ieee80211_rx_h_defragment(), fragment payloads are accumulated into entry->extra_len as subsequent fragments arrive:          entry->extra_len += rx->skb->len;  When the final fragment arrives, the head fragment is dequeued, and pskb_expand_head() is called with entry->extra_len to ensure sufficient tailroom for all queued fragments before copying:          if (skb_tailroom(rx->skb) < entry->extra_len) {                 if (unlikely(pskb_expand_head(rx->skb, 0, entry->extra_len,                                               GFP_ATOMIC))) {                         ...                 }         }         while ((skb = __skb_dequeue(&entry->skb_list))) {                 skb_put_data(rx->skb, skb->data, skb->len);                 dev_kfree_skb(skb);         }  In commit 69f132236827 ("mac80211: shrink struct ieee80211_fragment_entry"), entry->extra_len was narrowed from unsigned int to u16 in order to reduce structure memory footprint.  However, an IEEE 802.11 frame sequence can contain up to 16 fragments (frag numbers 0..15). If a sequence of large fragments arrives (e.g. from a malicious peer or rogue AP), the sum of fragment lengths can exceed 65535 bytes (for example, 15 fragments of 4400 bytes total 66000 bytes). Because extra_len is a u16, this addition overflows and wraps around modulo 65536 (e.g. 66000 wraps to 464).  Consequently, pskb_expand_head() allocates only the truncated amount of tailroom (or is skipped entirely if the head fragment already has >= 464 bytes of tailroom). When skb_put_data() subsequently iterates through the queued skb list, it appends the full payload into the undersized buffer, causing skb_put() to trigger skb_over_panic() and crash the kernel in softirq context.  A legitimate MSDU in IEEE 802.11 is at most 2304 bytes (or up to 7935/11454 bytes for A-MSDU, which is not fragmented), well below U16_MAX.  Fix this without increasing the size of struct ieee80211_fragment_entry by checking whether adding the incoming fragment length would exceed U16_MAX. If so, purge the queued fragments and drop the frame.  [assign a separate drop reason]

CVE-2026-98830:

        In the Linux kernel, the following vulnerability has been resolved:  wifi: wfx: validate MIB read length before copying to caller  wfx_hif_read_mib() copies reply->length bytes from the firmware response into the caller-provided buffer without checking that reply->length does not exceed val_len. A firmware response with a length field larger than expected overruns the caller buffer and reads past the end of the reply allocation.  Replace the dead -ENOMEM check with an active validation that reply->length fits within val_len before the memcpy.

CVE-2026-98831:

        In the Linux kernel, the following vulnerability has been resolved:  of/overlay: don't leak fragment references when changeset init fails  init_overlay_changeset() stores the number of initialized fragments in ovcs->count only on full success. When find_target() or the __symbols__ lookup fails partway through, the target and overlay references taken for the fragments initialized so far are never dropped: free_overlay_changeset() bounds its cleanup loop by ovcs->count, which is still 0.  Store the running count on the error path so free_overlay_changeset() puts whatever was set up. The store is guarded by ovcs->fragments because on the allocation-failure path cnt still holds the counting pass total while there is no fragments array; everywhere else cnt only counts fully-initialized fragments.

CVE-2026-98833:

        In the Linux kernel, the following vulnerability has been resolved:  mtd: core: call _get_device() with the master MTD  __get_mtd_device() calls the master's _get_device() callback with mtd, which may be a partition. __put_mtd_device() passes the master.  This breaks gluebi partitions because gluebi_get_device() uses container_of() and therefore requires the master MTD. Pass the master to _get_device(), matching _put_device().

CVE-2026-98834:

        In the Linux kernel, the following vulnerability has been resolved:  mtd: core: avoid double-free of OTP NVMEM device  If factory OTP setup fails after the user OTP NVMEM device has been registered, mtd_otp_nvmem_add() unregisters the user device but leaves mtd->otp_user_nvmem set. On an error, the caller unregisters it again. For -EOPNOTSUPP, registration continues and normal teardown unregisters it again.  Clear mtd->otp_user_nvmem after unregistering it.

CVE-2026-98836:

        In the Linux kernel, the following vulnerability has been resolved:  ALSA: line6: reject oversized playback packets  Each playback URB is handed a slice of out.buffer that is exactly LINE6_ISO_PACKETS * max_packet_size_out bytes, sized from the OUT endpoint, but the number of bytes written into that slice is never compared against it.  submit_audio_out_urb() takes the frame count from prev_fsize, which audio_in_callback() derived from the *IN* endpoint's received packet length, and rescales it with the playback frame size; when prev_fsize is still zero it synthesizes a length from the sample rate instead.  On a device declaring a large IN wMaxPacketSize and a small OUT wMaxPacketSize, the resulting memcpy(), or the memset() when the playback stream is idle, runs past its slice and, as the reproducer below shows, beyond the allocation.  usb_submit_urb() is not a backstop.  max_packet_size_out comes from usb_maxpacket(), which returns only the low 11 bits of wMaxPacketSize, while USB core validates a high-speed isochronous length against that base scaled by usb_endpoint_maxp_mult().  A length of up to three times the allocated slice is therefore accepted, and even a rejected URB is only rejected after the write.  Reject a packet that does not fit the slice the driver allocated for it. Clamping it instead would silently shorten the capture-derived rate feedback and desynchronize the two streams.    BUG: KASAN: slab-out-of-bounds in submit_audio_out_urb (sound/usb/line6/playback.c:229)   Write of size 1024 at addr ffff888100bbd400 by task kworker/1:2/5002   Workqueue: events line6_startup_work   Call Trace:    __asan_memcpy (mm/kasan/shadow.c:106)    submit_audio_out_urb (sound/usb/line6/playback.c:229)    line6_submit_audio_out_all_urbs (sound/usb/line6/playback.c:291)    line6_stream_start (sound/usb/line6/pcm.c:194)    line6_pcm_acquire (sound/usb/line6/pcm.c:337)    line6_startup_work (sound/usb/line6/driver.c:728)    process_one_work (kernel/workqueue.c:3396)    worker_thread (kernel/workqueue.c:3479 kernel/workqueue.c:3560)    kthread (kernel/kthread.c:436)    ret_from_fork (arch/x86/kernel/process.c:158)    ret_from_fork_asm (arch/x86/entry/entry_64.S:245)    The buggy address belongs to the object at ffff888100bbd400    which belongs to the cache kmalloc-256 of size 256   The buggy address is located 0 bytes inside of    allocated 256-byte region [ffff888100bbd400, ffff888100bbd500)

CVE-2026-98837:

        In the Linux kernel, the following vulnerability has been resolved:  ALSA: caiaq: unregister the input device when probe fails  setup_card() registers the input device, whose name and phys point into struct snd_usb_caiaqdev, and then goes on to snd_card_register() and snd_usb_caiaq_control_init(). If either fails, snd_probe() calls snd_card_free(), which frees the device state but leaves the input device registered: card_free() only clears the pointer, and the input device is unregistered from snd_disconnect() alone. Reading its "uevent" attribute afterwards dereferences freed memory:    BUG: KASAN: slab-use-after-free in string+0x4a9/0x4f0   Read of size 1 at addr ffff8880208f5043 by task caiaq/4967    add_uevent_var+0x183/0x3a0    input_dev_uevent+0x162/0x900    dev_uevent+0x2f1/0x870    uevent_show+0x1ca/0x3a0    ...  Unregister the input device on the probe error path, as snd_disconnect() does. snd_usb_caiaq_input_disconnect() is a no-op when no input device was registered.  Reproduced with a raw-gadget Audio Kontrol 1 and a temporary hack that makes snd_usb_caiaq_control_init() fail.

CVE-2026-98838:

        In the Linux kernel, the following vulnerability has been resolved:  vt: skip screen update for DEC alignment test on backgroup consoles  [BUG] Recently, we encountered a KASAN warning as follows:  BUG: KASAN: slab-out-of-bounds in fb_pad_aligned_buffer+0x11f/0x140 Read of size 1 at addr ff1100015fd9f6a4 by task tty_fbcon_oob/1239 CPU: 7 UID: 0 PID: 1239 Comm: tty_fbcon_oob Not tainted 7.3.0-rc1 #100 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 Call Trace:  <TASK>  ...  kasan_report+0xf0/0x120  fb_pad_aligned_buffer+0x11f/0x140  ccw_putcs+0x86c/0xa80  fbcon_putcs+0x338/0x410  do_update_region+0x21d/0x450  do_con_write+0x1e0e/0x4880  con_write+0x13/0x80  n_tty_write+0x374/0x1010  file_tty_write.isra.0+0x404/0x7a0  ...  reproduce: 1) open /dev/tty0, set a KDFONTOP ioctl with op.op = KD_FONT_OP_SET, op.width = 8 and op.height = 16 (visible VC1) 2) open /dev/tty1, set a KDFONTOP ioctl with op.op = KD_FONT_OP_SET, op.width = 28 and op.height = 24 (invisible VC2) 3) echo 3 > /sys/devices/virtual/graphics/fbcon/rotate_all 4) write EShash8(esc hash8) to tty1  [CAUSE] All VCs render to the framebuffer. setfont only modifies the target VC's font without resizing the framebuffer backing buffer (par->rotated.buf); the buffer is only resized for the visible VC (fbcon_do_set_font -> ... -> vc_do_resize -> update_screen). This relies on the con_should_update() check performed before every update_region().  However, the ESC # 8 path (do_con_trol -> do_update_region) omits the con_should_update() check. After changing the font size of an invisible VC, do_update_region() fills using the new font size against a buffer that was never resized, causing an out-of-bounds access.  [FIX] Only push the update when the console is visible and not blanked, add the con_should_update() check in the do_con_trol() like every other call site of do_update_region() (update_region(), invert_screen(), ...).

CVE-2026-98839:

        In the Linux kernel, the following vulnerability has been resolved:  vt: selection: Fix unsigned underflow and slab-out-of-bounds read in paste_selection()  In paste_selection(), the loop copies min_t(unsigned int, vc_sel.buf_len - pasted,tty->receive_room) bytes per iteration into tty_ldisc_receive_buf() and increments pasted += count.  Because the selection mutex (vc_sel.lock) is dropped inside the loop Whenever the line discipline buffer fills up and paste_selection() sleeps on tty->write_wait, a concurrent TIOCLINUX (TIOCL_SETSEL) ioctl can replace vc_sel.buffer with a shorter selection and reduce vc_sel.buf_len below pasted.  When paste_selection() resumes, vc_sel.buf_len - pasted underflows as an unsigned integer to a large positive value, causing tty_ldisc_receive_buf(ld, vc_sel.buffer + pasted, NULL, count) to read up to 4094 bytes out-of-bounds past the newly allocated vc_sel.buffer.  Fix this by terminating the loop when pasted >= vc_sel.buf_len.  Kernel stack trace (Linux 7.3.0-rc3):  ==================================================================  BUG: KASAN: slab-out-of-bounds in n_tty_receive_buf_common+0xa01/0x1650  Read of size 4094 at addr ffff888101c58010 by task kworker/u17:1/65  Workqueue: events_unbound flush_to_ldisc  Call Trace:   <TASK>   dump_stack_lvl+0x70/0xa0   print_report+0x153/0x4c6   kasan_report+0xf1/0x120   kasan_check_range+0x11c/0x200   __asan_memcpy+0x29/0x70   n_tty_receive_buf_common+0xa01/0x1650   tty_ldisc_receive_buf+0x66/0x110   tty_port_default_receive_buf+0x6b/0xb0   flush_to_ldisc+0x1b4/0x410   process_one_work+0x6ff/0x1110   worker_thread+0x4a8/0xb70   kthread+0x307/0x3e0   ret_from_fork+0x3ed/0x680   </TASK>  ==================================================================

CVE-2026-98840:

        In the Linux kernel, the following vulnerability has been resolved:  vc_screen: reload vc pointer before if (ret) in vcs_write() to avoid UAF  The reload of 'vc' added by commit 8fb9ea65c9d1 ("vc_screen: reload load of struct vc_data pointer in vcs_write() to avoid UAF") sits after the 'if (ret)' block, so the copy-failure break path exits the loop without reloading vc. If the vc was kfree()'d via vc_port_destruct during the unlocked copy_from_user() window, the post-loop 'if (written && vc) vcs_scr_updated(vc)' is reached with a stale non-NULL vc. The '&& vc' guard from commit a287620312dc ("vc_screen: fix null-ptr-deref in vcs_notifier() during concurrent vcs_write") only handles the NULL case, not this stale-non-NULL case; vcs_notifier() then reads param->vc->vc_num from freed memory:    BUG: KASAN: slab-use-after-free in vcs_notifier+0x7c/0xd0   Read of size 2 at addr ffff888007149190   Call Trace:    vcs_notifier+0x7c/0xd0    atomic_notifier_call_chain+0x70/0xa0    vcs_scr_updated+0x77/0xa0    vcs_write+0x71b/0x7e0   Allocated by task: vc_allocate -> con_install -> tty_open   Freed by task: kfree <- vt_ioctl (VT_DISALLOCATE -> vc_port_destruct)  Move the reload to immediately after console_lock(), before 'if (ret)', so every break path below passes a fresh vc to the post-loop vcs_scr_updated().

CVE-2026-98846:

        In the Linux kernel, the following vulnerability has been resolved:  sctp: check RCV_SHUTDOWN after the sendmsg connect wait  sctp_wait_for_connect() drops the socket lock while it sleeps. An out-of-the-blue ABORT can then be processed from the socket backlog and unlink the association. If a concurrent shutdown(fd, SHUT_RD) sets RCV_SHUTDOWN, the waiter breaks with err == 0 before checking asoc->base.dead. Its final sctp_association_put() can then free the association, leaving sctp_sendmsg_to_asoc() to continue with a dangling pointer.  Check RCV_SHUTDOWN along with the wait error in sctp_sendmsg_to_asoc() before using the association again. The check only accesses the socket, so it needs no additional association reference. Return the existing -ESRCH so that sctp_sendmsg() skips freeing a new association that may already have been destroyed.  Keep sctp_wait_for_connect() unchanged to preserve its behavior for the connect() caller.

CVE-2026-98847:

        In the Linux kernel, the following vulnerability has been resolved:  rtc: spear: initialize IRQ state before requesting alarm IRQ  devm_request_irq() enables the interrupt before it returns, so the handler may run while probe is still initializing the device. Initialize the MMIO address and spinlock before requesting the alarm IRQ.

CVE-2026-98850:

        In the Linux kernel, the following vulnerability has been resolved:  net/packet: prevent TX_RING byte count overflow  tpacket_snd() drains every SEND_REQUEST frame in a TX ring and adds each valid packet length to the signed int len_sum. Userspace can recycle completed frames concurrently, so a single blocking send call is not bounded by the ring size.  After enough successful transmissions len_sum wraps into the negative range. In particular, 65536 65535-byte frames followed by a 65007-byte frame produce 0xfffffdef, or -EIOCBQUEUED. sock_sendmsg_nosec() treats that as an impossible return and triggers a BUG. On systems configured to panic on oops, a CAP_NET_RAW holder can panic the host kernel.  Stop before the next frame would make the byte count exceed INT_MAX. The positive short count leaves that frame pending for a later send call.  A two-thread TPACKET_V2 reproducer triggered the BUG on an arm64 build of Linux 7.3-rc4. With this change, the same reproducer returned the expected positive short count without an oops.

CVE-2026-98851:

        In the Linux kernel, the following vulnerability has been resolved:  netfilter: nft_flow_offload: drop flowtable reference on init error path  nft_flow_offload_init() bumps the flowtable use count with nft_use_inc() before calling nf_ct_netns_get().  When the latter fails, the error is returned as-is and the reference is leaked.  The upper layers do not balance it either: nf_tables_newexpr() clears expr->ops when the expression init callback fails, so the nft_expr_more() iteration in nft_rule_expr_deactivate() and nf_tables_rule_destroy() stops right before the failed expression and its ->destroy callback, which would drop the reference, never runs.  Each failed rule addition therefore leaks one flowtable reference and the flowtable can no longer be removed: NFT_MSG_DELFLOWTABLE keeps reporting -EBUSY even though no rule references it.  Save the nf_ct_netns_get() return value and undo the nft_use_inc() when it fails, restoring the inc/dec pairing within nft_flow_offload_init() itself.

CVE-2026-98852:

        In the Linux kernel, the following vulnerability has been resolved:  net: extend IPv6 exthdr detection of tunneled packets  Commit c4336a07eb6b ("net: correctly handle tunneled traffic on IPV6_CSUM GSO fallback") split skb_gso_has_extension_hdr() into mutually exclusive branches on skb->encapsulation. This did not yet address all paths:  1. With skb->encapsulation set, the outer header is not checked. IPv6    tunnels such as ip6_gre and ip6_tunnel add an outer Destination    Options header by default (encap_limit). Their GSO packets skip    software GSO, then skb_csum_hwoffload_help() sees the outer extension    header and calls skb_checksum_help() on the GSO skb, which warns and    drops it.  2. Tunnels over IPv6 without an outer transport header, such as    ip6_tunnel, leave skb->transport_header at the inner transport    header. skb_network_header_len() then spans the outer IPv6, tunnel    and inner IP headers, a false positive.  3. UDP tunnels without an inner network header, such as SCTP-in-UDP or    PSP, have no inner IPv6 header to check. Decide on the outer header    alone.  4. Directly dereferencing inner_ip_hdr(skb)->version without    skb_header_pointer() is unsafe.  Instead, check ipv6_ext_hdr(nexthdr) on the outer IPv6 header and, if set, on the inner IPv6 header. Read the headers with skb_header_pointer(). Keep the skb_network_header_len() check when !skb->encapsulation to also catch encapsulated packets without skb->encapsulation (e.g., virtio).  Use the same helper in skb_csum_hwoffload_help(). Its open coded test has the false positive of (2) and ignores the inner header.  Background: checksum offload of tunneled packets invariants:  Non-GSO skb: - If the inner packet is CHECKSUM_PARTIAL, Local Checksum Offload computes   the outer checksum in software and the device offloads only the inner L4   checksum. - If the inner packet is CHECKSUM_NONE (e.g., SCTP-in-UDP, ESP-in-UDP,   Remote Checksum Offload), the device offloads the outer UDP or GRE   checksum instead.  GSO skb: - A device with NETIF_F_GSO_UDP_TUNNEL_CSUM or NETIF_F_GSO_GRE_CSUM   computes both inner and outer checksums per segment.   The outer checksum is seeded with only the pseudo-header checksum.  A NETIF_F_IPV6_CSUM device must parse through the outer headers to reach the inner ones.

CVE-2026-98853:

        In the Linux kernel, the following vulnerability has been resolved:  net: gso: limit recursive IP-in-IP segmentation  IP-in-IP GSO can re-enter inet_gso_segment() or ipv6_gso_segment() for each nested IP header. encap_level tracks header bytes, not callback depth, so a deep chain can exhaust the kernel stack. Making inet_gso_segment() stackable introduced unbounded IPv4 nesting; IPIP GSO/TSO later made the path reachable. The IPv6 stackable path was introduced separately and uses the same guard.  Count IPv4 and IPv6 GSO handler entries in skb_gso_cb, initialized once per top-level GSO operation and preserved across GRE/UDP context changes. Use the existing IP_TUNNEL_RECURSION_LIMIT for both handlers. The first five entries pass, and the sixth returns -EINVAL before dispatching another GSO callback.

CVE-2026-98854:

        In the Linux kernel, the following vulnerability has been resolved:  of/overlay: only treat a positive changeset id as registered  of_overlay_fdt_apply() stores the idr_alloc() return value in ovcs->id before checking it. On failure the stored id is negative, free_overlay_changeset()'s "if (ovcs->id)" check passes, idr_remove() is called with a negative id and list_del() runs on ovcs->ovcs_list, which is not initialized until after the id allocation. An allocation failure at that point dereferences NULL.  Make free_overlay_changeset() treat only a strict-positive id as registered. The rest of the function already copes with a partially-initialized ovcs, so the error path stays a plain goto err_free_ovcs.

CVE-2026-98855:

        In the Linux kernel, the following vulnerability has been resolved:  of/overlay: put property on deadprops only after changeset add succeeds  add_changeset_property() links a new property of a not-yet-live target node into the node's deadprops list before handing it to of_changeset_add_property(). If that fails, the error path frees the property but leaves the freed pointer linked in deadprops, and of_node_release() frees it a second time when the aborted overlay's node is released.  Record the changeset entry first and link the property into deadprops only on success. of_changeset_add_property() never looks at the node's property lists, so the order of the two steps is otherwise immaterial, and the error path frees a property that nothing references.

CVE-2026-98856:

        In the Linux kernel, the following vulnerability has been resolved:  kprobes: Skip disarmed probes when checking optkprobe overlap  On x86, an optkprobe at A replaces five bytes with a jump. If a disabled probe B is at A+2, get_optimized_kprobe() stops at B when arming a new probe C at A+4. It leaves A optimized:                A    A+1  A+2  A+3  A+4   A's jump  | e9 | d0 | d1 | d2 | d3 |   after C   | e9 | d0 | d1 | d2 | cc |  The INT3 for C overwrites the last byte of A's jump displacement, so execution can jump to the wrong address. B can have prepared optinsns while disarmed, but has no jump to unoptimize.  Continue past disarmed and unprepared probes to find the active optimized probe before arming a probe in its jump.

CVE-2026-98857:

        In the Linux kernel, the following vulnerability has been resolved:  ipvs: bound LBLCR and LBLC cache growth  ip_vs_lblcr_new() and ip_vs_lblc_new() create cache entries for every previously unseen destination address. The table max_size only tells the periodic collector to reclaim entries after the cache has already exceeded the limit. It does not reclaim entries that the attacker continues to use.  Reject new cache entries once either table reaches max_size * 3 / 2. The extra headroom lets the periodic collector catch up while the existing scheduler fallback continues to use the selected destination when cache creation fails. New traffic therefore stays serviceable without growing the tables further.

CVE-2026-98859:

        In the Linux kernel, the following vulnerability has been resolved:  HID: multitouch: stop the release timer from being rearmed on remove  mt_remove() quiesces the sticky-finger timer before stopping the hardware:      timer_delete_sync(&td->release_timer);      sysfs_remove_group(&hdev->dev.kobj, &mt_attribute_group);     hid_hw_stop(hdev);  timer_delete_sync() waits for a running callback and dequeues the timer, but it does not stop the timer from being armed again. The transport is still delivering reports at that point, and the report path rearms it:      if (app->quirks & MT_QUIRK_STICKY_FINGERS) {         if (td->mt_io_flags & MT_IO_SLOTS_MASK)             mod_timer(&td->release_timer,                       jiffies + msecs_to_jiffies(100));  A report that arrives after timer_delete_sync() has returned therefore leaves the timer queued. td is allocated with devm_kzalloc() against hdev->dev, so it is freed when the driver is unbound, after mt_remove() returns. When the timer fires afterwards, mt_expired_timeout() dereferences the freed td:      struct mt_device *td = timer_container_of(td, t, release_timer);     struct hid_device *hdev = td->hdev;      if (test_and_set_bit_lock(MT_IO_FLAGS_RUNNING, &td->mt_io_flags))  Simply moving the teardown after hid_hw_stop() does not fix this on its own, because mt_expired_timeout() calls mt_release_contacts(), which walks hdev->inputs; the timer still has to be quiesced before hid_hw_stop() tears the input devices down.  Use timer_shutdown_sync() instead, which additionally makes any later mod_timer() a no-op, so neither ordering constraint has to be traded off against the other. This is the final-teardown pattern the function was introduced for, and hid-wiimote already uses it for the same reason.

CVE-2026-98862:

        In the Linux kernel, the following vulnerability has been resolved:  audit: fix exe mark UAF in kill_rules()  kill_rules() removes mixed AUDIT_DIR and AUDIT_EXE rules when an audit tree is pruned. It drops entry->rule.exe before removing the rule from the RCU-visible filter lists.  After a rule has been installed with AUDIT_ADD_RULE, which requires CAP_AUDIT_CONTROL, removing the watched directory can race with another task that is still evaluating the rule. In that case, fsnotify can free the executable mark before the reader reaches audit_mark_compare(), causing a use-after-free.  KASAN reports:      BUG: KASAN: slab-use-after-free in audit_mark_compare+0x8d/0xa0  Unlink the published rules from the RCU-visible lists and retain them on tree->rules for cleanup. If any rule has an executable mark, wait for a single RCU grace period before removing the marks and scheduling the entries for freeing. Otherwise, call_rcu() already provides the required deferred freeing without a synchronous wait.

CVE-2026-98863:

        In the Linux kernel, the following vulnerability has been resolved:  KVM: x86: Re-pend GET_NESTED_STATE_PAGES if getting said pages fails  Re-pend GET_NESTED_STATE_PAGES before exiting to userspace if getting the nested pages fails in the KVM_RUN path.  If userspace re-runs the vCPU, and vmcs02 holds valid PFNs from the *previous* run of L2, then KVM could re-enter L2 with stale, unpinned PFNs mapped into e.g. the vAPIC page.  Note, both SVM and VMX (as of commit 11722439fb20 ("KVM: nVMX: Ensure KVM_REQ_GET_NESTED_STATE_PAGES is cleared on VM-Exit") ensure the request is cleared on VM-Exit (including the "forced" case), i.e. there is no risk of double-mapping due to emulated VMLAUNCH/VMRESUME/VMRUN *and* the request trying to map the nested pages.

CVE-2026-100072:

        In the Linux kernel, the following vulnerability has been resolved:  ACPI: platform: Use acpi_bus_get_primary_device()  The acpi_get_first_physical_node() usage in acpi_platform_fill_resource() and acpi_create_platform_device() is generally unsafe because in theory the device returned by it may be freed at any time [1].  It is also inefficient because acpi_get_first_physical_node() is called multiple times for the same argument which can be avoided.  Address these issues by using acpi_bus_get_primary_device() instead of acpi_get_first_physical_node() and adjusting the code to call it just once at the beginning of and acpi_create_platform_device() and drop the device reference acquired by it upon the return from that function.

CVE-2026-100076:

        In the Linux kernel, the following vulnerability has been resolved:  staging: rtl8723bs: fix xmit_frame/xmit_buf leaks on mgnt-frame error paths  issue_beacon(), issue_probersp() and issue_asocrsp() obtain a management xmit_frame together with its xmit_buf from the driver's fixed-size management-TX pools via alloc_mgtxmitframe(). On the normal path the frame is handed to dump_mgntframe(), which transfers ownership and eventually returns both objects to their pools (the frame and, for beacons, the buf in rtl8723bs_mgnt_xmit(); other bufs via the pending-xmitbuf/TX-completion path).  Several error/edge paths return early after a successful alloc_mgtxmitframe() but before dump_mgntframe(), so ownership is never transferred and neither object is freed:    - issue_beacon(): beacon larger than 512 bytes   - issue_probersp(): cur_network->ie_length > MAX_IE_SZ   - issue_probersp(): kzalloc() of the SSID scratch buffer fails   - issue_asocrsp(): pkt_type is neither ASSOCRSP nor REASSOCRSP  Because alloc_mgtxmitframe() removes the frame and buf from their free lists (list_del_init) without placing them on any pending list, an orphaned pair is on no list and referenced by nobody, so it is only reclaimed at driver teardown. Repeated hits progressively exhaust the management-TX pools until alloc_mgtxmitframe() returns NULL and the interface can no longer send beacons or probe/assoc responses.  Free the frame and buffer on these paths, matching the existing correct error handling in issue_assocreq().

CVE-2026-100077:

        In the Linux kernel, the following vulnerability has been resolved:  drm/msm: Recover HW before retire hung submit  During recovery, it is not safe to retire the hung submit before we recover the GPU. Retiring the submit triggers BO free and that can result in GPU pagefaults since the GPU may be actively accessing those BOs.  To fix this, retire the submits after gpu recovery is complete in recover_worker().  Patchwork: https://patchwork.freedesktop.org/patch/730655/

5 issues postponed or untriaged:

CVE-2019-15213:

            (postponed; to be fixed through a stable update)

        An issue was discovered in the Linux kernel before 5.2.3. There is a use-after-free caused by a malicious USB device in the drivers/media/usb/dvb-usb/dvb-usb-init.c driver.

CVE-2019-16089:

            (postponed; to be fixed through a stable update)

        An issue was discovered in the Linux kernel through 5.2.13. nbd_genl_status in drivers/block/nbd.c does not check the nla_nest_start_noflag return value.

CVE-2019-19449:

            (postponed; to be fixed through a stable update)

        In the Linux kernel 5.0.21, mounting a crafted f2fs filesystem image can lead to slab-out-of-bounds read access in f2fs_build_segment_manager in fs/f2fs/segment.c, related to init_min_max_mtime in fs/f2fs/segment.c (because the second argument to get_seg_entry is not validated).

CVE-2019-19814:

            (needs triaging)

        In the Linux kernel 5.0.21, mounting a crafted f2fs filesystem image can cause __remove_dirty_segment slab-out-of-bounds write access because an array is bounded by the number of dirty types (8) but the array index can exceed this.

CVE-2019-20794:

            (postponed; to be fixed through a stable update)

        An issue was discovered in the Linux kernel 4.18 through 5.6.11 when unprivileged user namespaces are allowed. A user can create their own PID namespace, and mount a FUSE filesystem. Upon interaction with this FUSE filesystem, if the userspace component is terminated via a kill of the PID namespace's pid 1, it will result in a hung task, and resources being permanently locked up until system reboot. This can result in resource exhaustion.

11 ignored issues:

CVE-2013-7445:

        The Direct Rendering Manager (DRM) subsystem in the Linux kernel through 4.x mishandles requests for Graphics Execution Manager (GEM) objects, which allows context-dependent attackers to cause a denial of service (memory consumption) via an application that processes graphics data, as demonstrated by JavaScript code that creates many CANVAS elements for rendering by Chrome or Firefox.

CVE-2018-12928:

        In the Linux kernel 4.15.0, a NULL pointer dereference was discovered in hfs_ext_read_extent in hfs.ko. This can occur during a mount of a crafted hfs filesystem.

CVE-2020-14304:

        A memory disclosure flaw was found in the Linux kernel's ethernet drivers, in the way it read data from the EEPROM of the device. This flaw allows a local user to read uninitialized values from the kernel memory. The highest threat from this vulnerability is to confidentiality.

CVE-2025-71188:

        In the Linux kernel, the following vulnerability has been resolved:  dmaengine: lpc18xx-dmamux: fix device leak on route allocation  Make sure to drop the reference taken when looking up the DMA mux platform device during route allocation.  Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference.

CVE-2026-45993:

        In the Linux kernel, the following vulnerability has been resolved:  LoongArch: Add spectre boundry for syscall dispatch table  The LoongArch syscall number is directly controlled by userspace, but does not have a array_index_nospec() boundry to prevent access past the syscall function pointer tables.

CVE-2026-46156:

        In the Linux kernel, the following vulnerability has been resolved:  LoongArch: Fix potential ADE in loongson_gpu_fixup_dma_hang()  The switch case in loongson_gpu_fixup_dma_hang() may not DC2 or DC3, and readl(crtc_reg) will access with random address, because the "device" is from "base+PCI_DEVICE_ID", "base" is from "pdev->devfn+1". This is wrong when my platform inserts a discrete GPU:  lspci -tv -[0000:00]-+-00.0  Loongson Technology LLC Hyper Transport Bridge Controller ...            +-06.0  Loongson Technology LLC LG100 GPU            +-06.2  Loongson Technology LLC Device 7a37 ...  Add a default switch case to fix the panic as below:   Kernel ade access[#1]:  CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.6.136-loong64-desktop-hwe+ #4  pc 90000000017e5534 ra 90000000017e54c0 tp 90000001002f8000 sp 90000001002fb6c0  a0 80000efe00003100 a1 0000000000003100 a2 0000000000000000 a3 0000000000000002  a4 90000001002fb6b4 a5 900000087cdb58fd a6 90000000027af000 a7 0000000000000001  t0 00000000000085b9 t1 000000000000ffff t2 0000000000000000 t3 0000000000000000  t4 fffffffffffffffd t5 00000000fffb6d9c t6 0000000000083b00 t7 00000000000070c0  t8 900000087cdb4d94 u0 900000087cdb58fd s9 90000001002fb826 s0 90000000031c12c8  s1 7fffffffffffff00 s2 90000000031c12d0 s3 0000000000002710 s4 0000000000000000  s5 0000000000000000 s6 9000000100053000 s7 7fffffffffffff00 s8 90000000030d4000     ra: 90000000017e54c0 loongson_gpu_fixup_dma_hang+0x40/0x210    ERA: 90000000017e5534 loongson_gpu_fixup_dma_hang+0xb4/0x210   CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)   PRMD: 00000004 (PPLV0 +PIE -PWE)   EUEN: 00000000 (-FPE -SXE -ASXE -BTE)   ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)  ESTAT: 00480000 [ADEM] (IS= ECode=8 EsubCode=1)   BADV: 7fffffffffffff00   PRID: 0014d000 (Loongson-64bit, Loongson-3A6000-HV)  Modules linked in:  Process swapper/0 (pid: 1, threadinfo=(____ptrval____), task=(____ptrval____))  Stack : 0000000000000006 90000001002fb778 90000001002fb704 0000000000000007          0000000016a65700 90000000017e5690 000000000000ffff ffffffffffffffff          900000000209f7c0 9000000100053000 900000000209f7a8 9000000000eebc08          0000000000000000 0000000000000000 0000000000000006 90000001002fb778          90000001000530b8 90000000027af000 0000000000000000 9000000100054000          9000000100053000 9000000000ebb70c 9000000100004c00 9000000004000001          90000001002fb7e4 bae765461f31cb12 0000000000000000 0000000000000000          0000000000000006 90000000027af000 0000000000000030 90000000027af000          900000087cd6f800 9000000100053000 0000000000000000 9000000000ebc560          7a2500147cdaf720 bae765461f31cb12 0000000000000001 0000000000000030          ...  Call Trace:  [<90000000017e5534>] loongson_gpu_fixup_dma_hang+0xb4/0x210  [<9000000000eebc08>] pci_fixup_device+0x108/0x280  [<9000000000ebb70c>] pci_setup_device+0x24c/0x690  [<9000000000ebc560>] pci_scan_single_device+0xe0/0x140  [<9000000000ebc684>] pci_scan_slot+0xc4/0x280  [<9000000000ebdd00>] pci_scan_child_bus_extend+0x60/0x3f0  [<9000000000f5bc94>] acpi_pci_root_create+0x2b4/0x420  [<90000000017e5e74>] pci_acpi_scan_root+0x2d4/0x440  [<9000000000f5b02c>] acpi_pci_root_add+0x21c/0x3a0  [<9000000000f4ee54>] acpi_bus_attach+0x1a4/0x3c0  [<90000000010e200c>] device_for_each_child+0x6c/0xe0  [<9000000000f4bbf4>] acpi_dev_for_each_child+0x44/0x70  [<9000000000f4ef40>] acpi_bus_attach+0x290/0x3c0  [<90000000010e200c>] device_for_each_child+0x6c/0xe0  [<9000000000f4bbf4>] acpi_dev_for_each_child+0x44/0x70  [<9000000000f4ef40>] acpi_bus_attach+0x290/0x3c0  [<9000000000f5211c>] acpi_bus_scan+0x6c/0x280  [<900000000189c028>] acpi_scan_init+0x194/0x310  [<900000000189bc6c>] acpi_init+0xcc/0x140  [<9000000000220cdc>] do_one_initcall+0x4c/0x310  [<90000000018618fc>] kernel_init_freeable+0x258/0x2d4  [<900000000184326c>] kernel_init+0x28/0x13c  [<9000000000222008>] ret_from_kernel_thread+0xc/0xa4

CVE-2026-46219:

        In the Linux kernel, the following vulnerability has been resolved:  spi: mpc52xx: fix use-after-free on unbind  The state machine work is scheduled by the interrupt handler and therefore needs to be cancelled after disabling interrupts to avoid a potential use-after-free.

CVE-2026-46293:

        In the Linux kernel, the following vulnerability has been resolved:  clk: microchip: mpfs-ccc: fix out of bounds access during output registration  UBSAN reported an out of bounds access during registration of the last two outputs. This out of bounds access occurs because space is only allocated in the hws array for two PLLs and the four output dividers that each has, but the defined IDs contain two DLLS and their two outputs each, which are not supported by the driver. The ID order is PLLs -> DLLs -> PLL outputs -> DLL outputs. Decrement the PLL output IDs by two while adding them to the array to avoid the problem.

CVE-2026-72198:

        In the Linux kernel, the following vulnerability has been resolved:  ntfs: reject non-resident records for resident-only attributes  The shared lookup-time attribute validator rejects non-resident $FILE_NAME and $VOLUME_NAME records because their formats require resident values and callers handle returned records as resident attributes. Other resident-only attribute types still pass through the generic non-resident mapping-pairs checks.  That leaves real resident/non-resident union confusion paths. Inode load looks up $STANDARD_INFORMATION and then reads data.resident.value_offset without checking a->non_resident. ntfs_inode_sync_standard_information() does the same when updating the standard information value. ntfs_write_volume_flags() also looks up $VOLUME_INFORMATION and reads data.resident.value_offset directly. $INDEX_ROOT callers in dir.c and index.c depend on the same lookup contract before consuming the resident index root value.  Reject non-resident records for all resident-only attribute types in the shared validator. Keep the existing $FILE_NAME and $VOLUME_NAME behavior, but factor it through a helper and extend it to $STANDARD_INFORMATION, $OBJECT_ID, $VOLUME_INFORMATION, $INDEX_ROOT, and $EA_INFORMATION. For $OBJECT_ID and $EA_INFORMATION this is contract hardening for resident-only formats; this patch only rejects the non-resident form and does not add new resident value validation for those types.

CVE-2026-72200:

        In the Linux kernel, the following vulnerability has been resolved:  ntfs: detect mapping-pairs LCN accumulator overflow  The NTFS mapping-pairs parser accumulates relative LCN deltas in a signed integer.  A corrupted attribute can drive that addition past the representable range.  One corrupt runlist shape sets the accumulated LCN to S64_MAX and then adds a delta of 1 in the next mapping-pairs entry.  Signed overflow is undefined and can turn an invalid runlist into a different set of physical clusters.  Check the LCN addition for overflow before storing the next run.

CVE-2026-72203:

        In the Linux kernel, the following vulnerability has been resolved:  ntfs: skip extent mft records in writeback to prevent deadlock  This patch fixes the ABBA deadlock between extent_lock and extent mrec_lock triggered by xfstests generic/113, that occurs since the commit 6994acf33bae ("ntfs: use base mft_no when looking up base inode for 		extent record").  Path A (inode writeback):   VFS writeback     -> ntfs_write_inode()       -> __ntfs_write_inode()         -> mutex_lock(&ni->extent_lock)         -> mutex_lock(&tni->mrec_lock)  Path B (MFT folio writeback):   VFS writeback of $MFT dirty folios     -> ntfs_mft_writepages()       -> ntfs_write_mft_block()         -> ntfs_may_write_mft_record()           -> holds one extent mrec_lock from a previous iteration           -> tries to acquire another base inode extent_lock  By removing all extent_lock and extent mrec_lock acquisition from the MFT folio writeback path, the ABBA lock ordering is eliminated:  Path A: __ntfs_write_inode(): extent_lock -> mrec_lock Path B (removed): ntfs_write_mft_block(): mrec_lock -> extent_lock  Path B is always redundant for extent records because:  1. mark_mft_record_dirty(ext_ni) does NOT dirty the MFT folio.    It only sets NInoDirty(ext_ni) and marks the base VFS inode dirty    via __mark_inode_dirty(I_DIRTY_DATASYNC), which triggers Path A.    Therefore, normal extent modifications never create a situation where    the MFT folio is dirty and Path B is not scheduled.  2. The MFT folio only gets dirtied via ntfs_mft_mark_dirty() inside    ntfs_mft_record_alloc(). But all identified callers in attrib.c    (ntfs_attr_add, ntfs_attr_record_move_away,    ntfs_attr_make_non_resident, ntfs_attr_record_resize) follow through    with mark_mft_record_dirty(), which triggers Path A to write the    complete record.  3. ntfs_evict_big_inode() calls ntfs_commit_inode() before freeing extent    inodes, ensuring all dirty extents are flushed via Path A before the    base inode leaves the icache.