Bug 175769 - CVE-2005-3359 incorrect inrement/decrement in atm module leads to panic
CVE-2005-3359 incorrect inrement/decrement in atm module leads to panic
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
4.0
ia64 Linux
medium Severity high
: ---
: ---
Assigned To: Thomas Graf
Brian Brock
reported=20051214,public=20051214,sou...
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-12-14 15:14 EST by Doug Chapman
Modified: 2014-06-18 04:28 EDT (History)
3 users (show)

See Also:
Fixed In Version: RHSA-2006-0493
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-05-24 05:27:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
proposed patch (1.45 KB, patch)
2006-01-31 11:49 EST, Thomas Graf
no flags Details | Diff

  None (edit)
Description Doug Chapman 2005-12-14 15:14:23 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050524 Fedora/1.0.4-4 Firefox/1.0.4

Description of problem:
Note, since this is a panic easily reproduced by any user I am submitting this as a security issue.  This panic is easily reproduceable on my HP ia64 systems.  I have not tried other platforms.

There appear to be incorrect error paths in the atm.ko module which can cause incorrect module reference counts and leads to a panic.  This can be reproduced by the following code:

#include <sys/socket.h>
main(){
        socket(PF_ATMPVC, SOCK_STREAM, 0);
        socket(PF_ATMPVC, 0, 0);
}


The first socket call does an extra decrement of the refcount.  If only this line is executed doing a lsmod | grep atm will show a refcount of 4294967295 (aka -1).  So doing this invalid call followed by a somewhat valid call increments it to zero which triggeres the panic.  Note that this refcount is still incorrect after the test process terminates.

Another odd and possibly related issue is if just the second line is executed the refcount is 2 (I would expect it to be 1).  Once the process calling this terminates and the socket is destroyed the refcount returns to 0 as expected.


This problem does NOT exist in the upstream 2.6.14.3 kernel however the issue with the refcount=2 still exists (which leads me to believe that part is correct for some reason I don't understand).



Version-Release number of selected component (if applicable):
kernel-2.6.9-25.EL

How reproducible:
Always

Steps to Reproduce:
1. compile the code listed above
2. run ./a.out as any user
3.
  

Additional info:
Comment 2 Mark J. Cox (Product Security) 2006-01-11 06:50:04 EST
asssign correct CVE name, CVE-2005-3359
Comment 6 Thomas Graf 2006-01-11 12:23:36 EST
The call to sk_set_owner() in vcc_create() is using THIS_MODULE instead of
sock->ops->owner which would correspond to the correct socket family module
reference.

For a module to take a reference on another module, it must be referenced by
someone else first. __sock_create in net/socket.c ensures this by taking a
reference on net_families[family]->owner (equals sock->ops->owner above) just
before invoking the family specific ->create() callback.

I attached a patch which should fix the problem but I'm very short on time and
two other issues having higher priority should be resolved first. So if someone
has the opportunity to test this, I'd appreciate it.
Comment 7 Thomas Graf 2006-01-31 11:49:49 EST
Created attachment 123918 [details]
proposed patch
Comment 8 Mark J. Cox (Product Security) 2006-02-17 03:14:16 EST
Upstream changeset
http://linux.bkbits.net:8080/linux-2.6/cset@4339c66aLroC1_zunYKhEIbtIWrnwg
therefore fixed in 2.6.14
Comment 11 Bob Johnson 2006-04-11 13:00:18 EDT
This issue is on Red Hat Engineering's list of planned work items 
for the upcoming Red Hat Enterprise Linux 4.4 release.  Engineering 
resources have been assigned and barring unforeseen circumstances, Red 
Hat intends to include this item in the 4.4 release.
Comment 12 Doug Chapman 2006-05-01 15:58:01 EDT
Looks like the fix for this is in the latest RHEL4 kernel.  I tested 2.6.9-34.27
and it is OK.

thanks,

- Doug
Comment 16 Red Hat Bugzilla 2006-05-24 05:27:44 EDT
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-0493.html

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