This is the mail archive of the
mailing list for the glibc project.
Re: [patch] Fix BZ 19165 -- overflow in fread / fwrite
- From: Zack Weinberg <zackw at panix dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: Rich Felker <dalias at libc dot org>, Paul Pluzhnikov <ppluzhnikov at google dot com>, Paul Eggert <eggert at cs dot ucla dot edu>, Alexander Cherepanov <ch3root at openwall dot com>, GLIBC Devel <libc-alpha at sourceware dot org>, "Joseph S. Myers" <joseph at codesourcery dot com>
- Date: Thu, 11 Feb 2016 09:07:54 -0500
- Subject: Re: [patch] Fix BZ 19165 -- overflow in fread / fwrite
- Authentication-results: sourceware.org; auth=none
- References: <CALoOobOpSFwNOqD2RbsSQ95+16=xWN=fTpDJZqgPGJPSXCDmEA at mail dot gmail dot com> <20151026200605 dot GI8645 at brightrain dot aerifal dot cx> <CALoOobPxCPN_Lwvc98CevgCJMwHa_9cURZsALsLeG+SPDSF+Xw at mail dot gmail dot com> <CALoOobOn9ni8FXK3W4ZGAEHSnYAEVUn10agEyC8NO62TyWg0ig at mail dot gmail dot com> <562FC0A8 dot 1080603 at openwall dot com> <CALoOobOxcxieyrfNf9Eg=wmymDyKUPZ_F+atPP+Af8dyYjez_w at mail dot gmail dot com> <5665D571 dot 3090504 at cs dot ucla dot edu> <CALoOobOm6waSvc+pS0DeNFDUq11MNL3xn0XeRNp2vVyOw7=pBA at mail dot gmail dot com> <5669D744 dot 5030307 at redhat dot com> <CALoOobNKxTg29=U_V00wTub5u_GdC3-LiEK-zEFgoW8r_s4RXw at mail dot gmail dot com> <20160211022624 dot GI9349 at brightrain dot aerifal dot cx> <56BC7CEF dot 5000305 at redhat dot com>
(sorry for the malformatted message earlier)
On Thu, Feb 11, 2016 at 7:22 AM, Florian Weimer <email@example.com> wrote:
> On 02/11/2016 03:26 AM, Rich Felker wrote:
> > I think the problem may be even worse than we all expected. I've been
> > trying to fix the corresponding issue in musl, and it looks like the
> > _kernel_ is spuriously failing these reads with EFAULT by pre-checking
> > the validity of the potential destination address range rather than
> > only checking if there would actually be data to copy.
> Yes, system call behavior in this area is fairly regular: if a memory
> region is passed, it is checked for validity as a whole, and not just
> for the parts that are actually needed. By now, this is part of the
> user space interface, and probably cannot change without breaking
> backwards compatibility.
Backward compatibility doesn't seem like a strong argument to me --
changing this would only make programs that don't work now, start
working. It would be much more problematic the other way around.
However, it seems to me there's a serious implementation-level
obstacle: for at least some device I/O, the kernel may need to
finalize memory access checks before it knows how much data is
available. And it would be very confusing if the behavior depended on
what type of fd you were using.