The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

bcache: fix NULL pointer in cachesetflush()

1. LINE#1794 - LINE#1887 is some codes about function of bchcacheset_alloc().
2. LINE#2078 - LINE#2142 is some codes about function of registercacheset().

3. registercacheset() will call bchcacheset_alloc() in LINE#2098.

   1794 struct cacheset *bchcachesetalloc(struct cachesb *sb) 1795 { ... 1860 if (!(c->devices = kcalloc(c->nruuids, sizeof(void *), GFPKERNEL)) || 1861 mempoolinitslabpool(&c->search, 32, bchsearchcache) || 1862 mempoolinitkmallocpool(&c->biometa, 2, 1863 sizeof(struct bbio) + sizeof(struct biovec) * 1864 bucketpages(c)) || 1865 mempoolinitkmallocpool(&c->filliter, 1, itersize) || 1866 biosetinit(&c->biosplit, 4, offsetof(struct bbio, bio), 1867 BIOSETNEEDBVECS|BIOSETNEEDRESCUER) || 1868 !(c->uuids = allocbucketpages(GFPKERNEL, c)) || 1869 !(c->movinggcwq = allocworkqueue("bcachegc", 1870 WQMEMRECLAIM, 0)) || 1871 bchjournalalloc(c) || 1872 bchbtreecachealloc(c) || 1873 bchopenbucketsalloc(c) || 1874 bchbsetsortstateinit(&c->sort, ilog2(c->btreepages))) 1875 goto err; ^^^^^^^^ 1876 ... 1883 return c; 1884 err: 1885 bchcachesetunregister(c); ^^^^^^^^^^^^^^^^^^^^^^^^^^^ 1886 return NULL; 1887 } ... 2078 static const char *registercacheset(struct cache *ca) 2079 { ... 2098 c = bchcachesetalloc(&ca->sb); 2099 if (!c) 2100 return err; ^^^^^^^^^^ ... 2128 ca->set = c; 2129 ca->set->cache[ca->sb.nrthisdev] = ca; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ... 2138 return NULL; 2139 err: 2140 bchcachesetunregister(c); 2141 return err; 2142 }

(1) If LINE#1860 - LINE#1874 is true, then do 'goto err'(LINE#1875) and call bchcacheset_unregister()(LINE#1885). (2) As (1) return NULL(LINE#1886), LINE#2098 - LINE#2100 would return. (3) As (2) has returned, LINE#2128 - LINE#2129 would do not give the value to c->cache[], it means that c->cache[] is NULL.

LINE#1624 - LINE#1665 is some codes about function of cachesetflush(). As (1), in LINE#1885 call bchcachesetunregister() ---> bchcachesetstop() ---> closurequeue() -.-> cacheset_flush() (as below LINE#1624)

1624 static void cachesetflush(struct closure *cl) 1625 { ... 1654 foreachcache(ca, c, i) 1655 if (ca->allocthread) ^^ 1656 kthreadstop(ca->alloc_thread); ... 1665 }

(4) In LINE#1655 ca is NULL(see (3)) in cachesetflush() then the kernel crash occurred as below: [ 846.712887] bcache: registercache() error drbd6: cannot allocate memory [ 846.713242] bcache: registerbcache() error : failed to register device [ 846.713336] bcache: cachesetfree() Cache set 2f84bdc1-498a-4f2f-98a7-01946bf54287 unregistered [ 846.713768] BUG: unable to handle kernel NULL pointer dereference at 00000000000009f8 [ 846.714790] PGD 0 P4D 0 [ 846.715129] Oops: 0000 [#1] SMP PTI [ 846.715472] CPU: 19 PID: 5057 Comm: kworker/19:16 Kdump: loaded Tainted: G OE --------- - - 4.18.0-147.5.1.el81.5es.3.x8664 #1 [ 846.716082] Hardware name: ESPAN GI-25212/X11DPL-i, BIOS 2.1 06/15/2018 [ 846.716451] Workqueue: events cachesetflush [bcache] [ 846.716808] RIP: 0010:cachesetflush+0xc9/0x1b0 [bcache] [ 846.717155] Code: 00 4c 89 a5 b0 03 00 00 48 8b 85 68 f6 ff ff a8 08 0f 84 88 00 00 00 31 db 66 83 bd 3c f7 ff ff 00 48 8b 85 48 ff ff ff 74 28 <48> 8b b8 f8 09 00 0 ---truncated---(CVE-2025-38263)

In the Linux kernel, the following vulnerability has been resolved:

vsock/vmci: Clear the vmci transport packet properly when initializing it

In vmcitransportpacketinit memset the vmcitransport_packet before populating the fields to avoid any uninitialised data being left in the structure.(CVE-2025-38403)

In the Linux kernel, the following vulnerability has been resolved:

atm: clip: Fix infinite recursive call of clip_push().

syzbot reported the splat below. [0]

This happens if we call ioctl(ATMARP_MKIP) more than once.

During the first call, clipmkip() sets clippush() to vcc->push(), and the second call copies it to clipvcc->oldpush().

Later, when the socket is close()d, vccdestroysocket() passes NULL skb to clippush(), which calls clipvcc->old_push(), triggering the infinite recursion.

Let's prevent the second ioctl(ATMARPMKIP) by checking vcc->userback, which is allocated by the first call as clip_vcc.

Note also that we use lock_sock() to prevent racy calls.

