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

ksmbd: fix PreauhHashValue race condition

If client send multiple session setup requests to ksmbd, PreauhHashValue race condition could happen. There is no need to free sess->PreauhHashValue at session setup phase. It can be freed together with session at connection termination phase.

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

sunrpc: fix handling of server side tls alerts

Scott Mayhew discovered a security exploit in NFS over TLS in tlsalertrecv() due to its assumption it can read data from the msg iterator's kvec..

kTLS implementation splits TLS non-data record payload between the control message buffer (which includes the type such as TLS aler or TLS cipher change) and the rest of the payload (say TLS alert's level/description) which goes into the msg payload buffer.

This patch proposes to rework how control messages are setup and used by sockrecvmsg().

If no control message structure is setup, kTLS layer will read and process TLS data record types. As soon as it encounters a TLS control message, it would return an error. At that point, NFS can setup a kvec backed msg buffer and read in the control message such as a TLS alert. Msg iterator can advance the kvec pointer as a part of the copy process thus we need to revert the iterator before calling into the tlsalertrecv.

[ceph] parselongname(): strrchr() expects NUL-terminated string

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

nfsd: handle getclientlocked() failure in nfsd4setclientidconfirm()

Lei Lu recently reported that nfsd4setclientidconfirm() did not check the return value from getclientlocked(). a SETCLIENTIDCONFIRM could race with a confirmed client expiring and fail to get a reference. That could later lead to a UAF.

Fix this by getting a reference early in the case where there is an extant confirmed client. If that fails then treat it as if there were no confirmed client found at all.

In the case where the unconfirmed client is expiring, just fail and return the result from getclientlocked().

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

drbd: add missing krefget in handlewriteconflicts

With two-primaries enabled, DRBD tries to detect "concurrent" writes and handle write conflicts, so that even if you write to the same sector simultaneously on both nodes, they end up with the identical data once the writes are completed.

In handling "superseeded" writes, we forgot a krefget, resulting in a premature drbddestroydevice and use after free, and further to kernel crashes with symptoms.

Relevance: No one should use DRBD as a random data generator, and apparently all users of "two-primaries" handle concurrent writes correctly on layer up. That is cluster file systems use some distributed lock manager, and live migration in virtualization environments stops writes on one node before starting writes on the other node.

Which means that other than for "test cases", this code path is never taken in real life.

FYI, in DRBD 9, things are handled differently nowadays. We still detect "write conflicts", but no longer try to be smart about them. We decided to disconnect hard instead: upper layers must not submit concurrent writes. If they do, that's their fault.

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

RDMA/siw: Fix the sendmsg byte count in siwtcpsendpages

Ever since commit c2ff29e99a76 ("siw: Inline dotcpsendpages()"), we have been doing this:

static int siwtcpsendpages(struct socket s, struct page page, int offset, sizet size) [...] / Calculate the number of bytes we need to push, for this page specifically / sizet bytes = mint(sizet, PAGESIZE - offset, size); / If we can't splice it, then copy it in, as normal / if (!sendpageok(page[i])) msg.msgflags &= ~MSGSPLICEPAGES; / Set the bvec pointing to the page, with len $bytes / bvecsetpage(&bvec, page[i], bytes, offset); / Set the iter to $size, aka the size of the whole sendpages (!!!) / ioviterbvec(&msg.msgiter, ITERSOURCE, &bvec, 1, size); trypageagain: locksock(sk); / Sendmsg with $size size (!!!) / rv = tcpsendmsglocked(sk, &msg, size);

This means we've been sending oversized ioviters and tcpsendmsg calls for a while. This has a been a benign bug because sendpageok() always returned true. With the recent slab allocator changes being slowly introduced into next (that disallow sendpage on large kmalloc allocations), we have recently hit out-of-bounds crashes, due to slight differences in ioviter behavior between the MSGSPLICEPAGES and "regular" copy paths:

(MSGSPLICEPAGES) skbsplicefromiter ioviterextractpages ioviterextractbvecpages uses i->nrsegs to correctly stop in its tracks before OoB'ing everywhere skbsplicefromiter gets a "short" read

(!MSGSPLICEPAGES) skbcopytopagenocache copy=iovitercount [...] copyfromiter / this doesn't help / if (unlikely(iter->count < len)) len = iter->count; iteratebvec ... and we run off the bvecs

Fix this by properly setting the ioviter's byte count, plus sending the correct byte count to tcpsendmsglocked.

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

rxrpc: Fix integer overflow in rxgkverifyresponse()

In rxgkverifyresponse(), there's a potential integer overflow due to rounding up tokenlen before checking it, thereby allowing the length check to be bypassed.

Fix this by checking the unrounded value against len too (len is limited as the response must fit in a single UDP packet).

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

idpf: fix readdevclklock spinlock init in idpfptpinit()

In idpfptpinit(), readdevclklock is initialized after ptpscheduleworker() had already been called (and after idpfptpsettime64() could reach the lock). The PTP aux worker fires immediately upon scheduling and can call into idpfptpreadsrcclkregdirect(), which takes spinlock(&ptp->readdevclklock) on an uninitialized lock, triggering the lockdep "non-static key" warning:

[12973.796587] idpf 0000:83:00.0: Device HW Reset initiated [12974.094507] INFO: trying to register non-static key. ... [12974.097208] Call Trace: [12974.097213] <TASK> [12974.097218] dumpstacklvl+0x93/0xe0 [12974.097234] registerlockclass+0x4c4/0x4e0 [12974.097249] ? lockacquire+0x427/0x2290 [12974.097259] lockacquire+0x98/0x2290 [12974.097272] lockacquire+0xc6/0x310 [12974.097281] ? idpfptpreadsrcclkreg+0xb7/0x150 [idpf] [12974.097311] ? lockdephardirqsonprepare+0xde/0x190 [12974.097318] ? finishtaskswitch.isra.0+0xd2/0x350 [12974.097330] ? pfxptpauxkworker+0x10/0x10 [ptp] [12974.097343] rawspinlock+0x30/0x40 [12974.097353] ? idpfptpreadsrcclkreg+0xb7/0x150 [idpf] [12974.097373] idpfptpreadsrcclkreg+0xb7/0x150 [idpf] [12974.097391] ? kthreadworkerfn+0x88/0x3d0 [12974.097404] ? kthreadworkerfn+0x4e/0x3d0 [12974.097411] idpfptpupdatecachedphctime+0x26/0x120 [idpf] [12974.097428] ? rawspinunlockirq+0x28/0x50 [12974.097436] idpfptpdoauxwork+0x15/0x20 [idpf] [12974.097454] ptpauxkworker+0x20/0x40 [ptp] [12974.097464] kthreadworkerfn+0xd5/0x3d0 [12974.097474] ? pfxkthreadworkerfn+0x10/0x10 [12974.097482] kthread+0xf4/0x130 [12974.097489] ? pfxkthread+0x10/0x10 [12974.097498] retfromfork+0x32c/0x410 [12974.097512] ? pfxkthread+0x10/0x10 [12974.097519] retfromforkasm+0x1a/0x30 [12974.097540] </TASK>

Move the call to spinlockinit() up a bit to make sure readdevclklock is not touched before it's been initialized.

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

netfilter: nftinner: release locallock before re-enabling softirqs

Quoting sashiko: In the error path, localbhenable() is called before localunlocknestedbh().

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

x86/sev: Evict cache lines during SNP memory validation

An SNP cache coherency vulnerability requires a cache line eviction mitigation when validating memory after a page state change to private. The specific mitigation is to touch the first and last byte of each 4K page that is being validated. There is no need to perform the mitigation when performing a page state change to shared and rescinding validation.

CPUID bit Fn8000001FEBX[31] defines the COHERENCYSFWNO CPUID bit that, when set, indicates that the software mitigation for this vulnerability is not needed.

Implement the mitigation and invoke it when validating memory (making it private) and the COHERENCYSFWNO bit is not set, indicating the SNP guest is vulnerable.

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

smb3: fix for slab out of bounds on mount to ksmbd

With KASAN enabled, it is possible to get a slab out of bounds during mount to ksmbd due to missing check in parseserverinterfaces() (see below):

BUG: KASAN: slab-out-of-bounds in parseserverinterfaces+0x14ee/0x1880 [cifs] Read of size 4 at addr ffff8881433dba98 by task mount/9827

CPU: 5 UID: 0 PID: 9827 Comm: mount Tainted: G OE 6.16.0-rc2-kasan #2 PREEMPT(voluntary) Tainted: [O]=OOTMODULE, [E]=UNSIGNEDMODULE Hardware name: Dell Inc. Precision Tower 3620/0MWYPT, BIOS 2.13.1 06/14/2019 Call Trace: <TASK> dumpstacklvl+0x9f/0xf0 printreport+0xd1/0x670 virtaddrvalid+0x22c/0x430 ? parseserverinterfaces+0x14ee/0x1880 [cifs] ? kasancompletemodereportinfo+0x2a/0x1f0 ? parseserverinterfaces+0x14ee/0x1880 [cifs] kasanreport+0xd6/0x110 parseserverinterfaces+0x14ee/0x1880 [cifs] asanreportloadnnoabort+0x13/0x20 parseserverinterfaces+0x14ee/0x1880 [cifs] ? pfxparseserverinterfaces+0x10/0x10 [cifs] ? tracehardirqson+0x51/0x60 SMB3requestinterfaces+0x1ad/0x3f0 [cifs] ? pfxSMB3requestinterfaces+0x10/0x10 [cifs] ? SMB2tcon+0x23c/0x15d0 [cifs] smb3qfstcon+0x173/0x2b0 [cifs] ? pfxsmb3qfstcon+0x10/0x10 [cifs] ? cifsgettcon+0x105d/0x2120 [cifs] ? dorawspinunlock+0x5d/0x200 ? cifsgettcon+0x105d/0x2120 [cifs] ? pfxsmb3qfstcon+0x10/0x10 [cifs] cifsmountgettcon+0x369/0xb90 [cifs] ? dfscachefind+0xe7/0x150 [cifs] dfsmountshare+0x985/0x2970 [cifs] ? checkpath.constprop.0+0x28/0x50 ? savetrace+0x54/0x370 ? pfxdfsmountshare+0x10/0x10 [cifs] ? lockacquire+0xb82/0x2ba0 ? kasancheckwrite+0x18/0x20 cifsmount+0xbc/0x9e0 [cifs] ? pfxcifsmount+0x10/0x10 [cifs] ? dorawspinunlock+0x5d/0x200 ? cifssetupcifssb+0x29d/0x810 [cifs] cifssmb3domount+0x263/0x1990 [cifs]

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

rxrpc: fix RESPONSE authenticator parser OOB read

rxgkverifyauthenticator() copies authlen bytes into a temporary buffer and then passes p + authlen as the parser limit to rxgkdoverifyauthenticator(). Since p is a be32 , that inflates the parser end pointer by a factor of four and lets malformed RESPONSE authenticators read past the kmalloc() buffer.

Decoded from the original latest-net reproduction logs with scripts/decodestacktrace.sh:

BUG: KASAN: slab-out-of-bounds in rxgkverifyresponse() Call Trace: dumpstacklvl() [lib/dumpstack.c:123] printreport() [mm/kasan/report.c:379 mm/kasan/report.c:482] kasanreport() [mm/kasan/report.c:597] rxgkverifyresponse() [net/rxrpc/rxgk.c:1103 net/rxrpc/rxgk.c:1167 net/rxrpc/rxgk.c:1274] rxrpcprocessconnection() [net/rxrpc/connevent.c:266 net/rxrpc/connevent.c:364 net/rxrpc/connevent.c:386] processonework() [kernel/workqueue.c:3281] workerthread() [kernel/workqueue.c:3353 kernel/workqueue.c:3440] kthread() [kernel/kthread.c:436] retfromfork() [arch/x86/kernel/process.c:164]

Allocated by task 54: rxgkverifyresponse() [include/linux/slab.h:954 net/rxrpc/rxgk.c:1155 net/rxrpc/rxgk.c:1274] rxrpcprocessconnection() [net/rxrpc/connevent.c:266 net/rxrpc/connevent.c:364 net/rxrpc/connevent.c:386]

Convert the byte count to be32 units before constructing the parser limit.

hfsplus: fix slab-out-of-bounds in hfsplusbnoderead()

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

wifi: mt76: mt7996: Fix possible OOB access in mt7996tx()

Fis possible Out-Of-Boundary access in mt7996tx routine if linkid is set to IEEE80211LINKUNSPECIFIED

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

wifi: ath11k: clear initialized flag for deinit-ed srng lists

In a number of cases we see kernel panics on resume due to ath11k kernel page fault, which happens under the following circumstances:

1) First ath11khaldumpsrngstats() call

Last interrupt received for each group: ath11kpci 0000:01:00.0: groupid 0 22511ms before ath11kpci 0000:01:00.0: groupid 1 14440788ms before [..] ath11kpci 0000:01:00.0: failed to receive control response completion, polling.. ath11kpci 0000:01:00.0: Service connect timeout ath11kpci 0000:01:00.0: failed to connect to HTT: -110 ath11kpci 0000:01:00.0: failed to start core: -110 ath11kpci 0000:01:00.0: firmware crashed: MHICBEERDDM ath11kpci 0000:01:00.0: already resetting count 2 ath11kpci 0000:01:00.0: failed to wait wlan mode request (mode 4): -110 ath11kpci 0000:01:00.0: qmi failed to send wlan mode off: -110 ath11kpci 0000:01:00.0: failed to reconfigure driver on crash recovery [..]

2) At this point reconfiguration fails (we have 2 resets) and ath11kcorereconfigureoncrash() calls ath11khalsrngdeinit() which destroys srng lists. However, it does not reset per-list ->initialized flag.

3) Second ath11khaldumpsrngstats() call sees stale ->initialized flag and attempts to dump srng stats:

Last interrupt received for each group: ath11kpci 0000:01:00.0: groupid 0 66785ms before ath11kpci 0000:01:00.0: groupid 1 14485062ms before ath11kpci 0000:01:00.0: groupid 2 14485062ms before ath11kpci 0000:01:00.0: groupid 3 14485062ms before ath11kpci 0000:01:00.0: groupid 4 14780845ms before ath11kpci 0000:01:00.0: groupid 5 14780845ms before ath11kpci 0000:01:00.0: groupid 6 14485062ms before ath11kpci 0000:01:00.0: groupid 7 66814ms before ath11kpci 0000:01:00.0: groupid 8 68997ms before ath11kpci 0000:01:00.0: groupid 9 67588ms before ath11kpci 0000:01:00.0: groupid 10 69511ms before BUG: unable to handle page fault for address: ffffa007404eb010 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 100000067 P4D 100000067 PUD 10022d067 PMD 100b01067 PTE 0 Oops: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:ath11khaldumpsrngstats+0x2b4/0x3b0 [ath11k] Call Trace: <TASK> ? diebody+0xae/0xb0 ? pagefaultoops+0x381/0x3e0 ? excpagefault+0x69/0xa0 ? asmexcpagefault+0x22/0x30 ? ath11khaldumpsrngstats+0x2b4/0x3b0 [ath11k (HASH:6cea 4)] ath11kqmidrivereventwork+0xbd/0x1050 [ath11k (HASH:6cea 4)] workerthread+0x389/0x930 kthread+0x149/0x170

Clear per-list ->initialized flag in ath11khalsrngdeinit().

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

Bluetooth: hcidevcddump: fix out-of-bounds via devcoredumpv

Currently both devcoredumpv and skbputdata in hcidevcddump use hdev->dump.head. However, devcoredumpv can free the buffer. From devcoredumpmtimeout documentation, which is used by devcoredumpv:

> Creates a new device coredump for the given device. If a previous one hasn't > been read yet, the new coredump is discarded. The data lifetime is determined > by the device coredump framework and when it is no longer needed the @free > function will be called to free the data.

If the data has not been read by the userspace yet, devcoredumpv will discard new buffer, freeing hdev->dump.head. This leads to vmalloc-out-of-bounds error when skbputdata tries to access hdev->dump.head.

A crash report from syzbot illustrates this:

================================================================== BUG: KASAN: vmalloc-out-of-bounds in skbputdata include/linux/skbuff.h:2752 [inline] BUG: KASAN: vmalloc-out-of-bounds in hcidevcddump+0x142/0x240 net/bluetooth/coredump.c:258 Read of size 140 at addr ffffc90004ed5000 by task kworker/u9:2/5844

CPU: 1 UID: 0 PID: 5844 Comm: kworker/u9:2 Not tainted 6.14.0-syzkaller-10892-g4e82c87058f4 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 Workqueue: hci0 hcidevcdtimeout Call Trace: <TASK> dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x116/0x1f0 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:408 [inline] printreport+0xc3/0x670 mm/kasan/report.c:521 kasanreport+0xe0/0x110 mm/kasan/report.c:634 checkregioninline mm/kasan/generic.c:183 [inline] kasancheckrange+0xef/0x1a0 mm/kasan/generic.c:189 asanmemcpy+0x23/0x60 mm/kasan/shadow.c:105 skbputdata include/linux/skbuff.h:2752 [inline] hcidevcddump+0x142/0x240 net/bluetooth/coredump.c:258 hcidevcdtimeout+0xb5/0x2e0 net/bluetooth/coredump.c:413 processonework+0x9cc/0x1b70 kernel/workqueue.c:3238 processscheduledworks kernel/workqueue.c:3319 [inline] workerthread+0x6c8/0xf10 kernel/workqueue.c:3400 kthread+0x3c2/0x780 kernel/kthread.c:464 retfromfork+0x45/0x80 arch/x86/kernel/process.c:153 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:245 </TASK>

