The Linux Kernel, the operating system core itself.

Security Fix(es):

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

misc: pciendpointtest: Avoid issue of interrupts remaining after request_irq error

After devmrequestirq() fails with error in pciendpointtestrequestirq(), the pciendpointtestfreeirq_vectors() is called assuming that all IRQs have been released.

However, some requested IRQs remain unreleased, so there are still /proc/irq/* entries remaining, and this results in WARN() with the following message:

removeprocentry: removing non-empty directory 'irq/30', leaking at least 'pci-endpoint-test.0' WARNING: CPU: 0 PID: 202 at fs/proc/generic.c:719 removeprocentry +0x190/0x19c

To solve this issue, set the number of remaining IRQs to test->numirqs, and release IRQs in advance by calling pciendpointtestrelease_irq().

kwilczynski: commit log

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

btrfs: avoid NULL pointer dereference if no valid csum tree

[BUG] When trying read-only scrub on a btrfs with rescue=idatacsums mount option, it will crash with the following call trace:

BUG: kernel NULL pointer dereference, address: 0000000000000208 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page CPU: 1 UID: 0 PID: 835 Comm: btrfs Tainted: G O 6.15.0-rc3-custom+ #236 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:btrfslookupcsumsbitmap+0x49/0x480 [btrfs] Call Trace: <TASK> scrubfindfillfirststripe+0x35b/0x3d0 [btrfs] scrubsimplemirror+0x175/0x290 [btrfs] scrubstripe+0x5f7/0x6f0 [btrfs] scrubchunk+0x9a/0x150 [btrfs] scrubenumeratechunks+0x333/0x660 [btrfs] btrfsscrubdev+0x23e/0x600 [btrfs] btrfs_ioctl+0x1dcf/0x2f80 [btrfs] __x64sysioctl+0x97/0xc0 dosyscall64+0x4f/0x120 entrySYSCALL64afterhwframe+0x76/0x7e

[CAUSE] Mount option "rescue=idatacsums" will completely skip loading the csum tree, so that any data read will not find any data csum thus we will ignore data checksum verification.

Normally call sites utilizing csum tree will check the fs state flag NODATACSUMS bit, but unfortunately scrub does not check that bit at all.

This results in scrub to call btrfssearchslot() on a NULL pointer and triggered above crash.

[FIX] Check both extent and csum tree root before doing any tree search.(CVE-2025-38059)

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

coresight: holding cscfgcsdevlock while removing cscfg from csdev

There'll be possible race scenario for coresight config:

CPU0 CPU1 (perf enable) load module cscfgloadconfigsets() activate config. // sysfs (sysactivecnt == 1) ... cscfgcsdevenableactiveconfig() lock(csdev->cscfgcsdevlock) deactivate config // sysfs (sysactiveccnt == 0) cscfgunloadconfigsets() <iterating configcsdevlist> cscfgremoveownedcsdevconfigs() // here load config activate by CPU1 unlock(csdev->cscfgcsdevlock)

iterating configcsdevlist could be raced with configcsdevlist's entry delete.

To resolve this race , hold csdev->cscfgcsdevlock() while cscfgremoveownedcsdevconfigs()(CVE-2025-38132)

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

wifi: mt76: mt7915: Fix null-ptr-deref in mt7915mmiowed_init()

devmioremap() returns NULL on error. Currently, mt7915mmiowedinit() does not check for this case, which results in a NULL pointer dereference.

Prevent null pointer dereference in mt7915mmiowed_init().(CVE-2025-38155)

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

fs/ntfs3: handle hdrfirstde() return value

The hdrfirstde() function returns a pointer to a struct NTFS_DE. This pointer may be NULL. To handle the NULL error effectively, it is important to implement an error handler. This will help manage potential errors consistently.

Additionally, error handling for the return value already exists at other points where this function is called.

Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2025-38167)

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

exfat: fix double free in delayed_free

The double free could happen in the following path.

exfatcreateupcasetable() exfatcreateupcasetable() : return error exfatfreeupcasetable() : free ->volutbl exfatloaddefaultupcasetable : return error exfatkillsb() delayedfree() exfatfreeupcasetable() <--------- double free This patch set ->vol_util as NULL after freeing it.(CVE-2025-38206)

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

aoe: clean device rqlist in aoedevdowndev()

An aoe device's rqlist contains accepted block requests that are waiting to be transmitted to the aoe target. This queue was added as part of the conversion to blkmq. However, the queue was not cleaned out when an aoe device is downed which caused blkmqfreezequeue() to sleep indefinitely waiting for those requests to complete, causing a hang. This fix cleans out the queue before calling blkmqfreezequeue().(CVE-2025-38326)

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

wifi: p54: prevent buffer-overflow in p54rxeeprom_readback()

Robert Morris reported:

|If a malicious USB device pretends to be an Intersil p54 wifi |interface and generates an eepromreadback message with a large |eeprom->v1.len, p54rxeepromreadback() will copy data from the |message beyond the end of priv->eeprom. | |static void p54rxeepromreadback(struct p54common *priv, | struct skbuff *skb) |{ | struct p54hdr *hdr = (struct p54hdr *) skb->data; | struct p54eepromlm86 *eeprom = (struct p54eepromlm86 *) hdr->data; | | if (priv->fwvar >= 0x509) { | memcpy(priv->eeprom, eeprom->v2.data, | le16tocpu(eeprom->v2.len)); | } else { | memcpy(priv->eeprom, eeprom->v1.data, | le16tocpu(eeprom->v1.len)); | } | [...]

The eeprom->v{1,2}.len is set by the driver in p54downloadeeprom(). The device is supposed to provide the same length back to the driver. But yes, it's possible (like shown in the report) to alter the value to something that causes a crash/panic due to overrun.

This patch addresses the issue by adding the size to the common device context, so p54rxeeprom_readback no longer relies on possibly tampered values... That said, it also checks if the "firmware" altered the value and no longer copies them.

The one, small saving grace is: Before the driver tries to read the eeprom, it needs to upload >a< firmware. the vendor firmware has a proprietary license and as a reason, it is not present on most distributions by default.(CVE-2025-38348)

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

bpf: Disable migration in nfhookrun_bpf().

syzbot reported that the netfilter bpf prog can be called without migration disabled in xmit path.

Then the assertion in __bpfprogrun() fails, triggering the splat below. [0]

Let's use bpfprogrunpinoncpu() in nfhookrunbpf().

inatomic(): 0, irqsdisabled(): 0, migrationdisabled() 0 pid: 5829, name: sshd-session 3 locks held by sshd-session/5829: #0: ffff88807b4e4218 (sklock-AFINET){+.+.}-{0:0}, at: locksock include/net/sock.h:1667 [inline] #0: ffff88807b4e4218 (sklock-AFINET){+.+.}-{0:0}, at: tcpsendmsg+0x20/0x50 net/ipv4/tcp.c:1395 #1: ffffffff8e5c4e00 (rcureadlock){....}-{1:3}, at: rculockacquire include/linux/rcupdate.h:331 [inline] #1: ffffffff8e5c4e00 (rcureadlock){....}-{1:3}, at: rcureadlock include/linux/rcupdate.h:841 [inline] #1: ffffffff8e5c4e00 (rcuread_lock){....}-{1:3}, at: __ipqueuexmit+0x69/0x26c0 net/ipv4/ipoutput.c:470 #2: ffffffff8e5c4e00 (rcureadlock){....}-{1:3}, at: rculockacquire include/linux/rcupdate.h:331 [inline] #2: ffffffff8e5c4e00 (rcureadlock){....}-{1:3}, at: rcureadlock include/linux/rcupdate.h:841 [inline] #2: ffffffff8e5c4e00 (rcureadlock){....}-{1:3}, at: nfhook+0xb2/0x680 include/linux/netfilter.h:241 CPU: 0 UID: 0 PID: 5829 Comm: sshd-session Not tainted 6.16.0-rc6-syzkaller-00002-g155a3c003e55 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Call Trace: <TASK> __dumpstack lib/dumpstack.c:94 [inline] dump_stacklvl+0x16c/0x1f0 lib/dumpstack.c:120 __cant_migrate kernel/sched/core.c:8860 [inline] __cant_migrate+0x1c7/0x250 kernel/sched/core.c:8834 __bpfprogrun include/linux/filter.h:703 [inline] bpfprogrun include/linux/filter.h:725 [inline] nfhookrun_bpf+0x83/0x1e0 net/netfilter/nfbpflink.c:20 nfhookentryhookfn include/linux/netfilter.h:157 [inline] nfhookslow+0xbb/0x200 net/netfilter/core.c:623 nfhook+0x370/0x680 include/linux/netfilter.h:272 NFHOOKCOND include/linux/netfilter.h:305 [inline] ipoutput+0x1bc/0x2a0 net/ipv4/ipoutput.c:433 dstoutput include/net/dst.h:459 [inline] iplocalout net/ipv4/ipoutput.c:129 [inline] __ipqueuexmit+0x1d7d/0x26c0 net/ipv4/ip_output.c:527 __tcptransmitskb+0x2686/0x3e90 net/ipv4/tcp_output.c:1479 tcptransmitskb net/ipv4/tcpoutput.c:1497 [inline] tcpwritexmit+0x1274/0x84e0 net/ipv4/tcpoutput.c:2838 __tcppushpendingframes+0xaf/0x390 net/ipv4/tcpoutput.c:3021 tcppush+0x225/0x700 net/ipv4/tcp.c:759 tcpsendmsglocked+0x1870/0x42b0 net/ipv4/tcp.c:1359 tcpsendmsg+0x2e/0x50 net/ipv4/tcp.c:1396 inetsendmsg+0xb9/0x140 net/ipv4/afinet.c:851 socksendmsgnosec net/socket.c:712 [inline] __socksendmsg net/socket.c:727 [inline] sockwriteiter+0x4aa/0x5b0 net/socket.c:1131 newsyncwrite fs/readwrite.c:593 [inline] vfswrite+0x6c7/0x1150 fs/readwrite.c:686 ksyswrite+0x1f8/0x250 fs/readwrite.c:738 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xcd/0x4c0 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7fe7d365d407 Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff RSP:(CVE-2025-38640)

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

MIPS: Don't crash in stack_top() for tasks without ABI or vDSO

Not all tasks have an ABI associated or vDSO mapped, for example kthreads never do. If such a task ever ends up calling stack_top(), it will derefence the NULL ABI pointer and crash.

This can for example happen when using kunit:

mips_stack_top+0x28/0xc0
arch_pick_mmap_layout+0x190/0x220
kunit_vm_mmap_init+0xf8/0x138
__kunit_add_resource+0x40/0xa8
kunit_vm_mmap+0x88/0xd8
usercopy_test_init+0xb8/0x240
kunit_try_run_case+0x5c/0x1a8
kunit_generic_run_threadfn_adapter+0x28/0x50
kthread+0x118/0x240
ret_from_kernel_thread+0x14/0x1c

Only dereference the ABI point if it is set.

The GIC page is also included as it is specific to the vDSO. Also move the randomization adjustment into the same conditional.(CVE-2025-38696)

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

sctp: linearize cloned gso packets in sctp_rcv

A cloned head skb still shares these frag skbs in fraglist with the original head skb. It's not safe to access these frag skbs.

syzbot reported two use-of-uninitialized-memory bugs caused by this:

BUG: KMSAN: uninit-value in sctpinqpop+0x15b7/0x1920 net/sctp/inqueue.c:211 sctpinqpop+0x15b7/0x1920 net/sctp/inqueue.c:211 sctpassocbhrcv+0x1a7/0xc50 net/sctp/associola.c:998 sctpinqpush+0x2ef/0x380 net/sctp/inqueue.c:88 sctpbacklogrcv+0x397/0xdb0 net/sctp/input.c:331 skbacklog_rcv+0x13b/0x420 include/net/sock.h:1122 _releasesock+0x1da/0x330 net/core/sock.c:3106 releasesock+0x6b/0x250 net/core/sock.c:3660 sctpwaitforconnect+0x487/0x820 net/sctp/socket.c:9360 sctpsendmsgtoasoc+0x1ec1/0x1f00 net/sctp/socket.c:1885 sctpsendmsg+0x32b9/0x4a80 net/sctp/socket.c:2031 inetsendmsg+0x25a/0x280 net/ipv4/afinet.c:851 socksendmsgnosec net/socket.c:718 [inline]

and

BUG: KMSAN: uninit-value in sctpassocbhrcv+0x34e/0xbc0 net/sctp/associola.c:987 sctpassocbhrcv+0x34e/0xbc0 net/sctp/associola.c:987 sctpinqpush+0x2a3/0x350 net/sctp/inqueue.c:88 sctpbacklogrcv+0x3c7/0xda0 net/sctp/input.c:331 skbacklogrcv+0x142/0x420 include/net/sock.h:1148 _releasesock+0x1d3/0x330 net/core/sock.c:3213 releasesock+0x6b/0x270 net/core/sock.c:3767 sctpwaitforconnect+0x458/0x820 net/sctp/socket.c:9367 sctpsendmsgtoasoc+0x223a/0x2260 net/sctp/socket.c:1886 sctpsendmsg+0x3910/0x49f0 net/sctp/socket.c:2032 inetsendmsg+0x269/0x2a0 net/ipv4/afinet.c:851 socksendmsgnosec net/socket.c:712 [inline]

This patch fixes it by linearizing cloned gso packets in sctp_rcv().(CVE-2025-38718)

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

net/smc: fix UAF on smcsk after smclistenout()

BPF CI testing report a UAF issue:

[ 16.446633] BUG: kernel NULL pointer dereference, address: 000000000000003 0 [ 16.447134] #PF: supervisor read access in kernel mod e [ 16.447516] #PF: errorcode(0x0000) - not-present pag e [ 16.447878] PGD 0 P4D 0 [ 16.448063] Oops: Oops: 0000 [#1] PREEMPT SMP NOPT I [ 16.448409] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:1 Tainted: G OE 6.13.0-rc3-g89e8a75fda73-dirty #4 2 [ 16.449124] Tainted: [O]=OOTMODULE, [E]=UNSIGNEDMODUL E [ 16.449502] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/201 4 [ 16.450201] Workqueue: smchswq smclistenwor k [ 16.450531] RIP: 0010:smclisten_work+0xc02/0x159 0 [ 16.452158] RSP: 0018:ffffb5ab40053d98 EFLAGS: 0001024 6 [ 16.452526] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 000000000000030 0 [ 16.452994] RDX: 0000000000000280 RSI: 00003513840053f0 RDI: 000000000000000 0 [ 16.453492] RBP: ffffa097808e3800 R08: ffffa09782dba1e0 R09: 000000000000000 5 [ 16.453987] R10: 0000000000000000 R11: 0000000000000000 R12: ffffa0978274640 0 [ 16.454497] R13: 0000000000000000 R14: 0000000000000000 R15: ffffa09782d4092 0 [ 16.454996] FS: 0000000000000000(0000) GS:ffffa097bbc00000(0000) knlGS:000000000000000 0 [ 16.455557] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003 3 [ 16.455961] CR2: 0000000000000030 CR3: 0000000102788004 CR4: 0000000000770ef 0 [ 16.456459] PKRU: 5555555 4 [ 16.456654] Call Trace : [ 16.456832] <TASK > [ 16.456989] ? __die+0x23/0x7 0 [ 16.457215] ? pagefaultoops+0x180/0x4c 0 [ 16.457508] ? __lockacquire+0x3e6/0x249 0 [ 16.457801] ? excpagefault+0x68/0x20 0 [ 16.458080] ? asmexcpagefault+0x26/0x3 0 [ 16.458389] ? smclistenwork+0xc02/0x159 0 [ 16.458689] ? smclistenwork+0xc02/0x159 0 [ 16.458987] ? lockisheldtype+0x8f/0x10 0 [ 16.459284] processonework+0x1ea/0x6d 0 [ 16.459570] workerthread+0x1c3/0x38 0 [ 16.459839] ? __pfxworkerthread+0x10/0x1 0 [ 16.460144] kthread+0xe0/0x11 0 [ 16.460372] ? __pfxkthread+0x10/0x1 0 [ 16.460640] retfrom_fork+0x31/0x5 0 [ 16.460896] ? __pfxkthread+0x10/0x1 0 [ 16.461166] retfromforkasm+0x1a/0x3 0 [ 16.461453] </TASK > [ 16.461616] Modules linked in: bpftestmod(OE) [last unloaded: bpftestmod(OE) ] [ 16.462134] CR2: 000000000000003 0 [ 16.462380] ---[ end trace 0000000000000000 ]--- [ 16.462710] RIP: 0010:smclistenwork+0xc02/0x1590

The direct cause of this issue is that after smclistenout_connected(), newclcsock->sk may be NULL since it will releases the smcsk. Therefore, if the application closes the socket immediately after accept, newclcsock->sk can be NULL. A possible execution order could be as follows:

smclistenwork | userspace

locksock(sk) | smclistenoutconnected() | | - smclistenout | | | - releasesock | | |- sk->skdataready() | | fd = accept(); | close(fd); | - socket->sk = NULL; /* newclcsock->sk is NULL now */ SMCSTATSERVSUCCINC(socknet(newclcsock->sk))

