Answer in brief
CVE-2026-64581 records a Unknown severity 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). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. 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). 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 |
Published upstream
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 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.
Answer in brief
CVE-2026-64581 records a Unknown severity 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). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. 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). 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 |
Published upstream
Aug 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Aug 5, 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.