CVE-2026-43244
Analyzed Analyzed - Analysis Complete
Memory Corruption in Linux Kernel KCM

Publication date: 2026-05-06

Last updated on: 2026-05-11

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: kcm: fix zero-frag skb in frag_list on partial sendmsg error Syzkaller reported a warning in kcm_write_msgs() when processing a message with a zero-fragment skb in the frag_list. When kcm_sendmsg() fills MAX_SKB_FRAGS fragments in the current skb, it allocates a new skb (tskb) and links it into the frag_list before copying data. If the copy subsequently fails (e.g. -EFAULT from user memory), tskb remains in the frag_list with zero fragments: head skb (msg being assembled, NOT yet in sk_write_queue) +-----------+ | frags[17] | (MAX_SKB_FRAGS, all filled with data) | frag_list-+--> tskb +-----------+ +----------+ | frags[0] | (empty! copy failed before filling) +----------+ For SOCK_SEQPACKET with partial data already copied, the error path saves this message via partial_message for later completion. For SOCK_SEQPACKET, sock_write_iter() automatically sets MSG_EOR, so a subsequent zero-length write(fd, NULL, 0) completes the message and queues it to sk_write_queue. kcm_write_msgs() then walks the frag_list and hits: WARN_ON(!skb_shinfo(skb)->nr_frags) TCP has a similar pattern where skbs are enqueued before data copy and cleaned up on failure via tcp_remove_empty_skb(). KCM was missing the equivalent cleanup. Fix this by tracking the predecessor skb (frag_prev) when allocating a new frag_list entry. On error, if the tail skb has zero frags, use frag_prev to unlink and free it in O(1) without walking the singly-linked frag_list. frag_prev is safe to dereference because the entire message chain is only held locally (or in kcm->seq_skb) and is not added to sk_write_queue until MSG_EOR, so the send path cannot free it underneath us. Also change the WARN_ON to WARN_ON_ONCE to avoid flooding the log if the condition is somehow hit repeatedly. There are currently no KCM selftests in the kernel tree; a simple reproducer is available at [1]. [1] https://gist.github.com/mrpre/a94d431c757e8d6f168f4dd1a3749daa
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-06
Last Modified
2026-05-11
Generated
2026-06-16
AI Q&A
2026-05-06
EPSS Evaluated
2026-06-15
NVD
CVE-2026-43244
EUVD
EUVD-2026-27807
Affected Vendors & Products
Showing 4 associated CPEs
Vendor Product Version / Range
linux linux_kernel 7.0
linux linux_kernel From 6.13 (inc) to 6.18.16 (exc)
linux linux_kernel From 6.19 (inc) to 6.19.6 (exc)
linux linux_kernel From 4.6 (inc) to 6.12.75 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-401 The product does not sufficiently track and release allocated memory after it has been used, making the memory unavailable for reallocation and reuse.
Attack-Flow Graph
AI Quick Actions
Instant insights powered by AI
Executive Summary

This vulnerability is in the Linux kernel's KCM (Kernel Connection Multiplexor) subsystem. It occurs when sending messages using kcm_sendmsg(). When the maximum number of fragments (MAX_SKB_FRAGS) is reached in the current socket buffer (skb), a new skb (tskb) is allocated and linked into a fragment list before copying data. If the data copy fails (for example, due to a user memory fault), the new skb remains in the fragment list but contains zero fragments.

For SOCK_SEQPACKET sockets, partial data may have already been copied, and the error path saves this partial message for later completion. However, because the zero-fragment skb remains linked, when the code later walks the fragment list, it triggers a warning (WARN_ON) due to the unexpected zero fragments.

The root cause is that KCM was missing cleanup code to unlink and free these zero-fragment skbs on error, unlike TCP which has similar cleanup. The fix involves tracking the predecessor skb and unlinking the zero-fragment skb efficiently on error to prevent this condition.

Impact Analysis

This vulnerability can cause warnings and potential instability in the kernel's networking subsystem when processing messages with zero-fragment skbs in the fragment list. It may lead to log flooding due to repeated warnings, which can obscure other important log messages.

While the description does not explicitly mention security impacts like data corruption or privilege escalation, the presence of zero-fragment skbs could potentially cause unexpected behavior in message handling or resource leaks if not properly cleaned up.

Detection Guidance

This vulnerability involves a warning triggered in the Linux kernel's kcm_write_msgs() function when processing a message with a zero-fragment skb in the frag_list.

Detection can be done by monitoring kernel logs for the warning message triggered by WARN_ON(!skb_shinfo(skb)->nr_frags) or WARN_ON_ONCE in newer kernels.

Since the issue relates to kernel warnings, you can check the kernel ring buffer or system logs using commands such as:

  • dmesg | grep -i kcm
  • journalctl -k | grep -i kcm
  • journalctl -k | grep WARN_ON

Additionally, reproducing the issue requires sending partial messages via SOCK_SEQPACKET sockets that trigger the zero-fragment skb condition, but no specific detection commands are provided.

Mitigation Strategies

The vulnerability has been fixed in the Linux kernel by properly unlinking and freeing zero-fragment skb entries in the frag_list on error paths.

Immediate mitigation steps include:

  • Update your Linux kernel to a version that includes the fix for this vulnerability.
  • Monitor kernel logs for warnings related to kcm_write_msgs() to detect if the issue is occurring.
  • Avoid using or limit use of KCM (Kernel Connection Multiplexor) sockets if possible until the patch is applied.

No other immediate workarounds or configuration changes are described.

Chat Assistant
Ask questions about this CVE
Hi! I’m here to help you understand CVE-2026-43244. Ask me anything about the vulnerability, its impact, or mitigation strategies.
0/70
EPSS Chart