CVE-2026-43244

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kcm: fix zero-frag skb in frag_list on partial sendmsg error<br /> <br /> Syzkaller reported a warning in kcm_write_msgs() when processing a<br /> message with a zero-fragment skb in the frag_list.<br /> <br /> When kcm_sendmsg() fills MAX_SKB_FRAGS fragments in the current skb,<br /> it allocates a new skb (tskb) and links it into the frag_list before<br /> copying data. If the copy subsequently fails (e.g. -EFAULT from<br /> user memory), tskb remains in the frag_list with zero fragments:<br /> <br /> head skb (msg being assembled, NOT yet in sk_write_queue)<br /> +-----------+<br /> | frags[17] | (MAX_SKB_FRAGS, all filled with data)<br /> | frag_list-+--&gt; tskb<br /> +-----------+ +----------+<br /> | frags[0] | (empty! copy failed before filling)<br /> +----------+<br /> <br /> For SOCK_SEQPACKET with partial data already copied, the error path<br /> saves this message via partial_message for later completion. For<br /> SOCK_SEQPACKET, sock_write_iter() automatically sets MSG_EOR, so a<br /> subsequent zero-length write(fd, NULL, 0) completes the message and<br /> queues it to sk_write_queue. kcm_write_msgs() then walks the<br /> frag_list and hits:<br /> <br /> WARN_ON(!skb_shinfo(skb)-&gt;nr_frags)<br /> <br /> TCP has a similar pattern where skbs are enqueued before data copy<br /> and cleaned up on failure via tcp_remove_empty_skb(). KCM was<br /> missing the equivalent cleanup.<br /> <br /> Fix this by tracking the predecessor skb (frag_prev) when allocating<br /> a new frag_list entry. On error, if the tail skb has zero frags,<br /> use frag_prev to unlink and free it in O(1) without walking the<br /> singly-linked frag_list. frag_prev is safe to dereference because<br /> the entire message chain is only held locally (or in kcm-&gt;seq_skb)<br /> and is not added to sk_write_queue until MSG_EOR, so the send path<br /> cannot free it underneath us.<br /> <br /> Also change the WARN_ON to WARN_ON_ONCE to avoid flooding the log<br /> if the condition is somehow hit repeatedly.<br /> <br /> There are currently no KCM selftests in the kernel tree; a simple<br /> reproducer is available at [1].<br /> <br /> [1] https://gist.github.com/mrpre/a94d431c757e8d6f168f4dd1a3749daa