The Linux Kernel, the operating system core itself.

Security Fix(es):

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

iommu/arm-smmu-v3-sva: Fix mm use-after-free

We currently call arm64mmcontext_put() without holding a reference to the mm, which can result in use-after-free. Call mmgrab()/mmdrop() to ensure the mm only gets freed after we unpinned the ASID.(CVE-2022-49426)

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

tty: ngsm: require CAPNETADMIN to attach NGSM0710 ldisc

Any unprivileged user can attach NGSM0710 ldisc, but it requires CAPNET_ADMIN to create a GSM network anyway.

Require initial namespace CAPNETADMIN to do that.(CVE-2023-52880)

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

wifi: mt76: mt7915: fix memory leak in mt7915mcuexit

Always purge mcu skb queues in mt7915mcuexit routine even if mt7915firmwarestate fails.(CVE-2023-53466)

In the Linux kernel, the following vulnerability has been resolved:fou: Fix null-ptr-deref in GRO.We observed a null-ptr-deref in fougroreceive() while shutting downa host. [0]The NULL pointer is sk->skuserdata, and the offset 8 is of protocolin struct fou.When fourelease() is called due to netns dismantle or explicit tunnelteardown, udptunnelsockrelease() sets NULL to sk->skuserdata.Then, the tunnel socket is destroyed after a single RCU grace period.So, in-flight udp4groreceive() could find the socket and execute theFOU GRO handler, where sk->skuserdata could be NULL.Let s use rcudereferenceskuserdata() in foufromsock() and add NULLchecks in FOU GRO handlers.[0]:BUG: kernel NULL pointer dereference, address: 0000000000000008 PF: supervisor read access in kernel mode PF: errorcode(0x0000) - not-present pagePGD 80000001032f4067 P4D 80000001032f4067 PUD 103240067 PMD 0SMP PTICPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.216-204.855.amzn2.x8664 #1Hardware name: Amazon EC2 c5.large/, BIOS 1.0 10/16/2017RIP: 0010:fougroreceive (net/ipv4/fou.c:233) [fou]Code: 41 5f c3 cc cc cc cc e8 e7 2e 69 f4 0f 1f 80 00 00 00 00 0f 1f 44 00 00 49 89 f8 41 54 48 89 f7 48 89 d6 49 8b 80 88 02 00 00 <0f> b6 48 08 0f b7 42 4a 66 25 fd fd 80 cc 02 66 89 42 4a 0f b6 42RSP: 0018:ffffa330c0003d08 EFLAGS: 00010297RAX: 0000000000000000 RBX: ffff93d9e3a6b900 RCX: 0000000000000010RDX: ffff93d9e3a6b900 RSI: ffff93d9e3a6b900 RDI: ffff93dac2e24d08RBP: ffff93d9e3a6b900 R08: ffff93dacbce6400 R09: 0000000000000002R10: 0000000000000000 R11: ffffffffb5f369b0 R12: ffff93dacbce6400R13: ffff93dac2e24d08 R14: 0000000000000000 R15: ffffffffb4edd1c0FS: 0000000000000000(0000) GS:ffff93daee800000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000008 CR3: 0000000102140001 CR4: 00000000007706f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400PKRU: 55555554Call Trace: <IRQ> ? showtraceloglvl (arch/x86/kernel/dumpstack.c:259) ? _diebody.cold (arch/x86/kernel/dumpstack.c:478 arch/x86/kernel/dumpstack.c:420) ? nocontext (arch/x86/mm/fault.c:752) ? excpagefault (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 arch/x86/mm/fault.c:1435 arch/x86/mm/fault.c:1483) ? asmexcpagefault (arch/x86/include/asm/idtentry.h:571) ? fougroreceive (net/ipv4/fou.c:233) [fou] udpgroreceive (include/linux/netdevice.h:2552 net/ipv4/udpoffload.c:559) udp4groreceive (net/ipv4/udpoffload.c:604) inetgroreceive (net/ipv4/afinet.c:1549 (discriminator 7)) devgroreceive (net/core/dev.c:6035 (discriminator 4)) napigroreceive (net/core/dev.c:6170) enacleanrxirq (drivers/amazon/net/ena/enanetdev.c:1558) [ena] enaiopoll (drivers/amazon/net/ena/enanetdev.c:1742) [ena] napipoll (net/core/dev.c:6847) netrxaction (net/core/dev.c:6917) _dosoftirq (arch/x86/include/asm/jumplabel.h:25 include/linux/jumplabel.h:200 include/trace/events/irq.h:142 kernel/softirq.c:299) asmcallirqonstack (arch/x86/entry/entry64.S:809)</IRQ> dosoftirqownstack (arch/x86/include/asm/irqstack.h:27 arch/x86/include/asm/irqstack.h:77 arch/x86/kernel/irq64.c:77) irqexitrcu (kernel/softirq.c:393 kernel/softirq.c:423 kernel/softirq.c:435) commoninterrupt (arch/x86/kernel/irq.c:239) asmcommoninterrupt (arch/x86/include/asm/idtentry.h:626)RIP: 0010:acpiidledoentry (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 drivers/acpi/processoridle.c:114 drivers/acpi/processor_idle.c:575)Code: 8b 15 d1 3c c4 02 ed c3 cc cc cc cc 65 48 8b 04 25 40 ef 01 00 48 8b 00 a8 08 75 eb 0f 1f 44 00 00 0f 00 2d d5 09 55 00 fb f4 <fa> c3 cc cc cc cc e9 be fc ff ff 66 66 2e 0f 1f 84 00 00 00 00 00RSP: 0018:ffffffffb5603e58 EFLAGS: 00000246RAX: 0000000000004000 RBX: ffff93dac0929c00 RCX: ffff93daee833900RDX: ffff93daee800000 RSI: ffff93d---truncated---(CVE-2024-46763)

