All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Fastabend <john.fastabend@gmail.com>
To: bot+bpf-ci@kernel.org
Cc: zhaogongyi@bytedance.com, bpf@vger.kernel.org,
	netdev@vger.kernel.org,  linux-kernel@vger.kernel.org,
	jakub@cloudflare.com, jiayuan.chen@linux.dev,
	 edumazet@google.com, kuniyu@google.com, pabeni@redhat.com,
	willemb@google.com,  davem@davemloft.net, kuba@kernel.org,
	horms@kernel.org, ast@kernel.org,  andrii@kernel.org,
	daniel@iogearbox.net, martin.lau@kernel.org, eddyz87@gmail.com,
	 yonghong.song@linux.dev, mason@kernel.org,
	ihor.solodrai@linux.dev
Subject: Re: [PATCH bpf] bpf, sockmap: reject max_entries > INT_MAX in sock_map_alloc
Date: Tue, 22 Sep 2026 10:06:57 -0700	[thread overview]
Message-ID: <arK1CpHjWpmX0S55@john-p8> (raw)
In-Reply-To: <dc4bd7fb4d98a0066958a4e1582b6a7a407079fd9a284318848909f9594a9295@mail.kernel.org>

On Tue, Sep 15, 2026 at 08:13:48AM +0000, bot+bpf-ci@kernel.org wrote:
>> sock_map_alloc() only rejects max_entries == 0 and never caps the upper
>> bound.  sock_map_free() then walks the sks[] array with a signed int
>> iterator:
>>
>> 	int i;
>> 	for (i = 0; i < stab->map.max_entries; i++)
>> 		struct sock **psk = &stab->sks[i];
>>
>> When a SOCKMAP is created with max_entries = 0xffffffff (UINT_MAX), the
>> allocation of 32 GiB can succeed on large-memory hosts.  During free the
>> counter reaches 0x80000000, wraps to INT_MIN, is sign-extended by movslq
>> and turned into a ~16 GiB negative offset from stab->sks, pointing far
>> below the allocation.  On a KASAN kernel the shadow check for that
>> address hits an unmapped shadow page and oopses:

[...]

>> Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg 
>> interface")
>
>Is 604326b41a6f the commit that introduced this bug?
>
>Looking at that commit, the version of sock_map_alloc() it created did
>cap max_entries:
>
>    /* Make sure page count doesn't overflow. */
>    cost = (u64) stab->map.max_entries * sizeof(struct sock *);
>    if (cost >= U32_MAX - PAGE_SIZE) {
>            err = -EINVAL;
>            goto free_stab;
>    }
>
>This bound limits max_entries to below (U32_MAX - PAGE_SIZE) / 8, about
>536,870,400 entries, which is far under INT_MAX. With that bound the
>signed iterator in sock_map_free() could not overflow.
>
>The check later moved into bpf_map_charge_init() with the same limit.
>The upper bound was actually removed by 0d2c4f964050 ("bpf: Eliminate
>rlimit-based memory accounting for sockmap and sockhash maps", v5.11),
>which deleted the bpf_map_charge_init() call without replacing the size
>check.
>
>Should the Fixes tag be:
>
>    Fixes: 0d2c4f964050 ("bpf: Eliminate rlimit-based memory accounting for sockmap and sockhash maps")

The fix is good, its probably worth getting the Fixes tag correct?

>
>> diff --git a/net/core/sock_map.c b/net/core/sock_map.c
>> index ca49bc7f8687c..38df842843289 100644
>> --- a/net/core/sock_map.c
>> +++ b/net/core/sock_map.c
>> @@ -41,6 +41,7 @@ static struct bpf_map *sock_map_alloc(union bpf_attr *attr)
>>  	struct bpf_stab *stab;
>>
>>  	if (attr->max_entries == 0 ||
>> +	    attr->max_entries > INT_MAX ||
>>  	    attr->key_size    != 4 ||
>>  	    (attr->value_size != sizeof(u32) &&
>>  	     attr->value_size != sizeof(u64)) ||

Otherwise,

Reviewed-by: John Fastabend <john.fastabend@gmail.com>

  reply	other threads:[~2026-09-22 17:07 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-15  7:17 [PATCH bpf] bpf, sockmap: reject max_entries > INT_MAX in sock_map_alloc Zhao Gongyi
2026-09-15  8:13 ` bot+bpf-ci
2026-09-22 17:06   ` John Fastabend [this message]
2026-09-17 12:10 ` [PATCH bpf v2] " Zhao Gongyi
2026-09-23  0:00   ` patchwork-bot+netdevbpf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=arK1CpHjWpmX0S55@john-p8 \
    --to=john.fastabend@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bot+bpf-ci@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=eddyz87@gmail.com \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=ihor.solodrai@linux.dev \
    --cc=jakub@cloudflare.com \
    --cc=jiayuan.chen@linux.dev \
    --cc=kuba@kernel.org \
    --cc=kuniyu@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.lau@kernel.org \
    --cc=mason@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=willemb@google.com \
    --cc=yonghong.song@linux.dev \
    --cc=zhaogongyi@bytedance.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.