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

netfilter: socket: Lookup orig tuple for IPv6 SNAT

nfsklookupslowv4 does the conntrack lookup for IPv4 packets to restore the original 5-tuple in case of SNAT, to be able to find the right socket (if any). Then socketmatch() can correctly check whether the socket was transparent.

However, the IPv6 counterpart (nfsklookupslowv6) lacks this conntrack lookup, making xtsocket fail to match on the socket when the packet was SNATed. Add the same logic to nfsklookupslowv6.

IPv6 SNAT is used in Kubernetes clusters for pod-to-world packets, as pods' addresses are in the fd00::/8 ULA subnet and need to be replaced with the node's external address. Cilium leverages Envoy to enforce L7 policies, and Envoy uses transparent sockets. Cilium inserts an iptables prerouting rule that matches on -m socket --transparent and redirects the packets to localhost, but it fails to match SNATed IPv6 packets due to that missing conntrack lookup.

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

RDMA/erdma: Prevent use-after-free in erdmaacceptnewconn()

After the erdmacepput(newcep) being called, newcep will be freed, and the following dereference will cause a UAF problem. Fix this issue.

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

netfilter: nfnetlinkqueue: Initialize ctx to avoid memory allocation error

It is possible that ctx in nfqnlbuildpacketmessage() could be used before it is properly initialize, which is only initialized by nfqnlgetsksecctx().

This patch corrects this problem by initializing the lsmctx to a safe value when it is declared.

This is similar to the commit 35fcac7a7c25 ("audit: Initialize lsmctx to avoid memory allocation error").

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

smb: client: fix UAF in decryption with multichannel

After commit f7025d861694 ("smb: client: allocate crypto only for primary server") and commit b0abcd65ec54 ("smb: client: fix UAF in async decryption"), the channels started reusing AEAD TFM from primary channel to perform synchronous decryption, but that can't done as there could be multiple cifsd threads (one per channel) simultaneously accessing it to perform decryption.

This fixes the following KASAN splat when running fstest generic/249 with 'vers=3.1.1,multichannel,maxchannels=4,seal' against Windows Server 2022:

BUG: KASAN: slab-use-after-free in gf128mul4klle+0xba/0x110 Read of size 8 at addr ffff8881046c18a0 by task cifsd/986 CPU: 3 UID: 0 PID: 986 Comm: cifsd Not tainted 6.15.0-rc1 #1 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc41 04/01/2014 Call Trace: <TASK> dumpstacklvl+0x5d/0x80 printreport+0x156/0x528 ? gf128mul4klle+0xba/0x110 ? virtaddrvalid+0x145/0x300 ? physaddr+0x46/0x90 ? gf128mul4klle+0xba/0x110 kasanreport+0xdf/0x1a0 ? gf128mul4klle+0xba/0x110 gf128mul4klle+0xba/0x110 ghashupdate+0x189/0x210 shashahashupdate+0x295/0x370 ? pfxshashahashupdate+0x10/0x10 ? pfxshashahashupdate+0x10/0x10 ? pfxextractitertosg+0x10/0x10 ? kmalloclargenode+0x10e/0x180 ? asanmemset+0x23/0x50 cryptoahashupdate+0x3c/0xc0 gcmhashassocremaincontinue+0x93/0xc0 cryptmessage+0xe09/0xec0 [cifs] ? pfxcryptmessage+0x10/0x10 [cifs] ? rawspinunlock+0x23/0x40 ? pfxcifsreadvfromsocket+0x10/0x10 [cifs] decryptrawdata+0x229/0x380 [cifs] ? pfxdecryptrawdata+0x10/0x10 [cifs] ? pfxcifsreaditerfromsocket+0x10/0x10 [cifs] smb3receivetransform+0x837/0xc80 [cifs] ? pfxsmb3receivetransform+0x10/0x10 [cifs] ? pfxmightresched+0x10/0x10 ? pfxsmb3istransformhdr+0x10/0x10 [cifs] cifsdemultiplexthread+0x692/0x1570 [cifs] ? pfxcifsdemultiplexthread+0x10/0x10 [cifs] ? rcuiswatching+0x20/0x50 ? rculockdepcurrentcpuonline+0x62/0xb0 ? findheldlock+0x32/0x90 ? kvmschedclockread+0x11/0x20 ? localclocknoinstr+0xd/0xd0 ? traceirqenable.constprop.0+0xa8/0xe0 ? pfxcifsdemultiplexthread+0x10/0x10 [cifs] kthread+0x1fe/0x380 ? kthread+0x10f/0x380 ? pfxkthread+0x10/0x10 ? localclocknoinstr+0xd/0xd0 ? retfromfork+0x1b/0x60 ? localclock+0x15/0x30 ? lockrelease+0x29b/0x390 ? rcuiswatching+0x20/0x50 ? pfxkthread+0x10/0x10 retfromfork+0x31/0x60 ? pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK>

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

