In the Linux kernel, the following vulnerability has been resolved:
KVM: x86/mmu: Check write tracking in all address spaces
kvmgfniswritetracked() checks only the supplied memslot, but page tracking is per-address-space and shadow pages are shared across all address spaces. With SMM, a GFN can therefore be write-tracked in one address space and appear untracked through the other.
Check the supplied slot first, then the slot for the other address space. This ensures all callers honor write tracking regardless of the active address space. In particular, it prevents mmutrytounsyncpages() from marking an upper-level shadow page unsync and eventually triggering the BUG in ptelistremove().
[invert direction of the conditional. - Paolo]
In the Linux kernel, the following vulnerability has been resolved:
cgroup: Avoid iteration of dying tasks with zero refcount
The commit 260fbcb92bbea ("cgroup: Move dyingtasks cleanup from cgrouptaskrelease() to cgrouptaskfree()") extended the lifetime of tasks on the dyingtasks list. The iterators have provision to go through dyingtasks because of dying threadgroup leaders or explicit CSSTASKITERWITHDEAD, however, it was expected that such tasks can obtain a new reference (that is possible before cgrouptaskrelease()/puttaskstructrcuuser()). The tasks after cgrouptaskrelease() and before cgrouptaskfree() are subject to race when they may or may not have ->usage count > 0.
The race window is between csstaskiternext() invocations when csssetlock is released and we may arrive at a new ->taskpos. The iterator should not attempt to resurrect tasks whose ->usage count dropped to zero. (When that happens, puttaskstructrcucb() is already imminent and the returned taskstruct would could be used after free.)
As for the fix, we cannot simply check the signal->live count of a task on the dying list because that won't distinguish regular zombies waiting to be reaped from RCU remnant tasks that are going to be free'd. Therefore add an extra check to rule out ->usage==0 tasks from any iteration.
The repeat: loop in csstaskiteradvance() doesn't consider ->usage count, so add a new loop to csstaskiternext() to skip de-used tasks on the dyinglist.
Rough illustration of the possible race
R (reader of cgroup.procs) T (thread) L (group leader) --------------------------------- -------------------------------- -------------------------------- L exits, signal->live > 0 cgrouptaskdead(L) csssetskiptaskiters() // skips only cset->tasks listaddtail(&L->cglist, &cset->dyingtasks) csstaskiternext() take csssetlock csstaskiteradvance() leader && signal->live != 0 => it->taskpos = &L->cglist release csssetlock T exits --signal->live == 0 cgrouptaskdead(T) // csssetlock releasetask(T) cgrouptaskrelease(T) releasetask(L) // zapleader cgrouptaskrelease(L) puttaskstructrcuuser(L) ...RCU... puttaskstruct(L) L->usage = 0 / L still on dyingtasks / ...RCU... puttaskstruct(L) csstaskiternext() // another iteration take csssetlock it->taskpos = &L->cglist gettaskstruct(L) => addition on 0 drop csssetlock cgrouptaskfree(L) csssetskiptaskiters() // dying skip comes too late freetask(L) cgroupprocsshow() taskpidvnr(L)
In the Linux kernel, the following vulnerability has been resolved:
staging: rtl8723bs: fix mismatched free of HalData in rtwsdioif1init()
padapter->HalData is allocated via vzalloc(), but incorrectly freed using kfree() in the rtwsdioif1init() error path. Using kfree() to release this vmalloc-backed buffer can lead to memory corruption.
Use rtwhaldatadeinit() to pair the free correctly and free HalData with vfree().
The bug was first flagged by an experimental static analysis tool we are developing for kernel memory-management bugs. Manual inspection confirms that the issue is still present in current mainline.
An x8664 allyesconfig build showed no new warnings. As we do not have suitable RTL8723BS SDIO hardware to test with, no runtime testing was able to be performed.
In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mei: pass correct argument to function
The first argument to iwlmeiwritecyclicbuf() should be the cldev but the qhead pointer is passed instead. Fix it.
btrfs: fix transaction use-after-free in raid stripe insertion
In the Linux kernel, the following vulnerability has been resolved:
net: bcmasp: clear txcb->last before writing each descriptor
bcmaspxmit() only wrote txcb->last = true for the final fragment of an SKB; non-final fragments left the field untouched. If a descriptor slot was reused while it still held a stale true from a previous SKB (possible when txspbringfull() underreported fullness), bcmasptxreclaim() would see last == true mid-SKB and call devconsumeskbany() prematurely, freeing the skbuff while its remaining fragments were still in flight.
Unconditionally clear txcb->last before the conditional set so every descriptor slot starts from a known false state regardless of what a prior transmission left behind.
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrumptp: Fix napigroreceive() call from GC workqueue context
Currently mlxswsp1ptphtgccollect() is run from the PTP garbage-collection workqueue, rather than the NAPI poll context. For any unmatched PTP entries carrying an SKB, it calls mlxswsp1ptpunmatchedfinish() -> mlxswsp1ptppacketfinish(). For ingress packets, this calls mlxswsprxlistenernomarkfunc(). The end of that function is the following:
skb->protocol = ethtypetrans(skb, skb->dev); napigroreceive(mlxswskbcb(skb)->rxmdinfo.napi, skb);
The napi pointer is one that was placed in the SKB control block when the trapped packet was received in the NAPI context. Later, when the GC reaps the unmatched entry (up to MLXSWSP1PTPHTGCTIMEOUT later), the call to napigroreceive() mutates the NAPI instance's GRO list, which is unsafe if the poll is running concurrently on another CPU.
In mlxswsp1ptphtgccollect(), localbhdisable() is called to prevent softirq processing, but this only applies to the local CPU. Additionally, its comment is stale. It states that mlxswsp1ptpunmatchedfinish() invokes netifreceiveskb(). This has not been accurate since the referenced commit; this patch makes that comment accurate again. mlxswpcinapidevsinit() calls netifthreadedenable() on the NAPI RX netdevice without any conditions. The NAPI instance's poll, which may be running concurrent to the GC, is running as an independently-scheduled kthread which may be on a different CPU. The call to localbhdisable() does not guard against this.
If a tx-timestamp timeout produces an unmatched entry (which can be easily reproduced by running ptp4l and waiting for a port to reach the UNCALIBRATED/SLAVE state) while the owning NAPI thread is in the middle of a poll on another CPU, both sides mutate the GRO list concurrently, as shown below:
[39.846] port 1 (swp1): MASTER to UNCALIBRATED on RSSLAVE listadd corruption. next->prev should be prev (ffff8d620faf4138), but was ffff8d624150f700. (next=ffff8d620faf4138). kernel BUG at lib/listdebug.c:29! Oops: invalid opcode: 0000 [#1] SMP PTI CPU: 1 UID: 0 PID: 539 Comm: napi/mlxswrx-0 Not tainted 6.18.48 #1-NixOS PREEMPT(lazy) Hardware name: Mellanox Technologies Ltd. MSN2410/VMOD0001, BIOS 4.6.5 09/13/2018 RIP: 0010:listaddvalidorreport+0x79/0xb0 RSP: 0018:ffffcdf8c0f27c08 EFLAGS: 00010246 RAX: 0000000000000075 RBX: ffff8d624150fd00 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8d6315d1e540 RBP: ffff8d620faf4070 R08: 0000000000000000 R09: 00000000ffffdfff R10: ffffffffa5c60fe0 R11: ffffcdf8c0f27ab8 R12: 0000000000000003 R13: 000000000000003d R14: 00000000000001bc R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8d636f63f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000562689a60c24 CR3: 000000015f224004 CR4: 00000000001726f0 Call Trace: <TASK> groreceiveskb+0xee/0x230 mlxswsp1ptpgotpacket+0x61/0x140 [mlxswspectrum] mlxswcoreskbreceive+0xdf/0x1b0 [mlxswcore] mlxswpcinapipollcqrx+0x780/0x9d0 [mlxswpci] napipoll+0x31/0x1e0 napithreadedpollloop+0x16b/0x1c0 napithreadedpoll+0x71/0xa0 kthread+0xfb/0x260 retfromfork+0x22d/0x260 retfromforkasm+0x1a/0x30 </TASK> Kernel panic - not syncing: Fatal exception in interrupt
The machinery that leads to this kernel panic has not been changed between 6.18.48 and mainline.
This patch adds an ingress-delivery helper for the PTP packetfinish() path that calls netifreceiveskb() instead of napigroreceive(). netifreceiveskb(), unlike napigroreceive(), can be called from outside of the NAPI instance's poll context, which can occur at the call site for this path. RX stats accounting and the skb->dev assignment are still preserved; the only change is the delivery call itself.
This removes GR ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
usb: misc: usbio: fix disconnect UAF in client teardown
usbiodisconnect() walks usbio->clilist in reverse and uninitializes each auxiliary device. auxiliarydeviceuninit() drops the device reference, and for an unbound child that can run usbioauxdevrelease() and free the containing struct usbioclient.
listforeachentryreverse() advances after the loop body by reading client->link.prev. If the current client is freed by auxiliarydeviceuninit(), the iterator dereferences freed memory.
Use listforeachentrysafereverse() so the previous client is cached before the body can drop the final reference. This preserves reverse teardown order while keeping the next iterator cursor independent of the current client's lifetime.
Validation reproduced this kernel report: BUG: KASAN: slab-use-after-free in usbiodisconnect+0x12e/0x150
Call Trace: <TASK> dumpstacklvl+0x66/0xa0 printreport+0xce/0x630 ? usbiodisconnect+0x12e/0x150 ? srsoaliasreturnthunk+0x5/0xfbef5 ? virtaddrvalid+0x188/0x320 ? usbiodisconnect+0x12e/0x150 kasanreport+0xe0/0x110 ? usbiodisconnect+0x12e/0x150 usbiodisconnect+0x12e/0x150 usbunbindinterface+0xf3/0x400 reallyprobe+0x316/0x660 driverprobedevice+0x106/0x240 driverprobedevice+0x4a/0x110 deviceattachdriver+0xf1/0x1a0 ? pfxdeviceattachdriver+0x10/0x10 busforeachdrv+0xf9/0x160 ? pfxbusforeachdrv+0x10/0x10 ? srsoaliasreturnthunk+0x5/0xfbef5 ? tracehardirqson+0x18/0x130 ? srsoaliasreturnthunk+0x5/0xfbef5 ? rawspinunlockirqrestore+0x44/0x60 deviceattach+0x133/0x2a0 ? pfxdeviceattach+0x10/0x10 ? srsoaliasreturnthunk+0x5/0xfbef5 ? dorawspinunlock+0x9a/0x100 ? srsoaliasreturnthunk+0x5/0xfbef5 deviceinitialprobe+0x55/0x70 busprobedevice+0x4a/0xd0 deviceadd+0x9b9/0xc10 ? pfxdeviceadd+0x10/0x10 ? rawspinunlockirqrestore+0x44/0x60 ? srsoaliasreturnthunk+0x5/0xfbef5 ? lockdephardirqsonprepare+0xea/0x1a0 ? srsoaliasreturnthunk+0x5/0xfbef5 ? usbenablelpm+0x3c/0x260 usbsetconfiguration+0xb64/0xf20 usbgenericdriverprobe+0x5f/0x90 usbprobedevice+0x71/0x1b0 reallyprobe+0x46b/0x660 driverprobedevice+0x106/0x240 driverprobedevice+0x4a/0x110 deviceattachdriver+0xf1/0x1a0 ? pfxdeviceattachdriver+0x10/0x10 busforeachdrv+0xf9/0x160 ? pfxbusforeachdrv+0x10/0x10 ? srsoaliasreturnthunk+0x5/0xfbef5 ? tracehardirqson+0x18/0x130 ? srsoaliasreturnthunk+0x5/0xfbef5 ? rawspinunlockirqrestore+0x44/0x60 deviceattach+0x133/0x2a0 ? pfxdeviceattach+0x10/0x10 ? srsoaliasreturnthunk+0x5/0xfbef5 ? dorawspinunlock+0x9a/0x100 ? srsoaliasreturnthunk+0x5/0xfbef5 deviceinitialprobe+0x55/0x70 busprobedevice+0x4a/0xd0 deviceadd+0x9b9/0xc10 ? pfxdeviceadd+0x10/0x10 ? srsoaliasreturnthunk+0x5/0xfbef5 ? adddevicerandomness+0xb7/0xf0 usbnewdevice+0x492/0x870 hubevent+0x1b10/0x29c0 ? pfxhubevent+0x10/0x10 ? srsoaliasreturnthunk+0x5/0xfbef5 ? lockacquire+0x187/0x300 ? processonework+0x475/0xb90 ? srsoaliasreturnthunk+0x5/0xfbef5 ? lockrelease+0xc8/0x290 ? srsoaliasreturnthunk+0x5/0xfbef5 processonework+0x4d7/0xb90 ? pfxprocessonework+0x10/0x10 ? srsoaliasreturnthunk+0x5/0xfbef5 ? srsoaliasreturnthunk+0x5/0xfbef5 ? listaddvalidorreport+0x37/0xf0 ? pfxhubevent+0x10/0x10 ? srsoaliasreturnthunk+0x5/0xfbef5 workerthread+0x2d8/0x570 ? pfxworkerthread+0x10/0x10 kthread+0x1ad/0x1f0 ? pfxkthread+0x10/0x10 retfromfork+0x3c9/0x540 ? pfxretfromfork+0x10/0x10 ? srsoaliasreturnthunk+0x5/0xfbef5 ? switchto+0x2e9/0x730 ? pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK>
6lowpan: fix NHC entry use-after-free on error path
In the Linux kernel, the following vulnerability has been resolved:
staging: vmeuser: bound slave read/write to the kernbuf size
The SLAVE-path helpers buffertouser() and bufferfromuser() copy 'count' bytes into/out of the fixed-size kernbuf (sizebuf == PCIBUFSIZE == 0x20000, 128 KiB) using ppos as the offset, without bounding ppos + count against sizebuf.
vmeuserwrite()/vmeuserread() only clamp count to the VME window size (imagesize = vmegetsize(resource)), which VMESETSLAVE sets from the user-supplied slave.size -- validated against the VME address space (up to VMEA32MAX = 4 GiB), not against PCIBUFSIZE. When the window exceeds 128 KiB, a write()/read() copies past the kernbuf allocation.
Clamp count against sizebuf in both helpers, with an early return when ppos is already at/after the buffer end. ppos is >= 0 here (the caller rejects negative offsets), so sizebuf - ppos cannot wrap. This mirrors the existing clamp in the MASTER-path helpers resourcetouser() / resourcefromuser(), and matches the read()/write() convention of a short transfer at end-of-buffer.
Found by static analysis (CodeQL taint tracking + CBMC bounded model checking) and confirmed dynamically under KASAN with the vmefake bridge:
BUG: KASAN: slab-out-of-bounds in copyfromuser+0x2d/0x80 Write of size 262144 at addr ffff888004100000 by task trigger/68 copyfromuser+0x2d/0x80 vmeuserwrite+0x13e/0x240 [vmeuser] vfswrite+0x1b8/0x7a0 ksyswrite+0xb8/0x150
In the Linux kernel, the following vulnerability has been resolved:
staging: media: ipu7: fix double-free and use-after-free in error paths
In both ipu7isysinit() and ipu7psysinit(), pdata is allocated and then passed to ipu7businitializedevice(), which stores it in adev->pdata. The ipu7busrelease() function frees adev->pdata when the device's reference count drops to zero.
Two error paths incorrectly call kfree(pdata) after the device teardown has already freed it:
1. When ipu7mmuinit() fails: putdevice() is called, which drops the reference count to zero and triggers ipu7busrelease() -> kfree(pdata). The subsequent kfree(pdata) is a double-free.
2. When ipu7busadddevice() fails: it calls auxiliarydeviceuninit() internally, which calls putdevice() -> ipu7busrelease() -> kfree(pdata). The subsequent kfree(pdata) is again a double-free.
Note that the kfree(pdata) when ipu7businitializedevice() itself fails is correct, because in that case auxiliarydeviceinit() failed and the release function was never set up, so pdata must be freed manually.
Additionally, the error code was not saved before calling putdevice(), causing ERRCAST() to dereference the already-freed adev pointer when constructing the return value. Fix this by saving the error from deverrprobe() before putdevice() and returning ERRPTR() instead.
Remove the redundant kfree(pdata) calls and fix the use-after-free in the return values of the two affected error paths.
In the Linux kernel, the following vulnerability has been resolved:
smb: client: restrict implied bcc[0] exemption to responses without data area
smb2checkmessage() has a long-standing quirk that accepts a response whose calculated length is one byte larger than the bytes actually received ("server can return one byte more due to implied bcc[0]"). This was introduced to accommodate servers that omit the trailing bcc[0] overlap byte when no data area is present.
However, the exemption is applied unconditionally, regardless of whether the command actually carries a data area (hassmb2dataarea[]). When a response with a data area is subject to the +1 exemption, the reported data can extend one byte beyond the bytes actually received, yet smb2checkmessage() still accepts it. The subsequent decoder then reads past the end of the receive buffer. This is reachable during NEGOTIATE and SESSIONSETUP, before the session is established.
The resulting out-of-bounds reads are visible under KASAN when mounting against a non-conforming server; both the SPNEGO/negTokenInit and the NTLMSSP challenge decoders are affected:
BUG: KASAN: slab-out-of-bounds in asn1berdecoder+0x16a7/0x1b00 Read of size 1 at addr ffff8880084d67c0 by task mount.cifs/81 CPU: 1 UID: 0 PID: 81 Comm: mount.cifs Not tainted 7.1.0-rc6 #1 Call Trace: <TASK> dumpstacklvl+0x4e/0x70 printreport+0x157/0x4c9 kasanreport+0xce/0x100 asn1berdecoder+0x16a7/0x1b00 decodenegTokenInit+0x19/0x30 SMB2negotiate+0x31d9/0x4c90 cifsnegotiateprotocol+0x1f2/0x3f0 cifsgetsmbses+0x93f/0x17e0 cifsmountgetsession+0x7f/0x3a0 cifsmount+0xb4/0xcf0 cifssmb3domount+0x23a/0x1500 smb3gettree+0x3b0/0x630 vfsgettree+0x82/0x2d0 fcmount+0x10/0x1b0 pathmount+0x50d/0x1de0 x64sysmount+0x20b/0x270 dosyscall64+0xee/0x590 entrySYSCALL64afterhwframe+0x77/0x7f </TASK> Allocated by task 85: kmemcacheallocnoprof+0x106/0x380 mempoolallocnoprof+0x116/0x1e0 cifssmallbufget+0x31/0x80 allocatebuffers+0x10d/0x2b0 cifsdemultiplexthread+0x1d5/0x1d50 kthread+0x2c6/0x390 retfromfork+0x36e/0x5a0 retfromforkasm+0x1a/0x30 The buggy address is located 0 bytes to the right of allocated 448-byte region [ffff8880084d6600, ffff8880084d67c0) which belongs to the cache cifssmallrq of size 448
BUG: KASAN: slab-out-of-bounds in kmemdupnoprof+0x36/0x50 Read of size 329 at addr ffff88800726c678 by task mount.cifs/89 CPU: 0 UID: 0 PID: 89 Comm: mount.cifs Tainted: G B 7.1.0-rc6 #1 Call Trace: <TASK> dumpstacklvl+0x4e/0x70 printreport+0x157/0x4c9 kasanreport+0xce/0x100 kasancheckrange+0x10f/0x1e0 asanmemcpy+0x23/0x60 kmemdupnoprof+0x36/0x50 decodentlmsspchallenge+0x457/0x680 SMB2sessauthrawntlmsspnegotiate+0x6f0/0xcb0 SMB2sesssetup+0x219/0x4f0 cifssetupsession+0x248/0xaf0 cifsgetsmbses+0xf79/0x17e0 cifsmountgetsession+0x7f/0x3a0 cifsmount+0xb4/0xcf0 cifssmb3domount+0x23a/0x1500 smb3gettree+0x3b0/0x630 vfsgettree+0x82/0x2d0 fcmount+0x10/0x1b0 pathmount+0x50d/0x1de0 x64sysmount+0x20b/0x270 dosyscall64+0xee/0x590 entrySYSCALL64afterhwframe+0x77/0x7f </TASK> Allocated by task 93: kmemcacheallocnoprof+0x106/0x380 mempoolallocnoprof+0x116/0x1e0 cifssmallbufget+0x31/0x80 allocatebuffers+0x10d/0x2b0 cifsdemultiplexthread+0x1d5/0x1d50 kthread+0x2c6/0x390 retfromfork+0x36e/0x5a0 retfromforkasm+0x1a/0x30 The buggy address is located 120 bytes inside of allocated 448-byte region [ffff88800726c600, ffff88800726c7c0) which belongs to the cache cifssmallrq of size 448
Restrict the +1 exemption to responses that have no data area, so that it still covers the bcc[0] omission it was meant for. When a data area is present, the +1 discrepancy instead means the reported data length overruns the ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
staging: rtl8723bs: fix heap buffer overflow in rtwcfg80211setwpaie()
supplicantie is a 256-byte array in struct securitypriv. The WPA and WPA2 IE copy paths use:
memcpy(padapter->securitypriv.supplicantie, &pwpa[0], wpaielen + 2);
where wpaielen is the raw IE length field (u8, 0-255). When a local user supplies a connect request via nl80211 with a crafted WPA IE of length 255, wpaielen + 2 equals 257, overflowing the 256-byte buffer by one byte into the adjacent lastmicerrtime field.
rtwparsewpaie() does not prevent this: its length consistency check compares (wpaie+1) against (u8)(wpaielen-2), which is (u8)(255) == 255 when wpaielen = 257, so the check passes silently.
Add explicit bounds checks for both the WPA and WPA2 paths before the memcpy, rejecting any IE whose total size (wpaielen + 2) exceeds the supplicantie buffer.
In the Linux kernel, the following vulnerability has been resolved:
staging: rtl8723bs: fix WEP length underflow and OOB read in OnAuth()
OnAuth() has two bugs in the shared-key authentication path.
When the Privacy bit is set, rtwwepdecrypt() is called without verifying that the frame is long enough to contain a valid WEP IV and ICV. Inside rtwwepdecrypt(), length is computed as:
length = len - WLANHDRA3LEN - ivlen
and then passed as (length - 4) to crc32le(). If len is less than WLANHDRA3LEN + ivlen + icvlen (32 bytes), length - 4 is negative and, after the implicit cast to sizet, causes crc32le() to read far beyond the frame buffer. Add a minimum length check before accessing the IV field and calling the decryption path.
When processing a seq=3 response, rtwgetie() stores the Challenge Text IE length in ielen, but the subsequent memcmp() always reads 128 bytes regardless of ielen. IEEE 802.11 mandates a challenge text of exactly 128 bytes; reject any IE whose length field differs, matching the check already applied to OnAuthClient().
In the Linux kernel, the following vulnerability has been resolved:
staging: rtl8723bs: fix OOB read in OnAssocRsp() IE loop
The IE parsing loop in OnAssocRsp() advances by (pIE->length + 2) each iteration but only guards on i < pktlen. When a malicious AP sends an AssocResponse whose last IE has only one byte remaining in the frame (the elementid byte lands at pktlen-1), the loop reads pIE->length from pframe[pktlen], which is one byte past the allocated receive buffer.
Additionally, even when the header bytes are in bounds, pIE->length itself can extend the data window beyond pktlen, silently passing a truncated IE to the handler functions.
Add two guards at the top of the loop body: 1. Break if fewer than sizeof(pIE) bytes remain (can't read header). 2. Break if the IE's declared data extends past pktlen.
In the Linux kernel, the following vulnerability has been resolved:
staging: rtl8723bs: fix OOB read in updatebeaconinfo() IE loop
The IE parsing loop in updatebeaconinfo() advances by (pIE->length + 2) each iteration but only guards on i < len. When a malicious AP sends a Beacon whose last IE has only one byte remaining in the frame (the elementid byte lands at len-1), the loop reads pIE->length from one byte past the allocated receive buffer.
Additionally, even when the header bytes are in bounds, pIE->length itself can extend the data window beyond len, passing a truncated IE to the handler functions.
Add two guards at the top of the loop body: 1. Break if fewer than sizeof(pIE) bytes remain (can't read header). 2. Break if the IE's declared data extends past len.
Also replace i += (pIE->length + 2) with i += sizeof(pIE) + pIE->length for consistency with the sizeof(pIE) guards added above.
In the Linux kernel, the following vulnerability has been resolved:
staging: rtl8723bs: fix OOB reads in IE loops in issueassocreq() and joincmdhdl()
Two IE parsing loops are missing the header bounds checks before they dereference pIE->length:
- issueassocreq() walks pmlmeinfo->network.ies to build the association request. If the stored IE data ends with only an elementid byte and no length byte, pIE->length is read one byte past the end of the buffer.
- joincmdhdl() walks pnetwork->ies during station join and has the same problem under the same conditions.
Both buffers are filled from AP beacon and probe-response frames, so a malicious AP that sends a truncated final IE can trigger the issue.
Apply the two-guard pattern established in updatebeaconinfo(): 1. Break if fewer than sizeof(pIE) bytes remain. 2. Break if the IE's declared data extends past the buffer end.
In the Linux kernel, the following vulnerability has been resolved:
staging: rtl8723bs: fix OOB write in HTcapshandler()
HTcapshandler() iterates pIE->length bytes and writes into HTcaps.u.HTcap[], which is a fixed 26-byte array (sizeof struct HTcapselement). Because pIE->length is a raw u8 from an over-the-air 802.11 AssocResponse frame and is never validated, a malicious AP can set it up to 255, causing up to 229 bytes of out-of-bounds writes into adjacent fields of struct mlmeextinfo.
Truncate the iteration count to the size of HTcaps.u.HTcap using umin() so that data from a longer-than-expected IE is silently ignored rather than written out of bounds, preserving interoperability with APs that pad the element. An early return on oversized IEs was considered but rejected: it would bypass the pmlmeinfo->HTcapsenable = 1 assignment that precedes the loop, silently disabling HT mode for APs that append extra bytes to the HT Capabilities IE.
In the Linux kernel, the following vulnerability has been resolved:
staging: rtl8723bs: fix OOB reads in rtwgetsecie(), rtwgetwapiie(), and rtwgetwpsattr()
Three IE/attribute parsing functions have missing bounds checks.
rtwgetsecie() and rtwgetwapiie() iterate over a raw IE buffer without verifying that the header bytes (tag + length) are within the remaining buffer before reading them. Additionally, rtwgetsecie() compares the 4-byte WPA OUI at cnt+2 without checking that at least 6 bytes remain, and rtwgetwapiie() compares a 4-byte WAPI OUI at cnt+6 without checking that at least 10 bytes remain.
rtwgetwpsattr() reads wpsie[0] and wpsie+2 unconditionally at entry, before verifying that wpsielen is large enough to contain the 6-byte WPS IE header (elementid + length + 4-byte OUI). Inside the attribute loop, getunalignedbe16() is called on attrptr and attrptr+2 without checking that 4 bytes remain in the buffer.
Add a cnt+2 bounds check before each loop body in rtwgetsecie() and rtwgetwapiie(), guard each multi-byte comparison with a minimum IE length requirement, add a wpsielen < 6 early return in rtwgetwpsattr(), and add a 4-byte bounds check in its inner loop.
In the Linux kernel, the following vulnerability has been resolved:
crypto: qat - fix VF2PF work teardown race in adfdisablesriov()
The VF2PF interrupt handler queues PF-side response work that stores a raw pointer to per-VF state (struct adfaccelvfinfo). Currently, adfdisablesriov() destroys per-VF mutexes and frees vfinfo without stopping new VF2PF work or waiting for in-flight workers to complete. A concurrently scheduled or already queued worker can then dereference freed memory.
This manifests as a use-after-free when KASAN is enabled:
BUG: KASAN: null-ptr-deref in mutexlock+0x76/0xe0 Write of size 8 at addr 0000000000000260 by task kworker/24:2/... Workqueue: qatpf2vfrespwq adfiovsendresp [intelqat] Call Trace: kasanreport+0x119/0x140 mutexlock+0x76/0xe0 adfgen4pfvfsend+0xd4/0x1f0 [intelqat] adfrecvandhandlevf2pfmsg+0x290/0x360 [intelqat] adfiovsendresp+0x8c/0xe0 [intelqat] processonework+0x6ac/0xfd0 workerthread+0x4dd/0xd30 kthread+0x326/0x410 retfromfork+0x33b/0x670
Add a PF-local flag, vf2pfdisabled, that gates work queueing, worker processing, and interrupt re-enabling during teardown. Set this flag atomically with the hardware interrupt mask inside adfdisableallvf2pfinterrupts(). After masking, synchronize the AE cluster MSI-X interrupt and flush the PF response workqueue before tearing down per-VF locks and state so all in-flight work completes before vfinfo is destroyed.
Introduce adfenableallvf2pfinterrupts() to clear the flag and unmask all VF2PF interrupts under the same lock when SR-IOV is re-enabled. This ensures the software flag and hardware state transition atomically on both the enable and disable paths.
In the Linux kernel, the following vulnerability has been resolved:
net: afkey: initialize algkeylen for IPComp states
pfkeymsg2xfrmstate() handles the IPComp (SADBXSATYPEIPCOMP) case by allocating x->calg and copying only the algorithm name:
x->calg = kmallocobj(x->calg); if (!x->calg) { err = -ENOMEM; goto out; } strcpy(x->calg->algname, a->name); x->props.calgo = sa->sadbsaencrypt;
Unlike the authentication (x->aalg) and encryption (x->ealg) branches of the same function, the compression branch never initializes calg->algkeylen. IPComp carries no key and the allocation only reserves sizeof(struct xfrmalgo) (i.e. no room for a key), so the field is left containing uninitialized slab data.
calg->algkeylen is later used as a length by xfrmalgoclone() when an IPComp state is cloned during XFRMMSGMIGRATE:
xfrmstatemigrate() xfrmstatecloneandsetup() x->calg = xfrmalgoclone(orig->calg); kmemdup(orig, xfrmalglen(orig));
where xfrmalglen() returns sizeof(alg) + (algkeylen + 7) / 8. With a non-zero garbage algkeylen, kmemdup() reads past the end of the 68-byte calg object. Adding an IPComp SA via PFKEY and then migrating it triggers (net-next, KASAN, initonalloc=0):
BUG: KASAN: slab-out-of-bounds in kmemdupnoprof+0x44/0x60 Read of size 4164 at addr ff11000025a74980 by task diag2/9287 CPU: 3 UID: 0 PID: 9287 Comm: diag2 7.1.0-rc6-g903db046d557 #1 Call Trace: <TASK> dumpstacklvl+0x10e/0x1f0 printreport+0xf7/0x600 kasanreport+0xe4/0x120 kasancheckrange+0x105/0x1b0 asanmemcpy+0x23/0x60 kmemdupnoprof+0x44/0x60 xfrmstatemigrate+0x70a/0x1da0 xfrmmigrate+0x753/0x18a0 xfrmdomigrate+0xb47/0xf10 xfrmuserrcvmsg+0x411/0xb50 netlinkrcvskb+0x158/0x420 xfrmnetlinkrcv+0x71/0x90 netlinkunicast+0x584/0x850 netlinksendmsg+0x8b0/0xdc0 syssendmsg+0x9f7/0xb90 syssendmsg+0x134/0x1d0 syssendmsg+0x16d/0x220 dosyscall64+0x116/0x7d0 entrySYSCALL64afterhwframe+0x77/0x7f </TASK>
Allocated by task 9287: kasansavestack+0x33/0x60 kasansavetrack+0x14/0x30 kasankmalloc+0xaa/0xb0 pfkeyadd+0x2652/0x2ea0 pfkeyprocess+0x6d0/0x830 pfkeysendmsg+0x42c/0x850 syssendto+0x461/0x4b0 x64syssendto+0xe0/0x1c0 dosyscall64+0x116/0x7d0 entrySYSCALL64afterhwframe+0x77/0x7f
The buggy address belongs to the object at ff11000025a74980 which belongs to the cache kmalloc-96 of size 96 The buggy address is located 0 bytes inside of allocated 68-byte region [ff11000025a74980, ff11000025a749c4)
Depending on the uninitialized value the same field can instead request an oversized kmemdup() allocation and make the migration clone fail.
The XFRM netlink path is not affected: verifyonealg() rejects an XFRMAALGCOMP attribute shorter than xfrmalglen(), so a calg added via XFRMMSGNEWSA is always self-consistent.
Initialize calg->algkeylen to 0, matching the aalg/ealg branches.
audit: Fix data races of skbqueuelen() readers on auditqueue
Bluetooth: MGMT: Fix UAF of hciconnparams in adddevicecomplete
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: validate Dirty Page Table capacity in logreplay copylcns
In the analysis pass of $LogFile journal replay, logreplay() copies LCNs from each action log record into an existing Dirty Page Table (DPT) entry without bounding the destination index. A crafted NTFS image with DPT entry lcnsfollow=1 and an action log record with lcnsfollow=2 produces a kernel slab out-of-bounds write at mount time:
BUG: KASAN: slab-out-of-bounds in logreplay+0x654c/0xdb60 Write of size 8 at addr ffff8880095e1040 by task mount
Two attacker-controlled fields can drive j+i past the allocated pagelcns[] array:
1. dp->lcnsfollow (capacity) can be smaller than lrh->lcnsfollow. 2. lrh->targetvcn may be smaller than dp->vcn, making the u64 subtraction wrap to a huge sizet.
Validate target VCN delta and per-record LCN count against the DPT entry capacity, bail via the existing out: cleanup label with -EINVAL.
This mirrors the bounds-check pattern added in commit b2bc7c44ed17 ("fs/ntfs3: Fix slab-out-of-bounds read in DeleteIndexEntryRoot") and commit 0ca0485e4b2e ("fs/ntfs3: validate rec->used in journal-replay file record check").
In the Linux kernel, the following vulnerability has been resolved:
NTB: epf: Avoid calling pciirqvector() from hardirq context
ntbepfvecisr() calls pciirqvector() in hardirq context to derive the vector number. pciirqvector() calls msigetvirq() that takes a mutex and can therefore trigger "scheduling while atomic" splats:
BUG: scheduling while atomic: kworker/u33:0/55/0x00010001 ... Call trace: ... schedule+0x38/0x110 schedulepreemptdisabled+0x28/0x50 mutexlock.constprop.0+0x848/0x908 mutexlockslowpath+0x18/0x30 mutexlock+0x4c/0x60 msidomaingetvirq+0xe8/0x138 pciirqvector+0x2c/0x60 ntbepfvecisr+0x28/0x120 [ntbhwepf] handleirqeventpercpu+0x70/0x3a8 handleirqevent+0x48/0x100 handleedgeirq+0x100/0x1c8 ...
Cache the Linux IRQ number for vector 0 when vectors are allocated and use it as a base in the ISR. Running the ISR in a threaded IRQ handler would also avoid the problem, but that would be unnecessary here.
gpio: sch: use rawspinlockt in the irq startup path
In the Linux kernel, the following vulnerability has been resolved:
netpoll: fix a use-after-free on shutdown path
There is a use-after-free error on netpoll, which is clearly detected by KASAN.
BUG: KASAN: slab-use-after-free in rawspinlockirqsave+0x3b/0x80 Read of size 1 at addr ... by task kworker/9:1 Workqueue: events queueprocess Call Trace: skbdequeue+0x1e/0xb0 queueprocess+0x2c/0x600 processscheduledworks+0x4b6/0x850 workerthread+0x414/0x5a0 Allocated by task 242: netpollsetup+0x201/0x4a0 netpollsetup+0x249/0x550 enabledstore+0x32f/0x380 Freed by task 0: kfree+0x1b7/0x540 rcucore+0x3f8/0x7a0
The problem happens when there is a pending TX worker running in parallel with the cleanup path.
This is what happens on netpoll shutdown path:
1) netpollcleanup() is called 2) set dev->npinfo to NULL 3) callrcu() with rcucleanupnetpollinfo() 3.1) rcucleanupnetpollinfo() tries to cancel all workers with canceldelayedwork(), but doesn't wait for the worker to finish 4) and kfree(npinfo);
Because 3.1) doesn't really cancel the work, as the comment says "we can't call canceldelayedworksync here, as we are in softirq", the TX worker can run after 4).
Tl;DR: queueprocess() is not an RCU reader, it reaches npinfo through the work item via containerof().
Use disabledelayedworksync() to ensure the worker is completely stopped and prevent any future re-arming attempts. Once npinfo is set to NULL, senders will bail out and not queue new work. The disable flag ensures any in-flight re-arming attempts also fail silently.
In the future, we can do the cleanup inline here without needing the npinfo->rcu rcuhead, but that is net-next material.
In the Linux kernel, the following vulnerability has been resolved:
ipv4: igmp: remove multicast group from hash table on device destruction
When a device is destroyed under RTNL, ipmcdestroydev() iterates through the multicast list and calls ipmaput() on each membership, scheduling them for RCU reclamation. However, they are not unlinked from the device's multicast hash table (mchash).
Since the device remains published in dev->ipptr until after ipmcdestroydev() completes, concurrent RCU readers traversing mchash can still locate and access the multicast group after its refcount is decremented. If the RCU callback runs and frees the group while a reader is accessing it, a use-after-free occurs.
Fix this by unlinking the multicast group from mchash using ipmchashremove() before scheduling it for reclamation.
BUG: KASAN: slab-use-after-free in ipcheckmcrcu+0x149/0x3f0 Read of size 4 at addr ffff888009bf1408 by task mausezahn/2276
Call Trace: <IRQ> dumpstacklvl+0x67/0x90 printreport+0x175/0x7c0 kasanreport+0x147/0x180 ipcheckmcrcu+0x149/0x3f0 udpv4earlydemux+0x36d/0x12d0 iprcvfinishcore+0xb8b/0x1390 iprcvfinish+0x54/0x120 NFHOOK+0x213/0x2b0 netifreceiveskb+0x126/0x340 processbacklog+0x4f2/0xf00 napipoll+0x92/0x2c0 netrxaction+0x583/0xc60 handlesoftirqs+0x236/0x7f0 dosoftirq+0x57/0x80 </IRQ>
Allocated by task 2239: kasansavetrack+0x3e/0x80 kasankmalloc+0x72/0x90 ipmcincgroup+0x31a/0xa40 ipmcjoingroup+0x334/0x3f0 doipsetsockopt+0x16fa/0x2010 ipsetsockopt+0x3f/0x90 dosocksetsockopt+0x1ad/0x300
Freed by task 0: kasansavetrack+0x3e/0x80 kasansavefreeinfo+0x40/0x50 kasanslabfree+0x3a/0x60 rcufreesheafprepare+0xd4/0x220 rcufreesheaf+0x36/0x190 rcucore+0x8d9/0x12f0 handlesoftirqs+0x236/0x7f0
In the Linux kernel, the following vulnerability has been resolved:
net: ipv4: bound TCP reordering sysctl writes and MTU probe sizes
Reject invalid net.ipv4.tcpreordering values before they reach TCP socket state. The sysctl is stored as an int but copied into the u32 tp->reordering field for new sockets, so negative writes wrap to large values.
With tcpmtuprobing=2, the wrapped value can overflow the tcpmtuprobe() size calculation and drive the MTU probing path into an out-of-bounds read. Route tcpreordering writes through procdointvecminmax() and require it to be at least 1. Also require tcpmaxreordering to be at least 1 so the configured maximum cannot become negative either.
When registering the table for a non-init network namespace, relocate extra2 pointers that refer into initnet.ipv4 so the tcpreordering upper bound follows that namespace's tcpmaxreordering.
Harden tcpmtuprobe() itself by computing sizeneeded as u64. This keeps the send queue and window checks from being bypassed through signed integer overflow.
In the Linux kernel, the following vulnerability has been resolved:
mfd: crosec: Delay devsetdrvdata() until probe success
If ecdeviceprobe() fails, crosecclassrelease releases memory for the crosecdev structure. However, because the drvdata was already set, sub-drivers like crosectypec can still retrieve the stale pointer via the platform device. This leads to a use-after-free when crosectypec attempts to access &typec->ec->ec->dev on a device that has already been released. Move devsetdrvdata() to ensure that the pointer is only made available once all initialization steps have succeeded.
sysfs: cannot create duplicate filename '/class/chromeos/crosec' Call trace: sysfsdocreatelinksd+0x94/0xdc sysfscreatelink+0x30/0x44 deviceaddclasssymlinks+0x90/0x13c deviceadd+0xf0/0x50c ecdeviceprobe+0x150/0x4f0 platformprobe+0xa0/0xe0 ... BUG: KASAN: invalid-access in memcpy+0x44/0x230 Write at addr f5ffff809e2d33ac by task kworker/u32:5/125 Pointer tag: [f5], memory tag: [fe] Tainted : [W]=WARN, [O]=OOTMODULE Hardware name: Google Navi unprovisioned 0x7FFFFFFF/sku0 board/sku3 Workqueue: eventsunbound deferredprobeworkfunc Call trace: memcpy+0x44/0x230 croseccheckfeatures+0x60/0xcc [crosecproto] crostypecprobe+0xe8/0x6e0 [crosectypec] platformprobe+0xa0/0xe0