Hi,
The attached pcap file shows that the knfsd server generates
bogus XDR for the reply to a GETATTR that follows a READDIR
operation.
More specifically, if you look at the pcap file in wireshark
and go to packet#22 and then click on the operations and
then "Opcode: GETATTR (9)", the start of
the XDR for the GETATTR will be highlighted in the hexadecimal
window.
Now, if you look at what follows (in the hexadeciaml window),
you'll see that the GETATTR reply looks like:
- GETATTR (9)
- NFS4_OK (0)
- Length of bitmap (0) <-- Not (2)
- 2 words of attribute bitmap
- 98 (length of attributes in hex)
- attribute values
Everything looks ok, except the number of bitmap words is
0 and not 2.
Since the knfsd does not do this normally, I'd guess it is
some sort of runaway pointer or use after free type bug that
causes this, maybe?
Sofar, it only appears to happen when the GETATTR follows a
READDIR operation.
This was reported to me for a FreeBSD client mounting the following:
Debian 12 w/kernel:
$ uname -r
6.1.0-25-amd64
> - what type of file system it exports
ZFS:
$ dpkg -l | fgrep libzfs4linux
ii libzfs4linux 2.1.11-1
amd64
I suspect that ZFS exports are not common for the Linux knfsd?
Anyhow, I am not sure if you have seen such a problem before,
but I thought I would at least report it.
(I have cc'd the reporter, in case you have questions for him.)
rick
ps: If the pcap file does not make it through the mailing list,
email me and I'll send you a copy.
Attachment:
rpc-struct-is-bad.pcap
Description: Binary data
