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

nvme-apple: Destroy the admin queue on removal

The admin queue is allocated with blkmqallocqueue() but never destroyed. nvmefreectrl() only drops the last reference and blkmqexitqueue() and blksyncqueue() never run: the hctx is never moved to q->unusedhctxlist and the timeout timer and work stay armed on a queue that is about to be freed which will eventually oops inside blkmqtimeoutwork().

This can only be triggered when the controller fails to come up and is then immediately torn down again which is why no one ever ran into this before.

Let's just copy what the pcie driver does: unquiesce and destroy the admin queue before nvmeuninitctrl().

With this the following WARN followed by a panic no longer happens:

WARNING: block/blk-mq.c:4390 at blkmqrelease+0x194/0x238, CPU#4: kworker/u34:4/119 CPU: 4 UID: 0 PID: 119 Comm: kworker/u34:4 Not tainted 7.2.0-rc1-dirty #248 PREEMPT Hardware name: Apple Mac mini (M1, 2020) (DT) Workqueue: nvme-wq applenvmeremovedeadctrlwork pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : blkmqrelease+0x194/0x238 lr : blkmqrelease+0x58/0x238 sp : ffffc000833a3b50 x29: ffffc000833a3b50 x28: ffff80001d0450f8 x27: ffff800020c95200 x26: 0000000000000088 x25: 0000000000000000 x24: ffff800020f36805 x23: 0000000000000000 x22: ffffc00081a86878 x21: ffff800020be9c60 x20: 0000000000000000 x19: ffff800022501698 x18: 000000000000000a x17: 7365757165722066 x16: 666f7265776f7020 x15: 0000000000000000 x14: 0000000000000028 x13: 0000000000004def x12: 0000000000000003 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc000805b4fc8 x8 : ffffc00081915820 x7 : ffffc00081c4f3c8 x6 : 0000000000000001 x5 : 0000000000000004 x4 : ffff800022498d80 x3 : ffffc000833a3b14 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff800022501698 Call trace: blkmqrelease+0x194/0x238 (P) blkputqueue+0x8c/0xf0 nvmefreectrl+0x4c/0x260 devicerelease+0x44/0x128 kobjectput+0xa0/0x120 putdevice+0x1c/0x40 nvmeuninitctrl+0x48/0x60 applenvmeremove+0x54/0xb0 platformremove+0x28/0x40 deviceremove+0x54/0x98 devicereleasedriverinternal+ devicereleasedriver+0x20/0x38 applenvmeremovedeadctrlwor processonework+0x1f4/0x770 workerthread+0x1b8/0x360 kthread+0x140/0x160 retfromfork+0x10/0x20 irq event stamp: 448 hardirqs last enabled at (447):inunlockirqrestore+0x74/0x80 hardirqs last disabled at (448): [<ffffc000811cf5c0>] el1brk64+0x20/0x60 softirqs last enabled at (0): [ess+0xb28/0x2698 softirqs last disabled at (0): [<0000000000000000>] 0x0 ---[ end trace 0000000000000000 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagA GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [0000000000000000] user address Internal error: Oops: 0000000096000005 [#1] SMP CPU: 7 UID: 0 PID: 54 Comm: kwor 7.2.0-rc1-dirty #248PREEMPT Tainted: [W]=WARN Hardware name: Apple Mac mini (M1, 2020) (DT) Workqueue: kblockd blkmqtimeou pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : percpureftrygetmany.cons lr : percpureftrygetmany.constprop.0+0xc0/0x168 sp : ffffc000829cbce0 x29: ffffc000829cbce0 x28: ffff800020be9f48 x27: ffff800013e503c0 x26: 0000000000000108 x25: 000009c05 x23: 0000000000000000 x22: ffffc000819f5000 x21: ffff800020be9f48 x20: ffff8001deda4808 x19: ffff8000a x17: 00000000580e1fac x16: ffffc00082bbbb7c x15: 0000000000000000 x14: 0000000000000028 x13: 000000001 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc000829cbc20 x8 : ---truncated---

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

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

wifi: mt76: mt7921: Add PCIe AER handler support to prevent system crash

When an AER error occurs and the bus is hung, the register reads return 0xFFFFFFFF, causing the DMA queue state to be corrupted and resulting in an invalid memory access when accessing q->desc[] or q->entry[].

