linux-kernel - Re: 2.6.22 -mm merge plans: mm-more-rmap-checking

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]

Message-ID: <46392A3C.30606@yahoo.com.au>
Date:	Thu, 03 May 2007 10:18:04 +1000
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Hugh Dickins <hugh@...itas.com>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: 2.6.22 -mm merge plans: mm-more-rmap-checking

Hugh Dickins wrote:
> On Wed, 2 May 2007, Nick Piggin wrote:
> 
>>Yes, but IIRC I put that in because there was another check in
>>SLES9 that I actually couldn't put in, but used this one instead
>>because it also caught the bug we saw.
>>... 
>>This was actually a rare corruption that is also in 2.6.21, and
>>as few rmap callsites as we have, it was never noticed until the
>>SLES9 bug check was triggered.
> 
> 
> You are being very mysterious.  Please describe this bug (privately
> if you think it's exploitable), and let's work on the patch to fix it,
> rather than this "debug" patch.

It is exec-fix-remove_arg_zero.patch in Andrew's tree, it's exploitable
in that it leaks memory, but it could also release corrupted pagetables
into quicklists on those architectures that have them...

Anyway, it quite likely would have gone unfixed for several more years
if we didn't have the bug triggers in. Now you could argue that my
patch obviously fixes all bugs in there (but I wouldn't :)), and being
most complex of the few callsites, _now_ we can avoid the bug checks.
However I'd prefer to keep them at least under CONFIG_DEBUG_VM.


>>Hmm, I didn't notice the do_swap_page change, rather just derived
>>its safety by looking at the current state of the code (which I
>>guess must have been post-do_swap_page change)...
> 
> 
> Your addition of page_add_new_anon_rmap clarified the situation too.
> 
> 
>>Do you have a pointer to the patch, for my interest?
> 
> 
> The patch which changed do_swap_page?
> 
> commit c475a8ab625d567eacf5e30ec35d6d8704558062
> Author: Hugh Dickins <hugh@...itas.com>
> Date:   Tue Jun 21 17:15:12 2005 -0700
> [PATCH] can_share_swap_page: use page_mapcount


Yeah, this one, thanks. I'm just interested.


> Or my intended PG_swapcache to PAGE_MAPPING_SWAP patch,
> which does assume PageLocked in page_add_anon_rmap?
> Yes, I can send you its current unsplit state if you like
> (but have higher priorities before splitting and commenting
> it for posting).

I would like to see that too, but when you are ready :)

Thanks,
Nick

-- 
SUSE Labs, Novell Inc.
-
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/