Re: [PATCH net v8 00/12] rxrpc: Fix CHALLENGE packet handling

[David Howells <dhowells@redhat.com>]

Actually, sashiko has a point.  It's theoretically possible for userspace to
fabricate a ticket with an encoding type that's supported by the client but
not by the fileserver, in which case, yes the fileserver would be unable to
use the proposed return channel if someone else tried to contact it with a
valid ticket.

Note that this is an afs layer problem, not an rxrpc layer problem.  Each
rxrpc call is tagged with the keys to use and are grouped into virtual
connections by those keys.

To solve the issue, it might be sufficient to ditch the appdata key from the
server record if the fileserver returns RXGK_BADETYPE and the caller's key
matches the enctype of the server's appdata - but that leaves a potental race
in which two callers try to talk to the fileserver simultaneously.

Probably the afs server rotation code needs to be changed so that, when a new
afs_server record is created, the caller creating it holds off other callers
until at least one probe is completed successfully - and if not, it removes
the key and moves on to the next fileserver.

David