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@lists.thekelleys.org.uk >> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss >> _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
