A flaw was found in BusyBox's volumeid. In volumeidgetbuffer(), a 64-bit offset+length addition can wrap past 2^64, passing the buffer size check and returning a pointer far outside the buffer, which the NTFS prober dereferences, causing a SIGSEGV crash. A crafted filesystem image on an attached device triggers this when probed by blkid, findfs or mount LABEL=/UUID=, preventing those applets from resolving any device.

A flaw was found in BusyBox's tar. The target of a deferred hardlink is resolved through deferred symlinks in its directory components: a symlink entry pointing outside the extraction directory, followed by a hardlink entry whose target passes through that symlink, makes the created hardlink refer to a file outside the extraction directory. A crafted archive can exploit this to pull an arbitrary outside file into the extraction tree as a hardlink; a second archive extracted into the same directory with an overwriting extractor could then replace the outside file's content.

A flaw was found in BusyBox's cpio. When FEATUREPATHTRAVERSALPROTECTION is enabled, leading '/' and '../' sequences are stripped from the names of entries cpio creates, but hardlinked files are remembered under their archive name and that unsanitized name is passed as the link target. A crafted archive can therefore create a hardlink inside the extraction directory that refers to a file outside it, pulling an arbitrary outside file into the tree; a second archive extracted into the same directory with an overwriting extractor could then replace the outside file's content.

A flaw was found in BusyBox. When processing filesystem metadata, the volume identification component does not properly validate header values in HFS+ filesystems. An attacker able to attach a storage device or supply a specially crafted filesystem image can trigger an application crash, resulting in a Denial of Service (DoS) and preventing device resolution.

A flaw was found in BusyBox's volumeid HFS+ prober. A blocksize value of 0 in the volume header is used as a divisor, causing a divide-by-zero (SIGFPE) crash, and the catalog leafnodesize is never validated, allowing a heap out-of-bounds read. A crafted HFS+ filesystem image on an attached device triggers these issues when probed by blkid, findfs or mount LABEL=/UUID=, causing the probing applet to crash and preventing device resolution.

A flaw was found in BusyBox. The volume identification component fails to properly validate cluster parameters when analyzing specially formatted FAT filesystems. An attacker able to present a crafted storage device or disk image can trigger a divide-by-zero condition when partition scanning utilities inspect the volume. This issue causes the probing utilities to crash unexpectedly, resulting in a Denial of Service (DoS) that can disrupt device discovery and system boot operations.

A flaw was found in BusyBox's volumeid FAT prober. A magic string in the boot sector, such as "FAT16 ", skips the geometry checks, so a sectorspercluster value of 0 can be used as a divisor, causing a divide-by-zero (SIGFPE) crash. A crafted filesystem image on an attached device triggers this when probed by blkid, findfs or mount LABEL=/UUID=, which probe every device in /proc/partitions; the crash prevents those applets from resolving any device and may fail boot or hotplug scripts that rely on them.

A flaw was found in BusyBox. The udhcpc6 DHCPv6 client does not properly validate the size of network options sent by a server before copying them into memory. A malicious DHCPv6 server on the local network can exploit this flaw by sending a crafted reply, triggering a stack-based buffer overflow. This vulnerability could allow an attacker to achieve arbitrary code execution with root privileges or cause a denial of service (DoS) crash.

A flaw was found in BusyBox's udhcpc6. The server's SERVERID, IANA and IAPD options are stored verbatim and later copied into a fixed-size struct d6packet on the stack together with the client's own options, without a size check. A malicious DHCPv6 server on the link can send a Reply whose options cause the next Renew to write 34 bytes past the end of the stack object (Release overflows by 20), with content that is partially controlled by the server. This may cause the udhcpc6 process, which runs as root, to crash and could potentially lead to arbitrary code execution.

