Re: [xml] https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=43743
On Mon, Jun 27, 2022 at 6:14 AM Nick Wellnhofer wrote: > On 24/06/2022 21:48, enh via xml wrote: > > did anyone report > https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=43743 > > <https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=43743> to > libxml2 directly? > > No, this wasn't reported. For now, these issues should be reported to the > libxml2 bug tracker. That said, I will resubscribe to OSS-Fuzz soon and > handle > new issues directly. > (sorry, your reply got stuck in gmail's spam filter :-( ) heh, the reason i found this in my spam filter is that i was hassling our oss-fuzz people and asking why they were only sending these bugs to a bunch of browser vendors rather than to you, who might actually be able to do something about them, and they wanted me to ask you whether you wanted to be in the config. sounds like you're already on top of things and they'll get their pull request when you have time anyway :-) > > sadly, it looks like there are actually a bunch of fuzzer-found bugs > that may > > never have been reported upstream? (i haven't checked; i'm just > guessing.) see > > https://bugs.chromium.org/p/oss-fuzz/issues/list?q=libxml2=2 > > <https://bugs.chromium.org/p/oss-fuzz/issues/list?q=libxml2=2> for > example. > > Most of the timeout and OOM issues are hard to fix. I'll try to address > some > of them in the next months. > yeah, the ones that get me (with Android non-third-party code where i have to _fix_ things rather than just cherrypick other people's fixes) are the stack overflows on large inputs. i really need to find out how to tell the _fuzzer_ i don't care rather than having to close bugs manually all the time! > Nick > ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org https://mail.gnome.org/mailman/listinfo/xml
[xml] https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=43743
did anyone report https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=43743 to libxml2 directly? i work on Android and was asked about this bug recently, and will try to improve the channel for reporting fuzzer-found libxml2 bugs like this going forward, but for now (since the secrecy deadline on that one has expired anyway), i can at least point you in that direction. sadly, it looks like there are actually a bunch of fuzzer-found bugs that may never have been reported upstream? (i haven't checked; i'm just guessing.) see https://bugs.chromium.org/p/oss-fuzz/issues/list?q=libxml2=2 for example. i assume you've seen these kinds of bugs before, but let me know if you have trouble with the reproducers ... not that i can ever remember how to do it myself, but i can find someone who definitely does know :-) ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org https://mail.gnome.org/mailman/listinfo/xml
Re: [xml] [PATCH] Fix xmlURIEscape memory leaks.
thanks! took a while for the fuzzing infrastructure to catch up, but it's looking good now. hopefully you won't hear from me again, but i'll be back with another patch if the fuzzers find anything else :-) On Mon, Nov 9, 2020 at 9:32 AM Nick Wellnhofer wrote: > > Merged here: > https://gitlab.gnome.org/GNOME/libxml2/-/commit/7c06d99e1f4f853e3c5b307c0dc79c8a32a09855 > > Nick > > On 27/10/2020 19:33, enh via xml wrote: > > Found by running the fuzz/uri.c fuzzer under asan (internal Android bug > > 171610679). > > > > Always free `ret` when exiting on failure. I've moved the definition of > > NULLCHK down past where ret is always initialized to make it clear that > > this is safe. > > > > This patch also fixes the indentation of two of the NULLCHK call sites > > to make it more obvious that NULLCHK isn't `if`-like. > > --- > > uri.c | 17 + > > 1 file changed, 9 insertions(+), 8 deletions(-) ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org https://mail.gnome.org/mailman/listinfo/xml
Re: [xml] [PATCH] Fix xmlURIEscape memory leaks.
Awesome... Just wanted to check I was in the right place. Thanks! On Fri, Nov 6, 2020, 02:31 Nick Wellnhofer wrote: > On 06/11/2020 00:54, enh via xml wrote: > > ping? > > > > (let me know if this should be a pull request somewhere instead...) > > Sending patches to the mailing list is fine. It might take another week or > two, but the issue will be addressed eventually. > > Nick > ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org https://mail.gnome.org/mailman/listinfo/xml
Re: [xml] [PATCH] Fix xmlURIEscape memory leaks.
ping? (let me know if this should be a pull request somewhere instead...) On Tue, Oct 27, 2020 at 11:33 AM enh wrote: > > Found by running the fuzz/uri.c fuzzer under asan (internal Android bug > 171610679). > > Always free `ret` when exiting on failure. I've moved the definition of > NULLCHK down past where ret is always initialized to make it clear that > this is safe. > > This patch also fixes the indentation of two of the NULLCHK call sites > to make it more obvious that NULLCHK isn't `if`-like. > --- > uri.c | 17 + > 1 file changed, 9 insertions(+), 8 deletions(-) ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org https://mail.gnome.org/mailman/listinfo/xml
[xml] [PATCH] Fix xmlURIEscape memory leaks.
Found by running the fuzz/uri.c fuzzer under asan (internal Android bug
171610679).
Always free `ret` when exiting on failure. I've moved the definition of
NULLCHK down past where ret is always initialized to make it clear that
this is safe.
This patch also fixes the indentation of two of the NULLCHK call sites
to make it more obvious that NULLCHK isn't `if`-like.
---
uri.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
From d012eb80e53a31198b2eb9ab6bc109835b060611 Mon Sep 17 00:00:00 2001
From: Elliott Hughes
Date: Tue, 27 Oct 2020 11:29:20 -0700
Subject: [PATCH] Fix xmlURIEscape memory leaks.
Found by running the fuzz/uri.c fuzzer under asan (internal Android bug
171610679).
Always free `ret` when exiting on failure. I've moved the definition of
NULLCHK down past where ret is always initialized to make it clear that
this is safe.
This patch also fixes the indentation of two of the NULLCHK call sites
to make it more obvious that NULLCHK isn't `if`-like.
---
uri.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/uri.c b/uri.c
index 7e9a9f44..8204825f 100644
--- a/uri.c
+++ b/uri.c
@@ -1754,11 +1754,6 @@ xmlURIEscape(const xmlChar * str)
xmlURIPtr uri;
int ret2;
-#define NULLCHK(p) if(!p) { \
- xmlURIErrMemory("escaping URI value\n"); \
- xmlFreeURI(uri); \
- return NULL; } \
-
if (str == NULL)
return (NULL);
@@ -1780,6 +1775,12 @@ xmlURIEscape(const xmlChar * str)
ret = NULL;
+#define NULLCHK(p) if(!p) { \
+ xmlURIErrMemory("escaping URI value\n"); \
+ xmlFreeURI(uri); \
+ xmlFree(ret); \
+ return NULL; } \
+
if (uri->scheme) {
segment = xmlURIEscapeStr(BAD_CAST uri->scheme, BAD_CAST "+-.");
NULLCHK(segment)
@@ -1800,7 +1801,7 @@ xmlURIEscape(const xmlChar * str)
if (uri->user) {
segment = xmlURIEscapeStr(BAD_CAST uri->user, BAD_CAST ";:&=+$,");
NULLCHK(segment)
- ret = xmlStrcat(ret,BAD_CAST "//");
+ret = xmlStrcat(ret,BAD_CAST "//");
ret = xmlStrcat(ret, segment);
ret = xmlStrcat(ret, BAD_CAST "@");
xmlFree(segment);
@@ -1809,8 +1810,8 @@ xmlURIEscape(const xmlChar * str)
if (uri->server) {
segment = xmlURIEscapeStr(BAD_CAST uri->server, BAD_CAST "/?;:@");
NULLCHK(segment)
- if (uri->user == NULL)
- ret = xmlStrcat(ret, BAD_CAST "//");
+if (uri->user == NULL)
+ret = xmlStrcat(ret, BAD_CAST "//");
ret = xmlStrcat(ret, segment);
xmlFree(segment);
}
--
2.29.0.rc2.309.g374f81d7ae-goog
___
xml mailing list, project page http://xmlsoft.org/
xml@gnome.org
https://mail.gnome.org/mailman/listinfo/xml
