Closed vuori closed 3 years ago
vuori notifications@github.com wrote:
FontAwesome version 5 contains glyph names which are longer than
GNLEN
(32). This causes astrcpy
buffer overflow infont_glyphput
.Fix for the immediate problem is to increase
GNLEN
, but perhaps checking the length and skipping the offending glyph with a warning would be nice here?
Now Neatpost truncates glyph names at GNLEN, like Neatroff. Also, Neatmkfn warns if glyph names are truncated.
AFAIK, glyph names in OTF are limited to 64 bytes. Maybe we should increase GNLEN?
Ali
Upping to 64 sounds good, that's what I set it to off the cuff. The offending FontAwesome glyph was called american-sign-language-interpreting
(35 bytes).
vuori notifications@github.com wrote:
Upping to 64 sounds good, that's what I set it to off the cuff. The offending FontAwesome glyph was called
american-sign-language-interpreting
(35 bytes).
Increasing GNLEN would probably increase Neatroff's memory usage noticeably. If such glyphs appear rarely, maybe we can safely let GNLEN remain 32. We can also remove ILNLEN. Please test the following patch.
Thanks, Ali
diff --git a/dev.c b/dev.c index 10a6783..469fb79 100644 --- a/dev.c +++ b/dev.c @@ -77,7 +77,7 @@ int dev_mnt(int pos, char id, char name) int dev_open(char dir, char dev) { char path[PATHLEN];
while (fscanf(desc, "%128s", tok) == 1) if (!strcmp("0", tok)) break; continue; diff --git a/dir.c b/dir.c index af65222..d4cbd13 100644 --- a/dir.c +++ b/dir.c @@ -77,7 +77,7 @@ static void setcolor(int m)
void dir_fix(struct sbuf sbuf, char src) {
if (fscanf(fin, "%128s", tok) != 1) return 1; col = strchr(tok, ':'); if (col) @@ -523,12 +523,12 @@ static int font_readgpos(struct font fn, FILE fin)
static int font_readggrp(struct font fn, FILE fin) {
if (fscanf(fin, GNFMT, tok) != 1) return 1; g = font_idx(fn, font_glyph(fn, tok)); if (g >= 0) @@ -539,10 +539,10 @@ static int font_readggrp(struct font fn, FILE fin)
static int font_readkern(struct font fn, FILE fin) {
while (fscanf(fin, "%128s", tok) == 1) { if (!strcmp("char", tok)) { font_readchar(fn, fin, &ch_n, &ch_g); } else if (!strcmp("kern", tok)) { diff --git a/hyph.c b/hyph.c index 64e602e..da0b973 100644 --- a/hyph.c +++ b/hyph.c @@ -296,7 +296,7 @@ void hyphenate(char hyph, char word, int flg)
void tr_hpfa(char **args) {
while (fscanf(filp, "%128s", tok) == 1) { char s = tok; if (utf8read(&s, c1) && utf8read(&s, c2) && !s) hcode_add(c2, c1); / inverting / diff --git a/roff.h b/roff.h index 9c4472f..c81b496 100644 --- a/roff.h +++ b/roff.h @@ -28,10 +28,10 @@
+#define GNFMT "%32s" / glyph name scanf format /
-#define ILNLEN 1000 / line limit of input files /
diff --git a/sbuf.c b/sbuf.c index f03ddd6..426c83f 100644 --- a/sbuf.c +++ b/sbuf.c @@ -38,7 +38,7 @@ void sbuf_append(struct sbuf sbuf, char s)
void sbuf_printf(struct sbuf sbuf, char s, ...) {
After applying the patch to neatroff and reverting the increase to GNLEN
in neatpost, I'm still seeing the crash with a long glyph name:
#6 0x000055555555c3bd in strcpy (__src=0x7fffffffd520 "american-sign-language-interpreting", __dest=<optimized out>)
at /usr/include/x86_64-linux-gnu/bits/string_fortified.h:90
#7 font_glyphput (type=3, name=0x7fffffffd130 "", id=0x7fffffffd520 "american-sign-language-interpreting", fn=0x5555558d9400)
at font.c:44
vuori notifications@github.com wrote:
After applying the patch to neatroff and reverting the increase to
GNLEN
in neatpost, I'm still seeing the crash with a long glyph name:#6 0x000055555555c3bd in strcpy ( src=0x7fffffffd520 "american-sign-language-interpreting", dest=<optimized out>) at /usr/include/x86 64-linux-gnu/bits/string fortified.h:90 #7 font glyphput (type=3, name=0x7fffffffd130 "", id=0x7fffffffd520 "american-sign-language-interpreting", fn=0x5555558d9400) at font.c:44
I have updated both Neatroff and Neatpost (no need for the patch anymore). Please test it once more. Do you get the same result?
Thanks, Ali
Working with the latest changes, thanks.
FontAwesome version 5 contains glyph names which are longer than
GNLEN
(32). This causes astrcpy
buffer overflow infont_glyphput
.Fix for the immediate problem is to increase
GNLEN
, but perhaps checking the length and skipping the offending glyph with a warning would be nice here?