Stable kernel updates (security fix) [LWN.net]

Stable kernel updates (security fix)

Posted May 7, 2008 18:27 UTC (Wed) by iabervon (subscriber, #722)
In reply to: Stable kernel updates (security fix) by mattdm
Parent article: Stable kernel updates (security fix)

I think that, if you do a lock fcntl() on a file descriptor in one thread and a close() on it
in another thread, it's possible that you'll end up with the fcntl starting and figuring out
what you're locking, and then the close happens, and then the lock completes. At this point,
you've locked the file, but it's closed. These locks are only supposed to last until you close
the file (or exit, which automatically closes it). So I think this lets people leak locks. I
don't know whether this matters significantly for security, but, since POSIX implies that, if
you really want a lock to go away and you're root, you can kill the process that holds it,
something might be depending on this actually working.

(Log in to post comments)

Stable kernel updates (security fix)

Posted May 7, 2008 19:56 UTC (Wed) by viro (subscriber, #7872) [Link]

It does matter; file_lock is not supposed to outlive the struct file
it refers to.  If it does, and if struct file in question is later
freed, you can get the page that used to contain it mapped in userland.
Then it's not hard to fill it with the right pattern, so that e.g.
reading from /proc/locks would read data from arbitrary kernel address
and print it for you (look at the place where it prints ->i_ino,
for starters).  That's already a roothole; looking for more direct
ways to escalate is left as an exercise for readers (and yes, it is
possible).

Stable kernel updates (security fix)

Posted May 7, 2008 21:49 UTC (Wed) by iabervon (subscriber, #722) [Link]

Ah, yes, if the kernel itself is assuming that a locked file must be open in how it handles
memory, that's a pretty easy escalation.