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

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

net: atm: fix crash due to unvalidated vcc pointer in sigdsend()

Reproducer available at [1].

The ATM send path (sendmsg -> vccsendmsg -> sigdsend) reads the vcc pointer from msg->vcc and uses it directly without any validation. This pointer comes from userspace via sendmsg() and can be arbitrarily forged:

int fd = socket(AFATMSVC, SOCKDGRAM, 0); ioctl(fd, ATMSIGDCTRL); // become ATM signaling daemon struct msghdr msg = { .msgiov = &iov, ... }; (unsigned long )(buf + 4) = 0xdeadbeef; // fake vcc pointer sendmsg(fd, &msg, 0); // kernel dereferences 0xdeadbeef

In normal operation, the kernel sends the vcc pointer to the signaling daemon via sigdenq() when processing operations like connect(), bind(), or listen(). The daemon is expected to return the same pointer when responding. However, a malicious daemon can send arbitrary pointer values.

Fix this by introducing findgetvcc() which validates the pointer by searching through vcchash (similar to how sigdclose() iterates over all VCCs), and acquires a reference via sockhold() if found.

Since struct atmvcc embeds struct sock as its first member, they share the same lifetime. Therefore using sockhold/sockput is sufficient to keep the vcc alive while it is being used.

Note that there may be a race with sigdclose() which could mark the vcc with various flags (e.g., ATMVFRELEASED) after findgetvcc() returns. However, sockhold() guarantees the memory remains valid, so this race only affects the logical state, not memory safety.

[1]: https://gist.github.com/mrpre/1ba5949c45529c511152e2f4c755b0f3

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

mm: thp: deny THP for files on anonymous inodes

filethpenabled() incorrectly allows THP for files on anonymous inodes (e.g. guestmemfd and secretmem). These files are created via allocfilepseudo(), which does not call getwriteaccess() and leaves inode->iwritecount at 0. Combined with SISREG(inode->imode) being true, they appear as read-only regular files when CONFIGREADONLYTHPFORFS is enabled, making them eligible for THP collapse.

Anonymous inodes can never pass the inodeisopenforwrite() check since their iwritecount is never incremented through the normal VFS open path. The right thing to do is to exclude them from THP eligibility altogether, since CONFIGREADONLYTHPFORFS was designed for real filesystem files (e.g. shared libraries), not for pseudo-filesystem inodes.

For guestmemfd, this allows khugepaged and MADVCOLLAPSE to create large folios in the page cache via the collapse path, but the guestmemfd fault handler does not support large folios. This triggers WARNONONCE(foliotestlarge(folio)) in kvmgmemfaultusermapping().

For secretmem, collapsefile() tries to copy page contents through the direct map, but secretmem pages are removed from the direct map. This can result in a kernel crash:

BUG: unable to handle page fault for address: ffff88810284d000 RIP: 0010:memcpyorig+0x16/0x130 Call Trace: collapsefile hpagecollapsescanfile madvisecollapse

Secretmem is not affected by the crash on upstream as the memory failure recovery handles the failed copy gracefully, but it still triggers confusing false memory failure reports:

Memory failure: 0x106d96f: recovery action for clean unevictable LRU page: Recovered

Check ISANONFILE(inode) in filethpenabled() to deny THP for all anonymous inode files.

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

btrfs: tracepoints: fix sleep while in atomic context in btrfssyncfile()

The trace event btrfssyncfile() is called in an atomic context (all trace events are) and its call to dput(), which is needed due to the call to dgetparent(), can sleep, triggering a kernel splat.

This can be reproduced by enabling the trace event and running btrfs/056 from fstests for example. The splat shown in dmesg is the following:

