6lowpan: fix NHC entry use-after-free on error path

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:

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.

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

smb: client: Fix next buffer leak in receiveencryptedstandard()

receiveencryptedstandard() allocates nextbuffer before checking whether the number of compound PDUs already reached MAXCOMPOUND. If the limit check fails, the function returns immediately and the newly allocated nextbuffer is not assigned to server->smallbuf/server->bigbuf, making it leaked.

Move the MAXCOMPOUND check before allocating nextbuffer.

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

smb: client: harden POSIX SID length parsing

posixinfosidsize() reads sid[1] to obtain the subauthority count, but its existing boundary check still accepts buffers with only one remaining byte. Require two bytes before reading sid[1] so all client paths that reuse the helper reject truncated POSIX SIDs safely.

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

smb: client: mask server-provided mode to 07777 in modefromsid

When modefromsid is active, parsedacl() applies the server-provided subauth[2] value from the NFS mode SID to cfmode without masking to 07777. Apply the correct masking, same as in the read path.

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

proc: protect ptracemayaccess() with execupdatelock (FD links)

procpidgetlink() and procpidreadlink() currently look up the task from the pid once, then do the ptrace access check on that task, then look up the task from the pid a second time to do the actual access. That's racy in several ways.

To fix it, pass the task to the ->procgetlink() handler, and instead of procfdaccessallowed(), introduce a new helper callprocgetlink() that looks up and locks the task, does the access check, and calls ->procgetlink().

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

sched/rt: Have RTPUSHIPI be default off for non PREEMPTRT

RT migration is done aggressively. When a CPU schedules out a high priority RT task for a lower priority task, it will look to see if there's any RT tasks that are waiting to run on another CPU that is of higher priority than the task this CPU is about to run. If it finds one, it will pull that task over to the CPU and allow it to run there instead.

Normally, this pulling is done by looking at the RT overloaded mask (rto) which contains all the CPUs in the scheduler domain with RT tasks that are waiting to run due to a higher priority RT task currently running on their CPU. The CPU that is about to schedule a lower priority task will grab the rq lock of the overloaded CPU and move the RT task from that CPU's runqueue to the local one and schedule the higher priority RT task.

This caused issues when a lot of CPUs would schedule a lower priority task at the same time. They would all try to grab the same runqueue lock of the CPU with the overloaded RT tasks. Only the first CPU that got in will get that task. All the others would wait until they got the runqueue lock and see there's nothing to pull and do nothing. On systems with lots of CPUs, this caused a large latency (up to 500us) which is beyond what PREEMPTRT is to allow.

The solution to that was to create an RTPUSHIPI logic. When any CPU wanted to pull a task, instead of grabbing the runqueue lock of the overloaded CPU, it would start by sending an IPI to the overloaded CPU, and that IPI handler would have the CPU with the waiting RT task do a push instead. Then that handler would send an IPI to the next CPU with overloaded RT tasks, and so on. Note, after the first CPU starts this process, if another CPU wanted to do a pull, it would see that the process has already begun and would only increment a counter to have the IPIs continue again.

The RTPUSHIPI solved the latency problem with PREEMPTRT but could cause a new issue with non PREEMPTRT. Namely, softirqs run in a threaded context on PREEMPTRT but they can run in an interrupt context in non-RT.

If an IPI lands on a CPU that has just woken up multiple RT tasks and the current CPU is running a non RT or a low priority RT task, instead of doing a push, it would simply do a schedule on that CPU. But if a softirq was also executing on this CPU, the schedule would need to wait until the softirq finished. Until then, the CPU would still be considered overloaded as there are RT tasks still waiting to run on it.

A live lock occurred on a workload that was doing heavy networking traffic on a large machine where the softirqs would run 500us out of 750us. And it would also be waking up RT tasks, causing the RT pull logic to be constantly executed.

When a softirq triggered on a CPU with RT tasks queued but not running yet, and the other CPUs would see this CPU as being overloaded, they would send an IPI over to it. The CPU would notice that the waiting RT tasks are of higher priority than the currently running task and simply schedule that CPU instead. But because the softirq was executing, before it could schedule, it would receive another IPI to do the same. The amount of IPIs would slow down the currently running softirq so much that before it could return back to task context, it would execute another softirq never allowing the CPU to schedule. This live locked that CPU.

As RTPUSHIPI was created to help PREEMPTRT, make it default off if PREEMPTRT is not enabled.

cpufreq: pcc: fix use-after-free and double free in OSC evaluation