Re: [PATCH] nfsd: nfsd4_decode_create: Fix a possible NULL pointer dereference

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

 



On Tue, Apr 22, 2014 at 6:06 PM, Bernd Schubert
<bernd.schubert@xxxxxxxxxxx> wrote:
>
>> cr_linkname maybe a path contains '/', or '.',
>> check_filename will return error nfserr_badname for those path.
>>
>> IMO, just check whether the length is zero as,
>>
>> if (create->cr_linklen == 0)
>>     return nfserr_inval;
>>
> Hmm, right, checking for a '/' not right here. Checking if link-name is
> "." or ".." isn't required, but shouldn't hurt either. But on the other
> hand we can leave that to the underlying file system.

According to rfc3530, 14.2.9, DESCRIPTION

   If the newname has a length of 0 (zero), or if newname does not obey
   the UTF-8 definition, the error NFS4ERR_INVAL will be returned.

The underlying filesystem will return -ENOENT not -EINVAL.
So, NFSD needs checking it explicitly by-self.

Can you sent the patch of v2?

thanks,
Kinglong Mee
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux