linux-hardening - Re: [PATCH] coredump: Do not lock during 'comm' reporting

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <463aeea5-c24d-41bd-888b-6e0911081aae@oracle.com>
Date: Sun, 29 Sep 2024 20:42:24 +0200
From: Vegard Nossum <vegard.nossum@...cle.com>
To: Kees Cook <kees@...nel.org>, Andrew Morton <akpm@...ux-foundation.org>
Cc: "Eric W. Biederman" <ebiederm@...ssion.com>,
        Allen Pais <apais@...ux.microsoft.com>,
        Roman Kisel <romank@...ux.microsoft.com>,
        Xiaoming Ni
 <nixiaoming@...wei.com>,
        Vijay Nag <nagvijay@...rosoft.com>, linux-kernel@...r.kernel.org,
        linux-hardening@...r.kernel.org
Subject: Re: [PATCH] coredump: Do not lock during 'comm' reporting


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 <kees@...nel.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.shao@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.nossum@...cle.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