CVE-2026-23321 in Linux
Riassunto
di VulDB • 01/07/2026
Based on the stack trace and the description of actions, this appears to be a **kernel NULL pointer dereference or use-after-free bug** in the Linux kernel's MPTCP (Multipath TCP implementation), specifically within the `genetlink` subsystem when handling netlink messages relatedMPTCP endpoint removal.
### Analysis of the Bug
1. **Stack Trace Context**: * The crash occurs during a `sys_sendmsg` system call, which is used to send data over sockets. In this context, it's likely sending an MCTP (Multipath Control Protocol) or netlink message related to MPTCP configuration. * The top of the stack shows `net/netlink/genetlink.c:1219`, indicating a problem in generic netlink processing. * The specific function chain is `genlmsg_put` -> `nlmsg_multicast`/`nlmsg_unicast` path, leading to `netlink_unicast_kernel`.
2. **Triggering Actions**: * **Set MPTCP subflows limit to 0**: This disables the creation of new subflows for existing connections or potentially affects how endpoints are managed. * **Create an MPTCP endpoint with 'signal' and 'subflow' flags**: The `signal` flag means the kernel will send ADD_ADDR messages when this address becomes available/used. The `subflow` flag typically indicates that a subflow should be initiated for new connections using this address. * **Create a new MPTCP connection from a different address**: This triggers the 'signal' behavior, causing an ADD_ADDR message to be sent for the previously created endpoint (even though no actual data flow might use it yet). However, because `subflow` is set but the limit is 0, or due to race conditions/state inconsistencies, something goes wrong. * **Remove the MPTCP endpoint**: This is likely where the crash occurs. The kernel tries to clean up resources associated with this endpoint (like pending ADD_ADDR messages, socket references, etc.), but some pointer becomes invalid because: * A reference was dropped prematurely. * An asynchronous event (like the completion of an ADD_ADDR send) accesses freed memory. * The state machine is inconsistent due to the `subflow_limit=0` interaction with the 'signal' flag.
3. **Likely Root Cause**: The bug likely resides in how MPTCP handles endpoint cleanup (`mptcp_pm_nl_endpoint_put()` or similar) when there are pending operations (like sending an ADD_ADDR triggered by the `signal` flag) and conflicting constraints (`subflow_limit=0`).
Specifically, it might be: * **Use-After-Free**: The endpoint structure is freed while a netlink message generation callback still holds a reference or expects valid data. * **NULL Pointer Dereference**: A pointer to the subflow socket or related control block becomes NULL because no subflows were allowed/created, but code assumes it exists when cleaning up an 'signal' event.
### How to Reproduce (Conceptual)
```bash # Requires root and MPTCP support enabled in kernel ip mptcp endpoint add 192.0.2.1 signal subflow # Create endpoint with both flags sysctl -w net.mptcp.subflows=0 # Set limit to 0 (may require specific sysctl or patch)
# Trigger the 'signal' by creating a connection that might use this address contextually, # though in practice, you often need an actual MPTCP socket creation attempt. mptcp_connect -4 192.0.2.1 # Attempt to connect using IPv4 (might trigger signal)
ip mptcp endpoint del 192.0.2.1 # Remove the endpoint -> CRASH ```
### Potential Fix Areas in Kernel Source (`net/mptcp/`)
Look for functions involved in: * `mptcp_pm_nl_endpoint_put()` or similar cleanup routines. * Handling of `MPTCP_PM_CMD_DEL_ENDPOINT`. * Interaction between the endpoint's 'signal' flag and pending ADD_ADDR messages. * Reference counting (`refcount`) on MPTCP endpoints, especially when subflows are disabled/limited to 0.
A common fix pattern for such bugs is: 1. Ensure all asynchronous operations (like sending netlink messages) complete or are cancelled before freeing the endpoint structure. 2. Add proper NULL checks if pointers can legitimately be NULL due to configuration limits (`subflow_limit=0`). 3. Use `refcount_dec_and_test()` correctly and ensure no dangling references exist during cleanup.
### Recommendation for Developers/Reporters
1. **Provide Full
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.