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

net: kcm: Fix race condition in kcmunattach()

syzbot found a race condition when kcmunattach(psock) and kcmrelease(kcm) are executed at the same time.

kcmunattach() is missing a check of the flag kcm->txstopped before calling queuework().

If the kcm has a reserved psock, kcmunattach() might get executed between cancelworksync() and unreservepsock() in kcmrelease(), requeuing kcm->txwork right before kcm gets freed in kcmdone().

Remove kcm->txstopped and replace it by the less error-prone disableworksync().

drm/amd/pm: fix null pointer access

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:

xfrm: Duplicate SPI Handling

The issue originates when Strongswan initiates an XFRMMSGALLOCSPI Netlink message, which triggers the kernel function xfrmallocspi(). This function is expected to ensure uniqueness of the Security Parameter Index (SPI) for inbound Security Associations (SAs). However, it can return success even when the requested SPI is already in use, leading to duplicate SPIs assigned to multiple inbound SAs, differentiated only by their destination addresses.

This behavior causes inconsistencies during SPI lookups for inbound packets. Since the lookup may return an arbitrary SA among those with the same SPI, packet processing can fail, resulting in packet drops.

According to RFC 4301 section 4.4.2 , for inbound processing a unicast SA is uniquely identified by the SPI and optionally protocol.

Reproducing the Issue Reliably: To consistently reproduce the problem, restrict the available SPI range in charon.conf : spimin = 0x10000000 spimax = 0x10000002 This limits the system to only 2 usable SPI values. Next, create more than 2 Child SA. each using unique pair of src/dst address. As soon as the 3rd Child SA is initiated, it will be assigned a duplicate SPI, since the SPI pool is already exhausted. With a narrow SPI range, the issue is consistently reproducible. With a broader/default range, it becomes rare and unpredictable.

Current implementation: xfrmspihash() lookup function computes hash using daddr, proto, and family. So if two SAs have the same SPI but different destination addresses, then they will: a. Hash into different buckets b. Be stored in different linked lists (byspi + h) c. Not be seen in the same hlistforeachentryrcu() iteration. As a result, the lookup will result in NULL and kernel allows that Duplicate SPI

Proposed Change: xfrmstatelookupspiproto() does a truly global search - across all states, regardless of hash bucket and matches SPI and proto.

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

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

net/mlx5e: Remove skb secpath if xfrm state is not found

Hardware returns a unique identifier for a decrypted packet's xfrm state, this state is looked up in an xarray. However, the state might have been freed by the time of this lookup.

Currently, if the state is not found, only a counter is incremented. The secpath (sp) extension on the skb is not removed, resulting in sp->len becoming 0.

Subsequently, functions like xfrmpolicycheck() attempt to access fields such as xfrminputstate(skb)->xso.type (which dereferences sp->xvec[sp->len - 1]) without first validating sp->len. This leads to a crash when dereferencing an invalid state pointer.

This patch prevents the crash by explicitly removing the secpath extension from the skb if the xfrm state is not found after hardware decryption. This ensures downstream functions do not operate on a zero-length secpath.

