From: sashiko-bot@kernel.org
To: "Yiyang Chen" <chenyy23@mails.tsinghua.edu.cn>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next 2/2] selftests/bpf: Cover small conntrack opts error writes
Date: Tue, 16 Jun 2026 05:52:34 +0000 [thread overview]
Message-ID: <20260616055234.DCE671F000E9@smtp.kernel.org> (raw)
In-Reply-To: <c4c898dd23181b676ebf6b6b4d9c54f51bb69c75.1781586477.git.chenyy23@mails.tsinghua.edu.cn>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Missing bounds check for the enum parameter `manip` in the `bpf_ct_set_nat_info` kfunc allows a BPF program to pass an arbitrary value, triggering a `WARN_ON` and corrupting the conntrack state.
--
commit a2c96d6b406da0481952334b633ba64cd47d26da
Author: Yiyang Chen <chenyy23@mails.tsinghua.edu.cn>
selftests/bpf: Cover small conntrack opts error writes
This commit adds a conntrack kfunc regression check for opts__sz values
that do not cover opts->error. It verifies that the guard value remains
intact when the kfunc returns NULL due to an error.
> diff --git a/tools/testing/selftests/bpf/progs/test_bpf_nf.c b/tools/testing/selftests/bpf/progs/test_bpf_nf.c
> index 076fbf03a1268..df43649ecb785 100644
> --- a/tools/testing/selftests/bpf/progs/test_bpf_nf.c
> +++ b/tools/testing/selftests/bpf/progs/test_bpf_nf.c
[ ... ]
> @@ -124,6 +128,28 @@ nf_ct_test(struct nf_conn *(*lookup_fn)(void *, struct bpf_sock_tuple *, u32,
> else
> test_einval_len_opts = opts_def.error;
>
> + opts_def.error = CT_OPTS_ERROR_GUARD;
> + ct = lookup_fn(ctx, &bpf_tuple, sizeof(bpf_tuple.ipv4), &opts_def,
> + sizeof(opts_def.netns_id));
> + if (ct) {
> + bpf_ct_release(ct);
> + test_einval_len_opts_small_lookup = -EINVAL;
> + } else {
> + test_einval_len_opts_small_lookup = opts_def.error;
> + }
> +
> + opts_def.error = CT_OPTS_ERROR_GUARD;
> + ct = alloc_fn(ctx, &bpf_tuple, sizeof(bpf_tuple.ipv4), &opts_def,
> + sizeof(opts_def.netns_id));
> + if (ct) {
> + ct = bpf_ct_insert_entry(ct);
> + if (ct)
> + bpf_ct_release(ct);
> + test_einval_len_opts_small_alloc = -EINVAL;
> + } else {
> + test_einval_len_opts_small_alloc = opts_def.error;
> + }
> +
[Severity: High]
This is a pre-existing issue, but while reviewing these conntrack kfunc
tests I noticed that bpf_ct_set_nat_info() lacks a bounds check for the
manip enum parameter.
Since the BPF verifier does not check the range of enum values passed to
kfuncs unless they are annotated with __const, could a BPF program pass an
arbitrary scalar value for the manip parameter?
Looking at net/netfilter/nf_nat_bpf.c:bpf_ct_set_nat_info():
__bpf_kfunc int bpf_ct_set_nat_info(struct nf_conn___init *nfct,
union nf_inet_addr *addr, int port,
enum nf_nat_manip_type manip)
{
...
return nf_nat_setup_info(ct, &range, manip) == NF_DROP ? -ENOMEM : 0;
}
If an invalid value is passed directly to nf_nat_setup_info(), would it
trigger the WARN_ON(maniptype != NF_NAT_MANIP_SRC && maniptype !=
NF_NAT_MANIP_DST) and fall through the default branches?
It seems this could result in the connection status being inconsistently set,
potentially corrupting the conntrack state or acting as a local denial of
service vector if panic_on_warn is enabled.
> opts_def.l4proto = IPPROTO_ICMP;
> ct = lookup_fn(ctx, &bpf_tuple, sizeof(bpf_tuple.ipv4), &opts_def,
> sizeof(opts_def));
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1781586477.git.chenyy23@mails.tsinghua.edu.cn?part=2
next prev parent reply other threads:[~2026-06-16 5:52 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-16 5:42 [PATCH bpf-next 0/2] bpf: Guard conntrack opts error writes Yiyang Chen
2026-06-16 5:42 ` [PATCH bpf-next 1/2] " Yiyang Chen
2026-06-16 5:57 ` sashiko-bot
2026-06-16 5:42 ` [PATCH bpf-next 2/2] selftests/bpf: Cover small " Yiyang Chen
2026-06-16 5:52 ` sashiko-bot [this message]
2026-06-16 6:19 ` 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=20260616055234.DCE671F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=chenyy23@mails.tsinghua.edu.cn \
--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.