linux-kernel - Re: Ugly rmap NULL ptr deref oopsie on hibernate (was Linux 2.6.34-rc3)

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:	Tue,  6 Apr 2010 17:53:48 +0900 (JST)
From:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	kosaki.motohiro@...fujitsu.com, Borislav Petkov <bp@...en8.de>,
	Rik van Riel <riel@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Lee Schermerhorn <Lee.Schermerhorn@...com>,
	Minchan Kim <minchan.kim@...il.com>,
	Nick Piggin <npiggin@...e.de>,
	Andrea Arcangeli <aarcange@...hat.com>,
	Hugh Dickins <hugh.dickins@...cali.co.uk>
Subject: Re: Ugly rmap NULL ptr deref oopsie on hibernate (was Linux 2.6.34-rc3)

> 
> I think this is likely due to the new scalable anon_vma linking by Rik. 
> Nothing else I can imagine should have introduced anything like it.
> 
> Rik: the picures have the information, but you need to look at several to 
> see both the oops and the backtrace. Here's a condensed version:
> 
>  shrink_all_memory ->
>    do_try_to_free_pages ->
>      shrink_zone ->
>        shrink_inactive_list ->
>          shrink_page_list ->
>            page_referenced
> 
> where page_referenced() oopses due page_referenced_anon() as per 
> Borislav's description below.
> 
> Added all the usual suspects to the Cc list. Left the full report appended 
> so that the new people don't have to search for it on lkml.

Today, I've reviewed this patch carefully. but I haven't found any bug.

1) anon_vma->list is alwasys protected anon_vma->lock.
2) If anyone forget to take lock, list_add() and/or list_del() never
   assign to NULL.

then, NULL mean either three possibility.

 a) we see uninitialized data
 b) we see after freed data
 c) we see memory corruption by another bug

but (a) can't happen because 

	static inline void __list_add()
	{
	        next->prev = new;
	        new->next = next;
	        new->prev = prev;
	        prev->next = new;  (*)
	}

If uninitialized var is linked to avc list, new->next was already !NULL.

(b) is also impossible. SLAB_DESTROY_BY_RCU delay the page for anon_vma 
freeing until next rcu period. It mean rcu_read_lock()+page_mapped() 
can see kfree()ed page. but it is safe. noone corrupt it.

now I doubt (c) ;-)



Also, I've runned stress workload with shrink_all_memory() today. but
I couldn't reproduce the issue. hmm..  (perhaps I'm no lucky guy. 
I'm frequently fail to reproduce)

I'll continue to work.


--
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/