A few minutes ago, there was a published security advisory for dnsmasq by OpenWrt developers. The full announcement can be found here: https://openwrt.org/advisory/2021-01-19-1
There are vulnerabilities in dnsmasq and it’s known as DNSpooq. There are two types of vulnerabilities - DNS cache poisoning attacks and buffer overflow vulnerabilities.
OpenWrt decided to do a new release - OpenWrt 19.07.6, which fixes or mitigates this vulnerability. We will shortly announce a new version of Turris OS in the Testing branch, which will be based on this version to make your routers safe.
The default configuration of Turris OS is not affected because we use knot-resolver (Omnia and Mox) and unbound (Turris 1.x) as the default DNS recursive resolver instead of dnsmasq.
Fixed in Turris OS 5.1.7.
OpenWrt 19.07.6 release were released at 23:56 (GMT+1) on 19th January
Turris OS 5.1.7 was released in HBT (Testing branch) on 20th January at 21:07 (GMT+1), and it reached the Stable branch on 22nd January at 00:42 (GMT+1).
Versions of Turris OS 3.x are still vulnerable to this issue. We are working on it, but there are some obstacles as when we were testing this dnsmasq was not properly working for us and we need to solve it first.
I just want to note that the new version of dnsmasq contains an error that causes much of errors in the log file:
Jan 23 11:56:47 turris dnsmasq[6233]: failed to send packet: Network unreachable
Jan 23 11:56:47 turris dnsmasq[6233]: failed to send packet: Network unreachable
Jan 23 11:56:48 turris dnsmasq[6233]: failed to send packet: Network unreachable
I’m aware of it and it is discussed on many channels as you pointed. I can add e.g. #openwrt-adm, #openwrt-devel on Freenode. To be fair, it affects just a few setups and it does not affect every installation.
AFAIK dnsmasq developer was notified yesterday about it and it was found out that it affects when you are using a local DoH or similar proxy with dnsmasq. Basically when dnsmasq itself is sending to 127.0.0.1/::1.
However, I’d like to release a new version during next week to avoid these messages in systemlog.