linux-kernel - RE: [PATCH] fs: fat: add check for dir size in fat_calc_dir

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200703142939epcms5p1440ec65f7e8a3e4741ade2496135d747@epcms5p1>
Date:   Fri, 03 Jul 2020 19:59:39 +0530
From:   Anupam Aggarwal <anupam.al@...sung.com>
To:     OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>,
        AMIT SAHRAWAT <a.sahrawat@...sung.com>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] fs: fat: add check for dir size in fat_calc_dir_size

Hi Ogawa,

>So what was the root cause of slowness on big directory?

Problem happened on FAT32 formatted 32GB USB 3.0 pendrive, which has 20GB of data, cluster size is 16KB
It has one corrupted directory whose size calculated by fat_calc_dir_size() is 1146896384 bytes i.e. 1.06 GB.

When directory traversal of corrupted directory starts, directory entries looks to be corrupted
and lookup fails for these directory entries.
Some directory entries name are having format abc/xyz,
following are the few observed directory entry names:

eqk/hb*
*ùï/ò¢7ô.úBæ
ty7@o/<`
-ò%/ç3{.9q
'ûu/öy<ö.^mö
Ph╤Cf┌6g.ß/k

Now when path lookup happens for above directory entries, it will search for name before ‘/’ in corrupted directory e.g.

eqk
*ùï
ty7@o
-ò%
'ûu
Ph╤Cf┌6g.ß

There are also directory entries with garbage name for which lookup fails, e.g.
á)Yº&q¼(.î».
Æ∞┴Ç▀╜r╟.╣g½
4▒h1▓x0┤.p3╣

During search for single name in fat_search_long() function, whole corrupted directory of size 1.06GB is traversed,
which takes around 230 to 240 secs, which finally ends up with returning ENOENT.

Now multiple lookups in corrupted directory makes “ls -lR” never-ending e.g. in overnite test of running “ls –lR”
on USB having corrupted directory, around 200 such lookups in corrupted directory took 14hrs and still ”ls –lR” is running.

Total number of directory entries in corrupted directory of size 1146896384 bytes = 1146896384/32 = 35840512,
so lookup for 35840512 looks very exhaustive, therefore we have put size check of directory in fat_calc_dir_size()
and prevented the directory traversal by returning -EIO.

While browsing corrupted directory(\CorruptedDIR) on Windows 10 PC,
2623 directory entries were listed and timestamps were wrong

Following is the readonly chkdsk output of USB.

--------------------------------------------------------------------------------------
chkdsk I:
The type of the file system is FAT32.
Volume AAA created 12/28/2018 3:15 PM
Volume Serial Number is 1606-72DC
Windows is verifying files and folders...
Windows found errors on the disk, but will not fix them
because disk checking was run without the /F (fix) parameter.
The \$TXRAJNL.DAT entry contains a nonvalid link.
The size of the \$TXRAJNL.DAT entry is not valid.
Unrecoverable error in folder \CorruptedDIR.
Convert folder to file (Y/N)? n
The \BBB\file1.txt entry contains a nonvalid link.
The size of the \BBB\file1.txt entry is not valid.
The \CCC\file1.txt entry contains a nonvalid link.
The size of the \CCC\file1.txt entry is not valid.
File and folder verification is complete.
Convert lost chains to files (Y/N)? n
3531520 KB of free disk space would be added.

Windows has checked the file system and found problems.
Run CHKDSK with the /F (fix) option to correct these.
   30,015,472 KB total disk space.
          400 KB in 2 hidden files.
        2,800 KB in 48 folders.
   16,479,312 KB in 7,583 files.
    9,999,392 KB are available.

       16,384 bytes in each allocation unit.
    1,875,967 total allocation units on disk.
      624,962 allocation units available on disk.
--------------------------------------------------------------------------------------

Please let us know for any queries,
and please suggest if something better can be done.

Regards,
Anupam