[BUG] fanotify: WARNING in fanotify_handle_event with crafted msdos image and long path

[BUG] fanotify: WARNING in fanotify_handle_event with crafted msdos image and long path

[ZW Tang]

Hi,

I am reporting a warning triggered by a syzkaller reproducer on
Linux 7.2.0-rc3. A similar issue appears to have been reported upstream
before, but I can still reproduce it on Linux 7.2.0-rc3 with HEAD commit
1137d8b5df06137fb49513cc923b3b24d94cb809.

The reproducer mounts a crafted msdos filesystem image, creates a very
long pathname, installs a fanotify mark, and then calls execve() on the
long path. During execve(), the file open path triggers fsnotify, which
then calls fanotify_handle_event(). While fanotify is constructing the
event, it hits a warning in fs/notify/fanotify/fanotify.h.

This looks like a fanotify name-event encoding robustness issue. A crafted
filesystem image together with a very long pathname appears to trigger an
unexpected name/fid event layout, and fanotify_info_copy_name() reaches a
WARN_ON_ONCE() path. The kernel should probably reject or truncate the
event cleanly instead of triggering a warning, because panic_on_warn turns
this into a kernel panic.

Reproducer:

syz reproducer: https://pastebin.com/raw/JqBwvgbH
console output: https://pastebin.com/raw/2jnY4jzL
kernel config: https://pastebin.com/raw/RgvQ5DPY

Kernel:

HEAD commit: 1137d8b5df06137fb49513cc923b3b24d94cb809
git tree: torvalds/linux
kernel version: 7.2.0-rc3 #1 PREEMPT(full) (QEMU Ubuntu 24.10)

Relevant log:

loop0: detected capacity change from 0 to 128

------------[ cut here ]------------
WARNING: fs/notify/fanotify/fanotify.h:217 at
fanotify_handle_event+0x3e93/0x4800, CPU#1: syz.0.17/10761

CPU: 1 UID: 0 PID: 10761 Comm: syz.0.17 Not tainted 7.2.0-rc3 #1 PREEMPT(full)
Hardware name: QEMU Ubuntu 24.10 PC (i440FX + PIIX, 1996)

RIP: 0010+0x3e93/0x4800

Call Trace:
<TASK>
fsnotify+0x1105/0x1be0
__fsnotify_parent+0x6b6/0xd40
vfs_open+0x2e6/0x3f0
path_openat+0x29a2/0x3e20
do_file_open+0x216/0x310
do_open_execat+0xe8/0x430
alloc_bprm+0x2b/0x900
do_execveat_common.isra.0+0x1a8/0x5d0
__x64_sys_execve+0x93/0xd0
do_syscall_64+0xc4/0x7a0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
</TASK>

Kernel panic - not syncing: kernel: panic_on_warn set ...

Re: [BUG] fanotify: WARNING in fanotify_handle_event with crafted msdos image and long path

[Jan Kara]

Hello,

On Mon 31-08-26 12:32:57, ZW Tang wrote:
> I am reporting a warning triggered by a syzkaller reproducer on
> Linux 7.2.0-rc3. A similar issue appears to have been reported upstream
> before, but I can still reproduce it on Linux 7.2.0-rc3 with HEAD commit
> 1137d8b5df06137fb49513cc923b3b24d94cb809.
> 
> The reproducer mounts a crafted msdos filesystem image, creates a very
> long pathname, installs a fanotify mark, and then calls execve() on the
> long path. During execve(), the file open path triggers fsnotify, which
> then calls fanotify_handle_event(). While fanotify is constructing the
> event, it hits a warning in fs/notify/fanotify/fanotify.h.
> 
> This looks like a fanotify name-event encoding robustness issue. A crafted
> filesystem image together with a very long pathname appears to trigger an
> unexpected name/fid event layout, and fanotify_info_copy_name() reaches a
> WARN_ON_ONCE() path. The kernel should probably reject or truncate the
> event cleanly instead of triggering a warning, because panic_on_warn turns
> this into a kernel panic.

fanotify complains that the name length is greater than NAME_MAX.  If I can
guess, the problem likely is that the msdos filesystem (vfat?) allows a
file name that is longer than NAME_MAX. Which would be a bug in the
filesystem driver, not a problem in fanotify... Ogawa, care to have a look?

								Honza

> 
> Reproducer:
> 
> syz reproducer: https://pastebin.com/raw/JqBwvgbH
> console output: https://pastebin.com/raw/2jnY4jzL
> kernel config: https://pastebin.com/raw/RgvQ5DPY
> 
> Kernel:
> 
> HEAD commit: 1137d8b5df06137fb49513cc923b3b24d94cb809
> git tree: torvalds/linux
> kernel version: 7.2.0-rc3 #1 PREEMPT(full) (QEMU Ubuntu 24.10)
> 
> Relevant log:
> 
> loop0: detected capacity change from 0 to 128
> 
> ------------[ cut here ]------------
> WARNING: fs/notify/fanotify/fanotify.h:217 at
> fanotify_handle_event+0x3e93/0x4800, CPU#1: syz.0.17/10761
> 
> CPU: 1 UID: 0 PID: 10761 Comm: syz.0.17 Not tainted 7.2.0-rc3 #1 PREEMPT(full)
> Hardware name: QEMU Ubuntu 24.10 PC (i440FX + PIIX, 1996)
> 
> RIP: 0010+0x3e93/0x4800
> 
> Call Trace:
> <TASK>
> fsnotify+0x1105/0x1be0
> __fsnotify_parent+0x6b6/0xd40
> vfs_open+0x2e6/0x3f0
> path_openat+0x29a2/0x3e20
> do_file_open+0x216/0x310
> do_open_execat+0xe8/0x430
> alloc_bprm+0x2b/0x900
> do_execveat_common.isra.0+0x1a8/0x5d0
> __x64_sys_execve+0x93/0xd0
> do_syscall_64+0xc4/0x7a0
> entry_SYSCALL_64_after_hwframe+0x76/0x7e
> </TASK>
> 
> Kernel panic - not syncing: kernel: panic_on_warn set ...
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: [BUG] fanotify: WARNING in fanotify_handle_event with crafted msdos image and long path

[OGAWA Hirofumi]

Jan Kara <jack@suse.cz> writes:

> On Mon 31-08-26 12:32:57, ZW Tang wrote:
>> I am reporting a warning triggered by a syzkaller reproducer on
>> Linux 7.2.0-rc3. A similar issue appears to have been reported upstream
>> before, but I can still reproduce it on Linux 7.2.0-rc3 with HEAD commit
>> 1137d8b5df06137fb49513cc923b3b24d94cb809.
>> 
>> The reproducer mounts a crafted msdos filesystem image, creates a very
>> long pathname, installs a fanotify mark, and then calls execve() on the
>> long path. During execve(), the file open path triggers fsnotify, which
>> then calls fanotify_handle_event(). While fanotify is constructing the
>> event, it hits a warning in fs/notify/fanotify/fanotify.h.
>> 
>> This looks like a fanotify name-event encoding robustness issue. A crafted
>> filesystem image together with a very long pathname appears to trigger an
>> unexpected name/fid event layout, and fanotify_info_copy_name() reaches a
>> WARN_ON_ONCE() path. The kernel should probably reject or truncate the
>> event cleanly instead of triggering a warning, because panic_on_warn turns
>> this into a kernel panic.
>
> fanotify complains that the name length is greater than NAME_MAX.  If I can
> guess, the problem likely is that the msdos filesystem (vfat?) allows a
> file name that is longer than NAME_MAX. Which would be a bug in the
> filesystem driver, not a problem in fanotify... Ogawa, care to have a look?

A patch looks like be applied to v7.3.
-- 
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>