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

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

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

igc: set tx buffer type for SMD frames

Sashiko pointed out that igcfpeinitsmdframe() initializes igctxbuffer fields for an SMD skb, but does not set the buffer type: https://sashiko.dev/#/patchset/20260415025226.114115-1-kohei%40enjuk.jp

Since igctxbuffer entries are reused, a stale XDP or XSK type can remain and make TX completion use the wrong cleanup path.

Set the buffer type to IGCTXBUFFERTYPESKB.

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

net: tls: prevent chain-after-chain in plain text SG

Sashiko points out that if end = 0 (start != 0) the current code will create a chain link to content type right after the wrap link:

This would create a chain where the wrap link points directly to another chain link. The scatterlist API sgnext iterator does not recursively resolve consecutive chain links.

meaning this is illegal input to crypto.

The wrapping link is unnecessary if end = 0. end is the entry after the last one used so end = 0 means there's nothing pushed after the wrap:

end start i v v v [ ]...[ ][ d ][ d ][ d ][ d ][rsv for wrap]

Skip the wrapping in this case.

TLS 1.3 can use the "wrapping slot" for it's chaining if end = 0. This avoids the chain-after-chain.

Move the wrap chaining before marking END and chaining off content type, that feels like more logical ordering to me, but should not matter from functional perspective.

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

netfs: Fix netfsreadtopagecache() to pause on subreq failure

Fix netfsreadtopagecache() so that it pauses the generation of new subrequests if an already-issued subrequest fails.

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

ipv6: ioam: refresh hdr pointer before ioam6event()

Reported by Sashiko:

In ipv6hopioam(), the hdr pointer is initialized to point into the skb's linear data buffer. Later, the code calls skbensurewritable(), which might reallocate the buffer:

if (skbensurewritable(skb, optoff + 2 + hdr->optlen)) goto drop;

/ Trace pointer may have changed / trace = (struct ioam6tracehdr )(skbnetworkheader(skb) + optoff + sizeof(hdr));

ioam6filltracedata(skb, ns, trace, true);

ioam6event(IOAM6EVENTTRACE, devnet(skb->dev), GFPATOMIC, (void )trace, hdr->optlen - 2);

If the skb is cloned or lacks sufficient linear headroom, skbensurewritable() will invoke pskbexpandhead(), which reallocates the skb's data buffer and frees the old one, invalidating pointers to it. While the code recalculates the trace pointer immediately after the call to skbensurewritable(), it fails to recalculate the hdr pointer.

This patch fixes the above by recalculating the hdr pointer before passing hdr->optlen to ioam6event(), so that we avoid any UaF.

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

net/mlx5e: Fix use-after-free in mlx5etxreportertimeoutrecover

mlx5etxreportertimeoutrecover() accesses sq->netdev after mlx5esafereopenchannels() has torn down and freed the channel (and its embedded SQs). Replace the three sq->netdev references with priv->netdev which is safe because priv outlives channel teardown.

The netdeverr() call already used priv->netdev for this reason; make the trylock/unlock and healthchanneleqrecover calls consistent.

This fixes the following KASAN splat:

BUG: KASAN: use-after-free in mlx5etxreportertimeoutrecover+0x1dd/0x360 [mlx5core] Read of size 8 at addr ffff889860ed0b28 by task kworker/u113:2/5277

Call Trace: mlx5etxreportertimeoutrecover+0x1dd/0x360 [mlx5core] devlinkhealthreporterrecover+0xa2/0x150 devlinkhealthreport+0x254/0x7c0 mlx5ereportertxtimeout+0x297/0x380 [mlx5core] mlx5etxtimeoutwork+0x109/0x170 [mlx5core] processonework+0x677/0xf20 workerthread+0x51f/0xd90 kthread+0x3a5/0x810 retfromfork+0x208/0x400 retfromforkasm+0x1a/0x30

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

idpf: fix readdevclklock spinlock init in idpfptpinit()

In idpfptpinit(), readdevclklock is initialized after ptpscheduleworker() had already been called (and after idpfptpsettime64() could reach the lock). The PTP aux worker fires immediately upon scheduling and can call into idpfptpreadsrcclkregdirect(), which takes spinlock(&ptp->readdevclklock) on an uninitialized lock, triggering the lockdep "non-static key" warning:

[12973.796587] idpf 0000:83:00.0: Device HW Reset initiated [12974.094507] INFO: trying to register non-static key. ... [12974.097208] Call Trace: [12974.097213] <TASK> [12974.097218] dumpstacklvl+0x93/0xe0 [12974.097234] registerlockclass+0x4c4/0x4e0 [12974.097249] ? lockacquire+0x427/0x2290 [12974.097259] lockacquire+0x98/0x2290 [12974.097272] lockacquire+0xc6/0x310 [12974.097281] ? idpfptpreadsrcclkreg+0xb7/0x150 [idpf] [12974.097311] ? lockdephardirqsonprepare+0xde/0x190 [12974.097318] ? finishtaskswitch.isra.0+0xd2/0x350 [12974.097330] ? pfxptpauxkworker+0x10/0x10 [ptp] [12974.097343] rawspinlock+0x30/0x40 [12974.097353] ? idpfptpreadsrcclkreg+0xb7/0x150 [idpf] [12974.097373] idpfptpreadsrcclkreg+0xb7/0x150 [idpf] [12974.097391] ? kthreadworkerfn+0x88/0x3d0 [12974.097404] ? kthreadworkerfn+0x4e/0x3d0 [12974.097411] idpfptpupdatecachedphctime+0x26/0x120 [idpf] [12974.097428] ? rawspinunlockirq+0x28/0x50 [12974.097436] idpfptpdoauxwork+0x15/0x20 [idpf] [12974.097454] ptpauxkworker+0x20/0x40 [ptp] [12974.097464] kthreadworkerfn+0xd5/0x3d0 [12974.097474] ? pfxkthreadworkerfn+0x10/0x10 [12974.097482] kthread+0xf4/0x130 [12974.097489] ? pfxkthread+0x10/0x10 [12974.097498] retfromfork+0x32c/0x410 [12974.097512] ? pfxkthread+0x10/0x10 [12974.097519] retfromforkasm+0x1a/0x30 [12974.097540] </TASK>

Move the call to spinlockinit() up a bit to make sure readdevclklock is not touched before it's been initialized.

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

KVM: SEV: Require in-GHCB scratch area if GHCB v2+ is in use

As per the GHCB spec, when using GHCB v2+ require the software scratch area to reside in the GHCB's shared buffer. Note, things like Page State Change (PSC) requests rely on this behavior, as the guest can't provide a length when making the request, i.e. the size of the guest payload is bounded by the size of the shared buffer.

Failure to force usage of the GHCB, and a slew of other flaws, lets a malicious SNP guest corrupt host kernel heap memory, and leak host heap layout information.

setupvmgexitscratch() allocates a buffer via kvzalloc(exitinfo2), where exitinfo2 is guest-controlled. With exitinfo2=24, this yields a 24-byte allocation in kmalloc-cg-32 (32-byte slab objects). The buffer holds an 8-byte pschdr followed by 8-byte pscentry structs, so only entries[0] and entries[1] are in-bounds.

snpbeginpsc() validates endentry against VMGEXITPSCMAXCOUNT (253) but NOT against the actual buffer size:

idxend = hdr->endentry;

