[PATCH 1/2] Add advisory text for CVE-2026-4437

[Carlos O'Donell]

On 3/20/26 7:46 PM, Collin Funk wrote:
> Carlos O'Donell <carlos@redhat.com> writes:
> 
>> Explain the security issue and set the context for the vulnerability to
>> help downstreams get a better understanding of the issue.
>> ---
>>   advisories/GLIBC-SA-2026-0005 | 35 +++++++++++++++++++++++++++++++++++
>>   1 file changed, 35 insertions(+)
>>   create mode 100644 advisories/GLIBC-SA-2026-0005
>>
>> diff --git a/advisories/GLIBC-SA-2026-0005 b/advisories/GLIBC-SA-2026-0005
>> new file mode 100644
>> index 0000000000..f668534139
>> --- /dev/null
>> +++ b/advisories/GLIBC-SA-2026-0005
>> @@ -0,0 +1,35 @@
>> +gethostbyaddr and gethostbyaddr_r may incorrectly handle DNS response
>> +
>> +Calling gethostbyaddr or gethostbyaddr_r with a configured nsswitch.conf
>> +that specifies the library's DNS backend in the GNU C Library version
>> +2.34 to version 2.43 could, with a crafted response from the configured
>> +DNS server, result in a violation of the DNS specification that causes
>> +the application to treat a non-answer section of the DNS response as a
>> +valid answer.
>> +
>> +A defect in the getanswer_ptr function, which implements the iteration
>> +and extraction of the answer from the DNS response, can cause it to
>> +incorrectly transition from the answer section to the next section while
>> +still treating it as an answer to the question.  This can happen when
>> +the answer contains only skipped records, and the subsequent section
>> +contains a semantically invalid T_PTR record.  This is considered a
>> +security issue because it is a violation of the DNS specification that
>> +leads to incorrect behaviour that could result in the wrong hostname
>> +being returned to the caller.
> 
> This all looks correct to me.
> 
>> At the time of publication, no known
>> +affected DNS server returns results that would be incorrectly
>> +interpreted by the library.  An attacker would either need to be network
>> +adjacent or have compromised the DNS server to use this defect to hide
>> +returned reverse DNS results from intrusion detection systems. Even
>> +then, the inbound connection from the attacker, or the outbound
>> +connection from the application, would be visible to the intrusion
>> +detection system.  At best, the defect can be used to obfuscate and
>> +delay analysis of the evolving threat.
> 
> This is probably correct, but I don't know enough about DNS server
> implementations to say. It would nice if someone else could review that
> part.
> 
>> +CVE-Id: CVE-2026-4437
>> +Public-Date: 2026-03-19
>> +Vulnerable-Commit: 32e5db37684ffcbc6ae34fcc6cdcf28670506baa (2.34-323)
>> +Vulnerable-Commit: def97e7f71a07517810f7263213d607e08ad21f1 (2.35-188)
>> +Vulnerable-Commit: 77f523c473878ec0051582ef15161c6982879095 (2.36-30)
>> +Vulnerable-Commit: e32547d661a43da63368e488b6cfa9c53b4dcf92 (2.37)
>> +Reported-by: Antonio Maini (0rbitingZer0) - 0rbitingZer0@proton.me
>> +Reported-by: Kevin Farrell
> 
> Those commits correct to me. Here is the relevant section of the diff:
> 
>      -  while (ancount-- > 0 && cp < end_of_message && had_error == 0)
>      +  while (ancount > 0)
> 
> Reviewed-by: Collin Funk <collin.funk1@gmail.com>

Thanks! This is exactly the kind of sanity check I want.

Another human looking at the same thing, and thinking about anything
I might have missed. Or even someone *without* the relevant experience
seeing something I didn't see because I have a bias.

Given that the security team reviewed, and you independently reviewed,
that's good enough for me to push and we can always fix up later.

-- 
Cheers,
Carlos.