From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============4520876981776507481==" MIME-Version: 1.0 From: Rik van Riel To: lkp@lists.01.org Subject: Re: [x86/uaccess] 5b710f34e1: kernel BUG at mm/usercopy.c:75! Date: Wed, 17 Aug 2016 17:37:00 -0400 Message-ID: <1471469820.32433.74.camel@redhat.com> In-Reply-To: List-Id: --===============4520876981776507481== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Wed, 2016-08-17 at 09:14 -0700, Linus Torvalds wrote: > but compound pages are about the mapping of hugepages, not about > simple multi-order allocations like the task structure (or slab > entries). > = > In other words, it looks like the memory hardening is simply broken > for any case that doesn't use kmalloc(), but instead just allocates > non-order-0 pages directly. Which is certainly _rare_, but not > unheard > of. > = > I'm not sure how to fix it.The low-level page allocator does *not* > mark orders anywhere. > = > I suspect we should just get rid of the page-crosser checking, > because > it's unsolvable. I glossed over the fact that prep_new_page only marks the page as a compound page if __GFP_COMP is set, which it is not for some higher order allocations, including GFP masks passed straight through by the SLOB allocator. This particular allocation is through kmalloc, but the kernel in question has CONFIG_SLOB=3Dy, and usercopy has no code in mm/slob.c I can think of two possibilities: - mark every higher order allocation so it can be =C2=A0 recognized later on (this might break allocators =C2=A0 that free part of a higher order allocation, I =C2=A0 do not know whether they exist) - drop this part of the usercopy code, and no longer =C2=A0 check that a range is part of an object that was =C2=A0 allocated all at once, or spans multiple memory =C2=A0 allocations - this may be ok, given that most =C2=A0 heap overflows are likely to be kmalloc/slab objects, =C2=A0 anyway kind regards, Rik -- = All Rights Reversed. --===============4520876981776507481== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjIKCmlRRWNCQUFC Q0FBR0JRSlh0Tmo5QUFvSkVNNTUzcEtFeE42RFVHOEgvMXNsYjhucTVVU3F2bUVNV0Rqd2FLZUEK M0dHOUVLQWJReTY1b0FyT0UxblJNVzgyZkJpbllVaEZKR1BjSTFycUwvSkF0RHJrNTBCSzNGSnA5 OWI4Sjl1WgpVVWd1ZmJDdmhZVzF3bWIxRmd4dkVSM3pTSWM0TjFUdFIvaEFEaXlmZkwrUHlnVWZR TnM2QkYyeUR2elMwZkYwCjJlZ2hsVHdSWlFhZWJ5bUtST0RjaUdQTXVhQ3BYV2JQZ3VZR0NrYWxa MVZGdUcwT1pTcVowWDBjQ0N3S0owc04KcXg0VVJOYlY5VVFZRzBDRDd6eW80K2U0WjRRbWVFSVJ3 YkpPWkNlQ1NmWkQ0RWhoSWRGenpuaENZRFVzKzVwYwpNQmNILzNURlI5OEJseHFWUGY2bnhtMHVw ZE5iYkVmbjAwL2ErSHc3T0xWaHRzWnJqV1RBTHE3c2tPM3FCdmM9Cj1JNW9YCi0tLS0tRU5EIFBH UCBTSUdOQVRVUkUtLS0tLQo= --===============4520876981776507481==-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753934AbcHQVnf (ORCPT ); Wed, 17 Aug 2016 17:43:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56834 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752406AbcHQVnd (ORCPT ); Wed, 17 Aug 2016 17:43:33 -0400 Message-ID: <1471469820.32433.74.camel@redhat.com> Subject: Re: [x86/uaccess] 5b710f34e1: kernel BUG at mm/usercopy.c:75! From: Rik van Riel To: Linus Torvalds , kernel test robot Cc: Kees Cook , LKP , LKML , Valdis Kletnieks Date: Wed, 17 Aug 2016 17:37:00 -0400 In-Reply-To: References: <57b455f0.PBbMwoqYXi+gB2ZE%xiaolong.ye@intel.com> Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-qbpKONJZjkV/6pX3yUdo" Mime-Version: 1.0 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Wed, 17 Aug 2016 21:37:04 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-qbpKONJZjkV/6pX3yUdo Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2016-08-17 at 09:14 -0700, Linus Torvalds wrote: > but compound pages are about the mapping of hugepages, not about > simple multi-order allocations like the task structure (or slab > entries). >=20 > In other words, it looks like the memory hardening is simply broken > for any case that doesn't use kmalloc(), but instead just allocates > non-order-0 pages directly. Which is certainly _rare_, but not > unheard > of. >=20 > I'm not sure how to fix it.The low-level page allocator does *not* > mark orders anywhere. >=20 > I suspect we should just get rid of the page-crosser checking, > because > it's unsolvable. I glossed over the fact that prep_new_page only marks the page as a compound page if __GFP_COMP is set, which it is not for some higher order allocations, including GFP masks passed straight through by the SLOB allocator. This particular allocation is through kmalloc, but the kernel in question has CONFIG_SLOB=3Dy, and usercopy has no code in mm/slob.c I can think of two possibilities: - mark every higher order allocation so it can be =C2=A0 recognized later on (this might break allocators =C2=A0 that free part of a higher order allocation, I =C2=A0 do not know whether they exist) - drop this part of the usercopy code, and no longer =C2=A0 check that a range is part of an object that was =C2=A0 allocated all at once, or spans multiple memory =C2=A0 allocations - this may be ok, given that most =C2=A0 heap overflows are likely to be kmalloc/slab objects, =C2=A0 anyway kind regards, Rik --=20 All Rights Reversed. --=-qbpKONJZjkV/6pX3yUdo Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABCAAGBQJXtNj9AAoJEM553pKExN6DUG8H/1slb8nq5USqvmEMWDjwaKeA 3GG9EKAbQy65oArOE1nRMW82fBinYUhFJGPcI1rqL/JAtDrk50BK3FJp99b8J9uZ UUgufbCvhYW1wmb1FgxvER3zSIc4N1TtR/hADiyffL+PygUfQNs6BF2yDvzS0fF0 2eghlTwRZQaebymKRODciGPMuaCpXWbPguYGCkalZ1VFuG0OZSqZ0X0cCCwKJ0sN qx4URNbV9UQYG0CD7zyo4+e4Z4QmeEIRwbJOZCeCSfZD4EhhIdFzznhCYDUs+5pc MBcH/3TFR98BlxqVPf6nxm0updNbbEfn00/a+Hw7OLVhtsZrjWTALq7skO3qBvc= =I5oX -----END PGP SIGNATURE----- --=-qbpKONJZjkV/6pX3yUdo--