CVE-2026-31673

What it actually does

This is a local Linux kernel race condition in the AF_UNIX diagnostics path. Exact UNIX socket diagnostic lookups hold a reference to the socket but did not consistently protect the associated VFS path pointer while another thread could release the socket and clear that path. A local authenticated user able to trigger UNIX socket diagnostic queries and concurrently manipulate UNIX sockets could potentially cause the kernel to read unstable or freed path-related data while building a netlink diagnostic response. Because the flaw occurs in kernel context, successful exploitation could plausibly lead to kernel memory corruption, information disclosure, denial of service, or privilege escalation, consistent with the high confidentiality, integrity, and availability impact reflected by the CVSS score.

Why it matters to the business

Affected Linux systems may be exposed to local privilege escalation or kernel crash risk if untrusted or compromised users can run code on the host. The highest operational concern is on multi-user servers, shared compute platforms, container hosts, developer workstations, CI runners, and systems where low-privileged shell access is common. EPSS is currently very low and there is no known KEV listing or public exploit maturity reported, so broad internet-scale exploitation is not indicated; however, kernel local privilege-escalation flaws are often chained after initial access and should still be remediated through normal kernel patch cycles.

How an attack unfolds

An attacker first needs local code execution with low privileges on an affected Linux system. They then create, inspect, and tear down UNIX domain sockets while issuing AF_UNIX diagnostic netlink requests that ask the kernel to return VFS metadata such as inode and device numbers. By racing the diagnostic lookup against socket release, the attacker attempts to make the kernel read path-related state after it has become unstable or been cleared. If the race is won in a controllable way, the result may be a kernel crash, disclosure of kernel memory or path metadata, or memory corruption that could be developed into local privilege escalation. There are no named threat actors, ransomware campaigns, KEV listing, or mature public exploitation currently associated with this CVE in the provided data.

How to fix it

Update to a Linux kernel version that includes the upstream fix for AF_UNIX UNIX_DIAG_VFS path handling, where inode and device numbers are read while holding unix_state_lock and the netlink attribute is emitted after the lock is released. Because no exact fixed package versions were provided, use the fixed kernel packages from the relevant Linux distribution or vendor advisory once available. Reboot systems after installing kernel updates to ensure the patched kernel is active. Where immediate patching is not possible, reduce exposure by limiting untrusted local shell access, isolating multi-tenant workloads, applying least privilege, enabling mandatory access controls such as SELinux or AppArmor, and restricting container capabilities and access to netlink diagnostic interfaces where feasible. Treat mitigation as risk reduction only; the durable fix is a patched kernel.

How to confirm the fix worked

Confirm the running kernel, not only the installed package, has been updated by checking the active kernel version after reboot. Validate against the relevant distribution advisory or kernel changelog for the AF_UNIX fix referencing UNIX_DIAG_VFS, unix_state_lock, unix_release_sock(), or stable handling of u->path. On source-based or custom kernels, verify that the AF_UNIX diagnostic code reads the VFS inode and device values while holding unix_state_lock and does not dereference the socket path after it can be cleared. For fleet validation, inventory Linux kernel versions across servers, containers hosts, CI runners, and workstations, then compare them with vendor-fixed releases. Also confirm that no hosts remain booted into older vulnerable kernels after patch installation.

Typical attack path

1. Obtain local low-privileged code execution on an affected Linux host.
2. Create UNIX domain sockets and identify paths that can be queried through UNIX socket diagnostics.
3. Issue AF_UNIX diagnostic netlink requests that request UNIX_DIAG_VFS data.
4. Concurrently close or release the targeted UNIX sockets to trigger the race with unix_release_sock().
5. Attempt to cause unstable path data to be read while the kernel builds the diagnostic response.
6. Use the resulting crash, disclosure, or memory corruption condition as a denial-of-service mechanism or as part of a local privilege-escalation exploit chain.

How to detect it

Detecting prior exploitation is difficult because this is a race condition in kernel socket diagnostic handling and successful exploitation may leave no unique artifact. Focus on indirect evidence: kernel logs from journald, dmesg, syslog, kmsg, crash dumps, audit logs, process accounting, and EDR telemetry. Look for kernel Oops, panic, general protection fault, use-after-free, KASAN, slab, or lock-related warnings involving AF_UNIX, unix_diag, UNIX_DIAG_VFS, unix_release_sock(), unix_state_lock, or netlink socket diagnostics. Investigate local processes that repeatedly open AF_UNIX diagnostic netlink sockets, issue SOCK_DIAG_BY_FAMILY requests for UNIX sockets, and rapidly create/unlink/close UNIX domain sockets. On container hosts and shared systems, correlate suspicious activity with low-privileged users or containers shortly before kernel crashes or privilege changes. Absence of these artifacts does not prove non-exploitation; it only reduces confidence that noisy exploitation or crash-oriented attempts occurred.

• UNIX_DIAG_VFS
• unix_diag
• unix_release_sock
• unix_state_lock
• af_unix
• AF_UNIX
• SOCK_DIAG_BY_FAMILY
• NETLINK_SOCK_DIAG
• kernel: Oops
• kernel: BUG: unable to handle kernel
• kernel: general protection fault
• kernel: KASAN
• kernel: use-after-free
• kernel: slab-use-after-free
• kernel panic
• BUG: KASAN: use-after-free
• WARNING: CPU:

What your security team should do

• Prioritize patching shared Linux systems where untrusted users, developers, CI jobs, containers, or third-party workloads can execute local code.
• Track the relevant Linux distribution advisories and deploy the first vendor-fixed kernel package available for each supported platform.
• Reboot after kernel updates and verify the active kernel version across the fleet.
• Review multi-tenant and container-host hardening, including capability restrictions, seccomp profiles, SELinux/AppArmor enforcement, and reduced access to diagnostic netlink functionality where operationally feasible.
• Monitor for kernel crashes, WARN/Oops events, and suspicious local programs repeatedly creating and tearing down UNIX sockets while querying socket diagnostics.
• Because EPSS is low, not KEV-listed, and no public exploit maturity is reported, handle as an important kernel maintenance item rather than an emergency internet-facing incident unless local multi-user exposure is high.
• If unexplained kernel instability is observed on vulnerable systems, preserve kernel logs, crash dumps, process accounting data, and recent user activity before rebooting or reimaging.