File graphviz-out-of-bounds-write.patch of Package graphviz.20622

Overview Repositories Revisions Requests Users Attributes Meta

File graphviz-out-of-bounds-write.patch of Package graphviz.20622

From 784411ca3655c80da0f6025ab20634b2a6ff696b Mon Sep 17 00:00:00 2001
From: Matthew Fernandez <matthew.fernandez@gmail.com>
Date: Sat, 25 Jul 2020 19:31:01 -0700
Subject: [PATCH] fix: out-of-bounds write on invalid label

When the label for a node cannot be parsed (due to it being malformed), it falls
back on the symbol name of the node itself. I.e. the default label the node
would have had if it had no label attribute at all. However, this is applied by
dynamically altering the node's label to "\N", a shortcut for the symbol name of
the node. All of this is fine, however if the hand written label itself is
shorter than the literal string "\N", not enough memory would have been
allocated to write "\N" into the label text.

Here we account for the possibility of error during label parsing, and assume
that the label text may need to be overwritten with "\N" after the fact. Fixes
issue #1700.
---
 lib/common/shapes.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/lib/common/shapes.c b/lib/common/shapes.c
index 0a0635fc3..9dca9ba6e 100644
--- a/lib/common/shapes.c
+++ b/lib/common/shapes.c
@@ -3546,9 +3546,10 @@ static void record_init(node_t * n)
     reclblp = ND_label(n)->text;
     len = strlen(reclblp);
     /* For some forgotten reason, an empty label is parsed into a space, so
-     * we need at least two bytes in textbuf.
+     * we need at least two bytes in textbuf, as well as accounting for the
+     * error path involving "\\N" below.
      */
-    len = MAX(len, 1);
+    len = MAX(MAX(len, 1), (int)strlen("\\N"));
     textbuf = N_NEW(len + 1, char);
     if (!(info = parse_reclbl(n, flip, TRUE, textbuf))) {
 	agerr(AGERR, "bad label format %s\n", ND_label(n)->text);
--

Places

File graphviz-out-of-bounds-write.patch of Package graphviz.20622

Places