linux-kernel - Re: [PATCH] block: set bi

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: <87r03vfpkm.fsf@kernel.org>
Date: Tue, 18 Feb 2025 12:40:57 +0100
From: Andreas Hindborg <a.hindborg@...nel.org>
To: "John Garry" <john.g.garry@...cle.com>
Cc: "Jens Axboe" <axboe@...nel.dk>,  "Oliver Mangold"
 <oliver.mangold@...me>,  <linux-block@...r.kernel.org>,
  <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] block: set bi_vcnt when cloning bio

"John Garry" <john.g.garry@...cle.com> writes:

> On 15/02/2025 10:58, Andreas Hindborg wrote:
>> When cloning a bio, the `bio.bi_vcnt` field is not cloned. This is a
>> problem if users want to perform bounds checks on the `bio.bi_io_vec`
>> field.
>
> Is this fixing a potential problem? Or fixing a real issue?

It is fixing a problem I ran into in rnull, the rust null block
implementation. When running with debug assertions enabled, a bound
check on `bi_io_vec` fails for split bio, because `bio_vcnt` becomes
zero in the cloned bio.

I can work around this by not using a slice type to represent
`bi_io_vec` in rust, not a big deal.

But I am genuinely curious if there is a reason for not setting
`bi_vcnt` during a clone. As far as I can tell, it should be safe to
set. `bi_vcnt` being zero does not seem to have any effect other than to
puzzle developers debugging the code.

Maybe I missed something?

Best regards,
Andreas Hindborg