OESA-2025-2804

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

drm/amd/display: Fix slab-use-after-free on hdcp_work

[Why] A slab-use-after-free is reported when HDCP is destroyed but the propertyvalidatedwork queue is still running.

[How] Cancel the delayed work when destroying workqueue.

(cherry picked from commit 725a04ba5a95e89c89633d4322430cfbca7ce128)(CVE-2025-21968)

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

nfsd: put dlstid if fail to queue dlrecall

Before calling nfsd4runcb to queue dlrecall to the callbackwq, we increment the reference count of dlstid. We expect that after the corresponding workstruct is processed, the reference count of dlstid will be decremented through the callback function nfsd4cbrecallrelease. However, if the call to nfsd4runcb fails, the incremented reference count of dlstid will not be decremented correspondingly, leading to the following nfs4stid leak: unreferenced object 0xffff88812067b578 (size 344): comm "nfsd", pid 2761, jiffies 4295044002 (age 5541.241s) hex dump (first 32 bytes): 01 00 00 00 6b 6b 6b 6b b8 02 c0 e2 81 88 ff ff ....kkkk........ 00 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 ad 4e ad de .kkkkkkk.....N.. backtrace: kmemcachealloc+0x4b9/0x700 nfsd4processopen1+0x34/0x300 nfsd4open+0x2d1/0x9d0 nfsd4proccompound+0x7a2/0xe30 nfsddispatch+0x241/0x3e0 svcprocesscommon+0x5d3/0xcc0 svcprocess+0x2a3/0x320 nfsd+0x180/0x2e0 kthread+0x199/0x1d0 retfromfork+0x30/0x50 retfromforkasm+0x1b/0x30 unreferenced object 0xffff8881499f4d28 (size 368): comm "nfsd", pid 2761, jiffies 4295044005 (age 5541.239s) hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 30 4d 9f 49 81 88 ff ff ........0M.I.... 30 4d 9f 49 81 88 ff ff 20 00 00 00 01 00 00 00 0M.I.... ....... backtrace: kmemcachealloc+0x4b9/0x700 nfs4allocstid+0x29/0x210 allocinitdeleg+0x92/0x2e0 nfs4setdelegation+0x284/0xc00 nfs4opendelegation+0x216/0x3f0 nfsd4processopen2+0x2b3/0xee0 nfsd4open+0x770/0x9d0 nfsd4proccompound+0x7a2/0xe30 nfsddispatch+0x241/0x3e0 svcprocesscommon+0x5d3/0xcc0 svcprocess+0x2a3/0x320 nfsd+0x180/0x2e0 kthread+0x199/0x1d0 retfromfork+0x30/0x50 retfromforkasm+0x1b/0x30 Fix it by checking the result of nfsd4runcb and call nfs4putstid if fail to queue dl_recall.(CVE-2025-22025)

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

ksmbd: add bounds check for create lease context

Add missing bounds check for create lease context.(CVE-2025-22042)

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

ksmbd: add bounds check for durable handle context

Add missing bounds check for durable handle context.(CVE-2025-22043)

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

wifi: cfg80211: fix out-of-bounds access during multi-link element defragmentation

Currently during the multi-link element defragmentation process, the multi-link element length added to the total IEs length when calculating the length of remaining IEs after the multi-link element in cfg80211defragmle(). This could lead to out-of-bounds access if the multi-link element or its corresponding fragment elements are the last elements in the IEs buffer.

To address this issue, correctly calculate the remaining IEs length by deducting the multi-link element end offset from total IEs end offset.(CVE-2025-37973)

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

net/sched: Always pass notifications when child class becomes empty

Certain classful qdiscs may invoke their classes' dequeue handler on an enqueue operation. This may unexpectedly empty the child qdisc and thus make an in-flight class passive via qlen_notify(). Most qdiscs do not expect such behaviour at this point in time and may re-activate the class eventually anyways which will lead to a use-after-free.

The referenced fix commit attempted to fix this behavior for the HFSC case by moving the backlog accounting around, though this turned out to be incomplete since the parent's parent may run into the issue too. The following reproducer demonstrates this use-after-free:

tc qdisc add dev lo root handle 1: drr
tc filter add dev lo parent 1: basic classid 1:1
tc class add dev lo parent 1: classid 1:1 drr
tc qdisc add dev lo parent 1:1 handle 2: hfsc def 1
tc class add dev lo parent 2: classid 2:1 hfsc rt m1 8 d 1 m2 0
tc qdisc add dev lo parent 2:1 handle 3: netem
tc qdisc add dev lo parent 3:1 handle 4: blackhole

echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888
tc class delete dev lo classid 1:1
echo 1 | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888

Since backlog accounting issues leading to a use-after-frees on stale class pointers is a recurring pattern at this point, this patch takes a different approach. Instead of trying to fix the accounting, the patch ensures that qdisctreereducebacklog always calls qlennotify when the child qdisc is empty. This solves the problem because deletion of qdiscs always involves a call to qdiscreset() and / or qdiscpurgequeue() which ultimately resets its qlen to 0 thus causing the following qdisctreereducebacklog() to report to the parent. Note that this may call qlennotify on passive classes multiple times. This is not a problem after the recent patch series that made all the classful qdiscs qlennotify() handlers idempotent.(CVE-2025-38350)

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

net: vlan: fix VLAN 0 refcount imbalance of toggling filtering during runtime

Assuming the "rx-vlan-filter" feature is enabled on a net device, the 8021q module will automatically add or remove VLAN 0 when the net device is put administratively up or down, respectively. There are a couple of problems with the above scheme.

The first problem is a memory leak that can happen if the "rx-vlan-filter" feature is disabled while the device is running:

# ip link add bond1 up type bond mode 0 # ethtool -K bond1 rx-vlan-filter off # ip link del dev bond1

When the device is put administratively down the "rx-vlan-filter" feature is disabled, so the 8021q module will not remove VLAN 0 and the memory will be leaked [1].

Another problem that can happen is that the kernel can automatically delete VLAN 0 when the device is put administratively down despite not adding it when the device was put administratively up since during that time the "rx-vlan-filter" feature was disabled. null-ptr-unref or bugon[2] will be triggered by unregistervlan_dev() for refcount imbalance if toggling filtering during runtime:

$ ip link add bond0 type bond mode 0 $ ip link add link bond0 name vlan0 type vlan id 0 protocol 802.1q $ ethtool -K bond0 rx-vlan-filter off $ ifconfig bond0 up $ ethtool -K bond0 rx-vlan-filter on $ ifconfig bond0 down $ ip link del vlan0

Root cause is as below: step1: add vlan0 for realdev, such as bond, team. registervlandev vlanvidadd(realdev,htons(ETHP8021Q),0) //refcnt=1 step2: disable vlan filter feature and enable realdev step3: change filter from 0 to 1 vlandeviceevent vlanfilterpushvids ndovlanrxaddvid //No refcnt added to realdev vlan0 step4: realdev down vlandeviceevent vlanviddel(dev, htons(ETHP8021Q), 0); //refcnt=0 vlaninforcufree //free vlan0 step5: delete vlan0 unregistervlandev BUGON(!vlaninfo); //vlaninfo is null

Fix both problems by noting in the VLAN info whether VLAN 0 was automatically added upon NETDEVUP and based on that decide whether it should be deleted upon NETDEVDOWN, regardless of the state of the "rx-vlan-filter" feature.

[1] unreferenced object 0xffff8880068e3100 (size 256): comm "ip", pid 384, jiffies 4296130254 hex dump (first 32 bytes): 00 20 30 0d 80 88 ff ff 00 00 00 00 00 00 00 00 . 0............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 81ce31fa): kmalloccachenoprof+0x2b5/0x340 vlanvidadd+0x434/0x940 vlandeviceevent.cold+0x75/0xa8 notifiercallchain+0xca/0x150 _devnotifyflags+0xe3/0x250 rtnlconfigurelink+0x193/0x260 rtnlnewlinkcreate+0x383/0x8e0 _rtnlnewlink+0x22c/0xa40 rtnlnewlink+0x627/0xb00 rtnetlinkrcvmsg+0x6fb/0xb70 netlinkrcvskb+0x11f/0x350 netlinkunicast+0x426/0x710 netlinksendmsg+0x75a/0xc20 _socksendmsg+0xc1/0x150 syssendmsg+0x5aa/0x7b0 _syssendmsg+0xfc/0x180

