CVE-2024-49954

What it actually does

A memory allocation failure inside __static_call_add_module called from static_call_module_notify triggers a WARN_ON that panics the kernel when panic_on_warn is enabled, even though the error is correctly propagated to userspace.

Why it matters to the business

Systems running affected Linux kernels with panic_on_warn set can experience unexpected crashes and reboots triggered by routine module operations, causing service outages and potential data loss on affected servers and embedded devices.

How an attack unfolds

An attacker with the ability to load kernel modules or trigger module-related operations causes a low-memory condition that leads __static_call_add_module to fail allocation; the resulting WARN_ON then forces a panic if the sysctl is set, achieving denial of service without needing code execution.

How to fix it

Update to a kernel containing commit bc9356513d56b688775497b7ac6f2b967f46a80c. For Rocky Linux 8 systems, upgrade nodejs-nodemon to 0:2.0.3-1.module+el8.6.0+982+9fdca2d4 or nodejs-packaging to 0:23-3.module+el8.7.0+1071+4bdda2a8. Disable panic_on_warn as a temporary mitigation if patching is delayed.

How to confirm the fix worked

Confirm the running kernel contains bc9356513d56b688775497b7ac6f2b967f46a80c or later; verify the WARN_ON has been replaced by pr_warn in static_call_module_notify; test module load under memory pressure without triggering panic.

Typical attack path

1. Obtain ability to trigger module load or notify events on target system
2. Induce memory pressure so __static_call_add_module allocation fails
3. Trigger static_call_module_notify via the module load path
4. Cause WARN_ON to fire and panic the kernel when panic_on_warn=1

How to detect it

Review kernel logs and crash dumps for warnings or panics originating from static_call_module_notify or __static_call_add_module; correlate with module load events under memory pressure.

What your security team should do

• Apply the listed kernel and package updates immediately on all affected systems
• Audit kernel configurations for panic_on_warn and disable where not required
• Monitor for kernel oops or panic logs referencing static_call_module_notify
• Prioritize patching on systems with high availability requirements