CVE-2026-64005

What it actually does

This is a Linux kernel memory-corruption vulnerability in the Shared Memory Communications (SMC) networking subsystem. During SMC initialization, the kernel could reinitialize SMC hash-list heads after protocol and socket registration had already occurred. If entries were already present or in use, this could corrupt the in-kernel linked-list state. A local low-privileged attacker may be able to trigger unsafe SMC socket activity around initialization/module-load conditions, potentially causing kernel memory corruption, denial of service through a crash or panic, and in the worst case local privilege escalation or kernel-level code execution.

Why it matters to the business

Successful exploitation could allow a user or compromised local workload to crash a Linux host or potentially gain elevated privileges on it. This is most relevant for multi-user systems, shared compute, container hosts, CI runners, appliances, and servers where untrusted or semi-trusted users can execute code. Because exploitation requires local access and there is no known public exploit or KEV listing at this time, urgency is moderate, but kernel issues with high confidentiality, integrity, and availability impact should be remediated during the next accelerated kernel maintenance window.

How an attack unfolds

An attacker first needs the ability to run code locally on a vulnerable Linux system. They would then attempt to exercise the SMC networking subsystem, typically by causing the SMC module or subsystem to initialize while also creating or manipulating SMC sockets so that hash-list entries exist or are referenced during initialization. The vulnerable initialization path can reset SMC hash tables that are already in use, leaving stale or corrupted list pointers inside kernel memory. The immediate outcome may be a kernel oops, panic, or service outage. With sufficient kernel exploitation skill and favorable memory-layout conditions, the same corruption primitive could potentially be shaped into a privilege-escalation path.

How to fix it

Upgrade the Linux kernel to a vendor-supported release that includes the upstream fix for net/smc preventing reinitialization of smc_v4_hashinfo.ht and smc_v6_hashinfo.ht during smc_init(). If exact package versions are not provided by the advisory feed, use the distribution vendor’s security advisory, kernel changelog, or source package to confirm inclusion of the patch titled "net/smc: Do not re-initialize smc hashtables". Reboot into the fixed kernel after installation; installing a kernel package without rebooting does not remove exposure. If SMC is not required, reduce exposure by disabling or preventing loading of the SMC kernel module where applicable, for example by blacklisting the smc module and rebuilding initramfs according to distribution guidance. Where SMC is built into the kernel, module blacklisting will not mitigate the issue. Limit local shell access, restrict untrusted workloads, and apply container hardening to reduce opportunities for local exploitation until patched.

How to confirm the fix worked

Confirm the running kernel, not only the installed kernel package, has been updated. Check the active version with uname -r and compare it against the distribution advisory for this vulnerability. Review kernel package changelogs or source patches for the fix referencing "net/smc: Do not re-initialize smc hashtables" or removal of the dangerous INIT_HLIST_HEAD calls for smc_v4_hashinfo.ht and smc_v6_hashinfo.ht in smc_init(). Verify whether SMC is present by checking kernel configuration for CONFIG_SMC and whether the smc module is loaded. If SMC was disabled as a mitigation, confirm the module cannot be loaded and that the mitigation persists after reboot. Review dmesg or journalctl -k after reboot to confirm the fixed kernel is active and there are no SMC-related kernel warnings or crashes.

Typical attack path

1. Obtain local code execution as an unprivileged or low-privileged user on a vulnerable Linux system.
2. Check whether the SMC networking subsystem is available as a loaded module, loadable module, or built-in kernel feature.
3. Trigger SMC socket creation or related SMC network activity while the vulnerable initialization sequence is reachable.
4. Cause SMC hash-list reinitialization while entries are present or being referenced.
5. Leverage the resulting kernel list corruption to crash the host or attempt privilege escalation.
6. If privilege escalation succeeds, execute commands with elevated privileges, disable controls, or pivot further from the compromised host.

How to detect it

There are no reliable public exploitation indicators specific to this vulnerability. Detection should focus on signs that the SMC subsystem was exercised followed by kernel memory corruption or crashes. Review kernel logs from journalctl -k, dmesg, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore analysis, and EDR telemetry for SMC-related oops, panic, list-corruption, KASAN, or general-protection-fault events. Pay particular attention to events involving smc, smc_init, AF_SMC socket activity, or module loading shortly before a kernel crash. Audit logs may show local users or workloads repeatedly loading the smc module or executing programs that create SMC sockets. These artifacts are not definitive proof of exploitation because kernel bugs and hardware faults can produce similar symptoms, but they are useful triage leads when correlated with local user activity and crash timing.

• smc_init
• smc_v4_hashinfo
• smc_v6_hashinfo
• net/smc
• smc:
• module smc
• list_del corruption
• list_add corruption
• corrupted list
• kernel BUG at lib/list_debug.c
• BUG: KASAN
• general protection fault
• kernel panic
• Oops:
• RIP: smc_
• Call Trace: smc_
• AF_SMC
• /sys/module/smc
• /proc/modules

What your security team should do

• Prioritize patching shared Linux systems, container hosts, CI/CD runners, bastion hosts, research systems, and any environment where non-administrative users can execute local code.
• Schedule an accelerated kernel update and reboot for affected systems because kernel memory-corruption flaws can have full host impact.
• Use vendor advisories to identify fixed kernel packages and confirm the running kernel includes the net/smc hash-table initialization fix.
• If SMC is not operationally required, disable or blacklist the smc module as a temporary risk-reduction measure until patched.
• Restrict local access and reduce privileges for untrusted users and workloads, especially on multi-tenant or shared compute systems.
• Monitor kernel logs for SMC-related oops, list-corruption, KASAN, or panic messages that may indicate attempted triggering or unstable exposure.
• Track EPSS and exploit-development activity; current EPSS is low and no known exploited status is reported, but local kernel vulnerabilities can become more urgent if public exploit code appears.