1. Patchew
  2. linux
  3. [PATCH bpf-next v3 0/4] Use correct destructor kfunc types
  4. View patch

[PATCH bpf-next v3 1/4] bpf: crypto: Use the correct destructor kfunc type

Sami Tolvanen posted 4 patches 6 months, 2 weeks ago
There is a newer version of this series
[PATCH bpf-next v3 1/4] bpf: crypto: Use the correct destructor kfunc type
Posted by Sami Tolvanen 6 months, 2 weeks ago 
With CONFIG_CFI_CLANG enabled, the kernel strictly enforces that
indirect function calls use a function pointer type that matches the
target function. I ran into the following type mismatch when running
BPF self-tests:

  CFI failure at bpf_obj_free_fields+0x190/0x238 (target:
    bpf_crypto_ctx_release+0x0/0x94; expected type: 0xa488ebfc)
  Internal error: Oops - CFI: 00000000f2008228 [#1]  SMP
  ...

As bpf_crypto_ctx_release() is also used in BPF programs and using
a void pointer as the argument would make the verifier unhappy, add
a simple stub function with the correct type and register it as the
destructor kfunc instead.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
---
 kernel/bpf/crypto.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/kernel/bpf/crypto.c b/kernel/bpf/crypto.c
index 94854cd9c4cc..a267d9087d40 100644
--- a/kernel/bpf/crypto.c
+++ b/kernel/bpf/crypto.c
@@ -261,6 +261,12 @@ __bpf_kfunc void bpf_crypto_ctx_release(struct bpf_crypto_ctx *ctx)
 		call_rcu(&ctx->rcu, crypto_free_cb);
 }
 
