The Linux Kernel, the operating system core itself.

Security Fix(es):

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

net: test for not too small csumstart in virtionethdrto_skb()

syzbot was able to trigger this warning [1], after injecting a malicious packet through afpacket, setting skb->csumstart and thus the transport header to an incorrect value.

We can at least make sure the transport header is after the end of the network header (with a estimated minimal size).

[1] [ 67.873027] skb len=4096 headroom=16 headlen=14 tailroom=0 mac=(-1,-1) maclen=0 net=(16,-6) trans=10 shinfo(txflags=0 nrfrags=1 gso(size=0 type=0 segs=0)) csum(0xa start=10 offset=0 ipsummed=3 completesw=0 valid=0 level=0) hash(0x0 sw=0 l4=0) proto=0x0800 pkttype=0 iif=0 priority=0x0 mark=0x0 alloccpu=10 vlanall=0x0 encapsulation=0 inner(proto=0x0000, mac=0, net=0, trans=0) [ 67.877172] dev name=veth0vlan feat=0x000061164fdd09e9 [ 67.877764] sk family=17 type=3 proto=0 [ 67.878279] skb linear: 00000000: 00 00 10 00 00 00 00 00 0f 00 00 00 08 00 [ 67.879128] skb frag: 00000000: 0e 00 07 00 00 00 28 00 08 80 1c 00 04 00 00 02 [ 67.879877] skb frag: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.880647] skb frag: 00000020: 00 00 02 00 00 00 08 00 1b 00 00 00 00 00 00 00 [ 67.881156] skb frag: 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.881753] skb frag: 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.882173] skb frag: 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.882790] skb frag: 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.883171] skb frag: 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.883733] skb frag: 00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.884206] skb frag: 00000090: 00 00 00 00 00 00 00 00 00 00 69 70 76 6c 61 6e [ 67.884704] skb frag: 000000a0: 31 00 00 00 00 00 00 00 00 00 2b 00 00 00 00 00 [ 67.885139] skb frag: 000000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.885677] skb frag: 000000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.886042] skb frag: 000000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.886408] skb frag: 000000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.887020] skb frag: 000000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.887384] skb frag: 00000100: 00 00 [ 67.887878] ------------[ cut here ]------------ [ 67.887908] offset (-6) >= skbheadlen() (14) [ 67.888445] WARNING: CPU: 10 PID: 2088 at net/core/dev.c:3332 skbchecksumhelp (net/core/dev.c:3332 (discriminator 2)) [ 67.889353] Modules linked in: macsec macvtap macvlan hsr wireguard curve25519x8664 libcurve25519generic libchacha20poly1305 chachax8664 libchacha poly1305x8664 dummy bridge srmod cdrom evdev pcspkr i2cpiix4 9pnetvirtio 9p 9pnet netfs [ 67.890111] CPU: 10 UID: 0 PID: 2088 Comm: b363492833 Not tainted 6.11.0-virtme #1011 [ 67.890183] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 67.890309] RIP: 0010:skbchecksumhelp (net/core/dev.c:3332 (discriminator 2)) [ 67.891043] Call Trace: [ 67.891173] <TASK> [ 67.891274] ? _warn (kernel/panic.c:741) [ 67.891320] ? skbchecksumhelp (net/core/dev.c:3332 (discriminator 2)) [ 67.891333] ? reportbug (lib/bug.c:180 lib/bug.c:219) [ 67.891348] ? handlebug (arch/x86/kernel/traps.c:239) [ 67.891363] ? excinvalidop (arch/x86/kernel/traps.c:260 (discriminator 1)) [ 67.891372] ? asmexcinvalidop (./arch/x86/include/asm/idtentry.h:621) [ 67.891388] ? skbchecksumhelp (net/core/dev.c:3332 (discriminator 2)) [ 67.891399] ? skbchecksumhelp (net/core/dev.c:3332 (discriminator 2)) [ 67.891416] ipdofragment (net/ipv4/ipoutput.c:777 (discriminator 1)) [ 67.891448] ? _iplocalout (./include/linux/skbuff.h:1146 ./include/net/l3mdev.h:196 ./include/net/l3mdev.h:213 ne ---truncated---(CVE-2024-49947)

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

ublk: don't allow user copy for unprivileged device

UBLKFUSER_COPY requires userspace to call write() on ublk char device for filling request buffer, and unprivileged device can't be trusted.

So don't allow user copy for unprivileged device.(CVE-2024-50080)

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

sched/core: Disable page allocation in tasktickmm_cid()

With KASAN and PREEMPTRT enabled, calling taskworkadd() in tasktickmmcid() may cause the following splat.

[ 63.696416] BUG: sleeping function called from invalid context at kernel/locking/spinlockrt.c:48 [ 63.696416] inatomic(): 1, irqsdisabled(): 1, nonblock: 0, pid: 610, name: modprobe [ 63.696416] preempt_count: 10001, expected: 0 [ 63.696416] RCU nest depth: 1, expected: 1

This problem is caused by the following call trace.

schedtick() [ acquire rq->lock ] -> tasktickmmcid() -> taskworkadd() -> _kasanrecordauxstack() -> kasansavestack() -> stackdepotsaveflags() -> allocpagesmpolnoprof() -> _allocpagesnoprof() -> getpagefromfreelist() -> rmqueue() -> rmqueuepcplist() -> _rmqueuepcplist() -> rmqueuebulk() -> rtspinlock()

The rq lock is a rawspinlockt. We can't sleep while holding it. IOW, we can't call allocpages() in stackdepotsaveflags().

The tasktickmmcid() function with its taskworkadd() call was introduced by commit 223baf9d17f2 ("sched: Fix performance regression introduced by mmcid") in v6.4 kernel.

Fortunately, there is a kasanrecordauxstacknoalloc() variant that calls stackdepotsaveflags() while not allowing it to allocate new pages. To allow tasktickmmcid() to use taskwork without page allocation, a new TWAFNOALLOC flag is added to enable calling kasanrecordauxstacknoalloc() instead of kasanrecordauxstack() if set. The tasktickmm_cid() function is modified to add this new flag.

The possible downside is the missing stack trace in a KASAN report due to new page allocation required when taskworkadd_noallloc() is called which should be rare.(CVE-2024-50140)

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

ipc: fix memleak if msginitns failed in createipcns

Percpu memory allocation may failed during createipcns however this fail is not handled properly since ipc sysctls and mq sysctls is not released properly. Fix this by release these two resource when failure.

Here is the kmemleak stack when percpu failed:

