Re: Off-by-one bug at unix_mkname ?

[YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@xxxxxxxxxxxxxx>]

In article <200503281700.HHE91205.FtVLOStGOSPMYJFMN@xxxxxxxxxxxxxxxxxxx> (at 
Mon, 28 Mar 2005 17:00:05 +0900), Tetsuo Handa 
<from-linux-kernel@xxxxxxxxxxxxxxxxxxx> says:

> It seems to me that the following code is off-by-one bug.
> 
> http://lxr.linux.no/source/net/unix/af_unix.c#L191
> http://lxr.linux.no/source/net/unix/af_unix.c?v=2.4.28#L182
> 
> I think
> ((char *)sunaddr)[len]=0;
> should be
> ((char *)sunaddr)[len-1]=0;

Well, 2.2 has some comment on this:

static int unix_mkname(struct sockaddr_un * sunaddr, int len, unsigned *hashp)
{
        if (len <= sizeof(short) || len > sizeof(*sunaddr))
                return -EINVAL;
:
        if (sunaddr->sun_path[0])
        {
                /*
                 *      This may look like an off by one error but it is
                 *      a bit more subtle. 108 is the longest valid AF_UNIX
                 *      path for a binding. sun_path[108] doesnt as such
                 *      exist. However in kernel space we are guaranteed that
                 *      it is a valid memory location in our kernel
                 *      address buffer.
                 */
                if (len > sizeof(*sunaddr))
                        len = sizeof(*sunaddr);
                ((char *)sunaddr)[len]=0;
                len = strlen(sunaddr->sun_path)+1+sizeof(short);
                return len;
        }
:

-- 
Hideaki YOSHIFUJI @ USAGI Project <yoshfuji@xxxxxxxxxxxxxx>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA