[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
kern/41154: possible races in NFS server code ?
>Synopsis: possible races in NFS server code ?
>Arrival-Date: Sun Apr 05 21:05:00 +0000 2009
>Originator: Manuel Bouyer
>Release: NetBSD 5.0_RC3
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
While working on the NFS server code I noticed that several
places use members of struct nfssvc_sock in a way that is not
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 ?
Main Index |
Thread Index |