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

net: add proper RCU protection to /proc/net/ptype

Yin Fengwei reported an RCU stall in ptypeseqshow() and provided a patch.

Real issue is that ptypeseqnext() and ptypeseqshow() violate RCU rules.

ptypeseqshow() runs under rcureadlock(), and reads pt->dev to get device name without any barrier.

At the same time, concurrent writers can remove a packettype structure (which is correctly freed after an RCU grace period) and clear pt->dev without an RCU grace period.

Define ptypeiterstate to carry a dev pointer along seqnetprivate:

struct ptypeiterstate { struct seqnetprivate p; struct netdevice dev; // added in this patch };

We need to record the device pointer in ptypegetidx() and ptypeseqnext() so that ptypeseqshow() is safe against concurrent pt->dev changes.

We also need to add full RCU protection in ptypeseqnext(). (Missing READONCE() when reading list.next values)

Many thanks to Dong Chenchen for providing a repro.

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

net/sched: clsu32: use skbheaderpointercareful()

skbheaderpointer() does not fully validate negative @offset values.

Use skbheaderpointercareful() instead.

GangMin Kim provided a report and a repro fooling u32classify():

BUG: KASAN: slab-out-of-bounds in u32classify+0x1180/0x11b0 net/sched/clsu32.c:221

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

net: fix segmentation of forwarding fraglist GRO

This patch enhances GSO segment handling by properly checking the SKBGSODODGY flag for fraglist GSO packets, addressing low throughput issues observed when a station accesses IPv4 servers via hotspots with an IPv6-only upstream interface.

Specifically, it fixes a bug in GSO segmentation when forwarding GRO packets containing a fraglist. The function skbsegmentlist cannot correctly process GRO skbs that have been converted by XLAT, since XLAT only translates the header of the head skb. Consequently, skbs in the fraglist may remain untranslated, resulting in protocol inconsistencies and reduced throughput.

To address this, the patch explicitly sets the SKBGSODODGY flag for GSO packets in XLAT's IPv4/IPv6 protocol translation helpers (bpfskbproto4to6 and bpfskbproto6to4). This marks GSO packets as potentially modified after protocol translation. As a result, GSO segmentation will avoid using skbsegmentlist and instead falls back to skbsegment for packets with the SKBGSODODGY flag. This ensures that only safe and fully translated fraglist packets are processed by skbsegmentlist, resolving protocol inconsistencies and improving throughput when forwarding GRO packets converted by XLAT.

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

iouring/io-wq: check IOWQBITEXIT inside work run loop

Currently this is checked before running the pending work. Normally this is quite fine, as work items either end up blocking (which will create a new worker for other items), or they complete fairly quickly. But syzbot reports an issue where io-wq takes seemingly forever to exit, and with a bit of debugging, this turns out to be because it queues a bunch of big (2GB - 4096b) reads with a /dev/msr file. Since this file type doesn't support ->readiter(), looprwiter() ends up handling them. Each read returns 16MB of data read, which takes 20 (!!) seconds. With a bunch of these pending, processing the whole chain can take a long time. Easily longer than the syzbot uninterruptible sleep timeout of 140 seconds. This then triggers a complaint off the io-wq exit path:

INFO: task syz.4.135:6326 blocked for more than 143 seconds. Not tainted syzkaller #0 Blocked by coredump. "echo 0 > /proc/sys/kernel/hungtasktimeoutsecs" disables this message. task:syz.4.135 state:D stack:26824 pid:6326 tgid:6324 ppid:5957 taskflags:0x400548 flags:0x00080000 Call Trace: <TASK> contextswitch kernel/sched/core.c:5256 [inline] schedule+0x1139/0x6150 kernel/sched/core.c:6863 scheduleloop kernel/sched/core.c:6945 [inline] schedule+0xe7/0x3a0 kernel/sched/core.c:6960 scheduletimeout+0x257/0x290 kernel/time/sleeptimeout.c:75 dowaitforcommon kernel/sched/completion.c:100 [inline] waitforcommon+0x2fc/0x4e0 kernel/sched/completion.c:121 iowqexitworkers iouring/io-wq.c:1328 [inline] iowqputandexit+0x271/0x8a0 iouring/io-wq.c:1356 iouringcleantctx+0x10d/0x190 iouring/tctx.c:203 iouringcancelgeneric+0x69c/0x9a0 iouring/cancel.c:651 iouringfilescancel include/linux/iouring.h:19 [inline] doexit+0x2ce/0x2bd0 kernel/exit.c:911 dogroupexit+0xd3/0x2a0 kernel/exit.c:1112 getsignal+0x2671/0x26d0 kernel/signal.c:3034 archdosignalorrestart+0x8f/0x7e0 arch/x86/kernel/signal.c:337 exittousermodeloop kernel/entry/common.c:41 [inline] exittousermodeloop+0x8c/0x540 kernel/entry/common.c:75 exittousermodeprepare include/linux/irq-entry-common.h:226 [inline] syscallexittousermodeprepare include/linux/irq-entry-common.h:256 [inline] syscallexittousermodework include/linux/entry-common.h:159 [inline] syscallexittousermode include/linux/entry-common.h:194 [inline] dosyscall64+0x4ee/0xf80 arch/x86/entry/syscall64.c:100 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7fa02738f749 RSP: 002b:00007fa0281ae0e8 EFLAGS: 00000246 ORIGRAX: 00000000000000ca RAX: fffffffffffffe00 RBX: 00007fa0275e6098 RCX: 00007fa02738f749 RDX: 0000000000000000 RSI: 0000000000000080 RDI: 00007fa0275e6098 RBP: 00007fa0275e6090 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fa0275e6128 R14: 00007fff14e4fcb0 R15: 00007fff14e4fd98

There's really nothing wrong here, outside of processing these reads will take a LONG time. However, we can speed up the exit by checking the IOWQBITEXIT inside the ioworkerhandlework() loop, as syzbot will exit the ring after queueing up all of these reads. Then once the first item is processed, io-wq will simply cancel the rest. That should avoid syzbot running into this complaint again.

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

netfilter: nftables: fix inverted genmask check in nftmapcatchallactivate()

nftmapcatchallactivate() has an inverted element activity check compared to its non-catchall counterpart nftmapelemactivate() and compared to what is logically required.

nftmapcatchallactivate() is called from the abort path to re-activate catchall map elements that were deactivated during a failed transaction. It should skip elements that are already active (they don't need re-activation) and process elements that are inactive (they need to be restored). Instead, the current code does the opposite: it skips inactive elements and processes active ones.

Compare the non-catchall activate callback, which is correct:

nftmapelemactivate(): if (nftsetelemactive(ext, iter->genmask)) return 0; / skip active, process inactive /

With the buggy catchall version:

nftmapcatchallactivate(): if (!nftsetelemactive(ext, genmask)) continue; / skip inactive, process active /

The consequence is that when a DELSET operation is aborted, nftsetelemdataactivate() is never called for the catchall element. For NFTGOTO verdict elements, this means nftdatahold() is never called to restore the chain->use reference count. Each abort cycle permanently decrements chain->use. Once chain->use reaches zero, DELCHAIN succeeds and frees the chain while catchall verdict elements still reference it, resulting in a use-after-free.

This is exploitable for local privilege escalation from an unprivileged user via user namespaces + nftables on distributions that enable CONFIGUSERNS and CONFIGNFTABLES.

Fix by removing the negation so the check matches nftmapelemactivate(): skip active elements, process inactive ones.

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

scsi: core: Wake up the error handler when final completions race against each other

The fragile ordering between marking commands completed or failed so that the error handler only wakes when the last running command completes or times out has race conditions. These race conditions can cause the SCSI layer to fail to wake the error handler, leaving I/O through the SCSI host stuck as the error state cannot advance.

First, there is an memory ordering issue within scsidechostbusy(). The write which clears SCMDSTATEINFLIGHT may be reordered with reads counting in scsihostbusy(). While the local CPU will see its own write, reordering can allow other CPUs in scsidechostbusy() or scsiehinchostfailed() to see a raised busy count, causing no CPU to see a host busy equal to the hostfailed count.

This race condition can be prevented with a memory barrier on the error path to force the write to be visible before counting host busy commands.

Second, there is a general ordering issue with scsiehinchostfailed(). By counting busy commands before incrementing hostfailed, it can race with a final command in scsidechostbusy(), such that scsidechostbusy() does not see hostfailed incremented but scsiehinchostfailed() counts busy commands before SCMDSTATEINFLIGHT is cleared by scsidechostbusy(), resulting in neither waking the error handler task.

This needs the call to scsihostbusy() to be moved after hostfailed is incremented to close the race condition.

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

ipvlan: Make the addrslock be per port

Make the addrslock be per port, not per ipvlan dev.

Initial code seems to be written in the assumption, that any address change must occur under RTNL. But it is not so for the case of IPv6. So

1) Introduce per-port addrslock.

2) It was needed to fix places where it was forgotten to take lock (ipvlanopen/ipvlanclose)

This appears to be a very minor problem though. Since it's highly unlikely that ipvlanaddaddr() will be called on 2 CPU simultaneously. But nevertheless, this could cause:

1) False-negative of ipvlanaddrbusy(): one interface iterated through all port->ipvlans + ipvlan->addrs under some ipvlan spinlock, and another added IP under its own lock. Though this is only possible for IPv6, since looks like only ipvlanaddr6event() can be called without rtnllock.

2) Race since ipvlanhtaddradd(port) is called under different ipvlan->addrslock locks

This should not affect performance, since add/remove IP is a rare situation and spinlock is not taken on fast paths.

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

mm/hugetlb: fix hugetlbpmdshared()

Patch series "mm/hugetlb: fixes for PMD table sharing (incl. using mmugather)", v3.

One functional fix, one performance regression fix, and two related comment fixes.

I cleaned up my prototype I recently shared [1] for the performance fix, deferring most of the cleanups I had in the prototype to a later point. While doing that I identified the other things.

The goal of this patch set is to be backported to stable trees "fairly" easily. At least patch #1 and #4.

Patch #1 fixes hugetlbpmdshared() not detecting any sharing Patch #2 + #3 are simple comment fixes that patch #4 interacts with. Patch #4 is a fix for the reported performance regression due to excessive IPI broadcasts during fork()+exit().

The last patch is all about TLB flushes, IPIs and mmugather. Read: complicated

There are plenty of cleanups in the future to be had + one reasonable optimization on x86. But that's all out of scope for this series.

Runtime tested, with a focus on fixing the performance regression using the original reproducer [2] on x86.

This patch (of 4):

We switched from (wrongly) using the page count to an independent shared count. Now, shared page tables have a refcount of 1 (excluding speculative references) and instead use ptdesc->ptsharecount to identify sharing.

We didn't convert hugetlbpmdshared(), so right now, we would never detect a shared PMD table as such, because sharing/unsharing no longer touches the refcount of a PMD table.

Page migration, like mbind() or migratepages() would allow for migrating folios mapped into such shared PMD tables, even though the folios are not exclusive. In smaps we would account them as "private" although they are "shared", and we would be wrongly setting the PMMMAPEXCLUSIVE in the pagemap interface.

Fix it by properly using ptdescpmdisshared() in hugetlbpmdshared().

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

gue: Fix skb memleak with inner IP protocol 0.

syzbot reported skb memleak below. [0]

The repro generated a GUE packet with its inner protocol 0.

gueudprecv() returns -guehdr->protoctype for "resubmit" in ipprotocoldeliverrcu(), but this only works with non-zero protocol number.

Let's drop such packets.

Note that 0 is a valid number (IPv6 Hop-by-Hop Option).

I think it is not practical to encap HOPOPT in GUE, so once someone starts to complain, we could pass down a resubmit flag pointer to distinguish two zeros from the upper layer:

no error resubmit HOPOPT

[0] BUG: memory leak unreferenced object 0xffff888109695a00 (size 240): comm "syz.0.17", pid 6088, jiffies 4294943096 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 40 c2 10 81 88 ff ff 00 00 00 00 00 00 00 00 .@.............. backtrace (crc a84b336f): kmemleakallocrecursive include/linux/kmemleak.h:44 [inline] slabpostallochook mm/slub.c:4958 [inline] slaballocnode mm/slub.c:5263 [inline] kmemcacheallocnoprof+0x3b4/0x590 mm/slub.c:5270 buildskb+0x23/0x60 net/core/skbuff.c:474 buildskb+0x20/0x190 net/core/skbuff.c:490 tunbuildskb drivers/net/tun.c:1541 [inline] tunbuildskb+0x4a1/0xa40 drivers/net/tun.c:1636 tungetuser+0xc12/0x2030 drivers/net/tun.c:1770 tunchrwriteiter+0x71/0x120 drivers/net/tun.c:1999 newsyncwrite fs/readwrite.c:593 [inline] vfswrite+0x45d/0x710 fs/readwrite.c:686 ksyswrite+0xa7/0x170 fs/readwrite.c:738 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xa4/0xf80 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f

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

scsi: xen: scsiback: Fix potential memory leak in scsibackremove()

Memory allocated for struct vscsiblkinfo in scsibackprobe() is not freed in scsibackremove() leading to potential memory leaks on remove, as well as in the scsibackprobe() error paths. Fix that by freeing it in scsibackremove().

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

vsock/virtio: cap TX credit to local buffer size

The virtio transports derives its TX credit directly from peerbufalloc, which is set from the remote endpoint's SOVMSOCKETSBUFFERSIZE value.

On the host side this means that the amount of data we are willing to queue for a connection is scaled by a guest-chosen buffer size, rather than the host's own vsock configuration. A malicious guest can advertise a large buffer and read slowly, causing the host to allocate a correspondingly large amount of skbuff memory. The same thing would happen in the guest with a malicious host, since virtio transports share the same code base.

Introduce a small helper, virtiotransporttxbufsize(), that returns min(peerbufalloc, bufalloc), and use it wherever we consume peerbufalloc.

This ensures the effective TX window is bounded by both the peer's advertised buffer and our own bufalloc (already clamped to buffermaxsize via SOVMSOCKETSBUFFERMAXSIZE), so a remote peer cannot force the other to queue more data than allowed by its own vsock settings.

On an unpatched Ubuntu 22.04 host (~64 GiB RAM), running a PoC with 32 guest vsock connections advertising 2 GiB each and reading slowly drove Slab/SUnreclaim from ~0.5 GiB to ~57 GiB; the system only recovered after killing the QEMU process. That said, if QEMU memory is limited with cgroups, the maximum memory used will be limited.

With this patch applied:

Before: MemFree: ~61.6 GiB Slab: ~142 MiB SUnreclaim: ~117 MiB

After 32 high-credit connections: MemFree: ~61.5 GiB Slab: ~178 MiB SUnreclaim: ~152 MiB

Only ~35 MiB increase in Slab/SUnreclaim, no host OOM, and the guest remains responsive.

Compatibility with non-virtio transports:

- VMCI uses the AFVSOCK buffer knobs to size its queue pairs per socket based on the local vsk->buffer values; the remote side cannot enlarge those queues beyond what the local endpoint configured.

- Hyper-V's vsock transport uses fixed-size VMBus ring buffers and an MTU bound; there is no peer-controlled credit field comparable to peerbufalloc, and the remote endpoint cannot drive in-flight kernel memory above those ring sizes.

- The loopback path reuses virtiotransportcommon.c, so it naturally follows the same semantics as the virtio transport.

This change is limited to virtiotransportcommon.c and thus affects virtio-vsock, vhost-vsock, and loopback, bringing them in line with the "remote window intersected with local policy" behaviour that VMCI and Hyper-V already effectively have.

[Stefano: small adjustments after changing the previous patch] [Stefano: tweak the commit message]

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

be2net: Fix NULL pointer dereference in becmdgetmacfromlist

When the parameter pmacidvalid argument of becmdgetmacfromlist() is set to false, the driver may request the PMACID from the firmware of the network card, and this function will store that PMACID at the provided address pmacid. This is the contract of this function.

However, there is a location within the driver where both pmacidvalid == false and pmacid == NULL are being passed. This could result in dereferencing a NULL pointer.

To resolve this issue, it is necessary to pass the address of a stub variable to the function.

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

fou: Don't allow 0 for FOUATTRIPPROTO.

fouudprecv() has the same problem mentioned in the previous patch.

If FOUATTRIPPROTO is set to 0, skb is not freed by fouudprecv() nor "resubmit"-ted in ipprotocoldeliverrcu().

Let's forbid 0 for FOUATTRIPPROTO.

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

crypto: authencesn - reject too-short AAD (assoclen<8) to match ESP/ESN spec

authencesn assumes an ESP/ESN-formatted AAD. When assoclen is shorter than the minimum expected length, cryptoauthencesndecrypt() can advance past the end of the destination scatterlist and trigger a NULL pointer dereference in scatterwalkmapandcopy(), leading to a kernel panic (DoS).

Add a minimum AAD length check to fail fast on invalid inputs.

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

dmaengine: qcom: gpi: Fix memory leak in gpiperipheralconfig()

Fix a memory leak in gpiperipheralconfig() where the original memory pointed to by gchan->config could be lost if krealloc() fails.

The issue occurs when: 1. gchan->config points to previously allocated memory 2. krealloc() fails and returns NULL 3. The function directly assigns NULL to gchan->config, losing the reference to the original memory 4. The original memory becomes unreachable and cannot be freed

Fix this by using a temporary variable to hold the krealloc() result and only updating gchan->config when the allocation succeeds.

Found via static analysis and code review.

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

net: marvell: prestera: fix NULL dereference on devlinkalloc() failure

devlinkalloc() may return NULL on allocation failure, but presteradevlinkalloc() unconditionally calls devlinkpriv() on the returned pointer.

This leads to a NULL pointer dereference if devlink allocation fails. Add a check for a NULL devlink pointer and return NULL early to avoid the crash.

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

ipv4: ipgre: make ipgreheader() robust

Analog to commit db5b4e39c4e6 ("ip6gre: make ip6greheader() robust")

Over the years, syzbot found many ways to crash the kernel in ipgreheader() [1].

This involves team or bonding drivers ability to dynamically change their dev->neededheadroom and/or dev->hardheaderlen

In this particular crash mldnewpack() allocated an skb with a too small reserve/headroom, and by the time mldsendpack() was called, syzbot managed to attach an ipgre device.

[1] skbuff: skbunderpanic: text:ffffffff89ea3cb7 len:2030915468 put:2030915372 head:ffff888058b43000 data:ffff887fdfa6e194 tail:0x120 end:0x6c0 dev:team0 kernel BUG at net/core/skbuff.c:213 ! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 1 UID: 0 PID: 1322 Comm: kworker/1:9 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 Workqueue: mld mldifcwork RIP: 0010:skbpanic+0x157/0x160 net/core/skbuff.c:213 Call Trace: <TASK> skbunderpanic net/core/skbuff.c:223 [inline] skbpush+0xc3/0xe0 net/core/skbuff.c:2641 ipgreheader+0x67/0x290 net/ipv4/ipgre.c:897 devhardheader include/linux/netdevice.h:3436 [inline] neighconnectedoutput+0x286/0x460 net/core/neighbour.c:1618 NFHOOKCOND include/linux/netfilter.h:307 [inline] ip6output+0x340/0x550 net/ipv6/ip6output.c:247 NFHOOK+0x9e/0x380 include/linux/netfilter.h:318 mldsendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855 mldsendcr net/ipv6/mcast.c:2154 [inline] mldifcwork+0x83e/0xd60 net/ipv6/mcast.c:2693 processonework kernel/workqueue.c:3257 [inline] processscheduledworks+0xad1/0x1770 kernel/workqueue.c:3340 workerthread+0x8a0/0xda0 kernel/workqueue.c:3421 kthread+0x711/0x8a0 kernel/kthread.c:463 retfromfork+0x510/0xa50 arch/x86/kernel/process.c:158 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:246

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