In the Linux kernel, the following vulnerability has been resolved:f2fs: Require FMODEWRITE for atomic write ioctlsThe F2FS ioctls for starting and committing atomic writes check forinodeownerorcapable(), but this does not give LSMs like SELinux orLandlock an opportunity to deny the write access - if the caller s FSUIDmatches the inode s UID, inodeownerorcapable() immediately returns true.There are scenarios where LSMs want to deny a process the ability to writeparticular files, even files that the FSUID of the process owns; but thiscan currently partially be bypassed using atomic write ioctls in two ways: - F2FSIOCSTARTATOMICREPLACE + F2FSIOCCOMMITATOMICWRITE can truncate an inode to size 0 - F2FSIOCSTARTATOMICWRITE + F2FSIOCABORTATOMICWRITE can revert changes another process concurrently made to a fileFix it by requiring FMODEWRITE for these operations, just like forF2FSIOCMOVE_RANGE. Since any legitimate caller should only be using theseioctls when intending to write into the file, that seems unlikely to breakanything.(CVE-2024-47740)

In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: kTLS, Fix incorrect page refcountingThe kTLS tx handling code is using a mix of getpage() andpagerefinc() APIs to increment the page reference. But on the releasepath (mlx5ektlstxhandleresyncdumpcomp()), only putpage() is used.This is an issue when using pages from large folios: the getpage()references are stored on the folio page while the pageref_inc()references are stored directly in the given page. On release the foliopage will be dereferenced too many times.This was found while doing kTLS testing with sendfile() + ZC when theserved file was read from NFS on a kernel with NFS large folios support(commit 49b29a573da8 ( nfs: add support for large folios )).(CVE-2024-53138)

In the Linux kernel, the following vulnerability has been resolved:x86/xen: don t do PV iret hypercall through hypercall pageInstead of jumping to the Xen hypercall page for doing the irethypercall, directly code the required sequence in xen-asm.S.This is done in preparation of no longer using hypercall page at all,as it has shown to cause problems with speculation mitigations.This is part of XSA-466 / CVE-2024-53241.(CVE-2024-53241)

