The remote Scientific Linux host is missing one or more security
These 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,
- 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,
- 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,
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
- 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
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 '
See also :
Update the affected packages.
Risk factor :
Medium / CVSS Base Score : 6.1