ice: fix Rx page leak on multi-buffer frames

The iceputrxmbuf() function handles calling iceputrxbuf() for each buffer in the current frame. This function was introduced as part of handling multi-buffer XDP support in the ice driver.

It works by iterating over the buffers from firstdesc up to 1 plus the total number of fragments in the frame, cached from before the XDP program was executed.

If the hardware posts a descriptor with a size of 0, the logic used in iceputrxmbuf() breaks. Such descriptors get skipped and don't get added as fragments in iceaddxdpfrag. Since the buffer isn't counted as a fragment, we do not iterate over it in iceputrxmbuf(), and thus we don't call iceputrxbuf().

Because we don't call iceputrxbuf(), we don't attempt to re-use the page or free it. This leaves a stale page in the ring, as we don't increment nexttoalloc.

The icereuserxpage() assumes that the nexttoalloc has been incremented properly, and that it always points to a buffer with a NULL page. Since this function doesn't check, it will happily recycle a page over the top of the nexttoalloc buffer, losing track of the old page.

Note that this leak only occurs for multi-buffer frames. The iceputrxmbuf() function always handles at least one buffer, so a single-buffer frame will always get handled correctly. It is not clear precisely why the hardware hands us descriptors with a size of 0 sometimes, but it happens somewhat regularly with "jumbo frames" used by 9K MTU.

To fix iceputrxmbuf(), we need to make sure to call iceputrxbuf() on all buffers between firstdesc and nexttoclean. Borrow the logic of a similar function in i40e used for this same purpose. Use the same logic also in icegetpgcnts().

Instead of iterating over just the number of fragments, use a loop which iterates until the current index reaches to the nexttoclean element just past the current frame. Unlike i40e, the iceputrxmbuf() function does call iceputrxbuf() on the last buffer of the frame indicating the end of packet.

For non-linear (multi-buffer) frames, we need to take care when adjusting the pagecntbias. An XDP program might release fragments from the tail of the frame, in which case that fragment page is already released. Only update the pagecntbias for the first descriptor and fragments still remaining post-XDP program. Take care to only access the shared info for fragmented buffers, as this avoids a significant cache miss.

The xdpxmit value only needs to be updated if an XDP program is run, and only once per packet. Drop the xdpxmit pointer argument from iceputrxmbuf(). Instead, set xdpxmit in the icecleanrxirq() function directly. This avoids needing to pass the argument and avoids an extra bit-wise OR for each buffer in the frame.

Move the increment of the ntc local variable to ensure its updated before all calls to icegetpgcnts() or iceputrxmbuf(), as the loop logic requires the index of the element just after the current frame.

Now that we use an index pointer in the ring to identify the packet, we no longer need to track or cache the number of fragments in the rxring.

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

mm: call ->freefolio() directly in foliounmapinvalidate()

We can only call filemapfreefolio() if we have a reference to (or hold a lock on) the mapping. Otherwise, we've already removed the folio from the mapping so it no longer pins the mapping and the mapping can be removed, causing a use-after-free when accessing mapping->aops.

Follow the same pattern as removemapping() and load the freefolio function pointer before dropping the lock on the mapping. That lets us make filemapfreefolio() static as this was the only caller outside filemap.c.

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

kthread: consolidate kthread exit paths to prevent use-after-free

Guillaume reported crashes via corrupted RCU callback function pointers during KUnit testing. The crash was traced back to the pidfs rhashtable conversion which replaced the 24-byte rbnode with an 8-byte rhashhead in struct pid, shrinking it from 160 to 144 bytes.

struct kthread (without CONFIGBLKCGROUP) is also 144 bytes. With CONFIGSLABMERGEDEFAULT and SLABHWCACHEALIGN both round up to 192 bytes and share the same slab cache. struct pid.rcu.func and struct kthread.affinitynode both sit at offset 0x78.

When a kthread exits via maketaskdead() it bypasses kthreadexit() and misses the affinitynode cleanup. freekthreadstruct() frees the memory while the node is still linked into the global kthreadaffinitylist. A subsequent listdel() by another kthread writes through dangling list pointers into the freed and reused memory, corrupting the pid's rcu.func pointer.

