[patch] Fix for heap overflow in wscanf (BZ 16618)

[Rich Felker]

On Tue, Feb 03, 2015 at 11:33:33PM -0500, Carlos O'Donell wrote:
> On 02/03/2015 07:27 PM, Rich Felker wrote:
> > On Tue, Feb 03, 2015 at 04:11:56PM -0800, Paul Eggert wrote:
> >> Carlos O'Donell wrote:
> >>> I'd read the POSIX wording differently.
> >>
> >> Although Rich's interpretation is correct for current POSIX, thanks
> >> to Eric Blake the next release of POSIX (Issue 8) is planned to
> >> change this, and to require 'free' to leave errno alone, which as I
> >> understand it is your preferred interpretation.  Please see:
> >>
> >> http://austingroupbugs.net/view.php?id=385
> >>
> >> Because of this, glibc 'free' should not set errno if the user
> >> invokes 'free' in a conforming way.  Setting errno will be a
> >> conformance bug once Issue 8 comes out, and glibc should be fixed to
> >> conform well before that.  Also, the glibc documentation should be
> >> changed to discuss this issue.  I have filed a glibc bug report to
> >> that effect, here:
> >>
> >> https://sourceware.org/bugzilla/show_bug.cgi?id=17924
> > 
> > Interesting. Unfortunately this makes it impossible for the
> > application to observe the "valid memory was unable to be freed"
> > condition that occurs when you can't split a vma. Formally, the memory
> > is still freed anyway, so it hardly matters, but it indicates a
> > critical situation where things are about to blow up for the
> > application (malloc no longer working, etc.) so conceivably an
> > application could want to detect and respond to the condition.
> 
> Could you expand a bit on the split vma issue? I'm not familiar
> with that failure mode.

Sure. When malloc uses mmap to allocate large chunks, they usually end
up immediately adjacent and merged into a single vma (virtual memory
area). If each were separated by gaps, you'd hit the kernel's vma
limit per process (default: 64k vmas) very quickly. Some hardened
kernels might aim to keep gaps, but in general this is very expensive
and not done in the mainline kernel.

Anyway, if you have a mmap-obtained chunk X with other anonymous
private mmaps (from malloc or otherwise) directly adjacent to it on
both sides, they're initially a single vma. But when free calls
munmap, the vma has to be split into three parts: the middle one
comprising X that's about to be destroyed, and new vmas for the
now-discontiguous parts left on each side. The result is a net
adjustment of +1 to the nummber of vmas, which may exceed the kernel
limit. In that case munmap will fail. I believe this case actually
used to crash glibc (intentional abort) but I may be mistaken.

It should be easy to make a test case (on 64-bit systems at least) by
allocating 128k objects of size greater than the mmap threshold (128k
iirc) and then freeing all of the even-indexed ones.

Rich