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:

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:

igc: set tx buffer type for SMD frames

Sashiko pointed out that igcfpeinitsmdframe() initializes igctxbuffer fields for an SMD skb, but does not set the buffer type: https://sashiko.dev/#/patchset/20260415025226.114115-1-kohei%40enjuk.jp

Since igctxbuffer entries are reused, a stale XDP or XSK type can remain and make TX completion use the wrong cleanup path.

Set the buffer type to IGCTXBUFFERTYPESKB.

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:

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:

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:

ksmbd: limit repeated connections from clients with the same IP

Repeated connections from clients with the same IP address may exhaust the max connections and prevent other normal client connections. This patch limit repeated connections from clients with the same IP.

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.

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:

ipv6: reject malicious packets in ipv6gsosegment()

syzbot was able to craft a packet with very long IPv6 extension headers leading to an overflow of skb->transportheader.

This 16bit field has a limited range.

Add skbresettransportheadercareful() helper and use it from ipv6gsosegment()

WARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 skbresettransportheader include/linux/skbuff.h:3032 [inline] WARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 ipv6gsosegment+0x15e2/0x21e0 net/ipv6/ip6offload.c:151 Modules linked in: CPU: 0 UID: 0 PID: 5871 Comm: syz-executor211 Not tainted 6.16.0-rc6-syzkaller-g7abc678e3084 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:skbresettransportheader include/linux/skbuff.h:3032 [inline] RIP: 0010:ipv6gsosegment+0x15e2/0x21e0 net/ipv6/ip6offload.c:151 Call Trace: <TASK> skbmacgsosegment+0x31c/0x640 net/core/gso.c:53 nshgsosegment+0x54a/0xe10 net/nsh/nsh.c:110 skbmacgsosegment+0x31c/0x640 net/core/gso.c:53 skbgsosegment+0x342/0x510 net/core/gso.c:124 skbgsosegment include/net/gso.h:83 [inline] validatexmitskb+0x857/0x11b0 net/core/dev.c:3950 validatexmitskblist+0x84/0x120 net/core/dev.c:4000 schdirectxmit+0xd3/0x4b0 net/sched/schgeneric.c:329 devxmitskb net/core/dev.c:4102 [inline] devqueuexmit+0x17b6/0x3a70 net/core/dev.c:4679

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

drm/xe: Make dma-fences compliant with the safe access rules

Xe can free some of the data pointed to by the dma-fences it exports. Most notably the timeline name can get freed if userspace closes the associated submit queue. At the same time the fence could have been exported to a third party (for example a syncfence fd) which will then cause an use- after-free on subsequent access.

To make this safe we need to make the driver compliant with the newly documented dma-fence rules. Driver has to ensure a RCU grace period between signalling a fence and freeing any data pointed to by said fence.

For the timeline name we simply make the queue be freed via kfreercu and for the shared lock associated with multiple queues we add a RCU grace period before freeing the per GT structure holding the lock.

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

iouring/net: commit partial buffers on retry

Ring provided buffers are potentially only valid within the single execution context in which they were acquired. iouring deals with this and invalidates them on retry. But on the networking side, if MSGWAITALL is set, or if the socket is of the streaming type and too little was processed, then it will hang on to the buffer rather than recycle or commit it. This is problematic for two reasons:

1) If someone unregisters the provided buffer ring before a later retry, then the req->buflist will no longer be valid.

2) If multiple sockers are using the same buffer group, then multiple receives can consume the same memory. This can cause data corruption in the application, as either receive could land in the same userspace buffer.

Fix this by disallowing partial retries from pinning a provided buffer across multiple executions, if ring provided buffers are used.

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

mm/hugememory: fix use of NULL folio in movepageshugepmd()

movepageshugepmd() handles UFFDIOMOVE for both normal THPs and huge zero pages. For the huge zero page path, srcfolio is explicitly set to NULL, and is used as a sentinel to skip folio operations like lock and rmap.

In the huge zero page branch, srcfolio is NULL, so foliomkpmd(NULL, pgprot) passes NULL through foliopfn() and pagetopfn(). With SPARSEMEMVMEMMAP this silently produces a bogus PFN, installing a PMD pointing to non-existent physical memory. On other memory models it is a NULL dereference.

Use pagefolio(srcpage) to obtain the valid huge zero folio from the page, which was obtained from pmdpage() and remains valid throughout.

