CVE-2026-43244 kcm: fix zero-frag skb in frag_list on partial sendmsg error

What is CVE-2026-43244?

CVE-2026-43244 is a medium-severity vulnerability in Linux kernel, published on 6 May 2026. It can only be exploited from the same machine or local network, with no action from the victim.

Official 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

Weakness: CWE-401

Which versions are affected by CVE-2026-43244?

It affects 1 product.

Products include Linux kernel.

How do I fix CVE-2026-43244?

Apply the vendor's patch.

Is CVE-2026-43244 being exploited?

There is no known exploitation of CVE-2026-43244 in the wild and no public exploit code.

Other vulnerabilities in Linux kernel

• CVE-2026-53266 Linux Kernel Out-of-Bounds Write Exploited High 8.8
• CVE-2013-6282 Linux Kernel Improper Input Validation Exploited High 8.8
• CVE-2022-0185 Linux Kernel Heap-Based Buffer Overflow Exploited High 8.4
• CVE-2013-2094 Linux Kernel Privilege Escalation Exploited High 8.4
• CVE-2026-53362 Linux Kernel Unspecified Exploited High 7.8

All Linux kernel vulnerabilities

Sources

• CVE record
• NVD
• OSV
• GitHub advisory
• How this page is made

Also known as AZL-85857, BELL-CVE-2026-43244, DEBIAN-CVE-2026-43244, GHSA-f26p-p2hg-c5qg, ROOT-OS-DEBIAN-11-CVE-2026-43244, ROOT-OS-DEBIAN-12-CVE-2026-43244 and 3 more.