Messages in this thread | | | Date | Fri, 6 May 2011 20:28:26 -0700 | From | Andrew Morton <> | Subject | Re: [PATCH 1/1] coredump: use task comm instead of (unknown) |
| |
On Sat, 7 May 2011 11:14:14 +0900 Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> wrote:
> Andrew Morton wrote: > > > char *strncpy(char *dest, const char *src, size_t n) > > > { > > > size_t len = __strnend(src, n) - src; > > If src was overwritten by prctl(PR_SET_NAME) at this moment (i.e. after len was > calculated), > > > > __builtin_memset(dest + len, 0, n - len); > > > __builtin_memcpy(dest, src, len); > > won't this result in inconsistent copying of src when length of src has changed > by prctl(PR_SET_NAME)? > > > > return dest; > > > } > > This strncpy() assumes that length of src won't change within the function. > I thought prctl(PR_SET_NAME) might break such assumption.
PR_SET_NAME uses set_task_comm() which has appropriate locking to protect against get_task_comm().
If kernel code directly accesses task->comm without taking task_lock() then yes, it's racy.
| |