Oops: stack guard page: 0000 [#1] SMP KASAN NOPTI CPU: 0 UID: 0 PID: 5322 Comm: syz.0.0 Not tainted 6.16.0-rc4-syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:clippush+0x5/0x720 net/atm/clip.c:191 Code: e0 8f aa 8c e8 1c ad 5b fa eb ae 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 55 <41> 57 41 56 41 55 41 54 53 48 83 ec 20 48 89 f3 49 89 fd 48 bd 00 RSP: 0018:ffffc9000d670000 EFLAGS: 00010246 RAX: 1ffff1100235a4a5 RBX: ffff888011ad2508 RCX: ffff8880003c0000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888037f01000 RBP: dffffc0000000000 R08: ffffffff8fa104f7 R09: 1ffffffff1f4209e R10: dffffc0000000000 R11: ffffffff8a99b300 R12: ffffffff8a99b300 R13: ffff888037f01000 R14: ffff888011ad2500 R15: ffff888037f01578 FS: 000055557ab6d500(0000) GS:ffff88808d250000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc9000d66fff8 CR3: 0000000043172000 CR4: 0000000000352ef0 Call Trace: <TASK> clippush+0x6dc/0x720 net/atm/clip.c:200 clippush+0x6dc/0x720 net/atm/clip.c:200 clippush+0x6dc/0x720 net/atm/clip.c:200 ... clippush+0x6dc/0x720 net/atm/clip.c:200 clippush+0x6dc/0x720 net/atm/clip.c:200 clippush+0x6dc/0x720 net/atm/clip.c:200 vccdestroysocket net/atm/common.c:183 [inline] vccrelease+0x157/0x460 net/atm/common.c:205 __sockrelease net/socket.c:647 [inline] sockclose+0xc0/0x240 net/socket.c:1391 __fput+0x449/0xa70 fs/filetable.c:465 taskworkrun+0x1d1/0x260 kernel/taskwork.c:227 resumeusermodework include/linux/resumeusermode.h:50 [inline] exittousermodeloop+0xec/0x110 kernel/entry/common.c:114 exittousermodeprepare include/linux/entry-common.h:330 [inline] syscallexittousermodework include/linux/entry-common.h:414 [inline] syscallexittousermode include/linux/entry-common.h:449 [inline] dosyscall64+0x2bd/0x3b0 arch/x86/entry/syscall64.c:100 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7ff31c98e929 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fffb5aa1f78 EFLAGS: 00000246 ORIGRAX: 00000000000001b4 RAX: 0000000000000000 RBX: 0000000000012747 RCX: 00007ff31c98e929 RDX: 0000000000000000 RSI: 000000000000001e RDI: 0000000000000003 RBP: 00007ff31cbb7ba0 R08: 0000000000000001 R09: 0000000db5aa226f R10: 00007ff31c7ff030 R11: 0000000000000246 R12: 00007ff31cbb608c R13: 00007ff31cbb6080 R14: ffffffffffffffff R15: 00007fffb5aa2090 </TASK> Modules linked in:(CVE-2025-38459)

In the Linux kernel, the following vulnerability has been resolved:

iwlwifi: Add missing check for allocorderedworkqueue

Add check for the return value of allocorderedworkqueue since it may return NULL pointer.(CVE-2025-38602)

In the Linux kernel, the following vulnerability has been resolved:

wifi: mac80211: reject TDLS operations when station is not associated

syzbot triggered a WARN in ieee80211tdlsoper() by sending NL80211TDLSENABLELINK immediately after NL80211CMD_CONNECT, before association completed and without prior TDLS setup.

This left internal state like sdata->u.mgd.tdlspeer uninitialized, leading to a WARNON() in code paths that assumed it was valid.

Reject the operation early if not in station mode or not associated.(CVE-2025-38644)

In the Linux kernel, the following vulnerability has been resolved:

btrfs: do not allow relocation of partially dropped subvolumes

[BUG] There is an internal report that balance triggered transaction abort, with the following call trace:

item 85 key (594509824 169 0) itemoff 12599 itemsize 33 extent refs 1 gen 197740 flags 2 ref#0: tree block backref root 7 item 86 key (594558976 169 0) itemoff 12566 itemsize 33 extent refs 1 gen 197522 flags 2 ref#0: tree block backref root 7 ... BTRFS error (device loop0): extent item not found for insert, bytenr 594526208 numbytes 16384 parent 449921024 rootobjectid 934 owner 1 offset 0 BTRFS error (device loop0): failed to run delayed ref for logical 594526208 numbytes 16384 type 182 action 1 refmod 1: -117 ------------[ cut here ]------------ BTRFS: Transaction aborted (error -117) WARNING: CPU: 1 PID: 6963 at ../fs/btrfs/extent-tree.c:2168 btrfsrundelayed_refs+0xfa/0x110 [btrfs]

And btrfs check doesn't report anything wrong related to the extent tree.

[CAUSE] The cause is a little complex, firstly the extent tree indeed doesn't have the backref for 594526208.

The extent tree only have the following two backrefs around that bytenr on-disk:

    item 65 key (594509824 METADATA_ITEM 0) itemoff 13880 itemsize 33
            refs 1 gen 197740 flags TREE_BLOCK
            tree block skinny level 0
            (176 0x7) tree block backref root CSUM_TREE
    item 66 key (594558976 METADATA_ITEM 0) itemoff 13847 itemsize 33
            refs 1 gen 197522 flags TREE_BLOCK
            tree block skinny level 0
            (176 0x7) tree block backref root CSUM_TREE

But the such missing backref item is not an corruption on disk, as the offending delayed ref belongs to subvolume 934, and that subvolume is being dropped:

    item 0 key (934 ROOT_ITEM 198229) itemoff 15844 itemsize 439
            generation 198229 root_dirid 256 bytenr 10741039104 byte_limit 0 bytes_used 345571328
            last_snapshot 198229 flags 0x1000000000001(RDONLY) refs 0
            drop_progress key (206324 EXTENT_DATA 2711650304) drop_level 2
            level 2 generation_v2 198229

And that offending tree block 594526208 is inside the dropped range of that subvolume. That explains why there is no backref item for that bytenr and why btrfs check is not reporting anything wrong.

But this also shows another problem, as btrfs will do all the orphan subvolume cleanup at a read-write mount.

So half-dropped subvolume should not exist after an RW mount, and balance itself is also exclusive to subvolume cleanup, meaning we shouldn't hit a subvolume half-dropped during relocation.

The root cause is, there is no orphan item for this subvolume. In fact there are 5 subvolumes from around 2021 that have the same problem.

It looks like the original report has some older kernels running, and caused those zombie subvolumes.

Thankfully upstream commit 8d488a8c7ba2 ("btrfs: fix subvolume/snapshot deletion not triggered on mount") has long fixed the bug.

[ENHANCEMENT] For repairing such old fs, btrfs-progs will be enhanced.

Considering how delayed the problem will show up (at run delayed ref time) and at that time we have to abort transaction already, it is too late.

Instead here we reject any half-dropped subvolume for reloc tree at the earliest time, preventing confusion and extra time wasted on debugging similar bugs.(CVE-2025-39738)

In the Linux kernel, the following vulnerability has been resolved:

can: peak_usb: fix shift-out-of-bounds issue

Explicitly uses a 64-bit constant when the number of bits used for its shifting is 32 (which is the case for PC CAN FD interfaces supported by this driver).

mkl: update subject, apply manually

In the Linux kernel, the following vulnerability has been resolved:

team: Move team device type change at the end of teamportadd

Attempting to add a port device that is already up will expectedly fail, but not before modifying the team device header_ops.

In the case of the syzbot reproducer the gre0 device is already in state UP when it attempts to add it as a port device of team0, this fails but before that headerops->create of team0 is changed from ethheader to ipgreheader in the call to teamdevtypecheck_change.

Later when we end up in ipgreheader() struct iptunnel* points to nonsense as the private data of the device still holds a struct team.

Example sequence of iproute2 commands to reproduce the hang/BUG(): ip link add dev team0 type team ip link add dev gre0 type gre ip link set dev gre0 up ip link set dev gre0 master team0 ip link set dev team0 up ping -I team0 1.1.1.1

Move teamdevtypecheckchange down where all other checks have passed as it changes the dev type with no way to restore it in case one of the checks that follow it fail.

Also make sure to preserve the origial mtu assignment: - If portdev is not the same type as dev, dev takes mtu from portdev - If portdev is the same type as dev, portdev takes mtu from dev

This is done by adding a conditional before the call to devsetmtu to prevent it from assigning portdev->mtu = dev->mtu and instead letting teamdevtypecheckchange assign dev->mtu = portdev->mtu. The conditional is needed because the patch moves the call to teamdevtypecheckchange past devsetmtu.

Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot(CVE-2025-68340)

In the Linux kernel, the following vulnerability has been resolved:

RDMA/umad: Reject negative datalen in ibumad_write

ibumadwrite computes datalen from user-controlled count and the MAD header sizes. With a mismatched user MAD header size and RMPP header length, datalen can become negative and reach ibcreatesendmad(). This can make the padding calculation exceed the segment size and trigger an out-of-bounds memset in allocsendrmpplist().

Add an explicit check to reject negative data_len before creating the send buffer.

KASAN splat: [ 211.363464] BUG: KASAN: slab-out-of-bounds in ibcreatesendmad+0xa01/0x11b0 [ 211.364077] Write of size 220 at addr ffff88800c3fa1f8 by task spraythread/102 [ 211.365867] ibcreatesendmad+0xa01/0x11b0 [ 211.365887] ibumad_write+0x853/0x1c80(CVE-2026-23243)

In the Linux kernel, the following vulnerability has been resolved:

macvlan: observe an RCU grace period in macvlancommonnewlink() error path

valis reported that a race condition still happens after my prior patch.

macvlancommonnewlink() might have made @dev visible before detecting an error, and its caller will directly call free_netdev(dev).

We must respect an RCU period, either in macvlan or the core networking stack.

After adding a temporary mdelay(1000) in macvlanforwardsource_one() to open the race window, valis repro was:

ip link add p1 type veth peer p2 ip link set address 00:00:00:00:00:20 dev p1 ip link set up dev p1 ip link set up dev p2 ip link add mv0 link p2 type macvlan mode source

(ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20 &) ; sleep 0.5 ; ping -c1 -I p1 1.2.3.4 PING 1.2.3.4 (1.2.3.4): 56 data bytes RTNETLINK answers: Invalid argument

BUG: KASAN: slab-use-after-free in macvlanforwardsource (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444) Read of size 8 at addr ffff888016bb89c0 by task e/175

CPU: 1 UID: 1000 PID: 175 Comm: e Not tainted 6.19.0-rc8+ #33 NONE Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 Call Trace: <IRQ> dumpstacklvl (lib/dumpstack.c:123) printreport (mm/kasan/report.c:379 mm/kasan/report.c:482) ? macvlanforwardsource (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444) kasanreport (mm/kasan/report.c:597) ? macvlanforwardsource (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444) macvlanforwardsource (drivers/net/macvlan.c:408 drivers/net/macvlan.c:444) ? taskletinit (kernel/softirq.c:983) macvlanhandleframe (drivers/net/macvlan.c:501)

Allocated by task 169: kasansavestack (mm/kasan/common.c:58) kasansavetrack (./arch/x86/include/asm/current.h:25 mm/kasan/common.c:70 mm/kasan/common.c:79) __kasan_kmalloc (mm/kasan/common.c:419) __kvmallocnodenoprof (./include/linux/kasan.h:263 mm/slub.c:5657 mm/slub.c:7140) allocnetdevmqs (net/core/dev.c:12012) rtnl_createlink (net/core/rtnetlink.c:3648) rtnlnewlink (net/core/rtnetlink.c:3830 net/core/rtnetlink.c:3957 net/core/rtnetlink.c:4072) rtnetlinkrcvmsg (net/core/rtnetlink.c:6958) netlinkrcvskb (net/netlink/afnetlink.c:2550) netlinkunicast (net/netlink/afnetlink.c:1319 net/netlink/afnetlink.c:1344) netlinksendmsg (net/netlink/afnetlink.c:1894) __sys_sendto (net/socket.c:727 net/socket.c:742 net/socket.c:2206) _x64syssendto (net/socket.c:2209) dosyscall64 (arch/x86/entry/syscall64.c:63 arch/x86/entry/syscall64.c:94) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:131)

Freed by task 169: kasansavestack (mm/kasan/common.c:58) kasansavetrack (./arch/x86/include/asm/current.h:25 mm/kasan/common.c:70 mm/kasan/common.c:79) kasansavefree_info (mm/kasan/generic.c:587) __kasanslabfree (mm/kasan/common.c:287) kfree (mm/slub.c:6674 mm/slub.c:6882) rtnlnewlink (net/core/rtnetlink.c:3845 net/core/rtnetlink.c:3957 net/core/rtnetlink.c:4072) rtnetlinkrcvmsg (net/core/rtnetlink.c:6958) netlinkrcvskb (net/netlink/afnetlink.c:2550) netlinkunicast (net/netlink/afnetlink.c:1319 net/netlink/afnetlink.c:1344) netlinksendmsg (net/netlink/af_netlink.c:1894) __sys_sendto (net/socket.c:727 net/socket.c:742 net/socket.c:2206) _x64syssendto (net/socket.c:2209) dosyscall64 (arch/x86/entry/syscall64.c:63 arch/x86/entry/syscall64.c:94) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:131)(CVE-2026-23273)

In the Linux kernel, the following vulnerability has been resolved:

mm: blk-cgroup: fix use-after-free in cgwbreleaseworkfn()

cgwbreleaseworkfn() calls cssput(wb->blkcgcss) and then later accesses wb->blkcgcss again via blkcgunpinonline(). If cssput() drops the last reference, the blkcg can be freed asynchronously (cssfreerworkfn -> blkcgcssfree -> kfree) before blkcgunpinonline() dereferences the pointer to access blkcg->onlinepin, resulting in a use-after-free:

BUG: KASAN: slab-use-after-free in blkcgunpinonline (./include/linux/instrumented.h:112 ./include/linux/atomic/atomic-instrumented.h:400 ./include/linux/refcount.h:389 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 block/blk-cgroup.c:1367) Write of size 4 at addr ff11000117aa6160 by task kworker/71:1/531 Workqueue: cgwbrelease cgwbreleaseworkfn Call Trace: <TASK> blkcgunpinonline (./include/linux/instrumented.h:112 ./include/linux/atomic/atomic-instrumented.h:400 ./include/linux/refcount.h:389 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 block/blk-cgroup.c:1367) cgwbreleaseworkfn (mm/backing-dev.c:629) processscheduled_works (kernel/workqueue.c:3278 kernel/workqueue.c:3385)

Freed by task 1016: kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6246 mm/slub.c:6561) cssfreerworkfn (kernel/cgroup/cgroup.c:5542) processscheduled_works (kernel/workqueue.c:3302 kernel/workqueue.c:3385)

** Stack based on commit 66672af7a095 ("Add linux-next specific files for 20260410")

I am seeing this crash sporadically in Meta fleet across multiple kernel versions. A full reproducer is available at: https://github.com/leitao/debug/blob/main/reproducers/reproblkcguaf.sh

(The race window is narrow. To make it easily reproducible, inject a msleep(100) between cssput() and blkcgunpinonline() in cgwbrelease_workfn(). With that delay and a KASAN-enabled kernel, the reproducer triggers the splat reliably in less than a second.)

Fix this by moving blkcgunpinonline() before cssput(), so the cgwb's CSS reference keeps the blkcg alive while blkcgunpin_online() accesses it.(CVE-2026-31586)

In the Linux kernel, the following vulnerability has been resolved:

KVM: x86: Use scratch field in MMIO fragment to hold small write values

When exiting to userspace to service an emulated MMIO write, copy the to-be-written value to a scratch field in the MMIO fragment if the size of the data payload is 8 bytes or less, i.e. can fit in a single chunk, instead of pointing the fragment directly at the source value.

This fixes a class of use-after-free bugs that occur when the emulator initiates a write using an on-stack, local variable as the source, the write splits a page boundary, and both pages are MMIO pages. Because KVM's ABI only allows for physically contiguous MMIO requests, accesses that split MMIO pages are separated into two fragments, and are sent to userspace one at a time. When KVM attempts to complete userspace MMIO in response to KVM_RUN after the first fragment, KVM will detect the second fragment and generate a second userspace exit, and reference the on-stack variable.

The issue is most visible if the second KVM_RUN is performed by a separate task, in which case the stack of the initiating task can show up as truly freed data.

================================================================== BUG: KASAN: use-after-free in completeemulatedmmio+0x305/0x420 Read of size 1 at addr ffff888009c378d1 by task syz-executor417/984

CPU: 1 PID: 984 Comm: syz-executor417 Not tainted 5.10.0-182.0.0.95.h2627.eulerosv2r13.x8664 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014 Call Trace: dumpstack+0xbe/0xfd printaddressdescription.constprop.0+0x19/0x170 __kasanreport.cold+0x6c/0x84 kasanreport+0x3a/0x50 checkmemoryregion+0xfd/0x1f0 memcpy+0x20/0x60 completeemulatedmmio+0x305/0x420 kvmarchvcpuioctlrun+0x63f/0x6d0 kvmvcpuioctl+0x413/0xb20 _sesysioctl+0x111/0x160 dosyscall64+0x30/0x40 entrySYSCALL64afterhwframe+0x67/0xd1 RIP: 0033:0x42477d Code: <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007faa8e6890e8 EFLAGS: 00000246 ORIGRAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00000000004d7338 RCX: 000000000042477d RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000005 RBP: 00000000004d7330 R08: 00007fff28d546df R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004d733c R13: 0000000000000000 R14: 000000000040a200 R15: 00007fff28d54720

The buggy address belongs to the page: page:0000000029f6a428 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x9c37 flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff) raw: 000fffffc0000000 0000000000000000 ffffea0000270dc8 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected

Memory state around the buggy address: ffff888009c37780: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888009c37800: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff >ffff888009c37880: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff888009c37900: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff888009c37980: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ==================================================================

The bug can also be reproduced with a targeted KVM-Unit-Test by hacking KVM to fill a large on-stack variable in completeemulatedmmio(), i.e. by overwrite the data value with garbage.

Limit the use of the scratch fields to 8-byte or smaller accesses, and to just writes, as larger accesses and reads are not affected thanks to implementation details in the emulator, but add a sanity check to ensure those details don't change in the future. Specifically, KVM never uses on-stack variables for accesses larger that 8 bytes, e.g. uses an operand in the emulator context, and *al ---truncated---(CVE-2026-31588)

In the Linux kernel, the following vulnerability has been resolved:

openvswitch: defer tunnel netdev_put to RCU release

ovsnetdevtunneldestroy() may run after NETDEVUNREGISTER already detached the device. Dropping the netdev reference in destroy can race with concurrent readers that still observe vport->dev.

Do not release vport->dev in ovsnetdevtunneldestroy(). Instead, let vportnetdev_free() drop the reference from the RCU callback, matching the non-tunnel destroy path and avoiding additional synchronization under RTNL.(CVE-2026-31678)

In the Linux kernel, the following vulnerability has been resolved:

usb: ulpi: fix double free in ulpiregisterinterface() error path

When deviceregister() fails, ulpiregister() calls put_device() on ulpi->dev.

The device release callback ulpidevrelease() drops the OF node reference and frees ulpi, but the current error path in ulpiregisterinterface() then calls kfree(ulpi) again, causing a double free.

Let putdevice() handle the cleanup through ulpidevrelease() and avoid freeing ulpi again in ulpiregister_interface().(CVE-2026-31759)

In the Linux kernel, the following vulnerability has been resolved:

drm/ioc32: stop speculation on the drmcompatioctl path

The drm compat ioctl path takes a user controlled pointer, and then dereferences it into a table of function pointers, the signature method of spectre problems. Fix this up by calling arrayindexnospec() on the index to the function pointer list.(CVE-2026-31781)

In the Linux kernel, the following vulnerability has been resolved:

ip6tunnel: clear skb2->cb[] in ip4ip6err()

Oskar Kjos reported the following problem.

ip4ip6err() calls icmpsend() on a cloned skb whose cb[] was written by the IPv6 receive path as struct inet6skbparm. icmp_send() passes IPCB(skb2) to __ipoptionsecho(), which interprets that cb[] region as struct inetskbparm (IPv4). The layouts differ: inet6skbparm.nhoff at offset 14 overlaps inetskbparm.opt.rr, producing a non-zero rr value. __ipoptionsecho() then reads optlen from attacker-controlled packet data at sptr[rr+1] and copies that many bytes into dopt->__data, a fixed 40-byte stack buffer (IPOPTIONSDATAFIXEDSIZE).

To fix this we clear skb2->cb[], as suggested by Oskar Kjos.

Also add minimal IPv4 header validation (version == 4, ihl >= 5).(CVE-2026-43037)

In the Linux kernel, the following vulnerability has been resolved:

ipv6: icmp: clear skb2->cb[] in ip6errgenicmpv6unreach()

Sashiko AI-review observed:

In ip6errgenicmpv6unreach(), the skb is an outer IPv4 ICMP error packet where its cb contains an IPv4 inetskbparm. When skb is cloned into skb2 and passed to icmp6_send(), it uses IP6CB(skb2).

IP6CB interprets the IPv4 inetskbparm as an inet6skbparm. The cipso offset in inetskbparm.opt directly overlaps with dsthao in inet6skbparm at offset 18.

If an attacker sends a forged ICMPv4 error with a CIPSO IP option, dsthao would be a non-zero offset. Inside icmp6send(), mip6addrswap() is called and uses ipv6findtlv(skb, opt->dsthao, IPV6TLV_HAO).

This would scan the inner, attacker-controlled IPv6 packet starting at that offset, potentially returning a fake TLV without checking if the remaining packet length can hold the full 18-byte struct ipv6destopthao.

Could mip6addrswap() then perform a 16-byte swap that extends past the end of the packet data into skbsharedinfo?

Should the cb array also be cleared in ip6errgenicmpv6unreach() and ip6ip6_err() to prevent this?

This patch implements the first suggestion.

I am not sure if ip6ip6_err() needs to be changed. A separate patch would be better anyway.(CVE-2026-43038)

In the Linux kernel, the following vulnerability has been resolved:

xfrm6: fix uninitialized saddr in xfrm6getsaddr()

xfrm6getsaddr() does not check the return value of ipv6devgetsaddr(). When ipv6devgetsaddr() fails to find a suitable source address (returns -EADDRNOTAVAIL), saddr->in6 is left uninitialized, but xfrm6getsaddr() still returns 0 (success).

This causes the caller xfrmtmplresolveone() to use the uninitialized address in xfrmstate_find(), triggering KMSAN warning:

===================================================== BUG: KMSAN: uninit-value in xfrmstatefind+0x2424/0xa940 xfrmstatefind+0x2424/0xa940 xfrmresolveandcreatebundle+0x906/0x5a20 xfrmlookupwithifid+0xcc0/0x3770 xfrmlookuproute+0x63/0x2b0 iprouteoutputflow+0x1ce/0x270 udpsendmsg+0x2ce1/0x3400 inetsendmsg+0x1ef/0x2a0 __sock_sendmsg+0x278/0x3d0 __sys_sendto+0x593/0x720 __x64syssendto+0x130/0x200 x64syscall+0x332b/0x3e70 dosyscall64+0xd3/0xf80 entrySYSCALL64afterhwframe+0x77/0x7f

Local variable tmp.i.i created at: xfrmresolveandcreatebundle+0x3e3/0x5a20

xfrmlookupwith_ifid+0xcc0/0x3770

Fix by checking the return value of ipv6devget_saddr() and propagating the error.(CVE-2026-43139)

In the Linux kernel, the following vulnerability has been resolved:

xfs: fix freemap adjustments when adding xattrs to leaf blocks

xfs/592 and xfs/794 both trip this assertion in the leaf block freemap adjustment code after ~20 minutes of running on my test VMs:

ASSERT(ichdr->firstused >= ichdr->count * sizeof(xfsattrleafentryt) + xfsattr3leafhdrsize(leaf));

Upon enabling quite a lot more debugging code, I narrowed this down to fsstress trying to set a local extended attribute with namelen=3 and valuelen=71. This results in an entry size of 80 bytes.

At the start of xfsattr3leafaddwork, the freemap looks like this:

i 0 base 448 size 0 rhs 448 count 46 i 1 base 388 size 132 rhs 448 count 46 i 2 base 2120 size 4 rhs 448 count 46 firstused = 520

where "rhs" is the first byte past the end of the leaf entry array. This is inconsistent -- the entries array ends at byte 448, but freemap[1] says there's free space starting at byte 388!

By the end of the function, the freemap is in worse shape:

i 0 base 456 size 0 rhs 456 count 47 i 1 base 388 size 52 rhs 456 count 47 i 2 base 2120 size 4 rhs 456 count 47 firstused = 440

Important note: 388 is not aligned with the entries array element size of 8 bytes.

Based on the incorrect freemap, the name area starts at byte 440, which is below the end of the entries array! That's why the assertion triggers and the filesystem shuts down.

How did we end up here? First, recall from the previous patch that the freemap array in an xattr leaf block is not intended to be a comprehensive map of all free space in the leaf block. In other words, it's perfectly legal to have a leaf block with:

• 376 bytes in use by the entries array
• freemap[0] has [base = 376, size = 8]
• freemap[1] has [base = 388, size = 1500]
• the space between 376 and 388 is free, but the freemap stopped tracking that some time ago

If we add one xattr, the entries array grows to 384 bytes, and freemap[0] becomes [base = 384, size = 0]. So far, so good. But if we add a second xattr, the entries array grows to 392 bytes, and freemap[0] gets pushed up to [base = 392, size = 0]. This is bad, because freemap[1] hasn't been updated, and now the entries array and the free space claim the same space.

