[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BANLkTimHFG4vSbr_RXtmwDraLzERHJzTfQ@mail.gmail.com>
Date: Mon, 11 Apr 2011 18:54:15 -0400
From: Dan Rosenberg <dan.j.rosenberg@...il.com>
To: oss-security@...ts.openwall.com
Cc: Moritz Muehlenhoff <jmm@...ian.org>
Subject: Re: CVE requests: Three Linux kernel issues
This made me chuckle.
>
> [1] http://permalink.gmane.org/gmane.linux.kernel/1124411 :
>
> | PATCH] char: briq_panel: fix TOCTOU bug
> |
> | There is a TOCTOU bug in briq_panel_write() code:
> |
> | if (vfd_cursor > 39) <<<
> | scroll_vfd();
> | vfd[vfd_cursor++] = c; <<<
> |
> | It's possible to write to arbitrary memory location in case of more than
> | one process tries to call write() simultaneously.
>
Firstly, this driver has locking that only allows one open file
descriptor at once.
Even if you can work around this, you'd have a race window of about
two instructions, with basically no possibility of being preempted
since there's no blocking or potentially faulting operation. And
that's assuming it's even possible, since it may be the case that this
index is in a register, which would render this completely
unexploitable.
Assuming this isn't the case, and you're running an SMP system and
spent countless hours (days? weeks?) spinning to hit this extremely
narrow race, you then get to write a single byte past the end of this
array, into the vfd_is_open integer, which is already set to 1 (it's
treated as a boolean value). Even if due to magical powers you manage
to hit the race window simultaneously on four cores (and the assembly
works perfectly in your favor), you still don't achieve anything. :p
But it'll get a CVE anyways, so I'm not sure what my point is. :)
-Dan
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
