From: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
To: Anupam Aggarwal <anupam.al@samsung.com>
Cc: linux-kernel@vger.kernel.org, a.sahrawat@samsung.com
Subject: Re: [PATCH] fs: fat: add check for dir size in fat_calc_dir_size
Date: Tue, 30 Jun 2020 20:08:12 +0900 [thread overview]
Message-ID: <87ftacolpf.fsf@mail.parknet.co.jp> (raw)
In-Reply-To: <1593428559-13920-1-git-send-email-anupam.al@samsung.com> (Anupam Aggarwal's message of "Mon, 29 Jun 2020 16:32:39 +0530")
Anupam Aggarwal <anupam.al@samsung.com> writes:
> Max directory size of FAT filesystem is FAT_MAX_DIR_SIZE(2097152 bytes)
> It is possible that, due to corruption, directory size calculated in
> fat_calc_dir_size() can be greater than FAT_MAX_DIR_SIZE, i.e.
> can be in GBs, hence directory traversal can take long time.
> for example when command "ls -lR" is executed on corrupted FAT
> formatted USB, fat_search_long() function will lookup for a filename from
> position 0 till end of corrupted directory size, multiple such lookups
> will lead to long directory traversal
>
> Added sanity check for directory size fat_calc_dir_size(),
> and return EIO error, which will prevent lookup in corrupted directory
>
> Signed-off-by: Anupam Aggarwal <anupam.al@samsung.com>
> Signed-off-by: Amit Sahrawat <a.sahrawat@samsung.com>
There are many implementation that doesn't follow the spec strictly. And
when I tested in past, Windows also allowed to read the directory beyond
that limit. I can't recall though if there is in real case or just test
case though.
So if there is no strong reason to apply the limit, I don't think it is
good to limit it. (btw, the current code should detect the corruption of
infinite loop already)
Thanks.
> ---
> fs/fat/inode.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/fs/fat/inode.c b/fs/fat/inode.c
> index a0cf99d..9b2e81e 100644
> --- a/fs/fat/inode.c
> +++ b/fs/fat/inode.c
> @@ -490,6 +490,13 @@ static int fat_calc_dir_size(struct inode *inode)
> return ret;
> inode->i_size = (fclus + 1) << sbi->cluster_bits;
>
> + if (i_size_read(inode) > FAT_MAX_DIR_SIZE) {
> + fat_fs_error(inode->i_sb,
> + "%s corrupted directory (invalid size %lld)\n",
> + __func__, i_size_read(inode));
> + return -EIO;
> + }
> +
> return 0;
> }
--
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
next prev parent reply other threads:[~2020-06-30 11:08 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20200629110320epcas5p34ccccc7c293f077b34b350935c328215@epcas5p3.samsung.com>
2020-06-29 11:02 ` [PATCH] fs: fat: add check for dir size in fat_calc_dir_size Anupam Aggarwal
2020-06-30 11:08 ` OGAWA Hirofumi [this message]
2020-06-30 12:33 ` AMIT SAHRAWAT
2020-06-30 16:26 ` (2) " OGAWA Hirofumi
2020-06-30 17:07 ` AMIT SAHRAWAT
2020-07-03 14:29 ` Anupam Aggarwal
2020-07-03 19:11 ` OGAWA Hirofumi
2020-07-06 11:53 ` Anupam Aggarwal
2020-07-06 14:22 ` OGAWA Hirofumi
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=87ftacolpf.fsf@mail.parknet.co.jp \
--to=hirofumi@mail.parknet.co.jp \
--cc=a.sahrawat@samsung.com \
--cc=anupam.al@samsung.com \
--cc=linux-kernel@vger.kernel.org \
/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