linux-kernel - f2fs_empty_dir() can be extremely slow on malicious disk images

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 for Android: free password hash cracker in your pocket

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

Message-ID: <Y2ILlpqFQVO9fH8B@sol.localdomain>
Date:   Tue, 1 Nov 2022 23:17:58 -0700
From:   Eric Biggers <ebiggers@...nel.org>
To:     Jaegeuk Kim <jaegeuk@...nel.org>, Chao Yu <chao@...nel.org>,
        linux-f2fs-devel@...ts.sourceforge.net
Cc:     tytso@....edu, jaegeuk@...nel.org, linux-fscrypt@...r.kernel.org,
        linux-kernel@...r.kernel.org, Wei Chen <harperchen1110@...il.com>
Subject: f2fs_empty_dir() can be extremely slow on malicious disk images

[+f2fs list and maintainers]
[changed subject from "INFO: task hung in fscrypt_ioctl_set_policy"]

On Mon, Oct 31, 2022 at 10:18:02PM +0800, Wei Chen wrote:
> Dear Linux developers,
> 
> Here is the link to the reproducers.
> 
> C reproducer: https://drive.google.com/file/d/1mduYsYuoOKemH3qkvpDQwnAHAaaLUp0Y/view?usp=share_link
> Syz reproducer:
> https://drive.google.com/file/d/1mu-_w7dy_562vWRlQvTRbcBjG4_G7b2L/view?usp=share_link
> 
> The bug persists in the latest commit, v5.15.76 (4f5365f77018). I hope
> it is helpful to you.
> 
> [ 1782.137186][   T30] INFO: task a.out:6910 blocked for more than 143 seconds.
> [ 1782.139217][   T30]       Not tainted 5.15.76 #5
> [ 1782.140388][   T30] "echo 0 >
> /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [ 1782.142524][   T30] task:a.out           state:D stack:14296 pid:
> 6910 ppid:  6532 flags:0x00004004
> [ 1782.144799][   T30] Call Trace:
> [ 1782.145623][   T30]  <TASK>
> [ 1782.146316][   T30]  __schedule+0x3e8/0x1850
> [ 1782.152029][   T30]  ? mark_held_locks+0x49/0x70
> [ 1782.153533][   T30]  ? mark_held_locks+0x10/0x70
> [ 1782.154759][   T30]  ? __down_write_common.part.14+0x31f/0x7b0
> [ 1782.156159][   T30]  schedule+0x4e/0xe0
> [ 1782.158314][   T30]  __down_write_common.part.14+0x324/0x7b0
> [ 1782.159704][   T30]  ? fscrypt_ioctl_set_policy+0xe0/0x200
> [ 1782.161050][   T30]  fscrypt_ioctl_set_policy+0xe0/0x200
> [ 1782.162330][   T30]  __f2fs_ioctl+0x9d6/0x45e0
> [ 1782.163417][   T30]  f2fs_ioctl+0x64/0x240
> [ 1782.164404][   T30]  ? __f2fs_ioctl+0x45e0/0x45e0
> [ 1782.165554][   T30]  __x64_sys_ioctl+0xb6/0x100
> [ 1782.166662][   T30]  do_syscall_64+0x34/0xb0
> [ 1782.169947][   T30]  entry_SYSCALL_64_after_hwframe+0x61/0xcb

Well, the quality of this bug report has a lot to be desired (not on upstream
kernel, reproducer is full of totally irrelevant stuff, not sent to the mailing
list of the filesystem whose disk image is being fuzzed, etc.).  But what is
going on is that f2fs_empty_dir() doesn't consider the case of a directory with
an extremely large i_size on a malicious disk image.

Specifically, the reproducer mounts an f2fs image with a directory that has an
i_size of 14814520042850357248, then calls FS_IOC_SET_ENCRYPTION_POLICY on it.
That results in a call to f2fs_empty_dir() to check whether the directory is
empty.  f2fs_empty_dir() then iterates through all 3616826182336513 blocks the
directory allegedly contains to check whether any contain anything.  i_rwsem is
held during this, so anything else that tries to take it will hang.

I'll look into this more if needed, but Jaegeuk and Chao, do you happen to have
any ideas for how f2fs_empty_dir() should be fixed?  Is there an easy way to
just iterate through the blocks that are actually allocated?

- Eric