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:

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).

apparmor: fix use-after-free in rawdata dedup loop

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

block: recompute nrintegritysegments in blkinsertclonedrequest

blkinsertclonedrequest() already recomputes nrphyssegments against the bottom queue, because "the queue settings related to segment counting may differ from the original queue." The exact same reasoning applies to integrity segments: a stacked driver's underlying queue can have tighter virtboundarymask, segboundarymask, or maxsegmentsize than the top queue, in which case blkrqcountintegritysg() against the bottom queue produces a different count than the cached rq->nrintegritysegments inherited from the source request by blkrqprepclone().

When the cached count is lower than the bottom queue's actual count, blkrqmapintegritysg() trips

BUGON(segments > rq->nrintegritysegments);

on dispatch. The same families of stacked setups that motivated the existing nrphyssegments recompute -- dm-multipath fanning out to nvme-rdma in particular -- can produce this.

Mirror the nrphyssegments handling: when the request carries integrity, recompute nrintegritysegments against the bottom queue and reject the request if it exceeds the bottom queue's maxintegritysegments. blkrqcountintegritysg() and queuemaxintegritysegments() are both already available via <linux/blk-integrity.h>, which blk-mq.c includes.

This closes a latent gap in the stacking contract and brings the integrity-segment accounting in line with the existing phys-segment accounting.

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

net: gro: properly validate BIG TCP aggregation criteria

When GRO attempts to aggregate packets beyond GROLEGACYMAXSIZE (64KB), BIG TCP should only be permitted for plain IPv4 TCP and plain IPv6 TCP (with sufficient MAC header room to insert the temporary HBH jumbo header).

However, commit b1a78b9b9886 ("net: add support for ipv4 big tcp") loosened the check in skbgroreceive(), leading to several issues:

1. skbgroreceive() checked skbheadroom(p) instead of the actual space before the MAC header (p->macheader). Because skbheadroom(p) includes maclen, crafted frames (e.g. injected via AFPACKET) can pass the check with p->macheader < 8 bytes. When ipv6grocomplete() inserts the temporary HBH jumbo header, the memmove() starts before skb->head, causing an out-of-bounds write and wrapping skb->macheader. 2. It allowed non-IP protocols such as software VLAN (ETHP8021Q / ETHP8021AD) to aggregate beyond 64KB because p->protocol != ETHPIPV6 was true. 3. It checked p->encapsulation instead of NAPIGROCB(skb)->encapmark, allowing encapsulated flows (e.g. SIT / IPv6-in-IPv4) to aggregate beyond 64KB.

Fix skbgroreceive() to strictly enforce: - NAPIGROCB(skb)->proto == IPPROTOTCP - Not encapsulated (!NAPIGROCB(skb)->encapmark && !p->encapsulation) - Protocol must be either ETHPIP or ETHPIPV6 - If ETHPIPV6, p->macheader must be at least sizeof(struct hopjumbohdr)

Returning -E2BIG from skbgroreceive() ensures that packets which cannot become BIG TCP are cleanly flushed at <= 64KB and delivered intact without dropping.

This issue does not exist in mainline (7.0+) because the subsystem was rewritten in commit 81be30c1f5f2 ("net/ipv6: Drop HBH for BIG TCP on RX side"), making this fix relevant only for older stable branches like 6.18.y.

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.

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:

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.

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

powerpc/pseries/iommu: IOMMU incorrectly marks MMIO range in DDW

Power Hypervisor can possibily allocate MMIO window intersecting with Dynamic DMA Window (DDW) range, which is over 32-bit addressing.

These MMIO pages needs to be marked as reserved so that IOMMU doesn't map DMA buffers in this range.

The current code is not marking these pages correctly which is resulting in LPAR to OOPS while booting. The stack is at below

