Bug 530490 (CVE-2009-3547)

Quote from the upstream commit:
fs: pipe.c null pointer dereference
    
This patch fixes a null pointer exception in pipe_rdwr_open() which generates the stack trace:
    
> Unable to handle kernel NULL pointer dereference at 0000000000000028 RIP:
>  [<ffffffff802899a5>] pipe_rdwr_open+0x35/0x70
>  [<ffffffff8028125c>] __dentry_open+0x13c/0x230
>  [<ffffffff8028143d>] do_filp_open+0x2d/0x40
>  [<ffffffff802814aa>] do_sys_open+0x5a/0x100
>  [<ffffffff8021faf3>] sysenter_do_call+0x1b/0x67
    
The failure mode is triggered by an attempt to open an anonymous pipe via /proc/pid/fd/* as exemplified by this script:
    
=============================================================
while : ; do
   { echo y ; sleep 1 ; } | { while read ; do echo z$REPLY; done ; } &
   PID=$!
   OUT=$(ps -efl | grep 'sleep 1' | grep -v grep |
        { read PID REST ; echo $PID; } )
   OUT="${OUT%% *}"
   DELAY=$((RANDOM * 1000 / 32768))
   usleep $((DELAY * 1000 + RANDOM % 1000 ))
   echo n > /proc/$OUT/fd/1                 # Trigger defect
done
=============================================================
    
Note that the failure window is quite small and I could only reliably reproduce the defect by inserting a small delay in pipe_rdwr_open(). For example:

 static int
 pipe_rdwr_open(struct inode *inode, struct file *filp)
 {
       msleep(100);
       mutex_lock(&inode->i_mutex);

Although the defect was observed in pipe_rdwr_open(), I think it makes sense to replicate the change through all the pipe_*_open() functions.
    
The core of the change is to verify that inode->i_pipe has not been released before attempting to manipulate it. If inode->i_pipe is no longer present, return ENOENT to indicate so.
    
The comment about potentially using atomic_t for i_pipe->readers and i_pipe->writers has also been removed because it is no longer relevant in this context. The inode->i_mutex lock must be used so that inode->i_pipe can be dealt with correctly.

http://lkml.org/lkml/2009/10/14/184
http://lkml.org/lkml/2009/10/21/42
http://git.kernel.org/linus/ad3960243e55320d74195fb85c975e0a8cc4466c

This issue has been addressed in following products:

  MRG for RHEL-5

Via RHSA-2009:1540 https://rhn.redhat.com/errata/RHSA-2009-1540.html

This issue has been addressed in following products:

  Red Hat Enterprise Linux 4

Via RHSA-2009:1541 https://rhn.redhat.com/errata/RHSA-2009-1541.html

This issue has been addressed in following products:

  Red Hat Enterprise Linux 5

Via RHSA-2009:1548 https://rhn.redhat.com/errata/RHSA-2009-1548.html

This issue has been addressed in following products:

  Red Hat Enterprise Linux 3

Via RHSA-2009:1550 https://rhn.redhat.com/errata/RHSA-2009-1550.html

kernel-2.6.30.9-96.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/kernel-2.6.30.9-96.fc11

kernel-2.6.30.9-96.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/kernel-2.6.30.9-96.fc11

kernel-2.6.27.38-170.2.113.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/kernel-2.6.27.38-170.2.113.fc10

kernel-2.6.30.9-96.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

kernel-2.6.27.38-170.2.113.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

This issue has been addressed in following products:

  Red Hat Enterprise Linux 5.3.Z - Server Only

Via RHSA-2009:1587 https://rhn.redhat.com/errata/RHSA-2009-1587.html

This issue has been addressed in following products:

  Red Hat Enterprise Linux 4.7 Z Stream

Via RHSA-2009:1588 https://rhn.redhat.com/errata/RHSA-2009-1588.html

Wrong placement for Comment #25, sorry!~ I should change its state back.

This issue has been addressed in following products:

  Red Hat Enterprise Linux 5.2 Z Stream

Via RHSA-2009:1672 https://rhn.redhat.com/errata/RHSA-2009-1672.html