linux-kernel - [BUG] Hung task in path_openat (possible rwsem lock inversion)

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: <AA*AfQAzJ9UTkMPQtLhvWaq3.1.1765460422030.Hmail.2200013188@stu.pku.edu.cn>
Date: Thu, 11 Dec 2025 21:40:22 +0800 (GMT+08:00)
From: Tianyu Li <2200013188@....pku.edu.cn>
To: linux-kernel <linux-kernel@...r.kernel.org>
Cc: linux-fsdevel <linux-fsdevel@...r.kernel.org>, 
	viro <viro@...iv.linux.org.uk>, brauner <brauner@...nel.org>
Subject: [BUG] Hung task in path_openat (possible rwsem lock inversion)

Hi,

I'm encountering a hang in path_openat() that appears to involve an rwsem reader being blocked by a writer in the same tgid. The issue was first detected by a fuzzing framework on Linux 6.18-rc6, and I have confirmed that it is reproducible on Linux 6.18.

The task gets stuck in the following call chain:

    openat -&gt; path_openat -&gt; open_last_lookups -&gt; inode_lock_shared

The kernel logs indicate that the read-side rwsem is likely owned by a sibling thread (writer), which suggests a potential VFS/namei locking interaction. When reproduced on a test machine, the code would stably trigger a several-minute hang.

Additional information is provided below:

More information is provided 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(fuzz): https://github.com/Wxm-233/KConfigFuzz_crashes/raw/refs/heads/main/5d9d684e10184c0e83d615412abea5f59537ff18/report0
    Kernel log(repro): https://github.com/Wxm-233/KConfigFuzz_crashes/raw/refs/heads/main/5d9d684e10184c0e83d615412abea5f59537ff18/repro_report0
    Reproduction C Code: https://github.com/Wxm-233/KConfigFuzz_crashes/raw/refs/heads/main/5d9d684e10184c0e83d615412abea5f59537ff18/repro.cprog
    Syscall sequence for reproduction (more precise): https://github.com/Wxm-233/KConfigFuzz_crashes/raw/refs/heads/main/5d9d684e10184c0e83d615412abea5f59537ff18/repro.prog
    GCC info: https://github.com/Wxm-233/KConfigFuzz_crashes/raw/refs/heads/main/0f85fc661af1e3c69b26b97eaaaa43d629de449c/gccinfo

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

Best regards,
Tianyu Li