OESA-2026-2580

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

iomap: Fix possible overflow condition in iomapwritedelalloc_scan

folionextindex() returns an unsigned long value which left shifted by PAGESHIFT could possibly cause an overflow on 32-bit system. Instead use foliopos(folio) + folio_size(folio), which does this correctly.(CVE-2023-54285)

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:

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:

wifi: prevent A-MSDU attacks in mesh networks

This patch is a mitigation to prevent the A-MSDU spoofing vulnerability for mesh networks. The initial update to the IEEE 802.11 standard, in response to the FragAttacks, missed this case (CVE-2025-27558). It can be considered a variant of CVE-2020-24588 but for mesh networks.

This patch tries to detect if a standard MSDU was turned into an A-MSDU by an adversary. This is done by parsing a received A-MSDU as a standard MSDU, calculating the length of the Mesh Control header, and seeing if the 6 bytes after this header equal the start of an rfc1042 header. If equal, this is a strong indication of an ongoing attack attempt.

This defense was tested with mac80211_hwsim against a mesh network that uses an empty Mesh Address Extension field, i.e., when four addresses are used, and when using a 12-byte Mesh Address Extension field, i.e., when six addresses are used. Functionality of normal MSDUs and A-MSDUs was also tested, and confirmed working, when using both an empty and 12-byte Mesh Address Extension field.

It was also tested with mac80211_hwsim that A-MSDU attacks in non-mesh networks keep being detected and prevented.

Note that the vulnerability being patched, and the defense being implemented, was also discussed in the following paper and in the following IEEE 802.11 presentation:

https://papers.mathyvanhoef.com/wisec2025.pdf https://mentor.ieee.org/802.11/dcn/25/11-25-0949-00-000m-a-msdu-mesh-spoof-protection.docx(CVE-2025-38512)

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:

f2fs: fix to avoid out-of-boundary access in devs.path

• touch /mnt/f2fs/012345678901234567890123456789012345678901234567890123
• truncate -s $((102410241024)) \ /mnt/f2fs/012345678901234567890123456789012345678901234567890123
• touch /mnt/f2fs/file
• truncate -s $((102410241024)) /mnt/f2fs/file
• mkfs.f2fs /mnt/f2fs/012345678901234567890123456789012345678901234567890123 \ -c /mnt/f2fs/file
• mount /mnt/f2fs/012345678901234567890123456789012345678901234567890123 \ /mnt/f2fs/loop

[16937.192268] F2FS-fs (loop0): Failed to find devices

If device path length equals to MAXPATHLEN, sbi->devs.path[] may not end up w/ null character due to path array is fully filled, So accidently, fields locate after path[] may be treated as part of device path, result in parsing wrong device path.

struct f2fsdevinfo { ... char path[MAXPATHLEN]; ... };

Let's add one byte space for sbi->devs.path[] to store null character of device path string.(CVE-2025-38652)

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

net/smc: fix UAF on smcsk after smclistenout()

BPF CI testing report a UAF issue:

[ 16.446633] BUG: kernel NULL pointer dereference, address: 000000000000003 0 [ 16.447134] #PF: supervisor read access in kernel mod e [ 16.447516] #PF: errorcode(0x0000) - not-present pag e [ 16.447878] PGD 0 P4D 0 [ 16.448063] Oops: Oops: 0000 [#1] PREEMPT SMP NOPT I [ 16.448409] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Tainted: G OE 6.13.0-rc3-g89e8a75fda73-dirty #4 2 [ 16.449124] Tainted: [O]=OOTMODULE, [E]=UNSIGNEDMODUL E [ 16.449502] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/201 4 [ 16.450201] Workqueue: smchswq smclistenwor k [ 16.450531] RIP: 0010:smclisten_work+0xc02/0x159 0 [ 16.452158] RSP: 0018:ffffb5ab40053d98 EFLAGS: 0001024 6 [ 16.452526] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 000000000000030 0 [ 16.452994] RDX: 0000000000000280 RSI: 00003513840053f0 RDI: 000000000000000 0 [ 16.453492] RBP: ffffa097808e3800 R08: ffffa09782dba1e0 R09: 000000000000000 5 [ 16.453987] R10: 0000000000000000 R11: 0000000000000000 R12: ffffa0978274640 0 [ 16.454497] R13: 0000000000000000 R14: 0000000000000000 R15: ffffa09782d4092 0 [ 16.454996] FS: 0000000000000000(0000) GS:ffffa097bbc00000(0000) knlGS:000000000000000 0 [ 16.455557] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003 3 [ 16.455961] CR2: 0000000000000030 CR3: 0000000102788004 CR4: 0000000000770ef 0 [ 16.456459] PKRU: 5555555 4 [ 16.456654] Call Trace : [ 16.456832] <TASK > [ 16.456989] ? __die+0x23/0x7 0 [ 16.457215] ? pagefaultoops+0x180/0x4c 0 [ 16.457508] ? __lockacquire+0x3e6/0x249 0 [ 16.457801] ? excpagefault+0x68/0x20 0 [ 16.458080] ? asmexcpagefault+0x26/0x3 0 [ 16.458389] ? smclistenwork+0xc02/0x159 0 [ 16.458689] ? smclistenwork+0xc02/0x159 0 [ 16.458987] ? lockisheldtype+0x8f/0x10 0 [ 16.459284] processonework+0x1ea/0x6d 0 [ 16.459570] workerthread+0x1c3/0x38 0 [ 16.459839] ? __pfxworkerthread+0x10/0x1 0 [ 16.460144] kthread+0xe0/0x11 0 [ 16.460372] ? __pfxkthread+0x10/0x1 0 [ 16.460640] retfrom_fork+0x31/0x5 0 [ 16.460896] ? __pfxkthread+0x10/0x1 0 [ 16.461166] retfromforkasm+0x1a/0x3 0 [ 16.461453] </TASK > [ 16.461616] Modules linked in: bpftestmod(OE) [last unloaded: bpftestmod(OE) ] [ 16.462134] CR2: 000000000000003 0 [ 16.462380] ---[ end trace 0000000000000000 ]--- [ 16.462710] RIP: 0010:smclistenwork+0xc02/0x1590

