Race condition in fs/proc/array.c with task->comm

Race condition in fs/proc/array.c with task->comm

Post by Corey Minyar » Mon, 30 Jun 2003 16:30:20

I searched for something about this, and I couldn't find anything.

I was having a problem with "top" crashing occasionally, so I looked,
and top was getting nil characters in the process name in
/proc/<pid>/stat.  It turns out that there is a race condition when
generating the output for task->comm.  If the task "execs" during this
time, it copies a new name into task->comm.  When generating
/proc/<pid>/stat, it uses sprintf to copy the string.  However, if the
data is changing in task->comm during this time, the results can be
corrupted, including putting nil characters into the string.

This seems to be a problem in all version of the kernel I looked at
(various 2.4 and 2.5 releases).  I have only tested the problem in 2.4.20.

I can think it two main ways to fix this.  You can:

* Make a local copy of task->comm.  The results might still be wrong,
but it will not contain nil characters.

 * Use locks so the data is consistent.

I can fix this and supply a patch, but I'd like suggestions on which
path to take.  If suggesting a lock, should I create a new lock, or is
there an existing lock I can use?



To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/