Linux Kernel Garbage Collection and MSG_PEEK Race Condition Vulnerability in af_unix

A vulnerability in the Linux kernel's af_unix implementation has been addressed, concerning the garbage collection (GC) process and the MSG_PEEK flag. When MSG_PEEK is used, it can inadvertently disrupt the GC's ability to accurately assess the state of sockets, leading to potential issues. This vulnerability arises because MSG_PEEK increases a socket's file reference count without coordinating with the GC. The problem becomes evident in scenarios where one socket (sk-A) is closed but can still be accessed through another socket (sk-B). If MSG_PEEK is applied to sk-B while the GC is evaluating the status of both sockets, it can create a false impression that sk-A is no longer in use, allowing the GC to prematurely clear it from the receive queue. This issue was previously resolved in an earlier commit but reemerged after changes were made to the GC algorithm. The vulnerability has been fixed by reintroducing a mechanism to properly synchronize MSG_PEEK with the GC process, ensuring that such races do not occur.

Impact

The vulnerability can lead to incorrect socket management, where active sockets are mistakenly identified as inactive, potentially causing disruptions in communication or data handling.

Reproduction

To reproduce this vulnerability, create a scenario with two sockets, sk-A and sk-B. Close sk-A but ensure it can still be received through sk-B. While the garbage collection process is checking the status of both sockets, use MSG_PEEK on sk-B. This will increase sk-A's file reference count, causing the garbage collector to incorrectly conclude that sk-A is no longer active. Subsequently, close sk-B, which will further complicate the reference counting, allowing the garbage collector to mistakenly identify both sockets as inactive.

Remediation

The vulnerability has been fixed in the Linux kernel. Users should upgrade to the latest version where this issue has been addressed.