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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <cdbd634d-4f15-48c8-9c2f-812130605465@kernel.dk>
Date: Sat, 10 Jan 2026 10:28:02 -0700
From: Jens Axboe <axboe@...nel.dk>
To: Caleb Sander Mateos <csander@...estorage.com>
Cc: linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
 Anuj Gupta <anuj20.g@...sung.com>, Christoph Hellwig <hch@....de>
Subject: Re: [PATCH v2 0/3] block: zero non-PI portion of auto integrity
 buffer

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