The Linux Kernel, the operating system core itself.

Security Fix(es):

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

Bluetooth: hciconn: Use disabledelayedworksync

This makes use of disabledelayedworksync instead canceldelayedworksync as it not only cancel the ongoing work but also disables new submit which is disarable since the object holding the work is about to be freed.(CVE-2024-56591)

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

ipv6: Fix memleak of nhcpcpurthoutput in fibchecknhv6_gw().

fibchecknhv6gw() expects that fib6nhinit() cleans up everything when it fails.

Commit 7dd73168e273 ("ipv6: Always allocate pcpu memory in a fib6nh") moved fibnhcommoninit() before allocpercpugfp() within fib6nhinit() but forgot to add cleanup for fib6nh->nhcommon.nhcpcpurthoutput in case it fails to allocate fib6nh->rt6i_pcpu, resulting in memleak.

Let's call fibnhcommonrelease() and clear nhcpcpurthoutput in the error path.

Note that we can remove the fib6nhrelease() call in nhcreateipv6() later in net-next.git.(CVE-2025-22005)

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

fs/ntfs3: Fix a couple integer overflows on 32bit systems

On 32bit systems the "off + sizeof(struct NTFSDE)" addition can have an integer wrapping issue. Fix it by using sizeadd().(CVE-2025-22081)

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

jfs: Prevent copying of nlink with value 0 from disk inode

syzbot report a deadlock in diFree. [1]

When calling "ioctl$LOOPSETSTATUS64", the offset value passed in is 4, which does not match the mounted loop device, causing the mapping of the mounted loop device to be invalidated.

When creating the directory and creating the inode of iag in diReadSpecial(), read the page of fixed disk inode (AIT) in raw mode in readmetapage(), the metapage data it returns is corrupted, which causes the nlink value of 0 to be assigned to the iag inode when executing copyfrom_dinode(), which ultimately causes a deadlock when entering diFree().

To avoid this, first check the nlink value of dinode before setting iag inode.

[1] WARNING: possible recursive locking detected

6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0 Not tainted

syz-executor301/5309 is trying to acquire lock: ffff888044548920 (&(imap->imaglock[index])){+.+.}-{3:3}, at: diFree+0x37c/0x2fb0 fs/jfs/jfsimap.c:889

but task is already holding lock: ffff888044548920 (&(imap->im_aglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630

other info that might help us debug this: Possible unsafe locking scenario:

   CPU0
   ----

lock(&(imap->imaglock[index])); lock(&(imap->imaglock[index]));

* DEADLOCK *

May be due to missing lock nesting notation

5 locks held by syz-executor301/5309: #0: ffff8880422a4420 (sbwriters#9){.+.+}-{0:0}, at: mntwantwrite+0x3f/0x90 fs/namespace.c:515 #1: ffff88804755b390 (&type->imutexdirkey#6/1){+.+.}-{3:3}, at: inodelocknested include/linux/fs.h:850 [inline] #1: ffff88804755b390 (&type->imutexdirkey#6/1){+.+.}-{3:3}, at: filenamecreate+0x260/0x540 fs/namei.c:4026 #2: ffff888044548920 (&(imap->imaglock[index])){+.+.}-{3:3}, at: diAlloc+0x1b6/0x1630 #3: ffff888044548890 (&imap->imfreelock){+.+.}-{3:3}, at: diNewIAG fs/jfs/jfsimap.c:2460 [inline] #3: ffff888044548890 (&imap->imfreelock){+.+.}-{3:3}, at: diAllocExt fs/jfs/jfsimap.c:1905 [inline] #3: ffff888044548890 (&imap->imfreelock){+.+.}-{3:3}, at: diAllocAG+0x4b7/0x1e50 fs/jfs/jfsimap.c:1669 #4: ffff88804755a618 (&jfsip->rdwrlock/1){++++}-{3:3}, at: diNewIAG fs/jfs/jfsimap.c:2477 [inline] #4: ffff88804755a618 (&jfsip->rdwrlock/1){++++}-{3:3}, at: diAllocExt fs/jfs/jfsimap.c:1905 [inline] #4: ffff88804755a618 (&jfsip->rdwrlock/1){++++}-{3:3}, at: diAllocAG+0x869/0x1e50 fs/jfs/jfs_imap.c:1669

stack backtrace: CPU: 0 UID: 0 PID: 5309 Comm: syz-executor301 Not tainted 6.12.0-rc7-syzkaller-00212-g4a5df3796467 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: <TASK> _dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:120 printdeadlockbug+0x483/0x620 kernel/locking/lockdep.c:3037 checkdeadlock kernel/locking/lockdep.c:3089 [inline] validatechain+0x15e2/0x5920 kernel/locking/lockdep.c:3891 _lockacquire+0x1384/0x2050 kernel/locking/lockdep.c:5202 lockacquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 _mutexlockcommon kernel/locking/mutex.c:608 [inline] _mutexlock+0x136/0xd70 kernel/locking/mutex.c:752 diFree+0x37c/0x2fb0 fs/jfs/jfsimap.c:889 jfsevictinode+0x32d/0x440 fs/jfs/inode.c:156 evict+0x4e8/0x9b0 fs/inode.c:725 diFreeSpecial fs/jfs/jfsimap.c:552 [inline] duplicateIXtree+0x3c6/0x550 fs/jfs/jfsimap.c:3022 diNewIAG fs/jfs/jfsimap.c:2597 [inline] diAllocExt fs/jfs/jfsimap.c:1905 [inline] diAllocAG+0x17dc/0x1e50 fs/jfs/jfsimap.c:1669 diAlloc+0x1d2/0x1630 fs/jfs/jfsimap.c:1590 ialloc+0x8f/0x900 fs/jfs/jfsinode.c:56 jfsmkdir+0x1c5/0xba0 fs/jfs/namei.c:225 vfsmkdir+0x2f9/0x4f0 fs/namei.c:4257 domkdirat+0x264/0x3a0 fs/namei.c:4280 _dosysmkdirat fs/namei.c:4295 [inline] _sesysmkdirat fs/namei.c:4293 [inline] _x64sysmkdirat+0x87/0xa0 fs/namei.c:4293 dosyscallx64 arch/x86/en ---truncated---(CVE-2025-37741)

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

net: ch9200: fix uninitialised access during miinwayrestart

In miinwayrestart() the code attempts to call mii->mdioread which is ch9200mdioread(). ch9200mdioread() utilises a local buffer called "buff", which is initialised with controlread(). However "buff" is conditionally initialised inside control_read():

    if (err == size) {
            memcpy(data, buf, size);
    }

If the condition of "err == size" is not met, then "buff" remains uninitialised. Once this happens the uninitialised "buff" is accessed and returned during ch9200mdioread():

    return (buff[0] | buff[1] << 8);

The problem stems from the fact that ch9200mdioread() ignores the return value of control_read(), leading to uinit-access of "buff".

To fix this we should check the return value of control_read() and return early on error.(CVE-2025-38086)

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

drm/amd/pp: Fix potential NULL pointer dereference in atomctrlinitializemcregtable

The function atomctrlinitializemcregtable() and atomctrlinitializemcregtablev22() does not check the return value of smuatomgetdatatable(). If smuatomgetdatatable() fails to retrieve vram_info, it returns NULL which is later dereferenced.(CVE-2025-38319)

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

tracing: Limit access to parser->buffer when tracegetuser failed

When the length of the string written to setftracefilter exceeds FTRACEBUFFMAX, the following KASAN alarm will be triggered:

BUG: KASAN: slab-out-of-bounds in strsep+0x18c/0x1b0 Read of size 1 at addr ffff0000d00bd5ba by task ash/165

CPU: 1 UID: 0 PID: 165 Comm: ash Not tainted 6.16.0-g6bcdbd62bd56-dirty Hardware name: linux,dummy-virt (DT) Call trace: showstack+0x34/0x50 (C) dumpstacklvl+0xa0/0x158 printaddressdescription.constprop.0+0x88/0x398 printreport+0xb0/0x280 kasanreport+0xa4/0xf0 asanreportload1noabort+0x20/0x30 strsep+0x18c/0x1b0 ftraceprocessregex.isra.0+0x100/0x2d8 ftraceregexrelease+0x484/0x618 _fput+0x364/0xa58 _fput+0x28/0x40 taskworkrun+0x154/0x278 donotifyresume+0x1f0/0x220 el0svc+0xec/0xf0 el0t64synchandler+0xa0/0xe8 el0t64sync+0x1ac/0x1b0

The reason is that tracegetuser will fail when processing a string longer than FTRACEBUFFMAX, but not set the end of parser->buffer to 0. Then an OOB access will be triggered in ftraceregexrelease-> ftraceprocessregex->strsep->strpbrk. We can solve this problem by limiting access to parser->buffer when tracegetuser failed.(CVE-2025-39683)

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

parisc: Revise gateway LWS calls to probe user read access

We use load and stbys,e instructions to trigger memory reference interruptions without writing to memory. Because of the way read access support is implemented, read access interruptions are only triggered at privilege levels 2 and 3. The kernel and gateway page execute at privilege level 0, so this code never triggers a read access interruption. Thus, it is currently possible for user code to execute a LWS compare and swap operation at an address that is read protected at privilege level 3 (PRIV_USER).

Fix this by probing read access rights at privilege level 3 and branching to lws_fault if access isn't allowed.(CVE-2025-39715)

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

iommu/arm-smmu-qcom: Add SM6115 MDSS compatible

Add the SM6115 MDSS compatible to clients compatible list, as it also needs that workaround. Without this workaround, for example, QRB4210 RB2 which is based on SM4250/SM6115 generates a lot of smmu unhandled context faults during boot:

armsmmucontext_fault: 116854 callbacks suppressed arm-smmu c600000.iommu: Unhandled context fault: fsr=0x402, iova=0x5c0ec600, fsynr=0x320021, cbfrsynra=0x420, cb=5 arm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420 arm-smmu c600000.iommu: FSYNR0 = 00320021 [S1CBNDX=50 PNU PLVL=1] arm-smmu c600000.iommu: Unhandled context fault: fsr=0x402, iova=0x5c0d7800, fsynr=0x320021, cbfrsynra=0x420, cb=5 arm-smmu c600000.iommu: FSR = 00000402 [Format=2 TF], SID=0x420

and also failed initialisation of lontium lt9611uxc, gpu and dpu is observed: (binding MDSS components triggered by lt9611uxc have failed)

------------[ cut here ]------------ !aspace WARNING: CPU: 6 PID: 324 at drivers/gpu/drm/msm/msmgemvma.c:130 msmgemvmainit+0x150/0x18c [msm] Modules linked in: ... (long list of modules) CPU: 6 UID: 0 PID: 324 Comm: (udev-worker) Not tainted 6.15.0-03037-gaacc73ceeb8b #4 PREEMPT Hardware name: Qualcomm Technologies, Inc. QRB4210 RB2 (DT) pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : msmgemvmainit+0x150/0x18c [msm] lr : msmgemvmainit+0x150/0x18c [msm] sp : ffff80008144b280 ... Call trace: msmgemvmainit+0x150/0x18c [msm] (P) getvmalocked+0xc0/0x194 [msm] msmgemgetandpiniovarange+0x4c/0xdc [msm] msmgemkernelnew+0x48/0x160 [msm] msmgpuinit+0x34c/0x53c [msm] adrenogpuinit+0x1b0/0x2d8 [msm] a6xxgpuinit+0x1e8/0x9e0 [msm] adrenobind+0x2b8/0x348 [msm] componentbindall+0x100/0x230 msmdrmbind+0x13c/0x3d0 [msm] trytobringupaggregatedevice+0x164/0x1d0 _componentadd+0xa4/0x174 componentadd+0x14/0x20 dsidevattach+0x20/0x34 [msm] dsihostattach+0x58/0x98 [msm] devmmipidsiattach+0x34/0x90 lt9611uxcattachdsi.isra.0+0x94/0x124 [lontiumlt9611uxc] lt9611uxcprobe+0x540/0x5fc [lontiumlt9611uxc] i2cdeviceprobe+0x148/0x2a8 reallyprobe+0xbc/0x2c0 _driverprobedevice+0x78/0x120 driverprobedevice+0x3c/0x154 _driverattach+0x90/0x1a0 busforeachdev+0x68/0xb8 driverattach+0x24/0x30 busadddriver+0xe4/0x208 driverregister+0x68/0x124 i2cregisterdriver+0x48/0xcc lt9611uxcdriverinit+0x20/0x1000 [lontiumlt9611uxc] dooneinitcall+0x60/0x1d4 doinitmodule+0x54/0x1fc loadmodule+0x1748/0x1c8c initmodulefromfile+0x74/0xa0 _arm64sysfinitmodule+0x130/0x2f8 invokesyscall+0x48/0x104 el0svccommon.constprop.0+0xc0/0xe0 doel0svc+0x1c/0x28 el0svc+0x2c/0x80 el0t64synchandler+0x10c/0x138 el0t64sync+0x198/0x19c ---[ end trace 0000000000000000 ]--- msmdpu 5e01000.display-controller: [drm:msmgpuinit [msm]] ERROR could not allocate memptrs: -22 msmdpu 5e01000.display-controller: failed to load adreno gpu platform a400000.remoteproc:glink-edge:apr:service@7:dais: Adding to iommu group 19 msmdpu 5e01000.display-controller: failed to bind 5900000.gpu (ops a3xxops [msm]): -22 msmdpu 5e01000.display-controller: adev bind failed: -22 lt9611uxc 0-002b: failed to attach dsi to host lt9611uxc 0-002b: probe with driver lt9611uxc failed with error -22(CVE-2025-39739)

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

ARM: rockchip: fix kernel hang during smp initialization

In order to bring up secondary CPUs main CPU write trampoline code to SRAM. The trampoline code is written while secondary CPUs are powered on (at least that true for RK3188 CPU). Sometimes that leads to kernel hang. Probably because secondary CPU execute trampoline code while kernel doesn't expect.

The patch moves SRAM initialization step to the point where all secondary CPUs are powered down.

That fixes rarely hangs on RK3188: [ 0.091568] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 [ 0.091996] rockchipsmpprepare_cpus: ncores 4(CVE-2025-39752)

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

usb: core: config: Prevent OOB read in SS endpoint companion parsing

usbparsessendpointcompanion() checks descriptor type before length, enabling a potentially odd read outside of the buffer size.

Fix this up by checking the size first before looking at any of the fields in the descriptor.(CVE-2025-39760)

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

fs/smb: Fix inconsistent refcnt update

A possible inconsistent update of refcount was identified in smb2_compound_op. Such inconsistent update could lead to possible resource leaks.

Why it is a possible bug: 1. In the comment section of the function, it clearly states that the reference to cfile should be dropped after calling this function. 2. Every control flow path would check and drop the reference to cfile, except the patched one. 3. Existing callers would not handle refcount update of cfile if -ENOMEM is returned.

To fix the bug, an extra goto label "out" is added, to make sure that the cleanup logic would always be respected. As the problem is caused by the allocation failure of vars, the cleanup logic between label "finished" and "out" can be safely ignored. According to the definition of function is_replayable_error, the error code of "-ENOMEM" is not recoverable. Therefore, the replay logic also gets ignored.(CVE-2025-39819)

A use-after-free vulnerability exists in the ASUS HID driver of the Linux kernel. After hidhwstart() is called, hidinputconnect() configures the device with the input layer. When processing input and output reports, if the capability bitmaps are not properly set, the hidinputhasbeenpopulated() check fails, leading to the freeing of hidinput and the underlying input device. A malicious HID device (such as an ASUS ROG N-Key keyboard) can trigger this scenario via a specially crafted descriptor, resulting in use-after-free when writing to the name of the freed input device after hidhw_start().(CVE-2025-39824)

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

mm: move page table sync declarations to linux/pgtable.h

During our internal testing, we started observing intermittent boot failures when the machine uses 4-level paging and has a large amount of persistent memory:

BUG: unable to handle page fault for address: ffffe70000000034 #PF: supervisor write access in kernel mode #PF: errorcode(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI RIP: 0010:initsinglepage+0x9/0x6d Call Trace: <TASK> _initzonedevicepage+0x17/0x5d memmapinitzonedevice+0x154/0x1bb pagemaprange+0x2e0/0x40f memremappages+0x10b/0x2f0 devmmemremappages+0x1e/0x60 devdaxprobe+0xce/0x2ec [devicedax] daxbus_probe+0x6d/0xc9 [... snip ...] </TASK>

It turns out that the kernel panics while initializing vmemmap (struct page array) when the vmemmap region spans two PGD entries, because the new PGD entry is only installed in init_mm.pgd, but not in the page tables of other tasks.

And looking at _populatesectionmemmap(): if (vmemmapcanoptimize(altmap, pgmap))
// does not sync top level page tables r = vmemmappopulatecompoundpages(pfn, start, end, nid, pgmap); else
// sync top level page tables in x86 r = vmemmap_populate(start, end, nid, altmap);

In the normal path, vmemmappopulate() in arch/x86/mm/init64.c synchronizes the top level page table (See commit 9b861528a801 ("x86-64, mem: Update all PGDs for direct mapping and vmemmap mapping changes")) so that all tasks in the system can see the new vmemmap area.

However, when vmemmapcanoptimize() returns true, the optimized path skips synchronization of top-level page tables. This is because vmemmappopulatecompound_pages() is implemented in core MM code, which does not handle synchronization of the top-level page tables. Instead, the core MM has historically relied on each architecture to perform this synchronization manually.

We're not the first party to encounter a crash caused by not-sync'd top level page tables: earlier this year, Gwan-gyeong Mun attempted to address the issue [1] [2] after hitting a kernel panic when x86 code accessed the vmemmap area before the corresponding top-level entries were synced. At that time, the issue was believed to be triggered only when struct page was enlarged for debugging purposes, and the patch did not get further updates.

It turns out that current approach of relying on each arch to handle the page table sync manually is fragile because 1) it's easy to forget to sync the top level page table, and 2) it's also easy to overlook that the kernel should not access the vmemmap and direct mapping areas before the sync.

The solution: Make page table sync more code robust and harder to miss

To address this, Dave Hansen suggested [3] [4] introducing {pgd,p4d}populatekernel() for updating kernel portion of the page tables and allow each architecture to explicitly perform synchronization when installing top-level entries. With this approach, we no longer need to worry about missing the sync step, reducing the risk of future regressions.

The new interface reuses existing ARCHPAGETABLESYNCMASK, PGTBLP*DMODIFIED and archsynckernel_mappings() facility used by vmalloc and ioremap to synchronize page tables.

pgdpopulatekernel() looks like this: static inline void pgdpopulatekernel(unsigned long addr, pgdt *pgd, p4dt *p4d) { pgdpopulate(&initmm, pgd, p4d); if (ARCHPAGETABLESYNCMASK & PGTBLPGDMODIFIED) archsynckernel_mappings(addr, addr); }

It is worth noting that vmalloc() and applytorange() carefully synchronizes page tables by calling p*dalloctrack() and archsynckernel_mappings(), and thus they are not affected by ---truncated---(CVE-2025-39844)

In the Linux kernel, a vulnerability was found in the x86/mm/64 architecture regarding page table synchronization. The issue defines ARCHPAGETABLESYNCMASK and archsynckernelmappings() to ensure proper page table synchronization when calling p*dpopulatekernel(). For 5-level paging, synchronization is performed via pgdpopulatekernel(). In 4-level paging, pgdpopulate() is a no-op, so synchronization is instead performed at the P4D level via p4dpopulatekernel(). This fixes intermittent boot failures on systems using 4-level paging and a large amount of persistent memory, as well as crashes in vmemmapsetpmd() caused by accessing vmemmap before syncglobalpgds().(CVE-2025-39845)

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

vxlan: Fix NPD in {arp,neigh}_reduce() when using nexthop objects

When the "proxy" option is enabled on a VXLAN device, the device will suppress ARP requests and IPv6 Neighbor Solicitation messages if it is able to reply on behalf of the remote host. That is, if a matching and valid neighbor entry is configured on the VXLAN device whose MAC address is not behind the "any" remote (0.0.0.0 / ::).

The code currently assumes that the FDB entry for the neighbor's MAC address points to a valid remote destination, but this is incorrect if the entry is associated with an FDB nexthop group. This can result in a NPD [1][3] which can be reproduced using [2][4].

Fix by checking that the remote destination exists before dereferencing it.

[1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 4 UID: 0 PID: 365 Comm: arping Not tainted 6.17.0-rc2-virtme-g2a89cb21162c #2 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:vxlanxmit+0xb58/0x15f0 [...] Call Trace: <TASK> devhardstartxmit+0x5d/0x1c0 _devqueuexmit+0x246/0xfd0 packetsendmsg+0x113a/0x1850 _socksendmsg+0x38/0x70 _syssendto+0x126/0x180 _x64syssendto+0x24/0x30 dosyscall64+0xa4/0x260 entrySYSCALL64after_hwframe+0x4b/0x53

[2] #!/bin/bash

ip address add 192.0.2.1/32 dev lo

ip nexthop add id 1 via 192.0.2.2 fdb ip nexthop add id 10 group 1 fdb

ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 4789 proxy

ip neigh add 192.0.2.3 lladdr 00:11:22:33:44:55 nud perm dev vx0

bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10

arping -b -c 1 -s 192.0.2.1 -I vx0 192.0.2.3

[3] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 13 UID: 0 PID: 372 Comm: ndisc6 Not tainted 6.17.0-rc2-virtmne-g6ee90cb26014 #3 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1v996), BIOS 1.17.0-4.fc41 04/01/2x014 RIP: 0010:vxlanxmit+0x803/0x1600 [...] Call Trace: <TASK> devhardstartxmit+0x5d/0x1c0 _devqueuexmit+0x246/0xfd0 ip6finishoutput2+0x210/0x6c0 ip6finishoutput+0x1af/0x2b0 ip6mroutput+0x92/0x3e0 ip6sendskb+0x30/0x90 rawv6sendmsg+0xe6e/0x12e0 _socksendmsg+0x38/0x70 _syssendto+0x126/0x180 _x64syssendto+0x24/0x30 dosyscall64+0xa4/0x260 entrySYSCALL64after_hwframe+0x4b/0x53 RIP: 0033:0x7f383422ec77

[4] #!/bin/bash

ip address add 2001:db8:1::1/128 dev lo

ip nexthop add id 1 via 2001:db8:1::1 fdb ip nexthop add id 10 group 1 fdb

ip link add name vx0 up type vxlan id 10010 local 2001:db8:1::1 dstport 4789 proxy

ip neigh add 2001:db8:1::3 lladdr 00:11:22:33:44:55 nud perm dev vx0

bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10

ndisc6 -r 1 -s 2001:db8:1::1 -w 1 2001:db8:1::3 vx0(CVE-2025-39850)

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

vxlan: Fix NPD when refreshing an FDB entry with a nexthop object

VXLAN FDB entries can point to either a remote destination or an FDB nexthop group. The latter is usually used in EVPN deployments where learning is disabled.

However, when learning is enabled, an incoming packet might try to refresh an FDB entry that points to an FDB nexthop group and therefore does not have a remote. Such packets should be dropped, but they are only dropped after dereferencing the non-existent remote, resulting in a NPD [1] which can be reproduced using [2].

Fix by dropping such packets earlier. Remove the misleading comment from firstremotercu().

[1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] CPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014 RIP: 0010:vxlansnoop+0x98/0x1e0 [...] Call Trace: <TASK> vxlanencapbypass+0x209/0x240 encapbypassiflocal+0xb1/0x100 vxlanxmitone+0x1375/0x17e0 vxlanxmit+0x6b4/0x15f0 devhardstartxmit+0x5d/0x1c0 _devqueuexmit+0x246/0xfd0 packetsendmsg+0x113a/0x1850 _socksendmsg+0x38/0x70 _syssendto+0x126/0x180 _x64syssendto+0x24/0x30 dosyscall64+0xa4/0x260 entrySYSCALL64after_hwframe+0x4b/0x53

[2] #!/bin/bash

ip address add 192.0.2.1/32 dev lo ip address add 192.0.2.2/32 dev lo

ip nexthop add id 1 via 192.0.2.3 fdb ip nexthop add id 10 group 1 fdb

ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning

bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020 bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10

mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q(CVE-2025-39851)

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

i40e: Fix potential invalid access when MAC list is empty

listfirstentry() never returns NULL - if the list is empty, it still returns a pointer to an invalid object, leading to potential invalid memory access when dereferenced.

Fix this by using listfirstentryornull instead of listfirstentry.(CVE-2025-39853)

A NULL pointer dereference vulnerability was discovered in the TEE subsystem of the Linux kernel. The teeshmput function has a NULL pointer dereference issue: in the _opteedisableshmcache function, regpairtoptr may return a NULL pointer, but when teeshmfree calls teeshm_put, no NULL pointer check is performed, causing system crashes. This vulnerability affects multiple Linux kernel versions and can lead to denial of service.(CVE-2025-39865)

A vulnerability was found in Linux Kernel up to 6.1.152/6.6.106/6.12.47/6.16.7/6.17-rc5. The issue exists in the unpoisonmemory function of the mm/memory-failure module, where it tries to check the PGHWPoison flags of an uninitialized page, triggering VMBUGON_PAGE(PagePoisoned(page)) and causing kernel panic. An attacker can trigger this vulnerability by offlining a memory block and writing an uninitialized page frame number to unpoison-pfn, leading to system crash and impacting confidentiality, integrity, and availability.(CVE-2025-39883)

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

bpf: Tell memcg to use allowspinning=false path in bpftimer_init()

Currently, calling bpfmapkmallocnode() from _bpfasyncinit() can cause various locking issues; see the following stack trace (edited for style) as one example:

... [10.011566] dorawspinlock.cold [10.011570] trytowakeup (5) double-acquiring the same [10.011575] kickpool rqlock, causing a hardlockup [10.011579] queuework [10.011582] queueworkon [10.011585] kernfsnotify [10.011589] cgroupfilenotify [10.011593] trychargememcg (4) memcg accounting raises an [10.011597] objcgroupchargepages MEMCGMAX event [10.011599] objcgroupchargeaccount [10.011600] _memcgslabpostallochook [10.011603] _kmallocnodenoprof ... [10.011611] bpfmapkmallocnode [10.011612] _bpfasyncinit [10.011615] bpftimerinit (3) BPF calls bpftimerinit() [10.011617] bpfprogxxxxxxxxxxxxxxxxfcgrunnable [10.011619] bpfschedextopsrunnable [10.011620] enqueuetaskscx (2) BPF runs with rqlock held [10.011622] enqueuetask [10.011626] ttwudoactivate [10.011629] schedttwupending (1) grabs rq_lock ...

The above was reproduced on bpf-next (b338cf849ec8) by modifying ./tools/schedext/scxflatcg.bpf.c to call bpftimerinit() during ops.runnable(), and hacking the memcg accounting code a bit to make a bpftimerinit() call more likely to raise an MEMCG_MAX event.

We have also run into other similar variants (both internally and on bpf-next), including double-acquiring cgroupfileknlock, the same workerpool::lock, etc.

As suggested by Shakeel, fix this by using _GFPHIGH instead of GFPATOMIC in _bpfasyncinit(), so that e.g. if trychargememcg() raises an MEMCGMAX event, we call _memcgmemoryevent() with @allowspinning=false and avoid calling cgroupfile_notify() there.

Depends on mm patch "memcg: skip cgroupfilenotify if spinning is not allowed": https://lore.kernel.org/bpf/(CVE-2025-39886)

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

sched: Fix schednumafindnthcpu() if mask offline

schednumafindnthcpu() uses a bsearch to look for the 'closest' CPU in scheddomainsnuma_masks and given cpus mask. However they might not intersect if all CPUs in the cpus mask are offline. bsearch will return NULL in that case, bail out instead of dereferencing a bogus pointer.

The previous behaviour lead to this bug when using maxcpus=4 on an rk3399 (LLLLbb) (i.e. booting with all big CPUs offline):

[ 1.422922] Unable to handle kernel paging request at virtual address ffffff8000000000 [ 1.423635] Mem abort info: [ 1.423889] ESR = 0x0000000096000006 [ 1.424227] EC = 0x25: DABT (current EL), IL = 32 bits [ 1.424715] SET = 0, FnV = 0 [ 1.424995] EA = 0, S1PTW = 0 [ 1.425279] FSC = 0x06: level 2 translation fault [ 1.425735] Data abort info: [ 1.425998] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000 [ 1.426499] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 1.426952] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 1.427428] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000004a9f000 [ 1.428038] [ffffff8000000000] pgd=18000000f7fff403, p4d=18000000f7fff403, pud=18000000f7fff403, pmd=0000000000000000 [ 1.429014] Internal error: Oops: 0000000096000006 [#1] SMP [ 1.429525] Modules linked in: [ 1.429813] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.17.0-rc4-dirty #343 PREEMPT [ 1.430559] Hardware name: Pine64 RockPro64 v2.1 (DT) [ 1.431012] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.431634] pc : schednumafindnthcpu+0x2a0/0x488 [ 1.432094] lr : schednumafindnthcpu+0x284/0x488 [ 1.432543] sp : ffffffc084e1b960 [ 1.432843] x29: ffffffc084e1b960 x28: ffffff80078a8800 x27: ffffffc0846eb1d0 [ 1.433495] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 [ 1.434144] x23: 0000000000000000 x22: fffffffffff7f093 x21: ffffffc081de6378 [ 1.434792] x20: 0000000000000000 x19: 0000000ffff7f093 x18: 00000000ffffffff [ 1.435441] x17: 3030303866666666 x16: 66663d736b73616d x15: ffffffc104e1b5b7 [ 1.436091] x14: 0000000000000000 x13: ffffffc084712860 x12: 0000000000000372 [ 1.436739] x11: 0000000000000126 x10: ffffffc08476a860 x9 : ffffffc084712860 [ 1.437389] x8 : 00000000ffffefff x7 : ffffffc08476a860 x6 : 0000000000000000 [ 1.438036] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000 [ 1.438683] x2 : 0000000000000000 x1 : ffffffc0846eb000 x0 : ffffff8000407b68 [ 1.439332] Call trace: [ 1.439559] schednumafindnthcpu+0x2a0/0x488 (P) [ 1.440016] smpcallfunctionany+0xc8/0xd0 [ 1.440416] armv8pmuinit+0x58/0x27c [ 1.440770] armv8cortexa72pmuinit+0x20/0x2c [ 1.441199] armpmudeviceprobe+0x1e4/0x5e8 [ 1.441603] armv8pmudeviceprobe+0x1c/0x28 [ 1.442007] platformprobe+0x5c/0xac [ 1.442347] reallyprobe+0xbc/0x298 [ 1.442683] _driverprobedevice+0x78/0x12c [ 1.443087] driverprobedevice+0xdc/0x160 [ 1.443475] _driverattach+0x94/0x19c [ 1.443833] busforeachdev+0x74/0xd4 [ 1.444190] driverattach+0x24/0x30 [ 1.444525] busadddriver+0xe4/0x208 [ 1.444874] driverregister+0x60/0x128 [ 1.445233] _platformdriverregister+0x24/0x30 [ 1.445662] armv8pmudriverinit+0x28/0x4c [ 1.446059] dooneinitcall+0x44/0x25c [ 1.446416] kernelinitfreeable+0x1dc/0x3bc [ 1.446820] kernelinit+0x20/0x1d8 [ 1.447151] retfromfork+0x10/0x20 [ 1.447493] Code: 90022e21 f000e5f5 910de2b5 2a1703e2 (f8767803) [ 1.448040] ---[ end trace 0000000000000000 ]--- [ 1.448483] note: swapper/0[1] exited with preempt_count 1 [ 1.449047] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b [ 1.449741] SMP: stopping secondary CPUs [ 1.450105] Kernel Offset: disabled [ 1.450419] CPU features: 0x000000,00080000,20002001,0400421b [
---truncated---(CVE-2025-39895)

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

tracing: Silence warning when chunk allocation fails in tracepidwrite

Syzkaller trigger a fault injection warning:

WARNING: CPU: 1 PID: 12326 at tracepointaddfunc+0xbfc/0xeb0 Modules linked in: CPU: 1 UID: 0 PID: 12326 Comm: syz.6.10325 Tainted: G U 6.14.0-rc5-syzkaller #0 Tainted: [U]=USER Hardware name: Google Compute Engine/Google Compute Engine RIP: 0010:tracepointaddfunc+0xbfc/0xeb0 kernel/tracepoint.c:294 Code: 09 fe ff 90 0f 0b 90 0f b6 74 24 43 31 ff 41 bc ea ff ff ff RSP: 0018:ffffc9000414fb48 EFLAGS: 00010283 RAX: 00000000000012a1 RBX: ffffffff8e240ae0 RCX: ffffc90014b78000 RDX: 0000000000080000 RSI: ffffffff81bbd78b RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000001 R12: ffffffffffffffef R13: 0000000000000000 R14: dffffc0000000000 R15: ffffffff81c264f0 FS: 00007f27217f66c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2e80dff8 CR3: 00000000268f8000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> tracepointproberegisterprio+0xc0/0x110 kernel/tracepoint.c:464 registertraceprioschedswitch include/trace/events/sched.h:222 [inline] registerpidevents kernel/trace/traceevents.c:2354 [inline] eventpidwrite.isra.0+0x439/0x7a0 kernel/trace/traceevents.c:2425 vfswrite+0x24c/0x1150 fs/readwrite.c:677 ksyswrite+0x12b/0x250 fs/readwrite.c:731 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcd/0x250 arch/x86/entry/common.c:83 entrySYSCALL64after_hwframe+0x77/0x7f

We can reproduce the warning by following the steps below: 1. echo 8 >> seteventnotracepid. Let tr->filteredpids owns one pid and register schedswitch tracepoint. 2. echo ' ' >> seteventpid, and perform fault injection during chunk allocation of tracepidlistalloc. Let pidlist with no pid and assign to tr->filteredpids. 3. echo ' ' >> seteventpid. Let pidlist is NULL and assign to tr->filteredpids. 4. echo 9 >> seteventpid, will trigger the double register sched_switch tracepoint warning.

The reason is that syzkaller injects a fault into the chunk allocation in tracepidlistalloc, causing a failure in tracepidlistset, which may trigger double register of the same tracepoint. This only occurs when the system is about to crash, but to suppress this warning, let's add failure handling logic to tracepidlist_set.(CVE-2025-39914)

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

cgroup: split cgroupdestroywq into 3 workqueues

A hung task can occur during [1] LTP cgroup testing when repeatedly mounting/unmounting perfevent and netprio controllers with systemd.unifiedcgrouphierarchy=1. The hang manifests in cgrouplockanddrainoffline() during root destruction.

Related case: cgroupfjfunctionperfevent cgroupfjfunction.sh perfevent cgroupfjfunctionnetprio cgroupfjfunction.sh netprio

Call Trace: cgrouplockanddrainoffline+0x14c/0x1e8 cgroupdestroyroot+0x3c/0x2c0 cssfreerworkfn+0x248/0x338 processonework+0x16c/0x3b8 workerthread+0x22c/0x3b0 kthread+0xec/0x100 retfromfork+0x10/0x20

Root Cause:

CPU0 CPU1 mount perfevent umount netprio cgroup1gettree cgroupkillsb rebindsubsystems // root destruction enqueues // cgroupdestroywq // kill all perfevent css // one perfevent css A is dying // css A offline enqueues cgroupdestroywq // root destruction will be executed first cssfreerworkfn cgroupdestroyroot cgrouplockanddrainoffline // some perf descendants are dying // cgroupdestroywq max_active = 1 // waiting for css A to die

Problem scenario: 1. CPU0 mounts perfevent (rebindsubsystems) 2. CPU1 unmounts netprio (cgroupkillsb), queuing root destruction work 3. A dying perfevent CSS gets queued for offline after root destruction 4. Root destruction waits for offline completion, but offline work is blocked behind root destruction in cgroupdestroywq (max_active=1)

Solution: Split cgroupdestroywq into three dedicated workqueues: cgroupofflinewq – Handles CSS offline operations cgroupreleasewq – Manages resource release cgroupfreewq – Performs final memory deallocation

This separation eliminates blocking in the CSS free path while waiting for offline operations to complete.

[1] https://github.com/linux-test-project/ltp/blob/master/runtest/controllers(CVE-2025-39953)