[BUG] fs: listns and listmount wrap UINT64_MAX cursors

[shaos]

Hello,

Both listns() and listmount() use a cursor representing the last returned ID, then advance it by one before looking up the next entry. With UINT64_MAX, that addition wraps to zero and restarts enumeration at the first visible entry.

The unprivileged probe reproduced this in listns() with unified, user-type, and owner filters: a UINT64_MAX cursor returned the same first page as cursor zero, while UINT64_MAX-1 returned ENOENT. It also reproduced the wrap in listmount(): with mnt_id=LSMT_ROOT selecting the root mount and param as the pagination cursor, param=UINT64_MAX returned the same first mount ID as param=0, while UINT64_MAX-1 returned no entries. LSMT_ROOT is the mount selector here; param is the cursor.

The test ran as UID 65534. This is an enumeration correctness bug; I do not claim a permission bypass or security-boundary impact.

HEAD commit:    24a19b953e2a3d0ea5a8c4951a0ab8f32720c907
source version: Linux 7.3.0-rc7
architecture:   x86-64
compiler:       gcc 11.4.0, GNU ld 2.38
QEMU:           6.2.0

console output: https://gist.githubusercontent.com/shaos26/b969791763b73e5897a3e749e31ea0af/raw/6abe5584dcb21dabe3f1e32611885bafe469a67a/console-output.txt
kernel config: https://gist.githubusercontent.com/shaos26/b969791763b73e5897a3e749e31ea0af/raw/9f9827ed98f86fd3364ef758da73936884e02ea3/kernel-config.txt
reproducer: https://gist.githubusercontent.com/shaos26/b969791763b73e5897a3e749e31ea0af/raw/986396bf363269b001cee6adac6a69781d52f6d6/poc.c

Build the kernel from the revision above with the attached config and place the static probe at /init in the supplied initramfs. A fresh unprivileged replay used:

    timeout 120 qemu-system-x86_64 -accel tcg,thread=single -cpu max \
        -m 1024 -smp 1 -kernel artifacts/bzImage \
        -initrd artifacts/initramfs-r02-unpriv.cpio.gz \
        -append "console=ttyS0 rdinit=/init panic=-1 oops=panic nokaslr loglevel=7" \
        -nographic -no-reboot

The guest reported RESULT=CURSOR_WRAP_OBSERVED as UID 65534 and exited cleanly. I checked the affected cursor additions at f47d223627f8; runtime validation was on v7.3-rc7.

Thanks,

shaos