[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wgXYkMueFpxgSY_vfCzdcCnyoaPcjS8e0BXiRfgceRHfQ@mail.gmail.com>
Date: Mon, 5 Aug 2024 20:09:51 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Yafang Shao <laoar.shao@...il.com>
Cc: akpm@...ux-foundation.org, ebiederm@...ssion.com,
alexei.starovoitov@...il.com, rostedt@...dmis.org, catalin.marinas@....com,
penguin-kernel@...ove.sakura.ne.jp, linux-mm@...ck.org,
linux-fsdevel@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
audit@...r.kernel.org, linux-security-module@...r.kernel.org,
selinux@...r.kernel.org, bpf@...r.kernel.org, netdev@...r.kernel.org,
dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH v5 0/9] Improve the copy of task comm
On Mon, 5 Aug 2024 at 20:01, Yafang Shao <laoar.shao@...il.com> wrote:
>
> One concern about removing the BUILD_BUG_ON() is that if we extend
> TASK_COMM_LEN to a larger size, such as 24, the caller with a
> hardcoded 16-byte buffer may overflow.
No, not at all. Because get_task_comm() - and the replacements - would
never use TASK_COMM_LEN.
They'd use the size of the *destination*. That's what the code already does:
#define get_task_comm(buf, tsk) ({ \
...
__get_task_comm(buf, sizeof(buf), tsk); \
note how it uses "sizeof(buf)".
Now, it might be a good idea to also verify that 'buf' is an actual
array, and that this code doesn't do some silly "sizeof(ptr)" thing.
We do have a helper for that, so we could do something like
#define get_task_comm(buf, tsk) \
strscpy_pad(buf, __must_be_array(buf)+sizeof(buf), (tsk)->comm)
as a helper macro for this all.
(Although I'm not convinced we generally want the "_pad()" version,
but whatever).
Linus
Powered by blists - more mailing lists