Re: [PATCH resend v4 00/11] Improve the copy of task comm

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux