Messages in this thread | | | From | Arnd Bergmann <> | Date | Tue, 5 Dec 2017 22:44:17 +0100 | Subject | Re: [PATCH] ocfs2: use get_task_comm |
| |
On Tue, Dec 5, 2017 at 9:32 PM, Kees Cook <keescook@chromium.org> wrote: > On Tue, Dec 5, 2017 at 12:27 PM, Arnd Bergmann <arnd@arndb.de> wrote: >> >> More generally speaking though, how exactly do we guarantee that >> there is NUL-termination on tsk->comm during a concurrent update? >> Could we ever get into a situation where overwrite the NUL byte >> while setting tsk->comm to a longer string, and read the new start >> of the string together with an unterminated end, or do we strictly >> guarantee that the last byte is still NUL? I assume the latter is >> true, just haven't found exactly where that guarantee is made. > > strncpy will zero pad with the trailing NULL, so it's supposed to > always be safe... still gives me the creeps, though.
But set_task_comm uses strlcpy(), not strncpy(), so you might get some of the old data back, the question is just whether it could leak uninitialized data or part of the task_struct up to the next NUL byte. I could not come up with any code path that would leave a non-NUL byte in at the end of task->comm though, so it's probably still safe.
Arnd
| |