CVE-2026-31786

What it actually does

This is a local Linux kernel memory-corruption vulnerability in the Xen sysfs hypervisor interface. The kernel treats the Xen build ID returned by HYPERVISOR_xen_version(XENVER_build_id) as a NUL-terminated string even though Xen returns binary data with an explicit length. When the sysfs build ID attribute is read, sprintf() can continue reading and copying past the returned build ID until it encounters a NUL byte, causing an out-of-bounds read and potentially an out-of-bounds write into the sysfs output buffer. On affected Linux systems running under Xen, a low-privileged local user may be able to trigger kernel memory disclosure, kernel memory corruption, a crash, or potentially local privilege escalation.

Why it matters to the business

Organizations running Linux workloads on Xen-based virtualization may face host or guest instability and potential compromise from a user or process that already has local access to an affected Linux system. The practical exposure is narrower than a remote network vulnerability because exploitation requires local privileges and a Xen-related kernel code path, and current public exploit maturity and EPSS are low and stable; however, successful exploitation could affect confidentiality, integrity, and availability of critical Linux systems.

How an attack unfolds

An attacker first obtains low-privileged local access to an affected Linux system that exposes the Xen hypervisor sysfs interface. The attacker checks whether the system is running under Xen and whether the build ID sysfs attribute is present and readable. By repeatedly reading the Xen build ID attribute, the attacker triggers the vulnerable buildid_show path in drivers/xen/sys-hypervisor.c. Because the returned build ID is binary data and not guaranteed to be NUL-terminated, the kernel uses sprintf() incorrectly and may copy data beyond the intended buffer. Depending on kernel layout, Xen build ID contents, and surrounding memory state, this may disclose kernel memory, corrupt adjacent memory, crash the kernel, or potentially be shaped into a local privilege escalation. There is no indication from the provided data that this vulnerability is in the CISA KEV catalog, used in ransomware campaigns, or currently has mature public exploitation.

How to fix it

Upgrade affected Linux kernels to a vendor version that includes the fix for the Xen sys-hypervisor build ID handling. The corrected implementation treats the Xen build ID as length-delimited binary data and uses bounded copying rather than sprintf() string formatting. Because no exact fixed versions were provided, follow the relevant Linux distribution or kernel vendor advisory for CVE-2026-31786 / XSA-485 and prioritize Xen guests, Xen dom0 systems, and systems with /sys/hypervisor exposed. If immediate patching is not possible, reduce local attack surface: restrict shell access, remove unnecessary local users, isolate untrusted workloads, monitor or restrict access to Xen sysfs attributes where operationally feasible, and consider temporarily moving high-risk workloads away from affected Xen-backed kernels. Do not rely on network filtering alone, because exploitation is local.

How to confirm the fix worked

Confirm exposure by checking whether the running kernel is from an affected vendor build and whether the system is running under Xen with the hypervisor sysfs interface enabled. Verify that vendor package metadata, kernel changelogs, or source patches include the change replacing unsafe string formatting in drivers/xen/sys-hypervisor.c build ID handling with bounded binary copying. After patching, reboot into the fixed kernel and confirm the active kernel version matches the vendor-fixed build, not only that the package is installed. Functional validation can include safely reading the Xen build ID sysfs attribute and confirming there are no kernel warnings, oopses, panics, or memory-corruption messages; this should be done only in a controlled test environment. Vulnerability scanners should be configured to assess the running kernel version and Xen-specific kernel exposure, not merely package presence.

Typical attack path

1. Gain low-privileged local code execution on a Linux system running in a Xen environment.
2. Confirm the Xen hypervisor sysfs interface is present, commonly under /sys/hypervisor/.
3. Locate and read the Xen build ID sysfs attribute exposed by the Linux kernel.
4. Trigger the vulnerable buildid_show code path that treats a binary Xen build ID as a NUL-terminated string.
5. Repeat or tune reads to cause kernel memory disclosure, kernel memory corruption, or a denial-of-service crash.
6. If reliable memory corruption is achieved, attempt local privilege escalation or persistence using elevated privileges.

How to detect it

To determine whether this was already exploited, review endpoint, audit, and kernel telemetry for access to Xen hypervisor sysfs build ID attributes followed by kernel instability or memory-corruption symptoms. Useful log sources include Linux auditd logs, systemd-journald, /var/log/kern.log, /var/log/messages, /var/log/syslog, kernel crash dumps, kdump/vmcore artifacts, EDR process telemetry, and shell history where available. Look for low-privileged processes repeatedly reading files under /sys/hypervisor, especially build_id, shortly before kernel oopses, panics, general protection faults, KASAN reports, slab allocator corruption, or unexpected reboots. If process accounting or audit rules were enabled, correlate read/open syscalls against /sys/hypervisor paths with the user, process tree, and remote login source. Because successful exploitation may leave only a crash or memory-corruption trace, absence of a clear IOC does not prove absence of exploitation. Also review for post-exploitation signs of local privilege escalation, such as unexpected root shells, new privileged users, modified sudoers files, unusual setuid binaries, suspicious kernel module loading, or persistence created shortly after relevant kernel faults.

• /sys/hypervisor/version/build_id
• /sys/hypervisor/
• drivers/xen/sys-hypervisor.c
• HYPERVISOR_xen_version
• XENVER_build_id
• buildid_show
• general protection fault
• kernel BUG
• Oops:
• Kernel panic
• BUG: KASAN
• slab-out-of-bounds
• use-after-free
• corrupted memory
• sys-hypervisor

What your security team should do

• Inventory Linux systems running on Xen, including dom0 and guest workloads, and identify those exposing /sys/hypervisor.
• Prioritize patching Xen-backed Linux systems where untrusted users, multi-user access, CI/CD jobs, containers, or third-party workloads can execute local code.
• Apply the vendor-fixed kernel as soon as available and reboot systems to ensure the fixed kernel is active.
• Because exploit maturity is currently reported as none and EPSS is low and stable, prioritize based on local-user exposure and business criticality rather than broad internet exposure.
• Restrict local interactive access and remove unnecessary accounts on affected systems until patched.
• Enable or review audit logging for suspicious access to Xen hypervisor sysfs attributes where feasible.
• Monitor kernel logs for oops, panic, general protection fault, KASAN, slab corruption, or other memory-corruption indicators after reads of /sys/hypervisor paths.
• Ensure incident response teams treat unexplained kernel crashes on Xen-backed Linux systems as potentially security-relevant until patched.
• Track vendor advisories for XSA-485 and distribution-specific fixed kernel versions.