linux-cve-announce - CVE-2023-52986: bpf, sockmap: Check for any of tcp_bpf

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <2025032707-CVE-2023-52986-91fe@gregkh>
Date: Thu, 27 Mar 2025 17:43:33 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: CVE-2023-52986: bpf, sockmap: Check for any of tcp_bpf_prots when cloning a listener

Description
===========

In the Linux kernel, the following vulnerability has been resolved:

bpf, sockmap: Check for any of tcp_bpf_prots when cloning a listener

A listening socket linked to a sockmap has its sk_prot overridden. It
points to one of the struct proto variants in tcp_bpf_prots. The variant
depends on the socket's family and which sockmap programs are attached.

A child socket cloned from a TCP listener initially inherits their sk_prot.
But before cloning is finished, we restore the child's proto to the
listener's original non-tcp_bpf_prots one. This happens in
tcp_create_openreq_child -> tcp_bpf_clone.

Today, in tcp_bpf_clone we detect if the child's proto should be restored
by checking only for the TCP_BPF_BASE proto variant. This is not
correct. The sk_prot of listening socket linked to a sockmap can point to
to any variant in tcp_bpf_prots.

If the listeners sk_prot happens to be not the TCP_BPF_BASE variant, then
the child socket unintentionally is left if the inherited sk_prot by
tcp_bpf_clone.

This leads to issues like infinite recursion on close [1], because the
child state is otherwise not set up for use with tcp_bpf_prot operations.

Adjust the check in tcp_bpf_clone to detect all of tcp_bpf_prots variants.

Note that it wouldn't be sufficient to check the socket state when
overriding the sk_prot in tcp_bpf_update_proto in order to always use the
TCP_BPF_BASE variant for listening sockets. Since commit
b8b8315e39ff ("bpf, sockmap: Remove unhash handler for BPF sockmap usage")
it is possible for a socket to transition to TCP_LISTEN state while already
linked to a sockmap, e.g. connect() -> insert into map ->
connect(AF_UNSPEC) -> listen().

[1]: https://lore.kernel.org/all/00000000000073b14905ef2e7401@google.com/

The Linux kernel CVE team has assigned CVE-2023-52986 to this issue.

Affected and fixed versions
===========================

	Issue introduced in 5.7 with commit e80251555f0befd1271e74b080bccf0ff0348bfc and fixed in 5.10.168 with commit 9bd6074e1872d22190a8da30e796cbf937d334f0
	Issue introduced in 5.7 with commit e80251555f0befd1271e74b080bccf0ff0348bfc and fixed in 5.15.93 with commit c681d7a4ed3d360de0574f4d6b7305a8de8dc54f
	Issue introduced in 5.7 with commit e80251555f0befd1271e74b080bccf0ff0348bfc and fixed in 6.1.11 with commit 12b0ec7c6953e1602957926439e5297095d7d065
	Issue introduced in 5.7 with commit e80251555f0befd1271e74b080bccf0ff0348bfc and fixed in 6.2 with commit ddce1e091757d0259107c6c0c7262df201de2b66

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2023-52986
will be updated if fixes are backported, please check that for the most
up to date information about this issue.

Affected files
==============

The file(s) affected by this issue are:
	include/linux/util_macros.h
	net/ipv4/tcp_bpf.c

Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/9bd6074e1872d22190a8da30e796cbf937d334f0
	https://git.kernel.org/stable/c/c681d7a4ed3d360de0574f4d6b7305a8de8dc54f
	https://git.kernel.org/stable/c/12b0ec7c6953e1602957926439e5297095d7d065
	https://git.kernel.org/stable/c/ddce1e091757d0259107c6c0c7262df201de2b66