Hi,

The tracker lists these six CVEs (published 2026-10-29) as unfixed in all
suites, and I found no Debian bug for them. I checked each one against the
sources of 2.93-3 (sid, forky), 2.91-1+deb13u2 (trixie) and 2.90-4~deb12u2
(bookworm). In short:

- 93006, 93010 and 93011 do not affect trixie or bookworm.
- 93006 is easy to hit on sid's build, and upstream's commit fixes it.
- Upstream's commit for 93009 does not appear to change behaviour.
- The commits for 93007 and 93008 are partial.

A note on the commit IDs: they come from the From: lines of the patches
OpenWrt
cherry-picked into its dnsmasq 2.93 package, since I could not read
upstream's
gitweb from here. Simon can confirm them, and may well know of later work.


CVE-2026-93006 (TFTP serves the wrong file)
Fix: cdbfb972 "Fix logic error in TFTP caching"
Affected: 2.93-3. Not affected: 2.91 and 2.90, which have no saved_offset
prefetch cache in get_block() (Red Hat: introduced in v2.92 by ee09f06).

Tested over loopback by fetching three different small files in rotation,
with
four rounds per configuration:
- Debian's installed 2.93-3, no TFTP options: 8 of 12 fetches returned the
wrong
file's contents. The result was the same with --port=0 and with DNS enabled
but idle.
- 2.93-3 with the upstream commit: 12 of 12 correct in both configurations.
- 2.91-1+deb13u2 and 2.90-4~deb12u2, rebuilt: 12 of 12 correct.

Two limits on exposure: on 2.93-3, fetches negotiating blksize and tsize
were all
correct (12 of 12), and so were two same-size 1 MiB files without options
(8 of
8). I only saw the wrong contents with files smaller than one block and no
options, though that test was not exhaustive.


CVE-2026-93007 (TCP slot exhaustion)
Partial fix: 11493fe2 "Improve resistance to many simultaneous TCP
connections"
Affected: all suites.

The commit reserves extra slots for DNSSEC validation, but accepted client
sockets still have no receive timeout. With --max-tcp-connections=3 and
three
idle clients held open, a new TCP query went unanswered on both unpatched
2.93-3
and 2.93-3 with the commit, with and without --dnssec. UDP kept working and
TCP
recovered once the clients closed. I did not exercise the reserved-slot path
itself. The commit applies to 2.93-3 but not cleanly to 2.91 or 2.90, where
the
hunk in main() fails.


CVE-2026-93008 (CNAME chase, no bailiwick check)
Partial fix: 7719737f "Fix subdomain-test in find_soa()"
Affected: all suites.

This fixes only the find_soa() label-boundary problem, which Red Hat's bug
lists
as a related issue. The CNAME chase that the CVE describes is unchanged:
Pi-hole
FTL's development copy of dnsmasq, which already has this commit, still has
no
bailiwick check in rfc1035.c. So this commit should not close the CVE on
its own.
It applies to all three versions, with offsets on 2.91 and 2.90.


CVE-2026-93009 (DHCPv6 FQDN one-byte over-read)
Commit: a627a784 "Fix off-by-one bounds check in DHCPv6 FQDN option"
Affected: all suites, and apparently not fixed by this commit.

The commit only changes the outer guard from "len != 0" to "len >= 1". But
len
is opt6_len(opt) - 1 and the option comes from opt6_find(..., 1), so len
cannot
be negative and the two conditions are equivalent. The loop Red Hat
describes is
untouched, and it tests *op before checking that op is inside the option:

while (*op != 0 && ((op + (*op)) - pp) < len)

The FTL copy with the commit applied still has this line. A candidate fix is
attached, changing that line to:

while ((op - pp) < len && *op != 0 && ((op + (*op)) - pp) < len)

I checked this with a logic model of the loop, not with DHCPv6 packets
against
the daemon. Over 97,656 generated payloads, 10,555 read past the option both
before and after a627a784, and none did with the candidate. Output was
identical
wherever the existing code stayed in bounds. The candidate is
compile-tested on
2.93-3 and applies to 2.91 and 2.90 with an offset. Red Hat's bug says the
byte
is only used as a loop-termination condition, so the impact looks low, but
a627a784 should not be recorded as the fix.


CVE-2026-93010 (--leasequery without an address has no source check)
No upstream commit that I could find.
Affected: 2.93-3, where the option is off by default. Not affected: 2.91
and 2.90,
which have no OPT_LEASEQUERY at all.


CVE-2026-93011 (DNSSEC name buffer overflow)
Fix: 145abca7 "Fix DNS name buffer overflow"
Affected: 2.93-3. Not affected: 2.91 and 2.90, whose buffers are still
(2 * MAXDNAME) + 1 with MAXDNAME 1025. This matches Red Hat's statement
that the
CVE-2026-2291 backports do not shrink them. I did not trigger this one.


Suggested tracker changes
- CVE-2026-93006, 93010, 93011: [trixie] and [bookworm] not-affected (code
introduced later).
- CVE-2026-93007, 93008, 93009: keep open even once the commits above ship,
unless upstream says otherwise.


Two related fixes with no CVE in the tracker
I did not reproduce either of these, and found no matching tracker entry.
- f90df6c5 "Fix heap OOB read in zone_status()" (CNVD-C-2026-590208). The
commit
message reports a crash with --dnssec from one crafted upstream reply. The
same
code is in all three versions, and the commit applies to all of them.
- 738c0499 "Fix OOB heap write in blockdata_read()". The commit message
says it
depends on running dnsmasq out of memory. It applies to 2.93-3 with an
offset
but not cleanly to 2.91 or 2.90, and I did not assess those further.


Regression check
2.93-3 with all seven commits builds without warnings with DNSSEC enabled,
using
the upstream Makefile and -Wall rather than dpkg-buildpackage. It answers
UDP and
TCP queries for a local --address name, with and without --dnssec. No DNSSEC
validation took place in that check, and I did not run the autopkgtests.

Regards,
Sumit Verma