CVE-2025-39857

What it actually does

NULL pointer dereference in smc_ib_is_sg_need_sync() when ibdev->dma_device is null for software RoCE devices, triggered during SMC buffer creation in the listen workqueue, resulting in kernel oops and potential denial of service.

Why it matters to the business

Systems using SMC over software-emulated RoCE devices may experience unexpected kernel crashes during network connection handling, leading to service interruptions and requiring reboots; low exploitability reduces immediate widespread risk but affects kernel stability in specialized RDMA environments.

How an attack unfolds

An attacker with local access triggers SMC listen operations on a host configured with a software RoCE device; the call path through smc_listen_work, smc_find_rdma_v2_device_serv, and buffer creation reaches the vulnerable function without null checks, dereferencing a null dma_device pointer and crashing the kernel.

How to fix it

Apply kernel patch from commit 0cdf1fd8fc59d44a48c694324611136910301ef9 or later stable releases; rebuild and deploy updated kernel images; for Debian-packaged environments ensure libtasn1 updates to 3.6-1 where applicable alongside kernel upgrades.

How to confirm the fix worked

Verify kernel version includes the referenced commit; test SMC listen operations with software RoCE device emulation to confirm absence of NULL dereference oops; review dmesg for resolved crash signatures in smc_ib_is_sg_need_sync.

Typical attack path

1. Obtain local access or trigger SMC connection handling via unprivileged process
2. Ensure target uses software RoCE device (ibdev->dma_device null)
3. Initiate SMC listen or RDMA v2 device service lookup
4. Force execution of smc_buf_create and smcr_buf_map_link paths
5. Reach smc_ib_is_sg_need_sync without null guard, causing dereference

How to detect it

Inspect kernel logs for Oops messages referencing smc_ib_is_sg_need_sync, smc_listen_work, and address 00000000000002ec; correlate with kworker processes in SMC workqueues; search system logs for tainted OOT_MODULE entries around SMC module loads.

What your security team should do

• Prioritize kernel updates on systems exposing SMC/RDMA interfaces
• Audit workloads for software RoCE usage and isolate or disable where feasible
• Monitor for kernel oops in SMC workqueues as part of stability checks
• Track EPSS and threat actor mentions for any escalation in exploit maturity