From: Michal Nowak <mnowak@isc.org>
Date: Thu, 21 May 2026 11:36:46 +0000 (+0200)
Subject: fix: dev: Validate nsec3hash arguments instead of relying on atoi()
X-Git-Tag: v9.21.23~43
X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=39314902916f304cd4863c7d203bb419091f813d;p=thirdparty%2Fbind9.git

fix: dev: Validate nsec3hash arguments instead of relying on atoi()

The nsec3hash tool parsed its algorithm, flags, and iterations
arguments with atoi(), then range-checked the result. For values
that overflow int during digit-by-digit accumulation, atoi() is
undefined; in practice on musl libc the modular wrap leaves
n == 0, which silently passes the "iterations > 0xffffU" check.
On Alpine Linux this made nsec3hash succeed with iterations
treated as 0 for inputs like 4294967296 (2^32).

The latent bug only surfaced when the recent image rebuild pulled
in Hypothesis 6.152.9 (2026-05-19), which unified the distribution
used for bounded and unbounded integers() strategies. The new
smoother distribution explores the 2^32 boundary on unbounded
ranges like integers(min_value=65536); earlier versions did not
reach there, so test_nsec3hash_too_many_iterations only started
failing on Alpine after the image refresh.

Replace the three atoi() calls with isc_parse_uint8 /
isc_parse_uint16, which uniformly reject overflow, trailing
garbage, leading sign, and non-numeric input across libc
implementations. As a side effect, error messages now include
the offending argument and a specific reason ("out of range" vs
"not a valid number").

Assisted-by: Claude:claude-opus-4-7

Closes #6013

Merge branch '6013-nsec3hash-iterations-overflow' into 'main'

See merge request isc-projects/bind9!12062
---

39314902916f304cd4863c7d203bb419091f813d