Re: [musl] [PATCH] mman: correct length check in __shm_mapname

[Rich Felker <dalias@libc.org>]

On Tue, Nov 05, 2024 at 02:03:21AM +0000, Zhao, Lihua (CN) wrote:
> This issue is found by attached test case, it works well with glibc.
> 
>         sem_name[0] = '/';
> 
>         sem_name[NAME_MAX + 1] = '\0';
> 
>         memset(sem_name + 1, 'N', NAME_MAX);
> 
>         /* Create the semaphore */
>         sem = sem_open(sem_name, O_CREAT, 0777, 1);
> 
> The above code will generate below string which has one '/' and 255 'N's:
> 
> "/NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN"
> 
> When call __shm_mapname, it firstly try to skip the first '/'
> character, name point to the first 'N' character, the p will point
> to the EOS, so the p-name equal 255, the original code won't enter
> the ENAMETOOLONG branch. The name string should end with EOS, and
> all valid characters should be less than or equal to 254.

This "should" is incorrect. A name consisting of 255 N's is valid not
an error. NAME_MAX is the maximum length of a file name (pathname
component) in bytes, not the amount of storage needed for such a
string buffer.

Reference:
https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/limits.h.html

"{NAME_MAX}
    Maximum number of bytes in a filename (not including the
    terminating null of a filename string)."

Rich