CVE-2024-26615

What it actually does

NULL pointer dereference in __smc_diag_dump when an SMC-D connection has been registered via smc_conn_create but rmb_desc has not yet been initialized by smc_buf_create, triggered during netlink socket diagnostics dump.

Why it matters to the business

Local users or monitoring processes can trigger kernel crashes and system instability on Linux hosts running affected kernels, leading to service outages and requiring reboots during high-connection workloads.

How an attack unfolds

An attacker with local access runs a tool that continuously invokes SMC-D connection dumps (such as smcss -D) while other processes establish SMC connections under load; the race between registration and buffer initialization causes the kernel NULL dereference and panic.

How to fix it

Upgrade the Linux kernel to a fixed version: Debian 12/13 packages 6.1.7-1 or later, or apply commit 27aea64838914c6122db5b8bd4bed865c9736f22 from the stable git tree; reboot after installation.

How to confirm the fix worked

Verify the running kernel version contains the fix commit or package 6.1.7-1+; attempt to reproduce the original crash scenario (smc_run wrk + watch smcss -D) and confirm no NULL dereference occurs.

Typical attack path

1. Obtain local shell or execute privileged diagnostic commands on target Linux host
2. Start or trigger SMC-D connection establishment (e.g., via smc_run nginx/wrk test)
3. Concurrently invoke repeated SMC diagnostics dumps via netlink (smc_diag_handler_dump)
4. Trigger the window where conn->rmb_desc is still NULL, causing page fault in __smc_diag_dump
5. Kernel oops/panic results in denial of service

How to detect it

Search kernel logs (dmesg, /var/log/kern.log, journalctl) for oops/panic entries containing __smc_diag_dump, smc_diag, page_fault_oops, and address 0000000000000030; correlate timestamps with smcss or netlink dump activity.

• BUG: kernel NULL pointer dereference, address: 0000000000000030
• __smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag]
• RIP: 0010:__smc_diag_dump.constprop.0
• smc_diag_dump_proto+0xd0/0xf0 [smc_diag]

What your security team should do

• Prioritize kernel upgrades on all systems exposing SMC-D or running smc_diag
• Restrict unprivileged access to netlink socket diagnostics where possible
• Monitor for kernel panics referencing smc_diag and schedule patching before the next maintenance window
• Test the fix in a staging environment that reproduces high-connection SMC workloads