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:
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.
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:
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
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:
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
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ebtables: zero chainstack array
sashiko reports: looking at ebtables table translation, could a sparse cpupossiblemask lead to an uninitialized pointer free?
If cpupossiblemask is sparse (for example, CPU 0 and CPU 2 are possible, but CPU 1 is not), the allocation loop skips CPU 1. If vmallocnode() fails at CPU 2, the cleanup loop will blindly decrement and call vfree() on newinfo->chainstack[1].
Not a real-world bug, such allocation isn't expected to fail in the first place.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ebtables: module names must be null-terminated
We need to explicitly check the length, else we may pass non-null terminated string to requestmodule().
In the Linux kernel, the following vulnerability has been resolved:
netfilter: ebtables: terminate table name before findtablelock()
updatecounters() and compatupdatecounters() forward a user-supplied 32-byte table name to findtablelock() without NUL-terminating it. On a lookup miss, findinlistlock() calls trythenrequestmodule(..., "%s%s", "ebtable", name), and vsnprintf() reads past the name field and the stack object until it hits a zero byte.
BUG: KASAN: stack-out-of-bounds in string (lib/vsprintf.c:648 lib/vsprintf.c:730) Read of size 1 at addr ffff8880119dfb20 by task exploit/147 Call Trace: ... string (lib/vsprintf.c:648 lib/vsprintf.c:730) vsnprintf (lib/vsprintf.c:2945) requestmodule (kernel/module/kmod.c:150) doupdatecounters.isra.0 (net/bridge/netfilter/ebtables.c:371 net/bridge/netfilter/ebtables.c:380) updatecounters (net/bridge/netfilter/ebtables.c:1440) doebtsetctl (net/bridge/netfilter/ebtables.c:2573) nfsetsockopt (net/netfilter/nfsockopt.c:101) ipsetsockopt (net/ipv4/ipsockglue.c:1424) rawsetsockopt (net/ipv4/raw.c:847) syssetsockopt (net/socket.c:2393) ...
compatdoreplace() shares the same unterminated name via compatcopyebtreplacefromuser(); terminate it there too so all findtablelock() callers behave alike. The other callers already terminate the name after the copy.
Bluetooth: bnep: pin L2CAP connection during netdev registration
Bluetooth: L2CAP: validate option length before reading conf opt value
In the Linux kernel, the following vulnerability has been resolved:
smb: client: resolve SWN tcon from live registrations
cifsswnnotify() looks up a witness registration by id under cifsswnregidrmutex, drops the mutex, and then uses the registration's cached tcon pointer. That pointer is not a lifetime reference, and it is not a stable representative once cifsgetswnreg() lets multiple tcons for the same net/share name share one registration id.
A same-share second mount can keep the cifsswnreg alive after the first tcon unregisters and is freed. The registration then still points at the freed first tcon, so taking tclock or incrementing tccount through swnreg->tcon only moves the use-after-free earlier. Taking tclock while holding cifsswnregidrmutex also violates the documented CIFS lock order.
Fix this by making the registration store only the stable witness identity: id, net name, share name, and notify flags. When a notify arrives, copy that identity under cifsswnregidrmutex, drop the mutex, then find and pin a live witness tcon that currently matches the net/share pair under the normal cifstcpseslock -> tclock order. The notification path uses that pinned tcon directly and drops the reference when done.
Registration and unregister messages now use the live tcon passed by the caller instead of a cached tcon in the registration. The final unregister send is folded into cifsswnunregister() while the registration is still protected by cifsswnregidrmutex. This removes the previous find/drop/reacquire raw-pointer window. The release path only removes the idr entry and frees the stable identity strings.
This preserves the intended one-registration/many-tcon behavior: a registration id represents a net/share pair, and notify handling acts on a live representative selected at use time. It also preserves CLIENTMOVE ordering for the representative tcon because the old-IP unregister is sent before cifsswnregister() sends the new-IP register.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: add a permission check for FSCTLSETZERODATA
FSCTLSETZERODATA in smb2ioctl() destroys file data via ksmbdvfszerodata() -> vfsfallocate(PUNCHHOLE/ZERORANGE) after checking only the share-level KSMBDTREECONNFLAGWRITABLE, with no per-handle access check. A handle opened with only FILEWRITEATTRIBUTES still yields an FMODEWRITE filp (FILEWRITEATTRIBUTES is part of FILEWRITEDESIREACCESSLE, so smb2createopenflags() opens it OWRONLY), so the vfsfallocate FMODEWRITE check does not stop it; only the missing fp->daccess gate would. Reproduced on mainline 7.1-rc7 with KASAN by an authenticated SMB client: a FILEWRITEATTRIBUTES-only handle zeroed 4096 bytes of file data it had no FILEWRITEDATA right to (6/6; a FILEREADDATA-only handle was correctly denied).
This is the unfixed sibling of commit cc57232cae23 ("ksmbd: fix FSCTL permission bypass by adding a permission check for FSCTLSETSPARSE"). Because SETZERODATA writes data (not an attribute), require FILEWRITEDATA.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: require source read access for duplicate extents
FSCTLDUPLICATEEXTENTSTOFILE passes the source file directly to vfsclonefilerange() or vfscopyfilerange() without checking the SMB access mask granted to the source handle. A handle opened with attribute access can consequently be used to copy file contents into an attacker-readable destination.
Require FILEREADDATA on the source handle before either VFS operation, matching other ksmbd data-copy paths.