Bug reported bt Royce M <royce@xchglabs.com>
Location: helper.c:265-270
DHCPv6 CLIDs can be up to 65535 bytes. When --dhcp-script is configured,
the helper hex-encodes raw CLID bytes via sprintf("%.2x") into daemon->packet (5131 bytes).
A 1000-byte CLID writes ~3000 bytes. The helper process retains root privileges.
Note: log6_packet() correctly caps CLID to 100 bytes for logging, but the helper code path was missed.
Resolves-Vulnerability: CVE-2026-4892
Resolves: RHEL-168313
Handle invalid names correctly and refuse them without writing into too
small buffer. Contains upstream proposed basic fix.
Resolves-Vulnerability: CVE-2026-2291
Resolves: RHEL-181041
Ensure extract_name stops whenever name is longer than 255 bytes. That
is defined by RFC 1035 and MAXDNAME is derived from that length. Dnsmasq
until now relied on upstream servers filtering similar responses to be
filtered out.
Stop immediately if the packet is big enough, but binary name length
exceeds 255 bytes. That is prerequisite for escaped name to become
longer than existing buffer long MAXDNAME. Introduce new MAXWNAME
constant for on-wire length limit. MAXDNAME remains escaped
"presentation" format limit, possibly containing IDN or escaping.
Standard escaping is \ddd, where ddd are decadic value of that byte.
Such escaping is not implemented by dnsmasq. MAXDNAME should be large
enough for any escaped names as long as MAXWNAME cannot exceed defined
length.
Signed-off-by: Petr Menšík <pemensik@redhat.com>
Resolves-Vulnerability: CVE-2026-2291
Resolves: RHEL-181041
Use just specialized local-service option, which would deactivate as
soon as any interface= or listen-address= options are used.
Update default configuration to use it.
Fix bug introduced in 2.88 (commit fe91134b) which can result
in corruption of the DNS cache internal data structures and
logging of "cache internal error". This has only been seen
in one place in the wild, and it took considerable effort
to even generate a test case to reproduce it, but there's
no way to be sure it won't strike, and the effect is to break
the cache badly. Installations with DNSSEC enabled are more
likely to see the problem, but not running DNSSEC does not
guarantee that it won't happen. Thanks to Timo van Roermund
for reporting the bug and for his great efforts in chasing
it down.
Also --no-ident option to disable CHAOS entries.
For now create just single additional languages pack, which provides
translations for some localizations. Because it is quite small, it
should not matter.
Correct loop updates of up pointer. Do not lose server records prior to
first marked server on update.
Modified for 2.86 version.
Resolves: rhbz#2061944
Correct used git repo for NM CI
Use moved upstream to gitlab.
Make fmf a bit nicer.
Remove discover from script only
It breaks running the other plan this way.
Prepare inside the script
