[PATCH bpf-next v3 0/4] Use correct destructor kfunc types

[PATCH bpf-next v3 0/4] Use correct destructor kfunc types

[Sami Tolvanen]

Hi folks,

While running BPF self-tests with CONFIG_CFI_CLANG (Clang Control
Flow Integrity) enabled, I ran into a couple of CFI failures
in bpf_obj_free_fields() caused by type mismatches between
the btf_dtor_kfunc_t function pointer type and the registered
destructor functions.

It looks like we can't change the argument type for these
functions to match btf_dtor_kfunc_t because the verifier doesn't
like void pointer arguments for functions used in BPF programs,
so this series fixes the issue by adding stubs with correct types
to use as destructors for each instance of this I found in the
kernel tree.

The last patch changes btf_check_dtor_kfuncs() to enforce the
function type when CFI is enabled, so we don't end up registering
destructors that panic the kernel.

Sami

---
v3:
- Renamed the functions and went back to __bpf_kfunc based
  on review feedback.

v2: https://lore.kernel.org/bpf/20250725214401.1475224-6-samitolvanen@google.com/
- Annotated the stubs with CFI_NOSEAL to fix issues with IBT
  sealing on x86.
- Changed __bpf_kfunc to explicit __used __retain.

v1: https://lore.kernel.org/bpf/20250724223225.1481960-6-samitolvanen@google.com/

---
Sami Tolvanen (4):
  bpf: crypto: Use the correct destructor kfunc type
  bpf: net_sched: Use the correct destructor kfunc type
  selftests/bpf: Use the correct destructor kfunc type
  bpf, btf: Enforce destructor kfunc type with CFI

 kernel/bpf/btf.c                                     | 7 +++++++
 kernel/bpf/crypto.c                                  | 8 +++++++-
 net/sched/bpf_qdisc.c                                | 8 +++++++-
 tools/testing/selftests/bpf/test_kmods/bpf_testmod.c | 8 +++++++-
 4 files changed, 28 insertions(+), 3 deletions(-)


base-commit: 5b4c54ac49af7f486806d79e3233fc8a9363961c
-- 
2.50.1.552.g942d659e1b-goog

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

[Sami Tolvanen]

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

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

[Sami Tolvanen]

With CONFIG_CFI_CLANG enabled, the kernel strictly enforces that
indirect function calls use a function pointer type that matches
the target function. As bpf_kfree_skb() signature differs from the
btf_dtor_kfunc_t pointer type used for the destructor calls in
bpf_obj_free_fields(), add a stub function with the correct type to
fix the type mismatch.

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

diff --git a/net/sched/bpf_qdisc.c b/net/sched/bpf_qdisc.c
index adcb618a2bfc..e9bea9890777 100644
--- a/net/sched/bpf_qdisc.c
+++ b/net/sched/bpf_qdisc.c
@@ -202,6 +202,12 @@ __bpf_kfunc void bpf_kfree_skb(struct sk_buff *skb)
 	kfree_skb(skb);
 }
 