A flaw was found in BusyBox's udhcpc6 DHCPv6 client. A malicious server on the local network can trigger a use-after-free condition by responding with a crafted Dynamic Host Configuration Protocol for IPv6 (DHCPv6) reply packet lacking usable address options. This issue causes the client to read stale heap memory, which can result in a Denial of Service (DoS) due to an application crash or disclose previously assigned network address data in subsequent discovery requests.

A flaw was found in BusyBox's udhcpc6. The requestedipv6 pointer references a heap copy of the IANA option that is freed on every Reply before the new one is validated, and again in sendd6discover() just before the pointer is read. A malicious DHCPv6 server on the link can trigger this use-after-free with a Reply lacking a usable IANA or IAPD, causing a 16-byte stale heap read; the stale value, typically the previously assigned address, is then sent in the next Discover. Under hardened allocators this may cause the client to crash.

A flaw was found in BusyBox. When the httpd web server processes subdirectory configuration files, an overly long index page name can trigger a stack-based buffer overflow. An attacker with permissions to write to a subdirectory configuration file could exploit this vulnerability to execute arbitrary code with elevated privileges or cause a denial of service (DoS) by crashing the server process.

A flaw was found in BusyBox's httpd. handleincomingandexit() allocates a stack copy of the request URL sized for the current index page name, then parses the httpd.conf file of each directory on the requested path, and finally copies the index page name into that buffer with strcpy(). Because parseconf() honors an "I:" index-page rule in subdirectory httpd.conf files, an overly long index page name in such a file overflows the stack buffer with attacker-chosen bytes when the directory is requested. A user who can write a subdirectory httpd.conf can use this to crash httpd or potentially execute arbitrary code in the forked child process, which runs as root unless the -u option is used.

A flaw was found in BusyBox. When the HTTP daemon (httpd) has pre-compressed file support enabled, authentication checks are evaluated only against the requested URL path rather than the pre-compressed file being served. A remote attacker can exploit this flaw by requesting an uncompressed file path while specifying gzip encoding, bypassing password rules configured specifically for the compressed file. This vulnerability can lead to unauthorized information disclosure of sensitive files.

A flaw was found in BusyBox's httpd. When FEATUREHTTPDGZIP is enabled and a request for /FILE includes an Accept-Encoding: gzip header, httpd serves the pre-compressed FILE.gz if it exists, but authentication rules are matched against the request path only. As a result, a password rule configured for /secret.txt.gz can be bypassed by requesting /secret.txt with Accept-Encoding: gzip, disclosing the contents of the protected file. Only rules naming a specific .gz file are affected; directory rules cover both names.

A flaw was found in BusyBox. When the TFTP (Trivial File Transfer Protocol) client requests a custom small block size and receives a standard response, it falls back to the default block size without resizing the allocated memory buffer. A malicious TFTP server can exploit this issue by sending standard-sized network packets during a transfer, causing a heap buffer overflow. This flaw allows an attacker to achieve arbitrary code execution or cause a Denial of Service (DoS) by crashing the application.

A flaw was found in BusyBox's tftp client. When the server's first reply to a read or write request is not an OACK packet, the client falls back to the default block size of 512 bytes without reallocating the packet buffers, which were allocated for the smaller block size requested with the -b option. A malicious tftp server can exploit this by sending a 516-byte datagram that is stored into the undersized heap buffer; on upload, 512 bytes of the local file are read into the undersized buffer. Processing a crafted tftp transfer may cause the client to crash or potentially execute arbitrary code.

A flaw was found in BusyBox wget. When resuming an FTP download, prepareftpsession() in networking/wget.c subtracts the resume offset from the file size reported by the server without validating that the offset does not exceed it, allowing the contentlen variable to become negative. In retrievefiledata(), a (int) cast lets a negative contentlen whose low 32 bits are positive pass the length check, and the truncated value is then used as the fread() size into the heap-allocated wget buffer. A malicious FTP server, or an on-path attacker when plain FTP is used, can trigger this when wget resumes a download whose offset is more than 2 GiB larger than the reported file size, overwriting heap memory beyond the buffer with server-controlled data, which may lead to a crash or potentially code execution.

