REDHAT-BUG-2458519: Medium severity Nlnet Labs Unbound vulnerability
In forward.c:724, processreply() calls checksource(header, plen, pheader, querysource) but plen at this point holds the OPT record length (~23 bytes), not the packet length n. With the wrong length, all bounds checks inside checksource() fail and the function unconditionally returns 1, bypassing RFC 7871 Section 9.2 ECS source validation entirely. Fix: change plen to n in the function call.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
In forward.c at line 724 within process_reply(), change the call from check_source(header, plen, pheader, query_source) to check_source(header, n, pheader, query_source) so check_source() receives the correct packet length n and RFC 7871 Section 9.2 ECS source validation is not bypassed.
forward.c (process_reply/check_source) plend-to-n argument in check_source() call = Use packet length n instead of plen (~OPT record length)
Event History
Frequently Asked Questions
What should be verified in a local fix or downstream backport?
Verify that process_reply() passes n, the packet length, rather than plen to check_source(). Using plen causes the ECS source-validation bounds checks to fail and check_source() to return 1.
Which vendor advisories are associated with this issue?
The provided references list RHSA-2026:19158, RHSA-2026:19373, and RHSA-2026:20589.