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] [day] [month] [year] [list]

Message-ID: <CADUfDZqbqWjGhY3FuSOgBk5pgTR7By6LgXPBH+A=7g9wLp5qmg@mail.gmail.com>
Date: Sat, 10 Jan 2026 12:05:12 -0800
From: Caleb Sander Mateos <csander@...estorage.com>
To: Jens Axboe <axboe@...nel.dk>
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 Sat, Jan 10, 2026 at 9:21 AM Jens Axboe <axboe@...nel.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@...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.

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