CVE-2024-56718

What it actually does

Use-after-free in the SMC module where smc_link_down_work can execute after the link group (lgr) structure is freed, resulting in list corruption and kernel panic during workqueue processing.

Why it matters to the business

Systems using Linux kernel SMC networking can experience sudden kernel crashes leading to denial of service, potential data loss for in-flight operations, and unplanned downtime; high prevalence in cloud and enterprise Linux deployments increases operational risk.

How an attack unfolds

An attacker with local access triggers scheduling of link down work while concurrently freeing the associated link group structure; when the work item later runs it dereferences freed memory, corrupting internal lists and causing a kernel BUG and panic. No remote unauthenticated path or named threat actor exploitation is known for this specific issue.

How to fix it

Upgrade the Linux kernel to a version containing commit bec2f52866d511e94c1c37cd962e4382b1b1a299 or later; apply the corresponding stable or distribution kernel package update that includes the reference-counting fix for the link down work item.

How to confirm the fix worked

Confirm the running kernel contains the fix commit or is newer than the vulnerable version; reproduce link up/down events under memory pressure and verify absence of the list_del corruption BUG; review kernel logs for smc_link_down_work crashes.

Typical attack path

1. Obtain local code execution on a Linux system using the SMC module
2. Trigger network link events that schedule smc_link_down_work
3. Force concurrent freeing of the link group (lgr) structure
4. Allow the work item to execute after the structure is released
5. Observe list_del corruption and kernel panic

How to detect it

Search kernel logs for the strings 'list_del corruption', '__list_del_entry_valid', and 'smc_link_down_work' near the time of any spontaneous reboot or kdump; examine workqueue activity and SMC module traces for concurrent link down and lgr free events.

What your security team should do

• Prioritize kernel updates on all systems exposing SMC interfaces within the next patch cycle
• Monitor EPSS trend and kernel mailing list for any increase in exploit maturity
• Restrict untrusted local access on systems where SMC is enabled until patched
• Test the updated kernel in staging environments before broad deployment