The direct cause of this issue is that after smclistenout_connected(), newclcsock->sk may be NULL since it will releases the smcsk. Therefore, if the application closes the socket immediately after accept, newclcsock->sk can be NULL. A possible execution order could be as follows:

smclistenwork | userspace

locksock(sk) | smclistenoutconnected() | | - smclistenout | | | - releasesock | | |- sk->skdataready() | | fd = accept(); | close(fd); | - socket->sk = NULL; /* newclcsock->sk is NULL now */ SMCSTATSERVSUCCINC(socknet(newclcsock->sk))

Since smclistenout_connected() will not fail, simply swapping the order of the code can easily fix this issue.(CVE-2025-38734)

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:

scsi: ufs: exynos: Fix programming of HCIUTRLNEXUS_TYPE

On Google gs101, the number of UTP transfer request slots (nutrs) is 32, and in this case the driver ends up programming the UTRLNEXUSTYPE incorrectly as 0.

This is because the left hand side of the shift is 1, which is of type int, i.e. 31 bits wide. Shifting by more than that width results in undefined behaviour.

Fix this by switching to the BIT() macro, which applies correct type casting as required. This ensures the correct value is written to UTRLNEXUSTYPE (0xffffffff on gs101), and it also fixes a UBSAN shift warning:

UBSAN: shift-out-of-bounds in drivers/ufs/host/ufs-exynos.c:1113:21
shift exponent 32 is too large for 32-bit type 'int'

For consistency, apply the same change to the nutmrs / UTMRLNEXUSTYPE write.(CVE-2025-39788)

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

wifi: cfg80211: fix use-after-free in cmp_bss()

Following bssfree() quirk introduced in commit 776b3580178f ("cfg80211: track hidden SSID networks properly"), adjust cfg80211updateknownbss() to free the last beacon frame elements only if they're not shared via the corresponding 'hiddenbeaconbss' pointer.(CVE-2025-39864)

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

wifi: mac80211: increase scanieslen for S1G

Currently the S1G capability element is not taken into account for the scanieslen, which leads to a buffer length validation failure in ieee80211prephw_scan() and subsequent WARN in __ieee80211startscan(). This prevents hw scanning from functioning. To fix ensure we accommodate for the S1G capability length.(CVE-2025-39957)

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

smc: Use _skdstget() and dstdevrcu() in smcclcprfxmatch().

smcclcprfxmatch() is called from smclisten_work() and not under RCU nor RTNL.

Using skdstget(sk)->dev could trigger UAF.

Let's use __skdstget() and dstdevrcu().

Note that the returned value of smcclcprfx_match() is not used in the caller.(CVE-2025-40168)

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

drm/radeon: delete radeonfenceprocess in is_signaled, no deadlock

Delete the attempt to progress the queue when checking if fence is signaled. This avoids deadlock.

dma-fence_ops::signaled can be called with the fence lock in unknown state. For radeon, the fence lock is also the wait queue lock. This can cause a self deadlock when signaled() tries to make forward progress on the wait queue. But advancing the queue is unneeded because incorrectly returning false from signaled() is perfectly acceptable.

(cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)(CVE-2025-68223)

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)

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2025-68789)

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

ipvs: fix ipv4 null-ptr-deref in route error path

The IPv4 code path in _ipvsgetoutrt() calls dstlinkfailure() without ensuring skb->dev is set, leading to a NULL pointer dereference in fibcomputespecdst() when ipv4linkfailure() attempts to send ICMP destination unreachable messages.

The issue emerged after commit ed0de45a1008 ("ipv4: recompile ip options in ipv4linkfailure") started calling _ipoptionscompile() from ipv4linkfailure(). This code path eventually calls fibcomputespecdst() which dereferences skb->dev. An attempt was made to fix the NULL skb->dev dereference in commit 0113d9c9d1cc ("ipv4: fix null-deref in ipv4linkfailure"), but it only addressed the immediate devnet(skb->dev) dereference by using a fallback device. The fix was incomplete because fibcomputespecdst() later in the call chain still accesses skb->dev directly, which remains NULL when IPVS calls dstlinkfailure().

The crash occurs when: 1. IPVS processes a packet in NAT mode with a misconfigured destination 2. Route lookup fails in __ipvsget_outrt() before establishing a route 3. The error path calls dstlinkfailure(skb) with skb->dev == NULL 4. ipv4linkfailure() → ipv4senddestunreach() → __ipoptionscompile() → fibcomputespecdst() 5. fibcomputespecdst() dereferences NULL skb->dev

Apply the same fix used for IPv6 in commit 326bf17ea5d4 ("ipvs: fix ipv6 route unreach panic"): set skb->dev from skbdst(skb)->dev before calling dstlink_failure().

KASAN: null-ptr-deref in range [0x0000000000000328-0x000000000000032f] CPU: 1 PID: 12732 Comm: syz.1.3469 Not tainted 6.6.114 #2 RIP: 0010:__indevget_rcu include/linux/inetdevice.h:233 RIP: 0010:fibcomputespecdst+0x17a/0x9f0 net/ipv4/fibfrontend.c:285 Call Trace: <TASK> specdstfill net/ipv4/ipoptions.c:232 specdstfill net/ipv4/ipoptions.c:229 __ipoptionscompile+0x13a1/0x17d0 net/ipv4/ipoptions.c:330 ipv4senddestunreach net/ipv4/route.c:1252 ipv4linkfailure+0x702/0xb80 net/ipv4/route.c:1265 dstlinkfailure include/net/dst.h:437 _ipvsgetoutrt+0x15fd/0x19e0 net/netfilter/ipvs/ipvsxmit.c:412 ipvsnatxmit+0x1d8/0xc80 net/netfilter/ipvs/ipvsxmit.c:764(CVE-2025-68813)

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

