The experimental USB host stack allocates a per-device configuration-descriptor buffer, udev->cfgdesc, from the dedicated usbdeviceheap in usbhdevicesetconfiguration() (subsys/usb/host/usbhdevice.c). On three failure paths — a failed full-length GETDESCRIPTOR(CONFIGURATION) read, a mismatch between the short and full descriptor reads, and a rejected descriptor in parseconfigurationdescriptor() — the buffer was released with kheapfree() but the pointer was left dangling. The cleanup in usbhdevicefree() is guarded only by if (udev->cfgdesc != NULL), so it frees the same block a second time.

The path is driven entirely by the attached peripheral: usbhdeviceconnect() calls usbhdeviceinit(), which ends in usbhdevicesetconfiguration(), and on failure usbhdeviceconnect() calls usbhdevicefree(). On v4.4.x this happens during the same enumeration, with no unplug required; on v4.1.0–v4.3.x the second free instead arrives via devremovedhandler()/devconnectedhandler() in subsys/usb/host/usbhcore.c, so it requires a removal or duplicate-connect event after the failed enumeration — a sequence the attached device fully controls. A malicious or malformed USB device only has to answer the first 9-byte configuration-descriptor request with a well-formed header and then fail any of the three checks, for example by returning a full descriptor whose interface count disagrees with bNumInterfaces, or by answering the second read with different bytes.

The result is a double free on usbdeviceheap. On builds where lib/heap hardening is active (the current default CONFIGSYSHEAPHARDENINGBASIC), sysheapfree() detects the already-free chunk and calls kpanic(), giving a deterministic, peripheral-triggered denial of service of the USB host. On builds without that detection — earlier releases, or CONFIGSYSHEAPHARDENINGNONE — the second free manipulates a chunk already on the free list, corrupting the heap's free list so that later allocations can return overlapping or invalid blocks.

Exploitation beyond denial of service is bounded by the fact that usbdeviceheap is a small dedicated heap (CONFIGUSBHUSBDEVICEHEAP, default 1024 bytes) whose only client is this descriptor buffer, and by CONFIGUSBHOSTSTACK being marked experimental and disabled by default. The fix sets udev->cfgdesc = NULL after every kheapfree(), making the cleanup guard sound.

Public exploits are now available for four recently patched Linux kernel vulnerabilities: • CVE-2026-80844 — DirtyAH6 • CVE-2026-81000 — TUNderflow • CVE-2026-68121 — PPPoEject • CVE-2026-74469 — DiagSpill These are mainly local privilege escalation bugs. So an attacker would generally need some access to the system first, but could potentially use these flaws to gain root access. This matters especially for shared servers, cloud/hosting systems and machines running older kernels. Fixes are already available, so updating your kernel/distro packages is recommended. So far, there are no reports of these exploits being used in real-world attacks.

Source:

On 9/18/26 11:30 AM, Kevin Riggle wrote: Would it be as conceptually straightforward on the distro side as breaking most of these less-common modules out into their own packages, e.g. linux-module-pppoe, linux-module-sctp, etc? That is exactly what Hanno said to do, so I presume that he thinks it is as simple as that.

There are, of course, challenges. Not all distribution package managers support split subpackages -- the Gentoo package manager does not, albeit people often compile from source on that distro ;) so it is redundant for the most part but also impossible to implement for "gentoo-kernel-bin", or for --getbinpkg "gentoo-kernel".

It also opens up a slightly worrying concern, that if you don't ship the whole thing together they can get out of sync. I doubt it would be very good for ABI if modules can be built against one kernel .config, then loaded against a very different one because package managers aren't describing the binding between two packages with anything closer than a

rundepend=" ${parentpackage}==${exactreleasetag}-${monotonicintegerbuildid}

"

Depending on package manager, buildid may be stored as:

- part of the "Version" field (e.g. debian) and defined purely as a versioning convention

- some extra field that is parsed as a version, e.g. Gentoo "${PR}" (package revision) or Arch Linux "pkgrel", rpm "Release:", etc.

