Bug 169130 - CVE-2005-3356 double decrement of mqueue_mnt->mnt_count in sys_mq_open
Summary: CVE-2005-3356 double decrement of mqueue_mnt->mnt_count in sys_mq_open
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel
Version: 4.0
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
: ---
Assignee: Alexander Viro
QA Contact: Brian Brock
URL:
Whiteboard: reported=20050923,impact=important,so...
Depends On:
Blocks: 168429
TreeView+ depends on / blocked
 
Reported: 2005-09-23 14:28 UTC by Doug Chapman
Modified: 2007-11-30 22:07 UTC (History)
2 users (show)

Fixed In Version: RHSA-2006-0101
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-01-17 08:33:48 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Ack'd patch used for 2.6.9 (3.37 KB, patch)
2005-11-24 15:47 UTC, Mark J. Cox
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2005:808 0 normal SHIPPED_LIVE Important: kernel security update 2005-10-27 04:00:00 UTC
Red Hat Product Errata RHSA-2006:0101 0 normal SHIPPED_LIVE Important: kernel security update 2006-01-17 05:00:00 UTC

Description Doug Chapman 2005-09-23 14:28:03 UTC
Created attachment 119181 [details]
simple reproducer

Comment 1 Doug Chapman 2005-09-23 14:28:03 UTC
Description of problem:
The mq_open system call has some error paths that decrement
mqueue_mnt->mnt_count twice causing the structure to be cleaned up which causes
a panic.  I am considering this a security sensitive bug because this can be
triggered by ANY USER using a 1 line program (see attachment).

I feel sys_mq_open needs to be rewritten to simplify the error paths.  The
problem is that when dentry_open fails it calls mntput() which decrements
mqueue_mnt->mnt_count then sys_mq_open calls mntput() again for any errors. 
Some of these error paths came from dentry_open while some did not.

I am seeing this on my HP ia64 systems however I do not believe it is archeture
specific.

Looking at the upstream 2.6.13.2 source I see sys_mq_open has not changed so it
appears that this patch will be needed upstream as well.

It does appear that fs/open.c on the 2.6.13.2 kernel has changed in the O_DIRECT
path (which this reproducer exploits) so it is possible that this reproducer may
not work there however since the error paths of sys_mq_open() have not changed I
am certain there are other exploits that would trigger this (just possibly not
the one liner I have come up with).

The upstream kernels don't seem to be working on ia64 and I don't have other
systems right now so I cannot verify.


Version-Release number of selected component (if applicable):
RHEL4-U2
kernel-2.6.9-20.EL (probably any 2.6.9 kernel as well)

How reproducible:
Every time.

Steps to Reproduce:
1. cc mq_open_panic.c (see attachment)
2. ./a.out (as any user)
  
Actual results:
panic

Expected results:
test should report an error via perror

Additional info:

Comment 3 Mark J. Cox 2005-11-24 15:47:55 UTC
Created attachment 121455 [details]
Ack'd patch used for 2.6.9

Comment 6 Jason Baron 2006-01-06 19:41:32 UTC
committed in -22.0.2

Comment 9 Mark J. Cox 2006-01-16 08:58:48 UTC
Reported upstream and vendor-sec on 20060111
Public 20060114

http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=7c7dce9209161eb260cdf9e9172f72c3a02379e6

Removing embargo from bug details

Comment 10 Red Hat Bugzilla 2006-01-17 08:33:50 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2006-0101.html



Note You need to log in before you can comment on or make changes to this bug.