Skip to main content

Linux Kernel EUVDEUVD-2026-32310

| CVE-2026-46013 MEDIUM
2026-05-27 416baaa9-dc9f-4396-8d5f-8c081fb06d67 GHSA-gxmw-vhgm-hqg8
Information Disclosure Linux Red Hat Suse
5.5
CVSS 3.1 · NVD
Share

Severity by source

NVD PRIMARY
5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
vuln.today AI
5.5 MEDIUM

Local-only trigger requiring low-privilege memfd operations; exclusively availability impact (kernel panic); no confidentiality or integrity effect identified.

3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
4.0 AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
SUSE
MEDIUM
qualitative

Primary rating from NVD.

CVSS VectorNVD

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

5
Analysis Generated
Jun 16, 2026 - 15:58 vuln.today
CVSS changed
Jun 16, 2026 - 15:37 NVD
5.5 (MEDIUM)
Patch available
May 27, 2026 - 19:46 EUVD
CVE Published
May 27, 2026 - 14:17 nvd
MEDIUM 5.5
CVE Published
May 27, 2026 - 14:17 nvd
UNKNOWN (no severity yet)

DescriptionNVD

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

mm/memfd_luo: fix physical address conversion in put_folios cleanup

In memfd_luo_retrieve_folios()'s put_folios cleanup path:

  1. kho_restore_folio() expects a phys_addr_t (physical address) but

receives a raw PFN (pfolio->pfn). This causes kho_restore_page() to check the wrong physical address (pfn << PAGE_SHIFT instead of the actual physical address).

  1. This loop lacks the !pfolio->pfn check that exists in the main

retrieval loop and memfd_luo_discard_folios(), which could incorrectly process sparse file holes where pfn=0.

Fix by converting PFN to physical address with PFN_PHYS() and adding the !pfolio->pfn check, matching the pattern used elsewhere in this file.

This issue was identified by the AI review. https://sashiko.dev/#/patchset/20260323110747.193569-1-duanchenghao@kylinos.cn

AnalysisAI

Incorrect physical address conversion in the Linux kernel's mm/memfd_luo subsystem can crash the kernel when the put_folios error-cleanup path executes during memfd Live Update Object (LUO) operations. The cleanup passes a raw Page Frame Number (PFN) where kho_restore_folio() requires a phys_addr_t, and a missing sparse-hole guard (pfn==0) risks misprocessing file holes. No public exploit identified at time of analysis; EPSS of 0.02% (5th percentile) and absence from CISA KEV confirm very low real-world exploitation probability, with impact confined to local denial of service on systems running the experimental KHO/LUO subsystem.

Technical ContextAI

The affected code resides in mm/memfd_luo.c, the Linux kernel's memfd Live Update Objects (LUO) subsystem, which interoperates with Kernel Handover Objects (KHO) - a developmental mechanism for preserving kernel state across live kernel updates. The bug contains two distinct defects in the put_folios cleanup path of memfd_luo_retrieve_folios(): (1) kho_restore_folio() is invoked with pfolio->pfn (a raw PFN value) where the function signature expects a phys_addr_t - the correct conversion requires PFN_PHYS(pfolio->pfn), which applies a PAGE_SHIFT left-shift; without this, kho_restore_page() checks a physical address that is off by a factor of PAGE_SIZE (typically 4096 on x86-64); (2) the cleanup loop omits the !pfolio->pfn guard that is present in both the main retrieval loop and in memfd_luo_discard_folios(), potentially causing incorrect processing of sparse file holes where pfn equals zero. CPE data identifies cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:* as affected, with EUVD-2026-32310 narrowing the introduced version to Linux 6.19. No CWE is formally assigned, but the root cause is an incorrect type conversion (analogous to CWE-704) combined with a missing zero-value boundary check.

RemediationAI

The primary fix is to upgrade to Linux kernel 7.0.4 (stable) or 7.1-rc1 (mainline), which include the corrected mm/memfd_luo.c logic via upstream commits 3538f90ab89aaf302782b4b073a0aae66904cd67 (https://git.kernel.org/stable/c/3538f90ab89aaf302782b4b073a0aae66904cd67) and bd0d6bde286a2b8e3ae7975b0dcc2d43875d5fc9 (https://git.kernel.org/stable/c/bd0d6bde286a2b8e3ae7975b0dcc2d43875d5fc9). For systems that cannot immediately upgrade, the most effective compensating control is to avoid use of the memfd LUO/KHO functionality entirely, since the defective path requires triggering memfd_luo_retrieve_folios() - systems not actively using KHO live-update operations are not exposed. If the kernel can be rebuilt, disabling CONFIG options related to KHO/LUO at compile time eliminates the affected code path with no functional trade-off for non-KHO workloads. Restricting local user access and applying namespace isolation (user namespaces, seccomp profiles) reduces the likelihood that an unprivileged local user can trigger the path.

Same technique Information Disclosure

View all
CVE-2019-2725 CRITICAL POC
9.8
CVE-2021-34523 CRITICAL POC
9.0
CVE-2013-2251 CRITICAL POC
9.8
CVE-2017-5638 CRITICAL POC
9.8
CVE-2025-24813 CRITICAL POC
9.8
CVE-2015-1701 HIGH POC
7.8
CVE-2017-0147 HIGH POC
7.5
CVE-2014-6324 HIGH POC
8.8

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
openSUSE Tumbleweed Fixed
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Not-Affected

Share

EUVD-2026-32310 vulnerability details – vuln.today
Back

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy