I am afraid I forgot to actually send the first bigger part, explaining
my motivation.
Replaced patches in original message with the latest one. More comments
below.
On 9/24/21 00:36, Simon Kelley wrote:
> On 23/09/2021 18:16, Petr Menšík wrote:
>> I am quite sure also --rebind-domain-ok is
Hi Simon,
I made attempt to move common local entries to only local struct. It
then requires explicit retyping on every place where members of struct
server needs to be updated. Makes it simpler to search all places where
full fledged server is required. I am a bit uncertain how should first
and
On 23/09/2021 18:16, Petr Menšík wrote:
> I am quite sure also --rebind-domain-ok is broken. It allocates struct
> serv_local, but does not set any flags if I saw it correctly. Therefore
> it would be later threated as struct server and checked in wrong places.
Those structures are kept on a
I am quite sure also --rebind-domain-ok is broken. It allocates struct
serv_local, but does not set any flags if I saw it correctly. Therefore
it would be later threated as struct server and checked in wrong places.
That is still unfixed even after commit
de372d6914ae20a1f9997815f258efbf3b14c39b.
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
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
>
Hi again,
after applying my patch from my previous mail, dnsmasq stopped
crashing. However, this only started to reveal abnormal and
partially conflicting behavior in certain configurations.
For instance, using the new attached configuration does make
dnsmasq behave strangely. The log contains
Hey Simon,
today we discovered a segmentation fault in
forward.c:allocate_rfd().
It checks "if (serv->sfd)" before accessing "serv->sfd->fd".
However, we've seen that the value of serv->sfd can be arbitrary
nonsense (such as 0xa1), hence, the access causes a crash here.
The reason for this is