In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: fix NULL pointer dereference in brcmftxfinalize()On removal of the device or unloading of the kernel module a potential NULLpointer dereference occurs.The following sequence deletes the interface: brcmfdetach() brcmfremoveinterface() brcmfdelif()Inside the brcmfdelif() function the drvr->if2bss[ifidx] is updated toBRCMFBSSIDXINVALID (-1) if the bsscfgidx matches.After brcmfremoveinterface() call the brcmfprotodetach() function iscalled providing the following sequence: brcmfdetach() brcmfprotodetach() brcmfprotomsgbufdetach() brcmfflowringdetach() brcmfmsgbufdeleteflowring() brcmfmsgbufremoveflowring() brcmfflowringdelete() brcmfgetifp() brcmftxfinalize()Since brcmfgetip() can and actually will return NULL in this case thecall to brcmftxfinalize() will result in a NULL pointer dereference insidebrcmftxfinalize() when trying to update ifp->ndev->stats.txerrors.This will only happen if a flowring still has an skb.Although the NULL pointer dereference has only been seen when trying toupdate the tx statistic, all other uses of the ifp pointer have beenguarded as well with an early return if ifp is NULL.(CVE-2025-21744)

In the Linux kernel, the following vulnerability has been resolved:net: let net.core.devweight always be non-zeroThe following problem was encountered during stability test:(NULL netdevice): NAPI poll function processbacklog+0x0/0x530 returned 1, exceeding its budget of 0.------------[ cut here ]------------listadd double add: new=ffff88905f746f48, prev=ffff88905f746f48, next=ffff88905f746e40.WARNING: CPU: 18 PID: 5462 at lib/listdebug.c:35 listaddvalidorreport+0xf3/0x130CPU: 18 UID: 0 PID: 5462 Comm: ping Kdump: loaded Not tainted 6.13.0-rc7+RIP: 0010:listaddvalidorreport+0xf3/0x130Call Trace:? warn+0xcd/0x250? _listaddvalidorreport+0xf3/0x130enqueuetobacklog+0x923/0x1070netifrxinternal+0x92/0x2b0netifrx+0x15/0x170loopbackxmit+0x2ef/0x450devhardstartxmit+0x103/0x490devqueuexmit+0xeac/0x1950ipfinishoutput2+0x6cc/0x1620ipoutput+0x161/0x270ippushpendingframes+0x155/0x1a0rawsendmsg+0xe13/0x1550syssendto+0x3bf/0x4e0x64syssendto+0xdc/0x1b0dosyscall64+0x5b/0x170entrySYSCALL64afterhwframe+0x76/0x7eThe reproduction command is as follows: sysctl -w net.core.devweight=0 ping 127.0.0.1This is because when the napi s weight is set to 0, processbacklog() mayreturn 0 and clear the NAPISTATESCHED bit of napi->state, causing thisnapi to be re-polled in netrxaction() until _dosoftirq() times out.Since the NAPISTATESCHED bit has been cleared, napischedulerps() canbe retriggered in enqueueto_backlog(), causing this issue.Making the napi s weight always non-zero solves this problem.Triggering this issue requires system-wide admin (setting isnot namespaced).(CVE-2025-21806)

In the Linux kernel, the following vulnerability has been resolved:tty: xilinxuartps: split sysrq handlinglockdep detects the following circular locking dependency:CPU 0 CPU 1========================== ============================cdnsuartisr() printk() uartportlock(port) consolelock() cdnsuartconsolewrite() if (!port->sysrq) uartportlock(port) uarthandlebreak() port->sysrq = ... uarthandlesysrqchar() printk() consolelock()The fixed commit attempts to avoid this situation by only taking theport lock in cdnsuartconsolewrite if port->sysrq unset. However, if(as shown above) cdnsuartconsole_write runs before port->sysrq is set,then it will try to take the port lock anyway. This may result in adeadlock.Fix this by splitting sysrq handling into two parts. We use the preparehelper under the port lock and defer handling until we release the lock.(CVE-2025-21820)

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