After commit d82d09e48219 ("mm/hugememory: mark PMD mappings of the huge zero folio special"), moved huge zero PMDs must remain special so vmnormalpagepmd() continues to treat them as special mappings.

movepageshugepmd() currently reconstructs the destination PMD in the huge zero page branch, which drops PMD state such as pmdspecial() on architectures with CONFIGARCHHASPTESPECIAL. As a result, vmnormalpagepmd() can treat the moved huge zero PMD as a normal page and corrupt its refcount.

Instead of reconstructing the PMD from the folio, derive the destination entry from srcpmdval after pmdphugeclearflush(), then handle the PMD metadata the same way movehugepmd() does for moved entries by marking it soft-dirty and clearing uffd-wp.

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

rxrpc: Fix RxGK token loading to check bounds

rxrpcpreparsexdryfsrxgk() reads the raw key length and ticket length from the XDR token as u32 values and passes each through roundup(x, 4) before using the rounded value for validation and allocation. When the raw length is >= 0xfffffffd, roundup() wraps to 0, so the bounds check and kzalloc both use 0 while the subsequent memcpy still copies the original ~4 GiB value, producing a heap buffer overflow reachable from an unprivileged addkey() call.

Fix this by:

(1) Rejecting raw key lengths above AFSTOKENGKKEYMAX and raw ticket lengths above AFSTOKENGKTOKENMAX before rounding, consistent with the caps that the RxKAD path already enforces via AFSTOKENRKTIXMAX.

(2) Sizing the flexible-array allocation from the validated raw key length via structsizet() instead of the rounded value.

(3) Caching the raw lengths so that the later field assignments and memcpy calls do not re-read from the token, eliminating a class of TOCTOU re-parse.

The control path (valid token with lengths within bounds) is unaffected.

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 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.

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

NFS: Fix filehandle bounds checking in nfsfhtodentry()

The function needs to check the minimal filehandle length before it can access the embedded filehandle.

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

nvmet: fix race in nvmetbiodone() leading to NULL pointer dereference

There is a race condition in nvmetbiodone() that can cause a NULL pointer dereference in blkcgroupbiostart():

1. nvmetbiodone() is called when a bio completes 2. nvmetreqcomplete() is called, which invokes req->ops->queueresponse(req) 3. The queueresponse callback can re-queue and re-submit the same request 4. The re-submission reuses the same inlinebio from nvmetreq 5. Meanwhile, nvmetreqbioput() (called after nvmetreqcomplete) invokes biouninit() for inlinebio, which sets bio->biblkg to NULL 6. The re-submitted bio enters submitbionoacctnocheck() 7. blkcgroupbiostart() dereferences bio->biblkg, causing a crash:

BUG: kernel NULL pointer dereference, address: 0000000000000028 #PF: supervisor read access in kernel mode RIP: 0010:blkcgroupbiostart+0x10/0xd0 Call Trace: submitbionoacctnocheck+0x44/0x250 nvmetbdevexecuterw+0x254/0x370 [nvmet] processonework+0x193/0x3c0 workerthread+0x281/0x3a0

Fix this by reordering nvmetbiodone() to call nvmetreqbioput() BEFORE nvmetreqcomplete(). This ensures the bio is cleaned up before the request can be re-submitted, preventing the race condition.

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

scsi: target: file: Use kzallocflex for aiocmd

The targetcorefile doesn't initialize the aiocmd->iocb for the kiwritestream. When a write command fdexecuterwaio() is executed, we may get a bogus kiwritestream value, causing unintended write failure status when checking iocb->kiwritestream > maxwritestreams in the block device.

Let's just use kzallocflex when allocating the aiocmd and let kiwritestream=0 to fix this issue.

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:

drm/amdgpu: fix use-after-free in amdgpuuserqsuspend+0x51a/0x5a0

[ +0.000020] BUG: KASAN: slab-use-after-free in amdgpuuserqsuspend+0x51a/0x5a0 [amdgpu] [ +0.000817] Read of size 8 at addr ffff88812eec8c58 by task amdpciunplug/1733

