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

[Jens Axboe]

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