openvpn: fix harness aborts and stalls in fuzz_route/fuzz_buffer

[tc-agent]

Summary

Three small fixes that let fuzz_route accumulate execs against OpenVPN/openvpn@fcc34b13, plus one matching guard in fuzz_buffer.

Fuzz Introspector (2026-05-09 baseline) shows the project at 10.07% line coverage: fuzz_base64 carries 62.27%, the other 9 harnesses each below 5%. fuzz_route was in the long tail.

Changes

fuzz_route — keep AI_NUMERICHOST in openvpn_getaddrinfo's retry loop (build.sh)

init_route_list and init_route_ipv6_list resolve user-supplied hostnames through openvpn_getaddrinfo, which first tries AI_NUMERICHOST and on failure clears the flag and re-enters getaddrinfo(3) for actual DNS. With random fuzz inputs almost never being numeric IPs, every iteration goes through the system resolver and pays its full timeout — leaving the harness at single-digit exec/s.

The patch keeps AI_NUMERICHOST set across the retry, so non-numeric inputs return EAI_NONAME immediately and the harness moves on. The patch lives inside apply_sed_changes() alongside the existing M_FATAL → M_WARN and socket-stub redirections.

fuzz_route — clamp r6.netbits to the IPv6 prefix range (fuzz_route.c)

The case-7 path constructs a route_ipv6 for add_route_ipv6. r6.netbits was randomized over 0..0xfffff, which is much wider than the legitimate IPv6 prefix range [0, 128]. Clamping it keeps the input in-range so the call exercises the real implementation rather than reaching the netlink layer with structurally invalid values.

fuzz_route — symmetric IPv6 cleanup (fuzz_route.c)

init_route_ipv6_list allocates route_ipv6 objects into rl6->gc. The harness already calls gc_free(&rl.gc) after the IPv4 path; the IPv6 counterpart was missing. Mirroring the existing cleanup adds the matching gc_free(&rl6.gc) when route_list_ipv6_inited is set.

fuzz_buffer — extend the existing BUF_SIZE_MAX guard to string_alloc_buf (fuzz_buffer.c)

The harness already gates buffer_list_push with strlen(tmp) < BUF_SIZE_MAX further down (line 228). The same kind of guard goes around the existing string_alloc_buf call, with a +1 for the trailing NUL that string_alloc_buf writes (strlen(tmp) + 1 < BUF_SIZE_MAX).

Validation

Built locally with --sanitizer=address against OpenVPN/openvpn@fcc34b13 (master). All ten harnesses ran for 5 minutes from an empty corpus; coverage measured with llvm-cov report over src/openvpn/src/openvpn:

Harness	Lines covered
fuzz_base64	62.27% (137 / 220)
fuzz_buffer	1.92% (953 / 49,605)
fuzz_dhcp	0.18% (91 / 49,390)
fuzz_list	0.91% (450 / 49,478)
fuzz_misc	0.80% (394 / 49,413)
fuzz_mroute	1.23% (609 / 49,415)
fuzz_packet_id	1.09% (538 / 49,443)
fuzz_proxy	2.21% (1,092 / 49,465)
fuzz_route	4.14% (2,051 / 49,538)
fuzz_verify_cert	0.02% (8 / 49,468)
TOTAL	9.68% (4,864 / 50,229)

The 5-minute total (9.68%) lands close to Fuzz Introspector's 24-hour figure (10.07%); the small gap is consistent with the shorter wall-time and a slightly different denominator (the local report covers only src/openvpn/src/openvpn).

[github-actions]

Fuzzing Coverage Report

Tested: project openvpn · base c4ba43b → head 602e977 · 300s total fuzz budget · updated 2026-05-27 19:25 UTC · workflow run

Metric	Before	After	Delta
Static reachability	>45m	>45m	—
Line coverage	9.0% (4527/50223)	9.9% (4949/50227)	+9.3%
Branch coverage	4.7% (1573/33117)	5.2% (1734/33121)	+10.2%
Function coverage	13.3% (301/2268)	14.4% (327/2268)	+8.6%

Per-harness

Harness	Lines before	Lines after	Δ
fuzz_base64	62.3% (137/220)	62.3% (137/220)	+0.0%
fuzz_buffer	1.9% (949/49602)	1.9% (951/49603)	+0.2%
fuzz_dhcp	0.2% (90/49389)	0.2% (90/49388)	+0.0%
fuzz_list	0.9% (450/49477)	0.9% (450/49476)	+0.0%
fuzz_misc	0.8% (393/49412)	0.8% (393/49411)	+0.0%
fuzz_mroute	1.2% (608/49414)	1.2% (608/49413)	+0.0%
fuzz_packet_id	1.1% (538/49442)	1.1% (538/49441)	+0.0%
fuzz_proxy	1.9% (928/49464)	1.9% (931/49463)	+0.3%
fuzz_route	3.2% (1584/49534)	4.1% (2039/49536)	+28.7%
fuzz_verify_cert	1.0% (518/49467)	1.0% (512/49466)	-1.2%

_{Δ = (after − before) / before, to accommodate that denominators may change. "new" when before is 0; "deleted" when after is 0.}