summaryrefslogtreecommitdiff
path: root/arch/avr32
diff options
context:
space:
mode:
authorChuck Lever <chuck.lever@oracle.com>2013-04-30 18:48:54 -0400
committerJ. Bruce Fields <bfields@redhat.com>2013-04-30 19:18:21 -0400
commit676e4ebd5f2c3b4fd1d2bff79b68385c23c5c105 (patch)
tree2e6af168ab04ed0c337c4faff795c60a6b6da472 /arch/avr32
parented9411a00464860cafe7e07224818cdf04fd9e89 (diff)
NFSD: SECINFO doesn't handle unsupported pseudoflavors correctly
If nfsd4_do_encode_secinfo() can't find GSS info that matches an export security flavor, it assumes the flavor is not a GSS pseudoflavor, and simply puts it on the wire. However, if this XDR encoding logic is given a legitimate GSS pseudoflavor but the RPC layer says it does not support that pseudoflavor for some reason, then the server leaks GSS pseudoflavor numbers onto the wire. I confirmed this happens by blacklisting rpcsec_gss_krb5, then attempted a client transition from the pseudo-fs to a Kerberos-only share. The client received a flavor list containing the Kerberos pseudoflavor numbers, rather than GSS tuples. The encoder logic can check that each pseudoflavor in flavs[] is less than MAXFLAVOR before writing it into the buffer, to prevent this. But after "nflavs" is written into the XDR buffer, the encoder can't skip writing flavor information into the buffer when it discovers the RPC layer doesn't support that flavor. So count the number of valid flavors as they are written into the XDR buffer, then write that count into a placeholder in the XDR buffer when all recognized flavors have been encoded. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Diffstat (limited to 'arch/avr32')
0 files changed, 0 insertions, 0 deletions