Bug 177044 - Mouse disconnect races with close of /dev/input/mice, causing crash
Summary: Mouse disconnect races with close of /dev/input/mice, causing crash
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel
Version: 4.0
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
: ---
Assignee: Pete Zaitcev
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-01-05 18:15 UTC by Kimball Murray
Modified: 2012-06-20 15:54 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-06-20 15:54:41 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Test patch 1 (4.84 KB, patch)
2007-02-28 22:32 UTC, Pete Zaitcev
no flags Details | Diff

Description Kimball Murray 2006-01-05 18:15:22 UTC
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 22:32:51 UTC
Created attachment 148969 [details]
Test patch 1

Kimball, care to give this a try?

Comment 2 Pete Zaitcev 2008-08-13 20:55:31 UTC
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 15:54:41 UTC
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.