Re: [PATCH v2 2/2] hfs/hfsplus: zero-initialize buffer in hfs_bnode_read

[Viacheslav Dubeyko <vdubeyko@redhat.com>]

On Thu, 2026-05-07 at 16:37 +0000, Tristan Madani wrote:
> On Wed, 2026-05-06 at 12:23 -0700, Viacheslav Dubeyko wrote:
> > We are returning back to the same my question. What if the caller of
> > hfs_bnode_read() provides the len == 0 somehow but the buffer has not zero size
> > on the caller side? I assume that memset() will do nothing and the buffer still
> > be not initialized. Am I correct here?
> 
> You are correct that memset(buf, 0, 0) is a no-op. But if the caller
> passes len == 0, it is asking to read zero bytes -- it should not
> expect the function to initialize anything beyond that.
> 
> The bug this fixes is different: callers pass a non-zero len (e.g.
> hfs_bnode_read_u16 passes 2, hfs_bnode_read_u8 passes 1), but
> check_and_correct_requested_length() internally reduces the effective
> read to 0 due to a corrupted image. The memset runs with the original
> caller-supplied len before any internal validation, so the buffer is
> already zeroed by the time the early-return happens.
> 
> No current caller passes len == 0 -- hfs_bnode_read_u16() always
> passes 2, hfs_bnode_read_u8() always passes 1, and hfs_bnode_read_key()
> passes a key_len that is validated against the btree key size.
> 

OK. I think I can agree with you. If we have len == 0 as input argument, then we
have:

if (len == 0) {
<skipped>
   return;
}

And if check_and_correct_requested_length() corrects the len to 0:

len = check_and_correct_requested_length(node, off, len);

then loop will do nothing because of len == 0:

for (bytes_read = 0; bytes_read < len; bytes_read += bytes_to_read) {
<skipped>
}

Thanks,
Slava.