Re: [PATCH bpf-next v4] bpf: crypto: Use AES-CBC and AES-ECB libraries

["Alexei Starovoitov" <alexei.starovoitov@gmail.com>]

On Wed Sep 23, 2026 at 3:37 AM UTC, sashiko-bot wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] bpf: BPF_CRYPTO is silently disabled if AES libraries are modules
> --
>
> commit 1bcee0286f1c7c6c86befd107081ebb8a0fb0eed
> Author: Eric Biggers <ebiggers@kernel.org>
>
> bpf: crypto: Use AES-CBC and AES-ECB libraries
>
> This commit reimplements BPF crypto using the AES-CBC and AES-ECB library
> APIs instead of the lskcipher API. It adds a new BPF_CRYPTO Kconfig option
> to conditionally compile crypto.c based on the new AES library dependencies.
>
>> diff --git a/kernel/bpf/Kconfig b/kernel/bpf/Kconfig
>> index d7d25477ef481..a44ecfa3e9ef5 100644
>> --- a/kernel/bpf/Kconfig
>> +++ b/kernel/bpf/Kconfig
>> @@ -91,6 +91,15 @@ config BPF_UNPRIV_DEFAULT_OFF
>>  
>>  	  If you are unsure how to answer this question, answer Y.
>>  
>> +config BPF_CRYPTO
>> +	def_bool y
>> +	depends on BPF_SYSCALL
>> +	depends on CRYPTO_LIB_AES_CBC
>> +	depends on CRYPTO_LIB_AES_ECB
>
> [Severity: High]
> Does this dependency logic silently disable BPF_CRYPTO if the AES libraries
> are built as modules?
>
> BPF_CRYPTO is defined as a bool in Kconfig but depends on CRYPTO_LIB_AES_CBC
> and CRYPTO_LIB_AES_ECB, which are tristate symbols. Under Kconfig rules, when
> a bool depends on a tristate that evaluates to m, the dependency evaluates
> to m, which downgrades the bool to n.
>
> Consequently, kernel/bpf/crypto.c might not be compiled, and the crypto
> kfuncs could be silently stripped from the kernel. Existing BPF programs
> using crypto kfuncs will fail to load with "unknown kfunc". Because the AES
> library symbols lack user prompts, users cannot manually fix this by
> explicitly setting them to =y in menuconfig.

The bot is correct. Looks like a regression.