[BUG] 9p: unknown RLOCK status triggers WARN_ONCE panic with panic_on_warn

[BUG] 9p: unknown RLOCK status triggers WARN_ONCE panic with panic_on_warn

[Yifei Chu]

[-- Attachment #1.1: Type: text/plain, Size: 1420 bytes --]

Hello,

Short version: I found that a 9P2000.L server can return an unknown RLOCK
status byte and make the Linux 9P client hit a WARN_ONCE() in
v9fs_file_do_lock(). With panic_on_warn=1, that turns into a reproducible
kernel panic.

The reproducer is small: it starts a minimal fd-transport 9P2000.L server,
mounts it, opens a file, and calls fcntl(F_SETLK). The server replies to
TLOCK with:

RLOCK status = 0xff

That server-controlled value reaches this path in the client:

WARN_ONCE(1, “unknown lock status code: %d\n”, status);

Tested environment:

Linux version 7.0.9, x86_64 QEMU
gcc 12.3.0, GNU ld 2.38
Boot args included: panic_on_warn=1 nokaslr console=ttyS0

The panic I see is:

unknown lock status code: 255
WARNING: fs/9p/vfs_file.c:201 at v9fs_file_do_lock+0x614/0x730
Kernel panic - not syncing: kernel: panic_on_warn set …

I also checked current mainline source and still see the WARN_ONCE path in
fs/9p/vfs_file.c. I have reproduced the panic on the 7.0.9 QEMU build
above; I have not yet runtime-tested current mainline.

My read is that an unknown status from a protocol peer should probably be
handled as a protocol/locking error instead of reaching WARN_ONCE().
Returning something like -EPROTO or -ENOLCK, with a non-WARN diagnostic if
useful, seems safer.

The attached tarball has the README, C reproducer, and full QEMU log.

Thanks,
Chuyifei

[-- Attachment #1.2: Type: text/html, Size: 1510 bytes --]

[-- Attachment #2: 9p_lock_unknown_status_warn_panic.tar.gz --]
[-- Type: application/x-tar, Size: 14302 bytes --]

Re: [BUG] 9p: unknown RLOCK status triggers WARN_ONCE panic with panic_on_warn

[Dominique Martinet]

Yifei Chu wrote on Sun, May 24, 2026 at 10:43:57AM -0400:
> Short version: I found that a 9P2000.L server can return an unknown RLOCK
> status byte and make the Linux 9P client hit a WARN_ONCE() in
> v9fs_file_do_lock(). With panic_on_warn=1, that turns into a reproducible
> kernel panic.

You're right we should not WARN() due to server sending us bogus data
(only on internal state bug)

Please send a patch directly next time, especially since this is trivial

I've saved us both time for this time:
https://lore.kernel.org/r/20260529-lock-warn-v1-1-20c29580d61d@codewreck.org

-- 
Dominique