Since smclistenout_connected() will not fail, simply swapping the order of the code can easily fix this issue.(CVE-2025-38734)

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

drm/amd/display: Avoid a NULL pointer dereference

[WHY] Although unlikely drmatomicgetnewconnectorstate() or drmatomicgetoldconnectorstate() can return NULL.

[HOW] Check returns before dereference.

(cherry picked from commit 1e5e8d672fec9f2ab352be121be971877bff2af9)(CVE-2025-39693)

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

media: ivsc: Fix crash at shutdown due to missing meicldevdisable() calls

Both the ACE and CSI driver are missing a meicldevdisable() call in their remove() function.

This causes the meicl client to stay part of the meidevice->filelist list even though its memory is freed by meiclbusdev_release() calling kfree(cldev->cl).

This leads to a use-after-free when meivscremove() runs meistop() which first removes all mei bus devices calling meiaceremove() and meicsiremove() followed by meiclbusdevrelease() and then calls meiclalldisconnect() which walks over meidevice->filelist dereferecing the just freed cldev->cl.

And meivscremove() it self is run at shutdown because of the platformdeviceunregister(tp->pdev) in vsctpshutdown()

When building a kernel with KASAN this leads to the following KASAN report:

[ 106.634504] ================================================================== [ 106.634623] BUG: KASAN: slab-use-after-free in meiclsetdisconnected (drivers/misc/mei/client.c:783) mei [ 106.634683] Read of size 4 at addr ffff88819cb62018 by task systemd-shutdow/1 [ 106.634729] [ 106.634767] Tainted: [E]=UNSIGNEDMODULE [ 106.634770] Hardware name: Dell Inc. XPS 16 9640/09CK4V, BIOS 1.12.0 02/10/2025 [ 106.634773] Call Trace: [ 106.634777] <TASK> ... [ 106.634871] kasanreport (mm/kasan/report.c:221 mm/kasan/report.c:636) [ 106.634901] meiclsetdisconnected (drivers/misc/mei/client.c:783) mei [ 106.634921] meiclalldisconnect (drivers/misc/mei/client.c:2165 (discriminator 4)) mei [ 106.634941] meireset (drivers/misc/mei/init.c:163) mei ... [ 106.635042] meistop (drivers/misc/mei/init.c:348) mei [ 106.635062] meivscremove (drivers/misc/mei/meidev.h:784 drivers/misc/mei/platform-vsc.c:393) meivsc [ 106.635066] platformremove (drivers/base/platform.c:1424)

