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.

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

ksmbd: fix UAF of struct filelock in SMB2LOCK deferred-lock cancellation

When a blocking byte-range lock request is deferred in the FILELOCKDEFERRED path, ksmbd registers the asynchronous work into the connection's asyncrequests list via setupasyncwork(). The cancel callback smb2removeblockedlock() holds a reference to the flock.

If the lock waiter is subsequently woken up but the work state is no longer KSMBDWORKACTIVE (e.g., due to a concurrent cancellation), the cleanup path calls locksfreelock(flock) without dequeuing the work from the asyncrequests list. Concurrently, smb2cancel() walks the list under conn->requestlock and invokes the cancel callback, which then dereferences the already freed 'flock'. This leads to a slab-use-after-free inside wakeupcommon.

Fix this by restructuring the cleanup logic after the worker returns from ksmbdvfsposixlockwait(). Move listdel(&smblock->llist) and releaseasyncwork(work) to the top of the cleanup block. This guarantees that the async work is completely dequeued and serialized under conn->requestlock before locksfreelock(flock) is called, rendering the flock unreachable for any concurrent smb2cancel().

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

ksmbd: add a WRITEDAC/WRITEOWNER check to SMB2 SETINFO SECURITY

commit cc57232cae23 ("ksmbd: fix FSCTL permission bypass by adding a permission check for FSCTLSETSPARSE") added a fp->daccess gate to fsctlsetsparse and noted that "similar handle-level checks exist in other functions but are missing here." The SMB2 SETINFO SECURITY arm is one of the missing ones, and the most security-relevant: smb2setinfosec() calls setinfosec() with no per-handle access check.

setinfosec() (fs/smb/server/smbacl.c) re-permissions the file: it rewrites owner/group/mode via notifychange(), rewrites the POSIX ACL via setposixacl(), and on KSMBDSHAREFLAGACLXATTR shares removes and rewrites the Windows security descriptor via ksmbdvfssetsdxattr(). Every other persistent-mutation arm of the sibling handler smb2setinfofile() checks fp->daccess first (FILEWRITEDATA / FILEDELETE / FILEWRITEEA / FILEWRITEATTRIBUTES); the SECURITY arm — which mutates the access control itself — is the only one with no gate.

A client can therefore open a handle with FILEWRITEATTRIBUTES only (no FILEWRITEDAC / FILEWRITEOWNER) and use SMB2SETINFO with InfoType SMB2OINFOSECURITY to rewrite the file's DACL and owner, granting itself access the handle's daccess never carried. Unlike the FSCTL data arms this is a metadata/xattr operation, so there is no FMODEWRITE VFS backstop — the missing fp->daccess check is the entire gate.

Setting a security descriptor is the WRITEDAC / WRITEOWNER operation, so require at least one of those on the handle before re-permissioning the file. -EACCES is mapped to STATUSACCESSDENIED by smb2setinfo().

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

ksmbd: track the connection owning a byte-range lock

SMB2LOCK adds each granted byte-range lock to both the file lock list and the lock list of the connection which handled the request. The final close and durable handle paths, however, remove the connection list entry while holding fp->conn->llistlock.

With SMB3 multichannel, the connection handling the LOCK request can be different from the connection which opened the file. The entry can therefore be removed under a different spinlock from the one protecting the list it belongs to. A concurrent traversal can then access freed struct ksmbdlock and struct filelock objects.

Record the connection owning each lock's clist entry and hold a reference to it while the entry is linked. Use that connection and its llistlock for unlock, rollback, close, and durable preserve. Durable reconnect assigns the new connection as the owner when publishing the locks again.