Re: [v2 PATCH] arith: Fix CVE-2026-31323 INTMAX_MIN / -1 overflow

On 13/04/2026 03:28, Herbert Xu wrote:
> On Wed, Apr 08, 2026 at 04:47:10PM +0800, 都觉得就到家 wrote:
>> Division and remainder currently guard against division by zero, but not
>> against the signed overflow case INTMAX_MIN / -1. On affected systems
>> this can trigger SIGFPE during arithmetic expansion.
>>
>> Add an explicit guard before evaluating division or remainder.
>>
>> Signed-off-by: Muchen Hou <[email protected]&gt;
> 
> Thanks for the patch.  For future submissions please send your
> email as plain-text, as otherwise it will be rejected by the
> mailing list.
> 
> I'm resending your patch with an additional change to combine it
> with the existing divide by zero check:
> 
> ---8<---
> From: Muchen Hou <[email protected]>
> 
> Division and remainder currently guard against division by zero, but not
> against the signed overflow case INTMAX_MIN / -1. On affected systems
> this can trigger SIGFPE during arithmetic expansion.
> 
> Add an explicit guard before evaluating division or remainder.
> 
> Signed-off-by: Muchen Hou <[email protected]>
> 
> Merge the overflow check with the zero division check.
> 
> Signed-off-by: Herbert Xu <[email protected]>
> 
> diff --git a/src/arith_yacc.c b/src/arith_yacc.c
> index 1a087c3..b978ef0 100644
> --- a/src/arith_yacc.c
> +++ b/src/arith_yacc.c
> @@ -98,8 +98,8 @@ static intmax_t do_binop(int op, intmax_t a, intmax_t b)
>   	default:
>   	case ARITH_REM:
>   	case ARITH_DIV:
> -		if (!b)
> -			yyerror("division by zero");
> +		if (!b || (a == INTMAX_MIN && b == -1))
> +			yyerror("division error");
>   		return op == ARITH_REM ? a % b : a / b;
>   	case ARITH_MUL:
>   		return a * b;

This looks fine if it's a conscious decision, but it differs from what 
dash generally does when the result of arithmetic is not representable 
in intmax_t, and also differs from bash. Depending on the reason there's 
apparently a CVE for this, this may be an issue, see below.

In dash, for arithmetic where the mathematically correct result is 
9223372036854775808, the result is usually converted to 
-9223372036854775808. Division of -9223372036854775808 by -1 is one of 
the few exceptions.

In bash, for arithmetic where the mathematically correct result is 
9223372036854775808, the result is usually converted to 
-9223372036854775808. Division of -9223372036854775808 by -1 follows the 
general rule.

It would be more consistent with dash's general handling to match bash. 
Alternatively, raising errors on all arithmetic overflow would also be 
consistent. But having it differ from one operation to the next is, I 
think, hard to explain.

Looking at the CVE for more context, 
https://www.cve.org/CVERecord?id=CVE-2026-31323 just says "This ID has 
been reserved by a CNA." I'm curious how this is a vulnerability: if you 
can execute arbitrary shell scripts, you can get SIGFPE much easier by 
just doing 'kill -FPE $$'. If that is not the reason for the CVE, if 
instead there are certain shell scripts that can be forced to exit 
unexpectedly that way that do not exit in bash, note that the proposed 
fix *still* forces most of the same shell scripts to exit unexpectedly 
that way, because that is the default handling of arithmetic errors.

Cheers,
Harald van Dijk