SUSE Security Announcement: kernel multiple security problems (SUSE-SA:2005:050)

From: Marcus Meissner (
Date: 09/01/05

  • Next message: iDEFENSE Labs: "iDEFENSE Security Advisory 09.01.05: 3Com Network Supervisor Directory Traversal Vulnerability"
    Date: Thu, 01 Sep 2005 16:34:36 +0200

    Hash: SHA1


                            SUSE Security Announcement

            Package: kernel
            Announcement ID: SUSE-SA:2005:050
            Date: Thu, 01 Sep 2005 14:00:00 +0000
            Affected Products: 9.1, 9.2, 9.3
                                    SUSE Linux Enterprise Server 9
                                    Novell Linux Desktop 9
            Vulnerability Type: denial of service, local privilege escalation
            Severity (1-10): 7
            SUSE Default Package: yes
            Cross-References: CAN-2005-2457

        Content of This Advisory:
            1) Security Vulnerability Resolved:
                 various security issues and bugfixes for the Linux kernel
               Problem Description
            2) Solution or Workaround
            3) Special Instructions and Notes
            4) Package Location and Checksums
            5) Pending Vulnerabilities, Solutions, and Workarounds:
                See SUSE Security Summary Report.
            6) Authenticity Verification and Additional Information


    1) Problem Description and Brief Discussion

       The Linux kernel was updated to fix the following security issues:
       - CAN-2005-2457: A problem in decompression of files on "zisofs"
         filesystem was fixed.

       - CAN-2005-2458: A potential buffer overflow in the zlib decompression
         handling in the kernel was fixed.

       - CAN-2005-2459: Some return codes in zlib decoding were fixed which
         could have led to an attacker crashing the kernel.

       - CAN-2005-2555: Only processes with the CAP_NET_ADMIN capability is
         now allowed load socket policies.

       - CAN-2005-2456: Fixed a potential overflow caused by missing boundary
         checks of sock->sk_policy in net/xfrm/.

       - AMD64/EM64T/x86_64 only: A previous fix for a denial of service
         attack with compat 32bit mode programs was too strict and could
         crash the kernel. (The earlier fix had the Mitre CVE ID CAN-2005-1765.)

       - S/390 only: Fixed /sys/ permissions where a user could change machine
         states, including powering down or up partitions.

       - CAN-2005-0916: PowerPC only: A missing patch for a hugetlb memory
         context handling problem was added.

       Above problems affect SUSE Linux 9.1 up to 9.3 and SUSE Linux
       Enterprise Server 9.

       Additionally following bugs were fixed for SUSE Linux Enterprise
       Server 9 and SUSE Linux 9.1:
       - The reported process start times sometimes were incorrect.
       - The OCFS2 filesystem was updated to version 1.0.2. (SLES 9 only)
       - A potential deadlock in cpuset handling was fixed.
       - Fixed a potential crash on startup of the tg3 network driver.
       - Avoid high IRQ latencies in the VM handling.
       - rpm/ was fixed so that initrd.previous is preserved again.
       - A problem in the handling of the tape ioctl MTIOCPOS was fixed.
       - Make the OOM process killer send SIGTERM first instead of SIGKILL.
       - Fixed a netfilter connection track return code mismatch.
       - Fixed a typo in the ipt_TTL netfilter module.
       - XEN was updated to version 2.0.6b. (i386 only)
       - Allow rsize/wsize values less than 4096 for NFS mounts.
       - A data corruption problem within the reiserfs filesystem in
         the handling of writing to mmaped regions after close of the file
         descriptor was fixed.

    2) Solution or Workaround

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

    3) Special Instructions and Notes

         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

       **** 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

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

       **** 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


       **** 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


         Warning: An improperly installed boot loader will render your
                  system unbootable.

       **** Step 7: Reboot.

         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.

       x86 Platform:

       SUSE Linux 9.3:

       SUSE Linux 9.2:

       SUSE Linux 9.1:
       source rpm(s):

       x86-64 Platform:

       SUSE Linux 9.3:
       source rpm(s):

       SUSE Linux 9.2:
       source rpm(s):

       SUSE Linux 9.1:
       source rpm(s):


    5) Pending Vulnerabilities, Solutions, and Workarounds:

       See SUSE Security Summary Report.

    6) Authenticity Verification and Additional Information

      - Announcement authenticity verification:

        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:

          gpg: Signature made <DATE> using RSA key ID 3D25D3D9
          gpg: Good signature from "SuSE Security Team <>"

        where <DATE> is replaced by the date the document was signed.

        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

          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

        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 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, 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

      - SUSE runs two security mailing lists to which any interested party may
            - General Linux and SUSE security discussion.
                All SUSE security announcements are sent to this list.
                To subscribe, send an e-mail to
            - SUSE's announce-only mailing list.
                Only SUSE's security announcements are sent to this list.
                To subscribe, send an e-mail to

        For general information or the frequently asked questions (FAQ),
        send mail to <> or

        SUSE's security contact is <> or <>.
        The <> public key is listed below.

        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.

    Type Bits/KeyID Date User ID
    pub 2048R/3D25D3D9 1999-03-06 SuSE Security Team <>
    pub 1024D/9C800ACA 2000-10-19 SuSE Package Signing Key <>

    Version: GnuPG v1.0.6 (GNU/Linux)
    Comment: For info see

    - -----END PGP PUBLIC KEY BLOCK-----
    Version: GnuPG v1.4.2 (GNU/Linux)

    -----END PGP SIGNATURE-----

  • Next message: iDEFENSE Labs: "iDEFENSE Security Advisory 09.01.05: 3Com Network Supervisor Directory Traversal Vulnerability"

    Relevant Pages