CVE-2024-36975

What it actually does

The flaw replaces an erroneous WARN() call on asn1_encode_sequence() failure in the trusted keys subsystem with pr_err(), preventing potential kernel panic when panic_on_warn is enabled.

Why it matters to the business

Affected Linux systems risk unexpected crashes during key operations, causing downtime in servers and devices; low EPSS and no KEV status after 848 days indicate limited active threat but stability concerns remain for large deployments.

How an attack unfolds

An attacker triggers a failure path in asn1_encode_sequence() within trusted key encoding; the WARN() macro then executes, and if panic_on_warn is configured the kernel panics, resulting in denial of service. No named threat actors or ransomware campaigns are associated.

How to fix it

Upgrade the Linux kernel to the fixed commit 96f650995c70237b061b497c66755e32908f8972 or an equivalent stable release containing the pr_err() change.

How to confirm the fix worked

Verify the running kernel contains commit 96f650995c70237b061b497c66755e32908f8972; inspect the source to confirm pr_err() and return-value logging replace the prior WARN() call.

Typical attack path

1. Identify or create conditions causing asn1_encode_sequence() to fail in the trusted keys code path
2. Invoke the failing encode operation
3. Trigger WARN() which may panic the kernel if panic_on_warn is set

How to detect it

Search kernel logs and dmesg for messages referencing asn1_encode_sequence failures or WARN triggers in the trusted keys module; correlate with any resulting panic traces.

What your security team should do

• Apply the kernel update to all affected systems within standard maintenance windows
• Audit kernel configurations for panic_on_warn and consider disabling it where feasible
• Monitor kernel logs for asn1_encode errors in the trusted keys subsystem