A Missing Release of Memory after Effective Lifetime vulnerability in the routing protocol daemon of Juniper Networks Junos OS and Junos OS Evolved allows an unauthenticated, network based attacker to cause a Denial of Service (DoS). In a BGP rib sharding scenario, when an attribute of an active BGP route is updated memory will leak. As rpd memory usage increases over time the rpd process will eventually run out of memory, crash, and restart. The memory utilization can be monitored with the following CLI commands: show task memory show system processes extensive | match rpd This issue affects: Juniper Networks Junos OS 20.3 versions prior to 20.3R3-S2; 20.4 versions prior to 20.4R3-S6; 21.1 versions prior to 21.1R3; 21.2 versions prior to 21.2R3; 21.3 versions prior to 21.3R2. Juniper Networks Junos OS Evolved 20.3-EVO version 20.3R1-EVO and later versions; 20.4-EVO versions prior to 20.4R3-S6-EVO; 21.2-EVO versions prior to 21.2R3-EVO; 21.3-EVO versions prior to 21.3R2-EVO.

A memory leak vulnerability in the of Juniper Networks Junos OS allows an attacker to cause a Denial of Service (DoS) to the device by sending specific commands from a peered BGP host and having those BGP states delivered to the vulnerable device. This issue affects: Juniper Networks Junos OS: 18.1 versions prior to 18.1R2-S4, 18.1R3-S1; 18.1X75 all versions. Versions before 18.1R1 are not affected.

A Missing Release of Memory after Effective Lifetime vulnerability in the Juniper Networks Junos OS on MX Series platforms with MPC10/MPC11 line cards, allows an unauthenticated adjacent attacker to cause a Denial of Service (DoS). Devices are only vulnerable when the Suspicious Control Flow Detection (scfd) feature is enabled. Upon enabling this specific feature, an attacker sending specific traffic is causing memory to be allocated dynamically and it is not freed. Memory is not freed even after deactivating this feature. Sustained processing of such 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. The FPC memory usage can be monitored using the CLI command "show chassis fpc". On running the above command, the memory of AftDdosScfdFlow can be observed to detect the memory leak. This issue affects Juniper Networks Junos OS on MX Series: All versions prior to 20.2R3-S5; 20.3 version 20.3R1 and later versions.

A Missing Release of Memory after Effective Lifetime vulnerability in the Flow Processing Daemon (flowd) of Juniper Networks Junos OS allows a network-based, unauthenticated attacker to cause a Denial of Service (DoS). In an IPsec VPN environment, a memory leak will be seen if a DH or ECDH group is configured. Eventually the flowd process will crash and restart. This issue affects Juniper Networks Junos OS on SRX Series: All versions prior to 19.3R3-S7; 19.4 versions prior to 19.4R2-S8, 19.4R3-S10; 20.2 versions prior to 20.2R3-S6; 20.3 versions prior to 20.3R3-S5; 20.4 versions prior to 20.4R3-S5; 21.1 versions prior to 21.1R3-S4; 21.2 versions prior to 21.2R3; 21.3 versions prior to 21.3R3; 21.4 versions prior to 21.4R2.

A Missing Release of Memory after Effective Lifetime vulnerability in the Packet Forwarding Engine (PFE) of Juniper Networks Junos OS allows an adjacent, unauthenticated attacker to cause a Denial of Service (DoS). PTX3000, PTX5000, QFX10000, PTX1000, PTX10002, and PTX10004, PTX10008 and PTX10016 with LC110x FPCs do not support certain flow-routes. Once a flow-route is received over an established BGP session and an attempt is made to install the resulting filter into the PFE, FPC heap memory is leaked. The FPC heap memory can be monitored using the CLI command "show chassis fpc". The following syslog messages can be observed if the respective filter derived from a flow-route cannot be installed. expr_dfw_sfm_range_add:661 SFM packet-length Unable to get a sfm entry for updating the hw expr_dfw_hw_sfm_add:750 Unable to add the filter secondarymatch to the hardware expr_dfw_base_hw_add:52 Failed to add h/w sfm data. expr_dfw_base_hw_create:114 Failed to add h/w data. expr_dfw_base_pfe_inst_create:241 Failed to create base inst for sfilter 0 on PFE 0 for __flowspec_default_inet__ expr_dfw_flt_inst_change:1368 Failed to create __flowspec_default_inet__ on PFE 0 expr_dfw_hw_pgm_fnum:465 dfw_pfe_inst_old not found for pfe_index 0! expr_dfw_bp_pgm_flt_num:548 Failed to pgm bind-point in hw: generic failure expr_dfw_bp_topo_handler:1102 Failed to program fnum. expr_dfw_entry_process_change:679 Failed to change instance for filter __flowspec_default_inet__. This issue affects Juniper Networks Junos OS: on PTX1000, PTX10002, and PTX10004, PTX10008 and PTX10016 with LC110x FPCs: * All versions prior to 20.4R3-S5; * 21.1 versions prior to 21.1R3-S4; * 21.2 versions prior to 21.2R3-S2; * 21.3 versions prior to 21.3R3; * 21.4 versions prior to 21.4R2-S2, 21.4R3; * 22.1 versions prior to 22.1R1-S2, 22.1R2. on PTX3000, PTX5000, QFX10000: * All versions prior to 20.4R3-S8; * 21.1 version 21.1R1 and later versions; * 21.2 versions prior to 21.2R3-S6; * 21.3 versions prior to 21.3R3-S5; * 21.4 versions prior to 21.4R3-S4; * 22.1 versions prior to 22.1R3-S3 * 22.2 versions prior to 22.2R3-S1 * 22.3 versions prior to 22.3R2-S2, 22.3R3 * 22.4 versions prior to 22.4R2.

A Missing Release of Memory after Effective Lifetime vulnerability in Flexible PIC Concentrator (FPC) of Juniper Networks Junos OS allows an adjacent, unauthenticated attacker from the same shared physical or logical network, to cause a heap memory leak and leading to FPC crash. On all Junos PTX Series and QFX10000 Series, when specific EVPN VXLAN Multicast packets are processed, an FPC heap memory leak is observed. The FPC memory usage can be monitored using the CLI command "show heap extensive". Following is an example output. ID Base Total(b) Free(b) Used(b) % Name Peak used % -- -------- --------- --------- --------- --- ----------- ----------- 0 37dcf000 3221225472 1694526368 1526699104 47 Kernel 47 1 17dcf000 1048576 1048576 0 0 TOE DMA 0 2 17ecf000 1048576 1048576 0 0 DMA 0 3 17fcf000 534773760 280968336 253805424 47 Packet DMA 47 This issue affects: Juniper Networks Junos OS PTX Series and QFX10000 Series 20.2 versions prior to 20.2R3-S6; 20.3 versions prior to 20.3R3-S6; 20.4 versions prior to 20.4R3-S4; 21.1 versions prior to 21.1R3-S3; 21.2 versions prior to 21.2R3-S1; 21.3 versions prior to 21.3R3; 21.4 versions prior to 21.4R3; 22.1 versions prior to 22.1R2; 22.2 versions prior to 22.2R2. This issue does not affect Juniper Networks Junos OS versions prior to 20.1R1 on PTX Series and QFX10000 Series.

