linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Namjae Jeon <linkinjeon@kernel.org>
To: "Yuezhang.Mo@sony.com" <Yuezhang.Mo@sony.com>
Cc: "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	Maxim Suhanov <dfirblog@gmail.com>,
	Sungjong Seo <sj1557.seo@samsung.com>
Subject: Re: [PATCH] exfat: check if filename entries exceeds max filename length
Date: Tue, 18 Jul 2023 08:35:26 +0900	[thread overview]
Message-ID: <CAKYAXd-Qd5vSYXXPppck3thk5kgQT7qtTxeG-+RVXZMn1u6BDA@mail.gmail.com> (raw)
In-Reply-To: <PUZPR04MB6316739EDE3554E9EE25AE10813BA@PUZPR04MB6316.apcprd04.prod.outlook.com>

2023-07-17 13:43 GMT+09:00, Yuezhang.Mo@sony.com <Yuezhang.Mo@sony.com>:
>
>> From: Namjae Jeon <linkinjeon@kernel.org>
>> Sent: Thursday, July 13, 2023 9:03 PM
>> exfat_extract_uni_name copies characters from a given file name entry
>> into
>> the 'uniname' variable. This variable is actually defined on the stack of
>> the
>> exfat_readdir() function. According to the definition of the
>> 'exfat_uni_name'
>> type, the file name should be limited 255 characters (+ null teminator
>> space),
>> but the exfat_get_uniname_from_ext_entry()
>> function can write more characters because there is no check if filename
>> entries exceeds max filename length. This patch add the check not to copy
>> filename characters when exceeding max filename length.
>
> This case is not compliant with the exFAT file system specification, I think
> it is
> better to return an error and let the user fix it with fsck.
> The current fix may result in multiple files with the same name in a
> directory.
>
> Such as, there are files $(filename255) and files $(filename255)1,
> $(filename255)2...
> in a directory, but they will all be found as $(filename255).
We were considering between handling it as an error and like this patch.
In windows, such files is visible and can be accessed without any
error like this patch.
And please don't assume that fsck can be run in all cases. In some
products and scenarios, fsck cannot be executed and should not be
expected. I can add an error print to make the user run fsck.
>
>
>

      reply	other threads:[~2023-07-17 23:37 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-13 13:03 [PATCH] exfat: check if filename entries exceeds max filename length Namjae Jeon
2023-07-17  4:43 ` Yuezhang.Mo
2023-07-17 23:35   ` Namjae Jeon [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAKYAXd-Qd5vSYXXPppck3thk5kgQT7qtTxeG-+RVXZMn1u6BDA@mail.gmail.com \
    --to=linkinjeon@kernel.org \
    --cc=Yuezhang.Mo@sony.com \
    --cc=dfirblog@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=sj1557.seo@samsung.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).