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

media: v4l2-async: Fix error handling on steps after finding a match

Once an async connection is found to be matching with an fwnode, a sub-device may be registered (in case it wasn't already), its bound operation is called, ancillary links are created, the async connection is added to the sub-device's list of connections and removed from the global waiting connection list. Further on, the sub-device's possible own notifier is searched for possible additional matches.

Fix these specific issues:

- If v4l2asyncmatchnotify() failed before the sub-notifier handling, the async connection was unbound and its entry removed from the sub-device's async connection list. The latter part was also done in v4l2asyncmatchnotify().

- The async connection's sd field was only set after creating ancillary links in v4l2asyncmatchnotify(). It was however dereferenced in v4l2asyncunbindsubdevone(), which was called on error path of v4l2asyncmatchnotify() failure.

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

ksmbd: replace hardcoded hdr2len with offsetof() in smb2calcmaxoutbuflen()

After this commit (e2b76ab8b5c9 "ksmbd: add support for read compound"), response buffer management was changed to use dynamic iov array. In the new design, smb2calcmaxoutbuflen() expects the second argument (hdr2len) to be the offset of ->Buffer field in the response structure, not a hardcoded magic number. Fix the remaining call sites to use the correct offsetof() value.

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

net: bcmasp: fix double free of WoL irq

We do not need to free wolirq since it was instantiated with devmrequestirq(). So devres will free for us.

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

ksmbd: fix OOB write in QUERYINFO for compound requests

When a compound request such as READ + QUERYINFO(Security) is received, and the first command (READ) consumes most of the response buffer, ksmbd could write beyond the allocated buffer while building a security descriptor.

The root cause was that smb2getinfosec() checked buffer space using ppntsdsize from xattr, while buildsecdesc() often synthesized a significantly larger descriptor from POSIX ACLs.

This patch introduces smbaclsecdescscratchlen() to accurately compute the final descriptor size beforehand, performs proper buffer checking with smb2calcmaxoutbuflen(), and uses exact-sized allocation + iov pinning.

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

quota: Fix race of dquotscanactive() with quota deactivation

dquotscanactive() can race with quota deactivation in quotareleaseworkfn() like:

CPU0 (quotareleaseworkfn) CPU1 (dquotscanactive) ============================== ============================== spinlock(&dqlistlock); listreplaceinit( &releasingdquots, &rlshead); / dquot X on rlshead, dqcount == 0, DQACTIVEB still set / spinunlock(&dqlistlock); synchronizesrcu(&dquotsrcu); spinlock(&dqlistlock); listforeachentry(dquot, &inuselist, dqinuse) { / finds dquot X / dquotactive(X) -> true atomicinc(&X->dqcount); } spinunlock(&dqlistlock); spinlock(&dqlistlock); dquot = listfirstentry(&rlshead); WARNONONCE(atomicread(&dquot->dqcount));

The problem is not only a cosmetic one as under memory pressure the caller of dquotscanactive() can end up working on freed dquot.

Fix the problem by making sure the dquot is removed from releasing list when we acquire a reference to it.

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

ksmbd: fix potencial OOB in getfileallinfo() for compound requests

When a compound request consists of QUERYDIRECTORY + QUERYINFO (FILEALLINFORMATION) and the first command consumes nearly the entire maxtranssize, getfileallinfo() would blindly call smbConvertToUTF16() with PATHMAX, causing out-of-bounds write beyond the response buffer. In getfileallinfo(), there was a missing validation check for the client-provided OutputBufferLength before copying the filename into FileName field of the smb2fileallinfo structure. If the filename length exceeds the available buffer space, it could lead to potential buffer overflows or memory corruption during smbConvertToUTF16 conversion. This calculating the actual free buffer size using smb2calcmaxoutbuflen() and returning -EINVAL if the buffer is insufficient and updating smbConvertToUTF16 to use the actual filename length (clamped by PATHMAX) to ensure a safe copy operation.

bpf: Fix undefined behavior in interpreter sdiv/smod for INTMIN

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

Bluetooth: hciconn: fix potential UAF in setcigparamssync

hciconn lookup and field access must be covered by hdev lock in setcigparamssync, otherwise it's possible it is freed concurrently.

Take hdev lock to prevent hciconn from being deleted or modified concurrently. Just RCU lock is not suitable here, as we also want to avoid "tearing" in the configuration.

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

ksmbd: fix out-of-bounds write in smb2getea() EA alignment

smb2getea() applies 4-byte alignment padding via memset() after writing each EA entry. The bounds check on buffreelen is performed before the value memcpy, but the alignment memset fires unconditionally afterward with no check on remaining space.

When the EA value exactly fills the remaining buffer (buffreelen == 0 after value subtraction), the alignment memset writes 1-3 NUL bytes past the buffreelen boundary. In compound requests where the response buffer is shared across commands, the first command (e.g., READ) can consume most of the buffer, leaving a tight remainder for the QUERYINFO EA response. The alignment memset then overwrites past the physical kvmalloc allocation into adjacent kernel heap memory.

Add a bounds check before the alignment memset to ensure buffreelen can accommodate the padding bytes.

This is the same bug pattern fixed by commit beef2634f81f ("ksmbd: fix potencial OOB in getfileallinfo() for compound requests") and commit fda9522ed6af ("ksmbd: fix OOB write in QUERYINFO for compound requests"), both of which added bounds checks before unconditional writes in QUERYINFO response handlers.

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

xsk: validate MTU against usable frame size on bind

AFXDP bind currently accepts zero-copy pool configurations without verifying that the device MTU fits into the usable frame space provided by the UMEM chunk.

This becomes a problem since we started to respect tailroom which is subtracted from chunksize (among with headroom). 2k chunk size might not provide enough space for standard 1500 MTU, so let us catch such settings at bind time. Furthermore, validate whether underlying HW will be able to satisfy configured MTU wrt XSK's frame size multiplied by supported Rx buffer chain length (that is exposed via netdevice::xdpzcmaxsegs).

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

x86: shadow stacks: proper error handling for mmap lock

김영민 reports that shstkpopsigframe() doesn't check for errors from mmapreadlockkillable(), which is a silly oversight, and also shows that we haven't marked those functions with "mustcheck", which would have immediately caught it.

So let's fix both issues.

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

netconsole: avoid OOB reads, msg is not nul-terminated

msg passed to netconsole from the console subsystem is not guaranteed to be nul-terminated. Before recent commit 7eab73b18630 ("netconsole: convert to NBCON console infrastructure") the message would be placed in printksharedpbufs, a static global buffer, so KASAN had harder time catching OOB accesses. Now we see:

printk: console [netconext0] enabled BUG: KASAN: slab-out-of-bounds in string+0x1f7/0x240 Read of size 1 at addr ffff88813b6d4c00 by task pr/netconext0/594

CPU: 65 UID: 0 PID: 594 Comm: pr/netconext0 Not tainted 6.19.0-11754-g4246fd6547c9 Call Trace: kasanreport+0xe4/0x120 string+0x1f7/0x240 vsnprintf+0x655/0xba0 scnprintf+0xba/0x120 netconsolewrite+0x3fe/0xa10 nbconemitnextrecord+0x46e/0x860 nbconkthreadfunc+0x623/0x750

Allocated by task 1: nbconalloc+0x1ea/0x450 registerconsole+0x26b/0xe10 initnetconsole+0xbb0/0xda0

The buggy address belongs to the object at ffff88813b6d4000 which belongs to the cache kmalloc-4k of size 4096 The buggy address is located 0 bytes to the right of allocated 3072-byte region [ffff88813b6d4000, ffff88813b6d4c00)

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

x86/kexec: Disable KCOV instrumentation after loadsegments()

The loadsegments() function changes segment registers, invalidating GS base (which KCOV relies on for per-cpu data). When CONFIGKCOV is enabled, any subsequent instrumented C code call (e.g. nativegdtinvalidate()) begins crashing the kernel in an endless loop.

To reproduce the problem, it's sufficient to do kexec on a KCOV-instrumented kernel:

$ kexec -l /boot/otherKernel $ kexec -e

The real-world context for this problem is enabling crash dump collection in syzkaller. For this, the tool loads a panic kernel before fuzzing and then calls makedumpfile after the panic. This workflow requires both CONFIGKEXEC and CONFIGKCOV to be enabled simultaneously.

Adding safeguards directly to the KCOV fast-path (sanitizercovtracepc()) is also undesirable as it would introduce an extra performance overhead.

Disabling instrumentation for the individual functions would be too fragile, so disable KCOV instrumentation for the entire machinekexec64.c and physaddr.c. If coverage-guided fuzzing ever needs these components in the future, other approaches should be considered.

The problem is not relevant for 32 bit kernels as CONFIGKCOV is not supported there.

[ bp: Space out comment for better readability. ]

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

ceph: fix memory leaks in cephmdscbuildpath()

Add putname() calls to error code paths that did not free the "path" pointer obtained by getname(). If ownership of this pointer is not passed to the caller via pathinfo.path, the function must free it before returning.

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

OPP: add index check to assert to avoid buffer overflow in readfreq()

Pass the freq index to the assert function to make sure we do not read a freq out of the opp->rates[] table when called from the indexed variants: devpmoppfindfreqexactindexed() or devpmoppfindfreqceil/floorindexed().

Add a secondary parameter to the assert function, unused for assertsingleclk() then add assertclkindex() which will check for the clock index when called from the indexed() find functions.

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

gfs2: fix use-after-free in gfs2qddealloc

gfs2qddealloc(), called as an RCU callback from gfs2qddispose(), accesses the superblock object sdp through qd->qdsbd after freeing qd. It does so to decrement sdquotacount and wake up sdkillwait.

However, by the time the RCU callback runs, gfs2putsuper() may have already freed sdp via freesbd(). This can happen when gfs2quotacleanup() is called during unmount: it disposes of quota objects via callrcu() and then waits on sdkillwait with a 60-second timeout. If the timeout expires, or if gfs2glhashclear() triggers additional qdput() calls that schedule more RCU callbacks after the wait completes, gfs2putsuper() will proceed to free the superblock while RCU callbacks referencing it are still pending.

Add an rcubarrier() before freesbd() in gfs2putsuper() to ensure all pending RCU callbacks (including gfs2qddealloc) have completed before the superblock is freed.

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

pppasync: drop the errored frame instead of resetting its headroom

pppreceivenonmpframe() prepends a two-byte direction tag before running the pass/active BPF filters:

(be16 )skbpush(skb, 2) = htons(PPPFILTERINBOUNDTAG);

Nothing on the receive path guarantees those two bytes of headroom. The frame-error path in pppasync's processinputpacket() resets a reused skb's headroom to zero while claiming to restore it to a freshly allocated state - but a fresh skb from devallocskb() carries NETSKBPAD:

err: if (skb) { / make skb appear as freshly allocated / skbtrim(skb, 0); skbreserve(skb, - skbheadroom(skb)); }

ap->rpkt still points at that skb, so the next frame is reassembled into it with no headroom at all. A peer that sends a bad-FCS frame followed by one beginning ff 03 then leaves a single byte of headroom by the time the filter tag is pushed, which lands one byte below skb->head:

skbuff: skbunderpanic: len:49 put:2 head:ffff888003c10000 data:ffff888003c0ffff tail:0x30 end:0x640 dev:<NULL> kernel BUG at net/core/skbuff.c:214! RIP: 0010:skbpanic+0x13e/0x230 Call Trace: skbpush+0xbd/0x100 pppreceivenonmpframe+0x48a/0x1d10 pppinput+0x4e9/0x2f80 pppasyncprocess+0x2a/0xe0 taskletactioncommon+0x20f/0x8a0 handlesoftirqs+0x18e/0x590 Kernel panic - not syncing: Fatal exception in interrupt

Zeroing the headroom violates the NETSKBPAD guarantee that devallocskb() gives the rest of the receive path. Besides the filter panic above, when CCP compression is enabled pppdecompressframe() hands skb->data - 2 to ->decompress()/->incomp(), which then reads out of bounds before skb->head for the same reason.

Rather than restore the headroom, drop the errored frame - as pppsynctty already does on its error path - and clear ap->rpkt so the next frame is reassembled into a fresh skb with proper headroom. This is simpler and fixes both the filter under-panic and the CCP out-of-bounds read.

The original V1 of this patch made room in pppreceivenonmpframe() with skbcowhead(); Eric pointed out that fixing the root cause in the transport is the right approach.

Found by fuzzing the PPP receive path with a mutating peer on a pty; it is an interesting (remote) DoS: root configures PPP, the peer supplies two crashing frames. The reproducer (repro-ppp-skb.c, unchanged from v1) panics in about a second, and returns cleanly with this applied.

drivers/base/memory: set mem->altmap after successful device registration

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

net: bcmasp: fix txspbringfull() checking same slot cnt times

The loop initialised nextindex from intf->txspbindex on every iteration, so incrring() always produced the same result and only one slot was ever tested. Move the initialisation before the loop so each iteration advances nextindex and the function correctly checks that cnt consecutive descriptor slots are available before allowing a new transmission.

EDAC/devicesysfs: Use kstrtouint() for pollmsec to prevent truncation

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

wifi: mt76: mt7921: validate CLC firmware records

The CLC region is supplied by firmware, but the loader trusts the region count and each record length. A malformed image can make the region table pointer precede the firmware buffer, make the record loop fail to advance, or index phy->clc past its end. Validate the table and record bounds before dereferencing or copying.

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

powerpc/hv-gpci: fix preempt count leak in sysfs show paths

Four sysfs show() callbacks in hv-gpci take getcpuvar(hvgpcireqb) (which calls preemptdisable()) but only call the matching putcpuvar() on the error path under the 'out:' label. Every successful read leaks one preemptdisable():

processorbustopologyshow() processorconfigshow() affinitydomainviavirtualprocessorshow() affinitydomainviadomainshow()

(affinitydomainviapartitionshow() was already correct.)

On a CONFIGPREEMPT=y kernel, repeated reads raise preemptcount and eventually return to userspace with preemption still disabled. The next user-mode page fault then hits faulthandlerdisabled() == 1, gets forced to SIGSEGV, and the resulting coredump trips 'BUG: scheduling while atomic' in callusermodehelperexec -> waitforcompletionstate -> schedule:

BUG: scheduling while atomic: <task>/<pid>/0x00000004 ... schedulebug+0x6c/0x90 schedule+0x58c/0x13a0 schedule+0x48/0x1a0 scheduletimeout+0x104/0x170 waitforcompletionstate+0x16c/0x330 callusermodehelperexec+0x254/0x2d0 vfscoredump+0x1050/0x2590 getsignal+0xb9c/0xc80 donotifyresume+0xf8/0x470

Add an outsuccess label that calls putcpuvar() before returning the byte count, mirroring affinitydomainviapartitionshow().

block: skip syncblockdev() on surprise removal in bdevmarkdead()

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

smb/server: fix tree connection leak in smb2treeconnect()

See the procedure below:

smb2treeconnect ksmbdtreeconnconnect xastore(&sess->treeconns, treeconn->id, treeconn) ksmbdcounterinc(KSMBDCOUNTERTREECONNS) ksmbdsharetreeconninc(sc) ksmbdiovpinrsp // fail status.ret = KSMBDTREECONNSTATUSNOMEM // do not disconnect treeconn

Disconnect the new tree connection if ksmbdiovpinrsp() fails.

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

net: bcmasp: clear txcb->last before writing each descriptor

bcmaspxmit() only wrote txcb->last = true for the final fragment of an SKB; non-final fragments left the field untouched. If a descriptor slot was reused while it still held a stale true from a previous SKB (possible when txspbringfull() underreported fullness), bcmasptxreclaim() would see last == true mid-SKB and call devconsumeskbany() prematurely, freeing the skbuff while its remaining fragments were still in flight.

Unconditionally clear txcb->last before the conditional set so every descriptor slot starts from a known false state regardless of what a prior transmission left behind.

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

nvme-rdma: fix -EIO cleanup order in queuerq

On -EIO, the RDMA queuerq path reports a host path error and then still cleans up the command and unmaps the SQE DMA. The path error helper completes the request, so that is double cleanup and DMA unmap after the request is already complete.

Unmap the SQE first, then report the host path error. Skip the outer command cleanup on that path.

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

usb: typec: ucsi: unregister debugfs entries on teardown

ucsiregister() creates per-instance debugfs entries, but ucsiunregister() keeps them around until ucsidestroy().

Drivers like ucsiglink that unregister/register the same UCSI instance across remoteproc restart then try to create an already existing debugfs directory and log:

debugfs: 'pmicglink.ucsi.0' already exists in 'ucsi'

Unregister debugfs entries as part of ucsiunregister(), and clear ucsi->debugfs after freeing it so repeated unregister paths remain safe.

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

bonding: stop the device in bondsetupbyslave()

Commit 9eed321cde22 ("net: lapbether: only support ethernet devices") has been able to keep syzbot away from net/lapb, until today.

In the following splat [1], the issue is that a lapbether device has been created on a bonding device without members. Then adding a non ARPHRDETHER member forced the bonding master to change its type.

The fix is to make sure we call devclose() in bondsetupbyslave() so that the potential linked lapbether devices (or any other devices having assumptions on the physical device) are removed.

A similar bug has been addressed in commit 40baec225765 ("bonding: fix panic on non-ARPHRDETHER enslave failure")

[1] skbuff: skbunderpanic: text:ffff800089508810 len:44 put:40 head:ffff0000c78e7c00 data:ffff0000c78e7bea tail:0x16 end:0x140 dev:bond0 kernel BUG at net/core/skbuff.c:192 ! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 6007 Comm: syz-executor383 Not tainted 6.6.0-rc3-syzkaller-gbf6547d8715b #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skbpanic net/core/skbuff.c:188 [inline] pc : skbunderpanic+0x13c/0x140 net/core/skbuff.c:202 lr : skbpanic net/core/skbuff.c:188 [inline] lr : skbunderpanic+0x13c/0x140 net/core/skbuff.c:202 sp : ffff800096a06aa0 x29: ffff800096a06ab0 x28: ffff800096a06ba0 x27: dfff800000000000 x26: ffff0000ce9b9b50 x25: 0000000000000016 x24: ffff0000c78e7bea x23: ffff0000c78e7c00 x22: 000000000000002c x21: 0000000000000140 x20: 0000000000000028 x19: ffff800089508810 x18: ffff800096a06100 x17: 0000000000000000 x16: ffff80008a629a3c x15: 0000000000000001 x14: 1fffe00036837a32 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000201 x10: 0000000000000000 x9 : cb50b496c519aa00 x8 : cb50b496c519aa00 x7 : 0000000000000001 x6 : 0000000000000001 x5 : ffff800096a063b8 x4 : ffff80008e280f80 x3 : ffff8000805ad11c x2 : 0000000000000001 x1 : 0000000100000201 x0 : 0000000000000086 Call trace: skbpanic net/core/skbuff.c:188 [inline] skbunderpanic+0x13c/0x140 net/core/skbuff.c:202 skbpush+0xf0/0x108 net/core/skbuff.c:2446 ip6greheader+0xbc/0x738 net/ipv6/ip6gre.c:1384 devhardheader include/linux/netdevice.h:3136 [inline] lapbethdatatransmit+0x1c4/0x298 drivers/net/wan/lapbether.c:257 lapbdatatransmit+0x8c/0xb0 net/lapb/lapbiface.c:447 lapbtransmitbuffer+0x178/0x204 net/lapb/lapbout.c:149 lapbsendcontrol+0x220/0x320 net/lapb/lapbsubr.c:251 lapbdisconnectrequest+0x9c/0x17c net/lapb/lapbiface.c:326 lapbdeviceevent+0x288/0x4e0 net/lapb/lapbiface.c:492 notifiercallchain+0x1a4/0x510 kernel/notifier.c:93 rawnotifiercallchain+0x3c/0x50 kernel/notifier.c:461 callnetdevicenotifiersinfo net/core/dev.c:1970 [inline] callnetdevicenotifiersextack net/core/dev.c:2008 [inline] callnetdevicenotifiers net/core/dev.c:2022 [inline] devclosemany+0x1b8/0x3c4 net/core/dev.c:1508 devclosemany+0x1e0/0x470 net/core/dev.c:1559 devclose+0x174/0x250 net/core/dev.c:1585 lapbethdeviceevent+0x2e4/0x958 drivers/net/wan/lapbether.c:466 notifiercallchain+0x1a4/0x510 kernel/notifier.c:93 rawnotifiercallchain+0x3c/0x50 kernel/notifier.c:461 callnetdevicenotifiersinfo net/core/dev.c:1970 [inline] callnetdevicenotifiersextack net/core/dev.c:2008 [inline] callnetdevicenotifiers net/core/dev.c:2022 [inline] devclosemany+0x1b8/0x3c4 net/core/dev.c:1508 devclosemany+0x1e0/0x470 net/core/dev.c:1559 devclose+0x174/0x250 net/core/dev.c:1585 bondenslave+0x2298/0x30cc drivers/net/bonding/bondmain.c:2332 bonddoioctl+0x268/0xc64 drivers/net/bonding/bondmain.c:4539 devifsioc+0x754/0x9ac devioctl+0x4d8/0xd34 net/core/devioctl.c:786 sockdoioctl+0x1d4/0x2d0 net/socket.c:1217 sockioctl+0x4e8/0x834 net/socket.c:1322 vfsioctl fs/ioctl.c:51 [inline] do ---truncated---

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

usb: typec: tcpm/tcpcimaxim: validate header NDO against RXBYTECNT

A broken/malicious port can transmit a CRC-valid frame whose header advertises up to seven data objects but whose body carries fewer than that. Check for this, and rightfully reject the message, instead of reading from uninitialized stack memory.

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

efi: Allocate runtime workqueue before ACPI init

Since commit

5894cf571e14 ("acpi/prmt: Use EFI runtime sandbox to invoke PRM handlers")

ACPI PRM calls are delegated to a workqueue which runs in a kernel thread, making it easier to detect and mitigate faulting memory accesses performed by the firmware.

Rafael reports that such PRM accesses may occur before efisubsysinit() executes, which is where the workqueue is allocated, leading to NULL pointer dereferences. Since acpiinit() [which triggers the early PRM accesses] executes as a subsysinitcall() as well, and has its own dependencies that may be sensitive to initcall ordering, deferring acpiinit() is not an option.

So instead, split off the workqueue allocation into its own postcore initcall, as this is the only missing piece to allow EFI runtime calls to be made. This ensures that EFI runtime call (including PRM calls) are accessible to all code running at subsysinitcall() level.