Robert Baron <robertbartlettba...@gmail.com> writes:
> Aren't many of the constructs used as examples in the paper are commonly used
> in c programming. For example it is very common to see a function that has a
> pointer as a parameter defined as:
>
> int func(void *ptr)
> {
> if(!ptr) return SOME_ERROR;
> /* rest of function*/
> return 1;
> }
>
> Isn't it interesting that their one example will potentially dereference the
> null pointer even before compiler optimizations (from the paper):
>
> struct tun_struct *tun=....;
> struct sock *sk = tun->sk;
> if(*tun) return POLLERR;
>
> The check to see that tun is non-null should occur before use, as in - quite
> frankly it is useless to check after as tun cannot be the null pointer (the
> program hasn't crashed):
>
> struct tun_struct *tun=....;
> if(*tun) return POLLERR;
> struct sock *sk = tun->sk;
The paper points out that the code contains a bug; the claim in the
paper is that it is a minor bug as written (it only gets past the
tun->sk dereference if page 0 has somehow been made readable), but
becomes a possible privilege escalation after the check has been
optimized away.
> I am under the impression that these problems are rather widely known among c
> programmers (perhaps not the kids fresh out of college). But this is why
> teams need to have experienced people.
>
> Furthermore, it is very common to find code that works before optimization,
> and fails at certain optimization levels. Recently, I was compiling a library
> that failed its own tests under the optimization level set in the makefile but
> passed its own test at a lower level of optimization.
Isn't that, and an analysis of when this can happen, the main point of
the paper?
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1bvbzgtj13....@snowball.wb.pfeifferfamily.net
