OESA-2025-1963

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

net/sched: act_ct: fix ref leak when switching zones

When switching zones or network namespaces without doing a ct clear in between, it is now leaking a reference to the old ct entry. That's because tcfctskbnfctcached() returns false and tcfctflowtablelookup() may simply overwrite it.

The fix is to, as the ct entry is not reusable, free it already at tcfctskbnfctcached().(CVE-2022-49183)

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

net: annotate races around sk->skbounddev_if

UDP sendmsg() is lockless, and reads sk->skbounddev_if while this field can be changed by another thread.

Adds minimal annotations to avoid KCSAN splats for UDP. Following patches will add more annotations to potential lockless readers.

BUG: KCSAN: data-race in _ip6datagramconnect / udpv6sendmsg

write to 0xffff888136d47a94 of 4 bytes by task 7681 on cpu 0: _ip6datagramconnect+0x6e2/0x930 net/ipv6/datagram.c:221 ip6datagramconnect+0x2a/0x40 net/ipv6/datagram.c:272 inetdgramconnect+0x107/0x190 net/ipv4/afinet.c:576 _sysconnectfile net/socket.c:1900 [inline] _sysconnect+0x197/0x1b0 net/socket.c:1917 _dosysconnect net/socket.c:1927 [inline] _sesysconnect net/socket.c:1924 [inline] _x64sysconnect+0x3d/0x50 net/socket.c:1924 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x2b/0x50 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x44/0xae

read to 0xffff888136d47a94 of 4 bytes by task 7670 on cpu 1: udpv6sendmsg+0xc60/0x16e0 net/ipv6/udp.c:1436 inet6sendmsg+0x5f/0x80 net/ipv6/afinet6.c:652 socksendmsgnosec net/socket.c:705 [inline] socksendmsg net/socket.c:725 [inline] _syssendmsg+0x39a/0x510 net/socket.c:2413 syssendmsg net/socket.c:2467 [inline] _syssendmmsg+0x267/0x4c0 net/socket.c:2553 _dosyssendmmsg net/socket.c:2582 [inline] _sesyssendmmsg net/socket.c:2579 [inline] _x64syssendmmsg+0x53/0x60 net/socket.c:2579 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x2b/0x50 arch/x86/entry/common.c:80 entrySYSCALL64after_hwframe+0x44/0xae

value changed: 0x00000000 -> 0xffffff9b

Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 7670 Comm: syz-executor.3 Tainted: G W 5.18.0-rc1-syzkaller-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011

I chose to not add Fixes: tag because race has minor consequences and stable teams busy enough.(CVE-2022-49420)

A flaw was found within the handling of SMB2 read requests in the kernel ksmbd module. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated buffer. An attacker can leverage this to disclose sensitive information on affected installations of Linux. Only systems with ksmbd enabled are vulnerable to this CVE.(CVE-2023-39179)

A flaw was found within the parsing of extended attributes in the kernel ksmbd module. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated buffer. An attacker can leverage this to disclose sensitive information on affected installations of Linux. Only systems with ksmbd enabled are vulnerable to this CVE.(CVE-2023-4458)

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

drm/dpmst: Ensure mstprimary pointer is valid in drmdpmsthandleup_req()

While receiving an MST up request message from one thread in drmdpmsthandleupreq(), the MST topology could be removed from another thread via drmdpmsttopologymgrsetmst(false), freeing mstprimary and setting drmdpmsttopologymgr::mstprimary to NULL. This could lead to a NULL deref/use-after-free of mstprimary in drmdpmsthandleup_req().

Avoid the above by holding a reference for mstprimary in drmdpmsthandleupreq() while it's used.

v2: Fix kfreeing the request if getting an mst_primary reference fails.(CVE-2024-57798)

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

net: sched: fix ets qdisc OOB Indexing

Haowei Yan <(CVE-2025-21692)

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

net: sched: Disallow replacing of child qdisc from one parent to another

Lion Ackermann was able to create a UAF which can be abused for privilege escalation with the following script

Step 1. create root qdisc tc qdisc add dev lo root handle 1:0 drr

step2. a class for packet aggregation do demonstrate uaf tc class add dev lo classid 1:1 drr

step3. a class for nesting tc class add dev lo classid 1:2 drr

step4. a class to graft qdisc to tc class add dev lo classid 1:3 drr

step5. tc qdisc add dev lo parent 1:1 handle 2:0 plug limit 1024

step6. tc qdisc add dev lo parent 1:2 handle 3:0 drr

step7. tc class add dev lo classid 3:1 drr

step 8. tc qdisc add dev lo parent 3:1 handle 4:0 pfifo

step 9. Display the class/qdisc layout

tc class ls dev lo class drr 1:1 root leaf 2: quantum 64Kb class drr 1:2 root leaf 3: quantum 64Kb class drr 3:1 root leaf 4: quantum 64Kb

tc qdisc ls qdisc drr 1: dev lo root refcnt 2 qdisc plug 2: dev lo parent 1:1 qdisc pfifo 4: dev lo parent 3:1 limit 1000p qdisc drr 3: dev lo parent 1:2

step10. trigger the bug <=== prevented by this patch tc qdisc replace dev lo parent 1:3 handle 4:0

