CVE-2026-43244

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 kcmwritemsgs() when processing a message with a zero-fragment skb in the frag_list.

When kcmsendmsg() fills MAXSKBFRAGS fragments in the current skb, it allocates a new skb (tskb) and links it into the fraglist 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 skwritequeue) +-----------+ | frags[17] | (MAXSKBFRAGS, all filled with data) | frag_list-+--> tskb +-----------+ +----------+ | frags[0] | (empty! copy failed before filling) +----------+

For SOCKSEQPACKET with partial data already copied, the error path saves this message via partialmessage for later completion. For SOCKSEQPACKET, sockwriteiter() automatically sets MSGEOR, so a subsequent zero-length write(fd, NULL, 0) completes the message and queues it to skwritequeue. kcmwritemsgs() then walks the frag_list and hits:

WARNON(!skbshinfo(skb)->nr_frags)

TCP has a similar pattern where skbs are enqueued before data copy and cleaned up on failure via tcpremoveempty_skb(). KCM was missing the equivalent cleanup.

Fix this by tracking the predecessor skb (fragprev) when allocating a new fraglist entry. On error, if the tail skb has zero frags, use fragprev to unlink and free it in O(1) without walking the singly-linked fraglist. fragprev is safe to dereference because the entire message chain is only held locally (or in kcm->seqskb) and is not added to skwritequeue until MSG_EOR, so the send path cannot free it underneath us.

Also change the WARNON to WARNON_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