BUG: Unable to handle kernel data access on read at 0xc00800005cd40000 Faulting instruction address: 0xc00000000005cdac Oops: Kernel access of bad area, sig: 11 [#1] LE PAGESIZE=64K MMU=Hash SMP NRCPUS=2048 NUMA pSeries Modules linked in: afpacket rfkill ibmveth(X) lpfc(+) nvmetfc nvmet nvmekeyring crct10difvpmsum nvmefc nvmefabrics nvmecore be2net(+) nvmeauth rtcgeneric nfsd authrpcgss nfsacl lockd grace sunrpc fuse configfs iptables xtables xfs libcrc32c dmservicetime ibmvfc(X) scsitransportfc vmxcrypto gf128mul crc32cvpmsum dmmirror dmregionhash dmlog dmmultipath dmmod sdmod scsidhemc scsidhrdac scsidhalua t10pi crc64rocksoftgeneric crc64rocksoft sg crc64 scsimod Supported: Yes, External CPU: 8 PID: 241 Comm: kworker/8:1 Kdump: loaded Not tainted 6.4.0-150600.23.14-default #1 SLE15-SP6 b44ee71c81261b9e4bab5e0cde1f2ed891d5359b Hardware name: IBM,9080-M9S POWER9 (raw) 0x4e2103 0xf000005 of:IBM,FW950.B0 (VH950149) hv:phyp pSeries Workqueue: events workforcpufn NIP: c00000000005cdac LR: c00000000005e830 CTR: 0000000000000000 REGS: c00001400c9ff770 TRAP: 0300 Not tainted (6.4.0-150600.23.14-default) MSR: 800000000280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 24228448 XER: 00000001 CFAR: c00000000005cdd4 DAR: c00800005cd40000 DSISR: 40000000 IRQMASK: 0 GPR00: c00000000005e830 c00001400c9ffa10 c000000001987d00 c00001400c4fe800 GPR04: 0000080000000000 0000000000000001 0000000004000000 0000000000800000 GPR08: 0000000004000000 0000000000000001 c00800005cd40000 ffffffffffffffff GPR12: 0000000084228882 c00000000a4c4f00 0000000000000010 0000080000000000 GPR16: c00001400c4fe800 0000000004000000 0800000000000000 c00000006088b800 GPR20: c00001401a7be980 c00001400eff3800 c000000002a2da68 000000000000002b GPR24: c0000000026793a8 c000000002679368 000000000000002a c0000000026793c8 GPR28: 000008007effffff 0000080000000000 0000000000800000 c00001400c4fe800 NIP [c00000000005cdac] iommutablereservepages+0xac/0x100 LR [c00000000005e830] iommuinittable+0x80/0x1e0 Call Trace: [c00001400c9ffa10] [c00000000005e810] iommuinittable+0x60/0x1e0 (unreliable) [c00001400c9ffa90] [c00000000010356c] iommubypasssupportedpSeriesLP+0x9cc/0xe40 [c00001400c9ffc30] [c00000000005c300] dmaiommudmasupported+0xf0/0x230 [c00001400c9ffcb0] [c00000000024b0c4] dmasupported+0x44/0x90 [c00001400c9ffcd0] [c00000000024b14c] dmasetmask+0x3c/0x80 [c00001400c9ffd00] [c0080000555b715c] beprobe+0xc4/0xb90 [be2net] [c00001400c9ffdc0] [c000000000986f3c] localpciprobe+0x6c/0x110 [c00001400c9ffe40] [c000000000188f28] workforcpufn+0x38/0x60 [c00001400c9ffe70] [c00000000018e454] processonework+0x314/0x620 [c00001400c9fff10] [c00000000018f280] workerthread+0x2b0/0x620 [c00001400c9fff90] [c00000000019bb18] kthread+0x148/0x150 [c00001400c9fffe0] [c00000000000ded8] startkernelthread+0x14/0x18

There are 2 issues in the code

1. The index is "int" while the address is "unsigned long". This results in negative value when setting the bitmap.

2. The DMA offset is page shifted but the MMIO range is used as-is (64-bit address). MMIO address needs to be page shifted as well.

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

tipc: fix slab-use-after-free Read in tipcaeaddecryptdone

tipcaeaddecrypt() goes straight from tipcbearerhold(b) to cryptoaeaddecrypt(req) without taking a reference on the netns, unlike the encrypt path. When cryptoaeaddecrypt() is offloaded asynchronously (e.g. the SIMD aead wrapper queuing to cryptd), the cryptd worker runs tipcaeaddecryptdone() later. If the bearer's netns is torn down in the meantime, cleanupnet() -> tipcexitnet() -> tipccryptostop() frees the per-netns tipccrypto, and the completion then reads it: tipcaeaddecryptdone() dereferences aead->crypto->stats and aead->crypto->net, and tipccryptorcvcomplete() dereferences aead->crypto->aead[] and the node table -- reading freed memory.

Decoded KASAN splat (v7.1-rc7, CONFIGKASANINLINE + TIPC + TIPCCRYPTO):

BUG: KASAN: slab-use-after-free in tipcaeaddecryptdone (net/tipc/crypto.c:999) Read of size 8 at addr ffff8881056258a8 by task kworker/u16:2/51 Workqueue: eventsunbound Call Trace: tipcaeaddecryptdone (net/tipc/crypto.c:999) processonework (kernel/workqueue.c:3314) workerthread (kernel/workqueue.c:3397 kernel/workqueue.c:3478) kthread (kernel/kthread.c:436) retfromfork (arch/x86/kernel/process.c:158) retfromforkasm (arch/x86/entry/entry64.S:245)

Allocated by task 169: kasankmalloc (mm/kasan/common.c:398 mm/kasan/common.c:415) tipccryptostart (net/tipc/crypto.c:1502) tipcinitnet (net/tipc/core.c:72) opsinit (net/core/netnamespace.c:137) setupnet (net/core/netnamespace.c:446) copynetns (net/core/netnamespace.c:579) createnewnamespaces (kernel/nsproxy.c:132) x64sysunshare (kernel/fork.c:3316) dosyscall64 (arch/x86/entry/syscall64.c:63) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:121)

Freed by task 8: kfree (mm/slub.c:6566) tipcexitnet (net/tipc/core.c:119) cleanupnet (net/core/netnamespace.c:704) processonework (kernel/workqueue.c:3314) kthread (kernel/kthread.c:436)

This is the same class of bug that commit e279024617134 ("net/tipc: fix slab-use-after-free Read in tipcaeadencryptdone") fixed for the encrypt side. The encrypt path takes maybegetnet(aead->crypto->net) before cryptoaeadencrypt() and drops it with putnet() on the synchronous return paths and in tipcaeadencryptdone(); the -EINPROGRESS/-EBUSY return keeps the reference for the async callback to release. The decrypt path was left without the equivalent guard.

Mirror the encrypt-side fix on the decrypt path: take a net reference before cryptoaeaddecrypt() (failing with -ENODEV and the matching bearer put if it cannot be acquired), keep it across the -EINPROGRESS/-EBUSY async return, and drop it with putnet() on the synchronous success/error return and at the end of tipcaeaddecryptdone().

Reproduced under KASAN on v7.1-rc7: a UDP bearer with a cluster key is flooded with crafted encrypted frames from an unknown peer (driving the cluster-key decrypt path) while the bearer's netns is repeatedly torn down. The completion must run asynchronously to outlive tipccryptostop(); on x86 the stock aesni gcm(aes) now decrypts synchronously, so the async path was exercised via cryptd offload. The unguarded aead->crypto dereference in tipcaeaddecryptdone() is the unpatched upstream path; tipcaeaddecrypt() still lacks maybegetnet(aead->crypto->net), so the completion can outlive the free on any config where cryptoaeaddecrypt() goes async.

Found by 0sec automated security-research tooling (https://0sec.ai).

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.

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:

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:

iouring/zcrx: fix overshooting recv limit

It's reported that sometimes a zcrx request can receive more than was requested. It's caused by iozcrxrecvskb() adjusting desc->count for all received buffers including frag lists, but then doing recursive calls to process frag list skbs, which leads to desc->count double accounting and underflow.

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

nvme-pci: fix out-of-bounds access in nvmesetupdescriptorpools

nvmesetupdescriptorpools() indexes dev->descriptorpools[] using the numanode forwarded from hctx->numanode by its single caller, nvmeinithctxcommon(). On a non-NUMA kernel hctx->numanode is NUMANONODE (-1). Because the parameter was declared 'unsigned', the value becomes UINTMAX and the index walks off the array (sized to nrnodeids), faulting during nvmeallocns() and leaving the namespace without a /dev node.

Reproduces on any NVMe controller probed by a CONFIGNUMA=n kernel:

BUG: unable to handle page fault for address: ffff889101603d38 RIP: 0010:nvmeinithctxcommon+0x5a/0x190 [nvme] Call Trace: nvmeinithctx+0x10/0x20 [nvme] nvmeallocns+0x9e/0xa10 [nvmecore] nvmescanns+0x301/0x3b0 [nvmecore] nvmescannsasync+0x23/0x30 [nvmecore]

Switch the parameter to int and fall back to node 0 when it is NUMANONODE; node 0 is always present.

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

ipv4: icmp: validate reply type before using icmppointers

Extended echo replies use ICMPEXTECHOREPLY as the outbound reply type. That value is outside the range covered by icmppointers[], which only describes the traditional ICMP types up to NRICMPTYPES.

Avoid consulting icmppointers[] for reply types outside that range, and use arrayindexnospec() for the remaining in-range lookup. Normal ICMP replies keep their existing behavior unchanged.

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:

reftracker: implement use-after-free detection

Whenever reftrackerdirinit() is called, mark the struct reftrackerdir as dead.

Test the dead status from reftrackeralloc() and reftrackerfree()

This should detect buggy devput()/devhold() happening too late in netdevice dismantle process.

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

net: stmmac: fix dma queue left shift overflow issue

When queue number is > 4, left shift overflows due to 32 bits integer variable. Mask calculation is wrong for MTLRXQDMAMAP1.

If CONFIGUBSAN is enabled, kernel dumps below warning: [ 10.363842] ================================================================== [ 10.363882] UBSAN: shift-out-of-bounds in /build/linux-intel-iotg-5.15-8e6Tf4/ linux-intel-iotg-5.15-5.15.0/drivers/net/ethernet/stmicro/stmmac/dwmac4core.c:224:12 [ 10.363929] shift exponent 40 is too large for 32-bit type 'unsigned int' [ 10.363953] CPU: 1 PID: 599 Comm: NetworkManager Not tainted 5.15.0-1003-intel-iotg [ 10.363956] Hardware name: ADLINK Technology Inc. LEC-EL/LEC-EL, BIOS 0.15.11 12/22/2021 [ 10.363958] Call Trace: [ 10.363960] <TASK> [ 10.363963] dumpstacklvl+0x4a/0x5f [ 10.363971] dumpstack+0x10/0x12 [ 10.363974] ubsanepilogue+0x9/0x45 [ 10.363976] ubsanhandleshiftoutofbounds.cold+0x61/0x10e [ 10.363979] ? wakeupklogd+0x4a/0x50 [ 10.363983] ? vprintkemit+0x8f/0x240 [ 10.363986] dwmac4mapmtldma.cold+0x42/0x91 [stmmac] [ 10.364001] stmmacmtlconfiguration+0x1ce/0x7a0 [stmmac] [ 10.364009] ? dwmac410dmainitchannel+0x70/0x70 [stmmac] [ 10.364020] stmmachwsetup.cold+0xf/0xb14 [stmmac] [ 10.364030] ? pagepoolallocpages+0x4d/0x70 [ 10.364034] ? stmmaccleartxdescriptors+0x6e/0xe0 [stmmac] [ 10.364042] stmmacopen+0x39e/0x920 [stmmac] [ 10.364050] devopen+0xf0/0x1a0 [ 10.364054] devchangeflags+0x188/0x1f0 [ 10.364057] devchangeflags+0x26/0x60 [ 10.364059] dosetlink+0x908/0xc40 [ 10.364062] ? dosetlink+0xb10/0xc40 [ 10.364064] ? nlavalidateparse+0x4c/0x1a0 [ 10.364068] rtnlnewlink+0x597/0xa10 [ 10.364072] ? nlareserve+0x41/0x50 [ 10.364074] ? kmallocnodetrackcaller+0x1d0/0x4d0 [ 10.364079] ? pskbexpandhead+0x75/0x310 [ 10.364082] ? nlareserve64bit+0x21/0x40 [ 10.364086] ? skbfreehead+0x65/0x80 [ 10.364089] ? securitysockrcvskb+0x2c/0x50 [ 10.364094] ? condresched+0x19/0x30 [ 10.364097] ? kmemcachealloctrace+0x15a/0x420 [ 10.364100] rtnlnewlink+0x49/0x70

This change fixes MTLRXQDMAMAP1 mask issue and channel/queue mapping warning.

BugLink: https://bugzilla.kernel.org/showbug.cgi?id=216195

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

net: davicom: fix UAF in dm9000drvremove

dm is netdev private data and it cannot be used after freenetdev() call. Using dm after freenetdev() can cause UAF bug. Fix it by moving freenetdev() at the end of the function.

This is similar to the issue fixed in commit ad297cd2db89 ("net: qcom/emac: fix UAF in emacremove").

This bug is detected by our static analysis tool.

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

scsi: smartpqi: Fix smpprocessorid() call trace for preemptible kernels

Correct kernel call trace when calling smpprocessorid() when called in preemptible kernels by using rawsmpprocessorid().

smpprocessorid() checks to see if preemption is disabled and if not, issue an error message followed by a call to dumpstack().

Brief example of call trace: kernel: checkpreemptiondisabled: 436 callbacks suppressed kernel: BUG: using smpprocessorid() in preemptible [00000000] code: kworker/u1025:0/2354 kernel: caller is pqiscsiqueuecommand+0x183/0x310 [smartpqi] kernel: CPU: 129 PID: 2354 Comm: kworker/u1025:0 kernel: ... kernel: Workqueue: writeback wbworkfn (flush-253:0) kernel: Call Trace: kernel: <TASK> kernel: dumpstacklvl+0x34/0x48 kernel: checkpreemptiondisabled+0xdd/0xe0 kernel: pqiscsiqueuecommand+0x183/0x310 [smartpqi] kernel: ...

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

drm/imagination: Fix double call to drmschedentityfini()

Call sequence of double call: pvrcontextdestroy   pvrcontextkillqueues     pvrqueuekill       drmschedentitydestroy         drmschedentityfini // here   pvrcontextput     krefput(..., pvrcontextrelease)       pvrcontextdestroyqueues         pvrqueuedestroy           drmschedentityfini // here

Call to drmschedentitydestroy() from pvrcontextkillqueues() calls drmschedentityflush() + drmschedentityfini(). drmschedentityflush() ensures all pending jobs are completed and drmschedentityfini() ensures no further submission is allowed as per expectation from pvrcontextkillqueues(). Double call to drmschedentityfini() is misuse of the API so keep call only in pvrcontextcreate() failure path.

Stack trace for issue with addition of refcounting for DRM entity stats in commit fd177135f0e6 ("drm/sched: Account entity GPU time"):

[ 789.490527] ------------[ cut here ]------------ [ 789.490559] refcountt: underflow; use-after-free. [ 789.490657] WARNING: lib/refcount.c:28 at refcountwarnsaturate+0xf4/0x144, CPU#0: kworker/u16:1/440 [ 789.490695] Modules linked in: powervr drmgpuvm drmexec gpusched drmshmemhelper xhciplathcd xhcihcd dwc3 usbcore usbcommon sndsocsimplecard sndsocsimplecardutils sa2ul sha512 sha256 dwc3am62 sha1 authenc rtiwdt libsha512 at24 schfqcodel fuse dmmod ipv6 [ 789.490798] CPU: 0 UID: 0 PID: 440 Comm: kworker/u16:1 Not tainted 7.0.0-rc7-02049-g5e2c0700091b #22 PREEMPT [ 789.490809] Hardware name: Texas Instruments AM625 SK (DT) [ 789.490815] Workqueue: powervr-sched pvrqueuefencereleasework [powervr] [ 789.490868] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 789.490876] pc : refcountwarnsaturate+0xf4/0x144 [ 789.490884] lr : refcountwarnsaturate+0xf4/0x144 [ 789.490892] sp : ffff8000822cbcc0 [ 789.490895] x29: ffff8000822cbcc0 x28: 0000000000000000 x27: 0000000000000000 [ 789.490909] x26: 0000000000000000 x25: ffff800081b1e338 x24: ffff000004541405 [ 789.490922] x23: ffff000004bea950 x22: ffff00000042e400 x21: ffff000007123e30 [ 789.490935] x20: ffff000007123000 x19: ffff000007a80d50 x18: fffffffffffe7768 [ 789.490948] x17: 74736574202c6e6f x16: 697461746e656d65 x15: ffff800081b269f0 [ 789.490962] x14: 0000000000000030 x13: ffff800081b26a70 x12: 0000000000000211 [ 789.490975] x11: 00000000000000c0 x10: 0000000000000b50 x9 : ffff8000822cbb30 [ 789.490988] x8 : ffff0000014e7bb0 x7 : ffff00007725e780 x6 : 0000000372a05f49 [ 789.491001] x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000010 [ 789.491013] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000014e7000 [ 789.491027] Call trace: [ 789.491032] refcountwarnsaturate+0xf4/0x144 (P) [ 789.491043] drmschedentityfini+0x164/0x18c [gpusched] [ 789.491081] pvrqueuedestroy+0x64/0x134 [powervr] [ 789.491110] pvrcontextdestroyqueues+0x34/0x64 [powervr] [ 789.491138] pvrcontextrelease+0x70/0xac [powervr] [ 789.491166] pvrcontextput.part.0+0x5c/0x7c [powervr] [ 789.491193] pvrcontextput+0x14/0x24 [powervr] [ 789.491221] pvrqueuefencereleasework+0x20/0x38 [powervr] [ 789.491249] processonework+0x160/0x4c4 [ 789.491264] workerthread+0x188/0x310 [ 789.491276] kthread+0x130/0x13c [ 789.491287] retfromfork+0x10/0x20 [ 789.491300] ---[ end trace 0000000000000000 ]---

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

xfrm: clear mode callbacks after failed mode setup

xfrmstategctask can run long after a failed IPTFS state setup. In the reproduced case, xfrminitstate() cached x->modecbs, IPTFS setup returned -ENOMEM before publishing modedata, and the temporary module reference from xfrmgetmodecbs() was dropped immediately. The dead state then kept x->modecbs until deferred GC ran after xfrmiptfs had been unloaded.

Clear x->modecbs when mode init or clone fails before publishing modedata. Those states never installed mode-specific state or the long-term IPTFS module pin, so deferred GC has nothing mode-specific to destroy and must not retain a callback table pointer past the temporary lookup reference.

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

failed setup path: 1. cache x->modecbs 2. mode setup fails before modedata 3. drop the temporary module ref 4. dead state keeps x->modecbs cached

GC/unload path: 1. xfrmstateput() queues GC work 2. xfrmiptfs unloads later 3. xfrmstategctask runs 4. GC dereferences stale x->modecbs

This also covers the failed clone path where clonestate() returns before publishing modedata.

Validation reproduced this kernel report: Kernel panic - not syncing: Fatal exception CONFIGFAULTINJECTIONSTACKTRACEFILTER=y failslabstacktracefilter matched xfrmiptfs frames ackerror=-12 FAULTINJECTION: forcing a failure BUG: unable to handle page fault Workqueue: events xfrmstategctask RIP: xfrmstategctask+0x142/0x650 Modules linked in: esp4offload xfrmuser [last unloaded: xfrmiptfs] Kernel panic - not syncing: Fatal exception

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

handshake: Require admin permission for DONE command

ACCEPT and DONE are the two downcalls of the handshake genl family, both intended for use by the trusted handshake agent (tlshd). ACCEPT already requires GENLADMINPERM; DONE has no privilege check at all.

The fd-lookup in handshakenldonedoit() only confirms that some pending handshake request exists for the supplied sockfd; it does not authenticate the sender. An unprivileged process that guesses or observes a valid sockfd can therefore submit a DONE with HANDSHAKEADONESTATUS == 0, leaving the kernel consumer to proceed as if the handshake succeeded. A non-zero status on a forged DONE tears down a legitimate in-flight handshake before tlshd can report its real result.

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:

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.

batman-adv: tpmeter: avoid divide-by-zero for deccwnd

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

wifi: iwlwifi: mld: stop TX during firmware restart

When iwlwifi firmware crashes (e.g., NMIINTERRUPTUNKNOWN on Intel BE201/Wi-Fi 7), iwlmldnicerror() sets mld->fwstatus.inhwrestart to true. However, iwlmldtxfromtxq() does not check this flag before dequeuing frames from mac80211 and pushing them to the transport layer.

Since the firmware is dead, iwltranstx() returns -EIO for each frame, which then gets freed immediately. Under high-throughput conditions (e.g., Tailscale UDP traffic or active SSH sessions), this creates a tight dequeue-send-fail-free loop that wastes CPU cycles and generates rapid skb allocation churn, leading to memory pressure from slab fragmentation.

The RX path already has this guard (iwlmldrxmpdu checks inhwrestart at rx.c:1906), and so does the TXQ allocation worker (iwlmldaddtxqswk at tx.c:156). Add the same guard to iwlmldtxfromtxq() to stop all TX during firmware restart.

Frames left in mac80211's TXQs are naturally drained after restart completes, when queue reallocation triggers iwlmldtxfromtxq() via iwlmldaddtxqlist(), or when new upper-layer traffic invokes waketxqueue.

Tested on ASUS Zenbook 14 UX3405CA with Intel BE201 (Wi-Fi 7) on kernel 6.19.5 where the firmware crashes approximately every 10-15 minutes under Tailscale traffic.

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

ksmbd: fix null pointer dereference in compareguidkey()

sessionfdcheck() walks the per-inode moplist during durable-handle session teardown and sets op->conn = NULL for every opinfo whose conn matched the closing session's connection. The matching opinfo, however, stays linked in its per-ClientGuid leasetablelist entry's lb->leaselist because destroyleasetable() only runs on full TCP-connection teardown, not on SESSIONLOGOFF.

If the same TCP connection then negotiates a fresh session with the same ClientGuid (ClientGuid is bound to NEGOTIATE, not the session, and is unchanged across LOGOFF + SETUP) and issues a SMB2 CREATE with a lease context on a different inode, findsameleasekey() walks lb->leaselist, reaches the stale opinfo, and calls compareguidkey(), which unconditionally dereferences opinfo->conn->ClientGUID. The conn pointer is NULL and the kernel panics.

Reproducer requires only a successful SMB2 SESSIONSETUP and a share configured with 'durable handles = yes'. KASAN report on mainline 70390501d194:

general protection fault, probably for non-canonical address 0xdffffc0000000069: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000348-0x000000000000034f] Workqueue: ksmbd-io handleksmbdwork RIP: 0010:bcmp+0x5b/0x230 Call Trace: compareguidkey+0x4b/0xd0 findsameleasekey+0x324/0x690 smb2open+0x6aea/0x8e60 handleksmbdwork+0x796/0xee0 ...

Faulting address 0x348 is the offset of ClientGUID within struct ksmbdconn, confirming opinfo->conn was NULL.

Read opinfo->conn once and bail out if it has been cleared by a concurrent sessionfdcheck(). A half-detached opinfo cannot be the owner of an active lease, so returning 0 is the correct match result.

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