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

usb: gadget: renesasusb3: validate endpoint index in standard request handlers

The GETSTATUS and SET/CLEARFEATURE handlers extract the endpoint number from the host-supplied wIndex without any sort of validation. Fix this up by validating the number of endpoints actually match up with the number the device has before attempting to dereference a pointer based on this math.

This is just like what was done in commit ee0d382feb44 ("usb: gadget: aspeedudc: validate endpoint index for ast udc") for the aspeed driver.

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

mm/hugememory: transfer the pmd dirty bit to the folio on zap

zaphugepmdfolio() propagates the pmd young bit to the folio for the file case, but not the dirty bit. The pte path does propagate it, in zappresentfolioptes() and so does the pmd split path, in splithugepmdlocked().

For most file mappings the omission is harmless, because writing to a shared file mapping goes through pagemkwrite(), which dirties the folio. tmpfs is different: it has no pagemkwrite(), and vmawantswritenotify() is false for it, so a read fault on a MAPSHARED tmpfs mapping installs a writable pmd via doreadfault(). doreadfault() does not call faultdirtysharedpage(), so subsequent stores through that mapping set only the hardware dirty bit in the pmd and never call foliomarkdirty(). A shmem folio allocated by a fault is marked uptodate but not dirty (see the clear: block in shmemgetfoliogfp()), so PGdirty is never set at all.

Unmapping such a folio - munmap(), or exitmmap() when the process dies - then loses the only record that it was written, because zaphugepmd() drops the pmd without transferring the dirty bit. Reclaim afterwards sees a clean shmem folio: the whole swap-out block in shrinkfoliolist() is inside "if (foliotestdirty(folio))", so pageout() is skipped and the folio falls into removemapping(). There, folioisfilelru() is false for a swapbacked folio, so no shadow entry is created and filemapremovefolio(folio, NULL) simply empties the ipages slot. The data is freed without ever being written to swap, and the next fault on that index returns a freshly zeroed folio.

This is silent data loss for any process that keeps state in a MAPSHARED tmpfs segment across an unmap - for example a cache handed from one process generation to the next through /dev/shm. It requires the folio to be PMD-mapped, so it only shows up once shmem THP is enabled (which is what we did in Meta fleet and started noticing crashes); with THP off the pte path transfers the dirty bit correctly. It also only becomes visible when swap is enabled, because with no swap device shmem folios (which are on the anon LRU) are not scanned by reclaim at all, so the clean folio is never dropped.

Reproduced on x8664 with a tmpfs mounted huge=withinsize: read-fault a 2MB-backed region, write a known pattern through the resulting mapping, munmap, force reclaim of the cgroup, then re-map and read back. Without this patch the region reads back as zeros and vmstat shows zswpout 0 - the data was discarded rather than swapped. With this patch the region reads back correctly and the pages are swapped out as expected. With huge=never, or when the first touch is a write, the test passes either way.

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

net: serialize netifrunning() check in enqueuetobacklog()

Syzbot reported a KASAN slab-use-after-free in fibruleslookup().

The root cause is a race condition where packets can escape the backlog flushing during device unregistration (e.g., during netns exit).

Commit e9e4dd3267d0 ("net: do not process device backlog during unregistration") introduced a lockless netifrunning() check in enqueuetobacklog() to prevent queuing packets to an unregistering device.

However, this creates a TOCTOU race window.

A lockless transmitter (like vethxmit) can pass the check before devclose() clears IFFUP. If the transmitter is then delayed, flushallbacklogs() can run and finish before the transmitter grabs the backlog lock and queues the packet. The packet then escapes the flush and triggers UAF later when processed.

Fix this by moving the netifrunning() check inside the backlog lock. This serializes the check with the flush work (which also grabs the lock). We then either queue the packet before the flush runs (so it gets flushed), or check netifrunning() after the flush/close completes (so it gets dropped).

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

Revert "media: v4l2-dev: fix error handling in videoregisterdevice()"

This reverts commit 2a934fdb01db6458288fc9386d3d8ceba6dd551a.

The intentions of that patch were good, but it doesn't work.

The idea is that if deviceregister fails, you have to do a putdevice to let the ref counter release resources.

However, the V4L2 API says that if videoregisterdevice() fails, then you have to call videodevicerelease(), which kfree()s the videodevice struct.

But the putdevice() will already have freed the struct, so you end up in a double-free scenario.

There is not really a good way of fixing this without breaking videoregisterdevice() into two parts, one that initializes everything, and one that does the actual deviceregister, and then converting all V4L2 drivers to this new model.

That is a massive job, and it is very unlikely that deviceregister will fail.

So rather than ending up in a double-free scenario, just revert this patch, and in that case we'll have a small memory leak. Which is a lot more robust.

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

wifi: mt76: mt7915: unlink TWT flow if the MCU rejects the agreement

The flow is added to dev->twtlist before sending the agreement to the firmware, but the error path leaves it linked while flowidmask is never set. The flow slot can then be reused and memset while still on the list, corrupting twtlist, and station removal leaves a dangling entry behind that mt7915mactwtschedlistadd() later walks.

ALSA: virmidi: Check card index validity at probe

i2c: imx: Fix slave registration race and error handling

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

ALSA: scarlett2: Use a private URB for the notification endpoint

scarlett2initnotify() used mixer->urb, which sndusbmixerstatuscreate() allocates for the UAC2 status interrupt endpoint and mixer.c manages. On a device with that endpoint, the "already in use" check fires on the status URB and returns 0 for success without doing anything. No notification URB is submitted, and cmddone is left zeroed because it is initialised past that check and nowhere else. scarlett2usbinit() then issues SCARLETT2USBINIT1 and waitforcompletiontimeout() would crash adding to the zeroed wait.head.

Use a separate URB in scarlett2data, as done for FCP, and initialise cmddone in scarlett2initprivate(). mixer.c was also freeing the URB in sndusbmixerfree() and resubmitting it in sndusbmixeractivate(), so scarlett2 must now do both: add scarlett2cleanupurb(), called from privatefree and privatesuspend, and a privateresume callback to re-establish the URB after resume. scarlett2initnotify() is reached from there, and the URB kill path in scarlett2notify() completes cmddone, leaving a stale count that would satisfy the next command's wait before the device ACKs. Use reinitcompletion() to clear it.

Also free the URB if the transfer buffer allocation fails, and both if usbsubmiturb() fails. Move scarlett2initnotify() up next to scarlett2cleanupurb() so scarlett2initprivate() can reference it without a forward declaration.

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

ALSA: pcm: Fix race between non-atomic ops and trigger-start

We protect the races of the concurrent state transitions between atomic PCM ops, but the checks between the non-atomic ops (hwparams, hwfree and prepare) and the atomic ops aren't perfect; there is a check of the conflicting PCM state at the beginning of hwparams & co, but the atomic PCM ops can be still issued during the non-atomic PCM operations. An example such scenario is that a thread A re-issues the PREPARE or HWPARAMS for the already prepared stream, while another thread B triggers the PCM start in the middle of the prepare operation. Although this usually doesn't lead to much serious issues, it can give some inconsistency as reported by syzkaller (such as ODEBUG warning).

There are various atomic PCM ops, and basically the only problem is the PCM start as it operates from the PREPARED state. Other trigger commands (stop, etc) are for the running or the other special state, hence they are filtered as pre-condition.

This patch is for preventing the PCM trigger-start during the non- atomic operations in order to address the problems above. Fortunately, the hwparams, hwfree and prepare operations call sndpcmbufferaccesslock(), and this can be used for checking the concurrent operations at the PCM trigger -- which sets the runtime->bufferaccessing to a negative (if possible), so the PCM trigger just needs to check the runtime->bufferaccessing value; if it's negative, it means the concurrent non-atomic PCM ops is running.

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

wifi: mt76: mt7925: ensure tx headroom in usbsdiotxprepareskb

mt7925usbsdiotxprepareskb() pushes a TX descriptor and a USB header onto every skb and assumes the headroom for them is already there. That holds for locally generated traffic, where mac80211 reserves hw->extratxheadroom, but forwarded frames are sent through ieee802118023xmit(), which does not reserve it. Bridge a wired interface to an mt7925u AP and the first forwarded frame that arrives short panics the kernel:

skbuff: skbunderpanic: len:415 put:4 tail:0x19b end:0x640 dev:wlan1 kernel BUG at net/core/skbuff.c:212! Call trace: skbpanic+0x58/0x60 (P) skbpush+0x58/0x60 mt7925usbsdiotxprepareskb+0xf8/0x1b8 [mt7925common] mt76utxqueueskb+0xa0/0x1f8 [mt76usb] mt76txqueueskb+0x54/0xe8 [mt76] mt76txqschedule.part.0+0x204/0x478 [mt76] mt76txqscheduleall+0x50/0x80 [mt76] mt792xtxworker+0x68/0x100 [mt792xlib] mt76workerfn+0x84/0x150 [mt76]

Whether a given setup hits it depends on how much headroom the ingress netdev leaves in its rx skbs. Reproduced on a Raspberry Pi 5 bridging onboard ethernet to a Netgear A9000; originally reported on an MT7986 router running OpenWrt. Nick Morrow's testing on a Pi 4 (bcmgenet), which leaves more headroom, helped narrow the trigger to the ingress path.

The same bug was fixed on mt7921 by commit 98c4d0abf5c4 ("mt76: mt7921: don't assume adequate headroom for SDIO headers"), but mt7925 was copied from mt7921 without the fix. Add the same guard here.

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

Bluetooth: eir: Fix OOB read in eirgetservicedata()

eirgetservicedata() walks the advertising data for a Service Data field with a matching UUID. On a mismatch it advances:

eir += dlen; eirlen -= dlen;

eirgetdata() reports dlen as the field's data length, but the field spans dlen + 2 bytes once its length and type bytes count, and more when non-Service-Data fields were skipped to reach it. The pointer lands correctly on the next field. eirlen does not, and the shortfall compounds across fields until eirgetdata() reads the length and type bytes of a "field" past the end of the buffer.

For an ISO broadcast sink that buffer is hcon->leperadvdata[], filled from the periodic advertising reports of a remote broadcaster. A PA payload packed with mismatching Service Data fields walks off the array into the rest of struct hciconn. A drifted field that matches the BAA UUID puts those bytes in isopi(sk)->base, where user space reads them back with getsockopt(BTISOBASE).

Recompute eirlen from the end of the buffer each iteration.

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

ALSA: ump: fix double free of outcvts on rawmidi error

sndumpattachlegacyrawmidi() allocates the legacy conversion array ump->outcvts and, on the sndrawmidinew() error path, frees it with kfree() but leaves ump->outcvts pointing at the freed memory. When the endpoint is later torn down, sndumpendpointfree() frees ump->outcvts a second time, resulting in a double free.

The host snd-usb-audio driver attaches the legacy rawmidi for any USB MIDI 2.0 (UMP) device, so a device that makes sndrawmidinew() fail reaches this path on enumeration.

Clear ump->outcvts after freeing it on the error path so it is not freed again during teardown.

Discovered by XBOW, triaged by Baul Lee <baul.lee@xbow.com>

HID: rmi: fix OOB access with undersized RMI reports

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

crypto: marvell/octeontx - fix DMA cleanup using wrong loop index

The sgcleanup path used list[i] instead of list[j] when unmapping DMA buffers, leaking successfully mapped entries and repeatedly unmapping the failed one.

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

ALSA: seq: midi: Serialize input teardown with eventinput

