ALINUX4-SA-2026:0333
摘要
Package updates are available for Alibaba Cloud Linux 4 that fix the following vulnerabilities: CVE-2023-52590: In the Linux kernel, the following vulnerability has been resolved:ocfs2: Avoid touching renamed directory if parent does not changeThe VFS will not be locking moved directory if its parent does notchange. Change ocfs2 rename code to avoid touching renamed directory ifits parent does not change as without locking that can corrupt thefilesystem. CVE-2024-39478: In the Linux kernel, the following vulnerability has been resolved:crypto: starfive - Do not free stack bufferRSA text data uses variable length buffer allocated in software stack.Calling kfree on it causes undefined behaviour in subsequent operations. CVE-2024-41082: In the Linux kernel, the following vulnerability has been resolved:nvme-fabrics: use reserved tag for reg read/write commandIn some scenarios, if too many commands are issued by nvme command inthe same time by user tasks, this may exhaust all tags of admin_q. Ifa 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 reservedtags. This maybe safe for nvmf:1. For the disable ctrl path, we will not issue connect command2. 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-58094: In the Linux kernel, the following vulnerability has been resolved:jfs: add check read-only before truncation in jfs_truncate_nolock()Added a check for "read-only" mode in the `jfs_truncate_nolock`function to avoid errors related to writing to a read-onlyfilesystem.Call stack:block_write_begin() { jfs_write_failed() { jfs_truncate() { jfs_truncate_nolock() { txEnd() { ... log = JFS_SBI(tblk->sb)->log; // (log == NULL)If the `isReadOnly(ip)` condition is triggered in`jfs_truncate_nolock`, the function execution will stop, and nofurther data modification will occur. Instead, the `xtTruncate`function will be called with the "COMMIT_WMAP" flag, preventingmodifications in "read-only" mode. CVE-2024-58095: In the Linux kernel, the following vulnerability has been resolved:jfs: add check read-only before txBeginAnon() callAdded a read-only check before calling `txBeginAnon` in `extAlloc`and `extRecord`. This prevents modification attempts on a read-onlymounted filesystem, avoiding potential errors or crashes.Call trace: txBeginAnon+0xac/0x154 extAlloc+0xe8/0xdec fs/jfs/jfs_extent.c:78 jfs_get_block+0x340/0xb98 fs/jfs/inode.c:248 __block_write_begin_int+0x580/0x166c fs/buffer.c:2128 __block_write_begin fs/buffer.c:2177 [inline] block_write_begin+0x98/0x11c fs/buffer.c:2236 jfs_write_begin+0x44/0x88 fs/jfs/inode.c:299 CVE-2025-21722: In the Linux kernel, the following vulnerability has been resolved:nilfs2: do not force clear folio if buffer is referencedPatch series "nilfs2: protect busy buffer heads from being force-cleared".This series fixes the buffer head state inconsistency issues reported bysyzbot that occurs when the filesystem is corrupted and falls back toread-only, and the associated buffer head use-after-free issue.This patch (of 2):Syzbot has reported that after nilfs2 detects filesystem corruption andfalls back to read-only, inconsistencies in the buffer state may occur.One of the inconsistencies is that when nilfs2 calls mark_buffer_dirty()to set a data or metadata buffer as dirty, but it detects that the bufferis not in the uptodate state: WARNING: CPU: 0 PID: 6049 at fs/buffer.c:1177 mark_buffer_dirty+0x2e5/0x520 fs/buffer.c:1177 ... Call Trace: <TASK> nilfs_palloc_commit_alloc_entry+0x4b/0x160 fs/nilfs2/alloc.c:598 nilfs_ifile_create_inode+0x1dd/0x3a0 fs/nilfs2/ifile.c:73 nilfs_new_inode+0x254/0x830 fs/nilfs2/inode.c:344 nilfs_mkdir+0x10d/0x340 fs/nilfs2/namei.c:218 vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257 do_mkdirat+0x264/0x3a0 fs/namei.c:4280 __do_sys_mkdirat fs/namei.c:4295 [inline] __se_sys_mkdirat fs/namei.c:4293 [inline] __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293 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/0x7fThe other is when nilfs_btree_propagate(), which propagates the dirtystate to the ancestor nodes of a b-tree that point to a dirty buffer,detects that the origin buffer is not dirty, even though it should be: WARNING: CPU: 0 PID: 5245 at fs/nilfs2/btree.c:2089 nilfs_btree_propagate+0xc79/0xdf0 fs/nilfs2/btree.c:2089 ... Call Trace: <TASK> nilfs_bmap_propagate+0x75/0x120 fs/nilfs2/bmap.c:345 nilfs_collect_file_data+0x4d/0xd0 fs/nilfs2/segment.c:587 nilfs_segctor_apply_buffers+0x184/0x340 fs/nilfs2/segment.c:1006 nilfs_segctor_scan_file+0x28c/0xa50 fs/nilfs2/segment.c:1045 nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1216 [inline] nilfs_segctor_collect fs/nilfs2/segment.c:1540 [inline] nilfs_segctor_do_construct+0x1c28/0x6b90 fs/nilfs2/segment.c:2115 nilfs_segctor_construct+0x181/0x6b0 fs/nilfs2/segment.c:2479 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2587 [inline] nilfs_segctor_thread+0x69e/0xe80 fs/nilfs2/segment.c:2701 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>Both of these issues are caused by the callbacks that handle thepage/folio write requests, forcibly clear various states, including theworking state of the buffers they hold, at unexpected times when theydetect read-only fallback.Fix these issues by checking if the buffer is referenced before clearingthe page/folio state, and skipping the clear if it is. 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 aninvalid header length (e.g. 255), causing nvme_tcp_verify_hdgst()to access memory outside the allocated area and cause memory corruptionsby overwriting it with the calculated digest.Fix this by rejecting packets with an unexpected header length. CVE-2025-22070: In the Linux kernel, the following vulnerability has been resolved:fs/9p: fix NULL pointer dereference on mkdirWhen a 9p tree was mounted with option 'posixacl', parent directory had adefault ACL set for its subdirectories, e.g.: setfacl -m default:group:simpsons:rwx parentdirthen creating a subdirectory crashed 9p client, as v9fs_fid_add() call infunction v9fs_vfs_mkdir_dotl() sets the passed 'fid' pointer to NULL(since dafbe689736) even though the subsequent v9fs_set_create_acl() callexpects 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 inv9fs_vfs_mkdir_dotl(), i.e. calling v9fs_set_create_acl() beforev9fs_fid_add(). CVE-2025-22104: In the Linux kernel, the following vulnerability has been resolved:ibmvnic: Use kernel helpers for hex dumpsPreviously, when the driver was printing hex dumps, the buffer was castto an 8 byte long and printed using string formatters. If the buffersize was not a multiple of 8 then a read buffer overflow was possible.Therefore, create a new ibmvnic function that loops over a buffer andcalls hex_dump_to_buffer instead.This patch address KASAN reports like the one below: ibmvnic 30000003 env3: Login Buffer: ibmvnic 30000003 env3: 01000000af000000 <...> ibmvnic 30000003 env3: 2e6d62692e736261 ibmvnic 30000003 env3: 65050003006d6f63 ================================================================== BUG: KASAN: slab-out-of-bounds in ibmvnic_login+0xacc/0xffc [ibmvnic] Read of size 8 at addr c0000001331a9aa8 by task ip/17681 <...> Allocated by task 17681: <...> ibmvnic_login+0x2f0/0xffc [ibmvnic] ibmvnic_open+0x148/0x308 [ibmvnic] __dev_open+0x1ac/0x304 <...> The buggy address is located 168 bytes inside of allocated 175-byte region [c0000001331a9a00, c0000001331a9aaf) <...> ================================================================= ibmvnic 30000003 env3: 000000000033766e CVE-2025-22113: In the Linux kernel, the following vulnerability has been resolved:ext4: avoid journaling sb update on error if journal is destroyingPresently we always BUG_ON if trying to start a transaction on a journal markedwith JBD2_UNMOUNT, since this should never happen. However, while ltp runningstress tests, it was observed that in case of some error handling paths, it ispossible for update_super_work to start a transaction after the journal isdestroyed 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 doa journaled (and deferred) update of sb if this flag is not set. Otherwise, justfallback 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 updatesThis sequence is important as it ensures that, after this point, there is no sbupdate that might be journaled so it is safe to update the sb outside thejournal. (To avoid race discussed in 2d01ddc86606)Also, we don't need a similar check in ext4_grp_locked_error since it is onlycalled from mballoc and AFAICT it would be always valid to schedule work here. 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-23131: In the Linux kernel, the following vulnerability has been resolved:dlm: prevent NPD when writing a positive value to event_donedo_uevent returns the value written to event_done. In case it is apositive value, new_lockspace would undo all the work, and lockspacewould not be set. __dlm_new_lockspace, however, would treat thatpositive value as a success due to commit 8511a2728ab8 ("dlm: fix usecount with multiple joins").Down the line, device_create_lockspace would pass that NULL lockspace todlm_find_lockspace_local, leading to a NULL pointer dereference.Treating such positive values as successes prevents the problem. Giventhis has been broken for so long, this is unlikely to break userspaceexpectations. 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/0x308pc : dquot_writeback_dquots+0x2fc/0x308lr : f2fs_quota_sync+0xcc/0x1c4Call trace:dquot_writeback_dquots+0x2fc/0x308f2fs_quota_sync+0xcc/0x1c4f2fs_write_checkpoint+0x3d4/0x9b0f2fs_issue_checkpoint+0x1bc/0x2c0f2fs_sync_fs+0x54/0x150f2fs_do_sync_file+0x2f8/0x814__f2fs_ioctl+0x1960/0x3244f2fs_ioctl+0x54/0xe0__arm64_sys_ioctl+0xa8/0xe4invoke_syscall+0x58/0x114checkpoint and f2fs_remount may race as below, resulting triggering warningin 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 remountIf checkpoint comes from mount/umount/remount/freeze/quotactl, caller ofcheckpoint 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 canknow whether the lock has held in the context or not by checking currentw/ it.In addition, in order to not misrepresent caller of checkpoint, we shouldnot allow to trigger async checkpoint for those callers: mount/umount/remount/freeze/quotactl. CVE-2025-37833: In the Linux kernel, the following vulnerability has been resolved:net/niu: Niu requires MSIX ENTRY_DATA fields touch before entry readsFix niu_try_msix() to not cause a fatal trap on sparc systems.Set PCI_DEV_FLAGS_MSIX_TOUCH_ENTRY_DATA_FIRST on the struct pci_dev towork around a bug in the hardware or firmware.For each vector entry in the msix table, niu chips will cause a fataltrap if any registers in that entry are read before that entries'ENTRY_DATA register is written to. Testing indicates writes to otherregisters are not sufficient to prevent the fatal trap, however the valuedoes not appear to matter. This only needs to happen once after power up,so simply rebooting into a kernel lacking this fix will NOT cause thetrap.NON-RESUMABLE ERROR: Reporting on cpu 64NON-RESUMABLE ERROR: TPC [0x00000000005f6900] <msix_prepare_msi_desc+0x90/0xa0>NON-RESUMABLE ERROR: RAW [4010000000000016:00000e37f93e32ff:0000000202000080:ffffffffffffffffNON-RESUMABLE ERROR: 0000000800000000:0000000000000000:0000000000000000:0000000000000000]NON-RESUMABLE ERROR: handle [0x4010000000000016] stick [0x00000e37f93e32ff]NON-RESUMABLE ERROR: type [precise nonresumable]NON-RESUMABLE ERROR: attrs [0x02000080] < ASI sp-faulted priv >NON-RESUMABLE ERROR: raddr [0xffffffffffffffff]NON-RESUMABLE ERROR: insn effective address [0x000000c50020000c]NON-RESUMABLE ERROR: size [0x8]NON-RESUMABLE ERROR: asi [0x00]CPU: 64 UID: 0 PID: 745 Comm: kworker/64:1 Not tainted 6.11.5 #63Workqueue: events work_for_cpu_fnTSTATE: 0000000011001602 TPC: 00000000005f6900 TNPC: 00000000005f6904 Y: 00000000 Not taintedTPC: <msix_prepare_msi_desc+0x90/0xa0>g0: 00000000000002e9 g1: 000000000000000c g2: 000000c50020000c g3: 0000000000000100g4: ffff8000470307c0 g5: ffff800fec5be000 g6: ffff800047a08000 g7: 0000000000000000o0: ffff800014feb000 o1: ffff800047a0b620 o2: 0000000000000011 o3: ffff800047a0b620o4: 0000000000000080 o5: 0000000000000011 sp: ffff800047a0ad51 ret_pc: 00000000005f7128RPC: <__pci_enable_msix_range+0x3cc/0x460>l0: 000000000000000d l1: 000000000000c01f l2: ffff800014feb0a8 l3: 0000000000000020l4: 000000000000c000 l5: 0000000000000001 l6: 0000000020000000 l7: ffff800047a0b734i0: ffff800014feb000 i1: ffff800047a0b730 i2: 0000000000000001 i3: 000000000000000di4: 0000000000000000 i5: 0000000000000000 i6: ffff800047a0ae81 i7: 00000000101888b0I7: <niu_try_msix.constprop.0+0xc0/0x130 [niu]>Call Trace:[<00000000101888b0>] niu_try_msix.constprop.0+0xc0/0x130 [niu][<000000001018f840>] niu_get_invariants+0x183c/0x207c [niu][<00000000101902fc>] niu_pci_init_one+0x27c/0x2fc [niu][<00000000005ef3e4>] local_pci_probe+0x28/0x74[<0000000000469240>] work_for_cpu_fn+0x8/0x1c[<000000000046b008>] process_scheduled_works+0x144/0x210[<000000000046b518>] worker_thread+0x13c/0x1c0[<00000000004710e0>] kthread+0xb8/0xc8[<00000000004060c8>] ret_from_fork+0x1c/0x2c[<0000000000000000>] 0x0Kernel panic - not syncing: Non-resumable error. CVE-2025-38203: In the Linux kernel, the following vulnerability has been resolved:jfs: Fix null-ptr-deref in jfs_ioc_trim[ Syzkaller Report ]Oops: general protection fault, probably for non-canonical address0xdffffc0000000087: 0000 [#1KASAN: null-ptr-deref in range [0x0000000000000438-0x000000000000043f]CPU: 2 UID: 0 PID: 10614 Comm: syz-executor.0 Not tainted6.13.0-rc6-gfbfd64d25c7a-dirty #1Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014Sched_ext: serialise (enabled+all), task: runnable_at=-30msRIP: 0010:jfs_ioc_trim+0x34b/0x8f0Code: e7 e8 59 a4 87 fe 4d 8b 24 24 4d 8d bc 24 38 04 00 00 48 8d 9390 82 fe ff 4c 89 ff 31 f6RSP: 0018:ffffc900055f7cd0 EFLAGS: 00010206RAX: 0000000000000087 RBX: 00005866a9e67ff8 RCX: 000000000000000aRDX: 0000000000000001 RSI: 0000000000000004 RDI: 0000000000000001RBP: dffffc0000000000 R08: ffff88807c180003 R09: 1ffff1100f830000R10: dffffc0000000000 R11: ffffed100f830001 R12: 0000000000000000R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000438FS: 00007fe520225640(0000) GS:ffff8880b7e80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005593c91b2c88 CR3: 000000014927c000 CR4: 00000000000006f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:<TASK>? __die_body+0x61/0xb0? die_addr+0xb1/0xe0? exc_general_protection+0x333/0x510? asm_exc_general_protection+0x26/0x30? jfs_ioc_trim+0x34b/0x8f0jfs_ioctl+0x3c8/0x4f0? __pfx_jfs_ioctl+0x10/0x10? __pfx_jfs_ioctl+0x10/0x10__se_sys_ioctl+0x269/0x350? __pfx___se_sys_ioctl+0x10/0x10? do_syscall_64+0xfb/0x210do_syscall_64+0xee/0x210? syscall_exit_to_user_mode+0x1e0/0x330entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7fe51f4903adCode: c3 e8 a7 2b 00 00 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 89 f8 4889 f7 48 89 d6 48 89 ca 4dRSP: 002b:00007fe5202250c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: ffffffffffffffda RBX: 00007fe51f5cbf80 RCX: 00007fe51f4903adRDX: 0000000020000680 RSI: 00000000c0185879 RDI: 0000000000000005RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe520225640R13: 000000000000000e R14: 00007fe51f44fca0 R15: 00007fe52021d000</TASK>Modules linked in:---[ end trace 0000000000000000 ]---RIP: 0010:jfs_ioc_trim+0x34b/0x8f0Code: e7 e8 59 a4 87 fe 4d 8b 24 24 4d 8d bc 24 38 04 00 00 48 8d 9390 82 fe ff 4c 89 ff 31 f6RSP: 0018:ffffc900055f7cd0 EFLAGS: 00010206RAX: 0000000000000087 RBX: 00005866a9e67ff8 RCX: 000000000000000aRDX: 0000000000000001 RSI: 0000000000000004 RDI: 0000000000000001RBP: dffffc0000000000 R08: ffff88807c180003 R09: 1ffff1100f830000R10: dffffc0000000000 R11: ffffed100f830001 R12: 0000000000000000R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000438FS: 00007fe520225640(0000) GS:ffff8880b7e80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005593c91b2c88 CR3: 000000014927c000 CR4: 00000000000006f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Kernel panic - not syncing: Fatal exception[ Analysis ]We believe that we have found a concurrency bug in the `fs/jfs` modulethat results in a null pointer dereference. There is a closely relatedissue which has been fixed:https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d6c1b3599b2feb5c7291f5ac3a36e5fa7cedb234... but, unfortunately, the accepted patch appears to still besusceptible to a null pointer dereference under some interleavings.To trigger the bug, we think that `JFS_SBI(ipbmap->i_sb)->bmap` is setto NULL in `dbFreeBits` and then dereferenced in `jfs_ioc_trim`. Thisbug manifests quite rarely under normal circumstances, but istriggereable from a syz-program. CVE-2025-38204: In the Linux kernel, the following vulnerability has been resolved:jfs: fix array-index-out-of-bounds read in add_missing_indicesstbl is s8 but it must contain offsets into slot which can go from 0 to127.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 returnswith an error. CVE-2025-38206: In the Linux kernel, the following vulnerability has been resolved:exfat: fix double free in delayed_freeThe double free could happen in the following path.exfat_create_upcase_table() exfat_create_upcase_table() : return error exfat_free_upcase_table() : free ->vol_utbl exfat_load_default_upcase_table : return error exfat_kill_sb() delayed_free() exfat_free_upcase_table() <--------- double freeThis patch set ->vol_util as NULL after freeing it. CVE-2025-38237: In the Linux kernel, the following vulnerability has been resolved:media: platform: exynos4-is: Add hardware sync wait to fimc_is_hw_change_mode()In fimc_is_hw_change_mode(), the function changes camera modes withoutwaiting for hardware completion, risking corrupted data or system hangsif subsequent operations proceed before the hardware is ready.Add fimc_is_hw_wait_intmsr0_intmsd0() after mode configuration, ensuringhardware state synchronization and stable interrupt handling. CVE-2025-38248: In the Linux kernel, the following vulnerability has been resolved:bridge: mcast: Fix use-after-free during router port configurationThe bridge maintains a global list of ports behind which a multicastrouter resides. The list is consulted during forwarding to ensuremulticast packets are forwarded to these ports even if the ports are notmember in the matching MDB entry.When per-VLAN multicast snooping is enabled, the per-port multicastcontext is disabled on each port and the port is removed from the globalrouter 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 routerHowever, the port can be re-added to the global list even when per-VLANmulticast 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: dummy1Since commit 4b30ae9adb04 ("net: bridge: mcast: re-implementbr_multicast_{enable, disable}_port functions"), when per-VLAN multicastsnooping is enabled, multicast disablement on a port will disable theper-{port, VLAN} multicast contexts and not the per-port one. As aresult, a port will remain in the global router port list even after itis deleted. This will lead to a use-after-free [1] when the list istraversed (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 2Similarly, stale entries can also be found in the per-VLAN router portlist. When per-VLAN multicast snooping is disabled, the per-{port, VLAN}contexts are disabled on each port and the port is removed from theper-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 routerHowever, the port can be re-added to the per-VLAN list even whenper-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: dummy1When the VLAN is deleted from the port, the per-{port, VLAN} multicastcontext will not be disabled since multicast snooping is not enabledon the VLAN. As a result, the port will remain in the per-VLAN routerport list even after it is no longer member in the VLAN. This will leadto a use-after-free [2] when the list is traversed (when adding a newport 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 2Fix these issues by removing the port from the relevant (global orper-VLAN) router port list in br_multicast_port_ctx_deinit(). Thefunction is invoked during port deletion with the per-port multicastcontext and during VLAN deletion with the per-{port, VLAN} multicastcontext.Note that deleting the multicast router timer is not enough as it onlytakes care of the temporary multicast router states (1 or 3) and not thepermanent one (2).[1]BUG: KASAN: slab-out-of-bounds in br_multicast_add_router.part.0+0x3f1/0x560Write of size 8 at addr ffff888004a67328 by task ip/384[...]Call Trace: <TASK> dump_stack---truncated--- CVE-2025-38264: In the Linux kernel, the following vulnerability has been resolved:nvme-tcp: sanitize request list handlingValidate the request in nvme_tcp_handle_r2t() to ensure it's not part ofany list, otherwise a malicious R2T PDU might inject a loop in requestlist processing. CVE-2025-38502: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix oob access in cgroup local storageLonial reported that an out-of-bounds access in cgroup local storagecan be crafted via tail calls. Given two programs each utilizing acgroup local storage with a different value size, and one programdoing a tail call into the other. The verifier will validate each ofthe indivial programs just fine. However, in the runtime contextthe bpf_cg_run_ctx holds an bpf_prog_array_item which contains theBPF program as well as any cgroup local storage flavor the programuses. Helpers such as bpf_get_local_storage() pick this up from theruntime context: ctx = container_of(current->bpf_ctx, struct bpf_cg_run_ctx, run_ctx); storage = ctx->prog_item->cgroup_storage[stype]; if (stype == BPF_CGROUP_STORAGE_SHARED) ptr = &READ_ONCE(storage->buf)->data[0]; else ptr = this_cpu_ptr(storage->percpu_buf);For the second program which was called from the originally attachedone, this means bpf_get_local_storage() will pick up the formerprogram's map, not its own. With mismatching sizes, this can resultin an unintended out-of-bounds access.To fix this issue, we need to extend bpf_map_owner with an array ofstorage_cookie[] to match on i) the exact maps from the originalprogram if the second program was using bpf_get_local_storage(), orii) allow the tail call combination if the second program was notusing any of the cgroup local storage maps. CVE-2025-38678: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: reject duplicate device on updatesA chain/flowtable update with duplicated devices in the same batch ispossible. Unfortunately, netdev event path only removes the firstdevice that is found, leaving unregistered the hook of the duplicateddevice.Check if a duplicated device exists in the transaction batch, bail outwith EEXIST in such case.WARNING is hit when unregistering the hook: [49042.221275] WARNING: CPU: 4 PID: 8425 at net/netfilter/core.c:340 nf_hook_entry_head+0xaa/0x150 [49042.221375] CPU: 4 UID: 0 PID: 8425 Comm: nft Tainted: G S 6.16.0+ #170 PREEMPT(full) [...] [49042.221382] RIP: 0010:nf_hook_entry_head+0xaa/0x150 CVE-2025-39682: In the Linux kernel, the following vulnerability has been resolved:tls: fix handling of zero-length records on the rx_listEach recvmsg() call must process either - only contiguous DATA records (any number of them) - one non-DATA recordIf the next record has different type than what has already beenprocessed we break out of the main processing loop. If the recordhas already been decrypted (which may be the case for TLS 1.3 wherewe don't know type until decryption) we queue the pending recordto the rx_list. Next recvmsg() will pick it up from there.Queuing the skb to rx_list after zero-copy decrypt is not possible,since in that case we decrypted directly to the user space buffer,and we don't have an skb to queue (darg.skb points to the ciphertextskb for access to metadata like length).Only data records are allowed zero-copy, and we break the processingloop after each non-data record. So we should never zero-copy andthen find out that the record type has changed. The corner casewe missed is when the initial record comes from rx_list, and it'szero length. CVE-2025-39702: In the Linux kernel, the following vulnerability has been resolved:ipv6: sr: Fix MAC comparison to be constant-timeTo prevent timing attacks, MACs need to be compared in constant time.Use the appropriate helper function for this. CVE-2025-39711: In the Linux kernel, the following vulnerability has been resolved:media: ivsc: Fix crash at shutdown due to missing mei_cldev_disable() callsBoth the ACE and CSI driver are missing a mei_cldev_disable() call intheir remove() function.This causes the mei_cl client to stay part of the mei_device->file_listlist even though its memory is freed by mei_cl_bus_dev_release() callingkfree(cldev->cl).This leads to a use-after-free when mei_vsc_remove() runs mei_stop()which first removes all mei bus devices calling mei_ace_remove() andmei_csi_remove() followed by mei_cl_bus_dev_release() and then callsmei_cl_all_disconnect() which walks over mei_device->file_list dereferecingthe just freed cldev->cl.And mei_vsc_remove() it self is run at shutdown because of theplatform_device_unregister(tp->pdev) in vsc_tp_shutdown()When building a kernel with KASAN this leads to the following KASAN report:[ 106.634504] ==================================================================[ 106.634623] BUG: KASAN: slab-use-after-free in mei_cl_set_disconnected (drivers/misc/mei/client.c:783) mei[ 106.634683] Read of size 4 at addr ffff88819cb62018 by task systemd-shutdow/1[ 106.634729][ 106.634767] Tainted: [E]=UNSIGNED_MODULE[ 106.634770] Hardware name: Dell Inc. XPS 16 9640/09CK4V, BIOS 1.12.0 02/10/2025[ 106.634773] Call Trace:[ 106.634777] <TASK>...[ 106.634871] kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:636)[ 106.634901] mei_cl_set_disconnected (drivers/misc/mei/client.c:783) mei[ 106.634921] mei_cl_all_disconnect (drivers/misc/mei/client.c:2165 (discriminator 4)) mei[ 106.634941] mei_reset (drivers/misc/mei/init.c:163) mei...[ 106.635042] mei_stop (drivers/misc/mei/init.c:348) mei[ 106.635062] mei_vsc_remove (drivers/misc/mei/mei_dev.h:784 drivers/misc/mei/platform-vsc.c:393) mei_vsc[ 106.635066] platform_remove (drivers/base/platform.c:1424)Add the missing mei_cldev_disable() calls so that the mei_cl gets removedfrom mei_device->file_list before it is freed to fix this. CVE-2025-39746: In the Linux kernel, the following vulnerability has been resolved:wifi: ath10k: shutdown driver when hardware is unreliableIn rare cases, ath10k may lose connection with the PCIe bus due tosome unknown reasons, which could further lead to system crashes duringresuming due to watchdog timeout:ath10k_pci 0000:01:00.0: wmi command 20486 timeout, restarting hardwareath10k_pci 0000:01:00.0: already restartingath10k_pci 0000:01:00.0: failed to stop WMI vdev 0: -11ath10k_pci 0000:01:00.0: failed to stop vdev 0: -11ieee80211 phy0: PM: **** DPM device timeout ****Call Trace: panic+0x125/0x315 dpm_watchdog_set+0x54/0x54 dpm_watchdog_handler+0x57/0x57 call_timer_fn+0x31/0x13cAt this point, all WMI commands will timeout and attempt to restartdevice. So set a threshold for consecutive restart failures. If thethreshold is exceeded, consider the hardware is unreliable and allath10k operations should be skipped to avoid system crash.fail_cont_count and pending_recovery are atomic variables, anddo not involve complex conditional logic. Therefore, even if recoverycheck and reconfig complete are executed concurrently, the recoverymechanism will not be broken.Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00288-QCARMSWPZ-1 CVE-2025-39790: In the Linux kernel, the following vulnerability has been resolved:bus: mhi: host: Detect events pointing to unexpected TREsWhen a remote device sends a completion event to the host, it contains apointer to the consumed TRE. The host uses this pointer to process all ofthe TREs between it and the host's local copy of the ring's read pointer.This works when processing completion for chained transactions, but canlead to nasty results if the device sends an event for a single-elementtransaction with a read pointer that is multiple elements ahead of thehost's read pointer.For instance, if the host accesses an event ring while the device isupdating it, the pointer inside of the event might still point to an oldTRE. If the host uses the channel's xfer_cb() to directly free the bufferpointed to by the TRE, the buffer will be double-freed.This behavior was observed on an ep that used upstream EP stack without'commit 6f18d174b73d ("bus: mhi: ep: Update read pointer only after bufferis written")'. Where the device updated the events ring pointer beforeupdating the event contents, so it left a window where the host was able toaccess the stale data the event pointed to, before the device had thechance to update them. The usual pattern was that the host received anevent pointing to a TRE that is not immediately after the last processedone, so it got treated as if it was a chained transaction, processing allof the TREs in between the two read pointers.This commit aims to harden the host by ensuring transactions where theevent points to a TRE that isn't local_rp + 1 are chained.[mani: added stable tag and reworded commit message] CVE-2025-39833: In the Linux kernel, the following vulnerability has been resolved:mISDN: hfcpci: Fix warning when deleting uninitialized timerWith CONFIG_DEBUG_OBJECTS_TIMERS unloading hfcpci module leadsto the following splat:[ 250.215892] ODEBUG: assert_init not available (active state 0) object: ffffffffc01a3dc0 object type: timer_list hint: 0x0[ 250.217520] WARNING: CPU: 0 PID: 233 at lib/debugobjects.c:612 debug_print_object+0x1b6/0x2c0[ 250.218775] Modules linked in: hfcpci(-) mISDN_core[ 250.219537] CPU: 0 UID: 0 PID: 233 Comm: rmmod Not tainted 6.17.0-rc2-g6f713187ac98 #2 PREEMPT(voluntary)[ 250.220940] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 250.222377] RIP: 0010:debug_print_object+0x1b6/0x2c0[ 250.223131] Code: fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 75 4f 41 56 48 8b 14 dd a0 4e 01 9f 48 89 ee 48 c7 c7 20 46 01 9f e8 cb 84d[ 250.225805] RSP: 0018:ffff888015ea7c08 EFLAGS: 00010286[ 250.226608] RAX: 0000000000000000 RBX: 0000000000000005 RCX: ffffffff9be93a95[ 250.227708] RDX: 1ffff1100d945138 RSI: 0000000000000008 RDI: ffff88806ca289c0[ 250.228993] RBP: ffffffff9f014a00 R08: 0000000000000001 R09: ffffed1002bd4f39[ 250.230043] R10: ffff888015ea79cf R11: 0000000000000001 R12: 0000000000000001[ 250.231185] R13: ffffffff9eea0520 R14: 0000000000000000 R15: ffff888015ea7cc8[ 250.232454] FS: 00007f3208f01540(0000) GS:ffff8880caf5a000(0000) knlGS:0000000000000000[ 250.233851] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 250.234856] CR2: 00007f32090a7421 CR3: 0000000004d63000 CR4: 00000000000006f0[ 250.236117] Call Trace:[ 250.236599] <TASK>[ 250.236967] ? trace_irq_enable.constprop.0+0xd4/0x130[ 250.237920] debug_object_assert_init+0x1f6/0x310[ 250.238762] ? __pfx_debug_object_assert_init+0x10/0x10[ 250.239658] ? __lock_acquire+0xdea/0x1c70[ 250.240369] __try_to_del_timer_sync+0x69/0x140[ 250.241172] ? __pfx___try_to_del_timer_sync+0x10/0x10[ 250.242058] ? __timer_delete_sync+0xc6/0x120[ 250.242842] ? lock_acquire+0x30/0x80[ 250.243474] ? __timer_delete_sync+0xc6/0x120[ 250.244262] __timer_delete_sync+0x98/0x120[ 250.245015] HFC_cleanup+0x10/0x20 [hfcpci][ 250.245704] __do_sys_delete_module+0x348/0x510[ 250.246461] ? __pfx___do_sys_delete_module+0x10/0x10[ 250.247338] do_syscall_64+0xc1/0x360[ 250.247924] entry_SYSCALL_64_after_hwframe+0x77/0x7fFix this by initializing hfc_tl timer with DEFINE_TIMER macro.Also, use mod_timer instead of manual timeout update. CVE-2025-39866: In the Linux kernel, the following vulnerability has been resolved:fs: writeback: fix use-after-free in __mark_inode_dirty()An use-after-free issue occurred when __mark_inode_dirty() get thebdi_writeback that was in the progress of switching.CPU: 1 PID: 562 Comm: systemd-random- Not tainted 6.6.56-gb4403bd46a8e #1......pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : __mark_inode_dirty+0x124/0x418lr : __mark_inode_dirty+0x118/0x418sp : ffffffc08c9dbbc0........Call trace: __mark_inode_dirty+0x124/0x418 generic_update_time+0x4c/0x60 file_modified+0xcc/0xd0 ext4_buffered_write_iter+0x58/0x124 ext4_file_write_iter+0x54/0x704 vfs_write+0x1c0/0x308 ksys_write+0x74/0x10c __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x114 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x40/0xe4 el0t_64_sync_handler+0x120/0x12c el0t_64_sync+0x194/0x198Root cause is:systemd-random-seed kworker----------------------------------------------------------------------___mark_inode_dirty inode_switch_wbs_work_fn spin_lock(&inode->i_lock); inode_attach_wb locked_inode_to_wb_and_lock_list get inode->i_wb spin_unlock(&inode->i_lock); spin_lock(&wb->list_lock) spin_lock(&inode->i_lock) inode_io_list_move_locked spin_unlock(&wb->list_lock) spin_unlock(&inode->i_lock) spin_lock(&old_wb->list_lock) inode_do_switch_wbs spin_lock(&inode->i_lock) inode->i_wb = new_wb spin_unlock(&inode->i_lock) spin_unlock(&old_wb->list_lock) wb_put_many(old_wb, nr_switched) cgwb_release old wb released wb_wakeup_delayed() accesses wb, then trigger the use-after-free issueFix this race condition by holding inode spinlock untilwb_wakeup_delayed() finished. CVE-2025-39946: In the Linux kernel, the following vulnerability has been resolved:tls: make sure to abort the stream if headers are bogusNormally we wait for the socket to buffer up the whole recordbefore we service it. If the socket has a tiny buffer, however,we read out the data sooner, to prevent connection stalls.Make sure that we abort the connection when we find out latethat the record is actually invalid. Retrying the parsing isfine in itself but since we copy some more data each timebefore we parse we can overflow the allocated skb space.Constructing a scenario in which we're under pressure withoutenough data in the socket to parse the length upfront is quitehard. syzbot figured out a way to do this by serving us the headerin small OOB sends, and then filling in the recvbuf with a largenormal send.Make sure that tls_rx_msg_size() aborts strp, if we reachan invalid record there's really no way to recover. CVE-2025-39964: In the Linux kernel, the following vulnerability has been resolved:crypto: af_alg - Disallow concurrent writes in af_alg_sendmsgIssuing two writes to the same af_alg socket is bogus as thedata will be interleaved in an unpredictable fashion. Furthermore,concurrent writes may create inconsistencies in the internalsocket state.Disallow this by adding a new ctx->write field that indiciatesexclusive ownership for writing. CVE-2025-40018: No description is available for this CVE. CVE-2025-40019: No description is available for this CVE. CVE-2025-40020: No description is available for this CVE. CVE-2025-40106: In the Linux kernel, the following vulnerability has been resolved: comedi: fix divide-by-zero in comedi_buf_munge() The comedi_buf_munge() function performs a modulo operation `async->munge_chan %= async->cmd.chanlist_len` without first checking if chanlist_len is zero. If a user program submits a command with chanlist_len set to zero, this causes a divide-by-zero error when the device processes data in the interrupt handler path. Add a check for zero chanlist_len at the beginning of the function, similar to the existing checks for !map and CMDF_RAWDATA flag. When chanlist_len is zero, update munge_count and return early, indicating the data was handled without munging. This prevents potential kernel panics from malformed user commands. CVE-2025-40214: In the Linux kernel, the following vulnerability has been resolved: af_unix: Initialise scc_index in unix_add_edge(). Quang Le reported that the AF_UNIX GC could garbage-collect a receive queue of an alive in-flight socket, with a nice repro. The repro consists of three stages. 1) 1-a. Create a single cyclic reference with many sockets 1-b. close() all sockets 1-c. Trigger GC 2) 2-a. Pass sk-A to an embryo sk-B 2-b. Pass sk-X to sk-X 2-c. Trigger GC 3) 3-a. accept() the embryo sk-B 3-b. Pass sk-B to sk-C 3-c. close() the in-flight sk-A 3-d. Trigger GC As of 2-c, sk-A and sk-X are linked to unix_unvisited_vertices, and unix_walk_scc() groups them into two different SCCs: unix_sk(sk-A)->vertex->scc_index = 2 (UNIX_VERTEX_INDEX_START) unix_sk(sk-X)->vertex->scc_index = 3 Once GC completes, unix_graph_grouped is set to true. Also, unix_graph_maybe_cyclic is set to true due to sk-X's cyclic self-reference, which makes close() trigger GC. At 3-b, unix_add_edge() allocates unix_sk(sk-B)->vertex and links it to unix_unvisited_vertices. unix_update_graph() is called at 3-a. and 3-b., but neither unix_graph_grouped nor unix_graph_maybe_cyclic is changed because both sk-B's listener and sk-C are not in-flight. 3-c decrements sk-A's file refcnt to 1. Since unix_graph_grouped is true at 3-d, unix_walk_scc_fast() is finally called and iterates 3 sockets sk-A, sk-B, and sk-X: sk-A -> sk-B (-> sk-C) sk-X -> sk-X This is totally fine. All of them are not yet close()d and should be grouped into different SCCs. However, unix_vertex_dead() misjudges that sk-A and sk-B are in the same SCC and sk-A is dead. unix_sk(sk-A)->scc_index == unix_sk(sk-B)->scc_index <-- Wrong! && sk-A's file refcnt == unix_sk(sk-A)->vertex->out_degree ^-- 1 in-flight count for sk-B -> sk-A is dead !? The problem is that unix_add_edge() does not initialise scc_index. Stage 1) is used for heap spraying, making a newly allocated vertex have vertex->scc_index == 2 (UNIX_VERTEX_INDEX_START) set by unix_walk_scc() at 1-c. Let's track the max SCC index from the previous unix_walk_scc() call and assign the max + 1 to a new vertex's scc_index. This way, we can continue to avoid Tarjan's algorithm while preventing misjudgments. CVE-2025-40215: In the Linux kernel, the following vulnerability has been resolved: xfrm: delete x->tunnel as we delete x The ipcomp fallback tunnels currently get deleted (from the various lists and hashtables) as the last user state that needed that fallback is destroyed (not deleted). If a reference to that user state still exists, the fallback state will remain on the hashtables/lists, triggering the WARN in xfrm_state_fini. Because of those remaining references, the fix in commit f75a2804da39 ("xfrm: destroy xfrm_state synchronously on net exit path") is not complete. We recently fixed one such situation in TCP due to defered freeing of skbs (commit 9b6412e6979f ("tcp: drop secpath at the same time as we currently drop dst")). This can also happen due to IP reassembly: skbs with a secpath remain on the reassembly queue until netns destruction. If we can't guarantee that the queues are flushed by the time xfrm_state_fini runs, there may still be references to a (user) xfrm_state, preventing the timely deletion of the corresponding fallback state. Instead of chasing each instance of skbs holding a secpath one by one, this patch fixes the issue directly within xfrm, by deleting the fallback state as soon as the last user state depending on it has been deleted. Destruction will still happen when the final reference is dropped. A separate lockdep class for the fallback state is required since we're going to lock x->tunnel while x is locked. CVE-2025-40297: In the Linux kernel, the following vulnerability has been resolved: net: bridge: fix use-after-free due to MST port state bypass syzbot reported[1] a use-after-free when deleting an expired fdb. It is due to a race condition between learning still happening and a port being deleted, after all its fdbs have been flushed. The port's state has been toggled to disabled so no learning should happen at that time, but if we have MST enabled, it will bypass the port's state, that together with VLAN filtering disabled can lead to fdb learning at a time when it shouldn't happen while the port is being deleted. VLAN filtering must be disabled because we flush the port VLANs when it's being deleted which will stop learning. This fix adds a check for the port's vlan group which is initialized to NULL when the port is getting deleted, that avoids the port state bypass. When MST is enabled there would be a minimal new overhead in the fast-path because the port's vlan group pointer is cache-hot. [1] https://syzkaller.appspot.com/bug?extid=dd280197f0f7ab3917be CVE-2025-40307: In the Linux kernel, the following vulnerability has been resolved: exfat: validate cluster allocation bits of the allocation bitmap syzbot created an exfat image with cluster bits not set for the allocation bitmap. exfat-fs reads and uses the allocation bitmap without checking this. The problem is that if the start cluster of the allocation bitmap is 6, cluster 6 can be allocated when creating a directory with mkdir. exfat zeros out this cluster in exfat_mkdir, which can delete existing entries. This can reallocate the allocated entries. In addition, the allocation bitmap is also zeroed out, so cluster 6 can be reallocated. This patch adds exfat_test_bitmap_range to validate that clusters used for the allocation bitmap are correctly marked as in-use. CVE-2025-40325: In the Linux kernel, the following vulnerability has been resolved:md/raid10: wait barrier before returning discard request with REQ_NOWAITraid10_handle_discard should wait barrier before returning a discard biowhich has REQ_NOWAIT. And there is no need to print warning calltraceif a discard bio has REQ_NOWAIT flag. Quality engineer usually checksdmesg and reports error if dmesg has warning/error calltrace. CVE-2025-40355: No description is available for this CVE. CVE-2025-68745: No description is available for this CVE. CVE-2026-23112: In the Linux kernel, the following vulnerability has been resolved:nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovecnvmet_tcp_build_pdu_iovec() could walk past cmd->req.sg when a PDUlength or offset exceeds sg_cnt and then use bogus sg->length/offsetvalues, leading to _copy_to_iter() GPF/KASAN. Guard sg_idx, remainingentries, and sg->length/offset before building the bvec. CVE-2026-23361: In the Linux kernel, the following vulnerability has been resolved:PCI: dwc: ep: Flush MSI-X write before unmapping its ATU entryEndpoint drivers use dw_pcie_ep_raise_msix_irq() to raise an MSI-Xinterrupt to the host using a writel(), which generates a PCI posted writetransaction. There's no completion for posted writes, so the writel() mayreturn before the PCI write completes. dw_pcie_ep_raise_msix_irq() alsounmaps the outbound ATU entry used for the PCI write, so the write raceswith the unmap.If the PCI write loses the race with the ATU unmap, the write may corrupthost memory or cause IOMMU errors, e.g., these when running fio with alarger 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: 0x0Flush the write by performing a readl() of the same address to ensure thatthe write has reached the destination before the ATU entry is unmapped.The same problem was solved for dw_pcie_ep_raise_msi_irq() in commit8719c64e76bf ("PCI: dwc: ep: Cache MSI outbound iATU mapping"), but thereit was solved by dedicating an outbound iATU only for MSI. We can't do thesame for MSI-X because each vector can have a different msg_addr and themsg_addr may be changed while the vector is masked.[bhelgaas: commit log] CVE-2026-31402: In the Linux kernel, the following vulnerability has been resolved:nfsd: fix heap overflow in NFSv4.0 LOCK replay cacheThe NFSv4.0 replay cache uses a fixed 112-byte inline buffer(rp_ibuf[NFSD4_REPLAY_ISIZE]) to store encoded operation responses.This size was calculated based on OPEN responses and does not accountfor LOCK denied responses, which include the conflicting lock owner asa variable-length field up to 1024 bytes (NFS4_OPAQUE_LIMIT).When a LOCK operation is denied due to a conflict with an existing lockthat has a large owner, nfsd4_encode_operation() copies the full encodedresponse into the undersized replay buffer via read_bytes_from_xdr_buf()with no bounds check. This results in a slab-out-of-bounds write of upto 944 bytes past the end of the buffer, corrupting adjacent heap memory.This can be triggered remotely by an unauthenticated attacker with twocooperating NFSv4.0 clients: one sets a lock with a large owner string,then the other requests a conflicting lock to provoke the denial.We could fix this by increasing NFSD4_REPLAY_ISIZE to allow for a fullopaque, but that would increase the size of every stateowner, when mostlockowners are not that large.Instead, fix this by checking the encoded response length againstNFSD4_REPLAY_ISIZE before copying into the replay buffer. If theresponse is too large, set rp_buflen to 0 to skip caching the replaypayload. The status is still cached, and the client already received thecorrect response on the original request. CVE-2026-31449: In the Linux kernel, the following vulnerability has been resolved:ext4: validate p_idx bounds in ext4_ext_correct_indexesext4_ext_correct_indexes() walks up the extent tree correctingindex entries when the first extent in a leaf is modified. Beforeaccessing path[k].p_idx->ei_block, there is no validation thatp_idx falls within the valid range of index entries for thatlevel.If the on-disk extent header contains a corrupted or craftedeh_entries value, p_idx can point past the end of the allocatedbuffer, causing a slab-out-of-bounds read.Fix this by validating path[k].p_idx against EXT_LAST_INDEX() atboth access sites: before the while loop and inside it. Return-EFSCORRUPTED if the index pointer is out of range, consistentwith how other bounds violations are handled in the ext4 extenttree code. CVE-2026-31450: In the Linux kernel, the following vulnerability has been resolved:ext4: publish jinode after initializationext4_inode_attach_jinode() publishes ei->jinode to concurrent users.It used to set ei->jinode before jbd2_journal_init_jbd_inode(),allowing a reader to observe a non-NULL jinode with i_vfs_inodestill unset.The fast commit flush path can then pass this jinode tojbd2_wait_inode_data(), which dereferences i_vfs_inode->i_mapping andmay crash.Below is the crash I observe:```BUG: unable to handle page fault for address: 000000010beb47f4PGD 110e51067 P4D 110e51067 PUD 0Oops: Oops: 0000 [#1] SMP NOPTICPU: 1 UID: 0 PID: 4850 Comm: fc_fsync_bench_ Not tainted 6.18.0-00764-g795a690c06a5 #1 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014RIP: 0010:xas_find_marked+0x3d/0x2e0Code: e0 03 48 83 f8 02 0f 84 f0 01 00 00 48 8b 47 08 48 89 c3 48 39 c6 0f 82 fd 01 00 00 48 85 c9 74 3d 48 83 f9 03 77 63 4c 8b 0f <49> 8b 71 08 48 c7 47 18 00 00 00 00 48 89 f1 83 e1 03 48 83 f9 02RSP: 0018:ffffbbee806e7bf0 EFLAGS: 00010246RAX: 000000000010beb4 RBX: 000000000010beb4 RCX: 0000000000000003RDX: 0000000000000001 RSI: 0000002000300000 RDI: ffffbbee806e7c10RBP: 0000000000000001 R08: 0000002000300000 R09: 000000010beb47ecR10: ffff9ea494590090 R11: 0000000000000000 R12: 0000002000300000R13: ffffbbee806e7c90 R14: ffff9ea494513788 R15: ffffbbee806e7c88FS: 00007fc2f9e3e6c0(0000) GS:ffff9ea6b1444000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000000010beb47f4 CR3: 0000000119ac5000 CR4: 0000000000750ef0PKRU: 55555554Call Trace:<TASK>filemap_get_folios_tag+0x87/0x2a0__filemap_fdatawait_range+0x5f/0xd0? srso_alias_return_thunk+0x5/0xfbef5? __schedule+0x3e7/0x10c0? srso_alias_return_thunk+0x5/0xfbef5? srso_alias_return_thunk+0x5/0xfbef5? srso_alias_return_thunk+0x5/0xfbef5? preempt_count_sub+0x5f/0x80? srso_alias_return_thunk+0x5/0xfbef5? cap_safe_nice+0x37/0x70? srso_alias_return_thunk+0x5/0xfbef5? preempt_count_sub+0x5f/0x80? srso_alias_return_thunk+0x5/0xfbef5filemap_fdatawait_range_keep_errors+0x12/0x40ext4_fc_commit+0x697/0x8b0? ext4_file_write_iter+0x64b/0x950? srso_alias_return_thunk+0x5/0xfbef5? preempt_count_sub+0x5f/0x80? srso_alias_return_thunk+0x5/0xfbef5? vfs_write+0x356/0x480? srso_alias_return_thunk+0x5/0xfbef5? preempt_count_sub+0x5f/0x80ext4_sync_file+0xf7/0x370do_fsync+0x3b/0x80? syscall_trace_enter+0x108/0x1d0__x64_sys_fdatasync+0x16/0x20do_syscall_64+0x62/0x2c0entry_SYSCALL_64_after_hwframe+0x76/0x7e...```Fix this by initializing the jbd2_inode first.Use smp_wmb() and WRITE_ONCE() to publish ei->jinode afterinitialization. Readers use READ_ONCE() to fetch the pointer. CVE-2026-31523: In the Linux kernel, the following vulnerability has been resolved:nvme-pci: ensure we're polling a polled queueA user can change the polled queue count at run time. There's a briefwindow during a reset where a hipri task may try to poll that queuebefore the block layer has updated the queue maps, which would race withthe now interrupt driven queue and may cause double completions. CVE-2026-31530: In the Linux kernel, the following vulnerability has been resolved:cxl/port: Fix use after free of parent_port in cxl_detach_ep()cxl_detach_ep() is called during bottom-up removal when all CXL memorydevices beneath a switch port have been removed. For each port in thehierarchy it locks both the port and its parent, removes the endpoint,and if the port is now empty, marks it dead and unregisters the portby calling delete_switch_port(). There are two places during this workwhere the parent_port may be used after freeing:First, a concurrent detach may have already processed a port by thetime a second worker finds it via bus_find_device(). Without pinningparent_port, it may already be freed when we discover port->dead andattempt to unlock the parent_port. In a production kernel that's asilent memory corruption, with lock debug, it looks like this:[]DEBUG_LOCKS_WARN_ON(__owner_task(owner) != get_current())[]WARNING: kernel/locking/mutex.c:949 at __mutex_unlock_slowpath+0x1ee/0x310[]Call Trace:[]mutex_unlock+0xd/0x20[]cxl_detach_ep+0x180/0x400 [cxl_core][]devm_action_release+0x10/0x20[]devres_release_all+0xa8/0xe0[]device_unbind_cleanup+0xd/0xa0[]really_probe+0x1a6/0x3e0Second, delete_switch_port() releases three devm actions registeredagainst parent_port. The last of those is unregister_port() and itcalls device_unregister() on the child port, which can cascade. Ifparent_port is now also empty the device core may unregister and freeit too. So by the time delete_switch_port() returns, parent_port maybe free, and the subsequent device_unlock(&parent_port->dev) operateson freed memory. The kernel log looks same as above, with a differentoffset in cxl_detach_ep().Both of these issues stem from the absence of a lifetime guaranteebetween a child port and its parent port.Establish a lifetime rule for ports: child ports hold a reference totheir parent device until release. Take the reference when the portis allocated and drop it when released. This ensures the parent isvalid for the full lifetime of the child and eliminates the use afterfree window in cxl_detach_ep().This is easily reproduced with a reload of cxl_acpi in QEMU with CXLdevices present. CVE-2026-31693: In the Linux kernel, the following vulnerability has been resolved:cifs: some missing initializations on replayIn several places in the code, we have a label to signifythe start of the code where a request can be replayed ifnecessary. However, some of these places were missing thenecessary reinitializations of certain local variablesbefore replay.This change makes sure that these variables get initializedafter the label. CVE-2026-31705: In the Linux kernel, the following vulnerability has been resolved:ksmbd: fix out-of-bounds write in smb2_get_ea() EA alignmentsmb2_get_ea() applies 4-byte alignment padding via memset() afterwriting each EA entry. The bounds check on buf_free_len is performedbefore the value memcpy, but the alignment memset fires unconditionallyafterward with no check on remaining space.When the EA value exactly fills the remaining buffer (buf_free_len == 0after value subtraction), the alignment memset writes 1-3 NUL bytespast the buf_free_len boundary. In compound requests where the responsebuffer is shared across commands, the first command (e.g., READ) canconsume most of the buffer, leaving a tight remainder for the QUERY_INFOEA response. The alignment memset then overwrites past the physicalkvmalloc allocation into adjacent kernel heap memory.Add a bounds check before the alignment memset to ensure buf_free_lencan accommodate the padding bytes.This is the same bug pattern fixed by commit beef2634f81f ("ksmbd: fixpotencial OOB in get_file_all_info() for compound requests") andcommit fda9522ed6af ("ksmbd: fix OOB write in QUERY_INFO for compoundrequests"), both of which added bounds checks before unconditionalwrites in QUERY_INFO response handlers. CVE-2026-31708: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix OOB read in smb2_ioctl_query_info QUERY_INFO pathsmb2_ioctl_query_info() has two response-copy branches: PASSTHRU_FSCTLand the default QUERY_INFO path. The QUERY_INFO branch clampsqi.input_buffer_length to the server-reported OutputBufferLength and thencopies qi.input_buffer_length bytes from qi_rsp->Buffer to userspace, butit never verifies that the flexible-array payload actually fits withinrsp_iov[1].iov_len.A malicious server can return OutputBufferLength larger than the actualQUERY_INFO response, causing copy_to_user() to walk past the responsebuffer and expose adjacent kernel heap to userspace.Guard the QUERY_INFO copy with a bounds check on the actual Bufferpayload. Use struct_size(qi_rsp, Buffer, qi.input_buffer_length)rather than an open-coded addition so the guard cannot overflow on32-bit builds. CVE-2026-31711: In the Linux kernel, the following vulnerability has been resolved:smb: server: fix active_num_conn leak on transport allocation failureCommit 77ffbcac4e56 ("smb: server: fix leak of active_num_conn inksmbd_tcp_new_connection()") addressed the kthread_run() failurepath. The earlier alloc_transport() == NULL path in the samefunction has the same leak, is reachable pre-authentication via anyTCP connect to port 445, and was empirically reproduced on UML(ARCH=um, v7.0-rc7): a small number of forced allocation failureswere sufficient to put ksmbd into a state where every subsequentconnection attempt was rejected for the remainder of the boot.ksmbd_kthread_fn() increments active_num_conn before callingksmbd_tcp_new_connection() and discards the return value, so whenalloc_transport() returns NULL the socket is released and -ENOMEMreturned without decrementing the counter. Each such failurepermanently consumes one slot from the max_connections pool; oncecumulative failures reach the cap, atomic_inc_return() hits thethreshold on every subsequent accept and every new connection isrejected. The counter is only reset by module reload.An unauthenticated remote attacker can drive the server toward thememory pressure that makes alloc_transport() fail by holding openconnections with large RFC1002 lengths up to MAX_STREAM_PROT_LEN(0x00FFFFFF); natural transient allocation failures on a loadedhost produce the same drift more slowly.Mirror the existing rollback pattern in ksmbd_kthread_fn(): on thealloc_transport() failure path, decrement active_num_conn gated onserver_conf.max_connections.Repro details: with the patch reverted, forced alloc_transport()NULL returns leaked counter slots and subsequent connectionattempts -- including legitimate connects issued after theforced-fail window had closed -- were all rejected with "Limit themaximum number of connections". With this patch applied, the sameconnect sequence produces no rejections and the counter cyclescleanly between zero and one on every accept. CVE-2026-31714: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to avoid memory leak in f2fs_rename()syzbot reported a f2fs bug as below:BUG: memory leakunreferenced object 0xffff888127f70830 (size 16): comm "syz.0.23", pid 6144, jiffies 4294943712 hex dump (first 16 bytes): 3c af 57 72 5b e6 8f ad 6e 8e fd 33 42 39 03 ff <.Wr[...n..3B9.. backtrace (crc 925f8a80): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4520 [inline] slab_alloc_node mm/slub.c:4844 [inline] __do_kmalloc_node mm/slub.c:5237 [inline] __kmalloc_noprof+0x3bd/0x560 mm/slub.c:5250 kmalloc_noprof include/linux/slab.h:954 [inline] fscrypt_setup_filename+0x15e/0x3b0 fs/crypto/fname.c:364 f2fs_setup_filename+0x52/0xb0 fs/f2fs/dir.c:143 f2fs_rename+0x159/0xca0 fs/f2fs/namei.c:961 f2fs_rename2+0xd5/0xf20 fs/f2fs/namei.c:1308 vfs_rename+0x7ff/0x1250 fs/namei.c:6026 filename_renameat2+0x4f4/0x660 fs/namei.c:6144 __do_sys_renameat2 fs/namei.c:6173 [inline] __se_sys_renameat2 fs/namei.c:6168 [inline] __x64_sys_renameat2+0x59/0x80 fs/namei.c:6168 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/0x7fThe root cause is in commit 40b2d55e0452 ("f2fs: fix to create selinuxlabel during whiteout initialization"), we added a call tof2fs_setup_filename() without a matching call to f2fs_free_filename(),fix it. CVE-2026-31716: In the Linux kernel, the following vulnerability has been resolved:fs/ntfs3: validate rec->used in journal-replay file record checkcheck_file_record() validates rec->total against the record size butnever validates rec->used. The do_action() journal-replay handlers readrec->used from disk and use it to compute memmove lengths: DeleteAttribute: memmove(attr, ..., used - asize - roff) CreateAttribute: memmove(..., attr, used - roff) change_attr_size: memmove(..., used - PtrOffset(rec, next))When rec->used is smaller than the offset of a validated attribute, orlarger than the record size, these subtractions can underflow allowingus to copy huge amounts of memory in to a 4kb buffer, generallyconsidered a bad idea overall.This requires a corrupted filesystem, which isn't a threat model thekernel really needs to worry about, but checking for such an obviousout-of-bounds value is good to keep things robust, especially on journalreplayFix this up by bounding rec->used correctly.This is much like commit b2bc7c44ed17 ("fs/ntfs3: Fix slab-out-of-boundsread in DeleteIndexEntryRoot") which checked different values in thissame switch statement. CVE-2026-43046: In the Linux kernel, the following vulnerability has been resolved:btrfs: reject root items with drop_progress and zero drop_level[BUG]When recovering relocation at mount time, merge_reloc_root() andbtrfs_drop_snapshot() both use BUG_ON(level == 0) to guard againstan impossible state: a non-zero drop_progress combined with a zerodrop_level in a root_item, which can be triggered:------------[ cut here ]------------kernel BUG at fs/btrfs/relocation.c:1545!Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTICPU: 1 UID: 0 PID: 283 ... Tainted: 6.18.0+ #16 PREEMPT(voluntary)Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULEHardware name: QEMU Ubuntu 24.04 PC v2, BIOS 1.16.3-debian-1.16.3-2RIP: 0010:merge_reloc_root+0x1266/0x1650 fs/btrfs/relocation.c:1545Code: ffff0000 00004589 d7e9acfa ffffe8a1 79bafebe 02000000Call Trace: merge_reloc_roots+0x295/0x890 fs/btrfs/relocation.c:1861 btrfs_recover_relocation+0xd6e/0x11d0 fs/btrfs/relocation.c:4195 btrfs_start_pre_rw_mount+0xa4d/0x1810 fs/btrfs/disk-io.c:3130 open_ctree+0x5824/0x5fe0 fs/btrfs/disk-io.c:3640 btrfs_fill_super fs/btrfs/super.c:987 [inline] btrfs_get_tree_super fs/btrfs/super.c:1951 [inline] btrfs_get_tree_subvol fs/btrfs/super.c:2094 [inline] btrfs_get_tree+0x111c/0x2190 fs/btrfs/super.c:2128 vfs_get_tree+0x9a/0x370 fs/super.c:1758 fc_mount fs/namespace.c:1199 [inline] do_new_mount_fc fs/namespace.c:3642 [inline] do_new_mount fs/namespace.c:3718 [inline] path_mount+0x5b8/0x1ea0 fs/namespace.c:4028 do_mount fs/namespace.c:4041 [inline] __do_sys_mount fs/namespace.c:4229 [inline] __se_sys_mount fs/namespace.c:4206 [inline] __x64_sys_mount+0x282/0x320 fs/namespace.c:4206 ...RIP: 0033:0x7f969c9a8fdeCode: 0f1f4000 48c7c2b0 fffffff7 d8648902 b8ffffff ffc3660f---[ end trace 0000000000000000 ]---The bug is reproducible on 7.0.0-rc2-next-20260310 with our dynamicmetadata fuzzing tool that corrupts btrfs metadata at runtime.[CAUSE]A non-zero drop_progress.objectid means an interruptedbtrfs_drop_snapshot() left a resume point on disk, and in that casedrop_level must be greater than 0 because the checkpoint is onlysaved at internal node levels.Although this invariant is enforced when the kernel writes the rootitem, it is not validated when the root item is read back from disk.That allows on-disk corruption to provide an invalid state withdrop_progress.objectid != 0 and drop_level == 0.When relocation recovery later processes such a root item,merge_reloc_root() reads drop_level and hits BUG_ON(level == 0). Thesame invalid metadata can also trigger the corresponding BUG_ON() inbtrfs_drop_snapshot().[FIX]Fix this by validating the root_item invariant in tree-checker whenreading root items from disk: if drop_progress.objectid is non-zero,drop_level must also be non-zero. Reject such malformed metadata with-EUCLEAN before it reaches merge_reloc_root() or btrfs_drop_snapshot()and triggers the BUG_ON.After the fix, the same corruption is correctly rejected by tree-checkerand the BUG_ON is no longer triggered. CVE-2026-43053: In the Linux kernel, the following vulnerability has been resolved:xfs: close crash window in attr dabtree inactivationWhen inactivating an inode with node-format extended attributes,xfs_attr3_node_inactive() invalidates all child leaf/node blocks viaxfs_trans_binval(), but intentionally does not remove the correspondingentries from their parent node blocks. The implicit assumption is thatxfs_attr_inactive() will truncate the entire attr fork to zero extentsafterwards, so log recovery will never reach the root node and followthose stale pointers.However, if a log shutdown occurs after the leaf/node block cancellationscommit but before the attr bmap truncation commits, this assumptionbreaks. Recovery replays the attr bmap intact (the inode still hasattr fork extents), but suppresses replay of all cancelled leaf/nodeblocks, maybe leaving them as stale data on disk. On the next mount,xlog_recover_process_iunlinks() retries inactivation and attempts toread the root node via the attr bmap. If the root node was not replayed,reading the unreplayed root block triggers a metadata verificationfailure immediately; if it was replayed, following its child pointersto 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 117Fix this in two places:In xfs_attr3_node_inactive(), after calling xfs_trans_binval() on achild block, immediately remove the entry that references it from theparent node in the same transaction. This eliminates the window wherethe parent holds a pointer to a cancelled block. Once all children areremoved, the now-empty root node is converted to a leaf block within thesame transaction. This node-to-leaf conversion is necessary for crashsafety. If the system shutdown after the empty node is written to thelog but before the second-phase bmap truncation commits, log recoverywill 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 failverification and trigger a metadata corruption shutdown. on the otherhand, leaf blocks are allowed to have this transient state.In xfs_attr_inactive(), split the attr fork truncation into two explicitphases. First, truncate all extents beyond the root block (the childextents whose parent references have already been removed above).Second, invalidate the root block and truncate the attr bmap to zero ina single transaction. The two operations in the second phase must beatomic: as long as the attr bmap has any non-zero length, recovery canfollow it to the root block, so the root block invalidation must committogether with the bmap-to-zero truncation. CVE-2026-43066: In the Linux kernel, the following vulnerability has been resolved:ext4: fix iloc.bh leak in ext4_fc_replay_inode() error pathsDuring code review, Joseph found that ext4_fc_replay_inode() callsext4_get_fc_inode_loc() to get the inode location, which holds areference to iloc.bh that must be released via brelse().However, several error paths jump to the 'out' label withoutreleasing iloc.bh: - ext4_handle_dirty_metadata() failure - sync_dirty_buffer() failure - ext4_mark_inode_used() failure - ext4_iget() failureFix this by introducing an 'out_brelse' label placed just beforethe existing 'out' label to ensure iloc.bh is always released.Additionally, make ext4_fc_replay_inode() propagate errorsproperly instead of always returning 0. CVE-2026-43068: In the Linux kernel, the following vulnerability has been resolved:ext4: avoid allocate block from corrupted group in ext4_mb_find_by_goal()There's issue as follows:...EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117EXT4-fs (mmcblk0p1): This should not happen!! Data will be lostEXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117EXT4-fs (mmcblk0p1): This should not happen!! Data will be lostEXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117EXT4-fs (mmcblk0p1): This should not happen!! Data will be lostEXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117EXT4-fs (mmcblk0p1): This should not happen!! Data will be lostEXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2243 at logical offset 0 with max blocks 1 with error 117EXT4-fs (mmcblk0p1): This should not happen!! Data will be lostEXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2239 at logical offset 0 with max blocks 1 with error 117EXT4-fs (mmcblk0p1): This should not happen!! Data will be lostEXT4-fs (mmcblk0p1): error count since last fsck: 1EXT4-fs (mmcblk0p1): initial error at time 1765597433: ext4_mb_generate_buddy:760EXT4-fs (mmcblk0p1): last error at time 1765597433: ext4_mb_generate_buddy:760...According to the log analysis, blocks are always requested from thecorrupted block group. This may happen as follows:ext4_mb_find_by_goal ext4_mb_load_buddy ext4_mb_load_buddy_gfp ext4_mb_init_cache ext4_read_block_bitmap_nowait ext4_wait_block_bitmap ext4_validate_block_bitmap if (!grp || EXT4_MB_GRP_BBITMAP_CORRUPT(grp)) return -EFSCORRUPTED; // There's no logs. if (err) return err; // Will return errorext4_lock_group(ac->ac_sb, group); if (unlikely(EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info))) // Unreachable goto out;After commit 9008a58e5dce ("ext4: make the bitmap read routines returnreal error codes") merged, Commit 163a203ddb36 ("ext4: mark block groupas corrupt on block bitmap error") is no real solution for allocatingblocks from corrupted block groups. This is because if'EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info)' is true, then'ext4_mb_load_buddy()' may return an error. This means that the blockallocation will fail.Therefore, check block group if corrupted when ext4_mb_load_buddy()returns error. CVE-2026-43074: In the Linux kernel, the following vulnerability has been resolved:eventpoll: defer struct eventpoll free to RCU grace periodIn certain situations, ep_free() in eventpoll.c will kfree the epi->epeventpoll struct while it still being used by another concurrent thread.Defer the kfree() to an RCU callback to prevent UAF. CVE-2026-43125: In the Linux kernel, the following vulnerability has been resolved:dlm: validate length in dlm_search_rsb_treeThe len parameter in dlm_dump_rsb_name() is not validated and comesfrom network messages. When it exceeds DLM_RESNAME_MAXLEN, it cancause out-of-bounds write in dlm_search_rsb_tree().Add length validation to prevent potential buffer overflow. CVE-2026-43153: In the Linux kernel, the following vulnerability has been resolved:xfs: remove xfs_attr_leaf_hasnameThe calling convention of xfs_attr_leaf_hasname() is problematic, becauseit returns a NULL buffer when xfs_attr3_leaf_read fails, a valid bufferwhen xfs_attr3_leaf_lookup_int returns -ENOATTR or -EEXIST, and anon-NULL buffer pointer for an already released buffer whenxfs_attr3_leaf_lookup_int fails with other error values.Fix this by simply open coding xfs_attr_leaf_hasname in the callers, sothat the buffer release code is done by each caller ofxfs_attr3_leaf_read. CVE-2026-43168: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix reflink preserve cleanup issuecommit c06c303832ec ("ocfs2: fix xattr array entry __counted_by error")doesn't handle all cases and the cleanup job for preserved xattr entriesstill has bug:- the 'last' pointer should be shifted by one unit after cleanup an array entry.- current code logic doesn't cleanup the first entry when xh_count is 1.Note, commit c06c303832ec is also a bug fix for 0fe9b66c65f3. CVE-2026-43200: In the Linux kernel, the following vulnerability has been resolved:PCI: endpoint: Fix swapped parameters in pci_{primary/secondary}_epc_epf_unlink() functionsstruct configfs_item_operations callbacks are defined like the following: int (*allow_link)(struct config_item *src, struct config_item *target); void (*drop_link)(struct config_item *src, struct config_item *target);While pci_primary_epc_epf_link() and pci_secondary_epc_epf_link() specifythe parameters in the correct order, pci_primary_epc_epf_unlink() andpci_secondary_epc_epf_unlink() specify the parameters in the wrong order,leading to the below kernel crash when using the unlink command inconfigfs: Unable to handle kernel paging request at virtual address 0000000300000857 Mem abort info: ... pc : string+0x54/0x14c lr : vsnprintf+0x280/0x6e8 ... string+0x54/0x14c vsnprintf+0x280/0x6e8 vprintk_default+0x38/0x4c vprintk+0xc4/0xe0 pci_epf_unbind+0xdc/0x108 configfs_unlink+0xe0/0x208+0x44/0x74 vfs_unlink+0x120/0x29c __arm64_sys_unlinkat+0x3c/0x90 invoke_syscall+0x48/0x134 do_el0_svc+0x1c/0x30prop.0+0xd0/0xf0[mani: cced stable, changed commit message as per https://lore.kernel.org/linux-pci/aV9joi3jF1R6ca02@ryzen] CVE-2026-43211: In the Linux kernel, the following vulnerability has been resolved:PCI: Fix pci_slot_trylock() error handlingCommit a4e772898f8b ("PCI: Add missing bridge lock to pci_bus_lock()")delegates the bridge device's pci_dev_trylock() to pci_bus_trylock() inpci_slot_trylock(), but it forgets to remove the correspondingpci_dev_unlock() when pci_bus_trylock() fails.Before a4e772898f8b, the code did: if (!pci_dev_trylock(dev)) /* <- lock bridge device */ goto unlock; if (dev->subordinate) { if (!pci_bus_trylock(dev->subordinate)) { pci_dev_unlock(dev); /* <- unlock bridge device */ goto unlock; } }After a4e772898f8b the bridge-device lock is no longer taken, but thepci_dev_unlock(dev) on the failure path was left in place, leading to thebug.This yields one of two errors: 1. A warning that the lock is being unlocked when no one holds it. 2. An incorrect unlock of a lock that belongs to another thread.Fix it by removing the now-redundant pci_dev_unlock(dev) on the failurepath.[Same patch later posted by Keith athttps://patch.msgid.link/[email protected]] CVE-2026-43262: In the Linux kernel, the following vulnerability has been resolved:gfs2: fiemap page fault fixIn gfs2_fiemap(), we are calling iomap_fiemap() while holding the inodeglock. This can lead to recursive glock taking if the fiemap buffer ismemory mapped to the same inode and accessing it triggers a page fault.Fix by disabling page faults for iomap_fiemap() and faulting in thebuffer by hand if necessary.Fixes xfstest generic/742. CVE-2026-43288: In the Linux kernel, the following vulnerability has been resolved:ext4: move ext4_percpu_param_init() before ext4_mb_init()When running `kvm-xfstests -c ext4/1k -C 1 generic/383` with the`DOUBLE_CHECK` macro defined, the following panic is triggered:==================================================================EXT4-fs error (device vdc): ext4_validate_block_bitmap:423: comm mount: bg 0: bad block bitmap checksumBUG: unable to handle page fault for address: ff110000fa2cc000PGD 3e01067 P4D 3e02067 PUD 0Oops: Oops: 0000 [#1] SMP NOPTICPU: 0 UID: 0 PID: 2386 Comm: mount Tainted: G W 6.18.0-gba65a4e7120a-dirty #1152 PREEMPT(none)RIP: 0010:percpu_counter_add_batch+0x13/0xa0Call Trace: <TASK> ext4_mark_group_bitmap_corrupted+0xcb/0xe0 ext4_validate_block_bitmap+0x2a1/0x2f0 ext4_read_block_bitmap+0x33/0x50 mb_group_bb_bitmap_alloc+0x33/0x80 ext4_mb_add_groupinfo+0x190/0x250 ext4_mb_init_backend+0x87/0x290 ext4_mb_init+0x456/0x640 __ext4_fill_super+0x1072/0x1680 ext4_fill_super+0xd3/0x280 get_tree_bdev_flags+0x132/0x1d0 vfs_get_tree+0x29/0xd0 vfs_cmd_create+0x59/0xe0 __do_sys_fsconfig+0x4f6/0x6b0 do_syscall_64+0x50/0x1f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e==================================================================This issue can be reproduced using the following commands: mkfs.ext4 -F -q -b 1024 /dev/sda 5G tune2fs -O quota,project /dev/sda mount /dev/sda /tmp/testWith DOUBLE_CHECK defined, mb_group_bb_bitmap_alloc() readsand validates the block bitmap. When the validation fails,ext4_mark_group_bitmap_corrupted() attempts to updatesbi->s_freeclusters_counter. However, this percpu_counter has not beeninitialized yet at this point, which leads to the panic described above.Fix this by moving the execution of ext4_percpu_param_init() to occurbefore ext4_mb_init(), ensuring the per-CPU counters are initializedbefore they are used. 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 criticalpath, btrfs flips RO (this part is expected, although the ENOSPC bugstill needs to be addressed).The problem is after the RO flip, if there is a read repair pending, wecan 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 stillunknown, although it's known that we still have cases where metadata canbe over-committed but can not be fulfilled correctly, thus if we hitsuch ENOSPC error inside a critical path, we have no choice but abortthe current transaction.This will mark the fs read-only.The problem is inside the btrfs_repair_io_failure() path that we requirethe fs not to be mount read-only. This is normally fine, but if we aredoing a read-repair meanwhile the fs flips RO due to a critical error,we can enter btrfs_repair_io_failure() with super block set toread-only, thus triggering the above crash.[FIX]Just replace the ASSERT() with a proper return if the fs is alreadyread-only. CVE-2026-43338: In the Linux kernel, the following vulnerability has been resolved:btrfs: reserve enough transaction items for qgroup ioctlsCurrently our qgroup ioctls don't reserve any space, they just do atransaction join, which does not reserve any space, neither for the quotatree updates nor for the delayed refs generated when updating the quotatree. The quota root uses the global block reserve, which is fine most ofthe time since we don't expect a lot of updates to the quota root, or tobe too close to -ENOSPC such that other critical metadata updates need toresort to the global reserve.However this is not optimal, as not reserving proper space may result in atransaction abort due to not reserving space for delayed refs and thenabusing the use of the global block reserve.For example, the following reproducer (which is unlikely to model anyreal world use case, but just to illustrate the problem), triggers such atransaction 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 $MNTWhen running this, we can see in dmesg/syslog that a transaction aborthappened: [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-43350: In the Linux kernel, the following vulnerability has been resolved:smb: client: require a full NFS mode SID before reading mode bitsparse_dacl() treats an ACE SID matching sid_unix_NFS_mode as an NFSmode SID and reads sid.sub_auth[2] to recover the mode bits.That assumes the ACE carries three subauthorities, but compare_sids()only compares min(a, b) subauthorities. A malicious server can returnan ACE with num_subauth = 2 and sub_auth[] = {88, 3}, which stillmatches sid_unix_NFS_mode and then drives the sub_auth[2] read fourbytes past the end of the ACE.Require num_subauth >= 3 before treating the ACE as an NFS mode SID.This keeps the fix local to the special-SID mode path without changingcompare_sids() semantics for the rest of cifsacl. CVE-2026-43359: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix transaction abort on set received ioctl due to item overflowIf the set received ioctl fails due to an item overflow when attempting toadd the BTRFS_UUID_KEY_RECEIVED_SUBVOL we have to abort the transactionsince we did some metadata updates before.This means that if a user calls this ioctl with the same received UUIDfield for a lot of subvolumes, we will hit the overflow, trigger thetransaction abort and turn the filesystem into RO mode. A malicious usercould exploit this, and this ioctl does not even requires that a userhas admin privileges (CAP_SYS_ADMIN), only that he/she owns the subvolume.Fix this by doing an early check for item overflow before starting atransaction. This is also race safe because we are holding the subvol_semsemaphore in exclusive (write) mode.A test case for fstests will follow soon. CVE-2026-43360: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix transaction abort on file creation due to name hash collisionIf we attempt to create several files with names that result in the samehash, we have to pack them in same dir item and that has a limit inherentto the leaf size. However if we reach that limit, we trigger a transactionabort and turns the filesystem into RO mode. This allows for a malicioususer to disrupt a system, without the need to have administrationprivileges/capabilities.Reproducer: $ cat exploit-hash-collisions.sh #!/bin/bash DEV=/dev/sdi MNT=/mnt/sdi # Use smallest node size to make the test faster and require fewer file # names that result in hash collision. mkfs.btrfs -f --nodesize 4K $DEV mount $DEV $MNT # List of names that result in the same crc32c hash for btrfs. declare -a names=( 'foobar' '%a8tYkxfGMLWRGr55QSeQc4PBNH9PCLIvR6jZnkDtUUru1t@RouaUe_L:@xGkbO3nCwvLNYeK9vhE628gss:T$yZjZ5l-Nbd6CbC$M=hqE-ujhJICXyIxBvYrIU9-TDC' 'AQci3EUB%shMsg-N%frgU:02ByLs=IPJU0OpgiWit5nexSyxZDncY6WB:=zKZuk5Zy0DD$Ua78%MelgBuMqaHGyKsJUFf9s=UW80PcJmKctb46KveLSiUtNmqrMiL9-Y0I_l5Fnam04CGIg=8@U:Z' 'CvVqJpJzueKcuA$wqwePfyu7VxuWNN3ho$p0zi2H8QFYK$7YlEqOhhb%:hHgjhIjW5vnqWHKNP4' 'ET:vk@rFU4tsvMB0$C_p=xQHaYZjvoF%-BTc%wkFW8yaDAPcCYoR%x$FH5O:' 'HwTon%v7SGSP4FE08jBwwiu5aot2CFKXHTeEAa@38fUcNGOWvE@Mz6WBeDH_VooaZ6AgsXPkVGwy9l@@ZbNXabUU9csiWrrOp0MWUdfi$EZ3w9GkIqtz7I_eOsByOkBOO' 'Ij%2VlFGXSuPvxJGf5UWy6O@1svxGha%b@=%wjkq:CIgE6u7eJOjmQY5qTtxE2Rjbis9@us' 'KBkjG5%9R8K9sOG8UTnAYjxLNAvBmvV5vz3IiZaPmKuLYO03-6asI9lJ_j4@6Xo$KZicaLWJ3Pv8XEwVeUPMwbHYWwbx0pYvNlGMO9F:ZhHAwyctnGy%_eujl%WPd4U2BI7qooOSr85J-C2V$LfY' 'NcRfDfuUQ2=zP8K3CCF5dFcpfiOm6mwenShsAb_F%n6GAGC7fT2JFFn:c35X-3aYwoq7jNX5$ZJ6hI3wnZs$7KgGi7wjulffhHNUxAT0fRRLF39vJ@NvaEMxsMO' 'Oj42AQAEzRoTxa5OuSKIr=A_lwGMy132v4g3Pdq1GvUG9874YseIFQ6QU' 'Ono7avN5GjC:_6dBJ_' 'WHmN2gnmaN-9dVDy4aWo:yNGFzz8qsJyJhWEWcud7$QzN2D9R0efIWWEdu5kwWr73NZm4=@CoCDxrrZnRITr-kGtU_cfW2:%2_am' 'WiFnuTEhAG9FEC6zopQmj-A-$LDQ0T3WULz%ox3UZAPybSV6v1Z$b4L_XBi4M4BMBtJZpz93r9xafpB77r:lbwvitWRyo$odnAUYlYMmU4RvgnNd--e=I5hiEjGLETTtaScWlQp8mYsBovZwM2k' 'XKyH=OsOAF3p%uziGF_ZVr$ivrvhVgD@1u%5RtrV-gl_vqAwHkK@x7YwlxX3qT6WKKQ%PR56NrUBU2dOAOAdzr2=5nJuKPM-T-$ZpQfCL7phxQbUcb:BZOTPaFExc-qK-gDRCDW2' 'd3uUR6OFEwZr%ns1XH_@tbxA@cCPmbBRLdyh7p6V45H$P2$F%w0RqrD3M0g8aGvWpoTFMiBdOTJXjD:JF7=h9a_43xBywYAP%r$SPZi%zDg%ql-KvkdUCtF9OLaQlxmd' 'ePTpbnit%hyNm@WELlpKzNZYOzOTf8EQ$sEfkMy1VOfIUu3coyvIr13-Y7Sv5v-Ivax2Go_GQRFMU1b3362nktT9WOJf3SpT%z8sZmM3gvYQBDgmKI%%RM-G7hyrhgYflOw%z::ZRcv5O:lDCFm' 'evqk743Y@dvZAiG5J05L_ROFV@$2%rVWJ2%3nxV72-W7$e$-SK3tuSHA2mBt$qloC5jwNx33GmQUjD%akhBPu=VJ5g$xhlZiaFtTrjeeM5x7dt4cHpX0cZkmfImndYzGmvwQG:$euFYmXn$_2rA9mKZ' 'gkgUtnihWXsZQTEkrMAWIxir09k3t7jk_IK25t1:cy1XWN0GGqC%FrySdcmU7M8MuPO_ppkLw3=Dfr0UuBAL4%GFk2$Ma10V1jDRGJje%Xx9EV2ERaWKtjpwiZwh0gCSJsj5UL7CR8RtW5opCVFKGGy8Cky' 'hNgsG_8lNRik3PvphqPm0yEH3P%%fYG:kQLY=6O-61Wa6nrV_WVGR6TLB09vHOv%g4VQRP8Gzx7VXUY1qvZyS' 'isA7JVzN12xCxVPJZ_qoLm-pTBuhjjHMvV7o=F:EaClfYNyFGlsfw-Kf%uxdqW-kwk1sPl2vhbjyHU1A6$hz' 'kiJ_fgcdZFDiOptjgH5PN9-PSyLO4fbk_:u5_2tz35lV_iXiJ6cx7pwjTtKy-XGaQ5IefmpJ4N_ZqGsqCsKuqOOBgf9LkUdffHet@Wu' 'lvwtxyhE9:%Q3UxeHiViUyNzJsy:fm38pg_b6s25JvdhOAT=1s0$pG25x=LZ2rlHTszj=gN6M4zHZYr_qrB49i=pA--@WqWLIuX7o1S_SfS@2FSiUZN' 'rC24cw3UBDZ=5qJBUMs9e$=S4Y94ni%Z8639vnrGp=0Hv4z3dNFL0fBLmQ40=EYIY:Z=SLc@QLMSt2zsss2ZXrP7j4=' 'uwGl2s-fFrf@GqS=DQqq2I0LJSsOmM%xzTjS:lzXguE3wChdMoHYtLRKPvfaPOZF2fER@j53evbKa7R%A7r4%YEkD=kicJe@SFiGtXHbKe4gCgPAYbnVn' 'UG37U6KKua2bgc:IHzRs7BnB6FD:2Mt5Cc5NdlsW%$1tyvnfz7S27FvNkroXwAW:mBZLA1@qa9WnDbHCDmQmfPMC9z-Eq6QT0jhhPpqyymaD:R02ghwYo%yx7SAaaq-:x33LYpei$5g8DMl3C' 'y2vjek0FE1PDJC0qpfnN:x8k2wCFZ9xiUF2ege=JnP98R%wxjKkdfEiLWvQzmnW' '8-HCSgH5B%K7P8_jaVtQhBXpBk:pE-$P7ts58U0J@iR9YZntMPl7j$s62yAJO@_9eanFPS54b=UTw$94C-t=HLxT8n6o9P=QnIxq-f1=Ne2dvhe6WbjEQtc' 'YPPh:IFt2mtR6XWSmjHptXL_hbSYu8bMw-JP8@PNyaFkdNFsk$M=xfL6LDKCDM-mSyGA_2MBwZ8Dr4=R1D%7-mC---truncated--- CVE-2026-43361: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix transaction abort when snapshotting received subvolumesCurrently a user can trigger a transaction abort by snapshotting apreviously received snapshot a bunch of times until we reach aBTRFS_UUID_KEY_RECEIVED_SUBVOL item overflow (the maximum item size wecan store in a leaf). This is very likely not common in practice, butif it happens, it turns the filesystem into RO mode. The snapshot, sendand set_received_subvol and subvol_setflags (used by receive) don'trequire CAP_SYS_ADMIN, just inode_owner_or_capable(). A malicious usercould use this to turn a filesystem into RO mode and disrupt a system.Reproducer script: $ cat test.sh #!/bin/bash DEV=/dev/sdi MNT=/mnt/sdi # Use smallest node size to make the test faster. mkfs.btrfs -f --nodesize 4K $DEV mount $DEV $MNT # Create a subvolume and set it to RO so that it can be used for send. btrfs subvolume create $MNT/sv touch $MNT/sv/foo btrfs property set $MNT/sv ro true # Send and receive the subvolume into snaps/sv. mkdir $MNT/snaps btrfs send $MNT/sv | btrfs receive $MNT/snaps # Now snapshot the received subvolume, which has a received_uuid, a # lot of times to trigger the leaf overflow. total=500 for ((i = 1; i <= $total; i++)); do echo -ne "\rCreating snapshot $i/$total" btrfs subvolume snapshot -r $MNT/snaps/sv $MNT/snaps/sv_$i > /dev/null done echo umount $MNTWhen running the test: $ ./test.sh (...) Create subvolume '/mnt/sdi/sv' At subvol /mnt/sdi/sv At subvol sv Creating snapshot 496/500ERROR: Could not create subvolume: Value too large for defined data type Creating snapshot 497/500ERROR: Could not create subvolume: Read-only file system Creating snapshot 498/500ERROR: Could not create subvolume: Read-only file system Creating snapshot 499/500ERROR: Could not create subvolume: Read-only file system Creating snapshot 500/500ERROR: Could not create subvolume: Read-only file systemAnd in dmesg/syslog: $ dmesg (...) [251067.627338] BTRFS warning (device sdi): insert uuid item failed -75 (0x4628b21c4ac8d898, 0x2598bee2b1515c91) type 252! [251067.629212] ------------[ cut here ]------------ [251067.630033] BTRFS: Transaction aborted (error -75) [251067.630871] WARNING: fs/btrfs/transaction.c:1907 at create_pending_snapshot.cold+0x52/0x465 [btrfs], CPU#10: btrfs/615235 [251067.632851] Modules linked in: btrfs dm_zero (...) [251067.644071] CPU: 10 UID: 0 PID: 615235 Comm: btrfs Tainted: G W 6.19.0-rc8-btrfs-next-225+ #1 PREEMPT(full) [251067.646165] Tainted: [W]=WARN [251067.646733] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 [251067.648735] RIP: 0010:create_pending_snapshot.cold+0x55/0x465 [btrfs] [251067.649984] Code: f0 48 0f (...) [251067.653313] RSP: 0018:ffffce644908fae8 EFLAGS: 00010292 [251067.653987] RAX: 00000000ffffff01 RBX: ffff8e5639e63a80 RCX: 00000000ffffffd3 [251067.655042] RDX: ffff8e53faa76b00 RSI: 00000000ffffffb5 RDI: ffffffffc0919750 [251067.656077] RBP: ffffce644908fbd8 R08: 0000000000000000 R09: ffffce644908f820 [251067.657068] R10: ffff8e5adc1fffa8 R11: 0000000000000003 R12: ffff8e53c0431bd0 [251067.658050] R13: ffff8e5414593600 R14: ffff8e55efafd000 R15: 00000000ffffffb5 [251067.659019] FS: 00007f2a4944b3c0(0000) GS:ffff8e5b27dae000(0000) knlGS:0000000000000000 [251067.660115] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [251067.660943] CR2: 00007ffc5aa57898 CR3: 00000005813a2003 CR4: 0000000000370ef0 [251067.661972] Call Trace: [251067.662292] <TASK> [251067.662653] create_pending_snapshots+0x97/0xc0 [btrfs] [251067.663413] btrfs_commit_transaction+0x26e/0xc00 [btrfs] [251067.664257] ? btrfs_qgroup_convert_reserved_meta+0x35/0x390 [btrfs] [251067.665238] ? _raw_spin_unlock+0x15/0x30 [251067.665837] ? record_root_---truncated--- 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 withciphertext. 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 areunstable, as reconnects trigger write retries that re-send thealready-encrypted data.This affects SFU mknod, MF symlinks, etc. On kernels before6.10 (prior to the netfs conversion), sync writes also usedthis path and were similarly affected. The async write pathwasn'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-43366: In the Linux kernel, the following vulnerability has been resolved:io_uring/kbuf: check if target buffer list is still legacy on recycleThere's a gap between when the buffer was grabbed and when itpotentially gets recycled, where if the list is empty, someone could'veupgraded it to a ring provided type. This can happen if the requestis forced via io-wq. The legacy recycling is missing checking if thebuffer_list still exists, and if it's of the correct type. Add thosechecks. CVE-2026-43376: In the Linux kernel, the following vulnerability has been resolved:ksmbd: fix use-after-free by using call_rcu() for oplock_infoksmbd currently frees oplock_info immediately using kfree(), eventhough it is accessed under RCU read-side critical sections in placeslike opinfo_get() and proc_show_files().Since there is no RCU grace period delay between nullifying the pointerand freeing the memory, a reader can still access oplock_infostructure after it has been freed. This can leads to a use-after-freeespecially in opinfo_get() where atomic_inc_not_zero() is called onalready freed memory.Fix this by switching to deferred freeing using call_rcu(). CVE-2026-43377: In the Linux kernel, the following vulnerability has been resolved:ksmbd: Don't log keys in SMB3 signing and encryption key generationWhen KSMBD_DEBUG_AUTH logging is enabled, generate_smb3signingkey() andgenerate_smb3encryptionkey() log the session, signing, encryption, anddecryption key bytes. Remove the logs to avoid exposing credentials. CVE-2026-43379: In the Linux kernel, the following vulnerability has been resolved:ksmbd: fix use-after-free in smb_lazy_parent_lease_break_close()opinfo pointer obtained via rcu_dereference(fp->f_opinfo) is beingaccessed after rcu_read_unlock() has been called. This creates arace condition where the memory could be freed by a concurrentwriter between the unlock and the subsequent pointer dereferences(opinfo->is_lease, etc.), leading to a use-after-free. CVE-2026-43414: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Completely fix fcport double freeIn 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-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 notpassed to the caller via path_info.path, the function must free itbefore returning. CVE-2026-43420: In the Linux kernel, the following vulnerability has been resolved:ceph: fix i_nlink underrun during async unlinkDuring async unlink, we drop the `i_nlink` counter before we receivethe completion (that will eventually update the `i_nlink`) because "weassume that the unlink will succeed". That is not a bad idea, but itraces against deletions by other clients (or against the completion ofour own unlink) and can lead to an underrun which emits a WARNING likethis one: WARNING: CPU: 85 PID: 25093 at fs/inode.c:407 drop_nlink+0x50/0x68 Modules linked in: CPU: 85 UID: 3221252029 PID: 25093 Comm: php-cgi8.1 Not tainted 6.14.11-cm4all1-ampere #655 Hardware name: Supermicro ARS-110M-NR/R12SPD-A, BIOS 1.1b 10/17/2023 pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : drop_nlink+0x50/0x68 lr : ceph_unlink+0x6c4/0x720 sp : ffff80012173bc90 x29: ffff80012173bc90 x28: ffff086d0a45aaf8 x27: ffff0871d0eb5680 x26: ffff087f2a64a718 x25: 0000020000000180 x24: 0000000061c88647 x23: 0000000000000002 x22: ffff07ff9236d800 x21: 0000000000001203 x20: ffff07ff9237b000 x19: ffff088b8296afc0 x18: 00000000f3c93365 x17: 0000000000070000 x16: ffff08faffcbdfe8 x15: ffff08faffcbdfec x14: 0000000000000000 x13: 45445f65645f3037 x12: 34385f6369706f74 x11: 0000a2653104bb20 x10: ffffd85f26d73290 x9 : ffffd85f25664f94 x8 : 00000000000000c0 x7 : 0000000000000000 x6 : 0000000000000002 x5 : 0000000000000081 x4 : 0000000000000481 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff08727d3f91e8 Call trace: drop_nlink+0x50/0x68 (P) vfs_unlink+0xb0/0x2e8 do_unlinkat+0x204/0x288 __arm64_sys_unlinkat+0x3c/0x80 invoke_syscall.constprop.0+0x54/0xe8 do_el0_svc+0xa4/0xc8 el0_svc+0x18/0x58 el0t_64_sync_handler+0x104/0x130 el0t_64_sync+0x154/0x158In ceph_unlink(), a call to ceph_mdsc_submit_request() submits theCEPH_MDS_OP_UNLINK to the MDS, but does not wait for completion.Meanwhile, between this call and the following drop_nlink() call, aworker thread may process a CEPH_CAP_OP_IMPORT, CEPH_CAP_OP_GRANT orjust a CEPH_MSG_CLIENT_REPLY (the latter of which could be our owncompletion). These will lead to a set_nlink() call, updating the`i_nlink` counter to the value received from the MDS. If that new`i_nlink` value happens to be zero, it is illegal to decrement itfurther. But that is exactly what ceph_unlink() will do then.The WARNING can be reproduced this way:1. Force async unlink; only the async code path is affected. Having no real clue about Ceph internals, I was unable to find out why the MDS wouldn't give me the "Fxr" capabilities, so I patched get_caps_for_async_unlink() to always succeed. (Note that the WARNING dump above was found on an unpatched kernel, without this kludge - this is not a theoretical bug.)2. Add a sleep call after ceph_mdsc_submit_request() so the unlink completion gets handled by a worker thread before drop_nlink() is called. This guarantees that the `i_nlink` is already zero before drop_nlink() runs.The solution is to skip the counter decrement when it is already zero,but doing so without a lock is still racy (TOCTOU). Sinceceph_fill_inode() and handle_cap_grant() both hold the`ceph_inode_info.i_ceph_lock` spinlock while set_nlink() runs, thisseems like the proper lock to protect the `i_nlink` updates.I found prior art in NFS and SMB (using `inode.i_lock`) and AFS (using`afs_vnode.cb_lock`). All three have the zero check as well. CVE-2026-43448: In the Linux kernel, the following vulnerability has been resolved:nvme-pci: Fix race bug in nvme_poll_irqdisable()In the following scenario, pdev can be disabled between (1) and (3) by(2). This sets pdev->msix_enabled = 0. Then, pci_irq_vector() willreturn MSI-X IRQ(>15) for (1) whereas return INTx IRQ(<=15) for (2).This causes IRQ warning because it tries to enable INTx IRQ that hasnever been disabled before.To fix this, save IRQ number into a local variable and ensuredisable_irq() and enable_irq() operate on the same IRQ number. Even ifpci_free_irq_vectors() frees the IRQ concurrently, disable_irq() andenable_irq() on a stale IRQ number is still valid and safe, and thedepth accounting reamins balanced.task 1:nvme_poll_irqdisable() disable_irq(pci_irq_vector(pdev, nvmeq->cq_vector)) ...(1) enable_irq(pci_irq_vector(pdev, nvmeq->cq_vector)) ...(3)task 2:nvme_reset_work() nvme_dev_disable() pdev->msix_enable = 0; ...(2)crash log:------------[ cut here ]------------Unbalanced enable for IRQ 10WARNING: kernel/irq/manage.c:753 at __enable_irq+0x102/0x190 kernel/irq/manage.c:753, CPU#1: kworker/1:0H/26Modules linked in:CPU: 1 UID: 0 PID: 26 Comm: kworker/1:0H Not tainted 6.19.0-dirty #9 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014Workqueue: kblockd blk_mq_timeout_workRIP: 0010:__enable_irq+0x107/0x190 kernel/irq/manage.c:753Code: ff df 48 89 fa 48 c1 ea 03 0f b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 04 84 d2 75 79 48 8d 3d 2e 7a 3f 05 41 8b 74 24 2c <67> 48 0f b9 3a e8 ef b9 21 00 5b 41 5c 5d e9 46 54 66 03 e8 e1 b9RSP: 0018:ffffc900001bf550 EFLAGS: 00010046RAX: 0000000000000007 RBX: 0000000000000000 RCX: ffffffffb20c0e90RDX: 0000000000000000 RSI: 000000000000000a RDI: ffffffffb74b88f0RBP: ffffc900001bf560 R08: ffff88800197cf00 R09: 0000000000000001R10: 0000000000000003 R11: 0000000000000003 R12: ffff8880012a6000R13: 1ffff92000037eae R14: 000000000000000a R15: 0000000000000293FS: 0000000000000000(0000) GS:ffff8880b49f7000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000555da4a25fa8 CR3: 00000000208e8000 CR4: 00000000000006f0Call Trace: <TASK> enable_irq+0x121/0x1e0 kernel/irq/manage.c:797 nvme_poll_irqdisable+0x162/0x1c0 drivers/nvme/host/pci.c:1494 nvme_timeout+0x965/0x14b0 drivers/nvme/host/pci.c:1744 blk_mq_rq_timed_out block/blk-mq.c:1653 [inline] blk_mq_handle_expired+0x227/0x2d0 block/blk-mq.c:1721 bt_iter+0x2fc/0x3a0 block/blk-mq-tag.c:292 __sbitmap_for_each_set include/linux/sbitmap.h:269 [inline] sbitmap_for_each_set include/linux/sbitmap.h:290 [inline] bt_for_each block/blk-mq-tag.c:324 [inline] blk_mq_queue_tag_busy_iter+0x969/0x1e80 block/blk-mq-tag.c:536 blk_mq_timeout_work+0x627/0x870 block/blk-mq.c:1763 process_one_work+0x956/0x1aa0 kernel/workqueue.c:3257 process_scheduled_works kernel/workqueue.c:3340 [inline] worker_thread+0x65c/0xe60 kernel/workqueue.c:3421 kthread+0x41a/0x930 kernel/kthread.c:463 ret_from_fork+0x6f8/0x8c0 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 </TASK>irq event stamp: 74478hardirqs last enabled at (74477): [<ffffffffb5720a9c>] __raw_spin_unlock_irq include/linux/spinlock_api_smp.h:159 [inline]hardirqs last enabled at (74477): [<ffffffffb5720a9c>] _raw_spin_unlock_irq+0x2c/0x60 kernel/locking/spinlock.c:202hardirqs last disabled at (74478): [<ffffffffb57207b5>] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline]hardirqs last disabled at (74478): [<ffffffffb57207b5>] _raw_spin_lock_irqsave+0x85/0xa0 kernel/locking/spinlock.c:162softirqs last enabled at (74304): [<ffffffffb1e9466c>] __do_softirq kernel/softirq.c:656 [inline]softirqs last enabled at (74304): [<ffffffffb1e9466c>] invoke_softirq kernel/softirq.c:496 [inline]softirqs last enabled at (74304): [<ffffffffb1e9466c>] __irq_exit_rcu+0xdc/0x120---truncated--- CVE-2026-43449: In the Linux kernel, the following vulnerability has been resolved:nvme-pci: Fix slab-out-of-bounds in nvme_dbbuf_setdev->online_queues is a count incremented in nvme_init_queue. Thus,valid indices are 0 through dev->online_queues − 1.This patch fixes the loop condition to ensure the index stays within thevalid range. Index 0 is excluded because it is the admin queue.KASAN splat:==================================================================BUG: KASAN: slab-out-of-bounds in nvme_dbbuf_free drivers/nvme/host/pci.c:377 [inline]BUG: KASAN: slab-out-of-bounds in nvme_dbbuf_set+0x39c/0x400 drivers/nvme/host/pci.c:404Read of size 2 at addr ffff88800592a574 by task kworker/u8:5/74CPU: 0 UID: 0 PID: 74 Comm: kworker/u8:5 Not tainted 6.19.0-dirty #10 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014Workqueue: nvme-reset-wq nvme_reset_workCall Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xea/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xce/0x5d0 mm/kasan/report.c:482 kasan_report+0xdc/0x110 mm/kasan/report.c:595 __asan_report_load2_noabort+0x18/0x20 mm/kasan/report_generic.c:379 nvme_dbbuf_free drivers/nvme/host/pci.c:377 [inline] nvme_dbbuf_set+0x39c/0x400 drivers/nvme/host/pci.c:404 nvme_reset_work+0x36b/0x8c0 drivers/nvme/host/pci.c:3252 process_one_work+0x956/0x1aa0 kernel/workqueue.c:3257 process_scheduled_works kernel/workqueue.c:3340 [inline] worker_thread+0x65c/0xe60 kernel/workqueue.c:3421 kthread+0x41a/0x930 kernel/kthread.c:463 ret_from_fork+0x6f8/0x8c0 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 </TASK>Allocated by task 34 on cpu 1 at 4.241550s: kasan_save_stack+0x2c/0x60 mm/kasan/common.c:57 kasan_save_track+0x1c/0x70 mm/kasan/common.c:78 kasan_save_alloc_info+0x3c/0x50 mm/kasan/generic.c:570 poison_kmalloc_redzone mm/kasan/common.c:398 [inline] __kasan_kmalloc+0xb5/0xc0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 [inline] __do_kmalloc_node mm/slub.c:5657 [inline] __kmalloc_node_noprof+0x2bf/0x8d0 mm/slub.c:5663 kmalloc_array_node_noprof include/linux/slab.h:1075 [inline] nvme_pci_alloc_dev drivers/nvme/host/pci.c:3479 [inline] nvme_probe+0x2f1/0x1820 drivers/nvme/host/pci.c:3534 local_pci_probe+0xef/0x1c0 drivers/pci/pci-driver.c:324 pci_call_probe drivers/pci/pci-driver.c:392 [inline] __pci_device_probe drivers/pci/pci-driver.c:417 [inline] pci_device_probe+0x743/0x920 drivers/pci/pci-driver.c:451 call_driver_probe drivers/base/dd.c:583 [inline] really_probe+0x29b/0xb70 drivers/base/dd.c:661 __driver_probe_device+0x3b0/0x4a0 drivers/base/dd.c:803 driver_probe_device+0x56/0x1f0 drivers/base/dd.c:833 __driver_attach_async_helper+0x155/0x340 drivers/base/dd.c:1159 async_run_entry_fn+0xa6/0x4b0 kernel/async.c:129 process_one_work+0x956/0x1aa0 kernel/workqueue.c:3257 process_scheduled_works kernel/workqueue.c:3340 [inline] worker_thread+0x65c/0xe60 kernel/workqueue.c:3421 kthread+0x41a/0x930 kernel/kthread.c:463 ret_from_fork+0x6f8/0x8c0 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246The buggy address belongs to the object at ffff88800592a000 which belongs to the cache kmalloc-2k of size 2048The buggy address is located 244 bytes to the right of allocated 1152-byte region [ffff88800592a000, ffff88800592a480)The buggy address belongs to the physical page:page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x5928head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0anon flags: 0xfffffc0000040(head|node=0|zone=1|lastcpupid=0x1fffff)page_type: f5(slab)raw: 000fffffc0000040 ffff888001042000 0000000000000000 dead000000000001raw: 0000000000000000 0000000000080008 00000000f5000000 0000000000000000head: 000fffffc0000040 ffff888001042000 00000---truncated--- CVE-2026-46333: In the Linux kernel, the following vulnerability has been resolved:ptrace: slightly saner 'get_dumpable()' logicThe 'dumpability' of a task is fundamentally about the memory image ofthe task - the concept comes from whether it can core dump or not - andmakes no sense when you don't have an associated mm.And almost all users do in fact use it only for the case where the taskhas a mm pointer.But we have one odd special case: ptrace_may_access() uses 'dumpable' tocheck various other things entirely independently of the MM (typicallyexplicitly using flags like PTRACE_MODE_READ_FSCREDS). Including forthreads that no longer have a VM (and maybe never did, like most kernelthreads).It's not what this flag was designed for, but it is what it is.The ptrace code does check that the uid/gid matches, so you do have tobe uid-0 to see kernel thread details, but this means that thetraditional "drop capabilities" model doesn't make any difference forthis all.Make it all make a *bit* more sense by saying that if you don't have aMM pointer, we'll use a cached "last dumpability" flag if the threadever had a MM (it will be zero for kernel threads since it is neverset), and require a proper CAP_SYS_PTRACE capability to override. **Solution**: 请您尽快将升级到修复后的版本。修复命令如下： yum update --advisory ALINUX4-SA-2026:0333 **Affected Products**: Alinux 4
正文
Package updates are available for Alibaba Cloud Linux 4 that fix the following vulnerabilities: CVE-2023-52590: In the Linux kernel, the following vulnerability has been resolved:ocfs2: Avoid touching renamed directory if parent does not changeThe VFS will not be locking moved directory if its parent does notchange. Change ocfs2 rename code to avoid touching renamed directory ifits parent does not change as without locking that can corrupt thefilesystem. CVE-2024-39478: In the Linux kernel, the following vulnerability has been resolved:crypto: starfive - Do not free stack bufferRSA text data uses variable length buffer allocated in software stack.Calling kfree on it causes undefined behaviour in subsequent operations. CVE-2024-41082: In the Linux kernel, the following vulnerability has been resolved:nvme-fabrics: use reserved tag for reg read/write commandIn some scenarios, if too many commands are issued by nvme command inthe same time by user tasks, this may exhaust all tags of admin_q. Ifa 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 reservedtags. This maybe safe for nvmf:1. For the disable ctrl path, we will not issue connect command2. 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-58094: In the Linux kernel, the following vulnerability has been resolved:jfs: add check read-only before truncation in jfs_truncate_nolock()Added a check for "read-only" mode in the `jfs_truncate_nolock`function to avoid errors related to writing to a read-onlyfilesystem.Call stack:block_write_begin() { jfs_write_failed() { jfs_truncate() { jfs_truncate_nolock() { txEnd() { ... log = JFS_SBI(tblk->sb)->log; // (log == NULL)If the `isReadOnly(ip)` condition is triggered in`jfs_truncate_nolock`, the function execution will stop, and nofurther data modification will occur. Instead, the `xtTruncate`function will be called with the "COMMIT_WMAP" flag, preventingmodifications in "read-only" mode. CVE-2024-58095: In the Linux kernel, the following vulnerability has been resolved:jfs: add check read-only before txBeginAnon() callAdded a read-only check before calling `txBeginAnon` in `extAlloc`and `extRecord`. This prevents modification attempts on a read-onlymounted filesystem, avoiding potential errors or crashes.Call trace: txBeginAnon+0xac/0x154 extAlloc+0xe8/0xdec fs/jfs/jfs_extent.c:78 jfs_get_block+0x340/0xb98 fs/jfs/inode.c:248 __block_write_begin_int+0x580/0x166c fs/buffer.c:2128 __block_write_begin fs/buffer.c:2177 [inline] block_write_begin+0x98/0x11c fs/buffer.c:2236 jfs_write_begin+0x44/0x88 fs/jfs/inode.c:299 CVE-2025-21722: In the Linux kernel, the following vulnerability has been resolved:nilfs2: do not force clear folio if buffer is referencedPatch series "nilfs2: protect busy buffer heads from being force-cleared".This series fixes the buffer head state inconsistency issues reported bysyzbot that occurs when the filesystem is corrupted and falls back toread-only, and the associated buffer head use-after-free issue.This patch (of 2):Syzbot has reported that after nilfs2 detects filesystem corruption andfalls back to read-only, inconsistencies in the buffer state may occur.One of the inconsistencies is that when nilfs2 calls mark_buffer_dirty()to set a data or metadata buffer as dirty, but it detects that the bufferis not in the uptodate state: WARNING: CPU: 0 PID: 6049 at fs/buffer.c:1177 mark_buffer_dirty+0x2e5/0x520 fs/buffer.c:1177 ... Call Trace: <TASK> nilfs_palloc_commit_alloc_entry+0x4b/0x160 fs/nilfs2/alloc.c:598 nilfs_ifile_create_inode+0x1dd/0x3a0 fs/nilfs2/ifile.c:73 nilfs_new_inode+0x254/0x830 fs/nilfs2/inode.c:344 nilfs_mkdir+0x10d/0x340 fs/nilfs2/namei.c:218 vfs_mkdir+0x2f9/0x4f0 fs/namei.c:4257 do_mkdirat+0x264/0x3a0 fs/namei.c:4280 __do_sys_mkdirat fs/namei.c:4295 [inline] __se_sys_mkdirat fs/namei.c:4293 [inline] __x64_sys_mkdirat+0x87/0xa0 fs/namei.c:4293 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/0x7fThe other is when nilfs_btree_propagate(), which propagates the dirtystate to the ancestor nodes of a b-tree that point to a dirty buffer,detects that the origin buffer is not dirty, even though it should be: WARNING: CPU: 0 PID: 5245 at fs/nilfs2/btree.c:2089 nilfs_btree_propagate+0xc79/0xdf0 fs/nilfs2/btree.c:2089 ... Call Trace: <TASK> nilfs_bmap_propagate+0x75/0x120 fs/nilfs2/bmap.c:345 nilfs_collect_file_data+0x4d/0xd0 fs/nilfs2/segment.c:587 nilfs_segctor_apply_buffers+0x184/0x340 fs/nilfs2/segment.c:1006 nilfs_segctor_scan_file+0x28c/0xa50 fs/nilfs2/segment.c:1045 nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1216 [inline] nilfs_segctor_collect fs/nilfs2/segment.c:1540 [inline] nilfs_segctor_do_construct+0x1c28/0x6b90 fs/nilfs2/segment.c:2115 nilfs_segctor_construct+0x181/0x6b0 fs/nilfs2/segment.c:2479 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2587 [inline] nilfs_segctor_thread+0x69e/0xe80 fs/nilfs2/segment.c:2701 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>Both of these issues are caused by the callbacks that handle thepage/folio write requests, forcibly clear various states, including theworking state of the buffers they hold, at unexpected times when theydetect read-only fallback.Fix these issues by checking if the buffer is referenced before clearingthe page/folio state, and skipping the clear if it is. 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 aninvalid header length (e.g. 255), causing nvme_tcp_verify_hdgst()to access memory outside the allocated area and cause memory corruptionsby overwriting it with the calculated digest.Fix this by rejecting packets with an unexpected header length. CVE-2025-22070: In the Linux kernel, the following vulnerability has been resolved:fs/9p: fix NULL pointer dereference on mkdirWhen a 9p tree was mounted with option 'posixacl', parent directory had adefault ACL set for its subdirectories, e.g.: setfacl -m default:group:simpsons:rwx parentdirthen creating a subdirectory crashed 9p client, as v9fs_fid_add() call infunction v9fs_vfs_mkdir_dotl() sets the passed 'fid' pointer to NULL(since dafbe689736) even though the subsequent v9fs_set_create_acl() callexpects 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 inv9fs_vfs_mkdir_dotl(), i.e. calling v9fs_set_create_acl() beforev9fs_fid_add(). CVE-2025-22104: In the Linux kernel, the following vulnerability has been resolved:ibmvnic: Use kernel helpers for hex dumpsPreviously, when the driver was printing hex dumps, the buffer was castto an 8 byte long and printed using string formatters. If the buffersize was not a multiple of 8 then a read buffer overflow was possible.Therefore, create a new ibmvnic function that loops over a buffer andcalls hex_dump_to_buffer instead.This patch address KASAN reports like the one below: ibmvnic 30000003 env3: Login Buffer: ibmvnic 30000003 env3: 01000000af000000 <...> ibmvnic 30000003 env3: 2e6d62692e736261 ibmvnic 30000003 env3: 65050003006d6f63 ================================================================== BUG: KASAN: slab-out-of-bounds in ibmvnic_login+0xacc/0xffc [ibmvnic] Read of size 8 at addr c0000001331a9aa8 by task ip/17681 <...> Allocated by task 17681: <...> ibmvnic_login+0x2f0/0xffc [ibmvnic] ibmvnic_open+0x148/0x308 [ibmvnic] __dev_open+0x1ac/0x304 <...> The buggy address is located 168 bytes inside of allocated 175-byte region [c0000001331a9a00, c0000001331a9aaf) <...> ================================================================= ibmvnic 30000003 env3: 000000000033766e CVE-2025-22113: In the Linux kernel, the following vulnerability has been resolved:ext4: avoid journaling sb update on error if journal is destroyingPresently we always BUG_ON if trying to start a transaction on a journal markedwith JBD2_UNMOUNT, since this should never happen. However, while ltp runningstress tests, it was observed that in case of some error handling paths, it ispossible for update_super_work to start a transaction after the journal isdestroyed 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 doa journaled (and deferred) update of sb if this flag is not set. Otherwise, justfallback 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 updatesThis sequence is important as it ensures that, after this point, there is no sbupdate that might be journaled so it is safe to update the sb outside thejournal. (To avoid race discussed in 2d01ddc86606)Also, we don't need a similar check in ext4_grp_locked_error since it is onlycalled from mballoc and AFAICT it would be always valid to schedule work here. 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-23131: In the Linux kernel, the following vulnerability has been resolved:dlm: prevent NPD when writing a positive value to event_donedo_uevent returns the value written to event_done. In case it is apositive value, new_lockspace would undo all the work, and lockspacewould not be set. __dlm_new_lockspace, however, would treat thatpositive value as a success due to commit 8511a2728ab8 ("dlm: fix usecount with multiple joins").Down the line, device_create_lockspace would pass that NULL lockspace todlm_find_lockspace_local, leading to a NULL pointer dereference.Treating such positive values as successes prevents the problem. Giventhis has been broken for so long, this is unlikely to break userspaceexpectations. 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/0x308pc : dquot_writeback_dquots+0x2fc/0x308lr : f2fs_quota_sync+0xcc/0x1c4Call trace:dquot_writeback_dquots+0x2fc/0x308f2fs_quota_sync+0xcc/0x1c4f2fs_write_checkpoint+0x3d4/0x9b0f2fs_issue_checkpoint+0x1bc/0x2c0f2fs_sync_fs+0x54/0x150f2fs_do_sync_file+0x2f8/0x814__f2fs_ioctl+0x1960/0x3244f2fs_ioctl+0x54/0xe0__arm64_sys_ioctl+0xa8/0xe4invoke_syscall+0x58/0x114checkpoint and f2fs_remount may race as below, resulting triggering warningin 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 remountIf checkpoint comes from mount/umount/remount/freeze/quotactl, caller ofcheckpoint 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 canknow whether the lock has held in the context or not by checking currentw/ it.In addition, in order to not misrepresent caller of checkpoint, we shouldnot allow to trigger async checkpoint for those callers: mount/umount/remount/freeze/quotactl. CVE-2025-37833: In the Linux kernel, the following vulnerability has been resolved:net/niu: Niu requires MSIX ENTRY_DATA fields touch before entry readsFix niu_try_msix() to not cause a fatal trap on sparc systems.Set PCI_DEV_FLAGS_MSIX_TOUCH_ENTRY_DATA_FIRST on the struct pci_dev towork around a bug in the hardware or firmware.For each vector entry in the msix table, niu chips will cause a fataltrap if any registers in that entry are read before that entries'ENTRY_DATA register is written to. Testing indicates writes to otherregisters are not sufficient to prevent the fatal trap, however the valuedoes not appear to matter. This only needs to happen once after power up,so simply rebooting into a kernel lacking this fix will NOT cause thetrap.NON-RESUMABLE ERROR: Reporting on cpu 64NON-RESUMABLE ERROR: TPC [0x00000000005f6900] <msix_prepare_msi_desc+0x90/0xa0>NON-RESUMABLE ERROR: RAW [4010000000000016:00000e37f93e32ff:0000000202000080:ffffffffffffffffNON-RESUMABLE ERROR: 0000000800000000:0000000000000000:0000000000000000:0000000000000000]NON-RESUMABLE ERROR: handle [0x4010000000000016] stick [0x00000e37f93e32ff]NON-RESUMABLE ERROR: type [precise nonresumable]NON-RESUMABLE ERROR: attrs [0x02000080] < ASI sp-faulted priv >NON-RESUMABLE ERROR: raddr [0xffffffffffffffff]NON-RESUMABLE ERROR: insn effective address [0x000000c50020000c]NON-RESUMABLE ERROR: size [0x8]NON-RESUMABLE ERROR: asi [0x00]CPU: 64 UID: 0 PID: 745 Comm: kworker/64:1 Not tainted 6.11.5 #63Workqueue: events work_for_cpu_fnTSTATE: 0000000011001602 TPC: 00000000005f6900 TNPC: 00000000005f6904 Y: 00000000 Not taintedTPC: <msix_prepare_msi_desc+0x90/0xa0>g0: 00000000000002e9 g1: 000000000000000c g2: 000000c50020000c g3: 0000000000000100g4: ffff8000470307c0 g5: ffff800fec5be000 g6: ffff800047a08000 g7: 0000000000000000o0: ffff800014feb000 o1: ffff800047a0b620 o2: 0000000000000011 o3: ffff800047a0b620o4: 0000000000000080 o5: 0000000000000011 sp: ffff800047a0ad51 ret_pc: 00000000005f7128RPC: <__pci_enable_msix_range+0x3cc/0x460>l0: 000000000000000d l1: 000000000000c01f l2: ffff800014feb0a8 l3: 0000000000000020l4: 000000000000c000 l5: 0000000000000001 l6: 0000000020000000 l7: ffff800047a0b734i0: ffff800014feb000 i1: ffff800047a0b730 i2: 0000000000000001 i3: 000000000000000di4: 0000000000000000 i5: 0000000000000000 i6: ffff800047a0ae81 i7: 00000000101888b0I7: <niu_try_msix.constprop.0+0xc0/0x130 [niu]>Call Trace:[<00000000101888b0>] niu_try_msix.constprop.0+0xc0/0x130 [niu][<000000001018f840>] niu_get_invariants+0x183c/0x207c [niu][<00000000101902fc>] niu_pci_init_one+0x27c/0x2fc [niu][<00000000005ef3e4>] local_pci_probe+0x28/0x74[<0000000000469240>] work_for_cpu_fn+0x8/0x1c[<000000000046b008>] process_scheduled_works+0x144/0x210[<000000000046b518>] worker_thread+0x13c/0x1c0[<00000000004710e0>] kthread+0xb8/0xc8[<00000000004060c8>] ret_from_fork+0x1c/0x2c[<0000000000000000>] 0x0Kernel panic - not syncing: Non-resumable error. CVE-2025-38203: In the Linux kernel, the following vulnerability has been resolved:jfs: Fix null-ptr-deref in jfs_ioc_trim[ Syzkaller Report ]Oops: general protection fault, probably for non-canonical address0xdffffc0000000087: 0000 [#1KASAN: null-ptr-deref in range [0x0000000000000438-0x000000000000043f]CPU: 2 UID: 0 PID: 10614 Comm: syz-executor.0 Not tainted6.13.0-rc6-gfbfd64d25c7a-dirty #1Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014Sched_ext: serialise (enabled+all), task: runnable_at=-30msRIP: 0010:jfs_ioc_trim+0x34b/0x8f0Code: e7 e8 59 a4 87 fe 4d 8b 24 24 4d 8d bc 24 38 04 00 00 48 8d 9390 82 fe ff 4c 89 ff 31 f6RSP: 0018:ffffc900055f7cd0 EFLAGS: 00010206RAX: 0000000000000087 RBX: 00005866a9e67ff8 RCX: 000000000000000aRDX: 0000000000000001 RSI: 0000000000000004 RDI: 0000000000000001RBP: dffffc0000000000 R08: ffff88807c180003 R09: 1ffff1100f830000R10: dffffc0000000000 R11: ffffed100f830001 R12: 0000000000000000R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000438FS: 00007fe520225640(0000) GS:ffff8880b7e80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005593c91b2c88 CR3: 000000014927c000 CR4: 00000000000006f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:<TASK>? __die_body+0x61/0xb0? die_addr+0xb1/0xe0? exc_general_protection+0x333/0x510? asm_exc_general_protection+0x26/0x30? jfs_ioc_trim+0x34b/0x8f0jfs_ioctl+0x3c8/0x4f0? __pfx_jfs_ioctl+0x10/0x10? __pfx_jfs_ioctl+0x10/0x10__se_sys_ioctl+0x269/0x350? __pfx___se_sys_ioctl+0x10/0x10? do_syscall_64+0xfb/0x210do_syscall_64+0xee/0x210? syscall_exit_to_user_mode+0x1e0/0x330entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7fe51f4903adCode: c3 e8 a7 2b 00 00 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 89 f8 4889 f7 48 89 d6 48 89 ca 4dRSP: 002b:00007fe5202250c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: ffffffffffffffda RBX: 00007fe51f5cbf80 RCX: 00007fe51f4903adRDX: 0000000020000680 RSI: 00000000c0185879 RDI: 0000000000000005RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe520225640R13: 000000000000000e R14: 00007fe51f44fca0 R15: 00007fe52021d000</TASK>Modules linked in:---[ end trace 0000000000000000 ]---RIP: 0010:jfs_ioc_trim+0x34b/0x8f0Code: e7 e8 59 a4 87 fe 4d 8b 24 24 4d 8d bc 24 38 04 00 00 48 8d 9390 82 fe ff 4c 89 ff 31 f6RSP: 0018:ffffc900055f7cd0 EFLAGS: 00010206RAX: 0000000000000087 RBX: 00005866a9e67ff8 RCX: 000000000000000aRDX: 0000000000000001 RSI: 0000000000000004 RDI: 0000000000000001RBP: dffffc0000000000 R08: ffff88807c180003 R09: 1ffff1100f830000R10: dffffc0000000000 R11: ffffed100f830001 R12: 0000000000000000R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000438FS: 00007fe520225640(0000) GS:ffff8880b7e80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005593c91b2c88 CR3: 000000014927c000 CR4: 00000000000006f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Kernel panic - not syncing: Fatal exception[ Analysis ]We believe that we have found a concurrency bug in the `fs/jfs` modulethat results in a null pointer dereference. There is a closely relatedissue which has been fixed:https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d6c1b3599b2feb5c7291f5ac3a36e5fa7cedb234... but, unfortunately, the accepted patch appears to still besusceptible to a null pointer dereference under some interleavings.To trigger the bug, we think that `JFS_SBI(ipbmap->i_sb)->bmap` is setto NULL in `dbFreeBits` and then dereferenced in `jfs_ioc_trim`. Thisbug manifests quite rarely under normal circumstances, but istriggereable from a syz-program. CVE-2025-38204: In the Linux kernel, the following vulnerability has been resolved:jfs: fix array-index-out-of-bounds read in add_missing_indicesstbl is s8 but it must contain offsets into slot which can go from 0 to127.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 returnswith an error. CVE-2025-38206: In the Linux kernel, the following vulnerability has been resolved:exfat: fix double free in delayed_freeThe double free could happen in the following path.exfat_create_upcase_table() exfat_create_upcase_table() : return error exfat_free_upcase_table() : free ->vol_utbl exfat_load_default_upcase_table : return error exfat_kill_sb() delayed_free() exfat_free_upcase_table() <--------- double freeThis patch set ->vol_util as NULL after freeing it. CVE-2025-38237: In the Linux kernel, the following vulnerability has been resolved:media: platform: exynos4-is: Add hardware sync wait to fimc_is_hw_change_mode()In fimc_is_hw_change_mode(), the function changes camera modes withoutwaiting for hardware completion, risking corrupted data or system hangsif subsequent operations proceed before the hardware is ready.Add fimc_is_hw_wait_intmsr0_intmsd0() after mode configuration, ensuringhardware state synchronization and stable interrupt handling. CVE-2025-38248: In the Linux kernel, the following vulnerability has been resolved:bridge: mcast: Fix use-after-free during router port configurationThe bridge maintains a global list of ports behind which a multicastrouter resides. The list is consulted during forwarding to ensuremulticast packets are forwarded to these ports even if the ports are notmember in the matching MDB entry.When per-VLAN multicast snooping is enabled, the per-port multicastcontext is disabled on each port and the port is removed from the globalrouter 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 routerHowever, the port can be re-added to the global list even when per-VLANmulticast 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: dummy1Since commit 4b30ae9adb04 ("net: bridge: mcast: re-implementbr_multicast_{enable, disable}_port functions"), when per-VLAN multicastsnooping is enabled, multicast disablement on a port will disable theper-{port, VLAN} multicast contexts and not the per-port one. As aresult, a port will remain in the global router port list even after itis deleted. This will lead to a use-after-free [1] when the list istraversed (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 2Similarly, stale entries can also be found in the per-VLAN router portlist. When per-VLAN multicast snooping is disabled, the per-{port, VLAN}contexts are disabled on each port and the port is removed from theper-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 routerHowever, the port can be re-added to the per-VLAN list even whenper-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: dummy1When the VLAN is deleted from the port, the per-{port, VLAN} multicastcontext will not be disabled since multicast snooping is not enabledon the VLAN. As a result, the port will remain in the per-VLAN routerport list even after it is no longer member in the VLAN. This will leadto a use-after-free [2] when the list is traversed (when adding a newport 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 2Fix these issues by removing the port from the relevant (global orper-VLAN) router port list in br_multicast_port_ctx_deinit(). Thefunction is invoked during port deletion with the per-port multicastcontext and during VLAN deletion with the per-{port, VLAN} multicastcontext.Note that deleting the multicast router timer is not enough as it onlytakes care of the temporary multicast router states (1 or 3) and not thepermanent one (2).[1]BUG: KASAN: slab-out-of-bounds in br_multicast_add_router.part.0+0x3f1/0x560Write of size 8 at addr ffff888004a67328 by task ip/384[...]Call Trace: <TASK> dump_stack---truncated--- CVE-2025-38264: In the Linux kernel, the following vulnerability has been resolved:nvme-tcp: sanitize request list handlingValidate the request in nvme_tcp_handle_r2t() to ensure it's not part ofany list, otherwise a malicious R2T PDU might inject a loop in requestlist processing. CVE-2025-38502: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix oob access in cgroup local storageLonial reported that an out-of-bounds access in cgroup local storagecan be crafted via tail calls. Given two programs each utilizing acgroup local storage with a different value size, and one programdoing a tail call into the other. The verifier will validate each ofthe indivial programs just fine. However, in the runtime contextthe bpf_cg_run_ctx holds an bpf_prog_array_item which contains theBPF program as well as any cgroup local storage flavor the programuses. Helpers such as bpf_get_local_storage() pick this up from theruntime context: ctx = container_of(current->bpf_ctx, struct bpf_cg_run_ctx, run_ctx); storage = ctx->prog_item->cgroup_storage[stype]; if (stype == BPF_CGROUP_STORAGE_SHARED) ptr = &READ_ONCE(storage->buf)->data[0]; else ptr = this_cpu_ptr(storage->percpu_buf);For the second program which was called from the originally attachedone, this means bpf_get_local_storage() will pick up the formerprogram's map, not its own. With mismatching sizes, this can resultin an unintended out-of-bounds access.To fix this issue, we need to extend bpf_map_owner with an array ofstorage_cookie[] to match on i) the exact maps from the originalprogram if the second program was using bpf_get_local_storage(), orii) allow the tail call combination if the second program was notusing any of the cgroup local storage maps. CVE-2025-38678: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: reject duplicate device on updatesA chain/flowtable update with duplicated devices in the same batch ispossible. Unfortunately, netdev event path only removes the firstdevice that is found, leaving unregistered the hook of the duplicateddevice.Check if a duplicated device exists in the transaction batch, bail outwith EEXIST in such case.WARNING is hit when unregistering the hook: [49042.221275] WARNING: CPU: 4 PID: 8425 at net/netfilter/core.c:340 nf_hook_entry_head+0xaa/0x150 [49042.221375] CPU: 4 UID: 0 PID: 8425 Comm: nft Tainted: G S 6.16.0+ #170 PREEMPT(full) [...] [49042.221382] RIP: 0010:nf_hook_entry_head+0xaa/0x150 CVE-2025-39682: In the Linux kernel, the following vulnerability has been resolved:tls: fix handling of zero-length records on the rx_listEach recvmsg() call must process either - only contiguous DATA records (any number of them) - one non-DATA recordIf the next record has different type than what has already beenprocessed we break out of the main processing loop. If the recordhas already been decrypted (which may be the case for TLS 1.3 wherewe don't know type until decryption) we queue the pending recordto the rx_list. Next recvmsg() will pick it up from there.Queuing the skb to rx_list after zero-copy decrypt is not possible,since in that case we decrypted directly to the user space buffer,and we don't have an skb to queue (darg.skb points to the ciphertextskb for access to metadata like length).Only data records are allowed zero-copy, and we break the processingloop after each non-data record. So we should never zero-copy andthen find out that the record type has changed. The corner casewe missed is when the initial record comes from rx_list, and it'szero length. CVE-2025-39702: In the Linux kernel, the following vulnerability has been resolved:ipv6: sr: Fix MAC comparison to be constant-timeTo prevent timing attacks, MACs need to be compared in constant time.Use the appropriate helper function for this. CVE-2025-39711: In the Linux kernel, the following vulnerability has been resolved:media: ivsc: Fix crash at shutdown due to missing mei_cldev_disable() callsBoth the ACE and CSI driver are missing a mei_cldev_disable() call intheir remove() function.This causes the mei_cl client to stay part of the mei_device->file_listlist even though its memory is freed by mei_cl_bus_dev_release() callingkfree(cldev->cl).This leads to a use-after-free when mei_vsc_remove() runs mei_stop()which first removes all mei bus devices calling mei_ace_remove() andmei_csi_remove() followed by mei_cl_bus_dev_release() and then callsmei_cl_all_disconnect() which walks over mei_device->file_list dereferecingthe just freed cldev->cl.And mei_vsc_remove() it self is run at shutdown because of theplatform_device_unregister(tp->pdev) in vsc_tp_shutdown()When building a kernel with KASAN this leads to the following KASAN report:[ 106.634504] ==================================================================[ 106.634623] BUG: KASAN: slab-use-after-free in mei_cl_set_disconnected (drivers/misc/mei/client.c:783) mei[ 106.634683] Read of size 4 at addr ffff88819cb62018 by task systemd-shutdow/1[ 106.634729][ 106.634767] Tainted: [E]=UNSIGNED_MODULE[ 106.634770] Hardware name: Dell Inc. XPS 16 9640/09CK4V, BIOS 1.12.0 02/10/2025[ 106.634773] Call Trace:[ 106.634777] <TASK>...[ 106.634871] kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:636)[ 106.634901] mei_cl_set_disconnected (drivers/misc/mei/client.c:783) mei[ 106.634921] mei_cl_all_disconnect (drivers/misc/mei/client.c:2165 (discriminator 4)) mei[ 106.634941] mei_reset (drivers/misc/mei/init.c:163) mei...[ 106.635042] mei_stop (drivers/misc/mei/init.c:348) mei[ 106.635062] mei_vsc_remove (drivers/misc/mei/mei_dev.h:784 drivers/misc/mei/platform-vsc.c:393) mei_vsc[ 106.635066] platform_remove (drivers/base/platform.c:1424)Add the missing mei_cldev_disable() calls so that the mei_cl gets removedfrom mei_device->file_list before it is freed to fix this. CVE-2025-39746: In the Linux kernel, the following vulnerability has been resolved:wifi: ath10k: shutdown driver when hardware is unreliableIn rare cases, ath10k may lose connection with the PCIe bus due tosome unknown reasons, which could further lead to system crashes duringresuming due to watchdog timeout:ath10k_pci 0000:01:00.0: wmi command 20486 timeout, restarting hardwareath10k_pci 0000:01:00.0: already restartingath10k_pci 0000:01:00.0: failed to stop WMI vdev 0: -11ath10k_pci 0000:01:00.0: failed to stop vdev 0: -11ieee80211 phy0: PM: **** DPM device timeout ****Call Trace: panic+0x125/0x315 dpm_watchdog_set+0x54/0x54 dpm_watchdog_handler+0x57/0x57 call_timer_fn+0x31/0x13cAt this point, all WMI commands will timeout and attempt to restartdevice. So set a threshold for consecutive restart failures. If thethreshold is exceeded, consider the hardware is unreliable and allath10k operations should be skipped to avoid system crash.fail_cont_count and pending_recovery are atomic variables, anddo not involve complex conditional logic. Therefore, even if recoverycheck and reconfig complete are executed concurrently, the recoverymechanism will not be broken.Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00288-QCARMSWPZ-1 CVE-2025-39790: In the Linux kernel, the following vulnerability has been resolved:bus: mhi: host: Detect events pointing to unexpected TREsWhen a remote device sends a completion event to the host, it contains apointer to the consumed TRE. The host uses this pointer to process all ofthe TREs between it and the host's local copy of the ring's read pointer.This works when processing completion for chained transactions, but canlead to nasty results if the device sends an event for a single-elementtransaction with a read pointer that is multiple elements ahead of thehost's read pointer.For instance, if the host accesses an event ring while the device isupdating it, the pointer inside of the event might still point to an oldTRE. If the host uses the channel's xfer_cb() to directly free the bufferpointed to by the TRE, the buffer will be double-freed.This behavior was observed on an ep that used upstream EP stack without'commit 6f18d174b73d ("bus: mhi: ep: Update read pointer only after bufferis written")'. Where the device updated the events ring pointer beforeupdating the event contents, so it left a window where the host was able toaccess the stale data the event pointed to, before the device had thechance to update them. The usual pattern was that the host received anevent pointing to a TRE that is not immediately after the last processedone, so it got treated as if it was a chained transaction, processing allof the TREs in between the two read pointers.This commit aims to harden the host by ensuring transactions where theevent points to a TRE that isn't local_rp + 1 are chained.[mani: added stable tag and reworded commit message] CVE-2025-39833: In the Linux kernel, the following vulnerability has been resolved:mISDN: hfcpci: Fix warning when deleting uninitialized timerWith CONFIG_DEBUG_OBJECTS_TIMERS unloading hfcpci module leadsto the following splat:[ 250.215892] ODEBUG: assert_init not available (active state 0) object: ffffffffc01a3dc0 object type: timer_list hint: 0x0[ 250.217520] WARNING: CPU: 0 PID: 233 at lib/debugobjects.c:612 debug_print_object+0x1b6/0x2c0[ 250.218775] Modules linked in: hfcpci(-) mISDN_core[ 250.219537] CPU: 0 UID: 0 PID: 233 Comm: rmmod Not tainted 6.17.0-rc2-g6f713187ac98 #2 PREEMPT(voluntary)[ 250.220940] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 250.222377] RIP: 0010:debug_print_object+0x1b6/0x2c0[ 250.223131] Code: fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 75 4f 41 56 48 8b 14 dd a0 4e 01 9f 48 89 ee 48 c7 c7 20 46 01 9f e8 cb 84d[ 250.225805] RSP: 0018:ffff888015ea7c08 EFLAGS: 00010286[ 250.226608] RAX: 0000000000000000 RBX: 0000000000000005 RCX: ffffffff9be93a95[ 250.227708] RDX: 1ffff1100d945138 RSI: 0000000000000008 RDI: ffff88806ca289c0[ 250.228993] RBP: ffffffff9f014a00 R08: 0000000000000001 R09: ffffed1002bd4f39[ 250.230043] R10: ffff888015ea79cf R11: 0000000000000001 R12: 0000000000000001[ 250.231185] R13: ffffffff9eea0520 R14: 0000000000000000 R15: ffff888015ea7cc8[ 250.232454] FS: 00007f3208f01540(0000) GS:ffff8880caf5a000(0000) knlGS:0000000000000000[ 250.233851] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 250.234856] CR2: 00007f32090a7421 CR3: 0000000004d63000 CR4: 00000000000006f0[ 250.236117] Call Trace:[ 250.236599] <TASK>[ 250.236967] ? trace_irq_enable.constprop.0+0xd4/0x130[ 250.237920] debug_object_assert_init+0x1f6/0x310[ 250.238762] ? __pfx_debug_object_assert_init+0x10/0x10[ 250.239658] ? __lock_acquire+0xdea/0x1c70[ 250.240369] __try_to_del_timer_sync+0x69/0x140[ 250.241172] ? __pfx___try_to_del_timer_sync+0x10/0x10[ 250.242058] ? __timer_delete_sync+0xc6/0x120[ 250.242842] ? lock_acquire+0x30/0x80[ 250.243474] ? __timer_delete_sync+0xc6/0x120[ 250.244262] __timer_delete_sync+0x98/0x120[ 250.245015] HFC_cleanup+0x10/0x20 [hfcpci][ 250.245704] __do_sys_delete_module+0x348/0x510[ 250.246461] ? __pfx___do_sys_delete_module+0x10/0x10[ 250.247338] do_syscall_64+0xc1/0x360[ 250.247924] entry_SYSCALL_64_after_hwframe+0x77/0x7fFix this by initializing hfc_tl timer with DEFINE_TIMER macro.Also, use mod_timer instead of manual timeout update. CVE-2025-39866: In the Linux kernel, the following vulnerability has been resolved:fs: writeback: fix use-after-free in __mark_inode_dirty()An use-after-free issue occurred when __mark_inode_dirty() get thebdi_writeback that was in the progress of switching.CPU: 1 PID: 562 Comm: systemd-random- Not tainted 6.6.56-gb4403bd46a8e #1......pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : __mark_inode_dirty+0x124/0x418lr : __mark_inode_dirty+0x118/0x418sp : ffffffc08c9dbbc0........Call trace: __mark_inode_dirty+0x124/0x418 generic_update_time+0x4c/0x60 file_modified+0xcc/0xd0 ext4_buffered_write_iter+0x58/0x124 ext4_file_write_iter+0x54/0x704 vfs_write+0x1c0/0x308 ksys_write+0x74/0x10c __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x114 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x40/0xe4 el0t_64_sync_handler+0x120/0x12c el0t_64_sync+0x194/0x198Root cause is:systemd-random-seed kworker----------------------------------------------------------------------___mark_inode_dirty inode_switch_wbs_work_fn spin_lock(&inode->i_lock); inode_attach_wb locked_inode_to_wb_and_lock_list get inode->i_wb spin_unlock(&inode->i_lock); spin_lock(&wb->list_lock) spin_lock(&inode->i_lock) inode_io_list_move_locked spin_unlock(&wb->list_lock) spin_unlock(&inode->i_lock) spin_lock(&old_wb->list_lock) inode_do_switch_wbs spin_lock(&inode->i_lock) inode->i_wb = new_wb spin_unlock(&inode->i_lock) spin_unlock(&old_wb->list_lock) wb_put_many(old_wb, nr_switched) cgwb_release old wb released wb_wakeup_delayed() accesses wb, then trigger the use-after-free issueFix this race condition by holding inode spinlock untilwb_wakeup_delayed() finished. CVE-2025-39946: In the Linux kernel, the following vulnerability has been resolved:tls: make sure to abort the stream if headers are bogusNormally we wait for the socket to buffer up the whole recordbefore we service it. If the socket has a tiny buffer, however,we read out the data sooner, to prevent connection stalls.Make sure that we abort the connection when we find out latethat the record is actually invalid. Retrying the parsing isfine in itself but since we copy some more data each timebefore we parse we can overflow the allocated skb space.Constructing a scenario in which we're under pressure withoutenough data in the socket to parse the length upfront is quitehard. syzbot figured out a way to do this by serving us the headerin small OOB sends, and then filling in the recvbuf with a largenormal send.Make sure that tls_rx_msg_size() aborts strp, if we reachan invalid record there's really no way to recover. CVE-2025-39964: In the Linux kernel, the following vulnerability has been resolved:crypto: af_alg - Disallow concurrent writes in af_alg_sendmsgIssuing two writes to the same af_alg socket is bogus as thedata will be interleaved in an unpredictable fashion. Furthermore,concurrent writes may create inconsistencies in the internalsocket state.Disallow this by adding a new ctx->write field that indiciatesexclusive ownership for writing. CVE-2025-40018: No description is available for this CVE. CVE-2025-40019: No description is available for this CVE. CVE-2025-40020: No description is available for this CVE. CVE-2025-40106: In the Linux kernel, the following vulnerability has been resolved: comedi: fix divide-by-zero in comedi_buf_munge() The comedi_buf_munge() function performs a modulo operation `async->munge_chan %= async->cmd.chanlist_len` without first checking if chanlist_len is zero. If a user program submits a command with chanlist_len set to zero, this causes a divide-by-zero error when the device processes data in the interrupt handler path. Add a check for zero chanlist_len at the beginning of the function, similar to the existing checks for !map and CMDF_RAWDATA flag. When chanlist_len is zero, update munge_count and return early, indicating the data was handled without munging. This prevents potential kernel panics from malformed user commands. CVE-2025-40214: In the Linux kernel, the following vulnerability has been resolved: af_unix: Initialise scc_index in unix_add_edge(). Quang Le reported that the AF_UNIX GC could garbage-collect a receive queue of an alive in-flight socket, with a nice repro. The repro consists of three stages. 1) 1-a. Create a single cyclic reference with many sockets 1-b. close() all sockets 1-c. Trigger GC 2) 2-a. Pass sk-A to an embryo sk-B 2-b. Pass sk-X to sk-X 2-c. Trigger GC 3) 3-a. accept() the embryo sk-B 3-b. Pass sk-B to sk-C 3-c. close() the in-flight sk-A 3-d. Trigger GC As of 2-c, sk-A and sk-X are linked to unix_unvisited_vertices, and unix_walk_scc() groups them into two different SCCs: unix_sk(sk-A)->vertex->scc_index = 2 (UNIX_VERTEX_INDEX_START) unix_sk(sk-X)->vertex->scc_index = 3 Once GC completes, unix_graph_grouped is set to true. Also, unix_graph_maybe_cyclic is set to true due to sk-X's cyclic self-reference, which makes close() trigger GC. At 3-b, unix_add_edge() allocates unix_sk(sk-B)->vertex and links it to unix_unvisited_vertices. unix_update_graph() is called at 3-a. and 3-b., but neither unix_graph_grouped nor unix_graph_maybe_cyclic is changed because both sk-B's listener and sk-C are not in-flight. 3-c decrements sk-A's file refcnt to 1. Since unix_graph_grouped is true at 3-d, unix_walk_scc_fast() is finally called and iterates 3 sockets sk-A, sk-B, and sk-X: sk-A -> sk-B (-> sk-C) sk-X -> sk-X This is totally fine. All of them are not yet close()d and should be grouped into different SCCs. However, unix_vertex_dead() misjudges that sk-A and sk-B are in the same SCC and sk-A is dead. unix_sk(sk-A)->scc_index == unix_sk(sk-B)->scc_index <-- Wrong! && sk-A's file refcnt == unix_sk(sk-A)->vertex->out_degree ^-- 1 in-flight count for sk-B -> sk-A is dead !? The problem is that unix_add_edge() does not initialise scc_index. Stage 1) is used for heap spraying, making a newly allocated vertex have vertex->scc_index == 2 (UNIX_VERTEX_INDEX_START) set by unix_walk_scc() at 1-c. Let's track the max SCC index from the previous unix_walk_scc() call and assign the max + 1 to a new vertex's scc_index. This way, we can continue to avoid Tarjan's algorithm while preventing misjudgments. CVE-2025-40215: In the Linux kernel, the following vulnerability has been resolved: xfrm: delete x->tunnel as we delete x The ipcomp fallback tunnels currently get deleted (from the various lists and hashtables) as the last user state that needed that fallback is destroyed (not deleted). If a reference to that user state still exists, the fallback state will remain on the hashtables/lists, triggering the WARN in xfrm_state_fini. Because of those remaining references, the fix in commit f75a2804da39 ("xfrm: destroy xfrm_state synchronously on net exit path") is not complete. We recently fixed one such situation in TCP due to defered freeing of skbs (commit 9b6412e6979f ("tcp: drop secpath at the same time as we currently drop dst")). This can also happen due to IP reassembly: skbs with a secpath remain on the reassembly queue until netns destruction. If we can't guarantee that the queues are flushed by the time xfrm_state_fini runs, there may still be references to a (user) xfrm_state, preventing the timely deletion of the corresponding fallback state. Instead of chasing each instance of skbs holding a secpath one by one, this patch fixes the issue directly within xfrm, by deleting the fallback state as soon as the last user state depending on it has been deleted. Destruction will still happen when the final reference is dropped. A separate lockdep class for the fallback state is required since we're going to lock x->tunnel while x is locked. CVE-2025-40297: In the Linux kernel, the following vulnerability has been resolved: net: bridge: fix use-after-free due to MST port state bypass syzbot reported[1] a use-after-free when deleting an expired fdb. It is due to a race condition between learning still happening and a port being deleted, after all its fdbs have been flushed. The port's state has been toggled to disabled so no learning should happen at that time, but if we have MST enabled, it will bypass the port's state, that together with VLAN filtering disabled can lead to fdb learning at a time when it shouldn't happen while the port is being deleted. VLAN filtering must be disabled because we flush the port VLANs when it's being deleted which will stop learning. This fix adds a check for the port's vlan group which is initialized to NULL when the port is getting deleted, that avoids the port state bypass. When MST is enabled there would be a minimal new overhead in the fast-path because the port's vlan group pointer is cache-hot. [1] https://syzkaller.appspot.com/bug?extid=dd280197f0f7ab3917be CVE-2025-40307: In the Linux kernel, the following vulnerability has been resolved: exfat: validate cluster allocation bits of the allocation bitmap syzbot created an exfat image with cluster bits not set for the allocation bitmap. exfat-fs reads and uses the allocation bitmap without checking this. The problem is that if the start cluster of the allocation bitmap is 6, cluster 6 can be allocated when creating a directory with mkdir. exfat zeros out this cluster in exfat_mkdir, which can delete existing entries. This can reallocate the allocated entries. In addition, the allocation bitmap is also zeroed out, so cluster 6 can be reallocated. This patch adds exfat_test_bitmap_range to validate that clusters used for the allocation bitmap are correctly marked as in-use. CVE-2025-40325: In the Linux kernel, the following vulnerability has been resolved:md/raid10: wait barrier before returning discard request with REQ_NOWAITraid10_handle_discard should wait barrier before returning a discard biowhich has REQ_NOWAIT. And there is no need to print warning calltraceif a discard bio has REQ_NOWAIT flag. Quality engineer usually checksdmesg and reports error if dmesg has warning/error calltrace. CVE-2025-40355: No description is available for this CVE. CVE-2025-68745: No description is available for this CVE. CVE-2026-23112: In the Linux kernel, the following vulnerability has been resolved:nvmet-tcp: add bounds checks in nvmet_tcp_build_pdu_iovecnvmet_tcp_build_pdu_iovec() could walk past cmd->req.sg when a PDUlength or offset exceeds sg_cnt and then use bogus sg->length/offsetvalues, leading to _copy_to_iter() GPF/KASAN. Guard sg_idx, remainingentries, and sg->length/offset before building the bvec. CVE-2026-23361: In the Linux kernel, the following vulnerability has been resolved:PCI: dwc: ep: Flush MSI-X write before unmapping its ATU entryEndpoint drivers use dw_pcie_ep_raise_msix_irq() to raise an MSI-Xinterrupt to the host using a writel(), which generates a PCI posted writetransaction. There's no completion for posted writes, so the writel() mayreturn before the PCI write completes. dw_pcie_ep_raise_msix_irq() alsounmaps the outbound ATU entry used for the PCI write, so the write raceswith the unmap.If the PCI write loses the race with the ATU unmap, the write may corrupthost memory or cause IOMMU errors, e.g., these when running fio with alarger 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: 0x0Flush the write by performing a readl() of the same address to ensure thatthe write has reached the destination before the ATU entry is unmapped.The same problem was solved for dw_pcie_ep_raise_msi_irq() in commit8719c64e76bf ("PCI: dwc: ep: Cache MSI outbound iATU mapping"), but thereit was solved by dedicating an outbound iATU only for MSI. We can't do thesame for MSI-X because each vector can have a different msg_addr and themsg_addr may be changed while the vector is masked.[bhelgaas: commit log] CVE-2026-31402: In the Linux kernel, the following vulnerability has been resolved:nfsd: fix heap overflow in NFSv4.0 LOCK replay cacheThe NFSv4.0 replay cache uses a fixed 112-byte inline buffer(rp_ibuf[NFSD4_REPLAY_ISIZE]) to store encoded operation responses.This size was calculated based on OPEN responses and does not accountfor LOCK denied responses, which include the conflicting lock owner asa variable-length field up to 1024 bytes (NFS4_OPAQUE_LIMIT).When a LOCK operation is denied due to a conflict with an existing lockthat has a large owner, nfsd4_encode_operation() copies the full encodedresponse into the undersized replay buffer via read_bytes_from_xdr_buf()with no bounds check. This results in a slab-out-of-bounds write of upto 944 bytes past the end of the buffer, corrupting adjacent heap memory.This can be triggered remotely by an unauthenticated attacker with twocooperating NFSv4.0 clients: one sets a lock with a large owner string,then the other requests a conflicting lock to provoke the denial.We could fix this by increasing NFSD4_REPLAY_ISIZE to allow for a fullopaque, but that would increase the size of every stateowner, when mostlockowners are not that large.Instead, fix this by checking the encoded response length againstNFSD4_REPLAY_ISIZE before copying into the replay buffer. If theresponse is too large, set rp_buflen to 0 to skip caching the replaypayload. The status is still cached, and the client already received thecorrect response on the original request. CVE-2026-31449: In the Linux kernel, the following vulnerability has been resolved:ext4: validate p_idx bounds in ext4_ext_correct_indexesext4_ext_correct_indexes() walks up the extent tree correctingindex entries when the first extent in a leaf is modified. Beforeaccessing path[k].p_idx->ei_block, there is no validation thatp_idx falls within the valid range of index entries for thatlevel.If the on-disk extent header contains a corrupted or craftedeh_entries value, p_idx can point past the end of the allocatedbuffer, causing a slab-out-of-bounds read.Fix this by validating path[k].p_idx against EXT_LAST_INDEX() atboth access sites: before the while loop and inside it. Return-EFSCORRUPTED if the index pointer is out of range, consistentwith how other bounds violations are handled in the ext4 extenttree code. CVE-2026-31450: In the Linux kernel, the following vulnerability has been resolved:ext4: publish jinode after initializationext4_inode_attach_jinode() publishes ei->jinode to concurrent users.It used to set ei->jinode before jbd2_journal_init_jbd_inode(),allowing a reader to observe a non-NULL jinode with i_vfs_inodestill unset.The fast commit flush path can then pass this jinode tojbd2_wait_inode_data(), which dereferences i_vfs_inode->i_mapping andmay crash.Below is the crash I observe:```BUG: unable to handle page fault for address: 000000010beb47f4PGD 110e51067 P4D 110e51067 PUD 0Oops: Oops: 0000 [#1] SMP NOPTICPU: 1 UID: 0 PID: 4850 Comm: fc_fsync_bench_ Not tainted 6.18.0-00764-g795a690c06a5 #1 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014RIP: 0010:xas_find_marked+0x3d/0x2e0Code: e0 03 48 83 f8 02 0f 84 f0 01 00 00 48 8b 47 08 48 89 c3 48 39 c6 0f 82 fd 01 00 00 48 85 c9 74 3d 48 83 f9 03 77 63 4c 8b 0f <49> 8b 71 08 48 c7 47 18 00 00 00 00 48 89 f1 83 e1 03 48 83 f9 02RSP: 0018:ffffbbee806e7bf0 EFLAGS: 00010246RAX: 000000000010beb4 RBX: 000000000010beb4 RCX: 0000000000000003RDX: 0000000000000001 RSI: 0000002000300000 RDI: ffffbbee806e7c10RBP: 0000000000000001 R08: 0000002000300000 R09: 000000010beb47ecR10: ffff9ea494590090 R11: 0000000000000000 R12: 0000002000300000R13: ffffbbee806e7c90 R14: ffff9ea494513788 R15: ffffbbee806e7c88FS: 00007fc2f9e3e6c0(0000) GS:ffff9ea6b1444000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000000010beb47f4 CR3: 0000000119ac5000 CR4: 0000000000750ef0PKRU: 55555554Call Trace:<TASK>filemap_get_folios_tag+0x87/0x2a0__filemap_fdatawait_range+0x5f/0xd0? srso_alias_return_thunk+0x5/0xfbef5? __schedule+0x3e7/0x10c0? srso_alias_return_thunk+0x5/0xfbef5? srso_alias_return_thunk+0x5/0xfbef5? srso_alias_return_thunk+0x5/0xfbef5? preempt_count_sub+0x5f/0x80? srso_alias_return_thunk+0x5/0xfbef5? cap_safe_nice+0x37/0x70? srso_alias_return_thunk+0x5/0xfbef5? preempt_count_sub+0x5f/0x80? srso_alias_return_thunk+0x5/0xfbef5filemap_fdatawait_range_keep_errors+0x12/0x40ext4_fc_commit+0x697/0x8b0? ext4_file_write_iter+0x64b/0x950? srso_alias_return_thunk+0x5/0xfbef5? preempt_count_sub+0x5f/0x80? srso_alias_return_thunk+0x5/0xfbef5? vfs_write+0x356/0x480? srso_alias_return_thunk+0x5/0xfbef5? preempt_count_sub+0x5f/0x80ext4_sync_file+0xf7/0x370do_fsync+0x3b/0x80? syscall_trace_enter+0x108/0x1d0__x64_sys_fdatasync+0x16/0x20do_syscall_64+0x62/0x2c0entry_SYSCALL_64_after_hwframe+0x76/0x7e...```Fix this by initializing the jbd2_inode first.Use smp_wmb() and WRITE_ONCE() to publish ei->jinode afterinitialization. Readers use READ_ONCE() to fetch the pointer. CVE-2026-31523: In the Linux kernel, the following vulnerability has been resolved:nvme-pci: ensure we're polling a polled queueA user can change the polled queue count at run time. There's a briefwindow during a reset where a hipri task may try to poll that queuebefore the block layer has updated the queue maps, which would race withthe now interrupt driven queue and may cause double completions. CVE-2026-31530: In the Linux kernel, the following vulnerability has been resolved:cxl/port: Fix use after free of parent_port in cxl_detach_ep()cxl_detach_ep() is called during bottom-up removal when all CXL memorydevices beneath a switch port have been removed. For each port in thehierarchy it locks both the port and its parent, removes the endpoint,and if the port is now empty, marks it dead and unregisters the portby calling delete_switch_port(). There are two places during this workwhere the parent_port may be used after freeing:First, a concurrent detach may have already processed a port by thetime a second worker finds it via bus_find_device(). Without pinningparent_port, it may already be freed when we discover port->dead andattempt to unlock the parent_port. In a production kernel that's asilent memory corruption, with lock debug, it looks like this:[]DEBUG_LOCKS_WARN_ON(__owner_task(owner) != get_current())[]WARNING: kernel/locking/mutex.c:949 at __mutex_unlock_slowpath+0x1ee/0x310[]Call Trace:[]mutex_unlock+0xd/0x20[]cxl_detach_ep+0x180/0x400 [cxl_core][]devm_action_release+0x10/0x20[]devres_release_all+0xa8/0xe0[]device_unbind_cleanup+0xd/0xa0[]really_probe+0x1a6/0x3e0Second, delete_switch_port() releases three devm actions registeredagainst parent_port. The last of those is unregister_port() and itcalls device_unregister() on the child port, which can cascade. Ifparent_port is now also empty the device core may unregister and freeit too. So by the time delete_switch_port() returns, parent_port maybe free, and the subsequent device_unlock(&parent_port->dev) operateson freed memory. The kernel log looks same as above, with a differentoffset in cxl_detach_ep().Both of these issues stem from the absence of a lifetime guaranteebetween a child port and its parent port.Establish a lifetime rule for ports: child ports hold a reference totheir parent device until release. Take the reference when the portis allocated and drop it when released. This ensures the parent isvalid for the full lifetime of the child and eliminates the use afterfree window in cxl_detach_ep().This is easily reproduced with a reload of cxl_acpi in QEMU with CXLdevices present. CVE-2026-31693: In the Linux kernel, the following vulnerability has been resolved:cifs: some missing initializations on replayIn several places in the code, we have a label to signifythe start of the code where a request can be replayed ifnecessary. However, some of these places were missing thenecessary reinitializations of certain local variablesbefore replay.This change makes sure that these variables get initializedafter the label. CVE-2026-31705: In the Linux kernel, the following vulnerability has been resolved:ksmbd: fix out-of-bounds write in smb2_get_ea() EA alignmentsmb2_get_ea() applies 4-byte alignment padding via memset() afterwriting each EA entry. The bounds check on buf_free_len is performedbefore the value memcpy, but the alignment memset fires unconditionallyafterward with no check on remaining space.When the EA value exactly fills the remaining buffer (buf_free_len == 0after value subtraction), the alignment memset writes 1-3 NUL bytespast the buf_free_len boundary. In compound requests where the responsebuffer is shared across commands, the first command (e.g., READ) canconsume most of the buffer, leaving a tight remainder for the QUERY_INFOEA response. The alignment memset then overwrites past the physicalkvmalloc allocation into adjacent kernel heap memory.Add a bounds check before the alignment memset to ensure buf_free_lencan accommodate the padding bytes.This is the same bug pattern fixed by commit beef2634f81f ("ksmbd: fixpotencial OOB in get_file_all_info() for compound requests") andcommit fda9522ed6af ("ksmbd: fix OOB write in QUERY_INFO for compoundrequests"), both of which added bounds checks before unconditionalwrites in QUERY_INFO response handlers. CVE-2026-31708: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix OOB read in smb2_ioctl_query_info QUERY_INFO pathsmb2_ioctl_query_info() has two response-copy branches: PASSTHRU_FSCTLand the default QUERY_INFO path. The QUERY_INFO branch clampsqi.input_buffer_length to the server-reported OutputBufferLength and thencopies qi.input_buffer_length bytes from qi_rsp->Buffer to userspace, butit never verifies that the flexible-array payload actually fits withinrsp_iov[1].iov_len.A malicious server can return OutputBufferLength larger than the actualQUERY_INFO response, causing copy_to_user() to walk past the responsebuffer and expose adjacent kernel heap to userspace.Guard the QUERY_INFO copy with a bounds check on the actual Bufferpayload. Use struct_size(qi_rsp, Buffer, qi.input_buffer_length)rather than an open-coded addition so the guard cannot overflow on32-bit builds. CVE-2026-31711: In the Linux kernel, the following vulnerability has been resolved:smb: server: fix active_num_conn leak on transport allocation failureCommit 77ffbcac4e56 ("smb: server: fix leak of active_num_conn inksmbd_tcp_new_connection()") addressed the kthread_run() failurepath. The earlier alloc_transport() == NULL path in the samefunction has the same leak, is reachable pre-authentication via anyTCP connect to port 445, and was empirically reproduced on UML(ARCH=um, v7.0-rc7): a small number of forced allocation failureswere sufficient to put ksmbd into a state where every subsequentconnection attempt was rejected for the remainder of the boot.ksmbd_kthread_fn() increments active_num_conn before callingksmbd_tcp_new_connection() and discards the return value, so whenalloc_transport() returns NULL the socket is released and -ENOMEMreturned without decrementing the counter. Each such failurepermanently consumes one slot from the max_connections pool; oncecumulative failures reach the cap, atomic_inc_return() hits thethreshold on every subsequent accept and every new connection isrejected. The counter is only reset by module reload.An unauthenticated remote attacker can drive the server toward thememory pressure that makes alloc_transport() fail by holding openconnections with large RFC1002 lengths up to MAX_STREAM_PROT_LEN(0x00FFFFFF); natural transient allocation failures on a loadedhost produce the same drift more slowly.Mirror the existing rollback pattern in ksmbd_kthread_fn(): on thealloc_transport() failure path, decrement active_num_conn gated onserver_conf.max_connections.Repro details: with the patch reverted, forced alloc_transport()NULL returns leaked counter slots and subsequent connectionattempts -- including legitimate connects issued after theforced-fail window had closed -- were all rejected with "Limit themaximum number of connections". With this patch applied, the sameconnect sequence produces no rejections and the counter cyclescleanly between zero and one on every accept. CVE-2026-31714: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to avoid memory leak in f2fs_rename()syzbot reported a f2fs bug as below:BUG: memory leakunreferenced object 0xffff888127f70830 (size 16): comm "syz.0.23", pid 6144, jiffies 4294943712 hex dump (first 16 bytes): 3c af 57 72 5b e6 8f ad 6e 8e fd 33 42 39 03 ff <.Wr[...n..3B9.. backtrace (crc 925f8a80): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4520 [inline] slab_alloc_node mm/slub.c:4844 [inline] __do_kmalloc_node mm/slub.c:5237 [inline] __kmalloc_noprof+0x3bd/0x560 mm/slub.c:5250 kmalloc_noprof include/linux/slab.h:954 [inline] fscrypt_setup_filename+0x15e/0x3b0 fs/crypto/fname.c:364 f2fs_setup_filename+0x52/0xb0 fs/f2fs/dir.c:143 f2fs_rename+0x159/0xca0 fs/f2fs/namei.c:961 f2fs_rename2+0xd5/0xf20 fs/f2fs/namei.c:1308 vfs_rename+0x7ff/0x1250 fs/namei.c:6026 filename_renameat2+0x4f4/0x660 fs/namei.c:6144 __do_sys_renameat2 fs/namei.c:6173 [inline] __se_sys_renameat2 fs/namei.c:6168 [inline] __x64_sys_renameat2+0x59/0x80 fs/namei.c:6168 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/0x7fThe root cause is in commit 40b2d55e0452 ("f2fs: fix to create selinuxlabel during whiteout initialization"), we added a call tof2fs_setup_filename() without a matching call to f2fs_free_filename(),fix it. CVE-2026-31716: In the Linux kernel, the following vulnerability has been resolved:fs/ntfs3: validate rec->used in journal-replay file record checkcheck_file_record() validates rec->total against the record size butnever validates rec->used. The do_action() journal-replay handlers readrec->used from disk and use it to compute memmove lengths: DeleteAttribute: memmove(attr, ..., used - asize - roff) CreateAttribute: memmove(..., attr, used - roff) change_attr_size: memmove(..., used - PtrOffset(rec, next))When rec->used is smaller than the offset of a validated attribute, orlarger than the record size, these subtractions can underflow allowingus to copy huge amounts of memory in to a 4kb buffer, generallyconsidered a bad idea overall.This requires a corrupted filesystem, which isn't a threat model thekernel really needs to worry about, but checking for such an obviousout-of-bounds value is good to keep things robust, especially on journalreplayFix this up by bounding rec->used correctly.This is much like commit b2bc7c44ed17 ("fs/ntfs3: Fix slab-out-of-boundsread in DeleteIndexEntryRoot") which checked different values in thissame switch statement. CVE-2026-43046: In the Linux kernel, the following vulnerability has been resolved:btrfs: reject root items with drop_progress and zero drop_level[BUG]When recovering relocation at mount time, merge_reloc_root() andbtrfs_drop_snapshot() both use BUG_ON(level == 0) to guard againstan impossible state: a non-zero drop_progress combined with a zerodrop_level in a root_item, which can be triggered:------------[ cut here ]------------kernel BUG at fs/btrfs/relocation.c:1545!Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTICPU: 1 UID: 0 PID: 283 ... Tainted: 6.18.0+ #16 PREEMPT(voluntary)Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULEHardware name: QEMU Ubuntu 24.04 PC v2, BIOS 1.16.3-debian-1.16.3-2RIP: 0010:merge_reloc_root+0x1266/0x1650 fs/btrfs/relocation.c:1545Code: ffff0000 00004589 d7e9acfa ffffe8a1 79bafebe 02000000Call Trace: merge_reloc_roots+0x295/0x890 fs/btrfs/relocation.c:1861 btrfs_recover_relocation+0xd6e/0x11d0 fs/btrfs/relocation.c:4195 btrfs_start_pre_rw_mount+0xa4d/0x1810 fs/btrfs/disk-io.c:3130 open_ctree+0x5824/0x5fe0 fs/btrfs/disk-io.c:3640 btrfs_fill_super fs/btrfs/super.c:987 [inline] btrfs_get_tree_super fs/btrfs/super.c:1951 [inline] btrfs_get_tree_subvol fs/btrfs/super.c:2094 [inline] btrfs_get_tree+0x111c/0x2190 fs/btrfs/super.c:2128 vfs_get_tree+0x9a/0x370 fs/super.c:1758 fc_mount fs/namespace.c:1199 [inline] do_new_mount_fc fs/namespace.c:3642 [inline] do_new_mount fs/namespace.c:3718 [inline] path_mount+0x5b8/0x1ea0 fs/namespace.c:4028 do_mount fs/namespace.c:4041 [inline] __do_sys_mount fs/namespace.c:4229 [inline] __se_sys_mount fs/namespace.c:4206 [inline] __x64_sys_mount+0x282/0x320 fs/namespace.c:4206 ...RIP: 0033:0x7f969c9a8fdeCode: 0f1f4000 48c7c2b0 fffffff7 d8648902 b8ffffff ffc3660f---[ end trace 0000000000000000 ]---The bug is reproducible on 7.0.0-rc2-next-20260310 with our dynamicmetadata fuzzing tool that corrupts btrfs metadata at runtime.[CAUSE]A non-zero drop_progress.objectid means an interruptedbtrfs_drop_snapshot() left a resume point on disk, and in that casedrop_level must be greater than 0 because the checkpoint is onlysaved at internal node levels.Although this invariant is enforced when the kernel writes the rootitem, it is not validated when the root item is read back from disk.That allows on-disk corruption to provide an invalid state withdrop_progress.objectid != 0 and drop_level == 0.When relocation recovery later processes such a root item,merge_reloc_root() reads drop_level and hits BUG_ON(level == 0). Thesame invalid metadata can also trigger the corresponding BUG_ON() inbtrfs_drop_snapshot().[FIX]Fix this by validating the root_item invariant in tree-checker whenreading root items from disk: if drop_progress.objectid is non-zero,drop_level must also be non-zero. Reject such malformed metadata with-EUCLEAN before it reaches merge_reloc_root() or btrfs_drop_snapshot()and triggers the BUG_ON.After the fix, the same corruption is correctly rejected by tree-checkerand the BUG_ON is no longer triggered. CVE-2026-43053: In the Linux kernel, the following vulnerability has been resolved:xfs: close crash window in attr dabtree inactivationWhen inactivating an inode with node-format extended attributes,xfs_attr3_node_inactive() invalidates all child leaf/node blocks viaxfs_trans_binval(), but intentionally does not remove the correspondingentries from their parent node blocks. The implicit assumption is thatxfs_attr_inactive() will truncate the entire attr fork to zero extentsafterwards, so log recovery will never reach the root node and followthose stale pointers.However, if a log shutdown occurs after the leaf/node block cancellationscommit but before the attr bmap truncation commits, this assumptionbreaks. Recovery replays the attr bmap intact (the inode still hasattr fork extents), but suppresses replay of all cancelled leaf/nodeblocks, maybe leaving them as stale data on disk. On the next mount,xlog_recover_process_iunlinks() retries inactivation and attempts toread the root node via the attr bmap. If the root node was not replayed,reading the unreplayed root block triggers a metadata verificationfailure immediately; if it was replayed, following its child pointersto 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 117Fix this in two places:In xfs_attr3_node_inactive(), after calling xfs_trans_binval() on achild block, immediately remove the entry that references it from theparent node in the same transaction. This eliminates the window wherethe parent holds a pointer to a cancelled block. Once all children areremoved, the now-empty root node is converted to a leaf block within thesame transaction. This node-to-leaf conversion is necessary for crashsafety. If the system shutdown after the empty node is written to thelog but before the second-phase bmap truncation commits, log recoverywill 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 failverification and trigger a metadata corruption shutdown. on the otherhand, leaf blocks are allowed to have this transient state.In xfs_attr_inactive(), split the attr fork truncation into two explicitphases. First, truncate all extents beyond the root block (the childextents whose parent references have already been removed above).Second, invalidate the root block and truncate the attr bmap to zero ina single transaction. The two operations in the second phase must beatomic: as long as the attr bmap has any non-zero length, recovery canfollow it to the root block, so the root block invalidation must committogether with the bmap-to-zero truncation. CVE-2026-43066: In the Linux kernel, the following vulnerability has been resolved:ext4: fix iloc.bh leak in ext4_fc_replay_inode() error pathsDuring code review, Joseph found that ext4_fc_replay_inode() callsext4_get_fc_inode_loc() to get the inode location, which holds areference to iloc.bh that must be released via brelse().However, several error paths jump to the 'out' label withoutreleasing iloc.bh: - ext4_handle_dirty_metadata() failure - sync_dirty_buffer() failure - ext4_mark_inode_used() failure - ext4_iget() failureFix this by introducing an 'out_brelse' label placed just beforethe existing 'out' label to ensure iloc.bh is always released.Additionally, make ext4_fc_replay_inode() propagate errorsproperly instead of always returning 0. CVE-2026-43068: In the Linux kernel, the following vulnerability has been resolved:ext4: avoid allocate block from corrupted group in ext4_mb_find_by_goal()There's issue as follows:...EXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117EXT4-fs (mmcblk0p1): This should not happen!! Data will be lostEXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117EXT4-fs (mmcblk0p1): This should not happen!! Data will be lostEXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117EXT4-fs (mmcblk0p1): This should not happen!! Data will be lostEXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 206 at logical offset 0 with max blocks 1 with error 117EXT4-fs (mmcblk0p1): This should not happen!! Data will be lostEXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2243 at logical offset 0 with max blocks 1 with error 117EXT4-fs (mmcblk0p1): This should not happen!! Data will be lostEXT4-fs (mmcblk0p1): Delayed block allocation failed for inode 2239 at logical offset 0 with max blocks 1 with error 117EXT4-fs (mmcblk0p1): This should not happen!! Data will be lostEXT4-fs (mmcblk0p1): error count since last fsck: 1EXT4-fs (mmcblk0p1): initial error at time 1765597433: ext4_mb_generate_buddy:760EXT4-fs (mmcblk0p1): last error at time 1765597433: ext4_mb_generate_buddy:760...According to the log analysis, blocks are always requested from thecorrupted block group. This may happen as follows:ext4_mb_find_by_goal ext4_mb_load_buddy ext4_mb_load_buddy_gfp ext4_mb_init_cache ext4_read_block_bitmap_nowait ext4_wait_block_bitmap ext4_validate_block_bitmap if (!grp || EXT4_MB_GRP_BBITMAP_CORRUPT(grp)) return -EFSCORRUPTED; // There's no logs. if (err) return err; // Will return errorext4_lock_group(ac->ac_sb, group); if (unlikely(EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info))) // Unreachable goto out;After commit 9008a58e5dce ("ext4: make the bitmap read routines returnreal error codes") merged, Commit 163a203ddb36 ("ext4: mark block groupas corrupt on block bitmap error") is no real solution for allocatingblocks from corrupted block groups. This is because if'EXT4_MB_GRP_BBITMAP_CORRUPT(e4b->bd_info)' is true, then'ext4_mb_load_buddy()' may return an error. This means that the blockallocation will fail.Therefore, check block group if corrupted when ext4_mb_load_buddy()returns error. CVE-2026-43074: In the Linux kernel, the following vulnerability has been resolved:eventpoll: defer struct eventpoll free to RCU grace periodIn certain situations, ep_free() in eventpoll.c will kfree the epi->epeventpoll struct while it still being used by another concurrent thread.Defer the kfree() to an RCU callback to prevent UAF. CVE-2026-43125: In the Linux kernel, the following vulnerability has been resolved:dlm: validate length in dlm_search_rsb_treeThe len parameter in dlm_dump_rsb_name() is not validated and comesfrom network messages. When it exceeds DLM_RESNAME_MAXLEN, it cancause out-of-bounds write in dlm_search_rsb_tree().Add length validation to prevent potential buffer overflow. CVE-2026-43153: In the Linux kernel, the following vulnerability has been resolved:xfs: remove xfs_attr_leaf_hasnameThe calling convention of xfs_attr_leaf_hasname() is problematic, becauseit returns a NULL buffer when xfs_attr3_leaf_read fails, a valid bufferwhen xfs_attr3_leaf_lookup_int returns -ENOATTR or -EEXIST, and anon-NULL buffer pointer for an already released buffer whenxfs_attr3_leaf_lookup_int fails with other error values.Fix this by simply open coding xfs_attr_leaf_hasname in the callers, sothat the buffer release code is done by each caller ofxfs_attr3_leaf_read. CVE-2026-43168: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix reflink preserve cleanup issuecommit c06c303832ec ("ocfs2: fix xattr array entry __counted_by error")doesn't handle all cases and the cleanup job for preserved xattr entriesstill has bug:- the 'last' pointer should be shifted by one unit after cleanup an array entry.- current code logic doesn't cleanup the first entry when xh_count is 1.Note, commit c06c303832ec is also a bug fix for 0fe9b66c65f3. CVE-2026-43200: In the Linux kernel, the following vulnerability has been resolved:PCI: endpoint: Fix swapped parameters in pci_{primary/secondary}_epc_epf_unlink() functionsstruct configfs_item_operations callbacks are defined like the following: int (*allow_link)(struct config_item *src, struct config_item *target); void (*drop_link)(struct config_item *src, struct config_item *target);While pci_primary_epc_epf_link() and pci_secondary_epc_epf_link() specifythe parameters in the correct order, pci_primary_epc_epf_unlink() andpci_secondary_epc_epf_unlink() specify the parameters in the wrong order,leading to the below kernel crash when using the unlink command inconfigfs: Unable to handle kernel paging request at virtual address 0000000300000857 Mem abort info: ... pc : string+0x54/0x14c lr : vsnprintf+0x280/0x6e8 ... string+0x54/0x14c vsnprintf+0x280/0x6e8 vprintk_default+0x38/0x4c vprintk+0xc4/0xe0 pci_epf_unbind+0xdc/0x108 configfs_unlink+0xe0/0x208+0x44/0x74 vfs_unlink+0x120/0x29c __arm64_sys_unlinkat+0x3c/0x90 invoke_syscall+0x48/0x134 do_el0_svc+0x1c/0x30prop.0+0xd0/0xf0[mani: cced stable, changed commit message as per https://lore.kernel.org/linux-pci/aV9joi3jF1R6ca02@ryzen] CVE-2026-43211: In the Linux kernel, the following vulnerability has been resolved:PCI: Fix pci_slot_trylock() error handlingCommit a4e772898f8b ("PCI: Add missing bridge lock to pci_bus_lock()")delegates the bridge device's pci_dev_trylock() to pci_bus_trylock() inpci_slot_trylock(), but it forgets to remove the correspondingpci_dev_unlock() when pci_bus_trylock() fails.Before a4e772898f8b, the code did: if (!pci_dev_trylock(dev)) /* <- lock bridge device */ goto unlock; if (dev->subordinate) { if (!pci_bus_trylock(dev->subordinate)) { pci_dev_unlock(dev); /* <- unlock bridge device */ goto unlock; } }After a4e772898f8b the bridge-device lock is no longer taken, but thepci_dev_unlock(dev) on the failure path was left in place, leading to thebug.This yields one of two errors: 1. A warning that the lock is being unlocked when no one holds it. 2. An incorrect unlock of a lock that belongs to another thread.Fix it by removing the now-redundant pci_dev_unlock(dev) on the failurepath.[Same patch later posted by Keith athttps://patch.msgid.link/[email protected]] CVE-2026-43262: In the Linux kernel, the following vulnerability has been resolved:gfs2: fiemap page fault fixIn gfs2_fiemap(), we are calling iomap_fiemap() while holding the inodeglock. This can lead to recursive glock taking if the fiemap buffer ismemory mapped to the same inode and accessing it triggers a page fault.Fix by disabling page faults for iomap_fiemap() and faulting in thebuffer by hand if necessary.Fixes xfstest generic/742. CVE-2026-43288: In the Linux kernel, the following vulnerability has been resolved:ext4: move ext4_percpu_param_init() before ext4_mb_init()When running `kvm-xfstests -c ext4/1k -C 1 generic/383` with the`DOUBLE_CHECK` macro defined, the following panic is triggered:==================================================================EXT4-fs error (device vdc): ext4_validate_block_bitmap:423: comm mount: bg 0: bad block bitmap checksumBUG: unable to handle page fault for address: ff110000fa2cc000PGD 3e01067 P4D 3e02067 PUD 0Oops: Oops: 0000 [#1] SMP NOPTICPU: 0 UID: 0 PID: 2386 Comm: mount Tainted: G W 6.18.0-gba65a4e7120a-dirty #1152 PREEMPT(none)RIP: 0010:percpu_counter_add_batch+0x13/0xa0Call Trace: <TASK> ext4_mark_group_bitmap_corrupted+0xcb/0xe0 ext4_validate_block_bitmap+0x2a1/0x2f0 ext4_read_block_bitmap+0x33/0x50 mb_group_bb_bitmap_alloc+0x33/0x80 ext4_mb_add_groupinfo+0x190/0x250 ext4_mb_init_backend+0x87/0x290 ext4_mb_init+0x456/0x640 __ext4_fill_super+0x1072/0x1680 ext4_fill_super+0xd3/0x280 get_tree_bdev_flags+0x132/0x1d0 vfs_get_tree+0x29/0xd0 vfs_cmd_create+0x59/0xe0 __do_sys_fsconfig+0x4f6/0x6b0 do_syscall_64+0x50/0x1f0 entry_SYSCALL_64_after_hwframe+0x76/0x7e==================================================================This issue can be reproduced using the following commands: mkfs.ext4 -F -q -b 1024 /dev/sda 5G tune2fs -O quota,project /dev/sda mount /dev/sda /tmp/testWith DOUBLE_CHECK defined, mb_group_bb_bitmap_alloc() readsand validates the block bitmap. When the validation fails,ext4_mark_group_bitmap_corrupted() attempts to updatesbi->s_freeclusters_counter. However, this percpu_counter has not beeninitialized yet at this point, which leads to the panic described above.Fix this by moving the execution of ext4_percpu_param_init() to occurbefore ext4_mb_init(), ensuring the per-CPU counters are initializedbefore they are used. 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 criticalpath, btrfs flips RO (this part is expected, although the ENOSPC bugstill needs to be addressed).The problem is after the RO flip, if there is a read repair pending, wecan 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 stillunknown, although it's known that we still have cases where metadata canbe over-committed but can not be fulfilled correctly, thus if we hitsuch ENOSPC error inside a critical path, we have no choice but abortthe current transaction.This will mark the fs read-only.The problem is inside the btrfs_repair_io_failure() path that we requirethe fs not to be mount read-only. This is normally fine, but if we aredoing a read-repair meanwhile the fs flips RO due to a critical error,we can enter btrfs_repair_io_failure() with super block set toread-only, thus triggering the above crash.[FIX]Just replace the ASSERT() with a proper return if the fs is alreadyread-only. CVE-2026-43338: In the Linux kernel, the following vulnerability has been resolved:btrfs: reserve enough transaction items for qgroup ioctlsCurrently our qgroup ioctls don't reserve any space, they just do atransaction join, which does not reserve any space, neither for the quotatree updates nor for the delayed refs generated when updating the quotatree. The quota root uses the global block reserve, which is fine most ofthe time since we don't expect a lot of updates to the quota root, or tobe too close to -ENOSPC such that other critical metadata updates need toresort to the global reserve.However this is not optimal, as not reserving proper space may result in atransaction abort due to not reserving space for delayed refs and thenabusing the use of the global block reserve.For example, the following reproducer (which is unlikely to model anyreal world use case, but just to illustrate the problem), triggers such atransaction 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 $MNTWhen running this, we can see in dmesg/syslog that a transaction aborthappened: [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-43350: In the Linux kernel, the following vulnerability has been resolved:smb: client: require a full NFS mode SID before reading mode bitsparse_dacl() treats an ACE SID matching sid_unix_NFS_mode as an NFSmode SID and reads sid.sub_auth[2] to recover the mode bits.That assumes the ACE carries three subauthorities, but compare_sids()only compares min(a, b) subauthorities. A malicious server can returnan ACE with num_subauth = 2 and sub_auth[] = {88, 3}, which stillmatches sid_unix_NFS_mode and then drives the sub_auth[2] read fourbytes past the end of the ACE.Require num_subauth >= 3 before treating the ACE as an NFS mode SID.This keeps the fix local to the special-SID mode path without changingcompare_sids() semantics for the rest of cifsacl. CVE-2026-43359: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix transaction abort on set received ioctl due to item overflowIf the set received ioctl fails due to an item overflow when attempting toadd the BTRFS_UUID_KEY_RECEIVED_SUBVOL we have to abort the transactionsince we did some metadata updates before.This means that if a user calls this ioctl with the same received UUIDfield for a lot of subvolumes, we will hit the overflow, trigger thetransaction abort and turn the filesystem into RO mode. A malicious usercould exploit this, and this ioctl does not even requires that a userhas admin privileges (CAP_SYS_ADMIN), only that he/she owns the subvolume.Fix this by doing an early check for item overflow before starting atransaction. This is also race safe because we are holding the subvol_semsemaphore in exclusive (write) mode.A test case for fstests will follow soon. CVE-2026-43360: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix transaction abort on file creation due to name hash collisionIf we attempt to create several files with names that result in the samehash, we have to pack them in same dir item and that has a limit inherentto the leaf size. However if we reach that limit, we trigger a transactionabort and turns the filesystem into RO mode. This allows for a malicioususer to disrupt a system, without the need to have administrationprivileges/capabilities.Reproducer: $ cat exploit-hash-collisions.sh #!/bin/bash DEV=/dev/sdi MNT=/mnt/sdi # Use smallest node size to make the test faster and require fewer file # names that result in hash collision. mkfs.btrfs -f --nodesize 4K $DEV mount $DEV $MNT # List of names that result in the same crc32c hash for btrfs. declare -a names=( 'foobar' '%a8tYkxfGMLWRGr55QSeQc4PBNH9PCLIvR6jZnkDtUUru1t@RouaUe_L:@xGkbO3nCwvLNYeK9vhE628gss:T$yZjZ5l-Nbd6CbC$M=hqE-ujhJICXyIxBvYrIU9-TDC' 'AQci3EUB%shMsg-N%frgU:02ByLs=IPJU0OpgiWit5nexSyxZDncY6WB:=zKZuk5Zy0DD$Ua78%MelgBuMqaHGyKsJUFf9s=UW80PcJmKctb46KveLSiUtNmqrMiL9-Y0I_l5Fnam04CGIg=8@U:Z' 'CvVqJpJzueKcuA$wqwePfyu7VxuWNN3ho$p0zi2H8QFYK$7YlEqOhhb%:hHgjhIjW5vnqWHKNP4' 'ET:vk@rFU4tsvMB0$C_p=xQHaYZjvoF%-BTc%wkFW8yaDAPcCYoR%x$FH5O:' 'HwTon%v7SGSP4FE08jBwwiu5aot2CFKXHTeEAa@38fUcNGOWvE@Mz6WBeDH_VooaZ6AgsXPkVGwy9l@@ZbNXabUU9csiWrrOp0MWUdfi$EZ3w9GkIqtz7I_eOsByOkBOO' 'Ij%2VlFGXSuPvxJGf5UWy6O@1svxGha%b@=%wjkq:CIgE6u7eJOjmQY5qTtxE2Rjbis9@us' 'KBkjG5%9R8K9sOG8UTnAYjxLNAvBmvV5vz3IiZaPmKuLYO03-6asI9lJ_j4@6Xo$KZicaLWJ3Pv8XEwVeUPMwbHYWwbx0pYvNlGMO9F:ZhHAwyctnGy%_eujl%WPd4U2BI7qooOSr85J-C2V$LfY' 'NcRfDfuUQ2=zP8K3CCF5dFcpfiOm6mwenShsAb_F%n6GAGC7fT2JFFn:c35X-3aYwoq7jNX5$ZJ6hI3wnZs$7KgGi7wjulffhHNUxAT0fRRLF39vJ@NvaEMxsMO' 'Oj42AQAEzRoTxa5OuSKIr=A_lwGMy132v4g3Pdq1GvUG9874YseIFQ6QU' 'Ono7avN5GjC:_6dBJ_' 'WHmN2gnmaN-9dVDy4aWo:yNGFzz8qsJyJhWEWcud7$QzN2D9R0efIWWEdu5kwWr73NZm4=@CoCDxrrZnRITr-kGtU_cfW2:%2_am' 'WiFnuTEhAG9FEC6zopQmj-A-$LDQ0T3WULz%ox3UZAPybSV6v1Z$b4L_XBi4M4BMBtJZpz93r9xafpB77r:lbwvitWRyo$odnAUYlYMmU4RvgnNd--e=I5hiEjGLETTtaScWlQp8mYsBovZwM2k' 'XKyH=OsOAF3p%uziGF_ZVr$ivrvhVgD@1u%5RtrV-gl_vqAwHkK@x7YwlxX3qT6WKKQ%PR56NrUBU2dOAOAdzr2=5nJuKPM-T-$ZpQfCL7phxQbUcb:BZOTPaFExc-qK-gDRCDW2' 'd3uUR6OFEwZr%ns1XH_@tbxA@cCPmbBRLdyh7p6V45H$P2$F%w0RqrD3M0g8aGvWpoTFMiBdOTJXjD:JF7=h9a_43xBywYAP%r$SPZi%zDg%ql-KvkdUCtF9OLaQlxmd' 'ePTpbnit%hyNm@WELlpKzNZYOzOTf8EQ$sEfkMy1VOfIUu3coyvIr13-Y7Sv5v-Ivax2Go_GQRFMU1b3362nktT9WOJf3SpT%z8sZmM3gvYQBDgmKI%%RM-G7hyrhgYflOw%z::ZRcv5O:lDCFm' 'evqk743Y@dvZAiG5J05L_ROFV@$2%rVWJ2%3nxV72-W7$e$-SK3tuSHA2mBt$qloC5jwNx33GmQUjD%akhBPu=VJ5g$xhlZiaFtTrjeeM5x7dt4cHpX0cZkmfImndYzGmvwQG:$euFYmXn$_2rA9mKZ' 'gkgUtnihWXsZQTEkrMAWIxir09k3t7jk_IK25t1:cy1XWN0GGqC%FrySdcmU7M8MuPO_ppkLw3=Dfr0UuBAL4%GFk2$Ma10V1jDRGJje%Xx9EV2ERaWKtjpwiZwh0gCSJsj5UL7CR8RtW5opCVFKGGy8Cky' 'hNgsG_8lNRik3PvphqPm0yEH3P%%fYG:kQLY=6O-61Wa6nrV_WVGR6TLB09vHOv%g4VQRP8Gzx7VXUY1qvZyS' 'isA7JVzN12xCxVPJZ_qoLm-pTBuhjjHMvV7o=F:EaClfYNyFGlsfw-Kf%uxdqW-kwk1sPl2vhbjyHU1A6$hz' 'kiJ_fgcdZFDiOptjgH5PN9-PSyLO4fbk_:u5_2tz35lV_iXiJ6cx7pwjTtKy-XGaQ5IefmpJ4N_ZqGsqCsKuqOOBgf9LkUdffHet@Wu' 'lvwtxyhE9:%Q3UxeHiViUyNzJsy:fm38pg_b6s25JvdhOAT=1s0$pG25x=LZ2rlHTszj=gN6M4zHZYr_qrB49i=pA--@WqWLIuX7o1S_SfS@2FSiUZN' 'rC24cw3UBDZ=5qJBUMs9e$=S4Y94ni%Z8639vnrGp=0Hv4z3dNFL0fBLmQ40=EYIY:Z=SLc@QLMSt2zsss2ZXrP7j4=' 'uwGl2s-fFrf@GqS=DQqq2I0LJSsOmM%xzTjS:lzXguE3wChdMoHYtLRKPvfaPOZF2fER@j53evbKa7R%A7r4%YEkD=kicJe@SFiGtXHbKe4gCgPAYbnVn' 'UG37U6KKua2bgc:IHzRs7BnB6FD:2Mt5Cc5NdlsW%$1tyvnfz7S27FvNkroXwAW:mBZLA1@qa9WnDbHCDmQmfPMC9z-Eq6QT0jhhPpqyymaD:R02ghwYo%yx7SAaaq-:x33LYpei$5g8DMl3C' 'y2vjek0FE1PDJC0qpfnN:x8k2wCFZ9xiUF2ege=JnP98R%wxjKkdfEiLWvQzmnW' '8-HCSgH5B%K7P8_jaVtQhBXpBk:pE-$P7ts58U0J@iR9YZntMPl7j$s62yAJO@_9eanFPS54b=UTw$94C-t=HLxT8n6o9P=QnIxq-f1=Ne2dvhe6WbjEQtc' 'YPPh:IFt2mtR6XWSmjHptXL_hbSYu8bMw-JP8@PNyaFkdNFsk$M=xfL6LDKCDM-mSyGA_2MBwZ8Dr4=R1D%7-mC---truncated--- CVE-2026-43361: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix transaction abort when snapshotting received subvolumesCurrently a user can trigger a transaction abort by snapshotting apreviously received snapshot a bunch of times until we reach aBTRFS_UUID_KEY_RECEIVED_SUBVOL item overflow (the maximum item size wecan store in a leaf). This is very likely not common in practice, butif it happens, it turns the filesystem into RO mode. The snapshot, sendand set_received_subvol and subvol_setflags (used by receive) don'trequire CAP_SYS_ADMIN, just inode_owner_or_capable(). A malicious usercould use this to turn a filesystem into RO mode and disrupt a system.Reproducer script: $ cat test.sh #!/bin/bash DEV=/dev/sdi MNT=/mnt/sdi # Use smallest node size to make the test faster. mkfs.btrfs -f --nodesize 4K $DEV mount $DEV $MNT # Create a subvolume and set it to RO so that it can be used for send. btrfs subvolume create $MNT/sv touch $MNT/sv/foo btrfs property set $MNT/sv ro true # Send and receive the subvolume into snaps/sv. mkdir $MNT/snaps btrfs send $MNT/sv | btrfs receive $MNT/snaps # Now snapshot the received subvolume, which has a received_uuid, a # lot of times to trigger the leaf overflow. total=500 for ((i = 1; i <= $total; i++)); do echo -ne "\rCreating snapshot $i/$total" btrfs subvolume snapshot -r $MNT/snaps/sv $MNT/snaps/sv_$i > /dev/null done echo umount $MNTWhen running the test: $ ./test.sh (...) Create subvolume '/mnt/sdi/sv' At subvol /mnt/sdi/sv At subvol sv Creating snapshot 496/500ERROR: Could not create subvolume: Value too large for defined data type Creating snapshot 497/500ERROR: Could not create subvolume: Read-only file system Creating snapshot 498/500ERROR: Could not create subvolume: Read-only file system Creating snapshot 499/500ERROR: Could not create subvolume: Read-only file system Creating snapshot 500/500ERROR: Could not create subvolume: Read-only file systemAnd in dmesg/syslog: $ dmesg (...) [251067.627338] BTRFS warning (device sdi): insert uuid item failed -75 (0x4628b21c4ac8d898, 0x2598bee2b1515c91) type 252! [251067.629212] ------------[ cut here ]------------ [251067.630033] BTRFS: Transaction aborted (error -75) [251067.630871] WARNING: fs/btrfs/transaction.c:1907 at create_pending_snapshot.cold+0x52/0x465 [btrfs], CPU#10: btrfs/615235 [251067.632851] Modules linked in: btrfs dm_zero (...) [251067.644071] CPU: 10 UID: 0 PID: 615235 Comm: btrfs Tainted: G W 6.19.0-rc8-btrfs-next-225+ #1 PREEMPT(full) [251067.646165] Tainted: [W]=WARN [251067.646733] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 [251067.648735] RIP: 0010:create_pending_snapshot.cold+0x55/0x465 [btrfs] [251067.649984] Code: f0 48 0f (...) [251067.653313] RSP: 0018:ffffce644908fae8 EFLAGS: 00010292 [251067.653987] RAX: 00000000ffffff01 RBX: ffff8e5639e63a80 RCX: 00000000ffffffd3 [251067.655042] RDX: ffff8e53faa76b00 RSI: 00000000ffffffb5 RDI: ffffffffc0919750 [251067.656077] RBP: ffffce644908fbd8 R08: 0000000000000000 R09: ffffce644908f820 [251067.657068] R10: ffff8e5adc1fffa8 R11: 0000000000000003 R12: ffff8e53c0431bd0 [251067.658050] R13: ffff8e5414593600 R14: ffff8e55efafd000 R15: 00000000ffffffb5 [251067.659019] FS: 00007f2a4944b3c0(0000) GS:ffff8e5b27dae000(0000) knlGS:0000000000000000 [251067.660115] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [251067.660943] CR2: 00007ffc5aa57898 CR3: 00000005813a2003 CR4: 0000000000370ef0 [251067.661972] Call Trace: [251067.662292] <TASK> [251067.662653] create_pending_snapshots+0x97/0xc0 [btrfs] [251067.663413] btrfs_commit_transaction+0x26e/0xc00 [btrfs] [251067.664257] ? btrfs_qgroup_convert_reserved_meta+0x35/0x390 [btrfs] [251067.665238] ? _raw_spin_unlock+0x15/0x30 [251067.665837] ? record_root_---truncated--- 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 withciphertext. 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 areunstable, as reconnects trigger write retries that re-send thealready-encrypted data.This affects SFU mknod, MF symlinks, etc. On kernels before6.10 (prior to the netfs conversion), sync writes also usedthis path and were similarly affected. The async write pathwasn'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-43366: In the Linux kernel, the following vulnerability has been resolved:io_uring/kbuf: check if target buffer list is still legacy on recycleThere's a gap between when the buffer was grabbed and when itpotentially gets recycled, where if the list is empty, someone could'veupgraded it to a ring provided type. This can happen if the requestis forced via io-wq. The legacy recycling is missing checking if thebuffer_list still exists, and if it's of the correct type. Add thosechecks. CVE-2026-43376: In the Linux kernel, the following vulnerability has been resolved:ksmbd: fix use-after-free by using call_rcu() for oplock_infoksmbd currently frees oplock_info immediately using kfree(), eventhough it is accessed under RCU read-side critical sections in placeslike opinfo_get() and proc_show_files().Since there is no RCU grace period delay between nullifying the pointerand freeing the memory, a reader can still access oplock_infostructure after it has been freed. This can leads to a use-after-freeespecially in opinfo_get() where atomic_inc_not_zero() is called onalready freed memory.Fix this by switching to deferred freeing using call_rcu(). CVE-2026-43377: In the Linux kernel, the following vulnerability has been resolved:ksmbd: Don't log keys in SMB3 signing and encryption key generationWhen KSMBD_DEBUG_AUTH logging is enabled, generate_smb3signingkey() andgenerate_smb3encryptionkey() log the session, signing, encryption, anddecryption key bytes. Remove the logs to avoid exposing credentials. CVE-2026-43379: In the Linux kernel, the following vulnerability has been resolved:ksmbd: fix use-after-free in smb_lazy_parent_lease_break_close()opinfo pointer obtained via rcu_dereference(fp->f_opinfo) is beingaccessed after rcu_read_unlock() has been called. This creates arace condition where the memory could be freed by a concurrentwriter between the unlock and the subsequent pointer dereferences(opinfo->is_lease, etc.), leading to a use-after-free. CVE-2026-43414: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Completely fix fcport double freeIn 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-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 notpassed to the caller via path_info.path, the function must free itbefore returning. CVE-2026-43420: In the Linux kernel, the following vulnerability has been resolved:ceph: fix i_nlink underrun during async unlinkDuring async unlink, we drop the `i_nlink` counter before we receivethe completion (that will eventually update the `i_nlink`) because "weassume that the unlink will succeed". That is not a bad idea, but itraces against deletions by other clients (or against the completion ofour own unlink) and can lead to an underrun which emits a WARNING likethis one: WARNING: CPU: 85 PID: 25093 at fs/inode.c:407 drop_nlink+0x50/0x68 Modules linked in: CPU: 85 UID: 3221252029 PID: 25093 Comm: php-cgi8.1 Not tainted 6.14.11-cm4all1-ampere #655 Hardware name: Supermicro ARS-110M-NR/R12SPD-A, BIOS 1.1b 10/17/2023 pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : drop_nlink+0x50/0x68 lr : ceph_unlink+0x6c4/0x720 sp : ffff80012173bc90 x29: ffff80012173bc90 x28: ffff086d0a45aaf8 x27: ffff0871d0eb5680 x26: ffff087f2a64a718 x25: 0000020000000180 x24: 0000000061c88647 x23: 0000000000000002 x22: ffff07ff9236d800 x21: 0000000000001203 x20: ffff07ff9237b000 x19: ffff088b8296afc0 x18: 00000000f3c93365 x17: 0000000000070000 x16: ffff08faffcbdfe8 x15: ffff08faffcbdfec x14: 0000000000000000 x13: 45445f65645f3037 x12: 34385f6369706f74 x11: 0000a2653104bb20 x10: ffffd85f26d73290 x9 : ffffd85f25664f94 x8 : 00000000000000c0 x7 : 0000000000000000 x6 : 0000000000000002 x5 : 0000000000000081 x4 : 0000000000000481 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff08727d3f91e8 Call trace: drop_nlink+0x50/0x68 (P) vfs_unlink+0xb0/0x2e8 do_unlinkat+0x204/0x288 __arm64_sys_unlinkat+0x3c/0x80 invoke_syscall.constprop.0+0x54/0xe8 do_el0_svc+0xa4/0xc8 el0_svc+0x18/0x58 el0t_64_sync_handler+0x104/0x130 el0t_64_sync+0x154/0x158In ceph_unlink(), a call to ceph_mdsc_submit_request() submits theCEPH_MDS_OP_UNLINK to the MDS, but does not wait for completion.Meanwhile, between this call and the following drop_nlink() call, aworker thread may process a CEPH_CAP_OP_IMPORT, CEPH_CAP_OP_GRANT orjust a CEPH_MSG_CLIENT_REPLY (the latter of which could be our owncompletion). These will lead to a set_nlink() call, updating the`i_nlink` counter to the value received from the MDS. If that new`i_nlink` value happens to be zero, it is illegal to decrement itfurther. But that is exactly what ceph_unlink() will do then.The WARNING can be reproduced this way:1. Force async unlink; only the async code path is affected. Having no real clue about Ceph internals, I was unable to find out why the MDS wouldn't give me the "Fxr" capabilities, so I patched get_caps_for_async_unlink() to always succeed. (Note that the WARNING dump above was found on an unpatched kernel, without this kludge - this is not a theoretical bug.)2. Add a sleep call after ceph_mdsc_submit_request() so the unlink completion gets handled by a worker thread before drop_nlink() is called. This guarantees that the `i_nlink` is already zero before drop_nlink() runs.The solution is to skip the counter decrement when it is already zero,but doing so without a lock is still racy (TOCTOU). Sinceceph_fill_inode() and handle_cap_grant() both hold the`ceph_inode_info.i_ceph_lock` spinlock while set_nlink() runs, thisseems like the proper lock to protect the `i_nlink` updates.I found prior art in NFS and SMB (using `inode.i_lock`) and AFS (using`afs_vnode.cb_lock`). All three have the zero check as well. CVE-2026-43448: In the Linux kernel, the following vulnerability has been resolved:nvme-pci: Fix race bug in nvme_poll_irqdisable()In the following scenario, pdev can be disabled between (1) and (3) by(2). This sets pdev->msix_enabled = 0. Then, pci_irq_vector() willreturn MSI-X IRQ(>15) for (1) whereas return INTx IRQ(<=15) for (2).This causes IRQ warning because it tries to enable INTx IRQ that hasnever been disabled before.To fix this, save IRQ number into a local variable and ensuredisable_irq() and enable_irq() operate on the same IRQ number. Even ifpci_free_irq_vectors() frees the IRQ concurrently, disable_irq() andenable_irq() on a stale IRQ number is still valid and safe, and thedepth accounting reamins balanced.task 1:nvme_poll_irqdisable() disable_irq(pci_irq_vector(pdev, nvmeq->cq_vector)) ...(1) enable_irq(pci_irq_vector(pdev, nvmeq->cq_vector)) ...(3)task 2:nvme_reset_work() nvme_dev_disable() pdev->msix_enable = 0; ...(2)crash log:------------[ cut here ]------------Unbalanced enable for IRQ 10WARNING: kernel/irq/manage.c:753 at __enable_irq+0x102/0x190 kernel/irq/manage.c:753, CPU#1: kworker/1:0H/26Modules linked in:CPU: 1 UID: 0 PID: 26 Comm: kworker/1:0H Not tainted 6.19.0-dirty #9 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014Workqueue: kblockd blk_mq_timeout_workRIP: 0010:__enable_irq+0x107/0x190 kernel/irq/manage.c:753Code: ff df 48 89 fa 48 c1 ea 03 0f b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 04 84 d2 75 79 48 8d 3d 2e 7a 3f 05 41 8b 74 24 2c <67> 48 0f b9 3a e8 ef b9 21 00 5b 41 5c 5d e9 46 54 66 03 e8 e1 b9RSP: 0018:ffffc900001bf550 EFLAGS: 00010046RAX: 0000000000000007 RBX: 0000000000000000 RCX: ffffffffb20c0e90RDX: 0000000000000000 RSI: 000000000000000a RDI: ffffffffb74b88f0RBP: ffffc900001bf560 R08: ffff88800197cf00 R09: 0000000000000001R10: 0000000000000003 R11: 0000000000000003 R12: ffff8880012a6000R13: 1ffff92000037eae R14: 000000000000000a R15: 0000000000000293FS: 0000000000000000(0000) GS:ffff8880b49f7000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000555da4a25fa8 CR3: 00000000208e8000 CR4: 00000000000006f0Call Trace: <TASK> enable_irq+0x121/0x1e0 kernel/irq/manage.c:797 nvme_poll_irqdisable+0x162/0x1c0 drivers/nvme/host/pci.c:1494 nvme_timeout+0x965/0x14b0 drivers/nvme/host/pci.c:1744 blk_mq_rq_timed_out block/blk-mq.c:1653 [inline] blk_mq_handle_expired+0x227/0x2d0 block/blk-mq.c:1721 bt_iter+0x2fc/0x3a0 block/blk-mq-tag.c:292 __sbitmap_for_each_set include/linux/sbitmap.h:269 [inline] sbitmap_for_each_set include/linux/sbitmap.h:290 [inline] bt_for_each block/blk-mq-tag.c:324 [inline] blk_mq_queue_tag_busy_iter+0x969/0x1e80 block/blk-mq-tag.c:536 blk_mq_timeout_work+0x627/0x870 block/blk-mq.c:1763 process_one_work+0x956/0x1aa0 kernel/workqueue.c:3257 process_scheduled_works kernel/workqueue.c:3340 [inline] worker_thread+0x65c/0xe60 kernel/workqueue.c:3421 kthread+0x41a/0x930 kernel/kthread.c:463 ret_from_fork+0x6f8/0x8c0 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 </TASK>irq event stamp: 74478hardirqs last enabled at (74477): [<ffffffffb5720a9c>] __raw_spin_unlock_irq include/linux/spinlock_api_smp.h:159 [inline]hardirqs last enabled at (74477): [<ffffffffb5720a9c>] _raw_spin_unlock_irq+0x2c/0x60 kernel/locking/spinlock.c:202hardirqs last disabled at (74478): [<ffffffffb57207b5>] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline]hardirqs last disabled at (74478): [<ffffffffb57207b5>] _raw_spin_lock_irqsave+0x85/0xa0 kernel/locking/spinlock.c:162softirqs last enabled at (74304): [<ffffffffb1e9466c>] __do_softirq kernel/softirq.c:656 [inline]softirqs last enabled at (74304): [<ffffffffb1e9466c>] invoke_softirq kernel/softirq.c:496 [inline]softirqs last enabled at (74304): [<ffffffffb1e9466c>] __irq_exit_rcu+0xdc/0x120---truncated--- CVE-2026-43449: In the Linux kernel, the following vulnerability has been resolved:nvme-pci: Fix slab-out-of-bounds in nvme_dbbuf_setdev->online_queues is a count incremented in nvme_init_queue. Thus,valid indices are 0 through dev->online_queues − 1.This patch fixes the loop condition to ensure the index stays within thevalid range. Index 0 is excluded because it is the admin queue.KASAN splat:==================================================================BUG: KASAN: slab-out-of-bounds in nvme_dbbuf_free drivers/nvme/host/pci.c:377 [inline]BUG: KASAN: slab-out-of-bounds in nvme_dbbuf_set+0x39c/0x400 drivers/nvme/host/pci.c:404Read of size 2 at addr ffff88800592a574 by task kworker/u8:5/74CPU: 0 UID: 0 PID: 74 Comm: kworker/u8:5 Not tainted 6.19.0-dirty #10 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014Workqueue: nvme-reset-wq nvme_reset_workCall Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xea/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xce/0x5d0 mm/kasan/report.c:482 kasan_report+0xdc/0x110 mm/kasan/report.c:595 __asan_report_load2_noabort+0x18/0x20 mm/kasan/report_generic.c:379 nvme_dbbuf_free drivers/nvme/host/pci.c:377 [inline] nvme_dbbuf_set+0x39c/0x400 drivers/nvme/host/pci.c:404 nvme_reset_work+0x36b/0x8c0 drivers/nvme/host/pci.c:3252 process_one_work+0x956/0x1aa0 kernel/workqueue.c:3257 process_scheduled_works kernel/workqueue.c:3340 [inline] worker_thread+0x65c/0xe60 kernel/workqueue.c:3421 kthread+0x41a/0x930 kernel/kthread.c:463 ret_from_fork+0x6f8/0x8c0 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 </TASK>Allocated by task 34 on cpu 1 at 4.241550s: kasan_save_stack+0x2c/0x60 mm/kasan/common.c:57 kasan_save_track+0x1c/0x70 mm/kasan/common.c:78 kasan_save_alloc_info+0x3c/0x50 mm/kasan/generic.c:570 poison_kmalloc_redzone mm/kasan/common.c:398 [inline] __kasan_kmalloc+0xb5/0xc0 mm/kasan/common.c:415 kasan_kmalloc include/linux/kasan.h:263 [inline] __do_kmalloc_node mm/slub.c:5657 [inline] __kmalloc_node_noprof+0x2bf/0x8d0 mm/slub.c:5663 kmalloc_array_node_noprof include/linux/slab.h:1075 [inline] nvme_pci_alloc_dev drivers/nvme/host/pci.c:3479 [inline] nvme_probe+0x2f1/0x1820 drivers/nvme/host/pci.c:3534 local_pci_probe+0xef/0x1c0 drivers/pci/pci-driver.c:324 pci_call_probe drivers/pci/pci-driver.c:392 [inline] __pci_device_probe drivers/pci/pci-driver.c:417 [inline] pci_device_probe+0x743/0x920 drivers/pci/pci-driver.c:451 call_driver_probe drivers/base/dd.c:583 [inline] really_probe+0x29b/0xb70 drivers/base/dd.c:661 __driver_probe_device+0x3b0/0x4a0 drivers/base/dd.c:803 driver_probe_device+0x56/0x1f0 drivers/base/dd.c:833 __driver_attach_async_helper+0x155/0x340 drivers/base/dd.c:1159 async_run_entry_fn+0xa6/0x4b0 kernel/async.c:129 process_one_work+0x956/0x1aa0 kernel/workqueue.c:3257 process_scheduled_works kernel/workqueue.c:3340 [inline] worker_thread+0x65c/0xe60 kernel/workqueue.c:3421 kthread+0x41a/0x930 kernel/kthread.c:463 ret_from_fork+0x6f8/0x8c0 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246The buggy address belongs to the object at ffff88800592a000 which belongs to the cache kmalloc-2k of size 2048The buggy address is located 244 bytes to the right of allocated 1152-byte region [ffff88800592a000, ffff88800592a480)The buggy address belongs to the physical page:page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x5928head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0anon flags: 0xfffffc0000040(head|node=0|zone=1|lastcpupid=0x1fffff)page_type: f5(slab)raw: 000fffffc0000040 ffff888001042000 0000000000000000 dead000000000001raw: 0000000000000000 0000000000080008 00000000f5000000 0000000000000000head: 000fffffc0000040 ffff888001042000 00000---truncated--- CVE-2026-46333: In the Linux kernel, the following vulnerability has been resolved:ptrace: slightly saner 'get_dumpable()' logicThe 'dumpability' of a task is fundamentally about the memory image ofthe task - the concept comes from whether it can core dump or not - andmakes no sense when you don't have an associated mm.And almost all users do in fact use it only for the case where the taskhas a mm pointer.But we have one odd special case: ptrace_may_access() uses 'dumpable' tocheck various other things entirely independently of the MM (typicallyexplicitly using flags like PTRACE_MODE_READ_FSCREDS). Including forthreads that no longer have a VM (and maybe never did, like most kernelthreads).It's not what this flag was designed for, but it is what it is.The ptrace code does check that the uid/gid matches, so you do have tobe uid-0 to see kernel thread details, but this means that thetraditional "drop capabilities" model doesn't make any difference forthis all.Make it all make a *bit* more sense by saying that if you don't have aMM pointer, we'll use a cached "last dumpability" flag if the threadever had a MM (it will be zero for kernel threads since it is neverset), and require a proper CAP_SYS_PTRACE capability to override.
标签
- cve:cve-2023-52590
- cve:cve-2024-39478
- cve:cve-2024-41082
- cve:cve-2024-58094
- cve:cve-2024-58095
- cve:cve-2025-21722
- cve:cve-2025-21927
- cve:cve-2025-22070
- cve:cve-2025-22104
- cve:cve-2025-22113
- cve:cve-2025-22127
- cve:cve-2025-23131
- cve:cve-2025-23132
- cve:cve-2025-37833
- cve:cve-2025-38203
- cve:cve-2025-38204
- cve:cve-2025-38206
- cve:cve-2025-38237
- cve:cve-2025-38248
- cve:cve-2025-38264
- cve:cve-2025-38502
- cve:cve-2025-38678
- cve:cve-2025-39682
- cve:cve-2025-39702
- cve:cve-2025-39711
- cve:cve-2025-39746
- cve:cve-2025-39790
- cve:cve-2025-39833
- cve:cve-2025-39866
- cve:cve-2025-39946
- cve:cve-2025-39964
- cve:cve-2025-40018
- cve:cve-2025-40019
- cve:cve-2025-40020
- cve:cve-2025-40106
- cve:cve-2025-40214
- cve:cve-2025-40215
- cve:cve-2025-40297
- cve:cve-2025-40307
- cve:cve-2025-40325
- cve:cve-2025-40355
- cve:cve-2025-68745
- cve:cve-2026-23112
- cve:cve-2026-23361
- cve:cve-2026-31402
- cve:cve-2026-31449
- cve:cve-2026-31450
- cve:cve-2026-31523
- cve:cve-2026-31530
- cve:cve-2026-31693
- cve:cve-2026-31705
- cve:cve-2026-31708
- cve:cve-2026-31711
- cve:cve-2026-31714
- cve:cve-2026-31716
- cve:cve-2026-43046
- cve:cve-2026-43053
- cve:cve-2026-43066
- cve:cve-2026-43068
- cve:cve-2026-43074
- cve:cve-2026-43125
- cve:cve-2026-43153
- cve:cve-2026-43168
- cve:cve-2026-43200
- cve:cve-2026-43211
- cve:cve-2026-43262
- cve:cve-2026-43288
- cve:cve-2026-43299
- cve:cve-2026-43338
- cve:cve-2026-43350
- cve:cve-2026-43359
- cve:cve-2026-43360
- cve:cve-2026-43361
- cve:cve-2026-43362
- cve:cve-2026-43366
- cve:cve-2026-43376
- cve:cve-2026-43377
- cve:cve-2026-43379
- cve:cve-2026-43414
- cve:cve-2026-43419
- cve:cve-2026-43420
- cve:cve-2026-43448
- cve:cve-2026-43449
- cve:cve-2026-46333
- severity:important
- type:advisory
- vendor:alibaba
扩展字段
{
"advisory_id": "ALINUX4-SA-2026:0333",
"affected_products": [
"Alinux 4"
],
"cve_ids": [
"CVE-2023-52590",
"CVE-2024-39478",
"CVE-2024-41082",
"CVE-2024-58094",
"CVE-2024-58095",
"CVE-2025-21722",
"CVE-2025-21927",
"CVE-2025-22070",
"CVE-2025-22104",
"CVE-2025-22113",
"CVE-2025-22127",
"CVE-2025-23131",
"CVE-2025-23132",
"CVE-2025-37833",
"CVE-2025-38203",
"CVE-2025-38204",
"CVE-2025-38206",
"CVE-2025-38237",
"CVE-2025-38248",
"CVE-2025-38264",
"CVE-2025-38502",
"CVE-2025-38678",
"CVE-2025-39682",
"CVE-2025-39702",
"CVE-2025-39711",
"CVE-2025-39746",
"CVE-2025-39790",
"CVE-2025-39833",
"CVE-2025-39866",
"CVE-2025-39946",
"CVE-2025-39964",
"CVE-2025-40018",
"CVE-2025-40019",
"CVE-2025-40020",
"CVE-2025-40106",
"CVE-2025-40214",
"CVE-2025-40215",
"CVE-2025-40297",
"CVE-2025-40307",
"CVE-2025-40325",
"CVE-2025-40355",
"CVE-2025-68745",
"CVE-2026-23112",
"CVE-2026-23361",
"CVE-2026-31402",
"CVE-2026-31449",
"CVE-2026-31450",
"CVE-2026-31523",
"CVE-2026-31530",
"CVE-2026-31693",
"CVE-2026-31705",
"CVE-2026-31708",
"CVE-2026-31711",
"CVE-2026-31714",
"CVE-2026-31716",
"CVE-2026-43046",
"CVE-2026-43053",
"CVE-2026-43066",
"CVE-2026-43068",
"CVE-2026-43074",
"CVE-2026-43125",
"CVE-2026-43153",
"CVE-2026-43168",
"CVE-2026-43200",
"CVE-2026-43211",
"CVE-2026-43262",
"CVE-2026-43288",
"CVE-2026-43299",
"CVE-2026-43338",
"CVE-2026-43350",
"CVE-2026-43359",
"CVE-2026-43360",
"CVE-2026-43361",
"CVE-2026-43362",
"CVE-2026-43366",
"CVE-2026-43376",
"CVE-2026-43377",
"CVE-2026-43379",
"CVE-2026-43414",
"CVE-2026-43419",
"CVE-2026-43420",
"CVE-2026-43448",
"CVE-2026-43449",
"CVE-2026-46333"
],
"raw_pub_date": "Fri, 24 Jul 2026 17:48:00 +0800",
"solution": "请您尽快将升级到修复后的版本。修复命令如下：\nyum update --advisory ALINUX4-SA-2026:0333"
}