[2] kernel BUG at net/8021q/vlan.c:99! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 0 UID: 0 PID: 382 Comm: ip Not tainted 6.16.0-rc3 #61 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:unregistervlandev (net/8021q/vlan.c:99 (discriminator 1)) RSP: 0018:ffff88810badf310 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff88810da84000 RCX: ffffffffb47ceb9a RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88810e8b43c8 RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6cefe80 R10: ffffffffb677f407 R11: ffff88810badf3c0 R12: ffff88810e8b4000 R13: 0000000000000000 R14: ffff88810642a5c0 R15: 000000000000017e FS: 00007f1ff68c20c0(0000) GS:ffff888163a24000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1ff5dad240 CR3: 0000000107e56000 CR4: 00000000000006f0 Call Trace: <TASK ---truncated---(CVE-2025-38470)

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

smb: client: fix use-after-free in cifsoplockbreak

A race condition can occur in cifsoplockbreak() leading to a use-after-free of the cinode structure when unmounting:

cifsoplockbreak() cifsFileInfoput(cfile) cifsFileInfoputfinal() cifssbdeactive() [last ref, start releasing sb] killsb() killanonsuper() genericshutdownsuper() evictinodes() disposelist() evict() destroyinode() callrcu(&inode->ircu, icallback) spinlock(&cinode->openfilelock) <- OK [later] icallback() cifsfreeinode() kmemcachefree(cinode) spinunlock(&cinode->openfilelock) <- UAF cifsdoneoplock_break(cinode) <- UAF

The issue occurs when umount has already released its reference to the superblock. When cifsFileInfoput() calls cifssbdeactive(), this releases the last reference, triggering the immediate cleanup of all inodes under RCU. However, cifsoplockbreak() continues to access the cinode after this point, resulting in use-after-free.

Fix this by holding an extra reference to the superblock during the entire oplock break operation. This ensures that the superblock and its inodes remain valid until the oplock break completes.(CVE-2025-38527)

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

netlink: avoid infinite retry looping in netlink_unicast()

netlink_attachskb() checks for the socket's read memory allocation constraints. Firstly, it has:

rmem < READONCE(sk->skrcvbuf)

to check if the just increased rmem value fits into the socket's receive buffer. If not, it proceeds and tries to wait for the memory under:

rmem + skb->truesize > READONCE(sk->skrcvbuf)

The checks don't cover the case when skb->truesize + sk->skrmemalloc is equal to sk->sk_rcvbuf. Thus the function neither successfully accepts these conditions, nor manages to reschedule the task - and is called in retry loop for indefinite time which is caught as:

rcu: INFO: rcusched self-detected stall on CPU rcu: 0-....: (25999 ticks this GP) idle=ef2/1/0x4000000000000000 softirq=262269/262269 fqs=6212 (t=26000 jiffies g=230833 q=259957) NMI backtrace for cpu 0 CPU: 0 PID: 22 Comm: kauditd Not tainted 5.10.240 #68 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc42 04/01/2014 Call Trace: <IRQ> dumpstack lib/dumpstack.c:120 nmicpubacktrace.cold lib/nmibacktrace.c:105 nmitriggercpumaskbacktrace lib/nmibacktrace.c:62 rcudumpcpustacks kernel/rcu/treestall.h:335 rcuschedclockirq.cold kernel/rcu/tree.c:2590 updateprocesstimes kernel/time/timer.c:1953 tickschedhandle kernel/time/tick-sched.c:227 tickschedtimer kernel/time/tick-sched.c:1399 _hrtimerrunqueues kernel/time/hrtimer.c:1652 hrtimerinterrupt kernel/time/hrtimer.c:1717 _sysvecapictimerinterrupt arch/x86/kernel/apic/apic.c:1113 asmcallirqonstack arch/x86/entry/entry64.S:808 </IRQ>

