[Bug nptl/14485] File corruption race condition in robust mutex unlocking

["bugdal at aerifal dot cx" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=14485

--- Comment #3 from Rich Felker <bugdal at aerifal dot cx> ---
The corruption is performed by the kernel when it walks the robust list. The
basic situation is the same as in PR #13690, except that here there's actually
a potential write to the memory rather than just a read.

The sequence of events leading to corruption goes like this:

1. Thread A unlocks the process-shared, robust mutex and is preempted after the
mutex is removed from the robust list and atomically unlocked, but before it's
removed from the list_op_pending field of the robust list header.

2. Thread B locks the mutex, and, knowing by program logic that it's the last
user of the mutex, unlocks and unmaps it, allocates/maps something else that
gets assigned the same address as the shared mutex mapping, and then exits.

3. The kernel destroys the process, which involves walking each thread's robust
list and processing each thread's list_op_pending field of the robust list
header. Since thread A has a list_op_pending pointing at the address previously
occupied by the mutex, the kernel obliviously "unlocks the mutex" by writing a
0 to the address and futex-waking it. However, the kernel has instead
overwritten part of whatever mapping thread A created. If this is private
memory it (probably) doesn't matter since the process is ending anyway (but are
there race conditions where this can be seen?). If this is shared memory or a
shared file mapping, however, the kernel corrupts it.

I suspect the race is difficult to hit since thread A has to get preempted at
exactly the wrong time AND thread B has to do a fair amount of work without
thread A getting scheduled again. So I'm not sure how much luck we'd have
getting a test case.

-- 
You are receiving this mail because:
You are on the CC list for the bug.