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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <cf37342e-c2dc-48c9-a63b-e62fe8e791e4@kernel.dk>
Date: Sat, 10 Jan 2026 10:21:51 -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/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.

-- 
Jens Axboe