Answer in brief
CVE-2026-64581 records a High severity (CVSS 7.8) vulnerability in xfrm: fix sk_dst_cache double-free in xfrm_user_policy(). The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 7.8. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=2b06cdf3e688b98fcc9945873b5d42792bd4eee0 <96b678d08268b5f5c6fc99d4289d9b7e334fc683 || >=2b06cdf3e688b98fcc9945873b5d42792bd4eee0 <c283e9ada7fcb7dd4b10592623086b2e6d2f9925 || 72f157be2f81910ae759bfe2e5c2256fc4625645 || 9e9fe58a92a46c6d154d2901735bf230d91b8507 || adc1ec6cdc20d430aa01b86497220709b9149466 || b54033eb1cfd77aba471269ddd804ed8d3e35dea || c9e82cb34c3c2ee895af01bc899c6ed0bc6eb04a || 5eef9b51114fcc65651d671add52f267f91b9451 || >=3.16.52 <3.17 || >=4.4.163 <4.5 || >=3.18.101 <3.19 || >=4.1.52 <4.2 || >=4.4.123 <4.5 || >=4.9.89 <4.10 | 96b678d08268b5f5c6fc99d4289d9b7e334fc683, c283e9ada7fcb7dd4b10592623086b2e6d2f9925, 3.17, 4.5, 3.19, 4.2, 4.10 |
| Linux/Linuxgeneric | 4.14 | Not reported |
| Linux/Linuxgeneric | >=2b06cdf3e688b98fcc9945873b5d42792bd4eee0 <e8686fd8d18b99f3a9038683045b2f2338a7706d || >=2b06cdf3e688b98fcc9945873b5d42792bd4eee0 <a9340ebdc13f8bb5063c0bc0b037ee7e640d4ae9 || >=2b06cdf3e688b98fcc9945873b5d42792bd4eee0 <f833821e4b52ab6335d443ede5fb79c38e61d19a || >=2b06cdf3e688b98fcc9945873b5d42792bd4eee0 <f0ab9a71167bae308e05ab13b65e2007504a603f || >=2b06cdf3e688b98fcc9945873b5d42792bd4eee0 <8dd8929b71c4f06c614f8f54c2cc070453faae16 || >=2b06cdf3e688b98fcc9945873b5d42792bd4eee0 <0ea8f06454012d9e7f9c6e6253df710949bf6294 || >=2b06cdf3e688b98fcc9945873b5d42792bd4eee0 <96b678d08268b5f5c6fc99d4289d9b7e334fc683 || >=2b06cdf3e688b98fcc9945873b5d42792bd4eee0 <c283e9ada7fcb7dd4b10592623086b2e6d2f9925 || 72f157be2f81910ae759bfe2e5c2256fc4625645 || 9e9fe58a92a46c6d154d2901735bf230d91b8507 || adc1ec6cdc20d430aa01b86497220709b9149466 || b54033eb1cfd77aba471269ddd804ed8d3e35dea || c9e82cb34c3c2ee895af01bc899c6ed0bc6eb04a || 5eef9b51114fcc65651d671add52f267f91b9451 || >=3.16.52 <3.17 || >=4.4.163 <4.5 || >=3.18.101 <3.19 || >=4.1.52 <4.2 || >=4.4.123 <4.5 || >=4.9.89 <4.10 | e8686fd8d18b99f3a9038683045b2f2338a7706d, a9340ebdc13f8bb5063c0bc0b037ee7e640d4ae9, f833821e4b52ab6335d443ede5fb79c38e61d19a, f0ab9a71167bae308e05ab13b65e2007504a603f, 8dd8929b71c4f06c614f8f54c2cc070453faae16, 0ea8f06454012d9e7f9c6e6253df710949bf6294, 96b678d08268b5f5c6fc99d4289d9b7e334fc683, c283e9ada7fcb7dd4b10592623086b2e6d2f9925, 3.17, 4.5, 3.19, 4.2, 4.10 |
Published upstream
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 27, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Aug 5, 2026
In the Linux kernel, the following vulnerability has been resolved: xfrm: fix sk_dst_cache double-free in xfrm_user_policy() xfrm_user_policy() clears the socket dst cache with __sk_dst_reset(), i.e. the non-atomic __sk_dst_set(sk, NULL): it reads sk_dst_cache with rcu_dereference_protected(), stores NULL and dst_release()s the old dst. That is only safe if no other thread modifies sk_dst_cache concurrently. For a connected UDP socket that does not hold: the transmit fast path (udp_sendmsg -> sk_dst_check -> sk_dst_reset) resets the cache locklessly with an atomic xchg(). A per-socket policy change racing a send can make both sides observe the same old dst and each dst_release() it, dropping the socket's single reference twice and freeing the xfrm_dst bundle while it is still referenced: BUG: KASAN: slab-use-after-free in dst_release Write of size 4 at addr ffff88801897b6c0 by task exploit/155 Call Trace: ... dst_release (... ./include/linux/rcuref.h:109) xfrm_user_policy (./include/net/sock.h:2239 ./include/net/sock.h:2256 net/xfrm/xfrm_state.c:3053) do_ip_setsockopt (net/ipv4/ip_sockglue.c:1347) ip_setsockopt (net/ipv4/ip_sockglue.c:1417) do_sock_setsockopt (net/socket.c:2368) __sys_setsockopt (net/socket.c:2393) __x64_sys_setsockopt (net/socket.c:2396) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121) Reachable by an unprivileged user via a user+network namespace. Use the atomic sk_dst_reset() so the cache is cleared and released with a single xchg(): whichever side wins releases the dst once, the other sees NULL and does nothing. Behaviour is otherwise unchanged.
Quoted source text, attributed separately from HOL analysis.