ipv6: Fix use-after-free in inet6addrdel().

syzbot reported use-after-free of inet6ifaddr in inet6addrdel(). [0]

The cited commit accidentally moved ipv6deladdr() for mngtmpaddr before reading its ifp->flags for temporary addresses in inet6addrdel().

Let's move ipv6deladdr() down to fix the UAF.

[0]: BUG: KASAN: slab-use-after-free in inet6addrdel.constprop.0+0x67a/0x6b0 net/ipv6/addrconf.c:3117 Read of size 4 at addr ffff88807b89c86c by task syz.3.1618/9593

CPU: 0 UID: 0 PID: 9593 Comm: syz.3.1618 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 Call Trace: <TASK> dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x116/0x1f0 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0xcd/0x630 mm/kasan/report.c:482 kasanreport+0xe0/0x110 mm/kasan/report.c:595 inet6addrdel.constprop.0+0x67a/0x6b0 net/ipv6/addrconf.c:3117 addrconfdelifaddr+0x11e/0x190 net/ipv6/addrconf.c:3181 inet6ioctl+0x1e5/0x2b0 net/ipv6/afinet6.c:582 sockdoioctl+0x118/0x280 net/socket.c:1254 sockioctl+0x227/0x6b0 net/socket.c:1375 vfsioctl fs/ioctl.c:51 [inline] dosysioctl fs/ioctl.c:597 [inline] sesysioctl fs/ioctl.c:583 [inline] x64sysioctl+0x18e/0x210 fs/ioctl.c:583 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xcd/0xf80 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f164cf8f749 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f164de64038 EFLAGS: 00000246 ORIGRAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f164d1e5fa0 RCX: 00007f164cf8f749 RDX: 0000200000000000 RSI: 0000000000008936 RDI: 0000000000000003 RBP: 00007f164d013f91 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007f164d1e6038 R14: 00007f164d1e5fa0 R15: 00007ffde15c8288 </TASK>

Allocated by task 9593: kasansavestack+0x33/0x60 mm/kasan/common.c:56 kasansavetrack+0x14/0x30 mm/kasan/common.c:77 poisonkmallocredzone mm/kasan/common.c:397 [inline] kasankmalloc+0xaa/0xb0 mm/kasan/common.c:414 kmallocnoprof include/linux/slab.h:957 [inline] kzallocnoprof include/linux/slab.h:1094 [inline] ipv6addaddr+0x4e3/0x2010 net/ipv6/addrconf.c:1120 inet6addradd+0x256/0x9b0 net/ipv6/addrconf.c:3050 addrconfaddifaddr+0x1fc/0x450 net/ipv6/addrconf.c:3160 inet6ioctl+0x103/0x2b0 net/ipv6/afinet6.c:580 sockdoioctl+0x118/0x280 net/socket.c:1254 sockioctl+0x227/0x6b0 net/socket.c:1375 vfsioctl fs/ioctl.c:51 [inline] dosysioctl fs/ioctl.c:597 [inline] sesysioctl fs/ioctl.c:583 [inline] x64sysioctl+0x18e/0x210 fs/ioctl.c:583 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xcd/0xf80 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f

Freed by task 6099: kasansavestack+0x33/0x60 mm/kasan/common.c:56 kasansavetrack+0x14/0x30 mm/kasan/common.c:77 kasansavefreeinfo+0x3b/0x60 mm/kasan/generic.c:584 poisonslabobject mm/kasan/common.c:252 [inline] kasanslabfree+0x5f/0x80 mm/kasan/common.c:284 kasanslabfree include/linux/kasan.h:234 [inline] slabfreehook mm/slub.c:2540 [inline] slabfreefreelisthook mm/slub.c:2569 [inline] slabfreebulk mm/slub.c:6696 [inline] kmemcachefreebulk mm/slub.c:7383 [inline] kmemcachefreebulk+0x2bf/0x680 mm/slub.c:7362 kfreebulk include/linux/slab.h:830 [inline] kvfreercubulk+0x1b7/0x1e0 mm/slabcommon.c:1523 kvfreercudrainready mm/slabcommon.c:1728 [inline] kfreercumonitor+0x1d0/0x2f0 mm/slabcommon.c:1801 processonework+0x9ba/0x1b20 kernel/workqueue.c:3257 processscheduledworks kernel/workqu ---truncated---

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

