Created attachment 331637 [details] ipdstcache (in blue) VS route -Cn | wc -l (in green) over time
Description of problem: The value of ipdstcache (in /proc/slabinfo) continues to grow constantly, even thought the cached route table remains fairly constant. This leads to the eventual time when ipdstcache reaches the value of /proc/sys/net/ipv4/route/maxsize. When this happens, the kernel complains with 'dst cache overflow' and the server no longer responds to any network activity.
Version-Release number of selected component (if applicable): kernel 2.6.18-92.1.22.el5
How reproducible: live system being currently affected by this issue.
Steps to Reproduce: 1. Configure test machine as a router between two networks 2. send packets from network A to network B with a large number of different source/dest IPs 3. Watch the values of ipdstcache and rtcache Actual results: ipdstcache continues to grow while rtcache grows and shrinks with the traffic
Expected results: ipdstcache and rtcache follow each other closely. Values return to zero after traffic stops and route cache entries expire.
Additional info:
Multiple use-after-free vulnerabilities in libxml2 2.5.10, 2.6.16, 2.6.26, 2.6.27, and 2.6.32, and libxml 1.8.17, allow context-dependent attackers to cause a denial of service (application crash) via crafted (1) Notation or (2) Enumeration attribute types in an XML file, as demonstrated by the Codenomicon XML fuzzing framework.
The VMware vCenter Server contains an out-of-bounds read vulnerability in the implementation of the DCERPC protocol. A malicious actor with network access to vCenter Server may trigger an out-of-bounds read by sending a specially crafted packet leading to denial-of-service of certain services (vmcad, vmdird, and vmafdd).
vCenter Server contains a partial information disclosure vulnerability. A malicious actor with non-administrative privileges to vCenter Server may leverage this issue to access unauthorized data.
VMware vCenter Server 4.0 before Update 4b, 5.0 before Update 2, and 5.1 before 5.1.0b; VMware ESXi 3.5 through 5.1; and VMware ESX 3.5 through 4.1 do not properly implement the Network File Copy (NFC) protocol, which allows man-in-the-middle attackers to execute arbitrary code or cause a denial of service (memory corruption) by modifying the client-server data stream.
Directory traversal vulnerability in vCenter Server in VMware vCenter 4.0 before Update 3 and 4.1 before Update 1, and VMware VirtualCenter 2.5 before Update 6a, allows remote attackers to read arbitrary files via unspecified vectors.
The self-extracting installer in the vSphere Client Installer package in VMware vCenter 4.0 before Update 3 and 4.1 before Update 1, VMware ESXi 4.x before 4.1 Update 1, and VMware ESX 4.x before 4.1 Update 1 does not have a digital signature, which might make it easier for remote attackers to spoof the software distribution via a Trojan horse installer.
Multiple cross-site scripting (XSS) vulnerabilities in WebWorks Help 2.0 through 5.0 in VMware vCenter 4.0 before Update 1 Build 208156; VMware Server 2.0.2; VMware ESX 4.0; VMware Lab Manager 2.x; VMware vCenter Lab Manager 3.x and 4.x before 4.0.1; VMware Stage Manager 1.x before 4.0.1; WebWorks Publisher 6.x through 8.x; WebWorks Publisher 2003; and WebWorks ePublisher 9.0.x through 9.3, 2008.1 through 2008.4, and 2009.x before 2009.3 allow remote attackers to inject arbitrary web script or HTML via (1) wwhelpentry.html, reachable through index.html and wwhsec.htm, (2) wwhelp/wwhimpl/api.htm, (3) wwhelp/wwhimpl/common/html/frameset.htm, (4) wwhelp/wwhimpl/common/scripts/switch.js, or (5) the window.opener component in wwhelp/wwhimpl/common/html/bookmark.htm, related to (a) unspecified parameters and (b) messages used in topic links for the bookmarking functionality.
Tavis Ormandy and Julien Tinnes, Google Security Team reported that Kernels <= 2.6.18.8 are vulnerable to a NULL pointer dereference issue when using MSGMORE on udp sockets.
Fixed upstream already by: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=1e0c14f49d6b393179f423abbac47f85618d3d46
Acknowledgements:
Red Hat would like to thank Tavis Ormandy and Julien Tinnes of the Google Security Team for responsibly reporting this flaw.
vCenter Server in VMware vCenter 4.0 before Update 3 and 4.1 before Update 1 allows local users to discover the SOAP session ID via unspecified vectors.