[PATCH v1] net: sock_reuseport: check program type on the migration path

[PATCH v1] net: sock_reuseport: check program type on the migration path

[Shihuang Liu]

From: Linux kernel audit <audit@example.invalid>

A BPF_PROG_TYPE_SOCKET_FILTER program can be loaded with
expected_attach_type set to BPF_SK_REUSEPORT_SELECT_OR_MIGRATE and
attached to a SO_REUSEPORT TCP group; both steps are allowed without
CAP_BPF.  Closing a listener that still has queued children then runs
that socket filter with a struct sk_reuseport_kern as its context,
while the program was verified against struct sk_buff.  It reads and
writes past the 56-byte object on the stack, which KASAN reports as a
stack-out-of-bounds in ___bpf_prog_run().

The cause is that reuseport_migrate_sock() decides from
prog->expected_attach_type alone.  That field is supplied by user
space and does not identify the program type, and
bpf_prog_load_check_attach() does not reject the value for
SOCKET_FILTER programs.

Fix this by requiring BPF_PROG_TYPE_SK_REUSEPORT before running the
program, and use the same check in reuseport_stop_listen_sock().
Socket filters can still be attached and used as selectors; the
selection path is unchanged.

Fixes: d5e4ddaeb6ab ("bpf: Support socket migration by eBPF.")
Signed-off-by: Linux kernel audit <audit@example.invalid>
---
 net/core/sock_reuseport.c | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

--- a/net/core/sock_reuseport.c
+++ b/net/core/sock_reuseport.c
@@ -460,6 +460,18 @@
 }
 EXPORT_SYMBOL(reuseport_detach_sock);
 
