CVE-2026-64048: net/smc: reject CHID-0 ACCEPT that matches an empty ism_dev slot
In the Linux kernel, the following vulnerability has been resolved:
net/smc: reject CHID-0 ACCEPT that matches an empty ismdev slot
On the SMC-D client, slot 0 of ini->ismdev[]/ini->ismchid[] is reserved for an SMC-Dv1 device. smcfindismv2deviceclnt() populates V2 entries starting at index 1, so when no V1 device is selected slot 0 is left in its kzalloc()'ed state with ismdev[0] == NULL and ismchid[0] == 0.
smcv2determineacceptedchid() then matches the peer's CHID against the array starting from index 0 using the CHID alone. A malicious peer replying to a SMC-Dv2-only proposal with d1.chid == 0 matches the empty slot, ini->ismselected becomes 0, and the subsequent ismdev[0]->lgrlock dereference in smcconncreate() faults at offsetof(struct smcddev, lgrlock) == 0x68:
BUG: KASAN: null-ptr-deref in rawspinlockbh+0x79/0xe0 Write of size 4 at addr 0000000000000068 by task exploit/144 Call Trace: rawspinlockbh smcconncreate (net/smc/smccore.c:1997) smcconnect (net/smc/afsmc.c:1447) smcconnect (net/smc/afsmc.c:1720) sysconnect x64sysconnect dosyscall64
Require ismdev[i] to be non-NULL before accepting a CHID match.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this issue?
Exposure is limited to Linux kernel SMC-D clients using an SMC-Dv2-only proposal where no SMC-Dv1 device has been selected. In that state, the reserved first ISM device slot is empty but has CHID 0.
What does an attacker need to do to trigger the failure?
A malicious peer must reply to an SMC-Dv2-only proposal with a CHID value of 0. The client can then select the empty slot and dereference a null ism_dev pointer while creating the connection.
What is the practical impact of successful exploitation?
The described outcome is a kernel null-pointer dereference during SMC connection creation, causing a fault. The supplied CVSS vector rates the impact as high availability impact, with no confidentiality or integrity impact.
How can I tell whether a system has encountered this vulnerability?
The provided failure signature is a KASAN null-pointer dereference in _raw_spin_lock_bh called from smc_conn_create, with a write at address 0x68. The call trace includes __smc_connect, smc_connect, and the connect system call.