[linux-security] local DoS attack in Linux kernel

[Martin Siegert <siegert@sfu.ca>]

Topic
=====
local DoS attack in Linux kernel

Problem Description
===================
A vulnerability in the Linux kernel has been discovered in which a non-root
user can cause the machine to freeze.
The flaw is related to the kernel's handling of TF and NT flags.

Affected System
===============
all kernels 2.2.x and 2.4.y with y < 20.
(this basically includes all Linux installations on the planet)

Solution
========
upgrade to 2.4.20 or patched kernel for your distribution
[warning: there is a bug in the recently released 2.4.20 kernel that
can lead to file system corruption under certain circumstances. If you plan
to compile your own 2.4.20 kernel, apply the patch that is attached to this
advisory.]

General instructions for upgrading the kernel
---------------------------------------------
(this mostly refers to RedHat kernels, but the upgrade procedure should
work similarly for other distributions as well).

Use the check-rpms (http://www.sfu.ca/acs/linux/security/check-rpms.html)
script to find the kernel you should upgrade to:

# check-rpms | grep kernel

This will list (besides other kernel packages) something of the form

kernel<type>-2.4.18-18.7.x.<arch>.rpm

where <type> is either empty or "-smp", "-enterprise", or "-bigmem"
and <arch> is either "i386", "i586", "i686", or "athlon".
Install the listed kernel rpm package using the -i flag:

rpm -ivh kernel<type>-2.4.18-18.7.x.<arch>.rpm

If you are using the grub boot loader:
  After installing the new kernel edit the /etc/grub.conf file so that
  the default line points to the new kernel:
  The grub.conf file contains a line
  
  default=#
  
  (where # is an integer index 0, 1, ...) and then a series of sections all
  staring with a line "title" line, e.g.,
  
  title Red Hat Linux (2.4.18-17.7xsmp)
  
  The first of these "title" lines corresponds to index 0, the second to
  index 1, etc. (yes, I do find this numbering scheme confusing as well, but
  certain people seem to have a hard time to associate first with 1, second
  with 2, etc.). Change the default line so that the index points to the
  newly installed kernel. In most cases the new kernel will be listed first,
  thus you would change the line to "default=0".
  
If you are using the lilo boot loader:
  If you are not using grub (highly recommend despite the braindead numbering
  scheme), but the older boot loader lilo, you must edit the file /etc/lilo.conf
  instead. The lilo.conf file contains a line
  
  default=linux
  
  and then several sections that start with a line
  
  image=/boot/vmlinux-2.2.22-6.2.2smp
          label=linux
          ...
  
  image=/boot/vmlinux-2.2.19-6.2.16
          label=linux-2.2.19
          ...
  
  etc. Change the label line in the section that contains the line
          label=linux
  to something like
          label=linux-2.2.22old
  and then copy this very section so that it appears twice in the list.
  In the copied section change the label back to
          label=linux
  and then change all the versions in that section so that they refer to
  the newly installed kernel, e.g.,
  
  image=/boot/vmlinux-2.2.22-6.2.3smp
          label=linux 
          ...
  
  If there is an "initrd=..." line as well in that section, change the
  version in that line as well and then create the image file with the
  command
  
  mkinitrd /boot/initrd-2.2.22-6.2.3smp.img 2.2.22-6.2.3smp
  
  (replace the version-release<type> string with the appropriate string for
  your new kernel). After that run "/sbin/lilo".

Then install all the other kernel packages listed below in the usual way
(using the -Fvh flag instead of the -ivh flag).
         
Then reboot.

RedHat 6.x
----------
rpm -ivh kernel<type>-2.2.22-6.2.3.<arch>.rpm

rpm -Fvh kernel-headers-2.2.22-6.2.3.i386.rpm \
         kernel-doc-2.2.22-6.2.3.i386.rpm \
         kernel-source-2.2.22-6.2.3.i386.rpm \
         kernel-utils-2.2.22-6.2.3.i386.rpm \
         kernel-pcmcia-cs-2.2.22-6.2.3.i386.rpm \
         kernel-ibcs-2.2.22-6.2.3.i386.rpm

RedHat 7.0
----------
rpm -ivh kernel<type>-2.2.22-7.0.3.<arch>.rpm

rpm -Fvh kernel-doc-2.2.22-7.0.3.i386.rpm \
         kernel-source-2.2.22-7.0.3.i386.rpm \
         kernel-utils-2.2.22-7.0.3.i386.rpm \
         kernel-pcmcia-cs-2.2.22-7.0.3.i386.rpm \
         kernel-ibcs-2.2.22-7.0.3.i386.rpm

RedHat 7.1, 7.2, 7.3
--------------------
rpm -ivh kernel<type>-2.4.18-18.7.x.<arch>.rpm

rpm -Fvh kernel-doc-2.4.18-18.7.x.i386.rpm \
         kernel-source-2.4.18-18.7.x.i386.rpm

RedHat 8.0
----------
rpm -ivh kernel<type>-2.4.18-18.8.0.<arch>.rpm

rpm -Fvh kernel-doc-2.4.18-18.8.0.i386.rpm \
         kernel-source-2.4.18-18.8.0.i386.rpm
diff -Nru a/fs/ext3/fsync.c b/fs/ext3/fsync.c
--- a/fs/ext3/fsync.c	Tue Aug 27 16:19:57 2002
+++ b/fs/ext3/fsync.c	Sat Nov 30 15:39:30 2002
@@ -63,10 +63,12 @@
 	 */
 	ret = fsync_inode_buffers(inode);
 
-	/* In writeback mode, we need to force out data buffers too.  In
-	 * the other modes, ext3_force_commit takes care of forcing out
-	 * just the right data blocks. */
-	if (test_opt(inode->i_sb, DATA_FLAGS) == EXT3_MOUNT_WRITEBACK_DATA)
+	/*
+	 * If the inode is under ordered-data writeback it is not necessary to
+	 * sync its data buffers here - commit will do that, with potentially
+	 * better IO merging
+	 */
+	if (!ext3_should_order_data(inode))
 		ret |= fsync_inode_data_buffers(inode);
 
 	ext3_force_commit(inode->i_sb);