[53.919] BUG: sleeping function called from invalid context at fs/dcache.c:970 [53.947] inatomic(): 1, irqsdisabled(): 0, nonblock: 0, pid: 32773, name: xfsio [53.988] preemptcount: 2, expected: 0 [53.967] RCU nest depth: 0, expected: 0 [53.943] Preemption disabled at: [53.944] [<0000000000000000>] 0x0 [54.078] CPU: 0 UID: 0 PID: 32773 Comm: xfsio Tainted: G W 7.1.0-rc1-btrfs-next-232+ #1 PREEMPT(full) [54.070] Tainted: [W]=WARN [54.071] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 [54.072] Call Trace: [54.074] <TASK> [54.076] dumpstacklvl+0x56/0x80 [54.079] mightresched.cold+0xd6/0x10f [54.072] dput.part.0+0x24/0x110 [54.078] traceeventraweventbtrfssyncfile+0x75/0x140 [btrfs] [54.089] btrfssyncfile+0x1ed/0x530 [btrfs] [54.087] ? handlemmfault+0x8ae/0xed0 [54.089] btrfsdowriteiter+0x172/0x210 [btrfs] [54.091] vfswrite+0x21f/0x450 [54.094] x64syspwrite64+0x8d/0xc0 [54.096] ? douseraddrfault+0x20c/0x670 [54.099] dosyscall64+0x60/0xf20 [54.092] ? clearbhbloop+0x60/0xb0 [54.094] entrySYSCALL64afterhwframe+0x76/0x7e

So stop using dgetparent() and dput() and access the parent dentry directly as dentry->dparent. This is also what ext4 is doing in its equivalent trace event ext4syncfileenter().

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

srcu: Don't queue workqueue handlers to never-online CPUs

While an srcustruct structure is in the midst of switching from CPU-0 to all-CPUs state, it can attempt to invoke callbacks for CPUs that have never been online. Worse yet, it can attempt in invoke callbacks for CPUs that never will be online, even including imaginary CPUs not in cpupossiblemask. This can cause hangs on s390, which is not set up to deal with workqueue handlers being scheduled on such CPUs. This commit therefore causes Tree SRCU to refrain from queueing workqueue handlers on CPUs that have not yet (and might never) come online.

Because callbacks are not invoked on CPUs that have not been online, it is an error to invoke callsrcu(), synchronizesrcu(), or synchronizesrcuexpedited() on a CPU that is not yet fully online. However, it turns out to be less code to redirect the callbacks from too-early invocations of callsrcu() than to warn about such invocations. This commit therefore also redirects callbacks queued on not-yet-fully-online CPUs to the boot CPU.

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

netfilter: nftables: clone set on flush only

Syzbot with fault injection triggered a failing memory allocation with GFPKERNEL which results in a WARN splat:

iter.err WARNING: net/netfilter/nftablesapi.c:845 at nftmapdeactivate+0x34e/0x3c0 net/netfilter/nftablesapi.c:845, CPU#0: syz.0.17/5992 Modules linked in: CPU: 0 UID: 0 PID: 5992 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2026 RIP: 0010:nftmapdeactivate+0x34e/0x3c0 net/netfilter/nftablesapi.c:845 Code: 8b 05 86 5a 4e 09 48 3b 84 24 a0 00 00 00 75 62 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc e8 63 6d fa f7 90 <0f> 0b 90 43 +80 7c 35 00 00 0f 85 23 fe ff ff e9 26 fe ff ff 89 d9 RSP: 0018:ffffc900045af780 EFLAGS: 00010293 RAX: ffffffff89ca45bd RBX: 00000000fffffff4 RCX: ffff888028111e40 RDX: 0000000000000000 RSI: 00000000fffffff4 RDI: 0000000000000000 RBP: ffffc900045af870 R08: 0000000000400dc0 R09: 00000000ffffffff R10: dffffc0000000000 R11: fffffbfff1d141db R12: ffffc900045af7e0 R13: 1ffff920008b5f24 R14: dffffc0000000000 R15: ffffc900045af920 FS: 000055557a6a5500(0000) GS:ffff888125496000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fb5ea271fc0 CR3: 000000003269e000 CR4: 00000000003526f0 Call Trace: <TASK> nftreleasetable+0xceb/0x11f0 net/netfilter/nftablesapi.c:12115 nftrcvnlevent+0xc25/0xdb0 net/netfilter/nftablesapi.c:12187 notifiercallchain+0x19d/0x3a0 kernel/notifier.c:85 blockingnotifiercallchain+0x6a/0x90 kernel/notifier.c:380 netlinkrelease+0x123b/0x1ad0 net/netlink/afnetlink.c:761 sockrelease net/socket.c:662 [inline] sockclose+0xc3/0x240 net/socket.c:1455

Restrict set clone to the flush set command in the preparation phase. Add NFTITERUPDATECLONE and use it for this purpose, update the rbtree and pipapo backends to only clone the set when this iteration type is used.

As for the existing NFTITERUPDATE type, update the pipapo backend to use the existing set clone if available, otherwise use the existing set representation. After this update, there is no need to clone a set that is being deleted, this includes bound anonymous set.

An alternative approach to NFTITERUPDATECLONE is to add a .clone interface and call it from the flush set path.

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

rtnetlink: add missing netlinknscapable() check for peer netns

rtnlnewlink() lacks a CAPNETADMIN capability check on the peer network namespace when creating paired devices (veth, vxcan, netkit). This allows an unprivileged user with a user namespace to create interfaces in arbitrary network namespaces, including initnet.

Add a netlinknscapable() check for CAPNETADMIN in the peer namespace before allowing device creation to proceed.

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

net: sched: actcsum: validate nested VLAN headers

tcfcsumact() walks nested VLAN headers directly from skb->data when an skb still carries in-payload VLAN tags. The current code reads vlan->hvlanencapsulatedproto and then pulls VLANHLEN bytes without first ensuring that the full VLAN header is present in the linear area.

If only part of an inner VLAN header is linearized, accessing hvlanencapsulatedproto reads past the linear area, and the following skbpull(VLANHLEN) may violate skb invariants.

Fix this by requiring pskbmaypull(skb, VLANHLEN) before accessing and pulling each nested VLAN header. If the header still is not fully available, drop the packet through the existing error path.

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

drm/xe/regsr: Fix leak on xastore failure

Free the newly allocated entry when xastore() fails to avoid a memory leak on the error path.

v2: use goto failfree. (Bala)

(cherry picked from commit 6bc6fec71ac45f52db609af4e62bdb96b9f5fadb)

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

drm/logicvc: Fix device node reference leak in logicvcdrmconfigparse()

The logicvcdrmconfigparse() function calls ofgetchildbyname() to find the "layers" node but fails to release the reference, leading to a device node reference leak.

Fix this by using the free(devicenode) cleanup attribute to automatic release the reference when the variable goes out of scope.

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

btrfs: free pages on error in btrfsuringreadextent()

In this function the 'pages' object is never freed in the hopes that it is picked up by btrfsuringreadfinished() whenever that executes in the future. But that's just the happy path. Along the way previous allocations might have gone wrong, or we might not get -EIOCBQUEUED from btrfsencodedreadregularfillpages(). In all these cases, we go to a cleanup section that frees all memory allocated by this function without assuming any deferred execution, and this also needs to happen for the 'pages' allocation.

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

wifi: wlcore: Fix a locking bug

Make sure that wl->mutex is locked before it is unlocked. This has been detected by the Clang thread-safety analyzer.

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

drm/xe/configfs: Free ctxrestoremidbb in release

ctxrestoremidbb memory is allocated in wabbstore(), but xeconfigdevicerelease() only frees ctxrestorepostbb.

Free ctxrestoremidbb[0].cs as well to avoid leaking the allocation when the configfs device is removed.

(cherry picked from commit a235e7d0098337c3f2d1e8f3610c719a589e115f)

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

spi: amlogic-spisg: Fix memory leak in amlspisgprobe()

In amlspisgprobe(), ctlr is allocated by spialloctarget()/spiallochost(), but fails to call spicontrollerput() in several error paths. This leads to a memory leak whenever the driver fails to probe after the initial allocation.

Convert to use devmspiallochost()/devmspialloctarget() to fix the memory leak.

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

ipv6: add NULL checks for idev in SRv6 paths

in6devget() can return NULL when the device has no IPv6 configuration (e.g. MTU < IPV6MINMTU or after NETDEVUNREGISTER).

Add NULL checks for idev returned by in6devget() in both seg6hmacvalidateskb() and ipv6srhrcv() to prevent potential NULL pointer dereferences.

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

net/mlx5e: Prevent concurrent access to IPSec ASO context

The query or updating IPSec offload object is through Access ASO WQE. The driver uses a single mlx5eipsecaso struct for each PF, which contains a shared DMA-mapped context for all ASO operations.

