[PATCH bpf-next v2 0/2] bpf: bound rdonly/rdwr_buf_size kfunc return size

[PATCH bpf-next v2 0/2] bpf: bound rdonly/rdwr_buf_size kfunc return size

[Nicholas Dudar]

check_kfunc_args() stores a kfunc's rdonly_buf_size/rdwr_buf_size
argument into a u64 that check_kfunc_call() later narrows into the
returned register's u32 mem_size, so a value above U32_MAX truncates
instead of being rejected. Fix it and add a selftest for coverage.

Changelog:
----------
v1 -> v2 (v1 was a private report to security@kernel.org)

 * Split the fix and selftest into separate patches.
 * Target bpf-next instead of bpf.

Nicholas Dudar (2):
  bpf: reject rdonly/rdwr_buf_size kfunc arguments that exceed u32 max
  selftests/bpf: add test for oversized rdonly/rdwr_buf_size kfunc
    argument

 kernel/bpf/verifier.c                         |  5 +++
 .../selftests/bpf/prog_tests/kfunc_call.c     |  1 +
 .../selftests/bpf/progs/kfunc_call_fail.c     | 33 +++++++++++++++++++
 3 files changed, 39 insertions(+)


base-commit: 36ffa86c42f91c8a57071e024afc4ffb51a8958f
-- 
2.34.1

[PATCH bpf-next v2 1/2] bpf: reject rdonly/rdwr_buf_size kfunc arguments that exceed u32 max

[Nicholas Dudar]

check_kfunc_args() detects a kfunc argument named rdonly_buf_size or
rdwr_buf_size and stores reg->var_off.value into meta->r0_size, a u64,
and does not bound it. check_kfunc_call() later copies that value into
the returned register's mem_size field:

  meta->r0_size = reg->var_off.value;
  ...
  regs[BPF_REG_0].mem_size = meta.r0_size;

regs[BPF_REG_0].mem_size is u32. A constant whose upper 32 bits are
set, such as 2^64 - 192, truncates to 0xffffff40 instead of causing a
load-time rejection, so the verifier records a PTR_TO_MEM register
with an approximately 4 GiB mem_size for whatever allocation the kfunc
returned. A later access check against that register uses the
truncated, wrong bound.

check_kfunc_args() is the site that stores this value for kfuncs that
declare an rdonly_buf_size or rdwr_buf_size argument.
hid_bpf_get_data() (drivers/hid/bpf/hid_bpf_dispatch.c) takes an
rdwr_buf_size argument this way and is reachable from a
BPF_PROG_TYPE_STRUCT_OPS HID-BPF program; io_uring/bpf-ops.c:26,47
declares one as well. The fix belongs at check_kfunc_args(), the
truncation site. The kfunc's runtime check still guards its allocation
bound, but it should not have to defend against a size the verifier
already mis-recorded.

bpf_obj_new refuses a local type ID that does not fit u32
(check_special_kfunc()). check_kfunc_args() does not bound the
rdonly_buf_size/rdwr_buf_size value that feeds mem_size.

Reject rdonly_buf_size/rdwr_buf_size values that exceed U32_MAX at the
point meta->r0_size is set, ahead of mark_chain_precision() and the
later PTR_TO_MEM assignment. The preceding tnum_is_const() check
already requires the argument to be a known constant, so
reg->var_off.value is the exact size and rejecting it is sound. U32_MAX
is the minimal bound that keeps the recorded mem_size within the u32
field; a tighter semantic maximum is out of scope.

Fixes: eb1f7f71c126 ("bpf/verifier: allow kfunc to return an allocated mem")
Signed-off-by: Nicholas Dudar <main.kalliope@gmail.com>
Assisted-by: Claude:claude-opus-4-8
---
 kernel/bpf/verifier.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 233472a871be..c7fabe50e487 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -12097,6 +12097,11 @@ static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_kfunc_call_
 				}
 
 				meta->r0_size = reg->var_off.value;
+				if (meta->r0_size > U32_MAX) {
+					verbose(env, "%s rdonly/rdwr_buf_size exceeds u32 max\n",
+						reg_arg_name(env, argno));
+					return -EINVAL;
+				}
 				if (regno >= 0)
 					ret = mark_chain_precision(env, regno);
 				else
-- 
2.34.1

[PATCH bpf-next v2 2/2] selftests/bpf: add test for oversized rdonly/rdwr_buf_size kfunc argument

[Nicholas Dudar]

Add a load-failure test to the kfunc_call suite using the existing
bpf_kfunc_call_test_get_rdwr_mem() test kfunc. Its rdwr_buf_size
argument is a const int, so the test uses a 64-bit immediate load in
inline asm to place 2^64 - 192 (0xffffffffffffff40) in the argument
register. The verifier records r0_size from the full 64-bit register
value, and the test asserts that BPF_PROG_LOAD rejects it with
"rdonly/rdwr_buf_size exceeds u32 max".

Signed-off-by: Nicholas Dudar <main.kalliope@gmail.com>
Assisted-by: Claude:claude-opus-4-8
---
 .../selftests/bpf/prog_tests/kfunc_call.c     |  1 +
 .../selftests/bpf/progs/kfunc_call_fail.c     | 33 +++++++++++++++++++
 2 files changed, 34 insertions(+)

diff --git a/tools/testing/selftests/bpf/prog_tests/kfunc_call.c b/tools/testing/selftests/bpf/prog_tests/kfunc_call.c
index 3df07680f9e0..67a30bf69509 100644
--- a/tools/testing/selftests/bpf/prog_tests/kfunc_call.c
+++ b/tools/testing/selftests/bpf/prog_tests/kfunc_call.c
@@ -66,6 +66,7 @@ static struct kfunc_test_params kfunc_tests[] = {
 	TC_FAIL(kfunc_call_test_get_mem_fail_rdonly, 0, "R0 cannot write into rdonly_mem"),
 	TC_FAIL(kfunc_call_test_get_mem_fail_use_after_free, 0, "invalid mem access 'scalar'"),
 	TC_FAIL(kfunc_call_test_get_mem_fail_oob, 0, "min value is outside of the allowed memory range"),
+	TC_FAIL(kfunc_call_test_get_mem_fail_oversized, 0, "rdonly/rdwr_buf_size exceeds u32 max"),
 	TC_FAIL(kfunc_call_test_get_mem_fail_not_const, 0, "is not a const"),
 	TC_FAIL(kfunc_call_test_mem_acquire_fail, 0, "acquire kernel function does not return PTR_TO_BTF_ID"),
 	TC_FAIL(kfunc_call_test_pointer_arg_type_mismatch, 0, "R1 expected pointer to ctx, but got scalar"),
diff --git a/tools/testing/selftests/bpf/progs/kfunc_call_fail.c b/tools/testing/selftests/bpf/progs/kfunc_call_fail.c
index a1963497f0bf..6144ce3ff0b2 100644
--- a/tools/testing/selftests/bpf/progs/kfunc_call_fail.c
+++ b/tools/testing/selftests/bpf/progs/kfunc_call_fail.c
@@ -103,6 +103,39 @@ int kfunc_call_test_get_mem_fail_oob(struct __sk_buff *skb)
 	return ret;
 }
 
+SEC("?tc")
+int kfunc_call_test_get_mem_fail_oversized(struct __sk_buff *skb)
+{
+	struct prog_test_ref_kfunc *pt;
+	unsigned long s = 0;
+	int *p = NULL;
+	int ret = 0;
+
+	pt = bpf_kfunc_call_test_acquire(&s);
+	if (pt) {
+		/*
+		 * rdwr_buf_size is a const int, so a C literal is narrowed to
+		 * 32 bits before the call. Force the full 64-bit value 2^64 - 192
+		 * (0xffffffffffffff40, > U32_MAX) into the argument register with
+		 * a 64-bit immediate load. The verifier records r0_size from the
+		 * full register value and must reject it before that value is
+		 * truncated into R0's u32 mem_size.
+		 */
+		asm volatile (
+			"r1 = %[pt];"
+			"r2 = %[oversized] ll;"
+			"call %[get_rdwr_mem];"
+			"%[p] = r0;"
+			: [p] "=r"(p)
+			: [pt] "r"(pt),
+			  [oversized] "i"(0xffffffffffffff40LL),
+			  [get_rdwr_mem] "i"(bpf_kfunc_call_test_get_rdwr_mem)
+			: "r0", "r1", "r2", "r3", "r4", "r5");
+		bpf_kfunc_call_test_release(pt);
+	}
+	return ret;
+}
+
 int not_const_size = 2 * sizeof(int);
 
 SEC("?tc")
-- 
2.34.1

Re: [PATCH bpf-next v2 1/2] bpf: reject rdonly/rdwr_buf_size kfunc arguments that exceed u32 max

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] 32-bit integer overflow in `hid_bpf_get_data()` allows arbitrary out-of-bounds kernel memory access.
- [High] Explicit 0-sized requests to kfuncs result in out-of-bounds read due to verifier BTF fallback.
--

--- Patch [1]: [PATCH bpf-next v2 1/2] bpf: reject rdonly/rdwr_buf_size kfunc arguments that exceed u32 max ---
commit 440bc8eb1e0c84aa93160b0ebdb9ef4731dce2ea
Author: Nicholas Dudar <main.kalliope@gmail.com>

bpf: reject rdonly/rdwr_buf_size kfunc arguments that exceed u32 max

This commit fixes a truncation issue where a 64-bit size argument was
incorrectly truncated into a 32-bit field without a bounds check. It rejects
sizes that exceed U32_MAX in check_kfunc_args() before assigning to the
PTR_TO_MEM register.

> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 233472a871be5..c7fabe50e4874 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -12097,6 +12097,11 @@ static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_kfunc_call_
>  				}
>  
>  				meta->r0_size = reg->var_off.value;

[Severity: High]
This is a pre-existing issue, but how does the verifier handle an explicit
0-sized buffer request here?

If a BPF program calls hid_bpf_get_data() with rdwr_buf_size = 0 and
offset = ctx->allocated_size, the bounds check passes:

drivers/hid/bpf/hid_bpf_dispatch.c:hid_bpf_get_data()
    if (rdwr_buf_size + offset > ctx->allocated_size)
        return NULL;

The function legally returns a pointer exactly at the end of the buffer.
However, in check_kfunc_call(), the verifier seems to misinterpret an
explicit 0 size as an absent size:

kernel/bpf/verifier.c:check_kfunc_call()
    if (!meta.r0_size) {
        __u32 sz;
        if (!IS_ERR(btf_resolve_size(desc_btf, ptr_type, &sz))) {
            meta.r0_size = sz;
            meta.r0_rdonly = true;
        }
    }

Does this fall back to the BTF type size (1 byte for __u8 *) and incorrectly
grant a 1-byte read permission from the out-of-bounds pointer?

> +				if (meta->r0_size > U32_MAX) {

[Severity: High]
This is a pre-existing issue, but does allowing the size to reach U32_MAX
expose a 32-bit integer overflow in hid_bpf_get_data()?

If a BPF program calls hid_bpf_get_data() with rdwr_buf_size = U32_MAX and
offset = 1, on 32-bit architectures size_t is 32 bits. This would cause the
addition to wrap around to 0:

drivers/hid/bpf/hid_bpf_dispatch.c:hid_bpf_get_data()
    if (rdwr_buf_size + offset > ctx->allocated_size)
        return NULL;

This bypasses the bounds check and returns a pointer to data + 1. Since the
verifier records the returned register's mem_size as U32_MAX, does this
allow arbitrary out-of-bounds read/write access to kernel memory?

> +					verbose(env, "%s rdonly/rdwr_buf_size exceeds u32 max\n",
> +						reg_arg_name(env, argno));
> +					return -EINVAL;
> +				}
>  				if (regno >= 0)
>  					ret = mark_chain_precision(env, regno);
>  				else

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260709155837.1879230-1-main.kalliope@gmail.com?part=1

Re: [PATCH bpf-next v2 1/2] bpf: reject rdonly/rdwr_buf_size kfunc arguments that exceed u32 max

[Amery Hung]

On Thu, Jul 9, 2026 at 9:22 AM <sashiko-bot@kernel.org> wrote:
>
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
>
> Pre-existing issues:
> - [High] 32-bit integer overflow in `hid_bpf_get_data()` allows arbitrary out-of-bounds kernel memory access.
> - [High] Explicit 0-sized requests to kfuncs result in out-of-bounds read due to verifier BTF fallback.

I also noticed the second preexisting issue when working on a patchset
unifying helper and kfunc handling. The patchset will fix it.

> --
>
> --- Patch [1]: [PATCH bpf-next v2 1/2] bpf: reject rdonly/rdwr_buf_size kfunc arguments that exceed u32 max ---
> commit 440bc8eb1e0c84aa93160b0ebdb9ef4731dce2ea
> Author: Nicholas Dudar <main.kalliope@gmail.com>
>
> bpf: reject rdonly/rdwr_buf_size kfunc arguments that exceed u32 max
>
> This commit fixes a truncation issue where a 64-bit size argument was
> incorrectly truncated into a 32-bit field without a bounds check. It rejects
> sizes that exceed U32_MAX in check_kfunc_args() before assigning to the
> PTR_TO_MEM register.
>
> > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > index 233472a871be5..c7fabe50e4874 100644
> > --- a/kernel/bpf/verifier.c
> > +++ b/kernel/bpf/verifier.c
> > @@ -12097,6 +12097,11 @@ static int check_kfunc_args(struct bpf_verifier_env *env, struct bpf_kfunc_call_
> >                               }
> >
> >                               meta->r0_size = reg->var_off.value;
>
> [Severity: High]
> This is a pre-existing issue, but how does the verifier handle an explicit
> 0-sized buffer request here?
>
> If a BPF program calls hid_bpf_get_data() with rdwr_buf_size = 0 and
> offset = ctx->allocated_size, the bounds check passes:
>
> drivers/hid/bpf/hid_bpf_dispatch.c:hid_bpf_get_data()
>     if (rdwr_buf_size + offset > ctx->allocated_size)
>         return NULL;
>
> The function legally returns a pointer exactly at the end of the buffer.
> However, in check_kfunc_call(), the verifier seems to misinterpret an
> explicit 0 size as an absent size:
>
> kernel/bpf/verifier.c:check_kfunc_call()
>     if (!meta.r0_size) {
>         __u32 sz;
>         if (!IS_ERR(btf_resolve_size(desc_btf, ptr_type, &sz))) {
>             meta.r0_size = sz;
>             meta.r0_rdonly = true;
>         }
>     }
>
> Does this fall back to the BTF type size (1 byte for __u8 *) and incorrectly
> grant a 1-byte read permission from the out-of-bounds pointer?
>
> > +                             if (meta->r0_size > U32_MAX) {
>
> [Severity: High]
> This is a pre-existing issue, but does allowing the size to reach U32_MAX
> expose a 32-bit integer overflow in hid_bpf_get_data()?
>
> If a BPF program calls hid_bpf_get_data() with rdwr_buf_size = U32_MAX and
> offset = 1, on 32-bit architectures size_t is 32 bits. This would cause the
> addition to wrap around to 0:
>
> drivers/hid/bpf/hid_bpf_dispatch.c:hid_bpf_get_data()
>     if (rdwr_buf_size + offset > ctx->allocated_size)
>         return NULL;
>
> This bypasses the bounds check and returns a pointer to data + 1. Since the
> verifier records the returned register's mem_size as U32_MAX, does this
> allow arbitrary out-of-bounds read/write access to kernel memory?
>
> > +                                     verbose(env, "%s rdonly/rdwr_buf_size exceeds u32 max\n",
> > +                                             reg_arg_name(env, argno));
> > +                                     return -EINVAL;
> > +                             }
> >                               if (regno >= 0)
> >                                       ret = mark_chain_precision(env, regno);
> >                               else
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260709155837.1879230-1-main.kalliope@gmail.com?part=1
>