+/*
+ * Only a BPF_PROG_TYPE_SK_REUSEPORT program is verified against
+ * struct sk_reuseport_kern, which is the context bpf_run_sk_reuseport()
+ * passes to it.  expected_attach_type is set by user space and does not
+ * identify the program type.
+ */
+static bool reuseport_is_migration_prog(const struct bpf_prog *prog)
+{
+	return prog && prog->type == BPF_PROG_TYPE_SK_REUSEPORT &&
+	       prog->expected_attach_type == BPF_SK_REUSEPORT_SELECT_OR_MIGRATE;
+}
+
 void reuseport_stop_listen_sock(struct sock *sk)
 {
 	if (sk->sk_protocol == IPPROTO_TCP) {
@@ -474,7 +486,7 @@
 						 lockdep_is_held(&reuseport_lock));
 
 		if (READ_ONCE(sock_net(sk)->ipv4.sysctl_tcp_migrate_req) ||
-		    (prog && prog->expected_attach_type == BPF_SK_REUSEPORT_SELECT_OR_MIGRATE)) {
+		    reuseport_is_migration_prog(prog)) {
 			/* Migration capable, move sk from the listening section
 			 * to the closed section.
 			 */
@@ -644,7 +656,7 @@
 
 	hash = migrating_sk->sk_hash;
 	prog = rcu_dereference(reuse->prog);
-	if (!prog || prog->expected_attach_type != BPF_SK_REUSEPORT_SELECT_OR_MIGRATE) {
+	if (!reuseport_is_migration_prog(prog)) {
 		if (READ_ONCE(sock_net(sk)->ipv4.sysctl_tcp_migrate_req))
 			goto select_by_hash;
 		goto failure;

Re: [PATCH v1] net: sock_reuseport: check program type on the migration path

[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.

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.

*IMPORTANT*: If you do repost (for other reasons) - please include
the relevant info in the cover letter or commit messages.
-- 
The evaluation is done by an LLM so it may be wrong, if you think
that is the case please reply and explain.

Re: [PATCH v1] net: sock_reuseport: check program type on the migration path

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [High] net: sock_reuseport: placeholder Signed-off-by trailer in
  commit message
--

commit cfe7ad076364a4b63b18cb16611dd2ffb1e3f230
Author: Linux kernel audit <audit@example.invalid>

> net: sock_reuseport: check program type on the migration path
>
> A BPF_PROG_TYPE_SOCKET_FILTER program can be loaded with
> expected_attach_type set to BPF_SK_REUSEPORT_SELECT_OR_MIGRATE and
> attached to a SO_REUSEPORT TCP group; both steps are allowed without
> CAP_BPF.  Closing a listener that still has queued children then runs
> that socket filter with a struct sk_reuseport_kern as its context,
> while the program was verified against struct sk_buff.  It reads and
> writes past the 56-byte object on the stack, which KASAN reports as a
> stack-out-of-bounds in ___bpf_prog_run().
>
> The cause is that reuseport_migrate_sock() decides from
> prog->expected_attach_type alone.  That field is supplied by user
> space and does not identify the program type, and
> bpf_prog_load_check_attach() does not reject the value for
> SOCKET_FILTER programs.
>
> Fix this by requiring BPF_PROG_TYPE_SK_REUSEPORT before running the
> program, and use the same check in reuseport_stop_listen_sock().
> Socket filters can still be attached and used as selectors; the
> selection path is unchanged.
>
> Fixes: d5e4ddaeb6ab ("bpf: Support socket migration by eBPF.")
> Signed-off-by: Linux kernel audit <audit@example.invalid>

[Severity: High]
The Signed-off-by trailer uses a placeholder identity and a non-routable
.invalid email address instead of a real developer name and routable
email address as required by the Developer's Certificate of Origin.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261115152408.48205-1-shlomojune6@gmail.com?part=1

Re: [PATCH v1] net: sock_reuseport: check program type on the migration path

[J4f J4f]

On Sun, 15 Nov 2026 at 23:24, Shihuang Liu <shlomojune6@gmail.com> wrote:
>
> From: Linux kernel audit <audit@example.invalid>
>
> A BPF_PROG_TYPE_SOCKET_FILTER program can be loaded with
> expected_attach_type set to BPF_SK_REUSEPORT_SELECT_OR_MIGRATE and
> attached to a SO_REUSEPORT TCP group; both steps are allowed without
> CAP_BPF.  Closing a listener that still has queued children then runs
> that socket filter with a struct sk_reuseport_kern as its context,
> while the program was verified against struct sk_buff.  It reads and
> writes past the 56-byte object on the stack, which KASAN reports as a
> stack-out-of-bounds in ___bpf_prog_run().
>
> The cause is that reuseport_migrate_sock() decides from
> prog->expected_attach_type alone.  That field is supplied by user
> space and does not identify the program type, and
> bpf_prog_load_check_attach() does not reject the value for
> SOCKET_FILTER programs.
>
> Fix this by requiring BPF_PROG_TYPE_SK_REUSEPORT before running the
> program, and use the same check in reuseport_stop_listen_sock().
> Socket filters can still be attached and used as selectors; the
> selection path is unchanged.
>
> Fixes: d5e4ddaeb6ab ("bpf: Support socket migration by eBPF.")
> Signed-off-by: Linux kernel audit <audit@example.invalid>
> ---

My mistake — I got the From: and Signed-off-by: wrong in v1.  Code and
commit message are unchanged; v2 will fix that.

Thanks
Shihuang
>  net/core/sock_reuseport.c | 16 ++++++++++++++--
>  1 file changed, 14 insertions(+), 2 deletions(-)
>
> --- a/net/core/sock_reuseport.c
> +++ b/net/core/sock_reuseport.c
> @@ -460,6 +460,18 @@
>  }
>  EXPORT_SYMBOL(reuseport_detach_sock);
>
> +/*
> + * Only a BPF_PROG_TYPE_SK_REUSEPORT program is verified against
> + * struct sk_reuseport_kern, which is the context bpf_run_sk_reuseport()
> + * passes to it.  expected_attach_type is set by user space and does not
> + * identify the program type.
> + */
> +static bool reuseport_is_migration_prog(const struct bpf_prog *prog)
> +{
> +       return prog && prog->type == BPF_PROG_TYPE_SK_REUSEPORT &&
> +              prog->expected_attach_type == BPF_SK_REUSEPORT_SELECT_OR_MIGRATE;
> +}
> +
>  void reuseport_stop_listen_sock(struct sock *sk)
>  {
>         if (sk->sk_protocol == IPPROTO_TCP) {
> @@ -474,7 +486,7 @@
>                                                  lockdep_is_held(&reuseport_lock));
>
>                 if (READ_ONCE(sock_net(sk)->ipv4.sysctl_tcp_migrate_req) ||
> -                   (prog && prog->expected_attach_type == BPF_SK_REUSEPORT_SELECT_OR_MIGRATE)) {
> +                   reuseport_is_migration_prog(prog)) {
>                         /* Migration capable, move sk from the listening section
>                          * to the closed section.
>                          */
> @@ -644,7 +656,7 @@
>
>         hash = migrating_sk->sk_hash;
>         prog = rcu_dereference(reuse->prog);
> -       if (!prog || prog->expected_attach_type != BPF_SK_REUSEPORT_SELECT_OR_MIGRATE) {
> +       if (!reuseport_is_migration_prog(prog)) {
>                 if (READ_ONCE(sock_net(sk)->ipv4.sysctl_tcp_migrate_req))
>                         goto select_by_hash;
>                 goto failure;