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:

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

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

media: nxp: imx8-isi: Fix use-after-free on remove

KASAN reports a slab-use-after-free in mediaentityremovelink() during rmmod of imx8isi:

BUG: KASAN: slab-use-after-free in mediaentityremovelink+0x608/0x650 Read of size 2 at addr ffff0000d47cb02a by task rmmod/724

Call trace: mediaentityremovelink+0x608/0x650 mediaentityremovelinks+0x78/0x144 mediadeviceunregisterentity+0x150/0x280 mediadeviceunregisterentity+0x48/0x68 v4l2deviceunregistersubdev+0x158/0x300 v4l2asyncunbindsubdevone+0x22c/0x358 v4l2asyncnfunbindallsubdevs+0xfc/0x1c0 v4l2asyncnfunregister+0x5c/0x14c mxcisiremove+0x124/0x2a0 [imx8isi]

Allocated by task 249: kmallocnoprof+0x27c/0x690 mxcisicrossbarinit+0x22c/0x560 [imx8isi]

Freed by task 724: kfree+0x1e4/0x5b0 mxcisicrossbarcleanup+0x34/0x80 [imx8isi] mxcisiremove+0x11c/0x2a0 [imx8isi]

The problem is that mxcisiremove() calls mxcisicrossbarcleanup() before mxcisiv4l2cleanup(). The crossbar cleanup frees the media entity pads, but the subsequent v4l2 cleanup still tries to remove media links that reference those pads.

Fix this by calling mxcisiv4l2cleanup() before mxcisicrossbarcleanup() to ensure all media entities are properly unregistered while the pads are still valid.

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

mm: shrinker: fix shrinkerinfo teardown race with expansion

expandshrinkerinfo() iterates all visible memcgs under shrinkermutex, including memcgs that have not finished ->cssonline() yet.

Once pn->shrinkerinfo has been published, teardown must stay serialized with expandshrinkerinfo() until that memcg is either fully online or no longer visible to iteration. Today allocshrinkerinfo() breaks that rule by dropping shrinkermutex before freeing a partially initialized shrinkerinfo array, which may cause the following race:

CPU0 CPU1 ==== ====

csscreate --> listaddtailrcu(&css->sibling, &parentcss->children); onlinecss --> memcgroupcssonline --> allocshrinkerinfo --> alloc node0 info rcuassignpointer(C->node0->shrinkerinfo, old0) alloc node1 info -> FAIL -> goto err mutexunlock(shrinkermutex)

shrinkeralloc() --> shrinkermemcgalloc --> mutexlock(shrinkermutex) expandshrinkerinfo --> memcgroupiter see the memcg expandoneshrinkerinfo --> old0 = C->node0->shrinkerinfo memcpy(new->unit, old0->unit, ...);

freeshrinkerinfo --> kvfree(old0);

/ double free !! / kvfreercu(old0, rcu);

The same problem exists later in memcgroupcssonline(). If allocshrinkerinfo() succeeds but a subsequent objcg allocation fails, the freeobjcg -> freeshrinkerinfo() unwind path tears down the already published pn->shrinkerinfo arrays without shrinkermutex. The expandoneshrinkerinfo() can race with that teardown in the same way, leading to use-after-free or double-free of the old shrinkerinfo.

Fix this by serializing shrinkerinfo teardown with shrinkermutex, and by keeping allocshrinkerinfo() error cleanup inside the locked section.

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

netfilter: handle unreadable frags

sashiko reports: When an skb with unreadable fragments (such as from devmem TCP, where skbfragsreadable(skb) returns false) is processed by the u32 module, skbcopybits() will safely return a negative error code [..]

xtu32: bail out with hotdrop in this case. gatherfrags: return -1, just as if we had no fragment header. nfnetlinkqueue: restrict to the linear part. nfnetlinklog: restrict to the linear part.

v2: - skbzerocopy helpers don't copy readable flag, i.e. nfnetlinkqueue is broken too xtu32 shouldn't return true if hotdrop was set.

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

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

Bluetooth: btnxpuart: Fix out-of-bounds firmware read in nxprecvfwreqv3()

During the v3 firmware download the controller sends a v3datareq with a 32 bit offset and a 16 bit len. nxprecvfwreqv3() checks only the lower bound of the offset and then sends firmware from that offset.

nxpdev->fwdnldv3offset = offset - nxpdev->fwv3offsetcorrection; serdevdevicewritebuf(nxpdev->serdev, nxpdev->fw->data + nxpdev->fwdnldv3offset, len);

Nothing checks that fwdnldv3offset + len stays within nxpdev->fw->size, so a controller that asks for an offset or length past the firmware image makes the driver read past the end of nxpdev->fw->data and send that memory back over UART.

nxprecvfwreqv1() already bounds the same write. Add the equivalent check to the v3 path, reject the request when it falls outside the firmware image, and zero len on the error path so the fwv3prevsent bookkeeping at freeskb stays consistent.

Bluetooth: hciconn: Fix null ptr deref in hciabortconn()

Bluetooth: L2CAP: validate option length before reading conf opt value