step 11. Redisplay again the qdiscs/classes

tc class ls dev lo class drr 1:1 root leaf 2: quantum 64Kb class drr 1:2 root leaf 3: quantum 64Kb class drr 1:3 root leaf 4: quantum 64Kb class drr 3:1 root leaf 4: quantum 64Kb

tc qdisc ls qdisc drr 1: dev lo root refcnt 2 qdisc plug 2: dev lo parent 1:1 qdisc pfifo 4: dev lo parent 3:1 refcnt 2 limit 1000p qdisc drr 3: dev lo parent 1:2

Observe that a) parent for 4:0 does not change despite the replace request. There can only be one parent. b) refcount has gone up by two for 4:0 and c) both class 1:3 and 3:1 are pointing to it.

Step 12. send one packet to plug echo "" | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10001)) step13. send one packet to the grafted fifo echo "" | socat -u STDIN UDP4-DATAGRAM:127.0.0.1:8888,priority=$((0x10003))

step14. lets trigger the uaf tc class delete dev lo classid 1:3 tc class delete dev lo classid 1:1

The semantics of "replace" is for a del/add on the same node and not a delete from one node(3:1) and add to another node (1:3) as in step10. While we could "fix" with a more complex approach there could be consequences to expectations so the patch takes the preventive approach of "disallow such config".

Joint work with Lion Ackermann <(CVE-2025-21700)

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

pfifotailenqueue: Drop new packet when sch->limit == 0

Expected behaviour: In case we reach scheduler's limit, pfifotailenqueue() will drop a packet in scheduler's queue and decrease scheduler's qlen by one. Then, pfifotailenqueue() enqueue new packet and increase scheduler's qlen by one. Finally, pfifotailenqueue() return NET_XMIT_CN status code.

Weird behaviour: In case we set sch->limit == 0 and trigger pfifotailenqueue() on a scheduler that has no packet, the 'drop a packet' step will do nothing. This means the scheduler's qlen still has value equal 0. Then, we continue to enqueue new packet and increase scheduler's qlen by one. In summary, we can leverage pfifotailenqueue() to increase qlen by one and return NET_XMIT_CN status code.

The problem is: Let's say we have two qdiscs: QdiscA and QdiscB. - QdiscA's type must have '->graft()' function to create parent/child relationship. Let's say QdiscA's type is hfsc. Enqueue packet to this qdisc will trigger hfsc_enqueue. - QdiscB's type is pfifoheaddrop. Enqueue packet to this qdisc will trigger pfifo_tail_enqueue. - QdiscB is configured to have sch->limit == 0. - QdiscA is configured to route the enqueued's packet to QdiscB.

Enqueue packet through QdiscA will lead to: - hfscenqueue(QdiscA) -> pfifotailenqueue(QdiscB) - QdiscB->q.qlen += 1 - pfifotailenqueue() return NET_XMIT_CN - hfscenqueue() check for NET_XMIT_SUCCESS and see NET_XMIT_CN => hfscenqueue() don't increase qlen of QdiscA.

The whole process lead to a situation where QdiscA->q.qlen == 0 and QdiscB->q.qlen == 1. Replace 'hfsc' with other type (for example: 'drr') still lead to the same problem. This violate the design where parent's qlen should equal to the sum of its childrens'qlen.

Bug impact: This issue can be used for user->kernel privilege escalation when it is reachable.(CVE-2025-21702)

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

ipvlan: ensure network headers are in skb linear part

syzbot found that ipvlanprocessv6_outbound() was assuming the IPv6 network header isis present in skb->head [1]

Add the needed pskbnetworkmay_pull() calls for both IPv4 and IPv6 handlers.

[1] BUG: KMSAN: uninit-value in _ipv6addrtype+0xa2/0x490 net/ipv6/addrconfcore.c:47 _ipv6addrtype+0xa2/0x490 net/ipv6/addrconfcore.c:47 ipv6addrtype include/net/ipv6.h:555 [inline] ip6routeoutputflagsnoref net/ipv6/route.c:2616 [inline] ip6routeoutputflags+0x51/0x720 net/ipv6/route.c:2651 ip6routeoutput include/net/ip6route.h:93 [inline] ipvlanroutev6outbound+0x24e/0x520 drivers/net/ipvlan/ipvlancore.c:476 ipvlanprocessv6outbound drivers/net/ipvlan/ipvlancore.c:491 [inline] ipvlanprocessoutbound drivers/net/ipvlan/ipvlancore.c:541 [inline] ipvlanxmitmodel3 drivers/net/ipvlan/ipvlancore.c:605 [inline] ipvlanqueuexmit+0xd72/0x1780 drivers/net/ipvlan/ipvlancore.c:671 ipvlanstartxmit+0x5b/0x210 drivers/net/ipvlan/ipvlanmain.c:223 _netdevstartxmit include/linux/netdevice.h:5150 [inline] netdevstartxmit include/linux/netdevice.h:5159 [inline] xmitone net/core/dev.c:3735 [inline] devhardstartxmit+0x247/0xa20 net/core/dev.c:3751 schdirectxmit+0x399/0xd40 net/sched/schgeneric.c:343 qdiscrestart net/sched/schgeneric.c:408 [inline] _qdiscrun+0x14da/0x35d0 net/sched/schgeneric.c:416 qdiscrun+0x141/0x4d0 include/net/pktsched.h:127 nettxaction+0x78b/0x940 net/core/dev.c:5484 handlesoftirqs+0x1a0/0x7c0 kernel/softirq.c:561 _dosoftirq+0x14/0x1a kernel/softirq.c:595 dosoftirq+0x9a/0x100 kernel/softirq.c:462 _localbhenableip+0x9f/0xb0 kernel/softirq.c:389 localbhenable include/linux/bottomhalf.h:33 [inline] rcureadunlockbh include/linux/rcupdate.h:919 [inline] _devqueuexmit+0x2758/0x57d0 net/core/dev.c:4611 devqueuexmit include/linux/netdevice.h:3311 [inline] packetxmit+0x9c/0x6c0 net/packet/afpacket.c:276 packetsnd net/packet/afpacket.c:3132 [inline] packetsendmsg+0x93e0/0xa7e0 net/packet/afpacket.c:3164 socksendmsg_nosec net/socket.c:718 inline

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

