URL:
<https://savannah.gnu.org/bugs/?65452>
Summary: Possibly incomplete bounds check after strtol(3)
Group: GNU roff
Submitter: barx
Submitted: Mon 11 Mar 2024 12:41:01 PM CDT
Category: Utilities
Severity: 2 - Minor
Item Group: Incorrect behaviour
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any
Planned Release: None
_______________________________________________________
Follow-up Comments:
-------------------------------------------------------
Date: Mon 11 Mar 2024 12:41:01 PM CDT By: Dave <barx>
Alejandro Colomar posted this concern to the email list:
http://lists.gnu.org/r/groff/2024-01/msg00054.html. His analysis looks sound,
but the code was never updated to address it.
I see some code calling strtol(3) that I suspect won't behave well in
some systems:
$ grepc -tfd check_integer_arg .
./src/utils/indxbib/indxbib.cpp:static void check_integer_arg(char opt, const
char *arg, int min, int *res)
{
char *ptr;
long n = strtol(arg, &ptr, 10);
if (n == 0 && ptr == arg)
error("argument to -%1 not an integer", opt);
else if (n < min)
error("argument to -%1 must not be less than %2", opt, min);
else {
if (n > INT_MAX)
error("argument to -%1 greater than maximum integer", opt);
else if (*ptr != '\0')
error("junk after integer argument to -%1", opt);
*res = int(n);
}
}
I think these tests miss some corner cases:
- If INT_MAX==LONG_MAX, then n>INT_MAX is impossible, but strtol(3)
will return LONG_MAX and errno ERANGE for values greater than that.
groff is silently accepting input >LONG_MAX in those systems, and
silently saturating it to LONG_MAX (INT_MAX).
- If min==INT_MIN==LONG_MIN, then a similar thing happens for underflow.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?65452>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