The fix here is to adjust all freemap entries so that none of them collide with the entries array. Note that this fix relies on commit 2a2b5932db6758 ("xfs: fix attr leaf header freemap.size underflow") and the previous patch that resets zero length freemap entries to have base = 0.(CVE-2026-43158)

In the Linux kernel, the following vulnerability has been resolved:

net: usb: kaweth: remove TX queue manipulation in kawethsetrx_mode

kawethsetrxmode(), the ndosetrxmode callback, calls netifstopqueue() and netifwakequeue(). These are TX queue flow control functions unrelated to RX multicast configuration.

The premature netifwakequeue() can re-enable TX while txurb is still in-flight, leading to a double usbsubmit_urb() on the same URB:

kawethstartxmit() { netifstopqueue(); usbsubmiturb(kaweth->tx_urb); }

kawethsetrxmode() { netifstopqueue(); netifwake_queue(); // wakes TX queue before URB is done }

kawethstartxmit() { netifstopqueue(); usbsubmiturb(kaweth->tx_urb); // URB submitted while active }

This triggers the WARN in usbsubmiturb():

"URB submitted while active"

This is a similar class of bug fixed in rtl8150 by

• commit 958baf5eaee3 ("net: usb: Remove disruptive netifwakequeue in rtl8150setmulticast").

Also kawethsetrxmode() is already functionally broken, the real setrxmode action is performed by kawethasyncsetrxmode(), which in turn is not a no-op only at ndoopen() time.(CVE-2026-43180)

In the Linux kernel, the following vulnerability has been resolved:

netfilter: xt_tcpmss: check remaining length before reading optlen

Quoting reporter: In net/netfilter/xt_tcpmss.c (lines 53-68), the TCP option parser reads op[i+1] directly without validating the remaining option length.

If the last byte of the option field is not EOL/NOP (0/1), the code attempts to index op[i+1]. In the case where i + 1 == optlen, this causes an out-of-bounds read, accessing memory past the optlen boundary (either reading beyond the stack buffer _opt or the following payload).(CVE-2026-43190)

In the Linux kernel, the following vulnerability has been resolved:

netfilter: nfconntrackh323: fix OOB read in decode_choice()

In decodechoice(), the boundary check before getlen() uses the variable len, which is still 0 from its initialization at the top of the function:

unsigned int type, ext, len = 0;
...
if (ext || (son->attr & OPEN)) {
    BYTE_ALIGN(bs);
    if (nf_h323_error_boundary(bs, len, 0))  /* len is 0 here */
        return H323_ERROR_BOUND;
    len = get_len(bs);                        /* OOB read */

When the bitstream is exactly consumed (bs->cur == bs->end), the check nfh323errorboundary(bs, 0, 0) evaluates to (bs->cur + 0 > bs->end), which is false. The subsequent getlen() call then dereferences *bs->cur++, reading 1 byte past the end of the buffer. If that byte has bit 7 set, get_len() reads a second byte as well.

This can be triggered remotely by sending a crafted Q.931 SETUP message with a User-User Information Element containing exactly 2 bytes of PER-encoded data ({0x08, 0x00}) to port 1720 through a firewall with the nfconntrackh323 helper active. The decoder fully consumes the PER buffer before reaching this code path, resulting in a 1-2 byte heap-buffer-overflow read confirmed by AddressSanitizer.

Fix this by checking for 2 bytes (the maximum that getlen() may read) instead of the uninitialized len. This matches the pattern used at every other getlen() call site in the same file, where the caller checks for 2 bytes of available data before calling get_len().(CVE-2026-43233)

In the Linux kernel, the following vulnerability has been resolved:

mailbox: Prevent out-of-bounds access in fwmboxindex_xlate()

Although it is guided that #mbox-cells must be at least 1, there are many instances of #mbox-cells = <0>; in the device tree. If that is the case and the corresponding mailbox controller does not provide fw_xlate and ofxlatefunction pointers,fwmboxindexxlate()` will be used by default and out-of-bounds accesses could occur due to lack of bounds check in that function.(CVE-2026-43281)

In the Linux kernel, there is a double free vulnerability in the error handling path of cpufreqdbsgovernorinit() function. When kobjectinitandadd() fails, cpufreqdbsgovernorinit() calls kobjectput(&dbsdata->attrset.kobj). The kobject release callback cpufreqdbsdatarelease() calls gov->exit(dbsdata) and kfree(dbsdata), but the current error path then calls gov->exit(dbsdata) and kfree(dbsdata) again, causing a double free. Keep the direct kfree(dbsdata) for the gov->init() failure path, but after kobjectinitandadd() has been called, let kobjectput() handle the cleanup through cpufreqdbsdata_release().(CVE-2026-43328)

In the Linux kernel, the following vulnerability has been resolved:

lib/crypto: chacha: Zeroize permuted_state before it leaves scope

Since the ChaCha permutation is invertible, the local variable 'permuted_state' is sufficient to compute the original 'state', and thus the key, even after the permutation has been done.

While the kernel is quite inconsistent about zeroizing secrets on the stack (and some prominent userspace crypto libraries don't bother at all since it's not guaranteed to work anyway), the kernel does try to do it as a best practice, especially in cases involving the RNG.

Thus, explicitly zeroize 'permuted_state' before it goes out of scope.(CVE-2026-43336)

In the Linux kernel, the following vulnerability has been resolved:

usb: class: cdc-wdm: fix reordering issue in read code path

Quoting the bug report:

Due to compiler optimization or CPU out-of-order execution, the desc->length update can be reordered before the memmove. If this happens, wdmread() can see the new length and call copyto_user() on uninitialized memory. This also violates LKMM data race rules [1].

Fix it by using WRITE_ONCE and memory barriers.(CVE-2026-43427)

In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: Fix DMA FIFO desync on error CQE SQ recovery

In case of a TX error CQE, a recovery flow is triggered, mlx5eresettxqsqccpc() resets dmafifocc to 0 but not dmafifopc, desyncing the DMA FIFO producer and consumer.

After recovery, the producer pushes new DMA entries at the old dmafifopc, while the consumer reads from position 0. This causes us to unmap stale DMA addresses from before the recovery.

The DMA FIFO is a purely software construct with no HW counterpart. At the point of reset, all WQEs have been flushed so dmafifocc is already equal to dmafifopc. There is no need to reset either counter, similar to how skb_fifo pc/cc are untouched.

Remove the 'dmafifocc = 0' reset.

This fixes the following WARNING: WARNING: CPU: 0 PID: 0 at drivers/iommu/dma-iommu.c:1240 iommudmaunmappage+0x79/0x90 Modules linked in: mlx5vdpa vringh vdpa bonding mlx5ib mlx5vfiopci ipip mlx5fwctl tunnel4 mlx5core ibipoib geneve ip6gre ipgre gre nftables ip6tunnel rdmaucm ibuverbs ibumad vfiopci vfiopcicore actmirred actskbedit actvlan vhostnet vhost tap ip6tablemangle ip6tablenat ip6tablefilter ip6tables iptablemangle clsmatchall nfnetlinkcttimeout actgact clsflower schingress vhostiotlb iptableraw tunnel6 vfioiommutype1 vfio openvswitch nsh rpcsecgsskrb5 authrpcgss oidregistry xtconntrack xtMASQUERADE nfconntracknetlink nfnetlink iptablenat nfnat xtaddrtype brnetfilter overlay zram zsmalloc rpcrdma ibiser libiscsi scsitransportiscsi rdmacm iwcm ibcm ibcore fuse [last unloaded: nftables] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5forupstreammindebug202412302133 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:iommudmaunmappage+0x79/0x90 Code: 2b 4d 3b 21 72 26 4d 3b 61 08 73 20 49 89 d8 44 89 f9 5b 4c 89 f2 4c 89 e6 48 89 ef 5d 41 5c 41 5d 41 5e 41 5f e9 c7 ae 9e ff <0f> 0b 5b 5d 41 5c 41 5d 41 5e 41 5f c3 66 2e 0f 1f 84 00 00 00 00 Call Trace: <IRQ> ? __warn+0x7d/0x110 ? iommudmaunmap_page+0x79/0x90 ? reportbug+0x16d/0x180 ? handlebug+0x4f/0x90 ? excinvalidop+0x14/0x70 ? asmexcinvalidop+0x16/0x20 ? iommudmaunmappage+0x79/0x90 ? iommudmaunmappage+0x2e/0x90 dmaunmappageattrs+0x10d/0x1b0 mlx5etxwidmaunmap+0xbe/0x120 [mlx5core] mlx5epolltxcq+0x16d/0x690 [mlx5core] mlx5enapipoll+0x8b/0xac0 [mlx5core] _napipoll+0x24/0x190 netrxaction+0x32a/0x3b0 ? mlx5eqcompint+0x7e/0x270 [mlx5core] ? notifiercallchain+0x35/0xa0 handlesoftirqs+0xc9/0x270 irqexitrcu+0x71/0xd0 commoninterrupt+0x7f/0xa0 </IRQ> <TASK> asmcommoninterrupt+0x22/0x40(CVE-2026-43466)

In the Linux kernel's openvswitch module, the vport netlink reply helpers allocate a fixed-size skb with nlmsgnew(NLMSGDEFAULTSIZE, ...) but serialize the full upcall PID array via ovsvportgetupcallportids(). Since ovsvportsetupcallportids() accepts any non-zero multiple of sizeof(u32) with no upper bound, a CAPNETADMIN user can install a PID array large enough to overflow the reply buffer, causing nlaput() to fail with -EMSGSIZE and hitting BUG_ON(err < 0), leading to a kernel panic. On systems with unprivileged user namespaces enabled (e.g., Ubuntu default), this is reachable via unshare -Urn.(CVE-2026-45840)

In the Linux kernel, the following vulnerability has been resolved: drm/nouveau: fix u32 overflow in pushbuf reloc bounds check nouveaugempushbufrelocapply() validates each relocation with if (r->relocbooffset + 4 > nvbo->bo.base.size) but relocbooffset is __u32 (uapi/drm/nouveaudrm.h) and the integer literal 4 promotes to unsigned int, so the addition is performed in 32 bits and wraps before the comparison against the sizet bo size. Cast to u64 so the addition happens in 64-bit arithmetic. [ Add Fixes: tag. - Danilo ] The Linux kernel CVE team has assigned CVE-2026-46006 to this issue.(CVE-2026-46006)

In the Linux kernel, the following vulnerability has been resolved:

thermal: core: Fix thermal zone governor cleanup issues

If thermalzonedeviceregisterwith_trips() fails after adding a thermal governor to the thermal zone being registered, the governor is not removed from it as appropriate which may lead to a memory leak.

In turn, thermalzonedeviceunregister() calls thermalset_governor() without acquiring the thermal zone lock beforehand which may race with a governor update via sysfs and may lead to a use-after-free in that case.

Address these issues by adding two thermalsetgovernor() calls, one to thermal_release() to remove the governor from the given thermal zone, and one to the thermal zone registration error path to cover failures preceding the thermal zone device registration.(CVE-2026-46021)

In the Linux kernel, the following vulnerability has been resolved: dm mirror: fix integer overflow in createdirtylog() The argument count calculation in createdirtylog() performs *args_used = 2 + param_count before validating against argc. When a user provides a paramcount close to UINTMAX via the device mapper table string, this unsigned addition wraps around to a small value, causing the subsequent argc < *args_used check to be bypassed. The overflowed paramcount is then passed as argc to dmdirtylogcreate(), where it can cause out-of-bounds reads on the argv array. Fix by comparing paramcount against argc - 2 before performing the addition, following the same pattern used by parsefeatures() in the same file. Since argc >= 2 is already guaranteed, the subtraction is safe. The Linux kernel CVE team has assigned CVE-2026-46023 to this issue.(CVE-2026-46023)

In the Linux kernel, the following vulnerability has been resolved: crypto: authencesn - reject short ahash digests during instance creation authencesn requires either a zero authsize or an authsize of at least 4 bytes because the ESN encrypt/decrypt paths always move 4 bytes of high-order sequence number data at the end of the authenticated data. While cryptoauthencesnsetauthsize() already rejects explicit non-zero authsizes in the range 1..3, cryptoauthencesncreate() still copied auth->digestsize into inst->alg.maxauthsize without validating it. The AEAD core then initialized the tfm's default authsize from that value. As a result, selecting an ahash with digest size 1..3, such as cbcmac(ciphernull), exposed authencesn instances whose default authsize was invalid even though setauthsize() would have rejected the same value. AFALG could then trigger the ESN tail handling with a too-short tag and hit an out-of-bounds access. Reject authencesn instances whose ahash digest size is in the invalid non-zero range 1..3 so that no tfm can inherit an unsupported default authsize. The Linux kernel CVE team has assigned CVE-2026-46033 to this issue.(CVE-2026-46033)

In the Linux kernel, the following vulnerability has been resolved:

ceph: only d_add() negative dentries when they are unhashed

Ceph can call d_add(dentry, NULL) on a negative dentry that is already present in the primary dcache hash.

In the current VFS that is not safe. d_add() goes through __d_add() to __drehash(), which unconditionally reinserts dentry->dhash into the hlist_bl bucket. If the dentry is already hashed, reinserting the same node can corrupt the bucket, including creating a self-loop. Once that happens, _dlookup() can spin forever in the hlistbl walk, typically looping only on the dname.hash mismatch check and eventually triggering RCU stall reports like this one:

rcu: INFO: rcu_sched self-detected stall on CPU rcu: 87-....: (2100 ticks this GP) idle=3a4c/1/0x4000000000000000 softirq=25003319/25003319 fqs=829 rcu: (t=2101 jiffies g=79058445 q=698988 ncpus=192) CPU: 87 UID: 2952868916 PID: 3933303 Comm: php-cgi8.3 Not tainted 6.18.17-i1-amd #950 NONE Hardware name: Dell Inc. PowerEdge R7615/0G9DHV, BIOS 1.6.6 09/22/2023 RIP: 0010:__dlookup+0x46/0xb0 Code: c1 e8 07 48 8d 04 c2 48 8b 00 49 89 fc 49 89 f5 48 89 c3 48 83 e3 fe 48 83 f8 01 77 0f eb 2d 0f 1f 44 00 00 48 8b 1b 48 85 db <74> 20 39 6b 18 75 f3 48 8d 7b 78 e8 ba 85 d0 00 4c 39 63 10 74 1f RSP: 0018:ff745a70c8253898 EFLAGS: 00000282 RAX: ff26e470054cb208 RBX: ff26e470054cb208 RCX: 000000006e958966 RDX: ff26e48267340000 RSI: ff745a70c82539b0 RDI: ff26e458f74655c0 RBP: 000000006e958966 R08: 0000000000000180 R09: 9cd08d909b919a89 R10: ff26e458f74655c0 R11: 0000000000000000 R12: ff26e458f74655c0 R13: ff745a70c82539b0 R14: d0d0d0d0d0d0d0d0 R15: 2f2f2f2f2f2f2f2f FS: 00007f5770896980(0000) GS:ff26e482c5d88000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f5764de50c0 CR3: 000000a72abb5001 CR4: 0000000000771ef0 PKRU: 55555554 Call Trace: <TASK> lookupfast+0x9f/0x100 walkcomponent+0x1f/0x150 linkpathwalk+0x20e/0x3d0 pathlookupat+0x68/0x180 filenamelookup+0xdc/0x1e0 vfsstatx+0x6c/0x140 vfs_fstatat+0x67/0xa0 __dosysnewfstatat+0x24/0x60 dosyscall64+0x6a/0x230 entrySYSCALL64afterhwframe+0x76/0x7e

This is reachable with reused cached negative dentries. A Ceph lookup or atomic_open can be handed a negative dentry that is already hashed, and fs/ceph/dir.c then hits one of two paths that incorrectly assume "negative" also means "unhashed":

• cephfinishlookup(): MDS reply is -ENOENT with no trace -> d_add(dentry, NULL)

• cephlookup(): local ENOENT fast path for a complete directory with shared caps -> dadd(dentry, NULL)

Both paths can therefore re-add an already-hashed negative dentry.

Ceph already uses the correct pattern elsewhere: cephfilltrace() only calls dadd(dn, NULL) for a negative null-dentry reply when dunhashed(dn) is true.

Fix both fs/ceph/dir.c sites the same way: only call d_add() for a negative dentry when it is actually unhashed. If the negative dentry is already hashed, leave it in place and reuse it as-is.

This preserves the existing behavior for unhashed dentries while avoiding d_hash list corruption for reused hashed negatives.(CVE-2026-46052)

In the Linux kernel, the following vulnerability has been resolved: sctp: revalidate list cursor after sctpsendmsgtoasoc() in SCTPSENDALL. The SCTPSENDALL path in sctpsendmsg() iterates ep->asocs with listforeachentrysafe(), which caches the next entry in @tmp before the loop body runs. The body calls sctpsendmsgtoasoc(), which may drop the socket lock inside sctpwaitforsndbuf(). While the lock is dropped, another thread can SCTPSOCKOPTPEELOFF the association cached in @tmp, migrating it to a new endpoint via sctpsockmigrate() (listdelinit() + listaddtail() to newep->asocs), and optionally close the new socket which frees the association via kfreercu(). The cached @tmp can also be freed by a network ABORT for that association, processed in softirq while the lock is dropped. sctpwaitforsndbuf() revalidates @asoc (the current entry) on re-lock via the "sk != asoc->base.sk" and "asoc->base.dead" checks, but nothing revalidates @tmp. After a successful return, the iterator advances to the stale @tmp, yielding either a use-after-free (if the peeled socket was closed) or a list-walk onto the new endpoint's list head (type confusion of &newep->asocs as a struct sctpassociation *). Both are reachable from CapEff=0; the type-confusion path gives controlled indirect call via the outqueue.sched->initsid pointer. Fix by re-deriving @tmp from @asoc after sctpsendmsgtoasoc() returns. @asoc is known to still be on ep->asocs at that point: the only callers that listdel an association from ep->asocs are sctpassociationfree() (which sets asoc->base.dead) and sctpassocmigrate() (which changes asoc->base.sk), and sctpwaitforsndbuf() checks both under the lock before any successful return; a tripped check propagates as err < 0 and the loop bails before the re-derive. The SCTPABORT path in sctpsendmsgchecksflags() returns 0 and the loop hits 'continue' before sctpsendmsgtoasoc() is ever called, so the @tmp cached by listforeachentrysafe() still covers the lock-held free that ba59fb027307 ("sctp: walk the list of asocs safely") was added for.(CVE-2026-46227)