nfsd in the Linux kernel before 2.6.28.9 does not drop the CAPMKNOD capability before handling a user request in a thread, which allows local users to create device nodes, as demonstrated on a filesystem that has been exported with the rootsquash option.
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.
Unspecified vulnerability in the VMware Descheduled Time Accounting driver in VMware Workstation 6.5.1 and earlier, VMware Player 2.5.1 and earlier, VMware ACE 2.5.1 and earlier, VMware Server 1.x before 1.0.9 build 156507 and 2.x before 2.0.1 build 156745, VMware Fusion 2.x before 2.0.2 build 147997, VMware ESXi 3.5, and VMware ESX 3.0.2, 3.0.3, and 3.5, when the Descheduled Time Accounting Service is not running, allows guest OS users on Windows to cause a denial of service via unknown vectors.
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