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

ethtool: cmis: require exact CDB reply length

Malicious SFP module could respond with rpllen longer than what cmiscdbprocessreply() expected, leading to OOB writes. Malicious HW is a bit theoretical but some modules may just be buggy and/or the reads may occasionally get corrupted, so let's protect the kernel.

The existing check protects from short replies. We need to protect from long ones, too. All callers that pass a non-zero rplexplen cast the reply payload to a fixed-layout struct and read fields at fixed offsets, with no version negotiation or short-reply handling:

- cmiscdbvalidatepassword() - cmiscdbmodulefeaturesget() - cmisfwupdatefwmngfeaturesget()

so let's assume that responses longer than expected do not have to be handled gracefully here. Add a warning message to make the debug easier in case my understanding is wrong...

Note that pagedata->length (argument of kmalloc) comes from last arg to ethtoolcmispageinit() which is rplexplen.

Note2 that AIs also like to point out overflows in args->req.payload itself (which is a fixed-size 120 B buffer, on the stack), but callers should be reading structs defined by the standard, so protecting from requests for more data than max seem like defensive programming.

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

ALSA: pcm: oss: Fix setup list UAF on proc write error

sndpcmossprocwrite() links a newly allocated setup entry into the OSS setup list before duplicating the task name. If the task-name allocation fails, the error path frees the already linked entry and leaves setuplist pointing at freed memory.

A later OSS device open can then walk the stale list entry in sndpcmosslookforsetup() and dereference freed memory.

Allocate the task name and initialize the setup entry before publishing the entry on setuplist. Also fetch the initial proc read iterator only after taking setupmutex, so all setuplist traversal follows the same list lifetime rules.

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

accel/rocket: fix UAF via dangling GEM handle in createbo

rocketioctlcreatebo() inserts a GEM handle into the file's IDR via drmgemhandlecreate() early on, then performs several operations that can fail (sgt allocation, drmmm insert, iommumap). If any fail after the handle is live, the error path calls drmgemshmemobjectfree() which kfree's the object without removing the handle from the IDR.

This leaves a dangling handle pointing to freed slab memory. Any subsequent ioctl using that handle (PREPBO, FINIBO, SUBMIT) calls drmgemobjectlookup() and dereferences freed memory (UAF).

Fix by moving drmgemhandlecreate() to after all fallible operations succeed, matching the pattern used by panfrost, lima, and etnaviv.

Also fix drmmminsertnodegeneric() whose return value was silently overwritten by iommumapsgtable() on the next line. Add the missing error check.

[tomeu: Move handle creation to the very end]

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

Bluetooth: L2CAP: Fix possible crash on l2capecredconnrsp

If dcid is received for an already-assigned destination CID the spec requires that both channels to be discarded, but calling l2capchandel may invalidate the tmp cursor created by listforeachentrysafe and in fact it is the wrong procedure as the chan->dcid may be assigned previously it really needs to be disconnected.

Calling l2capchanclone directly may still lead to l2capchandel so instead schedule l2capchantimeout with delay 0 to close the channel asynchronously.

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

net: mana: Skip redundant detach on already-detached port

When manaperportqueueresetworkhandler() runs after a previous detach succeeded but attach failed, the port is left in a detached state with apc->txqp and apc->rxqs already freed. Calling manadetach() again unconditionally leads to NULL pointer dereferences during queue teardown.

Add an early exit in manadetach() when the port is already in detached state (!netifdevicepresent) for non-close callers, making it safe to call idempotently. This allows the queue reset handler and other recovery paths to simply retry manaattach() without redundant teardown.

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

sctp: fix race between sctpwaitforconnect and peeloff

sctpwaitforconnect() drops and re-acquires the socket lock while waiting for the association to reach ESTABLISHED state. During this window, another thread can peeloff the association to a new socket via getsockopt(SCTPSOCKOPTPEELOFF), changing asoc->base.sk. After re-acquiring the old socket lock, sctpwaitforconnect() returns success without noticing the migration — the caller then accesses the association under the wrong lock in sctpdatamsgfromuser().

Add the same sk != asoc->base.sk check that sctpwaitforsndbuf() already has, returning an error if the association was migrated while we slept.

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

vsock/virtio: bind uarg before filling zerocopy skb

virtiotransportsendpktinfo() allocates or reuses the zerocopy uarg before entering the send loop, but virtiotransportallocskb() still fills the skb before it inherits that uarg. When fixed-buffer vectored zerocopy hits MAXSKBFRAGS, iosgfromiter() may partially attach managed frags and return -EMSGSIZE. The rollback path call kfreeskb() to free an skb that carries SKBFLMANAGEDFRAGREFS but no uarg, so skbreleasedata() falls through to ordinary frag unref.

Pass the uarg into virtiotransportallocskb() and bind it immediately before virtiotransportfillskb(). This keeps control or no-payload skbs untouched while ensuring success and rollback share one lifetime rule.

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

zram: fix use-after-free in zrambvecwritepartial()

zramreadpage() picks the sync or async backing device read path based on whether the parent bio is NULL. zrambvecwritepartial() passes its parent bio down, so for ZRAMWB slots the read is dispatched asynchronously and zramreadpage() returns 0 while the bio is still in flight. The caller then runs memcpyfrombvec(), zramwritepage() and freepage() on the buffer, leaving the async read to write into a freed page.

zrambvecreadpartial() was switched to NULL in commit 4e3c87b9421d ("zram: fix synchronous reads") for the same reason; the writepartial counterpart was missed.

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

net: gro: don't merge zcopy skbs

skbgroreceive() can currently copy frags between the source and GRO skb, without checking the zerocopy status, and in particular the SKBFLMANAGEDFRAGREFS flag.

When SKBFLMANAGEDFRAGREFS is set, the skb doesn't hold a reference on the pages in shinfo->frags. Appending those frags to another skb's frags without fixing up the page refcount can lead to UAF.

When either the last skb in the GRO chain (the one we would append frags to) or the source skb is zerocopy, don't merge the skbs.

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

rbd: eliminate a race in lockdwork draining on unmap

Given how rbdlockaddrequest() and rbdimgexclusivelock() are written, lockdwork may be (re)queued more than it's actually needed: for example in case a new I/O request comes in while we are in the middle of rbdacquirelock() on behalf of another I/O request. This is expected and with rbdreleaselock() preemptively canceling lockdwork is benign under normal operation.

A more problematic example is maybekickacquire():

if (haverequests || delayedworkpending(&rbddev->lockdwork)) { dout("%s rbddev %p kicking lockdwork\n", func, rbddev); moddelayedwork(rbddev->taskwq, &rbddev->lockdwork, 0); }

It's not unrealistic for lockdwork to get canceled right after delayedworkpending() returns true and for moddelayedwork() to requeue it right there anyway. This is a classic TOCTOU race.

When it comes to unmapping the image, there is an implicit assumption of no self-initiated exclusive lock activity past the point of return from rbddevimageunlock() which unlocks the lock if it happens to be held. This unlock is assumed to be final and lockdwork (as well as all other exclusive lock tasks, really) isn't expected to get queued again. However, lockdwork is canceled only in canceltaskssync() (i.e. later in the unmap sequence) and on top of that the cancellation can get in effect nullified by maybekickacquire(). This may result in rbdacquirelock() executing after rbddevdevicerelease() and rbddevimagerelease() run and free and/or reset a bunch of things. One of the possible failure modes then is a violated

rbdassert(rbdimageformatvalid(rbddev->imageformat));

in rbddevheaderinfo() which is called via rbddevrefresh() from rbdpostacquireaction().

Redo exclusive lock task draining to provide saner semantics and try to meet the assumptions around rbddevimageunlock().

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

wifi: mac80211: capture fast-RX rate before mesh reuses skb->cb

ieee80211invokefastrx() reads RX status through IEEE80211SKBRXCB(skb), which aliases the same skb->cb storage that ieee80211rxmeshdata() reuses as IEEE80211TXINFO. In the unicast forward path, meshdata does:

info = IEEE80211SKBCB(fwdskb); memset(info, 0, sizeof(info));

on the same skb the caller still names via rx->skb, then either queues the skb for TX (success) or kfreeskb()'s it (no-route) before returning RXQUEUED. The caller's RXQUEUED arm then calls stastatsencoderate(status) on memory that is either zeroed (success path) or freed (no-route path). The latter is KASAN slab-use-after-free in ieee80211prepareandrxhandle.

Fix by encoding the rate from status before invoking ieee80211rxmeshdata(), so the RXQUEUED arm consumes a value captured while status was still backed by valid memory.

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

net/mlx5e: xsk: Fix DMA and xdpframe leak on XDPTX xmit failure

In the XSK branch of mlx5exmitxdpbuff(), when sq->xmitxdpframe() returns false (e.g. XDPSQ is full), the function returns without unmapping the DMA address or freeing the xdpframe allocated by xdpconvertzctoxdpframe(). The xdpififo push only happens on success, so the completion path cannot recover these entries.

With CONFIGDMAAPIDEBUG=y, the leak surfaces on driver unbind:

DMA-API: pci 0000:08:00.0: device driver has pending DMA allocations while released from device [count=1116] One of leaked entries details: [device address=0x000000010ffd7028] [size=1534 bytes] [mapped with DMATODEVICE] [mapped as phy] WARNING: kernel/dma/debug.c:881 at dmadebugdevicechange+0x127/0x180 ... DMA-API: Mapped at: debugdmamapphys+0x4b/0xd0 dmamapphys+0xfd/0x2d0 mlx5exdphandle+0x5ae/0xac0 [mlx5core] mlx5exskskbfromcqempwrqlinear+0xc4/0x170 [mlx5core] mlx5ehandlerxcqempwrq+0xc1/0x290 [mlx5core]

Add the missing unmap + xdpreturnframe, matching the cleanup already done in mlx5exdpxmit(). hasfrags is rejected earlier in this branch, so no per-frag unmap is needed.

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

USB: serial: ioti: fix heap overflow in getmanufinfo()

getmanufinfo() reads le16tocpu(romdesc->Size) bytes from the device I2C EEPROM into a buffer allocated with kmallocobj(), which is sizeof(struct edgetimanufdescriptor) = 10 bytes.

The Size field comes from the device and is only validated (in checki2cimage()) to make sure the descriptor fits within TIMAXI2CSIZE (16384 bytes), not against the destination buffer size. A malicious USB device can therefore set Size to any value up to 16377, causing a heap overflow of up to 16367 bytes when plugged into a host running this driver.

validcsum() is called after readrom() and also iterates buffer[0..Size-1], compounding the out-of-bounds access.

Fix by rejecting descriptors with unexpected length before calling readrom().

[ johan: amend commit message; also check for short descriptors ]

A flaw in the Linux kernel's ebtables SNAT target allows writing to shared memory pages when rewriting ARP sender hardware addresses without ensuring writability, potentially causing file/memory corruption or denial of service.

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

net/mlx5e: xsk: Fix unlocked writing to ICOSQ

During napi poll, when the affinity changes and there's still XSK work to be done, we trigger an ICOSQ interrupt on the new CPU. However, this triggering on the ICOSQ is done unprotected.

There are 2 such races:

A) mlx5etriggerirq() is called while mlx5exskallocrxmpwqe() is running from a different CPU due to affinity change. This can happen because IRQ triggering is done after napicompletedone(). At this point the NAPI can be scheduled on a different CPU. Like this:

CPU A (old affinity, NAPI tail) CPU B (new affinity, fresh NAPI) ------------------------------- -------------------------------- napicompletedone() clears SCHED mlx5ecqarm(...) napischeduleprep() sets SCHED mlx5enapipoll() mlx5exskallocrxmpwqe() mlx5eicosqsynclock() // noop memcpy 640 B UMR body advance sq->pc by 10 mlx5etriggerirq(&c->icosq) wqeinfo[pi] = {NOP, 1} mlx5epostnop() advances sq->pc

B) mlx5etriggerirq() is called on the ICOSQ when mlx5etriggernapiicosq() is running.

The obvious fix would be to lock the ICOSQ. But ICOSQ has an optimized locking scheme that doesn't work for this scenario. Kick the async ICOSQ instead which is always locked.

This issue was noticed in the wild with the following splat:

netdevice: ge-0-0-1: Bad OP in ICOSQ CQE: 0xd WARNING: drivers/net/ethernet/mellanox/mlx5/core/enrx.c:826 [...] [...] Call Trace: <IRQ> mlx5enapipoll+0x11d/0x7f0 [mlx5core] napipoll+0x30/0x200 ? skbdeferfreeflush+0x9c/0xc0 netrxaction+0x2fe/0x3f0 handlesoftirqs+0xd8/0x340 irqexitrcu+0xbc/0xe0 commoninterrupt+0x85/0xa0 </IRQ> <TASK> asmcommoninterrupt+0x26/0x40 [...] ---[ end trace 0000000000000000 ]--- mlx5core 0000:08:00.0 ge-0-0-1: Error cqe on cqn 0x548, ci 0x2022, qn 0x8f4, opcode 0xd, syndrome 0x2, vendor syndrome 0x68 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000030: 00 00 00 00 01 00 68 02 01 00 08 f4 de 14 59 d2 WQE DUMP: WQ size 16384 WQ cur size 0, WQE index 0x1e14, len: 64 00000000: 00 00 00 01 d9 ed 80 02 00 00 00 01 d9 ed 90 02 00000010: 00 00 00 01 d9 ed a0 02 00 00 00 01 d9 ed b0 02 00000020: 00 00 00 01 d9 ed c0 02 00 00 00 01 d9 ed d0 02 00000030: 00 00 00 01 d9 ed e0 02 00 00 00 01 d9 ed f0 02 mlx5core 0000:08:00.0 ge-0-0-1: Error cqe on cqn 0x548, ci 0x2023, qn 0x8f4, opcode 0xd, syndrome 0x5, vendor syndrome 0xf9 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00000030: 00 00 00 00 01 00 f9 05 01 00 08 f4 de 15 cf d2

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

staging: rtl8723bs: rtwmlme: add bounds checks before ielength subtraction

Add guards to ensure ielength is large enough before subtracting fixed IE offsets to prevent unsigned integer underflow.

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

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

mm/listlru: drain before clearing xarray entry on reparent

memcgreparentlistlrus() clears the dying memcg's xarray entry with xasstore(&xas, NULL) before reparenting its per-node lists into the parent. This opens a window where a concurrent listlrudel() arriving for the dying memcg sees xaload() == NULL, walks to the parent in locklistlruofmemcg(), takes the parent's per-node lock, and calls listdelinit() on an item still physically linked on the dying memcg's list.

If another in-flight thread holds the dying memcg's per-node lock at the same moment (another listlrudel, or a listlruwalkone running an isolate callback), both threads modify ->next/->prev pointers on the same physical list under different locks. Adjacent items can corrupt each other's links.

Fix it by reversing the order: reparent each per-node list and mark the child's list lru dead and then clear the xarray entry. Any concurrent listlru op that finds the still-set xarray entry either takes the dying memcg's per-node lock (synchronizing with the drain) or sees LONGMIN and walks to the parent, where the items now live.

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

KVM: arm64: Take the SRCU lock for page table walks in fault injection and AT emulation

walks1() and kvmwalknesteds2() expect to be called while holding kvm->srcu to guard against memslot changes. While this is generally the case, kvmats12() and kvmfinds1desclevel() call into the respective walkers without taking kvm->srcu.

Fix by acquiring kvm->srcu prior to the table walk in both instances.

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

netfs: Fix netfsreadfolio() to wait on writeback

Fix netfsreadfolio() to wait for an ongoing writeback to complete so that it can trust the dirty flag and whatever is attached to folio->private (folio->private may get cleaned up by the collector before it clears the writeback flag).

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

xsk: cache csumstart/csumoffset to fix TOCTOU in xskskbmetadata()

The TX metadata area resides in the UMEM buffer which is memory-mapped and concurrently writable by userspace. In xskskbmetadata(), csumstart and csumoffset are read from shared memory for bounds validation, then read again for skb assignment. A malicious userspace application can race to overwrite these values between the two reads, bypassing the bounds check and causing out-of-bounds memory access during checksum computation in the transmit path.

Fix this by reading csumstart and csumoffset into local variables once, then using the local copies for both validation and assignment.

Note that other metadata fields (flags, launchtime) and the cached csum fields may be mutually inconsistent due to concurrent userspace writes, but this is benign: the only security-critical invariant is that each field's validated value is the same one used, which local caching guarantees.

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

