futex: Prevent lockup in requeue-PI during signal/ timeout wakeup

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

net: qrtr: ns: Limit the maximum server registration per node

Current code does no bound checking on the number of servers added per node. A malicious client can flood NEWSERVER messages and exhaust memory.

Fix this issue by limiting the maximum number of server registrations to 256 per node. If the NEWSERVER message is received for an old port, then don't restrict it as it will get replaced. While at it, also rate limit the error messages in the failure path of qrtrnsworker().

Note that the limit of 256 is chosen based on the current platform requirements. If requirement changes in the future, this limit can be increased.

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:

platform/x86: uniwill-laptop: Do not enable the charging limit even when forced

It seems that on some older models (~2020) the battery charging limit can permanently damage the battery. Prevent users from enabling this feature thru the "force" module parameter to avoid causing permanent hardware damage on such devices.

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

Bluetooth: btmtk: fix urb->setuppacket leak in error paths

The setuppacket of control urb is not freed if usbsubmiturb fails or the submitted urb is killed. Add free in these two paths.

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

pdscore: fix debugfslookup dentry leak and error handling

debugfslookup() returns a dentry with an elevated reference count that must be released with dput(). The current code discards the returned dentry without calling dput(), causing a reference leak on every firmware reset recovery.

Additionally, when CONFIGDEBUGFS is disabled, debugfslookup() returns ERRPTR(-ENODEV), not NULL. The current check passes for error pointers and would call dput() on an invalid pointer, causing a crash.

drivers/base/memory: set mem->altmap after successful device registration

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

dma-mapping: move dmamapresource() sanity check into debug code

dmamapresource() uses pfnvalid() to ensure the range is not RAM. However, pfnvalid() only checks for availability of the memory map for a PFN but it does not ensure that the PFN is actually backed by RAM. On ARM64 with SPARSEMEM (128MB section granularity), MMIO addresses that share a section with RAM will falsely trigger the WARNONONCE and cause dmamapresource() to return DMAMAPPINGERROR.

This causes a WARNING on Raspberry Pi 4 during spibcm2835 probe because the SPI FIFO register (0xfe204004) falls in the same sparsemem section as the end of RAM (0xf8000000-0xfbffffff), both in section 31 (0xf8000000-0xffffffff).

Move the sanity check from dmamapresource() into debugdmamapphys() and replace the unreliable pfnvalid() with pfnvalid() && !PageReserved(), which correctly identifies actual usable RAM without false positives for MMIO regions that happen to have struct pages.

Since dmamapresource() is dmamapphys(DMAATTRMMIO), the check applies equally to both APIs. Any non-reserved page represents kernel memory to a sufficient degree that using DMAATTRMMIO on it is almost certainly wrong and risks breaking coherency on non-coherent platforms. ZONEDEVICE pages used for PCI P2P DMA (MEMORYDEVICEPCIP2PDMA) have PageReserved set, so they will not trigger a false positive.

The check no longer blocks the mapping and uses errprintk() to integrate with dma-debug filtering.

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

wifi: ath11k: fix error path leaks in some WMI WOW calls

Fix two instances where we used to directly return the result of ath11kwmicmdsend(...). Because we did not check the return value, we also did not free the skb in the error path.

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

netfs: Fix partial invalidation of streaming-write folio

In netfsinvalidatefolio(), if the region of a partial invalidation overlaps the front (but not all) of a dirty write cached in a streaming write page (dirty, but not uptodate, with the dirty region tracked by a netfsfolio struct), the function modifies the dirty region - but incorrectly as it moves the region forward by setting the start to the start, not the end, of the invalidation region.

Fix this by setting finfo->dirtyoffset to the end of the invalidation region (iend).

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

mm: pageext: add count limit to pageextiternext to prevent invalid PFN access

The pageext iteration API does not validate if the PFN still belongs to a valid section while advancing the iterator. When dynamically adding memory in the hotplug path, it can lead to a NULL pointer dereference during pageextlookup at the boundary of the last valid section when iterator count equals pgcount.

The foreachpageext() macro calls pageextiternext() as its loop increment. foreachpageext() does a "pageext = pageextiternext(&iter)" at the end. This causes pageextiternext() to increment iter->index past pgcount and call pageextlookup(startpfn + pgcount). During memory hotplug (online), the PFN at startpfn + pgcount may belong to a section that has not yet been initialized, causing pageextlookup() to trigger a NULL pointer dereference.

[ 14.555124][ T846] Call trace: [ 14.555125][ T846] lookuppageext+0x6c/0x108 (P) [ 14.555127][ T846] pageextlookup+0x30/0x3c [ 14.555129][ T846] resetpageowner+0x11c/0x260 [ 14.571201][ T846] freepagesok+0x5e8/0x8e0 [ 14.571204][ T846] freepagescore+0x78/0xf0 [ 14.571206][ T846] genericonlinepage+0x14/0x24 [ 14.597782][ T846] onlinepages+0x178/0x30c [ 14.597784][ T846] memoryblockchangestate+0x284/0x32c [ 14.597787][ T846] memorysubsysonline+0x4c/0x64 [ 14.597789][ T846] deviceonline+0x88/0xb0 [ 14.597791][ T846] onlinememoryblock+0x30/0x40 [ 14.597793][ T846] walkmemoryblocks+0xac/0xe8 [ 14.597794][ T846] addmemoryresource+0x280/0x298 [ 14.656161][ T846] addmemory+0x60/0x98

Move the iteration boundary enforcement inside the iterator functions, so callers cannot inadvertently access beyond the requested range.

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

module: decompress: check return value of moduleextendmaxpages()

moduleextendmaxpages() calls kvrealloc() internally and returns -ENOMEM on allocation failure. The return value is never checked.

If the initial allocation fails, info->pages remains NULL and info->maxpages remains 0. Subsequent calls to modulegetnextpage() will attempt to dynamically grow the array by calling moduleextendmaxpages(info, 0) since info->usedpages is 0. This results in kvrealloc(NULL, 0) returning ZEROSIZEPTR, which is treated as a success, leading to a dereference of ZEROSIZEPTR and a kernel oops.

Fix: add the missing error check after moduleextendmaxpages() and return immediately on failure. This matches the pattern used by every other kvrealloc() caller in the module loading path.

[Sami: Corrected the analysis in the commit message.]

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

iommufd: Break the loop on failure in iommufdfaultfopsread()

On a copytouser() failure inside the inner listforeachentry, only the inner loop breaks; the outer while re-fetches the just-restored fault group and retries the failing copytouser() forever, spinning the reader at 100% CPU with fault->mutex held.

Check rc after the inner loop and break the outer while as well.

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

iommufd: Set upper bounds on cache invalidation entrynum and entrylen

iommufdhwptinvalidate() takes a user-controlled entrynum and entrylen, each bounded only by U32MAX. An entrylen beyond the kernel's struct size makes the copy helper verify the extra bytes are zero, scanning that excess in one uninterruptible pass; a multi-gigabyte value over zeroed user memory trips the soft-lockup watchdog.

A large entrynum is the other half, driving the backend invalidation loop with no reschedule. The VT-d nested handler, for one, copies each entry and flushes caches per iteration, pinning the CPU on a non-preemptible kernel.

Cap both in the ioctl. entrylen is held under PAGESIZE, above any request struct, and entrynum under 1 << 19, the order of a hardware invalidation queue and well beyond any real batch, bounding the per-call loop length.

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

iommufd: Move vevent memory allocation outside spinlock

The veventq memory allocation happens inside the spinlock. Given its depth is decided by the user space, this leaves a vulnerability, where userspace can allocate large queues to exhaust atomic memory reserves.

Move the allocation outside the spinlock and use GFPNOWAIT, which can fail fast under memory pressure without dipping into the GFPATOMIC reserves or direct-reclaiming from the threaded IRQ handler. On allocation failure, queue the losteventsheader (so userspace learns of the drop) and return -ENOMEM so the caller learns of the kernel-side memory pressure.

This is intentionally distinct from the queue-overflow path, which also queues the losteventsheader but returns 0: a full queue is an expected userspace-pacing condition rather than a kernel error.

A subsequent change will cap the upper bound of the veventqdepth.

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

KVM: arm64: nv: Avoid dereferencing NULL VNCR pseudo-TLB

VNCR TLB invalidation occurs from MMU notifiers or TLBI instructions, and either can race against a vcpu not being onlined yet (no pseudo-TLB allocated). Similarly, the TLB might be invalid, and the invalidation should be skipped in this case.

Both kvminvalidatevncripa() and kvminvalidatevncrva() are expected to perform the same checks, except that the latter doesn't check for the allocation and blindly dereferences the pointer.

