On 28/09/2024 23:51, Kees Cook wrote:
On Sat, Sep 28, 2024 at 02:46:36PM -0700, Andrew Morton wrote:
On Sat, 28 Sep 2024 14:39:45 -0700 Kees Cook <k...@kernel.org> wrote:
On Sat, Sep 28, 2024 at 02:35:32PM -0700, Andrew Morton wrote:
So why does __get_task_comm() need to take task_lock()?
That was to make sure we didn't end up with garbled results, but
discussions have determined that we don't care:
https://lore.kernel.org/all/20240828030321.20688-1-laoar.s...@gmail.com/
But just for safety's sake, I'll change this memcpy to:
memcpy_and_pad(comm, sizeof(comm), current->comm, sizeof(comm) - 1, 0);
Reverting Linus's revert, applying the patch in this thread, and then
changing it to that memcpy_and_pad above, everything seems to work well.
Tested-by: Vegard Nossum <vegard.nos...@oracle.com>
(However, I have not looked at the _safety_ of omitting task_lock()...)
I'm also wondering how I could successfully cat /proc/$pid/status before
on one of these hung processes given that it does __get_task_comm(),
which does task_lock(), which should have presumably hung as well?
Finally, I'll add that the comm/pid format is different from some other
messages:
kernel: coredump: 31447(entry-fuzz.1): coredump has not been created,
error -13
kernel: entry-fuzz.1[43396] bad frame in rt_sigreturn
frame:00000000e4ec200e ip:40a6712e sp:40c25f20 orax:f
Vegard
