linux-kernel - Re: [RFC] [PATCH] Pre-emption control for userspace

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, 4 Mar 2014 18:38:58 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Khalid Aziz <khalid.aziz@...cle.com>
Cc:	Oleg Nesterov <oleg@...hat.com>, tglx@...utronix.de,
	mingo@...hat.com, hpa@...or.com, peterz@...radead.org,
	akpm@...ux-foundation.org, andi.kleen@...el.com, rob@...dley.net,
	venki@...gle.com, linux-kernel@...r.kernel.org
Subject: Re: [RFC] [PATCH] Pre-emption control for userspace

On Tue, Mar 04, 2014 at 10:44:54AM -0700, Khalid Aziz wrote:

> do_exit() unmaps mmap_state->uaddr, and frees up mmap_state->kaddr
> and mmap_state. mmap_state should not be NULL after unmap. vfree()
> and kfree() are tolerant of pointers that have already been freed.

Huh?  Double free() is a bug, plain and simple.  Never do that - not
in userland and especially not in the kernel.  Think what happens if
some code gets executed between those two and asks to allocate something.
If it gets the area you'd just freed, your second free will leave it
with all kinds of nasty surprises.  Starting with "who the hell has
started to modify the object I'd allocated and hadn't freed?"

A:	p = alloc();
A:	free(p);
B:	q = alloc();	/* q == p now */
B:	*q = 0;		/* *q is zero */
A:	free(p);	/* same as free(q) */
C:	r = alloc();	/* r == q now */
C:	*r = 1;		/* *q is one */
B:	if (*q != 0) panic("somebody's buggering my memory");

It's always a bug, whether the implementation catches it or not.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/