CVE-2023-22397 in Junos OS Evolved
Summary
by MITRE • 01/13/2023
An Allocation of Resources Without Limits or Throttling weakness in the memory management of the Packet Forwarding Engine (PFE) on Juniper Networks Junos OS Evolved PTX10003 Series devices allows an adjacently located attacker who has established certain preconditions and knowledge of the environment to send certain specific genuine packets to begin a Time-of-check Time-of-use (TOCTOU) Race Condition attack which will cause a memory leak to begin. Once this condition begins, and as long as the attacker is able to sustain the offending traffic, a Distributed Denial of Service (DDoS) event occurs. As a DDoS event, the offending packets sent by the attacker will continue to flow from one device to another as long as they are received and processed by any devices, ultimately causing a cascading outage to any vulnerable devices. Devices not vulnerable to the memory leak will process and forward the offending packet(s) to neighboring devices. Due to internal anti-flood security controls and mechanisms reaching their maximum limit of response in the worst-case scenario, all affected Junos OS Evolved devices will reboot in as little as 1.5 days. Reboots to restore services cannot be avoided once the memory leak begins. The device will self-recover after crashing and rebooting. Operator intervention isn't required to restart the device. This issue affects: Juniper Networks Junos OS Evolved on PTX10003: All versions prior to 20.4R3-S4-EVO; 21.3 versions prior to 21.3R3-S1-EVO; 21.4 versions prior to 21.4R2-S2-EVO, 21.4R3-EVO; 22.1 versions prior to 22.1R1-S2-EVO, 22.1R2-EVO; 22.2 versions prior to 22.2R2-EVO. To check memory, customers may VTY to the PFE first then execute the following show statement: show jexpr jtm ingress-main-memory chip 255 | no-more Alternatively one may execute from the RE CLI: request pfe execute target fpc0 command "show jexpr jtm ingress-main-memory chip 255 | no-more" Iteration 1: Example output: Mem type: NH, alloc type: JTM 136776 bytes used (max 138216 bytes used) 911568 bytes available (909312 bytes from free pages) Iteration 2: Example output: Mem type: NH, alloc type: JTM 137288 bytes used (max 138216 bytes used) 911056 bytes available (909312 bytes from free pages) The same can be seen in the CLI below, assuming the scale does not change: show npu memory info Example output: FPC0:NPU16 mem-util-jnh-nh-size 2097152 FPC0:NPU16 mem-util-jnh-nh-allocated 135272 FPC0:NPU16 mem-util-jnh-nh-utilization 6
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/29/2025
The vulnerability described in CVE-2023-22397 represents a critical resource allocation weakness within the Packet Forwarding Engine (PFE) of Juniper Networks Junos OS Evolved PTX10003 Series devices. This issue manifests as an Allocation of Resources Without Limits or Throttling condition that specifically impacts memory management operations. The vulnerability operates through a sophisticated Time-of-check Time-of-use (TOCTOU) race condition attack pattern where an adjacent attacker can exploit preconditions and environmental knowledge to craft specific genuine packets that trigger the memory leak behavior. The attack leverages the inherent design flaw in how the PFE handles memory allocation for packet processing, creating a cascading effect that ultimately leads to device instability and service disruption.
The technical implementation of this vulnerability involves the PFE's inability to properly throttle or limit memory allocation requests during packet processing operations. When crafted packets are received, they initiate a race condition between the time when resource availability is checked and when the actual resource allocation occurs. This temporal gap allows the attacker to repeatedly submit packets that consume memory without proper limits, gradually depleting available resources. The vulnerability specifically affects devices running Junos OS Evolved versions prior to specific release thresholds including 20.4R3-S4-EVO, 21.3R3-S1-EVO, 21.4R2-S2-EVO, 21.4R3-EVO, 22.1R1-S2-EVO, 22.1R2-EVO, and 22.2R2-EVO. The memory leak occurs at the ingress processing level where network packets are initially received and processed, with the attack specifically targeting the JTM (Juno Traffic Manager) memory allocation mechanisms.
The operational impact of this vulnerability extends far beyond individual device compromise, creating a significant distributed denial of service scenario that can cascade across network infrastructure. Once the memory leak begins, the affected devices will continuously process and forward the malicious packets to neighboring devices, creating a propagation effect that can overwhelm entire network segments. The internal anti-flood security mechanisms reach their maximum response capacity within 1.5 days of attack initiation, resulting in automatic device reboots to restore service functionality. This self-recovery mechanism, while preventing complete network collapse, creates service disruption as devices must restart to recover. The vulnerability affects not only the directly targeted devices but also creates a ripple effect through network topology as packets continue flowing between vulnerable devices, potentially causing widespread service degradation. Network operators must monitor memory utilization through specific CLI commands to detect the attack, with memory consumption patterns showing gradual but consistent increases in allocated memory resources.
Mitigation strategies for CVE-2023-22397 require immediate implementation of firmware updates to supported Junos OS Evolved versions that contain the necessary patches to address the memory allocation throttling deficiency. The vulnerability aligns with CWE-770, Allocation of Resources Without Limits or Throttling, and demonstrates characteristics consistent with ATT&CK technique T1498.001, Direct Network Damage, as the attack results in network service disruption through resource exhaustion. Network administrators should implement traffic filtering rules to limit packet processing from adjacent networks and establish monitoring procedures to track memory utilization patterns using the provided CLI commands. The memory leak progression can be observed through the show jexpr jtm ingress-main-memory chip 255 command output, where increasing memory allocation values indicate active exploitation. Additionally, implementing rate limiting and packet filtering mechanisms at network boundaries can help prevent the attack from reaching vulnerable devices, while regular monitoring of NPU memory utilization through show npu memory info commands can provide early detection of potential exploitation attempts.