A race condition exists because the ASO spinlock is released before the hardware has finished processing WQE. If a second operation is initiated immediately after, it overwrites the shared context in the DMA area.

When the first operation's completion is processed later, it reads this corrupted context, leading to unexpected behavior and incorrect results.

This commit fixes the race by introducing a private context within each IPSec offload object. The shared ASO context is now copied to this private context while the ASO spinlock is held. Subsequent processing uses this saved, per-object context, ensuring its integrity is maintained.

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

udptunnel: fix NULL deref caused by udpsockcreate6 when CONFIGIPV6=n

When CONFIGIPV6 is disabled, the udpsockcreate6() function returns 0 (success) without actually creating a socket. Callers such as foucreate() then proceed to dereference the uninitialized socket pointer, resulting in a NULL pointer dereference.

The captured NULL deref crash: BUG: kernel NULL pointer dereference, address: 0000000000000018 RIP: 0010:founladddoit (net/ipv4/foucore.c:590 net/ipv4/foucore.c:764) [...] Call Trace: <TASK> genlfamilyrcvmsgdoit.constprop.0 (net/netlink/genetlink.c:1114) genlrcvmsg (net/netlink/genetlink.c:1194 net/netlink/genetlink.c:1209) [...] netlinkrcvskb (net/netlink/afnetlink.c:2550) genlrcv (net/netlink/genetlink.c:1219) netlinkunicast (net/netlink/afnetlink.c:1319 net/netlink/afnetlink.c:1344) netlinksendmsg (net/netlink/afnetlink.c:1894) socksendmsg (net/socket.c:727 (discriminator 1) net/socket.c:742 (discriminator 1)) syssendto (./include/linux/file.h:62 (discriminator 1) ./include/linux/file.h:83 (discriminator 1) net/socket.c:2183 (discriminator 1)) x64syssendto (net/socket.c:2213 (discriminator 1) net/socket.c:2209 (discriminator 1) net/socket.c:2209 (discriminator 1)) dosyscall64 (arch/x86/entry/syscall64.c:63 (discriminator 1) arch/x86/entry/syscall64.c:94 (discriminator 1)) entrySYSCALL64afterhwframe (net/arch/x86/entry/entry64.S:130)

This patch makes udpsockcreate6 return -EPFNOSUPPORT instead, so callers correctly take their error paths. There is only one caller of the vulnerable function and only privileged users can trigger it.

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

armmpam: Fix null pointer dereference when restoring bandwidth counters

When an MSC supporting memory bandwidth monitoring is brought offline and then online, mpamrestorembwustate() calls rismsmonread() via ipi to restore the configuration of the bandwidth counters. It doesn't care about the value read, mbwuarg.val, and doesn't set it leading to a null pointer dereference when rismsmonread() adds to it. This results in a kernel oops with a call trace such as:

Call trace: rismsmonread+0x19c/0x64c (P) mpamrestorembwustate+0xa0/0xe8 smpcalloncpucallback+0x1c/0x38 processonework+0x154/0x4b4 workerthread+0x188/0x310 kthread+0x11c/0x130 retfromfork+0x10/0x20

Provide a local variable for val to avoid rismsmonread() dereferencing a null pointer when adding to val.

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

net: shaper: protect from late creation of hierarchy

We look up a netdev during prep of Netlink ops (pre- callbacks) and take a ref to it. Then later in the body of the callback we take its lock or RCU which are the actual protections.

The netdev may get unregistered in between the time we take the ref and the time we lock it. We may allocate the hierarchy after flush has already run, which would lead to a leak.

Take the instance lock in pre- already, this saves us from the race and removes the need for dedicated lock/unlock callbacks completely. After all, if there's any chance of write happening concurrently with the flush - we're back to leaking the hierarchy.

We may take the lock for devices which don't support shapers but we're only dealing with SET operations here, not taking the lock would be optimizing for an error case.

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

net: usb: aqc111: Do not perform PM inside suspend callback

syzbot reports "task hung in rpmresume"

This is caused by aqc111suspend calling the PM variant of its writecmd routine.

The simplified call trace looks like this:

