Executive Summary

This vulnerability exists in the Linux kernel's tiny SRCU (Sleepable Read-Copy Update) implementation. The function srcu_gp_start_if_needed() directly calls schedule_work(), which acquires a lock on the workqueue pool. This leads to a lock dependency cycle (lockdep splat) when call_srcu() is called while holding a scheduler lock, causing potential deadlocks or kernel warnings.

Additionally, there was a risk of a use-after-free condition if a queued irq_work fired after cleanup_srcu_struct() began. The fix involved using irq_work to start the grace period and adding irq_work_sync() to cleanup_srcu_struct() to prevent this use-after-free.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can cause kernel lock dependency issues, potentially leading to deadlocks or kernel warnings that affect system stability. The use-after-free risk could lead to undefined behavior or kernel crashes if irq_work fires after cleanup has started.

Overall, it impacts the reliability and stability of the Linux kernel, which could affect any system running a vulnerable kernel version.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability relates to a lockdep splat caused by the interaction of srcu_gp_start_if_needed() and schedule_work() when called with a scheduler lock held in the Linux kernel.

Detection would involve monitoring for lockdep warnings related to SRCU (Sleepable Read-Copy Update) and scheduler locks in the kernel logs.

You can check for lockdep warnings by examining the kernel log using commands such as:

• dmesg | grep -i lockdep
• journalctl -k | grep -i lockdep

Additionally, running kernel debugging tools like rcutorture SRCU-T tests can help identify this issue as it was tested with these tools.

Useful 0 Not Useful 0

Mitigation Strategies

The vulnerability has been resolved by modifying srcu_gp_start_if_needed() to use irq_work to start GP in tiny SRCU, preventing the lockdep splat.

Immediate mitigation steps include:

• Update your Linux kernel to a version that includes the fix for this vulnerability.
• Ensure that irq_work_sync() is added to cleanup_srcu_struct() to prevent use-after-free conditions.
• Avoid running workloads or kernel modules that trigger call_srcu() with scheduler locks held until the fix is applied.

Useful 0 Not Useful 0