Add the missing meicldevdisable() calls so that the meicl gets removed from meidevice->file_list before it is freed to fix this.(CVE-2025-39711)

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

parisc: Revise _getuser() to probe user read access

Because of the way read access support is implemented, read access interruptions are only triggered at privilege levels 2 and 3. The kernel executes at privilege level 0, so _getuser() never triggers a read access interruption (code 26). Thus, it is currently possible for user code to access a read protected address via a system call.

Fix this by probing read access rights at privilege level 3 (PRIV_USER) and setting _guerr to -EFAULT (-14) if access isn't allowed.

Note the cmpiclr instruction does a 32-bit compare because COND macro doesn't work inside asm.(CVE-2025-39716)

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

iio: imu: bno055: fix OOB access of hw_xlate array

Fix a potential out-of-bounds array access of the hw_xlate array in bno055.c.

In bno055getregmask(), hwxlate was iterated over the length of the vals array instead of the length of the hwxlate array. In the case of bno055gyrscale, the vals array is larger than the hwxlate array, so this could result in an out-of-bounds access. In practice, this shouldn't happen though because a match should always be found which breaks out of the for loop before it iterates beyond the end of the hwxlate array.

By adding a new hwxlatelen field to the bno055sysfsattr, we can be sure we are iterating over the correct length.(CVE-2025-39719)

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

s390/ism: fix concurrency management in ism_cmd()

The s390x ISM device data sheet clearly states that only one request-response sequence is allowable per ISM function at any point in time. Unfortunately as of today the s390/ism driver in Linux does not honor that requirement. This patch aims to rectify that.

This problem was discovered based on Aliaksei's bug report which states that for certain workloads the ISM functions end up entering error state (with PEC 2 as seen from the logs) after a while and as a consequence connections handled by the respective function break, and for future connection requests the ISM device is not considered -- given it is in a dysfunctional state. During further debugging PEC 3A was observed as well.

A kernel message like [ 1211.244319] zpci: 061a:00:00.0: Event 0x2 reports an error for PCI function 0x61a is a reliable indicator of the stated function entering error state with PEC 2. Let me also point out that a kernel message like [ 1211.244325] zpci: 061a:00:00.0: The ism driver bound to the device does not support error recovery is a reliable indicator that the ISM function won't be auto-recovered because the ISM driver currently lacks support for it.

On a technical level, without this synchronization, commands (inputs to the FW) may be partially or fully overwritten (corrupted) by another CPU trying to issue commands on the same function. There is hard evidence that this can lead to DMB token values being used as DMB IOVAs, leading to PEC 2 PCI events indicating invalid DMA. But this is only one of the failure modes imaginable. In theory even completely losing one command and executing another one twice and then trying to interpret the outputs as if the command we intended to execute was actually executed and not the other one is also possible. Frankly, I don't feel confident about providing an exhaustive list of possible consequences.(CVE-2025-39726)

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

