public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: Matthias Fischer <matthias.fischer@ipfire.org>
To: development@lists.ipfire.org
Cc: Matthias Fischer <matthias.fischer@ipfire.org>
Subject: [PATCH] bind: Update to 9.20.21
Date: Thu, 26 Mar 2026 22:58:13 +0100	[thread overview]
Message-ID: <20260326215815.18055-1-matthias.fischer@ipfire.org> (raw)

For details see:

https://downloads.isc.org/isc/bind9/9.20.21/doc/arm/html/notes.html#notes-for-bind-9-20-21

"Notes for BIND 9.20.21
Security Fixes

    Fix unbounded NSEC3 iterations when validating referrals to unsigned
    delegations. (CVE-2026-1519)

    DNSSEC-signed zones may contain high iteration-count NSEC3 records,
    which prove that certain delegations are insecure. Previously, a
    validating resolver encountering such a delegation processed these
    iterations up to the number given, which could be a maximum of 65,535.
    This has been addressed by introducing a processing limit, set at 50.
    Now, if such an NSEC3 record is encountered, the delegation will be
    treated as insecure.

    ISC would like to thank Samy Medjahed/Ap4sh for bringing this
    vulnerability to our attention. [GL #5708]

    Fix memory leaks in code preparing DNSSEC proofs of non-existence.
    (CVE-2026-3104)

    An attacker controlling a DNSSEC-signed zone could trigger a memory
    leak in the logic preparing DNSSEC proofs of non-existence, by creating
    more than max-records-per-type RRSIGs for NSEC records. These memory
    leaks have been fixed.

    ISC would like to thank Vitaly Simonovich for bringing this
    vulnerability to our attention. [GL #5742]

    Prevent a crash in code processing queries containing a TKEY record.
    (CVE-2026-3119)

    The named process could terminate unexpectedly when processing a
    correctly signed query containing a TKEY record. This has been fixed.

    ISC would like to thank Vitaly Simonovich for bringing this
    vulnerability to our attention. [GL #5748]

    Fix a stack use-after-return flaw in SIG(0) handling code.
    (CVE-2026-3591)

    A stack use-after-return flaw in SIG(0) handling code could enable ACL
    bypass and/or assertion failures in certain circumstances. This flaw
    has been fixed.

    ISC would like to thank Mcsky23 for bringing this vulnerability to our
    attention. [GL #5754]

Bug Fixes

    Fix the handling of key statements defined inside views.

    A recent change introduced in BIND 9.20.17 hardened the key name check
    when used in primaries, to immediately reject the configuration if the
    key was not defined (rather than only checking whether the key name was
    correctly formed). However, that change introduced a regression that
    prevented the use of a key defined in a view. This has now been fixed.
    [GL #5761]"

Signed-off-by: Matthias Fischer <matthias.fischer@ipfire.org>
---
 config/rootfiles/common/bind | 10 +++++-----
 lfs/bind                     |  4 ++--
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/config/rootfiles/common/bind b/config/rootfiles/common/bind
index 42690fd5f..ad7f23645 100644
--- a/config/rootfiles/common/bind
+++ b/config/rootfiles/common/bind
@@ -241,18 +241,18 @@ usr/bin/nsupdate
 #usr/include/ns/types.h
 #usr/include/ns/update.h
 #usr/include/ns/xfrout.h
-usr/lib/libdns-9.20.20.so
+usr/lib/libdns-9.20.21.so
 #usr/lib/libdns.la
 #usr/lib/libdns.so
-usr/lib/libisc-9.20.20.so
+usr/lib/libisc-9.20.21.so
 #usr/lib/libisc.la
 #usr/lib/libisc.so
-usr/lib/libisccc-9.20.20.so
+usr/lib/libisccc-9.20.21.so
 #usr/lib/libisccc.la
 #usr/lib/libisccc.so
-usr/lib/libisccfg-9.20.20.so
+usr/lib/libisccfg-9.20.21.so
 #usr/lib/libisccfg.la
 #usr/lib/libisccfg.so
-usr/lib/libns-9.20.20.so
+usr/lib/libns-9.20.21.so
 #usr/lib/libns.la
 #usr/lib/libns.so
diff --git a/lfs/bind b/lfs/bind
index 179d4875d..9a52fcdde 100644
--- a/lfs/bind
+++ b/lfs/bind
@@ -25,7 +25,7 @@
 
 include Config
 
-VER        = 9.20.20
+VER        = 9.20.21
 
 THISAPP    = bind-$(VER)
 DL_FILE    = $(THISAPP).tar.xz
@@ -43,7 +43,7 @@ objects = $(DL_FILE)
 
 $(DL_FILE) = $(DL_FROM)/$(DL_FILE)
 
-$(DL_FILE)_BLAKE2 = 416593b641ec7de486f474bb4edbe843a2abd18d9a5c12dcd74fd55c4f1d2d89bdacfa32458dd6ecc09e7e601692f9c134459f5c183dabc3f98fa7b5506736e0
+$(DL_FILE)_BLAKE2 = 20c2acac40242516da10cc8e45074de3d5d8906e4c4e216f6d69cba0585816aba4ec77adda8142294623eef5b045ec64cc8a18c721ece6af939741903558454b
 
 install : $(TARGET)
 
-- 
2.53.0



                 reply	other threads:[~2026-03-26 21:58 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260326215815.18055-1-matthias.fischer@ipfire.org \
    --to=matthias.fischer@ipfire.org \
    --cc=development@lists.ipfire.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox