CVE-2023-53585
published 2025-10-04CVE-2023-53585: In the Linux kernel, the following vulnerability has been resolved: bpf: reject unhashed sockets in bpf_sk_assign The semantics for bpf_sk_assign are as…
PriorityP421medium5.5CVSS 3.1
AVLACLPRLUINSUCNINAH
EPSS
0.15%
4.4th percentile
In the Linux kernel, the following vulnerability has been resolved:
bpf: reject unhashed sockets in bpf_sk_assign
The semantics for bpf_sk_assign are as follows:
sk = some_lookup_func()
bpf_sk_assign(skb, sk)
bpf_sk_release(sk)
That is, the sk is not consumed by bpf_sk_assign. The function
therefore needs to make sure that sk lives long enough to be
consumed from __inet_lookup_skb. The path through the stack for a
TCPv4 packet is roughly:
netif_receive_skb_core: takes RCU read lock
__netif_receive_skb_core:
sch_handle_ingress:
tcf_classify:
bpf_sk_assign()
deliver_ptype_list_skb:
deliver_skb:
ip_packet_type->func == ip_rcv:
ip_rcv_core:
ip_rcv_finish_core:
dst_input:
ip_local_deliver:
ip_local_deliver_finish:
ip_protocol_deliver_rcu:
tcp_v4_rcv:
__inet_lookup_skb:
skb_steal_sock
The existing helper takes advantage of the fact that everything
happens in the same RCU critical section: for sockets with
SOCK_RCU_FREE set bpf_sk_assign never takes a reference.
skb_steal_sock then checks SOCK_RCU_FREE again and does sock_put
if necessary.
This approach assumes that SOCK_RCU_FREE is never set on a sk
between bpf_sk_assign and skb_steal_sock, but this invariant is
violated by unhashed UDP sockets. A new UDP socket is created
in TCP_CLOSE state but without SOCK_RCU_FREE set. That flag is only
added in udp_lib_get_port() which happens when a socket is bound.
When bpf_sk_assign was added it wasn't possible to access unhashed
UDP sockets from BPF, so this wasn't a problem. This changed
in commit 0c48eefae712 ("sock_map: Lift socket state restriction
for datagram sockets"), but the helper wasn't adjusted accordingly.
The following sequence of events will therefore lead to a refcount
leak:
1. Add socket(AF_INET, SOCK_DGRAM) to a sockmap.
2. Pull socket out of sockmap and bpf_sk_assign it. Since
SOCK_RCU_FREE is not set we increment the refcount.
3. bind() or connect() the socket, setting SOCK_RCU_FREE.
4. skb_steal_sock will now set refcounted = false due to
SOCK_RCU_FRE
Affected
17 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| debian | linux | < linux 6.1.55-1 (bookworm) | linux 6.1.55-1 (bookworm) |
| linux | linux | — | — |
| linux | linux | >= cf7fbe660f2dbd738ab58aea8e9b0ca6ad232449 < 791a12102e5191dcb6ce0b3a99d71b5a2802d12a | 791a12102e5191dcb6ce0b3a99d71b5a2802d12a |
| linux | linux | >= cf7fbe660f2dbd738ab58aea8e9b0ca6ad232449 < 7dcbc0bb0e5cc1823923744befce59ac353135e6 | 7dcbc0bb0e5cc1823923744befce59ac353135e6 |
| linux | linux | >= cf7fbe660f2dbd738ab58aea8e9b0ca6ad232449 < c0ce0fb76610d5fad31f56f2ca8241a2a6717a1b | c0ce0fb76610d5fad31f56f2ca8241a2a6717a1b |
| linux | linux | >= cf7fbe660f2dbd738ab58aea8e9b0ca6ad232449 < 8aa43cfbb68b25119d2ced14ec717173e2901fa2 | 8aa43cfbb68b25119d2ced14ec717173e2901fa2 |
| linux | linux | >= cf7fbe660f2dbd738ab58aea8e9b0ca6ad232449 < 3d4522f59fb748a54446846522941a4f09da63e9 | 3d4522f59fb748a54446846522941a4f09da63e9 |
| linux | linux | >= cf7fbe660f2dbd738ab58aea8e9b0ca6ad232449 < 67312adc96b5a585970d03b62412847afe2c6b01 | 67312adc96b5a585970d03b62412847afe2c6b01 |
| linux | linux_kernel | >= 0 < 5.10.197-1 | 5.10.197-1 |
| linux | linux_kernel | >= 0 < 6.1.55-1 | 6.1.55-1 |
| linux | linux_kernel | >= 0 < 6.5.3-1 | 6.5.3-1 |
| linux | linux_kernel | >= 0 < 6.5.3-1 | 6.5.3-1 |
| linux | linux_kernel | >= 5.11 < 5.15.132 | 5.15.132 |
| linux | linux_kernel | >= 5.16 < 6.1.53 | 6.1.53 |
| linux | linux_kernel | >= 5.7 < 5.10.195 | 5.10.195 |
| linux | linux_kernel | >= 6.2 < 6.4.16 | 6.4.16 |
| linux | linux_kernel | >= 6.5 < 6.5.3 | 6.5.3 |
CVSS provenance
nvdv3.15.5MEDIUMCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
osv5.5MEDIUM
vendor_debian5.5MEDIUM
vendor_redhat5.5MEDIUM
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
OSV
CVE-2023-53585: In the Linux kernel, the following vulnerability has been resolved: bpf: reject unhashed sockets in bpf_sk_assign The semantics for bpf_sk_assign are
osv·2025-10-04·CVSS 5.5
CVE-2023-53585 [MEDIUM] CVE-2023-53585: In the Linux kernel, the following vulnerability has been resolved: bpf: reject unhashed sockets in bpf_sk_assign The semantics for bpf_sk_assign are
In the Linux kernel, the following vulnerability has been resolved: bpf: reject unhashed sockets in bpf_sk_assign The semantics for bpf_sk_assign are as follows: sk = some_lookup_func() bpf_sk_assign(skb, sk) bpf_sk_release(sk) That is, the sk is not consumed by bpf_sk_assign. The function therefore needs to make sure that sk lives long enough to be consumed from __inet_lookup_skb. The path through the stack for a TCPv4 packet is roughly: netif_receive_skb_core: takes RCU read lock __netif_receive_skb_core: sch_handle_ingress: tcf_classify: bpf_sk_assign() deliver_ptype_list_skb: deliver_skb: ip_packet_type->func == ip_rcv: ip_rcv_core: ip_rcv_finish_core: dst_input: ip_local_deliver: ip_local_deliver_finish: ip_protocol_deliver_rcu: tcp_v4_rcv: __inet_lookup_skb: skb_steal_sock The existi
GHSA
GHSA-39wr-crm4-gxmv: In the Linux kernel, the following vulnerability has been resolved:
bpf: reject unhashed sockets in bpf_sk_assign
The semantics for bpf_sk_assign ar
ghsa_unreviewed·2025-10-04
CVE-2023-53585 [MEDIUM] GHSA-39wr-crm4-gxmv: In the Linux kernel, the following vulnerability has been resolved:
bpf: reject unhashed sockets in bpf_sk_assign
The semantics for bpf_sk_assign ar
In the Linux kernel, the following vulnerability has been resolved:
bpf: reject unhashed sockets in bpf_sk_assign
The semantics for bpf_sk_assign are as follows:
sk = some_lookup_func()
bpf_sk_assign(skb, sk)
bpf_sk_release(sk)
That is, the sk is not consumed by bpf_sk_assign. The function
therefore needs to make sure that sk lives long enough to be
consumed from __inet_lookup_skb. The path through the stack for a
TCPv4 packet is roughly:
netif_receive_skb_core: takes RCU read lock
__netif_receive_skb_core:
sch_handle_ingress:
tcf_classify:
bpf_sk_assign()
deliver_ptype_list_skb:
deliver_skb:
ip_packet_type->func == ip_rcv:
ip_rcv_core:
ip_rcv_finish_core:
dst_input:
ip_local_deliver:
ip_local_deliver_finish:
ip_protocol_deliver_rcu:
tcp_v4_rcv:
__inet_lookup_skb:
skb_steal_sock
The
Red Hat
kernel: bpf: reject unhashed sockets in bpf_sk_assign
vendor_redhat·2025-10-04·CVSS 5.5
CVE-2023-53585 [MEDIUM] CWE-911 kernel: bpf: reject unhashed sockets in bpf_sk_assign
kernel: bpf: reject unhashed sockets in bpf_sk_assign
In the Linux kernel, the following vulnerability has been resolved:
bpf: reject unhashed sockets in bpf_sk_assign
The semantics for bpf_sk_assign are as follows:
sk = some_lookup_func()
bpf_sk_assign(skb, sk)
bpf_sk_release(sk)
That is, the sk is not consumed by bpf_sk_assign. The function
therefore needs to make sure that sk lives long enough to be
consumed from __inet_lookup_skb. The path through the stack for a
TCPv4 packet is roughly:
netif_receive_skb_core: takes RCU read lock
__netif_receive_skb_core:
sch_handle_ingress:
tcf_classify:
bpf_sk_assign()
deliver_ptype_list_skb:
deliver_skb:
ip_packet_type->func == ip_rcv:
ip_rcv_core:
ip_rcv_finish_core:
dst_input:
ip_local_deliver:
ip_local_deliver_finish:
ip_protocol_deliver_rcu:
t
Debian
CVE-2023-53585: linux - In the Linux kernel, the following vulnerability has been resolved: bpf: reject...
vendor_debian·2023·CVSS 5.5
CVE-2023-53585 [MEDIUM] CVE-2023-53585: linux - In the Linux kernel, the following vulnerability has been resolved: bpf: reject...
In the Linux kernel, the following vulnerability has been resolved: bpf: reject unhashed sockets in bpf_sk_assign The semantics for bpf_sk_assign are as follows: sk = some_lookup_func() bpf_sk_assign(skb, sk) bpf_sk_release(sk) That is, the sk is not consumed by bpf_sk_assign. The function therefore needs to make sure that sk lives long enough to be consumed from __inet_lookup_skb. The path through the stack for a TCPv4 packet is roughly: netif_receive_skb_core: takes RCU read lock __netif_receive_skb_core: sch_handle_ingress: tcf_classify: bpf_sk_assign() deliver_ptype_list_skb: deliver_skb: ip_packet_type->func == ip_rcv: ip_rcv_core: ip_rcv_finish_core: dst_input: ip_local_deliver: ip_local_deliver_finish: ip_protocol_deliver_rcu: tcp_v4_rcv: __inet_lookup_skb: skb_steal_sock The existi
No detection rules found.
No public exploits indexed.
https://git.kernel.org/stable/c/3d4522f59fb748a54446846522941a4f09da63e9https://git.kernel.org/stable/c/67312adc96b5a585970d03b62412847afe2c6b01https://git.kernel.org/stable/c/791a12102e5191dcb6ce0b3a99d71b5a2802d12ahttps://git.kernel.org/stable/c/7dcbc0bb0e5cc1823923744befce59ac353135e6https://git.kernel.org/stable/c/8aa43cfbb68b25119d2ced14ec717173e2901fa2https://git.kernel.org/stable/c/c0ce0fb76610d5fad31f56f2ca8241a2a6717a1b
2025-10-04
Published