This update fixes various security as well as non-security problems
discovered since the last round of kernel updates.

Not all kernels are affected by all the problems, each of the problems
has an affected note attached to it.

The CAN-YYYY-NNNN IDs are Mitre CVE Candidate IDs, please see
http://www.mitre.org for more information.

The following security problems have been fixed:

- local users could crash the system by causing stack fault
exceptions (CAN-2005-1767)

SUSE Linux 9.0 and SLES8 are affected.

- local users could use ptrace to crash the kernel
(CAN-2005-1761).

SLES8 on the ia64 architecture is affected.

- by causing an overflow in the 32bit execve function users could
crash the kernel or even execute code (CAN-2005-1768).

SLES 9 on the x86-64 and ia64 architectures and SUSE Linux 9.1
on the x86-64 architecture are affected.

- an overflow when validating XDR data for the nfsacl protocol
could crash the kernel.

SUSE Linux 9.2 and 9.3 are affected.

- local users could crash the kernel by reading from large
offsets in sysfs files

SUSE Linux 9.2 is affected.

On SUSE Linux 9.1 this update contains the kernel used by the
SUSE Linux Enterprise Server 9, Service Pack 2. This kernel adds
among many bugfixes and driver updates support for non-executable
pages (NX) on x86 CPUs and improves dual core CPU support.

2) Solution or Work-Around

There is no known workaround, please install the update packages.

3) Special Instructions and Notes

SPECIAL INSTALLATION INSTRUCTIONS
=================================
The following paragraphs guide you through the installation
process in a step-by-step fashion. The character sequence "****"
marks the beginning of a new paragraph. In some cases, the steps
outlined in a particular paragraph may or may not be applicable
to your situation. Therefore, make sure that you read through
all of the steps below before attempting any of these
procedures. All of the commands that need to be executed must be
run as the superuser 'root'. Each step relies on the steps
before it to complete successfully.

**** Step 1: Determine the needed kernel type.

Use the following command to determine which kind of kernel is
installed on your system:

rpm -qf --qf '%{name}\n' /boot/vmlinuz

**** Step 2: Download the packages for your system.

Download the kernel RPM package for your distribution with the
name indicated by Step 1. Starting from SUSE LINUX 9.2, kernel
modules that are not free were moved to a separate package with
the suffix '-nongpl' in its name. Download that package as well
if you rely on hardware that requires non-free drivers, such as
some ISDN adapters. The list of all kernel RPM packages is
appended below.

The kernel-source package does not contain a binary kernel in
bootable form. Instead, it contains the sources that correspond
with the binary kernel RPM packages. This package is required to
build third party add-on modules.

**** Step 3: Verify authenticity of the packages.

Verify the authenticity of the kernel RPM package using the
methods as listed in Section 6 of this SUSE Security
Announcement.

**** Step 4: Installing your kernel rpm package.

Install the rpm package that you have downloaded in Step 2 with
the command

rpm -Uhv <FILE>

replacing <FILE> with the filename of the RPM package
downloaded.

Warning: After performing this step, your system may not boot
unless the following steps have been followed
completely.

**** Step 5: Configuring and creating the initrd.

The initrd is a RAM disk that is loaded into the memory of your
system together with the kernel boot image by the boot loader.
The kernel uses the content of this RAM disk to execute commands
that must be run before the kernel can mount its root file
system. The initrd is typically used to load hard disk
controller drivers and file system modules. The variable
INITRD_MODULES in /etc/sysconfig/kernel determines which kernel
modules are loaded in the initrd.

After a new kernel rpm has been installed, the initrd must be
recreated to include the updated kernel modules. Usually this
happens automatically when installing the kernel rpm. If
creating the initrd fails for some reason, manually run the
command

/sbin/mkinitrd

**** Step 6: Update the boot loader, if necessary.

Depending on your software configuration, you either have the
LILO or GRUB boot loader installed and initialized on your
system. Use the command

grep LOADER_TYPE /etc/sysconfig/bootloader

to find out which boot loader is configured.

