From: sashiko-bot@kernel.org
To: "Yiyang Chen" <chenyy23@mails.tsinghua.edu.cn>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next 1/2] bpf: Guard conntrack opts error writes
Date: Tue, 16 Jun 2026 05:57:18 +0000 [thread overview]
Message-ID: <20260616055718.F20421F000E9@smtp.kernel.org> (raw)
In-Reply-To: <70aeec0ab762aebe65129cf6052e132c7329edc2.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] TOCTOU Vulnerability / Use-After-Free due to multiple reads of BPF-provided `opts->netns_id`
--
commit 8efa13ac7f8992d846ab4af35e05c540c530390f
Author: Yiyang Chen <chenyy23@mails.tsinghua.edu.cn>
bpf: Guard conntrack opts error writes
This commit updates the BPF conntrack lookup and allocation wrappers to
conditionally write to opts->error. It ensures the write only occurs if
the provided opts__sz is large enough to include the error field.
> diff --git a/net/netfilter/nf_conntrack_bpf.c b/net/netfilter/nf_conntrack_bpf.c
> index 40c261cd0af38..3c182024ec509 100644
> --- a/net/netfilter/nf_conntrack_bpf.c
> +++ b/net/netfilter/nf_conntrack_bpf.c
[ ... ]
> @@ -298,7 +303,8 @@ bpf_xdp_ct_alloc(struct xdp_md *xdp_ctx, struct bpf_sock_tuple *bpf_tuple,
> nfct = __bpf_nf_ct_alloc_entry(dev_net(ctx->rxq->dev), bpf_tuple, tuple__sz,
> opts, opts__sz, 10);
[Severity: High]
This is a pre-existing issue, but does __bpf_nf_ct_alloc_entry() (and
similarly __bpf_nf_ct_lookup()) have a time-of-check to time-of-use
(TOCTOU) vulnerability regarding opts->netns_id?
The BPF verifier allows the opts argument to point to memory that can be
concurrently modified by a BPF program. Inside __bpf_nf_ct_alloc_entry(),
opts->netns_id is read multiple times:
net/netfilter/nf_conntrack_bpf.c:__bpf_nf_ct_alloc_entry() {
...
if (opts->netns_id >= 0) {
net = get_net_ns_by_id(net, opts->netns_id);
...
out:
if (opts->netns_id >= 0)
put_net(net);
}
Since function calls like get_net_ns_by_id() act as compiler barriers,
the value will be reloaded from memory. If a concurrent thread modifies
opts->netns_id from a negative value to a valid ID between the initial
check and the final put_net() check, could the function drop a reference
it never acquired, leading to a refcount underflow and use-after-free?
Similarly, changing it from a valid ID to a negative value could cause
a reference leak. Could we cache the value of opts->netns_id in a local
variable to ensure the same value is used for both checks?
> if (IS_ERR(nfct)) {
> - opts->error = PTR_ERR(nfct);
> + if (bpf_ct_opts_has_error(opts__sz))
> + opts->error = PTR_ERR(nfct);
> return NULL;
> }
>
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1781586477.git.chenyy23@mails.tsinghua.edu.cn?part=1
next prev parent reply other threads:[~2026-06-16 5:57 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 [this message]
2026-06-16 5:42 ` [PATCH bpf-next 2/2] selftests/bpf: Cover small " Yiyang Chen
2026-06-16 5:52 ` sashiko-bot
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=20260616055718.F20421F000E9@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.