Executive brief
A vulnerability in the Linux kernel's memory leak detection tool (kmemleak) can cause a system to become unresponsive. When the tool attempts to clean up a large number of tracked memory objects, it can monopolize the processor for an extended period, leading to a 'soft lockup.' This primarily affects systems running debug kernels or specific workloads that trigger mass memory object deletion, potentially resulting in a denial-of-service.
Technical details
A soft lockup vulnerability exists in the __kmemleak_do_cleanup() function within mm/kmemleak.c. When kmemleak is disabled (e.g., due to memory pool exhaustion), it attempts to remove and delete all existing kmemleak objects one-by-one in a loop. In environments with a large number of objects (e.g., 40,000+) and the overhead of a debug kernel, the cumulative time spent acquiring and releasing raw_spinlocks in __delete_object() without yielding the CPU causes a watchdog timeout. The fix introduces cond_resched() every 64 iterations to allow the scheduler to run other tasks. This is reachable by local users who can trigger workloads that exhaust the kmemleak memory pool or trigger cleanup.
Affected products
- Linux Linux Kernel 5.4 to 5.4.297, 5.5 to 5.10.241, 5.11 to 5.15.190, 5.16 to 6.1.149, 6.2 to 6.6.103, 6.7 to 6.12.43, 6.13 to 6.15.11, 6.16 to 6.16.2
Timeline
- 2025-09-11: advisory: Initial NVD publication
- 2025-07-28: patched: Fix authored by Waiman Long
References
- https://git.kernel.org/stable/c/1ef72a7fedc5bca70e8cc980985790de10d407aa
- https://git.kernel.org/stable/c/8d2d22a55ffe35c38e69795468a7addd1a80e9ce
- https://git.kernel.org/stable/c/926092268efdf1ed7b55cf486356c74a9e7710d1
- https://git.kernel.org/stable/c/9b80430c194e4a114dc663c1025d56b4f3d0153d
- https://git.kernel.org/stable/c/9f1f4e95031f84867c5821540466d62f88dab8ca
- https://git.kernel.org/stable/c/a04de4c40aab9b338dfa989cf4aec70fd187eeb2
- https://git.kernel.org/stable/c/d1534ae23c2b6be350c8ab060803fbf6e9682adc