Red Hat Bugzilla – Bug 175769
CVE-2005-3359 incorrect inrement/decrement in atm module leads to panic
Last modified: 2014-06-18 04:28:43 EDT
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:
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 18.104.22.168 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):
Steps to Reproduce:
1. compile the code listed above
2. run ./a.out as any user
asssign correct CVE name, CVE-2005-3359
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
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.
Created attachment 123918 [details]
therefore fixed in 2.6.14
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.
Looks like the fix for this is in the latest RHEL4 kernel. I tested 2.6.9-34.27
and it is OK.
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.