• J. Bruce Fields's avatar
    nfsd4: fix null dereference on replay · 9a307403
    J. Bruce Fields authored
    if we receive a compound such that:
    
    	- the sessionid, slot, and sequence number in the SEQUENCE op
    	  match a cached succesful reply with N ops, and
    	- the Nth operation of the compound is a PUTFH, PUTPUBFH,
    	  PUTROOTFH, or RESTOREFH,
    
    then nfsd4_sequence will return 0 and set cstate->status to
    nfserr_replay_cache.  The current filehandle will not be set.  This will
    cause us to call check_nfsd_access with first argument NULL.
    
    To nfsd4_compound it looks like we just succesfully executed an
    operation that set a filehandle, but the current filehandle is not set.
    
    Fix this by moving the nfserr_replay_cache earlier.  There was never any
    reason to have it after the encode_op label, since the only case where
    he hit that is when opdesc->op_func sets it.
    
    Note that there are two ways we could hit this case:
    
    	- a client is resending a previously sent compound that ended
    	  with one of the four PUTFH-like operations, or
    	- a client is sending a *new* compound that (incorrectly) shares
    	  sessionid, slot, and sequence number with a previously sent
    	  compound, and the length of the previously sent compound
    	  happens to match the position of a PUTFH-like operation in the
    	  new compound.
    
    The second is obviously incorrect client behavior.  The first is also
    very strange--the only purpose of a PUTFH-like operation is to set the
    current filehandle to be used by the following operation, so there's no
    point in having it as the last in a compound.
    
    So it's likely this requires a buggy or malicious client to reproduce.
    Reported-by: default avatarScott Mayhew <smayhew@redhat.com>
    Cc: stable@kernel.vger.org
    Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
    9a307403
nfs4proc.c 71.6 KB