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

RDMA/efa: Fix PBL chunk length computation

On register MR, when creating the PBL, if it's an indirect PBL we create a chunk list to hold the PBL pages pointers. Each chunk is 4KB in size and can hold 510 addresses (EFAPTRSPERCHUNK) and has a 12-byte control buffer at the end of it holding the next chunk's pointer and its length.

If the PBL number of pages is a multiple of EFAPTRSPERCHUNK, the calculated last chunk length is wrongly computed as 0, even though that chunk is fully populated with 510 real page pointers. This wrong length is used both to DMA map the chunk and is propagated to the device, causing the device to see the chunk as empty and reject the memory registration.

Fix the calculation so it will be performed only if the number of pages isn't a multiple of EFAPTRSPERCHUNK, if it is, its already handled in the above loop correctly. Also prevent out-of-bounds reach in the chunks array in such scenario.

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

scsi: qla2xxx: Fix response queue over-consumption in qlaconsumeiocb()

qla24xxprocessresponsequeue() advances ringptr past the head IOCB before dispatching, so by the time qlaconsumeiocb() runs, ringptr already points at the first continuation IOCB. The function however looped purex->entrycount times starting at ringptr. As entrycount includes the head, this consumed one entry too many: it stamped RESPONSEPROCESSED on the next, unrelated IOCB and advanced the ring past it, silently dropping a legitimate firmware response. The head IOCB's signature was also never marked.

Mark the head processed and account for it, then consume only the entrycount - 1 continuation IOCBs, matching qlacopypurextobuffer().

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

signal: avoid shared siginfo namespace rewrites

sendsignallocked() rewrites sender ids for the target namespace. Group sends reuse the same siginfo, so one recipient can affect the next.

Copy the siginfo before changing it.

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

of: fix out-of-bounds read in ofaliasscan() stem parser

The stem parser tests isdigit((end - 1)) before checking end > start and so reads one byte before the property name when the name is empty or all digits. Check the bound first.

Bluetooth: hcicore: use skbget() instead of skbclone() for reqskb

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

mm/hugetlb: fix swap entry corruption when clearing uffd-wp at fork()

copyhugetlbpagerange() clears the uffd-wp bit of migration and hwpoison entries with hugepteclearuffdwp(), which operates on the present-PTE bit position. Swap entries keep the uffd-wp state elsewhere -- the migration branch reads and sets it with pteswpuffdwp() and pteswpmkuffdwp() -- and the present-PTE position falls into the swap payload. On x86-64 it lands in the inverted swap offset, where a naturally-aligned hugetlb PFN always has the affected bit set, so the clear advances the encoded PFN by two pages.

No userfaultfd needs to be involved: the clear is guarded only by the child VMA not being uffd-wp registered, so a plain fork() with an in-flight hugetlb migration entry (or a poisoned hugetlb page) corrupts the entry copied into the child. Instrumenting the clear and forking after MADVHWPOISON on a 2MB anon hugetlb page shows:

offset before=120e00 offset after =120e02

The fallout is mostly latent: rmap walks match migration entries by folio range and removemigrationpte() rebuilds the PTE from the folio, so a within-folio PFN skew heals once migration completes. But any path that re-encodes the corrupted offset -- e.g. hugetlbchangeprotection() rewriting a writable migration entry via makereadablemigrationentry(swpoffset(entry)) -- propagates it.

Migration entries legitimately carry uffd-wp, so clear it with pteswpclearuffdwp(), matching copynonpresentpte() and movehugepte().

A hwpoison entry, on the other hand, never carries the uffd-wp bit: it is installed fresh by makehwpoisonentry() (trytounmapone() does not preserve uffd-wp on the hwpoison path) and hugetlbchangeprotection() leaves hwpoison entries untouched. There was nothing to clear there, only the corruption, so drop the clear entirely.

drm/tegra: gr2d/gr3d: Initialize address register map before HOST1X client is registered

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

mailbox: mchp-ipc-sbi: Add null check for devmkasprintf()

Add a check to see if devmkasprintf() is not NULL in mchpipcgetclusteraggrirq(), returning -ENOMEM if the function failed.

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

net/smc: fix qentry overwrite for CONFIRMLINK and ADDLINKCONT in smcllceventhandler()