[ +0.000027] CPU: 10 UID: 0 PID: 1733 Comm: amdpciunplug Tainted: G W 6.14.0+ #2 [ +0.000009] Tainted: [W]=WARN [ +0.000003] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020 [ +0.000004] Call Trace: [ +0.000004] <TASK> [ +0.000003] dumpstacklvl+0x76/0xa0 [ +0.000011] printreport+0xce/0x600 [ +0.000009] ? srsoreturnthunk+0x5/0x5f [ +0.000006] ? kasancompletemodereportinfo+0x76/0x200 [ +0.000007] ? kasanaddrtoslab+0xd/0xb0 [ +0.000006] ? amdgpuuserqsuspend+0x51a/0x5a0 [amdgpu] [ +0.000707] kasanreport+0xbe/0x110 [ +0.000006] ? amdgpuuserqsuspend+0x51a/0x5a0 [amdgpu] [ +0.000541] asanreportload8noabort+0x14/0x30 [ +0.000005] amdgpuuserqsuspend+0x51a/0x5a0 [amdgpu] [ +0.000535] ? stopcpsch+0x396/0x600 [amdgpu] [ +0.000556] ? stopcpsch+0x429/0x600 [amdgpu] [ +0.000536] ? pfxamdgpuuserqsuspend+0x10/0x10 [amdgpu] [ +0.000536] ? srsoreturnthunk+0x5/0x5f [ +0.000004] ? kgd2kfdsuspend+0x132/0x1d0 [amdgpu] [ +0.000542] amdgpudevicefinihw+0x581/0xe90 [amdgpu] [ +0.000485] ? downwrite+0xbb/0x140 [ +0.000007] ? mutexunlockslowpath.constprop.0+0x317/0x360 [ +0.000005] ? pfxamdgpudevicefinihw+0x10/0x10 [amdgpu] [ +0.000482] ? kasancheckwrite+0x14/0x30 [ +0.000004] ? srsoreturnthunk+0x5/0x5f [ +0.000004] ? upwrite+0x55/0xb0 [ +0.000007] ? srsoreturnthunk+0x5/0x5f [ +0.000005] ? blockingnotifierchainunregister+0x6c/0xc0 [ +0.000008] amdgpudriverunloadkms+0x69/0x90 [amdgpu] [ +0.000484] amdgpupciremove+0x93/0x130 [amdgpu] [ +0.000482] pcideviceremove+0xae/0x1e0 [ +0.000008] deviceremove+0xc7/0x180 [ +0.000008] devicereleasedriverinternal+0x3d4/0x5a0 [ +0.000007] devicereleasedriver+0x12/0x20 [ +0.000004] pcistopbusdevice+0x104/0x150 [ +0.000006] pcistopandremovebusdevicelocked+0x1b/0x40 [ +0.000005] removestore+0xd7/0xf0 [ +0.000005] ? pfxremovestore+0x10/0x10 [ +0.000006] ? pfxcopyfromiter+0x10/0x10 [ +0.000006] ? pfxdevattrstore+0x10/0x10 [ +0.000006] devattrstore+0x3f/0x80 [ +0.000006] sysfskfwrite+0x125/0x1d0 [ +0.000004] ? srsoreturnthunk+0x5/0x5f [ +0.000005] ? kasancheckwrite+0x14/0x30 [ +0.000005] kernfsfopwriteiter+0x2ea/0x490 [ +0.000005] ? rwverifyarea+0x70/0x420 [ +0.000005] ? pfxkernfsfopwriteiter+0x10/0x10 [ +0.000006] vfswrite+0x90d/0xe70 [ +0.000005] ? srsoreturnthunk+0x5/0x5f [ +0.000005] ? pfxvfswrite+0x10/0x10 [ +0.000004] ? localclock+0x15/0x30 [ +0.000008] ? srsoreturnthunk+0x5/0x5f [ +0.000004] ? kasanslabfree+0x5f/0x80 [ +0.000005] ? srsoreturnthunk+0x5/0x5f [ +0.000004] ? kasancheckread+0x11/0x20 [ +0.000004] ? srsoreturnthunk+0x5/0x5f [ +0.000004] ? fdgetpos+0x1d3/0x500 [ +0.000007] ksyswrite+0x119/0x220 [ +0.000005] ? putname+0x1c/0x30 [ +0.000006] ? pfxksyswrite+0x10/0x10 [ +0.000007] x64syswrite+0x72/0xc0 [ +0.000006] x64syscall+0x18ab/0x26f0 [ +0.000006] dosyscall64+0x7c/0x170 [ +0.000004] ? srsoreturnthunk+0x5/0x5f [ +0.000004] ? pfxx64sysopenat+0x10/0x10 [ +0.000006] ? srsoreturnthunk+0x5/0x5f [ +0.000004] ? kasancheckread+0x11/0x20 [ +0.000003] ? srsoreturnthunk+0x5/0x5f [ +0.000004] ? fpregsassertstateconsistent+0x21/0xb0 [ +0.000006] ? srsoreturnthunk+0x5/0x5f [ +0.000004] ? syscallexittousermode+0x4e/0x240 [ +0.000005] ? srsoreturnthunk+0x5/0x5f [ +0.000004] ? dosyscall64+0x88/0x170 [ +0.000003] ? srsoreturnthunk+0x5/0x5f [ +0.000004] ? irqentryexit+0x43/0x50 [ +0.000004] ? srsoreturnthunk+0x5 ---truncated---

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

padata: Fix pd UAF once and for all

There is a race condition/UAF in padatareorder that goes back to the initial commit. A reference count is taken at the start of the process in padatadoparallel, and released at the end in padataserialworker.

This reference count is (and only is) required for padatareplace to function correctly. If padatareplace is never called then there is no issue.

In the function padatareorder which serves as the core of padata, as soon as padata is added to queue->serial.list, and the associated spin lock released, that padata may be processed and the reference count on pd would go away.

Fix this by getting the next padata before the squeue->serial lock is released.

In order to make this possible, simplify padatareorder by only calling it once the next padata arrives.

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

xen: fix UAF in dmabufexpfrompages()

[dmabuffd() fixes; no preferences regarding the tree it goes through - up to xen folks]

As soon as we'd inserted a file reference into descriptor table, another thread could close it. That's fine for the case when all we are doing is returning that descriptor to userland (it's a race, but it's a userland race and there's nothing the kernel can do about it). However, if we follow fdinstall() with any kind of access to objects that would be destroyed on close (be it the struct file itself or anything destroyed by its ->release()), we have a UAF.

dmabuffd() is a combination of reserving a descriptor and fdinstall(). gntdev dmabufexpfrompages() calls it and then proceeds to access the objects destroyed on close - starting with gntdevdmabuf itself.

Fix that by doing reserving descriptor before anything else and do fdinstall() only when everything had been set up.

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

staging: media: atomisp: Fix stack buffer overflow in gmingetvarint()

When gmingetconfigvar() calls efi.getvariable() and the EFI variable is larger than the expected buffer size, two behaviors combine to create a stack buffer overflow:

1. gmingetconfigvar() does not return the proper error code when efi.getvariable() fails. It returns the stale 'ret' value from earlier operations instead of indicating the EFI failure.

2. When efi.getvariable() returns EFIBUFFERTOOSMALL, it updates outlen to the required buffer size but writes no data to the output buffer. However, due to bug #1, gmingetvarint() believes the call succeeded.

The caller gmingetvarint() then performs: - Allocates val[CFGVARNAMEMAX + 1] (65 bytes) on stack - Calls gmingetconfigvar(dev, isgmin, var, val, &len) with len=64 - If EFI variable is >64 bytes, efi.getvariable() sets len=requiredsize - Due to bug #1, thinks call succeeded with len=requiredsize - Executes val[len] = 0, writing past end of 65-byte stack buffer

This creates a stack buffer overflow when EFI variables are larger than 64 bytes. Since EFI variables can be controlled by firmware or system configuration, this could potentially be exploited for code execution.

Fix the bug by returning proper error codes from gmingetconfigvar() based on EFI status instead of stale 'ret' value.

The gmingetvarint() function is called during device initialization for camera sensor configuration on Intel Bay Trail and Cherry Trail platforms using the atomisp camera stack.

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

drm/panthor: Fix UAF in panthorgemcreatewithhandle() debugfs code

The object is potentially already gone after the drmgemobjectput(). In general the object should be fully constructed before calling drmgemhandlecreate(), except the debugfs tracking uses a separate lock and list and separate flag to denotate whether the object is actually initialized.

Since I'm touching this all anyway simplify this by only adding the object to the debugfs when it's ready for that, which allows us to delete that separate flag. panthorgemdebugfsborm() already checks whether we've actually been added to the list or this is some error path cleanup.

v2: Fix build issues for !CONFIGDEBUGFS (Adrián)

v3: Add linebreak and remove outdated comment (Liviu)