https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 02 Oct 2026 04:54:06 +0000 https://vulnerability.circl.lu/vuln/cve-2026-43244 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>kcm: fix zero-frag skb in frag_list on partial sendmsg error</p> <p>Syzkaller reported a warning in kcm_write_msgs() when processing a message with a zero-fragment skb in the frag_list.</p> <p>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:</p> <p>head skb (msg being assembled, NOT yet in sk_write_queue) +-----------+ | frags[17] | (MAX_SKB_FRAGS, all filled with data) | frag_list-+--&gt; tskb +-----------+ +----------+ | frags[0] | (empty! copy failed before filling) +----------+</p> <p>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:</p> <p>WARN_ON(!skb_shinfo(skb)-&gt;nr_frags)</p> <p>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.</p> <p>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 fra…</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>kcm: fix zero-frag skb in frag_list on partial sendmsg error</p> <p>Syzkaller reported a warning in kcm_write_msgs() when processing a message with a zero-fragment skb in the frag_list.</p> <p>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:</p> <p>head skb (msg being assembled, NOT yet in sk_write_queue) +-----------+ | frags[17] | (MAX_SKB_FRAGS, all filled with data) | frag_list-+--&gt; tskb +-----------+ +----------+ | frags[0] | (empty! copy failed before filling) +----------+</p> <p>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:</p> <p>WARN_ON(!skb_shinfo(skb)-&gt;nr_frags)</p> <p>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.</p> <p>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 fra…</p> https://vulnerability.circl.lu/vuln/cve-2026-43244