Messages in this thread | | | Date | Mon, 4 Jul 2011 00:01:06 +0400 | From | Vasiliy Kulikov <> | Subject | Re: [PATCH] proc: fix a race in do_io_accounting() |
| |
On Sun, Jul 03, 2011 at 12:24 -0700, Linus Torvalds wrote: > On Sun, Jul 3, 2011 at 3:39 AM, Vasiliy Kulikov <segoon@openwall.com> wrote: > > > > The order of locking is similar to the one inside of > > ptrace_attach(): first goes cred_guard_mutex, then lock_task_sighand(). > > Hmm. mm_for_maps() uses mutex_lock_killable(), as does lock_trace.
Killable/interruptable here makes sense.
> And neither proc_pid_wchan() nor the fd following ones > (proc_pid_follow_link etc) use anything at all. > > So I'm not sure. And do we really even care about the theoretical > race? Even if we do hit the race window and happen to get it just as a > process turns setuid, it would seem to be totally harmless (we're not > going to see any of the sensitive IO anyway).
I consider this as a theoretical race too unless there is a crazy bug in scheduler/timer. But IMO it's better to just fully remove the risk (even purely theoretical) given the lock is simple and it doesn't cost much.
Thanks,
-- Vasiliy Kulikov http://www.openwall.com - bringing security into open computing environments
| |