This is an interesting one...
There is a use after free bug in the X config parser, which can be trivially
demonstrated by creating a config file with the first line being a comment and
the second line containing invalid syntax:
$ echo "#foo\nfoo" > custom_config
$ X -config custom_config
[...]
(++) Using config file: "custom_config"
(==) Using system config directory "/usr/X11R6/share/X11/xorg.conf.d"
Parse error on line 3 of section InputClass in file custom_config
"ßßßßßßßßon" is not a valid keyword in this section.
(EE)
Fatal server error:
(EE) no screens found(EE)
[...]
So part of the error message is reading 0xdf bytes, which are obviously from a
buffer which has been free'd.
Looking in /usr/xenocara/xserver/hw/xfree86/parser/scan.c, in xf86getToken(),
there is an XXX comment in the code mentioning that, (for some unspecified
reason), the configRBuf pointer value is being returned in xf86_lex_val.str
instead of a private copy being made, (as is done for, E.G. non-comment
strings).
The comment seems to imply that xf86addComment would handle this gracefully
and not free() the pointer, but clearly the pointer _is_ free'd and the
reasons behind this design choice rather than the seemingly more obvious way
of doing the same malloc and strcpy that is done for regular strings are not
clear.
Indeed, the following cludge does mitigate the issue and the 0xdf bytes
disappear:
--- scan.c Thu Oct 5 19:48:29 2023
+++ scan.c.cludge Thu Oct 5 20:07:06 2023
@@ -335,7 +335,8 @@
/* XXX no private copy.
* Use xf86addComment when setting a comment.
*/
- xf86_lex_val.str = configRBuf;
+ xf86_lex_val.str =malloc(4096);
+ strcpy(xf86_lex_val.str, configRBuf);
return COMMENT;
}
But presumably there was a reason that this wasn't done all along, so
hopefully maybe somebody who is more familiar with this code can come up with
the propper fix.
