Hello,

Can you please kindly consider picking up the fix with revision 1683266 
(http://svn.apache.org/viewvc?view=revision&revision=1683266) in the 
next patch/official subversion release? 
It fixes a long standing issue in the subversion Perl bindings, whereby 
a client stressing the interface can cause a Perl stack 
corruption/segfault in the Swig wrapper to subversion.

The patch fixes, at least, the Swig typemap definition around the 
“result _digest” argument, so that it is handled in a safe manner: 
instead of calculating beforehand the Perl stack address where the 
result of the svn_swig_pl_from_md5() is going to be stored, is rather 
calculated after the function has been called. The md5 function has the 
potential to reallocate the Perl stack elsewhere in memory, so any stack 
addresses calculated before the function call can become invalid after 
the call. 

In my use case, I have git calling the subversion perl binding to 
retrieve the files from a moderately large subversion repository, 
whereby I am getting consistent segmentation faults at that point where 
svn_txdelta_apply() is being called:

        SVN::TxDelta::apply(GLOB(0x60107ece8), GLOB(0x6011ee3a0), undef, 
SVN::Pool=REF(0x6011ee268)) called at 
/usr/share/perl5/site_perl/Git/SVN/Fetcher.pm line 368
        
Git::SVN::Fetcher::apply_textdelta(Git::SVN::Fetcher=HASH(0x6010236a0), 
HASH(0x6011ee2e0), undef, _p_apr_pool_t=SCALAR(0x60113e510)) called at 
/usr/lib/perl5/vendor_perl/SVN/Ra.pm line 623
        
SVN::Ra::Reporter::AUTOLOAD(SVN::Ra::Reporter=ARRAY(0x6010e9ee0), 
SVN::Pool=REF(0x6010ea228)) called at 
/usr/share/perl5/site_perl/Git/SVN/Ra.pm 
line 312

Swig, taking in account the result_digest typemap, generates the 
following code in the wrapper _wrap_svn_txdelta_apply function at 
subversion/subversion/bindings/swig/perl/native/svn_delta.c:

      if (argvi >= items) EXTEND(sp,1);  ST(argvi) = 
svn_swig_pl_from_md5(arg3); argvi++  ;

When the available perl stack size happens to be at  24 SV* just before 
the call  on my system (MSYS2 on windows 7), the svn_swig_pl_from_md5 
will cause reallocation of the perl stack to a different memory address. 
The perl stack address calculated beforehand with the ST(argvi) macro 
will not be valid any more after the call, thus causing a segmentation 
fault when trying to write the result of the function there. The same 
fault happens when I try the same job on Arch Linux, thus it is also 
reproducible across platforms.

The fix makes sure that the result of svn_swig_pl_from_md5 is captured 
in a temporary variable, and stored in ST(argvi) just afterwards:

%typemap(argout) unsigned char *result_digest {
    SV *tmp;
    PUTBACK;
    tmp = svn_swig_pl_from_md5($1);
    SPAGAIN;
    %append_output(tmp);
}

I have tested the fix to work in my case.

A more detailed analysis of the issue with regards to this particular 
client can be found at http://www.mail-
archive.com/g...@vger.kernel.org/msg97227.html .

Thank you,
Yannis

Reply via email to