NetBSD Problem Report #51046

From www@NetBSD.org  Tue Apr  5 14:28:58 2016
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 004887A20E
	for <gnats-bugs@gnats.NetBSD.org>; Tue,  5 Apr 2016 14:28:57 +0000 (UTC)
Message-Id: <20160405142857.0F85D7AA98@mollari.NetBSD.org>
Date: Tue,  5 Apr 2016 14:28:57 +0000 (UTC)
From: coypu@sdf.org
Reply-To: coypu@sdf.org
To: gnats-bugs@NetBSD.org
Subject: kmem_alloc is not always tested, may corrupt stack.
X-Send-Pr-Version: www-1.0

>Number:         51046
>Category:       security
>Synopsis:       kmem_alloc is not always tested, may corrupt stack.
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    security-officer
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Apr 05 14:30:00 +0000 2016
>Closed-Date:    Sat Apr 16 17:02:53 +0000 2016
>Last-Modified:  Sat Apr 16 17:02:53 +0000 2016
>Originator:     coypu
>Release:        NetBSD 7.99.26
>Organization:
>Environment:
NetBSD  7.99.26 NetBSD 7.99.26 (GENERIC) #5: Sat Apr  2 17:50:15 EDT 2016  maya@ender:/home/maya/obj/sys/arch/amd64/compile/GENERIC amd64
>Description:
(Filing this with a lot of self doubt, I am not sure that I am correct at all - kern/51045 may be unrelated - but if I am, it may have some security implications. Sorry if I am wasting anyone's time.)

There are several kmem_allocs that are not tested for failure.
This can cause stack corruption, as evidenced in kern/51045, running out of RAM and swap results in kernel panic. I am not even sure that is the true cause of it yet.
It's possible that a clever attacker will use this to corrupt the stack to attack the kernel.

Possible list (using -current line numbers, at commit "Skip looking for .MAKE.JOBS if either of compatMake or forceJob is true.")

Some of these are probably wrong, as I did not read very thoroughly:

sys/uvm/uvm_device.c:218 (Original cause of panic)
sys/uvm/uvm_aobj.c:437
sys/uvm/uvm_page:1091-1093
sys/uvm/uvm_swap.c:481

Uncertain: sys/uvm/uvm_swap.c:527,631,.. etc.

If you confirm I am correct I will continue searching for more.
>How-To-Repeat:

>Fix:

>Release-Note:

>Audit-Trail:
From: coypu@SDF.ORG
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: security/51046: kmem_alloc is not always tested, may corrupt
 stack.
Date: Tue, 5 Apr 2016 19:12:21 +0000

 Errr... not testing it is fine because of the second parameter, sorry. I
 don't know why it (apparently) did not work for me.

State-Changed-From-To: open->closed
State-Changed-By: chs@NetBSD.org
State-Changed-When: Sat, 16 Apr 2016 17:02:53 +0000
State-Changed-Why:
submitter realized the error of their ways


>Unformatted:

Home	PR Database Search