Thanks for the persistence: On Wed, Oct 20, 2021 at 10:00:41PM -0700, dai.ngo@xxxxxxxxxx wrote: > The attack can come from the replies of the source server or requests > from the source server to the destination server via the back channel. > One of possible attack in the reply is BAD_STATEID which was handled > by the client code as mentioned by Olga. > > Here is the list of NFS requests made from the destination to the > source server: > > EXCHANGE_ID > CREATE_SESSION > RECLAIM_COMLETE > SEQUENCE > PUTROOTFH > PUTHF > GETFH > GETATTR > READ/READ_PLUS > DESTROY_SESSION > DESTROY_CLIENTID > > Do you think we should review all replies from these requests to make > sure error replies do not cause problems for the destination server? That's the exactly the sort of analysis I was curious to see, yes. (I doubt the PUTROOTFH, PUTFH, GETFH, and GETATTR are really necessary, I wonder if there's any way we could just bypass them in our case. I don't know, maybe that's more trouble than it's worth.) > same for the back channel ops: > > OP_CB_GETATTR > OP_CB_RECALL > OP_CB_LAYOUTRECALL > OP_CB_NOTIFY > OP_CB_PUSH_DELEG > OP_CB_RECALL_ANY > OP_CB_RECALLABLE_OBJ_AVAIL > OP_CB_RECALL_SLOT > OP_CB_SEQUENCE > OP_CB_WANTS_CANCELLED > OP_CB_NOTIFY_LOCK > OP_CB_NOTIFY_DEVICEID > OP_CB_OFFLOAD There shouldn't be any need for callbacks at all. We might be able to get away without even setting up a backchannel. But, yes, if the server tries to send one anyway, it'd be good to know we do something reasonable. --b.