Instead of patching freekthreadstruct() to handle the missed cleanup, consolidate all kthread exit paths. Turn kthreadexit() into a macro that calls doexit() and add kthreaddoexit() which is called from doexit() for any task with PFKTHREAD set. This guarantees that kthread-specific cleanup always happens regardless of the exit path - maketaskdead(), direct doexit(), or kthreadexit().

Replace tokthread() with a new tskiskthread() accessor in the public header. Export doexit() since module code using the kthreadexit() macro now needs it directly.

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

xfrm: iptfs: preserve shared-frag marker in iptfsconsumefrags()

iptfsconsumefrags() transfers paged fragments from one socket buffer to another but fails to propagate the SKBFLSHAREDFRAG flag. This is the same class of bug that was fixed in skbtrycoalesce() for CVE-2026-46300: when fragments backed by read-only page-cache pages are merged, the marker indicating their shared nature must be preserved so that ESP can decide correctly whether in-place encryption is safe.

Apply the same two-line fix used in skbtrycoalesce() to iptfsconsumefrags().

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

netfs: Fix cancellation of a DIO and single read subrequests

When the preparation of a new subrequest for a read fails, if the subrequest has already been added to the stream->subrequests list, it can't simply be put and abandoned as the collector may see it. Also, if it hasn't been queued yet, it has two outstanding refs that both need to be put. Both DIO read and single-read dispatch fail at this; further, both differ in the order they do things to the way buffered read works.

Fix cancellation of both DIO-read and single-read subrequests that failed preparation by the following steps:

(1) Harmonise all three reads (buffered, dio, single) to queue the subreq before prepping it.

(2) Make all three call netfsqueueread() to do the queuing.

(3) Set NETFSRREQALLQUEUED independently of the queuing as we don't know the length of the subreq at this point.

(4) In all cases, set the error and NETFSSREQFAILED flag on the subreq and then call netfsreadsubreqterminated() to deal with it. This will pass responsibility off to the collector for dealing with it.

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

ksmbd: fix use-after-free in ksmbdsessionsderegister()

In multichannel mode, UAF issue can occur in sessionderegister when the second channel sets up a session through the connection of the first channel. session that is freed through the global session table can be accessed again through ->sessions of connection.

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

ksmbd: fix session use-after-free in multichannel connection

There is a race condition between session setup and ksmbdsessionsderegister. The session can be freed before the connection is added to channel list of session. This patch check reference count of session before freeing it.

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

ksmbd: fix overflow in dacloffset bounds check

The dacloffset field was originally typed as int and used in an unchecked addition, which could overflow and bypass the existing bounds check in both smbcheckpermdacl() and smbinheritdacl().

This could result in out-of-bounds memory access and a kernel crash when dereferencing the DACL pointer.

This patch converts dacloffset to unsigned int and uses checkaddoverflow() to validate access to the DACL.

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

ksmbd: fix rcount dec/increment mismatch

rcount is only increased when there is an oplock break wait, so rcount inc/decrement are not paired. This can cause rcount to become negative, which can lead to a problem where the ksmbd thread does not terminate.

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

RDMA/mlx5: Fix mlx5pollone() curqp update flow

When curqp isn't NULL, in order to avoid fetching the QP from the radix tree again we check if the next cqe QP is identical to the one we already have.

The bug however is that we are checking if the QP is identical by checking the QP number inside the CQE against the QP number inside the mlx5ibqp, but that's wrong since the QP number from the CQE is from FW so it should be matched against mlx5coreqp which is our FW QP number.

Otherwise we could use the wrong QP when handling a CQE which could cause the kernel trace below.

This issue is mainly noticeable over QPs 0 & 1, since for now they are the only QPs in our driver whereas the QP number inside mlx5ibqp doesn't match the QP number inside mlx5coreqp.

