Re: CVS commit: src

[Maxime Villard <max%M00nBSD.net@localhost>]

Le 21/04/2014 16:29, Taylor R Campbell a écrit :
> 
>    Date: Mon, 21 Apr 2014 08:20:22 +0200
>    From: Maxime Villard <max%M00nBSD.net@localhost>
> 
>    Le 21/04/2014 01:46, Taylor R Campbell a écrit :
>    > In most cases of the changes you made, there is already a test for the
>    > length of the data buffer.  Is this not guaranteed to be zero if data
>    > is null?  It seems to me that the length test ought to suffice, and if
>    > anything the null pointer test should be an assertion, not a check.
> 
>    Not at all. 'data' and 'data_len' come from userpace. A user can set data
>    to NULL and data_len to a value high enough to bypass the data_len check.
> 
> If a user passes in null data and nonzero data_len, why doesn't
> mount(2) just return EINVAL?

Yes it should; and data_len should not be modified by the kernel.

We also talked about that, and agreed on the fact that it was more a design
issue than a security issue.

> 
> Giving file systems the responsibility for basic sanity checks on
> syscall arguments strikes me as error-prone.
> 

Some fs's don't care at all about data and data_len. You can pass
data=NULL data_len=1024 to kernfs for example.

We don't want to change the behavior for NetBSD-6; it will be fixed in
-current.