[librsvg/librsvg-2.42: 3/8] Add comment on limits for mitigating attacks

[Federico Mena Quintero <federico src gnome org>]

commit 56696f2db7bcd56ba3d4652af20295679aebcb36
Author: Federico Mena Quintero <federico gnome org>
Date:   Tue Feb 25 10:48:10 2020 -0600

    Add comment on limits for mitigating attacks

 librsvg/rsvg-base.c | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)
---
diff --git a/librsvg/rsvg-base.c b/librsvg/rsvg-base.c
index 47b75982..039fbf9e 100644
--- a/librsvg/rsvg-base.c
+++ b/librsvg/rsvg-base.c
@@ -1647,6 +1647,29 @@ rsvg_drawing_ctx_increase_num_elements_acquired (RsvgDrawingCtx *draw_ctx)
     draw_ctx->num_elements_acquired++;
 }
 
+/* This is a mitigation for the security-related bugs:
+ * https://gitlab.gnome.org/GNOME/librsvg/issues/323
+ * https://gitlab.gnome.org/GNOME/librsvg/issues/515
+ * 
+ * Imagine the XML [billion laughs attack], but done in SVG's terms:
+ * 
+ * - #323 above creates deeply nested groups of `<use>` elements.
+ * The first one references the second one ten times, the second one
+ * references the third one ten times, and so on.  In the file given,
+ * this causes 10^17 objects to be rendered.  While this does not
+ * exhaust memory, it would take a really long time.
+ * 
+ * - #515 has deeply nested references of `<pattern>` elements.  Each
+ * object inside each pattern has an attribute
+ * fill="url(#next_pattern)", so the number of final rendered objects
+ * grows exponentially.
+ * 
+ * We deal with both cases by placing a limit on how many references
+ * will be resolved during the SVG rendering process, that is,
+ * how many `url(#foo)` will be resolved.
+ * 
+ * [billion laughs attack]: https://bitbucket.org/tiran/defusedxml
+ */
 static gboolean
 limits_exceeded (RsvgDrawingCtx *draw_ctx)
 {