Re: [patch] Attempt #2 to handle null nameidata

On Thu, Apr 29, 2010 at 9:29 AM, Jeff Layton <[email protected]> wrote:

> On Thu, 29 Apr 2010 22:12:16 +0800
> Eugene Teo <[email protected]> wrote:
>
> > On Thu, Apr 29, 2010 at 9:51 PM, Shirish Pargaonkar
> > <[email protected]> wrote:
> > > On Thu, Apr 29, 2010 at 6:16 AM, Jeff Layton <[email protected]>
> wrote:
> > >> On Thu, 29 Apr 2010 15:56:02 +0530
> > >> Suresh Jayaraman <[email protected]> wrote:
> > >>
> > >>> On 04/09/2010 01:28 AM, Jeff Layton wrote:
> > >>> > On Thu, 8 Apr 2010 14:40:47 -0500
> > >>> > Shirish Pargaonkar <[email protected]> wrote:
> > >>> >
> > >>> >> On Thu, Apr 8, 2010 at 2:34 PM, Jeff Layton <[email protected]>
> wrote:
> > >>> >>> On Wed, �7 Apr 2010 11:19:10 -0500
> > >>> >>> [email protected] wrote:
> > >>> >>>
> > >>> >>>> While creating a file on a server which supports unix extensions
> > >>> >>>> such as Samba, if a file is being created which does not supply
> > >>> >>>> nameidata (i.e. nd is null), cifs client can oops when calling
> > >>> >>>> cifs_posix_open.
> > >>> >>>>
> > >>> >>>> Signed-off-by: Shirish Pargaonkar <[email protected]>
> > >>> >>>> Reported-by: Eugene Teo <[email protected]>
> > >>>
> > >>> >
> > >>> > We'll need to take this patch in the interim though to fix the
> > >>> > immediate oops.
> > >>> >
> > >>>
> > >>> Do we need to Cc -stable as well as the issue seem to be reproducible
> on
> > >>> kernel versions > 2.6.29-rc6?
> > >>>
> > >>> Thanks,
> > >>>
> > >>
> > >> Can someone clarify how to reproduce this oops? I think that the only
> > >> place where this function gets called with NULL nameidata is from nfsd
> > >> and the export ops for cifs are just stubs. Has this actually been
> seen
> > >> in the field or was it just found via inspection?
> > >>
> > >> --
> > >> Jeff Layton <[email protected]>
> > >
> > > As far as I know, by inspection.
> > > Eugene, can you please comment on this?
> >
> > It was found by inspection. Did not attempt to reproduce the issue.
> >
> > Eugene
> >
>
> Ok. I don't think this is actually exploitable. Certainly something
> that should be fixed in case CIFS ever is exportable via nfsd, but not
> worthy of a CVE.
>
>
Yes - that is what we talked about earlier.    Looks like nfs client
has the same problem too (dereferences, potentially null nd)
but in practice can't get there (nfsd over nfs)


> On a related note... the sb->s_export_ops ought to be NULL in all cases
> until CIFS actually has export ops that are functional. The current
> situation probably tricks nfsd into thinking that CIFS is exportable
> when it really isn't. That's likely to be very confusing for users.
>
>
I don't think it matters much, the use case is nfs server
reexporting resources over cifs mounts on servers that don't
have nfs (via a cifs mount) - not sure if it is worth just
doing this in smb2 (where we have persistent file ids anyway,
which may be useful for this) or should do it in both

-- 
Thanks,

Steve

_______________________________________________
linux-cifs-client mailing list
[email protected]
https://lists.samba.org/mailman/listinfo/linux-cifs-client