From 8fc9902bbb0d48c75fe33627641f14c9c3e09e25 Mon Sep 17 00:00:00 2001 From: Nico Weber Date: Sun, 21 Apr 2019 16:58:25 +0000 Subject: llvm-undname: Fix stack overflow on almost-valid If a unsigned with all 4 bytes non-0 was passed to outputHex(), there were two off-by-ones in it: - Both MaxPos and Pos left space for the final \0, which left the buffer one byte to small. Set MaxPos to 16 instead of 15 to fix. - The `assert(Pos >= 0);` was after a `Pos--`, move it up one line. Since valid Unicode codepoints are <= 0x10ffff, this could never really happen in practice. Found by oss-fuzz. llvm-svn: 358856 --- llvm/test/Demangle/ms-string-literals.test | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'llvm/test') diff --git a/llvm/test/Demangle/ms-string-literals.test b/llvm/test/Demangle/ms-string-literals.test index 2fe3384fe74..7ba6b48e6ae 100644 --- a/llvm/test/Demangle/ms-string-literals.test +++ b/llvm/test/Demangle/ms-string-literals.test @@ -781,3 +781,13 @@ ??_C@_0CC@MBPKDIAM@a?$AA?$AA?$AAb?$AA?$AA?$AAc?$AA?$AA?$AAd?$AA?$AA?$AAe?$AA?$AA?$AAf?$AA?$AA?$AAg?$AA?$AA?$AAh?$AA?$AA?$AA@ ; CHECK: u"a\0b\0c\0d\0e\0f\0g\0h\0"... + +; This is technically not a valid u32 string since the character in it is not +; <= 0x10FFFF like unicode demands. (Also, the crc doesn't match the contents.) +; It's here because this input used to cause a stack overflow in outputHex(). + +; FIXME: The demangler currently writes for \x codes for a single U string +; character. That's incorrect since that would mangle two four characters. + +??_C@_07LJGFEJEB@D3?$CC?$BB?$AA?$AA?$AA?$AA@) +; CHECK: U"\x11\x22\x33\x44" -- cgit v1.2.3