CVE-2026-31542

What it actually does

This is a Linux kernel denial-of-service flaw in the x86 UV platform code. On affected systems, a deconfigured CPU socket can be represented internally as SOCK_EMPTY, value 0xffff. The vulnerable code may incorrectly use that value while allocating UV hub information structures, causing invalid NUMA node handling and a kernel panic. The impact is availability loss only: no confidentiality or integrity impact is indicated by the advisory.

Why it matters to the business

Successful exploitation can crash an affected Linux system, interrupting workloads, services, and dependent applications until the host is rebooted and recovered. The risk is most relevant to organizations running Linux on x86 UV-class hardware or kernels with this platform code enabled. The vulnerability requires local privileges, has low EPSS, no known public exploit maturity, and is not listed in CISA KEV, so it should be prioritized as a stability and hardening issue rather than an internet-scale emergency.

How an attack unfolds

An attacker needs local access with the ability to run code on an affected Linux system. The attacker attempts to reach the vulnerable x86 UV platform path when the system has, or can be made to observe, a deconfigured socket state represented as SOCK_EMPTY. When the kernel processes that state, it may attempt to allocate UV hub structures using an invalid socket-to-node mapping. That invalid allocation path can trigger a kernel panic, crashing the host and causing denial of service. There is no indication that the flaw enables privilege escalation, data theft, or remote code execution.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix for x86/platform/uv handling of deconfigured sockets. Because no exact fixed package versions were provided, use the latest stable kernel or the latest vendor-supported kernel update for the distribution and hardware platform. The fix changes handling of deconfigured sockets by using NUMA_NO_NODE rather than treating SOCK_EMPTY as a valid allocation node. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted users from running code on affected hosts, applying least privilege controls, and prioritizing patching for systems where host crashes would affect critical workloads.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor release containing the x86/platform/uv deconfigured socket fix. Validate with distribution package metadata, vendor advisories, changelogs, or kernel source history referencing 'x86/platform/uv: Handle deconfigured sockets'. After patching, reboot into the fixed kernel and verify with 'uname -r' and package manager queries. Review boot and kernel logs to ensure no recurring UV hub allocation errors, NUMA node errors, or kernel panic events occur when the system detects deconfigured sockets.

Typical attack path

1. Obtain local authenticated access to an affected Linux system.
2. Confirm the host is running an affected kernel and relevant x86 UV platform code.
3. Trigger or wait for a deconfigured socket condition represented internally as SOCK_EMPTY.
4. Cause the kernel to process UV hub information allocation for the affected socket state.
5. The kernel dereferences or uses the invalid node mapping and panics, taking the system offline.

How to detect it

Look for evidence of prior kernel panics or crashes on affected Linux hosts, especially around UV platform initialization, socket deconfiguration, NUMA node handling, or hub information allocation. Relevant log sources include journald, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dump directories, kdump/vmcore artifacts, hardware event logs, and system management controller logs. Search for kernel panic events correlated with messages mentioning UV, x86 platform UV, sockets, deconfigured sockets, SOCK_EMPTY, NUMA nodes, or hub info allocation. Because this is a local denial-of-service issue and no public exploit indicators are known, detection should focus on crash forensics, repeated unexplained reboots, local user activity shortly before the crash, and command execution history from accounts active immediately before the panic.

• Kernel panic
• kernel panic
• panic:
• Oops:
• BUG: unable to handle kernel
• x86/platform/uv
• UV hub
• uv hub
• SOCK_EMPTY
• 0xffff
• NUMA_NO_NODE
• deconfigured socket
• deconfigured sockets
• hub info
• /var/crash
• /var/lib/systemd/coredump
• vmcore
• kdump

What your security team should do

• Inventory Linux systems running x86 UV platform-capable kernels, especially specialized high-memory or NUMA-heavy systems.
• Patch affected systems to the latest vendor-supported kernel containing the x86/platform/uv deconfigured socket fix.
• Prioritize systems where a kernel panic would disrupt production workloads, clustered services, batch processing, or critical compute jobs.
• Restrict local interactive access and code execution rights on affected hosts until patched.
• Monitor kernel logs for panic, UV platform, socket deconfiguration, and NUMA allocation errors.
• Ensure HA, clustering, job checkpointing, and reboot recovery procedures are functioning for systems that cannot be patched immediately.
• Track vendor advisories for exact fixed kernel package versions applicable to each Linux distribution in use.