if (idxend >= VMGEXITPSCMAXCOUNT) { // checks 253, not buffer snpcompletepsc(svm, ...); return 1; }

for (idx = idxstart; idx <= idxend; idx++) { entrystart = entries[idx]; // OOB when idx >= 2

The guest sets endentry=10+, causing the host to iterate entries[2+] which are OOB into adjacent slab objects. For each OOB entry:

- The host reads 8 bytes (OOB READ / info leak oracle) - If the data passes PSC validation, snpcompleteonepsc() writes curpage = 1 or 512 into the entry (OOB WRITE, sev.c:3806) - If validation fails, the error response reveals whether adjacent memory is zero vs non-zero (information disclosure to guest)

The guest controls allocation size (exitinfo2), entry range (curentry/endentry), and can fire unlimited VMGEXITs to repeatedly hit different slab positions.

By exploiting the variety of bugs, a malicious SEV-SNP guest can: - OOB read adjacent kmalloc-cg-32 objects (heap layout disclosure) - OOB write curpage bits into adjacent objects (heap corruption) - Trigger use-after-free conditions across VMGEXITs

E.g. with KASAN enabled, a single insmod of the PoC guest module produces 73 KASAN reports:

BUG: KASAN: slab-out-of-bounds in snpbeginpsc+0x126/0x890 Read of size 8 at addr ffff888219ffb5e0 by task qemu-system-x86/2199

BUG: KASAN: slab-out-of-bounds in snpbeginpsc+0x468/0x890 Write of size 8 at addr ffff888351566648 by task qemu-system-x86/2199

The buggy address belongs to the object at ffff888XXXXXXXXX which belongs to the cache kmalloc-cg-32 of size 32 The buggy address is located N bytes to the right of allocated 32-byte region [ffff888XXXXXXXXX, ffff888XXXXXXXXX)

Breakdown: 62 slab-out-of-bounds (reads + writes past allocation) 7 slab-use-after-free 4 use-after-free

All credit to Stan for the wonderful description and reproducer!

[sean: write changelog]

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

KVM: SEV: Ignore Port I/O requests of length '0'

Explicitly ignore Port I/O requests of length '0' (or count '0'), so that setting up the software scratch area (and other code) doesn't have to worry about underflowing the length, and to allow for WARNing on trying to configure the scratch area with len==0.

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

ipv6: rpl: reserve maclen headroom when recompressed SRH grows

ipv6rplsrhrcv() decompresses an RFC 6554 Source Routing Header, swaps the next segment into ipv6hdr->daddr, recompresses, then pulls the old header and pushes the new one plus the IPv6 header back. The recompressed header can be larger than the received one when the swap reduces the common-prefix length the segments share with daddr (CmprI=0, CmprE>0, seg[0][0] != daddr[0] gives the maximum +8 bytes).

pskbexpandhead() was gated on segmentsleft == 0, so on earlier segments the push consumed unchecked headroom. Once skbpush() leaves fewer than skb->maclen bytes in front of data, skbmacheaderrebuild()'s call to:

skbsetmacheader(skb, -skb->maclen);

will store (data - head) - maclen into the u16 macheader field, which wraps to ~65530, and the following memmove() writes maclen bytes ~64KiB past skb->head.

A single AFINET6/SOCKRAW/IPV6HDRINCL packet over lo with a two segment type-3 SRH (CmprI=0, CmprE=15) reaches headroom 8 after one pass; KASAN reports a 14-byte OOB write in ipv6rthdrrcv.

Fix this by expanding the head whenever the remaining room is less than the push size plus maclen, and request that much extra so the rebuilt MAC header fits afterwards.

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

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

scsi: target: iscsi: Bound iscsiencodetextoutput() appends to rspbuf

iscsiencodetextoutput() concatenates "key=value\0" records into login->rspbuf, an 8192-byte kzalloc(MAXKEYVALUEPAIRS) buffer allocated in iscsitallocloginsetupbuffer(). The three sprintf() call sites in this function (lines 1398, 1411, 1424 in v7.1-rc2) never check the remaining buffer capacity:

length += sprintf(outputbuf, "%s=%s", er->key, er->value); length += 1; outputbuf = textbuf + length;

The 8192-byte ceiling at iscsitargetcheckloginrequest() bounds the input Login PDU payload, but a single PDU can carry up to 2048 minimal four-byte "a=b\0" pairs, each unknown key expanding to a 16-byte "a=NotUnderstood\0" output record via iscsiaddnotunderstoodresponse(). 2048 16 = 32 KiB of output into an 8 KiB buffer, producing a ~24 KiB heap overrun in the kmalloc-8k slab.

The fix introduces a static iscsiencodetextrecord() helper that uses snprintf() with a per-call bounds check against the remaining buffer, and threads a u32 textbufsize parameter through iscsiencodetextoutput(). Both call sites in iscsitargethandlecsgzero() (PHASESECURITY) and iscsitargethandlecsgone() (PHASEOPERATIONAL) pass MAXKEYVALUEPAIRS. On overflow the encoder logs the condition, calls iscsireleaseextraresponses() to drop queued records, and returns -1; both caller sites now emit ISCSISTATUSCLSINITIATORERR / ISCSILOGINSTATUSINITERR via iscsittxloginrsp() before returning, so the initiator sees an explicit failed-login response rather than a silent connection drop. (Prior to this patch only the PHASEOPERATIONAL caller did that; the PHASESECURITY caller is converted to the same shape.)

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

net: mana: Fix TOCTOU double-fetch of hwcmsgid from DMA buffer

In manahwcrxeventhandler(), resp->response.hwcmsgid is read from DMA-coherent memory and bounds-checked, then manahwchandleresp() re-reads the same field from the same DMA buffer for testbit() and pointer arithmetic.

DMA-coherent memory is mapped uncacheable on x86 and is shared, unencrypted, in Confidential VMs (SEV-SNP/TDX), so each load goes directly to host-visible memory. A H/W can modify the value between the check and the use, bypassing the bounds validation.

Fix this by reading hwcmsgid exactly once using READONCE() into a stack-local variable in manahwcrxeventhandler(), and passing the validated value as a parameter to manahwchandleresp().

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

firmware: armffa: Snapshot notifier callbacks under lock

Both notification handlers currently look up a notifier callback under notifylock, drop the lock, and then dereference the returned notifier entry. A concurrent unregister can delete and free that entry in the gap, leaving the handler to dereference stale memory.

Copy the callback pointer and callback data while notifylock is still held and invoke the callback only after the lock is dropped. This keeps the existing callback execution model while removing the use-after-free window in both the framework and non-framework notification paths.

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

net: ipv6: fix NOREF dst use in seg6 and rpl lwtunnels

seg6inputcore() and rplinput() call ip6routeinput() which sets a NOREF dst on the skb, then pass it to dstcachesetip6() invoking dsthold() unconditionally. On PREEMPTRT, ksoftirqd is preemptible and a higher-priority task can release the underlying pcpurt between the lookup and the caching through a concurrent FIB lookup on a shared nexthop. Simplified race sequence:

ksoftirqd/X higher-prio task (same CPU X) ----------- -------------------------------- seg6inputcore(,skb)/rplinput(skb) dstcacheget() -> miss ip6routeinput(skb) -> ip6polroute(,skb,flags) [RT6LOOKUPFDSTNOREF in flags] -> FIB lookup resolves fib6nh [nhid=N route] -> rt6makepcpuroute() [creates pcpurt, refcount=1] pcpurt->sernum = fib6sernum [fib6sernum=W] -> cmpxchg(fib6nh.rt6ipcpu, NULL, pcpurt) [slot was empty, store succeeds] -> skbdstsetnoref(skb, dst) [dst is pcpurt, refcount still 1]

rtgenidbumpipv6() -> bumps fib6sernum [fib6sernum from W to Z] ip6routeoutput() -> ip6polroute() -> FIB lookup resolves fib6nh [nhid=N] -> rt6getpcpuroute() pcpurt->sernum != fib6sernum [W <> Z, stale] -> prev = xchg(rt6ipcpu, NULL) -> dstrelease(prev) [prev is pcpurt, refcount 1->0, dead]

dst = skbdst(skb) [dst is the dead pcpurt] dstcachesetip6(dst) -> dsthold() on dead dst -> WARN / use-after-free

For the race to occur, ksoftirqd must be preemptible (PREEMPTRT without PREEMPTRTNEEDSBHLOCK) and a concurrent task must be able to release the pcpurt. Shared nexthop objects provide such a path, as two routes pointing to the same nhid share the same fib6nh and its rt6ipcpu entry.

Fix seg6inputcore() and rplinput() by calling skbdstforce() after ip6routeinput() to force the NOREF dst into a refcounted one before caching. The output path is not affected as ip6routeoutput() already returns a refcounted dst.

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

nvmet-tcp: fix race between ICReq handling and queue teardown

nvmettcphandleicreq() updates queue->state after sending an Initialization Connection Response (ICResp), but it does so without serializing against target-side queue teardown.

If an NVMe/TCP host sends an Initialization Connection Request (ICReq) and immediately closes the connection, target-side teardown may start in softirq context before iowork drains the already buffered ICReq. In that case, nvmettcpschedulereleasequeue() sets queue->state to NVMETTCPQDISCONNECTING and drops the queue reference under statelock.

If iowork later processes that ICReq, nvmettcphandleicreq() can still overwrite the state back to NVMETTCPQLIVE. That defeats the DISCONNECTING-state guard in nvmettcpschedulereleasequeue() and allows a later socket state change to re-enter teardown and issue a second krefput() on an already released queue.

The ICResp send failure path has the same problem. If teardown has already moved the queue to DISCONNECTING, a send error can still overwrite the state with NVMETTCPQFAILED, again reopening the window for a second teardown path to drop the queue reference.

Fix this by serializing both post-send state transitions with statelock and bailing out if teardown has already started.

Use -ESHUTDOWN as an internal sentinel for that bail-out path rather than propagating it as a transport error like -ECONNRESET. Keep nvmettcpsocketerror() setting rcvstate to NVMETTCPRECVERR before honoring that sentinel so receive-side parsing stays quiesced until the existing release path completes.

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

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

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

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

scsi: target: iscsi: Validate CHAPR length before base64 decode

chapservercomputehash() allocates clientdigest as kzalloc(chap->digestsize) and then, for BASE64-encoded responses, passes chapr directly to chapbase64decode() without checking whether the input length could produce more than digestsize bytes of output.

chapbase64decode() writes to the destination unconditionally as long as there is input to consume. With MAXRESPONSELENGTH set to 128 and the "0b" prefix stripped by extractparam(), up to 127 base64 characters can reach the decoder. 127 characters decode to 95 bytes. For SHA-256 (digestsize=32) this overflows clientdigest by 63 bytes; for MD5 (digestsize=16) the overflow is 79 bytes.

The length check at line 344 fires after the write has already happened.

The HEX branch in the same switch statement already validates the length up front. Apply the same approach to the BASE64 branch: strip trailing base64 padding characters, then reject any input whose data length exceeds DIVROUNDUP(digestsize 4, 3) before calling the decoder.

Stripping trailing '=' before the comparison handles both padded and unpadded encodings. chapbase64decode() already returns early on '=', so the full original string is still passed to the decoder unchanged.

The mutual CHAP path decodes CHAPC into initiatorchgbinhex, which is kzalloc(CHAPCHALLENGESTRLEN). extractparam() caps initiatorchg at CHAPCHALLENGESTRLEN characters, so at most CHAPCHALLENGESTRLEN-1 base64 characters reach the decoder. The maximum decoded size, DIVROUNDUP((CHAPCHALLENGESTRLEN-1) 3, 4), is less than CHAPCHALLENGESTRLEN, so no overflow is possible there. A comment is added at the call site to document this.

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

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

RDMA/rtrs: Fix use-after-free in path file creation cleanup

In the error path of rtrssrvcreatepathfiles(), the sysfs root folders may already have been created and srvpath->kobj may already have been initialized. If a later step fails, the cleanup currently calls kobjectput(&srvpath->kobj) before rtrssrvdestroyoncesysfsrootfolders(srvpath).

kobjectput() may drop the last reference to srvpath->kobj and invoke the release callback, rtrssrvrelease(), which frees srvpath. The following call to rtrssrvdestroyoncesysfsrootfolders(srvpath) then dereferences srvpath internally to access srvpath->srv, resulting in a use-after-free.

This failure path is reached before rtrssrvcreatepathfiles() returns success, so the successful-path lifetime handling is not involved.

Fix this by destroying the sysfs root folders before calling kobjectput(&srvpath->kobj), so srvpath is still valid while the helper accesses it.

This issue was found by a static analysis tool I am developing.

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

net: ethernet: cortina: Carry over frag counter

The gmacrx() NAPI poll function assembles packets in an SKB from a ring buffer.

If the ring buffer gets completely emptied during a poll cycle, we exit gmacrx(), but the packet is not yet completely assembled in the SKB, yet the fragment counter fragnr is reset to zero on the next invocation.

Solve this by making the RX fragment counter a part of the port struct, and carry it over between invocations.

Reset the fragment counter only right after calling napigrofrags(), on error (after calling napifreefrags()) or if stopping the port.

Reset it in some place where not strictly necessary just to emphasize what is going on.

This was found by Sashiko during normal patch review.

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

net: ethernet: cortina: Make RX SKB per-port

The SKB used to assemble packets from fragments in gmacrx() is static local, but the Gemini has two ethernet ports, meaning there can be races between the ports on a bad day if a device is using both.

Make the RX SKB a per-port variable and carry it over between invocations in the port struct instead.

Zero the pointer once we call napigrofrags(), on error (after calling napifreefrags()) or if the port is stopped.

Zero it in some place where not strictly necessary just to emphasize what is going on.

This was found by Sashiko during normal patch review.

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:

KVM: arm64: Take the SRCU lock for page table walks in fault injection and AT emulation

walks1() and kvmwalknesteds2() expect to be called while holding kvm->srcu to guard against memslot changes. While this is generally the case, kvmats12() and kvmfinds1desclevel() call into the respective walkers without taking kvm->srcu.

Fix by acquiring kvm->srcu prior to the table walk in both instances.

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

KVM: SEV: Compute the correct max length of the in-GHCB scratch area

When setting the length of the GHCB scratch area, and the area is in the GHCB shared buffer, set the effective length of the scratch area to the max possible size given the start of the guest-provided pointer, and the end of the shared buffer.

The code was "fine" when first introduced, as KVM doesn't consult the length of the buffer when emulating MMIO, because the passed in @len always specifies the max size required. But for PSC requests, the incoming @len is just the minimum length (to process the header), and KVM needs to know the full size of the scratch area to avoid buffer overflows (spoiler alert).

Opportunistically rename @len => @minlen to better reflect its role.

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

KVM: SEV: Use READONCE() when reading entries/indices from PSC buffer

Use READONCE() when reading entries/indices from the guest-accessible Page State Change buffer to defend against TOCTOU bugs.

Don't bother with READONCE()/WRITEONCE() for cases where KVM is writing (and not consuming the result!), as the guest isn't supposed to touch the buffer while it's being processed. I.e. using READONCE() is all about protecting against misbehaving guests.

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

iommu: Fix WARNON in iommugroupsetdomainnofail() due to reset

In iommugroupsetdomaininternal(), concurrent domain attachments are rejected when any device in the group is recovering. This is necessary to fence concurrent attachments to a multi-device group where devices might share the same RID due to PCI DMA alias quirks, but triggers the WARNON in iommugroupsetdomainnofail().

Other IOMMUSETDOMAINMUSTSUCCEED callers in detach/teardown paths, such as iommugroupsetcoredomain and iommureleasedmaownership, should not be rejected, as the domain would be freed anyway in these nofail paths while group->domain is still pointing to it. So pcidevresetiommudone() could trigger a UAF when re-attaching group->domain.

Honor the IOMMUSETDOMAINMUSTSUCCEED flag, allowing the callers through the group->recoverycnt fence, so as to update the group->domain pointer. Instead add a gdev->blocked check in the device iteration loop, to prevent any concurrent per-device detachment.