CVE-2026-98559

What it actually does

Use-after-free during traversal of smc_lgr_list.list in smcr_port_err() because the list lock is not held, allowing a concurrent smc_lgr_terminate_sched() to free an entry while it is dereferenced.

Why it matters to the business

Linux systems using SMC may experience kernel crashes, memory corruption, or local privilege escalation; the issue affects kernel stability and security on servers and appliances five days after disclosure.

How an attack unfolds

An attacker with local access triggers concurrent SMC connection teardown and port-error handling paths so that a list entry is freed while smcr_port_err() still dereferences it, leading to a use-after-free.

How to fix it

Apply the upstream fix that holds smc_lgr_list.lock across the traversal and updates smc_ib_gid_check() to invoke smcr_port_err() after releasing the lock; rebuild and boot the patched kernel.

How to confirm the fix worked

Confirm the lock is acquired before the list walk in smcr_port_err() and that smc_ib_gid_check() calls smcr_port_err() only after releasing the lock; test with concurrent SMC termination and port-error workloads.

Typical attack path

1. Obtain local code execution on a Linux host using SMC
2. Create and terminate SMC link groups while forcing port-error callbacks
3. Race smc_lgr_terminate_sched() against smcr_port_err() list walk
4. Trigger dereference of the freed list entry to cause crash or corruption

How to detect it

Review kernel logs for SMC list-related warnings, use-after-free reports, or crashes in smcr_port_err(); inspect audit logs for unusual concurrent SMC connection teardown activity.

What your security team should do

• Prioritize kernel update on all systems that enable SMC
• Monitor for local privilege-escalation attempts targeting kernel list structures
• Restrict untrusted local access until patches are deployed