Preface: What is D3TN? In 2015, our company was founded under the name “FUSE” to offer dedicated software products for distributed systems. Due to our native interest in networking for challenged environments with an emphasis on space and underwater networks, we started focusing intensively on this field. In July 2018, we renamed the company D3TN, referring to our competences in so-called Delay- and Disruption-tolerant Networking (DTN) technologies. These technologies may be employed to render possible communication in the most challenging environments. We are experts in developing software and hardware solutions for this domain.

Background: The main purpose of NASA’s involvement in Bundle Protocol version 7 (BPv7) is to create a more robust, standard, and interoperable networking protocol for space exploration, enabling the Solar System Internet, lunar networks like LunaNet, and improving data return and communication reliability for all types of space missions. BPv7 builds upon BPv6 by adding essential features for network-layer functionality and standardized interfaces, addressing gaps in the previous standard and paving the way for future, complex space communication architectures.

BPv7 is used in Delay-Tolerant Networking (DTN), as it is the latest version of the Bundle Protocol (BP) and is being implemented in operational systems like the Interplanetary Overlay Network (ION). BPv7 is a more robust and standardized version of the Bundle Protocol (BP) that improves upon its predecessor, BPv6, and enables advanced functionalities like Bundle-in-Bundle Encapsulation (BIBE) to handle both versions concurrently.

Vulnerability details: CVE-2025-61910 state the following: 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 in `bei.c`:764) seems to be passed from `blockLength` which is an unsigned int, to a 32 bit signed integer `blkSize`.

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.

Summary:

The CVE description is outdated in practice but accurate in terms of formal release status.

The fix exists in GitHub, but no patched release version has been tagged or published yet.

Users should manually apply the fix or monitor the repository for an official release.

Official announcement: Please see the link for details –

https://nvd.nist.gov/vuln/detail/CVE-2025-61910

https://www.tenable.com/cve/CVE-2025-61910

Preface: mvfst (Pronounced move fast) is a client and server implementation of IETF QUIC protocol in C++ by Facebook. QUIC is a UDP based reliable, multiplexed transport protocol that will become an internet standard.

Background: QUIC (Quick UDP Internet Connections), was designed with the primary goal of enhancing the speed and reliability of internet connections, particularly for latency-sensitive and bandwidth-intensive applications. It aims to reduce connection setup time, improve data transfer speeds, and enhance security compared to traditional TCP and TLS protocols.

The QUIC protocol is a key component in modern CDN (Content Delivery Network) strategies, particularly with the rise of HTTP/3. QUIC, developed by Google and standardized by the IETF, is a transport layer protocol that offers significant performance and security improvements over traditional TCP, especially in the context of CDNs.

Vulnerability details: A heap-buffer-overflow vulnerability is possible in mvfst via a specially crafted message during a QUIC session. This issue affects mvfst versions prior to v2025.07.07.00.

Does removing maxBatchSize affect performance?

Yes, potentially.

To offset any performance degradation from removing maxBatchSize, CDNs may:

-Optimize packet scheduling and batching elsewhere in the QUIC stack to maintain throughput.

-Use adaptive batching: Dynamically adjust how many packets are processed based on system load and traffic patterns.

-Deploy hardware acceleration: Offload QUIC processing to specialized hardware (e.g., SmartNICs or FPGAs).

-Leverage edge caching: Reduce the need for frequent QUIC connections by serving more content directly from edge nodes.

Official announcement: Please refer to the url  for details – https://nvd.nist.gov/vuln/detail/CVE-2025-30403

Preface: Most of Google’s traffic already goes through QUIC. Several other well-known companies have also begun developing their own implementations, such as Microsoft, Facebook, CloudFlare, Mozilla, Apple, Akamai,…etc

Background: By combining the best of TCP and UDP, along with encryption and better handling of modern network conditions, QUIC is set to become the foundation of faster, more secure, and more reliable internet experiences. ngtcp2 project is an effort to implement RFC9000 QUIC protocol.

Vulnerability details: The ngtcp2 project is an effort to implement IETF QUIC protocol in C. In affected versions acks are not validated before being written to the qlog leading to a buffer overflow.

