CVE-2025-39828 in Linux
Riassunto
di VulDB • 19/06/2026
This is a Linux kernel crash dump (Oops) indicating a **NULL pointer dereference** or similar invalid memory access within the ATM (Asynchronous Transfer Mode) network subsystem.
### Key Analysis
1. **Crash Location**: * `vcc_sendmsg+0xa10/0xc60 net/atm/common.c:645` * The crash occurred in the `vcc_sendmsg` function, specifically at line 645 of `net/atm/common.c`. * This function is responsible for sending messages over an ATM Virtual Circuit Connection (VCC).
2. **Triggering System Call**: * The call trace shows the crash was triggered by a `sendmsg` system call (`__x64_sys_sendmsg`). * This means a user-space application attempted to send data over an ATM socket.
3. **Register State**: * `RAX: fffffffffffda` (This is `-22` in signed 64-bit, which is `-EINVAL` - Invalid argument, or potentially a pointer if interpreted differently, but usually indicates an error return or bad pointer). * `CR2: 000000000045ad50` (This is the faulting address. It is **not** `0x0`, so it's not a simple NULL dereference. It's an invalid/unmapped address `0x45ad50`).
4. **Modules**: * `Modules linked in:` is empty, meaning no out-of-tree kernel modules were loaded at the time of the crash. The crash is in core kernel code (`net/atm/`).
### Likely Cause
The crash at `vcc_sendmsg+0xa10` suggests that the kernel tried to dereference a pointer that was either: * **Uninitialized**: A pointer within the `vcc` (ATM VCC) structure or related control block was not properly initialized before use. * **Use-After-Free**: The VCC structure or a related object was freed while still being accessed. * **Corrupted Memory**: The memory containing the VCC structure was corrupted.
Given the faulting address `0x45ad50`, it's likely that a pointer field (e.g., `sk->sk_prot`, `vcc->dev`, or a callback function pointer) contained this invalid value.
### Steps to Investigate
1. **Check Kernel Version**: * Identify the exact kernel version (`uname -r`). This bug might be known and fixed in newer kernels.
2. **Review `net/atm/common.c` around line 645**: * Look at the code in `vcc_sendmsg` near line 645. Identify which pointer is being dereferenced. * Common patterns: `vcc->dev->hard_header`, `sk->sk_prot->sendmsg`, etc.
3. **Check for Recent Changes**: * If this is a custom or recently updated kernel, check for recent commits to `net/atm/`.
4. **Reproduce the Issue**: * Try to reproduce the crash with a minimal test case using an ATM socket. * Use `kdump` and `crash` utility to analyze the core dump if available.
5. **Check for Known Bugs**: * Search for bugs related to `vcc_sendmsg` and `net/atm/common.c` in the Linux kernel bug tracker or mailing lists.
### Example Code Snippet (Hypothetical)
If line 645 looks something like this: ```c err = vcc->dev->hard_header(skb, vcc->dev, type, daddr, saddr, len); ``` Then the crash might be because `vcc->dev` is NULL or `vcc->dev->hard_header` is NULL.
### Conclusion
This is a kernel bug in the ATM subsystem. It requires a code fix in `net/atm/common.c` to properly initialize or validate pointers before use. If you are a developer, please provide the exact kernel version and the code around line 645 for a more specific analysis. If you are a user, consider updating your kernel or disabling ATM support if not needed.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.