CVE-2026-64048

What it actually does

This is a remotely reachable denial-of-service flaw in the Linux kernel SMC-D networking code. During SMC-Dv2 connection negotiation, a malicious peer can send an ACCEPT response with CHID value 0. On affected kernels, the client-side selection logic may incorrectly match that CHID against an empty reserved slot where the ISM device pointer is NULL. The kernel then dereferences that NULL pointer while creating the SMC connection, leading to a kernel fault/oops and potentially a system crash or service interruption. The flaw does not provide confidentiality or integrity impact based on the available description, but it can cause high availability impact.

Why it matters to the business

Systems using affected Linux kernels with SMC-D enabled or reachable over networks where SMC negotiation can occur may be crashed or destabilized by an unauthenticated remote peer. The operational impact is primarily outage risk: interrupted applications, failed network services, node reboots, workload disruption, and possible cascading availability issues in clustered environments. The CVSS score is high at 7.5 because exploitation is network-accessible, low complexity, and requires no authentication or user interaction. EPSS is currently low and there is no known KEV listing or reported ransomware use, so prioritization should focus first on exposed or business-critical Linux systems that use SMC/SMC-D.

How an attack unfolds

An attacker positions a malicious endpoint so that a vulnerable Linux system initiates or negotiates an SMC-Dv2 connection with it. The attacker responds to the SMC-Dv2-only proposal with an ACCEPT message containing d1.chid set to 0. The vulnerable kernel compares the peer-provided CHID against the local ISM CHID array starting at index 0 and incorrectly treats the uninitialized reserved slot as a valid match because its zeroed CHID value is also 0. The kernel records slot 0 as selected even though the associated ISM device pointer is NULL. When connection creation continues, the kernel attempts to access the lgr_lock member through that NULL device pointer, triggering a NULL pointer dereference in the kernel networking path. The result is a kernel oops, crash, or degraded availability of the affected host.

How to fix it

Upgrade to a Linux kernel version that includes the upstream fix requiring ism_dev[i] to be non-NULL before accepting a CHID match in the SMC-D client path. If using a distribution kernel, apply the vendor security update or errata package containing the fix for this issue. Where immediate patching is not possible, reduce exposure by disabling SMC/SMC-D if it is not required, restricting network paths to systems that can negotiate SMC connections, and limiting untrusted peer access. Because no product-specific fixed versions were provided, use distribution advisories, kernel changelogs, or package metadata to confirm that the patch for the SMC-D CHID-0 ACCEPT handling issue is present.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package includes the fix for the SMC-D CHID-0 ACCEPT validation logic, not only that the package is installed on disk. Check the active kernel version after reboot, review vendor advisory status, and confirm the relevant patch is included in the deployed kernel source or changelog. Where feasible in a controlled test environment, validate that a crafted SMC-Dv2 ACCEPT with CHID 0 is rejected and does not produce a kernel oops. Also confirm whether SMC/SMC-D is enabled or in use; systems without SMC-D exposure have significantly reduced practical risk.

Typical attack path

1. Identify a Linux system where SMC/SMC-D networking is enabled and reachable for connection negotiation.
2. Cause or wait for the vulnerable system to initiate an SMC-Dv2-capable connection to an attacker-controlled peer.
3. Return a crafted SMC-D ACCEPT response with CHID value 0.
4. Trigger the vulnerable CHID selection path so the kernel selects the empty reserved ISM device slot.
5. Allow connection creation to proceed until the kernel dereferences the NULL ISM device pointer.
6. Cause a kernel oops, panic, service disruption, or host reboot depending on kernel configuration and fault handling.

How to detect it

Look for evidence of kernel crashes or oops events in system logs, journal entries, crash dumps, and kernel ring buffers. Useful sources include journalctl -k, /var/log/kern.log, /var/log/messages, /var/log/syslog, dmesg output, kdump/vmcore artifacts, crash reporting systems, hypervisor reset logs, and uptime/reboot telemetry. Search for NULL pointer dereferences and stack traces involving the Linux SMC subsystem, especially smc_conn_create, __smc_connect, smc_connect, smc_v2_determine_accepted_chid, and _raw_spin_lock_bh. If packet capture or network telemetry is available, look for SMC-D negotiation followed shortly by host instability or a kernel fault, particularly where the peer's accepted CHID is 0. Since exploitation is expected to cause availability impact rather than persistent compromise, durable host-based IOCs may be limited to crash artifacts and kernel log messages.

• BUG: KASAN: null-ptr-deref in _raw_spin_lock_bh
• null-ptr-deref in _raw_spin_lock_bh
• Write of size 4 at addr 0000000000000068
• smc_conn_create
• __smc_connect
• smc_connect
• smc_v2_determine_accepted_chid
• net/smc/smc_core.c
• net/smc/af_smc.c
• offsetof(struct smcd_dev, lgr_lock) == 0x68
• KASAN: null-ptr-deref
• kernel NULL pointer dereference
• Oops: 0000
• BUG: kernel NULL pointer dereference

What your security team should do

• Inventory Linux systems running kernels that include SMC/SMC-D support, especially servers with high availability requirements or exposure to untrusted networks.
• Prioritize patching internet-facing, externally connected, or business-critical Linux systems where SMC negotiation may be reachable.
• Apply vendor kernel updates that include the SMC-D CHID validation fix, then reboot into the fixed kernel.
• If patching must be delayed, disable SMC/SMC-D where operationally acceptable or restrict SMC-capable traffic to trusted peers only.
• Monitor kernel logs for NULL pointer dereference, KASAN, oops, or panic events involving smc_conn_create, smc_connect, _raw_spin_lock_bh, or net/smc code paths.
• Treat repeated kernel faults in the SMC connection path as suspicious, especially if correlated with connections from the same remote peer or network segment.
• Because this issue is not currently listed in KEV and has low EPSS, track for changes in exploit availability, EPSS trend, and vendor advisories, but do not defer remediation on exposed critical systems.