CVE-2023-52986

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

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

A listening socket linked to a sockmap has its skprot overridden. It points to one of the struct proto variants in tcpbpf_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 skprot. But before cloning is finished, we restore the child's proto to the listener's original non-tcpbpfprots one. This happens in tcpcreateopenreqchild -> tcpbpfclone.

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

If the listeners skprot happens to be not the TCPBPFBASE variant, then the child socket unintentionally is left if the inherited skprot by tcpbpfclone.

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

Adjust the check in tcpbpfclone to detect all of tcpbpfprots variants.

Note that it wouldn't be sufficient to check the socket state when overriding the skprot in tcpbpfupdateproto in order to always use the TCPBPFBASE 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 TCPLISTEN state while already linked to a sockmap, e.g. connect() -> insert into map -> connect(AFUNSPEC) -> listen().