Where it exists, it inevitably refers to a text value in a build recipe. For rpm, you can use %autorelease which parses git log; it doesn't really solve the problem here.

So you would have to be very careful about consistently incrementing that and then it would break anyway if someone decides to rebuild an existing package from source, which, well, kernels and people rebuilding from source. ;) Hardly uncommon.

It's quite rare for software to need such tight binding. So adding such a package manager feature (to bind subpackages to an extra metadata field outside of version + revision/buildid, probably a UUID or hash) is potentially a lot of one-off effort.

...

Alternatively, kernels could ship with a default /usr/lib/modprobe.d file that sets "install ... /bin/false" for modules that are shipped but "a bad idea unless you really know you need it". The size of the resulting package cannot be minimized by dropping unneeded large files, but that's the status quo today. It seems eminently reasonable that this would solve the security issue, and people could install an override in /etc/modprobe.d for any modules they don't want to be masked.

Some distros also have a package manager config file setting (INSTALLMASK, NoExtract) to skip individual filenames or filename globs from being unpacked by any package. It is a bit bulky to use (one record per module you don't use) and likely not suitable for automatic deployment with user opt-out as it's quite disruptive if you do end up needing the module.

-- Eli Schwartz

gptpmiqualifyannounce() in subsys/net/l2/ethernet/gptp/gptpmi.c walks the Path Trace TLV of a received IEEE 802.1AS Announce message, comparing each clock identity against the local one. The loop bound was taken solely from the attacker-controlled wire field announce->stepsremoved (accepted up to 254), never from announce->tlv.len, which is the field that states how many identities the TLV actually carries. Because pathsequence is the flexible member of the wire TLV (struct gptppathtracetlv) and GPTPANNOUNCE() yields a raw pointer into the received packet buffer, the memcmp() inside the loop can address memory well past the end of the received frame.

The stack's only length validation, GPTPANNOUNCECHECKLEN(), requires the received gPTP payload to be exactly 68 + tlv.len bytes — so it does not constrain the loop, it guarantees the data is absent. An unauthenticated attacker on the same Ethernet segment can send a single Announce frame declaring tlv.len = 0 with stepsremoved = 254; the frame passes the length check and reception path (netgptprecv() → gptphandlemsg() → gptpmiqualifyannounce()), which performs no authentication, and the loop then reads 255 entries of 8 bytes each — about 2 KB — beyond the end of the network buffer.

The impact is an out-of-bounds read. The bytes read are only used as a memcmp() operand and are never returned to the attacker, so there is no meaningful information disclosure; the practical risk is that the overread crosses a network buffer pool boundary into unmapped or MPU-protected memory and faults the networking RX thread, causing a denial of service. Exposure is limited to builds that enable the opt-in, experimental CONFIGNETGPTP (TSN/AVB deployments) and to attackers with layer-2 adjacency, since gPTP frames are sent to a link-local multicast address and are not routed.

The fix computes the true entry count as tlv.len / GPTPCLOCKIDLEN and rejects the announce when stepsremoved + 1 exceeds it, so the loop can no longer run past the data the packet-length check proved present.

i3c: master: Fix recursive locking during device registration

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

drm/rockchip: analogixdp: Fix OF node reference leak via auto cleanup

Sashiko reported a reference leak in rockchipdpdrmencoderenable(), the ofgetchildbyname() function does not call ofnodeput() in a symmetrical way [1].

Fix the device node reference leak by using free(devicenode) to automatically manage ofnodeput() for all device nodes.

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

smack: fix incorrect task context in smackmsgqueuemsgrcv

The smackmsgqueuemsgrcv() function incorrectly checks the permissions of the 'current' task instead of the 'target' task.

In the msgsnd() syscall path, if a receiver is already waiting, the pipelinedsend() optimization is used to push the message directly to the receiver task:

ipc/msg.cpipelinedsend(): smpstorerelease(&msr->rmsg, msg)

In this case, the 'sender' (current) task performs the check on behalf of the 'receiver' task (msr->rtsk, passed as the 'target' parameter):

ipc/msg.cpipelinedsend(): securitymsgqueuemsgrcv(,, target := msr->rtsk,,)

However, smackmsgqueuemsgrcv() ignores the 'target' and checks 'current':

smackmsgqueuemsgrcv(…) smkcuraccmsq(isp, MAYREADWRITE); // current task

'current' MAY satisfy smackmsgqueuemsgrcv r/w requirement, but 'target' (the receiver task) might NOT; as a result, an unauthorized receiver gets the message, violating MAC policy.

Test: 1) create a sysv message queue with label “foo” 2) echo "bar foo r" >/smack/load2 3) msgrcv(,,,0,MSGNOERROR) in "bar"-labeled task. The task is waiting for the messages ... 4) msgsnd() from a "foo"-labeled task: "bar"-labeled task gets the message.