LoongArch: Optimize module load time by optimizing PLT/GOT counting

When enabling CONFIGKASAN, CONFIGPREEMPTVOLUNTARYBUILD and CONFIGPREEMPTVOLUNTARY at the same time, there will be soft deadlock, the relevant logs are as follows:

rcu: INFO: rcusched self-detected stall on CPU ... Call Trace: [<900000000024f9e4>] showstack+0x5c/0x180 [<90000000002482f4>] dumpstacklvl+0x94/0xbc [<9000000000224544>] rcudumpcpustacks+0x1fc/0x280 [<900000000037ac80>] rcuschedclockirq+0x720/0xf88 [<9000000000396c34>] updateprocesstimes+0xb4/0x150 [<90000000003b2474>] ticknohzhandler+0xf4/0x250 [<9000000000397e28>] __hrtimerrunqueues+0x1d0/0x428 [<9000000000399b2c>] hrtimer_interrupt+0x214/0x538 [<9000000000253634>] constanttimerinterrupt+0x64/0x80 [<9000000000349938>] __handleirqeventpercpu+0x78/0x1a0 [<9000000000349a78>] handleirqeventpercpu+0x18/0x88 [<9000000000354c00>] handlepercpuirq+0x90/0xf0 [<9000000000348c74>] handleirqdesc+0x94/0xb8 [<9000000001012b28>] handlecpuirq+0x68/0xa0 [<9000000001def8c0>] handleloongarchirq+0x30/0x48 [<9000000001def958>] dovint+0x80/0xd0 [<9000000000268a0c>] kasanmemtoshadow.part.0+0x2c/0x2a0 [<90000000006344f4>] __asanload8+0x4c/0x120 [<900000000025c0d0>] modulefrobarchsections+0x5c8/0x6b8 [<90000000003895f0>] load_module+0x9e0/0x2958 [<900000000038b770>] _dosysinitmodule+0x208/0x2d0 [<9000000001df0c34>] dosyscall+0x94/0x190 [<900000000024d6fc>] handlesyscall+0xbc/0x158

After analysis, this is because the slow speed of loading the amdgpu module leads to the long time occupation of the cpu and then the soft deadlock.

When loading a module, modulefrobarchsections() tries to figure out the number of PLTs/GOTs that will be needed to handle all the RELAs. It will call the countmax_entries() to find in an out-of-order date which counting algorithm has O(n^2) complexity.

