Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 11 Apr 2011 18:54:15 -0400
From: Dan Rosenberg <>
Cc: Moritz Muehlenhoff <>
Subject: Re: CVE requests: Three Linux kernel issues

This made me chuckle.

> [1] :
> | 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

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. :)


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.