netlinkattachskb net/netlink/afnetlink.c:1234 netlinkunicast net/netlink/afnetlink.c:1349 kauditdsendqueue kernel/audit.c:776 kauditdthread kernel/audit.c:897 kthread kernel/kthread.c:328 retfromfork arch/x86/entry/entry64.S:304

Restore the original behavior of the check which commit in Fixes accidentally missed when restructuring the code.

Found by Linux Verification Center (linuxtesting.org).(CVE-2025-38727)

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

smb: client: fix crypto buffers in non-linear memory

The crypto API, through the scatterlist API, expects input buffers to be in linear memory. We handle this with the cifssgset_buf() helper that converts vmalloc'd memory to their corresponding pages.

However, when we allocate our aeadrequest buffer (@creq in smb2ops.c::cryptmessage()), we do so with kvzalloc(), which possibly puts aeadrequest->_ctx in vmalloc area.

AEAD algorithm then uses ->_ctx for its private/internal data and operations, and uses sgset_buf() for such data on a few places.

This works fine as long as @creq falls into kmalloc zone (small requests) or vmalloc'd memory is still within linear range.

Tasks' stacks are vmalloc'd by default (CONFIGVMAPSTACK=y), so too many tasks will increment the base stacks' addresses to a point where virtaddrvalid(buf) will fail (BUG() in sgsetbuf()) when that happens.

In practice: too many parallel reads and writes on an encrypted mount will trigger this bug.

To fix this, always alloc @creq with kmalloc() instead. Also drop the @sensitivesize variable/arguments since kfreesensitive() doesn't need it.

Backtrace:

[ 945.272081] ------------[ cut here ]------------ [ 945.272774] kernel BUG at include/linux/scatterlist.h:209! [ 945.273520] Oops: invalid opcode: 0000 [#1] SMP DEBUGPAGEALLOC NOPTI [ 945.274412] CPU: 7 UID: 0 PID: 56 Comm: kworker/u33:0 Kdump: loaded Not tainted 6.15.0-lku-11779-g8e9d6efccdd7-dirty #1 PREEMPT(voluntary) [ 945.275736] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014 [ 945.276877] Workqueue: writeback wbworkfn (flush-cifs-2) [ 945.277457] RIP: 0010:cryptogcminitcommon+0x1f9/0x220 [ 945.278018] Code: b0 00 00 00 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 48 c7 c0 00 00 00 80 48 2b 05 5c 58 e5 00 e9 58 ff ff ff <0f> 0b 0f 0b 0f 0b 0f 0b 0f 0b 0f 0b 48 c7 04 24 01 00 00 00 48 8b [ 945.279992] RSP: 0018:ffffc90000a27360 EFLAGS: 00010246 [ 945.280578] RAX: 0000000000000000 RBX: ffffc90001d85060 RCX: 0000000000000030 [ 945.281376] RDX: 0000000000080000 RSI: 0000000000000000 RDI: ffffc90081d85070 [ 945.282145] RBP: ffffc90001d85010 R08: ffffc90001d85000 R09: 0000000000000000 [ 945.282898] R10: ffffc90001d85090 R11: 0000000000001000 R12: ffffc90001d85070 [ 945.283656] R13: ffff888113522948 R14: ffffc90001d85060 R15: ffffc90001d85010 [ 945.284407] FS: 0000000000000000(0000) GS:ffff8882e66cf000(0000) knlGS:0000000000000000 [ 945.285262] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 945.285884] CR2: 00007fa7ffdd31f4 CR3: 000000010540d000 CR4: 0000000000350ef0 [ 945.286683] Call Trace: [ 945.286952] <TASK> [ 945.287184] ? cryptmessage+0x33f/0xad0 [cifs] [ 945.287719] cryptogcmencrypt+0x36/0xe0 [ 945.288152] cryptmessage+0x54a/0xad0 [cifs] [ 945.288724] smb3inittransformrq+0x277/0x300 [cifs] [ 945.289300] smbsendrqst+0xa3/0x160 [cifs] [ 945.289944] cifscallasync+0x178/0x340 [cifs] [ 945.290514] ? pfxsmb2writevcallback+0x10/0x10 [cifs] [ 945.291177] smb2asyncwritev+0x3e3/0x670 [cifs] [ 945.291759] ? findheldlock+0x32/0x90 [ 945.292212] ? netfsadvancewrite+0xf2/0x310 [ 945.292723] netfsadvancewrite+0xf2/0x310 [ 945.293210] netfswritefolio+0x346/0xcc0 [ 945.293689] ? _pfxrawspinunlockirq+0x10/0x10 [ 945.294250] netfswritepages+0x117/0x460 [ 945.294724] dowritepages+0xbe/0x170 [ 945.295152] ? findheldlock+0x32/0x90 [ 945.295600] ? kvmschedclockread+0x11/0x20 [ 945.296103] _writebacksingleinode+0x56/0x4b0 [ 945.296643] writebacksbinodes+0x229/0x550 [ 945.297140] _writebackinodeswb+0x4c/0xe0 [ 945.297642] wbwriteback+0x2f1/0x3f0 [ 945.298069] wbworkfn+0x300/0x490 [ 945.298472] processonework+0x1fe/0x590 [ 945.298949] workerthread+0x1ce/0x3c0 [ 945.299397] ? _pfxworkerthread+0x10/0x10 [ 945.299900] kthr ---truncated---(CVE-2025-40052)

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

RDMA/rxe: Fix race in do_task() when draining

When dotask() exhausts its iteration budget (!ret), it sets the state to TASKSTATEIDLE to reschedule, without a secondary check on the current task->state. This can overwrite the TASKSTATEDRAINING state set by a concurrent call to rxecleanuptask() or rxedisable_task().

While state changes are protected by a spinlock, both rxecleanuptask() and rxedisabletask() release the lock while waiting for the task to finish draining in the while(!isdone(task)) loop. The race occurs if dotask() hits its iteration limit and acquires the lock in this window. The cleanup logic may then proceed while the task incorrectly reschedules itself, leading to a potential use-after-free.

This bug was introduced during the migration from tasklets to workqueues, where the special handling for the draining case was lost.

Fix this by restoring the original pre-migration behavior. If the state is TASKSTATEDRAINING when iterations are exhausted, set cont to 1 to force a new loop iteration. This allows the task to finish its work, so that a subsequent iteration can reach the switch statement and correctly transition the state to TASKSTATEDRAINED, stopping the task as intended.(CVE-2025-40061)

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

ipv4: start using dstdevrcu()

Change icmpv4xrlimallow(), ip_defrag() to prevent possible UAF.

Change ipmrpreparexmit(), ipmrqueuefwdxmit(), ipmroutput(), ipv4neighlookup() to use lockdep enabled dstdev_rcu().(CVE-2025-40074)

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

tcpmetrics: use dstdevnetrcu()

Replace three dst_dev() with a lockdep enabled helper.(CVE-2025-40075)

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

ixgbevf: fix mailbox API compatibility by negotiating supported features

There was backward compatibility in the terms of mailbox API. Various drivers from various OSes supporting 10G adapters from Intel portfolio could easily negotiate mailbox API.

This convention has been broken since introducing API 1.4. Commit 0062e7cc955e ("ixgbevf: add VF IPsec offload code") added support for IPSec which is specific only for the kernel ixgbe driver. None of the rest of the Intel 10G PF/VF drivers supports it. And actually lack of support was not included in the IPSec implementation - there were no such code paths. No possibility to negotiate support for the feature was introduced along with introduction of the feature itself.

Commit 339f28964147 ("ixgbevf: Add support for new mailbox communication between PF and VF") increasing API version to 1.5 did the same - it introduced code supported specifically by the PF ESX driver. It altered API version for the VF driver in the same time not touching the version defined for the PF ixgbe driver. It led to additional discrepancies, as the code provided within API 1.6 cannot be supported for Linux ixgbe driver as it causes crashes.

The issue was noticed some time ago and mitigated by Jake within the commit d0725312adf5 ("ixgbevf: stop attempting IPSEC offload on Mailbox API 1.5"). As a result we have regression for IPsec support and after increasing API to version 1.6 ixgbevf driver stopped to support ESX MBX.

To fix this mess add new mailbox op asking PF driver about supported features. Basing on a response determine whether to set support for IPSec and ESX-specific enhanced mailbox.

New mailbox op, for compatibility purposes, must be added within new API revision, as API version of OOT PF & VF drivers is already increased to 1.6 and doesn't incorporate features negotiate op.

Features negotiation mechanism gives possibility to be extended with new features when needed in the future.(CVE-2025-40104)

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

ASoC: Intel: bytcr_rt5651: Fix invalid quirk input mapping

When an invalid value is passed via quirk option, currently bytcr_rt5640 driver just ignores and leaves as is, which may lead to unepxected results like OOB access.

This patch adds the sanity check and corrects the input mapping to the certain default value if an invalid value is passed.(CVE-2025-40121)

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

ipv6: use RCU in ip6_xmit()

Use RCU in ip6xmit() in order to use dstdev_rcu() to prevent possible UAF.(CVE-2025-40135)

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

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

smcclcprfx_set() is called during connect() and not under RCU nor RTNL.

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

Let's use _skdstget() and devdstrcu() under rcureadlock() after kernelgetsockname().

Note that the returned value of smcclcprfx_set() is not used in the caller.

While at it, we change the 1st arg of smcclcprfxset[46]rcu() not to touch dst there.(CVE-2025-40139)

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

tls: Use _skdstget() and dstdevrcu() in getnetdevforsock().

getnetdevfor_sock() is called during setsockopt(), so not under RCU.

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

Let's use _skdstget() and dstdev_rcu().

Note that the only ->ndoskgetlowerdev() user is bondskgetlowerdev(), which uses RCU.(CVE-2025-40149)

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

iommu/vt-d: debugfs: Fix legacy mode page table dump logic

In legacy mode, SSPTPTR is ignored if TT is not 00b or 01b. SSPTPTR maybe uninitialized or zero in that case and may cause oops like:

Oops: general protection fault, probably for non-canonical address 0xf00087d3f000f000: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 786 Comm: cat Not tainted 6.16.0 #191 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-5.fc42 04/01/2014 RIP: 0010:pgtablewalklevel+0x98/0x150 RSP: 0018:ffffc90000f279c0 EFLAGS: 00010206 RAX: 0000000040000000 RBX: ffffc90000f27ab0 RCX: 000000000000001e RDX: 0000000000000003 RSI: f00087d3f000f000 RDI: f00087d3f0010000 RBP: ffffc90000f27a00 R08: ffffc90000f27a98 R09: 0000000000000002 R10: 0000000000000000 R11: 0000000000000000 R12: f00087d3f000f000 R13: 0000000000000000 R14: 0000000040000000 R15: ffffc90000f27a98 FS: 0000764566dcb740(0000) GS:ffff8881f812c000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000764566d44000 CR3: 0000000109d81003 CR4: 0000000000772ef0 PKRU: 55555554 Call Trace: <TASK> pgtablewalklevel+0x88/0x150 domaintranslationstructshow.isra.0+0x2d9/0x300 devdomaintranslationstructshow+0x20/0x40 seqread_iter+0x12d/0x490 ...

Avoid walking the page table if TT is not 00b or 01b.(CVE-2025-40155)

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

ipv6: use RCU in ip6_output()

Use RCU in ip6output() in order to use dstdev_rcu() to prevent possible UAF.

We can remove rcureadlock()/rcureadunlock() pairs from ip6finishoutput2().(CVE-2025-40158)