rpmsuspend() usbsuspendboth() - here udev->dev.power.runtimestatus == RPMSUSPENDING aqc111suspend() - called for the usb device interface aqc111write32cmd() usbautopmgetinterface() pmruntimeresumeandget() rpmresume() - here we call rpmresume() on our parent rpmresume() - Here we wait for a status change that will never happen.

At this point we block another task which holds rtnllock and locks up the whole networking stack.

Fix this by replacing the writecmd calls with their nopm variants

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

drm/vmwgfx: Don't overwrite KMS surface dirty tracker

We were overwriting the surface's dirty tracker here causing a memory leak.

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

net: mvpp2: guard flow control update with globaltxfc in buffer switching

mvpp2bmswitchbuffers() unconditionally calls mvpp2bmpoolupdateprivfc() when switching between per-cpu and shared buffer pool modes. This function programs CM3 flow control registers via mvpp2cm3read()/mvpp2cm3write(), which dereference priv->cm3base without any NULL check.

When the CM3 SRAM resource is not present in the device tree (the third reg entry added by commit 60523583b07c ("dts: marvell: add CM3 SRAM memory to cp11x ethernet device tree")), priv->cm3base remains NULL and priv->globaltxfc is false. Any operation that triggers mvpp2bmswitchbuffers(), for example an MTU change that crosses the jumbo frame threshold, will crash:

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits pc : readl+0x0/0x18 lr : mvpp2cm3read.isra.0+0x14/0x20 Call trace: readl+0x0/0x18 mvpp2bmpoolupdatefc+0x40/0x12c mvpp2bmpoolupdateprivfc+0x94/0xd8 mvpp2bmswitchbuffers.isra.0+0x80/0x1c0 mvpp2changemtu+0x140/0x380 devsetmtu+0x1c/0x38 devsetmtuext+0x78/0x118 devsetmtu+0x48/0xa8 devifsioc+0x21c/0x43c devioctl+0x2d8/0x42c sockioctl+0x314/0x378

Every other flow control call site in the driver already guards hardware access with either priv->globaltxfc or port->txfc. mvpp2bmswitchbuffers() is the only place that omits this check.

Add the missing priv->globaltxfc guard to both the disable and re-enable calls in mvpp2bmswitchbuffers(), consistent with the rest of the driver.

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

perf/x86: Move event pointer setup earlier in x86pmuenable()

A production AMD EPYC system crashed with a NULL pointer dereference in the PMU NMI handler:

BUG: kernel NULL pointer dereference, address: 0000000000000198 RIP: x86perfeventupdate+0xc/0xa0 Call Trace: <NMI> amdpmuv2handleirq+0x1a6/0x390 perfeventnmihandler+0x24/0x40

The faulting instruction is cmpq $0x0, 0x198(%rdi) with RDI=0, corresponding to the if (unlikely(!hwc->eventbase)) check in x86perfeventupdate() where hwc = &event->hw and event is NULL.

drgn inspection of the vmcore on CPU 106 showed a mismatch between cpuc->activemask and cpuc->events[]:

activemask: 0x1e (bits 1, 2, 3, 4) events[1]: 0xff1100136cbd4f38 (valid) events[2]: 0x0 (NULL, but activemask bit 2 set) events[3]: 0xff1100076fd2cf38 (valid) events[4]: 0xff1100079e990a90 (valid)

The event that should occupy events[2] was found in eventlist[2] with hw.idx=2 and hw.state=0x0, confirming x86pmustart() had run (which clears hw.state and sets activemask) but events[2] was never populated.

Another event (eventlist[0]) had hw.state=0x7 (STOPPED|UPTODATE|ARCH), showing it was stopped when the PMU rescheduled events, confirming the throttle-then-reschedule sequence occurred.

The root cause is commit 7e772a93eb61 ("perf/x86: Fix NULL event access and potential PEBS record loss") which moved the cpuc->events[idx] assignment out of x86pmustart() and into step 2 of x86pmuenable(), after the PERFHESARCH check. This broke any path that calls pmu->start() without going through x86pmuenable() -- specifically the unthrottle path:

perfadjustfrequnthrevents() -> perfeventunthrottlegroup() -> perfeventunthrottle() -> event->pmu->start(event, 0) -> x86pmustart() // sets activemask but not events[]

