[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CALOAHbDPToZDrsB2wSp6Ss5L0ksrCb1ufx3SZ1GWeqQ2jP7Daw@mail.gmail.com>
Date: Tue, 6 Aug 2024 11:50:40 +0800
From: Yafang Shao <laoar.shao@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
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 Tue, Aug 6, 2024 at 11:10 AM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> 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).
>
Will do it.
Thanks for your explanation.
--
Regards
Yafang
Powered by blists - more mailing lists