CVE-2026-43244

What it actually does

This is a local Linux kernel availability flaw in the KCM socket implementation. During kcm_sendmsg(), a partially failed send can leave an empty skb in a frag_list after data copying fails, such as from an invalid user-memory pointer. A later zero-length write can complete and queue the malformed message, causing kcm_write_msgs() to encounter an unexpected zero-fragment skb and trigger a kernel warning. On systems configured to panic on kernel warnings, this can crash the host; otherwise it may cause kernel log noise and potential service instability. The issue requires local code execution or an account able to exercise KCM sockets and does not provide confidentiality or integrity impact by itself.

Why it matters to the business

An attacker with local access to an affected Linux system may be able to disrupt workloads by forcing kernel warnings or a host crash, especially where panic-on-warn is enabled. The risk is highest for shared Linux servers, container hosts, CI/build systems, and multi-user environments where untrusted users or workloads can run code. Public exploitation maturity is currently listed as none, EPSS is very low, and it is not in CISA KEV, so this should be prioritized as a hardening and availability fix rather than treated as an actively exploited internet-facing emergency.

How an attack unfolds

An attacker first obtains the ability to run local code on a Linux host with the vulnerable KCM kernel code available. They create and use KCM/SOCK_SEQPACKET sockets and send a message that fills the maximum number of skb fragments. The attacker then causes the next data copy into a newly allocated frag_list skb to fail, for example by passing an invalid user-space buffer so the kernel returns an error such as EFAULT. Because partial data was already copied, the vulnerable error path preserves the incomplete message and leaves the newly allocated empty skb linked in the frag_list. The attacker then performs a zero-length write that completes the message and places it on the socket write queue. When the kernel later processes that queued message, kcm_write_msgs() walks the frag_list, detects a zero-fragment skb, and triggers the warning condition. If the system is configured with panic_on_warn or equivalent crash-on-warning behavior, this can become a reliable local denial of service.

How to fix it

Upgrade to a vendor-supported Linux kernel build that includes the KCM fix for zero-fragment skb cleanup in the sendmsg error path. Because no product-specific fixed versions were provided, use the relevant distribution or appliance advisory and confirm the running kernel contains the upstream KCM change that unlinks and frees an empty tail skb on send failure. Reboot into the patched kernel after installation; simply installing the package is not sufficient if the old kernel remains running. If immediate patching is not possible and KCM is not required, disable or remove KCM support where feasible, blacklist the kcm kernel module if it is modular, and prevent untrusted workloads from creating AF_KCM sockets using seccomp, container runtime policy, or workload sandboxing. On systems where availability is critical, review kernel.panic_on_warn because enabling panic-on-warn can turn this warning into a full host crash; changing that setting is a mitigation only and does not correct the underlying bug.

How to confirm the fix worked

Confirm exposure by checking whether the running kernel version is older than the vendor-fixed build and whether KCM support is present, for example via kernel configuration, loaded modules, or the ability to create AF_KCM sockets. Confirm remediation by verifying the system has rebooted into the patched kernel, not merely installed it. Review the vendor changelog or kernel source package for the KCM fix in net/kcm/kcmsock.c that tracks the previous frag_list skb and removes an empty tail skb on copy failure. If KCM is intentionally disabled as a mitigation, validate that the kcm module is not loaded, cannot be auto-loaded, and that untrusted processes are blocked from using AF_KCM sockets. Kernel logs should no longer show warnings from kcm_write_msgs() when exercising KCM sendmsg error paths.

Typical attack path

1. Gain local code execution or access to run a program on an affected Linux system.
2. Confirm that KCM socket support is available in the running kernel or loadable as a module.
3. Create KCM/SOCK_SEQPACKET socket state needed to send KCM messages.
4. Send enough data to fill the current skb up to MAX_SKB_FRAGS.
5. Trigger a copy failure during the next fragment allocation, leaving an empty skb in the frag_list on vulnerable kernels.
6. Issue a zero-length write or otherwise complete the partial SOCK_SEQPACKET message.
7. Cause kcm_write_msgs() to process the malformed frag_list and trigger a kernel warning or host crash if warnings are configured to panic.

How to detect it

Look for evidence in kernel logs, system journals, crash dumps, and audit telemetry. Primary sources include dmesg, /var/log/kern.log, /var/log/messages, journalctl -k, kdump/vmcore records, panic reports, and EDR/audit logs showing unusual AF_KCM socket activity. Suspicious signs include kernel warnings referencing kcm_write_msgs(), net/kcm/kcmsock.c, KCM sockets, skb fragment handling, or repeated local programs making KCM socket and sendmsg/write calls immediately before a kernel warning or reboot. If panic_on_warn is enabled, correlate unexpected reboots or kernel panics with preceding KCM warning stack traces. There are no network indicators because exploitation is local and does not require a remote packet signature.

• kcm_write_msgs
• net/kcm/kcmsock.c
• WARNING: CPU:
• WARN_ON
• WARN_ON_ONCE
• skb_shinfo(skb)->nr_frags
• zero-fragment skb
• frag_list
• kcm_sendmsg
• KCM
• AF_KCM
• PF_KCM
• panic_on_warn
• kernel panic - not syncing

What your security team should do

• Inventory Linux systems where untrusted local users, containers, CI jobs, or third-party workloads can execute code and prioritize those for kernel updates.
• Apply the appropriate vendor kernel update and reboot into the fixed kernel during the next maintenance window, sooner for shared or multi-tenant systems.
• If KCM is unused, disable or blacklist the kcm module and enforce seccomp/container policies that block AF_KCM socket creation for untrusted workloads.
• Search historical kernel logs for KCM-related warnings to identify possible prior triggering or testing of the bug.
• Review hosts with kernel.panic_on_warn enabled, because this setting increases the operational impact from warning to crash.
• Track distribution advisories for exact fixed kernel package versions because no per-package fixed versions were provided in the input.
• Treat current urgency as moderate: the issue is local, low EPSS, not KEV-listed, and has no known mature public exploit, but it can still affect availability on shared systems.