CVE-2025-38717

Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source

AV:LAttack vector, local

The race is driven entirely by local syscalls — creating an AF_KCM socket, `SIOCKCMATTACH`/`SIOCKCMUNATTACH` ioctls, and `close()` — with no remote packet needed to reach the vulnerable window. No network-facing service parses attacker data on this path.

AC:LAttack complexity, low

The attacker controls both sides of the race, running `kcm_release()` in one thread while a second thread issues `SIOCKCMUNATTACH` on the reserved psock, and can retry the loop indefinitely until the window between `cancel_work_sync()` and `unreserve_psock()` is hit. syzbot hit it repeatedly with three separate reproducers, and `CONFIG_AF_KCM` is shipped as a module by major distributions.

PR:LPrivileges required, low

There is not a single `capable()` or `CAP_NET_ADMIN` check in `net/kcm/`, and the protocol family autoloads on an unprivileged `socket(AF_KCM, ...)` call via `MODULE_ALIAS_NETPROTO(PF_KCM)`. Any local unprivileged user can attach a TCP socket and trigger the race.

UI:NUser interaction, none

The attacker performs every step — socket creation, attach, unattach, and close — from its own threads. No victim action or cooperation is required.

S:UScope, unchanged

The use-after-free corrupts kernel heap memory within the same kernel security authority; there is no VM, IOMMU, or sandbox boundary crossed.

C:HConfidentiality impact, high

The freed `struct kcm_sock` is reachable from a workqueue and is reallocatable by the attacker (its own slab cache, refillable simply by creating more KCM sockets), so the UAF yields a read primitive over adjacent/reused kernel objects and can leak arbitrary kernel memory.

I:HIntegrity impact, high

Queueing work on a freed object makes the workqueue write into freed memory, and `kcm_tx_work()` subsequently operates on attacker-groomed contents, culminating in the indirect call `sk->sk_write_space(sk)` in `kcm_write_msgs()` — a control-flow hijack / arbitrary-write path, not just corruption.

A:HAvailability impact, high

Even unexploited, running `lock_sock()` and `kcm_write_msgs()` on a freed `kcm_sock` produces a KASAN-reported use-after-free, workqueue list corruption, and kernel oops/panic, which any unprivileged user can trigger repeatedly.