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.
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=aab32aa9e7a 35745713875b7fd fafbefcb31632c; hb=9e2ff880f3cb c0b4ec8505ad2ce 4a1c92d7f6d56# l85