+__bpf_kfunc void bpf_crypto_ctx_release_dtor(void *ctx)
+{
+	bpf_crypto_ctx_release(ctx);
+}
+CFI_NOSEAL(bpf_crypto_ctx_release_dtor);
+
 static int bpf_crypto_crypt(const struct bpf_crypto_ctx *ctx,
 			    const struct bpf_dynptr_kern *src,
 			    const struct bpf_dynptr_kern *dst,
@@ -368,7 +374,7 @@ static const struct btf_kfunc_id_set crypt_kfunc_set = {
 
 BTF_ID_LIST(bpf_crypto_dtor_ids)
 BTF_ID(struct, bpf_crypto_ctx)
-BTF_ID(func, bpf_crypto_ctx_release)
+BTF_ID(func, bpf_crypto_ctx_release_dtor)
 
 static int __init crypto_kfunc_init(void)
 {
-- 
2.50.1.552.g942d659e1b-goog
Re: [PATCH bpf-next v3 1/4] bpf: crypto: Use the correct destructor kfunc type
Posted by Viktor Malik 2 months, 2 weeks ago 
On 7/28/25 22:26, Sami Tolvanen wrote:
> With CONFIG_CFI_CLANG enabled, the kernel strictly enforces that
> indirect function calls use a function pointer type that matches the
> target function. I ran into the following type mismatch when running
> BPF self-tests:
> 
>   CFI failure at bpf_obj_free_fields+0x190/0x238 (target:
>     bpf_crypto_ctx_release+0x0/0x94; expected type: 0xa488ebfc)
>   Internal error: Oops - CFI: 00000000f2008228 [#1]  SMP
>   ...
> 
> As bpf_crypto_ctx_release() is also used in BPF programs and using
> a void pointer as the argument would make the verifier unhappy, add
> a simple stub function with the correct type and register it as the
> destructor kfunc instead.

Hi,

this patchset got somehow forgotten and I'd like to revive it.

We're hitting kernel oops when running the crypto cases from test_progs
(`./test_progs -t crypto`) on CPUs with IBT (Indirect Branch Tracking)
support. I managed to reproduce this on the latest bpf-next, see the
relevant part of dmesg at the end of this email.

After applying this patch, the oops no longer happens.

It looks like the series is stuck on a sparse warning reported by kernel
test robot, which seems like a false positive. Could we somehow resolve
it and proceed with reviewing and merging this?

Since this resolves our issue, adding my tested-by:

Tested-by: Viktor Malik <vmalik@redhat.com>

Thanks!
Viktor

The relevant part of dmesg:

    [ 1505.054762] Missing ENDBR: bpf_crypto_ctx_release+0x0/0x50 
    [ 1505.060306] ------------[ cut here ]------------ 
    [ 1505.064971] kernel BUG at arch/x86/kernel/cet.c:133! 
    [ 1505.069984] Oops: invalid opcode: 0000 [#1] SMP NOPTI 
    [ 1505.075085] CPU: 129 UID: 0 PID: 42861 Comm: kworker/u688:24 Tainted: G           OE       6.18.0-rc5+ #3 PREEMPT(voluntary)  
    [ 1505.086437] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE 
    [ 1505.091794] Hardware name: Intel Corporation GNR-WS/GNR-WS, BIOS GWS_REL1.IPC.3663.P19.2506271437 06/27/2025 
    [ 1505.101674] Workqueue: events_unbound bpf_map_free_deferred 
    [ 1505.107291] RIP: 0010:exc_control_protection+0x19a/0x1a0 
    [ 1505.112648] Code: d8 b9 09 00 00 00 48 8b 93 80 00 00 00 be 81 00 00 00 48 c7 c7 53 09 b2 a0 e8 c2 74 1c ff 80 a3 8a 00 00 00 fb e9 fb fe ff ff <0f> 0b 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 
    [ 1505.131474] RSP: 0018:ff714c596fe17ce8 EFLAGS: 00010002 
    [ 1505.136742] RAX: 000000000000002e RBX: ff714c596fe17d08 RCX: 0000000000000000 
    [ 1505.143924] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ff2a470fbe458240 
    [ 1505.151111] RBP: 0000000000000003 R08: 0000000000000000 R09: ff714c596fe17b70 
    [ 1505.158293] R10: ff2a470fbc07ffa8 R11: 0000000000000003 R12: 0000000000000000 
    [ 1505.165478] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 
    [ 1505.172661] FS:  0000000000000000(0000) GS:ff2a47101c091000(0000) knlGS:0000000000000000 
    [ 1505.180805] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 
    [ 1505.186600] CR2: 00005564968dd250 CR3: 0000001e45a22005 CR4: 0000000000f73ef0 
    [ 1505.193782] PKRU: 55555554 
    [ 1505.196533] Call Trace: 
    [ 1505.199026]  <TASK> 
    [ 1505.201171]  asm_exc_control_protection+0x26/0x60 
    [ 1505.205923] RIP: 0010:bpf_crypto_ctx_release+0x0/0x50 
    [ 1505.211023] Code: 00 eb ee 89 c2 eb d7 31 c0 5b c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 <0f> 1f 40 d6 0f 1f 44 00 00 48 8d 57 28 b8 ff ff ff ff f0 0f c1 47 
    [ 1505.229849] RSP: 0018:ff714c596fe17db8 EFLAGS: 00010202 
    [ 1505.235118] RAX: ffffffff9f7917d0 RBX: ff2a46f0ce98cc20 RCX: 000000008200019e 
    [ 1505.242301] RDX: 0000000000000001 RSI: ff2a46f0dd55ff30 RDI: ff2a46f0e8662280 
    [ 1505.249483] RBP: ff2a46f0ce98cc20 R08: 0000000000000000 R09: 0000000000000001 
    [ 1505.256666] R10: 000000008200019e R11: ff2a46f0c5573bc8 R12: 0000000000000000 
    [ 1505.263849] R13: ff2a46f0ce98cc00 R14: ff2a46f0dd55ff30 R15: ff2a46f0e8662280 
    [ 1505.271035]  ? __pfx_bpf_crypto_ctx_release+0x10/0x10 
    [ 1505.276135]  bpf_obj_free_fields+0x10c/0x230 
    [ 1505.280451]  array_map_free+0x56/0x140 
    [ 1505.284243]  bpf_map_free_deferred+0x95/0x180 
    [ 1505.288646]  process_one_work+0x18b/0x340 
    [ 1505.292705]  worker_thread+0x256/0x3a0 
    [ 1505.296497]  ? __pfx_worker_thread+0x10/0x10 
    [ 1505.300813]  kthread+0xfc/0x240 
    [ 1505.304000]  ? __pfx_kthread+0x10/0x10 
    [ 1505.307792]  ? __pfx_kthread+0x10/0x10 
    [ 1505.311584]  ret_from_fork+0xf0/0x110 
    [ 1505.315297]  ? __pfx_kthread+0x10/0x10 
    [ 1505.319089]  ret_from_fork_asm+0x1a/0x30 
    [ 1505.323059]  </TASK> 

> 
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
> ---
>  kernel/bpf/crypto.c | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/bpf/crypto.c b/kernel/bpf/crypto.c
> index 94854cd9c4cc..a267d9087d40 100644
> --- a/kernel/bpf/crypto.c
> +++ b/kernel/bpf/crypto.c
> @@ -261,6 +261,12 @@ __bpf_kfunc void bpf_crypto_ctx_release(struct bpf_crypto_ctx *ctx)
>  		call_rcu(&ctx->rcu, crypto_free_cb);
>  }
>  
> +__bpf_kfunc void bpf_crypto_ctx_release_dtor(void *ctx)
> +{
> +	bpf_crypto_ctx_release(ctx);
> +}
> +CFI_NOSEAL(bpf_crypto_ctx_release_dtor);
> +
>  static int bpf_crypto_crypt(const struct bpf_crypto_ctx *ctx,
>  			    const struct bpf_dynptr_kern *src,
>  			    const struct bpf_dynptr_kern *dst,
> @@ -368,7 +374,7 @@ static const struct btf_kfunc_id_set crypt_kfunc_set = {
>  
>  BTF_ID_LIST(bpf_crypto_dtor_ids)
>  BTF_ID(struct, bpf_crypto_ctx)
> -BTF_ID(func, bpf_crypto_ctx_release)
> +BTF_ID(func, bpf_crypto_ctx_release_dtor)
>  
>  static int __init crypto_kfunc_init(void)
>  {
Re: [PATCH bpf-next v3 1/4] bpf: crypto: Use the correct destructor kfunc type
Posted by Sami Tolvanen 2 months, 2 weeks ago 
Hi Viktor,

On Fri, Nov 21, 2025 at 8:06 AM Viktor Malik <vmalik@redhat.com> wrote:
>
> On 7/28/25 22:26, Sami Tolvanen wrote:
> > With CONFIG_CFI_CLANG enabled, the kernel strictly enforces that
> > indirect function calls use a function pointer type that matches the
> > target function. I ran into the following type mismatch when running
> > BPF self-tests:
> >
> >   CFI failure at bpf_obj_free_fields+0x190/0x238 (target:
> >     bpf_crypto_ctx_release+0x0/0x94; expected type: 0xa488ebfc)
> >   Internal error: Oops - CFI: 00000000f2008228 [#1]  SMP
> >   ...
> >
> > As bpf_crypto_ctx_release() is also used in BPF programs and using
> > a void pointer as the argument would make the verifier unhappy, add
> > a simple stub function with the correct type and register it as the
> > destructor kfunc instead.
>
> Hi,
>
> this patchset got somehow forgotten and I'd like to revive it.
>
> We're hitting kernel oops when running the crypto cases from test_progs
> (`./test_progs -t crypto`) on CPUs with IBT (Indirect Branch Tracking)
> support. I managed to reproduce this on the latest bpf-next, see the
> relevant part of dmesg at the end of this email.
>
> After applying this patch, the oops no longer happens.
>
> It looks like the series is stuck on a sparse warning reported by kernel
> test robot, which seems like a false positive. Could we somehow resolve
> it and proceed with reviewing and merging this?

I agree, it does look like a false positive.

> Since this resolves our issue, adding my tested-by:
>
> Tested-by: Viktor Malik <vmalik@redhat.com>

Thanks for testing! I can resend this series when I have a chance to
put it back in the review queue. The CFI config option also changed
from CONFIG_CFI_CLANG to just CONFIG_CFI since this was sent, so the
commit message could use an update too.

Sami
Re: [PATCH bpf-next v3 1/4] bpf: crypto: Use the correct destructor kfunc type
Posted by Viktor Malik 2 months, 2 weeks ago 
On 11/25/25 21:16, Sami Tolvanen wrote:
> Hi Viktor,
> 
> On Fri, Nov 21, 2025 at 8:06 AM Viktor Malik <vmalik@redhat.com> wrote:
>>
>> On 7/28/25 22:26, Sami Tolvanen wrote:
>>> With CONFIG_CFI_CLANG enabled, the kernel strictly enforces that
>>> indirect function calls use a function pointer type that matches the
>>> target function. I ran into the following type mismatch when running
>>> BPF self-tests:
>>>
>>>   CFI failure at bpf_obj_free_fields+0x190/0x238 (target:
>>>     bpf_crypto_ctx_release+0x0/0x94; expected type: 0xa488ebfc)
>>>   Internal error: Oops - CFI: 00000000f2008228 [#1]  SMP
>>>   ...
>>>
>>> As bpf_crypto_ctx_release() is also used in BPF programs and using
>>> a void pointer as the argument would make the verifier unhappy, add
>>> a simple stub function with the correct type and register it as the
>>> destructor kfunc instead.
>>
>> Hi,
>>
>> this patchset got somehow forgotten and I'd like to revive it.
>>
>> We're hitting kernel oops when running the crypto cases from test_progs
>> (`./test_progs -t crypto`) on CPUs with IBT (Indirect Branch Tracking)
>> support. I managed to reproduce this on the latest bpf-next, see the
>> relevant part of dmesg at the end of this email.
>>
>> After applying this patch, the oops no longer happens.
>>
>> It looks like the series is stuck on a sparse warning reported by kernel
>> test robot, which seems like a false positive. Could we somehow resolve
>> it and proceed with reviewing and merging this?
> 
> I agree, it does look like a false positive.
> 
>> Since this resolves our issue, adding my tested-by:
>>
>> Tested-by: Viktor Malik <vmalik@redhat.com>
> 
> Thanks for testing! I can resend this series when I have a chance to
> put it back in the review queue. The CFI config option also changed
> from CONFIG_CFI_CLANG to just CONFIG_CFI since this was sent, so the
> commit message could use an update too.

That would be very useful, thanks Sami!

Viktor

> 
> Sami
>
Re: [PATCH bpf-next v3 1/4] bpf: crypto: Use the correct destructor kfunc type
Posted by kernel test robot 6 months, 2 weeks ago 
Hi Sami,

kernel test robot noticed the following build warnings:

[auto build test WARNING on 5b4c54ac49af7f486806d79e3233fc8a9363961c]

url:    https://github.com/intel-lab-lkp/linux/commits/Sami-Tolvanen/bpf-crypto-Use-the-correct-destructor-kfunc-type/20250729-042936
base:   5b4c54ac49af7f486806d79e3233fc8a9363961c
patch link:    https://lore.kernel.org/r/20250728202656.559071-7-samitolvanen%40google.com
patch subject: [PATCH bpf-next v3 1/4] bpf: crypto: Use the correct destructor kfunc type
config: alpha-randconfig-r111-20250729 (https://download.01.org/0day-ci/archive/20250730/202507300122.RpqIKqFR-lkp@intel.com/config)
compiler: alpha-linux-gcc (GCC) 8.5.0
reproduce: (https://download.01.org/0day-ci/archive/20250730/202507300122.RpqIKqFR-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202507300122.RpqIKqFR-lkp@intel.com/

sparse warnings: (new ones prefixed by >>)
>> kernel/bpf/crypto.c:264:18: sparse: sparse: symbol 'bpf_crypto_ctx_release_dtor' was not declared. Should it be static?

vim +/bpf_crypto_ctx_release_dtor +264 kernel/bpf/crypto.c

   263	
 > 264	__bpf_kfunc void bpf_crypto_ctx_release_dtor(void *ctx)
   265	{
   266		bpf_crypto_ctx_release(ctx);
   267	}
   268	CFI_NOSEAL(bpf_crypto_ctx_release_dtor);
   269	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
Re: [PATCH bpf-next v3 1/4] bpf: crypto: Use the correct destructor kfunc type
Posted by Sami Tolvanen 6 months, 2 weeks ago 
On Tue, Jul 29, 2025 at 10:54 AM kernel test robot <lkp@intel.com> wrote:
>
> Hi Sami,
>
> kernel test robot noticed the following build warnings:
>
> [auto build test WARNING on 5b4c54ac49af7f486806d79e3233fc8a9363961c]
>
> url:    https://github.com/intel-lab-lkp/linux/commits/Sami-Tolvanen/bpf-crypto-Use-the-correct-destructor-kfunc-type/20250729-042936
> base:   5b4c54ac49af7f486806d79e3233fc8a9363961c
> patch link:    https://lore.kernel.org/r/20250728202656.559071-7-samitolvanen%40google.com
> patch subject: [PATCH bpf-next v3 1/4] bpf: crypto: Use the correct destructor kfunc type
> config: alpha-randconfig-r111-20250729 (https://download.01.org/0day-ci/archive/20250730/202507300122.RpqIKqFR-lkp@intel.com/config)
> compiler: alpha-linux-gcc (GCC) 8.5.0
> reproduce: (https://download.01.org/0day-ci/archive/20250730/202507300122.RpqIKqFR-lkp@intel.com/reproduce)
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202507300122.RpqIKqFR-lkp@intel.com/
>
> sparse warnings: (new ones prefixed by >>)
> >> kernel/bpf/crypto.c:264:18: sparse: sparse: symbol 'bpf_crypto_ctx_release_dtor' was not declared. Should it be static?
>
> vim +/bpf_crypto_ctx_release_dtor +264 kernel/bpf/crypto.c
>
>    263
>  > 264  __bpf_kfunc void bpf_crypto_ctx_release_dtor(void *ctx)
>    265  {
>    266          bpf_crypto_ctx_release(ctx);
>    267  }
>    268  CFI_NOSEAL(bpf_crypto_ctx_release_dtor);
>    269

__bpf_kfunc_start_defs() disables -Wmissing-declarations here, but I
assume sparse doesn't care about that. Is there something we can do to
teach it about this?

Sami
Re: [PATCH bpf-next v3 1/4] bpf: crypto: Use the correct destructor kfunc type
Posted by Yonghong Song 6 months, 2 weeks ago 

On 7/28/25 1:26 PM, Sami Tolvanen wrote:
> With CONFIG_CFI_CLANG enabled, the kernel strictly enforces that
> indirect function calls use a function pointer type that matches the
> target function. I ran into the following type mismatch when running
> BPF self-tests:
>
>    CFI failure at bpf_obj_free_fields+0x190/0x238 (target:
>      bpf_crypto_ctx_release+0x0/0x94; expected type: 0xa488ebfc)
>    Internal error: Oops - CFI: 00000000f2008228 [#1]  SMP
>    ...
>
> As bpf_crypto_ctx_release() is also used in BPF programs and using
> a void pointer as the argument would make the verifier unhappy, add
> a simple stub function with the correct type and register it as the
> destructor kfunc instead.
>
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

Acked-by: Yonghong Song <yonghong.song@linux.dev>

Patchew 2.1-devel-b67e4c2

© 2016 - 2026 Red Hat, Inc.