[nfsv4] Re: knfsd related bug reported to FreeBSD
Pali Rohár <pali-ietf-nfsv4@ietf.pali.im> Sat, 14 December 2024 00:59 UTC
Return-Path: <pali-ietf-nfsv4@ietf.pali.im>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB93AC15109A for <nfsv4@ietfa.amsl.com>; Fri, 13 Dec 2024 16:59:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Level:
X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pali.im
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfa4h5CK1mbL for <nfsv4@ietfa.amsl.com>; Fri, 13 Dec 2024 16:59:09 -0800 (PST)
Received: from pali.im (mail.pali.im [IPv6:2a02:2b88:6:5cc6::2a]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C0EFC151073 for <nfsv4@ietf.org>; Fri, 13 Dec 2024 16:59:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pali.im; s=mail; t=1734137938; i=@pali.im; bh=xieyt2M+hGu+41drAFbdycync/Vecpnq8hL4NoIsh58=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=FSrXCZ8q2j3pZSGMwNBRS8lUMBHy15RKuYHCeFJGl9jbcuV2q3XmyzwrXjrz8oRTs I730AAQbKg+NL5jOB2iOXQwqpZA7vMPTODkjM0HaK1rY4C9FIhwvT1usQAW8Svm4i5 WhNCfakGg8FXPDP2kNSsHMdnd9kWdAM5WbmPlKnN9ZjbSdAACUguTcswrVoWtyAsMp 4gU+7l5fTrb9moC3W6GgI6TcCqRQQCnmIID1VJjQgeOCHRHB2131lQyqdc7OQJdRo6 bOQNHOz35boZRwe4Yn0TjxfBrYJLkzVAfrQ5f2aL6DKX+JyA+1KwipRK5N+An34+d6 Xe78Gb1pjPxzA==
Received: by pali.im (Postfix) id CF8FF44E; Sat, 14 Dec 2024 01:58:58 +0100 (CET)
Date: Sat, 14 Dec 2024 01:58:58 +0100
From: Pali Rohár <pali-ietf-nfsv4@ietf.pali.im>
To: Rick Macklem <rick.macklem@gmail.com>
Message-ID: <20241214005858.k2jisy46njaegxkg@pali>
References: <CAM5tNy4q61V=JNB569wuFPpLVgvYkPMX=ENhwTpWanZkRFydAQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAM5tNy4q61V=JNB569wuFPpLVgvYkPMX=ENhwTpWanZkRFydAQ@mail.gmail.com>
User-Agent: NeoMutt/20180716
Message-ID-Hash: FJBIOJP263W4XIYBTH2THUWVMTUVHCNI
X-Message-ID-Hash: FJBIOJP263W4XIYBTH2THUWVMTUVHCNI
X-MailFrom: pali-ietf-nfsv4@ietf.pali.im
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-nfsv4.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: NFSv4 <nfsv4@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [nfsv4] Re: knfsd related bug reported to FreeBSD
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/d8r7b9hQTvBc-btf7XPadBQJwJk>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Owner: <mailto:nfsv4-owner@ietf.org>
List-Post: <mailto:nfsv4@ietf.org>
List-Subscribe: <mailto:nfsv4-join@ietf.org>
List-Unsubscribe: <mailto:nfsv4-leave@ietf.org>
Hello Rick, Just a quick reply. I have not looked at the pcap yet but I know that wireshark incorrectly decodes some of NFS4 packets with GETATTR opcode. I have my own modification of wireshark to fix this problem. So it could be possible that server is sending the correct reply and just wireshark dissect it incorrect. I'm not saying that it is this case, just to be aware of it. Pali On Friday 13 December 2024 16:47:45 Rick Macklem wrote: > 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 and > I can send you a copy.
- [nfsv4] knfsd related bug reported to FreeBSD Rick Macklem
- [nfsv4] Re: knfsd related bug reported to FreeBSD Pali Rohár
- [nfsv4] Re: knfsd related bug reported to FreeBSD Rick Macklem
- [nfsv4] Re: knfsd related bug reported to FreeBSD Pali Rohár