The race sequence is:

1. A group of perf events overflows, triggering group throttle via perfeventthrottlegroup(). All events are stopped: activemask bits cleared, events[] preserved (x86pmustop no longer clears events[] after commit 7e772a93eb61).

2. While still throttled (PERFHESSTOPPED), x86pmuenable() runs due to other scheduling activity. Stopped events that need to move counters get PERFHESARCH set and events[oldidx] cleared. In step 2 of x86pmuenable(), PERFHESARCH causes these events to be skipped -- events[newidx] is never set.

3. The timer tick unthrottles the group via pmu->start(). Since commit 7e772a93eb61 removed the events[] assignment from x86pmustart(), activemask[newidx] is set but events[newidx] remains NULL.

4. A PMC overflow NMI fires. The handler iterates active counters, finds activemask[2] set, reads events[2] which is NULL, and crashes dereferencing it.

Move the cpuc->events[hwc->idx] assignment in x86pmuenable() to before the PERFHESARCH check, so that events[] is populated even for events that are not immediately started. This ensures the unthrottle path via pmu->start() always finds a valid event pointer.

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

net: sched: clsapi: fix tcchainfillnode to initialize tcminfo to zero to prevent an info-leak

When building netlink messages, tcchainfillnode() never initializes the tcminfo field of struct tcmsg. Since the allocation is not zeroed, kernel heap memory is leaked to userspace through this 4-byte field.

The fix simply zeroes tcminfo alongside the other fields that are already initialized.

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

netfilter: ctnetlink: zero expect NAT fields when CTAEXPECTNAT absent

ctnetlinkallocexpect() allocates expectations from a non-zeroing slab cache via nfctexpectalloc(). When CTAEXPECTNAT is not present in the netlink message, savedaddr and savedproto are never initialized. Stale data from a previous slab occupant can then be dumped to userspace by ctnetlinkexpdumpexpect(), which checks these fields to decide whether to emit CTAEXPECTNAT.

The safe sibling nfctexpectinit(), used by the packet path, explicitly zeroes these fields.

Zero savedaddr, savedproto and dir in the else branch, guarded by ISENABLED(CONFIGNFNAT) since these fields only exist when NAT is enabled.

Confirmed by priming the expect slab with NAT-bearing expectations, freeing them, creating a new expectation without CTAEXPECTNAT, and observing that the ctnetlink dump emits a spurious CTAEXPECTNAT containing stale data from the prior allocation.

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

netfilter: nftables: reject immediate NFQUEUE verdict

nftqueue is always used from userspace nftables to deliver the NFQUEUE verdict. Immediately emitting an NFQUEUE verdict is never used by the userspace nft tools, so reject immediate NFQUEUE verdicts.

The arp family does not provide queue support, but such an immediate verdict is still reachable. Globally reject NFQUEUE immediate verdicts to address this issue.

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

bridge: brndsend: validate ND option lengths

brndsend() walks ND options according to option-provided lengths. A malformed option can make the parser advance beyond the computed option span or use a too-short source LLADDR option payload.

Validate option lengths against the remaining NS option area before advancing, and only read source LLADDR when the option is large enough for an Ethernet address.

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

xfrmuser: fix info leak in buildreport()

struct xfrmuserreport is a u8 proto field followed by a struct xfrmselector which means there is three "empty" bytes of padding, but the padding is never zeroed before copying to userspace. Fix that up by zeroing the structure before setting individual member variables.

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

net: ftgmac100: fix ring allocation unwind on open failure

ftgmac100allocrings() allocates rxskbs, txskbs, rxdes, txdes, and rxscratch in stages. On intermediate failures it returned -ENOMEM directly, leaking resources allocated earlier in the function.

Rework the failure path to use staged local unwind labels and free allocated resources in reverse order before returning -ENOMEM. This matches common netdev allocation cleanup style.

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

net: rfkill: prevent unlimited numbers of rfkill events from being created

Userspace can create an unlimited number of rfkill events if the system is so configured, while not consuming them from the rfkill file descriptor, causing a potential out of memory situation. Prevent this from bounding the number of pending rfkill events at a "large" number (i.e. 1000) to prevent abuses like this.