From: sashiko-bot@kernel.org
To: "Pengpeng Hou" <pengpeng@iscas.ac.cn>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH v2] bpf: crypto: snapshot params before string validation
Date: Thu, 23 Apr 2026 23:12:32 +0000 [thread overview]
Message-ID: <20260423231232.C8AE5C2BCAF@smtp.kernel.org> (raw)
In-Reply-To: <20260424070105.1-bpf-crypto-v2-pengpeng@iscas.ac.cn>
Sashiko AI review found 2 potential issue(s):
- [Medium] Cryptographic key material is left on the kernel stack without being zeroized.
- [Low] Unnecessary and technically incorrect file descriptor validation for a skeleton-generated program.
--
commit 4025cf60c980030df8d7712c14d6f5b70e1660b8
Author: Pengpeng Hou <pengpeng@iscas.ac.cn>
bpf: crypto: snapshot params before string validation
This commit updates bpf_crypto_ctx_create() to snapshot the BPF-provided
parameters into a local stack variable before validating them. This prevents
issues where BPF programs might modify the memory during validation. It also
adds a selftest for testing invalid crypto algorithms.
> diff --git a/kernel/bpf/crypto.c b/kernel/bpf/crypto.c
> index 51f89cecefb4dc..e2dc3dfb4d8540 100644
> --- a/kernel/bpf/crypto.c
> +++ b/kernel/bpf/crypto.c
[ ... ]
> @@ -147,31 +147,46 @@ bpf_crypto_ctx_create(const struct bpf_crypto_params *params, u32 params__sz,
> int *err)
> {
> const struct bpf_crypto_type *type;
> + struct bpf_crypto_params params_copy;
> struct bpf_crypto_ctx *ctx;
[ ... ]
> + params_copy = *params;
Does this leave plain-text cryptographic keys on the kernel stack?
The struct bpf_crypto_params contains key material. By copying the caller's
structure into the local params_copy variable, the key is placed on the
stack. Should params_copy be cleared using memzero_explicit() before the
function returns on both success and error paths to prevent potential
information leaks?
[ ... ]
> diff --git a/tools/testing/selftests/bpf/prog_tests/crypto_sanity.c b/tools/testing/selftests/bpf/prog_tests/crypto_sanity.c
> index 42bd07f7218dc3..044711e7263a8f 100644
> --- a/tools/testing/selftests/bpf/prog_tests/crypto_sanity.c
> +++ b/tools/testing/selftests/bpf/prog_tests/crypto_sanity.c
[ ... ]
> @@ -117,6 +117,19 @@ void test_crypto_sanity(void)
> udp_test_port = skel->data->udp_test_port;
> memcpy(skel->bss->key, crypto_key, sizeof(crypto_key));
> snprintf(skel->bss->algo, 128, "%s", algo);
> +
> + pfd = bpf_program__fd(skel->progs.skb_crypto_setup_bad_algo);
> + if (!ASSERT_GT(pfd, 0, "skb_crypto_setup_bad_algo fd"))
Is this file descriptor check necessary?
After a successful skeleton open_and_load(), the skeleton-generated program
fields are guaranteed to contain valid file descriptors, making manual
validation redundant.
Additionally, 0 is a valid file descriptor in Linux. If the test program
received FD 0, using ASSERT_GT(pfd, 0) would incorrectly cause the test to
fail. Could this be removed?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260424070105.1-bpf-crypto-v2-pengpeng@iscas.ac.cn?part=1
prev parent reply other threads:[~2026-04-23 23:12 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-17 7:31 [PATCH] bpf: crypto: reject unterminated type and algorithm names Pengpeng Hou
2026-04-17 7:43 ` sashiko-bot
2026-04-18 21:33 ` Vadim Fedorenko
2026-04-23 15:34 ` [PATCH v2] bpf: crypto: snapshot params before string validation Pengpeng Hou
2026-04-23 23:12 ` sashiko-bot [this message]
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=20260423231232.C8AE5C2BCAF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=pengpeng@iscas.ac.cn \
--cc=sashiko@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.