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

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

[Caleb Sander Mateos]

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

Caleb Sander Mateos (3):
  block: zero non-PI portion of auto integrity buffer
  block: replace gfp_t with bool in bio_integrity_prep()
  block: use pi_tuple_size in bi_offload_capable()

 block/bio-integrity-auto.c | 25 +++++++------------------
 1 file changed, 7 insertions(+), 18 deletions(-)

-- 
2.45.2

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

[Caleb Sander Mateos]

The auto-generated integrity buffer for writes needs to be fully
initialized before being passed to the underlying block device,
otherwise the uninitialized memory can be read back by userspace or
anyone with physical access to the storage device. If protection
information is generated, that portion of the integrity buffer is
already initialized. The integrity data is also zeroed if PI generation
is disabled via sysfs or the PI tuple size is 0. However, this misses
the case where PI is generated and the PI tuple size is nonzero, but the
metadata size is larger than the PI tuple. In this case, the remainder
("opaque") of the metadata is left uninitialized.
Generalize the BLK_INTEGRITY_CSUM_NONE check to cover any case when the
metadata is larger than just the PI tuple.

Signed-off-by: Caleb Sander Mateos <csander@purestorage.com>
Fixes: c546d6f43833 ("block: only zero non-PI metadata tuples in bio_integrity_prep")
Reviewed-by: Anuj Gupta <anuj20.g@samsung.com>
---
 block/bio-integrity-auto.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/block/bio-integrity-auto.c b/block/bio-integrity-auto.c
index 9850c338548d..cff025b06be1 100644
--- a/block/bio-integrity-auto.c
+++ b/block/bio-integrity-auto.c
@@ -138,11 +138,11 @@ bool bio_integrity_prep(struct bio *bio)
 		if (bi->flags & BLK_INTEGRITY_NOGENERATE) {
 			if (bi_offload_capable(bi))
 				return true;
 			set_flags = false;
 			gfp |= __GFP_ZERO;
-		} else if (bi->csum_type == BLK_INTEGRITY_CSUM_NONE)
+		} else if (bi->metadata_size > bi->pi_tuple_size)
 			gfp |= __GFP_ZERO;
 		break;
 	default:
 		return true;
 	}
-- 
2.45.2

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

[Christoph Hellwig]

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

[PATCH v2 2/3] block: replace gfp_t with bool in bio_integrity_prep()

[Caleb Sander Mateos]

Since commit ec7f31b2a2d3 ("block: make bio auto-integrity deadlock
safe"), the gfp_t gfp variable in bio_integrity_prep() is no longer
passed to an allocation function. It's only used to compute the
zero_buffer argument to bio_integrity_alloc_buf(). So change the
variable to bool zero_buffer to simplify the code.

Signed-off-by: Caleb Sander Mateos <csander@purestorage.com>
---
 block/bio-integrity-auto.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/block/bio-integrity-auto.c b/block/bio-integrity-auto.c
index cff025b06be1..605403b52c90 100644
--- a/block/bio-integrity-auto.c
+++ b/block/bio-integrity-auto.c
@@ -107,11 +107,11 @@ bool __bio_integrity_endio(struct bio *bio)
 bool bio_integrity_prep(struct bio *bio)
 {
 	struct blk_integrity *bi = blk_get_integrity(bio->bi_bdev->bd_disk);
 	struct bio_integrity_data *bid;
 	bool set_flags = true;
-	gfp_t gfp = GFP_NOIO;
+	bool zero_buffer = false;
 
 	if (!bi)
 		return true;
 
 	if (!bio_sectors(bio))
@@ -137,13 +137,14 @@ bool bio_integrity_prep(struct bio *bio)
 		 */
 		if (bi->flags & BLK_INTEGRITY_NOGENERATE) {
 			if (bi_offload_capable(bi))
 				return true;
 			set_flags = false;
-			gfp |= __GFP_ZERO;
-		} else if (bi->metadata_size > bi->pi_tuple_size)
-			gfp |= __GFP_ZERO;
+			zero_buffer = true;
+		} else {
+			zero_buffer = bi->metadata_size > bi->pi_tuple_size;
+		}
 		break;
 	default:
 		return true;
 	}
 
@@ -152,11 +153,11 @@ bool bio_integrity_prep(struct bio *bio)
 
 	bid = mempool_alloc(&bid_pool, GFP_NOIO);
 	bio_integrity_init(bio, &bid->bip, &bid->bvec, 1);
 	bid->bio = bio;
 	bid->bip.bip_flags |= BIP_BLOCK_INTEGRITY;
-	bio_integrity_alloc_buf(bio, gfp & __GFP_ZERO);
+	bio_integrity_alloc_buf(bio, zero_buffer);
 
 	bip_set_seed(&bid->bip, bio->bi_iter.bi_sector);
 
 	if (set_flags) {
 		if (bi->csum_type == BLK_INTEGRITY_CSUM_IP)
-- 
2.45.2

Re: [PATCH v2 2/3] block: replace gfp_t with bool in bio_integrity_prep()

[Anuj gupta]

Reviewed-by: Anuj Gupta <anuj20.g@samsung.com>

Re: [PATCH v2 2/3] block: replace gfp_t with bool in bio_integrity_prep()

[Christoph Hellwig]

On Thu, Jan 08, 2026 at 10:22:11AM -0700, Caleb Sander Mateos wrote:
> Since commit ec7f31b2a2d3 ("block: make bio auto-integrity deadlock
> safe"), the gfp_t gfp variable in bio_integrity_prep() is no longer
> passed to an allocation function. It's only used to compute the
> zero_buffer argument to bio_integrity_alloc_buf(). So change the
> variable to bool zero_buffer to simplify the code.
> 
> Signed-off-by: Caleb Sander Mateos <csander@purestorage.com>

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

[PATCH v2 3/3] block: use pi_tuple_size in bi_offload_capable()

[Caleb Sander Mateos]

bi_offload_capable() returns whether a block device's metadata size
matches its PI tuple size. Use pi_tuple_size instead of switching on
csum_type. This makes the code considerably simpler and less branchy.

Signed-off-by: Caleb Sander Mateos <csander@purestorage.com>
---
 block/bio-integrity-auto.c | 14 +-------------
 1 file changed, 1 insertion(+), 13 deletions(-)

diff --git a/block/bio-integrity-auto.c b/block/bio-integrity-auto.c
index 605403b52c90..626bbe17eb23 100644
--- a/block/bio-integrity-auto.c
+++ b/block/bio-integrity-auto.c
@@ -50,23 +50,11 @@ static bool bip_should_check(struct bio_integrity_payload *bip)
 	return bip->bip_flags & BIP_CHECK_FLAGS;
 }
 
 static bool bi_offload_capable(struct blk_integrity *bi)
 {
-	switch (bi->csum_type) {
-	case BLK_INTEGRITY_CSUM_CRC64:
-		return bi->metadata_size == sizeof(struct crc64_pi_tuple);
-	case BLK_INTEGRITY_CSUM_CRC:
-	case BLK_INTEGRITY_CSUM_IP:
-		return bi->metadata_size == sizeof(struct t10_pi_tuple);
-	default:
-		pr_warn_once("%s: unknown integrity checksum type:%d\n",
-			__func__, bi->csum_type);
-		fallthrough;
-	case BLK_INTEGRITY_CSUM_NONE:
-		return false;
-	}
+	return bi->metadata_size == bi->pi_tuple_size;
 }
 
 /**
  * __bio_integrity_endio - Integrity I/O completion function
  * @bio:	Protected bio
-- 
2.45.2

Re: [PATCH v2 3/3] block: use pi_tuple_size in bi_offload_capable()

[Anuj gupta]

Reviewed-by: Anuj Gupta <anuj20.g@samsung.com>

Re: [PATCH v2 3/3] block: use pi_tuple_size in bi_offload_capable()

[Christoph Hellwig]

On Thu, Jan 08, 2026 at 10:22:12AM -0700, Caleb Sander Mateos wrote:
> bi_offload_capable() returns whether a block device's metadata size
> matches its PI tuple size. Use pi_tuple_size instead of switching on
> csum_type. This makes the code considerably simpler and less branchy.
> 
> Signed-off-by: Caleb Sander Mateos <csander@purestorage.com>

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>

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

[Martin K. Petersen]

Caleb,

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

LGTM.

Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>

-- 
Martin K. Petersen

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

[Jens Axboe]

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

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

[Caleb Sander Mateos]

On Fri, Jan 9, 2026 at 5:57 AM Jens Axboe <axboe@kernel.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
>
>
>

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

[Jens Axboe]

On 1/9/26 9:29 AM, Caleb Sander Mateos wrote:
> On Fri, Jan 9, 2026 at 5:57 AM Jens Axboe <axboe@kernel.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

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

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

[Caleb Sander Mateos]

On Sat, Jan 10, 2026 at 9:21 AM Jens Axboe <axboe@kernel.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@kernel.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