[PATCH net] tcp: restrict SO_ATTACH_BPF to privileged users

[PATCH net] tcp: restrict SO_ATTACH_BPF to privileged users

[Manjunath Patil]

Commit 5d39580f68e6 ("tcp: restrict SO_ATTACH_FILTER to priv users")
requires CAP_NET_ADMIN to attach a classic BPF filter to a TCP socket.
However, a caller can still attach an eBPF socket filter through
SO_ATTACH_BPF without this capability. Both options install a filter
that runs on incoming TCP packets.

Disabling unprivileged BPF loading does not close this gap: a caller
that already holds a socket-filter program file descriptor can still
use SO_ATTACH_BPF.

Use one CAP_NET_ADMIN check for both attachment options before taking
the socket lock. Use the same namespace-aware capability helper already
used by SO_ATTACH_FILTER. Leave other socket types unchanged.

Fixes: 5d39580f68e6 ("tcp: restrict SO_ATTACH_FILTER to priv users")
Assisted-by: Codex:gpt-6
Signed-off-by: Manjunath Patil <manjunath.b.patil@oracle.com>
---
 net/core/sock.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/net/core/sock.c b/net/core/sock.c
index e7405be8941f..5f6d8b9ff4f6 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -1310,6 +1310,12 @@ int sk_setsockopt(struct sock *sk, int level, int optname,
 					optlen, optname == SO_RCVTIMEO_OLD);
 	}
 
+	/* Restrict TCP socket filters to prevent sequence/ack-number probing. */
+	if ((optname == SO_ATTACH_FILTER || optname == SO_ATTACH_BPF) &&
+	    sk_is_tcp(sk) &&
+	    !sockopt_ns_capable(sock_net(sk)->user_ns, CAP_NET_ADMIN))
+		return -EPERM;
+
 	sockopt_lock_sock(sk);
 
 	switch (optname) {
@@ -1466,11 +1472,6 @@ int sk_setsockopt(struct sock *sk, int level, int optname,
 	case SO_ATTACH_FILTER: {
 		struct sock_fprog fprog;
 
-		if (sk_is_tcp(sk) &&
-		    !sockopt_ns_capable(sock_net(sk)->user_ns, CAP_NET_ADMIN)) {
-			ret = -EPERM;
-			break;
-		}
 		ret = copy_bpf_fprog_from_user(&fprog, optval, optlen);
 		if (!ret)
 			ret = sk_attach_filter(&fprog, sk);

base-commit: 65ba8f34ec886ec72b2c07ddc8cf3d815c32869d
-- 
2.52.0

Re: [PATCH net] tcp: restrict SO_ATTACH_BPF to privileged users

[Alexei Starovoitov]

On Wed, Oct 28, 2026 at 02:58 PM Manjunath Patil <manjunath.b.patil@oracle.com> wrote:
> Commit 5d39580f68e6 ("tcp: restrict SO_ATTACH_FILTER to priv users")
> requires CAP_NET_ADMIN to attach a classic BPF filter to a TCP socket.
> However, a caller can still attach an eBPF socket filter through
> SO_ATTACH_BPF without this capability. Both options install a filter
> that runs on incoming TCP packets.

Nack.
SO_ATTACH_FILTER takes insns that the caller wrote.
SO_ATTACH_BPF takes a prog FD, and BPF_PROG_LOAD is the gate for it.
unprivileged_bpf_disabled is 2 by default, so the load needs CAP_BPF.
An admin who sets it to 0 allows every user to load socket filters.

> Disabling unprivileged BPF loading does not close this gap: a caller
> that already holds a socket-filter program file descriptor can still
> use SO_ATTACH_BPF.

That's not a gap. The FD is the permission.
A process with CAP_BPF loads the prog and passes the FD to a process
without caps. See the comment in bpf_prog_load() and
commit c8644cd0efe7 ("bpf: refine kernel.unprivileged_bpf_disabled behaviour").
This patch breaks it. It also breaks a process that has CAP_BPF and
doesn't have CAP_NET_ADMIN.

pw-bot: cr

Re: [PATCH net] tcp: restrict SO_ATTACH_BPF to privileged users

[manjunath.b.patil]

Hi,
On 10/28/26 3:12 PM, Alexei Starovoitov wrote:
> On Wed, Oct 28, 2026 at 02: 58 PM Manjunath Patil <manjunath. b. patil@  
> oracle. com> wrote: > Commit 5d39580f68e6 ("tcp: restrict 
> SO_ATTACH_FILTER to priv users") > requires CAP_NET_ADMIN to attach a 
> classic BPF filter to a TCP socket. 
> 
> 
> On Wed, Oct 28, 2026 at 02:58 PM Manjunath Patil <manjunath.b.patil@oracle.com> wrote:
>> Commit 5d39580f68e6 ("tcp: restrict SO_ATTACH_FILTER to priv users")
>> requires CAP_NET_ADMIN to attach a classic BPF filter to a TCP socket.
>> However, a caller can still attach an eBPF socket filter through
>> SO_ATTACH_BPF without this capability. Both options install a filter
>> that runs on incoming TCP packets.
> 
> Nack.
> SO_ATTACH_FILTER takes insns that the caller wrote.
> SO_ATTACH_BPF takes a prog FD, and BPF_PROG_LOAD is the gate for it.
Thanks for the explanation. I overlooked this distinction and treated 
the different attachment checks as a missing permission check.

> unprivileged_bpf_disabled is 2 by default, so the load needs CAP_BPF.
> An admin who sets it to 0 allows every user to load socket filters.
> 
>> Disabling unprivileged BPF loading does not close this gap: a caller
>> that already holds a socket-filter program file descriptor can still
>> use SO_ATTACH_BPF.
> 
> That's not a gap. The FD is the permission.
> A process with CAP_BPF loads the prog and passes the FD to a process
> without caps.
My test loaded the socket-filter program as root, then retained its FD 
in a worker that dropped its capabilities. That exercises supported 
delegation; it does not establish a security bypass.

  See the comment in bpf_prog_load() and
> commit c8644cd0efe7 ("bpf: refine kernel.unprivileged_bpf_disabled behaviour").
> This patch breaks it. It also breaks a process that has CAP_BPF and
> doesn't have CAP_NET_ADMIN.
I agree. I am withdrawing this patch.

-Thanks,
Manjunath>
> pw-bot: cr
> 

Re: [PATCH net] tcp: restrict SO_ATTACH_BPF to privileged users

[netdev-bot+sinfo]

Hi!

This is an automated message. This series looks like a fix, but its
commit messages seem to be missing some information:

 - How the issue was discovered, e.g. hit in production, hit during
   development, syzbot report, manual code inspection, LLM or static
   analysis tool scan.

 - Whether the issue was actually triggered, or is only theoretical
   (e.g. found by code inspection). If it was triggered please include
   the symptoms, like the stack trace or error messages.

Please do not repost the series just to address the above. Instead,
reply to this email with the missing information, so that reviewers
can take it into account. If the series needs another revision for
other reasons, please include the information in the commit messages
then.

The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.