linux-kernel - Re: [ 07/48] mm: fix slab->page _count corruption when using slub

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, 3 Jul 2012 13:19:01 -0700
From:	Pravin Shelar <pshelar@...ira.com>
To:	Herton Ronaldo Krzesinski <herton.krzesinski@...onical.com>
Cc:	Ben Hutchings <ben@...adent.org.uk>, linux-kernel@...r.kernel.org,
	stable@...r.kernel.org, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org, alan@...rguk.ukuu.org.uk,
	Amey Bhide <abhide@...ira.com>,
	Christoph Lameter <cl@...ux.com>,
	Pekka Enberg <penberg@...helsinki.fi>,
	Andrea Arcangeli <aarcange@...hat.com>
Subject: Re: [ 07/48] mm: fix slab->page _count corruption when using slub

Applying just this patch does not solve whole problem. There is
another patch which needs to be backported. Discussion on that is not
concluded yet. so I think we can drop this patch for now.
ref : http://www.vacationhomexchg.com/lists/linux-mm/msg36054.html

Thanks,
Pravin.

On Mon, Jul 2, 2012 at 6:17 PM, Herton Ronaldo Krzesinski
<herton.krzesinski@...onical.com> wrote:
> On Mon, Jul 02, 2012 at 08:56:32PM -0300, Herton Ronaldo Krzesinski wrote:
>> So, 3.2 didn't have the CONFIG_HAVE_CMPXCHG_DOUBLE and
>> CONFIG_HAVE_ALIGNED_STRUCT_PAGE defines, it had instead CMPXCHG_DOUBLE
>> and HAVE_ALIGNED_STRUCT_PAGE is a new logic. So the patch is broken for
>> 3.2 indeed.
>
> So here is a proposed backport for 3.2, I tested it etc., but please
> someone review/ack it as well...
>
> From: Pravin B Shelar <pshelar@...ira.com>
> Subject: mm: fix slab->page _count corruption when using slub
>
> commit abca7c4965845924f65d40e0aa1092bdd895e314 upstream.
>
> On arches that do not support this_cpu_cmpxchg_double() slab_lock is used
> to do atomic cmpxchg() on double word which contains page->_count.  The
> page count can be changed from get_page() or put_page() without taking
> slab_lock.  That corrupts page counter.
>
> Fix it by moving page->_count out of cmpxchg_double data.  So that slub
> does no change it while updating slub meta-data in struct page.
>
> [akpm@...ux-foundation.org: use standard comment layout, tweak comment text]
> Reported-by: Amey Bhide <abhide@...ira.com>
> Signed-off-by: Pravin B Shelar <pshelar@...ira.com>
> Acked-by: Christoph Lameter <cl@...ux.com>
> Cc: Pekka Enberg <penberg@...helsinki.fi>
> Cc: Andrea Arcangeli <aarcange@...hat.com>
> Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
> Signed-off-by: Linus Torvalds <torvalds@...ux-foundation.org>
> Signed-off-by: Ben Hutchings <ben@...adent.org.uk>
> [herton: backport to 3.2, use CONFIG_CMPXCHG_DOUBLE]
> Signed-off-by: Herton R. Krzesinski <herton@...onical.com>
> ---
>  include/linux/mm_types.h |    9 +++++++++
>  1 file changed, 9 insertions(+)
>
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 5b42f1b..2153639 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -56,8 +56,17 @@ struct page {
>                 };
>
>                 union {
> +#ifdef CONFIG_CMPXCHG_DOUBLE
>                         /* Used for cmpxchg_double in slub */
>                         unsigned long counters;
> +#else
> +                       /*
> +                        * Keep _count separate from slub cmpxchg_double data.
> +                        * As the rest of the double word is protected by
> +                        * slab_lock but _count is not.
> +                        */
> +                       unsigned counters;
> +#endif
>
>                         struct {
>
> --
> 1.7.9.5
>
>
> --
> []'s
> Herton
--
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/