CVE-2023-54268 in Linuxinfo

Summary

by MITRE • 12/30/2025

In the Linux kernel, the following vulnerability has been resolved:

debugobjects: Don't wake up kswapd from fill_pool()

syzbot is reporting a lockdep warning in fill_pool() because the allocation from debugobjects is using GFP_ATOMIC, which is (__GFP_HIGH | __GFP_KSWAPD_RECLAIM) and therefore tries to wake up kswapd, which acquires kswapd_wait::lock.

Since fill_pool() might be called with arbitrary locks held, fill_pool() should not assume that acquiring kswapd_wait::lock is safe.

Use __GFP_HIGH instead and remove __GFP_NORETRY as it is pointless for !__GFP_DIRECT_RECLAIM allocation.

If you want to get best quality of vulnerability data, you may have to visit VulDB.

Analysis

by VulDB Data Team • 04/27/2026

The vulnerability CVE-2023-54268 represents a critical concurrency issue within the Linux kernel's debugobjects subsystem that can lead to system instability and potential deadlock conditions. This flaw manifests when the kernel attempts to manage debug object allocations during memory pool filling operations, creating a scenario where the kernel's memory management subsystem can inadvertently cause itself to hang. The issue specifically affects the fill_pool() function which is responsible for populating memory pools used for debugging purposes in the kernel's memory management framework.

The technical root cause stems from improper memory allocation flags being used within the debugobjects subsystem. When fill_pool() executes, it attempts to allocate memory using GFP_ATOMIC flags which include __GFP_HIGH and __GFP_KSWAPD_RECLAIM bits. These flags instruct the kernel to potentially wake up the kswapd kernel thread responsible for background memory management and page reclamation. However, fill_pool() may be invoked while holding arbitrary locks, creating a dangerous dependency where the function attempts to acquire kswapd_wait::lock while other locks are already held, leading to potential deadlock scenarios. This violates fundamental kernel locking principles and can result in system-wide hangs or unresponsive states.

The operational impact of this vulnerability extends beyond simple system instability to potentially compromise system availability and reliability in production environments. When the kernel's memory management subsystem enters a deadlock state due to this condition, it can cause the entire system to become unresponsive, requiring manual intervention or reboot to restore functionality. The vulnerability is particularly concerning because it can occur during normal system operation when memory pools are being managed, making it difficult to predict or prevent. This issue affects systems running Linux kernel versions where debugobjects are enabled, potentially impacting servers, embedded systems, and other environments where kernel debugging features are active.

The mitigation strategy involves modifying the allocation flags used in the fill_pool() function to eliminate the problematic kswapd wake-up behavior. By changing from the current GFP_ATOMIC flags to __GFP_HIGH and removing the unnecessary __GFP_NORETRY flag, the kernel can avoid the deadlock condition while maintaining proper memory allocation functionality. This solution aligns with the principle of avoiding lock acquisitions during atomic operations and follows established kernel development practices for managing memory allocation in critical subsystems. The fix specifically addresses the CWE-362 weakness related to race conditions and improper locking, while also mitigating potential ATT&CK techniques that could exploit kernel-level concurrency issues to achieve system compromise or denial of service conditions. This remediation ensures that kernel memory management operations can proceed without creating dangerous lock dependency chains that could be exploited or that could cause system instability through deadlock conditions.

Responsible

Linux

Reservation

12/30/2025

Disclosure

12/30/2025

Moderation

accepted

CPE

ready

EPSS

0.00172

KEV

no

Activities

very low

Sources

Interested in the pricing of exploits?

See the underground prices here!