Unable to handle kernel paging request at virtual address ffffffc01099eac0 pc : mt76dmaaddbuf+0x124/0x188 [mt76] lr : mt76dmarxfill+0x11c/0x1d8 [mt76] sp : ffffffc016d9bbf0 x29: ffffffc016d9bc10 x28: 0000000000000000 x27: 0000000000000000 x26: ffffffb7855e50b8 x25: ffffffb80d04f000 x24: 0000000000000000 x23: 0000000000000ec0 x22: ffffffb796803648 x21: ffffffb796801f80 x20: ffffffb7968035f8 x19: 0000000000000ec0 x18: 0000000000000000 x17: 000000004ec00000 x16: 000000000ec00000 x15: ffffffc01099eac0 x14: 000000004ec00000 x13: 00000000ffc5a000 x12: ffffffc016d9bc32 x11: 00000000ffffffff x10: 0000000000000002 x9 : 0000000000000000 x8 : 000000000000b4ac x7 : 0000000000000a20 x6 : ffffffb6c1806400 x5 : 0000000000000000 x4 : ffffffb80d04f000 x3 : 0000000000000000 x2 : 0000000000000001 x1 : 000000000ec04000 x0 : ffffffb7968035f8 Call trace: mt76dmaaddbuf+0x124/0x188 [mt76 (HASH:1029 4)] mt76dmarxreset+0xe8/0xfc [mt76 (HASH:1029 4)] mt7921wpdmareset+0x188/0x1b0 [mt7921e (HASH:ee48 5)] mt7921emacreset+0x128/0x418 [mt7921e (HASH:ee48 5)] mt7921macresetwork+0xac/0x1a8 [mt7921common (HASH:f721 6)] processonework+0x188/0x514 workerthread+0x12c/0x300 kthread+0x140/0x1fc retfromfork+0x10/0x30

Fix the invalid memory access by validating the DMA index read from the hardware before it is used as a queue index. An out-of-range value, such as the 0xFFFFFFFF returned while the bus is hung, is now clamped so it can no longer corrupt q->head or q->tail. In addition, check the bushung flag in mt7921macresetwork() before attempting the reset sequence, reject MCU messages while the bus is hung, and install no-op bus operations when an unrecoverable AER error is detected, preventing further invalid hardware accesses.

Due to hardware limitations - such as the lack of a connected hardware reset pin or the absence of host re-probe functionality - affected Wi-Fi devices may not fully recover to a normal operational state after certain errors, even with AER enabled.

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

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

isertrecvdone() hands each received PDU to the opcode handlers without ever looking at wc->bytelen, the number of bytes the HCA actually placed in the receive descriptor. The handlers then copy that many bytes - the data-segment length the initiator declared in the BHS (ntoh24(hdr->dlength), via the derived unsoldatalen / immdatalen) - out of the fixed-size descriptor:

iserthandleiscsidataout(): sgcopyfrombuffer(sgstart, sgnents, isertgetdata(rxdesc), unsoldatalen); iserthandlescsicmd(): sgcopyfrombuffer(cmd->secmd.tdatasg, sgnents, isertgetdata(rxdesc), immdatalen);

Because the declared length is never checked against wc->bytelen, an initiator can declare a data segment larger than the bytes it actually sent (and larger than the descriptor) and cause an out-of-bounds read of the receive buffer.

Nothing upstream of isert closes this door:

- iscsitcheckdataouthdr() bounds the inbound payload against connops->MaxXmitDataSegmentLength (MXDSL) - a transmit parameter, used here for the inbound check. - iscsisetconnectionparameters() sets ops->MaxXmitDataSegmentLength = ops->TargetRecvDataSegmentLength; and TARGETRECVDATASEGMENTLENGTH is absent from the min()-clamp list in iscsicheckacceptorstate(), so the value the initiator declares is adopted verbatim (type range 512..16777215). The initiator effectively raises its own ceiling. - isert never clamps the negotiated value to its own fixed receive descriptor (ISERRXSIZE, 9216 bytes), so the target core's bound and the descriptor size are unrelated.

The immdatalen == datalen path is more than an over-read: it aliases the receive descriptor via sgsetbuf() and passes it to the backend as the data source for the SCSI WRITE, so an over-declared length causes heap contents past the descriptor to be written through the backend to the backing store. The backend is the victim of the oversized scatterlist isert hands it, not the cause; no read-back of the written bytes was demonstrated.

Trigger: after login completes (full feature phase), an initiator that has declared a large TargetRecvDataSegmentLength and a FirstBurstLength that permits unsolicited/immediate data sends a PDU whose declared data-segment length exceeds what was received. With KASAN:

BUG: KASAN: slab-out-of-bounds in sgcopybuffer+0x150/0x1c0 Read of size 4096 at addr ffff888109720800 by task kworker/1:0H/25 Workqueue: ib-comp-wq ibcqpollwork Call Trace: sgcopybuffer+0x150/0x1c0 isertrecvdone+0xba6/0x2390 ibprocesscq+0xe1/0x390 ibcqpollwork+0x46/0x150

isertrecvdone+0xba6 resolves to iserthandleiscsidataout() (ibisert.c:1160), inlined through isertrxopcode().

Validate wc->bytelen against the framing in isertrecvdone() before the PDU reaches any handler, and reinstate the connection if it is short. Because the test compares without subtracting the header length, it also rejects PDUs shorter than the iSER and iSCSI headers, which would otherwise be parsed out of stale descriptor contents. The login handler rejects PDUs shorter than ISERHEADERSLEN (commit 29e7b925ae6d ("IB/isert: Reject login PDUs shorter than ISERHEADERSLEN")) but does not bound the declared length either; that is fixed in the next patch. The data handlers had no length check at all.

isert reads the data segment from a fixed offset: isertgetdata() returns the iSER header plus ISERHEADERSLEN and makes no adjustment for an AHS. The bytes the handlers touch are therefore exactly [ISERHEADERSLEN, ISERHEADERSLEN + dlength), and comparing that sum against wc->bytelen bounds precisely the region that is read. An AHS term would only make the test stricter without bounding anything furth ---truncated---

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.

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:

smb: smbdirect: free completion queues with ibfreecq()

smbdirectconnectiondestroyqp() creates the send and receive completion queues with iballoccqany(), which for IBPOLLWORKQUEUE arms an internal completion handler that runs ibcqpollwork() on a workqueue. Tearing those CQs down with ibdestroycq() frees them without first cancelling that poll work.

If the provider posts a completion late -- for example Soft-RoCE (rxe) posting an RNR error from rxereceiver() after rdmadestroyqp() -- the handler re-queues ibcqpollwork() on the already-freed CQ, and a follow-on access faults in rxereqnotifycq().

Use ibfreecq(), which cancelworksync()es the poll work before freeing the CQ, so no completion handler can run against a freed queue.

[ 1236.599526] ================================================================== [ 1236.602142] BUG: KASAN: slab-use-after-free in ibcqpollwork+0xd0/0x1a0 [ 1236.605524] Read of size 8 at addr ffff888111865800 by task kworker/4:1H/82 [ 1236.609017] [ 1236.609270] CPU: 4 UID: 0 PID: 82 Comm: kworker/4:1H Not tainted 7.2.0-rc3-next-20260717-virtme #110 PREEMPT(lazy) [ 1236.609287] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 [ 1236.609498] Workqueue: ib-comp-wq ibcqpollwork [ 1236.609525] Call Trace: [ 1236.609536] <TASK> [ 1236.609545] dumpstack+0x21/0x60 [ 1236.609562] dumpstacklvl+0xc2/0x100 [ 1236.609573] printaddressdescription+0x77/0x200 [ 1236.609587] ? ibcqpollwork+0xd0/0x1a0 [ 1236.609597] printreport+0x58/0x70 [ 1236.609607] kasanreport+0x117/0x150 [ 1236.609623] ? ibcqpollwork+0xd0/0x1a0 [ 1236.609636] ? processscheduledworks+0x954/0x1600 [ 1236.609650] ibcqpollwork+0xd0/0x1a0 [ 1236.609662] ? processscheduledworks+0x954/0x1600 [ 1236.609674] processscheduledworks+0xc22/0x1600 [ 1236.609698] ? pfxprocessscheduledworks+0x10/0x10 [ 1236.609713] ? pfxassignwork+0x10/0x10 [ 1236.609726] ? lockisheldtype+0x7b/0x110 [ 1236.609741] workerthread+0x975/0xee0 [ 1236.609757] ? pfxdorawspinlock+0x10/0x10 [ 1236.609775] ? kthreadparkme+0x21e/0x260 [ 1236.609789] kthread+0x3a6/0x490 [ 1236.609800] ? pfxworkerthread+0x10/0x10 [ 1236.609809] ? pfxkthread+0x10/0x10 [ 1236.609820] retfromfork+0x55a/0xa20 [ 1236.609835] ? pfxretfromfork+0x10/0x10 [ 1236.609850] ? pfxkthread+0x10/0x10 [ 1236.609861] retfromforkasm+0x1a/0x30 [ 1236.609880] </TASK> [ 1236.609886] [ 1236.661292] Allocated by task 5076: [ 1236.662640] kasansavetrack+0x3e/0x80 [ 1236.663842] kasankmalloc+0x72/0x90 [ 1236.664763] kmallocnoprof+0x2b0/0x5d0 [ 1236.665356] iballoccq+0x284/0x1000 [ 1236.666573] iballoccqany+0x23e/0x340 [ 1236.668654] smbdirectconnectioncreateqp+0x6f7/0x1070 [ 1236.669757] smbdirectacceptconnectrequest+0x500/0x1ca0 [ 1236.672625] smbdirectlistenrdmaeventhandler+0x1655/0x1c50 [ 1236.673930] cmalistenhandler+0x1bf/0x260 [ 1236.674923] cmacmeventhandler+0x128/0x380 [ 1236.676926] cmaibreqhandler+0x2d3d/0x4de0 [ 1236.678368] cmprocesswork+0xb0/0x530 [ 1236.680454] cmqueueworkunlock+0xb1/0x230 [ 1236.681673] cmworkhandler+0x969f/0xdca0 [ 1236.682704] processscheduledworks+0xc22/0x1600 [ 1236.683447] workerthread+0x975/0xee0 [ 1236.685901] kthread+0x3a6/0x490 [ 1236.688164] retfromfork+0x55a/0xa20 [ 1236.689522] retfromforkasm+0x1a/0x30 [ 1236.690073] [ 1236.690378] Freed by task 5137: [ 1236.692242] kasansavetrack+0x3e/0x80 [ 1236.694272] kasansavefreeinfo+0x40/0x50 [ 1236.695514] kasanslabfree+0x3a/0x60 [ 1236.696773] kfree+0x14e/0x4e0 [ 1236.697216] ibdestroycquser+0x18d/0x250 [ 1236.699817] smbdirectconnectiondestroyqp+0xf2/0x280 [ 1236.702115] smbdirectsocketdestroysync+0x1607/0x2720 [ 1236.704062] smbdirectsocketrelease+0x140/0x280 [ 1236.705286] smbdirectfreetranspor ---truncated---

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

drm/xe: Reject page faults from non-fault-mode scratch VMs

Having scratch enabled does not make a VM capable of handling recoverable page faults. Allowing scratch VMs through the ASID lookup also admits dma-fence mode VMs.

If such a VM faults on an already valid VMA, the handler reports success without fixing the fault, causing the GPU to retry indefinitely.

Only allow fault-mode VMs through the ASID lookup. Fault-mode VMs using scratch remain supported, while faults from 3D VMs are rejected.

(cherry picked from commit bfb24a06405b652d37831f3fb66b71d33a6605de)

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:

power: supply: ab8500fg: fix use-after-free on remove

ab8500fgremove() destroys the driver workqueue while the threaded interrupt handlers are still armed; they are devm-managed and freed only after ->remove() returns, so a handler that fires in that window queues work on the freed workqueue.

Tear the workqueue down through devm instead, registering its cleanup after the power supply and before the interrupt requests. devm then frees the interrupts first, so the handlers can no longer queue work, before disabling the delayed and plain work items and destroying the workqueue. Disabling the items, rather than cancelling them, keeps them disabled so no producer (including the power-supply externalpowerchanged callback) can requeue them.

Found by an in-house static analysis tool.

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.

HID: wacom: validate report length in wacomintuospro2btirq

HID: rmi: fix OOB access with undersized RMI reports

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

KVM: arm64: vgic-its: Drop the translation cache reference only for the erased entry