The buggy address ffffc90004ed5000 belongs to a vmalloc virtual mapping Memory state around the buggy address: ffffc90004ed4f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90004ed4f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >ffffc90004ed5000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90004ed5080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90004ed5100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ==================================================================

To avoid this issue, reorder devcoredumpv to be called after skbputdata that does not free the data.

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

wifi: mt76: mt7925: fix off by one in mt7925mcuhwscan()

The ssid->ssids[] and sreq->ssids[] arrays have MT7925RNRSCANMAXBSSIDS elements so this >= needs to be > to prevent an out of bounds access.

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

wifi: cfg80211: Add missing lock in cfg80211checkandendcac()

Callers of wdevchandef() must hold the wiphy mutex.

But the worker cfg80211propagatecacdonewk() never takes the lock. Which triggers the warning below with the meshpeerconnecteddfs test from hostapd and not (yet) released mac80211 code changes:

WARNING: CPU: 0 PID: 495 at net/wireless/chan.c:1552 wdevchandef+0x60/0x165 Modules linked in: CPU: 0 UID: 0 PID: 495 Comm: kworker/u4:2 Not tainted 6.14.0-rc5-wt-g03960e6f9d47 #33 13c287eeabfe1efea01c0bcc863723ab082e17cf Workqueue: cfg80211 cfg80211propagatecacdonewk Stack: 00000000 00000001 ffffff00 6093267c 00000000 6002ec30 6d577c50 60037608 00000000 67e8d108 6063717b 00000000 Call Trace: [<6002ec30>] ? printk+0x0/0x98 [<6003c2b3>] showstack+0x10e/0x11a [<6002ec30>] ? printk+0x0/0x98 [<60037608>] dumpstacklvl+0x71/0xb8 [<6063717b>] ? wdevchandef+0x60/0x165 [<6003766d>] dumpstack+0x1e/0x20 [<6005d1b7>] warn+0x101/0x20f [<6005d3a8>] warnslowpathfmt+0xe3/0x15d [<600b0c5c>] ? marklock.part.0+0x0/0x4ec [<60751191>] ? thiscpupreemptcheck+0x0/0x16 [<600b11a2>] ? markheldlocks+0x5a/0x6e [<6005d2c5>] ? warnslowpathfmt+0x0/0x15d [<60052e53>] ? unblocksignals+0x3a/0xe7 [<60052f2d>] ? umsetsignals+0x2d/0x43 [<60751191>] ? thiscpupreemptcheck+0x0/0x16 [<607508b2>] ? lockisheldtype+0x207/0x21f [<6063717b>] wdevchandef+0x60/0x165 [<605f89b4>] regulatorypropagatedfsstate+0x247/0x43f [<60052f00>] ? umsetsignals+0x0/0x43 [<605e6bfd>] cfg80211propagatecacdonewk+0x3a/0x4a [<6007e460>] processscheduledworks+0x3bc/0x60e [<6007d0ec>] ? movelinkedworks+0x4d/0x81 [<6007d120>] ? assignwork+0x0/0xaa [<6007f81f>] workerthread+0x220/0x2dc [<600786ef>] ? setpfworker+0x0/0x57 [<60087c96>] ? tokthread+0x0/0x43 [<6008ab3c>] kthread+0x2d3/0x2e2 [<6007f5ff>] ? workerthread+0x0/0x2dc [<6006c05b>] ? calculatesigpending+0x0/0x56 [<6003b37d>] newthreadhandler+0x4a/0x64 irq event stamp: 614611 hardirqs last enabled at (614621): [<00000000600bc96b>] upconsolesem+0x82/0xaf hardirqs last disabled at (614630): [<00000000600bc92c>] upconsolesem+0x43/0xaf softirqs last enabled at (614268): [<00000000606c55c6>] ieee80211wakequeue+0x933/0x985 softirqs last disabled at (614266): [<00000000606c52d6>] ieee80211wakequeue+0x643/0x985

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

iommufd: Prevent ALIGN() overflow

When allocating IOVA the candidate range gets aligned to the target alignment. If the range is close to ULONGMAX then the ALIGN() can wrap resulting in a corrupted iova.

Open code the ALIGN() using getaddoverflow() to prevent this. This simplifies the checks as we don't need to check for length earlier either.

Consolidate the two copies of this code under a single helper.

This bug would allow userspace to create a mapping that overlaps with some other mapping or a reserved range.

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

wifi: ath12k: Correct tid cleanup when tid setup fails

Currently, if any error occurs during ath12kdprxpeertidsetup(), the tid value is already incremented, even though the corresponding TID is not actually allocated. Proceed to ath12kdprxpeertiddelete() starting from unallocated tid, which might leads to freeing unallocated TID and cause potential crash or out-of-bounds access.

Hence, fix by correctly decrementing tid before cleanup to match only the successfully allocated TIDs.

Also, remove tid-- from failure case of ath12kdprxpeerfragsetup(), as decrementing the tid before cleanup in loop will take care of this.

Compile tested only.

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

wifi: ath12k: Decrement TID on RX peer frag setup error handling

Currently, TID is not decremented before peer cleanup, during error handling path of ath12kdprxpeerfragsetup(). This could lead to out-of-bounds access in peer->rxtid[].

