block: avoid possible overflow for chunksectors check in blkstacklimits()

fs: Prevent file descriptor table allocations exceeding INTMAX

bpf: Forget ranges when refining tnum after JSET

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

netlink: avoid infinite retry looping in netlinkunicast()

netlinkattachskb() checks for the socket's read memory allocation constraints. Firstly, it has:

rmem < READONCE(sk->skrcvbuf)

to check if the just increased rmem value fits into the socket's receive buffer. If not, it proceeds and tries to wait for the memory under:

rmem + skb->truesize > READONCE(sk->skrcvbuf)

The checks don't cover the case when skb->truesize + sk->skrmemalloc is equal to sk->skrcvbuf. Thus the function neither successfully accepts these conditions, nor manages to reschedule the task - and is called in retry loop for indefinite time which is caught as:

rcu: INFO: rcusched self-detected stall on CPU rcu: 0-....: (25999 ticks this GP) idle=ef2/1/0x4000000000000000 softirq=262269/262269 fqs=6212 (t=26000 jiffies g=230833 q=259957) NMI backtrace for cpu 0 CPU: 0 PID: 22 Comm: kauditd Not tainted 5.10.240 #68 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc42 04/01/2014 Call Trace: <IRQ> dumpstack lib/dumpstack.c:120 nmicpubacktrace.cold lib/nmibacktrace.c:105 nmitriggercpumaskbacktrace lib/nmibacktrace.c:62 rcudumpcpustacks kernel/rcu/treestall.h:335 rcuschedclockirq.cold kernel/rcu/tree.c:2590 updateprocesstimes kernel/time/timer.c:1953 tickschedhandle kernel/time/tick-sched.c:227 tickschedtimer kernel/time/tick-sched.c:1399 hrtimerrunqueues kernel/time/hrtimer.c:1652 hrtimerinterrupt kernel/time/hrtimer.c:1717 sysvecapictimerinterrupt arch/x86/kernel/apic/apic.c:1113 asmcallirqonstack arch/x86/entry/entry64.S:808 </IRQ>

netlinkattachskb net/netlink/afnetlink.c:1234 netlinkunicast net/netlink/afnetlink.c:1349 kauditdsendqueue kernel/audit.c:776 kauditdthread kernel/audit.c:897 kthread kernel/kthread.c:328 retfromfork arch/x86/entry/entry64.S:304

Restore the original behavior of the check which commit in Fixes accidentally missed when restructuring the code.

Found by Linux Verification Center (linuxtesting.org).

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

net: usb: asixdevices: add phymask for ax88772 mdio bus

Without setting phymask for ax88772 mdio bus, current driver may create at most 32 mdio phy devices with phy address range from 0x00 ~ 0x1f. DLink DUB-E100 H/W Ver B1 is such a device. However, only one main phy device will bind to net phy driver. This is creating issue during system suspend/resume since phypollingmode() in phystatemachine() will directly deference member of phydev->drv for non-main phy devices. Then NULL pointer dereference issue will occur. Due to only external phy or internal phy is necessary, add phymask for ax88772 mdio bus to workarnoud the issue.

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

netfilter: ctnetlink: fix refcount leak on table dump

There is a reference count leak in ctnetlinkdumptable(): if (res < 0) { nfconntrackget(&ct->ctgeneral); // HERE cb->args[1] = (unsigned long)ct; ...

While its very unlikely, its possible that ct == last. If this happens, then the refcount of ct was already incremented. This 2nd increment is never undone.

This prevents the conntrack object from being released, which in turn keeps prevents cnet->count from dropping back to 0.

This will then block the netns dismantle (or conntrack rmmod) as nfconntrackcleanupnetlist() will wait forever.

This can be reproduced by running conntrackresize.sh selftest in a loop. It takes ~20 minutes for me on a preemptible kernel on average before I see a runaway kworker spinning in nfconntrackcleanupnetlist.

One fix would to change this to: if (res < 0) { if (ct != last) nfconntrackget(&ct->ctgeneral);

But this reference counting isn't needed in the first place. We can just store a cookie value instead.

A followup patch will do the same for ctnetlinkexpdumptable, it looks to me as if this has the same problem and like ctnetlinkdumptable, we only need a 'skip hint', not the actual object so we can apply the same cookie strategy there as well.

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

rcu/nocb: Fix possible invalid rdp's->nocbcbkthread pointer access

In the preparation stage of CPU online, if the corresponding the rdp's->nocbcbkthread does not exist, will be created, there is a situation where the rdp's rcuop kthreads creation fails, and then de-offload this CPU's rdp, does not assign this CPU's rdp->nocbcbkthread pointer, but this rdp's->nocbgprdp and rdp's->rdpgp->nocbgpkthread is still valid.

This will cause the subsequent re-offload operation of this offline CPU, which will pass the conditional check and the kthreadunpark() will access invalid rdp's->nocbcbkthread pointer.

This commit therefore use rdp's->nocbgpkthread instead of rdpgp's->nocbgpkthread for safety check.

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

mm/ptdump: take the memory hotplug lock inside ptdumpwalkpgd()

Memory hot remove unmaps and tears down various kernel page table regions as required. The ptdump code can race with concurrent modifications of the kernel page tables. When leaf entries are modified concurrently, the dump code may log stale or inconsistent information for a VA range, but this is otherwise not harmful.

But when intermediate levels of kernel page table are freed, the dump code will continue to use memory that has been freed and potentially reallocated for another purpose. In such cases, the ptdump code may dereference bogus addresses, leading to a number of potential problems.

To avoid the above mentioned race condition, platforms such as arm64, riscv and s390 take memory hotplug lock, while dumping kernel page table via the sysfs interface /sys/kernel/debug/kernelpagetables.

Similar race condition exists while checking for pages that might have been marked W+X via /sys/kernel/debug/kernelpagetables/checkwxpages which in turn calls ptdumpcheckwx(). Instead of solving this race condition again, let's just move the memory hotplug lock inside generic ptdumpcheckwx() which will benefit both the scenarios.

Drop getonlinemems() and putonlinemems() combination from all existing platform ptdump code paths.

eventpoll: Fix semi-unbounded recursion

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

crypto: ccp - Do not initialize SNP for ioctl(SNPCONFIG)

Sashiko notes:

if SEV initialization fails and KVM is actively running normal VMs, could a userspace process trigger this code path via /dev/sev ioctls (e.g., SEVPDHGEN) and zero out MSRVMHSAVEPA globally? Would the next VMRUN execution for an active VM trigger a general protection fault and crash the host?

Refuse to re-try initialization if SNP is not already initialized for SNPCONFIG.

This is technically an ABI break: before if SNP initialization failed it could be transparently retriggered by this ioctl, and if no VMs were running, everything worked fine. Hopefully this is enough of a corner case that nobody will notice, but someone does, there are a few options:

do something like symbolget() for kvm and refuse to initialize if KVM is loaded check each cpu's HSAVEPA for non-zero data before re-initializing once initialization has failed, continue to refuse to initialize until the ccp module is unloaded

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

crypto: ccp - Do not initialize SNP for ioctl(SNPVLEKLOAD)

Sashiko notes:

if SEV initialization fails and KVM is actively running normal VMs, could a userspace process trigger this code path via /dev/sev ioctls (e.g., SEVPDHGEN) and zero out MSRVMHSAVEPA globally? Would the next VMRUN execution for an active VM trigger a general protection fault and crash the host?

The SEV firmware docs for SNPVLEKLOAD note:

On SNPSHUTDOWN, the VLEK is deleted.

That is, the initialization/shutdown wrapper here is pointless, because the firmware immediately throws away the key anyway. Instead, refuse to do anything if SNP has not been previously initialized.

This is an ABI break: before, this was a no-op and almost certainly a mistake by userspace, and now it returns -ENODEV. ABI compatibility could be maintained here by simply returning 0 in the check instead.

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

crypto: ccp - Do not initialize SNP for ioctl(SNPCOMMIT)

Sashiko notes:

if SEV initialization fails and KVM is actively running normal VMs, could a userspace process trigger this code path via /dev/sev ioctls (e.g., SEVPDHGEN) and zero out MSRVMHSAVEPA globally? Would the next VMRUN execution for an active VM trigger a general protection fault and crash the host?

The SNPCOMMIT command does not require the firmware to be in any particular state. Skip initializing it if it was previously uninitialized.

The SEV-SNP firmware specification doc 56860 does not mention SNPCOMMIT in Table 5 as a command that is allowed in the UNINIT state, but it is in fact allowed and a future documentation update will reflect that.

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

crypto: ccp - Do not initialize SNP for SEV ioctls

Sashiko notes:

if SEV initialization fails and KVM is actively running normal VMs, could a userspace process trigger this code path via /dev/sev ioctls (e.g., SEVPDHGEN) and zero out MSRVMHSAVEPA globally? Would the next VMRUN execution for an active VM trigger a general protection fault and crash the host?

sevmovetoinitstate() is called for ioctls requiring only SEV firmware: SEVPEKGEN, SEVPDHGEN, SEVPEKCSR, SEVPEKCERTIMPORT, and SEVPDHCERTEXPORT. After the firmware command, it does SEVSHUTDOWN on the SEV firmware. Since these commands do not require SNP to be initialized, skip it by calling sevplatforminitlocked() which only initializes the SEV firmware. This way SNP is not Initialized at all, and HSAVEPA is not cleared.

The previous code saved any SEV initialization firmware error to initargs.error and then threw it away and hardcoded the return value of INVALIDPLATFORMSTATE regardless of the real firmware error. This patch changes it to surface the underlying error, which is hopefully both more useful and doesn't cause any problems.

Note that it is still safe to call sevfirmwareshutdown() directly: it calls sevsnpshutdownlocked(), which skips SNP shutdown if SNP was not initialized.

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

crypto: chacha20poly1305 - validate poly1305 template argument

chachapolycreate() still accepts the compatibility poly1305 parameter in the template name, but it assumes the second template argument is always present and immediately passes it to strcmp().

When the argument is missing, cryptoattralgname() returns an error pointer. Check for that before comparing the name so malformed template instantiations fail with an error instead of dereferencing the error pointer in strcmp().

This matches the surrounding Crypto API template pattern where cryptoattralgname() results are validated before string-specific use.

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

ovpn: respect peer refcount in CMDNEWPEER error path

ovpnnlpeernewdoit()'s error path calls ovpnpeerrelease() directly rather than ovpnpeerput(), bypassing the kref. The accompanying comment ("peer was not yet hashed, thus it is not used in any context") holds for UDP but not for TCP.

For UDP, the ovpnsocket union uses the .ovpn arm and never points back at a peer; UDP encaprecv looks up peers via the not-yet-populated hashtables, so the new peer is unreachable until ovpnpeeradd() publishes it.

For TCP, ovpnsocketnew() sets ovpnsock->peer and ovpntcpsocketattach() publishes ovpnsock via rcuassignskuserdata(). From that moment until ovpnsocketrelease() detaches in the error path, the TCP fd is fully wired: userspace recvmsg / sendmsg / close / poll on the fd, as well as the strparser-driven ovpntcprcv() path, can reach the peer through skuserdata -> ovpnsock->peer and bump its refcount via ovpnpeerhold().

ovpntcpsocketwaitfinish() (called inside ovpnsocketrelease()) drains strparser and the tx work, but does not synchronize with userspace syscall callers that already hold a peer reference. If ovpnnlpeermodify() or ovpnpeeradd() returns an error while such a caller is in flight - notably an ovpntcprecvmsg() blocked in skbrecvdatagram() on peer->tcp.userqueue - the direct ovpnpeerrelease() destroys the peer while the caller still holds the reference, and the eventual ovpnpeerput() from that caller operates on freed memory.

Replace the direct destructor call with ovpnpeerput() so the kref correctly defers destruction until the last reference is dropped. In the common case where no concurrent user is present, behaviour is unchanged: the kref hits zero immediately and ovpnpeerreleasekref() runs the same destructor.

With this conversion ovpnpeerrelease() has no callers outside peer.c - ovpnpeerreleasekref() in the same translation unit is the only remaining user - so make it static and drop its declaration from peer.h.

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

ovpn: tcp - use cached peer pointer in ovpntcpclose()

ovpntcpclose() loads the ovpnsocket via rcudereferenceskuserdata() under rcureadlock(), takes a reference on sock->peer, caches the peer pointer in a local, and drops the read lock. It then passes sock->peer (rather than the cached local) to ovpnpeerdel(), re-dereferencing the ovpnsocket after the RCU read section has ended.

Unlike ovpntcpsendmsg(), which uses the same "load under RCU, use after unlock" pattern but is protected by locksock() held across the function, ovpntcpclose() runs without the socket lock: inetrelease() invokes skprot->close() without taking locksock first.

ovpnsocketrelease() can therefore complete its krefput -> detach -> synchronizercu -> kfree(sock) sequence concurrently, in the window after ovpntcpclose() drops rcureadlock() but before it dereferences sock->peer. The synchronizercu() in ovpnsocketrelease() protects readers that use the dereferenced pointer inside the RCU read section, not those that escape the pointer to a local and use it afterwards.

A reproducer follows the pattern of commit 94560267d6c4 ("ovpn: tcp - don't deref NULL sksocket member after tcpclose()"): trigger a peer removal (keepalive expiration or netlink OVPNCMDDELPEER) at the same moment userspace closes the TCP fd. That commit fixed the detach-side of the same race window; this one fixes the close-side at a different victim.

Tighten the entry block to read sock->peer exactly once into the cached peer local, and route all subsequent uses (the hold check, the ovpnpeerdel() call, and the prot->close() invocation) through that local. sock->peer is only ever written once in ovpnsocketnew() under locksock(), before rcuassignskuserdata() publishes the ovpnsocket, and is never reassigned afterwards - but the previous multi-read pattern made that invariant implicit rather than explicit. The same multi-read shape exists in ovpntcprecvmsg(), ovpntcpsendmsg(), ovpntcpdataready() and ovpntcpwritespace(); those will be cleaned up via a dedicated helper in a follow-up net-next series.

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

NFS: Fix filehandle bounds checking in nfsfhtodentry()

The function needs to check the minimal filehandle length before it can access the embedded filehandle.

ALSA: usb-audio: Validate UAC3 cluster segment descriptors

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

tls: handle data disappearing from under the TLS ULP

TLS expects that it owns the receive queue of the TCP socket. This cannot be guaranteed in case the reader of the TCP socket entered before the TLS ULP was installed, or uses some non-standard read API (eg. zerocopy ones). Replace the WARNON() and a buggy early exit (which leaves anchor pointing to a freed skb) with real error handling. Wipe the parsing state and tell the reader to retry.

We already reload the anchor every time we (re)acquire the socket lock, so the only condition we need to avoid is an out of bounds read (not having enough bytes in the socket for previously parsed record len).

If some data was read from under TLS but there's enough in the queue we'll reload and decrypt what is most likely not a valid TLS record. Leading to some undefined behavior from TLS perspective (corrupting a stream? missing an alert? missing an attack?) but no kernel crash should take place.

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

smb3: fix for slab out of bounds on mount to ksmbd

With KASAN enabled, it is possible to get a slab out of bounds during mount to ksmbd due to missing check in parseserverinterfaces() (see below):

BUG: KASAN: slab-out-of-bounds in parseserverinterfaces+0x14ee/0x1880 [cifs] Read of size 4 at addr ffff8881433dba98 by task mount/9827

CPU: 5 UID: 0 PID: 9827 Comm: mount Tainted: G OE 6.16.0-rc2-kasan #2 PREEMPT(voluntary) Tainted: [O]=OOTMODULE, [E]=UNSIGNEDMODULE Hardware name: Dell Inc. Precision Tower 3620/0MWYPT, BIOS 2.13.1 06/14/2019 Call Trace: <TASK> dumpstacklvl+0x9f/0xf0 printreport+0xd1/0x670 virtaddrvalid+0x22c/0x430 ? parseserverinterfaces+0x14ee/0x1880 [cifs] ? kasancompletemodereportinfo+0x2a/0x1f0 ? parseserverinterfaces+0x14ee/0x1880 [cifs] kasanreport+0xd6/0x110 parseserverinterfaces+0x14ee/0x1880 [cifs] asanreportloadnnoabort+0x13/0x20 parseserverinterfaces+0x14ee/0x1880 [cifs] ? pfxparseserverinterfaces+0x10/0x10 [cifs] ? tracehardirqson+0x51/0x60 SMB3requestinterfaces+0x1ad/0x3f0 [cifs] ? pfxSMB3requestinterfaces+0x10/0x10 [cifs] ? SMB2tcon+0x23c/0x15d0 [cifs] smb3qfstcon+0x173/0x2b0 [cifs] ? pfxsmb3qfstcon+0x10/0x10 [cifs] ? cifsgettcon+0x105d/0x2120 [cifs] ? dorawspinunlock+0x5d/0x200 ? cifsgettcon+0x105d/0x2120 [cifs] ? pfxsmb3qfstcon+0x10/0x10 [cifs] cifsmountgettcon+0x369/0xb90 [cifs] ? dfscachefind+0xe7/0x150 [cifs] dfsmountshare+0x985/0x2970 [cifs] ? checkpath.constprop.0+0x28/0x50 ? savetrace+0x54/0x370 ? pfxdfsmountshare+0x10/0x10 [cifs] ? lockacquire+0xb82/0x2ba0 ? kasancheckwrite+0x18/0x20 cifsmount+0xbc/0x9e0 [cifs] ? pfxcifsmount+0x10/0x10 [cifs] ? dorawspinunlock+0x5d/0x200 ? cifssetupcifssb+0x29d/0x810 [cifs] cifssmb3domount+0x263/0x1990 [cifs]

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

media: venus: Fix OOB read due to missing payload bound check

Currently, The eventseqchanged() handler processes a variable number of properties sent by the firmware. The number of properties is indicated by the firmware and used to iterate over the payload. However, the payload size is not being validated against the actual message length.

This can lead to out-of-bounds memory access if the firmware provides a property count that exceeds the data available in the payload. Such a condition can result in kernel crashes or potential information leaks if memory beyond the buffer is accessed.

Fix this by properly validating the remaining size of the payload before each property access and updating bounds accordingly as properties are parsed.

This ensures that property parsing is safely bounded within the received message buffer and protects against malformed or malicious firmware behavior.

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

RDMA/siw: Fix the sendmsg byte count in siwtcpsendpages

Ever since commit c2ff29e99a76 ("siw: Inline dotcpsendpages()"), we have been doing this:

static int siwtcpsendpages(struct socket s, struct page page, int offset, sizet size) [...] / Calculate the number of bytes we need to push, for this page specifically / sizet bytes = mint(sizet, PAGESIZE - offset, size); / If we can't splice it, then copy it in, as normal / if (!sendpageok(page[i])) msg.msgflags &= ~MSGSPLICEPAGES; / Set the bvec pointing to the page, with len $bytes / bvecsetpage(&bvec, page[i], bytes, offset); / Set the iter to $size, aka the size of the whole sendpages (!!!) / ioviterbvec(&msg.msgiter, ITERSOURCE, &bvec, 1, size); trypageagain: locksock(sk); / Sendmsg with $size size (!!!) / rv = tcpsendmsglocked(sk, &msg, size);

This means we've been sending oversized ioviters and tcpsendmsg calls for a while. This has a been a benign bug because sendpageok() always returned true. With the recent slab allocator changes being slowly introduced into next (that disallow sendpage on large kmalloc allocations), we have recently hit out-of-bounds crashes, due to slight differences in ioviter behavior between the MSGSPLICEPAGES and "regular" copy paths:

(MSGSPLICEPAGES) skbsplicefromiter ioviterextractpages ioviterextractbvecpages uses i->nrsegs to correctly stop in its tracks before OoB'ing everywhere skbsplicefromiter gets a "short" read

(!MSGSPLICEPAGES) skbcopytopagenocache copy=iovitercount [...] copyfromiter / this doesn't help / if (unlikely(iter->count < len)) len = iter->count; iteratebvec ... and we run off the bvecs

Fix this by properly setting the ioviter's byte count, plus sending the correct byte count to tcpsendmsglocked.

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

rxrpc: Fix RxGK token loading to check bounds

rxrpcpreparsexdryfsrxgk() reads the raw key length and ticket length from the XDR token as u32 values and passes each through roundup(x, 4) before using the rounded value for validation and allocation. When the raw length is >= 0xfffffffd, roundup() wraps to 0, so the bounds check and kzalloc both use 0 while the subsequent memcpy still copies the original ~4 GiB value, producing a heap buffer overflow reachable from an unprivileged addkey() call.

Fix this by:

(1) Rejecting raw key lengths above AFSTOKENGKKEYMAX and raw ticket lengths above AFSTOKENGKTOKENMAX before rounding, consistent with the caps that the RxKAD path already enforces via AFSTOKENRKTIXMAX.

(2) Sizing the flexible-array allocation from the validated raw key length via structsizet() instead of the rounded value.

(3) Caching the raw lengths so that the later field assignments and memcpy calls do not re-read from the token, eliminating a class of TOCTOU re-parse.

The control path (valid token with lengths within bounds) is unaffected.

drm/amdgpu: Refactor amdgpugemvaioctl for Handling Last Fence Update and Timeline Management v4

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

nfsd: handle getclientlocked() failure in nfsd4setclientidconfirm()

Lei Lu recently reported that nfsd4setclientidconfirm() did not check the return value from getclientlocked(). a SETCLIENTIDCONFIRM could race with a confirmed client expiring and fail to get a reference. That could later lead to a UAF.

Fix this by getting a reference early in the case where there is an extant confirmed client. If that fails then treat it as if there were no confirmed client found at all.

In the case where the unconfirmed client is expiring, just fail and return the result from getclientlocked().

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

usb: core: config: Prevent OOB read in SS endpoint companion parsing

usbparsessendpointcompanion() checks descriptor type before length, enabling a potentially odd read outside of the buffer size.

Fix this up by checking the size first before looking at any of the fields in the descriptor.

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

netfilter: nftinner: release locallock before re-enabling softirqs

Quoting sashiko: In the error path, localbhenable() is called before localunlocknestedbh().

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

KVM: arm64: nv: Avoid dereferencing NULL VNCR pseudo-TLB

VNCR TLB invalidation occurs from MMU notifiers or TLBI instructions, and either can race against a vcpu not being onlined yet (no pseudo-TLB allocated). Similarly, the TLB might be invalid, and the invalidation should be skipped in this case.

Both kvminvalidatevncripa() and kvminvalidatevncrva() are expected to perform the same checks, except that the latter doesn't check for the allocation and blindly dereferences the pointer.

Solve this by introducing a new iterator built on top of the usual kvmforeachvcpu() that checks for both of the above conditions, and convert the two users to it.

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

KVM: arm64: Don't leak PFN when kvmtranslatevncr() races MMU notifier

In the case that kvmtranslatevncr() races with an MMU notifier the early return does not release a reference on the faulted in PFN. Add the necessary call to kvmreleasefaultinpage() for the unused PFN.

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

fuse-uring: fix moving cancelled entry to entinuserspace list

fuseuringcancel() moves entries that are available (these have no reqs attached) to the entinuserspace list. entlistrequestexpired() checks the first entry on entinuserspace and dereferences ent->fusereq unconditionally, which will crash on a cancelled entry that was moved to this list.

Fix this by freeing the entry and dropping queuerefs directly in fuseuringcancel(). This is safe because cancel is the cancel handler itself - after iouringcmddone(), no more cancels will be dispatched for this command, and teardown serializes with cancel via queue->lock.

Since cancel now decrements queuerefs, fuseuringabort() must no longer gate fuseuringabortendrequests() on queuerefs > 0, as cancelled entries may have already dropped queuerefs while requests are still queued. Remove the gate so abort always flushes requests and stops queues.