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

[Yifei Chu]

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: 9p_lock_unknown_status_warn_panic.tar.gz
Description: Unix tar archive