Re: [PATCH bpf-next v2 1/2] bpf: reject rdonly/rdwr_buf_size kfunc arguments that exceed u32 max

[Eduard Zingerman]

On Thu, 2026-07-09 at 11:58 -0400, Nicholas Dudar wrote:

Hi Nicholas,

Thank you for the patch. This patch-set lgtm, but please try to make
commit messages more concise in future submissions. E.g. for this one
Claude added a completely unnecessary amount of details.

> check_kfunc_args() detects a kfunc argument named rdonly_buf_size or
> rdwr_buf_size and stores reg->var_off.value into meta->r0_size, a u64,
> and does not bound it. check_kfunc_call() later copies that value into
> the returned register's mem_size field:
> 
>   meta->r0_size = reg->var_off.value;
>   ...
>   regs[BPF_REG_0].mem_size = meta.r0_size;
> 
> regs[BPF_REG_0].mem_size is u32. A constant whose upper 32 bits are
> set, such as 2^64 - 192, truncates to 0xffffff40 instead of causing a

Nit: reference to a specific constant is misleading here.

> load-time rejection, so the verifier records a PTR_TO_MEM register
> with an approximately 4 GiB mem_size for whatever allocation the kfunc
> returned. A later access check against that register uses the
> truncated, wrong bound.
> 
> check_kfunc_args() is the site that stores this value for kfuncs that
> declare an rdonly_buf_size or rdwr_buf_size argument.
> hid_bpf_get_data() (drivers/hid/bpf/hid_bpf_dispatch.c) takes an
> rdwr_buf_size argument this way and is reachable from a
> BPF_PROG_TYPE_STRUCT_OPS HID-BPF program; io_uring/bpf-ops.c:26,47
> declares one as well. The fix belongs at check_kfunc_args(), the
> truncation site. The kfunc's runtime check still guards its allocation
> bound, but it should not have to defend against a size the verifier
> already mis-recorded.
> 
> bpf_obj_new refuses a local type ID that does not fit u32
> (check_special_kfunc()). check_kfunc_args() does not bound the
> rdonly_buf_size/rdwr_buf_size value that feeds mem_size.

Nit: the above two paragraphs are not necessary.

> Reject rdonly_buf_size/rdwr_buf_size values that exceed U32_MAX at the
> point meta->r0_size is set,

Nit: the below paragraph is not necessary.

> ahead of mark_chain_precision() and the
> later PTR_TO_MEM assignment. The preceding tnum_is_const() check
> already requires the argument to be a known constant, so
> reg->var_off.value is the exact size and rejecting it is sound. U32_MAX
> is the minimal bound that keeps the recorded mem_size within the u32
> field; a tighter semantic maximum is out of scope.
> 
> Fixes: eb1f7f71c126 ("bpf/verifier: allow kfunc to return an allocated mem")
> Signed-off-by: Nicholas Dudar <main.kalliope@gmail.com>
> Assisted-by: Claude:claude-opus-4-8
> ---

Acked-by: Eduard Zingerman <eddyz87@gmail.com>

[...]

Re: [PATCH bpf-next v2 2/2] selftests/bpf: add test for oversized rdonly/rdwr_buf_size kfunc argument

[Eduard Zingerman]

On Thu, 2026-07-09 at 11:58 -0400, Nicholas Dudar wrote:
> Add a load-failure test to the kfunc_call suite using the existing
> bpf_kfunc_call_test_get_rdwr_mem() test kfunc. Its rdwr_buf_size
> argument is a const int, so the test uses a 64-bit immediate load in
> inline asm to place 2^64 - 192 (0xffffffffffffff40) in the argument
> register. The verifier records r0_size from the full 64-bit register
> value, and the test asserts that BPF_PROG_LOAD rejects it with
> "rdonly/rdwr_buf_size exceeds u32 max".
> 
> Signed-off-by: Nicholas Dudar <main.kalliope@gmail.com>
> Assisted-by: Claude:claude-opus-4-8
> ---

Acked-by: Eduard Zingerman <eddyz87@gmail.com>

[...]

Re: [PATCH bpf-next v2 1/2] bpf: reject rdonly/rdwr_buf_size kfunc arguments that exceed u32 max

