nslookup: out-of-bounds read in TXT record parsing

[ringzeropirate]

Summary
An out-of-bounds read exists in the TXT record handler of parse_reply() in networking/nslookup.c. A DNS server returning a crafted TXT record can cause nslookup to read up to 255 bytes beyond the valid RDATA region, resulting in an information disclosure to stdout.
Affected versions: All versions through 1.38.0 (when CONFIG_FEATURE_NSLOOKUP_BIG=y)
Vulnerable Code
networking/nslookup.c, lines 810-813:
n = *(unsigned char *)ns_rr_rdata(rr); if (n > 0) { memset(dname, 0, sizeof(dname)); memcpy(dname, ns_rr_rdata(rr) + 1, n); // n is not validated against rdlen printf("%s\ttext = \"%s\"\n", ns_rr_name(rr), dname); }
The variable n is read from the first byte of the TXT RDATA (range 0-255) and used directly as the length argument to memcpy(). There is no check that n <= rdlen - 1. When rdlen is smaller than n + 1, the memcpy reads past the end of the valid RDATA, which is located inside the reply[512] stack buffer of send_queries().
The ns_parserr() function correctly validates that rdlength bytes of RDATA fit within the DNS message, but this does not prevent the TXT length byte from claiming more data than rdlength actually provides.
Impact

Type: Out-of-bounds Read (CWE-125)
CVSS 3.1: 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N)
Impact: Information disclosure — data from adjacent stack memory is copied into dname and printed to stdout via printf()
Prerequisite: The user must query a DNS server controlled by the attacker (or the attacker must be in a position to spoof DNS responses)

Note on UI:N scoring: BusyBox is designed for and primarily deployed on embedded/IoT devices where DNS resolution is commonly automated (router diagnostic panels, monitoring scripts, firmware health checks, captive portals). In these environments, nslookup is invoked programmatically without direct user interaction, justifying UI:N. This is consistent with CVE-2019-5747 (BusyBox udhcp OOB read, scored 7.5 with UI:N).
Note: this is a read-only vulnerability. It does not corrupt memory and cannot directly achieve code execution.
Suggested Fix
Add a bounds check before the memcpy:
`n = *(unsigned char *)ns_rr_rdata(rr);

•   	if (n > rdlen - 1) {
  

•   		dbg("TXT string length %d exceeds rdlen %d\n", n, rdlen);
  

•   		return -1;
  

•   	}
    	if (n > 0) {
    		memset(dname, 0, sizeof(dname));
    		memcpy(dname, ns_rr_rdata(rr) + 1, n);`
  

Verification
The issue can be verified by compiling BusyBox with AddressSanitizer (-fsanitize=address) and processing a DNS response where a TXT record has RDLENGTH=1 and RDATA[0]=0xFF. ASAN reports:
ERROR: AddressSanitizer: heap-buffer-overflow
READ of size 255

Related Issue in SOA Handler
The SOA record handler in the same function (lines ~866-878) has a similar issue: after decompressing two domain names with ns_name_uncompress(), it reads five uint32_t values via ns_get32() without verifying that 20 bytes remain within the RDATA boundary. The suggested fix:
`printf("\tmail addr = %s\n", dname);
cp += n;

•   	if (cp + 20 > ns_rr_rdata(rr) + rdlen) {
  

•   		dbg("SOA record too short for fixed fields\n");
  

•   		return -1;
  

•   	}
    	printf("\tserial = %lu\n", ns_get32(cp));`
  

Date | Event |
2026-04-20 | Vulnerability discovered during static analysis of BusyBox 1.37.0
2026-04-23 | Private disclosure sent to vda.linux@googlemail.com and busybox@busybox.net (mailing list rejected the email, suggesting to contact busybox-owner@busybox.net)
2026-05-04 | Follow-up email sent to vda.linux@googlemail.com — no response
2026-05-21 | Follow-up email sent to busybox-owner@busybox.net — no response
2026-06-03 | Confirmed still present in BusyBox 1.38.0 (nslookup.c is unchanged)
2026-06-04 | Public disclosure via this issue (after 41 days and three contact attempts without vendor response)

A complete patch file, standalone PoC, and detailed advisory were provided in the private disclosure on 2026-04-23 and remain available upon request.

"This vulnerability was discovered through static analysis of publicly available source code. No unauthorized access to any system was performed. This disclosure is made in good faith to improve the security of BusyBox and its users."

[robang74]

Please check:

• https://github.com/robang74/busybox/commits/security/

Author: Roberto A. Foglietta <roberto.foglietta@gmail.com>
Date:   Sat Jun 13 13:12:10 2026 +0200

    nslookup: out-of-bounds read in TXT record parsing fix
    
    Vulnerability reported by RZP <ringzeropirate@proton.me>, fix by RAF
    
    - https://github.com/mirror/busybox/issues/122
    
    An out-of-bounds read exists in the TXT record handler of parse_reply()
    in networking/nslookup.c. A DNS server returning a crafted TXT record
    can cause nslookup to read up to 255 bytes beyond the valid RDATA
    region, resulting in an information disclosure to stdout.
    
    Affected versions:
    - All versions through 1.38.0 (when CONFIG_FEATURE_NSLOOKUP_BIG=y)
    
    Vulnerable Code:
    - networking/nslookup.c, lines 810-813
    - networking/nslookup.c, lines 866-878
    
    Type: Out-of-bounds Read (CWE-125)
    CVSS 3.1: 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N)
    Impact: Information disclosure - data from adjacent stack memory
            is copied into dname and printed to stdout via printf()
    Prerequisite: The user must query a DNS server controlled by the
                  attacker (or the attacker must be in a position to
                  spoof DNS responses)
    
    This is consistent with CVE-2019-5747:
    - BusyBox udhcp OOB read, scored 7.5 with UI:N.
    
    Fix rationale:
    - enforcing max lenght reading but not return error as suggested.
    
    Signed-off-by: Roberto A. Foglietta <roberto.foglietta@gmail.com>

[robang74]

update

    v1 --> v2:
    - fix the variable type using ip as pointer instead of i as integer.
    v2 --> v3:
    - binary code size reduction by -56 bytes, +21b total increase.
    v3 --> v4:
    - binary code size reduction by -26 bytes, -26b total difference.
    
     text    data     bss     dec     hex filename
     4807     128       0    4935    1347 networking/nslookup.o
     4884     128       0    5012    1394 networking/nslookup.o v2
                              -56         size reduction
     4788     168       0    4956    135c networking/nslookup.o v3
                              -45         size reduction
     4741     168       0    4909    132d networking/nslookup.o
                              -26         total difference

@ringzeropirate, the patch is ready for testing. Feedback welcomed.