linux-kernel - [BUG] strlen overflow in ext4 parse_apply_sb_mount

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: <AAQA6gDeJ9AKoitjlGagc4q*.1.1765285478995.Hmail.2200013188@stu.pku.edu.cn>
Date: Tue, 9 Dec 2025 21:04:38 +0800 (GMT+08:00)
From: Tianyu Li <lty218@....pku.edu.cn>
To: linux-kernel <linux-kernel@...r.kernel.org>
Cc: tytso <tytso@....edu>, "adilger.kernel" <adilger.kernel@...ger.ca>, 
	linux-ext4 <linux-ext4@...r.kernel.org>
Subject: [BUG] strlen overflow in ext4 parse_apply_sb_mount_options

Hi,

I discovered an issue on kernel 6.18 where ext4's parse_apply_sb_mount_options calls strnlen on a 64-byte kernel buffer and reads 65 bytes, triggering __fortify_report:
"strnlen: detected buffer overflow: 65 byte read of buffer size 64". This issue is first found via a fuzzing framework on linux6.18-rc6, then it is confirmed reproducible on linux6.18. On the test environment WARN is promoted to panic (panic_on_warn), so the warning causes a kernel panic and reboot.

parse_apply_sb_mount_options appears to call string helpers on a buffer that may not be NUL-terminated or properly length-bounded for user-supplied mount options, allowing strnlen to read past the 64-byte buffer, causing the code to run into a WARN zone.

Relevant materials are listed below:

    Kernel source: https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.18.tar.xz
    Kernel configuration: https://github.com/j1akai/KConfigFuzz_bug/raw/refs/heads/main/x86/mainline-config
    Kernel log(fuzzing): https://github.com/Wxm-233/KConfigFuzz_crashes/raw/refs/heads/main/b487b64ad500511b29a368007dc3d7456e767929/report0
    Kernel log(repro): https://github.com/Wxm-233/KConfigFuzz_crashes/raw/refs/heads/main/b487b64ad500511b29a368007dc3d7456e767929/repro_report0
    Reproduction C code: https://github.com/Wxm-233/KConfigFuzz_crashes/raw/refs/heads/main/b487b64ad500511b29a368007dc3d7456e767929/repro.cprog
    Syscall sequence for reproduction (more precise): https://github.com/Wxm-233/KConfigFuzz_crashes/raw/refs/heads/main/b487b64ad500511b29a368007dc3d7456e767929/repro.prog
    GCC Info: https://github.com/Wxm-233/KConfigFuzz_crashes/raw/refs/heads/main/b42a57a980ac99dba76418f8daaa80e2a90831a1/gccinfo

I hope this report helps in identifying and resolving the issue. Thanks for your time and attention.

Best regards.