Scientific Linux Security Update : kernel on SL4.x i386/x86_64
Medium Nessus Plugin ID 60215
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.