This patch fixes the issue by checking permission on the 'target' task instead of 'current'.

(2008-02-04, Casey Schaufler)

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

platform/chrome: crosectypec: Reject out-of-bounds PD cap count

crostypecregisterpartnerpdos() copies the partner PDOs from the EC TYPECSTATUS response into the fixed capsdesc.pdo[PDOMAXOBJECTS] array.

memcpy(capsdesc.pdo, resp->sourcecappdos, sizeof(u32) resp->sourcecapcount); ... memcpy(capsdesc.pdo, resp->sinkcappdos, sizeof(u32) resp->sinkcapcount);

PDOMAXOBJECTS is 7. sourcecapcount and sinkcapcount are u8 fields from the EC. The only check is that they are not both zero. If either is larger than 7, the memcpy writes past the end of the array on the stack. A count of 255 overflows it by about 1 KB. The EC source arrays are only seven entries wide. A larger count reads past them too.

The ChromeOS EC firmware caps these counts today, so a compliant setup does not hit this. The kernel should still validate these values rather than trust them.

Validate the counts in crostypecregisterpartnerpdos() next to the memcpy. Skip the PDO registration if either count is above PDOMAXOBJECTS. The rest of crostypechandlestatus() still runs so events are handled and cleared.

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

HID: core: quiesce input in hidhwstop() to prevent use-after-free

A driver's probe calls hiddeviceiostart() to enable input delivery, then fails at a later initialization step and unwinds via hidhwstop(). The unwind frees struct hidraw via hidrawdisconnect() while in-flight HID reports may still be running on another CPU, dereferencing the freed object through hidrawreportevent(). syzbot reports the resulting use-after-free for the corsair-psu HID driver.

Edward Adam Davis posted a per-driver fix for corsair-psu that adds an explicit hiddeviceiostop() before hidhwstop() in the probe error path ("hwmon: prevent packets from going to driver for probe", 2026-04-28). Auditing the tree shows 15 drivers call hiddeviceiostart(); 7 also call hiddeviceiostop() and 8 do not:

drivers calling hiddeviceiostart() without a matching hiddeviceiostop() before hidhwstop(): drivers/hwmon/corsair-psu.c (fix posted by Edward) drivers/hwmon/corsair-cpro.c drivers/hwmon/nzxt-kraken3.c drivers/hwmon/nzxt-smart2.c drivers/hwmon/gigabytewaterforce.c drivers/hid/hid-logitech-dj.c drivers/hid/hid-nintendo.c drivers/hid/hid-mcp2221.c

Roughly half of all callers of the API are exposed. Centralize the quiesce in hidhwstop() so callers do not have to remember the matching stop: if a driver has left hdev->iostarted true on entry, call hiddeviceiostop() before hiddisconnect().

For the 7 drivers that already call hiddeviceiostop() correctly, hdev->iostarted is false on entry, the guard short-circuits, and behavior is unchanged.

No Fixes: tag because the affected drivers gained their hiddeviceiostart() calls independently over years; the bug is a class-wide API misuse rather than a regression from one commit.

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

ASoC: SOF: ipc4-topology: Return error for invalid number of formats

When the number of input or output formats is zero, sofipc4widgetsetupcompsrc() and sofipc4widgetsetupcompasrc() print an error and jump to the cleanup label. At that point 'ret' is still 0, because the earlier sofipc4getaudiofmt() call succeeded, so the function returns success and the caller never finds out that the widget setup actually failed.

