Bug 2491587 (CVE-2026-12244)

Summary: CVE-2026-12244 nsd: A specially crafted SVCB RR can cause a heap overflow of up to 65509 attacker controlled bytes.
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: unspecifiedCC: security-response-team
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in nsd. When nsd is configured as a secondary server for a zone, a remote attacker, acting as the primary server for that zone, can send a specially crafted DNS message within an AXFR (Asynchronous Full Zone Transfer) request. This message, containing a malformed SVCB (Service Binding) resource record, can cause a heap overflow, leading to arbitrary code execution. This vulnerability poses a significant risk, especially in multi-tenant secondary DNS deployments, due to the potential for a controlled write of a large amount of data.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 2494186, 2494188    
Bug Blocks:    
Deadline: 2026-06-25   

Description OSIDB Bzimport 2026-06-22 23:38:10 UTC 
If NSD is configured as secondary for a zone, the primary of that zone can crash NSD with an AXFR containing a DNS message with a special crafted SVCB RR with an rdata size of 65512, that let's an (uint16_t) variable that is used to allocate space needed for the RR wrap (because total size > 65535), causing a heap overflow. The attacker can perform a controlled (RCE class) head write of up to 65509 bytes.

Even though the data is from a configured primary inside NSD's trust boundary, we do consider the risk significant enough for multi-tenant secondary DNS deployments, given the potential severity of the attack.