CVE-2026-53361 in Linux
Summary
by MITRE • 07/04/2026
In the Linux kernel, the following vulnerability has been resolved:
af_unix: Set gc_in_progress to true in unix_gc().
Igor Ushakov reported that unix_gc() could run with gc_in_progress being false if the work is scheduled while running:
Thread 1 Thread 2 Thread 3 -------- -------- -------- unix_schedule_gc() unix_schedule_gc() `- if (!gc_in_progress) `- if (!gc_in_progress) |- gc_in_progress = true | `- queue_work() | unix_gc() <----------------/ | | |- gc_in_progress = true ... `- queue_work() | | `- gc_in_progress = false | | unix_gc() <---------------------------------------------' | ... /* gc_in_progress == false */ | `- gc_in_progress = false
unix_peek_fpl() relies on gc_in_progress not to confuse GC by MSG_PEEK.
Let's set gc_in_progress to true in unix_gc().
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 07/04/2026
The vulnerability described represents a race condition in the Linux kernel's UNIX domain socket implementation that could lead to incorrect garbage collection behavior and potential security implications. This issue affects the af_unix subsystem which handles UNIX domain sockets, a fundamental component of inter-process communication in Unix-like operating systems. The problem manifests when multiple threads attempt to manage the garbage collection process simultaneously, creating a scenario where the gc_in_progress flag does not accurately reflect the actual state of garbage collection operations.
The technical flaw occurs within the unix_gc() function where the gc_in_progress flag is not properly set before garbage collection begins. According to the reported behavior, when unix_schedule_gc() is called from multiple threads, there exists a window where gc_in_progress remains false even though work has been scheduled. This race condition allows for multiple concurrent garbage collection processes to execute simultaneously or for operations that depend on gc_in_progress to proceed incorrectly. The sequence shows Thread 1 and Thread 2 both checking gc_in_progress which is false, setting it to true, and queueing work. However, subsequent calls to unix_gc() can occur with gc_in_progress still false, creating a dangerous inconsistency in the socket subsystem's internal state management.
The operational impact of this vulnerability extends beyond simple functional instability into potential security implications for systems relying on UNIX domain sockets. The unix_peek_fpl() function specifically depends on gc_in_progress remaining true during garbage collection to prevent confusion between peek operations and actual garbage collection activities. When this flag becomes false incorrectly, it can lead to malformed data handling and potentially allow attackers to exploit timing variations in socket operations. This vulnerability directly relates to CWE-362 which describes race conditions in concurrent programming, and could be classified under ATT&CK technique T1059.007 for process injection or command and scripting interpreter techniques that might leverage socket manipulation.
The fix implemented involves explicitly setting gc_in_progress to true within the unix_gc() function before beginning garbage collection operations, ensuring that all dependent functions receive accurate state information. This approach prevents the race condition by establishing proper synchronization between scheduling and execution phases of garbage collection. The mitigation strategy addresses the core issue without disrupting existing functionality while maintaining the intended semantics of the gc_in_progress flag. This solution aligns with kernel security best practices for concurrent data structure management and follows established patterns for avoiding race conditions in kernel-level code. The fix ensures that socket operations relying on gc_in_progress maintain their expected behavior regardless of thread scheduling variations, thereby preserving system stability and preventing potential exploitation opportunities through timing-based attacks against the UNIX domain socket subsystem.