On Wed, 10 Feb 2021 19:23:38 +0100
Eric Dumazet <eric.dumazet@xxxxxxxxx> wrote:
> >> The problem here is a kmalloc failure injection into
> >> tracepoint_probe_unregister, but the error is ignored -- so the bpf
> >> program is freed even though the tracepoint is never unregistered.
> >>
> >> I have a first pass at a patch to pipe through the error code, but it's
> >> pretty ugly. It's also called from the file_operations ->release(), for
> >
> > Maybe you can still post the patch, so people can review and make suggestions which may lead to a *better* solution.
>
>
> ping
>
> This bug is still there.
Is this a bug via syzkaller?
I have this fix in linux-next:
befe6d946551 ("tracepoint: Do not fail unregistering a probe due to memory failure")
But because it is using undefined behavior (calling a sub return from a
call that has parameters, but Peter Zijlstra says is OK), I'm hesitant to
send it to Linus now or label it as stable.
Now this can only happen if kmalloc fails from here (called by func_remove).
static inline void *allocate_probes(int count)
{
struct tp_probes *p = kmalloc(struct_size(p, probes, count),
GFP_KERNEL);
return p == NULL ? NULL : p->probes;
}
As probes and count together is typically much less than a page (unless you
are doing fuzz testing and adding a ton of callbacks to a single
tracepoint), that kmalloc should always succeed.
The failure above can only happen if allocate_probes returns NULL, which is
extremely unlikely.
My question is, how is this triggered? And this should only be triggered by
root doing stupid crap. Is it that critical to have fixed?
-- Steve