[Kumar Kartikeya Dwivedi]

On Thu Jul 9, 2026 at 10:01 PM CEST, Amery Hung wrote:
> On Thu, Jul 9, 2026 at 9:22 AM <sashiko-bot@kernel.org> wrote:
>>
>> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
>>
>> Pre-existing issues:
>> - [High] 32-bit integer overflow in `hid_bpf_get_data()` allows arbitrary out-of-bounds kernel memory access.
>> - [High] Explicit 0-sized requests to kfuncs result in out-of-bounds read due to verifier BTF fallback.
>
> I also noticed the second preexisting issue when working on a patchset
> unifying helper and kfunc handling. The patchset will fix it.
>

Exciting! Are you also planning to unify global function calls (and extend the
type system so that we have parity with what helpers/kfuncs can take), or is the
scope only helpers and kfuncs for now? Just curious, but I think it the
unification would be a good base to bring their argument types and the handling
at parity with helpers/kfuncs.

Re: [PATCH bpf-next v2 0/2] bpf: bound rdonly/rdwr_buf_size kfunc return size

[patchwork-bot+netdevbpf]

Hello:

This series was applied to bpf/bpf-next.git (master)
by Kumar Kartikeya Dwivedi <memxor@gmail.com>:

On Thu,  9 Jul 2026 11:58:35 -0400 you wrote:
> check_kfunc_args() stores a kfunc's rdonly_buf_size/rdwr_buf_size
> argument into a u64 that check_kfunc_call() later narrows into the
> returned register's u32 mem_size, so a value above U32_MAX truncates
> instead of being rejected. Fix it and add a selftest for coverage.
> 
> Changelog:
> 
> [...]

Here is the summary with links:
  - [bpf-next,v2,1/2] bpf: reject rdonly/rdwr_buf_size kfunc arguments that exceed u32 max
    https://git.kernel.org/bpf/bpf-next/c/2aaf67f0516f
  - [bpf-next,v2,2/2] selftests/bpf: add test for oversized rdonly/rdwr_buf_size kfunc argument
    https://git.kernel.org/bpf/bpf-next/c/12556c319832

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html

Re: [PATCH bpf-next v2 1/2] bpf: reject rdonly/rdwr_buf_size kfunc arguments that exceed u32 max

[Amery Hung]

On Thu, Jul 9, 2026 at 1:29 PM Kumar Kartikeya Dwivedi <memxor@gmail.com> wrote:
>
> On Thu Jul 9, 2026 at 10:01 PM CEST, Amery Hung wrote:
> > On Thu, Jul 9, 2026 at 9:22 AM <sashiko-bot@kernel.org> wrote:
> >>
> >> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> >>
> >> Pre-existing issues:
> >> - [High] 32-bit integer overflow in `hid_bpf_get_data()` allows arbitrary out-of-bounds kernel memory access.
> >> - [High] Explicit 0-sized requests to kfuncs result in out-of-bounds read due to verifier BTF fallback.
> >
> > I also noticed the second preexisting issue when working on a patchset
> > unifying helper and kfunc handling. The patchset will fix it.
> >
>
> Exciting! Are you also planning to unify global function calls (and extend the
> type system so that we have parity with what helpers/kfuncs can take), or is the
> scope only helpers and kfuncs for now? Just curious, but I think it the
> unification would be a good base to bring their argument types and the handling
> at parity with helpers/kfuncs.

Yeah. I'd like to cover global function calls. The incoming patchsets
will only cover helper and kfunc though due to the size of changes.

The basic idea is to have a common function call descriptor for
helper, kfunc and global function call using bpf_func_proto. Then have
a bpf_func_proto-based verification. Hopefully most of it will be
helper/kfunc/subprog agnostic.

As for the logistical refactoring:

- First step is to unify bpf{_kfunc}_call_arg_meta, which many
verfication logic {e.g., alloc memory size in this thread} rely on.
- Then, KF_ARG types and their verification will be aligned more
closely with helper's arg type.
- Finally, drop KF_ARG and unify core of check_func_arg and check_kfunc_args.