Re: [PATCH v2 0/3] block: zero non-PI portion of auto integrity buffer

[Caleb Sander Mateos]

On Fri, Jan 9, 2026 at 5:57 AM Jens Axboe <axboe@xxxxxxxxx> wrote:
>
>
> On Thu, 08 Jan 2026 10:22:09 -0700, Caleb Sander Mateos wrote:
> > For block devices capable of storing "opaque" metadata in addition to
> > protection information, ensure the opaque bytes are initialized by the
> > block layer's auto integrity generation. Otherwise, the contents of
> > kernel memory can be leaked via the storage device.
> > Two follow-on patches simplify the bio_integrity_prep() code a bit.
> >
> > v2:
> > - Clarify commit message (Christoph)
> > - Split gfp_t cleanup into separate patch (Christoph)
> > - Add patch simplifying bi_offload_capable()
> > - Add Reviewed-by tag
> >
> > [...]
>
> Applied, thanks!
>
> [1/3] block: zero non-PI portion of auto integrity buffer
>       commit: eaa33937d509197cd53bfbcd14247d46492297a3

Hi Jens,
I see the patches were applied to for-7.0/block. But I would argue the
first patch makes sense for 6.19, as being able to leak the contents
of kernel heap memory is pretty concerning. Block devices that support
metadata_size > pi_tuple_size aren't super widespread, but they do
exist (looking at a Samsung NVMe device that supports 64-byte metadata
right now).

Thanks,
Caleb

> [2/3] block: replace gfp_t with bool in bio_integrity_prep()
>       commit: fd902c117e49eabbbbe70b1bde8978763c6d3fc0
> [3/3] block: use pi_tuple_size in bi_offload_capable()
>       commit: 0357a764b5f8f2f503c1bb1f100d74feb67a599a
>
> Best regards,
> --
> Jens Axboe
>
>
>