[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 19 Oct 2016 01:58:35 +0200
From: Jann Horn <jann@...jh.net>
To: Sandy Harris <sandyinchina@...il.com>
Cc: kernel-hardening@...ts.openwall.com,
Vaishali Thakkar <vaishali.thakkar@...cle.com>,
Julia Lawall <julia.lawall@...6.fr>
Subject: Re: Use-after-free and management of reference
counts
On Tue, Oct 18, 2016 at 06:56:24PM -0400, Sandy Harris wrote:
> On Tue, Oct 18, 2016 at 9:13 AM, Jann Horn <jann@...jh.net> wrote:
>
> > Use-after-frees are really hard to deal with.
>
> I want to ask a possibly naive questions -- why can't we avoid the
> whole class of bugs in the first place? I can think of only two main
> sources for use-after-free bugs, both avoidable.
>
> One is allocating something within a function, then returning a
> pointer to it. I know I've done that on occasion, got a warning from
> lint(1) or the compiler, & fixed it; I have forgotten details. Surely
> current static analysis tools can catch nearly all of these. If not,
> writing one looks fairly straightforward. Sure, complex code with a
> lot of indirection might fool such tools, but in general such code
> should not be used anyway.
I'm pretty sure the kernel does that in a lot of places, actually.
> The other is misusing malloc()/free() or their kernel code analogs, &
> the obvious solution is to avoid using those wherever possible. There
> are some kernel data structures that need to grow dynamically, but I
> do not think there need to be a lot.
Actually, nearly everything in the kernel is allocated dynamically.
Even data that you might normally put on the stack is allocated
dynamically because kernel stacks are so small.
And thanks to namespaces, even things like the hostname can be stored
in dynamically allocated memory.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
