[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 24 Oct 2016 18:16:47 -0400
From: Sandy Harris <sandyinchina@...il.com>
To: Jann Horn <jann@...jh.net>
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 7:58 PM, Jann Horn <jann@...jh.net> wrote:
> 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.
>>
>> ...
>>
>> 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.
I meant code that allocates things on the stack & then returns a
pointer to them. That memory is guaranteed invalid since the
function's stack area is invalid after return. Surely such errors
are rare & can be caught by static analysis. Their frequency
should be near zero in any well-written code and zero once it
has gone through the sort of testing kernel code gets.
I think you meant calling something from the malloc() family
of functions, doing some error checking or initialisation, &
then returning the pointer. That is valid code; it just requires
great care to balance *alloc()s and free()s,
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.
