Possible DoS in file 4.20

[Christos Zoulas]

On Apr 4, 10:54am, kimmo at global-wire.fi (Kimmo Suominen) wrote:
-- Subject: Possible DoS in file 4.20

Well, the regex stuff on later versions of linux seems to be the
culprit:

A profiling run of file on sle9-sp3:

perl -e 'for (1..2700) {print "\n" x 10}' >0.lis

Shows the top line being:
 98.03     14.93    14.93        4     3.73     3.80  re_search_internal

The profiling tree looks like:

-----------------------------------------------
               14.93    0.29       4/4           regexec [11]
[10]    99.9   14.93    0.29       4         re_search_internal [10]
                0.00    0.28   53800/53800       re_string_reconstruct
[12]                 0.00    0.00      22/22          extend_buffers [24]
                0.00    0.00   53800/107598      re_string_context_at [27]
                0.00    0.00   53800/53800       match_ctx_clean [28]
0.00    0.00       6/621         cfree [36]
                0.00    0.00       6/6           build_trtable [82]
                0.00    0.00       4/60          memset [51]
                0.00    0.00       4/8
re_string_construct_common [78 ]
                0.00    0.00       4/30
re_string_realloc_buffers [57]                 0.00    0.00       4/8
re_string_destruct [79]

It fails on all recent glibc based linux distributions. On RH8.0
it works fine, and on all the BSD's it works fine. So it is the
new gnu regex code. If you comment out the following two lines
(thanks to conor at lsit.ucsb.edu for narrowing it down):

# OS/2 batch files are REXX. the second regex is a bit generic, oh well
# the matched commands seem to be common in REXX and uncommon elsewhere
#100 regex/c =^\\s*call\\s+rxfuncadd.*sysloadfu OS/2 REXX batch file text
#100 regex/c =^\\s*say\ ['"] OS/2 REXX batch file text

it works fine again. I will comment out the two lines for the next
file release, but the bug is in the gnu regex code.

christos