New! Vulnerability Priority Rating (VPR)
Tenable calculates a dynamic VPR for every vulnerability. VPR combines vulnerability information with threat intelligence and machine learning algorithms to predict which vulnerabilities are most likely to be exploited in attacks. Read more about what VPR is and how it's different from CVSS.
VPR Score: 3.7
SynopsisThe remote Scientific Linux host is missing one or more security updates.
DescriptionThese new kernel packages contain fixes for the security issues described below :
- a flaw in the connection tracking support for SCTP that allowed a remote user to cause a denial of service by dereferencing a NULL pointer. (CVE-2007-2876, Important)
- a flaw in the mount handling routine for 64-bit systems that allowed a local user to cause denial of service (crash). (CVE-2006-7203, Important)
- a flaw in the IPv4 forwarding base that allowed a local user to cause an out-of-bounds access. (CVE-2007-2172, Important)
- a flaw in the PPP over Ethernet implementation that allowed a local user to cause a denial of service (memory consumption) by creating a socket using connect and then releasing it before the PPPIOCGCHAN ioctl has been called. (CVE-2007-2525, Important)
- a flaw in the fput ioctl handling of 32-bit applications running on 64-bit platforms that allowed a local user to cause a denial of service (panic). (CVE-2007-0773, Important)
- a flaw in the NFS locking daemon that allowed a local user to cause denial of service (deadlock).
- a flaw in the sysfs_readdir function that allowed a local user to cause a denial of service by dereferencing a NULL pointer. (CVE-2007-3104, Moderate)
- a flaw in the core-dump handling that allowed a local user to create core dumps from unreadable binaries via PT_INTERP. (CVE-2007-0958, Low)
- a flaw in the Bluetooth subsystem that allowed a local user to trigger an information leak. (CVE-2007-1353, Low)
In addition, the following bugs were addressed :
- the NFS could recurse on the same spinlock. Also, NFS, under certain conditions, did not completely clean up Posix locks on a file close, leading to mount failures.
- the 32bit compatibility didn't return to userspace correct values for the rt_sigtimedwait system call.
- the count for unused inodes could be incorrect at times, resulting in dirty data not being written to disk in a timely manner.
- the cciss driver had an incorrect disk size calculation (off-by-one error) which prevented disk dumps.
NOTE1: From The Upstream Vendors release notes 'During PCI probing, Red Hat Enterprise Linux 4 Update 5 attempts to use information obtained from MCFG (memory-mapped PCI configuration space). On AMD-systems, this type of access does not work on some buses, as the kernel cannot parse the MCFG table.
To work around this, add the parameter pci=conf1 or pci=nommconf on the kernel boot line in /etc/grub.conf. For example :
title Red Hat Enterprise Linux AS (2.6.9-42.0.2.EL) root (hd0,0) kernel /vmlinuz-2.6.9-42.0.2.EL ro root=/dev/VolGroup00/LogVol00 rhgb quiet pci=conf1 initrd /initrd-2.6.9-42.0.2.EL.img
Doing this instructs the kernel to use PCI Conf1 access instead of MCFG-based access.'
NOTE2: From The Upstream Vendors Knowledge Base 'Why did the ordering of my NIC devices change in Red Hat Enterprise Linux 4.5?
The 2.6.9-55 version of the Red Hat Enterprise Linux 4 kernel (Update 5) reverts to the 2.4 ordering of network interface cards (NICs) on certain systems. Note that if the 'HWADDR=MAC ADDRESS' line is present in the /etc/sysconfig/network-scripts/ifcfg-ethX files, the NIC ordering will not change.
To restore the original 2.6 ordering, which is different from the 2.4 ordering, boot with the option pci=nobfsort '
SolutionUpdate the affected packages.