Set ret to -EINVAL before the goto so the error gets reported.

ASoC: rt700-sdw: always drain jack work on remove

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

ASoC: fslaudmix: rework runtime PM handling in probe

After pmruntimeenable() the AUDMIX block is powered off and stays suspended until the first runtime resume. Register writes issued between probe() and the first resume (e.g. from DAPM or ALSA control paths) target unpowered hardware and cause a system hang.

Fix this by calling pmruntimeresumeandget() immediately after pmruntimeenable() to power the hardware up and enable its clocks. Release the reference afterwards with pmruntimeput() to allow the runtime PM framework to suspend the device and switch the regmap to cache-only mode when idle.

When CONFIGPM is disabled or runtime PM is not enabled, pmruntime calls are stubs that do not power up the hardware. Handle this case explicitly by calling fslaudmixruntimeresume() directly so the hardware is always initialised and its clocks are enabled, ensuring register accesses succeed regardless of PM configuration.

drm/lima: call drmmminit() with a valid allocation range

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

perf/x86/intel/uncore: Fix uncorebox ref/unref ordering

In uncoreeventcpuonline(), uncoreboxref() was called before uncorechangecontext(). uncoreboxref() gates on box->cpu >= 0, but box->cpu is still -1 at that point because uncorechangecontext() has not run yet. As a result, the box is never initialized on the first CPU to come online in a die, leaving it permanently uninitialized in the single-CPU-per-die case.

Thus, box->refcnt is one count below the true value, and in the CPU offline path, the box will be torn down on the second-to-last CPU.

In uncoreeventcpuoffline(), uncoreboxunref() was called after uncorechangecontext(), so box->cpu is already -1 when the collector CPU goes offline, which prevents it from tearing down the box.

Fix by swapping the call order in both paths so that uncorebox{ref,unref}() runs at the point where box->cpu reflects the correct context.

Move allocateboxes() out of uncoreboxref() to enable this reordering.

drm/amdgpu/pm/powerplay: bounds-check voltage index in Vega10 lookup

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

bpf: Copy per-CPU map value padding in copymapvaluelong()

In kernel, per-CPU map elements are stored with roundup(map->valuesize, 8) bytes. On UAPI lookup paths, it copies the rounded size for each CPU into a temporary buffer.

However, copymapvaluelong() passes 'map->valuesize' to bpfobjmemcpy(). When the map has special fields, bpfobjmemcpy() copies around those fields with memcpy(), and does not copy the tail padding between 'map->valuesize' and roundup(map->valuesize, 8).

The temporary UAPI lookup buffers are allocated without GFPZERO. As a result, when the per-CPU map's value size is not equal to roundup(map->valuesize, 8), UAPI LOOKUPELEM and its variants can return stale heap contents from that padding to user space. The same issue applies to bpfiter for per-CPU maps.

Pass roundup(map->valuesize, 8) to bpfobjmemcpy() from copymapvaluelong(), so per-CPU maps both with and without special fields copy the entire per-CPU slot. Remove the now redundant roundup() from bpfobjmemcpy()'s longmemcpy path.

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

mm/mminit: handle allocpercpu failure in freeareainitcorehotplug

We miss a failed allocation check for pgdat->percpunodestats, which results in a NULL deref when we offset into the per-cpu area.

Propagate -ENOMEM up the stack and leave percpunodestats pointing at bootnodestats so a later online can retry the allocation.

hotaddinitpgdat() returns NULL on failure, which tryonlinenode() already maps to -ENOMEM.

On failure nothing needs to be unwound: - the node is never marked online - percpunodestats is left pointing at bootnodestats - addmemoryresource() cleans up pending memblock resources - later online attempts retry the percpunodestats allocation

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

leds: lp5860: Fix a potential double-unlock

In lp5860deviceinit(), if lp5860initdt() fails, an already unlocked mutex is unlocked another time.

Slightly rework how the lock is taken/released to avoid this potential double unlock.

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

dmaengine: xilinxdma: Fix channel idle state management in AXIDMA and MCDMA interrupt handlers

Fix a race condition in AXIDMA and MCDMA irq handlers where the channel could be incorrectly marked as idle and attempt spurious transfers when descriptors are still being processed.

The issue occurs when: 1. Multiple descriptors are queued and active. 2. An interrupt fires after completing some descriptors. 3. xilinxdmacompletedescriptor() moves completed descriptors to donelist. 4. Channel is marked idle and starttransfer() is called even though activelist still contains unprocessed descriptors. 5. This leads to premature transfer attempts and potential descriptor corruption or missed completions.

Only mark the channel as idle and start new transfers when the active list is actually empty, ensuring proper channel state management and avoiding spurious transfer attempts.

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

csky: Fix a4/a5 restoration in syscall trace path

The syscall trace path reloads syscall arguments from ptregs before calling the syscall handler. On C-SKY ABIv2, the 5th and 6th syscall arguments are prepared as stack arguments before invoking syscallid.

The current code adjusts sp before loading LSAVEA4 and LSAVEA5. Since those offsets are relative to the original ptregs base, loading them after changing sp fetches the wrong slots. As a result, traced syscalls that use the 5th or 6th argument may receive corrupted arguments.

This is visible with mmap2(), which takes six arguments. A small PTRACESYSCALL reproducer opens a file and maps one page with:

mmap(NULL, 4096, PROTREAD | PROTEXEC, MAPPRIVATE, fd, 0)

Before the fix, the traced child fails the mmap and exits with 12. After the fix, the mapping succeeds and the child exits with 0.

Fix the trace path by loading a4/a5 from ptregs before changing sp.

Tested on: ck860f, linux-4.19.15, C-SKY abiv2

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

wifi: rtw89: debug: fix off by on in rtw89ppdustr()

This > comparison should be >= to avoid an out of bounds access.

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

platform/chrome: sensorhub: Fix memory overread in ring handler

maxresponse and sensornum are read from different EC commands:

- maxresponse is from crosecgetprotoinfo(). ecdev->maxresponse = info->maxresponsepacketsize - sizeof(struct echostresponse);

- sensornum is from crosecgetsensorcount(). sensornum = crosecgetsensorcount(ec);

With a malfunctioning EC firmware, it is possible that the msg->insize (i.e., fifoinfolength in the context) could be clamped in croseccmdxfer() because msg->insize is greater than maxresponse.

int fifoinfolength = sizeof(struct ecresponsemotionsensefifoinfo) + sizeof(u16) sensorhub->sensornum;

This means the number of read bytes could be less than expected. As a result, the subsequent memcpy() in crosecsensorhubringhandler() overreads the resp->fifoinfo buffer.

Check the return value of croseccmdxferstatus() and abort if the number of bytes read does not match the expected length.

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

crypto: qat - clear AES key schedule from stack

qatalgxtsreversekey() expands the forward XTS AES key on the stack. That schedule contains key material and can remain in the stack frame.

Clear the temporary cryptoaesctx with memzeroexplicit() after the copy.

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

crypto: qat - cancel work on re-enable SR-IOV timeout

The QAT reset worker queues SR-IOV reenable work using a workstruct and completion embedded in an on-stack adfsriovdevdata. If the completion wait times out, the reset worker can return while devicesriovwq still holds or executes the stack-backed work item.

Cancel the work on the devicesriovwq on timeout before the stack frame unwinds.

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

crypto: atmel-sha204a - fix heap info leak on I2C transfer failure

The nonblocking RNG path allocates a workdata structure to track the state of an in-flight asynchronous I2C request. This pointer is stored in rng->priv and later consumed by the read path once the transaction completes.

If the underlying I2C transfer fails, the completion callback is invoked with a non-zero status. In this case, the allocated workdata is not usable for producing RNG output and must not remain associated with the hwrng state.

Previously, the failure path only logged a warning but left the pointer state uncleared, which can result in subsequent read attempts observing stale state and interpreting it as valid completion data.