vgicitsinvalidatecache() walks the per-ITS translation cache with xaforeach() and drops the cache's reference on each entry with vgicputirq(). It puts the iterated pointer, though, rather than the value returned by xaerase().

The function is called from contexts that do not exclude one another: the ITS command handlers hold itslock, the GITSCTLR write path holds cmdlock, and the path that clears EnableLPIs in a redistributor's GICRCTLR holds neither. Two or more of them can drain the same cache concurrently, and if each one observes the same entry, erases it and then puts it, the single reference the cache holds on that entry is dropped more than once. The entry can then be freed while an ITE still maps it.

xaerase() is atomic and returns the previous entry, so put only the entry that this context actually removed. The cache reference is then dropped exactly once per entry even when the invalidations run concurrently, and the behavior is unchanged when only one context runs.

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

HID: mcp2221: stop device IO before hidhwstop

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

net/iucv: filter frames in afiucvhsrcv() by ingress device

afiucvhsrcv() selects a socket from iucvsklist by matching four 8-byte name fields in the transport header alone. No check is made against the netdevice the frame arrived on.

This can cause a frame arriving on any netdev to be delivered to an AFIUCV socket. Three problems follow.

First, a frame arriving over HiperSockets can be delivered to a socket bound to the classic z/VM IUCV transport, which has iucv->hsdev == NULL. iucvsockbind() takes the classic path whenever the requested userid matches iucvuserid, even on a guest that also has a HiperSockets device carrying the same identifier. The child socket created by afiucvhscallbacksyn() for such a match inherits hsdev = NULL and transport = AFIUCVTRANSHIPER, so the first send() on it returns -ENODEV. The socket delivered to accept() is unusable.

Second, a frame arriving on one netdev can be delivered to a socket bound to a different IQD device. Which can lead to - Accept-queue exhaustion (DoS) - Attacker-controlled peer identity in the child socket - Data injection into existing sockets - Fabric noise on the IQD fabric, where bogus replies are sent - killing established connections

Third, all AFIUCV sockets live in initnet, as iucvsockalloc() calls skalloc(&initnet, ...). But even frames arriving on netdev devices in a namespace can be delivered to an IUCV socket. So a process in an unprivileged user and network namespace holding only the CAPNETRAW capability valid within that namespace can send a raw ETHPAFIUCV frame on its own lo device and have it matched against initnet sockets.

Fix all three by skipping any socket whose hsdev does not match the ingress device. A classic z/VM IUCV socket has hsdev == NULL; the ingress dev is never NULL, so classic sockets are skipped automatically. An unbound HIPER socket also has hsdev == NULL and is skipped. A bound HIPER socket is only reachable from the exact IQD device it was bound to. Because hsdev is always a device in initnet (iucvsockbind() scans foreachnetdevrcu(&initnet, ...) exclusively), a frame whose ingress device belongs to another namespace never matches any socket.

Note that AFIUCV over HiperSockets provides no per-connection authentication: no sequence numbers, no TLS, no nonce. The four name fields identifying a connection are exchanged in plaintext on the shared HiperSockets segment (VCHID). Any host on the same HiperSockets segment could spoof any frame type against an existing connection. That is a protocol-level property unchanged by this patch. The fix reduces the attack surface to peers present on the same HiperSockets segment.

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

wifi: rtl8xxxu: fix use-after-free from rxurbwq on stop

rtl8xxxu arms rxurbwq from the RX completion path: rtl8xxxurxcomplete() hands the URB to rtl8xxxuqueuerxurb(), which queues it on rxurbpendinglist and, once the list grows past RTL8XXXURXURBPENDINGWATER, schedules rxurbwq. The worker rtl8xxxurxurbwork() drains rxurbpendinglist, recovers priv through containerof, and resubmits each URB through rtl8xxxusubmitrxurb(), which anchors it on rxanchor and dereferences priv->udev.

rtl8xxxustop() cancels the sibling work items (c2hcmdwork, rawatchdog, updatebeaconwork) but never cancels rxurbwq, so a worker armed during the last burst of RX traffic can run rtl8xxxurxurbwork() after rtl8xxxudisconnect() has called ieee80211freehw(), which frees priv, producing a use-after-free. The window opens under active RX traffic (pending count above the watermark) followed by a disconnect.

There are two teardown races to close:

rtl8xxxuqueuerxurb() decided whether to enqueue under rxurblock but called schedulework() after dropping the lock. A completion that observed shutdown == false and released the lock could then call schedulework() after rtl8xxxustop() had set shutdown and cancelworksync() had already returned, arming the worker to run after the teardown. Move schedulework() under the same !shutdown branch so the arming decision is atomic with the shutdown check.

rtl8xxxurxurbwork() anchors every URB it drained back onto rxanchor through rtl8xxxusubmitrxurb(). A worker still running when usbkillanchoredurbs(&priv->rxanchor) returned would submit a URB that escaped the kill. In rtl8xxxustop(), call cancelworksync(&priv->rxurbwq) before the kill so the worker is drained first.

After priv->shutdown is set under rxurblock, completions can no longer queue rxurbwq. cancelworksync() then drains the last queued or running worker, and the following usbkillanchoredurbs() kills the URBs it may have submitted.

rtl8xxxudisconnect() is covered because ieee80211unregisterhw() guarantees .stop() runs for a live interface before ieee80211freehw() frees priv. The probe error path needs no cancel: rxurbwq is INITWORK()'d there but cannot have been scheduled, since no URB is submitted before ieee80211registerhw() succeeds.

This bug was found by static analysis.

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]

HID: sony: fix UAF of ghlpoketimer / ghlurb at driver unbind

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:

HID: mcp2221: validate report size in mcp2221rawevent()

mcp2221rawevent() never validates the size of incoming HID reports. In the MCP2221I2CGETDATA path it trusts the device-supplied data[3] as the copy length without checking that 4 + data[3] bytes actually exist in the received report. A malicious or misbehaving USB device can send a short report with a large data[3], causing the memcpy to read past the valid report data in the HID transfer buffer and leak uninitialized kernel memory back to userspace through the I2C/SMBus read path.

Add a minimum size check at entry and validate that the source range fits within the received report before the copy.

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:

seg6: reset IP6CB after IPv6 decapsulation

decapandvalidate() pulls the outer SRv6 headers and makes the inner packet the skb network header. The IPv6 control block still contains values collected while parsing the outer packet, including nhoff and extension-header flags.

End.DX6 and End.DT6 route the inner IPv6 packet directly to the IPv6 input path. An unprivileged user can reach End.DT6 from a user and net namespace by installing a local SID and injecting an outer packet with Hop-by-Hop and Destination Options headers followed by an SRH and a minimal inner IPv6 packet.

The outer extension headers leave a large nhoff in IP6CB. After decapsulation, ip6protocoldeliverrcu() uses that stale offset on the inner packet and reads beyond the skb head. KASAN reports:

BUG: KASAN: slab-out-of-bounds in ip6protocoldeliverrcu ip6protocoldeliverrcu+0x1118/0x1450 ip6inputfinish+0x11b/0x240 seg6localinputcore+0xed/0x2e0 lwtunnelinput+0x1e9/0x4e0 ipv6rthdrrcv+0x525f/0x6c50 ip6protocoldeliverrcu+0xcb7/0x1450

Before clearing IP6CB for an inner IPv6 packet, save its incoming interface index and L3 slave state. Restore both after the clear and set nhoff to the inner IPv6 base-header nexthdr field.

Use IP6CB(skb)->iif rather than skb->skbiif because VRF processing can replace skbiif with the L3 master while IP6CB keeps the receiving interface. Preserve IP6SKBL3SLAVE for the same reason.

ALSA: virmidi: Check card index validity at probe

ALSA: bcd2000: clear the URB pointers on disconnect

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

ALSA: FCP: do not copy out an uninitialised init response

fcpioctlinit() allocates its response buffer with kmalloc() and copies the whole buffer back to userspace:

bufsize = init.step0respsize + init.step2respsize;

void resp free(kfree) = kmalloc(bufsize, GFPKERNEL); ... if (copytouser(arg->resp, resp, bufsize)) return -EFAULT;

Nothing clears the buffer, and the only writer of its leading step0respsize bytes is the step-0 control transfer:

err = sndusbctlmsg(dev, usbrcvctrlpipe(dev, 0), FCPUSBREQSTEP0, USBRECIPINTERFACE | USBTYPECLASS | USBDIRIN, 0, private->bInterfaceNumber, step0resp, private->step0respsize); if (err < 0) return err;

usbfillcontrolurb() does not set URBSHORTNOTOK, so a short or zero-length data stage completes with status 0 and sndusbctlmsg() returns a small actuallength. The only check is err < 0, so a short transfer is accepted as success.

sndusbctlmsg() copies the full size back unconditionally:

buf = kmemdup(data, size, GFPKERNEL); ... memcpy(data, buf, size);

Bytes the device never wrote are therefore restored into resp unchanged and copied to userspace. step0respsize and step2respsize are each validated only to 1..255, so the caller also picks the slab cache, from kmalloc-8 up to kmalloc-512.

On 7.2.0-rc5 (arm64), device answering step 0 with a zero-length data stage, s0 = s2 = 255:

# initonalloc off, no spray step0 window [0,255): nonzero=94/255 000: 00 80 60 06 00 00 ff ff 18 00 00 00 57 01 ea 01 010: 08 78 22 13 00 00 ff ff a8 c4 5f 80 00 80 ff ff

# same kernel, kmalloc-512 pre-seeded with an 8-byte tag step0 window [0,255): nonzero=219/255 tagbytes=232

# identical run, initonalloc=1 step0 window [0,255): nonzero=0/255 tagbytes=0

# all three runs step2 window [255,510): device words matched=62/62

a8 c4 5f 80 00 80 ff ff is the little-endian kernel text address ffff8000805fc4a8. The step-2 window is unaffected, so the disclosure is exactly the step-0 region.

Zero the buffer, and require the step-0 transfer to deliver the full step0respsize bytes so a short data stage is reported as an error.

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

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

HID: universal-pidff: stop the device when force-feedback init fails

universalpidffprobe() starts the device with hidhwstart() and then, if force-feedback initialisation fails, returns the error through a label that only does "return error". The device is left started.

The HID core does not unwind on the driver's behalf. hiddeviceprobe() releases the devres group, closes the report and clears hdev->driver:

if (ret) { devresreleasegroup(&hdev->dev, hdev->devresgroupid); hidclosereport(hdev); hdev->driver = NULL; }

The hidraw character device that hidhwstart() registered through hidconnect() is allocated with kzalloc() and added with cdevdeviceadd(), so it is not devres-managed and survives that. With hdev->driver NULL, hiddeviceremove() skips hidhwstop() as well, because it only unwinds while a driver is still attached. The registration therefore outlives the device on both paths.

Opening the surviving /dev/hidrawX writes into freed memory. KASAN reports a use-after-free write from hidrawopen() -> hidhwopen() -> the transport's open callback, which takes a spinlock inside the freed object. A descriptor that carries a PID usage page and no input reports is enough: hidraw claims the device so hidhwstart() succeeds, while hid->inputs stays empty so force-feedback init fails. The other failure returns in hidpidffinitwithquirks() - no output reports, an allocation failure, pidffinitfields(), pidffcheckautocenter(), an unusable effect count, inputffcreate() - all reach the same label.

Stop the device on that path. hid-dr.c and hid-emsff.c, which start the device with the same HIDCONNECTDEFAULT & ~HIDCONNECTFF mask, already do this. The two earlier gotos must keep returning without hidhwstop(), since neither has a started device, so give the path that fails after the start its own label.

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

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

i3c: renesas: Fix out-of-bounds access for newdevs mask

When software initiates DAA (Dynamic Address Assignment), the controller reports the result via the NRSPQP (Normal Response Queue Port Register). The data length field of the response descriptor, which is accessible through the NRSPQP register, indicates the number of devices remaining after DAA. Consequently, when the bus is empty, this field contains the maximum number of devices supported by the controller (8 for the Renesas I3C controller).

Adjust the condition that computes the newly discovered devices bitmask to prevent an out-of-bounds when the I3C bus is empty.

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

zram: fix out-of-bounds access in readblockstate()

readblockstate() calculates nrpages before taking devlock. If the device is reset and reinitialized with a smaller disksize before lock acquisition, nrpages still describes the old table. The subsequent loop can then call slotlock() past the end of the newly allocated table.

Read disksize after acquiring devlock and checking that the device is initialized. The read lock then keeps the table and its bound stable for the duration of the scan.