Reproducible by listening on an interface by name, ASAN reports a
heap-buffer-overflow. This was a regression caused by !1286, which did
not account for null-terminators properly.

Tom Herbers authored 2 years ago and Vladimír Čunát committed 2 years ago

It's resonable to assume that people would also want to disable DNS64 for
IPv4 source addresses if they only enable it for some IPv6 sources.

Close https://github.com/CZ-NIC/knot-resolver/pull/83

https://gitlab.nic.cz/knot/knot-resolver/-/jobs/802541#L272

I don't know how to fix building the image with it.
A few things were tried around different go versions (from -backports).

release 5.5.3

See merge request !1343

It's a mitigation for CVE-2022-40188 and similar DoS attempts.
It's using really trivial approaches, at least for now.

This fixes config_tests on aarch64 macOS.
The key difference is that they use 16k pages,
so LMDB space usage also behaves a bit different.

That option isn't supported there, so the test wouldn't work.
Now the config tests work for me on x86 macOS.

Enums are more like ints anyway (in standard),
even when drawn from a small subset.

So far the message wasn't pointing to freebind at all:
[net   ] bind to '::1@53' (UDP): Operation not supported

I used preprocessor to avoid duplication and unused warnings.

Another way would be to ignore the freebind option if not supported,
but I think it's better to convince users not to specify it.

release 5.5.2

See merge request !1337

21.10 isn't supported anymore, which is probably why it's failing.

We've already done that on OBS side, which is probably why it's failing.

https://github.com/lunarmodules/luacov/issues/99

We're mostly using those in NEWS and first line of commit messages.
I'm not sure if they're much better than alternatives, but at least
consistency is nice.

This caused a huge increase in real memory usage in case of queries
arriving to kresd while being disconnected from internet.
The usage was slowly creeping up, even over 2G.

Interesting past commits: b350d38d and two preceding.

There apparently was no real memory leak.  I assume that reusal of
long-living mempools is risky in terms of memory fragmentation,
though the extent of the issue surprised me very much.
The issue seemed the same with normal glibc and jemalloc.

I generally dislike ad-hoc optimization attempts like these freelists.
Now the allocator can better decide *itself* how to reuse memory.

For long arrays we really want to increase their length by a fraction.
Otherwise it will cost lots of CPU.  Doubling seems customary,
though I could imagine e.g. keeping the +50% growth on longest arrays.

I finally got sufficiently angry with this piece of code when debugging
https://forum.turris.cz/t/how-to-debug-a-custom-hosts-file-for-kresd/17449
though in that case it wasn't the main source of inefficiency.

CI: two of the mysterious/bogus warnings around arrays disappeared.

Fixes #760

Oto Šťáva authored 2 years ago and Vladimír Čunát committed 2 years ago

Fixes #760.

Also removes a warning in policy.REROUTE that is no longer true.

Oto Šťáva authored 2 years ago and Vladimír Čunát committed 2 years ago

Fixes CIDs 355763 and 355764. Also fixes a minor typo.

Other LTS than 22.04 have really old versions in the repo (<= 3.2.1),
so better not advertise those at all.