kern/60554: nfs: integer shift UB in pathconf(_PC_FILESIZEBITS)

["campbell+netbsd%mumble.net@localhost via gnats" <gnats-admin%NetBSD.org@localhost>]

>Number:         60554
>Category:       kern
>Synopsis:       nfs: integer shift UB in pathconf(_PC_FILESIZEBITS)
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Aug 07 22:20:00 +0000 2026
>Originator:     Taylor R Campbell
>Release:        current, 11, 10, 9, ...
>Organization:
The NfsBSD Infinite Loop, Inc.
>Environment:
>Description:

	When nmp->nm_maxfilesize is 64 bits long, this logic to compute
	ilog2(nmp->nm_maxfilesize) overflows the shift into undefined
	behaviour:

   3226 			for (l = 0, maxsize = nmp->nm_maxfilesize;
   3227 			    (maxsize >> l) > 0; l++)
   3228 				;

https://nxr.netbsd.org/xref/src/sys/nfs/nfs_vnops.c?r=1.327#3218

	This can be provoked by an nfs server that returns a large
	maxfilesize in the FSINFO request.

>How-To-Repeat:

	1. Set up an NFS server with maxfilesize = 2^64 - 1 (e.g.,
	   FreeBSD serving from ZFS).

	2. Mount it on NetBSD.

	3. Run `getconf GETFILESIZEBITS /mnt'.

>Fix:

	Use ilog2(maxsize) instead of the bespoke loop, taking care to
	handle the fencepost error required by definition of
	_PC_FILESIZEBITS:

     _PC_FILESIZEBITS
             If the maximum size file that could ever exist on the mounted
             file system is maxsize, then the returned value is 2 plus the
             floor of the base 2 logarithm of maxsize.