Integer overflow in wcswidth

[Florian Weimer <fweimer at redhat dot com>]

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