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:
VMware Tools in VMware Workstation 6.5.x before 6.5.4 build 246459; VMware Player 2.5.x before 2.5.4 build 246459; VMware ACE 2.5.x before 2.5.4 build 246459; VMware Server 2.x before 2.0.2 build 203138; VMware Fusion 2.x before 2.0.6 build 246742; VMware ESXi 3.5 and 4.0; and VMware ESX 2.5.5, 3.0.3, 3.5, and 4.0 does not properly access libraries, which allows user-assisted remote attackers to execute arbitrary code by tricking a Windows guest OS user into clicking on a file that is stored on a network share.
VMware Tools in VMware Workstation 6.5.x before 6.5.4 build 246459; VMware Player 2.5.x before 2.5.4 build 246459; VMware ACE 2.5.x before 2.5.4 build 246459; VMware Server 2.x before 2.0.2 build 203138; VMware Fusion 2.x before 2.0.6 build 246742; VMware ESXi 3.5 and 4.0; and VMware ESX 2.5.5, 3.0.3, 3.5, and 4.0 does not properly load VMware programs, which might allow Windows guest OS users to gain privileges by placing a Trojan horse program at an unspecified location on the guest OS disk.
Description of problem: Frank Filz reported: the problem is that permission checking is skipped if atomic open is possible, but when exec opens a file, it just opens it OREADONLY which means EXEC permission will not be checked at that time.
This problem is observed by the following sequence (executed as root):
mount -t nfs4 server:/ /mnt4 echo "ls" >/mnt4/foo chmod 744 /mnt4/foo su guest -c "mnt4/foo"
Reference: http://article.gmane.org/gmane.linux.nfs/26592