llvm.org GIT mirror llvm / f6b23df
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@358856 91177308-0d34-0410-b5e6-96231b3b80d8 Nico Weber 1 year, 7 months ago
2 changed file(s) with 14 addition(s) and 4 deletion(s). Raw diff Collapse all Expand all
10701070 char TempBuffer[17];
10711071
10721072 ::memset(TempBuffer, 0, sizeof(TempBuffer));
1073 constexpr int MaxPos = 15;
1074
1075 int Pos = MaxPos - 1;
1073 constexpr int MaxPos = sizeof(TempBuffer) - 1;
1074
1075 int Pos = MaxPos - 1; // TempBuffer[MaxPos] is the terminating \0.
10761076 while (C != 0) {
10771077 for (int I = 0; I < 2; ++I) {
10781078 writeHexDigit(&TempBuffer[Pos--], C % 16);
10791079 C /= 16;
10801080 }
10811081 TempBuffer[Pos--] = 'x';
1082 assert(Pos >= 0);
10821083 TempBuffer[Pos--] = '\\';
1083 assert(Pos >= 0);
10841084 }
10851085 OS << StringView(&TempBuffer[Pos + 1]);
10861086 }
780780
781781 ??_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@
782782 ; CHECK: u"a\0b\0c\0d\0e\0f\0g\0h\0"...
783
784 ; This is technically not a valid u32 string since the character in it is not
785 ; <= 0x10FFFF like unicode demands. (Also, the crc doesn't match the contents.)
786 ; It's here because this input used to cause a stack overflow in outputHex().
787
788 ; FIXME: The demangler currently writes for \x codes for a single U string
789 ; character. That's incorrect since that would mangle two four characters.
790
791 ??_C@_07LJGFEJEB@D3?$CC?$BB?$AA?$AA?$AA?$AA@)
792 ; CHECK: U"\x11\x22\x33\x44"