dm: fix unconditional IO throttle caused by REQ_PREFLUSH

When a bio with REQPREFLUSH is submitted to dm, _sendemptyflush() generates a flushbio with REQOPWRITE | REQPREFLUSH | REQSYNC, which causes the flushbio to be throttled by wbt_wait().

An example from v5.4, similar problem also exists in upstream:

crash> bt 2091206
PID: 2091206  TASK: ffff2050df92a300  CPU: 109  COMMAND: "kworker/u260:0"
 #0 [ffff800084a2f7f0] __switch_to at ffff80004008aeb8
 #1 [ffff800084a2f820] __schedule at ffff800040bfa0c4
 #2 [ffff800084a2f880] schedule at ffff800040bfa4b4
 #3 [ffff800084a2f8a0] io_schedule at ffff800040bfa9c4
 #4 [ffff800084a2f8c0] rq_qos_wait at ffff8000405925bc
 #5 [ffff800084a2f940] wbt_wait at ffff8000405bb3a0
 #6 [ffff800084a2f9a0] __rq_qos_throttle at ffff800040592254
 #7 [ffff800084a2f9c0] blk_mq_make_request at ffff80004057cf38
 #8 [ffff800084a2fa60] generic_make_request at ffff800040570138
 #9 [ffff800084a2fae0] submit_bio at ffff8000405703b4
#10 [ffff800084a2fb50] xlog_write_iclog at ffff800001280834 [xfs]
#11 [ffff800084a2fbb0] xlog_sync at ffff800001280c3c [xfs]
#12 [ffff800084a2fbf0] xlog_state_release_iclog at ffff800001280df4 [xfs]
#13 [ffff800084a2fc10] xlog_write at ffff80000128203c [xfs]
#14 [ffff800084a2fcd0] xlog_cil_push at ffff8000012846dc [xfs]
#15 [ffff800084a2fda0] xlog_cil_push_work at ffff800001284a2c [xfs]
#16 [ffff800084a2fdb0] process_one_work at ffff800040111d08
#17 [ffff800084a2fe00] worker_thread at ffff8000401121cc
#18 [ffff800084a2fe70] kthread at ffff800040118de4

After commit 2def2845cc33 ("xfs: don't allow log IO to be throttled"), the metadata submitted by xlogwriteiclog() should not be throttled. But due to the existence of the dm layer, throttling flush_bio indirectly causes the metadata bio to be throttled.

Fix this by conditionally adding REQIDLE to flushbio.biopf, which makes wbtshouldthrottle() return false to avoid wbtwait().(CVE-2025-38063)

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

net: stmmac: make sure that ptp_rate is not 0 before configuring EST

If the ptp_rate recorded earlier in the driver happens to be 0, this bogus value will propagate up to EST configuration, where it will trigger a division by 0.

Prevent this division by 0 by adding the corresponding check and error code.(CVE-2025-38125)

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

calipso: Fix null-ptr-deref in calipsoreq{set,del}attr().

syzkaller reported a null-ptr-deref in sock_omalloc() while allocating a CALIPSO option. [0]

The NULL is of struct sock, which was fetched by sktofullsk() in calipsoreq_setattr().

Since commit a1a5344ddbe8 ("tcp: avoid two atomic ops for syncookies"), reqsk->rsk_listener could be NULL when SYN Cookie is returned to its client, as hinted by the leading SYN Cookie log.

Here are 3 options to fix the bug:

1) Return 0 in calipsoreqsetattr() 2) Return an error in calipsoreqsetattr() 3) Alaways set rsk_listener

1) is no go as it bypasses LSM, but 2) effectively disables SYN Cookie for CALIPSO. 3) is also no go as there have been many efforts to reduce atomic ops and make TCP robust against DDoS. See also commit 3b24d854cb35 ("tcp/dccp: do not touch listener sk_refcnt under synflood").

As of the blamed commit, SYN Cookie already did not need refcounting, and no one has stumbled on the bug for 9 years, so no CALIPSO user will care about SYN Cookie.

Let's return an error in calipsoreqsetattr() and calipsoreqdelattr() in the SYN Cookie case.

