A Missing Release of Memory after Effective Lifetime vulnerability in the Layer-2 control protocols daemon (l2cpd) of Juniper Networks Junos OS and Junos OS Evolved allows an unauthenticated adjacent attacker to cause a memory leak. Continued exploitation can lead to memory exhaustion and thereby a Denial of Service (DoS). This issue occurs when specific LLDP packets are received. The impact of the l2cpd cores is that if any of the stp protocols (rstp, mstp or vstp) is used then stp re-converges and traffic loss will occur during that time. Also if any services depend on LLDP state (like PoE or VoIP device recognition) then these will also be affected. The memory utilization of the L2CPd process can be monitored with the following command: user@host> show system processes extensive | match l2cpd 1234 root 52 0 521M 43412K RUN 1 4:02 34.47% l2cpd This issue affects: Juniper Networks Junos OS 18.4 version 18.4R2-S4 and later versions prior to 18.4R2-S10. 19.2 versions prior to 19.2R1-S8, 19.2R3-S4; 19.3 versions prior to 19.3R3-S5; 19.4 versions prior to 19.4R3-S7; 20.1 versions prior to 20.1R3-S3; 20.2 versions prior to 20.2R3-S2; 20.3 versions prior to 20.3R3-S1; 20.4 versions prior to 20.4R3; 21.1 versions prior to 21.1R2-S2, 21.1R3; 21.2 versions prior to 21.2R2; Juniper Networks Junos OS Evolved All versions prior to 20.4R3-S2-EVO; 21.1 version 21.1R1-EVO and later versions; 21.2 versions prior to 21.2R2-EVO. This issue does not affect: Juniper Networks Junos OS 19.1 version 19.1R1 and later versions.
CWE-401
CVE-2022-22173
A Missing Release of Memory after Effective Lifetime vulnerability in the Public Key Infrastructure daemon (pkid) of Juniper Networks Junos OS allows an unauthenticated networked attacker to cause Denial of Service (DoS). In a scenario where Public Key Infrastructure (PKI) is used in combination with Certificate Revocation List (CRL), if the CRL fails to download the memory allocated to store the CRL is not released. Repeated occurrences will eventually consume all available memory and lead to an inoperable state of the affected system causing a DoS. This issue affects Juniper Networks Junos OS: All versions prior to 18.3R3-S6; 18.4 versions prior to 18.4R2-S9, 18.4R3-S10; 19.1 versions prior to 19.1R2-S3, 19.1R3-S7; 19.2 versions prior to 19.2R1-S8, 19.2R3-S4; 19.3 versions prior to 19.3R3-S4; 19.4 versions prior to 19.4R2-S5, 19.4R3-S5; 20.1 versions prior to 20.1R3-S1; 20.2 versions prior to 20.2R3-S2; 20.3 versions prior to 20.3R3-S1; 20.4 versions prior to 20.4R3; 21.1 versions prior to 21.1R2, 21.1R3; 21.2 versions prior to 21.2R1-S1, 21.2R2. This issue can be observed by monitoring the memory utilization of the pkid process via: root@jtac-srx1500-r2003> show system processes extensive | match pki 20931 root 20 0 733M 14352K select 0:00 0.00% pkid which increases over time: root@jtac-srx1500-r2003> show system processes extensive | match pki 22587 root 20 0 901M 181M select 0:03 0.00% pkid
CVE-2022-22174
A vulnerability in the processing of inbound IPv6 packets in Juniper Networks Junos OS on QFX5000 Series and EX4600 switches may cause the memory to not be freed, leading to a packet DMA memory leak, and eventual Denial of Service (DoS) condition. Once the condition occurs, further packet processing will be impacted, creating a sustained Denial of Service (DoS) condition. The following error logs may be observed using the “show heap” command and the device may eventually run out of memory if such packets are received continuously. Jan 12 12:00:00 device-name fpc0 (buf alloc) failed allocating packet buffer Jan 12 12:00:01 device-name fpc0 (buf alloc) failed allocating packet buffer user@device-name> request pfe execute target fpc0 timeout 30 command “show heap” ID Base Total(b) Free(b) Used(b) % Name — ———- ———– ———– ———– — ———– 0 246fc1a8 536870488 353653752 183216736 34 Kernel 1 91800000 16777216 12069680 4707536 28 DMA 2 92800000 75497472 69997640 5499832 7 PKT DMA DESC 3 106fc000 335544320 221425960 114118360 34 Bcm_sdk 4 97000000 176160768 200 176160568 99 Packet DMA <<<<<<<<<<<<<< 5 903fffe0 20971504 20971504 0 0 Blob This issue affects Juniper Networks Junos OS on QFX5000 Series, EX4600: 18.3R3 versions prior to 18.3R3-S6; 18.4 versions prior to 18.4R2-S9, 18.4R3-S9; 19.1 versions prior to 19.1R2-S3, 19.1R3-S7; 19.2 versions prior to 19.2R1-S8, 19.2R3-S3; 19.3 versions prior to 19.3R2-S7, 19.3R3-S4; 19.4 versions prior to 19.4R2-S5, 19.4R3-S6; 20.1 versions prior to 20.1R3-S1; 20.2 versions prior to 20.2R3-S2; 20.3 versions prior to 20.3R3-S1; 20.4 versions prior to 20.4R3; 21.1 versions prior to 21.1R2-S1, 21.1R3; 21.2 versions prior to 21.2R1-S1, 21.2R2. This issue does not affect Juniper Networks Junos OS: Any versions prior to 17.4R3; 18.1 versions prior to 18.1R3-S6; 18.2 versions prior to 18.2R3; 18.3 versions prior to 18.3R3; 18.4 versions prior to 18.4R2; 19.1 versions prior to 19.1R2.
CVE-2022-22204
An Improper Release of Memory Before Removing Last Reference vulnerability in the Session Initiation Protocol (SIP) Application Layer Gateway (ALG) of Juniper Networks Junos OS allows unauthenticated network-based attacker to cause a partial Denial of Service (DoS). On all MX and SRX platforms, if the SIP ALG is enabled, receipt of a specific SIP packet will create a stale SIP entry. Sustained receipt of such packets will cause the SIP call table to eventually fill up and cause a DoS for all SIP traffic. The SIP call usage can be monitored by “show security alg sip calls”. To be affected the SIP ALG needs to be enabled, either implicitly / by default or by way of configuration. Please verify on SRX with: user@host> show security alg status | match sip SIP : Enabled Please verify on MX whether the following is configured: [ services … rule (term ) from/match application/application-set ] where either a. name = junos-sip or an application or application-set refers to SIP: b. [ applications application application-protocol sip ] or c. [ applications application-set application junos-sip ] This issue affects Juniper Networks Junos OS on SRX Series and MX Series: 20.4 versions prior to 20.4R3-S2; 21.1 versions prior to 21.1R3-S2; 21.2 versions prior to 21.2R2-S2; 21.2 versions prior to 21.2R3; 21.3 versions prior to 21.3R2; 21.4 versions prior to 21.4R2. This issue does not affect Juniper Networks Junos OS versions prior to 20.4R1. Juniper SIRT is not aware of any malicious exploitation of this vulnerability.
CVE-2022-22205
A Missing Release of Memory after Effective Lifetime vulnerability in the Application Quality of Experience (appqoe) subsystem of the PFE of Juniper Networks Junos OS on SRX Series allows an unauthenticated network based attacker to cause a Denial of Service (DoS). Upon receiving specific traffic a memory leak will occur. Sustained processing of such specific traffic will eventually lead to an out of memory condition that prevents all services from continuing to function, and requires a manual restart to recover. A device is only vulnerable when advance(d) policy based routing (APBR) is configured and AppQoE (sla rule) is not configured for these APBR rules. This issue affects Juniper Networks Junos OS on SRX Series: 20.3 versions prior to 20.3R3-S2; 20.4 versions prior to 20.4R3-S2; 21.1 versions prior to 21.1R3; 21.2 versions prior to 21.2R2-S1, 21.2R3; 21.3 versions prior to 21.3R1-S2, 21.3R2. This issue does not affect Juniper Networks Junos OS versions prior to 20.3R1.
CVE-2022-22209
A Missing Release of Memory after Effective Lifetime vulnerability in the kernel of Juniper Networks Junos OS allows an unauthenticated network based attacker to cause a Denial of Service (DoS). On all Junos platforms, the Kernel Routing Table (KRT) queue can get stuck due to a memory leak triggered by interface flaps or route churn leading to RIB and PFEs getting out of sync. The memory leak causes RTNEXTHOP/route and next-hop memory pressure issue and the KRT queue will eventually get stuck with the error- ‘ENOMEM — Cannot allocate memory’. The out-of-sync state between RIB and FIB can be seen with the “show route” and “show route forwarding-table” command. This issue will lead to failures for adding new routes. The KRT queue status can be checked using the CLI command “show krt queue”: user@host > show krt state High-priority add queue: 1 queued ADD nhtype Router index 0 (31212) error ‘ENOMEM — Cannot allocate memory’ kqp ‘0x8ad5e40’ The following messages will be observed in /var/log/messages, which indicate high memory for routes/nexthops: host rpd[16279]: RPD_RT_HWM_NOTICE: New RIB highwatermark for routes: 266 [2022-03-04 05:06:07] host rpd[16279]: RPD_KRT_Q_RETRIES: nexthop ADD: Cannot allocate memory host rpd[16279]: RPD_KRT_Q_RETRIES: nexthop ADD: Cannot allocate memory host kernel: rts_veto_net_delayed_unref_limit: Route/nexthop memory is severe pressure. User Application to perform recovery actions. O p 8 err 12, rtsm_id 0:-1, msg type 10, veto simulation: 0. host kernel: rts_veto_net_delayed_unref_limit: Memory usage of M_RTNEXTHOP type = (806321208) Max size possible for M_RTNEXTHOP type = (689432176) Current delayed unref = (0), Max delayed unref on this platform = (120000) Current delayed weight unref = (0) Max delayed weight unref on this platform = (400000) curproc = rpd. This issue affects: Juniper Networks Junos OS 21.2 versions prior to 21.2R3; 21.3 versions prior to 21.3R2-S1, 21.3R3; 21.4 versions prior to 21.4R1-S2, 21.4R2; This issue does not affect Juniper Networks Junos OS versions prior to 21.2R1.