[PATCH] resolv: Count records, and check hostname (CVE-2026-4437, CVE-2026-4438)

[Carlos O'Donell]

On 3/20/26 4:11 PM, Florian Weimer wrote:
> * Carlos O'Donell:
> 
>> The answer section boundary was previously ignored, and the code in
>> getanswer_ptr would iterate past the last resource record, but not
>> beyond the end of the returned data.  This could lead to subsequent data
>> being interpreted as answer records, thus violating the DNS
>> specification.  Such resource records could be maliciously crafted and
>> hidden from other tooling, but processed by the glibc stub resolver and
>> acted upon by the application.  While we trust the data returned by the
>> configured recursive resolvers, we should not trust its format and
>> should validate it as required.  It is a security issue to incorrectly
>> process the DNS protocol.
>>
>> The processed hostname in getanswer_ptr should be correctly checked to
>> avoid invalid characters from being allowed, including shell
>> metacharacters. It is a security issue to fail to check the returned
>> hostname for validity.
>>
>> These two issues are considered distinct CVEs, but are fixed in one
>> commit to make the update process easier, given that they change the
>> same file and function.
>>
>> Regression tests are added for invalid metacharacters and response
>> section crossing.
>>
>> No regressions on x86_64-linux-gnu.
>> ---
>>   resolv/Makefile                 |   7 +
>>   resolv/nss_dns/dns-host.c       |   4 +-
>>   resolv/tst-resolv-dns-section.c | 161 ++++++++++++++++++++
>>   resolv/tst-resolv-invalid-ptr.c | 258 ++++++++++++++++++++++++++++++++
>>   4 files changed, 428 insertions(+), 2 deletions(-)
>>   create mode 100644 resolv/tst-resolv-dns-section.c
>>   create mode 100644 resolv/tst-resolv-invalid-ptr.c
> 
> I don't quite understand why this is a single commit for two bugs that
> have very different impact, fixes, and even separate test cases.

The justification is in the commit log? :-)
~~~
These two issues are considered distinct CVEs, but are fixed in one
commit to make the update process easier, given that they change the
same file and function.
~~~
  
> Why not split this into two?  That makes the accompanying advisory text
> clearer, too.

Would you still like them split up?

I don't have a strong opinion.

-- 
Cheers,
Carlos.