Solve this by introducing a new iterator built on top of the usual kvmforeachvcpu() that checks for both of the above conditions, and convert the two users to it.

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

iommufd: Set veventqdepth upper bound

iommufdveventqalloc() accepts any !0 veventqdepth from userspace, with an upper bound at U32MAX.

This leaves a vulnerability where userspace can allocate excessively large queues to exhaust kernel memory reserves.

Cap the veventqdepth (maximum number of entries) to 1 << 19, matching the maximum number of entries in the SMMUv3 EVTQ (the largest use case today).

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

i2c: imx-lpi2c: mark I2C adapter when hardware is powered down

On some i.MX platforms, certain I2C client drivers keep a periodic workqueue which continues to trigger I2C transfers.

During system suspend/resume, there exists a time window between: - suspendnoirq and the system entering suspend - the system starting to resume and resumenoirq

In this window, the I2C controller resources such as clock and pinctrl may already be disabled or not yet restored.

If a workqueue triggers an I2C transfer in this period, the driver attempts to access I2C registers while the hardware resources are unavailable, which may lead to system hang.

Mark the I2C adapter as suspended during noirq suspend and block new transfers until resume, ensuring that I2C transfers are only issued when hardware resources are available.

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

KVM: arm64: Don't leak PFN when kvmtranslatevncr() races MMU notifier

In the case that kvmtranslatevncr() races with an MMU notifier the early return does not release a reference on the faulted in PFN. Add the necessary call to kvmreleasefaultinpage() for the unused PFN.

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

Input: elani2c - prevent division by zero and arithmetic underflow

The Elan I2C touchpad driver queries the device for its physical dimensions and trace counts to calculate the device resolution and width. However, if the device firmware or device tree provides invalid zero values for xtraces or ytraces, it results in a fatal division-by-zero exception leading to a kernel panic during device probe.

Add checks to ensure these parameters are non-zero before performing the division. If invalid trace values are detected, fall back to a safe default of 1.

Additionally, prevent an arithmetic underflow in the touch reporting logic. Previously, if the calculated or fallback width was smaller than ETPFWIDTHREDUCE (90), the subtraction would underflow, resulting in a massive unsigned integer being reported to userspace. Clamp the adjusted width to a minimum of 0 to safely handle small physical dimensions and fallback scenarios.

Completing the probe with safe fallback values ensures the sysfs nodes are created, keeping the firmware update path intact so a recovery firmware can be flashed to the device.

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

fuse-uring: fix moving cancelled entry to entinuserspace list

fuseuringcancel() moves entries that are available (these have no reqs attached) to the entinuserspace list. entlistrequestexpired() checks the first entry on entinuserspace and dereferences ent->fusereq unconditionally, which will crash on a cancelled entry that was moved to this list.

Fix this by freeing the entry and dropping queuerefs directly in fuseuringcancel(). This is safe because cancel is the cancel handler itself - after iouringcmddone(), no more cancels will be dispatched for this command, and teardown serializes with cancel via queue->lock.

Since cancel now decrements queuerefs, fuseuringabort() must no longer gate fuseuringabortendrequests() on queuerefs > 0, as cancelled entries may have already dropped queuerefs while requests are still queued. Remove the gate so abort always flushes requests and stops queues.

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

fuse: avoid 32-bit prune notification count wrap

FUSENOTIFYPRUNE validates the nodeid payload length with:

size - sizeof(outarg) != outarg.count sizeof(u64)

On 32-bit kernels, sizet is also 32 bits, so the daemon-controlled count multiplication can wrap. A prune notification with count 0x20000000 and no nodeid payload passes the check, enters the copy loop, and asks the device copy path to read nodeids that are not present in the userspace write buffer. In QEMU this reaches the fusecopyfill() BUGON(!err) path.

Validate the payload length with arraysize() instead. That accepts exactly the same valid messages, but avoids wrapping arithmetic before the copy loop consumes the count.

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

fuse-uring: fix EFAULT clobber in fuseuringcommit

copyfromuser() returns the number of bytes not copied as an unsigned residual on failure (1..sizeof(struct fuseoutheader)). fuseuringcommit stores that residual in ssizet err, sets req->out.h.error to -EFAULT, then jumps to out: with err still holding the positive residual.

err = copyfromuser(&req->out.h, &ent->headers->inout, sizeof(req->out.h)); if (err) { req->out.h.error = -EFAULT; goto out; / err is the positive residual / } ... out: fuseuringreqend(ent, req, err);

fuseuringreqend() then runs

if (error) req->out.h.error = error;

which overwrites the just-assigned -EFAULT with the positive residual. FUSE callers such as fusesimplerequest() test err < 0 to detect failure, so the positive value is interpreted as success and the caller proceeds with an uninitialised or partial req->out.args.

Fix by assigning err = -EFAULT in the failure branch before jumping to out, so fuseuringreqend() receives a negative errno and sets req->out.h.error to -EFAULT.

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

fuse-uring: end fusereq on io-uring cancel task work

When iouring delivers task work with tw.cancel set (PFEXITING, PFKTHREAD fallback, or percpurefisdying on the ring context), fuseuringsendintask() takes the cancel branch, assigns -ECANCELED, and falls through to fuseuringsend(). That path only flips the entry to FRRSUSERSPACE and completes the iouring cmd; it never discharges the ring entry's owning reference to the fusereq that fuseuringaddreqtoringent() handed it at dispatch time.

fuseuringsendintask() tw.cancel == true err = -ECANCELED fuseuringsend(ent, cmd, err, issueflags) ent->state = FRRSUSERSPACE listmove(&ent->list, &queue->entinuserspace) ent->cmd = NULL iouringcmddone(-ECANCELED) / ent->fusereq still set, req still hashed /

The fusereq stays linked on fpq->processing[hash] and fuserequestend() is never invoked. The originating syscall thread blocks in D-state in requestwaitanswer() until fuseabortconn() runs, which can be the entire connection lifetime. For FRBACKGROUND requests fc->numbackground is never decremented either, so repeated cancels inflate the counter until maxbackground is hit and all later background ops stall. tw.cancel does not imply a connection abort (e.g. a single iouring worker thread exits while the fuse connection stays up), so this cannot be left for fuseabortconn() to clean up.

Ending the req but still routing the entry through fuseuringsend() is not enough: that leaves a req-less entry on entinuserspace, and entlistrequestexpired() dereferences ent->fusereq unconditionally on the head of that list, which would then NULL-deref.

Fix the cancel branch to release the entry directly. Remove it from the queue, complete the iouring cmd, end the fusereq, free the entry, and drop its queuerefs (waking the teardown waiter if it was the last).

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

fuse-uring: remove request-less entries from entwreqqueue to fix NULL deref

If a copy into the userspace ring buffer fails, a request will be terminated and fuseuringreqend() will set ent->fusereq to NULL but it will leave the entry on entwreqqueue in FRRSFUSEREQ state. This can lead to a NULL deref if the request expiration logic scans entwreqqueue in the window before the entry is moved off it.

Fix this by taking the entry off entwreqqueue and changing its state from FRRSFUSEREQ to FRRSINVALID before terminating the request.

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

xfs: don't wrap around quota ids in dqiterate

LOLLM noticed that qid is an unsigned 32-bit variable. If it happens to be set to XFSDQIDMAX due to a filesystem that actually has a dquot for IDMAX, then this addition will truncate to zero and the iteration starts over. Fix this by casting to u64.

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

MIPS: DEC: Prevent initial console buffer from landing in XKPHYS

In 64-bit configurations calling the initial console output handler from a kernel thread other than the initial one will result in a situation where the stack has been placed in the XKPHYS 64-bit memory segment and consequently so has been the buffer allocated there that is used as the argument corresponding to the %s' output conversion specifier for the firmware's printf() entry point.

This 64-bit address will then be truncated by 32-bit firmware, resulting in an attempt to access the wrong memory location, which in turn will cause all kinds of unpredictable behaviour, such as a kernel crash:

