[PATCH] x86: Avoid integer truncation with large cache sizes (bug 32470)

Florian Weimer fweimer@redhat.com
Tue Dec 17 18:30:28 GMT 2024


* Joseph Myers:

> On Tue, 17 Dec 2024, Florian Weimer wrote:
>
>> Some hypervisors report 1 TiB L3 cache size.  This results
>> in some variables incorrectly getting zeroed, causing crashes
>> in memcpy/memmove because invariants are violated.
>> 
>> Tested on i686-linux-gnu and x86_64-linux-gnu on bare metal, and on
>> x86_64-linux-gnu with bhyve reporting 1 TiB of L3 cache.
>
> This patch is using unsigned long int - what happens for x32 when the 
> hypervisor reports 1 TiB (or for that matter for i686 if reporting a 
> non-32-bit value is possible when executing in 32-bit mode)?  Would 
> uint64_t be better, or is it impossible to have a value that would be 
> truncated when executing for an ABI where long is 32-bit?

It's still consistent with the other computed values, which also use
unsigned long int.  Fixing this issue properly is rather involved.  For
example, sysconf returns long int, so we would have to clamp some of the
values as they are returned from sysconf if they are stored internally
as 64-bit variables.

Thanks,
Florian



More information about the Libc-alpha mailing list