Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1617687imu; Thu, 13 Dec 2018 19:42:53 -0800 (PST) X-Google-Smtp-Source: AFSGD/WpsFvdQjNGGVRJrFMJLt+hpsiql6vCtT6jJzPk4tFb8maQzLRhlsAksAA8TBJKvbW08hVX X-Received: by 2002:a62:e704:: with SMTP id s4mr1394190pfh.124.1544758973898; Thu, 13 Dec 2018 19:42:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544758973; cv=none; d=google.com; s=arc-20160816; b=fNQIxBQ2bBJN4/HoA4l9+iMmoR4WNb0kOcLFYxQTbdJPYrab1+C/yoAFFxBv/zf1Yx Zxt0c4nclBlmaCZVaPOaz072paoHnRYZb6Ng2EAxDtAcLFOcagh03X8GeNUXZRRilwnp G3DbbjdE5coSIKZWRQtyeborq7zJ3gtbaIdAJHrLIJMq7NuR9+JHbWRCWm4+vEsVVeEI BVvzY2mxpFozqyvl7FkD6fhhb0GoBdQ2+X/tCOvJhkeWaZQjv5+7Pt96DLx1SAEEVjtb Wv6XwjdwCBuxo5u4VX+vA9u6Sx+AiAatEDRoSmo68yRfKlXG+Dje1zMOm1xXFJeelFjw tYcg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from; bh=gBghzIL2PQDBDxvljzpjUi54h0XK52X+EY4IM42aNhE=; b=J8A9NAlCASjAhu0rubw2SuNK6GpZp+GFUIPmUpnnHIZTJhR4n5VKD3GzUnhggV2OpY dFePF2EvfrVha+tJDzsYf2LWHXZkxkUQkVZTu9y0EqP0wQ1l50PIV/Ar3VbOR8RkD9YV ZsCykWlyUP30mdt+5LfSTlZwcXIhahjVBPXvZE+hsz9yKdc4Oiusq4cSWsWxECIFMQpw YxN/74hGohaJKzR21JVnSlykF7O0MpXOE1QO7syvQqqRfjYXRXwF7oqaU91VMvdHEwd+ oj65onYCrBRdRmRWFsJUiPidY8YH5pDbHp4GCmuBCconFVFHXoB3iB5Bf58MePOPgyI5 FIAA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q7si2985680pgl.303.2018.12.13.19.42.39; Thu, 13 Dec 2018 19:42:53 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727015AbeLNDlS (ORCPT + 99 others); Thu, 13 Dec 2018 22:41:18 -0500 Received: from mail.parknet.co.jp ([210.171.160.6]:42514 "EHLO mail.parknet.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726437AbeLNDlS (ORCPT ); Thu, 13 Dec 2018 22:41:18 -0500 Received: from ibmpc.myhome.or.jp (server.parknet.ne.jp [210.171.168.39]) by mail.parknet.co.jp (Postfix) with ESMTPSA id 085F4161688; Fri, 14 Dec 2018 12:41:17 +0900 (JST) Received: from devron.myhome.or.jp (foobar@devron.myhome.or.jp [192.168.0.3]) by ibmpc.myhome.or.jp (8.15.2/8.15.2/Debian-12) with ESMTPS id wBE3fFnY019587 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 14 Dec 2018 12:41:16 +0900 Received: from devron.myhome.or.jp (foobar@localhost [127.0.0.1]) by devron.myhome.or.jp (8.15.2/8.15.2/Debian-12) with ESMTPS id wBE3fFTa018938 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 14 Dec 2018 12:41:15 +0900 Received: (from hirofumi@localhost) by devron.myhome.or.jp (8.15.2/8.15.2/Submit) id wBE3fFMT018937; Fri, 14 Dec 2018 12:41:15 +0900 From: OGAWA Hirofumi To: Matteo Croce Cc: Timothy Redaelli , linux-kernel@vger.kernel.org Subject: Re: [PATCH] vfat: don't read garbage after last dirent References: <20181207013410.7050-1-mcroce@redhat.com> Date: Fri, 14 Dec 2018 12:41:15 +0900 In-Reply-To: <20181207013410.7050-1-mcroce@redhat.com> (Matteo Croce's message of "Fri, 7 Dec 2018 02:34:10 +0100") Message-ID: <87lg4sdbc4.fsf@mail.parknet.co.jp> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Matteo Croce writes: > The FAT32 File System Specification[1] states: > > If DIR_Name[0] == 0x00, then the directory entry is free, and there > are no allocated directory entries after this one. > > The special 0 value, indicates to FAT file system driver code that > the rest of the entries in this directory do notneed to be examined > because they are all free. > > This is not enforced by Linux, and is possible to read garbage if > not all the dirents after the last one are filled with zeroes. > > [1] http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/fatgen103.doc > > Reported-by: Timothy Redaelli > Signed-off-by: Matteo Croce I know this spec. But name[0] == 0 means - the rest of the entries in this directory must be 0. Otherwise, overwriting zeroed entry by adding new dir entry, then shows garbage as dir entry. So "stop at zero" is just a optimization. On other hand, I know there is buggy formatters don't clear that garbage, and uses it on read-only storage area. So I will agree to supporting "stop at zero" though (and keep assuming dir is initialized with zero clear. i.e. don't add tricky workaround to support buggy formatters.), the implementation should handle it for whole path, not only readdir(). E.g. I recall lookup, dir empty check path, and maybe there are others I can't recall immediately. > get_new: > - if (fat_get_entry(inode, &cpos, &bh, &de) == -1) > + if (fat_get_entry(inode, &cpos, &bh, &de) == -1 || !de->name[0]) > goto end_of_dir; > parse_record: > nr_slots = 0; Thanks. -- OGAWA Hirofumi