ntfs: set dummy blocksize to read boot_block when mounting

When mounting, sb->sblocksize is used to read the bootblock without being defined or validated. Set a dummy blocksize before attempting to read the boot_block.

The issue can be triggered with the following syz reproducer:

mkdirat(0xffffffffffffff9c, &(0x7f0000000080)='./file1\x00', 0x0) r4 = openat$nullb(0xffffffffffffff9c, &(0x7f0000000040), 0x121403, 0x0) ioctl$FSIOCSETFLAGS(r4, 0x40081271, &(0x7f0000000980)=0x4000) mount(&(0x7f0000000140)=@nullb, &(0x7f0000000040)='./cgroup\x00', &(0x7f0000000000)='ntfs3\x00', 0x2208004, 0x0) syz_clone(0x88200200, 0x0, 0x0, 0x0, 0x0, 0x0)

Here, the ioctl sets the bdev block size to 16384. During mount, gettreebdevflags() calls sbsetblocksize(sb, blocksize(bdev)), but since blocksize(bdev) > PAGESIZE, sbsetblocksize() leaves sb->s_blocksize at zero.

Later, ntfsinitfromboot() attempts to read the bootblock while sb->s_blocksize is still zero, which triggers the bug.

[(CVE-2025-71067)

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

ipv6: BUG() in pskbexpandhead() as part of calipsoskbuffsetattr()

There exists a kernel oops caused by a BUGON(nhead < 0) at net/core/skbuff.c:2232 in pskbexpandhead(). This bug is triggered as part of the calipsoskbuffsetattr() routine when skbcow() is passed headroom > INTMAX (i.e. (int)(skbheadroom(skb) + len_delta) < 0).

The root cause of the bug is due to an implicit integer cast in _skbcow(). The check (headroom > skbheadroom(skb)) is meant to ensure that delta = headroom - skbheadroom(skb) is never negative, otherwise we will trigger a BUGON in pskbexpandhead(). However, if headroom > INTMAX and delta <= -NETSKBPAD, the check passes, delta becomes negative, and pskbexpandhead() is passed a negative value for nhead.

Fix the trigger condition in calipsoskbuffsetattr(). Avoid passing "negative" headroom sizes to skbcow() within calipsoskbuffsetattr() by only using skbcow() to grow headroom.

PoC: Using netlabelctl tool:

    netlabelctl map del default
    netlabelctl calipso add pass doi:7
    netlabelctl map add default address:0::1/128 protocol:calipso,7

    Then run the following PoC:

    int fd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_UDP);

    // setup msghdr
    int cmsg_size = 2;
    int cmsg_len = 0x60;
    struct msghdr msg;
    struct sockaddr_in6 dest_addr;
    struct cmsghdr * cmsg = (struct cmsghdr *) calloc(1,
                    sizeof(struct cmsghdr) + cmsg_len);
    msg.msg_name = &dest_addr;
    msg.msg_namelen = sizeof(dest_addr);
    msg.msg_iov = NULL;
    msg.msg_iovlen = 0;
    msg.msg_control = cmsg;
    msg.msg_controllen = cmsg_len;
    msg.msg_flags = 0;

    // setup sockaddr
    dest_addr.sin6_family = AF_INET6;
    dest_addr.sin6_port = htons(31337);
    dest_addr.sin6_flowinfo = htonl(31337);
    dest_addr.sin6_addr = in6addr_loopback;
    dest_addr.sin6_scope_id = 31337;

    // setup cmsghdr
    cmsg->cmsg_len = cmsg_len;
    cmsg->cmsg_level = IPPROTO_IPV6;
    cmsg->cmsg_type = IPV6_HOPOPTS;
    char * hop_hdr = (char *)cmsg + sizeof(struct cmsghdr);
    hop_hdr[1] = 0x9; //set hop size - (0x9 + 1) * 8 = 80

    sendmsg(fd, &msg, 0);(CVE-2025-71085)

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

macvlan: fix possible UAF in macvlanforwardsource()

Add RCU protection on (struct macvlansourceentry)->vlan.

Whenever macvlanhashdel_source() is called, we must clear entry->vlan pointer before RCU grace period starts.

This allows macvlanforwardsource() to skip over entries queued for freeing.

Note that macvlandev are already RCU protected, as they are embedded in a standard netdev (netdevpriv(ndev)).

https: //lore.kernel.org/netdev/(CVE-2026-23001)

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

net/sched: Enforce that teql can only be used as root qdisc

Design intent of teql is that it is only supposed to be used as root qdisc. We need to check for that constraint.

Although not important, I will describe the scenario that unearthed this issue for the curious.

GangMin Kim <(CVE-2026-23074)

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

arm64/fpsimd: signal: Allocate SSVE storage when restoring ZA

The code to restore a ZA context doesn't attempt to allocate the task's svestate before setting TIFSME. Consequently, restoring a ZA context can place a task into an invalid state where TIFSME is set but the task's svestate is NULL.

In legitimate but uncommon cases where the ZA signal context was NOT created by the kernel in the context of the same task (e.g. if the task is saved/restored with something like CRIU), we have no guarantee that svestate had been allocated previously. In these cases, userspace can enter streaming mode without trapping while svestate is NULL, causing a later NULL pointer dereference when the kernel attempts to store the register state:

| # ./sigreturn-za | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 | Mem abort info: | ESR = 0x0000000096000046 | EC = 0x25: DABT (current EL), IL = 32 bits | SET = 0, FnV = 0 | EA = 0, S1PTW = 0 | FSC = 0x06: level 2 translation fault | Data abort info: | ISV = 0, ISS = 0x00000046, ISS2 = 0x00000000 | CM = 0, WnR = 1, TnD = 0, TagAccess = 0 | GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 | user pgtable: 4k pages, 52-bit VAs, pgdp=0000000101f47c00 | [0000000000000000] pgd=08000001021d8403, p4d=0800000102274403, pud=0800000102275403, pmd=0000000000000000 | Internal error: Oops: 0000000096000046 [#1] SMP | Modules linked in: | CPU: 0 UID: 0 PID: 153 Comm: sigreturn-za Not tainted 6.19.0-rc1 #1 PREEMPT | Hardware name: linux,dummy-virt (DT) | pstate: 214000c9 (nzCv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--) | pc : svesavestate+0x4/0xf0 | lr : fpsimdsaveuserstate+0xb0/0x1c0 | sp : ffff80008070bcc0 | x29: ffff80008070bcc0 x28: fff00000c1ca4c40 x27: 63cfa172fb5cf658 | x26: fff00000c1ca5228 x25: 0000000000000000 x24: 0000000000000000 | x23: 0000000000000000 x22: fff00000c1ca4c40 x21: fff00000c1ca4c40 | x20: 0000000000000020 x19: fff00000ff6900f0 x18: 0000000000000000 | x17: fff05e8e0311f000 x16: 0000000000000000 x15: 028fca8f3bdaf21c | x14: 0000000000000212 x13: fff00000c0209f10 x12: 0000000000000020 | x11: 0000000000200b20 x10: 0000000000000000 x9 : fff00000ff69dcc0 | x8 : 00000000000003f2 x7 : 0000000000000001 x6 : fff00000c1ca5b48 | x5 : fff05e8e0311f000 x4 : 0000000008000000 x3 : 0000000000000000 | x2 : 0000000000000001 x1 : fff00000c1ca5970 x0 : 0000000000000440 | Call trace: | svesavestate+0x4/0xf0 (P) | fpsimdthread_switch+0x48/0x198 | __switch_to+0x20/0x1c0 | __schedule+0x36c/0xce0 | schedule+0x34/0x11c | exittousermodeloop+0x124/0x188 | el0_interrupt+0xc8/0xd8 | __el0irqhandlercommon+0x18/0x24 | el0t64irqhandler+0x10/0x1c | el0t64irq+0x198/0x19c | Code: 54000040 d51b4408 d65f03c0 d503245f (e5bb5800) | ---[ end trace 0000000000000000 ]---

Fix this by having restorezacontext() ensure that the task's sve_state is allocated, matching what we do when taking an SME trap. Any live SVE/SSVE state (which is restored earlier from a separate signal context) must be preserved, and hence this is not zeroed.(CVE-2026-23107)

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

netfilter: nf_tables: unconditionally bump set->nelems before insertion

In case that the set is full, a new element gets published then removed without waiting for the RCU grace period, while RCU reader can be walking over it already.

To address this issue, add the element transaction even if set is full, but toggle the set_full flag to report -ENFILE so the abort path safely unwinds the set to its previous state.

As for element updates, decrement set->nelems to restore it.

A simpler fix is to call synchronize_rcu() in the error path. However, with a large batch adding elements to already maxed-out set, this could cause noticeable slowdown of such batches.(CVE-2026-23272)

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

ALSA: usb-audio: Use correct version for UAC3 header validation

The entry of the validators table for UAC3 AC header descriptor is defined with the wrong protocol version UACVERSION2, while it should have been UACVERSION3. This results in the validator never matching for actual UAC3 devices (protocol == UACVERSION3), causing their header descriptors to bypass validation entirely. A malicious USB device presenting a truncated UAC3 header could exploit this to cause out-of-bounds reads when the driver later accesses unvalidated descriptor fields.

The bug was introduced in the same commit as the recently fixed UAC3 feature unit sub-type typo, and appears to be from the same copy-paste error when the UAC3 section was created from the UAC2 section.(CVE-2026-23318)

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

mm/hugememory: fix folio isn't locked in softleafto_folio()

On arm64 server, we found folio that get from migration entry isn't locked in softleaftofolio(). This issue triggers when mTHP splitting and zapnonpresentptes() races, and the root cause is lack of memory barrier in softleaftofolio(). The race is as follows:

CPU0                                             CPU1

deferredsplitscan() zapnonpresentptes() lock folio splitfolio() unmapfolio() change ptes to migration entries _splitfoliotoorder() softleaftofolio() set flags(including PGlocked) for tail pages folio = pfnfolio(softleaftopfn(entry)) smpwmb() VMWARNONONCE(!foliotestlocked(folio)) prepcompoundpage() for tail pages

In _splitfoliotoorder(), smpwmb() guarantees page flags of tail pages are visible before the tail page becomes non-compound. smpwmb() should be paired with smprmb() in softleaftofolio(), which is missed. As a result, if zapnonpresentptes() accesses migration entry that stores tail pfn, softleaftofolio() may see the updated compoundhead of tail page before page->flags.

This issue will trigger VMWARNONONCE() in pfnswapentryfolio() because of the race between folio split and zapnonpresentptes() leading to a folio incorrectly undergoing modification without a folio lock being held.

This is a BUG_ON() before commit 93976a20345b ("mm: eliminate further swapops predicates"), which in merged in v6.19-rc1.

To fix it, add missing smprmb() if the softleaf entry is migration entry in softleaftofolio() and softleafto_page().

[(CVE-2026-31466)

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:

ALSA: fireworks: bound device-supplied status before string array lookup

The status field in an EFW response is a 32-bit value supplied by the firewire device. efrstatusnames[] has 17 entries so a status value outside that range goes off into the weeds when looking at the %s value.

Even worse, the status could return EFRSTATUSINCOMPLETE which is 0x80000000, and is obviously not in that array of potential strings.

Fix this up by properly bounding the index against the array size and printing "unknown" if it's not recognized.(CVE-2026-31619)

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

tipc: fix bcackers underflow on duplicate GRPACK_MSG

The GRPACKMSG handler in tipcgroupprotorcv() currently decrements bcackers on every inbound group ACK, even when the same member has already acknowledged the current broadcast round.

Because bcackers is a u16, a duplicate ACK received after the last legitimate ACK wraps the counter to 65535. Once wrapped, tipcgroupbccong() keeps reporting congestion and later group broadcasts on the affected socket stay blocked until the group is recreated.

Fix this by ignoring duplicate or stale ACKs before touching bcacked or bcackers. This makes repeated GRPACKMSG handling idempotent and prevents the underflow path.(CVE-2026-31662)

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:

ksmbd: require minimum ACE size in smbcheckperm_dacl()

Both ACE-walk loops in smbcheckperm_dacl() only guard against an under-sized remaining buffer, not against an ACE whose declared ace->size is smaller than the struct it claims to describe:

if (offsetof(struct smbace, accessreq) > acessize) break; acesize = le16tocpu(ace->size); if (acesize > acessize) break;

The first check only requires the 4-byte ACE header to be in bounds; it does not require accessreq (4 bytes at offset 4) to be readable. An attacker who has set a crafted DACL on a file they own can declare ace->size == 4 with acessize == 4, pass both checks, and then

granted |= le32tocpu(ace->accessreq); /* upper loop */ comparesids(&sid, &ace->sid); /* lower loop */

reads accessreq at offset 4 (OOB by up to 4 bytes) and ace->sid at offset 8 (OOB by up to CIFSSIDBASESIZE + SIDMAXSUB_AUTHORITIES * 4 bytes).

Tighten both loops to require

acesize >= offsetof(struct smbace, sid) + CIFSSIDBASE_SIZE

which is the smallest valid on-wire ACE layout (4-byte header + 4-byte accessreq + 8-byte sid base with zero sub-auths). Also reject ACEs whose sid.numsubauth exceeds SIDMAXSUBAUTHORITIES before letting comparesids() dereference sub_auth[] entries.

parsesecdesc() already enforces an equivalent check (lines 441-448); smbcheckperm_dacl() simply grew weaker validation over time.

Reachability: authenticated SMB client with permission to set an ACL on a file. On a subsequent CREATE against that file, the kernel walks the stored DACL via smbcheckperm_dacl() and triggers the OOB read. Not pre-auth, and the OOB read is not reflected to the attacker, but KASAN reports and kernel state corruption are possible.(CVE-2026-31712)

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:

ALSA: ctxfi: Check the error for index mapping

The ctxfi driver blindly assumed a proper value returned from daiodeviceindex(), but it's not always true. Add a proper error check to deal with the error from the function.(CVE-2026-31777)

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

ALSA: caiaq: fix stack out-of-bounds read in init_card

The loop creates a whitespace-stripped copy of the card shortname where len < sizeof(card->id) is used for the bounds check. Since sizeof(card->id) is 16 and the local id buffer is also 16 bytes, writing 16 non-space characters fills the entire buffer, overwriting the terminating nullbyte.

When this non-null-terminated string is later passed to sndcardsetid() -> copyvalididstring(), the function scans forward with while (*nid && ...) and reads past the end of the stack buffer, reading the contents of the stack.

A USB device with a product name containing many non-ASCII, non-space characters (e.g. multibyte UTF-8) will reliably trigger this as follows:

BUG: KASAN: stack-out-of-bounds in copyvalididstring sound/core/init.c:696 [inline] BUG: KASAN: stack-out-of-bounds in sndcardsetidnolock+0x698/0x74c sound/core/init.c:718

The off-by-one has been present since commit bafeee5b1f8d ("ALSA: sndusbcaiaq: give better shortname") from June 2009 (v2.6.31-rc1), which first introduced this whitespace-stripping loop. The original code never accounted for the null terminator when bounding the copy.

Fix this by changing the loop bound to sizeof(card->id) - 1, ensuring at least one byte remains as the null terminator.(CVE-2026-31778)

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:

crypto: authencesn - Do not place hiseq at end of dst for out-of-place decryption

When decrypting data that is not in-place (src != dst), there is no need to save the high-order sequence bits in dst as it could simply be re-copied from the source.

However, the data to be hashed need to be rearranged accordingly.

Thanks,(CVE-2026-43033)

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:

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:

net: consume xmit errors of GSO frames

udpgrofrglist.sh and udpgrobench.sh are the flakiest tests currently in NIPA. They fail in the same exact way, TCP GRO test stalls occasionally and the test gets killed after 10min.

These tests use veth to simulate GRO. They attach a trivial ("return XDP_PASS;") XDP program to the veth to force TSO off and NAPI on.

Digging into the failure mode we can see that the connection is completely stuck after a burst of drops. The sender's sndnxt is at sequence number N [1], but the receiver claims to have received (rcvnxt) up to N + 3 * MSS [2]. Last piece of the puzzle is that senders rtx queue is not empty (let's say the block in the rtx queue is at sequence number N - 4 * MSS [3]).

In this state, sender sends a retransmission from the rtx queue with a single segment, and sequence numbers N-4MSS:N-3MSS [3]. Receiver sees it and responds with an ACK all the way up to N + 3 * MSS [2]. But sender will reject this ack as TCPACKUNSENT_DATA because it has no recollection of ever sending data that far out [1]. And we are stuck.

The root cause is the mess of the xmit return codes. veth returns an error when it can't xmit a frame. We end up with a loss event like this:

| GSO super frame 1 | GSO super frame 2 | |-----------------------------------------------| | seg | seg | seg | seg | seg | seg | seg | seg | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |

 x    ok    ok    <ok>|  ok    ok    ok   <x>
                      \\
           snd_nxt

"x" means packet lost by veth, and "ok" means it went thru. Since veth has TSO disabled in this test it sees individual segments. Segment 1 is on the retransmit queue and will be resent.

So why did the sender not advance sndnxt even tho it clearly did send up to seg 8? tcpwrite_xmit() interprets the return code from the core to mean that data has not been sent at all. Since TCP deals with GSO super frames, not individual segment the crux of the problem is that loss of a single segment can be interpreted as loss of all. TCP only sees the last return code for the last segment of the GSO frame (in <> brackets in the diagram above).

Of course for the problem to occur we need a setup or a device without a Qdisc. Otherwise Qdisc layer disconnects the protocol layer from the device errors completely.

We have multiple ways to fix this.

1) make veth not return an error when it lost a packet. While this is what I think we did in the past, the issue keeps reappearing and it's annoying to debug. The game of whack a mole is not great.

2) fix the damn return codes We only talk about NETDEVTXOK and NETDEVTXBUSY in the documentation, so maybe we should make the return code from ndostartxmit() a boolean. I like that the most, but perhaps some ancient, not-really-networking protocol would suffer.

3) make TCP ignore the errors It is not entirely clear to me what benefit TCP gets from interpreting the result of ipqueuexmit()? Specifically once the connection is established and we're pushing data - packet loss is just packet loss?

4) this fix Ignore the rc in the Qdisc-less+GSO case, since it's unreliable. We already always return OK in the TCQFCAN_BYPASS case. In the Qdisc-less case let's be a bit more conservative and only mask the GSO errors. This path is taken by non-IP-"networks" like CAN, MCTP etc, so we could regress some ancient thing. This is the simplest, but also maybe the hackiest fix?

Similar fix has been proposed by Eric in the past but never committed because original reporter was working with an OOT driver and wasn't providing feedback (see Link).(CVE-2026-43194)

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, the following vulnerability has been resolved:

drm: Account property blob allocations to memcg

DRMIOCTLMODE_CREATEPROPBLOB allows userspace to allocate arbitrary-sized property blobs backed by kernel memory.

Currently, the blob data allocation is not accounted to the allocating process's memory cgroup, allowing unprivileged users to trigger unbounded kernel memory consumption and potentially cause system-wide OOM.

Mark the property blob data allocation with GFPKERNELACCOUNT so that the memory is properly charged to the caller's memcg. This ensures existing cgroup memory limits apply and prevents uncontrolled kernel memory growth without introducing additional policy or per-file limits.(CVE-2026-43287)

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:

Bluetooth: SMP: force responder MITM requirements before building the pairing response

smpcmdpairingreq() currently builds the pairing response from the initiator authreq before enforcing the local BTSECURITYHIGH requirement. If the initiator omits SMPAUTHMITM, the response can also omit it even though the local side still requires MITM.

tkrequest() then sees an auth value without SMPAUTHMITM and may select JUSTCFM, making method selection inconsistent with the pairing policy the responder already enforces.

When the local side requires HIGH security, first verify that MITM can be achieved from the IO capabilities and then force SMPAUTHMITM in the response in both rsp.auth_req and auth. This keeps the responder auth bits and later method selection aligned.(CVE-2026-43334)

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, the following vulnerability has been resolved:

scsi: storvsc: Fix scheduling while atomic on PREEMPT_RT

This resolves the follow splat and lock-up when running with PREEMPT_RT enabled on Hyper-V:

[ 415.140818] BUG: scheduling while atomic: stress-ng-iomix/1048/0x00000002 [ 415.140822] INFO: lockdep is turned off. [ 415.140823] Modules linked in: intelraplmsr intelraplcommon inteluncorefrequencycommon intelpmccore pmttelemetry pmtdiscovery pmtclass intelpmcssramtelemetry intelvsec ghashclmulniintel aesniintel rapl binfmtmisc nlsascii nlscp437 vfat fat sndpcm hypervdrm sndtimer drmclientlib drmshmemhelper snd sg soundcore drmkmshelper pcspkr hvballoon hvutils evdev joydev drm configfs efipstore nfnetlink vsockloopback vmwvsockvirtiotransportcommon hvsock vmwvsockvmcitransport vsock vmwvmci efivarfs autofs4 ext4 crc16 mbcache jbd2 srmod sdmod cdrom hvstorvsc serioraw hidgeneric scsitransportfc hidhyperv scsimod hid hvnetvsc hypervkeyboard scsicommon [ 415.140846] Preemption disabled at: [ 415.140847] [<ffffffffc0656171>] storvscqueuecommand+0x2e1/0xbe0 [hvstorvsc] [ 415.140854] CPU: 8 UID: 0 PID: 1048 Comm: stress-ng-iomix Not tainted 6.19.0-rc7 #30 PREEMPT_{RT,(full)} [ 415.140856] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/04/2024 [ 415.140857] Call Trace: [ 415.140861] <TASK> [ 415.140861] ? storvscqueuecommand+0x2e1/0xbe0 [hvstorvsc] [ 415.140863] dumpstacklvl+0x91/0xb0 [ 415.140870] __schedule_bug+0x9c/0xc0 [ 415.140875] __schedule+0xdf6/0x1300 [ 415.140877] ? rtlockslowlocklocked+0x56c/0x1980 [ 415.140879] ? rcuiswatching+0x12/0x60 [ 415.140883] schedule_rtlock+0x21/0x40 [ 415.140885] rtlockslowlocklocked+0x502/0x1980 [ 415.140891] rtspinlock+0x89/0x1e0 [ 415.140893] hvringbufferwrite+0x87/0x2a0 [ 415.140899] vmbussendpacketmpbdesc+0xb6/0xe0 [ 415.140900] ? rcuiswatching+0x12/0x60 [ 415.140902] storvscqueuecommand+0x669/0xbe0 [hvstorvsc] [ 415.140904] ? HARDIRQverbose+0x10/0x10 [ 415.140908] ? __rqqosissue+0x28/0x40 [ 415.140911] scsi_queuerq+0x760/0xd80 [scsimod] [ 415.140926] __blkmqissuedirectly+0x4a/0xc0 [ 415.140928] blkmqissuedirect+0x87/0x2b0 [ 415.140931] blkmqdispatchqueuerequests+0x120/0x440 [ 415.140933] blkmqflushpluglist+0x7a/0x1a0 [ 415.140935] __blkflushplug+0xf4/0x150 [ 415.140940] __submitbio+0x2b2/0x5c0 [ 415.140944] ? submitbionoacctnocheck+0x272/0x360 [ 415.140946] submit_bionoacctnocheck+0x272/0x360 [ 415.140951] ext4readbhlock+0x3e/0x60 [ext4] [ 415.140995] ext4blockwritebegin+0x396/0x650 [ext4] [ 415.141018] ? __pfxext4dagetblockprep+0x10/0x10 [ext4] [ 415.141038] ext4dawritebegin+0x1c4/0x350 [ext4] [ 415.141060] genericperformwrite+0x14e/0x2c0 [ 415.141065] ext4bufferedwriteiter+0x6b/0x120 [ext4] [ 415.141083] vfswrite+0x2ca/0x570 [ 415.141087] ksyswrite+0x76/0xf0 [ 415.141089] dosyscall64+0x99/0x1490 [ 415.141093] ? rcuiswatching+0x12/0x60 [ 415.141095] ? finishtaskswitch.isra.0+0xdf/0x3d0 [ 415.141097] ? rcuiswatching+0x12/0x60 [ 415.141098] ? lockrelease+0x1f0/0x2a0 [ 415.141100] ? rcuiswatching+0x12/0x60 [ 415.141101] ? finishtaskswitch.isra.0+0xe4/0x3d0 [ 415.141103] ? rcuiswatching+0x12/0x60 [ 415.141104] ? __schedule+0xb34/0x1300 [ 415.141106] ? hrtimertrytocancel+0x1d/0x170 [ 415.141109] ? donanosleep+0x8b/0x160 [ 415.141111] ? hrtimer_nanosleep+0x89/0x100 [ 415.141114] ? _pfxhrtimerwakeup+0x10/0x10 [ 415.141116] ? xfdvalidatestate+0x26/0x90 [ 415.141118] ? rcuiswatching+0x12/0x60 [ 415.141120] ? dosyscall64+0x1e0/0x1490 [ 415.141121] ? dosyscall64+0x1e0/0x1490 [ 415.141123] ? rcuiswatching+0x12/0x60 [ 415.141124] ? dosyscall64+0x1e0/0x1490 [ 415.141125] ? dosyscall64+0x1e0/0x1490 [ 415.141127] ? irqentryexit+0x140/0 ---truncated---(CVE-2026-43475)

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

