ListFileLexer: fix heap-buffer-overflow on malicious input

In case a list file contains a null terminated string that is continued
until a later space, the lexer token information got inconsistent:

e.g. an argument   "TEST\0FOOBAR"    is passed by the lexer as a token

char* = "TEST\0FOOBAR" and length 11
             ^^ note: ascii 0x00

Using strdup in cmListFileLexer leads lexer->token.text to be allocated
with size 5 and lexer->token.length to be set to 11

A subsequent call to this function with an argument of  5 < length <= 11
wrongly assumed a sufficiently sized buffer and therefore corrupted the
heap buffer. The program might crash due to this corruption.
The case "NullTerminatedArgument" is intentionally using a quite large
'rest' to increase the chance to actually hit the issue. It will reliably
crash with address sanitizer enabled though.

This fix addresses all rules where arbitrary characters are matched to
ignore \0 in order to fall through to the rule that matches an arbitrary
character as BadCharacter.

Signed-off-by: Matthias Maennich <matthias@maennich.net>

1 files changed, 1 insertions, 0 deletions

diff --git a/Tests/RunCMake/Syntax/NullTerminatedArgument-result.txt b/Tests/RunCMake/Syntax/NullTerminatedArgument-result.txt
new file mode 100644
index 0000000..d00491f
--- /dev/null
+++ b/Tests/RunCMake/Syntax/NullTerminatedArgument-result.txt
@@ -0,0 +1 @@
+1