kern/41154: possible races in NFS server code ?

[Manuel Bouyer <Manuel.Bouyer%lip6.fr@localhost>]

>Number:         41154
>Category:       kern
>Synopsis:       possible races in NFS server code ?
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Apr 05 21:05:00 +0000 2009
>Originator:     Manuel Bouyer
>Release:        NetBSD 5.0_RC3
>Organization:
>Environment:
System: NetBSD horn 5.0_RC3 NetBSD 5.0_RC3 (DISCODEBUG) #34: Sun Apr 5 21:37:10 
MEST 2009 bouyer@disco:/home/bouyer/src-5/src/sys/arch/i386/compile/DISCODEBUG 
i386
Architecture: i386
Machine: i386
>Description:
        While working on the NFS server code I noticed that several
        places use members of struct nfssvc_sock in a way that is not
        obviously thread-safe.
        There appears to be no locking to prevent a nfssvc_sock that has been
        checked as SLP_VALID to become invalid while in use.
        Some places recheck SLP_VALID where appropriate but some don't.
        Especially I suspect there's a possible use after free of
        ns_nam in nfssvc_nfsd(), as nothing seems to prevent nfsrv_zapsock()
        from freeing it while nd_nam points to it. More generally the tail
        of nfssvc_nfsd() doens't look safe.

        If concurent execution of nfssvc_addsock() and nfsrv_zapsock()
        possible ? If so nfssvc_addsock() would need to take the ns_lock,
        and revisit the way SLP_VALID is handled in these 2 functions.

        Last I suspect a race between sys_nfssvc() and nfsrv_zapsock()
        could cause a corruption of the UID hash lists. More generally
        what prevents concurent updates of the ns_uidlruhead ?
        
>How-To-Repeat:
        code inspection
>Fix: