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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 15 May 2014 02:11:40 +0400
From:	Cyrill Gorcunov <gorcunov@...il.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Sasha Levin <sasha.levin@...cle.com>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	Dave Jones <davej@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Pavel Emelyanov <xemul@...allels.com>
Subject: Re: mm: NULL ptr deref handling mmaping of special mappings

On Wed, May 14, 2014 at 02:33:54PM -0700, Andy Lutomirski wrote:
> On Wed, May 14, 2014 at 2:31 PM, Andrew Morton
> <akpm@...ux-foundation.org> wrote:
> > On Wed, 14 May 2014 17:11:00 -0400 Sasha Levin <sasha.levin@...cle.com> wrote:
> >
> >> > In my linux-next all that code got deleted by Andy's "x86, vdso:
> >> > Reimplement vdso.so preparation in build-time C" anyway.  What kernel
> >> > were you looking at?
> >>
> >> Deleted? It appears in today's -next. arch/x86/vdso/vma.c:124 .
> >>
> >> I don't see Andy's patch removing that code either.
> >
> > ah, OK, it got moved from arch/x86/vdso/vdso32-setup.c into
> > arch/x86/vdso/vma.c.
> >
> > Maybe you managed to take a fault against the symbol area between the
> > _install_special_mapping() and the remap_pfn_range() call, but mmap_sem
> > should prevent that.
> >
> > Or the remap_pfn_range() call never happened.  Should map_vdso() be
> > running _install_special_mapping() at all if
> > image->sym_vvar_page==NULL?
> 
> I'm confused: are we talking about 3.15-rcsomething or linux-next?
> That code changed.
> 
> Would this all make more sense if there were just a single vma in
> here?  cc: Pavel and Cyrill, who might have to deal with this stuff in
> CRIU

Well, for criu we've not modified any vdso kernel's code (except
setting VM_SOFTDIRTY for this vdso VMA in _install_special_mapping).
And never experienced problems Sasha points. Looks like indeed in
-next code is pretty different from mainline one. To figure out
why I need to fetch -next branch and get some research. I would
try to do that tomorrow (still hoping someone more experienced
in mm system would beat me on that).
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