Re: [PATCH] fsverity: Fix bpf_get_fsverity_digest() dynptr assumptions
Kumar Kartikeya Dwivedi <[email protected]> Sat, 1 Aug 2026 22:47:55 +0200
| Newsgroups | dev.linux.lists.fsverity,org.kernel.vger.bpf,org.kernel.vger.linux-kernel,org.kernel.vger.stable |
|---|---|
| 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