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: <CADUfDZoacSnJz5FOZQov50k4_nP0sxqxDHYOvDqp1_7KKD8z1A@mail.gmail.com>
Date: Fri, 9 Jan 2026 08:29:53 -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 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).

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