[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEf4BzYTuOJ88FR6oN1KDbM5bWuiYo7eVdrrn0FLziuzi3B_Fg@mail.gmail.com>
Date: Tue, 8 Oct 2024 10:21:47 -0700
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: Eduard Zingerman <eddyz87@...il.com>
Cc: I Hsin Cheng <richard120310@...il.com>, martin.lau@...ux.dev, ast@...nel.org,
daniel@...earbox.net, andrii@...nel.org, song@...nel.org,
yonghong.song@...ux.dev, john.fastabend@...il.com, kpsingh@...nel.org,
sdf@...ichev.me, haoluo@...gle.com, jolsa@...nel.org, bpf@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] libbpf: Fix integer overflow issue
On Tue, Oct 8, 2024 at 2:49 AM Eduard Zingerman <eddyz87@...il.com> wrote:
>
> On Mon, 2024-10-07 at 20:42 -0700, Andrii Nakryiko wrote:
>
> [...]
>
> > Not sure what Eduard is suggesting here, tbh. But I think if this
> > actually can happen that we have a non-loaded BPF program in one of
> > those struct_ops slots, then let's add a test demonstrating that.
>
> Given the call chain listed in a previous email I think that such
> situation is not possible (modulo obj->gen_loader, which I know
> nothing about).
>
> Thus I suggest to add a pr_warn() and return -EINVAL or something like
> that here.
>
That's what confused me :) If it's impossible, there is no need to
handle it, we know the FD has to be there. So I'd just not change
anything.
> > Worst case of what can happen right now is the kernel rejecting
> > struct_ops loading due to -22 as a program FD.
> >
> > pw-bot: cr
>
> [...]
>
Powered by blists - more mailing lists