Hence, add a decrement operation for TID, before peer cleanup to ensures proper cleanup and prevents out-of-bounds access issues when the RX peer frag setup fails.

Found during code review. Compile tested only.

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

net: devmem: reject dma-buf bind with non-page-aligned size or SG length

netdevmembinddmabuf() trusts dmabuf->size and sgdmalen() to be PAGESIZE multiples without checking:

- txvec is sized dmabuf->size / PAGESIZE, and netdevmemgetniovat() only bounds-checks virtaddr < dmabuf->size before indexing txvec[virtaddr / PAGESIZE]. With size = NPAGESIZE + r (1 <= r < PAGESIZE), sendmsg() at iovbase = NPAGESIZE passes the bound check and reads txvec[N] -- one past.

- owner->area.numniovs = len / PAGESIZE while genpooladdowner() covers the full byte len, so a non-page-multiple non-final sg desyncs numniovs from the genpool region for every later sg, on both RX and TX.

dma-buf does not require page-aligned sizes, so the bind path has to enforce what its own indexing assumes. Reject both with -EINVAL.

The size check is TX-only (only txvec is sized off dmabuf->size); the SG-length check covers both directions.

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

pptp: ensure minimal skb length in pptpxmit()

Commit aabc6596ffb3 ("net: ppp: Add bound checking for skb data on pppsynctxmung") fixed pppsynctxmunge()

We need a similar fix in pptpxmit(), otherwise we might read uninit data as reported by syzbot.

BUG: KMSAN: uninit-value in pptpxmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193 pptpxmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193 pppchannelbridgeinput drivers/net/ppp/pppgeneric.c:2290 [inline] pppinput+0x1d6/0xe60 drivers/net/ppp/pppgeneric.c:2314 pppoercvcore+0x1e8/0x760 drivers/net/ppp/pppoe.c:379 skbacklogrcv+0x142/0x420 include/net/sock.h:1148 releasesock+0x1d3/0x330 net/core/sock.c:3213 releasesock+0x6b/0x270 net/core/sock.c:3767 pppoesendmsg+0x15d/0xcb0 drivers/net/ppp/pppoe.c:904 socksendmsgnosec net/socket.c:712 [inline] socksendmsg+0x330/0x3d0 net/socket.c:727 syssendmsg+0x893/0xd80 net/socket.c:2566 syssendmsg+0x271/0x3b0 net/socket.c:2620 syssendmmsg+0x2d9/0x7c0 net/socket.c:2709

