Re: [PATCH] libbpf:fix use empty function pointers in ringbuf_poll

[Stanislav Fomichev]

On Fri, Jun 9, 2023 at 2:38 AM zhangmingyi <zhangmingyi5@xxxxxxxxxx> wrote:
>
> On Fri, Jun 9, 2023 at 1:39 AM Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote:
>
> > On Thu, Jun 8, 2023 at 9:27 AM Stanislav Fomichev <sdf@xxxxxxxxxx> wrote:
> > >
> > > On Thu, Jun 8, 2023 at 6:00 AM zhangmingyi <zhangmingyi5@xxxxxxxxxx> wrote:
> > > >
> > > > On 06/06,Stanislav Fomichev wrote:
> > > >
> > > > > On 06/05, Xin Liu wrote:
> > > > > > From: zhangmingyi <zhangmingyi5@xxxxxxxxxx>
> > > > >
> > > > > > The sample_cb of the ring_buffer__new interface can transfer NULL. However,
> > > > > > the system does not check whether sample_cb is NULL during
> > > > > > ring_buffer__poll, null pointer is used.
> > > >
> > > > > What is the point of calling ring_buffer__new with sample_cb == NULL?
> > > >
> > > > Yes, as you said, passing sample_cb in ring_buffer__new to NULL doesn't
> > > > make sense, and few people use it that way, but that doesn't prevent this
> > > > from being a allowed and supported scenario. And when ring_buffer__poll is
> > > > called, it leads to a segmentation fault (core dump), which I think needs
> > > > to be fixed to ensure the security quality of libbpf.
> > >
> > > I dunno. I'd argue that passing a NULL to ring_buffer__new is an API
> > > misuse. Maybe ring_buffer__new should return -EINVAL instead when
> > > passed NULL sample_cb? Although, we don't usually have those checks
> > > for the majority of the arguments in libbpf...
> >
> > Right. I'd say we should add a proper doc comment specifying all
> > arguments and which ones are optional or not. And make it explicit
> > that callback is not optional. If we start checking every possible
> > pointer for NULL, libbpf will be littered with NULL checks, I'm not
> > sure that's good.
>
> I agree, we should add a proper doc comment specifying all
> arguments and which ones are optional or not.
> However, why does the external interface API in libbpf not verify input
> parameters or add verification where risky operations may exist?
> What's more, i think sample_cb=NULL is not strictly a mistake or
> prohibited use, and is meaningless.

It's not really customary in C to do it? So maybe you can follow up
with the update to the doc?

The kindergarten is over, you pass NULL you get SIGSEGV :-D