Retire mrt_count which is only used to prevent MRT_API_CONFIG once
multicast is already going.
MRT_API_CONFIG must be called right after MRT_INIT and it should only work
then. The moment a VIF or MFC is added MRT_API_CONFIG needs to fail.
Implement this with a mrt_api_locked variable that is toggled in the
setsockopt calls. This way MRT_API_CONFIG can be simplified and the
somewhat problematic mrt_count can be removed.
It seems nothing really uses MRT_API_CONFIG so we can be super strict
here and only allow it on the first call after MRT_INIT and so
mrt_api_locked is toggled even if the setsockopt command failed.
OK bluhm@
Backport security fixes from zlib 1.4
From the 9 security fixes listed in
https://github.com/madler/zlib/releases/tag/v1.4
we already have the fix for CVE-2026-85091 in 8.0.
The remaining 8 of these are cherry-picked here for userland, 6 of which
also affect the kernel. That required a bit of fiddling due to our patches
(#ifdef SMALL, size for ZFREE in the kernel).
There is an oob write of 32k and various other oob accesses, some info
leaks and a cloexec carelessness.
looks good to deraadt
In detail this is:
deflate.c, hunks 1 and 2:
[109 lines not shown]
