[Dnsmasq-discuss] [BUG] [PATCH] Segmentation fault in src/forward.c

Simon Kelley simon at thekelleys.org.uk
Thu Sep 23 10:28:34 UTC 2021



On 22/09/2021 23:07, Petr Menšík wrote:
> Good catch. A new bug #2006367 [1] were also reported on Fedora. It
> seems to point to related structures and memory corruption in them. I
> have no coredump to check it (yet), so mostly guessing.
> 
> Juggling with type unsafe structures with few common members is quite
> bad idea. I think those structures should contain common server_local
> struct member at the start. They could pass pointer to it on every place
> which needs working just with those common parts.
> 
> On domain-match.c:677 is also suspicious memset. Its flags are not
> directly related to allocated size. I think there might be a case, when
> it overwrites more memory than allocated for the pointer. On line 696 it
> may overwrite interface target even with flags SERV_4ADDR | SERV_6ADDR.
> Both allow rewriting uid member when HAVE_LOOP is set, which is a
> default. 

SERV_IS_LOCAL is defined at the top of the file, and provides a simple
check. If that's NOT true then the record is a complete server struct.
If it is set then it's a struct serv_local, possibly with added IPv4 or
IPV6 address, controlled by the SERV_4ADDR and SERV_6ADDR flags bits.

/* If the server is USE_RESOLV or LITERAL_ADDRESS, it lives on the
local_domains chain. */
#define SERV_IS_LOCAL (SERV_USE_RESOLV | SERV_LITERAL_ADDRESS)

With that information, it's fairly easy to see that the code is correct.

The problem here was nothing to do with this code, the domain search
code assumed that --server=/example.com/# would not be set along with
--server=/example.com/<address> and when that was done, it wrongly
returned BOTH server records, each if which has different lengths. The
consumer of that set of records  assumed (as it was entitled to do) they
were of the same type and length, hence the dereferencing of fields
outside allocated memory.

>I see many tricky corners without simple and readable checks
> ensuring it always does what it should. I think char type enum would
> definitely not hurt in common structure instead of this juggling with
> flags. It would be much more clear what members are available. I think
> default struct should be the smallest one and only retyped to bigger
> struct, if some flag clearly indicated it is there. Preferred would be
> separate type member.

A major goal of this rewrite was to avoid wasting memory when there are
100,000 --address=/adserver.com/ lines in the configuration. Doing what
you suggest would break that.
> 
> At first it should be fixed by minimal fix. I think constant sized
> structure with some unused members would be far more safe. I think union
> would be good candidate here. Its a pity we did not notice those issues
> before release. I should spend some time on basic automated tests again.
> I think dnsmasq it small, but needs more regular testing.
> 


Agree entirely. I still have you test system in a git branch, and would
like to progress it. It would have been nice to find the regression
(removal) of --address=/#/..... before release.


Cheers,

Simon.



> Cheers,
> 
> Petr
> 
> 1. https://bugzilla.redhat.com/show_bug.cgi?id=2006367
> 
> On 9/16/21 16:31, Dominik DL6ER wrote:
>> Addendum: Depending on the configuration, it can happen that the
>> query is sent to another server that is configured to be used for
>> an altogether different domain, e.g.
>>
>>> server=127.0.0.1#5353
>>> server=::1#5353
>>> rev-server=192.168.0.1/24,192.168.0.1
>>> server=/fritz.box/192.168.0.1
>>> server=/bo.net/#
>>> address=/bo.net/#/
>> resulting in "A bo.net" being sent to 192.168.0.1
>>
>> Something is definitely fishy here.
>>
>> Best,
>> Dominik
>>
>>
>> _______________________________________________
>> Dnsmasq-discuss mailing list
>> Dnsmasq-discuss at lists.thekelleys.org.uk
>> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
>>



More information about the Dnsmasq-discuss mailing list