ALSA: usb-audio: Avoid potential endless loop in convertchmapv3()

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

iommufd: Fix race during abort for file descriptors

fput() doesn't actually call fileoperations release() synchronously, it puts the file on a work queue and it will be released eventually.

This is normally fine, except for iommufd the file and the iommufdobject are tied to gether. The file has the object as it's privatedata and holds a users refcount, while the object is expected to remain alive as long as the file is.

When the allocation of a new object aborts before installing the file it will fput() the file and then go on to immediately kfree() the obj. This causes a UAF once the workqueue completes the fput() and tries to decrement the users refcount.

Fix this by putting the core code in charge of the file lifetime, and call fputsync() during abort to ensure that release() is called before kfree. fputsync() is a bit too tricky to open code in all the object implementations. Instead the objects tell the core code where the file pointer is and the core will take care of the life cycle.

If the object is successfully allocated then the file will hold a users refcount and the iommufdobject cannot be destroyed.

It is worth noting that close(); ioctl(IOMMUDESTROY); doesn't have an issue because close() is already using a synchronous version of fput().

The UAF looks like this:

BUG: KASAN: slab-use-after-free in iommufdeventqfopsrelease+0x45/0xc0 drivers/iommu/iommufd/eventq.c:376 Write of size 4 at addr ffff888059c97804 by task syz.0.46/6164

CPU: 0 UID: 0 PID: 6164 Comm: syz.0.46 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 Call Trace: <TASK> dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x116/0x1f0 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0xcd/0x630 mm/kasan/report.c:482 kasanreport+0xe0/0x110 mm/kasan/report.c:595 checkregioninline mm/kasan/generic.c:183 [inline] kasancheckrange+0x100/0x1b0 mm/kasan/generic.c:189 instrumentatomicreadwrite include/linux/instrumented.h:96 [inline] atomicfetchsubrelease include/linux/atomic/atomic-instrumented.h:400 [inline] refcountdec include/linux/refcount.h:455 [inline] refcountdec include/linux/refcount.h:476 [inline] iommufdeventqfopsrelease+0x45/0xc0 drivers/iommu/iommufd/eventq.c:376 fput+0x402/0xb70 fs/filetable.c:468 taskworkrun+0x14d/0x240 kernel/taskwork.c:227 resumeusermodework include/linux/resumeusermode.h:50 [inline] exittousermodeloop+0xeb/0x110 kernel/entry/common.c:43 exittousermodeprepare include/linux/irq-entry-common.h:225 [inline] syscallexittousermodework include/linux/entry-common.h:175 [inline] syscallexittousermode include/linux/entry-common.h:210 [inline] dosyscall64+0x41c/0x4c0 arch/x86/entry/syscall64.c:100 entrySYSCALL64afterhwframe+0x77/0x7f

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

xfrm: xfrmallocspi shouldn't use 0 as SPI

x->id.spi == 0 means "no SPI assigned", but since commit 94f39804d891 ("xfrm: Duplicate SPI Handling"), we now create states and add them to the byspi list with this value.

xfrmstatedelete doesn't remove those states from the byspi list, since they shouldn't be there, and this shows up as a UAF the next time we go through the byspi list.

crypto: afalg - Disallow concurrent writes in afalgsendmsg

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

iouring: fix incorrect iokiocb reference in iolinkskb

In iolinkskb function, there is a bug where prevnotif is incorrectly assigned using 'nd' instead of 'prevnd'. This causes the context validation check to compare the current notification with itself instead of comparing it with the previous notification.

Fix by using the correct prevnd parameter when obtaining prevnotif.

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

iommu/amd/pgtbl: Fix possible race while increase page table level

The AMD IOMMU host page table implementation supports dynamic page table levels (up to 6 levels), starting with a 3-level configuration that expands based on IOVA address. The kernel maintains a root pointer and current page table level to enable proper page table walks in allocpte()/fetchpte() operations.

The IOMMU IOVA allocator initially starts with 32-bit address and onces its exhuasted it switches to 64-bit address (max address is determined based on IOMMU and device DMA capability). To support larger IOVA, AMD IOMMU driver increases page table level.

But in unmap path (iommuv1unmappages()), fetchpte() reads pgtable->[root/mode] without lock. So its possible that in exteme corner case, when increaseaddressspace() is updating pgtable->[root/mode], fetchpte() reads wrong page table level (pgtable->mode). It does compare the value with level encoded in page table and returns NULL. This will result is iommuunmap ops to fail and upper layer may retry/log WARNON.

CPU 0 CPU 1 ------ ------ map pages unmap pages allocpte() -> increaseaddressspace() iommuv1unmappages() -> fetchpte() pgtable->root = pte (new root value) READ pgtable->[mode/root] Reads new root, old mode Updates mode (pgtable->mode += 1)

Since Page table level updates are infrequent and already synchronized with a spinlock, implement seqcount to enable lock-free read operations on the read path.

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

rxrpc: Fix untrusted unsigned subtract

Fix the following Smatch static checker warning:

net/rxrpc/rxgkapp.c:65 rxgkyfsdecodeticket() warn: untrusted unsigned subtract. 'ticketlen - 10 4'

by prechecking the length of what we're trying to extract in two places in the token and decoding for a response packet.

Also use sizeof() on the struct we're extracting rather specifying the size numerically to be consistent with the other related statements.

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

gpiolib: acpi: initialize acpigpioinfo struct

Since commit 7c010d463372 ("gpiolib: acpi: Make sure we fill struct acpigpioinfo"), uninitialized acpigpioinfo struct are passed to acpifindgpio() and later in the call stack info->quirks is used in acpipopulategpiolookup. This breaks the i2chidcpi driver:

[ 58.122916] i2chidacpi i2c-UNIW0001:00: HID over i2c has not been provided an Int IRQ [ 58.123097] i2chidacpi i2c-UNIW0001:00: probe with driver i2chidacpi failed with error -22

Fix this by initializing the acpigpioinfo pass to acpifindgpio()

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

iommu/s390: Make attach succeed when the device was surprise removed

When a PCI device is removed with surprise hotplug, there may still be attempts to attach the device to the default domain as part of tear down via (iommureleasedmaownership()), or because the removal happens during probe (iommuprobedevice()). In both cases zpciregisterioat() fails with a cc value indicating that the device handle is invalid. This is because the device is no longer part of the instance as far as the hypervisor is concerned.

Currently this leads to an error return and s390iommuattachdevice() fails. This triggers the WARNON() in iommugroupsetdomainnofail() because attaching to the default domain must never fail.

With the device fenced by the hypervisor no DMAs to or from memory are possible and the IOMMU translations have no effect. Proceed as if the registration was successful and let the hotplug event handling clean up the device.

This is similar to how devices in the error state are handled since commit 59bbf596791b ("iommu/s390: Make attach succeed even if the device is in error state") except that for removal the domain will not be registered later. This approach was also previously discussed at the link.

Handle both cases, error state and removal, in a helper which checks if the error needs to be propagated or ignored. Avoid magic number condition codes by using the pre-existing, but never used, defines for PCI load/store condition codes and rename them to reflect that they apply to all PCI instructions.

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

igc: don't fail igcprobe() on LED setup error

When igcledsetup() fails, igcprobe() fails and triggers kernel panic in freenetdev() since unregisternetdev() is not called. [1] This behavior can be tested using fault-injection framework, especially the failslab feature. [2]

Since LED support is not mandatory, treat LED setup failures as non-fatal and continue probe with a warning message, consequently avoiding the kernel panic.

[1] kernel BUG at net/core/dev.c:12047! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 937 Comm: repro-igc-led-e Not tainted 6.17.0-rc4-enjuk-tnguy-00865-gc4940196ab02 #64 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:freenetdev+0x278/0x2b0 [...] Call Trace: <TASK> igcprobe+0x370/0x910 localpciprobe+0x3a/0x80 pcideviceprobe+0xd1/0x200 [...]

[2] #!/bin/bash -ex

FAILSLABPATH=/sys/kernel/debug/failslab/ DEVICE=0000:00:05.0 STARTADDR=$(grep " igcledsetup" /proc/kallsyms \ | awk '{printf("0x%s", $1)}') ENDADDR=$(printf "0x%x" $((STARTADDR + 0x100)))

echo $STARTADDR > $FAILSLABPATH/require-start echo $ENDADDR > $FAILSLABPATH/require-end echo 1 > $FAILSLABPATH/times echo 100 > $FAILSLABPATH/probability echo N > $FAILSLABPATH/ignore-gfp-wait

echo $DEVICE > /sys/bus/pci/drivers/igc/bind

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

wifi: mac80211: increase scanieslen for S1G

Currently the S1G capability element is not taken into account for the scanieslen, which leads to a buffer length validation failure in ieee80211prephwscan() and subsequent WARN in ieee80211startscan(). This prevents hw scanning from functioning. To fix ensure we accommodate for the S1G capability length.

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

tcp: Clear tcpsk(sk)->fastopenrsk in tcpdisconnect().

syzbot reported the splat below where a socket had tcpsk(sk)->fastopenrsk in the TCPESTABLISHED state. [0]

syzbot reused the server-side TCP Fast Open socket as a new client before the TFO socket completes 3WHS:

1. accept() 2. connect(AFUNSPEC) 3. connect() to another destination

As of accept(), sk->skstate is TCPSYNRECV, and tcpdisconnect() changes it to TCPCLOSE and makes connect() possible, which restarts timers.

Since tcpdisconnect() forgot to clear tcpsk(sk)->fastopenrsk, the retransmit timer triggered the warning and the intended packet was not retransmitted.

Let's call reqskfastopenremove() in tcpdisconnect().

[0]: WARNING: CPU: 2 PID: 0 at net/ipv4/tcptimer.c:542 tcpretransmittimer (net/ipv4/tcptimer.c:542 (discriminator 7)) Modules linked in: CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.17.0-rc5-g201825fb4278 #62 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:tcpretransmittimer (net/ipv4/tcptimer.c:542 (discriminator 7)) Code: 41 55 41 54 55 53 48 8b af b8 08 00 00 48 89 fb 48 85 ed 0f 84 55 01 00 00 0f b6 47 12 3c 03 74 0c 0f b6 47 12 3c 04 74 04 90 <0f> 0b 90 48 8b 85 c0 00 00 00 48 89 ef 48 8b 40 30 e8 6a 4f 06 3e RSP: 0018:ffffc900002f8d40 EFLAGS: 00010293 RAX: 0000000000000002 RBX: ffff888106911400 RCX: 0000000000000017 RDX: 0000000002517619 RSI: ffffffff83764080 RDI: ffff888106911400 RBP: ffff888106d5c000 R08: 0000000000000001 R09: ffffc900002f8de8 R10: 00000000000000c2 R11: ffffc900002f8ff8 R12: ffff888106911540 R13: ffff888106911480 R14: ffff888106911840 R15: ffffc900002f8de0 FS: 0000000000000000(0000) GS:ffff88907b768000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8044d69d90 CR3: 0000000002c30003 CR4: 0000000000370ef0 Call Trace: <IRQ> tcpwritetimer (net/ipv4/tcptimer.c:738) calltimerfn (kernel/time/timer.c:1747) runtimers (kernel/time/timer.c:1799 kernel/time/timer.c:2372) timerexpireremote (kernel/time/timer.c:2385 kernel/time/timer.c:2376 kernel/time/timer.c:2135) tmigrhandleremoteup (kernel/time/timermigration.c:944 kernel/time/timermigration.c:1035) walkgroups.isra.0 (kernel/time/timermigration.c:533 (discriminator 1)) tmigrhandleremote (kernel/time/timermigration.c:1096) handlesoftirqs (./arch/x86/include/asm/jumplabel.h:36 ./include/trace/events/irq.h:142 kernel/softirq.c:580) irqexitrcu (kernel/softirq.c:614 kernel/softirq.c:453 kernel/softirq.c:680 kernel/softirq.c:696) sysvecapictimerinterrupt (arch/x86/kernel/apic/apic.c:1050 (discriminator 35) arch/x86/kernel/apic/apic.c:1050 (discriminator 35)) </IRQ>

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

wifi: wilc1000: avoid buffer overflow in WID string configuration

Fix the following copy overflow warning identified by Smatch checker.

drivers/net/wireless/microchip/wilc1000/wlancfg.c:184 wilcwlanparseresponseframe() error: 'memcpy()' 'cfg->s[i]->str' copy overflow (512 vs 65537)

This patch introduces size check before accessing the memory buffer. The checks are base on the WID type of received data from the firmware. For WID string configuration, the size limit is determined by individual element size in 'struct wilccfgstrvals' that is maintained in 'len' field of 'struct wilccfgstr'.

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

um: virtiouml: Fix use-after-free after putdevice in probe

When registervirtiodevice() fails in virtioumlprobe(), the code sets vudev->registered = 1 even though the device was not successfully registered. This can lead to use-after-free or other issues.

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

qed: Don't collect too many protection override GRC elements

In the protection override dump path, the firmware can return far too many GRC elements, resulting in attempting to write past the end of the previously-kmalloc'ed dump buffer.

This will result in a kernel panic with reason:

BUG: unable to handle kernel paging request at ADDRESS

where "ADDRESS" is just past the end of the protection override dump buffer. The start address of the buffer is: phwfn->cdev->dbgfeatures[DBGFEATUREPROTECTIONOVERRIDE].dumpbuf and the size of the buffer is bufsize in the same data structure.

The panic can be arrived at from either the qede Ethernet driver path:

[exception RIP: qedgrcdumpaddrrange+0x108] qedprotectionoverridedump at ffffffffc02662ed [qed] qeddbgprotectionoverridedump at ffffffffc0267792 [qed] qeddbgfeature at ffffffffc026aa8f [qed] qeddbgalldata at ffffffffc026b211 [qed] qedfwfatalreporterdump at ffffffffc027298a [qed] devlinkhealthdodump at ffffffff82497f61 devlinkhealthreport at ffffffff8249cf29 qedreportfatalerror at ffffffffc0272baf [qed] qedesptask at ffffffffc045ed32 [qede] processonework at ffffffff81d19783

or the qedf storage driver path:

[exception RIP: qedgrcdumpaddrrange+0x108] qedprotectionoverridedump at ffffffffc068b2ed [qed] qeddbgprotectionoverridedump at ffffffffc068c792 [qed] qeddbgfeature at ffffffffc068fa8f [qed] qeddbgalldata at ffffffffc0690211 [qed] qedfwfatalreporterdump at ffffffffc069798a [qed] devlinkhealthdodump at ffffffff8aa95e51 devlinkhealthreport at ffffffff8aa9ae19 qedreportfatalerror at ffffffffc0697baf [qed] qedhwerrnotify at ffffffffc06d32d7 [qed] qedspqpost at ffffffffc06b1011 [qed] qedfcoedestroyconn at ffffffffc06b2e91 [qed] qedfcleanupfcport at ffffffffc05e7597 [qedf] qedfrporteventhandler at ffffffffc05e7bf7 [qedf] fcrportwork at ffffffffc02da715 [libfc] processonework at ffffffff8a319663

Resolve this by clamping the firmware's return value to the maximum number of legal elements the firmware should return.

cnic: Fix use-after-free bugs in cnicdeletetask

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

octeontx2-pf: Fix use-after-free bugs in otx2synctstamp()

The original code relies on canceldelayedwork() in otx2ptpdestroy(), which does not ensure that the delayed work item synctstampwork has fully completed if it was already running. This leads to use-after-free scenarios where otx2ptp is deallocated by otx2ptpdestroy(), while synctstampwork remains active and attempts to dereference otx2ptp in otx2synctstamp(). Furthermore, the synctstampwork is cyclic, the likelihood of triggering the bug is nonnegligible.

A typical race condition is illustrated below:

CPU 0 (cleanup) | CPU 1 (delayed work callback) otx2remove() | otx2ptpdestroy() | otx2synctstamp() canceldelayedwork() | kfree(ptp) | | ptp = containerof(...); //UAF | ptp-> //UAF

This is confirmed by a KASAN report:

BUG: KASAN: slab-use-after-free in runtimerbase.part.0+0x7d7/0x8c0 Write of size 8 at addr ffff88800aa09a18 by task bash/136 ... Call Trace: <IRQ> dumpstacklvl+0x55/0x70 printreport+0xcf/0x610 ? runtimerbase.part.0+0x7d7/0x8c0 kasanreport+0xb8/0xf0 ? runtimerbase.part.0+0x7d7/0x8c0 runtimerbase.part.0+0x7d7/0x8c0 ? pfxruntimerbase.part.0+0x10/0x10 ? pfxreadtsc+0x10/0x10 ? ktimeget+0x60/0x140 ? lapicnextevent+0x11/0x20 ? clockeventsprogramevent+0x1d4/0x2a0 runtimersoftirq+0xd1/0x190 handlesoftirqs+0x16a/0x550 irqexitrcu+0xaf/0xe0 sysvecapictimerinterrupt+0x70/0x80 </IRQ> ... Allocated by task 1: kasansavestack+0x24/0x50 kasansavetrack+0x14/0x30 kasankmalloc+0x7f/0x90 otx2ptpinit+0xb1/0x860 otx2probe+0x4eb/0xc30 localpciprobe+0xdc/0x190 pcideviceprobe+0x2fe/0x470 reallyprobe+0x1ca/0x5c0 driverprobedevice+0x248/0x310 driverprobedevice+0x44/0x120 driverattach+0xd2/0x310 busforeachdev+0xed/0x170 busadddriver+0x208/0x500 driverregister+0x132/0x460 dooneinitcall+0x89/0x300 kernelinitfreeable+0x40d/0x720 kernelinit+0x1a/0x150 retfromfork+0x10c/0x1a0 retfromforkasm+0x1a/0x30

Freed by task 136: kasansavestack+0x24/0x50 kasansavetrack+0x14/0x30 kasansavefreeinfo+0x3a/0x60 kasanslabfree+0x3f/0x50 kfree+0x137/0x370 otx2ptpdestroy+0x38/0x80 otx2remove+0x10d/0x4c0 pcideviceremove+0xa6/0x1d0 devicereleasedriverinternal+0xf8/0x210 pcistopbusdevice+0x105/0x150 pcistopandremovebusdevicelocked+0x15/0x30 removestore+0xcc/0xe0 kernfsfopwriteiter+0x2c3/0x440 vfswrite+0x871/0xd70 ksyswrite+0xee/0x1c0 dosyscall64+0xac/0x280 entrySYSCALL64afterhwframe+0x77/0x7f ...

Replace canceldelayedwork() with canceldelayedworksync() to ensure that the delayed work item is properly canceled before the otx2ptp is deallocated.

This bug was initially identified through static analysis. To reproduce and test it, I simulated the OcteonTX2 PCI device in QEMU and introduced artificial delays within the otx2synctstamp() function to increase the likelihood of triggering the bug.

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

zram: fix slot write race condition

Parallel concurrent writes to the same zram index result in leaked zsmalloc handles. Schematically we can have something like this:

CPU0 CPU1 zramslotlock() zsfree(handle) zramslotlock() zramslotlock() zsfree(handle) zramslotlock()

compress compress handle = zsmalloc() handle = zsmalloc() zramslotlock zramsethandle(handle) zramslotlock zramslotlock zramsethandle(handle) zramslotlock

Either CPU0 or CPU1 zsmalloc handle will leak because zsfree() is done too early. In fact, we need to reset zram entry right before we set its new handle, all under the same slot lock scope.

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

ksmbd: smbdirect: verify remainingdatalength respects maxfragmentedrecvsize

This is inspired by the check for dataoffset + datalength.

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

iommu/s390: Fix memory corruption when using identity domain

zpcigetiommuctrs() returns counter information to be reported as part of device statistics; these counters are stored as part of the s390domain. The problem, however, is that the identity domain is not backed by an s390domain and so the conversion via tos390domain() yields a bad address that is zero'd initially and read on-demand later via a sysfs read. These counters aren't necessary for the identity domain; just return NULL in this case.

This issue was discovered via KASAN with reports that look like: BUG: KASAN: global-out-of-bounds in zpcifmbenabledevice when using the identity domain for a device on s390.

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

ASoC: codec: sma1307: Fix memory corruption in sma1307settingloaded()

The sma1307->set.headersize is how many integers are in the header (there are 8 of them) but instead of allocating space of 8 integers we allocate 8 bytes. This leads to memory corruption when we copy data it on the next line:

memcpy(sma1307->set.header, data, sma1307->set.headersize sizeof(int));

Also since we're immediately copying over the memory in ->set.header, there is no need to zero it in the allocator. Use devmkmallocarray() to allocate the memory instead.

crypto: afalg - Set merge to zero early in afalgsendmsg

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

smb: client: fix smbdirectrecvio leak in smbdnegotiate() error path

During tests of another unrelated patch I was able to trigger this error: Objects remaining on kmemcacheshutdown()

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

i2c: rtl9300: ensure data length is within supported range

Add an explicit check for the xfer length to 'rtl9300i2cconfigxfer' to ensure the data length isn't within the supported range. In particular a data length of 0 is not supported by the hardware and causes unintended or destructive behaviour.

This limitation becomes obvious when looking at the register documentation [1]. 4 bits are reserved for DATAWIDTH and the value of these 4 bits is used as N + 1, allowing a data length range of 1 <= len <= 16.

Affected by this is the SMBus Quick Operation which works with a data length of 0. Passing 0 as the length causes an underflow of the value due to:

(len - 1) & 0xf

and effectively specifying a transfer length of 16 via the registers. This causes a 16-byte write operation instead of a Quick Write. For example, on SFP modules without write-protected EEPROM this soft-bricks them by overwriting some initial bytes.

For completeness, also add a quirk for the zero length.

[1] https://svanheule.net/realtek/longan/register/i2cmst1ctrl2

ceph: fix race condition validating rparent before applying state

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

erofs: fix invalid algorithm for encoded extents

The current algorithm sanity checks do not properly apply to new encoded extents.

Unify the algorithm check with ZEROFSCOMPRESSION(RUNTIME)MAX and ensure consistency with sbi->availablecompralgs.

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

ixgbe: fix incorrect map used in eee linkmode

incorrectly used ixgbelpmap in loops intended to populate the supported and advertised EEE linkmode bitmaps based on ixgbelsmap. This results in incorrect bit setting and potential out-of-bounds access, since ixgbelpmap and ixgbelsmap have different sizes and purposes.

ixgbelpmap[i] -> ixgbelsmap[i]

Use ixgbelsmap for supported and advertised linkmodes, and keep ixgbelpmap usage only for link partner (lpadvertised) mapping.

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

wifi: mt76: mt7996: add missing check for rx wcid entries

Non-station wcid entries must not be passed to the rx functions. In case of the global wcid entry, it could even lead to corruption in the wcid array due to pointer being casted to struct mt7996stalink using containerof.

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

wifi: mt76: fix linked list corruption

Never leave scheduled wcid entries on the temporary on-stack list

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

bpf: Fix out-of-bounds dynptr write in bpfcryptocrypt

Stanislav reported that in bpfcryptocrypt() the destination dynptr's size is not validated to be at least as large as the source dynptr's size before calling into the crypto backend with 'len = srclen'. This can result in an OOB write when the destination is smaller than the source.

Concretely, in mentioned function, psrc and pdst are both linear buffers fetched from each dynptr:

psrc = bpfdynptrdata(src, srclen); [...] pdst = bpfdynptrdatarw(dst, dstlen); [...] err = decrypt ? ctx->type->decrypt(ctx->tfm, psrc, pdst, srclen, piv) : ctx->type->encrypt(ctx->tfm, psrc, pdst, srclen, piv);

The crypto backend expects pdst to be large enough with a srclen length that can be written. Add an additional srclen > dstlen check and bail out if it's the case. Note that these kfuncs are accessible under root privileges only.