On Mon, Jul 29, 2024 at 5:29 PM Jani Nikula <jani.nikula@xxxxxxxxxxxxxxx> wrote:
>
> On Mon, 29 Jul 2024, Yafang Shao <laoar.shao@xxxxxxxxx> wrote:
> > Hello Andrew,
> >
> > Is it appropriate for you to apply this to the mm tree?
> >
> > Using {memcpy,strncpy,strcpy,kstrdup} to copy the task comm relies on the
> > length of task comm. Changes in the task comm could result in a destination
> > string that is overflow. Therefore, we should explicitly ensure the destination
> > string is always NUL-terminated, regardless of the task comm. This approach
> > will facilitate future extensions to the task comm.
>
> Why are we normalizing calling double-underscore prefixed functions all
> over the place? i.e. __get_task_comm().
>
> get_task_comm() is widely used. At a glance, looks like it could be used
> in many of the patches here too.
There is a BUILD_BUG_ON() inside get_task_comm(), so when you use
get_task_comm(), it implies that the BUILD_BUG_ON() is necessary.
However, we don't want to impose this restriction on code where the
length can be dynamically changed.
One use case of get_task_comm() is in code that has already exposed
the length to userspace. In such cases, we specifically add the
BUILD_BUG_ON() to prevent developers from changing it. For more
information, see commit 95af469c4f60 ("fs/binfmt_elf: replace
open-coded string copy with get_task_comm").
--
Regards
Yafang
