linux-kernel - Re: lib/test_overflow.c causes WARNING and tainted kernel

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: <e2646ac0-c194-4397-c021-a64fa2935388@infradead.org>
Date:   Sat, 25 May 2019 08:33:13 -0700
From:   Randy Dunlap <rdunlap@...radead.org>
To:     Kees Cook <keescook@...omium.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Dan Carpenter <dan.carpenter@...cle.com>,
        Rasmus Villemoes <linux@...musvillemoes.dk>,
        Matthew Wilcox <willy@...radead.org>,
        Linux MM <linux-mm@...ck.org>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: lib/test_overflow.c causes WARNING and tainted kernel

On 3/13/19 7:53 PM, Kees Cook wrote:
> Hi!
> 
> On Wed, Mar 13, 2019 at 2:29 PM Randy Dunlap <rdunlap@...radead.org> wrote:
>>
>> This is v5.0-11053-gebc551f2b8f9, MAR-12 around 4:00pm PT.
>>
>> In the first test_kmalloc() in test_overflow_allocation():
>>
>> [54375.073895] test_overflow: ok: (s64)(0 << 63) == 0
>> [54375.074228] WARNING: CPU: 2 PID: 5462 at ../mm/page_alloc.c:4584 __alloc_pages_nodemask+0x33f/0x540
>> [...]
>> [54375.079236] ---[ end trace 754acb68d8d1a1cb ]---
>> [54375.079313] test_overflow: kmalloc detected saturation
> 
> Yup! This is expected and operating as intended: it is exercising the
> allocator's detection of insane allocation sizes. :)
> 
> If we want to make it less noisy, perhaps we could add a global flag
> the allocators could check before doing their WARNs?
> 
> -Kees

I didn't like that global flag idea.  I also don't like the kernel becoming
tainted by this test.

Would it make sense to change the WARN_ON_ONCE() to a call to warn_alloc()
instead?  or use a plain raw printk_once()?

warn_alloc() does the _NOWARN check and does rate limiting.


--- lnx-51-rc2.orig/mm/page_alloc.c
+++ lnx-51-rc2/mm/page_alloc.c
@@ -4581,7 +4581,8 @@ __alloc_pages_nodemask(gfp_t gfp_mask, u
 	 * so bail out early if the request is out of bound.
 	 */
 	if (unlikely(order >= MAX_ORDER)) {
-		WARN_ON_ONCE(!(gfp_mask & __GFP_NOWARN));
+		warn_alloc(gfp_mask, NULL,
+				"page allocation failure: order:%u", order);
 		return NULL;
 	}
 


-- 
~Randy