Bug 177044 - Mouse disconnect races with close of /dev/input/mice, causing crash
Mouse disconnect races with close of /dev/input/mice, causing crash
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
4.0
All Linux
medium Severity high
: ---
: ---
Assigned To: Pete Zaitcev
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-01-05 13:15 EST by Kimball Murray
Modified: 2012-06-20 11:54 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-20 11:54:41 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)
Test patch 1 (4.84 KB, patch)
2007-02-28 17:32 EST, Pete Zaitcev
no flags Details | Diff

  None (edit)
Description Kimball Murray 2006-01-05 13:15:22 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225

Description of problem:
When a USB mouse is unplugged, and nearly at the same time a process like the X server is releasing its input devices (closing the file /dev/input/mice), the kernel may crash, panic, or oops.  This happens because of a race between mousedev_release, and mousedev_disconnect, both of which ultimately kfree the same data structure.

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

How reproducible:
Sometimes

Steps to Reproduce:
1. Ensure that no process currently has the file /dev/input/mice open. (use fuser).
2. Write a small program that simply opens and closes /dev/input/mice.  Put this program in a loop.
3. With the above program running, disconnect the USB mouse.  This may take a few tries.
  

Actual Results:  Eventually, kfree is called twice, and the system panics or crashes.

Expected Results:  No crash or panic.

Additional info:

Upstream code is slightly different, but it's not obvious that the race is fixed.  Shouldn't be too hard to verify that using the steps outlined in the repro.

Note: the deadly race only happens when the _last_ user of /dev/input/mice closes the file.  This bug has probably been around for a while, but we managed to close down the X server just at the right time when somebody was unplugging the USB mouse.  All the relavant code is in drivers/input/mousedev.c.
Comment 1 Pete Zaitcev 2007-02-28 17:32:51 EST
Created attachment 148969 [details]
Test patch 1

Kimball, care to give this a try?
Comment 2 Pete Zaitcev 2008-08-13 16:55:31 EDT
I want the requestor to decide if this is a problem they want pursuing
further. The bug is real, just does not happen often.
Comment 3 Jiri Pallich 2012-06-20 11:54:41 EDT
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. 
Please See https://access.redhat.com/support/policy/updates/errata/

If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.

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