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.

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.

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.

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)

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()

Bluetooth: btintel: Validate length before parsing diagnostics TLV