The GRUB boot loader does not require any further action after a
new kernel has been installed. You may proceed to the next step
if you are using GRUB.

If you use the LILO boot loader, lilo must be run to
reinitialize the boot sector of the hard disk. Usually this
happens automatically when installing the kernel RPM. In case
this step fails, run the command

If all of the steps above have been successfully completed on
your system, the new kernel including the kernel modules and the
initrd are ready to boot. The system needs to be rebooted for
the changes to be active. Make sure that all steps have been
completed then reboot using the command

/sbin/shutdown -r now

Your system will now shut down and restart with the new kernel.

4) Package Location and Checksums

The preferred method for installing security updates is to use the YaST
Online Update (YOU) tool. YOU detects which updates are required and
automatically performs the necessary steps to verify and install them.
Alternatively, download the update packages for your distribution manually
and verify their integrity by the methods listed in Section 6 of this
announcement. Then install the packages using the command

rpm -Fhv <file.rpm>

to apply the update, replacing <file.rpm> with the filename of the
downloaded RPM package.

Our maintenance customers are notified individually. The packages are
offered for installation from the maintenance web.

SUSE security announcements are published via mailing lists and on Web
sites. The authenticity and integrity of a SUSE security announcement is
guaranteed by a cryptographic signature in each announcement. All SUSE
security announcements are published with a valid signature.

To verify the signature of the announcement, save it as text into a file
and run the command

gpg --verify <file>

replacing <file> with the name of the file where you saved the
announcement. The output for a valid signature looks like:

If the security team's key is not contained in your key ring, you can
import it from the first installation CD. To import the key, use the
command

gpg --import gpg-pubkey-3d25d3d9-36e12d04.asc

- Package authenticity verification:

SUSE update packages are available on many mirror FTP servers all over the
world. While this service is considered valuable and important to the free
and open source software community, the authenticity and the integrity of
a package needs to be verified to ensure that it has not been tampered
with.

There are two verification methods that can be used independently from
each other to prove the authenticity of a downloaded file or RPM package:

1) Using the internal gpg signatures of the rpm package
2) MD5 checksums as provided in this announcement

1) The internal rpm package signatures provide an easy way to verify the
authenticity of an RPM package. Use the command

rpm -v --checksig <file.rpm>

to verify the signature of the package, replacing <file.rpm> with the
filename of the RPM package downloaded. The package is unmodified if it
contains a valid signature from build@suse.de with the key ID 9C800ACA.

This key is automatically imported into the RPM database (on
RPMv4-based distributions) and the gpg key ring of 'root' during
installation. You can also find it on the first installation CD and at
the end of this announcement.

2) If you need an alternative means of verification, use the md5sum
command to verify the authenticity of the packages. Execute the command

md5sum <filename.rpm>

after you downloaded the file from a SUSE FTP server or its mirrors.
Then compare the resulting md5sum with the one that is listed in the
SUSE security announcement. Because the announcement containing the
checksums is cryptographically signed (by security@suse.de), the
checksums show proof of the authenticity of the package if the
signature of the announcement is valid. Note that the md5 sums
published in the SUSE Security Announcements are valid for the
respective packages only. Newer versions of these packages cannot be
verified.

- SUSE runs two security mailing lists to which any interested party may
subscribe:

suse-security@suse.com
- General Linux and SUSE security discussion.
All SUSE security announcements are sent to this list.
To subscribe, send an e-mail to
<suse-security-subscribe@suse.com>.

suse-security-announce@suse.com
- SUSE's announce-only mailing list.
Only SUSE's security announcements are sent to this list.
To subscribe, send an e-mail to
<suse-security-announce-subscribe@suse.com>.

For general information or the frequently asked questions (FAQ),
send mail to <suse-security-info@suse.com> or
<suse-security-faq@suse.com>.

The information in this advisory may be distributed or reproduced,
provided that the advisory is not modified in any way. In particular, the
clear text signature should show proof of the authenticity of the text.

SUSE Linux Products GmbH provides no warranties of any kind whatsoever
with respect to the information contained in this security advisory.