The 'comm' member will always be NUL terminated, and this is not fast-path, so we can just perform a direct memcpy during a coredump instead of potentially deadlocking while holding the task struct lock.
Reported-by: Vegard Nossum <[email protected]> Closes: https://lore.kernel.org/all/[email protected] Fixes: c114e9948c2b ("coredump: Standartize and fix logging") Signed-off-by: Kees Cook <[email protected]> --- Cc: "Eric W. Biederman" <[email protected]> Cc: Allen Pais <[email protected]> Cc: Andrew Morton <[email protected]> Cc: Roman Kisel <[email protected]> Cc: Xiaoming Ni <[email protected]> Vegard, can you validate that this fixes the problem for you? I have been wrecked by covid, so very slow to respond here. There's a related thread about this locked, but we can just totally bypass it here. --- include/linux/coredump.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/linux/coredump.h b/include/linux/coredump.h index edeb8532ce0f..a99079115a38 100644 --- a/include/linux/coredump.h +++ b/include/linux/coredump.h @@ -52,8 +52,8 @@ extern int do_coredump(const kernel_siginfo_t *siginfo); #define __COREDUMP_PRINTK(Level, Format, ...) \ do { \ char comm[TASK_COMM_LEN]; \ - \ - get_task_comm(comm, current); \ + /* This will always be NUL terminated. */ \ + memcpy(comm, current->comm, sizeof(comm)); \ printk_ratelimited(Level "coredump: %d(%*pE): " Format "\n", \ task_tgid_vnr(current), (int)strlen(comm), comm, ##__VA_ARGS__); \ } while (0) \ -- 2.34.1