xfrm: policy: fix use-after-free on inexact bin in xfrmpolicybyselctx()

Fix the race by pruning the bin while still holding xfrmpolicylock, before dropping it. Use xfrmpolicyinexactprunebin() directly since the lock is already held. The wrapper xfrmpolicyinexactprunebin() becomes unused and is removed.

Race:

CPU0 (XFRMMSGDELPOLICY) CPU1 (XFRMMSGNEWSPDINFO) ========================== ========================== xfrmpolicybyselctx(): spinlockbh(xfrmpolicylock) bin = xfrmpolicyinexactlookup() xfrmpolicyunlink(pol) spinunlockbh(xfrmpolicylock) xfrmpolicykill(ret) // wide window, lock not held xfrmhashrebuild(): spinlockbh(xfrmpolicylock) xfrmpolicyinexactflush(): kfreercu(bin) // bin freed spinunlockbh(xfrmpolicylock) xfrmpolicyinexactprunebin(bin) // UAF: bin is freed

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

ipv6: mcast: Fix use-after-free when processing MLD queries

When processing an MLD query, a pointer to the multicast group address is retrieved when initially parsing the packet. This pointer is later dereferenced without being reloaded despite the fact that the skb header might have been reallocated following the pskbmaypull() calls, leading to a use-after-free [1].

Fix by copying the multicast group address when the packet is initially parsed.

[1] BUG: KASAN: slab-use-after-free in mldquerywork (net/ipv6/mcast.c:1512) Read of size 8 at addr ffff8881154b8e90 by task kworker/4:1/118

Workqueue: mld mldquerywork Call Trace: <TASK> dumpstacklvl (lib/dumpstack.c:94 lib/dumpstack.c:120) printaddressdescription.constprop.0 (mm/kasan/report.c:378) printreport (mm/kasan/report.c:482) kasanreport (mm/kasan/report.c:595) mldquerywork (net/ipv6/mcast.c:1512) mldquerywork (net/ipv6/mcast.c:1563) processonework (kernel/workqueue.c:3314) workerthread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) retfromfork (arch/x86/kernel/process.c:158) retfromforkasm (arch/x86/entry/entry64.S:245) </TASK>

[...]

Freed by task 118: kasansavestack (mm/kasan/common.c:57) kasansavetrack (mm/kasan/common.c:78) kasansavefreeinfo (mm/kasan/generic.c:584) kasanslabfree (mm/kasan/common.c:253 mm/kasan/common.c:285) kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6251 mm/slub.c:6566) pskbexpandhead (net/core/skbuff.c:2335) pskbpulltail (net/core/skbuff.c:2878 (discriminator 4)) mldquerywork (net/ipv6/mcast.c:1495 (discriminator 1)) mldquerywork (net/ipv6/mcast.c:1563) processonework (kernel/workqueue.c:3314) workerthread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) retfromfork (arch/x86/kernel/process.c:158) retfromforkasm (arch/x86/entry/entry64.S:245)

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

ipv4: restrict IPOPTSSRR and IPOPTLSRR options

This patch restricts setting Loose Source and Record Route (LSRR) and Strict Source and Record Route (SSRR) IP options to users with CAPNETRAW capability.

This prevents unprivileged applications from forcing packets to route through attacker-controlled nodes to leak TCP ISN and possibly other protocol information.

While LSRR and SSRR are commonly filtered in many network environments, they may still be supported and forwarded along some network paths.

RFC 7126 (Recommendations on Filtering of IPv4 Packets Containing IPv4 Options) recommend to drop these options in 4.3 and 4.4.

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

netfilter: conntrackirc: fix possible out-of-bounds read

When parsing fails after we've matched the command string we should bail out instead of trying to match a different command.

This helper should be deprecated, given prevalence of TLS I doubt it has any relevance in 2026.

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

netfilter: nftexthdr: fix register tracking for FPRESENT flag

nftexthdrinit() passes user-controlled priv->len to nftparseregisterstore(), which marks that many bytes in the register bitmap as initialized. However, when NFTEXTHDRFPRESENT is set, the eval paths write only 1 byte (nftregstore8) or 4 bytes (dest = 0 on TCP/DCCP error path). When len > 4, registers beyond the first are never written, retaining uninitialized stack data from nftregs.

