linux-kernel - Re: [3.8 Regression] backporting "[PATCH stable pre 3.9] mm, gup: close FOLL MAP

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: <20161021064602.GD6045@dhcp22.suse.cz>
Date:   Fri, 21 Oct 2016 08:46:02 +0200
From:   Michal Hocko <mhocko@...nel.org>
To:     Brian Norris <briannorris@...omium.org>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Andy Lutomirski <luto@...nel.org>,
        Phil not Paul Oester <kernel@...uxace.com>,
        linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Willy Tarreau <w@....eu>, Guenter Roeck <linux@...ck-us.net>,
        Kees Cook <keescook@...omium.org>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>
Subject: Re: [3.8 Regression] backporting "[PATCH stable pre 3.9] mm, gup:
 close FOLL MAP_PRIVATE race"

On Thu 20-10-16 23:39:39, Brian Norris wrote:
> (Preface: this wasn't a clean backport, I'm a bit under the weather, and
> it's getting late here. So forgive me if my head's not on straight.)
> 
> Hi,
> 
> I'm not sure the best way to report this, but the Chrome OS test
> infrastructure noticed some problems when testing the following patch
> backported to our 3.8 kernels:
> 
> http://www.spinics.net/lists/stable/msg147998.html
> 
> Specifically (if you can hold your nose and stand Gerrit), this change:
> 
> https://chromium-review.googlesource.com/#/c/401041/

This is not correct. You have
https://chromium-review.googlesource.com/#/c/401041/2/mm/memory.c

f ((flags & FOLL_WRITE) && !can_follow_write_pte(pte, page, flags)) {
		pte_unmap_unlock(ptep, ptl);
		goto no_page;
	}

so you do a double unlock. See how my patch does
+	if ((flags & FOLL_WRITE) && !can_follow_write_pte(pte, page, flags)) {
+		pte_unmap_unlock(ptep, ptl);
+		return NULL;
+	}

-- 
Michal Hocko
SUSE Labs