CVE-2026-52937: 
Linux Kernel Analyse et atténuation des vulnérabilités

CVE-2026-52937 is a kernel stack information disclosure vulnerability in the Linux kernel's tap driver, specifically in the tap_ioctl() function's SIOCGIFHWADDR handling path. When a user issues the SIOCGIFHWADDR ioctl on a macvtap chardev, the function copies 16 bytes of an uninitialized on-stack struct sockaddr_storage to userspace, but netif_get_mac_address() only initializes sa_family and 6 bytes of MAC address data, leaving 8 bytes (sa_data[6..13]) uninitialized. These 8 trailing bytes can contain kernel .text and direct-map pointers, effectively defeating KASLR. The vulnerability was published on June 24, 2026, and affects Linux kernel versions from 5.4.103 through certain 5.x releases up to 5.12, with patches available (Github Advisory). A CVSS score has not yet been formally assigned, though it is estimated as Medium severity (Github Advisory).

The root cause is use of an uninitialized stack variable (CWE-200: Exposure of Sensitive Information to an Unauthorized Actor) — specifically, a struct sockaddr_storage allocated on the stack in tap_ioctl() without being zeroed before use. When the SIOCGIFHWADDR ioctl is processed, netif_get_mac_address() writes only sa_family (2 bytes) and the Ethernet MAC address (6 bytes) into the structure, leaving bytes 8–15 (sa_data[6..13]) containing whatever was previously on the kernel stack. The full 16-byte structure is then copied to userspace via ifr_hwaddr, leaking those uninitialized bytes. The fix is straightforward: initialize the sockaddr_storage structure at declaration time (e.g., struct sockaddr_storage ss = {};) to ensure no stale stack data is exposed (Github Advisory).

Successful exploitation allows any local user with access to a tap or macvtap chardev to read 8 bytes of uninitialized kernel stack memory per ioctl call, which may contain kernel .text segment pointers and direct-map pointers. This information disclosure can be used to defeat Kernel Address Space Layout Randomization (KASLR), a key exploit mitigation, potentially enabling an attacker to chain this vulnerability with a separate kernel exploit that requires knowledge of kernel memory layout to achieve privilege escalation or arbitrary code execution (Github Advisory).

1. Identify access: Confirm local access to a system running a vulnerable Linux kernel (5.4.103–5.11.x or 5.11.4–5.12) with a macvtap or tap chardev accessible to the current user (e.g., /dev/tapX or /dev/macvtapX).
2. Open the chardev: Open the tap/macvtap character device file descriptor using open("/dev/macvtapX", O_RDWR).
3. Issue SIOCGIFHWADDR ioctl: Construct an ifreq structure and call ioctl(fd, SIOCGIFHWADDR, &ifr) on the opened file descriptor.
4. Extract leaked bytes: Read bytes 8–15 of ifr.ifr_hwaddr.sa_data (i.e., sa_data[6..13]), which contain uninitialized kernel stack contents — potentially kernel .text or direct-map pointers.
5. Defeat KASLR: Parse the leaked pointers to determine the kernel base address or physical memory map offset, enabling subsequent exploitation of a separate kernel vulnerability that requires known memory addresses (Github Advisory).

• Logs: Repeated or scripted ioctl calls with SIOCGIFHWADDR on tap/macvtap devices from unprivileged user processes, visible in auditd logs if syscall auditing is enabled (audit rule: -a always,exit -F arch=b64 -S ioctl -F a1=0x8927).
• Process: Unusual processes (especially those not associated with virtualization management) opening /dev/tapX or /dev/macvtapX device files and issuing SIOCGIFHWADDR ioctls.
• File System: Unexpected access to macvtap/tap character devices by non-root, non-virtualization users, detectable via inotifywait or auditd file access rules on /dev/macvtap* or /dev/tap*.

Apply the upstream Linux kernel patches that initialize the sockaddr_storage structure at declaration in tap_ioctl(): commit 719007c3492f (one stable branch), 05305e832be7 (second stable branch), and bddc09212c24 (third stable branch) (Github Advisory). Fixed versions include kernel 6.18.34, 7.0.11, and 7.1+. As a workaround, restrict access to tap and macvtap character devices to only trusted users and processes using filesystem permissions or Linux Security Modules (e.g., SELinux, AppArmor policies). Disabling macvtap/tap functionality entirely where not required also eliminates the attack surface.