[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 18 Oct 2016 20:19:11 -0400
From: David Windsor <dave@...gbits.org>
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 6:56 PM, Sandy Harris <sandyinchina@...il.com> 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.
>
The main use case in the kernel of reference counters is garbage
collection: the kernel manages a particular object that has multiple
users. It cannot safely delete this object until all users of the
object have finished using it. Users acquire and release references
to this object via a get()/put() API. When all users have called
put(), the reference counter becomes 0 (or -1, or some other
sentinel), and the kernel frees the object.
Things go wrong when the reference counter gets overflowed. If the
reference counter is represented with a signed integer type,
overflowing the reference counter causes it to go from INT_MAX to
INT_MIN, then approach 0. Depending on the logic, the transition to
INT_MIN may be enough to trigger the bug, but when the reference
counter becomes 0, the kernel will free the underlying object guarded
by the reference counter while it still has valid users.
> 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.
