You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Onig has several leaks when an invalid pattern is passed and the parser returns an error.
Here are 3 patterns we use in our tests:
"[ab+"
"[ab]+"
"(\d:"
Each one causes a different parse error, respectively:
-103
-104
-117
And each one results in leaks as reported by GCC 5.4 and ASAN/LSAN (on Ubuntu 16.04 with all patches applied).
Here are 2 examples. I traced the first example by breaking on the only instance of ONIGERR_PREMATURE_END_OF_CHAR_CLASS in regparse.c and stepping out from there.
The root problem seems to be in parse_exp() where some return paths cause the 'qn' node to leak. I do not know the exact paths as I was stepping out from the error point.
In the 1st case below, the allocation of 'qn' occurs in the 'repeat' goto on line 5165 (frame 3). Then in the TK_CC_OPEN case handler in parse_exp() when parse_char_class() fails, parse_exp() immediately returns at that point leaking a live 'qn' allocation.
These leaks should be fixed as they could cause issues with a long running app that allows users to enter random patterns of their own (through UI or through a config file).
For our tests too, these leaks cause test harness failures with ASAN leaks active, so we have to disable ASAN leaks for our test harness.
`Direct leak of 56 byte(s) in 1 object(s) allocated from:
#0 0x7ffff6f02602 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602) #1 0x85c6ab in node_new /home/src/core/modules/regex/vendor/onig/onig/src/regparse.c:1072 #2 0x85cbb5 in node_new_quantifier /home/src/core/modules/regex/vendor/onig/onig/src/regparse.c:1252 #3 0x865c73 in parse_exp /home/src/core/modules/regex/vendor/onig/onig/src/regparse.c:5165 #4 0x865eb6 in parse_branch /home/src/core/modules/regex/vendor/onig/onig/src/regparse.c:5222 #5 0x866048 in parse_subexp /home/src/core/modules/regex/vendor/onig/onig/src/regparse.c:5259 #6 0x866204 in parse_regexp /home/src/core/modules/regex/vendor/onig/onig/src/regparse.c:5304 #7 0x866324 in onig_parse_make_tree /home/src/core/modules/regex/vendor/onig/onig/src/regparse.c:5335 #8 0x870d60 in onig_compile /home/src/core/modules/regex/vendor/onig/onig/src/regcomp.c:5279 #9 0x871448 in onig_new /home/src/core/modules/regex/vendor/onig/onig/src/regcomp.c:5518
...
Direct leak of 56 byte(s) in 1 object(s) allocated from:
#0 0x7ffff6f02602 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602) #1 0x85c6ab in node_new /home/src/core/modules/regex/vendor/onig/onig/src/regparse.c:1072 #2 0x85cc67 in node_new_enclose /home/src/core/modules/regex/vendor/onig/onig/src/regparse.c:1278 #3 0x85cd05 in node_new_enclose_memory /home/src/core/modules/regex/vendor/onig/onig/src/regparse.c:1301 #4 0x86491a in parse_enclose /home/src/core/modules/regex/vendor/onig/onig/src/regparse.c:4639 #5 0x8651ca in parse_exp /home/src/core/modules/regex/vendor/onig/onig/src/regparse.c:4899 #6 0x865eb6 in parse_branch /home/src/core/modules/regex/vendor/onig/onig/src/regparse.c:5222 #7 0x866048 in parse_subexp /home/src/core/modules/regex/vendor/onig/onig/src/regparse.c:5259 #8 0x866204 in parse_regexp /home/src/core/modules/regex/vendor/onig/onig/src/regparse.c:5304 #9 0x866324 in onig_parse_make_tree /home/src/core/modules/regex/vendor/onig/onig/src/regparse.c:5335 #10 0x870d60 in onig_compile /home/src/core/modules/regex/vendor/onig/onig/src/regcomp.c:5279 #11 0x871448 in onig_new /home/src/core/modules/regex/vendor/onig/onig/src/regcomp.c:5518
...`
The text was updated successfully, but these errors were encountered:
Onig has several leaks when an invalid pattern is passed and the parser returns an error.
Here are 3 patterns we use in our tests:
"[ab+"
"[ab]+"
"(\d:"
Each one causes a different parse error, respectively:
-103
-104
-117
And each one results in leaks as reported by GCC 5.4 and ASAN/LSAN (on Ubuntu 16.04 with all patches applied).
Here are 2 examples. I traced the first example by breaking on the only instance of ONIGERR_PREMATURE_END_OF_CHAR_CLASS in regparse.c and stepping out from there.
The root problem seems to be in parse_exp() where some return paths cause the 'qn' node to leak. I do not know the exact paths as I was stepping out from the error point.
In the 1st case below, the allocation of 'qn' occurs in the 'repeat' goto on line 5165 (frame 3). Then in the TK_CC_OPEN case handler in parse_exp() when parse_char_class() fails, parse_exp() immediately returns at that point leaking a live 'qn' allocation.
These leaks should be fixed as they could cause issues with a long running app that allows users to enter random patterns of their own (through UI or through a config file).
For our tests too, these leaks cause test harness failures with ASAN leaks active, so we have to disable ASAN leaks for our test harness.
`Direct leak of 56 byte(s) in 1 object(s) allocated from:
#0 0x7ffff6f02602 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602)
#1 0x85c6ab in node_new /home/src/core/modules/regex/vendor/onig/onig/src/regparse.c:1072
#2 0x85cbb5 in node_new_quantifier /home/src/core/modules/regex/vendor/onig/onig/src/regparse.c:1252
#3 0x865c73 in parse_exp /home/src/core/modules/regex/vendor/onig/onig/src/regparse.c:5165
#4 0x865eb6 in parse_branch /home/src/core/modules/regex/vendor/onig/onig/src/regparse.c:5222
#5 0x866048 in parse_subexp /home/src/core/modules/regex/vendor/onig/onig/src/regparse.c:5259
#6 0x866204 in parse_regexp /home/src/core/modules/regex/vendor/onig/onig/src/regparse.c:5304
#7 0x866324 in onig_parse_make_tree /home/src/core/modules/regex/vendor/onig/onig/src/regparse.c:5335
#8 0x870d60 in onig_compile /home/src/core/modules/regex/vendor/onig/onig/src/regcomp.c:5279
#9 0x871448 in onig_new /home/src/core/modules/regex/vendor/onig/onig/src/regcomp.c:5518
...
Direct leak of 56 byte(s) in 1 object(s) allocated from:
#0 0x7ffff6f02602 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602)
#1 0x85c6ab in node_new /home/src/core/modules/regex/vendor/onig/onig/src/regparse.c:1072
#2 0x85cc67 in node_new_enclose /home/src/core/modules/regex/vendor/onig/onig/src/regparse.c:1278
#3 0x85cd05 in node_new_enclose_memory /home/src/core/modules/regex/vendor/onig/onig/src/regparse.c:1301
#4 0x86491a in parse_enclose /home/src/core/modules/regex/vendor/onig/onig/src/regparse.c:4639
#5 0x8651ca in parse_exp /home/src/core/modules/regex/vendor/onig/onig/src/regparse.c:4899
#6 0x865eb6 in parse_branch /home/src/core/modules/regex/vendor/onig/onig/src/regparse.c:5222
#7 0x866048 in parse_subexp /home/src/core/modules/regex/vendor/onig/onig/src/regparse.c:5259
#8 0x866204 in parse_regexp /home/src/core/modules/regex/vendor/onig/onig/src/regparse.c:5304
#9 0x866324 in onig_parse_make_tree /home/src/core/modules/regex/vendor/onig/onig/src/regparse.c:5335
#10 0x870d60 in onig_compile /home/src/core/modules/regex/vendor/onig/onig/src/regcomp.c:5279
#11 0x871448 in onig_new /home/src/core/modules/regex/vendor/onig/onig/src/regcomp.c:5518
...`
The text was updated successfully, but these errors were encountered: