Dear Maintainer,

I've been told by several root nameservers that version of unbound
as shipped by Debian has a serious flaw that causes unbound to double
the traffic to the root zone system endangering the whole stability
of the DNS system (the RZ operators could still cope with this, but
doubling the traffic is quite horrible).

There has been large operator that upgraded to Debian Trixie and
enabled serve-stale and this has caused several eyebrows to raise,
and people coming to me (since they know I am DD) asking if I can
help.

NLNetLabs had been notified, but since this is already fixed in
the upstream packages, this needs to be expeditely fixed in Debian
as this can cause instability in the DNS ecosystem.

Please look into this as soon as possible, or ping me if you want
me to NMU unbound via security-team.  I am notifying the security
team as well.

Thanks,
Ondrej

- -- System Information:
Debian Release: 13.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates'), (500, 'stable'), (50, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.12.94+deb13-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages unbound depends on:
ii  adduser                     3.152
ii  init-system-helpers         1.69~deb13u1
ii  libc6                       2.41-12+deb13u3
ii  libevent-2.1-7t64           2.1.12-stable-10+b1
ii  libhiredis1.1.0             1.2.0-6+b3
ii  libnghttp2-14               1.64.0-1.1+deb13u1
ii  libprotobuf-c1              1.5.1-1
ii  libpython3.13               3.13.5-2+deb13u3
pn  libpython3.14               <none>
ii  libssl3t64                  3.5.6-1~deb13u2
ii  libsystemd0                 257.13-1~deb13u1
ii  systemd [systemd-tmpfiles]  257.13-1~deb13u1

Versions of packages unbound recommends:
ii  dns-root-data  2025080400~deb13u1

Versions of packages unbound suggests:
pn  apparmor  <none>
ii  openssl   3.5.6-1~deb13u2
-----BEGIN PGP SIGNATURE-----

iQKTBAEBCgB9FiEEw2Gx4wKVQ+vGJel9g3Kkd++uWcIFAmpfcv9fFIAAAAAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEMz
NjFCMUUzMDI5NTQzRUJDNjI1RTk3RDgzNzJBNDc3RUZBRTU5QzIACgkQg3Kkd++u
WcLegxAAi1YVu97jM6GQvqzoaPSC/r80WBcsGtnOd8Tyd89t8HOImo+nIoPf5Udy
TlN3bu324oh3jm3VYfkte/pWGP55UwHR47Lez4eHA32YXbV2JBZz7Xgc1MBs+WM5
G6smtsaiCpxDLXVCt4QLFmNsQGfPzDz2WNRCo/8FZjXbHtP7EMReDknRXL+JR4Gh
OPcRodwYzuDGRwwWeIPI1le/jtpjYjRk8CEC59nw2WSLgmwLs8yqF6HhPmWQlSp2
PKpLh79BB3AXPl1fnraq6A5GYenm1UKamuEO/AQCaXCm3HGWAJOu6+T+tykXTHsF
K2ApIBax/Ihfi728/evdNVeWH+iiNG5zntIKgDy8IBC5p8TD8KIaSM9PW5pff2Br
Ii1XO3OmOv3QJz10cODqZu2+9fQ5e4fLgzDK14NYGAyoyQBe/gS75wXFLgFRLE9d
UIHSPCaDsLSz+eTpSdX7M9uF6oMUx9pCImUix/OkquvM0VbRuAhoSeTS+nEjtV9A
NQklG1tp48TK+GcrU5P/OP9ijAnAXj3Bp0ZpZqMzehz+9Sov+oCooxIxdh0lnqFJ
kI48f0+D+VgPlmvoX8nO456LxzP1LZPZC4iNQOwI7TLX6M78FcM6bw+RMn4+Hnqi
XB+/bBNk8VmLVt26dF3hCbSjzCH04yhkOHOgeZii+SjC2r73d3Y=
=7rBu
-----END PGP SIGNATURE-----

Hi,
a security issue in unbound), so an update via a stable-update (with a
SUA advisory) seems more appropriate.

See: https://wiki.debian.org/StableUpdates
https://lists.debian.org/debian-stable-announce/

Regards,
Salvatore

So what is the upstream bugfix?

Thanks,

/mjt

That’s probably fine as well, but my reasoning is that such issue is a borderline DDoS on the root zone system.

At least three different root server operators came to me with this.

Ondřej
--
Ondřej Surý (He/Him)

A gentle nudge is always appreciated if I take a little longer to reply.

Hi Michael,

I believe it is this one: https://github.com/NLnetLabs/unbound/issues/1174
and the fix is: https://github.com/NLnetLabs/unbound/commit/fff9f62a1ec008185868a369207b0d56ffb7dcb3
(Just confirmed by Yorgos.)

There will be security release for Unbound tomorrow, so I think bundling
this fix with the security update would make sense and make DNS people
happy.

Ondrej
--
Ondřej Surý (He/Him)
ondrej@sury.org

A gentle nudge is always appreciated if I take a little longer to reply.

Note this commit is based on https://github.com/NLnetLabs/unbound/commit/d5e91d181
(at least contextually - it uses extra parameter is_valrec to iter_dns_store(),
added by d5e91d181.

With so much quite sensitive changes for such a fragile area, I'm not confident
to just cherry-pick these two commits (without the Changelog parts) and hope the
whole thing will work correctly.

Thanks,

/mjt

The debdiff is attached.  But I haven't verified if the result fixes the issue.
At the very least, regular operations of unbond seems to be unaffected by the
two patches, the thing continue to work.

As stated by Salvatore already, this is not a security material for debian,
but if we're to release a real security update, this change can be squashed
into that one.

Thanks,

/mjt

Version: 1.23.0-1

This is fixed in upstream release 1.23.0, so sid & testing is
unaffected by this.

I'm also not in agreement with the bug severity, but that does
not really matter here.

After the subsequent discussion, verifying locally and confirmation
with the upstream, I'm confident enough with the changes I collected
from the upstream commits to fix this issue, it should be ok to
update unbound in trixie now.

However, after the yesterdays upstream release of unbound, 1.25.2,
and after I tried picking up fixes in there for the trixie version,
I can conclude this is not going to work - at least not the way I
did it before.  It looks like this time, we'll have to update
unbound in trixie to the last upstream version (1.25.2), instead
of patching the vulnerabilities in 1.22 version.

An interesting note - some security fixes require previous fixes
which either needs to be back-ported to previous version - and quite
some of them are obvious bug fixes, and some requires even more prior
fixes too! - or the subsequent changes should be edited, including
re-thinking and re-evaluating the logic behind them - to work in older
context.

I did quite some work trying to adopt previous batch of security
fixes in unbound for the trixie version - and each time tried to
decide what to do, - to pick up another prior fix, or to edit the
fix being applied.  I tend to do the former, but only if the chain
of pick-ups isn't large.  Now with the new set, some prior fixes
which I missed previously, should finally be picked up too, and
the already applied changes re-done in context of new pick-ups.

And all this becomes unique to debian, with resulting version being
our own, with no way if the final logic actually works or not - we
risk to have other hidden vulnerabilities and bugs because of
unknown and unique combination of (modified) patches collected.

I'm now at patch 5 out of 24 from the Jul-2026 batch (1.25.2),
and I think I'll give up here.  Either we update unbound to
1.25.2 in trixie, or we declare it's not supported in there,
and recommend to install it from bpo13 (which I'll publish with
pleasure).

Speaking of the API/ABI stability - unlike some other software,
here with unbond it should be entirely okay to update it with
no risk of breaking some reverse dependency.

Thanks,

/mjt