Bug 175769
| Summary: | CVE-2005-3359 incorrect inrement/decrement in atm module leads to panic | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 4 | Reporter: | Doug Chapman <dchapman> | ||||
| Component: | kernel | Assignee: | Thomas Graf <tgraf> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Brian Brock <bbrock> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 4.0 | CC: | jbaron, rkhan, security-response-team | ||||
| Target Milestone: | --- | Keywords: | Security | ||||
| Target Release: | --- | ||||||
| Hardware: | ia64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | reported=20051214,public=20051214,source=redhat,impact=important | ||||||
| Fixed In Version: | RHSA-2006-0493 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2006-05-24 09:27:44 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
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 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. Created attachment 123918 [details]
proposed patch
Upstream changeset http://linux.bkbits.net:8080/linux-2.6/cset@4339c66aLroC1_zunYKhEIbtIWrnwg 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. thanks, - Doug 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 |
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: