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
Published: 2026-05-06
Score: n/a
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

A flaw in the Linux Kernel Connection Manager (KCM) left a zero‑fragment socket buffer chained into the fragment list when a sendmsg operation failed to copy user data. The error path allocates a new skb but does not free it on failure, causing a memory leak, repeated WARN_ON_ONCE messages, and potentially kernel instability. The issue is reflected in CWE‑390. Based on the description, it is inferred that the presence of a zero‑fragment skb in the fragment list can lead to memory consumption growth and kernel instability during repeated failures, ultimately resulting in a denial‑of‑service condition.

Affected Systems

Any Linux kernel containing the unpatched KCM implementation is affected. The advisory does not specify particular releases, so all distributions whose kernel code matches the default KCM path before the fix are potentially vulnerable.

Risk and Exploitability

The CVSS and EPSS metrics are not provided and the vulnerability is not listed in the CISA KEV catalog. Exploitation requires the ability to create a SOCK_SEQPACKET KCM socket and send a malformed message that triggers a copy error; this typically demands local or privileged access. The probability of exploitation in the wild appears low to moderate; successful use would lead to memory consumption growth and a denial‑of‑service condition. The likely attack vector is a local process that can open a KCM socket and invoke sendmsg with data that causes a copy failure. Based on the description, it is inferred that the attacker must trigger the copying error to create the zero‑fragment skb and that the vulnerability is not remotely exploitable without userland access to the KCM interface.

Generated by OpenCVE AI on May 7, 2026 at 05:44 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply the kernel patch that implements predecessor skb tracking and zero‑fragment cleanup.
  • If an immediate kernel update is unavailable, disable KCM socket functionality by removing or blacklisting the kcm module or disabling the KCM socket option in the kernel configuration.
  • Monitor kernel logs for WARN_ON_ONCE messages about zero‑fragment skbs and plan an upgrade or patch when such messages appear.

Generated by OpenCVE AI on May 7, 2026 at 05:44 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Thu, 07 May 2026 04:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-401
CWE-404

Thu, 07 May 2026 00:15:00 +0000


Wed, 06 May 2026 18:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-401
CWE-404

Wed, 06 May 2026 12:15:00 +0000

Type Values Removed Values Added
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
Title kcm: fix zero-frag skb in frag_list on partial sendmsg error
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-05-06T11:28:36.946Z

Reserved: 2026-05-01T14:12:55.995Z

Link: CVE-2026-43244

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Awaiting Analysis

Published: 2026-05-06T12:16:44.873

Modified: 2026-05-06T13:07:51.607

Link: CVE-2026-43244

cve-icon Redhat

Severity :

Publid Date: 2026-05-06T00:00:00Z

Links: CVE-2026-43244 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-05-07T05:45:06Z

Weaknesses