net: skbuff: propagate shared-frag marker through frag-transfer helpers

Two frag-transfer helpers (__pskbcopyfclone() and skbshift()) fail to propagate the SKBFLSHAREDFRAG bit in skbshinfo()->flags when moving frags from source to destination. pskbcopyfclone() defers the rest of the shinfo metadata to skbcopyheader() after copying frag descriptors, but that helper only carries over gso{size,segs, type} and never touches skbshinfo()->flags; skbshift() moves frag descriptors directly and leaves flags untouched. As a result, the destination skb keeps a reference to the same externally-owned or page-cache-backed pages while reporting skbhassharedfrag() as false.

The mismatch is harmful in any in-place writer that uses skbhassharedfrag() to decide whether shared pages must be detoured through skbcowdata(). ESP input is one such writer (esp4.c, esp6.c), and a single nft 'dup to <local>' rule -- or any other nfdupipv4() / xtTEE caller -- is enough to land a pskbcopy()'d skb in espinput() with the marker stripped, letting an unprivileged user write into the page cache of a root-owned read-only file via authencesn-ESN stray writes.

Set SKBFLSHAREDFRAG on the destination whenever frag descriptors were actually moved from the source. skbcopy() and skbcopyexpand() share skbcopyheader() too but linearize all paged data into freshly allocated head storage and emerge with nrfrags == 0, so skbhasshared_frag() returns false on its own; they need no change.

The same omission exists in skbgroreceive() and skbgroreceivelist(). The former moves the incoming skb's frag descriptors into the accumulator's last sub-skb via two paths (a direct frag-move loop and the headfrag + memcpy path); the latter chains the incoming skb whole onto p's fraglist. Downstream skbsegment() reads only skbshinfo(p)->flags, and skbsegment_list() reuses each sub-skb's shinfo as the nskb -- both p and lp must carry the marker.

The same omission also exists in tcpclonepayload(), which builds an MTU probe skb by moving frag descriptors from skbs on skwritequeue into a freshly allocated nskb. The helper falls into the same family and warrants the same fix for consistency; no TCP TX-side in-place writer is currently known to reach a user page through this gap, but a future consumer depending on the marker would regress silently.

The same omission exists in skbsegment(): the per-iteration flag merge takes only headskb's flag, and the inner switch that rebinds fragskb to listskb on headskb-frags exhaustion does not fold the new fragskb's flag into nskb. Fold fragskb's flag at both sites so segments drawing frags from fraglist members carry the marker.(CVE-2026-43503)

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

RDMA/uverbs: Validate wqesize before using it in ibuverbspostsend

ibuverbspostsend() uses cmd.wqesize from userspace without any validation before passing it to kmalloc() and using the allocated buffer as struct ibuverbssend_wr.

If a user provides a small wqesize value (e.g., 1), kmalloc() will succeed, but subsequent accesses to userwr->opcode, userwr->numsge, and other fields will read beyond the allocated buffer, resulting in an out-of-bounds read from kernel heap memory. This could potentially leak sensitive kernel information to userspace.

Additionally, providing an excessively large wqe_size can trigger a WARNING in the memory allocation path, as reported by syzkaller.

This is inconsistent with ibuverbsunmarshallrecv() which properly validates that wqesize >= sizeof(struct ibuverbsrecv_wr) before proceeding.

Add the same validation for ibuverbspostsend() to ensure wqesize is at least sizeof(struct ibuverbssend_wr).(CVE-2026-45856)

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

cpuidle: Skip governor when only one idle state is available