sndmidiinputevent() must not be running while a rawmidi substream is closing, since this can lead to the trigger state becoming out-of-step through this sequence in sndrawmidiinputtrigger():

sndrawmidiinputtrigger(up=0) sndmidiinputevent() -> sndrawmidikernelread() -> sndrawmidiinputtrigger(up=1) -> cancelworksync()

which ends with the underlying device being active unexpectedly.

When this is called from closesubstream(), further input can re-trigger the input event leaving it running after rawmidireleasepriv() has set rfile->rmidi to NULL which leads to:

Unable to handle kernel NULL pointer dereference at virtual address 00000000000000b0 Call trace: sndmidiinputevent+0x3c/0x134 [sndseqmidi] (P) sndrawmidiinputeventwork+0x1c/0x2c processonework+0x150/0x3a4 workerthread+0x190/0x318

Apply a similar approach to commit ef7607ab1c8ad ("ALSA: seq: midi: Serialize output teardown with eventinput") which fixed the same issue in the output direction, but updated to use RCU following Takashi Iwai's proposed follow-on patch [1].

With this change in place, midisynthunsubscribe() clears the input file so sndmidiinputevent() will not re-trigger the stream and will be quiesced by the cancelworksync() in sndrawmidiinputtrigger().

[1] https://lore.kernel.org/linux-sound/20260813144224.753399-1-tiwai@suse.de/

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

Bluetooth: MGMT: Fix adv monitor add failure cleanup

hciaddadvmonitor() publishes a new advmonitor in hdev->advmonitorsidr before the powered MSFT setup step. The MSFT offload add path can then fail either locally before the controller add command completes, or in the MSFT add callback. In the current queued management add flow, hcicmdsyncwork() still invokes mgmtaddadvpatternsmonitorcomplete() with the original pending command after msftaddmonitorpattern() returns.

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

MSFT add handling MGMT completion 1. insert monitor and handle 1. receive sync error 2. send MSFT add command 2. call add-monitor completion 3. callback sees bad response 3. load cmd->userdata 4. callback frees monitor 4. read monitor->handle

Local MSFT setup failures have the other half of the same ownership bug: they return an error after the IDR insertion, but no later code removes the failed monitor from the IDR.

Keep ownership with the pending management command until its completion. For normal management adds, the MSFT add callback now records successful controller state and returns errors to its caller. The management completion frees the monitor on non-success after copying the response handle, while resume/reregister callback-error cleanup remains in the MSFT callback. The success path keeps the existing bookkeeping.

Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in mgmtaddadvpatternsmonitorcomplete+0xfb/0x260 [bluetooth]

Call Trace: <TASK> dumpstacklvl+0x66/0xa0 printreport+0xce/0x5f0 ? mgmtaddadvpatternsmonitorcomplete+0xfb/0x260 [bluetooth] ? srsoaliasreturnthunk+0x5/0xfbef5 ? virtaddrvalid+0x19f/0x330 ? mgmtaddadvpatternsmonitorcomplete+0xfb/0x260 [bluetooth] kasanreport+0xe0/0x110 ? mgmtaddadvpatternsmonitorcomplete+0xfb/0x260 [bluetooth] mgmtaddadvpatternsmonitorcomplete+0xfb/0x260 [bluetooth] ? srsoaliasreturnthunk+0x5/0xfbef5 ? 0xffffffffc00d00da ? pfxmgmtaddadvpatternsmonitorcomplete+0x10/0x10 [bluetooth] ? pfxmgmtaddadvpatternsmonitorcomplete+0x10/0x10 [bluetooth] ? hcicmdsyncwork+0x1ab/0x210 [bluetooth] hcicmdsyncwork+0x1c0/0x210 [bluetooth] ? pfxmgmtaddadvpatternsmonitorcomplete+0x10/0x10 [bluetooth] processonework+0x4fd/0xbc0 ? pfxprocessonework+0x10/0x10 ? srsoaliasreturnthunk+0x5/0xfbef5 ? srsoaliasreturnthunk+0x5/0xfbef5 ? listaddvalidorreport+0x37/0xf0 ? pfxhcicmdsyncwork+0x10/0x10 [bluetooth] ? 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 471 on cpu 3 at 285.205389s: kasansavestack+0x33/0x60 kasansavetrack+0x17/0x60 kasankmalloc+0xaa/0xb0 addadvpatternsmonitorrssi+0xd5/0x230 [bluetooth] hcisocksendmsg+0x96b/0xf80 [bluetooth] syssendto+0x2bc/0x2d0 x64syssendto+0x76/0x90 dosyscall64+0x115/0x6a0 entrySYSCALL64afterhwframe+0x77/0x7f

