Re: [PATCH] fsverity: Fix bpf_get_fsverity_digest() dynptr assumptions

Kumar Kartikeya Dwivedi <[email protected]>
Newsgroups org.kernel.vger.stable,dev.linux.lists.fsverity,org.kernel.vger.bpf,org.kernel.vger.linux-kernel
Message-ID <CAP01T74A0umBf_2hCuAygvUFBocjrDogxnu1_U+RkKBw8ictfw@mail.gmail.com>
On Sat, 1 Aug 2026 at 22:18, Eric Biggers <[email protected]> wrote:
>
> On Sat, Aug 01, 2026 at 07:38:08PM +0200, Kumar Kartikeya Dwivedi wrote:
> > On Sat Aug 1, 2026 at 7:35 PM CEST, Kumar Kartikeya Dwivedi wrote:
> > > On Sat Aug 1, 2026 at 7:15 PM CEST, Eric Biggers wrote:
> > >> On Sat, Aug 01, 2026 at 06:52:45PM +0200, Kumar Kartikeya Dwivedi wrote:
> > >>> > Also correctly handle sizes over INT_MAX, which previously caused an
> > >>> > integer overflow and crash.  __bpf_dynptr_size() returns a u64.
> > >>> >
> > >>>
> > >>> I guess this occurs when using file dynptrs? Otherwise the size is capped to
> > >>> DYNPTR_SIZE_MASK.
> > >>
> > >> Yes, though it looks like __bpf_dynptr_data_rw() excludes file dynptrs.
> > >> So this particular issue might be unreachable.  Still seems like a good
> > >> idea to match the u64 type that __bpf_dynptr_size() returns though.
> > >>
> > >
> > > I don't see this in patchwork, so you might have to resend this with [PATCH
> > > bpf-next] subject again to trigger CI if you want this to go through bpf tree.
> > >
> >
> > Sorry, [PATCH bpf], rather.
>
> Sure I can do that.
>
> Would it be okay to also make this function return -EOVERFLOW if
> out_digest_sz is too small, similar to FS_IOC_MEASURE_VERITY, instead of
> silently truncating?  The silent truncation is a footgun.

Yeah, I think it makes sense. I will also ping Song to ack this on
Monday (or your new version).
Thanks

>
> - Eric
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.