CVE-2024-36945

What it actually does

Refcount leak of neighbour objects from neigh_lookup() and rtable objects from ip_route_output_flow() in smc_ib_find_route() due to missing release before function return, allowing gradual resource exhaustion in the Linux kernel SMC subsystem.

Why it matters to the business

Linux systems using SMC over RDMA or InfiniBand networks may experience gradual memory pressure or resource exhaustion, potentially leading to degraded network performance or instability if the affected code path is triggered repeatedly; urgency is low given absence from KEV and stable low EPSS.

How an attack unfolds

An attacker triggers repeated calls to smc_ib_find_route() through crafted SMC connection setup sequences that exercise neighbour and route resolution without allowing cleanup, causing incremental refcount leaks; no named threat actors or ransomware campaigns are associated with this issue.

How to fix it

Apply the kernel patch that resolves the leak, specifically updating to commit d5a466ab6e78d6f2e0f64435f1e17246c8e941ff or later stable releases containing this fix; rebuild and deploy updated kernel images across affected systems.

How to confirm the fix worked

Verify the running kernel contains commit d5a466ab6e78d6f2e0f64435f1e17246c8e941ff or equivalent backport; inspect source for proper neigh_release() and dst_release() calls after neigh_lookup() and ip_route_output_flow() in smc_ib_find_route().

Typical attack path

1. Establish conditions that invoke SMC connection setup requiring route resolution
2. Force repeated execution of smc_ib_find_route() via network traffic patterns or local processes
3. Accumulate unreleased neighbour and rtable references over time
4. Monitor for system-wide memory or resource pressure leading to degraded operation

How to detect it

Review kernel logs and memory usage statistics for anomalous growth in neighbour or route cache entries correlated with SMC activity; no public exploit artifacts or threat actor TTPs are known.

What your security team should do

• Prioritize kernel updates on systems with SMC/RDMA workloads within standard patch cycles
• Monitor upstream stable kernel releases for additional SMC-related fixes
• Review network configurations to limit unnecessary SMC usage where feasible