bpf, ktls: Fix data corruption when using bpfmsgpopdata() in ktls

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

ovpn: tcp - use cached peer pointer in ovpntcpclose()

ovpntcpclose() loads the ovpnsocket via rcudereferenceskuserdata() under rcureadlock(), takes a reference on sock->peer, caches the peer pointer in a local, and drops the read lock. It then passes sock->peer (rather than the cached local) to ovpnpeerdel(), re-dereferencing the ovpnsocket after the RCU read section has ended.

Unlike ovpntcpsendmsg(), which uses the same "load under RCU, use after unlock" pattern but is protected by locksock() held across the function, ovpntcpclose() runs without the socket lock: inetrelease() invokes skprot->close() without taking locksock first.

ovpnsocketrelease() can therefore complete its krefput -> detach -> synchronizercu -> kfree(sock) sequence concurrently, in the window after ovpntcpclose() drops rcureadlock() but before it dereferences sock->peer. The synchronizercu() in ovpnsocketrelease() protects readers that use the dereferenced pointer inside the RCU read section, not those that escape the pointer to a local and use it afterwards.

A reproducer follows the pattern of commit 94560267d6c4 ("ovpn: tcp - don't deref NULL sksocket member after tcpclose()"): trigger a peer removal (keepalive expiration or netlink OVPNCMDDELPEER) at the same moment userspace closes the TCP fd. That commit fixed the detach-side of the same race window; this one fixes the close-side at a different victim.

Tighten the entry block to read sock->peer exactly once into the cached peer local, and route all subsequent uses (the hold check, the ovpnpeerdel() call, and the prot->close() invocation) through that local. sock->peer is only ever written once in ovpnsocketnew() under locksock(), before rcuassignskuserdata() publishes the ovpnsocket, and is never reassigned afterwards - but the previous multi-read pattern made that invariant implicit rather than explicit. The same multi-read shape exists in ovpntcprecvmsg(), ovpntcpsendmsg(), ovpntcpdataready() and ovpntcpwritespace(); those will be cleaned up via a dedicated helper in a follow-up net-next series.

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

sunrpc: fix client side handling of tls alerts

A security exploit was discovered in NFS over TLS in tlsalertrecv due to its assumption that there is valid data in the msghdr's iterator's kvec.

Instead, this patch proposes the rework how control messages are setup and used by sockrecvmsg().

If no control message structure is setup, kTLS layer will read and process TLS data record types. As soon as it encounters a TLS control message, it would return an error. At that point, NFS can setup a kvec backed control buffer and read in the control message such as a TLS alert. Scott found that a msg iterator can advance the kvec pointer as a part of the copy process thus we need to revert the iterator before calling into the tlsalertrecv.

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

rxrpc: Fix buffer overread in rxgkdoverifyauthenticator()

Fix rxgkdoverifyauthenticator() to check the buffer size before checking the nonce.

HID: core: Harden s32ton() against conversion to 0 bits

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

eth: fbnic: unlink NAPIs from queues on error to open

CI hit a UaF in fbnic in the AFXDP portion of the queues.py test. The UaF is in the skmarknapiidonce() call in xskbind(), NAPI has been freed. Looks like the device failed to open earlier, and we lack clearing the NAPI pointer from the queue.

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

perf/core: Prevent VMA split of buffer mappings

The perf mmap code is careful about mmap()'ing the user page with the ringbuffer and additionally the auxiliary buffer, when the event supports it. Once the first mapping is established, subsequent mapping have to use the same offset and the same size in both cases. The reference counting for the ringbuffer and the auxiliary buffer depends on this being correct.

Though perf does not prevent that a related mapping is split via mmap(2), munmap(2) or mremap(2). A split of a VMA results in perfmmapopen() calls, which take reference counts, but then the subsequent perfmmapclose() calls are not longer fulfilling the offset and size checks. This leads to reference count leaks.

As perf already has the requirement for subsequent mappings to match the initial mapping, the obvious consequence is that VMA splits, caused by resizing of a mapping or partial unmapping, have to be prevented.

Implement the vmoperationsstruct::maysplit() callback and return unconditionally -EINVAL.

That ensures that the mapping offsets and sizes cannot be changed after the fact. Remapping to a different fixed address with the same size is still possible as it takes the references for the new mapping and drops those of the old mapping.