Fedora has issued an advisory on May 4: https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/FI3D5TQE3IMCSF5OUTXQL4GVKFCIY5JG/ The RedHat bug has a link to the upstream commit that fixed the issue: https://bugzilla.redhat.com/show_bug.cgi?id=1699848 Mageia 7 is also affected.
Whiteboard: (none) => MGA7TOO
This RPM has no maintainer, so assigning globally.
Assignee: bugsquad => pkg-bugs
Suggested advisory: ======================== The updated packages fix a security vulnerability: The agroot() function in cgraph\obj.c in libcgraph.a in Graphviz 2.39.20160612.1140 has a NULL pointer dereference, as demonstrated by graphml2gv. (CVE-2019-11023) References: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11023 https://bugzilla.redhat.com/show_bug.cgi?id=1699848 https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/FI3D5TQE3IMCSF5OUTXQL4GVKFCIY5JG/ ======================== Updated packages in core/updates_testing: ======================== graphviz-2.40.1-17.1.mga7 graphviz-doc-2.40.1-17.1.mga7 lib(64)cdt5-2.40.1-17.1.mga7 lib(64)cgraph6-2.40.1-17.1.mga7 lib(64)lab_gamut1-2.40.1-17.1.mga7 lib(64)gvc6-2.40.1-17.1.mga7 lib(64)gvpr2-2.40.1-17.1.mga7 lib(64)pathplan4-2.40.1-17.1.mga7 lib(64)xdot4-2.40.1-17.1.mga7 lua-graphviz-2.40.1-17.1.mga7 php-graphviz-2.40.1-17.1.mga7 python2-graphviz-2.40.1-17.1.mga7 ruby-graphviz-2.40.1-17.1.mga7 perl-graphviz-2.40.1-17.1.mga7 tcl-graphviz-2.40.1-17.1.mga7 java-graphviz-2.40.1-17.1.mga7 ocaml-graphviz-2.40.1-17.1.mga7 lib(64)graphviz-devel-2.40.1-17.1.mga7 from SRPMS: graphviz-2.40.1-17.1.mga7.src.rpm
Whiteboard: MGA7TOO => (none)CVE: (none) => CVE-2019-11023Version: Cauldron => 7Status: NEW => ASSIGNEDAssignee: pkg-bugs => qa-bugsCC: (none) => nicolas.salguero
MGA7-64 Plasma on Lenovo B50 No installation issues at first. Reading thru bug 23133 (tx Len) up to Comment 10, checked xterm package. This wa not installed, installed it, and downloaded Len's attachment example.gv Then at CLI: $ vimdot example.gv giving vim output digraph test123 { a -> b -> c; a -> {x y}; b [shape = box]; c [label = "Hello\nWorld", color=blue, fontsize=24, fontname="Palatino Italic", fontcolor=red, style=filled]; a -> z [label="hi", weight=100]; etc ...... and a graph of a "Hello World" example. So looks good at the end, but shouldn't xterm then be a dependency for graphviz??
CC: (none) => herman.viaene
Thanks for path-finding on this Herman. Time to put it to bed. graphviz rang no bells, not even a distant tinkle, so your backpointer to bug #23133 is much appreciated. Not sure how xterm is involved in this. An xterm is very basic indeed but the term is often used in a generic sense so mate-terminal or konsole should do the job just as well. There is a reproducer for the null pointer dereference. CVE-2019-11023 https://gitlab.com/graphviz/graphviz/issues/1517 Before update: $ graphml2gv -g cooldude -o test.gv NP Segmentation fault (core dumped) test.gv is empty. Updated all the packages. Ran the POC again to demonstrate that the segfault had been avoided. $ graphml2gv -g cooldude -o test.gv NP node n2 outside graph, ignored node n3 outside graph, ignored node n4 outside graph, ignored node n5 outside graph, ignored mismatched tag at line 23 $ vimdot test.gv now displays a graph with five nodes. Documentation at https://graphviz.gitlab.io/documentation/ Layout engines like neato, lefty and dotty are available. Here we are! lefty run against example.gv, the "Hello World" demo, invokes what looks like an xterm window. So there is a background dependency on xterm by the look of it but presumably it comes with lefty. Downloaded the demo.c script which appears to be a template for the layout engines. There are wrappers for development which provide APIs for scripting languages such as perl, java, python, ruby, php and tcl. After a lot of poking around finally figured out how to compile demo.c. $ gcc -o demo demo.c `pkg-config --libs --cflags /usr/lib64/pkgconfig/libgvc.pc` $ mv demo neato $ ./neato example.gv digraph g { graph [bb="0,0,125.21,46.639"]; node [label="\N"]; n [color=red, height=0.5, pos="27,28.639", width=0.75]; m [height=0.5, pos="98.21,18", width=0.75]; n -> m [pos="e,71.434,22 53.516,24.677 56.076,24.295 58.704,23.902 61.341,23.508"]; } Not sure what that demonstrates apart from the fact that the API is working. With reference to Herman's test and this investigation these packages should be let loose.
CC: (none) => tarazed25Whiteboard: (none) => MGA7-64-OK
CC: (none) => tmb, sysadmin-bugsKeywords: (none) => advisory, validated_update
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2019-0305.html
Status: ASSIGNED => RESOLVEDResolution: (none) => FIXED