BUG: kernel NULL pointer dereference, address: 0000000000000012 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP CPU: 0 UID: 0 PID: 7927 Comm: kworker/u62:1 Not tainted 6.14.0-rc3+ #189 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: ib-comp-unb-wq ibcqpollwork [ibcore] RIP: 0010:mlx5ibpollcq+0x4c7/0xd90 [mlx5ib] Code: 03 00 00 8d 58 ff 21 cb 66 39 d3 74 39 48 c7 c7 3c 89 6e a0 0f b7 db e8 b7 d2 b3 e0 49 8b 86 60 03 00 00 48 c7 c7 4a 89 6e a0 <0f> b7 5c 98 02 e8 9f d2 b3 e0 41 0f b7 86 78 03 00 00 83 e8 01 21 RSP: 0018:ffff88810511bd60 EFLAGS: 00010046 RAX: 0000000000000010 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff88885fa1b3c0 RDI: ffffffffa06e894a RBP: 00000000000000b0 R08: 0000000000000000 R09: ffff88810511bc10 R10: 0000000000000001 R11: 0000000000000001 R12: ffff88810d593000 R13: ffff88810e579108 R14: ffff888105146000 R15: 00000000000000b0 FS: 0000000000000000(0000) GS:ffff88885fa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000012 CR3: 00000001077e6001 CR4: 0000000000370eb0 Call Trace: <TASK> ? die+0x20/0x60 ? pagefaultoops+0x150/0x3e0 ? excpagefault+0x74/0x130 ? asmexcpagefault+0x22/0x30 ? mlx5ibpollcq+0x4c7/0xd90 [mlx5ib] ibprocesscq+0x5a/0x150 [ibcore] ibcqpollwork+0x31/0x90 [ibcore] processonework+0x169/0x320 workerthread+0x288/0x3a0 ? workbusy+0xb0/0xb0 kthread+0xd7/0x1f0 ? kthreadsonlinecpu+0x130/0x130 ? kthreadsonlinecpu+0x130/0x130 retfromfork+0x2d/0x50 ? kthreadsonlinecpu+0x130/0x130 retfromforkasm+0x11/0x20 </TASK>

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

KVM: arm64: Tear down vGIC on failed vCPU creation

If kvmarchvcpucreate() fails to share the vCPU page with the hypervisor, we propagate the error back to the ioctl but leave the vGIC vCPU data initialised. Note only does this leak the corresponding memory when the vCPU is destroyed but it can also lead to use-after-free if the redistributor device handling tries to walk into the vCPU.

Add the missing cleanup to kvmarchvcpucreate(), ensuring that the vGIC vCPU structures are destroyed on error.

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

wifi: ath12k: Fix invalid data access in ath12kdprxhundecapnwifi

In certain cases, hardware might provide packets with a length greater than the maximum native Wi-Fi header length. This can lead to accessing and modifying fields in the header within the ath12kdprxhundecapnwifi function for DPRXDECAPTYPENATIVEWIFI decap type and potentially resulting in invalid data access and memory corruption.

Add a sanity check before processing the SKB to prevent invalid data access in the undecap native Wi-Fi function for the DPRXDECAPTYPENATIVEWIFI decap type.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPLSILICONZ-1

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

wifi: ath12k: Fix invalid entry fetch in ath12kdpmonsrngprocess

Currently, ath12kdpmonsrngprocess uses ath12khalsrngsrcgetnextentry to fetch the next entry from the destination ring. This is incorrect because ath12khalsrngsrcgetnextentry is intended for source rings, not destination rings. This leads to invalid entry fetches, causing potential data corruption or crashes due to accessing incorrect memory locations. This happens because the source ring and destination ring have different handling mechanisms and using the wrong function results in incorrect pointer arithmetic and ring management.

To fix this issue, replace the call to ath12khalsrngsrcgetnextentry with ath12khalsrngdstgetnextentry in ath12kdpmonsrngprocess. This ensures that the correct function is used for fetching entries from the destination ring, preventing invalid memory accesses.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPLSILICONZ-1 Tested-on: WCN7850 hw2.0 WLAN.HMT.1.0.c5-00481-QCAHMTSWPLV1.0V2.0SILICONZ-3

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

KVM: arm64: Fix uninitialized memcache pointer in usermemabort()

Commit fce886a60207 ("KVM: arm64: Plumb the pKVM MMU in KVM") made the initialization of the local memcache variable in usermemabort() conditional, leaving a codepath where it is used uninitialized via kvmpgtablestage2map().

This can fail on any path that requires a stage-2 allocation without transition via a permission fault or dirty logging.

Fix this by making sure that memcache is always valid.

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

scsi: fnic: Fix crash in fnicwqcmplhandler when FDMI times out

When both the RHBA and RPA FDMI requests time out, fnic reuses a frame to send ABTS for each of them. On send completion, this causes an attempt to free the same frame twice that leads to a crash.

Fix crash by allocating separate frames for RHBA and RPA, and modify ABTS logic accordingly.

Tested by checking MDS for FDMI information.

Tested by using instrumented driver to:

