[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <586edd61c4fed61324d16c9a2a18f1cb416ce89ffa945e5a9f865e7d8cb3c0d1@mail.kernel.org>
Date: Sat, 24 Jan 2026 18:03:35 +0000 (UTC)
From: bot+bpf-ci@...nel.org
To: git@...ielhodges.dev,bpf@...r.kernel.org
Cc: ast@...nel.org,andrii@...nel.org,daniel@...earbox.net,vadim.fedorenko@...ux.dev,song@...nel.org,yatsenko@...a.com,martin.lau@...ux.dev,eddyz87@...il.com,haoluo@...gle.com,jolsa@...nel.org,john.fastabend@...il.com,kpsingh@...nel.org,sdf@...ichev.me,yonghong.song@...ux.dev,herbert@...dor.apana.org.au,davem@...emloft.net,linux-crypto@...r.kernel.org,linux-kernel@...r.kernel.org,linux-kselftest@...r.kernel.org,git@...ielhodges.dev,ast@...nel.org,andrii@...nel.org,daniel@...earbox.net,martin.lau@...nel.org,eddyz87@...il.com,yonghong.song@...ux.dev,clm@...a.com,ihor.solodrai@...ux.dev
Subject: Re: [PATCH bpf-next v6 1/4] bpf: Add hash kfunc for cryptographic hashing
> diff --git a/include/linux/bpf_crypto.h b/include/linux/bpf_crypto.h
> index a41e71d4e2d9..cf2c66f9782b 100644
> --- a/include/linux/bpf_crypto.h
> +++ b/include/linux/bpf_crypto.h
> @@ -3,6 +3,12 @@
> #ifndef _BPF_CRYPTO_H
> #define _BPF_CRYPTO_H
>
> +enum bpf_crypto_type_id {
> + BPF_CRYPTO_TYPE_SKCIPHER = 1,
> + BPF_CRYPTO_TYPE_HASH,
> + BPF_CRYPTO_TYPE_SIG,
> +};
> +
> struct bpf_crypto_type {
[ ... ]
> + enum bpf_crypto_type_id type_id;
> char name[14];
> };
> diff --git a/kernel/bpf/crypto.c b/kernel/bpf/crypto.c
> index 7e75a1936256..bf14856ab5b1 100644
[ ... ]
> @@ -325,6 +337,9 @@ __bpf_kfunc int bpf_crypto_decrypt(struct bpf_crypto_ctx *ctx,
> const struct bpf_dynptr_kern *dst_kern = (struct bpf_dynptr_kern *)dst;
> const struct bpf_dynptr_kern *siv_kern = (struct bpf_dynptr_kern *)siv__nullable;
>
> + if (ctx->type->type_id != BPF_CRYPTO_TYPE_SKCIPHER)
> + return -EINVAL;
The type_id check here will break existing skcipher users. Looking at
crypto/bpf_crypto_skcipher.c, bpf_crypto_lskcipher_type does not set
the type_id field:
static const struct bpf_crypto_type bpf_crypto_lskcipher_type = {
.alloc_tfm = bpf_crypto_lskcipher_alloc_tfm,
...
.owner = THIS_MODULE,
.name = "skcipher",
// no .type_id = BPF_CRYPTO_TYPE_SKCIPHER
};
Since the struct is const and type_id is not initialized, it defaults to 0.
BPF_CRYPTO_TYPE_SKCIPHER is 1, so this check will always fail for skcipher
contexts, causing bpf_crypto_decrypt() to return -EINVAL for all skcipher
operations.
Should bpf_crypto_skcipher.c be updated in this commit to set
.type_id = BPF_CRYPTO_TYPE_SKCIPHER?
I found that commit 2dad6d96489e ("bpf: Add signature verification kfuncs")
later in the series adds this initialization, but until then existing
skcipher functionality appears broken.
> +
> return bpf_crypto_crypt(ctx, src_kern, dst_kern, siv_kern, true);
> }
>
> @@ -346,9 +361,64 @@ __bpf_kfunc int bpf_crypto_encrypt(struct bpf_crypto_ctx *ctx,
> const struct bpf_dynptr_kern *dst_kern = (struct bpf_dynptr_kern *)dst;
> const struct bpf_dynptr_kern *siv_kern = (struct bpf_dynptr_kern *)siv__nullable;
>
> + if (ctx->type->type_id != BPF_CRYPTO_TYPE_SKCIPHER)
> + return -EINVAL;
Same issue here - bpf_crypto_encrypt() will fail for skcipher contexts
because type_id is uninitialized in bpf_crypto_lskcipher_type.
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/21319193058
Powered by blists - more mailing lists