[stable] please do not merge 058504edd026 (was Re: fs: use after free in /proc/pid/mountinfo)

[stable] please do not merge 058504edd026 (was Re: fs: use after free in /proc/pid/mountinfo)

[David Rientjes]

On Fri, 4 Jul 2014, Sasha Levin wrote:

> > Does this now reproduce on Linus's tree?  If so, does reverting commit
> > 058504edd026 ("fs/seq_file: fallback to vmalloc allocation") prevent this 
> > issue?
> > 
> > This is a use-after-free since the poison value is 0x6b and I'm presuming 
> > that your /proc/self/mountinfo may be larger than PAGE_SIZE in your 
> > testing environment.
> > 
> 
> Good call, reverting that patch made both issues go away.
> 

Thanks for checking, Sasha.

Stable maintainers, please do not merge commit 058504edd026 ("fs/seq_file: 
fallback to vmalloc allocation") that is annotated with a cc for 
stable@vger.kernel.org in Linus's tree into stable kernels.

Although we're at 3.16-rc3, I'm hoping that we can get a fix for the 
use-after-free in the next couple days before asking for a revert.  Sasha 
confirms[*] this commit causes the bug.

Thanks.

 [*] http://marc.info/?l=linux-kernel&m=140448573612154

Re: [stable] please do not merge 058504edd026 (was Re: fs: use after free in /proc/pid/mountinfo)

[Greg KH]

On Fri, Jul 04, 2014 at 03:35:54PM -0700, David Rientjes wrote:
> On Fri, 4 Jul 2014, Sasha Levin wrote:
> 
> > > Does this now reproduce on Linus's tree?  If so, does reverting commit
> > > 058504edd026 ("fs/seq_file: fallback to vmalloc allocation") prevent this 
> > > issue?
> > > 
> > > This is a use-after-free since the poison value is 0x6b and I'm presuming 
> > > that your /proc/self/mountinfo may be larger than PAGE_SIZE in your 
> > > testing environment.
> > > 
> > 
> > Good call, reverting that patch made both issues go away.
> > 
> 
> Thanks for checking, Sasha.
> 
> Stable maintainers, please do not merge commit 058504edd026 ("fs/seq_file: 
> fallback to vmalloc allocation") that is annotated with a cc for 
> stable@vger.kernel.org in Linus's tree into stable kernels.
> 
> Although we're at 3.16-rc3, I'm hoping that we can get a fix for the 
> use-after-free in the next couple days before asking for a revert.  Sasha 
> confirms[*] this commit causes the bug.

I should also drop "Subject: /proc/stat: convert to single_open_size()"
from the -stable tree, right?

thanks,

greg k-h

Re: [stable] please do not merge 058504edd026 (was Re: fs: use after free in /proc/pid/mountinfo)

[Andrew Morton]

On Mon, 7 Jul 2014 16:05:42 -0700 Greg KH <greg@kroah.com> wrote:

> On Fri, Jul 04, 2014 at 03:35:54PM -0700, David Rientjes wrote:
> > On Fri, 4 Jul 2014, Sasha Levin wrote:
> > 
> > > > Does this now reproduce on Linus's tree?  If so, does reverting commit
> > > > 058504edd026 ("fs/seq_file: fallback to vmalloc allocation") prevent this 
> > > > issue?
> > > > 
> > > > This is a use-after-free since the poison value is 0x6b and I'm presuming 
> > > > that your /proc/self/mountinfo may be larger than PAGE_SIZE in your 
> > > > testing environment.
> > > > 
> > > 
> > > Good call, reverting that patch made both issues go away.
> > > 
> > 
> > Thanks for checking, Sasha.
> > 
> > Stable maintainers, please do not merge commit 058504edd026 ("fs/seq_file: 
> > fallback to vmalloc allocation") that is annotated with a cc for 
> > stable@vger.kernel.org in Linus's tree into stable kernels.
> > 
> > Although we're at 3.16-rc3, I'm hoping that we can get a fix for the 
> > use-after-free in the next couple days before asking for a revert.  Sasha 
> > confirms[*] this commit causes the bug.
> 
> I should also drop "Subject: /proc/stat: convert to single_open_size()"
> from the -stable tree, right?
> 

That would be best.

I can't see how "fs: use after free in /proc/pid/mountinfo" can cause a
use-after-free so perhaps the bug lies elsewhere and was hidden by luck
(slab buffering or slab rcu-freeing or something).  In which case
"fs/seq_file: fallback to vmalloc allocation" might be the patch which
added the bug.

Re: [stable] please do not merge 058504edd026 (was Re: fs: use after free in /proc/pid/mountinfo)

[Greg KH]

On Mon, Jul 07, 2014 at 04:06:27PM -0700, Andrew Morton wrote:
> On Mon, 7 Jul 2014 16:05:42 -0700 Greg KH <greg@kroah.com> wrote:
> 
> > On Fri, Jul 04, 2014 at 03:35:54PM -0700, David Rientjes wrote:
> > > On Fri, 4 Jul 2014, Sasha Levin wrote:
> > > 
> > > > > Does this now reproduce on Linus's tree?  If so, does reverting commit
> > > > > 058504edd026 ("fs/seq_file: fallback to vmalloc allocation") prevent this 
> > > > > issue?
> > > > > 
> > > > > This is a use-after-free since the poison value is 0x6b and I'm presuming 
> > > > > that your /proc/self/mountinfo may be larger than PAGE_SIZE in your 
> > > > > testing environment.
> > > > > 
> > > > 
> > > > Good call, reverting that patch made both issues go away.
> > > > 
> > > 
> > > Thanks for checking, Sasha.
> > > 
> > > Stable maintainers, please do not merge commit 058504edd026 ("fs/seq_file: 
> > > fallback to vmalloc allocation") that is annotated with a cc for 
> > > stable@vger.kernel.org in Linus's tree into stable kernels.
> > > 
> > > Although we're at 3.16-rc3, I'm hoping that we can get a fix for the 
> > > use-after-free in the next couple days before asking for a revert.  Sasha 
> > > confirms[*] this commit causes the bug.
> > 
> > I should also drop "Subject: /proc/stat: convert to single_open_size()"
> > from the -stable tree, right?
> > 
> 
> That would be best.

Ok, now dropped, thanks.

greg k-h