kern/60097: seemingly unsafe usage of round_page(off_t)

["imuwoto%gmail.com@localhost via gnats" <gnats-admin%NetBSD.org@localhost>]

>Number:         60097
>Category:       kern
>Synopsis:       seemingly unsafe usage of round_page(off_t)
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Mar 17 08:00:00 +0000 2026
>Originator:     YAMAMOTO Takashi
>Release:        -current
>Organization:
>Environment:
>Description:
the kernel often uses round_pages() macro on off_t/voff_t
to pass VOP_PUTPAGES and similar functions.

because off_t/voff_t is signed, "+ PAGE_MASK" in round_page()
can overflow, which is an UD, and typical compilers returns a negative
value, which is not safe to pass to VOP_PUTPAGES and similar apis.

similar roundup macros like ffs_blkroundup may have similar issues.

>How-To-Repeat:

>Fix:
for VOP_PUTPAGES arguments, i was thinking about something like the following:

+/*
+ * macros to round/trunc off_t/voff_t for VOP_PUTPAGES and similar
+ * functions.
+ *
+ * note that, because off_t/voff_t is signed, "+ PAGE_MASK" in round_page()
+ * can overflow, which is an UD, and typical compilers returns a negative
+ * value, which is not safe to pass to VOP_PUTPAGES and similar apis.
+ * off_round_page() detects such a case and returns 0, which means
+ * "up to the end of the object" for VOP_PUTPAGES and similar apis.
+ * off_trunc_page() is just for a symmetry.
+ */
+#define        off_round_page(x)       ((x) <= INT64_MAX - PAGE_MASK ? ((x) + PAGE_MASK) & ~PAGE_MASK : 0)
+#define        off_trunc_page(x)       (((x) & ~PAGE_MASK))

but i guess the problem is not only about VOP_PUTPAGES.

iirc, ffs's max file size is far smaller than INT64_MAX.
maybe we can reject user requests which exceeds the value
before entering file systems.
eg. by checking cached value of _PC_FILESIZEBITS.