This can be reproduced by [1] on Fedora and now connect() of nc times out.

Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037] CPU: 3 UID: 0 PID: 12262 Comm: syz.1.2611 Not tainted 6.14.0 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:readpnet include/net/netnamespace.h:406 [inline] RIP: 0010:socknet include/net/sock.h:655 [inline] RIP: 0010:sockkmalloc+0x35/0x170 net/core/sock.c:2806 Code: 89 d5 41 54 55 89 f5 53 48 89 fb e8 25 e3 c6 fd e8 f0 91 e3 00 48 8d 7b 30 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 26 01 00 00 48 b8 00 00 00 00 00 fc ff df 4c 8b RSP: 0018:ffff88811af89038 EFLAGS: 00010216 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffff888105266400 RDX: 0000000000000006 RSI: ffff88800c890000 RDI: 0000000000000030 RBP: 0000000000000050 R08: 0000000000000000 R09: ffff88810526640e R10: ffffed1020a4cc81 R11: ffff88810526640f R12: 0000000000000000 R13: 0000000000000820 R14: ffff888105266400 R15: 0000000000000050 FS: 00007f0653a07640(0000) GS:ffff88811af80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f863ba096f4 CR3: 00000000163c0005 CR4: 0000000000770ef0 PKRU: 80000000 Call Trace: <IRQ> ipv6renewoptions+0x279/0x950 net/ipv6/exthdrs.c:1288 calipsoreqsetattr+0x181/0x340 net/ipv6/calipso.c:1204 calipsoreqsetattr+0x56/0x80 net/netlabel/netlabelcalipso.c:597 netlblreqsetattr+0x18a/0x440 net/netlabel/netlabelkapi.c:1249 selinuxnetlblinetconnrequest+0x1fb/0x320 security/selinux/netlabel.c:342 selinuxinetconnrequest+0x1eb/0x2c0 security/selinux/hooks.c:5551 securityinetconnrequest+0x50/0xa0 security/security.c:4945 tcpv6routereq+0x22c/0x550 net/ipv6/tcpipv6.c:825 tcpconnrequest+0xec8/0x2b70 net/ipv4/tcpinput.c:7275 tcpv6connrequest+0x1e3/0x440 net/ipv6/tcpipv6.c:1328 tcprcvstateprocess+0xafa/0x52b0 net/ipv4/tcpinput.c:6781 tcpv6dorcv+0x8a6/0x1a40 net/ipv6/tcpipv6.c:1667 tcpv6rcv+0x505e/0x5b50 net/ipv6/tcpipv6.c:1904 ip6protocoldeliverrcu+0x17c/0x1da0 net/ipv6/ip6input.c:436 ip6inputfinish+0x103/0x180 net/ipv6/ip6input.c:480 NFHOOK include/linux/netfilter.h:314 [inline] NFHOOK include/linux/netfilter.h:308 [inline] ip6input+0x13c/0x6b0 net/ipv6/ip6input.c:491 dstinput include/net/dst.h:469 [inline] ip6rcvfinish net/ipv6/ip6input.c:79 [inline] ip6rcvfinish+0xb6/0x490 net/ipv6/ip6input.c:69 NFHOOK include/linux/netfilter.h:314 [inline] NFHOOK include/linux/netf ---truncated---(CVE-2025-38181)

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

ext4: inline: fix len overflow in ext4prepareinline_data

When running the following code on an ext4 filesystem with inline_data feature enabled, it will lead to the bug below.

    fd = open("file1", O_RDWR | O_CREAT | O_TRUNC, 0666);
    ftruncate(fd, 30);
    pwrite(fd, "a", 1, (1UL << 40) + 5UL);

That happens because writebegin will succeed as when ext4genericwriteinlinedata calls ext4prepareinlinedata, pos + len will be truncated, leading to ext4prepareinline_data parameter to be 6 instead of 0x10000000006.

Then, later when write_end is called, we hit:

    BUG_ON(pos + len > EXT4_I(inode)->i_inline_size);

at ext4writeinline_data.

Fix it by using a lofft type for the len parameter in ext4prepareinlinedata instead of an unsigned int.