x86/fpu: Clear XSTATEBV[i] in guest XSAVE state whenever XFD[i]=1

When loading guest XSAVE state via KVMSETXSAVE, and when updating XFD in response to a guest WRMSR, clear XFD-disabled features in the saved (or to be restored) XSTATEBV to ensure KVM doesn't attempt to load state for features that are disabled via the guest's XFD. Because the kernel executes XRSTOR with the guest's XFD, saving XSTATEBV[i]=1 with XFD[i]=1 will cause XRSTOR to #NM and panic the kernel.

E.g. if fpuupdateguestxfd() sets XFD without clearing XSTATEBV:

------------[ cut here ]------------ WARNING: arch/x86/kernel/traps.c:1524 at excdevicenotavailable+0x101/0x110, CPU#29: amxtest/848 Modules linked in: kvmintel kvm irqbypass CPU: 29 UID: 1000 PID: 848 Comm: amxtest Not tainted 6.19.0-rc2-ffa07f7fd437-x86amxnmxfdnoninit-vm #171 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:excdevicenotavailable+0x101/0x110 Call Trace: <TASK> asmexcdevicenotavailable+0x1a/0x20 RIP: 0010:restorefpregsfromfpstate+0x36/0x90 switchfpureturn+0x4a/0xb0 kvmarchvcpuioctlrun+0x1245/0x1e40 [kvm] kvmvcpuioctl+0x2c3/0x8f0 [kvm] x64sysioctl+0x8f/0xd0 dosyscall64+0x62/0x940 entrySYSCALL64afterhwframe+0x4b/0x53 </TASK> ---[ end trace 0000000000000000 ]---

This can happen if the guest executes WRMSR(MSRIA32XFD) to set XFD[18] = 1, and a host IRQ triggers kernelfpubegin() prior to the vmexit handler's call to fpuupdateguestxfd().

and if userspace stuffs XSTATEBV[i]=1 via KVMSETXSAVE:

------------[ cut here ]------------ WARNING: arch/x86/kernel/traps.c:1524 at excdevicenotavailable+0x101/0x110, CPU#14: amxtest/867 Modules linked in: kvmintel kvm irqbypass CPU: 14 UID: 1000 PID: 867 Comm: amxtest Not tainted 6.19.0-rc2-2dace9faccd6-x86amxnmxfdnoninit-vm #168 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:excdevicenotavailable+0x101/0x110 Call Trace: <TASK> asmexcdevicenotavailable+0x1a/0x20 RIP: 0010:restorefpregsfromfpstate+0x36/0x90 fpuswapkvmfpstate+0x6b/0x120 kvmloadguestfpu+0x30/0x80 [kvm] kvmarchvcpuioctlrun+0x85/0x1e40 [kvm] kvmvcpuioctl+0x2c3/0x8f0 [kvm] x64sysioctl+0x8f/0xd0 dosyscall64+0x62/0x940 entrySYSCALL64afterhwframe+0x4b/0x53 </TASK> ---[ end trace 0000000000000000 ]---

The new behavior is consistent with the AMX architecture. Per Intel's SDM, XSAVE saves XSTATEBV as '0' for components that are disabled via XFD (and non-compacted XSAVE saves the initial configuration of the state component):

If XSAVE, XSAVEC, XSAVEOPT, or XSAVES is saving the state component i, the instruction does not generate #NM when XCR0[i] = IA32XFD[i] = 1; instead, it operates as if XINUSE[i] = 0 (and the state component was in its initial state): it saves bit i of XSTATEBV field of the XSAVE header as 0; in addition, XSAVE saves the initial configuration of the state component (the other instructions do not save state component i).

Alternatively, KVM could always do XRSTOR with XFD=0, e.g. by using a constant XFD based on the set of enabled features when XSAVEing for a struct fpuguest. However, having XSTATEBV[i]=1 for XFD-disabled features can only happen in the above interrupt case, or in similar scenarios involving preemption on preemptible kernels, because fpuswapkvmfpstate()'s call to savefpregstofpstate() saves the outgoing FPU state with the current XFD; and that is (on all but the first WRMSR to XFD) the guest XFD.

Therefore, XFD can only go out of sync with XSTATEBV in the above interrupt case, or in similar scenarios involving preemption on preemptible kernels, and it we can consider it (de facto) part of KVM ABI that KVMGETXSAVE returns XSTATEBV[i]=0 for XFD-disabled features.

