[PATCH] resolv: Fix assertion failure on search list truncation [BZ 31026, CVE-2026-8674]

[Adhemerval Zanella Netto]

On 15/09/26 08:11, Florian Weimer wrote:
> * Adhemerval Zanella:
> 
>> update_from_conf copies the search list into the 256-byte
>> resp->defdname and truncates it when an entry does not fit, then
>> asserts that resolv_conf_matches accepts the result.
>>
>> The truncation check there compared the accumulated size against
>> sizeof (resp->dnsrch) (the pointer array) instead of resp->defdname,
>> and the empty-list case did not account for a first entry that does
>> not fit at all.  A long search domain in resolv.conf or LOCALDOMAIN
>> thus aborts any process using the resolver.
>>
>> Check whether the entry fits in the remaining defdname space, matching
>> alloc_buffer_copy_string, and also accept an empty resp->dnsrch when
>> the first entry is too long.  Add tests covering both cases through
>> the search and domain directives.
> 
> Why is this considered a vulnerability?  I can see that this data can
> come from DHCP, but DHCP can easily serve bad name servers, and then
> name resolution is busted, too.
> 
> Is the concern that once the system has learned the bad data, it won't
> boo anymore?

The concern came from the exchange with Hùng Nguyen, where he pointed out:

  --
  And I find systemd-resolved (which most systems now use) is safe.
  However, sometimes people just use dhclient, ifup, or ifdown
  (with dhclient as a dependency) because some tutorials on
  the internet says they are useful despite it's out of support.
  The demo here for dhclient [1]

  1) Using OpenVPN mean user trust the network configuration's
  for networking domain. Anything other than network should stay
  intact. There is a common configuration [4] involved 
  `  update-resolv-conf` script to update /etc/resolv.conf.
  --
  There are something I'd like to clarify about my last email:
  - The DHCP config sent from the OpenVPN server is valid 
  (<= 253 characters) while show_bug.cgi?id=31026 
  showed a non RFC search domain that has >253 bytes requiring
  direct modification to resolv.conf 
  - dhclient will accept domain lenght of >253 bytes due to a bug.
  - systemd-resolved will not take "search" option so no direct
  local network attack.
  - systemd-resolved combines with OpenVPN's update-resolv-conf
  put "search" into resolv.conf => reached assert
  --

It is been some months since I dug into this, but seems that some
arcane DHCP configurations (like https://protonvpn.com/support/linux-openvpn)
might be subject to this issue.

> 
> The patch iself looks okay.
> 
> Reviewed-by: Florian Weimer <fweimer@redhat.com>
> 
> Thanks,
> Florian