Update of bug #61043 (project groff):
Category: None => Preprocessor grn
Severity: 3 - Normal => 4 - Important
Item Group: None => Incorrect behaviour
Status: None => In Progress
Assigned to: None => gbranden
_______________________________________________________
Follow-up Comment #1:
[comment #0 original submission:]
> Hi, I found some integer overflow bug in the source code of groff.
>
> In src/preproc/grn/hdb.cpp:189,
>
> 189 (void) fscanf(file, "%d", &len); /* text length */
> 190 (void) getc(file); /* eat blank */
> 191 txt = (char *) malloc((unsigned) len + 1);
>
> The program reads the value of len from an input file and calls malloc with
len + 1.
>
> If a maliciously crafted input that sets len to -1 is given, it will cause
an integer overflow, and allocation with 0 leads to buggy behavior like denial
of service.
Thank you for the report.
Using the grn from groff 1.22.4, if I contrive incorrect input, I get an error
diagnostic.
$ groff -ww -g -me gremlin.me >| gremlin.ps
grn: fatal error: unknown element type
Here are my input files.
$ cat gremlin.me
.GS
roman 1
italics 2
bold 3
special 4
narrow 1
medium 3
thick 5
width 5.5
l mg
file gremlin.g
.GE
$ cat gremlin.g
sungremlinfile
1 0.0 0.0
CENTCENT
5.0 5.0
*
1 1
-1 Savannah
-1
The second to last line, "-1 Savannah", is the culprit. It should read "8
Savannah". (There are many other valid possibilities.)
However, if I change "Savannah" to another ASCII string, I can in fact provoke
an infinite loop.
I'm looking into this.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?61043>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