bpf: Fix kmemleak warning for percpu hashmap

Vlad Poenaru reported the following kmemleak issue:

unreferenced object 0x606fd7c44ac8 (size 32): backtrace (crc 0): pcpuallocnoprof+0x730/0xeb0 bpfmapallocpercpu+0x69/0xc0 preallocinit+0x9d/0x1b0 htabmapalloc+0x363/0x510 mapcreate+0x215/0x3a0 _sysbpf+0x16b/0x3e0 _x64sysbpf+0x18/0x20 dosyscall64+0x7b/0x150 entrySYSCALL64afterhwframe+0x4b/0x53

Further investigation shows the reason is due to not 8-byte aligned store of percpu pointer in htabelemsetptr(): *(void _percpu **)(l->key + key_size) = pptr;

Note that the whole htabelem alignment is 8 (for x8664). If the keysize is 4, that means pptr is stored in a location which is 4 byte aligned but not 8 byte aligned. In mm/kmemleak.c, scanblock() scans the memory based on 8 byte stride, so it won't detect above pptr, hence reporting the memory leak.

In htabmapalloc(), we already have

    htab->elem_size = sizeof(struct htab_elem) +
                      round_up(htab->map.key_size, 8);
    if (percpu)
            htab->elem_size += sizeof(void *);
    else
            htab->elem_size += round_up(htab->map.value_size, 8);

So storing pptr with 8-byte alignment won't cause any problem and can fix kmemleak too.

The issue can be reproduced with bpf selftest as well: 1. Enable CONFIGDEBUGKMEMLEAK config 2. Add a getchar() before skel destroy in testhashmap() in progtests/foreach.c. The purpose is to keep map available so kmemleak can be detected. 3. run './testprogs -t foreach/hash_map &' and a kmemleak should be reported.(CVE-2025-37807)

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

ksmbd: fix Preauh_HashValue race condition

If client send multiple session setup requests to ksmbd, PreauhHashValue race condition could happen. There is no need to free sess->PreauhHashValue at session setup phase. It can be freed together with session at connection termination phase.(CVE-2025-38561)

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

fs: Prevent file descriptor table allocations exceeding INT_MAX

When sysctlnropen is set to a very high value (for example, 1073741816 as set by systemd), processes attempting to use file descriptors near the limit can trigger massive memory allocation attempts that exceed INT_MAX, resulting in a WARNING in mm/slub.c:

WARNING: CPU: 0 PID: 44 at mm/slub.c:5027 _kvmallocnode_noprof+0x21a/0x288

This happens because kvmallocarray() and kvmalloc() check if the requested size exceeds INTMAX and emit a warning when the allocation is not flagged with _GFPNOWARN.

Specifically, when nropen is set to 1073741816 (0x3ffffff8) and a process calls dup2(oldfd, 1073741880), the kernel attempts to allocate: - File descriptor array: 1073741880 * 8 bytes = 8,589,935,040 bytes - Multiple bitmaps: ~400MB - Total allocation size: > 8GB (exceeding INTMAX = 2,147,483,647)

Reproducer: 1. Set /proc/sys/fs/nropen to 1073741816: # echo 1073741816 > /proc/sys/fs/nropen