[ 44.545164] ------------[ cut here ]------------ [ 44.545530] kernel BUG at fs/ext4/inline.c:240! [ 44.545834] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 44.546172] CPU: 3 UID: 0 PID: 343 Comm: test Not tainted 6.15.0-rc2-00003-g9080916f4863 #45 PREEMPT(full) 112853fcebfdb93254270a7959841d2c6aa2c8bb [ 44.546523] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 44.546523] RIP: 0010:ext4writeinlinedata+0xfe/0x100 [ 44.546523] Code: 3c 0e 48 83 c7 48 48 89 de 5b 41 5c 41 5d 41 5e 41 5f 5d e9 e4 fa 43 01 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc 0f 0b <0f> 0b 0f 1f 44 00 00 55 41 57 41 56 41 55 41 54 53 48 83 ec 20 49 [ 44.546523] RSP: 0018:ffffb342008b79a8 EFLAGS: 00010216 [ 44.546523] RAX: 0000000000000001 RBX: ffff9329c579c000 RCX: 0000010000000006 [ 44.546523] RDX: 000000000000003c RSI: ffffb342008b79f0 RDI: ffff9329c158e738 [ 44.546523] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000 [ 44.546523] R10: 00007ffffffff000 R11: ffffffff9bd0d910 R12: 0000006210000000 [ 44.546523] R13: fffffc7e4015e700 R14: 0000010000000005 R15: ffff9329c158e738 [ 44.546523] FS: 00007f4299934740(0000) GS:ffff932a60179000(0000) knlGS:0000000000000000 [ 44.546523] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 44.546523] CR2: 00007f4299a1ec90 CR3: 0000000002886002 CR4: 0000000000770eb0 [ 44.546523] PKRU: 55555554 [ 44.546523] Call Trace: [ 44.546523] <TASK> [ 44.546523] ext4writeinlinedataend+0x126/0x2d0 [ 44.546523] genericperformwrite+0x17e/0x270 [ 44.546523] ext4bufferedwriteiter+0xc8/0x170 [ 44.546523] vfswrite+0x2be/0x3e0 [ 44.546523] x64syspwrite64+0x6d/0xc0 [ 44.546523] dosyscall64+0x6a/0xf0 [ 44.546523] ? _wakeup+0x89/0xb0 [ 44.546523] ? xasfind+0x72/0x1c0 [ 44.546523] ? nextuptodatefolio+0x317/0x330 [ 44.546523] ? setpterange+0x1a6/0x270 [ 44.546523] ? filemapmappages+0x6ee/0x840 [ 44.546523] ? ext4setattr+0x2fa/0x750 [ 44.546523] ? doptemissing+0x128/0xf70 [ 44.546523] ? securityinodepostsetattr+0x3e/0xd0 [ 44.546523] ? pteoffsetmap+0x19/0x100 [ 44.546523] ? handlemmfault+0x721/0xa10 [ 44.546523] ? douseraddrfault+0x197/0x730 [ 44.546523] ? dosyscall64+0x76/0xf0 [ 44.546523] ? archexittousermodeprepare+0x1e/0x60 [ 44.546523] ? irqentryexittousermode+0x79/0x90 [ 44.546523] entrySYSCALL64afterhwframe+0x55/0x5d [ 44.546523] RIP: 0033:0x7f42999c6687 [ 44.546523] Code: 48 89 fa 4c 89 df e8 58 b3 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 fa 08 75 de e8 23 ff ff ff [ 44.546523] RSP: 002b:00007ffeae4a7930 EFLAGS: 00000202 ORIGRAX: 0000000000000012 [ 44.546523] RAX: ffffffffffffffda RBX: 00007f4299934740 RCX: 00007f42999c6687 [ 44.546523] RDX: 0000000000000001 RSI: 000055ea6149200f RDI: 0000000000000003 [ 44.546523] RBP: 00007ffeae4a79a0 R08: 0000000000000000 R09: 0000000000000000 [ 44.546523] R10: 0000010000000005 R11: 0000000000000202 R12: 0000 ---truncated---(CVE-2025-38222)

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

scsi: lpfc: Use memcpy() for BIOS version

The strlcat() with FORTIFY support is triggering a panic because it thinks the target buffer will overflow although the correct target buffer size is passed in.

Anyway, instead of memset() with 0 followed by a strlcat(), just use memcpy() and ensure that the resulting buffer is NULL terminated.

BIOSVersion is only used for the lpfcprintflog() which expects a properly terminated string.(CVE-2025-38332)

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

drm/amd/display: Add null pointer check for getfirstactive_display()

The function modhdcphdcp1enableencryption() calls the function getfirstactivedisplay(), but does not check its return value. The return value is a null pointer if the display list is empty. This will lead to a null pointer dereference in modhdcphdcp2enable_encryption().

Add a null pointer check for getfirstactivedisplay() and return MODHDCPSTATUSDISPLAYNOTFOUND if the function return null.(CVE-2025-38362)

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

drm/v3d: Disable interrupts before resetting the GPU

Currently, an interrupt can be triggered during a GPU reset, which can lead to GPU hangs and NULL pointer dereference in an interrupt context as shown in the following trace:

[ 314.035040] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000c0 [ 314.043822] Mem abort info: [ 314.046606] ESR = 0x0000000096000005 [ 314.050347] EC = 0x25: DABT (current EL), IL = 32 bits [ 314.055651] SET = 0, FnV = 0 [ 314.058695] EA = 0, S1PTW = 0 [ 314.061826] FSC = 0x05: level 1 translation fault [ 314.066694] Data abort info: [ 314.069564] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 314.075039] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 314.080080] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 314.085382] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000102728000 [ 314.091814] [00000000000000c0] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 314.100511] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP [ 314.106770] Modules linked in: v3d i2cbrcmstb vc4 sndsochdmicodec gpusched drmshmemhelper drmdisplayhelper cec drmdmahelper drmkmshelper drm drmpanelorientationquirks sndsoccore sndcompress sndpcmdmaengine sndpcm sndtimer snd backlight [ 314.129654] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.25+rpt-rpi-v8 #1 Debian 1:6.12.25-1+rpt1 [ 314.139388] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT) [ 314.145211] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 314.152165] pc : v3dirq+0xec/0x2e0 [v3d] [ 314.156187] lr : v3dirq+0xe0/0x2e0 [v3d] [ 314.160198] sp : ffffffc080003ea0 [ 314.163502] x29: ffffffc080003ea0 x28: ffffffec1f184980 x27: 021202b000000000 [ 314.170633] x26: ffffffec1f17f630 x25: ffffff8101372000 x24: ffffffec1f17d9f0 [ 314.177764] x23: 000000000000002a x22: 000000000000002a x21: ffffff8103252000 [ 314.184895] x20: 0000000000000001 x19: 00000000deadbeef x18: 0000000000000000 [ 314.192026] x17: ffffff94e51d2000 x16: ffffffec1dac3cb0 x15: c306000000000000 [ 314.199156] x14: 0000000000000000 x13: b2fc982e03cc5168 x12: 0000000000000001 [ 314.206286] x11: ffffff8103f8bcc0 x10: ffffffec1f196868 x9 : ffffffec1dac3874 [ 314.213416] x8 : 0000000000000000 x7 : 0000000000042a3a x6 : ffffff810017a180 [ 314.220547] x5 : ffffffec1ebad400 x4 : ffffffec1ebad320 x3 : 00000000000bebeb [ 314.227677] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 314.234807] Call trace: [ 314.237243] v3dirq+0xec/0x2e0 [v3d] [ 314.240906] _handleirqeventpercpu+0x58/0x218 [ 314.245609] handleirqevent+0x54/0xb8 [ 314.249439] handlefasteoiirq+0xac/0x240 [ 314.253527] handleirqdesc+0x48/0x68 [ 314.257269] generichandledomainirq+0x24/0x38 [ 314.261879] gichandleirq+0x48/0xd8 [ 314.265533] callonirqstack+0x24/0x58 [ 314.269448] dointerrupthandler+0x88/0x98 [ 314.273624] el1interrupt+0x34/0x68 [ 314.277193] el1h64irqhandler+0x18/0x28 [ 314.281281] el1h64irq+0x64/0x68 [ 314.284673] defaultidlecall+0x3c/0x168 [ 314.288675] doidle+0x1fc/0x230 [ 314.291895] cpustartupentry+0x3c/0x50 [ 314.295810] restinit+0xe4/0xf0 [ 314.299030] startkernel+0x5e8/0x790 [ 314.302684] _primaryswitched+0x80/0x90 [ 314.306691] Code: 940029eb 360ffc13 f9442ea0 52800001 (f9406017) [ 314.312775] ---[ end trace 0000000000000000 ]--- [ 314.317384] Kernel panic - not syncing: Oops: Fatal exception in interrupt [ 314.324249] SMP: stopping secondary CPUs [ 314.328167] Kernel Offset: 0x2b9da00000 from 0xffffffc080000000 [ 314.334076] PHYSOFFSET: 0x0 [ 314.336946] CPU features: 0x08,00002013,c0200000,0200421b [ 314.342337] Memory Limit: none [ 314.345382] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---

Before resetting the G ---truncated---(CVE-2025-38371)

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

ACPICA: Refuse to evaluate a method if arguments are missing

As reported in [1], a platform firmware update that increased the number of method parameters and forgot to update a least one of its callers, caused ACPICA to crash due to use-after-free.

Since this a result of a clear AML issue that arguably cannot be fixed up by the interpreter (it cannot produce missing data out of thin air), address it by making ACPICA refuse to evaluate a method if the caller attempts to pass fewer arguments than expected to it.(CVE-2025-38386)

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

RDMA/mlx5: Initialize objevent->objsublist before xainsert

The objevent may be loaded immediately after inserted, then if the listhead is not initialized then we may get a poisonous pointer. This fixes the crash below:

mlx5core 0000:03:00.0: MLX5E: StrdRq(1) RqSz(8) StrdSz(2048) RxCqeCmprss(0 enhanced) mlx5core.sf mlx5core.sf.4: firmware version: 32.38.3056 mlx5core 0000:03:00.0 en3f0pf0sf2002: renamed from eth0 mlx5core.sf mlx5core.sf.4: Rate limit: 127 rates are supported, range: 0Mbps to 195312Mbps IPv6: ADDRCONF(NETDEVCHANGE): en3f0pf0sf2002: link becomes ready Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060 Mem abort info: ESR = 0x96000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000007760fb000 [0000000000000060] pgd=000000076f6d7003, p4d=000000076f6d7003, pud=0000000777841003, pmd=0000000000000000 Internal error: Oops: 96000006 [#1] SMP Modules linked in: ipmbhost(OE) actmirred(E) clsflower(E) schingress(E) mptcpdiag(E) udpdiag(E) rawdiag(E) unixdiag(E) tcpdiag(E) inetdiag(E) binfmtmisc(E) bonding(OE) rdmaucm(OE) rdmacm(OE) iwcm(OE) ibipoib(OE) ibcm(OE) isofs(E) cdrom(E) mstpciconf(OE) ibumad(OE) mlx5ib(OE) ipmbdevint(OE) mlx5core(OE) kpatch15237886(OEK) mlxdevm(OE) auxiliary(OE) ibuverbs(OE) ibcore(OE) psample(E) mlxfw(OE) tls(E) sunrpc(E) vfat(E) fat(E) crct10difce(E) ghashce(E) sha1ce(E) sbsagwdt(E) virtioconsole(E) ext4(E) mbcache(E) jbd2(E) xfs(E) libcrc32c(E) mmcblock(E) virtionet(E) netfailover(E) failover(E) sha2ce(E) sha256arm64(E) nvme(OE) nvmecore(OE) gpiomlxbf3(OE) mlxcompat(OE) mlxbfpmc(OE) i2cmlxbf(OE) sdhciofdwcmshc(OE) pinctrlmlxbf3(OE) mlxbfpka(OE) gpiogeneric(E) i2ccore(E) mmccore(E) mlxbfgige(OE) vitesse(E) pwrmlxbf(OE) mlxbftmfifo(OE) micrel(E) mlxbfbootctl(OE) virtioring(E) virtio(E) ipmidevintf(E) ipmimsghandler(E) [last unloaded: mstpci] CPU: 11 PID: 20913 Comm: rte-worker-11 Kdump: loaded Tainted: G OE K 5.10.134-13.1.an8.aarch64 #1 Hardware name: https://www.mellanox.com BlueField-3 SmartNIC Main Card/BlueField-3 SmartNIC Main Card, BIOS 4.2.2.12968 Oct 26 2023 pstate: a0400089 (NzCv daIf +PAN -UAO -TCO BTYPE=--) pc : dispatcheventfd+0x68/0x300 [mlx5ib] lr : devxeventnotifier+0xcc/0x228 [mlx5ib] sp : ffff80001005bcf0 x29: ffff80001005bcf0 x28: 0000000000000001 x27: ffff244e0740a1d8 x26: ffff244e0740a1d0 x25: ffffda56beff5ae0 x24: ffffda56bf911618 x23: ffff244e0596a480 x22: ffff244e0596a480 x21: ffff244d8312ad90 x20: ffff244e0596a480 x19: fffffffffffffff0 x18: 0000000000000000 x17: 0000000000000000 x16: ffffda56be66d620 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000040 x10: ffffda56bfcafb50 x9 : ffffda5655c25f2c x8 : 0000000000000010 x7 : 0000000000000000 x6 : ffff24545a2e24b8 x5 : 0000000000000003 x4 : ffff80001005bd28 x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff244e0596a480 x0 : ffff244d8312ad90 Call trace: dispatcheventfd+0x68/0x300 [mlx5ib] devxeventnotifier+0xcc/0x228 [mlx5ib] atomicnotifiercallchain+0x58/0x80 mlx5eqasyncint+0x148/0x2b0 [mlx5core] atomicnotifiercallchain+0x58/0x80 irqinthandler+0x20/0x30 [mlx5core] _handleirqeventpercpu+0x60/0x220 handleirqeventpercpu+0x3c/0x90 handleirqevent+0x58/0x158 handlefasteoiirq+0xfc/0x188 generichandleirq+0x34/0x48 ...(CVE-2025-38387)

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

nfs: Clean up /proc/net/rpc/nfs when nfsfsprocnetinit() fails.

syzbot reported a warning below [1] following a fault injection in nfsfsprocnetinit(). [0]

When nfsfsprocnetinit() fails, /proc/net/rpc/nfs is not removed.

Later, rpcprocexit() tries to remove /proc/net/rpc, and the warning is logged as the directory is not empty.

Let's handle the error of nfsfsprocnetinit() properly.

name failslab, interval 1, probability 0, space 0, times 0 CPU: 1 UID: 0 PID: 6120 Comm: syz.2.27 Not tainted 6.16.0-rc1-syzkaller-00010-g2c4a1f3fe03e #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Call Trace: <TASK> dumpstacklvl (lib/dumpstack.c:123) shouldfailex (lib/fault-inject.c:73 lib/fault-inject.c:174) shouldfailslab (mm/failslab.c:46) kmemcacheallocnoprof (mm/slub.c:4178 mm/slub.c:4204) _proccreate (fs/proc/generic.c:427) proccreatereg (fs/proc/generic.c:554) proccreatenetdata (fs/proc/procnet.c:120) nfsfsprocnetinit (fs/nfs/client.c:1409) nfsnetinit (fs/nfs/inode.c:2600) opsinit (net/core/netnamespace.c:138) setupnet (net/core/netnamespace.c:443) copynetns (net/core/netnamespace.c:576) createnewnamespaces (kernel/nsproxy.c:110) unsharensproxynamespaces (kernel/nsproxy.c:218 (discriminator 4)) ksysunshare (kernel/fork.c:3123) _x64sysunshare (kernel/fork.c:3190) dosyscall64 (arch/x86/entry/syscall64.c:63 arch/x86/entry/syscall64.c:94) entrySYSCALL64afterhwframe (arch/x86/entry/entry_64.S:130) </TASK>

WARNING: CPU: 1 PID: 6120 at fs/proc/generic.c:727 removeprocentry+0x45e/0x530 fs/proc/generic.c:727 Modules linked in: CPU: 1 UID: 0 PID: 6120 Comm: syz.2.27 Not tainted 6.16.0-rc1-syzkaller-00010-g2c4a1f3fe03e #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 RIP: 0010:removeprocentry+0x45e/0x530 fs/proc/generic.c:727 Code: 3c 02 00 0f 85 85 00 00 00 48 8b 93 d8 00 00 00 4d 89 f0 4c 89 e9 48 c7 c6 40 ba a2 8b 48 c7 c7 60 b9 a2 8b e8 33 81 1d ff 90 <0f> 0b 90 90 e9 5f fe ff ff e8 04 69 5e ff 90 48 b8 00 00 00 00 00 RSP: 0018:ffffc90003637b08 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff88805f534140 RCX: ffffffff817a92c8 RDX: ffff88807da99e00 RSI: ffffffff817a92d5 RDI: 0000000000000001 RBP: ffff888033431ac0 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000001 R12: ffff888033431a00 R13: ffff888033431ae4 R14: ffff888033184724 R15: dffffc0000000000 FS: 0000555580328500(0000) GS:ffff888124a62000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f71733743e0 CR3: 000000007f618000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> sunrpcexitnet+0x46/0x90 net/sunrpc/sunrpcsyms.c:76 opsexitlist net/core/netnamespace.c:200 [inline] opsundolist+0x2eb/0xab0 net/core/netnamespace.c:253 setupnet+0x2e1/0x510 net/core/netnamespace.c:457 copynetns+0x2a6/0x5f0 net/core/netnamespace.c:574 createnewnamespaces+0x3ea/0xa90 kernel/nsproxy.c:110 unsharensproxynamespaces+0xc0/0x1f0 kernel/nsproxy.c:218 ksysunshare+0x45b/0xa40 kernel/fork.c:3121 _dosysunshare kernel/fork.c:3192 [inline] _sesysunshare kernel/fork.c:3190 [inline] _x64sysunshare+0x31/0x40 kernel/fork.c:3190 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xcd/0x490 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7fa1a6b8e929 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c ---truncated---(CVE-2025-38400)

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

perf: Fix sample vs do_exit()

Baisheng Gao reported an ARM64 crash, which Mark decoded as being a synchronous external abort -- most likely due to trying to access MMIO in bad ways.

The crash further shows perf trying to do a user stack sample while in exitmmap()'s tlbfinish_mmu() -- i.e. while tearing down the address space it is trying to access.

It turns out that we stop perf after we tear down the userspace mm; a receipie for disaster, since perf likes to access userspace for various reasons.

Flip this order by moving up where we stop perf in do_exit().

Additionally, harden PERFSAMPLECALLCHAIN and PERFSAMPLESTACKUSER to abort when the current task does not have an mm (exitmm() makes sure to set current->mm = NULL; before commencing with the actual teardown). Such that CPU wide events don't trip on this same problem.(CVE-2025-38424)

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

bnxten: Set DMA unmap len correctly for XDPREDIRECT

When transmitting an XDPREDIRECT packet, call dmaunmaplenset() with the proper length instead of 0. This bug triggers this warning on a system with IOMMU enabled:

WARNING: CPU: 36 PID: 0 at drivers/iommu/dma-iommu.c:842 iommudmaunmap+0x159/0x170 RIP: 0010:iommudmaunmap+0x159/0x170 Code: a8 00 00 00 00 48 c7 45 b0 00 00 00 00 48 c7 45 c8 00 00 00 00 48 c7 45 a0 ff ff ff ff 4c 89 45 b8 4c 89 45 c0 e9 77 ff ff ff <0f> 0b e9 60 ff ff ff e8 8b bf 6a 00 66 66 2e 0f 1f 84 00 00 00 00 RSP: 0018:ff22d31181150c88 EFLAGS: 00010206 RAX: 0000000000002000 RBX: 00000000e13a0000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ff22d31181150cf0 R08: ff22d31181150ca8 R09: 0000000000000000 R10: 0000000000000000 R11: ff22d311d36c9d80 R12: 0000000000001000 R13: ff13544d10645010 R14: ff22d31181150c90 R15: ff13544d0b2bac00 FS: 0000000000000000(0000) GS:ff13550908a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005be909dacff8 CR3: 0008000173408003 CR4: 0000000000f71ef0 PKRU: 55555554 Call Trace: <IRQ> ? showregs+0x6d/0x80 ? _warn+0x89/0x160 ? _iommudmaunmap+0x159/0x170 ? reportbug+0x17e/0x1b0 ? handlebug+0x46/0x90 ? excinvalidop+0x18/0x80 ? asmexcinvalidop+0x1b/0x20 ? _iommudmaunmap+0x159/0x170 ? _iommudmaunmap+0xb3/0x170 iommudmaunmappage+0x4f/0x100 dmaunmappageattrs+0x52/0x220 ? srsoaliasreturnthunk+0x5/0xfbef5 ? xdpreturnframe+0x2e/0xd0 bnxttxintxdp+0xdf/0x440 [bnxten] _bnxtpollworkdone+0x81/0x1e0 [bnxten] bnxtpoll+0xd3/0x1e0 bnxten

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

usb: net: sierra: check for no status endpoint

The driver checks for having three endpoints and having bulk in and out endpoints, but not that the third endpoint is interrupt input. Rectify the omission.(CVE-2025-38474)

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

dochangetype(): refuse to operate on unmounted/not ours mounts

Ensure that propagation settings can only be changed for mounts located in the caller's mount namespace. This change aligns permission checking with the rest of mount(2).(CVE-2025-38498)