Freed by task 454 on cpu 2 at 285.217112s: kasansavestack+0x33/0x60 kasansavetrack+0x17/0x60 kasansavefreeinfo+0x3b/0x60 kasanslabfree+0x5f/0x80 kfree+0x313/0x590 msftaddmonitorsync+0x54a/0x570 [bluetooth] hciaddadvmonitor+0x133/0x180 [bluetooth] hcicmdsyncwork+0x187/0x210 [bluetooth] processonework+0x4fd/0xbc0 workerthread+0x2d8/0x570 kthread+0x1ad/0x1f0 retfromfork+0x3c9/0x540 retfromforkasm+0x1a/0x30

HID: mcp2221: stop device IO before hidhwstop

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

ALSA: aoa: check sndctlnew1() return value

sndctlnew1() can return NULL when memory allocation fails. In layout.c, the function does not check the return value before dereferencing ctl->id.name or passing to aoasndctladd(), which can lead to a NULL pointer dereference.

Add NULL checks after sndctlnew1() calls and return early if any fails.

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

ALSA: hda/cs35l41: Fix firmware load work teardown

cs35l41hda creates ALSA controls whose private data points at the cs35l41hda object. The firmware load control can also queue fwloadwork.

Those controls are not removed on component unbind, and device remove only cancels fwloadwork through cs35l41removedsp(). That helper is skipped when haloinitialized is false. With firmwareautostart disabled, a firmware load can be requested before the DSP has been initialized. If the component or device is removed before the queued work runs, the worker can run after teardown and dereference driver state that is no longer valid.

Track the created controls and remove them on unbind so no new control callback can reach the driver data or queue more work. Then cancel fwloadwork to drain any request that was already queued. Also cancel the work unconditionally during device remove before runtime PM teardown.

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

ALSA: compress: Fix task creation error unwind

sndcomprtasknew() allocates the driver task before validating the returned DMA buffers and reserving file descriptors. When either of those later steps fails, the core frees its task wrapper and DMA-buffer references without calling the driver's taskfree() callback. Any driver resources allocated by taskcreate() are therefore leaked.

The dual-fd allocation path also jumps to cleanup without storing the negative getunusedfdflags() result in retval. Since retval still contains the successful taskcreate() return value, TASKCREATE can incorrectly report success although the task was discarded.

Preserve the fd allocation errors and call taskfree() when failure occurs after a successful taskcreate() callback.

hwrng: virtio: clamp device-reported used.len at copydata()

ALSA: bcd2000: clear the URB pointers on disconnect

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

Bluetooth: ISO: fix leaking sk after socket release

isosockkill() tests !sockflag(sk, SOCKZAPPED) || sk->sksocket || sockflag(sk, SOCKDEAD) for early return, but this is always true since sockorphan(sk) sets SOCKDEAD, so the sk reference released by socket always leaks, isosockdestruct is never called.

The socket reference also leaks when isosockclose() does not set SOCKZAPPED, since isoconndel() does not call isosockkill() after zapping.

Fix by replacing SOCKDEAD by BTSKKILLED flag that is not used for something else, and locksock to ensure isosockkill() puts sk only after socket release only once. Release and isoconndel may run concurrently. Call isosockkill() from isoconndel() to clean sk up after zapping.

Remove call to isosockkill() from isosockclose(), as it's generally no-op there.

Bluetooth: mgmt: fix UAF in pair command cancellation

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

Bluetooth: hcisync: Fix advertising data UAFs

hcifindadvinstance() returns an advinfo pointer that is valid only while hdev->lock is held. The advertising command-sync paths perform instance lookups without that lock and, in some cases, retain the pointer while waiting for a controller response.

An advertising termination event can therefore interleave as follows:

hcicmdsyncwork hcirxwork hcifindadvinstance() hcicmdsyncstatus() wait for controller reply hcidevlock() hciremoveadvinstance() kfree(adv) adv->scanrspchanged = false

KASAN reported:

BUG: KASAN: slab-use-after-free in hcisetextscanrspdatasync+0x2e1/0x300 Write of size 1 at addr ffff88810a45d21d by task kworker/u17:0/88 Workqueue: hci0 hcicmdsyncwork Call Trace: hcisetextscanrspdatasync+0x2e1/0x300 hcischeduleadvinstancesync+0x390/0x4c0 hcicmdsyncwork+0x173/0x300 Allocated by task 87: hciaddadvinstance+0x538/0xac0 addadvertising+0x885/0x1160 Freed by task 89: kfree+0x131/0x3c0 hciremoveadvinstance+0x1d8/0x3b0 hcileextadvtermevt+0x17b/0x730

Protect the instance lookup and payload construction in the extended advertising, scan response, and periodic advertising data paths. Snapshot the advertising parameters under hdev->lock, but release the lock before waiting for the controller.

Clear advertising-data dirty bits before issuing their commands and restore them after a failure using a fresh lookup. Likewise, update the reported transmit power through a fresh lookup after the parameter command completes. No advinfo pointer then survives an HCI command wait.

fs/ntfs3: fix info-leak on partial LZNT decompress in nireadframe()

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

mm/vmscan: report RCU-tasks quiescent states in shrinklruvec()

I am seeing some rcutasks stalls in the Meta fleet during reclaim.

INFO: rcutasks detected stalls on tasks: 0000000088620d09: .. nvcsw: 6735/6735 holdout: 1 idlecpu: -1/8 task:GlobalCPUThread state:R running task pid:2552016 tgid:2524552 Call Trace: shrinklruvec memcgroupiter shrinknode dotrytofreepages trytofreepages allocfrozenpagesnoprof allocpagesnoprof pteallocone ptealloc handlemmfault

Nothing promises direct reclaim returns in bounded time, and the scan loop in shrinklruvec() only calls condresched(), which is a no-op on PREEMPTION kernels. Involuntary preemption is not a Tasks-RCU quiescent state, so the reclaiming task never reports one and becomes a holdout.

Upgrade it to condreschedtasksrcuqs(), which reports a quiescent state even when condresched() does nothing.

PS: This has been discussed in [1]

Bluetooth: fix UAF in l2capsockcleanuplisten() vs l2capconndel()

IB/isert: reject login PDUs declaring more data than was received

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

crypto: atmel-sha204a - fix blocking and non-blocking rng logic

The blocking and non-blocking paths were failing to provide valid entropy due to improper buffer management. Reading the buffer starting from byte 1, only fetch the 32 bytes of random data from the return message.

Tested on an Atmel SHA204A device.

Before (here for blocking), tests showed repeatedly reading reduced bytes. $ head -c 32 /dev/hwrng | hexdump -C 00000000 02 28 85 b3 47 40 f2 ee 00 00 00 00 00 00 00 00 |.(..G@..........| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020

After, the result will be similar to the following: $ head -c 32 /dev/hwrng | hexdump -C 00000000 5a fc 3f 13 14 68 fe 06 68 0a bd 04 83 6e 09 69 |Z.?..h..h....n.i| 00000010 75 ff cf 87 10 84 3b c9 c1 df ae eb 45 53 4c c3 |u.....;.....ESL.| 00000020