CVE-2024-48876

What it actually does

The stack_depot_save_flags() function attempts to acquire pool_lock without checking for NMI context when STACK_DEPOT_FLAG_CAN_ALLOC is unset, allowing a deadlock when an NMI occurs while the lock is held.

Why it matters to the business

Kernel deadlocks can cause system freezes or crashes during interrupt handling, leading to unplanned downtime and reduced reliability for Linux-based systems and services.

How an attack unfolds

An attacker triggers conditions that hold pool_lock while simultaneously causing an NMI to invoke stack_depot_save_flags(), forcing the lock acquisition attempt in NMI context and resulting in deadlock.

How to fix it

Apply the upstream fix by updating the Linux kernel to commit 9bfeeeff2c92b9dd261198b601b45bde4c529841 or a later equivalent stable release containing the change; rebuild and deploy the patched kernel across affected systems.

How to confirm the fix worked

Verify the running kernel contains commit 9bfeeeff2c92b9dd261198b601b45bde4c529841 via git log or kernel version string; test stack_depot_save_flags() calls from NMI context to confirm no lock acquisition occurs.

Typical attack path

1. Identify or create workload that acquires pool_lock in stack depot operations
2. Force or wait for NMI context while lock is held
3. Invoke stack_depot_save_flags() without allocation flag from NMI
4. Trigger deadlock and system unresponsiveness

How to detect it

Inspect kernel logs for deadlock warnings, NMI-related stack traces involving pool_lock, or soft lockup messages; correlate with processes or drivers invoking stack depot functions around the time of the event.

What your security team should do

• Prioritize kernel updates on systems with high NMI activity or real-time requirements
• Monitor for kernel deadlock reports or watchdog timeouts post-deployment
• Review NMI handlers and stack depot usage in custom kernel modules
• Schedule broad rollout after validation in staging environments