- Drop PLOGI response - Drop RHBA response - Drop RPA response - Drop RHBA and RPA response - Drop PLOGI response + ABTS response - Drop RHBA response + ABTS response - Drop RPA response + ABTS response - Drop RHBA and RPA response + ABTS response for both of them

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

nvmet: pci-epf: Do not complete commands twice if nvmetreqinit() fails

Have nvmetreqinit() and req->execute() complete failed commands.

Description of the problem: nvmetreqinit() calls nvmetreqcomplete() internally upon failure, e.g., unsupported opcode, which calls the "queueresponse" callback, this results in nvmetpciepfqueueresponse() being called, which will call nvmetpciepfcompleteiod() if datalen is 0 or if dmadir is different from DMATODEVICE. This results in a double completion as nvmetpciepfexeciodwork() also calls nvmetpciepfcompleteiod() when nvmetreqinit() fails.

Steps to reproduce: On the host send a command with an unsupported opcode with nvme-cli, For example the admin command "security receive" $ sudo nvme security-recv /dev/nvme0n1 -n1 -x4096

This triggers a double completion as nvmetreqinit() fails and nvmetpciepfqueueresponse() is called, here iod->dmadir is still in the default state of "DMANONE" as set by default in nvmetpciepfallociod(), so nvmetpciepfcompleteiod() is called. Because nvmetreqinit() failed nvmetpciepfcompleteiod() is also called in nvmetpciepfexeciodwork() leading to a double completion. This not only sends two completions to the host but also corrupts the state of the PCI NVMe target leading to kernel oops.

This patch lets nvmetreqinit() and req->execute() complete all failed commands, and removes the double completion case in nvmetpciepfexeciodwork() therefore fixing the edge cases where double completions occurred.

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

KVM: arm64: Fix ID register initialization for non-protected pKVM guests

In protected mode, the hypervisor maintains a separate instance of the kvm structure for each VM. For non-protected VMs, this structure is initialized from the host's kvm state.

Currently, pkvminitfeaturesfromhost() copies the KVMARCHFLAGIDREGSINITIALIZED flag from the host without the underlying idregs data being initialized. This results in the hypervisor seeing the flag as set while the ID registers remain zeroed.

Consequently, kvmhasfeat() checks at EL2 fail (return 0) for non-protected VMs. This breaks logic that relies on feature detection, such as ctxthastcrx() for TCR2EL1 support. As a result, certain system registers (e.g., TCR2EL1, PIREL1, POREL1) are not saved/restored during the world switch, which could lead to state corruption.

Fix this by explicitly copying the ID registers from the host kvm to the hypervisor kvm for non-protected VMs during initialization, since we trust the host with its non-protected guests' features. Also ensure KVMARCHFLAGIDREGSINITIALIZED is cleared initially in pkvminitfeaturesfromhost so that vmcopyidregs can properly initialize them and set the flag once done.

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

Bluetooth: L2CAP: Fix use-after-free in l2capunregisteruser

After commit ab4eedb790ca ("Bluetooth: L2CAP: Fix corrupted list in hcichandel"), l2capconndel() uses conn->lock to protect access to conn->users. However, l2capregisteruser() and l2capunregisteruser() don't use conn->lock, creating a race condition where these functions can access conn->users and conn->hchan concurrently with l2capconndel().

This can lead to use-after-free and list corruption bugs, as reported by syzbot.

Fix this by changing l2capregisteruser() and l2capunregisteruser() to use conn->lock instead of hcidevlock(), ensuring consistent locking for the l2capconn structure.

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

xfrm: iptfs: fix use-after-free on firstskb in inputprocesspayload

inputprocesspayload() stores firstskb into xtfs->ranewskb under droplock when starting partial reassembly, then unlocks and breaks out of the processing loop. The post-loop check reads xtfs->ranewskb without the lock to decide whether firstskb is still owned:

if (firstskb && firstiplen && !defer && firstskb != xtfs->ranewskb)

Between spinunlock and this read, a concurrent CPU running iptfsreassemcont() (or the droptimer hrtimer) can complete reassembly, NULL xtfs->ranewskb, and free the skb. The check then evaluates firstskb != NULL as true, and pskbtrim/ipsummed/consumeskb operate on the freed skb — a use-after-free in skbuffheadcache.

Replace the unlocked read with a local bool that records whether firstskb was handed to the reassembly state in the current call. The flag is set after the existing spinunlock, before the break, using the pointer equality that is stable at that point (firstskb == skb iff firstskb was stored in ranewskb).

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