A flaw was found in BusyBox wget. When resuming an FTP download, prepareftpsession() in networking/wget.c subtracts the resume offset from the file size reported by the server without validating that the offset does not exceed it, allowing the contentlen variable to become negative. In retrievefiledata(), a (int) cast lets a negative contentlen whose low 32 bits are positive pass the length check, and the truncated value is then used as the fread() size into the heap-allocated wget buffer. A malicious FTP server, or an on-path attacker when plain FTP is used, can trigger this when wget resumes a download whose offset is more than 2 GiB larger than the reported file size, overwriting heap memory beyond the buffer with server-controlled data, which may lead to a crash or potentially code execution.

Rejected reason: Red Hat Product Security determined this is not a security vulnerability. BusyBox internal TLS is intentionally minimal and documents in FEATUREWGETHTTPS that it does not verify peer identity or provide full TLS security; missing Finished verifydata checking is consistent with that documented design and does not cross a separate security boundary warranting a CVE.

A flaw was found in busybox. The tar applet defers creation of symlink and hardlink entries whose targets look unsafe (absolute paths, hardlinks, or targets containing '..') until after all archive members have been processed, in order to avoid a same-archive time-of-check-to-time-of-use issue. However, when those deferred links are finally created, the code performs the underlying symlink() or link() system call directly, without re-validating that the resolved destination parent remains inside the extraction directory. By chaining an immediately-created symlink with a deferred symlink whose target is exactly '..' (a value not caught by the separate prefix-based sanitizer applied to member names, which only strips leading '../' and embedded '/../' sequences), an attacker can make a path that appears to be inside the extraction directory resolve outside it once the deferred link is created. Combined with a deferred hardlink in the same archive, this creates a new file outside the extraction directory; reusing the same destination directory across two archives allows an existing external file to be deleted and replaced with attacker-controlled content, including attacker-controlled ownership and permissions for privileged extraction, since the second archive's replacement member is an ordinary file entry (not a hardlink) and is subject to busybox tar's normal chown()/chmod() restoration from the archive header. The one-archive hardlink primitive requires the internal source file and the external target to reside on the same filesystem; the two-archive primitive requires the extraction directory to be reused across two extraction invocations.

A flaw was found in busybox. The tar applet defers creation of symlink and hardlink entries whose targets look unsafe (absolute paths, hardlinks, or targets containing '..') until after all archive members have been processed, in order to avoid a same-archive time-of-check-to-time-of-use issue. However, when those deferred links are finally created, the code performs the underlying symlink() or link() system call directly, without re-validating that the resolved destination parent remains inside the extraction directory. By chaining an immediately-created symlink with a deferred symlink whose target is exactly '..' (a value not caught by the separate prefix-based sanitizer applied to member names, which only strips leading '../' and embedded '/../' sequences), an attacker can make a path that appears to be inside the extraction directory resolve outside it once the deferred link is created. Combined with a deferred hardlink in the same archive, this creates a new file outside the extraction directory; reusing the same destination directory across two archives allows an existing external file to be deleted and replaced with attacker-controlled content, including attacker-controlled ownership and permissions for privileged extraction, since the second archive's replacement member is an ordinary file entry (not a hardlink) and is subject to busybox tar's normal chown()/chmod() restoration from the archive header. The one-archive hardlink primitive requires the internal source file and the external target to reside on the same filesystem; the two-archive primitive requires the extraction directory to be reused across two extraction invocations.

This vulnerability allows remote attackers to create arbitrary files on affected installations of BusyBox. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the libarchive component. The issue results from the lack of proper validation of a user-supplied path prior to using it in file operations. An attacker can leverage this vulnerability to create files in the context of the current user.

This vulnerability allows remote attackers to create arbitrary files on affected installations of BusyBox. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the libarchive component. The issue results from the lack of proper validation of a user-supplied path prior to using it in file operations. An attacker can leverage this vulnerability to create files in the context of the current user.

BusyBox libarchive Symlink Directory Traversal Arbitrary File Creation Vulnerability. This vulnerability allows remote attackers to create arbitrary files on affected installations of BusyBox. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file.

The specific flaw exists within the libarchive component. The issue results from the lack of proper validation of a user-supplied path prior to using it in file operations. An attacker can leverage this vulnerability to create files in the context of the current user. Was ZDI-CAN-27556.

A flaw was found in BusyBox's dpkg-deb archive extraction. The ar archive handler flushes deferred symlinks after each archive member, unlike the tar, cpio, and unzip handlers which flush once after the last member. A specially crafted .deb archive with two data.tar members can exploit this ordering: the first member declares a symlink pointing to an absolute path (e.g., '/'), which is deferred as unsafe but flushed after the first member. The second member declares a regular file whose path traverses the now-live symlink, resulting in a file being written outside the intended extraction directory. This could allow an attacker to write arbitrary files to arbitrary locations when a user extracts a crafted .deb package.

BusyBox provides lightweight Unix utilities as a single binary. A path traversal vulnerability exists in the dpkg-deb extraction path in archival/libarchive/getheaderar.c. The ar container handler flushes deferred symlinks (via createlinksfromlist() at line 133) inside the per-member loop, rather than once after all members are processed. The tar, cpio, and unzip front-ends correctly flush deferred symlinks after the main loop (tar.c:1269, cpio.c:578, unzip.c:1059), but the ar path does not follow this pattern.

The deferred-symlink mechanism (unsafesymlinktarget.c:13) exists to prevent directory traversal: symlinks with absolute targets or '..' components are deferred until after all archive members are extracted, so that no subsequent member can traverse them. By flushing per ar member, the ar path breaks this invariant: a symlink deferred from the first data.tar member is placed on disk before the second data.tar member is parsed.

A crafted .deb containing two uncompressed data.tar ar members can exploit this: the first declares a symlink whose target is the filesystem root, and the second declares a regular file whose path is resolved through that live symlink, writing a file outside the extraction root.

Constraints: only uncompressed data.tar members work (compressed members cause setupunziponfd() to replace srcfd with a pipe, making the subsequent lseek fail). filteracceptlistreassign() does not remove matched entries from the accept list, so duplicate member names are accepted. BBSUIDDROP is set for the dpkg-deb applet, preventing setuid escalation.

The reporter states the bug was introduced by commit 8c24af9dc (2018-05-22), affecting versions 1290 through current master. No fixing commit exists. Reproduced on Fedora busybox-1.37.0-7.fc44, Debian 13, and Ubuntu 24.04 LTS.

Reported by Shubham Raj, Causal Security. PSIRT ticket: PSIRTSUPT-23314.

A flaw was found in BusyBox dpkg. The writestatusfile() function does not reset a field cursor between package stanzas. When two packages are removed in a single invocation and the first stanza is larger than the second, the second package stanza can be dropped from the status file, causing limited data corruption.

A vulnerability exists in the BusyBox dpkg applet in archival/dpkg.c. The writestatusfile() function does not reset the fieldstart cursor between package stanzas. When two packages are removed in a single invocation and the first stanza is larger than the second, the stale cursor causes readpackagefield() to read past the second stanza's buffer.

Observable consequences include: silent data corruption (the second package stanza vanishes from the status file), potential heap information leakage, and crashes under ASan.

A vulnerability exists in the BusyBox TLS server implementation in networking/tls.c. The getclienthello() function reads p[0] (the compression-methods length byte) after consuming the cipher suite list without verifying that len > 0. A crafted ClientHello that ends immediately after the cipher suite list triggers a 1-byte out-of-bounds heap read.

This is a pre-authentication vulnerability. The one-byte OOB read can potentially leak a single byte of adjacent heap memory or cause a crash in memory-safety-hardened builds.