Front page | perl.perl5.porters |
Postings from January 2017
On Mon, 2017-01-30 at 09:58 -0800, James E Keenan via RT wrote: > On Sun, 29 Jan 2017 00:41:50 GMT, john@nixnuts.net wrote: > > On Thu, 2017-01-26 at 13:48 -0800, James E Keenan via RT wrote: > > > As previously reported, I configure with: > > > > > > "-des -Dusedevel -Duseithreads -Doptimize='-O2 -pipe -fstack- > > > protector -fno- > > > strict-aliasing' -DDEBUGGING" > > > > > > ... because that gets us very close to the way that the FreeBSD port > > > of perl > > > is configured. > > > > > > > Excellent, thanks. > > > > The problem turned out to be that the AFL generated payload was > > hitting two > > other memory allocation errors before it even entered retrieve_hook(). > > That > > combination of flags on FreeBSD seems to crash whenever Storable tries > > to > > allocate too much memory. > > > > I adjusted the test data to use more realistic sizes when it enters > > retrieve_hash() and retrieve_flag_hash() so that it's only focusing on > > the stack > > overflow in retrieve_hook(). > > > > I also cleaned up the test output formatting a bit. > > > > An updated patch is attached. > > The third patch you submitted differs from the second patch submitted only in > some test input data in t/store.t. You haven't changed any source code. Are > you sure you're not simply fudging the test? > Yes, that's accurate. The original payload generated by AFL hit three different errors: - memory allocation failure in retrieve_hash - memory allocation failure in retrieve_flag_hash - stack overflow in retrieve_hook The retrieve_hash() crash, for instance, is essentially this code: RLEN(len); hv = newHV(); hv_ksplit(hv, len + 1); For some reason, FreeBSD with the flags you provided can't handle this when len is too large to allocate. My patch only fixes the stack overflow, so I changed the test payload to only generate the stack overflow error.Thread Next