Re: [PATCH bpf-next] bpf: cleanup aux->used_maps after jit

[Chris Mason <clm@meta.com>]

On 11/24/25 11:55 AM, Alexei Starovoitov wrote:
> On Mon, Nov 24, 2025 at 7:56 AM Chris Mason <clm@meta.com> wrote:
>>
>> On 11/24/25 10:30 AM, bot+bpf-ci@kernel.org wrote:
>>>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>>>> index 2e170be64..766695491 100644
>>>> --- a/kernel/bpf/verifier.c
>>>> +++ b/kernel/bpf/verifier.c
>>>> @@ -22266,6 +22266,15 @@ static int jit_subprogs(struct bpf_verifier_env *env)
>>>>              cond_resched();
>>>>      }
>>>>
>>>> +    /*
>>>> +     * Cleanup func[i]->aux fields which aren't required
>>>> +     * or can become invalid in future
>>>> +     */
>>>> +    for (i = 0; i < env->subprog_cnt; i++) {
>>>> +            func[i]->aux->used_maps = NULL;
>>>> +            func[i]->aux->used_map_cnt = 0;
>>>> +    }
>>>> +
>>>
>>> The patch correctly fixes the use-after-free issue. However, this isn't a
>>> bug, but should this have a Cc: stable@vger.kernel.org tag? The bug being
>>> fixed affects released kernels where bpf_prog_free_deferred() will call
>>> bpf_free_used_maps() on the dangling func[i]->aux->used_maps pointer,
>>> potentially causing kfree() to be called on already-freed or invalid memory.
>>
>> I took a pull request for the review prompts this morning that adds
>> Fixes: suggestions and verification.  If Alexei or others here would
>> rather have this disabled for the BPF reviews, I'll make them default to
>> off.
> 
> Disable it pls.
> In this case Fixes tag point to a commit in bpf-next,
> so nothing to backport and, in general, we pretty much
> never do "cc: stable" unless it's a critical fix.
> I believe Greg and Sasha don't rely on cc: stable much.
> Automation will figure things out based on Fixes tag.
> cc: stable is an additional signal, but not mandatory,
> and we prefer to avoid extra lines in the commit log when they
> are not necessary.
> 
> Fixes tag is a different story. We definitely want it for fixes
> and related changes even when they're not necessarily a fix.
> But a generic AI comment "should there be a Fixes tag?" will not
> be useful. If it can say "Should there be Fixes: sha ("bpf: ..")"
> that would be nice.

Agreed, it shouldn't be hard for AI to suggest the Fixes: tag and the
commit being fixed.  I'll work on this.

I've disabled the Fixes: prompt by default, looks like one more review
got in before I turned it off.

-chris