Re: [PATCH v4 1/2] PM: wakeup: Add kfuncs to traverse over wakeup_sources

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] The kfunc `bpf_wakeup_sources_get_head()` returns `void *` instead of `struct list_head *`, which the BPF verifier downgrades to an unknown scalar, destroying BTF type tracking.
- [High] The verifier cannot enforce that the SRCU lock is actually held during list traversal, allowing trivial use-after-free vulnerabilities and violating BPF architectural patterns.
- [Medium] Wrapping the integer SRCU index in a fake `struct bpf_ws_lock *` pointer circumvents verifier safeguards and introduces invalid trusted pointers.
--

commit 6dcbdc1d5aa4a12914c7281f95390e19498129d0
Author: Samuel Wu <wusamuel@google.com>

PM: wakeup: Add kfuncs to traverse over wakeup_sources

This patch introduces BPF kfuncs to allow in-kernel traversal of the
wakeup_sources list. It adds functions to get the list head and manage
the SRCU lock, using an opaque pointer to hold the SRCU index for the
verifier.

> diff --git a/drivers/base/power/wakeup.c b/drivers/base/power/wakeup.c
> index b8e48a023bf0c..80b497de2deb0 100644
> --- a/drivers/base/power/wakeup.c
> +++ b/drivers/base/power/wakeup.c

[ ... ]

> +/**
> + * bpf_wakeup_sources_read_lock - Acquire the SRCU lock for wakeup sources
> + *
> + * The underlying SRCU lock returns an integer index. However, the BPF verifier
> + * requires a pointer (PTR_TO_BTF_ID) to strictly track the state of acquired
> + * resources using KF_ACQUIRE and KF_RELEASE semantics. We use an opaque
> + * structure pointer (struct bpf_ws_lock *) to satisfy the verifier while
> + * safely encoding the integer index within the pointer address itself.
> + *
> + * Return: An opaque pointer encoding the SRCU lock index + 1 (to avoid NULL).
> + */
> +__bpf_kfunc struct bpf_ws_lock *bpf_wakeup_sources_read_lock(void)
> +{
> +	return (struct bpf_ws_lock *)(long)(wakeup_sources_read_lock() + 1);
> +}

The verifier treats the returned struct bpf_ws_lock * as a trusted
PTR_TO_BTF_ID. By casting the integer index returned by srcu_read_lock()
into a pointer, we end up fabricating invalid kernel pointers pointing to
near-zero addresses like 0x1 or 0x2.

Does this circumvent verifier safeguards by introducing invalid trusted
pointers?

[ ... ]

> +/**
> + * bpf_wakeup_sources_read_unlock - Release the SRCU lock for wakeup sources
> + * @lock: The opaque pointer returned by bpf_wakeup_sources_read_lock()
> + *
> + * The BPF verifier guarantees that @lock is a valid, unreleased pointer from
> + * the acquire function. We decode the pointer back into the integer SRCU index
> + * by subtracting 1 and release the lock.
> + */
> +__bpf_kfunc void bpf_wakeup_sources_read_unlock(struct bpf_ws_lock *lock)
> +{
> +	wakeup_sources_read_unlock((int)(long)lock - 1);
> +}

The patch uses KF_ACQUIRE and KF_RELEASE to ensure the lock is eventually
unlocked. However, does the BPF verifier have a mechanism to tie this
custom lock state to the list pointer returned by
bpf_wakeup_sources_get_head()?

It seems a BPF program could fetch the list head and traverse it without
ever acquiring the lock, or continue accessing elements after releasing
the lock, resulting in a use-after-free.

Would it be safer to implement a dedicated BPF iterator
(bpf_iter_wakeup_source) that internally manages the SRCU lock and safely
yields elements, rather than exposing the raw lock and list head?

> +/**
> + * bpf_wakeup_sources_get_head - Get the head of the wakeup sources list
> + *
> + * Return: The head of the wakeup sources list.
> + */
> +__bpf_kfunc void *bpf_wakeup_sources_get_head(void)
> +{
> +	return &wakeup_sources;
> +}

Since this kfunc returns void * instead of struct list_head *, the BPF
verifier evaluates it as returning an unknown scalar.

Because the return value becomes a scalar, BPF programs cannot natively
or safely dereference the list head. They would be forced to cast the
scalar back into a pointer using bpf_rdonly_cast(), which the verifier
marks as PTR_UNTRUSTED.

Since untrusted pointers cause field dereferences to be rewritten into
slow PROBE_MEM operations, does this defeat the goal of high-performance
in-kernel traversal?

Could the return type be changed to struct list_head * to be natively
tracked as a PTR_TO_BTF_ID?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260511174559.659782-1-wusamuel@google.com?part=1