Bug 169261 - CVE-2005-3055 async usb devio oops
CVE-2005-3055 async usb devio oops
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Pete Zaitcev
Brian Brock
: Security
Depends On:
Blocks: RHEL3U8CanFix 186960
  Show dependency treegraph
Reported: 2005-09-26 05:34 EDT by Mark J. Cox
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version: RHSA-2006-0437
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-07-20 09:30:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Candidate #1 - Same as RHEL-4 (5.22 KB, patch)
2006-04-14 03:57 EDT, Pete Zaitcev
no flags Details | Diff

  None (edit)
Description Mark J. Cox 2005-09-26 05:34:09 EDT
+++ This bug was initially created as a clone of Bug #169260 +++

Harald Welte mailed the lkml on 20050925 with a report of how to cause a local
oops if a user has permissions to access an arbitrary usb device.  I've rated
this as 'moderate' instead of 'important' due to that requirement.  Although usb
permissions will be given automatically to console users, a DOS from a user who
has physical access to a machine is little extra risk and we ignore that from
the severity calculation.

See the following URL for the description and patch
Comment 1 Mark J. Cox 2005-09-27 11:04:08 EDT
(See followup from Linus; proposed patch won't be applied)
Comment 3 Pete Zaitcev 2005-10-13 00:25:47 EDT
I have verified that RHEL 3 does not give access by default, both before
and after X start (init 3). I have pam-0.75-58, initscripts-7.31.16.EL-1.
When usbdevfs is mounted, no extra flags are supplied.

Normally access is granted by giving options "devmode" or "devuid"
to usbdevfs, but remember that one can do use chown(1) too.
It is not persistent across reboots, but it works otherwise.

Mark wrote that permissions are given, but perhaps he meant RHEL 4
and then cloned the bug into RHEL 3. I'm going to check if I have
same userland as he did.
Comment 4 Pete Zaitcev 2005-10-13 01:21:53 EDT
I am taking back the comment #3 for now. It is possible to open read-only,
so the question is if harmful ioctls are available in such case.
Comment 5 Mark J. Cox 2005-10-13 09:37:03 EDT
The discusson on vendor-sec was also mirrored to lkml; here is the link to the
most recent message (use thread previous to see the others)
Comment 9 Bob Johnson 2006-04-11 12:17:47 EDT
This issue is on Red Hat Engineering's list of planned work items 
for the upcoming Red Hat Enterprise Linux 3.8 release.  Engineering 
resources have been assigned and barring unforeseen circumstances, Red 
Hat intends to include this item in the 3.8 release.
Comment 10 Pete Zaitcev 2006-04-14 03:57:56 EDT
Created attachment 127737 [details]
Candidate #1 - Same as RHEL-4
Comment 11 Ernie Petrides 2006-04-22 04:58:59 EDT
A fix for this problem has just been committed to the RHEL3 U8
patch pool this evening (in kernel version 2.4.21-40.9.EL).
Comment 14 Red Hat Bugzilla 2006-07-20 09:30:43 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.


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