linux-ext4 - [Bug 14256] kernel BUG at fs/ext3/super.c:435

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, 19 Jan 2010 23:24:43 GMT
From:	bugzilla-daemon@...zilla.kernel.org
To:	linux-ext4@...r.kernel.org
Subject: [Bug 14256] kernel BUG at fs/ext3/super.c:435

http://bugzilla.kernel.org/show_bug.cgi?id=14256





--- Comment #28 from Darren Hart <dvhltc@...ibm.com>  2010-01-19 23:24:41 ---
>From the following in the test:

  mem = mmap (NULL, ps, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);

this may be related to be the problem reported by Kosaki and fixed with his
patch recently pulled into tip by Ingo and sent Linus and stable. Can you try
with this patch from tip/core-fixes-for-linus?

commit 7485d0d3758e8e6491a5c9468114e74dc050785d
Author: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
Date:   Tue Jan 5 16:32:43 2010 +0900

    futexes: Remove rw parameter from get_futex_key()

    Currently, futexes have two problem:

    A) The current futex code doesn't handle private file mappings properly.

    get_futex_key() uses PageAnon() to distinguish file and
    anon, which can cause the following bad scenario:

      1) thread-A call futex(private-mapping, FUTEX_WAIT), it
         sleeps on file mapping object.
      2) thread-B writes a variable and it makes it cow.
      3) thread-B calls futex(private-mapping, FUTEX_WAKE), it
         wakes up blocked thread on the anonymous page. (but it's nothing)

    B) Current futex code doesn't handle zero page properly.

    Read mode get_user_pages() can return zero page, but current
    futex code doesn't handle it at all. Then, zero page makes
    infinite loop internally.

    The solution is to use write mode get_user_page() always for
    page lookup. It prevents the lookup of both file page of private
    mappings and zero page.

    Performance concerns:

    Probaly very little, because glibc always initialize variables
    for futex before to call futex(). It means glibc users never see
    the overhead of this patch.

    Compatibility concerns:

    This patch has few compatibility issues. After this patch,
    FUTEX_WAIT require writable access to futex variables (read-only
    mappings makes EFAULT). But practically it's not a problem,
    glibc always initalizes variables for futexes explicitly - nobody
    uses read-only mappings.

    Reported-by: Hugh Dickins <hugh.dickins@...cali.co.uk>
    Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
    Acked-by: Peter Zijlstra <peterz@...radead.org>
    Acked-by: Darren Hart <dvhltc@...ibm.com>
    Cc: <stable@...nel.org>
    Cc: Linus Torvalds <torvalds@...ux-foundation.org>
    Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
    Cc: Nick Piggin <npiggin@...e.de>
    Cc: Ulrich Drepper <drepper@...il.com>
    LKML-Reference: <20100105162633.45A2.A69D9226@...fujitsu.com>
    Signed-off-by: Ingo Molnar <mingo@...e.hu>

-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html