BPF List
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Ren Wei" <weir@nebusec.ai>, bpf@vger.kernel.org
Subject: Re: [PATCH bpf 1/2] bpf: Reject user ringbuf backlogs larger than total ring size
Date: Mon, 09 Nov 2026 03:17:04 +0000	[thread overview]
Message-ID: <sashiko-outbox-204366@kernel.org> (raw)
In-Reply-To: <ecf1a73cac8881d58b0b5957fb72caaeaa055339.1793951856.git.rakukuip@gmail.com>

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] bpf: early backlog check in __bpf_user_ringbuf_peek() breaks
  -E2BIG return
It also noticed 1 related pre-existing issue this patch does not
introduce:
- [High] bpf: compat mode ring buffer hang in __bpf_user_ringbuf_peek()
  [1]
--

commit c14bce3c5f895ee2ea691c51e1942bac34af6108
Author: Luxiao Xu <rakukuip@gmail.com>

bpf: Reject user ringbuf backlogs larger than total ring size

This commit rejects user ring buffer drain operations with -EINVAL when
the unread window between producer_pos and consumer_pos exceeds the total
data size of the ring buffer.

> diff --git a/kernel/bpf/ringbuf.c b/kernel/bpf/ringbuf.c
> index 447863ece26a3..cfd4fe4e85ee6 100644
> --- a/kernel/bpf/ringbuf.c
> +++ b/kernel/bpf/ringbuf.c
> @@ -761,6 +761,9 @@ static int __bpf_user_ringbuf_peek(struct bpf_ringbuf *rb, void **sample, u32 *s
>  	if (cons_pos >= prod_pos)
>  		return -ENODATA;

[Severity: High]
This problem wasn't introduced by this patch, but can cons_pos >= prod_pos
permanently stall sample processing for a 32-bit compat user-space
producer on a 64-bit kernel [1]?

A 32-bit compat application updates rb->producer_pos with a 32-bit store
that wraps to zero at 4 GB, while the 64-bit kernel increments
rb->consumer_pos past 4 GB using 64-bit arithmetic.  Once producer_pos
wraps, cons_pos >= prod_pos evaluates to true and __bpf_user_ringbuf_peek()
returns -ENODATA on every subsequent drain.

>  
> +	if (prod_pos - cons_pos > ringbuf_total_data_sz(rb))
> +		return -EINVAL;

[Severity: Medium]
Does checking prod_pos - cons_pos > ringbuf_total_data_sz(rb) here break
the -E2BIG return for a single oversized sample?

Later in __bpf_user_ringbuf_peek(), total_len is checked against both
prod_pos - cons_pos and ringbuf_total_data_sz(rb):

kernel/bpf/ringbuf.c:__bpf_user_ringbuf_peek() {
	...
	/* The sample must fit within the region advertised by the producer position. */
	if (total_len > prod_pos - cons_pos)
		return -EINVAL;

	/* The sample must fit within the data region of the ring buffer. */
	if (total_len > ringbuf_total_data_sz(rb))
		return -E2BIG;
	...
}

Because prod_pos - cons_pos <= ringbuf_total_data_sz(rb) and
total_len <= prod_pos - cons_pos are already enforced before reaching
total_len > ringbuf_total_data_sz(rb), the -E2BIG branch becomes
unreachable.  When user space publishes a single sample larger than the
ring buffer (setting producer_pos to at least ringbuf_total_data_sz(rb) +
BPF_RINGBUF_HDR_SZ), bpf_user_ringbuf_drain() now returns -EINVAL instead
of the -E2BIG documented in include/uapi/linux/bpf.h and expected by
test_user_ringbuf_post_larger_than_ringbuf_sz() in
tools/testing/selftests/bpf/prog_tests/user_ringbuf.c.

[1] https://sashiko.dev/#/bug/linux-262d24f9-bac4-4511-aaed-6698163eb6f5

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1793951856.git.rakukuip@gmail.com?part=1

  reply	other threads:[~2026-11-09  3:17 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-09  3:03 [PATCH bpf 0/2] bpf: Reject user ringbuf backlogs larger than total ring size Ren Wei
2026-11-09  3:03 ` [PATCH bpf 1/2] " Ren Wei
2026-11-09  3:17   ` sashiko-bot [this message]
2026-11-09 18:28   ` Alexei Starovoitov
2026-11-09  3:03 ` [PATCH bpf 2/2] selftests/bpf: Test user ringbuf backlog larger than " Ren Wei
2026-11-09  3:14   ` sashiko-bot

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=sashiko-outbox-204366@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=weir@nebusec.ai \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox