Skip to main content

Linux Kernel EUVDEUVD-2026-38707

| CVE-2026-52937 MEDIUM
Memory Leak (CWE-401)
2026-06-24 Linux GHSA-2xmc-f6qc-h4h9
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 access and low privileges to open macvtap device required; impact is purely confidentiality (kernel pointer disclosure), no integrity or availability consequence.

3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
4.0 AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
SUSE
MEDIUM
qualitative
Red Hat
5.5 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
Jul 08, 2026 - 22:34 vuln.today
CVSS changed
Jul 08, 2026 - 19:37 NVD
5.5 (MEDIUM)
Patch available
Jun 24, 2026 - 09:16 EUVD
CVE Published
Jun 24, 2026 - 07:14 nvd
MEDIUM 5.5
CVE Published
Jun 24, 2026 - 07:14 cve.org
UNKNOWN (no severity yet)

DescriptionNVD

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

tap: fix stack info leak in tap_ioctl() SIOCGIFHWADDR

In the SIOCGIFHWADDR path, tap_ioctl() copies 16 bytes of an uninitialised on-stack struct sockaddr_storage to userspace via ifr_hwaddr, but netif_get_mac_address() only writes sa_family and dev->addr_len (6 for Ethernet) bytes, leaving sa_data[6..13] uninitialised.

Those 8 trailing bytes leak kernel stack contents; SIOCGIFHWADDR on a macvtap chardev returns kernel .text and direct-map pointers, defeating KASLR.

Initialise ss at declaration.

AnalysisAI

Stack information disclosure in the Linux kernel's tap/macvtap driver exposes 8 bytes of uninitialized kernel stack contents to local users via the SIOCGIFHWADDR ioctl, leaking kernel .text and direct-map pointers that defeat KASLR. The affected code path in tap_ioctl() copies a 16-byte sockaddr_storage to userspace while netif_get_mac_address() initializes only 8 bytes (sa_family plus 6-byte Ethernet address), leaving the trailing 8 bytes unread. No public exploit is identified at time of analysis and EPSS sits at 0.15% (5th percentile), but KASLR bypass primitives of this type are routinely chained with local privilege-escalation exploits to gain kernel code-execution. NOTE: The provided CVSS vector (C:N/I:N/A:H) appears to misclassify this vulnerability - confidentiality is the impacted property, not availability; the assessed vector below corrects this.

Technical ContextAI

The vulnerability resides in drivers/net/tap.c in the Linux kernel's virtual network tap/macvtap subsystem (CPE: cpe:2.3:a:linux:linux). When a process calls ioctl(fd, SIOCGIFHWADDR, &ifr) on a macvtap character device, tap_ioctl() populates ifr_hwaddr using a stack-allocated struct sockaddr_storage of 16 bytes. netif_get_mac_address() writes only the sa_family field (2 bytes) and the Ethernet MAC address (6 bytes via dev->addr_len), leaving the upper 8 bytes of sa_data (indices 6 through 13) in their uninitialized state. These bytes are then copied verbatim to userspace. Because this storage sits on the kernel stack, the leaked bytes frequently contain kernel .text segment addresses and direct physical-map (physmap) pointers from prior stack frames, providing a reliable KASLR defeat primitive to any process that can open the macvtap device. The assigned CWE-401 (Missing Release of Memory) does not accurately describe this flaw; CWE-909 (Missing Initialization of Resource) or CWE-200 (Exposure of Sensitive Information) are more precise root-cause classifications.

RemediationAI

The primary fix is to upgrade to a patched Linux kernel version: 7.1 or later, 7.0.11 or later in the 7.0.x stable series, or 6.18.34 or later in the 6.18.x stable series, per EUVD patch metadata. Distribution maintainers should apply the upstream stable commits referenced at the kernel.org stable tree (commits 719007c, 05305e8, bddc092). For systems that cannot be immediately patched, a compensating control is to restrict access to macvtap character devices using filesystem permissions or seccomp/LSM policy (SELinux or AppArmor device rules) so only trusted processes can open the device - this eliminates unprivileged access to the leaking ioctl. In containerized or virtualized environments using macvtap for VM networking, restricting which guest VMs or container processes can access the host macvtap interface reduces exposure. Note that restricting macvtap access may impact VM network connectivity workflows and must be tested before deployment. No workaround fully mitigates the flaw in a running unpatched kernel for processes that legitimately require macvtap access.

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Affected
SUSE Linux Enterprise High Availability Extension 16.0 Affected

Share

EUVD-2026-38707 vulnerability details – vuln.today

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