On 2025-10-20 10:16, Daniel Kiper wrote:
> On Fri, Oct 17, 2025 at 05:23:48PM -0600, Logan Gunthorpe via Grub-devel 
> wrote:
>> My read is that unless we are dealing with files greater than the two
>> offsets are 64bits and unlikely to ever see a file that doesn't fit.
> 
> First of all, please remember that the GRUB can be compiled for 32-bit
> targets. So, zstdio->output.size can be 32-bit...

Yes, but zstdio->output.size is always less than the relatively small
buffer size returned by ZSTD_DStreamOutSize ().

The only values that could conceivably be larger than 32-bits are the
offsets within the file which are of type grup_off_t, which is a typedef
of grub_uint64_t and, by my read of the code, it looks like it should be
64-bits on all platforms.

>> len is going to be the size of a memory buffer and ret is going to be
>> less than or equal to ret. So it doesn't seem like an overflow is possible.
> 
> I think you meant "less than or equal to len"...

Yes, sorry.

> I am not saying I disagree. I rather have some reservations. However, if
> you convince me it is not possible or it is very difficult to blow up
> this code using malformed zstd archives than I am OK with it.

I'm just worried the change is a bit tricky to get right needing to
convert it to a string of grub_add() calls. And the conversion seems
risky especially given the existing code it was copied from has been
around for a while without issue (as far as I'm aware).


> PS I am going to cut GRUB 2.14~rc1 in second half of the week. So, it
>    would be nice to have these patches before that...
Ok, well except for this issue I should be good to send the next version
today or, at worst tomorrow.

Thanks,

Logan

_______________________________________________
Grub-devel mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/grub-devel

Reply via email to