include/linux/bpf.h | 1 + include/linux/bpf_verifier.h | 11 +- kernel/bpf/arraymap.c | 18 ++- kernel/bpf/diagnostics.c | 3 + kernel/bpf/diagnostics.h | 1 + kernel/bpf/states.c | 4 + kernel/bpf/verifier.c | 149 +++++++++++++++--- .../selftests/bpf/prog_tests/cb_refs.c | 4 +- .../selftests/bpf/progs/exceptions_fail.c | 20 +++ .../selftests/bpf/progs/user_ringbuf_fail.c | 143 +++++++++++++++++ .../bpf/progs/verifier_iterating_callbacks.c | 91 +++++++++++ 11 files changed, 419 insertions(+), 26 deletions(-)
A callback-calling helper or kfunc can pass its callback a pointer
that is only valid for the duration of the call, and the verifier has
no way to express that.
Two helpers need fixing:
* bpf_user_ringbuf_drain() passes a CONST_PTR_TO_DYNPTR over a
sample it releases as soon as the callback returns. When parked in
callback_ctx, that register describes reused kernel stack and
gives the program an arbitrary kernel read and write (bpf-next
only, see patch #2).
* bpf_for_each_map_elem() over an (percpu-) array map passes the
address of a u32 held in bpf_for_each_array_elem()'s own frame,
leaking four bytes of kernel stack.
Neither has a local fix: both arguments point into a helper's own
frame, with nothing longer-lived to anchor them to.
Introduce REF_TYPE_FRAME for this use case: a reference owned by a
callee frame, dropped when the frame is popped. Then use this
mechanism in both bpf_user_ringbuf_drain() and bpf_for_each_map_elem()
callee state setup.
---
The series is composed as follows:
* patch #1 implements REF_TYPE_FRAME and relevant infra code, but
it's not used yet
* patches #2 and #5 use the new mark_frame_scoped_arg() helper
* patch #3 adds relevant diagnostics
* patches #4 and #6 add selftests to cover the changes
---
Ihor Solodrai (6):
bpf: Introduce REF_TYPE_FRAME in the verifier
bpf: Scope the bpf_user_ringbuf_drain() dynptr to its callback frame
bpf: Name the callback in frame-release diagnostics
selftests/bpf: Cover the user ringbuf callback dynptr lifetime
bpf: Scope the bpf_for_each_map_elem() array key to the callback frame
selftests/bpf: Cover callback-frame map key lifetime
include/linux/bpf.h | 1 +
include/linux/bpf_verifier.h | 11 +-
kernel/bpf/arraymap.c | 18 ++-
kernel/bpf/diagnostics.c | 3 +
kernel/bpf/diagnostics.h | 1 +
kernel/bpf/states.c | 4 +
kernel/bpf/verifier.c | 149 +++++++++++++++---
.../selftests/bpf/prog_tests/cb_refs.c | 4 +-
.../selftests/bpf/progs/exceptions_fail.c | 20 +++
.../selftests/bpf/progs/user_ringbuf_fail.c | 143 +++++++++++++++++
.../bpf/progs/verifier_iterating_callbacks.c | 91 +++++++++++
11 files changed, 419 insertions(+), 26 deletions(-)
base-commit: 79dc258c9392051420a26f1504c647bd3d27c66a
--
2.55.0
On Mon, Sep 21, 2026 at 06:03 PM Ihor Solodrai <ihor.solodrai@linux.dev> wrote:
> Neither has a local fix: both arguments point into a helper's own
> frame, with nothing longer-lived to anchor them to.
It's the same problem as a pointer to callee's stack.
check_stack_write_fixed_off() deals with it like this:
if (state != cur && reg->type == PTR_TO_STACK) {
verbose(env, "cannot spill pointers to stack into stack frame of the caller\n");
return -EINVAL;
}
CONST_PTR_TO_DYNPTR wasn't spillable before 7.3, so nothing depends
on parking it in the caller's frame. Reject it there too ?
and then no need for REF_TYPE_FRAME complexity?
On 2026-09-21 6:55 p.m., Alexei Starovoitov wrote:
> On Mon, Sep 21, 2026 at 06:03 PM Ihor Solodrai <ihor.solodrai@linux.dev> wrote:
>
>> Neither has a local fix: both arguments point into a helper's own
>> frame, with nothing longer-lived to anchor them to.
>
> It's the same problem as a pointer to callee's stack.
> check_stack_write_fixed_off() deals with it like this:
> if (state != cur && reg->type == PTR_TO_STACK) {
> verbose(env, "cannot spill pointers to stack into stack frame of the caller\n");
> return -EINVAL;
> }
> CONST_PTR_TO_DYNPTR wasn't spillable before 7.3, so nothing depends
> on parking it in the caller's frame. Reject it there too ?
> and then no need for REF_TYPE_FRAME complexity?
If we focus on the nasty bpf_user_ringbuf_drain() bug specifically,
then yes, check_stack_write_fixed_off() change patches it:
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index d62c0f74cff5..f261423e9282 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -3668,7 +3668,8 @@ static int check_stack_write_fixed_off(struct
bpf_verifier_env *env,
verbose(env, "invalid size of register spill\n");
return -EACCES;
}
- if (state != cur && reg->type == PTR_TO_STACK) {
+ if (state != cur && (reg->type == PTR_TO_STACK ||
+ reg->type == CONST_PTR_TO_DYNPTR)) {
verbose(env, "cannot spill pointers to stack
into stack frame of the caller\n");
return -EINVAL;
}
However it doesn't cover some of the new test cases:
- user_ringbuf_callback_park_data_slice
- user_ringbuf_callback_park_kfunc_slice
- user_ringbuf_callback_park_clone
- user_ringbuf_callback_park_clone_then_slice
(not counting the diag message diff)
The original suggestion that came with the bug report was a
cb_dynptr_id field in bpf_func_state set up in
set_user_ringbuf_callback_state() and read in prepare_func_exit() to
release it there.
The cb_dynptr_id seemed way too specific, I didn't like it. So I've
tried to figure out a feasible generalization of the problem, and came
to "verifier can't track a lifetime of a ref tied to a frame", and
then to this series.
I think we need to decide whether the REF_TYPE_FRAME is a useful
mechanism in principle, and whether it's sufficiently generic. It at
least covers the cases in this series and more.
For example AI also flagged for me parking the vma argument
(PTR_TO_BTF_ID) of the bpf_find_vma() callback. It's low severity,
which is why I excluded that from the series, but "reject a reg type"
wouldn't work there AFAIU (we would break many legitimate programs).
Opinions?
On Tue Sep 22, 2026 at 8:13 AM CEST, Ihor Solodrai wrote:
> On 2026-09-21 6:55 p.m., Alexei Starovoitov wrote:
>> On Mon, Sep 21, 2026 at 06:03 PM Ihor Solodrai <ihor.solodrai@linux.dev> wrote:
>>
>>> Neither has a local fix: both arguments point into a helper's own
>>> frame, with nothing longer-lived to anchor them to.
>>
>> It's the same problem as a pointer to callee's stack.
>> check_stack_write_fixed_off() deals with it like this:
>> if (state != cur && reg->type == PTR_TO_STACK) {
>> verbose(env, "cannot spill pointers to stack into stack frame of the caller\n");
>> return -EINVAL;
>> }
>> CONST_PTR_TO_DYNPTR wasn't spillable before 7.3, so nothing depends
>> on parking it in the caller's frame. Reject it there too ?
>> and then no need for REF_TYPE_FRAME complexity?
>
> If we focus on the nasty bpf_user_ringbuf_drain() bug specifically,
> then yes, check_stack_write_fixed_off() change patches it:
>
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index d62c0f74cff5..f261423e9282 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -3668,7 +3668,8 @@ static int check_stack_write_fixed_off(struct
> bpf_verifier_env *env,
> verbose(env, "invalid size of register spill\n");
> return -EACCES;
> }
> - if (state != cur && reg->type == PTR_TO_STACK) {
> + if (state != cur && (reg->type == PTR_TO_STACK ||
> + reg->type == CONST_PTR_TO_DYNPTR)) {
> verbose(env, "cannot spill pointers to stack
> into stack frame of the caller\n");
> return -EINVAL;
> }
>
> However it doesn't cover some of the new test cases:
> - user_ringbuf_callback_park_data_slice
> - user_ringbuf_callback_park_kfunc_slice
> - user_ringbuf_callback_park_clone
> - user_ringbuf_callback_park_clone_then_slice
>
> (not counting the diag message diff)
>
> The original suggestion that came with the bug report was a
> cb_dynptr_id field in bpf_func_state set up in
> set_user_ringbuf_callback_state() and read in prepare_func_exit() to
> release it there.
>
> The cb_dynptr_id seemed way too specific, I didn't like it. So I've
> tried to figure out a feasible generalization of the problem, and came
> to "verifier can't track a lifetime of a ref tied to a frame", and
> then to this series.
>
> I think we need to decide whether the REF_TYPE_FRAME is a useful
> mechanism in principle, and whether it's sufficiently generic. It at
> least covers the cases in this series and more.
>
> For example AI also flagged for me parking the vma argument
> (PTR_TO_BTF_ID) of the bpf_find_vma() callback. It's low severity,
> which is why I excluded that from the series, but "reject a reg type"
> wouldn't work there AFAIU (we would break many legitimate programs).
>
> Opinions?
Ok, I think I didn't realize the issue was broader than just CONST_PTR_TO_DYNPTR
type. In that case I think what you suggest does make sense, and might help
generalize the behavior across different cases.
On Mon, Sep 21, 2026 at 11:13 PM Ihor Solodrai <ihor.solodrai@linux.dev> wrote:
>
> On 2026-09-21 6:55 p.m., Alexei Starovoitov wrote:
> > On Mon, Sep 21, 2026 at 06:03 PM Ihor Solodrai <ihor.solodrai@linux.dev> wrote:
> >
> >> Neither has a local fix: both arguments point into a helper's own
> >> frame, with nothing longer-lived to anchor them to.
> >
> > It's the same problem as a pointer to callee's stack.
> > check_stack_write_fixed_off() deals with it like this:
> > if (state != cur && reg->type == PTR_TO_STACK) {
> > verbose(env, "cannot spill pointers to stack into stack frame of the caller\n");
> > return -EINVAL;
> > }
> > CONST_PTR_TO_DYNPTR wasn't spillable before 7.3, so nothing depends
> > on parking it in the caller's frame. Reject it there too ?
> > and then no need for REF_TYPE_FRAME complexity?
>
> If we focus on the nasty bpf_user_ringbuf_drain() bug specifically,
> then yes, check_stack_write_fixed_off() change patches it:
>
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index d62c0f74cff5..f261423e9282 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -3668,7 +3668,8 @@ static int check_stack_write_fixed_off(struct
> bpf_verifier_env *env,
> verbose(env, "invalid size of register spill\n");
> return -EACCES;
> }
> - if (state != cur && reg->type == PTR_TO_STACK) {
> + if (state != cur && (reg->type == PTR_TO_STACK ||
> + reg->type == CONST_PTR_TO_DYNPTR)) {
> verbose(env, "cannot spill pointers to stack
> into stack frame of the caller\n");
> return -EINVAL;
> }
>
> However it doesn't cover some of the new test cases:
> - user_ringbuf_callback_park_data_slice
> - user_ringbuf_callback_park_kfunc_slice
> - user_ringbuf_callback_park_clone
> - user_ringbuf_callback_park_clone_then_slice
>
> (not counting the diag message diff)
>
> The original suggestion that came with the bug report was a
> cb_dynptr_id field in bpf_func_state set up in
> set_user_ringbuf_callback_state() and read in prepare_func_exit() to
> release it there.
>
> The cb_dynptr_id seemed way too specific, I didn't like it. So I've
> tried to figure out a feasible generalization of the problem, and came
> to "verifier can't track a lifetime of a ref tied to a frame", and
> then to this series.
>
> I think we need to decide whether the REF_TYPE_FRAME is a useful
> mechanism in principle, and whether it's sufficiently generic. It at
> least covers the cases in this series and more.
>
> For example AI also flagged for me parking the vma argument
> (PTR_TO_BTF_ID) of the bpf_find_vma() callback. It's low severity,
> which is why I excluded that from the series, but "reject a reg type"
> wouldn't work there AFAIU (we would break many legitimate programs).
>
> Opinions?
>
It does seem like we miss a reference representing single frame
lifetime which we can then use as a parent for all things that
shouldn't survive past the current frame. There is a separate fix
right now to invalidate dynptr created in subprog's frame. Seems like
that one should be expressible the same way: local dynptr's parent is
"frame lifetime" reference.
We can even relax this "cannot spill pointers to stack into stack
frame of the caller" error, potentially, by just turning that
PTR_TO_STACK into SCALAR at exit from current frame and let program
verification go, no harm.
So for me it seems like a necessary and useful addition.
On Tue, 2026-09-22 at 15:41 -0700, Andrii Nakryiko wrote: ... > It does seem like we miss a reference representing single frame > lifetime which we can then use as a parent for all things that > shouldn't survive past the current frame. There is a separate fix > right now to invalidate dynptr created in subprog's frame. Seems like > that one should be expressible the same way: local dynptr's parent is > "frame lifetime" reference. > > We can even relax this "cannot spill pointers to stack into stack > frame of the caller" error, potentially, by just turning that > PTR_TO_STACK into SCALAR at exit from current frame and let program > verification go, no harm. > > So for me it seems like a necessary and useful addition. I shared some feedback about unnecessary bit mask manipulation with Ihor off list, but overall I think that this series makes sense.
On Tue Sep 22, 2026 at 3:55 AM CEST, Alexei Starovoitov wrote:
> On Mon, Sep 21, 2026 at 06:03 PM Ihor Solodrai <ihor.solodrai@linux.dev> wrote:
>
>> Neither has a local fix: both arguments point into a helper's own
>> frame, with nothing longer-lived to anchor them to.
>
> It's the same problem as a pointer to callee's stack.
> check_stack_write_fixed_off() deals with it like this:
> if (state != cur && reg->type == PTR_TO_STACK) {
> verbose(env, "cannot spill pointers to stack into stack frame of the caller\n");
> return -EINVAL;
> }
> CONST_PTR_TO_DYNPTR wasn't spillable before 7.3, so nothing depends
> on parking it in the caller's frame. Reject it there too ?
> and then no need for REF_TYPE_FRAME complexity?
+1, will be much simpler fix.
© 2016 - 2026 Red Hat, Inc.