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

Caleb Sander Mateos (3):
  block: zero non-PI portion of auto integrity buffer
  block: replace gfp_t with bool in bio_integrity_prep()
  block: use pi_tuple_size in bi_offload_capable()

 block/bio-integrity-auto.c | 25 +++++++------------------
 1 file changed, 7 insertions(+), 18 deletions(-)

-- 
2.45.2

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
[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

On Fri, Jan 9, 2026 at 5:57 AM Jens Axboe <axboe@kernel.dk> 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
>
>
>

On 1/9/26 9:29 AM, Caleb Sander Mateos wrote:
> On Fri, Jan 9, 2026 at 5:57 AM Jens Axboe <axboe@kernel.dk> 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).

Good point, let me see if I can reshuffle it a bit. In the future, would
be nice with these split, particularly if they don't have any real
dependencies. I'll shift 1/3 to block-6.19.

-- 
Jens Axboe

On Sat, Jan 10, 2026 at 9:21 AM Jens Axboe <axboe@kernel.dk> wrote:
>
> On 1/9/26 9:29 AM, Caleb Sander Mateos wrote:
> > On Fri, Jan 9, 2026 at 5:57 AM Jens Axboe <axboe@kernel.dk> 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).
>
> Good point, let me see if I can reshuffle it a bit. In the future, would
> be nice with these split, particularly if they don't have any real
> dependencies. I'll shift 1/3 to block-6.19.

Thanks, I'll try to label my patch series more clearly in the future.
Christoph had suggested splitting apart the fix patch 1 from the
cleanup patch 2, but I see how that makes it a pain to apply the
series. I'll resend patch 2 once for-7.0/block picks up patch 1 from
block-6.19.

--Caleb

On 1/10/26 10:21 AM, Jens Axboe wrote:
> On 1/9/26 9:29 AM, Caleb Sander Mateos wrote:
>> On Fri, Jan 9, 2026 at 5:57?AM Jens Axboe <axboe@kernel.dk> 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).
> 
> Good point, let me see if I can reshuffle it a bit. In the future, would
> be nice with these split, particularly if they don't have any real
> dependencies. I'll shift 1/3 to block-6.19.

Done - 1/3 is now in block-6.19. I dropped 2/3 as it's mostly useless
and will now through a conflict in for-7.0/block. 3/3 still in there.

-- 
Jens Axboe

Caleb,

> 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.

LGTM.

Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>

-- 
Martin K. Petersen