linux-kernel - Re: BUG: mmapfile/writev spurious zero bytes still in the wild

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20081003060723.7184a1ed.akpm@linux-foundation.org>
Date:	Fri, 3 Oct 2008 06:07:23 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Bron Gondwana <brong@...tmail.fm>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Nick Piggin <npiggin@...e.de>, Rob Mueller <robm@...tmail.fm>,
	Andi Kleen <andi@...stfloor.org>, Ingo Molnar <mingo@...e.hu>,
	stable@...nel.org
Subject: Re: BUG: mmapfile/writev spurious zero bytes still in the wild

On Fri, 3 Oct 2008 21:44:14 +1000 Bron Gondwana <brong@...tmail.fm> wrote:

> On Tue, Jun 17, 2008 at 02:20:49PM -0700, Linus Torvalds wrote:
> 
> [reminder from way back: this bug was caused by writev containing 
> mmaped pages that weren't paged in, it's 64 bit only.  It
> particularly affects Cyrus Imapd's database formats]
> 
> > On Tue, 17 Jun 2008, Linus Torvalds wrote:
> > > 
> > > Hmm. Something like this *may* salvage it.
> > > 
> > > Untested, so far (I'll reboot and test soon enough), but even if it fixes 
> > > things, it's not really very good. 
> > 
> > Ok, so I just rebooted with this, and it does indeed fix the bug.
> > 
> > I'd be happier with a more complete fix (ie being byte-accurate and 
> > actually doing the partial copy when it hits a fault in the middle), but 
> > this seems to be the minimal fix, and at least fixes the totally bogus 
> > return values from the x86-64 __copy_user*() functions.
> 
> Has this been revisited since?  I haven't noticed, but I really only
> skim LKML - have to save some time in the day for my real job[tm] of
> keeping an email service running!
> 
> > Not that I checked that I got _all_ cases correct (and maybe there are 
> > other versions of __copy_user that I missed entirely), but Bron's 
> > test-case at least seems to work properly for me now.
> > 
> > Bron? If you have a more complete test-suite (ie the real-world case that 
> > made you find this), it would be good to verify the whole thing. 
> 
> It's been fine for us since, but unfortunately most of the world is
> still running distribution "stable" kernels.  I've just been helping a
> user who's getting corrupted flat file databases on Ubuntu's stable 64
> bit xen kernels, and it looks like it's the same issue.
> 
> Is there a standard way to tell backporters "you really need to add this
> patch for your users' sanity"?

Yes, there is.  We backport the patch into earlier kernel releases and
that action _should_ wake the distros up to take a look at the fix.

This particular fix (42a886af728c089df8da1b0017b0e7e6c81b5335) was
included in 2.6.26 and also is present in 2.6.25.17, but not 2.6.25. 
So we did backport it into 2.6.25.x.  Maybe distros were slow or errant
in picking up the patch.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/