Due to an Improper Initialization vulnerability in Juniper Networks Junos OS on PTX platforms and QFX10K Series with Paradise (PE) chipset-based line cards, ddos-protection configuration changes made from the CLI will not take effect as expected beyond the default DDoS (Distributed Denial of Service) settings in the Packet Forwarding Engine (PFE). This may cause BFD sessions to flap when a high rate of specific packets are received. Flapping of BFD sessions in turn may impact routing protocols and network stability, leading to a Denial of Service (DoS) condition. Continued receipt and processing of this packet will create a sustained Denial of Service (DoS) condition. This issue affects only the following platforms with Paradise (PE) chipset-based line cards: PTX1000, PTX3000 (NextGen), PTX5000, PTX10008, PTX10016 Series and QFX10002 Series. This issue affects: Juniper Networks Junos OS 17.4 versions prior to 17.4R3-S5 on PTX Series, QFX10K Series; 18.2 versions prior to 18.2R3-S8 on PTX Series, QFX10K Series; 18.3 versions prior to 18.3R3-S5 on PTX Series, QFX10K Series; 18.4 versions prior to 18.4R2-S8 on PTX Series, QFX10K Series; 19.1 versions prior to 19.1R3-S5 on PTX Series, QFX10K Series; 19.2 versions prior to 19.2R3-S2 on PTX Series, QFX10K Series; 19.3 versions prior to 19.3R3-S2 on PTX Series, QFX10K Series; 19.4 versions prior to 19.4R3-S2 on PTX Series, QFX10K Series; 20.1 versions prior to 20.1R3 on PTX Series, QFX10K Series; 20.2 versions prior to 20.2R2-S3, 20.2R3 on PTX Series, QFX10K Series; 20.3 versions prior to 20.3R2 on PTX Series, QFX10K Series; 20.4 versions prior to 20.4R2 on PTX Series, QFX10K Series.
On PTX Series and QFX10k Series devices with the "inline-jflow" feature enabled, a use after free weakness in the Packet Forwarding Engine (PFE) microkernel architecture of Juniper Networks Junos OS may allow an attacker to cause a Denial of Service (DoS) condition whereby one or more Flexible PIC Concentrators (FPCs) may restart. As this is a race condition situation this issue become more likely to be hit when network instability occurs, such as but not limited to BGP/IGP reconvergences, and/or further likely to occur when more active "traffic flows" are occurring through the device. When this issue occurs, it will cause one or more FPCs to restart unexpectedly. During FPC restarts core files will be generated. While the core file is generated traffic will be disrupted. Sustained receipt of large traffic flows and reconvergence-like situations may sustain the Denial of Service (DoS) situation. This issue affects: Juniper Networks Junos OS: 18.1 version 18.1R2 and later versions prior to 18.1R3-S10 on PTX Series, QFX10K Series.
A Race Condition (Concurrent Execution using Shared Resource with Improper Synchronization) vulnerability in the firewall process (dfwd) of Juniper Networks Junos OS allows an attacker to bypass the firewall rule sets applied to the input loopback filter on any interfaces of a device. This issue is detectable by reviewing the PFE firewall rules, as well as the firewall counters and seeing if they are incrementing or not. For example: show firewall Filter: __default_bpdu_filter__ Filter: FILTER-INET-01 Counters: Name Bytes Packets output-match-inet 0 0 <<<<<< missing firewall packet count This issue affects: Juniper Networks Junos OS 14.1X53 versions prior to 14.1X53-D53 on QFX Series; 14.1 versions 14.1R1 and later versions prior to 15.1 versions prior to 15.1R7-S6 on QFX Series, PTX Series; 15.1X53 versions prior to 15.1X53-D593 on QFX Series; 16.1 versions prior to 16.1R7-S7 on QFX Series, PTX Series; 16.2 versions prior to 16.2R2-S11, 16.2R3 on QFX Series, PTX Series; 17.1 versions prior to 17.1R2-S11, 17.1R3-S2 on QFX Series, PTX Series; 17.2 versions prior to 17.2R1-S9, 17.2R3-S3 on QFX Series, PTX Series; 17.3 versions prior to 17.3R2-S5, 17.3R3-S7 on QFX Series, PTX Series; 17.4 versions prior to 17.4R2-S9, 17.4R3 on QFX Series, PTX Series; 18.1 versions prior to 18.1R3-S9 on QFX Series, PTX Series; 18.2 versions prior to 18.2R2-S6, 18.2R3-S3 on QFX Series, PTX Series; 18.3 versions prior to 18.3R1-S7, 18.3R2-S3, 18.3R3-S1 on QFX Series, PTX Series; 18.4 versions prior to 18.4R1-S5, 18.4R2-S3, 18.4R2-S7, 18.4R3 on QFX Series, PTX Series; 19.1 versions prior to 19.1R1-S4, 19.1R2-S1, 19.1R3 on QFX Series, PTX Series; 19.2 versions prior to 19.2R1-S3, 19.2R2 on QFX Series, PTX Series.
A Data Processing vulnerability in the Multi-Service process (multi-svcs) on the FPC of Juniper Networks Junos OS on the PTX Series routers may lead to the process becoming unresponsive, ultimately affecting traffic forwarding, allowing an attacker to cause a Denial of Service (DoS) condition . The Multi-Service Process running on the FPC is responsible for handling sampling-related operations when a J-Flow configuration is activated. This can occur during periods of heavy route churn, causing the Multi-Service Process to stop processing updates, without consuming any further updates from kernel. This back pressure towards the kernel affects further dynamic updates from other processes in the system, including RPD, causing a KRT-STUCK condition and traffic forwarding issues. An administrator can monitor the following command to check if there is the KRT queue is stuck: user@device > show krt state ... Number of async queue entries: 65007 <--- this value keep on increasing. The following logs/alarms will be observed when this condition exists: user@junos> show chassis alarms 2 alarms currently active Alarm time Class Description 2020-10-11 04:33:45 PDT Minor Potential slow peers are: MSP(FPC1-PIC0) MSP(FPC3-PIC0) MSP(FPC4-PIC0) Logs: Oct 11 04:33:44.672 2020 test /kernel: rts_peer_cp_recv_timeout : Bit set for msp8 as it is stuck Oct 11 04:35:56.000 2020 test-lab fpc4 user.err gldfpc-multi-svcs.elf: Error in parsing composite nexthop Oct 11 04:35:56.000 2020 test-lab fpc4 user.err gldfpc-multi-svcs.elf: composite nexthop parsing error Oct 11 04:43:05 2020 test /kernel: rt_pfe_veto: Possible slowest client is msp38. States processed - 65865741. States to be processed - 0 Oct 11 04:55:55 2020 test /kernel: rt_pfe_veto: Memory usage of M_RTNEXTHOP type = (0) Max size possible for M_RTNEXTHOP type = (8311787520) Current delayed unref = (60000), Current unique delayed unref = (10896), Max delayed unref on this platform = (40000) Current delayed weight unref = (71426) Max delayed weight unref on this platform= (400000) curproc = rpd Oct 11 04:56:00 2020 test /kernel: rt_pfe_veto: Too many delayed route/nexthop unrefs. Op 2 err 55, rtsm_id 5:-1, msg type 2 This issue only affects PTX Series devices. No other products or platforms are affected by this vulnerability. This issue affects Juniper Networks Junos OS on PTX Series: 18.2 versions prior to 18.2R3-S7; 18.3 versions prior to 18.3R3-S4; 18.4 versions prior to 18.4R2-S8, 18.4R3-S7; 19.1 versions prior to 19.1R3-S4; 19.2 versions prior to 19.2R3-S1; 19.3 versions prior to 19.3R3-S1; 19.4 versions prior to 19.4R2-S4, 19.4R3-S1; 20.1 versions prior to 20.1R2; 20.2 versions prior to 20.2R2; 20.3 versions prior to 20.3R1-S2, 20.3R2. This issue does not affect Juniper Networks Junos OS versions prior to 18.2R1.
On Juniper Networks PTX and QFX Series devices with packet sampling configured using tunnel-observation mpls-over-udp, sampling of a malformed packet can cause the Kernel Routing Table (KRT) queue to become stuck. KRT is the module within the Routing Process Daemon (RPD) that synchronized the routing tables with the forwarding tables in the kernel. This table is then synchronized to the Packet Forwarding Engine (PFE) via the KRT queue. Thus, when KRT queue become stuck, it can lead to unexpected packet forwarding issues. An administrator can monitor the following command to check if there is the KRT queue is stuck: user@device > show krt state ... Number of async queue entries: 65007 <--- this value keep on increasing. When this issue occurs, the following message might appear in the /var/log/messages: DATE DEVICE kernel: %KERN-3: rt_pfe_veto: Too many delayed route/nexthop unrefs. Op 2 err 55, rtsm_id 5:-1, msg type 2 DATE DEVICE kernel: %KERN-3: rt_pfe_veto: Memory usage of M_RTNEXTHOP type = (0) Max size possible for M_RTNEXTHOP type = (7297134592) Current delayed unref = (60000), Current unique delayed unref = (18420), Max delayed unref on this platform = (40000) Current delayed weight unref = (60000) Max delayed weight unref on this platform= (400000) curproc = rpd This issue affects Juniper Networks Junos OS on PTX/QFX Series: 17.2X75 versions prior to 17.2X75-D105; 18.1 versions prior to 18.1R3-S11; 18.2 versions prior to 18.2R3-S5; 18.2X75 versions prior to 18.2X75-D420, 18.2X75-D53, 18.2X75-D65; 18.3 versions prior to 18.3R2-S4, 18.3R3-S3; 18.4 versions prior to 18.4R1-S7, 18.4R2-S5, 18.4R3-S4; 19.1 versions prior to 19.1R2-S2, 19.1R3-S2; 19.2 versions prior to 19.2R1-S5, 19.2R3; 19.3 versions prior to 19.3R2-S3, 19.3R3; 19.4 versions prior to 19.4R1-S2, 19.4R2-S1, 19.4R3; 20.1 versions prior to 20.1R1-S2, 20.1R2. This issue does not affect Juniper Networks Junos OS prior to 18.1R1.
An issue was discovered in Embedthis GoAhead before 4.0.1 and Appweb before 7.0.2. The server mishandles some HTTP request fields associated with time, which results in a NULL pointer dereference, as demonstrated by If-Modified-Since or If-Unmodified-Since with a month greater than 11.
Embedthis Appweb before 4.6.6 and 5.x before 5.2.1 allows remote attackers to cause a denial of service (NULL pointer dereference) via a Range header with an empty value, as demonstrated by "Range: x=,".