dmaengine: sun6i-dma: Fix reclaim descriptors while terminating DMA

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

ring-buffer: Fix crash passing ERRPTR to kthreadstop()

In testringbuffer()'s outfree cleanup loop, the check !rbthreads[cpu] only catches NULL entries and misses entries that hold an ERRPTR.

rbthreads[] is static, so unassigned slots are NULL. But when kthreadrunoncpu() fails for a cpu, it stores ERRPTR(-ENOMEM) (or -EINTR) in rbthreads[cpu] before the creation loop jumps to outfree. That entry is non-NULL, so the old !ptr check does not break, and the cleanup proceeds to call kthreadstop() on the ERRPTR. kthreadstop() then dereferences the bogus pointer, crashing the kernel during the lateinitcall self-test.

crash logs: BUG: kernel NULL pointer dereference, address: 000000000000001c Oops: 0002 [#1] SMP NOPTI CPU: 1 PID: 1 Comm: swapper/0 Not tainted 7.2.0-rc6-dirty #7 PREEMPT(lazy) RIP: 0010:kthreadstop+0x2e/0x220 RBX: fffffffffffffff4 CR2: 000000000000001c Call Trace: <TASK> testringbuffer+0x1ec/0x650 dooneinitcall+0x6c/0x2c0 kernelinitfreeable+0x21d/0x420 kernelinit+0x15/0x1c0 retfromfork+0x21b/0x320 </TASK> Kernel panic - not syncing: Fatal exception

When Ethernet bridging is enabled (CONFIGNETETHERNETBRIDGE), ethbridgeinputprocess() in subsys/net/l2/ethernet/bridge/bridgeinput.c decides how each frame received on a bridge member interface is handled. For frames that must also be delivered to the local stack, the code called ethbridgehandlelocally() and returned NETOK. That helper does not consume the packet — it only calls bridgeifacerecv() (via virtualrecv()), which returns NETCONTINUE without taking ownership of pkt.

The NETOK verdict then propagates through ethernetrecv() up to processingdata() in subsys/net/ip/netcore.c, where NETOK is interpreted as "the packet was consumed, do not free it." Because no consumer actually took ownership, the RX netpkt is never returned to the pool and is leaked. The concretely reproducible leak occurs for frames whose EtherType has no registered L3 handler when CONFIGNETETHERNETFORWARDUNRECOGNISEDETHERTYPE is set (default y when CONFIGNETSOCKETSPACKET is enabled): the fall-through L3 dispatch does not overwrite the NETOK verdict, so ethernetrecv() returns NETOK and the buffer is never released.

Any device on a bridged L2 segment can emit broadcast/multicast frames carrying an arbitrary EtherType with no authentication. Each such frame permanently consumes one buffer from the finite RX pool (CONFIGNETPKTRXCOUNT), so a brief broadcast flood exhausts the pool and the device can no longer receive traffic until it is rebooted — a persistent denial of service. There is no confidentiality or integrity impact.

The fix makes ethbridgehandlelocally() propagate the real netverdict and return NETCONTINUE for locally-kept frames, writing the bridge interface back through a new dstiface out-parameter so the packet follows the normal receive path and is unreferenced exactly once.

devlink: fix net namespace reference leak in reload

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

net/ncsi: fix heap OOB read in NCSICMDSENDCMD payload length

ncsisendcmdnl() takes the number of bytes to copy from the attacker-controlled ncsipkthdr.length field of the in-band packet header, while the source buffer is the NCSIATTRDATA netlink attribute whose readable size is nlalen() - sizeof(ncsipkthdr). The two length sources are never cross-checked: only nlalen() >= sizeof(struct ncsipkthdr) is enforced.

With hdr->length set larger than the attribute payload (up to 65535 against at most 2032 readable bytes), ncsicmdhandleroem() copies past the end of the netlink attribute buffer with unsafememcpy(), leaking up to ~64KB of kernel heap memory into the transmitted NCSI command packet. The destination skb is sized by the declared payload, so the write side does not overflow - this is a pure OOB read / information leak, reachable with CAPNETADMIN on systems with a registered NCSI device (e.g. OpenBMC on Aspeed BMC SoCs, where NETNCSI=y is standard).

Reject commands whose declared payload extends past the end of the data attribute.

The issue was found by the autokbug dynamic kernel fuzzer at Tencent Yunding Lab.

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

ovl: don't warn when the mount is completed from another user namespace

fsopen() records the caller's user namespace in fc->userns and hands back an ordinary file descriptor. Nothing ties the task that calls fsconfig(FSCONFIGCMDCREATE) to the task that created the context. The fd is inherited across fork() and exec() and it can be passed over a unix socket.

Completing a context from another user namespace is allowed on purpose. vfscmdcreate() authorizes the create with mountcapable(), which for FSUSERNSMOUNT checks nscapable(fc->userns, CAPSYSADMIN), and that succeeds for a task holding CAPSYSADMIN in an ancestor of fc->userns. So an unprivileged task can reach the WARNON() in ovlfillsuper(): create a user and a mount namespace in a child, call fsopen("overlay") there, send the fscontext fd to the parent and let the parent issue FSCONFIGCMDCREATE. Both namespaces come from a plain unshare(1) and no capability is needed anywhere:

WARNING: fs/overlayfs/super.c:1551 at ovlfillsuper+0x7b9/0x1e20 [overlay] CPU: 3 UID: 1000 PID: 3243376 Comm: fswarn Call Trace: gettreenodev+0x71/0xa0 ovlgettree+0x15/0x20 [overlay] vfsgettree+0x2a/0x100 vfscmdcreate+0x60/0xf0 dosysfsconfig+0x4b2/0x500

The child needs the mount namespace because fsopen() itself gates on maymount(), which asks for CAPSYSADMIN in the user namespace owning the caller's mount namespace. fsconfig() doesn't repeat that check.

It is a WARNON() and not a WARNONONCE(), so the condition can be raised in a loop to taint the kernel and flood the log, and it panics a kernel booted with paniconwarn.

Keep refusing the mount and stop warning about it. ovlparseparam() already spells a user namespace check this way for Optoverridecreds.

The compat32 kevent() handler translates a 64-bit kevent struct into a stack- declared 32-bit struct. It did not first zero the stack struct.

An unprivileged user may observe a small amount of uninitialized kernel stack data, which may contain sensitive information.

hwmon: (nct6775-core) Fix number of temperature registers for NCT6116

drm/vmwgfx: reject DXBINDQUERY without a DX context

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

KVM: x86/mmu: Fix use-after-free on vendor module reload

mmudestroycaches() destroys ptelistdesccache and mmupageheadercache, but leaves both pointers unchanged. The pointers live in kvm.ko, and therefore survive when a vendor module is unloaded while kvm.ko remains loaded.

If creation of ptelistdesccache fails during a subsequent vendor module load, its assignment sets ptelistdesccache to NULL and the error path calls mmudestroycaches(). mmupageheadercache still points to the cache destroyed during the preceding vendor module unload. Passing that stale pointer to kmemcachedestroy() causes a slab use-after-free.

Reproduce the issue on a v7.1.3 kernel with CONFIGKASAN=y, CONFIGKASANGENERIC=y, CONFIGKVM=m, and CONFIGKVMINTEL=m. A one-shot test hook forces ptelistdesccache to NULL on the second invocation of kvmmmuvendormoduleinit():

1. Load kvm.ko and kvm-intel.ko, creating both caches. 2. Unload only kvmintel, leaving kvm.ko loaded. 3. Reload kvmintel and force initialization through the -ENOMEM path.

KASAN reports:

BUG: KASAN: slab-use-after-free in kvmmmuvendormoduleinit+0x5b/0x170 [kvm] ... kmemcachedestroy+0x21/0x1d0 kvmmmuvendormoduleinit+0x5b/0x170 [kvm] ... Allocated by task 16817: kmemcachecreateargs+0x12c/0x3b0 kmemcachecreate.constprop.0+0xb6/0xf0 [kvm] kvmmmuvendormoduleinit+0x13b/0x170 [kvm] ... Freed by task 16820: kmemcachedestroy+0x117/0x1d0 kvmmmuvendormoduleexit+0x21/0x30 [kvm]

Clear both pointers immediately after destroying their caches so that the stored state reflects the caches' lifetime and repeated cleanup is safe.

With the fix applied, the same injected vendor module reload fails with -ENOMEM as expected and produces no KASAN report.

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

wifi: libertas: fix memory leak in helperfirmwarecb()

helperfirmwarecb() neglects to free the single-stage firmware image after a successful async load, leading to a memory leak in the USB firmware-download path.

Fix this memory leak by calling releasefirmware() immediately after lbsfwloaded() returns.

The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in the current wireless tree.

An x8664 allyesconfig build showed no new warnings. As we do not have compatible Libertas USB hardware for exercising this firmware-download path, no runtime testing was able to be performed.

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

wifi: mac80211: free APVLAN bcbuf SKBs outside IRQ lock

ieee80211dostop() removes APVLAN packets from the parent AP ps->bcbuf while holding ps->bcbuf.lock with IRQs disabled. It then calls ieee80211freetxskb() before dropping the lock.

ieee80211freetxskb() is not just a passive SKB release. For SKBs with TX status state it can report a dropped frame through cfg80211/nl80211, and that path can reach netlink tap transmit. This is the same reason the pending queue cleanup in ieee80211dostop() already unlinks SKBs under the queue lock and frees them after IRQ state is restored.

The buggy scenario involves two paths, with each column showing the order within that path:

APVLAN management TX: APVLAN stop: 1. attach ACK-status state 1. clear the running state 2. queue a multicast SKB on 2. take ps->bcbuf.lock with IRQs parent ps->bcbuf disabled 3. unlink the APVLAN SKB 4. call ieee80211freetxskb()

Unlink matching APVLAN SKBs from ps->bcbuf under the existing lock, but move them to a local free queue. Drop the lock and restore IRQ state before calling ieee80211freetxskb().

WARNING: kernel/softirq.c:430 at localbhenableip

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

usb: gadget: printer: fix infinite loop in printerread()

printerread() uses the same variable for the requested copy size and the number of bytes actually copied to user space. copytouser() returns the number of bytes not copied, so when it fails to copy anything, the computed copied length becomes zero.

In that case len, buf, currentrxbytes and currentrxbuf are left unchanged. If RX data is available and the user buffer remains unwritable, the read loop can repeat indefinitely.

Track the copied length separately and return -EFAULT, or the number of bytes already copied, if an iteration makes no progress.

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

usb: gadget: ftcm: synchronize delayed setalt with teardown

The ftcm setalt() path defers endpoint setup to a work item and completes the delayed status response from process context. The delayed work uses ftcm private state and may complete the setup request after disconnect or function teardown has already moved on.

Cancel and drain the delayed setalt work when the function is unbound or freed. For disable paths, which are reached under the composite device lock, use a small state machine and a non-sleeping cancellation path instead of cancelworksync(). If the work is already running, mark it cancelled and let the worker own the cleanup; otherwise tcmdisable() can cancel the queued work and clean up immediately.

Also serialize the final delayed-status completion with the cancellation check while holding the composite device lock. This prevents a disconnect from clearing delayedstatus while the worker is about to complete the control request.

Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in tcmdelayedsetalt+0x6c/0xef0

Call Trace: <TASK> dumpstacklvl+0x66/0xa0 printreport+0xce/0x630 ? tcmdelayedsetalt+0x6c/0xef0 ? srsoaliasreturnthunk+0x5/0xfbef5 ? virtaddrvalid+0x188/0x320 ? tcmdelayedsetalt+0x6c/0xef0 kasanreport+0xe0/0x110 ? tcmdelayedsetalt+0x6c/0xef0 tcmdelayedsetalt+0x6c/0xef0 ? pfxtcmdelayedsetalt+0x10/0x10 ? processonework+0x4cb/0xb90 ? rcuiswatching+0x20/0x50 ? tcmdelayedsetalt+0x9/0xef0 processonework+0x4d7/0xb90 ? pfxprocessonework+0x10/0x10 ? srsoaliasreturnthunk+0x5/0xfbef5 ? listaddvalidorreport+0x37/0xf0 ? pfxtcmdelayedsetalt+0x10/0x10 ? srsoaliasreturnthunk+0x5/0xfbef5 workerthread+0x2d8/0x570 ? pfxworkerthread+0x10/0x10 kthread+0x1ad/0x1f0 ? pfxkthread+0x10/0x10 retfromfork+0x3c9/0x540 ? pfxretfromfork+0x10/0x10 ? srsoaliasreturnthunk+0x5/0xfbef5 ? switchto+0x2e9/0x730 ? pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK>

Allocated by task 544: kasansavestack+0x33/0x60 kasansavetrack+0x14/0x30 kasankmalloc+0x8f/0xa0 tcmalloc+0x68/0x180 usbgetfunction+0x36/0x60 configusbcfglink+0x125/0x1b0 configfssymlink+0x322/0x890 vfssymlink+0xc2/0x270 filenamesymlinkat+0x295/0x2f0 x64syssymlinkat+0x62/0x90 dosyscall64+0x115/0x6a0 entrySYSCALL64afterhwframe+0x77/0x7f

Freed by task 661: kasansavestack+0x33/0x60 kasansavetrack+0x14/0x30 kasansavefreeinfo+0x3b/0x60 kasanslabfree+0x43/0x70 kfree+0x2f9/0x530 configusbcfgunlink+0x173/0x1e0 configfsunlink+0x1fa/0x340 vfsunlink+0x15c/0x510 filenameunlinkat+0x2ba/0x450 x64sysunlinkat+0x63/0x90 dosyscall64+0x115/0x6a0 entrySYSCALL64afterhwframe+0x77/0x7f

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

wifi: ath11k: fix NULL pointer dereference in ath11khalsrngaccessbegin

In ATH11KQMIEVENTFWREADY, ATH11KFLAGREGISTERED is set unconditionally even when ath11kcoreqmifirmwareready() fails. This leaves the driver in an inconsistent state where initialization is considered complete although the firmware ready handling did not finish successfully. During the subsequent SSR, the driver enters the restart path based on this incorrect state and dereferences uninitialized srng members, resulting in a NULL pointer dereference.

Call trace: ath11khalsrngaccessbegin+0xc/0x60 [ath11k] (P) ath11kcecleanuppipes+0x17c/0x180 [ath11k] ath11kcorerestart+0x40/0x168 [ath11k]

Fix this by: - skipping firmwareready if ATH11KFLAGREGISTERED is already set - setting ATH11KFLAGREGISTERED only when firmwareready succeeds - setting ATH11KFLAGQMIFAIL and aborting the FWREADY handling on error

Tested-on: WCN6750 hw1.0 AHB WLAN.MSL.2.0.c2-00204-QCAMSLSWPLZ-1

hwmon: (corsair-psu) Stop device IO before calling hidhwstop

bonding: fix devconfall NULL dereference when IPv6 is disabled

dpaa2-switch: put MAC endpoint device on disconnect

dpaa2-eth: put MAC endpoint device on disconnect

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

nfp: Check resource mutex allocation

nfpcppresourcefind() allocates a CPP mutex handle for the matching resource-table entry and then reports success. nfpresourcetryacquire() immediately passes that handle to nfpcppmutextrylock().

However, nfpcppmutexalloc() returns NULL on failure. If that happens for a matching table entry, the resource lookup still returns success and the following trylock dereferences a NULL mutex pointer while opening the resource.

nfpresourceacquire() already treats failure to allocate the table mutex as -ENOMEM. Do the same for the resource mutex and fail the lookup before publishing the rest of the resource handle.

This issue was found by a static analysis checker and confirmed by manual source review.

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

wan: wanxl: Only reset hardware after BAR mapping

wanxlpciinitone() stores the freshly allocated card in driver data before the PLX BAR is mapped. Several early probe failures then unwind through wanxlpciremoveone(), including failure to allocate the coherent status area or to restore the DMA mask.

wanxlpciremoveone() unconditionally calls wanxlreset(), and wanxlreset() dereferences card->plx. On those early failures card->plx is still NULL, so the error path can dereference a NULL MMIO pointer.

Only issue the hardware reset once the BAR mapping exists. The remaining cleanup in wanxlpciremoveone() already checks whether later resources were allocated.

This issue was found by a static analysis checker and confirmed by manual source review.

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

pdscore: fix auxiliary device add/del races

Two paths add or delete the same slot (pf->vfs[vfid].padev): a VF's pdscresetdone() and the PF's devlink enablevnet/disablevnet handler. They serialize on configlock, but neither guards the slot under it correctly.

add() registers and stores a new auxiliary device without first checking the slot, so a second add of an already-populated slot leaks the first device. del() makes that check outside configlock, so two concurrent dels can both pass it; the first clears the slot, and the second dereferences a NULL pointer.

Check and update the slot under configlock in both paths.

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

mm/khugepaged: write all dirty file folios when collapsing

[There is no upstream commit, as this code was removed by upstream commit 044925f9b565 ("mm: fs: remove filemapnrthps() functions and their users")]

As-is, khugepaged and writable-file opening exclude each other. A file cannot be open writeable and have THPs (because the filesystem is not aware of them). khugepaged will never collapse file pages for files that are opened writeable. On an open(ORDWR/OWRONLY), the page cache for that particular file is dropped. This is fine because nothing could've been dirtied.

However, there is an edge-case: collapsefile() might not be able to coexist with concurrent writers, but it can coexist with dirty folios (from previous writers). Therefore, the following can happen:

open(file, ORDWR) write(file) close(file) madvise(filemapping, MADVCOLLAPSE, some non-dirty range) open(file, ORDWR) nrthps > 0 truncateinodepages() / THPs are cleared out, but so are the dirty folios /

When this edge-case happens, there is data loss, as the dirty folios are fully discarded.

Fix it by fully writing back the page cache (and waiting) when collapsing file THPs. Doing so provides the guarantee that no dirty folio will be observed while there are active THPs. To fully ensure this is safe, the invalidatelock needs to be held while doing the writeout, so that dodentryopen()'s page cache truncation excludes this write-and-wait.

As a side effect, move the nrthps counter bumping outside the ipages lock. This is correct since the counter itself is an atomict and the producer <-> consumer correctness is provided by a full memory barrier: smpmb() in collapsefile()/memory barrier implied by full ordering in getwriteaccess() -> atomicincunlessnegative().

drm/amdgpu: validate CPGFXSHADOW chunk size in CS pass1

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

media: airspy: Return queued buffers on startstreaming() failure

The vb2 framework hands buffers to the driver via bufqueue() before calling startstreaming(). If startstreaming() returns an error without first returning those buffers via vb2bufferdone(), vb2startstreaming() fires WARNON(ownedbydrvcount) and the queued buffers leak.

airspystartstreaming() returned -ENODEV early when the USB device had been disconnected (s->udev == NULL) without returning any buffers that bufqueue() had already accepted. Take v4l2lock first and jump to the existing errclearbit label, which already drains s->queuedbufs via vb2bufferdone(..., VB2BUFSTATEQUEUED) before unlocking.

This mirrors the uvcvideo fix in commit 4cf3b6fd54eb ("media: uvcvideo: Return queued buffers on startstreaming() failure").

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

media: meson: vdec: Fix memory leak in error path of vdecopen

The vdecopen() function previously jumped directly to errm2mrelease when vdecinitctrls() failed, skipping release of the m2m context. This caused a resource leak.

Fix it by introducing a proper errm2mctxrelease label that calls v4l2m2mctxrelease(sess->m2mctx) before releasing the m2m device.

This was identified via kmemleak: unreferenced object 0xffff0000205d6878 (size 8): comm "v4lid", pid 5289, jiffies 4294938580 hex dump (first 8 bytes): 40 d2 49 18 00 00 ff ff @.I..... backtrace (crc d3204599): kmemleakalloc+0xc8/0xf0 kvmallocnodenoprof+0x60c/0x850 v4l2ctrlhandlerinitclass+0x1b4/0x2e8 [videodev] vdecopen+0x1f4/0x788 [mesonvdec] v4l2open+0x144/0x460 [videodev] chrdevopen+0x1ac/0x500 dodentryopen+0x3f0/0xfe8 vfsopen+0x68/0x320 doopen+0x2d8/0x9a8 pathopenat+0x1d0/0x4f0 dofilpopen+0x190/0x380 dosysopenat2+0xf8/0x1b0 arm64sysopenat+0x13c/0x1e8 invokesyscall+0xdc/0x268 el0svccommon.constprop.0+0x178/0x258 doel0svc+0x4c/0x70

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

wifi: mt76: mt7615: drop TXRXNOTIFY on non-mmio buses

PKTTYPETXRXNOTIFY is an mmio-only event, but mt7615rxcheck() and mt7615queuerxskb() dispatch it to mt7615mactxfree() on every bus. mt7615mactxfree() cleans the DMA tx queues with mt76queuetxcleanup(), which calls queueops->txcleanup(). Only the mmio queue ops implement that callback; on the mt7663 USB and SDIO buses it is NULL, so a TXRXNOTIFY there calls a NULL pointer in the RX worker. Same defect as the mt7921 and mt7925 patches in this series.

Drop the event on non-mmio buses via mt76ismmio(), as in commit 5683e1488aa9 ("wifi: mt76: connac: do not check WED status for non-mmio devices").

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

wifi: mt76: mt7921: drop TXRXNOTIFY on non-mmio buses

PKTTYPETXRXNOTIFY is an mmio-only event, but mt7921rxcheck() and mt7921queuerxskb() dispatch it to mt7921mactxfree() on every bus. mt7921mactxfree() cleans the DMA tx queues with mt76queuetxcleanup(), which calls queueops->txcleanup(). Only the mmio queue ops implement that callback; on USB and SDIO it is NULL, so a TXRXNOTIFY there calls a NULL pointer in the RX worker:

BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:0x0 Call Trace: mt7921mactxfree+0x64/0x310 [mt7921common] mt7921rxcheck+0x5f/0xf0 [mt7921common] mt76urxworker+0x1b9/0x620 [mt76usb]

Drop the event on non-mmio buses via mt76ismmio(), as in commit 5683e1488aa9 ("wifi: mt76: connac: do not check WED status for non-mmio devices").

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

staging: rtl8723bs: fix OOB reads in rtwgetwpsie()

rtwgetwpsie() iterates over IE data from network frames without validating that the IE header and payload fit within the remaining buffer before reading them. Specifically:

- inie[cnt + 1] is read without checking cnt + 1 < inlen - memcmp(&inie[cnt + 2], ...) accesses cnt + 2 without bounds check - inie[cnt + 1] is used as length without verifying payload fits

Add bounds checks at the top of the loop body to break early if fewer than 2 bytes remain for the IE header, or if the declared payload extends past the end of the buffer. Also require at least 4 bytes of payload before comparing the WPS OUI.

exec: fix unsigned loop counter wrap in transferargstostack()