linux-ext4 - [BUG] WARNING in gup_vma

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>] [day] [month] [year] [list]

Message-ID: <CAJNGr6tvycbeVx+C_ER-BDPsRK3M76B2ufQLDSvC79mUKwMGSA@mail.gmail.com>
Date: Thu, 15 May 2025 19:22:31 +0800
From: Guoyu Yin <y04609127@...il.com>
To: akpm@...ux-foundation.org
Cc: tytso@....edu, adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: [BUG] WARNING in gup_vma_lookup

Hi,

This crash occurs due to a mismatched symlink length validation in
ext4 when handling corrupted inode data, combined with improper stack
expansion handling in GUP. The crash can be reproduced through
syzkaller's filesystem stress tests involving symlink operations and
direct I/O writes.

The key issues are:

1. In __ext4_iget() at fs/ext4/inode.c:5012:

inode_set_cached_link() triggers a warning when detecting a symlink
with actual length 39 bytes while expecting 29 bytes. This indicates
either disk corruption or a kernel bug in symlink length handling. The
problem likely stems from improper validation of i_extra_isize and
fast symlink storage in ext4_inode.

2. In gup_vma_lookup() at mm/gup.c:1362:

The warning "GUP no longer grows the stack" appears when handling VMA
lookups for addresses below the stack region. This occurs during
direct I/O writes (ext4_dio_write_iter) when pin_user_pages_fast()
attempts to access user memory near stack boundaries, but the kernel
refuses to expand the stack automatically.

Suggested fixes:

1. For ext4: Add stronger validation of i_extra_isize and inline data
size before calling inode_set_cached_link() in __ext4_iget

2. For GUP: Re-examine the stack growth policy when handling direct
I/O operations near stack boundaries to avoid filesystem corruption
cascades

This can be reproduced on:

HEAD commit:

38fec10eb60d687e30c8c6b5420d86e8149f7557

report: https://pastebin.com/raw/wDUgDsV0

console output : https://pastebin.com/raw/HndaBU1E

kernel config : https://pastebin.com/raw/u0Efyj5P

C reproducer :

part1: https://pastebin.com/raw/3AA1ZHUd

part2: https://pastebin.com/raw/0LaFkaAd