To make it faster, we sort the relocation list by info and addend. That way, to check for a duplicate relocation, it just needs to compare with the previous entry. This reduces the complexity of the algorithm to O(n log n), as done in commit d4e0340919fb ("arm64/module: Optimize module load time by optimizing PLT counting"). This gives sinificant reduction in module load time for modules with large number of relocations.

After applying this patch, the soft deadlock problem has been solved, and the kernel starts normally without "Call Trace".

Using the default configuration to test some modules, the results are as follows:

Module Size ip_tables 36K fat 143K radeon 2.5MB amdgpu 16MB

Without this patch: Module Module load time (ms) Count(PLTs/GOTs) ip_tables 18 59/6 fat 0 162/14 radeon 54 1221/84 amdgpu 1411 4525/1098

With this patch: Module Module load time (ms) Count(PLTs/GOTs) ip_tables 18 59/6 fat 0 162/14 radeon 22 1221/84 amdgpu 45 4525/1098(CVE-2025-39767)

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

parisc: Drop WARNONONCE() from flushcachevmap

I have observed warning to occassionally trigger.(CVE-2025-39781)

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

ARM: tegra: Use I/O memcpy to write to IRAM

Kasan crashes the kernel trying to check boundaries when using the normal memcpy.(CVE-2025-39794)

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

HID: hid-ntrig: fix unable to handle page fault in ntrigreportversion()

in ntrigreportversion(), hdev parameter passed from hidprobe(). sending descriptor to /dev/uhid can make hdev->dev.parent->parent to null if hdev->dev.parent->parent is null, usbdev has invalid address(0xffffffffffffff58) that hidtousbdev(hdev) returned when usbrcvctrlpipe() use usb_dev,it trigger page fault error for address(0xffffffffffffff58)

add null check logic to ntrigreportversion() before calling hidtousb_dev()(CVE-2025-39808)

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

ocfs2: prevent release journal inode after journal shutdown

Before calling ocfs2deleteosb(), ocfs2journalshutdown() has already been executed in ocfs2dismountvolume(), so osb->journal must be NULL. Therefore, the following calltrace will inevitably fail when it reaches jbd2journalreleasejbdinode().

ocfs2dismountvolume()-> ocfs2deleteosb()-> ocfs2freeslot_info()-> __ocfs2freeslotinfo()-> evict()-> ocfs2evictinode()-> ocfs2clearinode()-> jbd2journalreleasejbdinode(osb->journal->jjournal,

Adding osb->journal checks will prevent null-ptr-deref during the above execution path.(CVE-2025-39842)

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

pcmcia: Fix a NULL pointer dereference in _iodynfindioregion()

In _iodynfindioregion(), pcmciamakeresource() is assigned to res and used in pcibusallocresource(). There is a dereference of res in pcibusallocresource(), which could lead to a NULL pointer dereference on failure of pcmciamakeresource().

Fix this bug by adding a check of res.(CVE-2025-39846)

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

Bluetooth: vhci: Prevent use-after-free by removing debugfs files early

Move the creation of debugfs files into a dedicated function, and ensure they are explicitly removed during vhci_release(), before associated data structures are freed.

Previously, debugfs files such as "forcesuspend", "forcewakeup", and others were created under hdev->debugfs but not removed in vhcirelease(). Since vhcirelease() frees the backing vhci_data structure, any access to these files after release would result in use-after-free errors.

Although hdev->debugfs is later freed in hcireleasedev(), user can access files after vhci_data is freed but before hdev->debugfs is released.(CVE-2025-39861)

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

wifi: brcmfmac: fix use-after-free when rescheduling brcmfbtcoexinfo work

The brcmfbtcoexdetach() only shuts down the btcoex timer, if the flag timeron is false. However, the brcmfbtcoextimerfunc(), which runs as timer handler, sets timeron to false. This creates critical race conditions:

1.If brcmfbtcoexdetach() is called while brcmfbtcoextimerfunc() is executing, it may observe timeron as false and skip the call to timershutdown_sync().

2.The brcmfbtcoextimerfunc() may then reschedule the brcmfbtcoexinfo worker after the cancelworksync() has been executed, resulting in use-after-free bugs.

The use-after-free bugs occur in two distinct scenarios, depending on the timing of when the brcmfbtcoexinfo struct is freed relative to the execution of its worker thread.

Scenario 1: Freed before the worker is scheduled

The brcmfbtcoexinfo is deallocated before the worker is scheduled. A race condition can occur when schedulework(&btlocal->work) is called after the target memory has been freed. The sequence of events is detailed below:

CPU0 | CPU1 brcmfbtcoexdetach | brcmfbtcoextimerfunc | btlocal->timeron = false; if (cfg->btcoex->timeron) | ... | cancelworksync(); | ... | kfree(cfg->btcoex); // FREE | | schedulework(&bt_local->work); // USE

Scenario 2: Freed after the worker is scheduled

The brcmfbtcoexinfo is freed after the worker has been scheduled but before or during its execution. In this case, statements within the brcmfbtcoexhandler() — such as the containerof macro and subsequent dereferences of the brcmfbtcoex_info object will cause a use-after-free access. The following timeline illustrates this scenario:

CPU0 | CPU1 brcmfbtcoexdetach | brcmfbtcoextimerfunc | btlocal->timeron = false; if (cfg->btcoex->timeron) | ... | cancelworksync(); | ... | schedulework(); // Reschedule | kfree(cfg->btcoex); // FREE | brcmfbtcoexhandler() // Worker /* | btci = container_of(....); // USE The kfree() above could | ... also occur at any point | btci-> // USE during the worker's execution| */ |

To resolve the race conditions, drop the conditional check and call timershutdownsync() directly. It can deactivate the timer reliably, regardless of its current state. Once stopped, the timer_on state is then set to false.(CVE-2025-39863)

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

mm/damon/lrusort: avoid divide-by-zero in damonlrusortapply_parameters()

Patch series "mm/damon: avoid divide-by-zero in DAMON module's parameters application".

DAMON's RECLAIM and LRU_SORT modules perform no validation on user-configured parameters during application, which may lead to division-by-zero errors.

Avoid the divide-by-zero by adding validation checks when DAMON modules attempt to apply the parameters.

This patch (of 2):

During the calculation of 'hotthres' and 'coldthres', either 'sampleinterval' or 'aggrinterval' is used as the divisor, which may lead to division-by-zero errors. Fix it by directly returning -EINVAL when such a case occurs. Additionally, since 'aggrinterval' is already required to be set no smaller than 'sampleinterval' in damonsetattrs(), only the case where 'sample_interval' is zero needs to be checked.(CVE-2025-39909)

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

mm/damon/reclaim: avoid divide-by-zero in damonreclaimapply_parameters()

When creating a new scheme of DAMONRECLAIM, the calculation of 'minageregion' uses 'aggrinterval' as the divisor, which may lead to division-by-zero errors. Fix it by directly returning -EINVAL when such a case occurs.(CVE-2025-39916)

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

drm: bridge: anx7625: Fix NULL pointer dereference with early IRQ

If the interrupt occurs before resource initialization is complete, the interrupt handler/worker may access uninitialized data such as the I2C tcpc_client device, potentially leading to NULL pointer dereference.(CVE-2025-39934)

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

wifi: wilc1000: avoid buffer overflow in WID string configuration

Fix the following copy overflow warning identified by Smatch checker.

drivers/net/wireless/microchip/wilc1000/wlancfg.c:184 wilcwlanparseresponse_frame() error: '__memcpy()' 'cfg->s[i]->str' copy overflow (512 vs 65537)

This patch introduces size check before accessing the memory buffer. The checks are base on the WID type of received data from the firmware. For WID string configuration, the size limit is determined by individual element size in 'struct wilccfgstrvals' that is maintained in 'len' field of 'struct wilccfg_str'.(CVE-2025-39952)

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

KVM: SVM: Skip fastpath emulation on VM-Exit if next RIP isn't valid

Skip the WRMSR and HLT fastpaths in SVM's VM-Exit handler if the next RIP isn't valid, e.g. because KVM is running with nrips=false. SVM must decode and emulate to skip the instruction if the CPU doesn't provide the next RIP, and getting the instruction bytes to decode requires reading guest memory. Reading guest memory through the emulator can fault, i.e. can sleep, which is disallowed since the fastpath handlers run with IRQs disabled.

BUG: sleeping function called from invalid context at ./include/linux/uaccess.h:106 inatomic(): 1, irqsdisabled(): 1, nonblock: 0, pid: 32611, name: qemu preemptcount: 1, expected: 0 INFO: lockdep is turned off. irq event stamp: 30580 hardirqs last enabled at (30579): [<ffffffffc08b2527>] vcpu_run+0x1787/0x1db0 [kvm] hardirqs last disabled at (30580): [<ffffffffb4f62e32>] __schedule+0x1e2/0xed0 softirqs last enabled at (30570): [<ffffffffb4247a64>] fpuswapkvmfpstate+0x44/0x210 softirqs last disabled at (30568): [<ffffffffb4247a64>] fpuswapkvmfpstate+0x44/0x210 CPU: 298 UID: 0 PID: 32611 Comm: qemu Tainted: G U 6.16.0-smp--e6c618b51cfe-sleep #782 NONE Tainted: [U]=USER Hardware name: Google Astoria-Turin/astoria, BIOS 0.20241223.2-0 01/17/2025 Call Trace: <TASK> dumpstacklvl+0x7d/0xb0 __might_resched+0x271/0x290 __mightfault+0x28/0x80 kvmvcpureadguestpage+0x8d/0xc0 [kvm] kvmfetchguestvirt+0x92/0xc0 [kvm] __doinsnfetchbytes+0xf3/0x1e0 [kvm] x86decodeinsn+0xd1/0x1010 [kvm] x86emulate_instruction+0x105/0x810 [kvm] __svmskipemulatedinstruction+0xc4/0x140 [kvmamd] handlefastpathinvd+0xc4/0x1a0 [kvm] vcpurun+0x11a1/0x1db0 [kvm] kvmarchvcpuioctlrun+0x5cc/0x730 [kvm] kvmvcpu_ioctl+0x578/0x6a0 [kvm] __sesysioctl+0x6d/0xb0 dosyscall64+0x8a/0x2c0 entrySYSCALL64afterhwframe+0x4b/0x53 RIP: 0033:0x7f479d57a94b </TASK>

Note, this is essentially a reapply of commit 5c30e8101e8d ("KVM: SVM: Skip WRMSR fastpath on VM-Exit if next RIP isn't valid"), but with different justification (KVM now grabs SRCU when skipping the instruction for other reasons).(CVE-2025-40038)

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

ext4: fix potential null deref in ext4mbinit()

In ext4mbinit(), ext4mbavgfragmentsizedestroy() may be called when sbi->smbavgfragmentsize remains uninitialized (e.g., if groupinfo slab cache allocation fails). Since ext4mbavgfragmentsizedestroy() lacks null pointer checking, this leads to a null pointer dereference.

================================================================== EXT4-fs: no memory for groupinfo slab cache BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: Oops: 0002 [#1] SMP PTI CPU:2 UID: 0 PID: 87 Comm:mount Not tainted 6.17.0-rc2 #1134 PREEMPT(none) RIP: 0010:rawspinlockirqsave+0x1b/0x40 Call Trace: <TASK> xadestroy+0x61/0x130 ext4mb_init+0x483/0x540 __ext4fillsuper+0x116d/0x17b0 ext4fillsuper+0xd3/0x280 gettreebdevflags+0x132/0x1d0 vfsgettree+0x29/0xd0 donew_mount+0x197/0x300 __x64sysmount+0x116/0x150 dosyscall64+0x50/0x1c0

entrySYSCALL64afterhwframe+0x76/0x7e

Therefore, add necessary null check to ext4mbavgfragmentsizedestroy() to prevent this issue. The same fix is also applied to ext4mblargestfreeordersdestroy().(CVE-2025-40119)

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

EDAC/i10nm: Skip DIMM enumeration on a disabled memory controller

When loading the i10nm_edac driver on some Intel Granite Rapids servers, a call trace may appear as follows:

UBSAN: shift-out-of-bounds in drivers/edac/skx_common.c:453:16 shift exponent -66 is negative ... __ubsanhandleshiftoutofbounds+0x1e3/0x390 skxgetdimminfo.cold+0x47/0xd40 [skxedaccommon] i10nmgetdimmconfig+0x23e/0x390 [i10nmedac] skxregistermci+0x159/0x220 [skxedaccommon] i10nminit+0xcb0/0x1ff0 [i10nmedac] ...

This occurs because some BIOS may disable a memory controller if there aren't any memory DIMMs populated on this memory controller. The DIMMMTR register of this disabled memory controller contains the invalid value ~0, resulting in the call trace above.

Fix this call trace by skipping DIMM enumeration on a disabled memory controller.(CVE-2025-40157)

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

fs: quota: create dedicated workqueue for quotareleasework

There is a kernel panic due to WARNONCE when panicon_warn is set.

This issue occurs when writeback is triggered due to sync call for an opened file(ie, writeback reason is WBREASONSYNC). When f2fs balance is needed at sync path, flush for quotareleasework is triggered. By default quotareleasework is queued to "eventsunbound" queue which does not have WQMEMRECLAIM flag. During f2fs balance "writeback" workqueue tries to flush quotareleasework causing kernel panic due to MEMRECLAIM flag mismatch errors.

This patch creates dedicated workqueue with WQMEMRECLAIM flag for work quotareleasework.

------------[ cut here ]------------ WARNING: CPU: 4 PID: 14867 at kernel/workqueue.c:3721 checkflushdependency+0x13c/0x148 Call trace: checkflushdependency+0x13c/0x148 __flushwork+0xd0/0x398 flushdelayed_work+0x44/0x5c dquotwritebackdquots+0x54/0x318 f2fsdoquotasync+0xb8/0x1a8 f2fswritecheckpoint+0x3cc/0x99c f2fsgc+0x190/0x750 f2fsbalancefs+0x110/0x168 f2fswritesingledatapage+0x474/0x7dc f2fswritedatapages+0x7d0/0xd0c dowritepages+0xe0/0x2f4 _writebacksingleinode+0x44/0x4ac writebacksbinodes+0x30c/0x538 wbwriteback+0xf4/0x440 wbworkfn+0x128/0x5d4 processscheduledworks+0x1c4/0x45c workerthread+0x32c/0x3e8 kthread+0x11c/0x1b0 retfromfork+0x10/0x20 Kernel panic - not syncing: kernel: paniconwarn set ...(CVE-2025-40196)

In the Linux kernel, the following vulnerability has been resolved: media: v4l2-subdev: Fix alloc failure check in v4l2subdevcallstatetry(). v4l2subdevcallstatetry() macro allocates a subdev state with __v4l2subdevstate_alloc(), but does not check the returned value. If __v4l2subdevstatealloc fails, it returns an ERRPTR, and that would cause v4l2subdevcallstatetry() to crash. Add proper error handling to v4l2subdevcallstatetry().(CVE-2025-40207)