[Move clea ---truncated---

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

ip6tunnel: use skbvlaninetprepare() in ip6tnlrcv()

Blamed commit did not take care of VLAN encapsulations as spotted by syzbot [1].

Use skbvlaninetprepare() instead of pskbinetmaypull().

[1] BUG: KMSAN: uninit-value in INETECNdecapsulate include/net/inetecn.h:253 [inline] BUG: KMSAN: uninit-value in INETECNdecapsulate include/net/inetecn.h:275 [inline] BUG: KMSAN: uninit-value in IP6ECNdecapsulate+0x7a8/0x1fa0 include/net/inetecn.h:321 INETECNdecapsulate include/net/inetecn.h:253 [inline] INETECNdecapsulate include/net/inetecn.h:275 [inline] IP6ECNdecapsulate+0x7a8/0x1fa0 include/net/inetecn.h:321 ip6ip6dscpecndecapsulate+0x16f/0x1b0 net/ipv6/ip6tunnel.c:729 ip6tnlrcv+0xed9/0x1b50 net/ipv6/ip6tunnel.c:860 ip6tnlrcv+0xc3/0x100 net/ipv6/ip6tunnel.c:903 grercv+0x1529/0x1b90 net/ipv6/ip6gre.c:-1 ip6protocoldeliverrcu+0x1c89/0x2c60 net/ipv6/ip6input.c:438 ip6inputfinish+0x1f4/0x4a0 net/ipv6/ip6input.c:489 NFHOOK include/linux/netfilter.h:318 [inline] ip6input+0x9c/0x330 net/ipv6/ip6input.c:500 ip6mcinput+0x7ca/0xc10 net/ipv6/ip6input.c:590 dstinput include/net/dst.h:474 [inline] ip6rcvfinish+0x958/0x990 net/ipv6/ip6input.c:79 NFHOOK include/linux/netfilter.h:318 [inline] ipv6rcv+0xf1/0x3c0 net/ipv6/ip6input.c:311 netifreceiveskbonecore net/core/dev.c:6139 [inline] netifreceiveskb+0x1df/0xac0 net/core/dev.c:6252 netifreceiveskbinternal net/core/dev.c:6338 [inline] netifreceiveskb+0x57/0x630 net/core/dev.c:6397 tunrxbatched+0x1df/0x980 drivers/net/tun.c:1485 tungetuser+0x5c0e/0x6c60 drivers/net/tun.c:1953 tunchrwriteiter+0x3e9/0x5c0 drivers/net/tun.c:1999 newsyncwrite fs/readwrite.c:593 [inline] vfswrite+0xbe2/0x15d0 fs/readwrite.c:686 ksyswrite fs/readwrite.c:738 [inline] dosyswrite fs/readwrite.c:749 [inline] sesyswrite fs/readwrite.c:746 [inline] x64syswrite+0x1fb/0x4d0 fs/readwrite.c:746 x64syscall+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls64.h:2 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xd3/0xf80 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f

Uninit was created at: slabpostallochook mm/slub.c:4960 [inline] slaballocnode mm/slub.c:5263 [inline] kmemcacheallocnodenoprof+0x9e7/0x17a0 mm/slub.c:5315 kmallocreserve+0x13c/0x4b0 net/core/skbuff.c:586 allocskb+0x805/0x1040 net/core/skbuff.c:690 allocskb include/linux/skbuff.h:1383 [inline] allocskbwithfrags+0xc5/0xa60 net/core/skbuff.c:6712 sockallocsendpskb+0xacc/0xc60 net/core/sock.c:2995 tunallocskb drivers/net/tun.c:1461 [inline] tungetuser+0x1142/0x6c60 drivers/net/tun.c:1794 tunchrwriteiter+0x3e9/0x5c0 drivers/net/tun.c:1999 newsyncwrite fs/readwrite.c:593 [inline] vfswrite+0xbe2/0x15d0 fs/readwrite.c:686 ksyswrite fs/readwrite.c:738 [inline] dosyswrite fs/readwrite.c:749 [inline] sesyswrite fs/readwrite.c:746 [inline] x64syswrite+0x1fb/0x4d0 fs/readwrite.c:746 x64syscall+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls64.h:2 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xd3/0xf80 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f

CPU: 0 UID: 0 PID: 6465 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(none) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025

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

bpf: Fix reference count leak in bpfprogtestrunxdp()

syzbot is reporting

unregisternetdevice: waiting for sit0 to become free. Usage count = 2

problem. A debug printk() patch found that a refcount is obtained at xdpconvertmdtobuff() from bpfprogtestrunxdp().

According to commit ec94670fcb3b ("bpf: Support specifying ingress via xdpmd context in BPFPROGTESTRUN"), the refcount obtained by xdpconvertmdtobuff() will be released by xdpconvertbufftomd().

Therefore, we can consider that the error handling path introduced by commit 1c1949982524 ("bpf: introduce frags support to bpfprogtestrunxdp()") forgot to call xdpconvertbufftomd().

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

dmaengine: mmppdma: Fix race condition in mmppdmaresidue()

Add proper locking in mmppdmaresidue() to prevent use-after-free when accessing descriptor list and descriptor contents.

The race occurs when multiple threads call txstatus() while the tasklet on another CPU is freeing completed descriptors:

CPU 0 CPU 1 ----- ----- mmppdmatxstatus() mmppdmaresidue() -> NO LOCK held listforeachentry(sw, ..) DMA interrupt dmadotasklet() -> spinlock(&desclock) listmove(sw->node, ...) spinunlock(&desclock) | dmapoolfree(sw) <- FREED! -> access sw->desc <- UAF!

This issue can be reproduced when running dmatest on the same channel with multiple threads (threadsperchan > 1).

Fix by protecting the chainrunning list iteration and descriptor access with the chan->desclock spinlock.

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

dmaengine: athdmac: fix device leak on ofdmaxlate()

Make sure to drop the reference taken when looking up the DMA platform device during ofdmaxlate() when releasing channel resources.

Note that commit 3832b78b3ec2 ("dmaengine: athdmac: add missing putdevice() call in atdmaxlate()") fixed the leak in a couple of error paths but the reference is still leaking on successful allocation.

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

dmaengine: bcm-sba-raid: fix device leak on probe

Make sure to drop the reference taken when looking up the mailbox device during probe on probe failures and on driver unbind.

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

dmaengine: dw: dmamux: fix OF node leak on route allocation failure

Make sure to drop the reference taken to the DMA master OF node also on late route allocation failures.

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

dmaengine: stm32: dmamux: fix device leak on route allocation

Make sure to drop the reference taken when looking up the DMA mux platform device during route allocation.

Note that holding a reference to a device does not prevent its driver data from going away so there is no point in keeping the reference.

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

dmaengine: ti: dma-crossbar: fix device leak on am335x route allocation

Make sure to drop the reference taken when looking up the crossbar platform device during am335x route allocation.

dmaengine: idxd: fix device leaks on compat bind and unbind

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

dmaengine: tegra-adma: Fix use-after-free

A use-after-free bug exists in the Tegra ADMA driver when audio streams are terminated, particularly during XRUN conditions. The issue occurs when the DMA buffer is freed by tegraadmaterminateall() before the vchan completion tasklet finishes accessing it.

The race condition follows this sequence:

1. DMA transfer completes, triggering an interrupt that schedules the completion tasklet (tasklet has not executed yet) 2. Audio playback stops, calling tegraadmaterminateall() which frees the DMA buffer memory via kfree() 3. The scheduled tasklet finally executes, calling vchancomplete() which attempts to access the already-freed memory

Since tasklets can execute at any time after being scheduled, there is no guarantee that the buffer will remain valid when vchancomplete() runs.

Fix this by properly synchronizing the virtual channel completion: - Calling vchanterminatevdesc() in tegraadmastop() to mark the descriptors as terminated instead of freeing the descriptor. - Add the callback tegraadmasynchronize() that calls vchansynchronize() which kills any pending tasklets and frees any terminated descriptors.

Crash logs: [ 337.427523] BUG: KASAN: use-after-free in vchancomplete+0x124/0x3b0 [ 337.427544] Read of size 8 at addr ffff000132055428 by task swapper/0/0

[ 337.427562] Call trace: [ 337.427564] dumpbacktrace+0x0/0x320 [ 337.427571] showstack+0x20/0x30 [ 337.427575] dumpstacklvl+0x68/0x84 [ 337.427584] printaddressdescription.constprop.0+0x74/0x2b8 [ 337.427590] kasanreport+0x1f4/0x210 [ 337.427598] asanload8+0xa0/0xd0 [ 337.427603] vchancomplete+0x124/0x3b0 [ 337.427609] taskletactioncommon.constprop.0+0x190/0x1d0 [ 337.427617] taskletaction+0x30/0x40 [ 337.427623] dosoftirq+0x1a0/0x5c4 [ 337.427628] irqexit+0x110/0x140 [ 337.427633] handledomainirq+0xa4/0xe0 [ 337.427640] gichandleirq+0x64/0x160 [ 337.427644] callonirqstack+0x20/0x4c [ 337.427649] dointerrupthandler+0x7c/0x90 [ 337.427654] el1interrupt+0x30/0x80 [ 337.427659] el1h64irqhandler+0x18/0x30 [ 337.427663] el1h64irq+0x7c/0x80 [ 337.427667] cpuidleenterstate+0xe4/0x540 [ 337.427674] cpuidleenter+0x54/0x80 [ 337.427679] doidle+0x2e0/0x380 [ 337.427685] cpustartupentry+0x2c/0x70 [ 337.427690] restinit+0x114/0x130 [ 337.427695] archcallrestinit+0x18/0x24 [ 337.427702] startkernel+0x380/0x3b4 [ 337.427706] primaryswitched+0xc0/0xc8

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

crypto: seqiv - Do not use req->iv after cryptoaeadencrypt

As soon as cryptoaeadencrypt is called, the underlying request may be freed by an asynchronous completion. Thus dereferencing req->iv after it returns is invalid.

Instead of checking req->iv against info, create a new variable unalignedinfo and use it for that purpose instead.