The SMCLLCCONFIRMLINK / SMCLLCADDLINKCONT branch in smcllceventhandler() stores an incoming qentry into the local LLC flow without first checking whether a qentry is already pending. If a malicious or buggy peer sends a second CONFIRMLINK or ADDLINKCONT request while a flow is active and flow->qentry is already set, smcllcflowqentryset() overwrites the pointer without freeing the previous allocation, leaking one kmalloc-96 object per spurious message.

The sibling SMCLLCDELETELINK branch already has the correct !flow->qentry guard. Apply the same guard to the CONFIRMLINK/ADDLINKCONT branch so that a duplicate message when qentry is already occupied falls through to break and is freed by the kfree(qentry) at the out: label, rather than silently leaking the existing allocation.

The response direction (smcllcrxresponse()) is unaffected: it already guards with flow->qentry at the equivalent site and drops duplicate responses correctly.

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

vt: add permission check for KDSKBMETA ioctl

KDSKBMETA modifies keyboard meta mode but lacks the !perm check that all other keyboard setter ioctls in vtkioctl() enforce, allowing a process to change meta mode on a non-controlling console without authorization.

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

Input: evdev - fix information leak in evdevpassvalues()

In evdevpassvalues(), the inputevent structure is allocated on the kernel stack and populated field-by-field. However, it is never fully initialized. On architectures where struct inputevent contains explicit or implicit padding (such as the 32-bit pad field on SPARC64), these padding bytes are left uninitialized.

When this event structure is subsequently passed to the client buffer and later copied to userspace, the uninitialized padding bytes leak kernel stack memory, potentially exposing sensitive information.

Similar issues exist in evdevqueuesyndropped and passevent.

Fix this by explicitly zeroing the entire event structure with memset() before populating its fields. This ensures all padding bytes are cleared before the data crosses the security boundary.

ima: fix out-of-bounds read in xattrverify()

futex: Prevent robust futex exit race some more

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

net: mpls: initialize rtmtos in mplsgetroute()

mplsgetroute() builds the RTMNEWROUTE reply to an RTMGETROUTE request by filling a struct rtmsg allocated from an skb whose data area is not zeroed (allocskb(NLMSGGOODSIZE, ...)). It sets every field of the header except rtmtos:

r = nlmsgdata(nlh); r->rtmfamily = AFMPLS; r->rtmdstlen = 20; r->rtmsrclen = 0; r->rtmtable = RTTABLEMAIN; r->rtmtype = RTNUNICAST; r->rtmscope = RTSCOPEUNIVERSE; r->rtmprotocol = rt->rtprotocol; r->rtmflags = 0;

struct rtmsg has no padding, so the one uninitialised byte rtmtos (offset 3) is copied straight to user space on recvmsg(), leaking a byte of uninitialised heap memory. This is in contrast to mplsdumproute(), which fills the very same header and does set rtmtos = 0.

Initialize rtmtos to 0, matching mplsdumproute().

Reproduced with KMSAN by adding an MPLS route and issuing a non-RTMFFIBMATCH RTMGETROUTE for its label:

BUG: KMSAN: kernel-infoleak in copytoiter+0x36c/0x33f0 copytoiter+0x36c/0x33f0 skbdatagramiter+0x196/0x12c0 skbcopydatagramiter+0x5b/0x210 netlinkrecvmsg+0x37b/0xef0 ... Uninit was created at: allocskb+0x8ca/0x10e0 mplsgetroute+0x1280/0x3a40 rtnetlinkrcvmsg+0x1138/0x15a0 ... Byte 19 of 64 is uninitialized

(byte 19 = nlmsghdr(16) + rtmsg offset 3 = rtmtos)

Bluetooth: btintel: Validate length before parsing diagnostics TLV

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

net: sxgbe: free TX rings on RX allocation failure

When RX descriptor ring allocation fails, initdmadescrings() only frees the partially allocated RX rings and returns. The TX rings that were allocated earlier in the same function are leaked.

Rearrange error labels to clean up TX rings upon RX failures.

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

net: openvswitch: fix skb leak on flow key update failure during ct

ovsctexecute() always steals or frees the skb on failure while ovsflowkeyupdate() does not. So, if it fails and we return right away, the skb ends up leaked.

Fix that by breaking instead and letting the common error handling code at the bottom of the loop to free the skb properly.

This is a very unlikely scenario as it requires the packet to become unparseable by applying a set of actions on a previously parseable skb, but should be fixed nevertheless.

Reported by Sashiko.

drm/amdkfd: fix QID bit leak in pqmcreatequeue()