2. Run a program that uses a high file descriptor:

   include <unistd.h>

   include <sys/resource.h>

   int main() { struct rlimit rlim = {1073741824, 1073741824}; setrlimit(RLIMIT_NOFILE, &rlim); dup2(2, 1073741880); // Triggers the warning return 0; }

3. Observe WARNING in dmesg at mm/slub.c:5027

systemd commit a8b627a introduced automatic bumping of fs.nr_open to the maximum possible value. The rationale was that systems with memory control groups (memcg) no longer need separate file descriptor limits since memory is properly accounted. However, this change overlooked that:

1. The kernel's allocation functions still enforce INT_MAX as a maximum size regardless of memcg accounting
2. Programs and tests that legitimately test file descriptor limits can inadvertently trigger massive allocations
3. The resulting allocations (>8GB) are impractical and will always fail

systemd's algorithm starts with INTMAX and keeps halving the value until the kernel accepts it. On most systems, this results in nropen being set to 1073741816 (0x3ffffff8), which is just under 1GB of file descriptors.

While processes rarely use file descriptors near this limit in normal operation, certain selftests (like tools/testing/selftests/core/unshare_test.c) and programs that test file descriptor limits can trigger this issue.

Fix this by adding a check in allocfdtable() to ensure the requested allocation size does not exceed INTMAX. This causes the operation to fail with -EMFILE instead of triggering a kernel warning and avoids the impractical >8GB memory allocation request.(CVE-2025-39756)

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

i40e: remove read access to debugfs files

The 'command' and 'netdev_ops' debugfs files are a legacy debugging interface supported by the i40e driver since its early days by commit 02e9c290814c ("i40e: debugfs interface").

Both of these debugfs files provide a read handler which is mostly useless, and which is implemented with questionable logic. They both use a static 256 byte buffer which is initialized to the empty string. In the case of the 'command' file this buffer is literally never used and simply wastes space. In the case of the 'netdev_ops' file, the last command written is saved here.

On read, the files contents are presented as the name of the device followed by a colon and then the contents of their respective static buffer. For 'command' this will always be "<device>: ". For 'netdev_ops', this will be "<device>: <last command written>". But note the buffer is shared between all devices operated by this module. At best, it is mostly meaningless information, and at worse it could be accessed simultaneously as there doesn't appear to be any locking mechanism.

We have also recently received multiple reports for both read functions about their use of snprintf and potential overflow that could result in reading arbitrary kernel memory. For the 'command' file, this is definitely impossible, since the static buffer is always zero and never written to. For the 'netdevops' file, it does appear to be possible, if the user carefully crafts the command input, it will be copied into the buffer, which could be large enough to cause snprintf to truncate, which then causes the copyto_user to read beyond the length of the buffer allocated by kzalloc.

A minimal fix would be to replace snprintf() with scnprintf() which would cap the return to the number of bytes written, preventing an overflow. A more involved fix would be to drop the mostly useless static buffers, saving 512 bytes and modifying the read functions to stop needing those as input.

Instead, lets just completely drop the read access to these files. These are debug interfaces exposed as part of debugfs, and I don't believe that dropping read access will break any script, as the provided output is pretty useless. You can find the netdev name through other more standard interfaces, and the 'netdev_ops' interface can easily result in garbage if you issue simultaneous writes to multiple devices at once.

In order to properly remove the i40edbgnetdevopsbuf, we need to refactor its write function to avoid using the static buffer. Instead, use the same logic as the i40edbgcommandwrite, with an allocated buffer. Update the code to use this instead of the static buffer, and ensure we free the buffer on exit. This fixes simultaneous writes to 'netdevops' on multiple devices, and allows us to remove the now unused static buffer along with removing the read access.(CVE-2025-39901)

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

ACPI: video: Fix use-after-free in acpivideoswitch_brightness()

The switchbrightnesswork delayed work accesses device->brightness and device->backlight, freed by acpivideodevunregisterbacklight() during device removal.

If the work executes after acpivideobusunregisterbacklight() frees these resources, it causes a use-after-free when acpivideoswitch_brightness() dereferences device->brightness or device->backlight.

Fix this by calling canceldelayedworksync() for each device's switchbrightnesswork in acpivideobusremovenotifyhandler() after removing the notify handler that queues the work. This ensures the work completes before the memory is freed.

rjw: Changelog edit