[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 18 Oct 2016 18:56:24 -0400
From: Sandy Harris <sandyinchina@...il.com>
To: kernel-hardening@...ts.openwall.com
Cc: 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 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.
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. Code the few very carefully and
refuse to accept patches elsewhere that use dynamic allocation; the
problem may not vanish, but it looks like this reduces it to
manageable size.
I have the feeling I might be missing something here. Pointers welcome.
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.