A Missing Release of Memory after Effective Lifetime vulnerability in the packet forwarding engine (PFE) of Juniper Networks Junos OS on MX Series allows an unauthenticated adjacent attacker to cause a Denial-of-Service (DoS). In a subscriber management scenario, login/logout activity triggers a memory leak, and the leaked memory gradually increments and eventually results in a crash.                 user@host> show chassis fpc                                        Temp    CPU Utilization (%)   CPU Utilization (%)   Memory     Utilization (%)                       Slot State       (C)     Total   Interrupt     1min   5min  15min    DRAM (MB)  Heap   Buffer                       2 Online         36       10         0          9     8     9        32768      26         0                                                                                                       This issue affects Junos OS on MX Series: * All versions before 21.2R3-S9 * from 21.4 before 21.4R3-S10 * from 22.2 before 22.2R3-S6 * from 22.4 before 22.4R3-S5 * from 23.2 before 23.2R2-S3 * from 23.4 before 23.4R2-S3 * from 24.2 before 24.2R2.

A Missing Release of Memory after Effective Lifetime vulnerability in the Anti-Virus processing of Juniper Networks Junos OS on SRX Series allows an unauthenticated, network-based attacker to cause a Denial-of-Service (DoS). On all SRX platforms with Anti-Virus enabled, if a server sends specific content in the HTTP body of a response to a client request, these packets are queued by Anti-Virus processing in Juniper Buffers (jbufs) which are never released. When these jbufs are exhausted, the device stops forwarding all transit traffic. A jbuf memory leak can be noticed from the following logs: (<node>.)<fpc> Warning: jbuf pool id <#> utilization level (<current level>%) is above <threshold>%! To recover from this issue, the affected device needs to be manually rebooted to free the leaked jbufs. This issue affects Junos OS on SRX Series:  * all versions before 21.2R3-S9, * 21.4 versions before 21.4R3-S10, * 22.2 versions before 22.2R3-S6, * 22.4 versions before 22.4R3-S6, * 23.2 versions before 23.2R2-S3, * 23.4 versions before 23.4R2-S3, * 24.2 versions before 24.2R2.

An Uncontrolled Resource Consumption vulnerability in the handling of IPv6 neighbor state change events in Juniper Networks Junos OS allows an adjacent attacker to cause a memory leak in the Flexible PIC Concentrator (FPC) of an ACX5448 router. The continuous flapping of an IPv6 neighbor with specific timing will cause the FPC to run out of resources, leading to a Denial of Service (DoS) condition. Once the condition occurs, further packet processing will be impacted, creating a sustained Denial of Service (DoS) condition, requiring a manual PFE restart to restore service. The following error messages will be seen after the FPC resources have been exhausted: fpc0 DNX_NH::dnx_nh_tag_ipv4_hw_install(),3135: dnx_nh_tag_ipv4_hw_install: BCM L3 Egress create object failed for NH 602 (-14:No resources for operation), BCM NH Params: unit:0 Port:41, L3_INTF:0 Flags: 0x40 fpc0 DNX_NH::dnx_nh_tag_ipv4_hw_install(),3135: dnx_nh_tag_ipv4_hw_install: BCM L3 Egress create object failed for NH 602 (-14:No resources for operation), BCM NH Params: unit:0 Port:41, L3_INTF:0 Flags: 0x40 fpc0 DNX_NH::dnx_nh_tag_ipv4_hw_install(),3135: dnx_nh_tag_ipv4_hw_install: BCM L3 Egress create object failed for NH 602 (-14:No resources for operation), BCM NH Params: unit:0 Port:41, L3_INTF:0 Flags: 0x40 fpc0 DNX_NH::dnx_nh_tag_ipv4_hw_install(),3135: dnx_nh_tag_ipv4_hw_install: BCM L3 Egress create object failed for NH 602 (-14:No resources for operation), BCM NH Params: unit:0 Port:41, L3_INTF:0 Flags: 0x40 This issue only affects the ACX5448 router. No other products or platforms are affected by this vulnerability. This issue affects Juniper Networks Junos OS on ACX5448: 18.4 versions prior to 18.4R3-S10; 19.1 versions prior to 19.1R3-S5; 19.2 versions prior to 19.2R1-S8, 19.2R3-S2; 19.3 versions prior to 19.3R2-S6, 19.3R3-S2; 19.4 versions prior to 19.4R1-S3, 19.4R2-S2, 19.4R3; 20.1 versions prior to 20.1R2; 20.2 versions prior to 20.2R1-S1, 20.2R2.

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 <rule-name> (term <term-name>) from/match application/application-set <name> ] where either a. name = junos-sip or an application or application-set refers to SIP: b. [ applications application <name> application-protocol sip ] or c. [ applications application-set <name> 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.

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.

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.

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.

An Improper Validation of Specified Type of Input vulnerability in the kernel of Juniper Networks Junos OS allows an unauthenticated adjacent attacker to trigger a Missing Release of Memory after Effective Lifetime vulnerability. Continued exploitation of this vulnerability will eventually lead to an FPC reboot and thereby a Denial of Service (DoS). This issue affects: Juniper Networks Junos OS on vMX and MX150: All versions prior to 19.2R1-S8, 19.2R3-S4; 19.3 versions prior to 19.3R3-S5; 19.4 versions prior to 19.4R2-S5, 19.4R3-S6; 20.1 versions prior to 20.1R3-S2; 20.2 versions prior to 20.2R3-S3; 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; 21.3 versions prior to 21.3R1-S1, 21.3R2.

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.

On Juniper Networks MX series, receipt of a stream of specific Layer 2 frames may cause a memory leak resulting in the packet forwarding engine (PFE) on the line card to crash and restart, causing traffic interruption. By continuously sending this stream of specific layer 2 frame, an attacker connected to the same broadcast domain can repeatedly crash the PFE, causing a prolonged Denial of Service (DoS). This issue affects Juniper Networks Junos OS on MX Series: 17.2 versions prior to 17.2R3-S4; 17.2X75 versions prior to 17.2X75-D105.19; 17.3 versions prior to 17.3R3-S7; 17.4 versions prior to 17.4R1-S3, 17.4R2; 18.1 versions prior to 18.1R2. This issue does not affect Juniper Networks Junos OS releases prior to 17.2R1.

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

On Juniper Networks Junos OS and Junos OS Evolved platforms with EVPN configured, receipt of specific BGP packets causes a slow memory leak. If the memory is exhausted the rpd process might crash. If the issue occurs, the memory leak could be seen by executing the "show task memory detail | match policy | match evpn" command multiple times to check if memory (Alloc Blocks value) is increasing. root@device> show task memory detail | match policy | match evpn ------------------------ Allocator Memory Report ------------------------ Name | Size | Alloc DTXP Size | Alloc Blocks | Alloc Bytes | MaxAlloc Blocks | MaxAlloc Bytes Policy EVPN Params 20 24 3330678 79936272 3330678 79936272 root@device> show task memory detail | match policy | match evpn ------------------------ Allocator Memory Report ------------------------ Name | Size | Alloc DTXP Size | Alloc Blocks | Alloc Bytes | MaxAlloc Blocks | MaxAlloc Bytes Policy EVPN Params 20 24 36620255 878886120 36620255 878886120 This issue affects: Juniper Networks Junos OS 19.4 versions prior to 19.4R2; 20.1 versions prior to 20.1R1-S4, 20.1R2; Juniper Networks Junos OS Evolved: 19.4 versions; 20.1 versions prior to 20.1R1-S4-EVO, 20.1R2-EVO; 20.2 versions prior to 20.2R1-EVO; This issue does not affect: Juniper Networks Junos OS releases prior to 19.4R1. Juniper Networks Junos OS Evolved releases prior to 19.4R1-EVO.

On Juniper Networks Junos OS devices, a specific SNMP OID poll causes a memory leak which over time leads to a kernel crash (vmcore). Prior to the kernel crash other processes might be impacted, such as failure to establish SSH connection to the device. The administrator can monitor the output of the following command to check if there is memory leak caused by this issue: user@device> show system virtual-memory | match "pfe_ipc|kmem" pfe_ipc 147 5K - 164352 16,32,64,8192 <-- increasing vm.kmem_map_free: 127246336 <-- decreasing pfe_ipc 0 0K - 18598 32,8192 vm.kmem_map_free: 134582272 This issue affects Juniper Networks Junos OS: 17.4R3; 18.1 version 18.1R3-S5 and later versions prior to 18.1R3-S10; 18.2 version 18.2R3 and later versions prior to 18.2R3-S3; 18.2X75 version 18.2X75-D420, 18.2X75-D50 and later versions prior to 18.2X75-D430, 18.2X75-D53, 18.2X75-D60; 18.3 version 18.3R3 and later versions prior to 18.3R3-S2; 18.4 version 18.4R1-S4, 18.4R2 and later versions prior to 18.4R2-S5, 18.4R3-S1; 19.1 version 19.1R2 and later versions prior to 19.1R2-S2, 19.1R3; 19.2 version 19.2R1 and later versions prior to 19.2R1-S5, 19.2R2; 19.3 versions prior to 19.3R2-S5, 19.3R3; 19.4 versions prior to 19.4R1-S3, 19.4R2. This issue does not affect Juniper Networks Junos OS prior to 17.4R3.

The kernel memory usage represented as "temp" via 'show system virtual-memory' may constantly increase when Integrated Routing and Bridging (IRB) is configured with multiple underlay physical interfaces, and one interface flaps. This memory leak can affect running daemons (processes), leading to an extended Denial of Service (DoS) condition. Usage of "temp" virtual memory, shown here by a constantly increasing value of outstanding Requests, can be monitored by executing the 'show system virtual-memory' command as shown below: user@junos> show system virtual-memory |match "fpc|type|temp" fpc0: -------------------------------------------------------------------------- Type InUse MemUse HighUse Requests Size(s) temp 2023 431K - 10551 16,32,64,128,256,512,1024,2048,4096,65536,262144,1048576,2097152,4194304,8388608 fpc1: -------------------------------------------------------------------------- Type InUse MemUse HighUse Requests Size(s) temp 2020 431K - 6460 16,32,64,128,256,512,1024,2048,4096,65536,262144,1048576,2097152,4194304,8388608 user@junos> show system virtual-memory |match "fpc|type|temp" fpc0: -------------------------------------------------------------------------- Type InUse MemUse HighUse Requests Size(s) temp 2023 431K - 16101 16,32,64,128,256,512,1024,2048,4096,65536,262144,1048576,2097152,4194304,8388608 fpc1: -------------------------------------------------------------------------- Type InUse MemUse HighUse Requests Size(s) temp 2020 431K - 6665 16,32,64,128,256,512,1024,2048,4096,65536,262144,1048576,2097152,4194304,8388608 user@junos> show system virtual-memory |match "fpc|type|temp" fpc0: -------------------------------------------------------------------------- Type InUse MemUse HighUse Requests Size(s) temp 2023 431K - 21867 16,32,64,128,256,512,1024,2048,4096,65536,262144,1048576,2097152,4194304,8388608 fpc1: -------------------------------------------------------------------------- Type InUse MemUse HighUse Requests Size(s) temp 2020 431K - 6858 16,32,64,128,256,512,1024,2048,4096,65536,262144,1048576,2097152,4194304,8388608 This issue affects Juniper Networks Junos OS: 16.1 versions prior to 16.1R7-S6; 17.1 versions prior to 17.1R2-S11, 17.1R3-S1; 17.2 versions prior to 17.2R2-S8, 17.2R3-S3; 17.2X75 versions prior to 17.2X75-D44; 17.3 versions prior to 17.3R2-S5, 17.3R3-S6; 17.4 versions prior to 17.4R2-S5, 17.4R3; 18.1 versions prior to 18.1R3-S7; 18.2 versions prior to 18.2R2-S5, 18.2R3; 18.2X75 versions prior to 18.2X75-D33, 18.2X75-D411, 18.2X75-D420, 18.2X75-D60; 18.3 versions prior to 18.3R1-S5, 18.3R2-S3, 18.3R3; 18.4 versions prior to 18.4R2-S2, 18.4R3; 19.1 versions prior to 19.1R1-S3, 19.1R2; 19.2 versions prior to 19.2R1-S3, 19.2R2. This issue does not affect Juniper Networks Junos OS 12.3 and 15.1.

Specific IPv6 packets sent by clients processed by the Routing Engine (RE) are improperly handled. These IPv6 packets are designed to be blocked by the RE from egressing the RE. Instead, the RE allows these specific IPv6 packets to egress the RE, at which point a mbuf memory leak occurs within the Juniper Networks Junos OS device. This memory leak eventually leads to a kernel crash (vmcore), or the device hanging and requiring a power cycle to restore service, creating a Denial of Service (DoS) condition. During the time where mbufs are rising, yet not fully filled, some traffic from client devices may begin to be black holed. To be black holed, this traffic must match the condition where this traffic must be processed by the RE. Continued receipt and attempted egress of these specific IPv6 packets from the Routing Engine (RE) will create an extended Denial of Service (DoS) condition. Scenarios which have been observed are: 1. In a single chassis, single RE scenario, the device will hang without vmcore, or a vmcore may occur and then hang. In this scenario the device needs to be power cycled. 2. In a single chassis, dual RE scenario, the device master RE will fail over to the backup RE. In this scenario, the master and the backup REs need to be reset from time to time when they vmcore. There is no need to power cycle the device. 3. In a dual chassis, single RE scenario, the device will hang without vmcore, or a vmcore may occur and then hang. In this scenario, the two chassis' design relies upon some type of network level redundancy - VRRP, GRES, NSR, etc. - 3.a In a commanded switchover, where nonstop active routing (NSR) is enabled no session loss is observed. 4. In a dual chassis, dual chassis scenario, rely upon the RE to RE failover as stated in the second scenario. In the unlikely event that the device does not switch RE to RE gracefully, then the fallback position is to the network level services scenario in the third scenario. This issue affects: Juniper Networks Junos OS 16.1 versions prior to 16.1R7-S6; 16.1 version 16.1X70-D10 and later; 16.2 versions prior to 16.2R2-S11; 17.1 versions prior to 17.1R2-S11, 17.1R3-S1; 17.2 versions prior to 17.2R1-S9, 17.2R2-S8, 17.2R3-S3; 17.3 versions prior to 17.3R3-S6; 17.4 versions prior to 17.4R2-S9, 17.4R3; 18.1 versions prior to 18.1R3-S7; 18.2 versions prior to 18.2R3-S2; 18.2X75 versions prior to 18.2X75-D50, 18.2X75-D410; 18.3 versions prior to 18.3R1-S6, 18.3R2-S2, 18.3R3; 18.4 versions prior to 18.4R1-S6, 18.4R2-S2, 18.4R3; 19.1 versions prior to 19.1R1-S3, 19.1R2; 19.2 versions prior to 19.2R1-S2, 19.2R2. This issue does not affect releases prior to Junos OS 16.1R1.

An Improper Input Validation vulnerability in the VxLAN packet forwarding engine (PFE) of Juniper Networks Junos OS on QFX5000 Series, EX4600 Series devices allows an unauthenticated, adjacent attacker, sending two or more genuine packets in the same VxLAN topology to possibly cause a DMA memory leak to occur under various specific operational conditions. The scenario described here is the worst-case scenario. There are other scenarios that require operator action to occur. An indicator of compromise may be seen when multiple devices indicate that FPC0 has gone missing when issuing a show chassis fpc command for about 10 to 20 minutes, and a number of interfaces have also gone missing. Use the following command to determine if FPC0 has gone missing from the device. show chassis fpc detail This issue affects: Juniper Networks Junos OS on QFX5000 Series, EX4600 Series: * 18.4 version 18.4R2 and later versions prior to 20.4R3-S8; * 21.1 version 21.1R1 and later versions prior to 21.2R3-S6; * 21.3 versions prior to 21.3R3-S5; * 21.4 versions prior to 21.4R3-S4; * 22.1 versions prior to 22.1R3-S3; * 22.2 versions prior to 22.2R3-S1; * 22.3 versions prior to 22.3R2-S2, 22.3R3; * 22.4 versions prior to 22.4R2.

A Missing Release of Memory after Effective Lifetime vulnerability in the Packet Forwarding Engine (PFE) of Juniper Networks Junos OS and Junos OS Evolved allows an adjacent, unauthenticated attacker to cause an FPC to crash, leading to Denial of Service (DoS). On all Junos OS and Junos OS Evolved platforms, in an EVPN-VXLAN scenario, when specific ARP packets are received on an IPv4 network, or specific NDP packets are received on an IPv6 network, kernel heap memory leaks, which eventually leads to an FPC crash and restart. This issue does not affect MX Series platforms. Heap size growth on FPC can be seen using below command. user@host> show chassis fpc                     Temp CPU Utilization (%) CPU Utilization (%) Memory   Utilization (%) Slot State           (C) Total Interrupt     1min   5min   15min   DRAM (MB)   Heap   Buffer   0 Online           45     3         0       2       2      2       32768      19       0 <<<<<<< Heap increase in all fPCs This issue affects Junos OS: * All versions before 21.2R3-S7, * 21.4 versions before 21.4R3-S4, * 22.2 versions before 22.2R3-S1,  * 22.3 versions before 22.3R3-S1,  * 22.4 versions before 22.4R2-S2, 22.4R3. and Junos OS Evolved: * All versions before 21.2R3-S7-EVO, * 21.4-EVO versions before 21.4R3-S4-EVO, * 22.2-EVO versions before 22.2R3-S1-EVO,  * 22.3-EVO versions before 22.3R3-S1-EVO,  * 22.4-EVO versions before 22.4R3-EVO.

A Missing Release of Memory after Effective Lifetime vulnerability in the Juniper Tunnel Driver (jtd) of Juniper Networks Junos OS Evolved allows an unauthenticated network-based attacker to cause Denial of Service.  Receipt of specifically malformed IPv6 packets, destined to the device, causes kernel memory to not be freed, resulting in memory exhaustion leading to a system crash and Denial of Service (DoS). Continuous receipt and processing of these packets will continue to exhaust kernel memory, creating a sustained Denial of Service (DoS) condition. This issue only affects systems configured with IPv6. This issue affects Junos OS Evolved:  * from 22.4-EVO before 22.4R3-S5-EVO,  * from 23.2-EVO before 23.2R2-S2-EVO,  * from 23.4-EVO before 23.4R2-S2-EVO,  * from 24.2-EVO before 24.2R1-S2-EVO, 24.2R2-EVO. This issue does not affect Juniper Networks Junos OS Evolved versions prior to 22.4R1-EVO.

A Missing Release of Memory after Effective Lifetime vulnerability in the kernel of Juniper Networks Junos OS and Junos OS Evolved allows an adjacent, unauthenticated attacker to cause a Denial of Service (DoS). In a segment-routing scenario with OSPF as IGP, when a peer interface continuously flaps, next-hop churn will happen and a continuous increase in Routing Protocol Daemon (rpd) memory consumption will be observed. This will eventually lead to an rpd crash and restart when the memory is full. The memory consumption can be monitored using the CLI command "show task memory detail" as shown in the following example: user@host> show task memory detail | match "RT_NEXTHOPS_TEMPLATE|RT_TEMPLATE_BOOK_KEE" RT_NEXTHOPS_TEMPLATE 1008 1024 T 50 51200 50 51200 RT_NEXTHOPS_TEMPLATE 688 768 T 50 38400 50 38400 RT_NEXTHOPS_TEMPLATE 368 384 T 412330 158334720 412330 158334720 RT_TEMPLATE_BOOK_KEE 2064 2560 T 33315 85286400 33315 85286400 user@host> show task memory detail | match "RT_NEXTHOPS_TEMPLATE|RT_TEMPLATE_BOOK_KEE" RT_NEXTHOPS_TEMPLATE 1008 1024 T 50 51200 50 51200 RT_NEXTHOPS_TEMPLATE 688 768 T 50 38400 50 38400 RT_NEXTHOPS_TEMPLATE 368 384 T 419005 160897920 419005 160897920 <=== RT_TEMPLATE_BOOK_KEE 2064 2560 T 39975 102336000 39975 10233600 <=== This issue affects: Juniper Networks Junos OS All versions prior to 19.3R3-S7; 19.4 versions prior to 19.4R2-S8, 19.4R3-S9; 20.2 versions prior to 20.2R3-S5; 20.3 versions prior to 20.3R3-S5; 20.4 versions prior to 20.4R3-S4; 21.1 versions prior to 21.1R3-S3; 21.2 versions prior to 21.2R3-S2; 21.3 versions prior to 21.3R3-S1; 21.4 versions prior to 21.4R2-S1, 21.4R3; 22.1 versions prior to 22.1R2. Juniper Networks Junos OS Evolved All versions prior to 20.4R3-S4-EVO; 21.4 versions prior to 21.4R2-S1-EVO, 21.4R3-EVO; 22.1 versions prior to 22.1R2-EVO.

A Missing Release of Memory after Effective Lifetime vulnerability in the kernel of Juniper Networks Junos OS allows an unauthenticated, adjacent attacker to cause a Denial of Service (DoS). In an MPLS scenario specific packets destined to an Integrated Routing and Bridging (irb) interface of the device will cause a buffer (mbuf) to leak. Continued receipt of these specific packets will eventually cause a loss of connectivity to and from the device, and requires a reboot to recover. These mbufs can be monitored by using the CLI command 'show system buffers': user@host> show system buffers 783/1497/2280 mbufs in use (current/cache/total) user@host> show system buffers 793/1487/2280 mbufs in use (current/cache/total) <<<<<< mbuf usage increased This issue affects Juniper Networks Junos OS: All versions prior to 19.3R3-S7; 19.4 versions prior to 19.4R3-S9; 20.1 version 20.1R1 and later versions; 20.2 versions prior to 20.2R3-S5; 20.3 versions prior to 20.3R3-S5; 20.4 versions prior to 20.4R3-S4; 21.1 versions prior to 21.1R3-S3; 21.2 versions prior to 21.2R3-S2; 21.3 versions prior to 21.3R3-S1; 21.4 versions prior to 21.4R3; 22.1 versions prior to 22.1R2.

A kernel memory leak in QFX10002-32Q, QFX10002-60C, QFX10002-72Q, QFX10008, QFX10016 devices Flexible PIC Concentrators (FPCs) on Juniper Networks Junos OS allows an attacker to send genuine packets destined to the device to cause a Denial of Service (DoS) to the device. On QFX10002-32Q, QFX10002-60C, QFX10002-72Q devices the device will crash and restart. On QFX10008, QFX10016 devices, depending on the number of FPCs involved in an attack, one more more FPCs may crash and traffic through the device may be degraded in other ways, until the attack traffic stops. A reboot is required to restore service and clear the kernel memory. Continued receipt and processing of these genuine packets will create a sustained Denial of Service (DoS) condition. On QFX10008, QFX10016 devices, an indicator of compromise may be the existence of DCPFE core files. You can also monitor PFE memory utilization for incremental growth: user@qfx-RE:0% cprod -A fpc0 -c "show heap 0" | grep -i ke 0 3788a1b0 3221225048 2417120656 804104392 24 Kernel user@qfx-RE:0% cprod -A fpc0 -c "show heap 0" | grep -i ke 0 3788a1b0 3221225048 2332332200 888892848 27 Kernel This issue affects: Juniper Networks Junos OS on QFX10002-32Q, QFX10002-60C, QFX10002-72Q, QFX10008, QFX10016: 16.1 versions 16.1R1 and above prior to 17.3 versions prior to 17.3R3-S9; 17.4 versions prior to 17.4R3-S2; 18.1 versions prior to 18.1R3-S11; 18.2 versions prior to 18.2R3-S5; 18.3 versions prior to 18.3R3-S3; 18.4 versions prior to 18.4R2-S5, 18.4R3-S4; 19.1 versions prior to 19.1R3-S2; 19.2 versions prior to 19.2R3; 19.3 versions prior to 19.3R3; 19.4 versions prior to 19.4R3; 20.1 versions prior to 20.1R2. This issue does not affect releases prior to Junos OS 16.1R1. This issue does not affect EX Series devices. This issue does not affect Junos OS Evolved.

On Juniper Networks SRX Series devices with link aggregation (lag) configured, executing any operation that fetches Aggregated Ethernet (AE) interface statistics, including but not limited to SNMP GET requests, causes a slow kernel memory leak. If all the available memory is consumed, the traffic will be impacted and a reboot might be required. The following log can be seen if this issue happens. /kernel: rt_pfe_veto: Memory over consumed. Op 1 err 12, rtsm_id 0:-1, msg type 72 /kernel: rt_pfe_veto: free kmem_map memory = (20770816) curproc = kmd An administrator can use the following CLI command to monitor the status of memory consumption (ifstat bucket): user@device > show system virtual-memory no-forwarding | match ifstat Type InUse MemUse HighUse Limit Requests Limit Limit Size(s) ifstat 2588977 162708K - 19633958 <<<< user@device > show system virtual-memory no-forwarding | match ifstat Type InUse MemUse HighUse Limit Requests Limit Limit Size(s) ifstat 3021629 189749K - 22914415 <<<< This issue affects Juniper Networks Junos OS on SRX Series: 17.1 versions 17.1R3 and above prior to 17.3R3-S11; 17.4 versions prior to 17.4R3-S5; 18.2 versions prior to 18.2R3-S7, 18.2R3-S8; 18.3 versions prior to 18.3R3-S4; 18.4 versions prior to 18.4R2-S7, 18.4R3-S6; 19.1 versions prior to 19.1R3-S4; 19.2 versions prior to 19.2R1-S6; 19.3 versions prior to 19.3R3-S1; 19.4 versions prior to 19.4R3-S1; 20.1 versions prior to 20.1R2, 20.1R3; 20.2 versions prior to 20.2R2-S2, 20.2R3; 20.3 versions prior to 20.3R1-S2, 20.3R2. This issue does not affect Juniper Networks Junos OS prior to 17.1R3.

On Juniper Networks MX Series and EX9200 Series platforms with Trio-based MPCs (Modular Port Concentrators) where Integrated Routing and Bridging (IRB) interfaces are configured and mapped to a VPLS instance or a Bridge-Domain, certain Layer 2 network events at Customer Edge (CE) devices may cause memory leaks in the MPC of Provider Edge (PE) devices which can cause an out of memory condition and MPC restart. When this issue occurs, there will be temporary traffic interruption until the MPC is restored. An administrator can use the following CLI command to monitor the status of memory usage level of the MPC: user@device> show system resource-monitor fpc FPC Resource Usage Summary Free Heap Mem Watermark : 20 % Free NH Mem Watermark : 20 % Free Filter Mem Watermark : 20 % * - Watermark reached Slot # % Heap Free RTT Average RTT 1 87 PFE # % ENCAP mem Free % NH mem Free % FW mem Free 0 NA 88 99 1 NA 89 99 When the issue is occurring, the value of “% NH mem Free” will go down until the MPC restarts. This issue affects MX Series and EX9200 Series with Trio-based PFEs (Packet Forwarding Engines), including MX-MPC1-3D, MX-MPC1E-3D, MX-MPC2-3D, MX-MPC2E-3D, MPC-3D-16XGE, and CHAS-MXxx Series MPCs. No other products or platforms are affected by this issue. This issue affects Juniper Networks Junos OS on MX Series, EX9200 Series: 17.3 versions prior to 17.3R3-S10; 17.4 versions prior to 17.4R3-S3; 18.2 versions prior to 18.2R3-S7; 18.3 versions prior to 18.3R3-S4; 18.4 versions prior to 18.4R3-S6; 19.2 versions prior to 19.2R3-S2; 19.3 versions prior to 19.3R3-S1; 19.4 versions prior to 19.4R2-S2, 19.4R3; 20.2 versions prior to 20.2R1-S3, 20.2R2; 20.3 versions prior to 20.3R1-S1,, 20.3R2. This issue does not affect Juniper Networks Junos OS: 17.3 versions prior to 17.3R3-S8; 17.4 versions prior to 17.4R3-S2; 18.1; 18.2 versions prior to 18.2R3-S4; 18.3 versions prior to 18.3R3-S2; 18.4 versions prior to 18.4R3-S1; 19.1; 19.2 versions prior to 19.2R2; 19.3 versions prior to 19.3R3; 19.4 versions prior to 19.4R2.

In the Linux kernel, the following vulnerability has been resolved: dccp: Fix memory leak in dccp_feat_change_recv If dccp_feat_push_confirm() fails after new value for SP feature was accepted without reconciliation ('entry == NULL' branch), memory allocated for that value with dccp_feat_clone_sp_val() is never freed. Here is the kmemleak stack for this: unreferenced object 0xffff88801d4ab488 (size 8): comm "syz-executor310", pid 1127, jiffies 4295085598 (age 41.666s) hex dump (first 8 bytes): 01 b4 4a 1d 80 88 ff ff ..J..... backtrace: [<00000000db7cabfe>] kmemdup+0x23/0x50 mm/util.c:128 [<0000000019b38405>] kmemdup include/linux/string.h:465 [inline] [<0000000019b38405>] dccp_feat_clone_sp_val net/dccp/feat.c:371 [inline] [<0000000019b38405>] dccp_feat_clone_sp_val net/dccp/feat.c:367 [inline] [<0000000019b38405>] dccp_feat_change_recv net/dccp/feat.c:1145 [inline] [<0000000019b38405>] dccp_feat_parse_options+0x1196/0x2180 net/dccp/feat.c:1416 [<00000000b1f6d94a>] dccp_parse_options+0xa2a/0x1260 net/dccp/options.c:125 [<0000000030d7b621>] dccp_rcv_state_process+0x197/0x13d0 net/dccp/input.c:650 [<000000001f74c72e>] dccp_v4_do_rcv+0xf9/0x1a0 net/dccp/ipv4.c:688 [<00000000a6c24128>] sk_backlog_rcv include/net/sock.h:1041 [inline] [<00000000a6c24128>] __release_sock+0x139/0x3b0 net/core/sock.c:2570 [<00000000cf1f3a53>] release_sock+0x54/0x1b0 net/core/sock.c:3111 [<000000008422fa23>] inet_wait_for_connect net/ipv4/af_inet.c:603 [inline] [<000000008422fa23>] __inet_stream_connect+0x5d0/0xf70 net/ipv4/af_inet.c:696 [<0000000015b6f64d>] inet_stream_connect+0x53/0xa0 net/ipv4/af_inet.c:735 [<0000000010122488>] __sys_connect_file+0x15c/0x1a0 net/socket.c:1865 [<00000000b4b70023>] __sys_connect+0x165/0x1a0 net/socket.c:1882 [<00000000f4cb3815>] __do_sys_connect net/socket.c:1892 [inline] [<00000000f4cb3815>] __se_sys_connect net/socket.c:1889 [inline] [<00000000f4cb3815>] __x64_sys_connect+0x6e/0xb0 net/socket.c:1889 [<00000000e7b1e839>] do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 [<0000000055e91434>] entry_SYSCALL_64_after_hwframe+0x67/0xd1 Clean up the allocated memory in case of dccp_feat_push_confirm() failure and bail out with an error reset code. Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

In the Linux kernel, the following vulnerability has been resolved: fbdev: sh7760fb: Fix a possible memory leak in sh7760fb_alloc_mem() When information such as info->screen_base is not ready, calling sh7760fb_free_mem() does not release memory correctly. Call dma_free_coherent() instead.

In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix qi_batch NULL pointer with nested parent domain The qi_batch is allocated when assigning cache tag for a domain. While for nested parent domain, it is missed. Hence, when trying to map pages to the nested parent, NULL dereference occurred. Also, there is potential memleak since there is no lock around domain->qi_batch allocation. To solve it, add a helper for qi_batch allocation, and call it in both the __cache_tag_assign_domain() and __cache_tag_assign_parent_domain(). BUG: kernel NULL pointer dereference, address: 0000000000000200 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 8104795067 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 223 UID: 0 PID: 4357 Comm: qemu-system-x86 Not tainted 6.13.0-rc1-00028-g4b50c3c3b998-dirty #2632 Call Trace: ? __die+0x24/0x70 ? page_fault_oops+0x80/0x150 ? do_user_addr_fault+0x63/0x7b0 ? exc_page_fault+0x7c/0x220 ? asm_exc_page_fault+0x26/0x30 ? cache_tag_flush_range_np+0x13c/0x260 intel_iommu_iotlb_sync_map+0x1a/0x30 iommu_map+0x61/0xf0 batch_to_domain+0x188/0x250 iopt_area_fill_domains+0x125/0x320 ? rcu_is_watching+0x11/0x50 iopt_map_pages+0x63/0x100 iopt_map_common.isra.0+0xa7/0x190 iopt_map_user_pages+0x6a/0x80 iommufd_ioas_map+0xcd/0x1d0 iommufd_fops_ioctl+0x118/0x1c0 __x64_sys_ioctl+0x93/0xc0 do_syscall_64+0x71/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e

In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Several fixes to bpf_msg_pop_data Several fixes to bpf_msg_pop_data, 1. In sk_msg_shift_left, we should put_page 2. if (len == 0), return early is better 3. pop the entire sk_msg (last == msg->sg.size) should be supported 4. Fix for the value of variable "a" 5. In sk_msg_shift_left, after shifting, i has already pointed to the next element. Addtional sk_msg_iter_var_next may result in BUG.

In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: pltfrm: Dellocate HBA during ufshcd_pltfrm_remove() This will ensure that the scsi host is cleaned up properly using scsi_host_dev_release(). Otherwise, it may lead to memory leaks.

In the Linux kernel, the following vulnerability has been resolved: PCI: Fix reset_method_store() memory leak In reset_method_store(), a string is allocated via kstrndup() and assigned to the local "options". options is then used in with strsep() to find spaces: while ((name = strsep(&options, " ")) != NULL) { If there are no remaining spaces, then options is set to NULL by strsep(), so the subsequent kfree(options) doesn't free the memory allocated via kstrndup(). Fix by using a separate tmp_options to iterate with strsep() so options is preserved.

In the Linux kernel, the following vulnerability has been resolved: wifi: rtlwifi: fix memory leaks and invalid access at probe error path Deinitialize at reverse order when probe fails. When init_sw_vars fails, rtl_deinit_core should not be called, specially now that it destroys the rtl_wq workqueue. And call rtl_pci_deinit and deinit_sw_vars, otherwise, memory will be leaked. Remove pci_set_drvdata call as it will already be cleaned up by the core driver code and could lead to memory leaks too. cf. commit 8d450935ae7f ("wireless: rtlwifi: remove unnecessary pci_set_drvdata()") and commit 3d86b93064c7 ("rtlwifi: Fix PCI probe error path orphaned memory").

In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/gfx9: Add Cleaner Shader Deinitialization in gfx_v9_0 Module This commit addresses an omission in the previous patch related to the cleaner shader support for GFX9 hardware. Specifically, it adds the necessary deinitialization code for the cleaner shader in the gfx_v9_0_sw_fini function. The added line amdgpu_gfx_cleaner_shader_sw_fini(adev); ensures that any allocated resources for the cleaner shader are freed correctly, avoiding potential memory leaks and ensuring that the GPU state is clean for the next initialization sequence.

In the Linux kernel, the following vulnerability has been resolved: net: fix memory leak in tcp_conn_request() If inet_csk_reqsk_queue_hash_add() return false, tcp_conn_request() will return without free the dst memory, which allocated in af_ops->route_req. Here is the kmemleak stack: unreferenced object 0xffff8881198631c0 (size 240): comm "softirq", pid 0, jiffies 4299266571 (age 1802.392s) hex dump (first 32 bytes): 00 10 9b 03 81 88 ff ff 80 98 da bc ff ff ff ff ................ 81 55 18 bb ff ff ff ff 00 00 00 00 00 00 00 00 .U.............. backtrace: [<ffffffffb93e8d4c>] kmem_cache_alloc+0x60c/0xa80 [<ffffffffba11b4c5>] dst_alloc+0x55/0x250 [<ffffffffba227bf6>] rt_dst_alloc+0x46/0x1d0 [<ffffffffba23050a>] __mkroute_output+0x29a/0xa50 [<ffffffffba23456b>] ip_route_output_key_hash+0x10b/0x240 [<ffffffffba2346bd>] ip_route_output_flow+0x1d/0x90 [<ffffffffba254855>] inet_csk_route_req+0x2c5/0x500 [<ffffffffba26b331>] tcp_conn_request+0x691/0x12c0 [<ffffffffba27bd08>] tcp_rcv_state_process+0x3c8/0x11b0 [<ffffffffba2965c6>] tcp_v4_do_rcv+0x156/0x3b0 [<ffffffffba299c98>] tcp_v4_rcv+0x1cf8/0x1d80 [<ffffffffba239656>] ip_protocol_deliver_rcu+0xf6/0x360 [<ffffffffba2399a6>] ip_local_deliver_finish+0xe6/0x1e0 [<ffffffffba239b8e>] ip_local_deliver+0xee/0x360 [<ffffffffba239ead>] ip_rcv+0xad/0x2f0 [<ffffffffba110943>] __netif_receive_skb_one_core+0x123/0x140 Call dst_release() to free the dst memory when inet_csk_reqsk_queue_hash_add() return false in tcp_conn_request().

In the Linux kernel, the following vulnerability has been resolved: vfio/mlx5: Fix an unwind issue in mlx5vf_add_migration_pages() Fix an unwind issue in mlx5vf_add_migration_pages(). If a set of pages is allocated but fails to be added to the SG table, they need to be freed to prevent a memory leak. Any pages successfully added to the SG table will be freed as part of mlx5vf_free_data_buffer().

In the Linux kernel, the following vulnerability has been resolved: sched/numa: fix memory leak due to the overwritten vma->numab_state [Problem Description] When running the hackbench program of LTP, the following memory leak is reported by kmemleak. # /opt/ltp/testcases/bin/hackbench 20 thread 1000 Running with 20*40 (== 800) tasks. # dmesg | grep kmemleak ... kmemleak: 480 new suspected memory leaks (see /sys/kernel/debug/kmemleak) kmemleak: 665 new suspected memory leaks (see /sys/kernel/debug/kmemleak) # cat /sys/kernel/debug/kmemleak unreferenced object 0xffff888cd8ca2c40 (size 64): comm "hackbench", pid 17142, jiffies 4299780315 hex dump (first 32 bytes): ac 74 49 00 01 00 00 00 4c 84 49 00 01 00 00 00 .tI.....L.I..... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc bff18fd4): [<ffffffff81419a89>] __kmalloc_cache_noprof+0x2f9/0x3f0 [<ffffffff8113f715>] task_numa_work+0x725/0xa00 [<ffffffff8110f878>] task_work_run+0x58/0x90 [<ffffffff81ddd9f8>] syscall_exit_to_user_mode+0x1c8/0x1e0 [<ffffffff81dd78d5>] do_syscall_64+0x85/0x150 [<ffffffff81e0012b>] entry_SYSCALL_64_after_hwframe+0x76/0x7e ... This issue can be consistently reproduced on three different servers: * a 448-core server * a 256-core server * a 192-core server [Root Cause] Since multiple threads are created by the hackbench program (along with the command argument 'thread'), a shared vma might be accessed by two or more cores simultaneously. When two or more cores observe that vma->numab_state is NULL at the same time, vma->numab_state will be overwritten. Although current code ensures that only one thread scans the VMAs in a single 'numa_scan_period', there might be a chance for another thread to enter in the next 'numa_scan_period' while we have not gotten till numab_state allocation [1]. Note that the command `/opt/ltp/testcases/bin/hackbench 50 process 1000` cannot the reproduce the issue. It is verified with 200+ test runs. [Solution] Use the cmpxchg atomic operation to ensure that only one thread executes the vma->numab_state assignment. [1] https://lore.kernel.org/lkml/1794be3c-358c-4cdc-a43d-a1f841d91ef7@amd.com/

Memory leak in QEMU (aka Quick Emulator), when built with USB EHCI Emulation support, allows local guest OS privileged users to cause a denial of service (memory consumption) by repeatedly hot-unplugging the device.

In the Linux kernel, the following vulnerability has been resolved: ipv6: fix memory leak in fib6_rule_suppress The kernel leaks memory when a `fib` rule is present in IPv6 nftables firewall rules and a suppress_prefix rule is present in the IPv6 routing rules (used by certain tools such as wg-quick). In such scenarios, every incoming packet will leak an allocation in `ip6_dst_cache` slab cache. After some hours of `bpftrace`-ing and source code reading, I tracked down the issue to ca7a03c41753 ("ipv6: do not free rt if FIB_LOOKUP_NOREF is set on suppress rule"). The problem with that change is that the generic `args->flags` always have `FIB_LOOKUP_NOREF` set[1][2] but the IPv6-specific flag `RT6_LOOKUP_F_DST_NOREF` might not be, leading to `fib6_rule_suppress` not decreasing the refcount when needed. How to reproduce: - Add the following nftables rule to a prerouting chain: meta nfproto ipv6 fib saddr . mark . iif oif missing drop This can be done with: sudo nft create table inet test sudo nft create chain inet test test_chain '{ type filter hook prerouting priority filter + 10; policy accept; }' sudo nft add rule inet test test_chain meta nfproto ipv6 fib saddr . mark . iif oif missing drop - Run: sudo ip -6 rule add table main suppress_prefixlength 0 - Watch `sudo slabtop -o | grep ip6_dst_cache` to see memory usage increase with every incoming ipv6 packet. This patch exposes the protocol-specific flags to the protocol specific `suppress` function, and check the protocol-specific `flags` argument for RT6_LOOKUP_F_DST_NOREF instead of the generic FIB_LOOKUP_NOREF when decreasing the refcount, like this. [1]: https://github.com/torvalds/linux/blob/ca7a03c4175366a92cee0ccc4fec0038c3266e26/net/ipv6/fib6_rules.c#L71 [2]: https://github.com/torvalds/linux/blob/ca7a03c4175366a92cee0ccc4fec0038c3266e26/net/ipv6/fib6_rules.c#L99

In the Linux kernel, the following vulnerability has been resolved: net: rds: fix memory leak in rds_recvmsg Syzbot reported memory leak in rds. The problem was in unputted refcount in case of error. int rds_recvmsg(struct socket *sock, struct msghdr *msg, size_t size, int msg_flags) { ... if (!rds_next_incoming(rs, &inc)) { ... } After this "if" inc refcount incremented and if (rds_cmsg_recv(inc, msg, rs)) { ret = -EFAULT; goto out; } ... out: return ret; } in case of rds_cmsg_recv() fail the refcount won't be decremented. And it's easy to see from ftrace log, that rds_inc_addref() don't have rds_inc_put() pair in rds_recvmsg() after rds_cmsg_recv() 1) | rds_recvmsg() { 1) 3.721 us | rds_inc_addref(); 1) 3.853 us | rds_message_inc_copy_to_user(); 1) + 10.395 us | rds_cmsg_recv(); 1) + 34.260 us | }

In the Linux kernel, the following vulnerability has been resolved: net: hamradio: fix memory leak in mkiss_close My local syzbot instance hit memory leak in mkiss_open()[1]. The problem was in missing free_netdev() in mkiss_close(). In mkiss_open() netdevice is allocated and then registered, but in mkiss_close() netdevice was only unregistered, but not freed. Fail log: BUG: memory leak unreferenced object 0xffff8880281ba000 (size 4096): comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s) hex dump (first 32 bytes): 61 78 30 00 00 00 00 00 00 00 00 00 00 00 00 00 ax0............. 00 27 fa 2a 80 88 ff ff 00 00 00 00 00 00 00 00 .'.*............ backtrace: [<ffffffff81a27201>] kvmalloc_node+0x61/0xf0 [<ffffffff8706e7e8>] alloc_netdev_mqs+0x98/0xe80 [<ffffffff84e64192>] mkiss_open+0xb2/0x6f0 [1] [<ffffffff842355db>] tty_ldisc_open+0x9b/0x110 [<ffffffff84236488>] tty_set_ldisc+0x2e8/0x670 [<ffffffff8421f7f3>] tty_ioctl+0xda3/0x1440 [<ffffffff81c9f273>] __x64_sys_ioctl+0x193/0x200 [<ffffffff8911263a>] do_syscall_64+0x3a/0xb0 [<ffffffff89200068>] entry_SYSCALL_64_after_hwframe+0x44/0xae BUG: memory leak unreferenced object 0xffff8880141a9a00 (size 96): comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s) hex dump (first 32 bytes): e8 a2 1b 28 80 88 ff ff e8 a2 1b 28 80 88 ff ff ...(.......(.... 98 92 9c aa b0 40 02 00 00 00 00 00 00 00 00 00 .....@.......... backtrace: [<ffffffff8709f68b>] __hw_addr_create_ex+0x5b/0x310 [<ffffffff8709fb38>] __hw_addr_add_ex+0x1f8/0x2b0 [<ffffffff870a0c7b>] dev_addr_init+0x10b/0x1f0 [<ffffffff8706e88b>] alloc_netdev_mqs+0x13b/0xe80 [<ffffffff84e64192>] mkiss_open+0xb2/0x6f0 [1] [<ffffffff842355db>] tty_ldisc_open+0x9b/0x110 [<ffffffff84236488>] tty_set_ldisc+0x2e8/0x670 [<ffffffff8421f7f3>] tty_ioctl+0xda3/0x1440 [<ffffffff81c9f273>] __x64_sys_ioctl+0x193/0x200 [<ffffffff8911263a>] do_syscall_64+0x3a/0xb0 [<ffffffff89200068>] entry_SYSCALL_64_after_hwframe+0x44/0xae BUG: memory leak unreferenced object 0xffff8880219bfc00 (size 512): comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s) hex dump (first 32 bytes): 00 a0 1b 28 80 88 ff ff 80 8f b1 8d ff ff ff ff ...(............ 80 8f b1 8d ff ff ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff81a27201>] kvmalloc_node+0x61/0xf0 [<ffffffff8706eec7>] alloc_netdev_mqs+0x777/0xe80 [<ffffffff84e64192>] mkiss_open+0xb2/0x6f0 [1] [<ffffffff842355db>] tty_ldisc_open+0x9b/0x110 [<ffffffff84236488>] tty_set_ldisc+0x2e8/0x670 [<ffffffff8421f7f3>] tty_ioctl+0xda3/0x1440 [<ffffffff81c9f273>] __x64_sys_ioctl+0x193/0x200 [<ffffffff8911263a>] do_syscall_64+0x3a/0xb0 [<ffffffff89200068>] entry_SYSCALL_64_after_hwframe+0x44/0xae BUG: memory leak unreferenced object 0xffff888029b2b200 (size 256): comm "syz-executor.1", pid 11443, jiffies 4295046091 (age 17.660s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff81a27201>] kvmalloc_node+0x61/0xf0 [<ffffffff8706f062>] alloc_netdev_mqs+0x912/0xe80 [<ffffffff84e64192>] mkiss_open+0xb2/0x6f0 [1] [<ffffffff842355db>] tty_ldisc_open+0x9b/0x110 [<ffffffff84236488>] tty_set_ldisc+0x2e8/0x670 [<ffffffff8421f7f3>] tty_ioctl+0xda3/0x1440 [<ffffffff81c9f273>] __x64_sys_ioctl+0x193/0x200 [<ffffffff8911263a>] do_syscall_64+0x3a/0xb0 [<ffffffff89200068>] entry_SYSCALL_64_after_hwframe+0x44/0xae

In the Linux kernel, the following vulnerability has been resolved: rpcrdma: Always release the rpcrdma_device's xa_array Dai pointed out that the xa_init_flags() in rpcrdma_add_one() needs to have a matching xa_destroy() in rpcrdma_remove_one() to release underlying memory that the xarray might have accrued during operation.

In the Linux kernel, the following vulnerability has been resolved: scsi: pm80xx: Fix memory leak during rmmod Driver failed to release all memory allocated. This would lead to memory leak during driver removal. Properly free memory when the module is removed.