> On Nov 13, 2021, at 4:57 PM, Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > > On Sat, Nov 13, 2021 at 09:31:40PM +0000, Chuck Lever III wrote: >> This allows the client to send bitmaps larger than bmval[], >> as the old decoder did, > > Oh, thanks, right, I guess rejecting too-large bitmaps outright might > cause compatibility problems with future implementations. > > (Hm, ideally, shouldn't we be checking whether bits are set beyond where > we expect so that e.g. we can return NFS4ERR_ATTRNOTSUPP on operations > that set attributes? Perhaps that's more than is necessary; it's a > separate issue, anyway.) The spec might call for those bits to be ignored. The server would simply not set those in the response. I believe that's how unsupported bits are handled anyway, rather than returning an error response. Also note that the "count > 1000" sanity check might be unneeded. If the count is unrealistically large, it will cause the subsequent xdr_inline_decode() to fail. I could send a separate patch to remove that check if you agree. >> and ensures that decode_bitmap() >> cannot write farther than @bmlen into the bmval array. >> >> >>> return nfserr_bad_xdr; >>> p = xdr_inline_decode(argp->xdr, count << 2); >>> if (!p) >> >> -- >> Chuck Lever -- Chuck Lever
