From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f48.google.com (mail-wr1-f48.google.com [209.85.221.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4FEC45CDF1 for ; Sat, 25 Apr 2026 10:42:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777113771; cv=none; b=Uz5g+bkO5FO8z7P3hM0h+/T2ilYRg9h5XX5EX1fmE/iRxY21JVWiQEVIi+xjpo2eQ4zbJ0Aiqg2NCoKMb7WwqH2xjuHMSa2CLXNGYK3dQ+P+x9gXQAdtSwzkk49406O1n3PUsCnfj6JKgsv33IFDQfi56Lm28zhC4rYVC0cXaRI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777113771; c=relaxed/simple; bh=Egy9oIhvrx5hg4QkVotouSNsGelH81Y3m1SLo3TezjY=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=o90woLAn0Yata4j46IZZiPwqZ5A3TtM7/3j+pYf0Z0aRJaDMQg1rj+Dua1bgcVg9XhlMl01tYZql9ghAT2LTUljkIY3MTcgg/gws6fCUzvF0vv+HoolJ6QgskntiIe0LyfBpR4TRZtQa6gqLwghrjPcKLNqhglOop7VB3FSbQuw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=sA0kU2HE; arc=none smtp.client-ip=209.85.221.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="sA0kU2HE" Received: by mail-wr1-f48.google.com with SMTP id ffacd0b85a97d-43fea39e066so7245208f8f.1 for ; Sat, 25 Apr 2026 03:42:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1777113769; x=1777718569; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=34WxWxej/rheu7BMO/zOIqxNRzr1fPAiznRBaEu59Lk=; b=sA0kU2HE5PZWPfs9TVlFeDltx/YyInxIsvAcy9pQLjOP4QUkmB4t8PC9PV/CXZW0Ub jKGi00Zm/wKIa5I6J+s2VjCVZVpiameo8JY6H0tZO7VEkEM5+Z9RnaTvXUjkB9s5yiHv L02r97SIBjiflL71NjuMJDL84sLH2HhAA6S8ZNQr3xMruv7ltKzZNUSgXjBFLs1mBJUo 3Cq+1zer8l4HTXXGSzIxkOIb6JgGbCWV+eGBziTp9fiH50mzshol7YlFlQR/wmksYcSi ysKH3pMVIP+usbuX74xwm1g/IeiWagntcPonQ207MLg+uRuO/BJp9nBY/e/MrOoMQzjp 3oyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777113769; x=1777718569; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=34WxWxej/rheu7BMO/zOIqxNRzr1fPAiznRBaEu59Lk=; b=Uh2lu+x5r4Tzc8wMA82WjypUkJASLGcGVx23dWREY5un9VA9IrlD3qDWleO+imHo+a Z54iRtDgb/aTqk/a6JfpZh6t6YxJBD4K3/Z+J/u5YJKETE0Wgk7zdHKeG4cOhYX+3PDA haogF8vjs9IfkkUipjS9P0mCAecCBpYikcNIjVFVDyK/13XzLWCMwSjRTtfLJx2SlZjT OlprrhCkPREz1QVSV1u3DIu6Kced49ZG36Qbvdvl93lad1rWxlxbQFOd6ptxj1NC1JS4 OyRiIHgNa0XVsWGl7xKrmzH23WkRlaWUgi2JUk2tE2M9InNG+14+fY+WZhCesS8Fj4sf +Kmg== X-Forwarded-Encrypted: i=1; AFNElJ/H1Y5GmN2o+Q7feccLanBGEpvhWdIRLfeOjftwTl/j7CZpwJIaBUdF4U7i9K0ojAIpXQ9MK1JFIWUfWJg=@vger.kernel.org X-Gm-Message-State: AOJu0YxHdkK4UIOIK2XWAhTFga2sc/J7EO6V7vjHjo2XRn+xiK/gYs7c iQSAvZuVr5z6uc0nUZcfKyDYyUpF0RPR1VssrTx34ZWymbDwLAEPVFiC X-Gm-Gg: AeBDievPpLlvavjIsVtYu1E5EI/MZ+00s0eZWzgZEEbP5vsb2+B5b29BK2Me8FD/mE0 nA0PN7kY17d5uum1jpj/LFFakiwwqfvFvuQmGbLZX/zoypM2hBh531l1WY/GVthCj1o+F8xGBn/ rOKpciN336g+BUobViW77rzJL8l8p5RhTDqMnUWyURsGEU6PQ8BYfySkY+a9xp6dsqVAXpHK21R al5jNZ+75RAYSnf+6zdenzEDP9PlkXLFmuFvp5uAtHfhXCf9voCGYkiNfz0UY/+sBsrpuLVST2Y Ys8s/7Yho6KR7ZFx43MlLeZbhgIiT9VsU5h9VuiNOxI6UUnKZiuGQSYdxkqg/Bmh89YwoCx93ib B7XxqfBtkh7gb86P/6C0L296hG0o0tdSjA9pBGpn4pGvtBSJVAgt4exDeA6tEaRWR8Xv6pBiCtK V1+qIvblp8P3xMdcOasFK2l1YZ6kshM6tzIk6RFzi1odPjlJ0ngyPbErxRzltUb1/7I9d8zXaKh r4= X-Received: by 2002:a05:6000:186c:b0:43e:a703:3665 with SMTP id ffacd0b85a97d-43fe3e0c6femr53600038f8f.25.1777113768335; Sat, 25 Apr 2026 03:42:48 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43fe4e46471sm64019084f8f.28.2026.04.25.03.42.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 25 Apr 2026 03:42:48 -0700 (PDT) Date: Sat, 25 Apr 2026 11:42:46 +0100 From: David Laight To: Zhan Xusheng Cc: Konstantin Komarov , linux-kernel@vger.kernel.org, Zhan Xusheng Subject: Re: [PATCH] fs/ntfs3: reject evcn == U64_MAX in mi_enum_attr() Message-ID: <20260425114246.545866b6@pumpkin> In-Reply-To: <20260425020309.1663-1-zhanxusheng@xiaomi.com> References: <20260424161558.2d21b624@pumpkin> <20260425020309.1663-1-zhanxusheng@xiaomi.com> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Sat, 25 Apr 2026 10:03:09 +0800 Zhan Xusheng wrote: > On Fri, 24 Apr 2026 16:15:58 +0100 > David Laight wrote: > > > Is that analysis correct? with the current code: > > If evcn is 2 then everything except 0, 1, 2 and 3 are errors. > > If evcn is -3 then only -1 is an error. > > If evcn is -2 no values are errors. > > If evcn is -1 then all svcn values except 0 are errors. > > > > Clearly this doesn't make sense if evcn is -1. > > > > But there isn't an obvious reason why svcn == -4, evcn == -1 > > shouldn't be a valid range. > > (There might be a sanity upper limit is evcn for other reasons.) > > Thanks for looking into this, David. > > The on-disk svcn/evcn fields are __le64 (ntfs.h:339-340), and ntfs3 > uses them as u64 throughout -- the internal VCN type CLST is typedef'd > to u32 or u64 (ntfs.h:73-78). NTFS VCNs are unsigned by definition; > there is no such thing as a negative VCN. I was just writing negative values as shorthand for unsigned ones just below the ~0ull. Perhaps I should have added the (u64) cast. > So the signed interpretation doesn't apply here. In the unsigned > domain, 0xFFFFFFFFFFFFFFFF is simply the maximum u64 value, not -1. > The only issue is the arithmetic wrap: (u64)0xFFFFFFFFFFFFFFFF + 1 == 0. > > Regarding a separate upper bound: yes, evcn is also bounded by the > volume's total cluster count, but mi_enum_attr() validates on-disk > MFT records before the superblock fields are necessarily available > to every caller, so the U64_MAX check is the minimal fix for the > overflow. True - but your comment is wrong. And if the code was looping through the range, I suspect there are other values that would also lead to is looping ~forever. If the numbers are relative the to physical media then the maximum size is much smaller. Basically you can't have 2^64 of anything - there aren't enough atoms. So you can use a much smaller 'sanity check' - limit possibly earlier on. David > > Thanks, > Zhan Xusheng