CVE-2024-44935 in Linux
Riassunto
di VulDB • 14/06/2026
This is a **kernel panic** (or at least a severe kernel oops) occurring in the Linux kernel's **SCTP (Stream Control Transmission Protocol)** implementation.
### Key Information from the Trace
1. **Faulting Instruction**: * `knlGS:0000000000000000` indicates a **NULL pointer dereference** or an invalid access to the GS segment (often used for thread-local storage or per-CPU data in x86_64). * The crash happens inside `__sctp_hash_endpoint`.
2. **Call Trace**: ``` __sctp_hash_endpoint net/sctp/input.c:762 [inline]
sctp_hash_endpoint+0x52a/0x600 net/sctp/input.c:790 sctp_listen_start net/sctp/socket.c:8570 [inline]
sctp_inet_listen+0x767/0xa20 net/sctp/socket.c:8625 __sys_listen_socket net/socket.c:1883 [inline]
__sys_listen+0x1b7/0x230 net/socket.c:1894 ... ``` * The crash occurs when a user-space process calls the `listen()` system call on an SCTP socket. * The kernel tries to hash the endpoint into the SCTP endpoint hash table. * The crash is in `__sctp_hash_endpoint`, which suggests that a pointer expected to be valid (likely `ep` or `net` or `hash_table`) is **NULL** or corrupted.
3. **Registers**: * `RAX: ffffffffffffffda` → This is `-42` in two's complement, which is `ERR_PTR(-42)` or similar error encoding. However, in the context of a crash, it might be the value being dereferenced. * `CR2: 00007ffcced5f7b8` → This is the **faulting virtual address**. It is a user-space address (high bit set, in the stack/heap range). This is unusual for a kernel NULL deref. It suggests the kernel tried to dereference a pointer that looks like a user-space address, which is a **major security/stability bug**.
### Likely Cause
The most probable cause is a **NULL pointer dereference** or **use-after-free** in `__sctp_hash_endpoint`. Specifically:
* The function `__sctp_hash_endpoint` expects a valid `struct sctp_endpoint *ep`. * If `ep` is NULL, or if `ep->net` is NULL, or if the hash table pointer is NULL, the kernel will crash. * The fact that `CR2` is a user-space address suggests that a pointer field within the `sctp_endpoint` structure (or a related structure) contains a garbage value that happens to look like a user-space address. This could be due to: 1. **Memory corruption**: The `sctp_endpoint` structure was freed or overwritten. 2. **Race condition**: The endpoint was partially initialized or torn down while `listen()` was being called. 3. **Bug in SCTP code**: A recent commit may have introduced a bug where a pointer is not properly initialized before being used in `__sctp_hash_endpoint`.
### How to Debug Further
1. **Check Kernel Version**: * Identify the exact kernel version (`uname -r`). * Search for known SCTP bugs in that version.
2. **Reproduce the Issue**: * Try to reproduce the crash with a minimal test case that calls `listen()` on an SCTP socket. * Use `kdump` to analyze the core dump if available.
3. **Check for Recent Changes**: * If this is a new issue, check recent commits to `net/sctp/input.c` and `net/sctp/socket.c`.
4. **Enable Debugging**: * Recompile the kernel with `CONFIG_SCTP_DEBUG=y` and `CONFIG_KASAN=y` (Kernel Address Sanitizer) to get more detailed information about memory corruption.
5. **Look for Similar Bugs**: * Search for "sctp_hash_endpoint NULL pointer dereference" or "sctp listen kernel panic" in bug trackers (e.g., kernel.org, Red Hat Bugzilla, Ubuntu Launchpad).
### Example of a Potential Fix (Hypothetical)
If the bug is that `ep` is NULL, the fix would be to add a NULL check
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.