On certain platforms (PowerNV systems without a power-mgt DT node), cpuidle may register only a single idle state. In cases where that single state is a polling state (state 0), the ladder governor may incorrectly treat state 1 as the first usable state and pass an out-of-bounds index. This can lead to a NULL enter callback being invoked, ultimately resulting in a system crash.

[ 13.342636] cpuidle-powernv : Only Snooze is available [ 13.351854] Faulting instruction address: 0x00000000 [ 13.376489] NIP [0000000000000000] 0x0 [ 13.378351] LR [c000000001e01974] cpuidleenterstate+0x2c4/0x668

Fix this by adding a bail-out in cpuidleselect() that returns state 0 directly when statecount <= 1, bypassing the governor and keeping the tick running.(CVE-2026-45968)

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

s390/cio: Fix device lifecycle handling in cssallocsubchannel()

css_alloc_subchannel() calls device_initialize() before setting up the DMA masks. If dma_set_coherent_mask() or dma_set_mask() fails, the error path frees the subchannel structure directly, bypassing the device model reference counting.

Once device_initialize() has been called, the embedded struct device must be released via put_device(), allowing the release callback to free the container structure.

Fix the error path by dropping the initial device reference with put_device() instead of calling kfree() directly.

This ensures correct device lifetime handling and avoids potential use-after-free or double-free issues.(CVE-2026-45981)

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

gfs2: Fix use-after-free in iomap inline data write path

The inline data buffer head (dibh) is being released prematurely in gfs2iomapbegin() via releasemetapath() while iomap->inlinedata still points to dibh->bdata. This causes a use-after-free when iomapwriteendinline() later attempts to write to the inline data area.

The bug sequence: 1. gfs2iomapbegin() calls gfs2metainodebuffer() to read inode metadata into dibh 2. Sets iomap->inlinedata = dibh->bdata + sizeof(struct gfs2dinode) 3. Calls releasemetapath() which calls brelse(dibh), dropping refcount to 0 4. kswapd reclaims the page (~39ms later in the syzbot report) 5. iomapwriteendinline() tries to memcpy() to iomap->inline_data 6. KASAN detects use-after-free write to freed memory

Fix by storing dibh in iomap->private and incrementing its refcount with getbh() in gfs2iomapbegin(). The buffer is then properly released in gfs2iomap_end() after the inline write completes, ensuring the page stays alive for the entire iomap operation.

Note: A C reproducer is not available for this issue. The fix is based on analysis of the KASAN report and code review showing the buffer head is freed before use.

agruenba: Take buffer head reference in gfs2iomapbegin() to avoid leaks in gfs2iomapget() and gfs2iomapalloc().

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: 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:

usb: usblp: fix heap leak in IEEE 1284 device ID via short response

usblpctrlmsg() collapses the usbcontrolmsg() return value to 0/-errno, discarding the actual number of bytes transferred. A broken printer can complete the GETDEVICEID control transfer short and the driver has no way to know.

usblpcachedeviceidstring() reads the 2-byte big-endian length prefix from the response and trusts it (clamped only to the buffer bounds). The buffer is kmalloc(1024) at probe time. A device that sends exactly two bytes (e.g. 0x03 0xFF, claiming a 1023-byte ID) leaves deviceidstring[2..1022] holding stale kmalloc heap.

That stale data is then exposed: - via the ieee1284id sysfs attribute (sprintf("%s", buf+2), truncated at the first NUL in the stale heap), and - via the IOCNRGETDEVICEID ioctl, which copytouser()s the full claimed length regardless of NULs, up to 1021 bytes of uninitialized heap, with the leak size chosen by the device.

Fix this up by just zapping the buffer with zeros before each request sent to the device.(CVE-2026-46151)

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

usb: usblp: fix uninitialized heap leak via LPGETSTATUS ioctl

Just like in a previous problem in this driver, usblpctrlmsg() will collapse the usbcontrolmsg() return value to 0/-errno, discarding the actual number of bytes transferred.

Ideally that short command should be detected and error out, but many printers are known to send "incorrect" responses back so we can't just do that.

statusbuf is kmalloc(8) at probe time and never filled before the first LPGETSTATUS ioctl.

usblpreadstatus() requests 1 byte. If a malicious printer responds with zero bytes, *statusbuf is one byte of stale kmalloc heap, sign-extended into the local int status, which the LPGETSTATUS path then copytouser()s directly to the ioctl caller.

Fix this all by just zapping out the memory buffer when allocated at probe time. If a later call does a short read, the data will be identical to what the device sent it the last time, so there is no "leak" of information happening.(CVE-2026-46167)

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

RDMA/mlx4: Fix mis-use of RCU in mlx4srqevent()

Sashiko points out the radixtree itself is RCU safe, but nothing ever frees the mlx4srq struct with RCU, and it isn't even accessed within the RCU critical section. It also will crash if an event is delivered before the srq object is finished initializing.

Use the spinlock since it isn't easy to make RCU work, use refcountincnotzero() to protect against partially initialized objects, and order the refcountset() to be after the srq is fully initialized.(CVE-2026-46181)

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

wifi: rsi: fix kthread lifetime race between self-exit and external-stop

RSI driver use both self-exit(kthreadcompleteandexit) and external-stop (kthreadstop) when killing a kthread. Generally, kthread_stop() is called first, and in this case, no particular issues occur.

However, in rare instances where kthreadcompleteandexit() is called first and then kthreadstop() is called, a UAF occurs because the kthread object, which has already exited and been freed, is accessed again.

Therefore, to prevent this with minimal modification, you must remove kthread_stop() and change the code to wait until the self-exit operation is completed.(CVE-2026-46187)

In the Linux kernel's vsock/virtio implementation, virtiotransportrecvlisten() calls skacceptqadded() before vsockassigntransport(). If vsockassigntransport() fails or selects a different transport, the error path returns without calling skacceptqremoved(), permanently incrementing skackbacklog. After approximately backlog+1 such failures, skacceptqisfull() returns true, causing the listener to reject all new connections, leading to a denial of service.(CVE-2026-46214)