CVE Database

Unbound before 1.9.4 accesses uninitialized memory, which allows remote attackers to trigger a crash via a crafted NOTIFY query. The source IP address of the query must match an access-control rule.

A vulnerability in the Bidirectional Forwarding Detection (BFD) offload implementation of Cisco Catalyst 4500 Series Switches and Cisco Catalyst 4500-X Series Switches could allow an unauthenticated, remote attacker to cause a crash of the iosd process, causing a denial of service (DoS) condition. The vulnerability is due to insufficient error handling when the BFD header in a BFD packet is incomplete. An attacker could exploit this vulnerability by sending a crafted BFD message to or across an affected switch. A successful exploit could allow the attacker to trigger a reload of the system. This vulnerability affects Catalyst 4500 Supervisor Engine 6-E (K5), Catalyst 4500 Supervisor Engine 6L-E (K10), Catalyst 4500 Supervisor Engine 7-E (K10), Catalyst 4500 Supervisor Engine 7L-E (K10), Catalyst 4500E Supervisor Engine 8-E (K10), Catalyst 4500E Supervisor Engine 8L-E (K10), Catalyst 4500E Supervisor Engine 9-E (K10), Catalyst 4500-X Series Switches (K10), Catalyst 4900M Switch (K5), Catalyst 4948E Ethernet Switch (K5). Cisco Bug IDs: CSCvc40729.

The error page mechanism of the Java Servlet Specification requires that, when an error occurs and an error page is configured for the error that occurred, the original request and response are forwarded to the error page. This means that the request is presented to the error page with the original HTTP method. If the error page is a static file, expected behaviour is to serve content of the file as if processing a GET request, regardless of the actual HTTP method. The Default Servlet in Apache Tomcat 9.0.0.M1 to 9.0.0.M20, 8.5.0 to 8.5.14, 8.0.0.RC1 to 8.0.43 and 7.0.0 to 7.0.77 did not do this. Depending on the original request this could lead to unexpected and undesirable results for static error pages including, if the DefaultServlet is configured to permit writes, the replacement or removal of the custom error page. Notes for other user provided error pages: (1) Unless explicitly coded otherwise, JSPs ignore the HTTP method. JSPs used as error pages must must ensure that they handle any error dispatch as a GET request, regardless of the actual method. (2) By default, the response generated by a Servlet does depend on the HTTP method. Custom Servlets used as error pages must ensure that they handle any error dispatch as a GET request, regardless of the actual method.