OESA-2025-2120

 sk_alloc (./include/net/net_namespace.h:345 net/core/sock.c:2236)
 inet_create (net/ipv4/af_inet.c:326 net/ipv4/af_inet.c:252)
 __sock_create (net/socket.c:1558)
 udp_sock_create4 (net/ipv4/udp_tunnel_core.c:18)
 gtp_create_sock (./include/net/udp_tunnel.h:59 drivers/net/gtp.c:1423)
 gtp_create_sockets (drivers/net/gtp.c:1447)
 gtp_newlink (drivers/net/gtp.c:1507)
 rtnl_newlink (net/core/rtnetlink.c:3786 net/core/rtnetlink.c:3897 net/core/rtnetlink.c:4012)
 rtnetlink_rcv_msg (net/core/rtnetlink.c:6922)
 netlink_rcv_skb (net/netlink/af_netlink.c:2542)
 netlink_unicast (net/netlink/af_netlink.c:1321 net/netlink/af_netlink.c:1347)
 netlink_sendmsg (net/netlink/af_netlink.c:1891)
 ____sys_sendmsg (net/socket.c:711 net/socket.c:726 net/socket.c:2583)
 ___sys_sendmsg (net/socket.c:2639)
 __sys_sendmsg (net/socket.c:2669)
 do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)

WARNING: CPU: 1 PID: 60 at lib/reftracker.c:179 reftrackerdirexit (lib/reftracker.c:179) Modules linked in: CPU: 1 UID: 0 PID: 60 Comm: kworker/u16:2 Not tainted 6.13.0-rc5-00147-g4c1224501e9d #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Workqueue: netns cleanupnet RIP: 0010:reftrackerdirexit (lib/reftracker.c:179) Code: 00 00 00 fc ff df 4d 8b 26 49 bd 00 01 00 00 00 00 ad de 4c 39 f5 0f 85 df 00 00 00 48 8b 74 24 08 48 89 df e8 a5 cc 12 02 90 <0f> 0b 90 48 8d 6b 44 be 04 00 00 00 48 89 ef e8 80 de 67 ff 48 89 RSP: 0018:ff11000009a07b60 EFLAGS: 00010286 RAX: 0000000000002bd3 RBX: ff1100000f4e1aa0 RCX: 1ffffffff0e40ac6 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff8423ee3c RBP: ff1100000f4e1af0 R08: 0000000000000001 R09: fffffbfff0e395ae R10: 0000000000000001 R11: 0000000000036001 R12: ff1100000f4e1af0 R13: dead000000000100 R14: ff1100000f4e1af0 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ff1100006ce80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f9b2464bd98 CR3: 0000000005286005 CR4: 0000000000771ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? _warn (kernel/panic.c:748) ? reftrackerdirexit (lib/reftracker.c:179) ? reportbug (lib/bug.c:201 lib/bug.c:219) ? handlebug (arch/x86/kernel/traps.c:285) ? excinvalidop (arch/x86/kernel/traps.c:309 (discriminator 1)) ? asmexcinvalidop (./arch/x86/include/asm/idtentry.h:621) ? rawspinunlockirqrestore (./arch/x86/include/asm/irqflags.h:42 ./arch/x86/include/asm/irqflags.h:97 ./arch/x86/include/asm/irqflags.h:155 ./include/linux/spinlockapismp.h:151 kernel/locking/spinlock.c:194) ? reftrackerdirexit (lib/reftracker.c:179) ? _pfxreftrackerdirexit (lib/reftracker.c:158) ? kfree (mm/slub.c:4613 mm/slub.c:4761) netfree (net/core/netnamespace.c:476 net/core/netnamespace.c:467) cleanupnet (net/core/netnamespace.c:664 (discriminator 3)) processonework (kernel/workqueue.c:3229) workerthread (kernel/workqueue.c:3304 kernel/workqueue.c:3391 ---truncated---(CVE-2025-21678)

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

scsi: mpi3mr: Fix possible crash when setting up bsg fails

If bsgsetupqueue() fails, the bsgqueue is assigned a non-NULL value. Consequently, in mpi3mrbsgexit(), the condition "if(!mrioc->bsgqueue)" will not be satisfied, preventing execution from entering bsgremovequeue(), which could lead to the following crash:

BUG: kernel NULL pointer dereference, address: 000000000000041c Call Trace: <TASK> mpi3mrbsgexit+0x1f/0x50 [mpi3mr] mpi3mrremove+0x6f/0x340 [mpi3mr] pcideviceremove+0x3f/0xb0 devicereleasedriverinternal+0x19d/0x220 unbindstore+0xa4/0xb0 kernfsfopwriteiter+0x11f/0x200 vfswrite+0x1fc/0x3e0 ksyswrite+0x67/0xe0 dosyscall64+0x38/0x80 entrySYSCALL64afterhwframe+0x78/0xe2(CVE-2025-21723)

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

tcp: drop secpath at the same time as we currently drop dst

Xiumei reported hitting the WARN in xfrm6tunnelnet_exit while running tests that boil down to: - create a pair of netns - run a basic TCP test over ipcomp6 - delete the pair of netns

The xfrmstate found on spibyaddr was not deleted at the time we delete the netns, because we still have a reference on it. This lingering reference comes from a secpath (which holds a ref on the xfrmstate), which is still attached to an skb. This skb is not leaked, it ends up on skreceivequeue and then gets defer-free'd by skbattemptdeferfree.

The problem happens when we defer freeing an skb (push it on one CPU's deferlist), and don't flush that list before the netns is deleted. In that case, we still have a reference on the xfrmstate that we don't expect at this point.

We already drop the skb's dst in the TCP receive path when it's no longer needed, so let's also drop the secpath. At this point, tcp_filter has already called into the LSM hooks that may require the secpath, so it should not be needed anymore. However, in some of those places, the MPTCP extension has just been attached to the skb, so we cannot simply drop all extensions.(CVE-2025-21864)

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

ksmbd: fix type confusion via race condition when using ipcmsgsend_request

req->handle is allocated using ksmbdacquireid(&ipcida), based on idaalloc. req->handle from ksmbdipcloginrequest and FSCTLPIPE_TRANSCEIVE ioctl can be same and it could lead to type confusion between messages, resulting in access to unexpected parts of memory after an incorrect delivery. ksmbd check type of ipc response but missing add continue to check next ipc reponse.(CVE-2025-21947)

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

ksmbd: prevent connection release during oplock break notification

ksmbdwork could be freed when after connection release. Increment rcount of ksmbd_conn to indicate that requests are not finished yet and to not release the connection.(CVE-2025-21955)

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

Bluetooth: Fix error code in chanallocskb_cb()

The chanallocskb_cb() function is supposed to return error pointers on error. Returning NULL will lead to a NULL dereference.(CVE-2025-22007)

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

netfilter: socket: Lookup orig tuple for IPv6 SNAT

nfsklookupslowv4 does the conntrack lookup for IPv4 packets to restore the original 5-tuple in case of SNAT, to be able to find the right socket (if any). Then socket_match() can correctly check whether the socket was transparent.

However, the IPv6 counterpart (nfsklookupslowv6) lacks this conntrack lookup, making xtsocket fail to match on the socket when the packet was SNATed. Add the same logic to nfsklookupslow_v6.

IPv6 SNAT is used in Kubernetes clusters for pod-to-world packets, as pods' addresses are in the fd00::/8 ULA subnet and need to be replaced with the node's external address. Cilium leverages Envoy to enforce L7 policies, and Envoy uses transparent sockets. Cilium inserts an iptables prerouting rule that matches on -m socket --transparent and redirects the packets to localhost, but it fails to match SNATed IPv6 packets due to that missing conntrack lookup.(CVE-2025-22021)

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

netfilter: nfttunnel: fix geneveopt type confusion addition

When handling multiple NFTATUNNELKEYOPTSGENEVE attributes, the parsing logic should place every geneveopt structure one by one compactly. Hence, when deciding the next geneveopt position, the pointer addition should be in units of char *.

However, the current implementation erroneously does type conversion before the addition, which will lead to heap out-of-bounds write.

[ 6.989857] ================================================================== [ 6.990293] BUG: KASAN: slab-out-of-bounds in nfttunnelobjinit+0x977/0xa70 [ 6.990725] Write of size 124 at addr ffff888005f18974 by task poc/178 [ 6.991162] [ 6.991259] CPU: 0 PID: 178 Comm: poc-oob-write Not tainted 6.1.132 #1 [ 6.991655] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 6.992281] Call Trace: [ 6.992423] <TASK> [ 6.992586] dumpstacklvl+0x44/0x5c [ 6.992801] printreport+0x184/0x4be [ 6.993790] kasanreport+0xc5/0x100 [ 6.994252] kasancheckrange+0xf3/0x1a0 [ 6.994486] memcpy+0x38/0x60 [ 6.994692] nfttunnelobjinit+0x977/0xa70 [ 6.995677] nftobjinit+0x10c/0x1b0 [ 6.995891] nftablesnewobj+0x585/0x950 [ 6.996922] nfnetlinkrcvbatch+0xdf9/0x1020 [ 6.998997] nfnetlinkrcv+0x1df/0x220 [ 6.999537] netlinkunicast+0x395/0x530 [ 7.000771] netlinksendmsg+0x3d0/0x6d0 [ 7.001462] socksendmsg+0x99/0xa0 [ 7.001707] syssendmsg+0x409/0x450 [ 7.002391] _syssendmsg+0xfd/0x170 [ 7.003145] _syssendmsg+0xea/0x170 [ 7.004359] dosyscall64+0x5e/0x90 [ 7.005817] entrySYSCALL64afterhwframe+0x6e/0xd8 [ 7.006127] RIP: 0033:0x7ec756d4e407 [ 7.006339] Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 faf [ 7.007364] RSP: 002b:00007ffed5d46760 EFLAGS: 00000202 ORIG_RAX: 000000000000002e [ 7.007827] RAX: ffffffffffffffda RBX: 00007ec756cc4740 RCX: 00007ec756d4e407 [ 7.008223] RDX: 0000000000000000 RSI: 00007ffed5d467f0 RDI: 0000000000000003 [ 7.008620] RBP: 00007ffed5d468a0 R08: 0000000000000000 R09: 0000000000000000 [ 7.009039] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000 [ 7.009429] R13: 00007ffed5d478b0 R14: 00007ec756ee5000 R15: 00005cbd4e655cb8

Fix this bug with correct pointer addition and conversion in parse and dump code.(CVE-2025-22056)

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

net: decrease cached dst counters in dst_release

Upstream fix ac888d58869b ("net: do not delay dstentriesadd() in dstrelease()") moved decrementing the dst count from dstdestroy to dstrelease to avoid accessing already freed data in case of netns dismantle. However in case CONFIGDST_CACHE is enabled and OvS+tunnels are used, this fix is incomplete as the same issue will be seen for cached dsts:

Unable to handle kernel paging request at virtual address ffff5aabf6b5c000 Call trace: percpucounteraddbatch+0x3c/0x160 (P) dstrelease+0xec/0x108 dstcachedestroy+0x68/0xd8 dstdestroy+0x13c/0x168 dstdestroyrcu+0x1c/0xb0 rcudobatch+0x18c/0x7d0 rcucore+0x174/0x378 rcucoresi+0x18/0x30

Fix this by invalidating the cache, and thus decrementing cached dst counters, in dst_release too.(CVE-2025-22057)

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

netlabel: Fix NULL pointer exception caused by CALIPSO on IPv4 sockets

When calling netlblconnsetattr(), addr->safamily is used to determine the function behavior. If sk is an IPv4 socket, but the connect function is called with an IPv6 address, the function calipsosock_setattr() is triggered. Inside this function, the following code is executed:

skfullsock(sk) ? inetsk(sk)->pinet6 : NULL;

Since sk is an IPv4 socket, pinet6 is NULL, leading to a null pointer dereference.

This patch fixes the issue by checking if inet6_sk(sk) returns a NULL pointer before accessing pinet6.(CVE-2025-22063)

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

netfilter: nf_tables: don't unregister hook when table is dormant

When nftablesupdchain encounters an error, hook registration needs to be rolled back.

This should only be done if the hook has been registered, which won't happen when the table is flagged as dormant (inactive).

Just move the assignment into the registration block.(CVE-2025-22064)

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

RDMA/mlx5: Fix mlx5pollone() cur_qp update flow

When cur_qp isn't NULL, in order to avoid fetching the QP from the radix tree again we check if the next cqe QP is identical to the one we already have.

The bug however is that we are checking if the QP is identical by checking the QP number inside the CQE against the QP number inside the mlx5ibqp, but that's wrong since the QP number from the CQE is from FW so it should be matched against mlx5coreqp which is our FW QP number.

Otherwise we could use the wrong QP when handling a CQE which could cause the kernel trace below.

This issue is mainly noticeable over QPs 0 & 1, since for now they are the only QPs in our driver whereas the QP number inside mlx5ibqp doesn't match the QP number inside mlx5coreqp.

BUG: kernel NULL pointer dereference, address: 0000000000000012 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP CPU: 0 UID: 0 PID: 7927 Comm: kworker/u62:1 Not tainted 6.14.0-rc3+ #189 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: ib-comp-unb-wq ibcqpollwork [ibcore] RIP: 0010:mlx5ibpollcq+0x4c7/0xd90 [mlx5ib] Code: 03 00 00 8d 58 ff 21 cb 66 39 d3 74 39 48 c7 c7 3c 89 6e a0 0f b7 db e8 b7 d2 b3 e0 49 8b 86 60 03 00 00 48 c7 c7 4a 89 6e a0 <0f> b7 5c 98 02 e8 9f d2 b3 e0 41 0f b7 86 78 03 00 00 83 e8 01 21 RSP: 0018:ffff88810511bd60 EFLAGS: 00010046 RAX: 0000000000000010 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff88885fa1b3c0 RDI: ffffffffa06e894a RBP: 00000000000000b0 R08: 0000000000000000 R09: ffff88810511bc10 R10: 0000000000000001 R11: 0000000000000001 R12: ffff88810d593000 R13: ffff88810e579108 R14: ffff888105146000 R15: 00000000000000b0 FS: 0000000000000000(0000) GS:ffff88885fa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000012 CR3: 00000001077e6001 CR4: 0000000000370eb0 Call Trace: <TASK> ? _die+0x20/0x60 ? pagefaultoops+0x150/0x3e0 ? excpagefault+0x74/0x130 ? asmexcpagefault+0x22/0x30 ? mlx5ibpollcq+0x4c7/0xd90 [mlx5ib] _ibprocesscq+0x5a/0x150 [ibcore] ibcqpollwork+0x31/0x90 [ibcore] processonework+0x169/0x320 workerthread+0x288/0x3a0 ? workbusy+0xb0/0xb0 kthread+0xd7/0x1f0 ? kthreadsonlinecpu+0x130/0x130 ? kthreadsonlinecpu+0x130/0x130 retfromfork+0x2d/0x50 ? kthreadsonlinecpu+0x130/0x130 retfromforkasm+0x11/0x20 </TASK>(CVE-2025-22086)

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

RDMA/core: Don't expose hw_counters outside of init net namespace

Commit 467f432a521a ("RDMA/core: Split port and device counter sysfs attributes") accidentally almost exposed hw counters to non-init net namespaces. It didn't expose them fully, as an attempt to read any of those counters leads to a crash like this one:

[42021.807566] BUG: kernel NULL pointer dereference, address: 0000000000000028 [42021.814463] #PF: supervisor read access in kernel mode [42021.819549] #PF: errorcode(0x0000) - not-present page [42021.824636] PGD 0 P4D 0 [42021.827145] Oops: 0000 [#1] SMP PTI [42021.830598] CPU: 82 PID: 2843922 Comm: switchto-defaul Kdump: loaded Tainted: G S W I XXX [42021.841697] Hardware name: XXX [42021.849619] RIP: 0010:hwstatdeviceshow+0x1e/0x40 [ibcore] [42021.855362] Code: 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 49 89 d0 4c 8b 5e 20 48 8b 8f b8 04 00 00 48 81 c7 f0 fa ff ff <48> 8b 41 28 48 29 ce 48 83 c6 d0 48 c1 ee 04 69 d6 ab aa aa aa 48 [42021.873931] RSP: 0018:ffff97fe90f03da0 EFLAGS: 00010287 [42021.879108] RAX: ffff9406988a8c60 RBX: ffff940e1072d438 RCX: 0000000000000000 [42021.886169] RDX: ffff94085f1aa000 RSI: ffff93c6cbbdbcb0 RDI: ffff940c7517aef0 [42021.893230] RBP: ffff97fe90f03e70 R08: ffff94085f1aa000 R09: 0000000000000000 [42021.900294] R10: ffff94085f1aa000 R11: ffffffffc0775680 R12: ffffffff87ca2530 [42021.907355] R13: ffff940651602840 R14: ffff93c6cbbdbcb0 R15: ffff94085f1aa000 [42021.914418] FS: 00007fda1a3b9700(0000) GS:ffff94453fb80000(0000) knlGS:0000000000000000 [42021.922423] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [42021.928130] CR2: 0000000000000028 CR3: 00000042dcfb8003 CR4: 00000000003726f0 [42021.935194] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [42021.942257] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [42021.949324] Call Trace: [42021.951756] <TASK> [42021.953842] [<ffffffff86c58674>] ? showregs+0x64/0x70 [42021.959030] [<ffffffff86c58468>] ? _die+0x78/0xc0 [42021.963874] [<ffffffff86c9ef75>] ? pagefaultoops+0x2b5/0x3b0 [42021.969749] [<ffffffff87674b92>] ? excpagefault+0x1a2/0x3c0 [42021.975549] [<ffffffff87801326>] ? asmexcpagefault+0x26/0x30 [42021.981517] [<ffffffffc0775680>] ? _pfxshowhwstats+0x10/0x10 [ibcore] [42021.988482] [<ffffffffc077564e>] ? hwstatdeviceshow+0x1e/0x40 [ibcore] [42021.995438] [<ffffffff86ac7f8e>] devattrshow+0x1e/0x50 [42022.000803] [<ffffffff86a3eeb1>] sysfskfseqshow+0x81/0xe0 [42022.006508] [<ffffffff86a11134>] seqreaditer+0xf4/0x410 [42022.011954] [<ffffffff869f4b2e>] vfsread+0x16e/0x2f0 [42022.017058] [<ffffffff869f50ee>] ksysread+0x6e/0xe0 [42022.022073] [<ffffffff8766f1ca>] dosyscall64+0x6a/0xa0 [42022.027441] [<ffffffff8780013b>] entrySYSCALL64afterhwframe+0x78/0xe2

The problem can be reproduced using the following steps: ip netns add foo ip netns exec foo bash cat /sys/class/infiniband/mlx40/hwcounters/*

The panic occurs because of casting the device pointer into an ibdevice pointer using containerof() in hwstatdevice_show() is wrong and leads to a memory corruption.

However the real problem is that hw counters should never been exposed outside of the non-init net namespace.

Fix this by saving the index of the corresponding attribute group (it might be 1 or 2 depending on the presence of driver-specific attributes) and zeroing the pointer to hw_counters group for compat devices during the initialization.

With this fix applied hwcounters are not available in a non-init net namespace: find /sys/class/infiniband/mlx40/ -name hwcounters /sys/class/infiniband/mlx40/ports/1/hwcounters /sys/class/infiniband/mlx40/ports/2/hwcounters /sys/class/infiniband/mlx40/hw_counters

ip netns add foo ip netns exec foo bash find /sys/class/infiniband/mlx40/ -name hwcounters(CVE-2025-22089)

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

vmxnet3: unregister xdp rxq info in the reset path

vmxnet3 does not unregister xdp rxq info in the vmxnet3resetwork() code path as vmxnet3rqdestroy() is not invoked in this code path. So, we get below message with a backtrace.

Missing unregister, handled but fix driver WARNING: CPU:48 PID: 500 at net/core/xdp.c:182 _xdprxqinforeg+0x93/0xf0

This patch fixes the problem by moving the unregister code of XDP from vmxnet3rqdestroy() to vmxnet3rqcleanup().(CVE-2025-22106)

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

net: ppp: Add bound checking for skb data on pppsynctxmung

Ensure we have enough data in linear buffer from skb before accessing initial bytes. This prevents potential out-of-bounds accesses when processing short packets.

When pppsynctxmung receives an incoming package with an empty payload: (remote) gef➤ p *(struct pppoehdr *) (skb->head + skb->networkheader) $18 = { type = 0x1, ver = 0x1, code = 0x0, sid = 0x2, length = 0x0, tag = 0xffff8880371cdb96 }

from the skb struct (trimmed) tail = 0x16, end = 0x140, head = 0xffff88803346f400 "4", data = 0xffff88803346f416 ":\377", truesize = 0x380, len = 0x0, datalen = 0x0, maclen = 0xe, hdr_len = 0x0,

it is not safe to access data[2].

[(CVE-2025-37749)

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

netsched: schsfq: move the limit validation

It is not sufficient to directly validate the limit on the data that the user passes as it can be updated based on how the other parameters are changed.

Move the check at the end of the configuration update process to also catch scenarios where the limit is indirectly updated, for example with the following configurations:

tc qdisc add dev dummy0 handle 1: root sfq limit 2 flows 1 depth 1 tc qdisc add dev dummy0 handle 1: root sfq limit 2 flows 1 divisor 1

This fixes the following syzkaller reported crash:

------------[ cut here ]------------ UBSAN: array-index-out-of-bounds in net/sched/schsfq.c:203:6 index 65535 is out of range for type 'struct sfqhead[128]' CPU: 1 UID: 0 PID: 3037 Comm: syz.2.16 Not tainted 6.14.0-rc2-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 12/27/2024 Call Trace: <TASK> _dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x201/0x300 lib/dumpstack.c:120 ubsanepilogue lib/ubsan.c:231 [inline] _ubsanhandleoutofbounds+0xf5/0x120 lib/ubsan.c:429 sfqlink net/sched/schsfq.c:203 [inline] sfqdec+0x53c/0x610 net/sched/schsfq.c:231 sfqdequeue+0x34e/0x8c0 net/sched/schsfq.c:493 sfqreset+0x17/0x60 net/sched/schsfq.c:518 qdiscreset+0x12e/0x600 net/sched/schgeneric.c:1035 tbfreset+0x41/0x110 net/sched/schtbf.c:339 qdiscreset+0x12e/0x600 net/sched/schgeneric.c:1035 devresetqueue+0x100/0x1b0 net/sched/schgeneric.c:1311 netdevforeachtxqueue include/linux/netdevice.h:2590 [inline] devdeactivatemany+0x7e5/0xe70 net/sched/schgeneric.c:1375(CVE-2025-37752)

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

RDMA/cma: Fix workqueue crash in cmaneteventwork_handler

struct rdmacmid has member "struct workstruct network" that is reused for enqueuing cmaneteventworkhandler()s onto cmawq.

Below crash[1] can occur if more than one call to cmaneteventcallback() occurs in quick succession, which further enqueues cmaneteventworkhandler()s for the same rdmacmid, overwriting any previously queued work-item(s) that was just scheduled to run i.e. there is no guarantee the queued work item may run between two successive calls to cmaneteventcallback() and the 2nd INITWORK would overwrite the 1st work item (for the same rdmacmid), despite grabbing idtablelock during enqueue.

Also drgn analysis [2] indicates the work item was likely overwritten.

Fix this by moving the INITWORK() to _rdmacreateid(), so that it doesn't race with any existing queue_work() or its worker thread.

[1] Trimmed crash stack:

BUG: kernel NULL pointer dereference, address: 0000000000000008 kworker/u256:6 ... 6.12.0-0... Workqueue: cmaneteventworkhandler [rdmacm] (rdmacm) RIP: 0010:processonework+0xba/0x31a Call Trace: workerthread+0x266/0x3a0 kthread+0xcf/0x100 retfromfork+0x31/0x50

retfromfork_asm+0x1a/0x30

[2] drgn crash analysis:

>>> trace = prog.crashedthread().stacktrace() >>> trace (0) crashsetupregs (./arch/x86/include/asm/kexec.h:111:15) (1) _crashkexec (kernel/crashcore.c:122:4) (2) panic (kernel/panic.c:399:3) (3) oopsend (arch/x86/kernel/dumpstack.c:382:3) ... (8) processonework (kernel/workqueue.c:3168:2) (9) processscheduledworks (kernel/workqueue.c:3310:3) (10) worker_thread (kernel/workqueue.c:3391:4) (11) kthread (kernel/kthread.c:389:9)

Line workqueue.c:3168 for this kernel version is in processonework(): 3168 strscpy(worker->desc, pwq->wq->name, WORKERDESCLEN);

>>> trace[8]["work"] *(struct workstruct *)0xffff92577d0a21d8 = { .data = (atomiclongt){ .counter = (s64)536870912, <=== Note }, .entry = (struct listhead){ .next = (struct listhead *)0xffff924d075924c0, .prev = (struct listhead *)0xffff924d075924c0, }, .func = (workfunct)cmaneteventwork_handler+0x0 = 0xffffffffc2cec280, }

Suspicion is that pwq is NULL: >>> trace[8]["pwq"] (struct pool_workqueue *)<absent>

In processonework(), pwq is assigned from: struct poolworkqueue *pwq = getwork_pwq(work);

and getworkpwq() is: static struct poolworkqueue *getworkpwq(struct workstruct *work) { unsigned long data = atomiclongread(&work->data);

if (data &amp; WORK_STRUCT_PWQ)
    return work_struct_pwq(data);
else
    return NULL;

}

WORKSTRUCTPWQ is 0x4: >>> print(repr(prog['WORKSTRUCTPWQ'])) Object(prog, 'enum work_flags', value=4)

But work->data is 536870912 which is 0x20000000. So, getworkpwq() returns NULL and we crash in processonework(): 3168 strscpy(worker->desc, pwq->wq->name, WORKERDESCLEN); =============================================(CVE-2025-37772)

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

net: openvswitch: fix nested key length validation in the set() action

It's not safe to access nlalen(ovskey) if the data is smaller than the netlink header. Check that the attribute is OK first.(CVE-2025-37789)

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

wifi: mac80211: Purge vif txq in ieee80211dostop()

After ieee80211dostop() SKB from vif's txq could still be processed. Indeed another concurrent vif scheduleandwaketxq call could cause those packets to be dequeued (see ieee80211handlewaketx_queue()) without checking the sdata current state.

Because vif.drv_priv is now cleared in this function, this could lead to driver crash.

For example in ath12k, ahvif is store in vif.drvpriv. Thus if ath12kmacoptx() is called after ieee80211dostop(), ahvif->ah can be NULL, leading the ath12k_warn(ahvif->ah,...) call in this function to trigger the NULL deref below.

Unable to handle kernel paging request at virtual address dfffffc000000001 KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] batmanadv: bat0: Interface deactivated: brbh1337 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [dfffffc000000001] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP CPU: 1 UID: 0 PID: 978 Comm: lbd Not tainted 6.13.0-g633f875b8f1e #114 Hardware name: HW (DT) pstate: 10000005 (nzcV daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ath12kmacoptx+0x6cc/0x29b8 [ath12k] lr : ath12kmacoptx+0x174/0x29b8 [ath12k] sp : ffffffc086ace450 x29: ffffffc086ace450 x28: 0000000000000000 x27: 1ffffff810d59ca4 x26: ffffff801d05f7c0 x25: 0000000000000000 x24: 000000004000001e x23: ffffff8009ce4926 x22: ffffff801f9c0800 x21: ffffff801d05f7f0 x20: ffffff8034a19f40 x19: 0000000000000000 x18: ffffff801f9c0958 x17: ffffff800bc0a504 x16: dfffffc000000000 x15: ffffffc086ace4f8 x14: ffffff801d05f83c x13: 0000000000000000 x12: ffffffb003a0bf03 x11: 0000000000000000 x10: ffffffb003a0bf02 x9 : ffffff8034a19f40 x8 : ffffff801d05f818 x7 : 1ffffff0069433dc x6 : ffffff8034a19ee0 x5 : ffffff801d05f7f0 x4 : 0000000000000000 x3 : 0000000000000001 x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000008 Call trace: ath12kmacoptx+0x6cc/0x29b8 [ath12k] (P) ieee80211handlewaketxqueue+0x16c/0x260 ieee80211queueskb+0xeec/0x1d20 ieee80211tx+0x200/0x2c8 ieee80211xmit+0x22c/0x338 _ieee80211subifstartxmit+0x7e8/0xc60 ieee80211subifstartxmit+0xc4/0xee0 _ieee80211subifstartxmit8023.isra.0+0x854/0x17a0 ieee80211subifstartxmit8023+0x124/0x488 devhardstartxmit+0x160/0x5a8 _devqueuexmit+0x6f8/0x3120 brdevqueuepushxmit+0x120/0x4a8 _brforward+0xe4/0x2b0 deliverclone+0x5c/0xd0 brflood+0x398/0x580 brdevxmit+0x454/0x9f8 devhardstartxmit+0x160/0x5a8 _devqueuexmit+0x6f8/0x3120 ip6finishoutput2+0xc28/0x1b60 _ip6finishoutput+0x38c/0x638 ip6output+0x1b4/0x338 ip6localout+0x7c/0xa8 ip6sendskb+0x7c/0x1b0 ip6pushpendingframes+0x94/0xd0 rawv6sendmsg+0x1a98/0x2898 inetsendmsg+0x94/0xe0 _syssendto+0x1e4/0x308 _arm64syssendto+0xc4/0x140 doel0svc+0x110/0x280 el0svc+0x20/0x60 el0t64synchandler+0x104/0x138 el0t64sync+0x154/0x158

To avoid that, empty vif's txq at ieee80211dostop() so no packet could be dequeued after ieee80211dostop() (new packets cannot be queued because SDATASTATERUNNING is cleared at this point).(CVE-2025-37794)

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

cpufreq: scpi: Fix null-ptr-deref in scpicpufreqget_rate()

cpufreqcpugetraw() can return NULL when the target CPU is not present in the policy->cpus mask. scpicpufreqgetrate() does not check for this case, which results in a NULL pointer dereference.(CVE-2025-37829)

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

mm/vmscan: don't try to reclaim hwpoison folio

Syzkaller reports a bug as follows:

Injecting memory failure for pfn 0x18b00e at process virtual address 0x20ffd000 Memory failure: 0x18b00e: dirty swapcache page still referenced by 2 users Memory failure: 0x18b00e: recovery action for dirty swapcache page: Failed page: refcount:2 mapcount:0 mapping:0000000000000000 index:0x20ffd pfn:0x18b00e memcg:ffff0000dd6d9000 anon flags: 0x5ffffe00482011(locked|dirty|arch1|swapbacked|hwpoison|node=0|zone=2|lastcpupid=0xfffff) raw: 005ffffe00482011 dead000000000100 dead000000000122 ffff0000e232a7c9 raw: 0000000000020ffd 0000000000000000 00000002ffffffff ffff0000dd6d9000 page dumped because: VMBUGONFOLIO(!foliotestuptodate(folio)) ------------[ cut here ]------------ kernel BUG at mm/swapstate.c:184! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP Modules linked in: CPU: 0 PID: 60 Comm: kswapd0 Not tainted 6.6.0-gcb097e7de84e #3 Hardware name: linux,dummy-virt (DT) pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : addtoswap+0xbc/0x158 lr : addtoswap+0xbc/0x158 sp : ffff800087f37340 x29: ffff800087f37340 x28: fffffc00052c0380 x27: ffff800087f37780 x26: ffff800087f37490 x25: ffff800087f37c78 x24: ffff800087f377a0 x23: ffff800087f37c50 x22: 0000000000000000 x21: fffffc00052c03b4 x20: 0000000000000000 x19: fffffc00052c0380 x18: 0000000000000000 x17: 296f696c6f662865 x16: 7461646f7470755f x15: 747365745f6f696c x14: 6f6621284f494c4f x13: 0000000000000001 x12: ffff600036d8b97b x11: 1fffe00036d8b97a x10: ffff600036d8b97a x9 : dfff800000000000 x8 : 00009fffc9274686 x7 : ffff0001b6c5cbd3 x6 : 0000000000000001 x5 : ffff0000c25896c0 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff0000c25896c0 x0 : 0000000000000000 Call trace: addtoswap+0xbc/0x158 shrinkfoliolist+0x12ac/0x2648 shrinkinactivelist+0x318/0x948 shrinklruvec+0x450/0x720 shrinknodememcgs+0x280/0x4a8 shrinknode+0x128/0x978 balancepgdat+0x4f0/0xb20 kswapd+0x228/0x438 kthread+0x214/0x230 retfromfork+0x10/0x20

I can reproduce this issue with the following steps:

1) When a dirty swapcache page is isolated by reclaim process and the page isn't locked, inject memory failure for the page. meswapcachedirty() clears uptodate flag and tries to delete from lru, but fails. Reclaim process will put the hwpoisoned page back to lru.

2) The process that maps the hwpoisoned page exits, the page is deleted the page will never be freed and will be in the lru forever.

3) If we trigger a reclaim again and tries to reclaim the page, addtoswap() will trigger VMBUGON_FOLIO due to the uptodate flag is cleared.

To fix it, skip the hwpoisoned page in shrinkfoliolist(). Besides, the hwpoison folio may not be unmapped by hwpoisonusermappings() yet, unmap it in shrinkfoliolist(), otherwise the folio will fail to be unmaped by hwpoisonusermappings() since the folio isn't in lru list.(CVE-2025-37834)

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

page_pool: avoid infinite loop to schedule delayed worker

We noticed the kworker in pagepoolreleaseretry() was waken up repeatedly and infinitely in production because of the buggy driver causing the inflight less than 0 and warning us in pagepool_inflight()[1].

Since the inflight value goes negative, it means we should not expect the whole page_pool to get back to work normally.

This patch mitigates the adverse effect by not rescheduling the kworker when detecting the inflight negative in pagepoolrelease_retry().

[1] [Mon Feb 10 20:36:11 2025] ------------[ cut here ]------------ [Mon Feb 10 20:36:11 2025] Negative(-51446) inflight packet-pages ... [Mon Feb 10 20:36:11 2025] Call Trace: [Mon Feb 10 20:36:11 2025] pagepoolreleaseretry+0x23/0x70 [Mon Feb 10 20:36:11 2025] processonework+0x1b1/0x370 [Mon Feb 10 20:36:11 2025] workerthread+0x37/0x3a0 [Mon Feb 10 20:36:11 2025] kthread+0x11a/0x140 [Mon Feb 10 20:36:11 2025] ? processonework+0x370/0x370 [Mon Feb 10 20:36:11 2025] ? _kthreadcancelwork+0x40/0x40 [Mon Feb 10 20:36:11 2025] retfromfork+0x35/0x40 [Mon Feb 10 20:36:11 2025] ---[ end trace ebffe800f33e7e34 ]--- Note: before this patch, the above calltrace would flood the dmesg due to repeated reschedule of releasedw kworker.(CVE-2025-37859)

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

igc: fix PTM cycle trigger logic

Writing to clear the PTM status 'valid' bit while the PTM cycle is triggered results in unreliable PTM operation. To fix this, clear the PTM 'trigger' and status after each PTM transaction.

The issue can be reproduced with the following:

$ sudo phc2sys -R 1000 -O 0 -i tsn0 -m

Note: 1000 Hz (-R 1000) is unrealistically large, but provides a way to quickly reproduce the issue.

PHC2SYS exits with:

"ioctl PTPOFFSETPRECISE: Connection timed out" when the PTM transaction fails

This patch also fixes a hang in igc_probe() when loading the igc driver in the kdump kernel on systems supporting PTM.

The igc driver running in the base kernel enables PTM trigger in igc_probe(). Therefore the driver is always in PTM trigger mode, except in brief periods when manually triggering a PTM cycle.

When a crash occurs, the NIC is reset while PTM trigger is enabled. Due to a hardware problem, the NIC is subsequently in a bad busmaster state and doesn't handle register reads/writes. When running igc_probe() in the kdump kernel, the first register access to a NIC register hangs driver probing and ultimately breaks kdump.

With this patch, igc has PTM trigger disabled most of the time, and the trigger is only enabled for very brief (10 - 100 us) periods when manually triggering a PTM cycle. Chances that a crash occurs during a PTM trigger are not 0, but extremely reduced.(CVE-2025-37875)

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

9p/net: fix improper handling of bogus negative read/write replies

In p9clientwrite() and p9clientread_once(), if the server incorrectly replies with success but a negative write/read count then we would consider written (negative) <= rsize (positive) because both variables were signed.

Make variables unsigned to avoid this problem.

The reproducer linked below now fails with the following error instead of a null pointer deref: 9pnet: bogus RWRITE count (4294967295 > 3)(CVE-2025-37879)

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

KVM: x86: Reset IRTE to host control if new route isn't postable

Restore an IRTE back to host control (remapped or posted MSI mode) if the new GSI route prevents posting the IRQ directly to a vCPU, regardless of the GSI routing type. Updating the IRTE if and only if the new GSI is an MSI results in KVM leaving an IRTE posting to a vCPU.

The dangling IRTE can result in interrupts being incorrectly delivered to the guest, and in the worst case scenario can result in use-after-free, e.g. if the VM is torn down, but the underlying host IRQ isn't freed.(CVE-2025-37885)

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

net: lan743x: Fix memleak issue when GSO enabled

Always map the skb to the LS descriptor. Previously skb was mapped to EXT descriptor when the number of fragments is zero with GSO enabled. Mapping the skb to EXT descriptor prevents it from being freed, leading to a memory leak(CVE-2025-37909)

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

bnxt_en: Fix out-of-bound memcpy() during ethtool -w

When retrieving the FW coredump using ethtool, it can sometimes cause memory corruption:

BUG: KFENCE: memory corruption in _bnxtgetcoredump+0x3ef/0x670 [bnxten] Corrupted memory at 0x000000008f0f30e8 [ ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ] (in kfence-#45): _bnxtgetcoredump+0x3ef/0x670 [bnxten] ethtoolgetdumpdata+0xdc/0x1a0 _devethtool+0xa1e/0x1af0 devethtool+0xa8/0x170 devioctl+0x1b5/0x580 sockdoioctl+0xab/0xf0 sockioctl+0x1ce/0x2e0 _x64sysioctl+0x87/0xc0 dosyscall64+0x5c/0xf0 entrySYSCALL64after_hwframe+0x78/0x80

...

This happens when copying the coredump segment list in bnxthwrmdbgdmadata() with the HWRMDBGCOREDUMPLIST FW command. The info->destbuf buffer is allocated based on the number of coredump segments returned by the FW. The segment list is then DMA'ed by the FW and the length of the DMA is returned by FW. The driver then copies this DMA'ed segment list to info->dest_buf.

In some cases, this DMA length may exceed the info->destbuf length and cause the above BUG condition. Fix it by capping the copy length to not exceed the length of info->destbuf. The extra DMA data contains no useful information.

This code path is shared for the HWRMDBGCOREDUMPLIST and the HWRMDBGCOREDUMPRETRIEVE FW commands. The buffering is different for these 2 FW commands. To simplify the logic, we need to move the line to adjust the buffer length for HWRMDBGCOREDUMP_RETRIEVE up, so that the new check to cap the copy length will work for both commands.(CVE-2025-37911)

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

ice: Check VF VSI Pointer Value in icevcaddfdirfltr()

As mentioned in the commit baeb705fd6a7 ("ice: always check VF VSI pointer values"), we need to perform a null pointer check on the return value of icegetvf_vsi() before using it.(CVE-2025-37912)

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

net: phy: allow MDIO bus PM ops to start/stop state machine for phylink-controlled PHY

DSA has 2 kinds of drivers:

Those who call dsaswitchsuspend() and dsaswitchresume() from their device PM ops: qca8k-8xxx, bcm_sf2, microchip ksz
Those who don't: all others. The above methods should be optional.

For type 1, dsaswitchsuspend() calls dsausersuspend() -> phylinkstop(), and dsaswitchresume() calls dsauserresume() -> phylinkstart(). These seem good candidates for setting macmanagedpm = true because that is essentially its definition [1], but that does not seem to be the biggest problem for now, and is not what this change focuses on.

Talking strictly about the 2nd category of DSA drivers here (which do not have MAC managed PM, meaning that for their attached PHYs, mdiobusphysuspend() and mdiobusphyresume() should run in full), I have noticed that the following warning from mdiobusphy_resume() is triggered:

WARN_ON(phydev-&gt;state != PHY_HALTED &amp;&amp; phydev-&gt;state != PHY_READY &amp;&amp;
    phydev-&gt;state != PHY_UP);

because the PHY state machine is running.

It's running as a result of a previous dsauseropen() -> ... -> phylinkstart() -> phystart() having been initiated by the user.

The previous mdiobusphysuspend() was supposed to have called phystopmachine(), but it didn't. So this is why the PHY is in state PHYNOLINK by the time mdiobusphy_resume() runs.

mdiobusphysuspend() did not call phystopmachine() because for phylink, the phydev->adjustlink function pointer is NULL. This seems a technicality introduced by commit fddd91016d16 ("phylib: fix PAL state machine restart on resume"). That commit was written before phylink existed, and was intended to avoid crashing with consumer drivers which don't use the PHY state machine - phylink always does, when using a PHY. But phylink itself has historically not been developed with suspend/resume in mind, and apparently not tested too much in that scenario, allowing this bug to exist unnoticed for so long. Plus, prior to the WARN_ON(), it would have likely been invisible.

This issue is not in fact restricted to type 2 DSA drivers (according to the above ad-hoc classification), but can be extrapolated to any MAC driver with phylink and MDIO-bus-managed PHY PM ops. DSA is just where the issue was reported. Assuming macmanagedpm is set correctly, a quick search indicates the following other drivers might be affected:

$ grep -Zlr PHYLINKNETDEV drivers/ | xargs -0 grep -L macmanagedpm drivers/net/ethernet/atheros/ag71xx.c drivers/net/ethernet/microchip/sparx5/sparx5main.c drivers/net/ethernet/microchip/lan966x/lan966xmain.c drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c drivers/net/ethernet/freescale/fsenet/fsenet-main.c drivers/net/ethernet/freescale/dpaa/dpaaeth.c drivers/net/ethernet/freescale/uccgeth.c drivers/net/ethernet/freescale/enetc/enetcpfcommon.c drivers/net/ethernet/marvell/mvpp2/mvpp2main.c drivers/net/ethernet/marvell/mvneta.c drivers/net/ethernet/marvell/prestera/presteramain.c drivers/net/ethernet/mediatek/mtkethsoc.c drivers/net/ethernet/altera/alteratsemain.c drivers/net/ethernet/wangxun/txgbe/txgbephy.c drivers/net/ethernet/meta/fbnic/fbnicphylink.c drivers/net/ethernet/tehuti/tn40phy.c drivers/net/ethernet/mscc/ocelot_net.c

Make the existing conditions dependent on the PHY device having a phydev->phylinkchange() implementation equal to the default phylinkchange() provided by phylib. Otherwise, we implicitly know that the phydev has the phylink-provided phylinkphychange() callback, and when phylink is used, the PHY state machine always needs to be stopped/ started on the suspend/resume path. The code is structured as such that if phydev->phylinkchange() is absent, it is a matter of time until the kernel will crash - no need to further complicate the test.

Thus, for the situation where the PM is not managed b ---truncated---(CVE-2025-37945)

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

bpf: Scrub packet on bpfredirectpeer

When bpfredirectpeer is used to redirect packets to a device in another network namespace, the skb isn't scrubbed. That can lead skb information from one namespace to be "misused" in another namespace.

As one example, this is causing Cilium to drop traffic when using bpfredirectpeer to redirect packets that just went through IPsec decryption to a container namespace. The following pwru trace shows (1) the packet path from the host's XFRM layer to the container's XFRM layer where it's dropped and (2) the number of active skb extensions at each function.

NETNS       MARK  IFACE  TUPLE                                FUNC
4026533547  d00   eth0   10.244.3.124:35473-&gt;10.244.2.158:53  xfrm_rcv_cb
                         .active_extensions = (__u8)2,
4026533547  d00   eth0   10.244.3.124:35473-&gt;10.244.2.158:53  xfrm4_rcv_cb
                         .active_extensions = (__u8)2,
4026533547  d00   eth0   10.244.3.124:35473-&gt;10.244.2.158:53  gro_cells_receive
                         .active_extensions = (__u8)2,
[...]
4026533547  0     eth0   10.244.3.124:35473-&gt;10.244.2.158:53  skb_do_redirect
                         .active_extensions = (__u8)2,
4026534999  0     eth0   10.244.3.124:35473-&gt;10.244.2.158:53  ip_rcv
                         .active_extensions = (__u8)2,
4026534999  0     eth0   10.244.3.124:35473-&gt;10.244.2.158:53  ip_rcv_core
                         .active_extensions = (__u8)2,
[...]
4026534999  0     eth0   10.244.3.124:35473-&gt;10.244.2.158:53  udp_queue_rcv_one_skb
                         .active_extensions = (__u8)2,
4026534999  0     eth0   10.244.3.124:35473-&gt;10.244.2.158:53  __xfrm_policy_check
                         .active_extensions = (__u8)2,
4026534999  0     eth0   10.244.3.124:35473-&gt;10.244.2.158:53  __xfrm_decode_session
                         .active_extensions = (__u8)2,
4026534999  0     eth0   10.244.3.124:35473-&gt;10.244.2.158:53  security_xfrm_decode_session
                         .active_extensions = (__u8)2,
4026534999  0     eth0   10.244.3.124:35473-&gt;10.244.2.158:53  kfree_skb_reason(SKB_DROP_REASON_XFRM_POLICY)
                         .active_extensions = (__u8)2,

In this case, there are no XFRM policies in the container's network namespace so the drop is unexpected. When we decrypt the IPsec packet, the XFRM state used for decryption is set in the skb extensions. This information is preserved across the netns switch. When we reach the XFRM policy check in the container's netns, _xfrmpolicycheck drops the packet with LINUXMIB_XFRMINNOPOLS because a (container-side) XFRM policy can't be found that matches the (host-side) XFRM state used for decryption.

This patch fixes this by scrubbing the packet when using bpfredirectpeer, as is done on typical netns switches via veth devices except skb->mark and skb->tstamp are not zeroed.(CVE-2025-37959)

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

memblock: Accept allocated memory before use in memblockdoublearray()

When increasing the array size in memblockdoublearray() and the slab is not yet available, a call to memblockfindin_range() is used to reserve/allocate memory. However, the range returned may not have been accepted, which can result in a crash when booting an SNP guest:

RIP: 0010:memcpyorig+0x68/0x130 Code: ... RSP: 0000:ffffffff9cc03ce8 EFLAGS: 00010006 RAX: ff11001ff83e5000 RBX: 0000000000000000 RCX: fffffffffffff000 RDX: 0000000000000bc0 RSI: ffffffff9dba8860 RDI: ff11001ff83e5c00 RBP: 0000000000002000 R08: 0000000000000000 R09: 0000000000002000 R10: 000000207fffe000 R11: 0000040000000000 R12: ffffffff9d06ef78 R13: ff11001ff83e5000 R14: ffffffff9dba7c60 R15: 0000000000000c00 memblockdoublearray+0xff/0x310 memblockaddrange+0x1fb/0x2f0 memblockreserve+0x4f/0xa0 memblockallocrangenid+0xac/0x130 memblockallocinternal+0x53/0xc0 memblockalloctrynid+0x3d/0xa0 swiotlbinitremap+0x149/0x2f0 meminit+0xb/0xb0 mmcoreinit+0x8f/0x350 startkernel+0x17e/0x5d0 x8664startreservations+0x14/0x30 x8664startkernel+0x92/0xa0 secondarystartup64noverify+0x194/0x19b

Mitigate this by calling accept_memory() on the memory range returned before the slab is available.

Prior to v6.12, the acceptmemory() interface used a 'start' and 'end' parameter instead of 'start' and 'size', therefore the acceptmemory() call must be adjusted to specify 'start + size' for 'end' when applying to kernels prior to v6.12.(CVE-2025-37960)

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

ipvs: fix uninit-value for saddr in dooutputroute4

syzbot reports for uninit-value for the saddr argument [1]. commit 4754957f04f5 ("ipvs: do not use random local source address for tunnels") already implies that the input value of saddr should be ignored but the code is still reading it which can prevent to connect the route. Fix it by changing the argument to ret_saddr.

[1] BUG: KMSAN: uninit-value in dooutputroute4+0x42c/0x4d0 net/netfilter/ipvs/ipvsxmit.c:147 dooutputroute4+0x42c/0x4d0 net/netfilter/ipvs/ipvsxmit.c:147 ipvsgetoutrt+0x403/0x21d0 net/netfilter/ipvs/ipvsxmit.c:330 ipvstunnelxmit+0x205/0x2380 net/netfilter/ipvs/ipvsxmit.c:1136 ipvsinhook+0x1aa5/0x35b0 net/netfilter/ipvs/ipvscore.c:2063 nfhookentryhookfn include/linux/netfilter.h:154 [inline] nfhookslow+0xf7/0x400 net/netfilter/core.c:626 nfhook include/linux/netfilter.h:269 [inline] _iplocalout+0x758/0x7e0 net/ipv4/ipoutput.c:118 iplocalout net/ipv4/ipoutput.c:127 [inline] ipsendskb+0x6a/0x3c0 net/ipv4/ipoutput.c:1501 udpsendskb+0xfda/0x1b70 net/ipv4/udp.c:1195 udpsendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483 inetsendmsg+0x1fc/0x280 net/ipv4/afinet.c:851 socksendmsgnosec net/socket.c:712 [inline] _socksendmsg+0x267/0x380 net/socket.c:727 _syssendmsg+0x91b/0xda0 net/socket.c:2566 _syssendmsg+0x28d/0x3c0 net/socket.c:2620 _syssendmmsg+0x41d/0x880 net/socket.c:2702 _compatsyssendmmsg net/compat.c:360 [inline] _docompatsyssendmmsg net/compat.c:367 [inline] _secompatsyssendmmsg net/compat.c:364 [inline] _ia32compatsyssendmmsg+0xc8/0x140 net/compat.c:364 ia32syscall+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls32.h:346 dosyscall32irqson arch/x86/entry/syscall32.c:83 [inline] _dofastsyscall32+0xb0/0x110 arch/x86/entry/syscall32.c:306 dofastsyscall32+0x38/0x80 arch/x86/entry/syscall32.c:331 doSYSENTER32+0x1f/0x30 arch/x86/entry/syscall32.c:369 entrySYSENTERcompatafter_hwframe+0x84/0x8e

Uninit was created at: slabpostallochook mm/slub.c:4167 [inline] slaballocnode mm/slub.c:4210 [inline] kmalloccachenoprof+0x8fa/0xe00 mm/slub.c:4367 kmallocnoprof include/linux/slab.h:905 [inline] ipvsdestdstalloc net/netfilter/ipvs/ipvsxmit.c:61 [inline] _ipvsgetoutrt+0x35d/0x21d0 net/netfilter/ipvs/ipvsxmit.c:323 ipvstunnelxmit+0x205/0x2380 net/netfilter/ipvs/ipvsxmit.c:1136 ipvsinhook+0x1aa5/0x35b0 net/netfilter/ipvs/ipvscore.c:2063 nfhookentryhookfn include/linux/netfilter.h:154 [inline] nfhookslow+0xf7/0x400 net/netfilter/core.c:626 nfhook include/linux/netfilter.h:269 [inline] _iplocalout+0x758/0x7e0 net/ipv4/ipoutput.c:118 iplocalout net/ipv4/ipoutput.c:127 [inline] ipsendskb+0x6a/0x3c0 net/ipv4/ipoutput.c:1501 udpsendskb+0xfda/0x1b70 net/ipv4/udp.c:1195 udpsendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483 inetsendmsg+0x1fc/0x280 net/ipv4/afinet.c:851 socksendmsgnosec net/socket.c:712 [inline] _socksendmsg+0x267/0x380 net/socket.c:727 syssendmsg+0x91b/0xda0 net/socket.c:2566 _syssendmsg+0x28d/0x3c0 net/socket.c:2620 _syssendmmsg+0x41d/0x880 net/socket.c:2702 _compatsyssendmmsg net/compat.c:360 [inline] _docompatsyssendmmsg net/compat.c:367 [inline] _secompatsyssendmmsg net/compat.c:364 [inline] _ia32compatsyssendmmsg+0xc8/0x140 net/compat.c:364 ia32syscall+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls32.h:346 dosyscall32irqson arch/x86/entry/syscall32.c:83 [inline] _dofastsyscall32+0xb0/0x110 arch/x86/entry/syscall32.c:306 dofastsyscall32+0x38/0x80 arch/x86/entry/syscall32.c:331 doSYSENTER32+0x1f/0x30 arch/x86/entry/syscall32.c:369 entrySYSENTERcompatafter_hwframe+0x84/0x8e

CPU: 0 UID: 0 PID: 22408 Comm: syz.4.5165 Not tainted 6.15.0-rc3-syzkaller-00019-gbc3372351d0c #0 PREEMPT(undef) Hardware name: Google Google Compute Engi ---truncated---(CVE-2025-37961)

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

net: phy: leds: fix memory leak

A network restart test on a router led to an out-of-memory condition, which was traced to a memory leak in the PHY LED trigger code.

The root cause is misuse of the devm API. The registration function (phyledtriggersregister) is called from phyattachdirect, not phyprobe, and the unregister function (phyledtriggersunregister) is called from phydetach, not phy_remove. This means the register and unregister functions can be called multiple times for the same PHY device, but devm-allocated memory is not freed until the driver is unbound.

This also prevents kmemleak from detecting the leak, as the devm API internally stores the allocated pointer.

Fix this by replacing devmkzalloc/devmkcalloc with standard kzalloc/kcalloc, and add the corresponding kfree calls in the unregister path.(CVE-2025-37989)

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

wifi: brcm80211: fmac: Add error handling for brcmfusbdl_writeimage()

The function brcmfusbdlwriteimage() calls the function brcmfusbdlcmd() but dose not check its return value. The 'state.state' and the 'state.bytes' are uninitialized if the function brcmfusbdl_cmd() fails. It is dangerous to use uninitialized variables in the conditions.

Add error handling for brcmfusbdlcmd() to jump to error handling path if the brcmfusbdlcmd() fails and the 'state.state' and the 'state.bytes' are uninitialized.

Improve the error message to report more detailed error information.(CVE-2025-37990)

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

can: bcm: add missing rcu read protection for procfs content

When the procfs content is generated for a bcm_op which is in the process to be removed the procfs output might show unreliable data (UAF).

As the removal of bcmop's is already implemented with rcu handling this patch adds the missing rcuread_lock() and makes sure the list entries are properly removed under rcu protection.(CVE-2025-38003)

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

can: bcm: add locking for bcm_op runtime updates

The CAN broadcast manager (CAN BCM) can send a sequence of CAN frames via hrtimer. The content and also the length of the sequence can be changed resp reduced at runtime where the 'currframe' counter is then set to zero.

Although this appeared to be a safe operation the updates of 'currframe' can be triggered from user space and hrtimer context in bcmcantx(). Anderson Nascimento created a proof of concept that triggered a KASAN slab-out-of-bounds read access which can be prevented with a spinlockbh.

At the rework of bcmcantx() the 'count' variable has been moved into the protected section as this variable can be modified from both contexts too.(CVE-2025-38004)

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

phy: tegra: xusb: Use a bitmask for UTMI pad power state tracking

The current implementation uses biaspadenable as a reference count to manage the shared bias pad for all UTMI PHYs. However, during system suspension with connected USB devices, multiple power-down requests for the UTMI pad result in a mismatch in the reference count, which in turn produces warnings such as:

[ 237.762967] WARNING: CPU: 10 PID: 1618 at tegra186utmipadpowerdown+0x160/0x170 [ 237.763103] Call trace: [ 237.763104] tegra186utmipadpowerdown+0x160/0x170 [ 237.763107] tegra186utmiphypoweroff+0x10/0x30 [ 237.763110] phypoweroff+0x48/0x100 [ 237.763113] tegraxusbenterelpg+0x204/0x500 [ 237.763119] tegraxusbsuspend+0x48/0x140 [ 237.763122] platformpmsuspend+0x2c/0xb0 [ 237.763125] dpmruncallback.isra.0+0x20/0xa0 [ 237.763127] _devicesuspend+0x118/0x330 [ 237.763129] dpmsuspend+0x10c/0x1f0 [ 237.763130] dpmsuspendstart+0x88/0xb0 [ 237.763132] suspenddevicesandenter+0x120/0x500 [ 237.763135] pmsuspend+0x1ec/0x270

The root cause was traced back to the dynamic power-down changes introduced in commit a30951d31b25 ("xhci: tegra: USB2 pad power controls"), where the UTMI pad was being powered down without verifying its current state. This unbalanced behavior led to discrepancies in the reference count.

To rectify this issue, this patch replaces the single reference counter with a bitmask, renamed to utmipadenabled. Each bit in the mask corresponds to one of the four USB2 PHYs, allowing us to track each pad's enablement status individually.

With this change: - The bias pad is powered on only when the mask is clear. - Each UTMI pad is powered on or down based on its corresponding bit in the mask, preventing redundant operations. - The overall power state of the shared bias pad is maintained correctly during suspend/resume cycles.

The mutex used to prevent race conditions during UTMI pad enable/disable operations has been moved from the tegra186utmibiaspadpoweron/off functions to the parent functions tegra186utmipadpower_on/down. This change ensures that there are no race conditions when updating the bitmask.(CVE-2025-38010)

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

mlxsw: spectrum_router: Fix use-after-free when deleting GRE net devices

The driver only offloads neighbors that are constructed on top of net devices registered by it or their uppers (which are all Ethernet). The device supports GRE encapsulation and decapsulation of forwarded traffic, but the driver will not offload dummy neighbors constructed on top of GRE net devices as they are not uppers of its net devices:

# ip link add name gre1 up type gre tos inherit local 192.0.2.1 remote 198.51.100.1 # ip neigh add 0.0.0.0 lladdr 0.0.0.0 nud noarp dev gre1 $ ip neigh show dev gre1 nud noarp 0.0.0.0 lladdr 0.0.0.0 NOARP

(Note that the neighbor is not marked with 'offload')

When the driver is reloaded and the existing configuration is replayed, the driver does not perform the same check regarding existing neighbors and offloads the previously added one:

# devlink dev reload pci/0000:01:00.0 $ ip neigh show dev gre1 nud noarp 0.0.0.0 lladdr 0.0.0.0 offload NOARP

If the neighbor is later deleted, the driver will ignore the notification (given the GRE net device is not its upper) and will therefore keep referencing freed memory, resulting in a use-after-free [1] when the net device is deleted:

# ip neigh del 0.0.0.0 lladdr 0.0.0.0 dev gre1 # ip link del dev gre1

Fix by skipping neighbor replay if the net device for which the replay is performed is not our upper.

[1] BUG: KASAN: slab-use-after-free in mlxswspneighentryupdate+0x1ea/0x200 Read of size 8 at addr ffff888155b0e420 by task ip/2282 [...] Call Trace: <TASK> dumpstacklvl+0x6f/0xa0 printaddressdescription.constprop.0+0x6f/0x350 printreport+0x108/0x205 kasanreport+0xdf/0x110 mlxswspneighentryupdate+0x1ea/0x200 mlxswsprouterrifgonesync+0x2a8/0x440 mlxswsprifdestroy+0x1e9/0x750 mlxswspnetdeviceipipolevent+0x3c9/0xdc0 mlxswsprouternetdeviceevent+0x3ac/0x15e0 notifiercallchain+0xca/0x150 callnetdevicenotifiersinfo+0x7f/0x100 unregisternetdevicemanynotify+0xc8c/0x1d90 rtnldellink+0x34e/0xa50 rtnetlinkrcvmsg+0x6fb/0xb70 netlinkrcvskb+0x131/0x360 netlinkunicast+0x426/0x710 netlinksendmsg+0x75a/0xc20 socksendmsg+0xc1/0x150 _syssendmsg+0x5aa/0x7b0 _syssendmsg+0xfc/0x180 _syssendmsg+0x121/0x1b0 dosyscall64+0xbb/0x1d0 entrySYSCALL64afterhwframe+0x4b/0x53(CVE-2025-38019)

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

net/mlx5e: Disable MACsec offload for uplink representor profile

MACsec offload is not supported in switchdev mode for uplink representors. When switching to the uplink representor profile, the MACsec offload feature must be cleared from the netdevice's features.

If left enabled, attempts to add offloads result in a null pointer dereference, as the uplink representor does not support MACsec offload even though the feature bit remains set.

Clear NETIFFHWMACSEC in mlx5efixuplinkrep_features().

Kernel log:

Oops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f] CPU: 29 UID: 0 PID: 4714 Comm: ip Not tainted 6.14.0-rc4forupstreamdebug202503021735 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:mutexlock+0x128/0x1dd0 Code: d0 7c 08 84 d2 0f 85 ad 15 00 00 8b 35 91 5c fe 03 85 f6 75 29 49 8d 7e 60 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 a6 15 00 00 4d 3b 76 60 0f 85 fd 0b 00 00 65 ff RSP: 0018:ffff888147a4f160 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000001 RDX: 000000000000000f RSI: 0000000000000000 RDI: 0000000000000078 RBP: ffff888147a4f2e0 R08: ffffffffa05d2c19 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: dffffc0000000000 R14: 0000000000000018 R15: ffff888152de0000 FS: 00007f855e27d800(0000) GS:ffff88881ee80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000004e5768 CR3: 000000013ae7c005 CR4: 0000000000372eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 Call Trace: <TASK> ? dieaddr+0x3d/0xa0 ? excgeneralprotection+0x144/0x220 ? asmexcgeneralprotection+0x22/0x30 ? mlx5emacsecaddsecy+0xf9/0x700 [mlx5core] ? _mutexlock+0x128/0x1dd0 ? lockdepsetlockcmpfn+0x190/0x190 ? mlx5emacsecaddsecy+0xf9/0x700 [mlx5core] ? mutexlockionested+0x1ae0/0x1ae0 ? lockacquire+0x1c2/0x530 ? macsecupdoffload+0x145/0x380 ? lockdephardirqsonprepare+0x400/0x400 ? kasansavestack+0x30/0x40 ? kasansavestack+0x20/0x40 ? kasansavetrack+0x10/0x30 ? _kasankmalloc+0x77/0x90 ? _kmallocnoprof+0x249/0x6b0 ? genlfamilyrcvmsgattrsparse.constprop.0+0xb5/0x240 ? mlx5emacsecaddsecy+0xf9/0x700 [mlx5core] mlx5emacsecaddsecy+0xf9/0x700 [mlx5core] ? mlx5emacsecaddrxsa+0x11a0/0x11a0 [mlx5core] macsecupdateoffload+0x26c/0x820 ? macsecsetmacaddress+0x4b0/0x4b0 ? lockdephardirqsonprepare+0x284/0x400 ? _rawspinunlockirqrestore+0x47/0x50 macsecupdoffload+0x2c8/0x380 ? macsecupdateoffload+0x820/0x820 ? _nlaparse+0x22/0x30 ? genlfamilyrcvmsgattrsparse.constprop.0+0x15e/0x240 genlfamilyrcvmsgdoit+0x1cc/0x2a0 ? genlfamilyrcvmsgattrsparse.constprop.0+0x240/0x240 ? capcapable+0xd4/0x330 genlrcvmsg+0x3ea/0x670 ? genlfamilyrcvmsgdumpit+0x2a0/0x2a0 ? lockdepsetlockcmpfn+0x190/0x190 ? macsecupdateoffload+0x820/0x820 netlinkrcvskb+0x12b/0x390 ? genlfamilyrcvmsgdumpit+0x2a0/0x2a0 ? netlinkack+0xd80/0xd80 ? rwsemdownreadslowpath+0xf90/0xf90 ? netlinkdelivertap+0xcd/0xac0 ? netlinkdelivertap+0x155/0xac0 ? _copyfromiter+0x1bb/0x12c0 genlrcv+0x24/0x40 netlinkunicast+0x440/0x700 ? netlinkattachskb+0x760/0x760 ? lockacquire+0x1c2/0x530 ? _mightfault+0xbb/0x170 netlinksendmsg+0x749/0xc10 ? netlinkunicast+0x700/0x700 ? _mightfault+0xbb/0x170 ? netlinkunicast+0x700/0x700 _socksendmsg+0xc5/0x190 syssendmsg+0x53f/0x760 ? importiovec+0x7/0x10 ? kernelsendmsg+0x30/0x30 ? copymsghdr+0x3c0/0x3c0 ? filterirqstacks+0x90/0x90 ? stackdepotsaveflags+0x28/0xa30 _syssen ---truncated---(CVE-2025-38020)

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

RDMA/core: Fix "KASAN: slab-use-after-free Read in ibregisterdevice" problem

Call Trace:

dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x116/0x1f0 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:408 [inline] printreport+0xc3/0x670 mm/kasan/report.c:521 kasanreport+0xe0/0x110 mm/kasan/report.c:634 strlen+0x93/0xa0 lib/string.c:420 _fortifystrlen include/linux/fortify-string.h:268 [inline] getkobjpathlength lib/kobject.c:118 [inline] kobjectgetpath+0x3f/0x2a0 lib/kobject.c:158 kobjectueventenv+0x289/0x1870 lib/kobjectuevent.c:545 ibregisterdevice drivers/infiniband/core/device.c:1472 [inline] ibregisterdevice+0x8cf/0xe00 drivers/infiniband/core/device.c:1393 rxeregisterdevice+0x275/0x320 drivers/infiniband/sw/rxe/rxeverbs.c:1552 rxenetadd+0x8e/0xe0 drivers/infiniband/sw/rxe/rxenet.c:550 rxenewlink+0x70/0x190 drivers/infiniband/sw/rxe/rxe.c:225 nldevnewlink+0x3a3/0x680 drivers/infiniband/core/nldev.c:1796 rdmanlrcvmsg+0x387/0x6e0 drivers/infiniband/core/netlink.c:195 rdmanlrcvskb.constprop.0.isra.0+0x2e5/0x450 netlinkunicastkernel net/netlink/afnetlink.c:1313 [inline] netlinkunicast+0x53a/0x7f0 net/netlink/afnetlink.c:1339 netlinksendmsg+0x8d1/0xdd0 net/netlink/afnetlink.c:1883 socksendmsgnosec net/socket.c:712 [inline] _socksendmsg net/socket.c:727 [inline] syssendmsg+0xa95/0xc70 net/socket.c:2566 _syssendmsg+0x134/0x1d0 net/socket.c:2620 _syssendmsg+0x16d/0x220 net/socket.c:2652 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xcd/0x260 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f

This problem is similar to the problem that the commit 1d6a9e7449e2 ("RDMA/core: Fix use-after-free when rename device name") fixes.

The root cause is: the function ibdevicerename() renames the name with lock. But in the function kobject_uevent(), this name is accessed without lock protection at the same time.

The solution is to add the lock protection when this name is accessed in the function kobject_uevent().(CVE-2025-38022)

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

RDMA/rxe: Fix slab-use-after-free Read in rxequeuecleanup bug

Call Trace: <TASK> _dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x7d/0xa0 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0xcf/0x610 mm/kasan/report.c:489 kasanreport+0xb5/0xe0 mm/kasan/report.c:602 rxequeuecleanup+0xd0/0xe0 drivers/infiniband/sw/rxe/rxequeue.c:195 rxecqcleanup+0x3f/0x50 drivers/infiniband/sw/rxe/rxecq.c:132 _rxecleanup+0x168/0x300 drivers/infiniband/sw/rxe/rxepool.c:232 rxecreatecq+0x22e/0x3a0 drivers/infiniband/sw/rxe/rxeverbs.c:1109 createcq+0x658/0xb90 drivers/infiniband/core/uverbscmd.c:1052 ibuverbscreatecq+0xc7/0x120 drivers/infiniband/core/uverbscmd.c:1095 ibuverbswrite+0x969/0xc90 drivers/infiniband/core/uverbsmain.c:679 vfswrite fs/readwrite.c:677 [inline] vfswrite+0x26a/0xcc0 fs/readwrite.c:659 ksyswrite+0x1b8/0x200 fs/readwrite.c:731 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xaa/0x1b0 arch/x86/entry/common.c:83 entrySYSCALL64after_hwframe+0x77/0x7f

In the function rxecreatecq, when rxecqfrominit fails, the function rxecleanup will be called to handle the allocated resources. In fact, some memory resources have already been freed in the function rxecqfrom_init. Thus, this problem will occur.

The solution is to let rxe_cleanup do all the work.(CVE-2025-38024)

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

net/mlx5e: Avoid WARN_ON when configuring MQPRIO with HTB offload enabled

When attempting to enable MQPRIO while HTB offload is already configured, the driver currently returns -EINVAL and triggers a WARN_ON, leading to an unnecessary call trace.

Update the code to handle this case more gracefully by returning -EOPNOTSUPP instead, while also providing a helpful user message.(CVE-2025-38039)

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

dmaengine: ti: k3-udma-glue: Drop skipfdq argument from k3udmaglueresetrxchn

The user of k3udmaglueresetrxchn() e.g. tiam65cpswnuss can run on multiple platforms having different DMA architectures. On some platforms there can be one FDQ for all flows in the RX channel while for others there is a separate FDQ for each flow in the RX channel.

So far we have been relying on the skipfdq argument of k3udmaglueresetrxchn().

Instead of relying on the user to provide this information, infer it based on DMA architecture during k3udmagluerequestrxchn() and save it in an internal flag 'singlefdq'. Use that flag at k3udmaglueresetrx_chn() to deicide if the FDQ needs to be cleared for every flow or just for flow 0.

Fixes the below issue on tiam65cpsw_nuss driver on AM62-SK.

> ip link set eth1 down > ip link set eth0 down > ethtool -L eth0 rx 8 > ip link set eth0 up > modprobe -r tiam65cpsw_nuss

[ 103.045726] ------------[ cut here ]------------ [ 103.050505] k3knavdescpool size 512000 != avail 64000 [ 103.050703] WARNING: CPU: 1 PID: 450 at drivers/net/ethernet/ti/k3-cppi-desc-pool.c:33 k3cppidescpooldestroy+0xa0/0xa8 [k3cppidescpool] [ 103.068810] Modules linked in: tiam65cpswnuss(-) k3cppidescpool sndsochdmicodec crct10difce sndsocsimplecard sndsocsimplecardutils displayconnector rtctik3 k3j72xxbandgap tidss drmclientlib sndsocdavincimcas p drmdmahelper tps6598x phylink sndsoctiudma rtiwdt drmdisplayhelper sndsoctlv320aic3xi2c typec at24 phygmiisel sndsoctiedma sndsoctlv320aic3x sii902x sndsoctisdma sa2ul omapmailbox drmkmshelper authenc cfg80211 r fkill fuse drm drmpanelorientationquirks backlight iptables xtables ipv6 [last unloaded: k3cppidescpool] [ 103.119950] CPU: 1 UID: 0 PID: 450 Comm: modprobe Not tainted 6.13.0-rc7-00001-g9c5e3435fa66 #1011 [ 103.119968] Hardware name: Texas Instruments AM625 SK (DT) [ 103.119974] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 103.119983] pc : k3cppidescpooldestroy+0xa0/0xa8 [k3cppidescpool] [ 103.148007] lr : k3cppidescpooldestroy+0xa0/0xa8 [k3cppidescpool] [ 103.154709] sp : ffff8000826ebbc0 [ 103.158015] x29: ffff8000826ebbc0 x28: ffff0000090b6300 x27: 0000000000000000 [ 103.165145] x26: 0000000000000000 x25: 0000000000000000 x24: ffff0000019df6b0 [ 103.172271] x23: ffff0000019df6b8 x22: ffff0000019df410 x21: ffff8000826ebc88 [ 103.179397] x20: 000000000007d000 x19: ffff00000a3b3000 x18: 0000000000000000 [ 103.186522] x17: 0000000000000000 x16: 0000000000000000 x15: 000001e8c35e1cde [ 103.193647] x14: 0000000000000396 x13: 000000000000035c x12: 0000000000000000 [ 103.200772] x11: 000000000000003a x10: 00000000000009c0 x9 : ffff8000826eba20 [ 103.207897] x8 : ffff0000090b6d20 x7 : ffff00007728c180 x6 : ffff00007728c100 [ 103.215022] x5 : 0000000000000001 x4 : ffff000000508a50 x3 : ffff7ffff6146000 [ 103.222147] x2 : 0000000000000000 x1 : e300b4173ee6b200 x0 : 0000000000000000 [ 103.229274] Call trace: [ 103.231714] k3cppidescpooldestroy+0xa0/0xa8 [k3cppidescpool] (P) [ 103.238408] am65cpswnussfreerxchns+0x28/0x4c [tiam65cpswnuss] [ 103.244942] devmactionrelease+0x14/0x20 [ 103.249040] releasenodes+0x3c/0x68 [ 103.252610] devresreleaseall+0x8c/0xdc [ 103.256614] deviceunbindcleanup+0x18/0x60 [ 103.260876] devicereleasedriverinternal+0xf8/0x178 [ 103.266004] driverdetach+0x50/0x9c [ 103.269571] busremovedriver+0x6c/0xbc [ 103.273485] driverunregister+0x30/0x60 [ 103.277401] platformdriverunregister+0x14/0x20 [ 103.282096] am65cpswnussdriverexit+0x18/0xff4 [tiam65cpswnuss] [ 103.288620] _arm64sysdeletemodule+0x17c/0x25c [ 103.293404] invokesyscall+0x44/0x100 [ 103.297149] el0svccommon.constprop.0+0xc0/0xe0 [ 103.301845] doel0svc+0x1c/0x28 [ 103.305155] el0_svc+0x28/0x98 ---truncated---(CVE-2025-38042)

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

media: cx231xx: set device_caps for 417

The videodevice for the MPEG encoder did not set devicecaps.

Add this, otherwise the video device can't be registered (you get a WARN_ON instead).

Not seen before since currently 417 support is disabled, but I found this while experimenting with it.(CVE-2025-38044)

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

espintcp: fix skb leaks

A few error paths are missing a kfree_skb.(CVE-2025-38057)

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

dm cache: prevent BUG_ON by blocking retries on failed device resumes

A cache device failing to resume due to mapping errors should not be retried, as the failure leaves a partially initialized policy object. Repeating the resume operation risks triggering BUG_ON when reloading cache mappings into the incomplete policy object.

Reproduce steps:

create a cache metadata consisting of 512 or more cache blocks, with some mappings stored in the first array block of the mapping array. Here we use cache_restore v1.0 to build the metadata.

cat <<EOF >> cmeta.xml <superblock uuid="" blocksize="128" nrcacheblocks="512" \ policy="smq" hintwidth="4"> <mappings> <mapping cacheblock="0" originblock="0" dirty="false"/> </mappings> </superblock> EOF dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" cache_restore -i cmeta.xml -o /dev/mapper/cmeta --metadata-version=2 dmsetup remove cmeta

wipe the second array block of the mapping array to simulate data degradations.

mappingroot=$(dd if=/dev/sdc bs=1c count=8 skip=192 \ 2>/dev/null | hexdump -e '1/8 "%u\n"') ablock=$(dd if=/dev/sdc bs=1c count=8 skip=$((4096*mappingroot+2056)) \ 2>/dev/null | hexdump -e '1/8 "%u\n"') dd if=/dev/zero of=/dev/sdc bs=4k count=1 seek=$ablock

try bringing up the cache device. The resume is expected to fail due to the broken array block.

dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 65536 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc 262144" dmsetup create cache --notable dmsetup load cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" dmsetup resume cache

try resuming the cache again. An unexpected BUG_ON is triggered while loading cache mappings.

dmsetup resume cache

Kernel logs:

(snip) ------------[ cut here ]------------ kernel BUG at drivers/md/dm-cache-policy-smq.c:752! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 0 UID: 0 PID: 332 Comm: dmsetup Not tainted 6.13.4 #3 RIP: 0010:smqloadmapping+0x3e5/0x570

Fix by disallowing resume operations for devices that failed the initial attempt.(CVE-2025-38066)

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

mm/hugetlb: fix hugepmdunshare() vs GUP-fast race

hugepmdunshare() drops a reference on a page table that may have previously been shared across processes, potentially turning it into a normal page table used in another process in which unrelated VMAs can afterwards be installed.

If this happens in the middle of a concurrent gupfast(), gupfast() could end up walking the page tables of another process. While I don't see any way in which that immediately leads to kernel memory corruption, it is really weird and unexpected.

Fix it with an explicit broadcast IPI through tlbremovetablesyncone(), just like we do in khugepaged when removing page tables for a THP collapse.(CVE-2025-38085)

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

net/sched: fix use-after-free in tapriodevnotifier

Since taprio’s tapriodevnotifier() isn’t protected by an RCU read-side critical section, a race with advance_sched() can lead to a use-after-free.

Adding rcureadlock() inside tapriodevnotifier() prevents this.(CVE-2025-38087)

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

espintcp: remove encap socket caching to avoid reference leak

The current scheme for caching the encap socket can lead to reference leaks when we try to delete the netns.

The reference chain is: xfrmstate -> enacpsk -> netns

Since the encap socket is a userspace socket, it holds a reference on the netns. If we delete the espintcp state (through flush or individual delete) before removing the netns, the reference on the socket is dropped and the netns is correctly deleted. Otherwise, the netns may not be reachable anymore (if all processes within the ns have terminated), so we cannot delete the xfrm state to drop its reference on the socket.

This patch results in a small (~2% in my tests) performance regression.

A GC-type mechanism could be added for the socket cache, to clear references if the state hasn't been used "recently", but it's a lot more complex than just not caching the socket.(CVE-2025-38097)

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

pagepool: Fix use-after-free in pagepoolrecyclein_ring

syzbot reported a uaf in pagepoolrecycleinring:

BUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30 kernel/locking/lockdep.c:5862 Read of size 8 at addr ffff8880286045a0 by task syz.0.284/6943

CPU: 0 UID: 0 PID: 6943 Comm: syz.0.284 Not tainted 6.13.0-rc3-syzkaller-gdfa94ce54f41 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: <TASK> _dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0x169/0x550 mm/kasan/report.c:489 kasanreport+0x143/0x180 mm/kasan/report.c:602 lockrelease+0x151/0xa30 kernel/locking/lockdep.c:5862 _rawspinunlockbh include/linux/spinlockapismp.h:165 [inline] _rawspinunlockbh+0x1b/0x40 kernel/locking/spinlock.c:210 spinunlockbh include/linux/spinlock.h:396 [inline] ptrringproducebh include/linux/ptrring.h:164 [inline] pagepoolrecycleinring net/core/pagepool.c:707 [inline] pagepoolputunrefednetmem+0x748/0xb00 net/core/pagepool.c:826 pagepoolputnetmem include/net/pagepool/helpers.h:323 [inline] pagepoolputfullnetmem include/net/pagepool/helpers.h:353 [inline] napippputpage+0x149/0x2b0 net/core/skbuff.c:1036 skbpprecycle net/core/skbuff.c:1047 [inline] skbfreehead net/core/skbuff.c:1094 [inline] skbreleasedata+0x6c4/0x8a0 net/core/skbuff.c:1125 skbreleaseall net/core/skbuff.c:1190 [inline] _kfreeskb net/core/skbuff.c:1204 [inline] skskbreasondrop+0x1c9/0x380 net/core/skbuff.c:1242 kfreeskbreason include/linux/skbuff.h:1263 [inline] _skbqueuepurge_reason include/linux/skbuff.h:3343 [inline]

root cause is:

pagepoolrecycleinring ptrringproduce spinlock(&r->producerlock); WRITEONCE(r->queue[r->producer++], ptr) //recycle last page to pool pagepoolrelease pagepoolscrub pagepoolemptyring ptrringconsume pagepoolreturnpage //release all page _pagepooldestroy freepercpu(pool->recyclestats); free(pool) //free

 spin_unlock(&amp;r-&gt;producer_lock); //pool-&gt;ring uaf read

recyclestatinc(pool, ring);

pagepool can be free while page pool recycle the last page in ring. Add producer-lock barrier to pagepool_release to prevent the page pool from being free before all pages have been recycled.

recyclestatinc() is empty when CONFIGPAGEPOOL_STATS is not enabled, which will trigger Wempty-body build warning. Add definition for pool stat macro to fix warning.(CVE-2025-38129)

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

bpf, sockmap: Avoid using sk_socket after free when sending

The sk->sksocket is not locked or referenced in backlog thread, and during the call to skbsendsock(), there is a race condition with the release of sksocket. All types of sockets(tcp/udp/unix/vsock) will be affected.

Race conditions: ''' CPU0 CPU1

backlog::skbsendsock sendmsgunlocked socksendmsg socksendmsgnosec close(fd): ... ops->release() -> sockmapclose() sk_socket->ops = NULL free(socket) sock->ops->sendmsg ^ panic here '''

The ref of psock become 0 after sockmapclose() executed. ''' void sockmapclose() { ... if (likely(psock)) { ... // !! here we remove psock and the ref of psock become 0 sockmapremovelinks(sk, psock) psock = skpsockget(sk); if (unlikely(!psock)) goto nopsock; <=== Control jumps here via goto ... canceldelayedworksync(&psock->work); <=== not executed skpsock_put(sk, psock); ... } '''

Based on the fact that we already wait for the workqueue to finish in sockmapclose() if psock is held, we simply increase the psock reference count to avoid race conditions.

With this patch, if the backlog thread is running, sockmapclose() will wait for the backlog thread to complete and cancel all pending work.

If no backlog running, any pending work that hasn't started by then will fail when invoked by skpsockget(), as the psock reference count have been zeroed, and skpsockdrop() will cancel all jobs via canceldelayedwork_sync().

In summary, we require synchronization to coordinate the backlog thread and close() thread.

The panic I catched: ''' Workqueue: events skpsockbacklog RIP: 0010:socksendmsg+0x21d/0x440 RAX: 0000000000000000 RBX: ffffc9000521fad8 RCX: 0000000000000001 ... Call Trace: <TASK> ? dieaddr+0x40/0xa0 ? excgeneralprotection+0x14c/0x230 ? asmexcgeneralprotection+0x26/0x30 ? socksendmsg+0x21d/0x440 ? socksendmsg+0x3e0/0x440 ? _pfxsocksendmsg+0x10/0x10 _skbsendsock+0x543/0xb70 skpsock_backlog+0x247/0xb80 ... '''(CVE-2025-38154)

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

bpf, sockmap: Fix panic when calling skb_linearize

The panic can be reproduced by executing the command: ./bench sockmap -c 2 -p 1 -a --rx-verdict-ingress --rx-strp 100000

Then a kernel panic was captured: ''' [ 657.460555] kernel BUG at net/core/skbuff.c:2178! [ 657.462680] Tainted: [W]=WARN [ 657.463287] Workqueue: events skpsockbacklog ... [ 657.469610] <TASK> [ 657.469738] ? die+0x36/0x90 [ 657.469916] ? dotrap+0x1d0/0x270 [ 657.470118] ? pskbexpandhead+0x612/0xf40 [ 657.470376] ? pskbexpandhead+0x612/0xf40 [ 657.470620] ? doerrortrap+0xa3/0x170 [ 657.470846] ? pskbexpandhead+0x612/0xf40 [ 657.471092] ? handleinvalidop+0x2c/0x40 [ 657.471335] ? pskbexpandhead+0x612/0xf40 [ 657.471579] ? excinvalidop+0x2d/0x40 [ 657.471805] ? asmexcinvalidop+0x1a/0x20 [ 657.472052] ? pskbexpandhead+0xd1/0xf40 [ 657.472292] ? pskbexpandhead+0x612/0xf40 [ 657.472540] ? lockacquire+0x18f/0x4e0 [ 657.472766] ? findheldlock+0x2d/0x110 [ 657.472999] ? pfxpskbexpandhead+0x10/0x10 [ 657.473263] ? _kmalloccachenoprof+0x5b/0x470 [ 657.473537] ? _pfxlockrelease.isra.0+0x10/0x10 [ 657.473826] _pskbpulltail+0xfd/0x1d20 [ 657.474062] ? _kasanslaballoc+0x4e/0x90 [ 657.474707] skpsockskbingressenqueue+0x3bf/0x510 [ 657.475392] ? _kasankmalloc+0xaa/0xb0 [ 657.476010] skpsockbacklog+0x5cf/0xd70 [ 657.476637] processonework+0x858/0x1a20 '''

The panic originates from the assertion BUGON(skbshared(skb)) in skblinearize(). A previous commit(see Fixes tag) introduced skbget() to avoid race conditions between skb operations in the backlog and skb release in the recvmsg path. However, this caused the panic to always occur when skb_linearize is executed.

The "--rx-strp 100000" parameter forces the RX path to use the strparser module which aggregates data until it reaches 100KB before calling sockmap logic. The 100KB payload exceeds MAXMSGFRAGS, triggering skb_linearize.

To fix this issue, just move skbget into skpsockskbingress_enqueue.

''' skpsockbacklog: skpsockhandleskb skbget(skb) <== we move it into 'skpsockskbingressenqueue' skpsockskbingress ↓ | | → skpsockskbingressself | skpsockskbingressenqueue skpsockverdictapply_↑ skb_linearize '''

Note that for verdictapply path, the skbget operation is unnecessary so we add 'take_ref' param to control it's behavior.(CVE-2025-38165)

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

bpf: fix ktls panic with sockmap

[ 2172.936997] ------------[ cut here ]------------ [ 2172.936999] kernel BUG at lib/ioviter.c:629! ...... [ 2172.944996] PKRU: 55555554 [ 2172.945155] Call Trace: [ 2172.945299] <TASK> [ 2172.945428] ? die+0x36/0x90 [ 2172.945601] ? dotrap+0xdd/0x100 [ 2172.945795] ? ioviterrevert+0x178/0x180 [ 2172.946031] ? ioviterrevert+0x178/0x180 [ 2172.946267] ? doerrortrap+0x7d/0x110 [ 2172.946499] ? ioviterrevert+0x178/0x180 [ 2172.946736] ? excinvalidop+0x50/0x70 [ 2172.946961] ? ioviterrevert+0x178/0x180 [ 2172.947197] ? asmexcinvalidop+0x1a/0x20 [ 2172.947446] ? ioviterrevert+0x178/0x180 [ 2172.947683] ? ioviterrevert+0x5c/0x180 [ 2172.947913] tlsswsendmsglocked.isra.0+0x794/0x840 [ 2172.948206] tlsswsendmsg+0x52/0x80 [ 2172.948420] ? inetsendmsg+0x1f/0x70 [ 2172.948634] _syssendto+0x1cd/0x200 [ 2172.948848] ? findheldlock+0x2b/0x80 [ 2172.949072] ? syscalltraceenter+0x140/0x270 [ 2172.949330] ? _lockrelease.isra.0+0x5e/0x170 [ 2172.949595] ? findheldlock+0x2b/0x80 [ 2172.949817] ? syscalltraceenter+0x140/0x270 [ 2172.950211] ? lockdephardirqsonprepare+0xda/0x190 [ 2172.950632] ? ktimegetcoarserealts64+0xc2/0xd0 [ 2172.951036] _x64syssendto+0x24/0x30 [ 2172.951382] dosyscall_64+0x90/0x170 ......

After calling bpfexectxverdict(), the size of msgpl->sg may increase, e.g., when the BPF program executes bpfmsgpush_data().

If the BPF program sets corkbytes and sg.size is smaller than corkbytes, it will return -ENOSPC and attempt to roll back to the non-zero copy logic. However, during rollback, msg->msgiter is reset, but since msgpl->sg.size has been increased, subsequent executions will exceed the actual size of msgiter. ''' ioviterrevert(&msg->msgiter, msgpl->sg.size - origsize); '''

The changes in this commit are based on the following considerations:

When cork_bytes is set, rolling back to non-zero copy logic is pointless and can directly go to zero-copy logic.
We can not calculate the correct number of bytes to revert msg_iter.

Assume the original data is "abcdefgh" (8 bytes), and after 3 pushes by the BPF program, it becomes 11-byte data: "abc?de?fgh?". Then, we set corkbytes to 6, which means the first 6 bytes have been processed, and the remaining 5 bytes "?fgh?" will be cached until the length meets the corkbytes requirement.

However, some data in "?fgh?" is not within 'sg->msgiter' (but in msgpl instead), especially the data "?" we pushed.

So it doesn't seem as simple as just reverting through an offset of msg_iter.

For non-TLS sockets in tcpbpfsendmsg, when a "cork" situation occurs, the user-space send() doesn't return an error, and the returned length is the same as the input length parameter, even if some data is cached.

Additionally, I saw that the current non-zero-copy logic for handling corking is written as: ''' line 1177 else if (ret != -EAGAIN) { if (ret == -ENOSPC) ret = 0; goto send_end; '''

So it's ok to just return 'copied' without error when a "cork" situation occurs.(CVE-2025-38166)

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

netfilter: nftsetpipapo: clamp maximum map bucket size to INT_MAX

Otherwise, it is possible to hit WARNONONCE in _kvmallocnodenoprof() when resizing hashtable because _GFP_NOWARN is unset.

Similar to:

b541ba7d1f5a ("netfilter: conntrack: clamp maximum hashtable size to INT_MAX")(CVE-2025-38201)

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

KVM: x86/hyper-v: Skip non-canonical addresses during PV TLB flush

In KVM guests with Hyper-V hypercalls enabled, the hypercalls HVCALLFLUSHVIRTUALADDRESSLIST and HVCALLFLUSHVIRTUALADDRESSLIST_EX allow a guest to request invalidation of portions of a virtual TLB. For this, the hypercall parameter includes a list of GVAs that are supposed to be invalidated.

However, when non-canonical GVAs are passed, there is currently no filtering in place and they are eventually passed to checked invocations of INVVPID on Intel / INVLPGA on AMD. While AMD's INVLPGA silently ignores non-canonical addresses (effectively a no-op), Intel's INVVPID explicitly signals VM-Fail and ultimately triggers the WARNONCE in invvpiderror():

invvpid failed: ext=0x0 vpid=1 gva=0xaaaaaaaaaaaaa000 WARNING: CPU: 6 PID: 326 at arch/x86/kvm/vmx/vmx.c:482 invvpiderror+0x91/0xa0 [kvmintel] Modules linked in: kvmintel kvm 9pnetvirtio irqbypass fuse CPU: 6 UID: 0 PID: 326 Comm: kvm-vm Not tainted 6.15.0 #14 PREEMPT(voluntary) RIP: 0010:invvpiderror+0x91/0xa0 [kvmintel] Call Trace: vmxflushtlbgva+0x320/0x490 [kvmintel] kvmhvvcpuflushtlb+0x24f/0x4f0 [kvm] kvmarchvcpuioctlrun+0x3013/0x5810 [kvm]

Hyper-V documents that invalid GVAs (those that are beyond a partition's GVA space) are to be ignored. While not completely clear whether this ruling also applies to non-canonical GVAs, it is likely fine to make that assumption, and manual testing on Azure confirms "real" Hyper-V interprets the specification in the same way.

Skip non-canonical GVAs when processing the list of address to avoid tripping the INVVPID failure. Alternatively, KVM could filter out "bad" GVAs before inserting into the FIFO, but practically speaking the only downside of pushing validation to the final processing is that doing so is suboptimal for the guest, and no well-behaved guest will request TLB flushes for non-canonical addresses.(CVE-2025-38351)

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

platform/x86: dell-wmi-sysman: Fix WMI data block retrieval in sysfs callbacks

After retrieving WMI data blocks in sysfs callbacks, check for the validity of them before dereferencing their content.(CVE-2025-38412)

In the Linux kernel, the collectmd property of xfrm interfaces can only be set during device creation. However, the xfrmichangelink() function failed to properly validate this when called. This resulted in the erroneous placement of the special interface xi in the xfrminet->xfrmi hash when attempting to modify a collectmd interface. Since it also exists in the xfrminet->collectmd_xfrmi pointer, this led to a double free when the net namespace was taken down, causing a kernel crash.(CVE-2025-38500)

In the Linux kernel, the wxrxbuffer structure contained two DMA address fields: 'dma' and 'pagedma'. However, only 'pagedma' was actually initialized and used to program the Rx descriptor. But 'dma' was uninitialized and used in some paths. This could lead to undefined behavior, including DMA errors or use-after-free, if the uninitialized 'dma' was used. Although such error has not yet occurred, it is worth fixing in the code.(CVE-2025-38533)

In the Linux kernel, the following vulnerability has been resolved: HID: quirks: Add quirk for 2 Chicony Electronics HP 5MP Cameras. The Chicony Electronics HP 5MP Cameras (USB ID 04F2:B824 & 04F2:B82C) report a HID sensor interface that is not actually implemented. Attempting to access this non-functional sensor via iio_info causes system hangs as runtime PM tries to wake up an unresponsive sensor. Add these 2 devices to the HID ignore list since the sensor interface is non-functional by design and should not be exposed to userspace.(CVE-2025-38540)

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

perf/core: Prevent VMA split of buffer mappings

The perf mmap code is careful about mmap()'ing the user page with the ringbuffer and additionally the auxiliary buffer, when the event supports it. Once the first mapping is established, subsequent mapping have to use the same offset and the same size in both cases. The reference counting for the ringbuffer and the auxiliary buffer depends on this being correct.

Though perf does not prevent that a related mapping is split via mmap(2), munmap(2) or mremap(2). A split of a VMA results in perfmmapopen() calls, which take reference counts, but then the subsequent perfmmapclose() calls are not longer fulfilling the offset and size checks. This leads to reference count leaks.

As perf already has the requirement for subsequent mappings to match the initial mapping, the obvious consequence is that VMA splits, caused by resizing of a mapping or partial unmapping, have to be prevented.

Implement the vmoperationsstruct::may_split() callback and return unconditionally -EINVAL.

That ensures that the mapping offsets and sizes cannot be changed after the fact. Remapping to a different fixed address with the same size is still possible as it takes the references for the new mapping and drops those of the old mapping.(CVE-2025-38563)

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

benet: fix BUG when creating VFs

benet crashes as soon as SRIOV VFs are created:

kernel BUG at mm/vmalloc.c:3457! Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI CPU: 4 UID: 0 PID: 7408 Comm: test.sh Kdump: loaded Not tainted 6.16.0+ #1 PREEMPT(voluntary) [...] RIP: 0010:vunmap+0x5f/0x70 [...] Call Trace: <TASK> _iommudmafree+0xe8/0x1c0 becmdsetmaclist+0x3fe/0x640 [be2net] becmdsetmac+0xaf/0x110 [be2net] bevfethaddrconfig+0x19f/0x330 [be2net] bevfsetup+0x4f7/0x990 [be2net] bepcisriovconfigure+0x3a1/0x470 [be2net] sriovnumvfsstore+0x20b/0x380 kernfsfopwriteiter+0x354/0x530 vfswrite+0x9b9/0xf60 ksyswrite+0xf3/0x1d0 dosyscall64+0x8c/0x3d0

becmdsetmaclist() calls dmafreecoherent() under a spinlockbh. Fix it by freeing only after the lock has been released.(CVE-2025-38569)

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

RDMA/hns: Fix double destruction of rsv_qp

rsvqp may be double destroyed in error flow, first in freemrinit(), and then in hnsroceexit(). Fix it by moving the freemrinit() call into hnsrocev2init().

listdel corruption, ffff589732eb9b50->next is LISTPOISON1 (dead000000000100) WARNING: CPU: 8 PID: 1047115 at lib/listdebug.c:53 _listdelentryvalid+0x148/0x240 ... Call trace: _listdelentryvalid+0x148/0x240 hnsroceqpremove+0x4c/0x3f0 [hnsrocehwv2] hnsrocev2destroyqpcommon+0x1dc/0x5f4 [hnsrocehwv2] hnsrocev2destroyqp+0x22c/0x46c [hnsrocehwv2] freemrexit+0x6c/0x120 [hnsrocehwv2] hnsrocev2exit+0x170/0x200 [hnsrocehwv2] hnsroceexit+0x118/0x350 [hnsrocehwv2] _hnsrocehwv2initinstance+0x1c8/0x304 [hnsrocehwv2] hnsrocehwv2resetnotifyinit+0x170/0x21c [hnsrocehwv2] hnsrocehwv2resetnotify+0x6c/0x190 [hnsrocehwv2] hclgenotifyroceclient+0x6c/0x160 [hclge] hclgeresetrebuild+0x150/0x5c0 [hclge] hclgereset+0x10c/0x140 [hclge] hclgeresetsubtask+0x80/0x104 [hclge] hclgeresetservicetask+0x168/0x3ac [hclge] hclgeservicetask+0x50/0x100 [hclge] processonework+0x250/0x9a0 workerthread+0x324/0x990 kthread+0x190/0x210 retfromfork+0x10/0x18(CVE-2025-38582)

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

vmci: Prevent the dispatching of uninitialized payloads

The reproducer executes the host's unlockedioctl call in two different tasks. When initcontext fails, the struct vmcieventctx is not fully initialized when executing vmcidatagramdispatch() to send events to all vm contexts. This affects the datagram taken from the datagram queue of its context by another task, because the datagram payload is not initialized according to the size payload_size, which causes the kernel data to leak to the user space.

Before dispatching the datagram, and before setting the payload content, explicitly set the payload content to 0 to avoid data leakage caused by incomplete payload initialization.(CVE-2025-38611)

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

pinmux: fix race causing muxowner NULL with active muxusecount

commit 5a3e85c3c397 ("pinmux: Use sequential access to access desc->pinmux data") tried to address the issue when two client of the same gpio calls pinctrlselectstate() for the same functionality, was resulting in NULL pointer issue while accessing desc->mux_owner. However, issue was not completely fixed due to the way it was handled and it can still result in the same NULL pointer.

The issue occurs due to the following interleaving:

 cpu0 (process A)                   cpu1 (process B)

  pin_request() {                   pin_free() {

                                     mutex_lock()
                                     desc-&gt;mux_usecount--; //becomes 0
                                     ..
                                     mutex_unlock()

mutexlock(desc->mux) desc->muxusecount++; // becomes 1 desc->muxowner = owner; mutexunlock(desc->mux)

                                     mutex_lock(desc-&gt;mux)
                                     desc-&gt;mux_owner = NULL;
                                     mutex_unlock(desc-&gt;mux)

This sequence leads to a state where the pin appears to be in use (mux_usecount == 1) but has no owner (mux_owner == NULL), which can cause NULL pointer on next pin_request on the same pin.

Ensure that updates to muxusecount and muxowner are performed atomically under the same lock. Only clear muxowner when muxusecount reaches zero and no new owner has been assigned.(CVE-2025-38632)

In the Linux kernel, a vulnerability has been resolved where checking proclseek in the same manner as procreaditer and others could lead to a Use-After-Free (UAF) scenario during rmmod. This was a gap in procregopen() after commit 654b33ada4ab (proc: fix UAF in procget_inode()). Following AI Viro's suggestion, it was fixed in the same manner.(CVE-2025-38653)

In the Linux kernel, a vulnerability was found in the i2c: qup driver where the original logic only sets the return value but does not break out of the loop when the bus remains active due to a client. This unexpected behavior could allow a malicious or faulty i2c client to hang the kernel. The issue was observed during long-term testing with a PCA953x GPIO extender. The fix modifies the logic to not only set the return value but also break out of the loop and return -ETIMEDOUT to the caller.(CVE-2025-38671)

Database specific

{
    "severity": "High"
}

References

Affected packages

openEuler:24.03-LTS / kernel

Package

Name: kernel
Purl: pkg:rpm/openEuler/kernel&distro=openEuler-24.03-LTS

Affected ranges

Type: ECOSYSTEM
Events: Introduced

0Unknown introduced version / All previous versions are affected

Fixed

6.6.0-108.0.0.100.oe2403

Ecosystem specific

{
    "src": [
        "kernel-6.6.0-108.0.0.100.oe2403.src.rpm"
    ],
    "aarch64": [
        "bpftool-6.6.0-108.0.0.100.oe2403.aarch64.rpm",
        "bpftool-debuginfo-6.6.0-108.0.0.100.oe2403.aarch64.rpm",
        "kernel-6.6.0-108.0.0.100.oe2403.aarch64.rpm",
        "kernel-debuginfo-6.6.0-108.0.0.100.oe2403.aarch64.rpm",
        "kernel-debugsource-6.6.0-108.0.0.100.oe2403.aarch64.rpm",
        "kernel-devel-6.6.0-108.0.0.100.oe2403.aarch64.rpm",
        "kernel-headers-6.6.0-108.0.0.100.oe2403.aarch64.rpm",
        "kernel-source-6.6.0-108.0.0.100.oe2403.aarch64.rpm",
        "kernel-tools-6.6.0-108.0.0.100.oe2403.aarch64.rpm",
        "kernel-tools-debuginfo-6.6.0-108.0.0.100.oe2403.aarch64.rpm",
        "kernel-tools-devel-6.6.0-108.0.0.100.oe2403.aarch64.rpm",
        "perf-6.6.0-108.0.0.100.oe2403.aarch64.rpm",
        "perf-debuginfo-6.6.0-108.0.0.100.oe2403.aarch64.rpm",
        "python3-perf-6.6.0-108.0.0.100.oe2403.aarch64.rpm",
        "python3-perf-debuginfo-6.6.0-108.0.0.100.oe2403.aarch64.rpm"
    ],
    "x86_64": [
        "bpftool-6.6.0-108.0.0.100.oe2403.x86_64.rpm",
        "bpftool-debuginfo-6.6.0-108.0.0.100.oe2403.x86_64.rpm",
        "kernel-6.6.0-108.0.0.100.oe2403.x86_64.rpm",
        "kernel-debuginfo-6.6.0-108.0.0.100.oe2403.x86_64.rpm",
        "kernel-debugsource-6.6.0-108.0.0.100.oe2403.x86_64.rpm",
        "kernel-devel-6.6.0-108.0.0.100.oe2403.x86_64.rpm",
        "kernel-headers-6.6.0-108.0.0.100.oe2403.x86_64.rpm",
        "kernel-source-6.6.0-108.0.0.100.oe2403.x86_64.rpm",
        "kernel-tools-6.6.0-108.0.0.100.oe2403.x86_64.rpm",
        "kernel-tools-debuginfo-6.6.0-108.0.0.100.oe2403.x86_64.rpm",
        "kernel-tools-devel-6.6.0-108.0.0.100.oe2403.x86_64.rpm",
        "perf-6.6.0-108.0.0.100.oe2403.x86_64.rpm",
        "perf-debuginfo-6.6.0-108.0.0.100.oe2403.x86_64.rpm",
        "python3-perf-6.6.0-108.0.0.100.oe2403.x86_64.rpm",
        "python3-perf-debuginfo-6.6.0-108.0.0.100.oe2403.x86_64.rpm"
    ]
}