Bug 169261

Summary: CVE-2005-3055 async usb devio oops
Product: Red Hat Enterprise Linux 3 Reporter: Mark J. Cox <mjc>
Component: kernelAssignee: Pete Zaitcev <zaitcev>
Status: CLOSED ERRATA QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: dhoward, petrides
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: impact=moderate,public=20050925,source=lkml,reported=20050925
Fixed In Version: RHSA-2006-0437 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-07-20 13:30:42 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:
Bug Depends On:    
Bug Blocks: 181405, 186960    
Attachments:
Description Flags
Candidate #1 - Same as RHEL-4 none

Description Mark J. Cox 2005-09-26 09:34:09 UTC 
+++ 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
http://marc.theaimsgroup.com/?l=linux-kernel&m=112766129313883
Comment 1 Mark J. Cox 2005-09-27 15:04:08 UTC 
(See followup from Linus; proposed patch won't be applied)
Comment 3 Pete Zaitcev 2005-10-13 04:25:47 UTC 
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 05:21:53 UTC 
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 13:37:03 UTC 
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)
http://marc.theaimsgroup.com/?l=linux-kernel&m=112918286904030&w=2
Comment 9 Bob Johnson 2006-04-11 16:17:47 UTC 
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 07:57:56 UTC 
Created attachment 127737 [details]
Candidate #1 - Same as RHEL-4
Comment 11 Ernie Petrides 2006-04-22 08:58:59 UTC 
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 13:30:43 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-0437.html