All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Longjun Tang" <lange_tang@163.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v2 4/5] bpf: add bpf_strpbrk kfunc
Date: Wed, 24 Jun 2026 09:49:47 +0000	[thread overview]
Message-ID: <20260624094948.2D9ED1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260624093638.117062-5-lange_tang@163.com>

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:

New issues:
- [Critical] Incomplete bounds check in `bpf_strpbrk` allows pointer wraparound and out-of-bounds reads.
- [High] Unoptimized O(N*M) nested loop in `bpf_strpbrk` causes CPU exhaustion and Denial of Service.

Pre-existing issues:
- [Critical] Incomplete bounds checks in pre-existing string kfuncs allow pointer wraparound and arbitrary memory reads.
- [High] Pre-existing string kfuncs (`bpf_strcspn`, `bpf_strspn`, `bpf_strnstr`, etc.) contain O(N*M) nested loops vulnerable to CPU exhaustion.
--

commit eccea6a6a708ac6a6e30a1e094434ed92118f8f0
Author: Longjun Tang <tanglongjun@kylinos.cn>

bpf: add bpf_strpbrk kfunc

Add bpf_strpbrk() that returns the index of the first character in a
string matching any character from the accept set, or -ENOENT if no
match is found.

> diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c
> --- a/kernel/bpf/helpers.c
> +++ b/kernel/bpf/helpers.c

[ ... ]

> +__bpf_kfunc int bpf_strpbrk(const char *s__ign, const char *accept__ign)
> +{
> +	char cs, ca;
> +	int i, j;
> +
> +	if (!copy_from_kernel_nofault_allowed(s__ign, 1) ||
> +	    !copy_from_kernel_nofault_allowed(accept__ign, 1)) {

[Severity: Critical]
Since the __ign suffix allows arbitrary scalar values as pointers, could
checking only the first byte allow a pointer near ULONG_MAX
(e.g. ULONG_MAX - 5) to pass this validation?

Because the loop below increments the pointer up to XATTR_SIZE_MAX times,
it appears the pointer could wrap around to user space (0). Since
__get_kernel_nofault() uses __get_user(), could this allow reading
arbitrary user-space memory, bypassing security boundaries?

[Severity: Critical]
This is a pre-existing issue, but other string functions like bpf_strcspn()
and __bpf_strnstr() use this same 1-byte validation pattern.

In __bpf_strnstr(), accessing s1 + i + j can reach up to 131,070 bytes past
the start pointer, bypassing mmap_min_addr and allowing direct user space
memory reads from within BPF. Could this be updated across all string kfuncs
to validate the entire memory range being accessed?

> +		return -ERANGE;
> +	}
> +
> +	guard(pagefault)();
> +	for (i = 0; i < XATTR_SIZE_MAX; i++) {
> +		__get_kernel_nofault(&cs, s__ign, char, err_out);
> +		if (cs == '\0')
> +			return -ENOENT;
> +		for (j = 0; j < XATTR_SIZE_MAX; j++) {

[Severity: High]
Does this nested loop introduce a potential CPU stall or soft lockup?

If a BPF program passes 64KB strings for both s__ign and accept__ign where
no characters match and the null terminator is placed near the end of
accept__ign, the outer loop could execute 65,536 times with the inner loop
executing ~65,535 times per iteration.

With page faults disabled via guard(pagefault)(), could this lead to
~4.29 billion memory accesses, potentially causing a Denial of Service?

[Severity: High]
This is a pre-existing issue, but other kfuncs like bpf_strcspn() and
bpf_strspn() also contain these XATTR_SIZE_MAX nested loops.

Could crafted strings force those inner loops to run fully for every
iteration of the outer loop, causing the same CPU exhaustion? Is there a
way to optimize these searches or limit the execution time?

> +			__get_kernel_nofault(&ca, accept__ign + j, char, err_out);
> +			if (ca == '\0')
> +				break;
> +			if (cs == ca)
> +				return i;
> +		}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260624093638.117062-1-lange_tang@163.com?part=4

  reply	other threads:[~2026-06-24  9:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-24  9:36 [PATCH bpf-next v2 0/5] bpf: add bpf_memcmp and bpf_strpbrk kfuncs Longjun Tang
2026-06-24  9:36 ` [PATCH bpf-next v2 1/5] bpf: add bpf_memcmp kfunc Longjun Tang
2026-06-24  9:48   ` sashiko-bot
2026-06-24  9:36 ` [PATCH bpf-next v2 2/5] selftests/bpf: rename local bpf_memcmp to avoid conflict Longjun Tang
2026-06-24  9:36 ` [PATCH bpf-next v2 3/5] selftests/bpf: add tests for bpf_memcmp Longjun Tang
2026-06-24  9:36 ` [PATCH bpf-next v2 4/5] bpf: add bpf_strpbrk kfunc Longjun Tang
2026-06-24  9:49   ` sashiko-bot [this message]
2026-06-24  9:36 ` [PATCH bpf-next v2 5/5] selftests/bpf: add tests for bpf_strpbrk Longjun Tang
2026-06-24  9:48   ` sashiko-bot
2026-06-24 12:08   ` bot+bpf-ci

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=20260624094948.2D9ED1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=lange_tang@163.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.