The Linux Kernel, the operating system core itself.

Security Fix(es):

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

xfrm: state: fix out-of-bounds read during lookup

lookup and resize can run in parallel.

The xfrmstatehash_generation seqlock ensures a retry, but the hash functions can observe a hmask value that is too large for the new hlist array.

rehash does: rcuassignpointer(net->xfrm.statebydst, ndst) [..] net->xfrm.statehmask = nhashmask;

While state lookup does: h = xfrmdsthash(net, daddr, saddr, tmpl->reqid, encapfamily); hlistforeachentryrcu(x, net->xfrm.statebydst + h, bydst) {

This is only safe in case the update to statebydst is larger than net->xfrm.xfrmstate_hmask (or if the lookup function gets serialized via state spinlock again).

Fix this by prefetching statehmask and the associated pointers. The xfrmstatehashgeneration seqlock retry will ensure that the pointer and the hmask will be consistent.

The existing helpers, like xfrmdsthash(), are now unsafe for RCU side, add lockdep assertions to document that they are only safe for insert side.

xfrmstatelookup_byaddr() uses the spinlock rather than RCU. AFAICS this is an oversight from back when state lookup was converted to RCU, this lock should be replaced with RCU in a future patch.(CVE-2024-57982)

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

eth: bnxt: always recalculate features after XDP clearing, fix null-deref

Recalculate features when XDP is detached.

Before: # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp # ip li set dev eth0 xdp off # ethtool -k eth0 | grep gro rx-gro-hw: off [requested on]

After: # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp # ip li set dev eth0 xdp off # ethtool -k eth0 | grep gro rx-gro-hw: on

The fact that HW-GRO doesn't get re-enabled automatically is just a minor annoyance. The real issue is that the features will randomly come back during another reconfiguration which just happens to invoke netdevupdatefeatures(). The driver doesn't handle reconfiguring two things at a time very robustly.

Starting with commit 98ba1d931f61 ("bnxten: Fix RSS logic in _bnxtreserverings()") we only reconfigure the RSS hash table if the "effective" number of Rx rings has changed. If HW-GRO is enabled "effective" number of rings is 2x what user sees. So if we are in the bad state, with HW-GRO re-enablement "pending" after XDP off, and we lower the rings by / 2 - the HW-GRO rings doing 2x and the ethtool -L doing / 2 may cancel each other out, and the:

if (oldrxrings != bp->hwresc.resvrx_rings &&

condition in _bnxtreserve_rings() will be false. The RSS map won't get updated, and we'll crash with:

BUG: kernel NULL pointer dereference, address: 0000000000000168 RIP: 0010:_bnxthwrmvnicsetrss+0x13a/0x1a0 bnxthwrmvnicrsscfgp5+0x47/0x180 _bnxtsetupvnicp5+0x58/0x110 bnxtinitnic+0xb72/0xf50 _bnxtopennic+0x40d/0xab0 bnxtopennic+0x2b/0x60 ethtoolset_channels+0x18c/0x1d0

As we try to access a freed ring.

The issue is present since XDP support was added, really, but prior to commit 98ba1d931f61 ("bnxten: Fix RSS logic in _bnxtreserverings()") it wasn't causing major issues.(CVE-2025-21682)

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

net: better track kernel sockets lifetime

While kernel sockets are dismantled during pernetoperations->exit(), their freeing can be delayed by any tx packets still held in qdisc or device queues, due to skbsetownerw() prior calls.

This then trigger the following warning from reftrackerdir_exit() [1]

To fix this, make sure that kernel sockets own a reference on net->passive.

Add sknetrefcnt_upgrade() helper, used whenever a kernel socket is converted to a refcounted one.

[1]

[ 136.263918][ T35] reftracker: net notrefcnt@ffff8880638f01e0 has 1/2 users at [ 136.263918][ T35] skalloc+0x2b3/0x370 [ 136.263918][ T35] inet6create+0x6ce/0x10f0 [ 136.263918][ T35] _sockcreate+0x4c0/0xa30 [ 136.263918][ T35] inetctlsockcreate+0xc2/0x250 [ 136.263918][ T35] igmp6netinit+0x39/0x390 [ 136.263918][ T35] opsinit+0x31e/0x590 [ 136.263918][ T35] setupnet+0x287/0x9e0 [ 136.263918][ T35] copynetns+0x33f/0x570 [ 136.263918][ T35] createnewnamespaces+0x425/0x7b0 [ 136.263918][ T35] unsharensproxynamespaces+0x124/0x180 [ 136.263918][ T35] ksysunshare+0x57d/0xa70 [ 136.263918][ T35] _x64sysunshare+0x38/0x40 [ 136.263918][ T35] dosyscall64+0xf3/0x230 [ 136.263918][ T35] entrySYSCALL64afterhwframe+0x77/0x7f [ 136.263918][ T35] [ 136.343488][ T35] reftracker: net notrefcnt@ffff8880638f01e0 has 1/2 users at [ 136.343488][ T35] skalloc+0x2b3/0x370 [ 136.343488][ T35] inet6create+0x6ce/0x10f0 [ 136.343488][ T35] _sockcreate+0x4c0/0xa30 [ 136.343488][ T35] inetctlsockcreate+0xc2/0x250 [ 136.343488][ T35] ndiscnetinit+0xa7/0x2b0 [ 136.343488][ T35] opsinit+0x31e/0x590 [ 136.343488][ T35] setupnet+0x287/0x9e0 [ 136.343488][ T35] copynetns+0x33f/0x570 [ 136.343488][ T35] createnewnamespaces+0x425/0x7b0 [ 136.343488][ T35] unsharensproxynamespaces+0x124/0x180 [ 136.343488][ T35] ksysunshare+0x57d/0xa70 [ 136.343488][ T35] _x64sysunshare+0x38/0x40 [ 136.343488][ T35] dosyscall64+0xf3/0x230 [ 136.343488][ T35] entrySYSCALL64afterhwframe+0x77/0x7f(CVE-2025-21884)

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:

KVM: SVM: Forcibly leave SMM mode on SHUTDOWN interception

Previously, commit ed129ec9057f ("KVM: x86: forcibly leave nested mode on vCPU reset") addressed an issue where a triple fault occurring in nested mode could lead to use-after-free scenarios. However, the commit did not handle the analogous situation for System Management Mode (SMM).

This omission results in triggering a WARN when KVM forces a vCPU INIT after SHUTDOWN interception while the vCPU is in SMM. This situation was reprodused using Syzkaller by:

1) Creating a KVM VM and vCPU 2) Sending a KVM_SMI ioctl to explicitly enter SMM 3) Executing invalid instructions causing consecutive exceptions and eventually a triple fault

The issue manifests as follows:

WARNING: CPU: 0 PID: 25506 at arch/x86/kvm/x86.c:12112 kvmvcpureset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112 Modules linked in: CPU: 0 PID: 25506 Comm: syz-executor.0 Not tainted 6.1.130-syzkaller-00157-g164fe5dde9b6 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:kvmvcpureset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112 Call Trace: <TASK> shutdowninterception+0x66/0xb0 arch/x86/kvm/svm/svm.c:2136 svminvokeexithandler+0x110/0x530 arch/x86/kvm/svm/svm.c:3395 svmhandleexit+0x424/0x920 arch/x86/kvm/svm/svm.c:3457 vcpuenterguest arch/x86/kvm/x86.c:10959 [inline] vcpurun+0x2c43/0x5a90 arch/x86/kvm/x86.c:11062 kvmarchvcpuioctlrun+0x50f/0x1cf0 arch/x86/kvm/x86.c:11283 kvmvcpuioctl+0x570/0xf00 arch/x86/kvm/../../../virt/kvm/kvmmain.c:4122 vfsioctl fs/ioctl.c:51 [inline] _dosysioctl fs/ioctl.c:870 [inline] _sesysioctl fs/ioctl.c:856 [inline] _x64sysioctl+0x19a/0x210 fs/ioctl.c:856 dosyscallx64 arch/x86/entry/common.c:51 [inline] dosyscall64+0x35/0x80 arch/x86/entry/common.c:81 entrySYSCALL64afterhwframe+0x6e/0xd8

Architecturally, INIT is blocked when the CPU is in SMM, hence KVM's WARN() in kvmvcpureset() to guard against KVM bugs, e.g. to detect improper emulation of INIT. SHUTDOWN on SVM is a weird edge case where KVM needs to do something sane with the VMCB, since it's technically undefined, and INIT is the least awful choice given KVM's ABI.

So, double down on stuffing INIT on SHUTDOWN, and force the vCPU out of SMM to avoid any weirdness (and the WARN).

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

sean: massage changelog, make it clear this isn't architectural behavior

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

netsched: Flush gsoskb list too during ->change()

Previously, when reducing a qdisc's limit via the ->change() operation, only the main skb queue was trimmed, potentially leaving packets in the gso_skb list. This could result in NULL pointer dereference when we only check sch->limit against sch->q.qlen.

This patch introduces a new helper, qdiscdequeueinternal(), which ensures both the gsoskb list and the main queue are properly flushed when trimming excess packets. All relevant qdiscs (codel, fq, fqcodel, fq_pie, hhf, pie) are updated to use this helper in their ->change() routines.(CVE-2025-37992)

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

serial: mctrlgpio: split disablems into sync and no_sync APIs

The following splat has been observed on a SAMA5D27 platform using atmel_serial:

BUG: sleeping function called from invalid context at kernel/irq/manage.c:738 inatomic(): 1, irqsdisabled(): 128, nonblock: 0, pid: 27, name: kworker/u5:0 preemptcount: 1, expected: 0 INFO: lockdep is turned off. irq event stamp: 0 hardirqs last enabled at (0): [<00000000>] 0x0 hardirqs last disabled at (0): [<c01588f0>] copyprocess+0x1c4c/0x7bec softirqs last enabled at (0): [<c0158944>] copyprocess+0x1ca0/0x7bec softirqs last disabled at (0): [<00000000>] 0x0 CPU: 0 UID: 0 PID: 27 Comm: kworker/u5:0 Not tainted 6.13.0-rc7+ #74 Hardware name: Atmel SAMA5 Workqueue: hci0 hcipoweron [bluetooth] Call trace: unwindbacktrace from showstack+0x18/0x1c showstack from dumpstacklvl+0x44/0x70 dumpstacklvl from _mightresched+0x38c/0x598 _mightresched from disableirq+0x1c/0x48 disableirq from mctrlgpiodisablems+0x74/0xc0 mctrlgpiodisablems from atmeldisablems.part.0+0x80/0x1f4 atmeldisablems.part.0 from atmelsettermios+0x764/0x11e8 atmelsettermios from uartchangelinesettings+0x15c/0x994 uartchangelinesettings from uartsettermios+0x2b0/0x668 uartsettermios from ttysettermios+0x600/0x8ec ttysettermios from ttyportsetflowcontrol+0x188/0x1e0 ttyportsetflowcontrol from wilcsetup+0xd0/0x524 [hciwilc] wilcsetup [hciwilc] from hcidevopensync+0x330/0x203c [bluetooth] hcidevopensync [bluetooth] from hcidevdoopen+0x40/0xb0 [bluetooth] hcidevdoopen [bluetooth] from hcipoweron+0x12c/0x664 [bluetooth] hcipoweron [bluetooth] from processonework+0x998/0x1a38 processonework from workerthread+0x6e0/0xfb4 workerthread from kthread+0x3d4/0x484 kthread from retfrom_fork+0x14/0x28

This warning is emitted when trying to toggle, at the highest level, some flow control (with serdevdevicesetflowcontrol) in a device driver. At the lowest level, the atmelserial driver is using serialmctrlgpio lib to enable/disable the corresponding IRQs accordingly. The warning emitted by CONFIGDEBUGATOMICSLEEP is due to disableirq (called in mctrlgpiodisablems) being possibly called in some atomic context (some tty drivers perform modem lines configuration in regions protected by port lock).

Split mctrlgpiodisablems into two differents APIs, a non-blocking one and a blocking one. Replace mctrlgpiodisablems calls with the relevant version depending on whether the call is protected by some port lock.(CVE-2025-38040)

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

virtioring: Fix data race by tagging eventtriggered as racy for KCSAN

syzbot reports a data-race when accessing the event_triggered, here is the simplified stack when the issue occurred:

================================================================== BUG: KCSAN: data-race in virtqueuedisablecb / virtqueueenablecb_delayed

write to 0xffff8881025bc452 of 1 bytes by task 3288 on cpu 0: virtqueueenablecbdelayed+0x42/0x3c0 drivers/virtio/virtioring.c:2653 startxmit+0x230/0x1310 drivers/net/virtionet.c:3264 _netdevstartxmit include/linux/netdevice.h:5151 [inline] netdevstartxmit include/linux/netdevice.h:5160 [inline] xmitone net/core/dev.c:3800 [inline]

read to 0xffff8881025bc452 of 1 bytes by interrupt on cpu 1: virtqueuedisablecbsplit drivers/virtio/virtioring.c:880 [inline] virtqueuedisablecb+0x92/0x180 drivers/virtio/virtioring.c:2566 skbxmitdone+0x5f/0x140 drivers/net/virtionet.c:777 vringinterrupt+0x161/0x190 drivers/virtio/virtioring.c:2715 _handleirqeventpercpu+0x95/0x490 kernel/irq/handle.c:158 handleirqevent_percpu kernel/irq/handle.c:193 [inline]

value changed: 0x01 -> 0x00

When the data race occurs, the function virtqueueenablecbdelayed() sets eventtriggered to false, and virtqueuedisablecbsplit/packed() reads it as false due to the race condition. Since eventtriggered is an unreliable hint used for optimization, this should only cause the driver temporarily suggest that the device not send an interrupt notification when the event index is used.

Fix this KCSAN reported data-race issue by explicitly tagging the access as data_racy.(CVE-2025-38048)

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:

serial: Fix potential null-ptr-deref in mlbusioprobe()

devmioremap() can return NULL on error. Currently, mlbusio_probe() does not check for this case, which could result in a NULL pointer dereference.

Add NULL check after devm_ioremap() to prevent this issue.(CVE-2025-38135)

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

soc: aspeed: Add NULL check in aspeedlpcenable_snoop()

devmkasprintf() returns NULL when memory allocation fails. Currently, aspeedlpcenablesnoop() does not check for this case, which results in a NULL pointer dereference.

Add NULL check after devm_kasprintf() to prevent this issue.

arj: Fix Fixes: tag to use subject from 3772e5da4454

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:

mm: fix uprobe pte be overwritten when expanding vma

Patch series "Fix uprobe pte be overwritten when expanding vma".

This patch (of 4):

We encountered a BUG alert triggered by Syzkaller as follows: BUG: Bad rss-counter state mm:00000000b4a60fca type:MM_ANONPAGES val:1

And we can reproduce it with the following steps: 1. register uprobe on file at zero offset 2. mmap the file at zero offset: addr1 = mmap(NULL, 2 * 4096, PROTNONE, MAPPRIVATE, fd, 0); 3. mremap part of vma1 to new vma2: addr2 = mremap(addr1, 4096, 2 * 4096, MREMAPMAYMOVE); 4. mremap back to orig addr1: mremap(addr2, 4096, 4096, MREMAPMAYMOVE | MREMAP_FIXED, addr1);

In step 3, the vma1 range [addr1, addr1 + 4096] will be remap to new vma2 with range [addr2, addr2 + 8192], and remap uprobe anon page from the vma1 to vma2, then unmap the vma1 range [addr1, addr1 + 4096].

In step 4, the vma2 range [addr2, addr2 + 4096] will be remap back to the addr range [addr1, addr1 + 4096]. Since the addr range [addr1 + 4096, addr1 + 8192] still maps the file, it will take vmamergenewrange to expand the range, and then do uprobemmap in vmacomplete. Since the merged vma pgoff is also zero offset, it will install uprobe anon page to the merged vma. However, the upcomming movepagetables step, which use setpte_at to remap the vma2 uprobe pte to the merged vma, will overwrite the newly uprobe pte in the merged vma, and lead that pte to be orphan.

Since the uprobe pte will be remapped to the merged vma, we can remove the unnecessary uprobe_mmap upon merged vma.

This problem was first found in linux-6.6.y and also exists in the community syzkaller: https://lore.kernel.org/all/(CVE-2025-38207)

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:

bnxt: properly flush XDP redirect lists

We encountered following crash when testing a XDP_REDIRECT feature in production:

[56251.579676] listadd corruption. next->prev should be prev (ffff93120dd40f30), but was ffffb301ef3a6740. (next=ffff93120dd 40f30). [56251.601413] ------------[ cut here ]------------ [56251.611357] kernel BUG at lib/listdebug.c:29! [56251.621082] Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [56251.632073] CPU: 111 UID: 0 PID: 0 Comm: swapper/111 Kdump: loaded Tainted: P O 6.12.33-cloudflare-2025.6. 3 #1 [56251.653155] Tainted: [P]=PROPRIETARYMODULE, [O]=OOTMODULE [56251.663877] Hardware name: MiTAC GC68B-B8032-G11P6-GPU/S8032GM-HE-CFR, BIOS V7.020.B10-sig 01/22/2025 [56251.682626] RIP: 0010:_listaddvalidorreport+0x4b/0xa0 [56251.693203] Code: 0e 48 c7 c7 68 e7 d9 97 e8 42 16 fe ff 0f 0b 48 8b 52 08 48 39 c2 74 14 48 89 f1 48 c7 c7 90 e7 d9 97 48 89 c6 e8 25 16 fe ff <0f> 0b 4c 8b 02 49 39 f0 74 14 48 89 d1 48 c7 c7 e8 e7 d9 97 4c 89 [56251.725811] RSP: 0018:ffff93120dd40b80 EFLAGS: 00010246 [56251.736094] RAX: 0000000000000075 RBX: ffffb301e6bba9d8 RCX: 0000000000000000 [56251.748260] RDX: 0000000000000000 RSI: ffff9149afda0b80 RDI: ffff9149afda0b80 [56251.760349] RBP: ffff9131e49c8000 R08: 0000000000000000 R09: ffff93120dd40a18 [56251.772382] R10: ffff9159cf2ce1a8 R11: 0000000000000003 R12: ffff911a80850000 [56251.784364] R13: ffff93120fbc7000 R14: 0000000000000010 R15: ffff9139e7510e40 [56251.796278] FS: 0000000000000000(0000) GS:ffff9149afd80000(0000) knlGS:0000000000000000 [56251.809133] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [56251.819561] CR2: 00007f5e85e6f300 CR3: 00000038b85e2006 CR4: 0000000000770ef0 [56251.831365] PKRU: 55555554 [56251.838653] Call Trace: [56251.845560] <IRQ> [56251.851943] cpumapenqueue.cold+0x5/0xa [56251.860243] xdpdoredirect+0x2d9/0x480 [56251.868388] bnxtrxxdp+0x1d8/0x4c0 [bnxten] [56251.877028] bnxtrxpkt+0x5f7/0x19b0 [bnxten] [56251.885665] ? cpumaxwrite+0x1e/0x100 [56251.893510] ? srsoaliasreturnthunk+0x5/0xfbef5 [56251.902276] _bnxtpollwork+0x190/0x340 [bnxten] [56251.911058] bnxtpoll+0xab/0x1b0 [bnxten] [56251.919041] ? srsoaliasreturnthunk+0x5/0xfbef5 [56251.927568] ? srsoaliasreturnthunk+0x5/0xfbef5 [56251.935958] ? srsoaliasreturnthunk+0x5/0xfbef5 [56251.944250] _napipoll+0x2b/0x160 [56251.951155] bpftrampoline6442548651+0x79/0x123 [56251.959262] _napipoll+0x5/0x160 [56251.966037] netrxaction+0x3d2/0x880 [56251.973133] ? srsoaliasreturnthunk+0x5/0xfbef5 [56251.981265] ? srsoaliasreturnthunk+0x5/0xfbef5 [56251.989262] ? _hrtimerrunqueues+0x162/0x2a0 [56251.996967] ? srsoaliasreturnthunk+0x5/0xfbef5 [56252.004875] ? srsoaliasreturnthunk+0x5/0xfbef5 [56252.012673] ? bnxtmsix+0x62/0x70 [bnxten] [56252.019903] handlesoftirqs+0xcf/0x270 [56252.026650] irqexitrcu+0x67/0x90 [56252.032933] commoninterrupt+0x85/0xa0 [56252.039498] </IRQ> [56252.044246] <TASK> [56252.048935] asmcommoninterrupt+0x26/0x40 [56252.055727] RIP: 0010:cpuidleenterstate+0xb8/0x420 [56252.063305] Code: dc 01 00 00 e8 f9 79 3b ff e8 64 f7 ff ff 49 89 c5 0f 1f 44 00 00 31 ff e8 a5 32 3a ff 45 84 ff 0f 85 ae 01 00 00 fb 45 85 f6 <0f> 88 88 01 00 00 48 8b 04 24 49 63 ce 4c 89 ea 48 6b f1 68 48 29 [56252.088911] RSP: 0018:ffff93120c97fe98 EFLAGS: 00000202 [56252.096912] RAX: ffff9149afd80000 RBX: ffff9141d3a72800 RCX: 0000000000000000 [56252.106844] RDX: 00003329176c6b98 RSI: ffffffe36db3fdc7 RDI: 0000000000000000 [56252.116733] RBP: 0000000000000002 R08: 0000000000000002 R09: 000000000000004e [56252.126652] R10: ffff9149afdb30c4 R11: 071c71c71c71c71c R12: ffffffff985ff860 [56252.136637] R13: 00003329176c6b98 R14: 0000000000000002 R15: 0000000000000000 [56252.146667] ? cpuidleenterstate+0xab/0x420 [56252.153909] cpuidleenter+0x2d/0x40 [56252.160360] doidle+0x176/0x1c0 [56252.166456 ---truncated---(CVE-2025-38246)

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

serial: jsm: fix NPE during jsmuartport_init

No device was set which caused serialbasectrl_add to crash.

BUG: kernel NULL pointer dereference, address: 0000000000000050 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 16 UID: 0 PID: 368 Comm: (udev-worker) Not tainted 6.12.25-amd64 #1 Debian 6.12.25-1 RIP: 0010:serialbasectrladd+0x96/0x120 Call Trace: <TASK> serialcoreregisterport+0x1a0/0x580 ? setupirq+0x39c/0x660 ? _kmalloccachenoprof+0x111/0x310 jsmuartportinit+0xe8/0x180 [jsm] jsmprobeone+0x1f4/0x410 [jsm] localpciprobe+0x42/0x90 pcideviceprobe+0x22f/0x270 reallyprobe+0xdb/0x340 ? pmruntimebarrier+0x54/0x90 ? _pfxdriverattach+0x10/0x10 _driverprobedevice+0x78/0x110 driverprobedevice+0x1f/0xa0 _driverattach+0xba/0x1c0 busforeachdev+0x8c/0xe0 busadddriver+0x112/0x1f0 driverregister+0x72/0xd0 jsminitmodule+0x36/0xff0 [jsm] ? _pfxjsminitmodule+0x10/0x10 [jsm] dooneinitcall+0x58/0x310 doinitmodule+0x60/0x230

Tested with Digi Neo PCIe 8 port card.(CVE-2025-38265)

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:

fs/nfs/read: fix double-unlock bug in nfsreturnempty_folio()

Sometimes, when a file was read while it was being truncated by another NFS client, the kernel could deadlock because folio_unlock() was called twice, and the second call would XOR back the PG_locked flag.

Most of the time (depending on the timing of the truncation), nobody notices the problem because folio_unlock() gets called three times, which flips PG_locked back off:

1. vfsread, nfsreadfolio, ... nfsreadaddfolio, nfsreturnempty_folio
2. vfsread, nfsreadfolio, ... netfsreadcollection, netfsunlockabandonedread_pages
3. vfsread, ... nfsdoreadfolio, nfsreadaddfolio, nfsreturnemptyfolio

The problem is that nfsreadaddfolio() is not supposed to unlock the folio if fscache is enabled, and a nfsnetfsfoliounlock() check is missing in nfsreturnempty_folio().

Rarely this leads to a warning in netfsreadcollection():

------------[ cut here ]------------ R=0000031c: folio 10 is not locked WARNING: CPU: 0 PID: 29 at fs/netfs/readcollect.c:133 netfsreadcollection+0x7c0/0xf00 [...] Workqueue: eventsunbound netfsreadcollectionworker RIP: 0010:netfsreadcollection+0x7c0/0xf00 [...] Call Trace: <TASK> netfsreadcollectionworker+0x67/0x80 processonework+0x12e/0x2c0 worker_thread+0x295/0x3a0

Most of the time, however, processes just get stuck forever in foliowaitbit_common(), waiting for PG_locked to disappear, which never happens because nobody is really holding the folio lock.(CVE-2025-38338)

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

ACPICA: fix acpi operand cache leak in dswstate.c

ACPICA commit 987a3b5cf7175916e2a4b6ea5b8e70f830dfe732

I found an ACPI cache leak in ACPI early termination and boot continuing case.

When early termination occurs due to malicious ACPI table, Linux kernel terminates ACPI function and continues to boot process. While kernel terminates ACPI function, kmemcachedestroy() reports Acpi-Operand cache leak.

Boot log of ACPI operand cache leak is as follows: >[ 0.585957] ACPI: Added OSI(Module Device) >[ 0.587218] ACPI: Added _OSI(Processor Device) >[ 0.588530] ACPI: Added _OSI(3.0 _SCP Extensions) >[ 0.589790] ACPI: Added _OSI(Processor Aggregator Device) >[ 0.591534] ACPI Error: Illegal I/O port address/length above 64K: C806E00000004002/0x2 (20170303/hwvalid-155) >[ 0.594351] ACPI Exception: AELIMIT, Unable to initialize fixed events (20170303/evevent-88) >[ 0.597858] ACPI: Unable to start the ACPI Interpreter >[ 0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) >[ 0.601836] kmemcachedestroy Acpi-Operand: Slab cache still has objects >[ 0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26 >[ 0.605159] Hardware name: innotek gmbh virtualbox/virtualbox, BIOS virtualbox 12/01/2006 >[ 0.609177] Call Trace: >[ 0.610063] ? dumpstack+0x5c/0x81 >[ 0.611118] ? kmemcachedestroy+0x1aa/0x1c0 >[ 0.612632] ? acpisleepprocinit+0x27/0x27 >[ 0.613906] ? acpiosdeletecache+0xa/0x10 >[ 0.617986] ? acpiutdeletecaches+0x3f/0x7b >[ 0.619293] ? acpiterminate+0xa/0x14 >[ 0.620394] ? acpiinit+0x2af/0x34f >[ 0.621616] ? _classcreate+0x4c/0x80 >[ 0.623412] ? videosetup+0x7f/0x7f >[ 0.624585] ? acpisleepprocinit+0x27/0x27 >[ 0.625861] ? dooneinitcall+0x4e/0x1a0 >[ 0.627513] ? kernelinitfreeable+0x19e/0x21f >[ 0.628972] ? restinit+0x80/0x80 >[ 0.630043] ? kernelinit+0xa/0x100 >[ 0.631084] ? retfromfork+0x25/0x30 >[ 0.633343] vgaarb: loaded >[ 0.635036] EDAC MC: Ver: 3.0.0 >[ 0.638601] PCI: Probing PCI hardware >[ 0.639833] PCI host bridge to bus 0000:00 >[ 0.641031] pci_bus 0000:00: root bus resource [io 0x0000-0xffff] > ... Continue to boot and log is omitted ...

I analyzed this memory leak in detail and found acpidsobjstackpopand delete() function miscalculated the top of the stack. acpidsobjstackpush() function uses walkstate->operandindex for start position of the top, but acpidsobjstackpopanddelete() function considers index 0 for it. Therefore, this causes acpi operand memory leak.

This cache leak causes a security threat because an old kernel (<= 4.9) shows memory locations of kernel functions in stack dump. Some malicious users could use this information to neutralize kernel ASLR.

I made a patch to fix ACPI operand cache leak.(CVE-2025-38345)

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:

i2c/designware: Fix an initialization issue

The i2cdwxferinit() function requires msgs and msgwrite_idx from the dev context to be initialized.

amdi2cdwxferquirk() inits msgs and msgsnum, but not msgwrite_idx.

This could allow an out of bounds access (of msgs).

Initialize msgwriteidx before calling i2cdwxfer_init().(CVE-2025-38380)

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

net: usb: lan78xx: fix WARN in _netifnapidellocked on disconnect

Remove redundant netifnapidel() call from disconnect path.

A WARN may be triggered in _netifnapidellocked() during USB device disconnect:

WARNING: CPU: 0 PID: 11 at net/core/dev.c:7417 _netifnapidellocked+0x2b4/0x350

This happens because netifnapidel() is called in the disconnect path while NAPI is still enabled. However, it is not necessary to call netifnapidel() explicitly, since unregister_netdev() will handle NAPI teardown automatically and safely. Removing the redundant call avoids triggering the warning.

Full trace: lan78xx 1-1:1.0 enu1: Failed to read register index 0x000000c4. ret = -ENODEV lan78xx 1-1:1.0 enu1: Failed to set MAC down with error -ENODEV lan78xx 1-1:1.0 enu1: Link is Down lan78xx 1-1:1.0 enu1: Failed to read register index 0x00000120. ret = -ENODEV ------------[ cut here ]------------ WARNING: CPU: 0 PID: 11 at net/core/dev.c:7417 _netifnapidellocked+0x2b4/0x350 Modules linked in: flexcan candev fuse CPU: 0 UID: 0 PID: 11 Comm: kworker/0:1 Not tainted 6.16.0-rc2-00624-ge926949dab03 #9 PREEMPT Hardware name: SKOV IMX8MP CPU revC - bd500 (DT) Workqueue: usbhubwq hubevent pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : _netifnapidellocked+0x2b4/0x350 lr : _netifnapidellocked+0x7c/0x350 sp : ffffffc085b673c0 x29: ffffffc085b673c0 x28: ffffff800b7f2000 x27: ffffff800b7f20d8 x26: ffffff80110bcf58 x25: ffffff80110bd978 x24: 1ffffff0022179eb x23: ffffff80110bc000 x22: ffffff800b7f5000 x21: ffffff80110bc000 x20: ffffff80110bcf38 x19: ffffff80110bcf28 x18: dfffffc000000000 x17: ffffffc081578940 x16: ffffffc08284cee0 x15: 0000000000000028 x14: 0000000000000006 x13: 0000000000040000 x12: ffffffb0022179e8 x11: 1ffffff0022179e7 x10: ffffffb0022179e7 x9 : dfffffc000000000 x8 : 0000004ffdde8619 x7 : ffffff80110bcf3f x6 : 0000000000000001 x5 : ffffff80110bcf38 x4 : ffffff80110bcf38 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 1ffffff0022179e7 x0 : 0000000000000000 Call trace: _netifnapidellocked+0x2b4/0x350 (P) lan78xxdisconnect+0xf4/0x360 usbunbindinterface+0x158/0x718 deviceremove+0x100/0x150 devicereleasedriverinternal+0x308/0x478 devicereleasedriver+0x1c/0x30 busremovedevice+0x1a8/0x368 devicedel+0x2e0/0x7b0 usbdisabledevice+0x244/0x540 usbdisconnect+0x220/0x758 hubevent+0x105c/0x35e0 processonework+0x760/0x17b0 workerthread+0x768/0xce8 kthread+0x3bc/0x690 retfromfork+0x10/0x20 irq event stamp: 211604 hardirqs last enabled at (211603): [<ffffffc0828cc9ec>] _rawspinunlockirqrestore+0x84/0x98 hardirqs last disabled at (211604): [<ffffffc0828a9a84>] el1dbg+0x24/0x80 softirqs last enabled at (211296): [<ffffffc080095f10>] handlesoftirqs+0x820/0xbc8 softirqs last disabled at (210993): [<ffffffc080010288>] _dosoftirq+0x18/0x20 ---[ end trace 0000000000000000 ]--- lan78xx 1-1:1.0 enu1: failed to kill vid 0081/0(CVE-2025-38385)

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:

fs: export anoninodemakesecureinode() and fix secretmem LSM bypass

Export anoninodemakesecureinode() to allow KVM guestmemfd to create anonymous inodes with proper security context. This replaces the current pattern of calling allocanoninode() followed by inodeinitsecurityanon() for creating security context manually.

This change also fixes a security regression in secretmem where the SPRIVATE flag was not cleared after allocanon_inode(), causing LSM/SELinux checks to be bypassed for secretmem file descriptors.

As guestmemfd currently resides in the KVM module, we need to export this symbol for use outside the core kernel. In the future, guestmemfd might be moved to core-mm, at which point the symbols no longer would have to be exported. When/if that happens is still unclear.(CVE-2025-38396)

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:

Squashfs: check return result of sbminblocksize

Syzkaller reports an "UBSAN: shift-out-of-bounds in squashfsbioread" bug.

Syzkaller forks multiple processes which after mounting the Squashfs filesystem, issues an ioctl("/dev/loop0", LOOPSETBLOCKSIZE, 0x8000). Now if this ioctl occurs at the same time another process is in the process of mounting a Squashfs filesystem on /dev/loop0, the failure occurs. When this happens the following code in squashfsfill_super() fails.

msblk->devblksize = sbminblocksize(sb, SQUASHFSDEVBLKSIZE);

msblk->devblksize_log2 = ffz(~msblk->devblksize);

sbminblocksize() returns 0, which means msblk->devblksize is set to 0.

As a result, ffz(~msblk->devblksize) returns 64, and msblk->devblksize_log2 is set to 64.

This subsequently causes the

UBSAN: shift-out-of-bounds in fs/squashfs/block.c:195:36 shift exponent 64 is too large for 64-bit type 'u64' (aka 'unsigned long long')

This commit adds a check for a 0 return by sbminblocksize().(CVE-2025-38415)

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:

video: screen_info: Relocate framebuffers behind PCI bridges

Apply PCI host-bridge window offsets to screen_info framebuffers. Fixes invalid access to I/O memory.

Resources behind a PCI host bridge can be relocated by a certain offset in the kernel's CPU address range used for I/O. The framebuffer memory range stored in screeninfo refers to the CPU addresses as seen during boot (where the offset is 0). During boot up, firmware may assign a different memory offset to the PCI host bridge and thereby relocating the framebuffer address of the PCI graphics device as seen by the kernel. The information in screeninfo must be updated as well.

The helper pcibiosbustoresource() performs the relocation of the screeninfo's framebuffer resource (given in PCI bus addresses). The result matches the I/O-memory resource of the PCI graphics device (given in CPU addresses). As before, we store away the information necessary to later update the information in screen_info itself.

Commit 78aa89d1dfba ("firmware/sysfb: Update screeninfo for relocated EFI framebuffers") added the code for updating screeninfo. It is based on similar functionality that pre-existed in efifb. Efifb uses a pointer to the PCI resource, while the newer code does a memcpy of the region. Hence efifb sees any updates to the PCI resource and avoids the issue.

v3: - Only use struct pcibusregion for PCI bus addresses (Bjorn) - Clarify address semantics in commit messages and comments (Bjorn) v2: - Fixed tags (Takashi, Ivan) - Updated information on efifb(CVE-2025-38427)

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

nfsd: nfsd4spomust_allow() must check this is a v4 compound request

If the request being processed is not a v4 compound request, then examining the cstate can have undefined results.

This patch adds a check that the rpc procedure being executed (rqprocinfo) is the NFSPROC4COMPOUND procedure.(CVE-2025-38430)

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:

mm/rmap: fix potential out-of-bounds page table access during batched unmap

As pointed out by David[1], the batched unmap logic in trytounmap_one() may read past the end of a PTE table when a large folio's PTE mappings are not fully contained within a single page table.

While this scenario might be rare, an issue triggerable from userspace must be fixed regardless of its likelihood. This patch fixes the out-of-bounds access by refactoring the logic into a new helper, foliounmappte_batch().

The new helper correctly calculates the safe batch size by capping the scan at both the VMA and PMD boundaries. To simplify the code, it also supports partial batching (i.e., any number of pages from 1 up to the calculated safe maximum), as there is no strong reason to special-case for fully mapped folios.(CVE-2025-38447)

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

perf: Revert to requiring CAPSYSADMIN for uprobes

Jann reports that uprobes can be used destructively when used in the middle of an instruction. The kernel only verifies there is a valid instruction at the requested offset, but due to variable instruction length cannot determine if this is an instruction as seen by the intended execution stream.

Additionally, Mark Rutland notes that on architectures that mix data in the text segment (like arm64), a similar things can be done if the data word is 'mistaken' for an instruction.

As such, require CAPSYSADMIN for uprobes.(CVE-2025-38466)

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

tls: always refresh the queue when reading sock

After recent changes in net-next TCP compacts skbs much more aggressively. This unearthed a bug in TLS where we may try to operate on an old skb when checking if all skbs in the queue have matching decrypt state and geometry.

BUG: KASAN: slab-use-after-free in tls_strp_check_rcv+0x898/0x9a0 [tls]
(net/tls/tls_strp.c:436 net/tls/tls_strp.c:530 net/tls/tls_strp.c:544)
Read of size 4 at addr ffff888013085750 by task tls/13529

CPU: 2 UID: 0 PID: 13529 Comm: tls Not tainted 6.16.0-rc5-virtme
Call Trace:
 kasan_report+0xca/0x100
 tls_strp_check_rcv+0x898/0x9a0 [tls]
 tls_rx_rec_wait+0x2c9/0x8d0 [tls]
 tls_sw_recvmsg+0x40f/0x1aa0 [tls]
 inet_recvmsg+0x1c3/0x1f0

Always reload the queue, fast path is to have the record in the queue when we wake, anyway (IOW the path going down "if !strp->stm.full_len").(CVE-2025-38471)

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:

dm-bufio: fix sched in atomic context

If "tryverifyintasklet" is set for dm-verity, DMBUFIOCLIENTNOSLEEP is enabled for dm-bufio. However, when bufio tries to evict buffers, there is a chance to trigger scheduling in spinlock_bh, the following warning is hit:

BUG: sleeping function called from invalid context at drivers/md/dm-bufio.c:2745 inatomic(): 1, irqsdisabled(): 0, nonblock: 0, pid: 123, name: kworker/2:2 preemptcount: 201, expected: 0 RCU nest depth: 0, expected: 0 4 locks held by kworker/2:2/123: #0: ffff88800a2d1548 ((wqcompletion)dmbufiocache){....}-{0:0}, at: processonework+0xe46/0x1970 #1: ffffc90000d97d20 ((workcompletion)(&dmbufioreplacementwork)){....}-{0:0}, at: processonework+0x763/0x1970 #2: ffffffff8555b528 (dmbufioclientslock){....}-{3:3}, at: doglobalcleanup+0x1ce/0x710 #3: ffff88801d5820b8 (&c->spinlock){....}-{2:2}, at: doglobalcleanup+0x2a5/0x710 Preemption disabled at: [<0000000000000000>] 0x0 CPU: 2 UID: 0 PID: 123 Comm: kworker/2:2 Not tainted 6.16.0-rc3-g90548c634bd0 #305 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: dmbufiocache doglobalcleanup Call Trace: <TASK> dumpstacklvl+0x53/0x70 _mightresched+0x360/0x4e0 doglobalcleanup+0x2f5/0x710 processonework+0x7db/0x1970 workerthread+0x518/0xea0 kthread+0x359/0x690 retfromfork+0xf3/0x1b0 retfromforkasm+0x1a/0x30 </TASK>

That can be reproduced by:

veritysetup format --data-block-size=4096 --hash-block-size=4096 /dev/vda /dev/vdb SIZE=$(blockdev --getsz /dev/vda) dmsetup create myverity -r --table "0 $SIZE verity 1 /dev/vda /dev/vdb 4096 4096 <datablocks> 1 sha256 <roothash> <salt> 1 tryverifyintasklet" mount /dev/dm-0 /mnt -o ro echo 102400 > /sys/module/dmbufio/parameters/maxcachesize_bytes read files in /mnt

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)