HOMEVULNERABILITIESCVE-2026-43244
MEDIUM

CVE-2026-43244

Published: May 6, 2026· Updated: May 11, 2026

5.5
CVSS v3.1
EPSS:0.02%probability of exploitation in 30 daysPercentile:4.7th

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

NVD Source

Technical Analysis

CVE-2026-43244 requires local access, meaning attackers must already have a foothold on the target system.

Exploitation requires low privileges, which limits the exposure to scenarios where an attacker has already gained initial access.

A successful exploit results in availability disruption (denial of service), with a CVSS base score of 5.5.

CVSS v3.1 Vector Breakdown

Exploitability
Attack VectorLocal
Attack ComplexityLow
Privileges Req.Low
User InteractionNone
ScopeUnchanged
Impact
ConfidentialityNone
IntegrityNone
AvailabilityHigh
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Affected Vendors & Products

Linux1 product
linux kernel
Source: NVD CPE · 2 total CPE entries

Exploit & PoC Resources

NO KNOWN EXPLOITNo public exploit confirmed at this time
External links open in a new tab. Always verify in a controlled environment before use.

Official Patches & Advisories

All References (4)

Quick Facts

CVE IDCVE-2026-43244
CVSS Score5.5 / 10
SeverityMEDIUM
CISA KEVNo
EPSS (30d)0.02%
Affected1 vendor
PublishedMay 6, 2026

Recommended Actions

  • Apply vendor patches immediately
  • Monitor CVE-2026-43244 in threat intel feeds
  • Review IDS/IPS signatures for exploitation attempts
Data sourced from NVD (NIST), CISA KEV, and EPSS (FIRST). Analysis generated by CTIWATCH.COM. CVE data is provided under the NVD usage policy.