unreferenced object 0xffff88819de2a600 (size 512): comm "shmem2nstest", pid 120711, jiffies 4300542254 hex dump (first 32 bytes): 60 aa 9d 84 ff ff ff ff fc 18 48 b2 84 88 ff ff `.........H..... 04 00 00 00 a4 01 00 00 20 e4 56 81 ff ff ff ff ........ .V..... backtrace (crc be7cba35): [<ffffffff81b43f83>] _kmallocnodetrackcallernoprof+0x333/0x420 [<ffffffff81a52e56>] kmemdupnoprof+0x26/0x50 [<ffffffff821b2f37>] setupmqsysctls+0x57/0x1d0 [<ffffffff821b29cc>] copyipcs+0x29c/0x3b0 [<ffffffff815d6a10>] createnewnamespaces+0x1d0/0x920 [<ffffffff815d7449>] copynamespaces+0x2e9/0x3e0 [<ffffffff815458f3>] copyprocess+0x29f3/0x7ff0 [<ffffffff8154b080>] kernelclone+0xc0/0x650 [<ffffffff8154b6b1>] _dosysclone+0xa1/0xe0 [<ffffffff843df8ff>] dosyscall64+0xbf/0x1c0 [<ffffffff846000b0>] entrySYSCALL64afterhwframe+0x4b/0x53(CVE-2024-53175)

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

wifi: ath12k: fix crash when unbinding

If there is an error during some initialization related to firmware, the function ath12kdpcccleanup is called to release resources. However this is released again when the device is unbinded (ath12kpci), and we get: BUG: kernel NULL pointer dereference, address: 0000000000000020 at RIP: 0010:ath12kdpcccleanup.part.0+0xb6/0x500 [ath12k] Call Trace: ath12kdpcccleanup ath12kdpfree ath12kcoredeinit ath12kpciremove ...

The issue is always reproducible from a VM because the MSI addressing initialization is failing.

In order to fix the issue, just set to NULL the released structure in ath12kdpcc_cleanup at the end.(CVE-2024-53188)

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

drm/amd/display: Fix null check for pipectx->planestate in hwsssetupdpp

This commit addresses a null pointer dereference issue in hwsssetupdpp(). The issue could occur when pipectx->planestate is null. The fix adds a check to ensure pipe_ctx->plane_state is not null before accessing. This prevents a null pointer dereference.(CVE-2024-53200)

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

iommu/arm-smmu: Defer probe of clients after smmu device bound

Null pointer dereference occurs due to a race between smmu driver probe and client driver probe, when ofdmaconfigure() for client is called after the iommudeviceregister() for smmu driver probe has executed but before the driver_bound() for smmu driver has been called.

Following is how the race occurs:

T1:Smmu device probe T2: Client device probe

reallyprobe() armsmmudeviceprobe() iommudeviceregister() reallyprobe() platformdmaconfigure() ofdmaconfigure() ofdmaconfigureid() ofiommuconfigure() iommuprobedevice() iommuinitdevice() armsmmuprobedevice() armsmmugetbyfwnode() driverfinddevicebyfwnode() driverfinddevice() nextdevice() klistnext() /* null ptr assigned to smmu */ /* null ptr dereference while smmu->streamidmask */ driverbound() klistadd_tail()

When this null smmu pointer is dereferenced later in armsmmuprobe_device, the device crashes.

Fix this by deferring the probe of the client device until the smmu device has bound to the arm smmu driver.

will: Add comment

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

net: fec: handle pagepooldevallocpages error

The fecenetupdatecbd function calls pagepooldevallocpages but did not handle the case when it returned NULL. There was a WARNON(!new_page) but it would still proceed to use the NULL pointer and then crash.

This case does seem somewhat rare but when the system is under memory pressure it can happen. One case where I can duplicate this with some frequency is when writing over a smbd share to a SATA HDD attached to an imx6q.

Setting /proc/sys/vm/minfreekbytes to higher values also seems to solve the problem for my test case. But it still seems wrong that the fec driver ignores the memory allocation error and can crash.

This commit handles the allocation error by dropping the current packet.(CVE-2025-21676)

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

sched/fair: Fix potential memory corruption in childcfsrqonlist

childcfsrqonlist attempts to convert a 'prev' pointer to a cfsrq. This 'prev' pointer can originate from struct rq's leafcfsrqlist, making the conversion invalid and potentially leading to memory corruption. Depending on the relative positions of leafcfsrq_list and the task group (tg) pointer within the struct, this can cause a memory fault or access garbage data.

The issue arises in listaddleafcfsrq, where both cfsrq->leafcfsrqlist and rq->leafcfsrqlist are added to the same leaf list. Also, rq->tmpalonebranch can be set to rq->leafcfsrqlist.

This adds a check if (prev == &rq->leaf_cfs_rq_list) after the main conditional in childcfsrqonlist. This ensures that the containerof operation will convert a correct cfsrq struct.

This check is sufficient because only cfs_rqs on the same CPU are added to the list, so verifying the 'prev' pointer against the current rq's list head is enough.

Fixes a potential memory corruption issue that due to current struct layout might not be manifesting as a crash but could lead to unpredictable behavior when the layout changes.(CVE-2025-21919)

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

media: vimc: skip .s_stream() for stopped entities

Syzbot reported [1] a warning prompted by a check in callsstream() that checks whether .s_stream() operation is warranted for unstarted or stopped subdevs.

Add a simple fix in vimcstreamerpipelineterminate() ensuring that entities skip a call to .sstream() unless they have been previously properly started.

[1] Syzbot report: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 5933 at drivers/media/v4l2-core/v4l2-subdev.c:460 callsstream+0x2df/0x350 drivers/media/v4l2-core/v4l2-subdev.c:460 Modules linked in: CPU: 0 UID: 0 PID: 5933 Comm: syz-executor330 Not tainted 6.13.0-rc2-syzkaller-00362-g2d8308bf5b67 #0 ... Call Trace: <TASK> vimcstreamerpipelineterminate+0x218/0x320 drivers/media/test-drivers/vimc/vimc-streamer.c:62 vimcstreamerpipelineinit drivers/media/test-drivers/vimc/vimc-streamer.c:101 [inline] vimcstreamersstream+0x650/0x9a0 drivers/media/test-drivers/vimc/vimc-streamer.c:203 vimccapturestartstreaming+0xa1/0x130 drivers/media/test-drivers/vimc/vimc-capture.c:256 vb2startstreaming+0x15f/0x5a0 drivers/media/common/videobuf2/videobuf2-core.c:1789 vb2corestreamon+0x2a7/0x450 drivers/media/common/videobuf2/videobuf2-core.c:2348 vb2streamon drivers/media/common/videobuf2/videobuf2-v4l2.c:875 [inline] vb2ioctlstreamon+0xf4/0x170 drivers/media/common/videobuf2/videobuf2-v4l2.c:1118 _videodoioctl+0xaf0/0xf00 drivers/media/v4l2-core/v4l2-ioctl.c:3122 videousercopy+0x4d2/0x1620 drivers/media/v4l2-core/v4l2-ioctl.c:3463 v4l2ioctl+0x1ba/0x250 drivers/media/v4l2-core/v4l2-dev.c:366 vfsioctl fs/ioctl.c:51 [inline] _dosysioctl fs/ioctl.c:906 [inline] _sesysioctl fs/ioctl.c:892 [inline] _x64sysioctl+0x190/0x200 fs/ioctl.c:892 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcd/0x250 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f2b85c01b19 ...(CVE-2025-22028)

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

ibmvnic: Use kernel helpers for hex dumps

Previously, when the driver was printing hex dumps, the buffer was cast to an 8 byte long and printed using string formatters. If the buffer size was not a multiple of 8 then a read buffer overflow was possible.

Therefore, create a new ibmvnic function that loops over a buffer and calls hexdumpto_buffer instead.

This patch address KASAN reports like the one below: ibmvnic 30000003 env3: Login Buffer: ibmvnic 30000003 env3: 01000000af000000 <...> ibmvnic 30000003 env3: 2e6d62692e736261 ibmvnic 30000003 env3: 65050003006d6f63 ================================================================== BUG: KASAN: slab-out-of-bounds in ibmvniclogin+0xacc/0xffc [ibmvnic] Read of size 8 at addr c0000001331a9aa8 by task ip/17681 <...> Allocated by task 17681: <...> ibmvniclogin+0x2f0/0xffc [ibmvnic] ibmvnicopen+0x148/0x308 [ibmvnic] _dev_open+0x1ac/0x304 <...> The buggy address is located 168 bytes inside of allocated 175-byte region [c0000001331a9a00, c0000001331a9aaf) <...> ================================================================= ibmvnic 30000003 env3: 000000000033766e(CVE-2025-22104)

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

ax25: Remove broken autobind

Binding AX25 socket by using the autobind feature leads to memory leaks in ax25connect() and also refcount leaks in ax25release(). Memory leak was detected with kmemleak:

================================================================ unreferenced object 0xffff8880253cd680 (size 96): backtrace: _kmallocnodetrackcallernoprof (./include/linux/kmemleak.h:43) kmemdupnoprof (mm/util.c:136) ax25rtautobind (net/ax25/ax25route.c:428) ax25connect (net/ax25/afax25.c:1282) _sysconnectfile (net/socket.c:2045) _sysconnect (net/socket.c:2064) _x64sysconnect (net/socket.c:2067) dosyscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)

entrySYSCALL64afterhwframe (arch/x86/entry/entry_64.S:130)

When socket is bound, refcounts must be incremented the way it is done in ax25bind() and ax25setsockopt() (SO_BINDTODEVICE). In case of autobind, the refcounts are not incremented.

This bug leads to the following issue reported by Syzkaller:

================================================================ ax25_connect(): syz-executor318 uses autobind, please contact (CVE-2025-22109)

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

f2fs: fix potential deadloop in preparecompressoverwrite()

Jan Prusakowski reported a kernel hang issue as below:

When running xfstests on linux-next kernel (6.14.0-rc3, 6.12) I encountered a problem in generic/475 test where fsstress process gets blocked in _f2fswritedatapages() and the test hangs. The options I used are:

MKFSOPTIONS -- -O compression -O extraattr -O projectquota -O quota /dev/vdc MOUNTOPTIONS -- -o acl,userxattr -o discard,compressextension=* /dev/vdc /vdc

INFO: task kworker/u8:0:11 blocked for more than 122 seconds. Not tainted 6.14.0-rc3-xfstests-lockdep #1 "echo 0 > /proc/sys/kernel/hungtasktimeoutsecs" disables this message. task:kworker/u8:0 state:D stack:0 pid:11 tgid:11 ppid:2 taskflags:0x4208160 flags:0x00004000 Workqueue: writeback wbworkfn (flush-253:0) Call Trace: <TASK> _schedule+0x309/0x8e0 schedule+0x3a/0x100 schedulepreemptdisabled+0x15/0x30 _mutexlock+0x59a/0xdb0 _f2fswritedatapages+0x3ac/0x400 dowritepages+0xe8/0x290 _writebacksingleinode+0x5c/0x360 writebacksbinodes+0x22f/0x570 wbwriteback+0xb0/0x410 wbdowriteback+0x47/0x2f0 wbworkfn+0x5a/0x1c0 processonework+0x223/0x5b0 workerthread+0x1d5/0x3c0 kthread+0xfd/0x230 retfromfork+0x31/0x50 retfromforkasm+0x1a/0x30 </TASK>

The root cause is: once generic/475 starts toload error table to dm device, f2fspreparecompress_overwrite() will loop reading compressed cluster pages due to IO error, meanwhile it has held .writepages lock, it can block all other writeback tasks.

Let's fix this issue w/ below changes: - add f2fshandlepageeio() in preparecompressoverwrite() to detect IO error. - detect cperror earler in f2fsreadmulti_pages().(CVE-2025-22127)

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

PCI: vmd: Make vmddev::cfglock a rawspinlockt type

The access to the PCI config space via pciops::read and pciops::write is a low-level hardware access. The functions can be accessed with disabled interrupts even on PREEMPTRT. The pcilock is a rawspinlockt for this purpose.

A spinlockt becomes a sleeping lock on PREEMPTRT, so it cannot be acquired with disabled interrupts. The vmddev::cfglock is accessed in the same context as the pci_lock.

Make vmddev::cfglock a rawspinlockt type so it can be used with interrupts disabled.

This was reported as:

BUG: sleeping function called from invalid context at kernel/locking/spinlockrt.c:48 Call Trace: rtspinlock+0x4e/0x130 vmdpciread+0x8d/0x100 [vmd] pciuserreadconfigbyte+0x6f/0xe0 pcireadconfig+0xfe/0x290 sysfskfbinread+0x68/0x90

[bigeasy: reword commit message] Tested-off-by: Luis Claudio R. Goncalves <(CVE-2025-23161)

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

ext4: ignore xattrs past end

Once inside 'ext4xattrinodedecref_all' we should ignore xattrs entries past the 'end' entry.

This fixes the following KASAN reported issue:

================================================================== BUG: KASAN: slab-use-after-free in ext4xattrinodedecref_all+0xb8c/0xe90 Read of size 4 at addr ffff888012c120c4 by task repro/2065

CPU: 1 UID: 0 PID: 2065 Comm: repro Not tainted 6.13.0-rc2+ #11 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dumpstacklvl+0x1fd/0x300 ? tcpgrodevwarn+0x260/0x260 ? _printk+0xc0/0x100 ? readlockisrecursive+0x10/0x10 ? irqworkqueue+0x72/0xf0 ? _virtaddrvalid+0x17b/0x4b0 printaddressdescription+0x78/0x390 printreport+0x107/0x1f0 ? _virtaddrvalid+0x17b/0x4b0 ? _virtaddrvalid+0x3ff/0x4b0 ? _physaddr+0xb5/0x160 ? ext4xattrinodedecrefall+0xb8c/0xe90 kasanreport+0xcc/0x100 ? ext4xattrinodedecrefall+0xb8c/0xe90 ext4xattrinodedecrefall+0xb8c/0xe90 ? ext4xattrdeleteinode+0xd30/0xd30 ? _ext4journalensurecredits+0x5f0/0x5f0 ? _ext4journalensurecredits+0x2b/0x5f0 ? inodeupdatetimestamps+0x410/0x410 ext4xattrdeleteinode+0xb64/0xd30 ? ext4truncate+0xb70/0xdc0 ? ext4expandextraisizeea+0x1d20/0x1d20 ? _ext4markinodedirty+0x670/0x670 ? ext4journalcheckstart+0x16f/0x240 ? ext4inodeisfastsymlink+0x2f2/0x3a0 ext4evictinode+0xc8c/0xff0 ? ext4inodeisfastsymlink+0x3a0/0x3a0 ? dorawspinunlock+0x53/0x8a0 ? ext4inodeisfastsymlink+0x3a0/0x3a0 evict+0x4ac/0x950 ? procnrinodes+0x310/0x310 ? traceext4dropinode+0xa2/0x220 ? rawspinunlock+0x1a/0x30 ? iput+0x4cb/0x7e0 dounlinkat+0x495/0x7c0 ? trybreakdeleg+0x120/0x120 ? 0xffffffff81000000 ? _checkobjectsize+0x15a/0x210 ? strncpyfromuser+0x13e/0x250 ? getnameflags+0x1dc/0x530 _x64sysunlinkat+0xc8/0xf0 dosyscall64+0x65/0x110 entrySYSCALL64afterhwframe+0x67/0x6f RIP: 0033:0x434ffd Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 8 RSP: 002b:00007ffc50fa7b28 EFLAGS: 00000246 ORIGRAX: 0000000000000107 RAX: ffffffffffffffda RBX: 00007ffc50fa7e18 RCX: 0000000000434ffd RDX: 0000000000000000 RSI: 0000000020000240 RDI: 0000000000000005 RBP: 00007ffc50fa7be0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 00007ffc50fa7e08 R14: 00000000004bbf30 R15: 0000000000000001 </TASK>

The buggy address belongs to the object at ffff888012c12000 which belongs to the cache filp of size 360 The buggy address is located 196 bytes inside of freed 360-byte region [ffff888012c12000, ffff888012c12168)

The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x12c12 head: order:1 mapcount:0 entiremapcount:0 nrpagesmapped:0 pincount:0 flags: 0x40(head|node=0|zone=0) pagetype: f5(slab) raw: 0000000000000040 ffff888000ad7640 ffffea0000497a00 dead000000000004 raw: 0000000000000000 0000000000100010 00000001f5000000 0000000000000000 head: 0000000000000040 ffff888000ad7640 ffffea0000497a00 dead000000000004 head: 0000000000000000 0000000000100010 00000001f5000000 0000000000000000 head: 0000000000000001 ffffea00004b0481 ffffffffffffffff 0000000000000000 head: 0000000000000002 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected

Memory state around the buggy address: ffff888012c11f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888012c12000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb > ffff888012c12080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888012c12100: fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc ffff888012c12180: fc fc fc fc fc fc fc fc fc ---truncated---(CVE-2025-37738)

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

perf: Fix hang while freeing sigtrap event

Perf can hang while freeing a sigtrap event if a related deferred signal hadn't managed to be sent before the file got closed:

perfeventoverflow() taskworkadd(perfpendingtask)

fput() taskworkadd(__fput())

taskworkrun() _fput() perfrelease() perfeventreleasekernel() _freeevent() perfpendingtasksync() taskworkcancel() -> FAILED rcuwaitwait_event()

Once taskworkrun() is running, the list of pending callbacks is removed from the taskstruct and from this point on taskworkcancel() can't remove any pending and not yet started work items, hence the taskworkcancel() failure and the hang on rcuwaitwait_event().

Task work could be changed to remove one work at a time, so a work running on the current task can always cancel a pending one, however the wait / wake design is still subject to inverted dependencies when remote targets are involved, as pictured by Oleg:

T1 T2

fd = perfeventopen(pid => T2->pid); fd = perfeventopen(pid => T1->pid); close(fd) close(fd) <IRQ> <IRQ> perfeventoverflow() perfeventoverflow() taskworkadd(perfpendingtask) taskworkadd(perfpendingtask) </IRQ> </IRQ> fput() fput() taskworkadd(_fput()) taskworkadd(_fput())

task_work_run()                                        task_work_run()
    ____fput()                                             ____fput()
        perf_release()                                         perf_release()
            perf_event_release_kernel()                            perf_event_release_kernel()
                _free_event()                                          _free_event()
                    perf_pending_task_sync()                               perf_pending_task_sync()
                        rcuwait_wait_event()                                   rcuwait_wait_event()

Therefore the only option left is to acquire the event reference count upon queueing the perf task work and release it from the task work, just like it was done before 3a5465418f5f ("perf: Fix event leak upon exec and file release") but without the leaks it fixed.

Some adjustments are necessary to make it work:

• A child event might dereference its parent upon freeing. Care must be taken to release the parent last.

• Some places assuming the event doesn't have any reference held and therefore can be freed right away must instead put the reference and let the reference counting to its job.(CVE-2025-37747)

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

PCI: Fix reference leak in pciregisterhost_bridge()

If deviceregister() fails, call putdevice() to give up the reference to avoid a memory leak, per the comment at device_register().

Found by code review.

[bhelgaas: squash Dan Carpenter's double free fix from https://lore.kernel.org/r/(CVE-2025-37836)

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

drm/amd/display: Fix slab-use-after-free in hdcp

The HDCP code in amdgpudmhdcp.c copies pointers to amdgpudmconnector objects without incrementing the kref reference counts. When using a USB-C dock, and the dock is unplugged, the corresponding amdgpudmconnector objects are freed, creating dangling pointers in the HDCP code. When the dock is plugged back, the dangling pointers are dereferenced, resulting in a slab-use-after-free:

[ 66.775837] BUG: KASAN: slab-use-after-free in eventpropertyvalidate+0x42f/0x6c0 [amdgpu] [ 66.776171] Read of size 4 at addr ffff888127804120 by task kworker/0:1/10

[ 66.776179] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.14.0-rc7-00180-g54505f727a38-dirty #233 [ 66.776183] Hardware name: HP HP Pavilion Aero Laptop 13-be0xxx/8916, BIOS F.17 12/18/2024 [ 66.776186] Workqueue: events eventpropertyvalidate [amdgpu] [ 66.776494] Call Trace: [ 66.776496] <TASK> [ 66.776497] dumpstacklvl+0x70/0xa0 [ 66.776504] printreport+0x175/0x555 [ 66.776507] ? _virtaddrvalid+0x243/0x450 [ 66.776510] ? kasancompletemodereportinfo+0x66/0x1c0 [ 66.776515] kasanreport+0xeb/0x1c0 [ 66.776518] ? eventpropertyvalidate+0x42f/0x6c0 [amdgpu] [ 66.776819] ? eventpropertyvalidate+0x42f/0x6c0 [amdgpu] [ 66.777121] _asanreportload4noabort+0x14/0x20 [ 66.777124] eventpropertyvalidate+0x42f/0x6c0 [amdgpu] [ 66.777342] ? _lockacquire+0x6b40/0x6b40 [ 66.777347] ? enableassr+0x250/0x250 [amdgpu] [ 66.777571] processonework+0x86b/0x1510 [ 66.777575] ? pwqdecnrinflight+0xcf0/0xcf0 [ 66.777578] ? assignwork+0x16b/0x280 [ 66.777580] ? lockisheldtype+0xa3/0x130 [ 66.777583] workerthread+0x5c0/0xfa0 [ 66.777587] ? processonework+0x1510/0x1510 [ 66.777588] kthread+0x3a2/0x840 [ 66.777591] ? kthreadispercpu+0xd0/0xd0 [ 66.777594] ? tracehardirqson+0x4f/0x60 [ 66.777597] ? rawspinunlockirq+0x27/0x60 [ 66.777599] ? calculatesigpending+0x77/0xa0 [ 66.777602] ? kthreadispercpu+0xd0/0xd0 [ 66.777605] retfromfork+0x40/0x90 [ 66.777607] ? kthreadispercpu+0xd0/0xd0 [ 66.777609] retfromforkasm+0x11/0x20 [ 66.777614] </TASK>

[ 66.777643] Allocated by task 10: [ 66.777646] kasansavestack+0x39/0x60 [ 66.777649] kasansavetrack+0x14/0x40 [ 66.777652] kasansaveallocinfo+0x37/0x50 [ 66.777655] _kasankmalloc+0xbb/0xc0 [ 66.777658] _kmalloccachenoprof+0x1c8/0x4b0 [ 66.777661] dmdpaddmstconnector+0xdd/0x5c0 [amdgpu] [ 66.777880] drmdpmstportaddconnector+0x47e/0x770 [drmdisplayhelper] [ 66.777892] drmdpsendlinkaddress+0x1554/0x2bf0 [drmdisplayhelper] [ 66.777901] drmdpcheckandsendlinkaddress+0x187/0x1f0 [drmdisplayhelper] [ 66.777909] drmdpmstlinkprobework+0x2b8/0x410 [drmdisplayhelper] [ 66.777917] processonework+0x86b/0x1510 [ 66.777919] workerthread+0x5c0/0xfa0 [ 66.777922] kthread+0x3a2/0x840 [ 66.777925] retfromfork+0x40/0x90 [ 66.777927] retfromforkasm+0x11/0x20

[ 66.777932] Freed by task 1713: [ 66.777935] kasansavestack+0x39/0x60 [ 66.777938] kasansavetrack+0x14/0x40 [ 66.777940] kasansavefreeinfo+0x3b/0x60 [ 66.777944] _kasanslabfree+0x52/0x70 [ 66.777946] kfree+0x13f/0x4b0 [ 66.777949] dmdpmstconnectordestroy+0xfa/0x150 [amdgpu] [ 66.778179] drmconnectorfree+0x7d/0xb0 [ 66.778184] drmmodeobjectput.part.0+0xee/0x160 [ 66.778188] drmmodeobjectput+0x37/0x50 [ 66.778191] drmatomicstatedefaultclear+0x220/0xd60 [ 66.778194] _drmatomicstatefree+0x16e/0x2a0 [ 66.778197] drmmodeatomicioctl+0x15ed/0x2ba0 [ 66.778200] drmioctlkernel+0x17a/0x310 [ 66.778203] drmioctl+0x584/0xd10 [ 66.778206] amdgpudrmioctl+0xd2/0x1c0 [amdgpu] [ 66.778375] _x64sysioctl+0x139/0x1a0 [ 66.778378] x64sys_call+0xee7/0xfb0 [ 66.778381] ---truncated---(CVE-2025-37903)

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

ksmbd: Fix UAF in _closefiletableids

A use-after-free is possible if one thread destroys the file via _ksmbdclose_fd while another thread holds a reference to it. The existing checks on fp->refcount are not sufficient to prevent this.

The fix takes ft->lock around the section which removes the file from the file table. This prevents two threads acquiring the same file pointer via _closefiletableids, as well as the other functions which retrieve a file from the IDR and which already use this same lock.(CVE-2025-37952)

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

fix a couple of races in MNTTREEBENEATH handling by domovemount()

Normally dolockmount(path, ) is locking a mountpoint pinned by *path and at the time when matching unlockmount() unlocks that location it is still pinned by the same thing.

Unfortunately, for 'beneath' case it's no longer that simple - the object being locked is not the one *path points to. It's the mountpoint of path->mnt. The thing is, without sufficient locking ->mntparent may change under us and none of the locks are held at that point. The rules are * mountlock stabilizes m->mntparent for any mount m. * namespacesem stabilizes m->mntparent, provided that m is mounted. * if either of the above holds and refcount of m is positive, we are guaranteed the same for refcount of m->mntparent.

namespacesem nests inside inodelock(), so dolockmount() has to take inodelock() before grabbing namespacesem. It does recheck that path->mnt is still mounted in the same place after getting namespace_sem, and it does take care to pin the dentry. It is needed, since otherwise we might end up with racing mount --move (or umount) happening while we were getting locks; in that case dentry would no longer be a mountpoint and could've been evicted on memory pressure along with its inode - not something you want when grabbing lock on that inode.

However, pinning a dentry is not enough - the matching mount is also pinned only by the fact that path->mnt is mounted on top it and at that point we are not holding any locks whatsoever, so the same kind of races could end up with all references to that mount gone just as we are about to enter inode_lock(). If that happens, we are left with filesystem being shut down while we are holding a dentry reference on it; results are not pretty.

What we need to do is grab both dentry and mount at the same time; that makes inodelock() safe *and* avoids the problem with fs getting shut down under us. After taking namespacesem we verify that path->mnt is still mounted (which stabilizes its ->mntparent) and check that it's still mounted at the same place. From that point on to the matching namespaceunlock() we are guaranteed that mount/dentry pair we'd grabbed are also pinned by being the mountpoint of path->mnt, so we can quietly drop both the dentry reference (as the current code does) and mnt one - it's OK to do under namespace_sem, since we are not dropping the final refs.

That solves the problem on dolockmount() side; unlockmount() also has one, since dentry is guaranteed to stay pinned only until the namespaceunlock(). That's easy to fix - just have inodeunlock() done earlier, while it's still pinned by mp->mdentry.(CVE-2025-37988)