Integer overflow in wcswidth
Florian Weimer
fweimer@redhat.com
Mon Sep 19 10:04:00 GMT 2016
There is a new paper out there, âTwice the Bits, Twice the Trouble:
Vulnerabilities Induced by Migrating to 64-Bit Platformsâ by Wressnegger
et al. In points out that wcswidth has a âdormant integer overflowâ and
continues,
â
As the input string might be larger than INT_MAX on 64-bit systems,
processing the complete string overflows the counter. With a string
longer than UINT_MAX the return value wraps around to a positive number
again, such that using this value for memory allocations inevitable
results in a buffer overflow.
â
This appears to be based on a misunderstanding what wcswidth does (and
the semantics of C integer overflow, but let's assume they are
describing the generated machine code in C terms). It is not an alias
for wcsnlen. The returned value does not correspond to an array or
buffer size, but intends to reflect the length of the string when
printed to the terminal. Consequently, input characters can contribute
0, 1 or 2 character widths to the result. An application which uses the
return value of wcswidth for a memory allocation will always be buggy
because zero-width characters such as combining characters still carry
semantic value.
But in the end, this interface is just broken (we can't even report and
EOVERFLOW error). Maybe we should add a compile-time warning if the
function is used. Applications can just call wcwidth in a loop, which
does not have this issue.
Florian
More information about the Libc-alpha
mailing list