Comment 6 for bug 2011326

Revision history for this message
Simon Chopin (schopin) wrote (last edit ):

A related bug is that one: https://bugs.launchpad.net/ubuntu/+source/notcurses/+bug/2008108

I've raised the issue upstream: https://sourceware.org/pipermail/libc-alpha/2023-March/146343.html

Note that even though I technically asked the question "should we fix it?", my personal conviction is that it's not worth it. The issue triggers whenever the given size overflows the address space, which happens there because stack addressed are around 0xffxxxxxx in 32-bit architectures, so INT_MAX would overflow. Switch the buffer to a heap-allocated one, and the issue disappears.

You can reproduce it on other architectures by substituting INT_MAX with ~(size_t)buf+1, which should overflow the address space by 1.

IMHO both the notcurses and cyrus-imapd authors are abusing the API in a way that's just broken and doesn't actually translate the (apparent) intent, which is to say "just write as far as you can". Which would of course be better served by simply using sprintf.

The code responsible for the truncature is there: https://sourceware.org/git/?p=glibc.git;a=blob;f=libio/vsnprintf.c;h=aab32aa9e7a35745713875b7fdfafbefcb31632c;hb=9e2ff880f3cbc0b4ec8505ad2ce4a1c92d7f6d56#l85