linux-kernel - Re: [PATCH v2] mul_u64_u64_div_u64: fix the division-by-zero behavior

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <8s09r460-1523-728p-33pn-p7nn3655so4o@onlyvoer.pbz>
Date: Mon, 16 Jun 2025 17:54:34 -0400 (EDT)
From: Nicolas Pitre <npitre@...libre.com>
To: David Laight <david.laight.linux@...il.com>
cc: Andrew Morton <akpm@...ux-foundation.org>, 
    Thomas Weißschuh <linux@...ssschuh.net>, 
    Oleg Nesterov <oleg@...hat.com>, 
    Uwe Kleine-König <u.kleine-koenig@...libre.com>, 
    Peter Zijlstra <peterz@...radead.org>, 
    Biju Das <biju.das.jz@...renesas.com>, linux-kernel@...r.kernel.org, 
    Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH v2] mul_u64_u64_div_u64: fix the division-by-zero
 behavior

On Mon, 16 Jun 2025, David Laight wrote:

> On Mon, 16 Jun 2025 15:22:44 -0400 (EDT)
> Nicolas Pitre <npitre@...libre.com> wrote:
> 
> > The current implementation forces a compile-time 1/0 division, which
> > generates an undefined instruction (ud2 on x86) rather than a proper
> > runtime division-by-zero exception.
> > 
> > Change to trigger an actual div-by-0 exception at runtime, consistent
> > with other division operations. Use a non-1 dividend to prevent the
> > compiler from optimizing the division into a comparison.
> 
> Given there is a definite 'plan' to avoid adding more BUG() to code
> I'm not at all sure generating UB here is right at all.
> 
> I don't know the best solution though.

The best solution is to be coherent with all the other divisions. They 
have well known behaviors, people are ready for them, debuggers are 
ready for them. If a given architecture doesn't trap and returns zero 
then with this patch we'll return zero too. If another arch raises an FP 
exception then we'll raise an FP exception. Coherency is the key.

> To my mind returning zero for divide by zero and ~0 for overflow is least
> likely to cause real grief later on in the called code.

Maybe. But that would be unexpected for some. Plenty of raw divisions 
without helper wrappers are out there. They won't all just produce 0.


Nicolas