BUG: unable to handle page fault for address: ffffffff000002c8 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 282e067 P4D 282e067 PUD 0 Oops: Oops: 0000 [#1] SMP CPU: 12 UID: 0 PID: 0 Comm: swapper/12 Not tainted 6.15.0-rc7forupstreammindebug202505272244 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:xfrmpolicycheck+0x61a/0xa30 Code: b6 77 7f 83 e6 02 74 14 4d 8b af d8 00 00 00 41 0f b6 45 05 c1 e0 03 48 98 49 01 c5 41 8b 45 00 83 e8 01 48 98 49 8b 44 c5 10 <0f> b6 80 c8 02 00 00 83 e0 0c 3c 04 0f 84 0c 02 00 00 31 ff 80 fa RSP: 0018:ffff88885fb04918 EFLAGS: 00010297 RAX: ffffffff00000000 RBX: 0000000000000002 RCX: 0000000000000000 RDX: 0000000000000002 RSI: 0000000000000002 RDI: 0000000000000000 RBP: ffffffff8311af80 R08: 0000000000000020 R09: 00000000c2eda353 R10: ffff88812be2bbc8 R11: 000000001faab533 R12: ffff88885fb049c8 R13: ffff88812be2bbc8 R14: 0000000000000000 R15: ffff88811896ae00 FS: 0000000000000000(0000) GS:ffff8888dca82000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffff000002c8 CR3: 0000000243050002 CR4: 0000000000372eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> ? trytowakeup+0x108/0x4c0 ? udp4liblookup2+0xbe/0x150 ? udpliblportinuse+0x100/0x100 ? udp4liblookup+0x2b0/0x410 xfrmpolicycheck2.constprop.0+0x11e/0x130 udpqueuercvoneskb+0x1d/0x530 udpunicastrcvskb+0x76/0x90 udp4librcv+0xa64/0xe90 ipprotocoldeliverrcu+0x20/0x130 iplocaldeliverfinish+0x75/0xa0 iplocaldeliver+0xc1/0xd0 ? ipprotocoldeliverrcu+0x130/0x130 ipsublistrcv+0x1f9/0x240 ? iprcvfinishcore+0x430/0x430 iplistrcv+0xfc/0x130 netifreceiveskblistcore+0x181/0x1e0 netifreceiveskblistinternal+0x200/0x360 ? mlx5ebuildrxskb+0x1bc/0xda0 [mlx5core] groreceiveskb+0xfd/0x210 mlx5ehandlerxcqempwrq+0x141/0x280 [mlx5core] mlx5epollrxcq+0xcc/0x8e0 [mlx5core] ? mlx5ehandlerxdim+0x91/0xd0 [mlx5core] mlx5enapipoll+0x114/0xab0 [mlx5core] napipoll+0x25/0x170 netrxaction+0x32d/0x3a0 ? mlx5eqcompint+0x8d/0x280 [mlx5core] ? notifiercallchain+0x33/0xa0 handlesoftirqs+0xda/0x250 irqexitrcu+0x6d/0xc0 commoninterrupt+0x81/0xa0 </IRQ>

block: avoid possible overflow for chunksectors check in blkstacklimits()

fs: Prevent file descriptor table allocations exceeding INTMAX

bpf: Forget ranges when refining tnum after JSET

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

netlink: avoid infinite retry looping in netlinkunicast()

netlinkattachskb() checks for the socket's read memory allocation constraints. Firstly, it has:

rmem < READONCE(sk->skrcvbuf)

to check if the just increased rmem value fits into the socket's receive buffer. If not, it proceeds and tries to wait for the memory under:

rmem + skb->truesize > READONCE(sk->skrcvbuf)

The checks don't cover the case when skb->truesize + sk->skrmemalloc is equal to sk->skrcvbuf. Thus the function neither successfully accepts these conditions, nor manages to reschedule the task - and is called in retry loop for indefinite time which is caught as:

rcu: INFO: rcusched self-detected stall on CPU rcu: 0-....: (25999 ticks this GP) idle=ef2/1/0x4000000000000000 softirq=262269/262269 fqs=6212 (t=26000 jiffies g=230833 q=259957) NMI backtrace for cpu 0 CPU: 0 PID: 22 Comm: kauditd Not tainted 5.10.240 #68 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc42 04/01/2014 Call Trace: <IRQ> dumpstack lib/dumpstack.c:120 nmicpubacktrace.cold lib/nmibacktrace.c:105 nmitriggercpumaskbacktrace lib/nmibacktrace.c:62 rcudumpcpustacks kernel/rcu/treestall.h:335 rcuschedclockirq.cold kernel/rcu/tree.c:2590 updateprocesstimes kernel/time/timer.c:1953 tickschedhandle kernel/time/tick-sched.c:227 tickschedtimer kernel/time/tick-sched.c:1399 hrtimerrunqueues kernel/time/hrtimer.c:1652 hrtimerinterrupt kernel/time/hrtimer.c:1717 sysvecapictimerinterrupt arch/x86/kernel/apic/apic.c:1113 asmcallirqonstack arch/x86/entry/entry64.S:808 </IRQ>

netlinkattachskb net/netlink/afnetlink.c:1234 netlinkunicast net/netlink/afnetlink.c:1349 kauditdsendqueue kernel/audit.c:776 kauditdthread kernel/audit.c:897 kthread kernel/kthread.c:328 retfromfork arch/x86/entry/entry64.S:304

Restore the original behavior of the check which commit in Fixes accidentally missed when restructuring the code.

Found by Linux Verification Center (linuxtesting.org).

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

net: usb: asixdevices: add phymask for ax88772 mdio bus

Without setting phymask for ax88772 mdio bus, current driver may create at most 32 mdio phy devices with phy address range from 0x00 ~ 0x1f. DLink DUB-E100 H/W Ver B1 is such a device. However, only one main phy device will bind to net phy driver. This is creating issue during system suspend/resume since phypollingmode() in phystatemachine() will directly deference member of phydev->drv for non-main phy devices. Then NULL pointer dereference issue will occur. Due to only external phy or internal phy is necessary, add phymask for ax88772 mdio bus to workarnoud the issue.

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

netfilter: ctnetlink: fix refcount leak on table dump

There is a reference count leak in ctnetlinkdumptable(): if (res < 0) { nfconntrackget(&ct->ctgeneral); // HERE cb->args[1] = (unsigned long)ct; ...

While its very unlikely, its possible that ct == last. If this happens, then the refcount of ct was already incremented. This 2nd increment is never undone.

This prevents the conntrack object from being released, which in turn keeps prevents cnet->count from dropping back to 0.

This will then block the netns dismantle (or conntrack rmmod) as nfconntrackcleanupnetlist() will wait forever.

This can be reproduced by running conntrackresize.sh selftest in a loop. It takes ~20 minutes for me on a preemptible kernel on average before I see a runaway kworker spinning in nfconntrackcleanupnetlist.

One fix would to change this to: if (res < 0) { if (ct != last) nfconntrackget(&ct->ctgeneral);

But this reference counting isn't needed in the first place. We can just store a cookie value instead.

A followup patch will do the same for ctnetlinkexpdumptable, it looks to me as if this has the same problem and like ctnetlinkdumptable, we only need a 'skip hint', not the actual object so we can apply the same cookie strategy there as well.

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

rcu/nocb: Fix possible invalid rdp's->nocbcbkthread pointer access

In the preparation stage of CPU online, if the corresponding the rdp's->nocbcbkthread does not exist, will be created, there is a situation where the rdp's rcuop kthreads creation fails, and then de-offload this CPU's rdp, does not assign this CPU's rdp->nocbcbkthread pointer, but this rdp's->nocbgprdp and rdp's->rdpgp->nocbgpkthread is still valid.

This will cause the subsequent re-offload operation of this offline CPU, which will pass the conditional check and the kthreadunpark() will access invalid rdp's->nocbcbkthread pointer.

This commit therefore use rdp's->nocbgpkthread instead of rdpgp's->nocbgpkthread for safety check.

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

mm/ptdump: take the memory hotplug lock inside ptdumpwalkpgd()

Memory hot remove unmaps and tears down various kernel page table regions as required. The ptdump code can race with concurrent modifications of the kernel page tables. When leaf entries are modified concurrently, the dump code may log stale or inconsistent information for a VA range, but this is otherwise not harmful.

But when intermediate levels of kernel page table are freed, the dump code will continue to use memory that has been freed and potentially reallocated for another purpose. In such cases, the ptdump code may dereference bogus addresses, leading to a number of potential problems.

To avoid the above mentioned race condition, platforms such as arm64, riscv and s390 take memory hotplug lock, while dumping kernel page table via the sysfs interface /sys/kernel/debug/kernelpagetables.

Similar race condition exists while checking for pages that might have been marked W+X via /sys/kernel/debug/kernelpagetables/checkwxpages which in turn calls ptdumpcheckwx(). Instead of solving this race condition again, let's just move the memory hotplug lock inside generic ptdumpcheckwx() which will benefit both the scenarios.

Drop getonlinemems() and putonlinemems() combination from all existing platform ptdump code paths.

eventpoll: Fix semi-unbounded recursion

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

crypto: ccp - Do not initialize SNP for ioctl(SNPCONFIG)

Sashiko notes:

if SEV initialization fails and KVM is actively running normal VMs, could a userspace process trigger this code path via /dev/sev ioctls (e.g., SEVPDHGEN) and zero out MSRVMHSAVEPA globally? Would the next VMRUN execution for an active VM trigger a general protection fault and crash the host?

Refuse to re-try initialization if SNP is not already initialized for SNPCONFIG.

This is technically an ABI break: before if SNP initialization failed it could be transparently retriggered by this ioctl, and if no VMs were running, everything worked fine. Hopefully this is enough of a corner case that nobody will notice, but someone does, there are a few options:

do something like symbolget() for kvm and refuse to initialize if KVM is loaded check each cpu's HSAVEPA for non-zero data before re-initializing once initialization has failed, continue to refuse to initialize until the ccp module is unloaded

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

crypto: ccp - Do not initialize SNP for ioctl(SNPVLEKLOAD)

Sashiko notes:

if SEV initialization fails and KVM is actively running normal VMs, could a userspace process trigger this code path via /dev/sev ioctls (e.g., SEVPDHGEN) and zero out MSRVMHSAVEPA globally? Would the next VMRUN execution for an active VM trigger a general protection fault and crash the host?

The SEV firmware docs for SNPVLEKLOAD note:

On SNPSHUTDOWN, the VLEK is deleted.

That is, the initialization/shutdown wrapper here is pointless, because the firmware immediately throws away the key anyway. Instead, refuse to do anything if SNP has not been previously initialized.

This is an ABI break: before, this was a no-op and almost certainly a mistake by userspace, and now it returns -ENODEV. ABI compatibility could be maintained here by simply returning 0 in the check instead.

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

crypto: ccp - Do not initialize SNP for ioctl(SNPCOMMIT)

Sashiko notes:

if SEV initialization fails and KVM is actively running normal VMs, could a userspace process trigger this code path via /dev/sev ioctls (e.g., SEVPDHGEN) and zero out MSRVMHSAVEPA globally? Would the next VMRUN execution for an active VM trigger a general protection fault and crash the host?

The SNPCOMMIT command does not require the firmware to be in any particular state. Skip initializing it if it was previously uninitialized.

The SEV-SNP firmware specification doc 56860 does not mention SNPCOMMIT in Table 5 as a command that is allowed in the UNINIT state, but it is in fact allowed and a future documentation update will reflect that.

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

crypto: ccp - Do not initialize SNP for SEV ioctls

Sashiko notes:

if SEV initialization fails and KVM is actively running normal VMs, could a userspace process trigger this code path via /dev/sev ioctls (e.g., SEVPDHGEN) and zero out MSRVMHSAVEPA globally? Would the next VMRUN execution for an active VM trigger a general protection fault and crash the host?

sevmovetoinitstate() is called for ioctls requiring only SEV firmware: SEVPEKGEN, SEVPDHGEN, SEVPEKCSR, SEVPEKCERTIMPORT, and SEVPDHCERTEXPORT. After the firmware command, it does SEVSHUTDOWN on the SEV firmware. Since these commands do not require SNP to be initialized, skip it by calling sevplatforminitlocked() which only initializes the SEV firmware. This way SNP is not Initialized at all, and HSAVEPA is not cleared.

The previous code saved any SEV initialization firmware error to initargs.error and then threw it away and hardcoded the return value of INVALIDPLATFORMSTATE regardless of the real firmware error. This patch changes it to surface the underlying error, which is hopefully both more useful and doesn't cause any problems.

Note that it is still safe to call sevfirmwareshutdown() directly: it calls sevsnpshutdownlocked(), which skips SNP shutdown if SNP was not initialized.

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

crypto: chacha20poly1305 - validate poly1305 template argument

chachapolycreate() still accepts the compatibility poly1305 parameter in the template name, but it assumes the second template argument is always present and immediately passes it to strcmp().

When the argument is missing, cryptoattralgname() returns an error pointer. Check for that before comparing the name so malformed template instantiations fail with an error instead of dereferencing the error pointer in strcmp().

This matches the surrounding Crypto API template pattern where cryptoattralgname() results are validated before string-specific use.

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

ovpn: respect peer refcount in CMDNEWPEER error path

ovpnnlpeernewdoit()'s error path calls ovpnpeerrelease() directly rather than ovpnpeerput(), bypassing the kref. The accompanying comment ("peer was not yet hashed, thus it is not used in any context") holds for UDP but not for TCP.

For UDP, the ovpnsocket union uses the .ovpn arm and never points back at a peer; UDP encaprecv looks up peers via the not-yet-populated hashtables, so the new peer is unreachable until ovpnpeeradd() publishes it.

For TCP, ovpnsocketnew() sets ovpnsock->peer and ovpntcpsocketattach() publishes ovpnsock via rcuassignskuserdata(). From that moment until ovpnsocketrelease() detaches in the error path, the TCP fd is fully wired: userspace recvmsg / sendmsg / close / poll on the fd, as well as the strparser-driven ovpntcprcv() path, can reach the peer through skuserdata -> ovpnsock->peer and bump its refcount via ovpnpeerhold().

ovpntcpsocketwaitfinish() (called inside ovpnsocketrelease()) drains strparser and the tx work, but does not synchronize with userspace syscall callers that already hold a peer reference. If ovpnnlpeermodify() or ovpnpeeradd() returns an error while such a caller is in flight - notably an ovpntcprecvmsg() blocked in skbrecvdatagram() on peer->tcp.userqueue - the direct ovpnpeerrelease() destroys the peer while the caller still holds the reference, and the eventual ovpnpeerput() from that caller operates on freed memory.

Replace the direct destructor call with ovpnpeerput() so the kref correctly defers destruction until the last reference is dropped. In the common case where no concurrent user is present, behaviour is unchanged: the kref hits zero immediately and ovpnpeerreleasekref() runs the same destructor.

With this conversion ovpnpeerrelease() has no callers outside peer.c - ovpnpeerreleasekref() in the same translation unit is the only remaining user - so make it static and drop its declaration from peer.h.

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:

NFS: Fix filehandle bounds checking in nfsfhtodentry()

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

ALSA: usb-audio: Validate UAC3 cluster segment descriptors

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

tls: handle data disappearing from under the TLS ULP

TLS expects that it owns the receive queue of the TCP socket. This cannot be guaranteed in case the reader of the TCP socket entered before the TLS ULP was installed, or uses some non-standard read API (eg. zerocopy ones). Replace the WARNON() and a buggy early exit (which leaves anchor pointing to a freed skb) with real error handling. Wipe the parsing state and tell the reader to retry.

We already reload the anchor every time we (re)acquire the socket lock, so the only condition we need to avoid is an out of bounds read (not having enough bytes in the socket for previously parsed record len).

If some data was read from under TLS but there's enough in the queue we'll reload and decrypt what is most likely not a valid TLS record. Leading to some undefined behavior from TLS perspective (corrupting a stream? missing an alert? missing an attack?) but no kernel crash should take place.

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:

media: venus: Fix OOB read due to missing payload bound check

Currently, The eventseqchanged() handler processes a variable number of properties sent by the firmware. The number of properties is indicated by the firmware and used to iterate over the payload. However, the payload size is not being validated against the actual message length.

This can lead to out-of-bounds memory access if the firmware provides a property count that exceeds the data available in the payload. Such a condition can result in kernel crashes or potential information leaks if memory beyond the buffer is accessed.

Fix this by properly validating the remaining size of the payload before each property access and updating bounds accordingly as properties are parsed.

This ensures that property parsing is safely bounded within the received message buffer and protects against malformed or malicious firmware behavior.

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

drm/amdgpu: Refactor amdgpugemvaioctl for Handling Last Fence Update and Timeline Management v4