Console: colour dummy device 160x64 Calibrating delay loop... 49.36 BogoMIPS (lpj=192512) pidmax: default: 32768 minimum: 301 CPU 0 Unable to handle kernel paging request at virtual address 000000000203bd00, epc == ffffffffbfc08364, ra == ffffffffbfc08800 Oops[#1]: CPU: 0 PID: 0 Comm: swapper Not tainted 5.18.0-rc2-00254-gfb649bda6f56-dirty #121 $ 0 : 0000000000000000 0000000000000001 0000000000000023 ffffffff80684ba0 $ 4 : 000000000203bd00 ffffffffbfc0f3b4 ffffffffffffffff 0000000000000073 $ 8 : 0a303d7469000000 0000000000000000 0000000000000073 ffffffffbfc0f473 $12 : 0000000000000002 0000000000000000 ffffffff80684c1c 0000000000000000 $16 : 0000000000000000 ffffffff80596dc9 0000000000000000 ffffffffbfc09240 $20 : ffffffff80684c40 ffffffffbfc0f400 000000000000002d 000000000000002b $24 : ffffffffffffffbf 000000000203bd00 $28 : ffffffff805f0000 ffffffff80684b58 0000000000000030 ffffffffbfc08800 Hi : 0000000000000000 Lo : 0000000000000aa8 epc : ffffffffbfc08364 0xffffffffbfc08364 ra : ffffffffbfc08800 0xffffffffbfc08800 Status: 140120e2 KX SX UX KERNEL EXL Cause : 00000008 (ExcCode 02) BadVA : 000000000203bd00 PrId : 00000430 (R4000SC) Modules linked in: Process swapper (pid: 0, threadinfo=(ptrval), task=(ptrval), tls=0000000000000000) Stack : 0000000000000000 0000000000000000 0000000000000000 0000004d0000004d 80684cc0806a2a40 80596dc80000004d 8061000000000000 bfc0850c80684c38 0000000000000000 000000000203bd00 0000000000000000 0000000000000000 0000000000000000 00000000bfc0f3b4 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000002500000000 0000000000000000 0000000000000000 802c1a7400000000 0203bd0080596dc8 0203bd4d69000000 6c61632000000018 5f746567646e6172 6c616320625f6d6f 5f736e5f6d6f7266 206361323778302b 303d74696e726320 806a0a38806b0000 806a0a38806b0000 00000000806b0000 80683c58806b0000 ... Call Trace:

Code: a082ffff 03e00008 00601021 <80820000> 00001821 10400005 24840001 80820000 24630001

---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Fatal exception in interrupt

KN04 V2.1k (PC: 0xa0026768, SP: 0x806848e8) >>

In this case the pointer in $4 was truncated from 0x980000000203bd00 to 0x000000000203bd00.

This may happen when no final console driver has been enabled in the configuration and consequently the initial console continues being used late into bootstrap or with an upcoming change that will switch the zs driver to use a platform device, which in turn will make the console handover happen only after other kernel threads have already been started.

Fix the issue by making the buffer static and initdata, and therefore placed in the CKSEG0 32-bit compatibility segment, observing that the console output handler is called with the console lock held, implying no need for this code to be reentrant. Add an assertion to verify the buffer actually has been placed in a compatibility segment.

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

NTB: epf: Avoid pciiounmap() with offset when PEERSPAD and CONFIG share BAR

When BARPEERSPAD and BARCONFIG share one PCI BAR, the module teardown path ends up calling pciiounmap() on the same iomem with some offset, which is unnecessary and triggers a kernel warning like the following:

Trying to vunmap() nonexistent vm area (0000000069a5ffe8) WARNING: mm/vmalloc.c:3470 at vunmap+0x58/0x68, CPU#5: modprobe/2937 [...] Call trace: vunmap+0x58/0x68 (P) iounmap+0x34/0x48 pciiounmap+0x2c/0x40 ntbepfpciremove+0x44/0x80 [ntbhwepf] pcideviceremove+0x48/0xf8 deviceremove+0x50/0x88 devicereleasedriverinternal+0x1c8/0x228 driverdetach+0x50/0xb0 busremovedriver+0x74/0x100 driverunregister+0x34/0x68 pciunregisterdriver+0x34/0xa0 ntbepfpcidriverexit+0x14/0xfe0 [ntbhwepf] [...]

Fix it by unmapping only when PEERSPAD and CONFIG use difference bars.

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

kernel/fork: clear PFBLOCKTS in copyprocess()

PFBLOCKTS is only set in blktimegetns() when current->plug is non-NULL, and blkfinishplug() clears it via blkflushplug() before NULLing the plug pointer. copyprocess() breaks the invariant by inheriting PFBLOCKTS from the parent while resetting the child's plug to NULL.

Clear PFBLOCKTS alongside that assignment so callers can rely on "PFBLOCKTS set implies current->plug != NULL" and dereference current->plug unguarded.