virt: sev-guest: Explicitly leak pages in unknown state

When setmemory{encrypted,decrypted}() fail, the user cannot know at which point the function failed, meaning that the pages are left in an unknown state from the point of view of the caller.

Since the pages may be left in an unencrypted state, they are not suitable for general use, and cannot be returned safely to the buddy allocator. Avoid the issue by never freeing the pages, and then do the proper accounting by calling snpleakpages().

fs/ntfs3: Prevent integer overflow in hdrfirstde()

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

ASoC: simple-card-utils: Don't use free(devicenode) at graphutilparsedai()

commit 419d1918105e ("ASoC: simple-card-utils: use free(devicenode) for device node") uses free(devicenode) for dlc->ofnode, but we need to keep it while driver is in use.

Don't use free(devicenode) in graphutilparsedai().

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

media: venus: hfi: add a check to handle OOB in sfr region

sfr->bufsize is in shared memory and can be modified by malicious user. OOB write is possible when the size is made higher than actual sfr data buffer. Cap the size to allocated size for such cases.

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

HID: intel-thc-hid: intel-quicki2c: Fix ACPI dsd ICRS/ISUB length

The QuickI2C ACPI DSD methods return ICRS and ISUB data with a trailing byte, making the actual length is one more byte than the structs defined.

It caused stack-out-of-bounds and kernel crash:

kernel: BUG: KASAN: stack-out-of-bounds in quicki2cacpigetdsdproperty.constprop.0+0x111/0x1b0 [intelquicki2c] kernel: Write of size 12 at addr ffff888106d1f900 by task kworker/u33:2/75 kernel: kernel: CPU: 3 UID: 0 PID: 75 Comm: kworker/u33:2 Not tainted 6.16.0+ #3 PREEMPT(voluntary) kernel: Workqueue: async asyncrunentryfn kernel: Call Trace: kernel: <TASK> kernel: dumpstacklvl+0x76/0xa0 kernel: printreport+0xd1/0x660 kernel: ? pfxrawspinlockirqsave+0x10/0x10 kernel: ? kasanslabfree+0x5d/0x80 kernel: ? kasanaddrtoslab+0xd/0xb0 kernel: kasanreport+0xe1/0x120 kernel: ? quicki2cacpigetdsdproperty.constprop.0+0x111/0x1b0 [intelquicki2c] kernel: ? quicki2cacpigetdsdproperty.constprop.0+0x111/0x1b0 [intelquicki2c] kernel: kasancheckrange+0x11c/0x200 kernel: asanmemcpy+0x3b/0x80 kernel: quicki2cacpigetdsdproperty.constprop.0+0x111/0x1b0 [intelquicki2c] kernel: ? pfxquicki2cacpigetdsdproperty.constprop.0+0x10/0x10 [intelquicki2c] kernel: quicki2cgetacpiresources+0x237/0x730 [intelquicki2c] [...] kernel: </TASK> kernel: kernel: The buggy address belongs to stack of task kworker/u33:2/75 kernel: and is located at offset 48 in frame: kernel: quicki2cgetacpiresources+0x0/0x730 [intelquicki2c] kernel: kernel: This frame has 3 objects: kernel: [32, 36) 'hiddescaddr' kernel: [48, 59) 'i2cparam' kernel: [80, 224) 'i2cconfig'

ACPI DSD methods return:

\SB.PC00.THC0.ICRS Buffer 000000003fdc947b 001 Len 0C = 0A 00 80 1A 06 00 00 00 00 00 00 00 \SB.PC00.THC0.ISUB Buffer 00000000f2fcbdc4 001 Len 91 = 00 00 00 00 00 00 00 00 00 00 00 00

Adding reserved padding to quicki2csubipacpiparameter/config.

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

mailbox: mchp-ipc-sbi: fix out-of-bounds access in mchpipcgetclusteraggrirq()

The clustercfg array is dynamically allocated to hold per-CPU configuration structures, with its size based on the number of online CPUs. Previously, this array was indexed using hartid, which may be non-contiguous or exceed the bounds of the array, leading to out-of-bounds access. Switch to using cpuid as the index, as it is guaranteed to be within the valid range provided by foreachonlinecpu().

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

ksmbd: validate zero numsubauth before subauth is accessed

Access psid->subauth[psid->numsubauth - 1] without checking if numsubauth is non-zero leads to an out-of-bounds read. This patch adds a validation step to ensure numsubauth != 0 before subauth is accessed.