Instead of this patch series, why don't we simply upgrade to 2.92rel2 ? https://thekelleys.org.uk/dnsmasq/CHANGELOG?
cheers Ankur On Tue, May 19, 2026 at 5:14 AM Abhishek Bachiphale via lists.openembedded.org <[email protected]> wrote: > > A buffer overflow in dnsmasq’s extract_addresses() function allows > an attacker to trigger a heap out-of-bounds read and crash by > exploiting a malformed DNS response, enabling extract_name() > to advance the pointer past the record’s end. > > Reference: > [ https://nvd.nist.gov/vuln/detail/CVE-2026-5172 ] > > Signed-off-by: Abhishek Bachiphale <[email protected]> > --- > .../recipes-support/dnsmasq/dnsmasq_2.92.bb | 1 + > .../dnsmasq/files/CVE-2026-5172.patch | 34 +++++++++++++++++++ > 2 files changed, 35 insertions(+) > create mode 100644 > meta-networking/recipes-support/dnsmasq/files/CVE-2026-5172.patch > > diff --git a/meta-networking/recipes-support/dnsmasq/dnsmasq_2.92.bb > b/meta-networking/recipes-support/dnsmasq/dnsmasq_2.92.bb > index 4ae650f7e7..c19467aed9 100644 > --- a/meta-networking/recipes-support/dnsmasq/dnsmasq_2.92.bb > +++ b/meta-networking/recipes-support/dnsmasq/dnsmasq_2.92.bb > @@ -20,6 +20,7 @@ SRC_URI = > "http://www.thekelleys.org.uk/dnsmasq/${@['archive/', ''][float(d.getV > file://CVE-2026-4891.patch \ > file://CVE-2026-4892.patch \ > file://CVE-2026-4893.patch \ > + file://CVE-2026-5172.patch \ > " > SRC_URI[sha256sum] = > "fd908e79ff37f73234afcb6d3363f78353e768703d92abd8e3220ade6819b1e1" > > diff --git > a/meta-networking/recipes-support/dnsmasq/files/CVE-2026-5172.patch > b/meta-networking/recipes-support/dnsmasq/files/CVE-2026-5172.patch > new file mode 100644 > index 0000000000..ce6e0f464b > --- /dev/null > +++ b/meta-networking/recipes-support/dnsmasq/files/CVE-2026-5172.patch > @@ -0,0 +1,34 @@ > +commit fa3c8ddef6712b52f562813317e6a997e1210123 > +Author: Simon Kelley <[email protected]> > +Date: Mon Mar 30 16:24:33 2026 +0100 > + > +Fix buffer overflow vulnerability in extract_addresses() CVE-2026-5172 > + > +Thanks to Hugo Martinez Ray for spotting this. > + > +The value of rdlen for an RR can be a lie, allowing the > +call to extract_name() at rfc1025.c:952 to advance the value of p1 > +past the calculated end of the record. The makes the calculation > +of bytes remaining in the RR underflow to a huge number and results > +in a massive heap OOB read and certain crash. > + > +CVE: CVE-2026-5172 > + > +Upstream-Status: Backport [ > https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=073082ddc0aba7b8efa15a688d6183463b65effa > ] > + > +Signed-off-by: Abhishek Bachiphale <[email protected]> > + > +diff --git a/src/rfc1035.c b/src/rfc1035.c > +index f0e1082..7e05fb5 100644 > +--- a/src/rfc1035.c > ++++ b/src/rfc1035.c > +@@ -943,7 +943,8 @@ int extract_addresses(struct dns_header *header, size_t > qlen, char *name, time_t > + /* Name, extract it then re-encode. */ > + int len; > + > +- if (!extract_name(header, qlen, &p1, name, > EXTR_NAME_EXTRACT, 0)) > ++ /* rdlen may lie, and extract_name() advances > p1 past where it says the record ends. */ > ++ if (!extract_name(header, qlen, &p1, name, > EXTR_NAME_EXTRACT, 0) || (p1 > endrr)) > + { > + blockdata_free(addr.rrblock.rrdata); > + return 2; > -- > 2.40.0 > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#127133): https://lists.openembedded.org/g/openembedded-devel/message/127133 Mute This Topic: https://lists.openembedded.org/mt/119376896/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
