Juniper Junos up to 21.1/21.2R2/21.3R2/21.4R1-S1 Kernel Routing Table memory leak

Summaryinfo

A vulnerability classified as problematic has been found in Juniper Junos up to 21.1/21.2R2/21.3R2/21.4R1-S1. This impacts an unknown function of the component Kernel Routing Table. Performing a manipulation results in memory leak. This vulnerability is cataloged as CVE-2022-22209. It is possible to initiate the attack remotely. There is no exploit available. It is recommended to upgrade the affected component.

Detailsinfo

A vulnerability, which was classified as critical, was found in Juniper Junos up to 21.1/21.2R2/21.3R2/21.4R1-S1 (Router Operating System). This affects some unknown processing of the component Kernel Routing Table. The manipulation with an unknown input leads to a memory leak vulnerability. CWE is classifying the issue as CWE-401. The product does not sufficiently track and release allocated memory after it has been used, which slowly consumes remaining memory. This is going to have an impact on availability. The summary by CVE is:

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.

The weakness was shared 07/20/2022 as JSA69713. The advisory is shared at kb.juniper.net. This vulnerability is uniquely identified as CVE-2022-22209 since 12/21/2021. Neither technical details nor an exploit are publicly available. MITRE ATT&CK project uses the attack technique T1499 for this issue.

Upgrading to version 21.2R3, 21.3R2-S1, 21.3R3, 21.4R1-S2 or 21.4R2 eliminates this vulnerability.

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Productinfo

Type

• Router Operating System

Vendor

• Juniper

Name

• Junos

Version

• 21.0
• 21.1
• 21.2R2
• 21.3R2
• 21.4R1-S1

License

• commercial

Website

• Vendor: https://www.juniper.net/

CPE 2.3info

• 🔍
• 🔍
• 🔍

CPE 2.2info

• 🔍
• 🔍
• 🔍

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Discussion