Fix this by freeing the pending workdata. The I2C transaction reports an error. This ensures that failed requests do not leave residual state behind that could be interpreted as valid RNG data on later reads. Clearing rng->priv is done at the subsequent call to nonblocking read.

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

crypto: sa2ul - stop probe if context pool creation fails

saulprobe() calls sainitmem() to create the DMA pool used for security context buffers, but ignores its return value. If pool creation fails, probe still continues with DMA setup, algorithm registration and child population even though later request setup depends on that pool.

Stop probing when sainitmem() fails, and route that failure to the PM cleanup path without attempting to destroy an uncreated DMA pool.

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

RDMA/bngre: return a timeout when firmware responses stall

waitforresp() documents that it returns a non-zero error when a firmware command does not complete, and bngrercfwsendmessage() already marks the firmware as stalled when the helper returns -ENODEV.

However, the helper ignores waiteventtimeout() expiry. If the response slot remains in use after the timeout and after the polled CREQ service attempt, the loop starts another full timeout period and can repeat forever.

Return -ENODEV after a timed out wait that still has no response. The existing caller then marks FIRMWARESTALLDETECTED and returns -ETIMEDOUT to the command issuer.

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

nvmet-rdma: fix response resource leak on queue teardown

When an nvme target with rdma transport is removed while I/Os are in flight, a response can be posted but its send completion is never delivered before the connection is torn down. As a result nvmetrdmasenddone() and nvmetrdmareleasersp() are never called for the response, and this leaks the allocated RDMA read/write context and request SGLs.

These leaks are recreated by running blktests nvme/061 with the rdma transport and the siw driver. Kernel kmemleak feature reports them as follows:

unreferenced object 0xffff88812bc490c0 (size 32): comm "kworker/2:1H", pid 409, jiffies 4307744490 backtrace (crc 89afd339): kmallocnoprof+0x5f9/0x890 sglallocorder+0x7b/0x380 nvmetreqallocsgls+0x290/0x4f0 [nvmet] nvmetrdmamapsglkeyed+0x241/0x12e0 [nvmetrdma] nvmetrdmahandlecommand+0x73e/0xb80 [nvmetrdma] ibprocesscq+0x149/0x4c0 [ibcore] ibcqpollwork+0x49/0x160 [ibcore] processonework+0x8b2/0x1640 workerthread+0x5fd/0xfe0 kthread+0x367/0x460 retfromfork+0x655/0x9d0 retfromforkasm+0x1a/0x30

unreferenced object 0xffff88814bd05e80 (size 64): comm "kworker/3:1H", pid 148, jiffies 4295195428 backtrace (crc e35510cb): kmallocnoprof+0x5f9/0x890 rdmarwctxinit+0x333/0x1fa0 [ibcore] nvmetrdmamapsglkeyed+0x5c8/0x12e0 [nvmetrdma] nvmetrdmahandlecommand+0x73e/0xb80 [nvmetrdma] ibprocesscq+0x149/0x4c0 [ibcore] ibcqpollwork+0x49/0x160 [ibcore] processonework+0x8b2/0x1640 workerthread+0x5fd/0xfe0 kthread+0x367/0x460 retfromfork+0x655/0x9d0 retfromforkasm+0x1a/0x30

To avoid the memory leaks, reclaim the memory of the in-flight responses when the queue QP is torn down. Call nvmetrdmafreerspresources() that frees up the RDMA read/write context and the request SGLs of such responses.

cgroup/cpuset: Make nrdeadlinetasks an atomict

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

time/namespace: Validate nanosecond field in proctimenssetoffset()

The function validates tvsec to be within [-KTIMESECMAX, KTIMESECMAX] but never validates that tvnsec is within the valid range of [0, NSECPERSEC-1] before using it in timespec64add().

timespec64add() expects both timespec64 structures to have normalized values with tvnsec in the range [0, 999999999]. If off->val.tvnsec contains invalid values (negative or >= NSECPERSEC), it could lead to incorrect calculations or unexpected behavior.

Add validation to ensure tvnsec is within the valid range before performing the addition.