Bail out if userspace requests too much data when FPRESENT is set.

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

net: guard timestamp cmsgs to real error queue skbs

skbiserrqueue() treats PACKETOUTGOING as the sole marker for an skb from skerrorqueue. That assumption is not true for AFPACKET sockets: outgoing packet taps are also delivered to packet sockets with skb->pkttype == PACKETOUTGOING, but their skb->cb is owned by AFPACKET instead of struct sockexterrskb.

If such an skb is received with timestamping enabled, the generic timestamp cmsg path can read AFPACKET control-buffer state as sockexterrskb::optstats. With SORXQOVFL enabled, the packet drop counter overlaps optstats. An odd drop count makes the path emit SCMTIMESTAMPINGOPTSTATS with skb->len and skb->data. For non-linear skbs this copies past the linear head and can trigger hardened usercopy or disclose adjacent heap contents.

Keep skbiserrqueue() local to net/socket.c, but make it verify that the PACKETOUTGOING marker is paired with the sockrmemfree destructor installed by sockqueueerrskb(). AFPACKET receive skbs use normal receive ownership and no longer pass as error-queue skbs, while legitimate skerrorqueue entries keep the PACKETOUTGOING marker and sockrmemfree ownership.

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

tcp: restrict SOATTACHFILTER to priv users

This patch restricts the use of SOATTACHFILTER (cBPF) on TCP sockets to users with CAPNETADMIN capability.

This blocks potential side-channel attack where an unprivileged application attaches a filter to leak TCP sequence/acknowledgment numbers.

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

netfilter: nfqueue: hold bridge skb->dev while queued

brpassframeup() rewrites skb->dev from the ingress port to the bridge master before queueing bridge LOCALIN packets. NFQUEUE only holds references on state.in/out and bridge physdevs, so a queued bridge packet can retain a freed bridge master in skb->dev until reinjection.

When the verdict is reinjected later, brnetifreceiveskb() re-enters the receive path with skb->dev still pointing at the freed bridge master, triggering a use-after-free.

Store skb->dev in the queue entry, hold a reference on it for the queue lifetime, and use the saved device when dropping queued packets during NETDEVDOWN handling.

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

netfilter: nflog: validate MAC header was set before dumping it

The fallback path of dumpmacheader() guards the MAC header access only with "skb->macheader != skb->networkheader", without checking skbmacheaderwasset(). When the MAC header is unset, macheader is 0xffff, so the test passes and skbmacheader(skb) returns skb->head + 0xffff, ~64 KiB past the buffer; the loop then reads dev->hardheaderlen bytes out of bounds into the kernel log.

This is reachable via the netdev logger: nflogunknownpacket() calls dumpmacheader() unconditionally, and an skb sent through AFPACKET with PACKETQDISCBYPASS reaches the egress hook with macheader still unset (devqueuexmit(), which would reset it, is bypassed).

Add the skbmacheaderwasset() check the ARPHRDETHER path already uses, and replace the open-coded MAC header length test with skbmacheaderlen(). Only skbs with an unset MAC header are affected; valid ones are dumped as before.

BUG: KASAN: slab-out-of-bounds in dumpmacheader (net/netfilter/nflogsyslog.c:831) Read of size 1 at addr ffff88800ea49d3f by task exploit/148 Call Trace: kasanreport (mm/kasan/report.c:595) dumpmacheader (net/netfilter/nflogsyslog.c:831) nflognetdevpacket (net/netfilter/nflogsyslog.c:938 net/netfilter/nflogsyslog.c:963) nflogpacket (net/netfilter/nflog.c:260) nftlogeval (net/netfilter/nftlog.c:60) nftdochain (net/netfilter/nftablescore.c:285) nftdochainnetdev (net/netfilter/nftchainfilter.c:307) nfhookslow (net/netfilter/core.c:619) nfhookdirectegress (net/packet/afpacket.c:257) packetxmit (net/packet/afpacket.c:280) packetsendmsg (net/packet/afpacket.c:3114) syssendto (net/socket.c:2265)