In `ngtcp2_conn::conn_recv_pkt` for an ACK, there was new logic that got added to skip `conn_recv_ack` if an ack has already been processed in the payload. However, this causes us to also skip `ngtcp2_pkt_validate_ack`. The ack which was skipped still got written to qlog.

The bug occurs in `ngtcp2_qlog::write_ack_frame`. It is now possible to reach this code with an invalid ack, suppose `largest_ack=0` and `first_ack_range=15`. Subtracting `largest_ack – first_ack_range` will lead to an integer underflow which is 20 chars long. However, the ngtcp2 qlog code assumes the number written is a signed integer and only accounts for 19 characters of overhead (see `NGTCP2_QLOG_ACK_FRAME_RANGE_OVERHEAD`).

Therefore, we overwrite the buffer causing a heap overflow. This is high priority and could potentially impact many users if they enable qlog.

Remark: qlog is disabled by default. Due to its overhead, it is most likely used for debugging purpose, but the actual use is unknown.

Remedy: ngtcp2 v1.9.1 fixes the bug and users are advised to upgrade. Users unable to upgrade should not turn on qlog.

Official announcement: Please see the link below for details – https://nvd.nist.gov/vuln/detail/CVE-2024-52811

Preface: The core purpose of a BGP UPDATE is to tell another router some traffic it can (or can no longer) send to it. However, simply knowing directly what can be sent to another router is not very useful without context. Therefore, a BGP packet is divided into two parts: Network Layer Reachability Information (NLRI) data (also known as an IP address range) and attributes that help describe additional context about that reachability data.

Background:

One important flag is called the “transitive bit”:

If a BGP implementation does not understand an attribute and the transitive bit is set, it will copy it to another router. If the router does understand this attribute, it can apply its own policy. But in this way,  it allows possibly unknown information to propagate blindly through systems that do not understand the impact of what they are forwarding. 

Vulnerability details: The BGP daemon in Extreme Networks ExtremeXOS (aka EXOS) 30.7.1.1 allows an attacker (who is not on a directly connected network) to cause a denial of service (BGP session reset) because of BGP attribute error mishandling (for attribute 21 and 25). NOTE: the vendor disputes this because it is “evaluating support for RFC 7606 as a future feature” and believes that “customers that have chosen to not require or implement RFC 7606 have done so willingly and with knowledge of what is needed to defend against these types of attacks.”

Official announcement: Please refer to the official announcement for details – https://nvd.nist.gov/vuln/detail/CVE-2023-40457/change-record?changeRecordedOn=11/10/2024T19:15:13.817-0500

Preface: What is jiffies in the Linux kernel? A jiffy is a kernel unit of time declared in <linux/jiffies[.]h> . To understand jiffies, we need to introduce a new constant, HZ, which is the number of times jiffies is incremented in one second. Each increment is called a tick.

Background: tcp_user_timeout – Controls the number of milliseconds that transmitted data may remain unacknowledged before a connection is forcibly closed. Default is 0 which means it is disabled.

Vulnerability details: Avoid too many retransmit packets. If a TCP socket is using TCP_USER_TIMEOUT, and the other peer retracted its window to zero, tcp_retransmit_timer() can retransmit a packet every two jiffies (2 ms for HZ=1000), for about 4 minutes after TCP_USER_TIMEOUT has ‘expired’.

Solution: The fix is to make sure tcp_rtx_probe0_timed_out() takes icsk->icsk_user_timeout into account. Before blamed commit, the socket would not timeout after icsk->icsk_user_timeout, but would use standard exponential backoff for the retransmits. Also worth noting that before commit e89688e3e978 (“net: tcp: fix unexcepted socket die when snd_wnd is 0”), the issue would last 2 minutes instead of 4.

Speculation: CVE does not describe a Common Weakness Enumeration. But believe that the minimal impact would be a denial of service. But it may more serious!

Official announcement: Please refer to the vendor announcement for details – https://nvd.nist.gov/vuln/detail/CVE-2024-41007