+__bpf_kfunc void bpf_kfree_skb_dtor(void *skb)
+{
+	bpf_kfree_skb(skb);
+}
+CFI_NOSEAL(bpf_kfree_skb_dtor);
+
 /* bpf_qdisc_skb_drop - Drop an skb by adding it to a deferred free list.
  * @skb: The skb whose reference to be released and dropped.
  * @to_free_list: The list of skbs to be dropped.
@@ -449,7 +455,7 @@ static struct bpf_struct_ops bpf_Qdisc_ops = {
 	.owner = THIS_MODULE,
 };
 
-BTF_ID_LIST_SINGLE(bpf_sk_buff_dtor_ids, func, bpf_kfree_skb)
+BTF_ID_LIST_SINGLE(bpf_sk_buff_dtor_ids, func, bpf_kfree_skb_dtor)
 
 static int __init bpf_qdisc_kfunc_init(void)
 {
-- 
2.50.1.552.g942d659e1b-goog

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

[Sami Tolvanen]

With CONFIG_CFI_CLANG enabled, the kernel strictly enforces that
indirect function calls use a function pointer type that matches the
target function. As bpf_testmod_ctx_release() signature differs from
the btf_dtor_kfunc_t pointer type used for the destructor calls in
bpf_obj_free_fields(), add a stub function with the correct type to
fix the type mismatch.

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

diff --git a/tools/testing/selftests/bpf/test_kmods/bpf_testmod.c b/tools/testing/selftests/bpf/test_kmods/bpf_testmod.c
index e9e918cdf31f..7f8cd8637a7b 100644
--- a/tools/testing/selftests/bpf/test_kmods/bpf_testmod.c
+++ b/tools/testing/selftests/bpf/test_kmods/bpf_testmod.c
@@ -249,6 +249,12 @@ __bpf_kfunc void bpf_testmod_ctx_release(struct bpf_testmod_ctx *ctx)
 		call_rcu(&ctx->rcu, testmod_free_cb);
 }
 
+__bpf_kfunc void bpf_testmod_ctx_release_dtor(void *ctx)
+{
+	bpf_testmod_ctx_release(ctx);
+}
+CFI_NOSEAL(bpf_testmod_ctx_release_dtor);
+
 static struct bpf_testmod_ops3 *st_ops3;
 
 static int bpf_testmod_test_3(void)
@@ -631,7 +637,7 @@ BTF_KFUNCS_END(bpf_testmod_common_kfunc_ids)
 
 BTF_ID_LIST(bpf_testmod_dtor_ids)
 BTF_ID(struct, bpf_testmod_ctx)
-BTF_ID(func, bpf_testmod_ctx_release)
+BTF_ID(func, bpf_testmod_ctx_release_dtor)
 
 static const struct btf_kfunc_id_set bpf_testmod_common_kfunc_set = {
 	.owner = THIS_MODULE,
-- 
2.50.1.552.g942d659e1b-goog

[PATCH bpf-next v3 4/4] bpf, btf: Enforce destructor kfunc type with CFI

[Sami Tolvanen]

Ensure that registered destructor kfuncs have the same type
as btf_dtor_kfunc_t to avoid a kernel panic on systems with
CONFIG_CFI_CLANG enabled.

Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Acked-by: Yonghong Song <yonghong.song@linux.dev>
---
 kernel/bpf/btf.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
index 0aff814cb53a..2b0ebd46db4a 100644
--- a/kernel/bpf/btf.c
+++ b/kernel/bpf/btf.c
@@ -8856,6 +8856,13 @@ static int btf_check_dtor_kfuncs(struct btf *btf, const struct btf_id_dtor_kfunc
 		 */
 		if (!t || !btf_type_is_ptr(t))
 			return -EINVAL;
+
+		if (IS_ENABLED(CONFIG_CFI_CLANG)) {
+			/* Ensure the destructor kfunc type matches btf_dtor_kfunc_t */
+			t = btf_type_by_id(btf, t->type);
+			if (!btf_type_is_void(t))
+				return -EINVAL;
+		}
 	}
 	return 0;
 }
-- 
2.50.1.552.g942d659e1b-goog

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

[Yonghong Song]

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>

Re: [PATCH bpf-next v3 2/4] bpf: net_sched: Use the correct destructor kfunc type

[Yonghong Song]

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. As bpf_kfree_skb() signature differs from the
> btf_dtor_kfunc_t pointer type used for the destructor calls in
> bpf_obj_free_fields(), add a stub function with the correct type to
> fix the type mismatch.
>
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

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

Re: [PATCH bpf-next v3 3/4] selftests/bpf: Use the correct destructor kfunc type

[Yonghong Song]

On 7/28/25 1:27 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. As bpf_testmod_ctx_release() signature differs from
> the btf_dtor_kfunc_t pointer type used for the destructor calls in
> bpf_obj_free_fields(), add a stub function with the correct type to
> fix the type mismatch.
>
> Signed-off-by: Sami Tolvanen <samitolvanen@google.com>

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

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

[kernel test robot]

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

[Sami Tolvanen]

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

[Viktor Malik]

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

[Sami Tolvanen]

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

[Viktor Malik]

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
>