Hello Evan,
Evan Silberman wrote on Tue, Jun 07, 2022 at 09:16:02PM -0700:
> With certain malformed markup, mandoc segfaults attempting to access
> fields on a null roff_node pointer at tag.c:102 in tag_put
[...]
> This may not be a minimal reproducer but
> hopefully it's reasonably close for debugging.
Thank you very much for the good report.
In general, reporting a mandoc crash by providing a real-world manual
page triggering it is fine. As long as the code is written by a human
or by some automatic man(7) code generator, it is usually reasonably
simple to figure out what is going on.
On the other hand, if people find a crash with a fuzzer, trying to
minimize the input (usually employing tools provided by the fuzzer
toolkit that was used) becomes really helpful. Fuzzers intentionally
generate gibberish, and that often makes it much more of a challenge
to unravel the flow of control.
The following commit (made both to OpenBSD and bsd.lv)
fixes the bug.
Yours,
Ingo
Log Message:
-----------
When looking for the next block to tag, we aren't interested in children
of the current block but really want the next block instead. This fixes
a segfault reported by Evan Silberman <evan at jklol dot net> on bugs@.
Modified Files:
--------------
mandoc:
mdoc_validate.c
Revision Data
-------------
Index: mdoc_validate.c
===================================================================
RCS file: /home/cvs/mandoc/mandoc/mdoc_validate.c,v
retrieving revision 1.390
retrieving revision 1.391
diff -Lmdoc_validate.c -Lmdoc_validate.c -u -p -r1.390 -r1.391
--- mdoc_validate.c
+++ mdoc_validate.c
@@ -1113,7 +1113,8 @@ post_tg(POST_ARGS)
/* Find the next node. */
n = mdoc->last;
for (nn = n; nn != NULL; nn = nn->parent) {
- if (nn->next != NULL) {
+ if (nn->type != ROFFT_HEAD && nn->type != ROFFT_BODY &&
+ nn->type != ROFFT_TAIL && nn->next != NULL) {
nn = nn->next;
break;
}
