3.17-rc5: kernel oops when exiting X under heavy load

DISCUSSION Pavel Machek 3 participants 8 messages Oct 3, 2014 – Oct 7, 2014

Subsystems (2)

HID Input drivers

lore

Share & tools

lore

Pavel Machek

author

2014-10-03 23:11 UTC #0 lore raw

Hi!

Quoted 1 line

From the backtrace, it looks evdev related...?

Oct  4 00:59:47 duo wpa_supplicant[3824]: wlan0: SME: Trying to authenticate with 00:11:95:05:30:d7 (SSID='pavel' freq=2412 MHz)
Oct  4 00:59:47 duo wpa_supplicant[3824]: wlan0: Trying to associate with 00:11:95:05:30:d7 (SSID='pavel' freq=2412 MHz)
Oct  4 00:59:47 duo NetworkManager[3465]: <info> (wlan0): supplicant interface state: scanning -> authenticating
Oct  4 00:59:47 duo wpa_supplicant[3824]: wlan0: Associated with 00:11:95:05:30:d7
Oct  4 00:59:47 duo wpa_supplicant[3824]: wlan0: CTRL-EVENT-CONNECTED - Connection to 00:11:95:05:30:d7 completed (reauth) [id=0 id_str=]
Oct  4 00:59:47 duo NetworkManager[3465]: <info> (wlan0): supplicant interface state: authenticating -> associating
Oct  4 00:59:47 duo NetworkManager[3465]: <info> (wlan0): supplicant interface state: associating -> completed
Oct  4 00:59:55 duo kernel: BUG: unable to handle kernel paging request at f47b5000
Oct  4 00:59:55 duo kernel: IP: [<c42765ff>] memcpy+0xf/0x20
Oct  4 00:59:55 duo kernel: *pde = 373f3067 *pte = 347b5060 
Oct  4 00:59:55 duo kernel: Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
Oct  4 00:59:55 duo kernel: Modules linked in:
Oct  4 00:59:55 duo kernel: CPU: 0 PID: 22293 Comm: Xorg Not tainted 3.17.0-rc5+ #399
Oct  4 00:59:55 duo kernel: Hardware name: LENOVO 17097HU/17097HU, BIOS 7BETD8WW (2.19 ) 03/31/2011
Oct  4 00:59:55 duo kernel: task: eb4b1580 ti: ec6a2000 task.ti: ec6a2000
Oct  4 00:59:55 duo kernel: EIP: 0060:[<c42765ff>] EFLAGS: 00213006 CPU: 0
Oct  4 00:59:55 duo kernel: EIP is at memcpy+0xf/0x20
Oct  4 00:59:55 duo kernel: EAX: f5c42000 EBX: 00000bfc ECX: 00000146 EDX: f47b491c
Oct  4 00:59:55 duo kernel: ESI: f47b5000 EDI: f5c426e4 EBP: ec6a3e80 ESP: ec6a3e74
Oct  4 00:59:55 duo kernel: DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Oct  4 00:59:55 duo kernel: CR0: 80050033 CR2: f47b5000 CR3: 2c77d000 CR4: 00000710
Oct  4 00:59:55 duo kernel: Stack:
Oct  4 00:59:55 duo kernel: ec409800 f47b499c 00000bfc ec6a3ec4 c451f154 ec40980c f5c42000 c47ee121
Oct  4 00:59:55 duo kernel: 00000001 00000001 00000000 00203246 c47ef168 c451f367 f47cdcb4 eb4b1580
Oct  4 00:59:55 duo kernel: 00203246 eab3eec0 ec409800 ec409800 ec6a3f2c c451f468 f47b491c 000002ff
Oct  4 00:59:55 duo kernel: Call Trace:
Oct  4 00:59:55 duo kernel: [<c451f154>] evdev_handle_get_val.isra.7+0x54/0x240
Oct  4 00:59:55 duo kernel: [<c47ee121>] ? mutex_lock_interruptible_nested+0x31/0x330
Oct  4 00:59:55 duo kernel: [<c47ef168>] ? mutex_unlock+0x8/0x10
Oct  4 00:59:55 duo kernel: [<c451f367>] ? evdev_ioctl+0x27/0x7f0
Oct  4 00:59:55 duo kernel: [<c451f468>] evdev_ioctl+0x128/0x7f0
Oct  4 00:59:55 duo kernel: [<c40e9c5c>] ? cache_free_debugcheck+0x2ac/0x340
Oct  4 00:59:55 duo kernel: [<c451f340>] ? evdev_handle_get_val.isra.7+0x240/0x240
Oct  4 00:59:55 duo kernel: [<c40fead2>] do_vfs_ioctl+0x2f2/0x520
Oct  4 00:59:55 duo kernel: [<c40f8178>] ? final_putname+0x18/0x40
Oct  4 00:59:55 duo kernel: [<c40f8178>] ? final_putname+0x18/0x40
Oct  4 00:59:55 duo kernel: [<c40ee12a>] ? do_sys_open+0x17a/0x200
Oct  4 00:59:55 duo kernel: [<c40fed36>] SyS_ioctl+0x36/0x70
Oct  4 00:59:55 duo kernel: [<c47f105e>] syscall_call+0x7/0x7
Oct  4 00:59:55 duo kernel: [<c47f0000>] ? hrtimer_nanosleep_restart+0x60/0xa0
Oct  4 00:59:55 duo kernel: Code: fb ff ff 8b 43 54 2b 43 50 88 43 4e 5b 5d f3 c3 90 90 90 90 90 90 90 90 90 90 90 90 55 89 e5 57 89 c7 56 89 d6 53 89 cb c1 e9 02 <f3> a5 89 d9 83 e1 03 74 02 f3 a4 5b 5e 5f 5d c3 90 55 89 e5 57
Oct  4 00:59:55 duo kernel: EIP: [<c42765ff>] memcpy+0xf/0x20 SS:ESP 0068:ec6a3e74
Oct  4 00:59:55 duo kernel: CR2: 00000000f47b5000
Oct  4 00:59:55 duo kernel: ---[ end trace fee349319591dc44 ]---
Oct  4 01:04:08 duo rsyslogd: [origin software="rsyslogd" swVersion="8.4.0" x-pid="3490" x-info="http://www.rsyslog.com"] start

Signature · 2 lines

(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Dmitry Torokhov

2014-10-06 18:12 UTC #1 lore raw

Quoted 3 lines · Pavel Machek

Hi!
From the backtrace, it looks evdev related...?

Hmm, looks like it...

Quoted 39 lines


Oct  4 00:59:47 duo wpa_supplicant[3824]: wlan0: SME: Trying to authenticate with 00:11:95:05:30:d7 (SSID='pavel' freq=2412 MHz)
Oct  4 00:59:47 duo wpa_supplicant[3824]: wlan0: Trying to associate with 00:11:95:05:30:d7 (SSID='pavel' freq=2412 MHz)
Oct  4 00:59:47 duo NetworkManager[3465]: <info> (wlan0): supplicant interface state: scanning -> authenticating
Oct  4 00:59:47 duo wpa_supplicant[3824]: wlan0: Associated with 00:11:95:05:30:d7
Oct  4 00:59:47 duo wpa_supplicant[3824]: wlan0: CTRL-EVENT-CONNECTED - Connection to 00:11:95:05:30:d7 completed (reauth) [id=0 id_str=]
Oct  4 00:59:47 duo NetworkManager[3465]: <info> (wlan0): supplicant interface state: authenticating -> associating
Oct  4 00:59:47 duo NetworkManager[3465]: <info> (wlan0): supplicant interface state: associating -> completed
Oct  4 00:59:55 duo kernel: BUG: unable to handle kernel paging request at f47b5000
Oct  4 00:59:55 duo kernel: IP: [<c42765ff>] memcpy+0xf/0x20
Oct  4 00:59:55 duo kernel: *pde = 373f3067 *pte = 347b5060 
Oct  4 00:59:55 duo kernel: Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
Oct  4 00:59:55 duo kernel: Modules linked in:
Oct  4 00:59:55 duo kernel: CPU: 0 PID: 22293 Comm: Xorg Not tainted 3.17.0-rc5+ #399
Oct  4 00:59:55 duo kernel: Hardware name: LENOVO 17097HU/17097HU, BIOS 7BETD8WW (2.19 ) 03/31/2011
Oct  4 00:59:55 duo kernel: task: eb4b1580 ti: ec6a2000 task.ti: ec6a2000
Oct  4 00:59:55 duo kernel: EIP: 0060:[<c42765ff>] EFLAGS: 00213006 CPU: 0
Oct  4 00:59:55 duo kernel: EIP is at memcpy+0xf/0x20
Oct  4 00:59:55 duo kernel: EAX: f5c42000 EBX: 00000bfc ECX: 00000146 EDX: f47b491c
Oct  4 00:59:55 duo kernel: ESI: f47b5000 EDI: f5c426e4 EBP: ec6a3e80 ESP: ec6a3e74
Oct  4 00:59:55 duo kernel: DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Oct  4 00:59:55 duo kernel: CR0: 80050033 CR2: f47b5000 CR3: 2c77d000 CR4: 00000710
Oct  4 00:59:55 duo kernel: Stack:
Oct  4 00:59:55 duo kernel: ec409800 f47b499c 00000bfc ec6a3ec4 c451f154 ec40980c f5c42000 c47ee121
Oct  4 00:59:55 duo kernel: 00000001 00000001 00000000 00203246 c47ef168 c451f367 f47cdcb4 eb4b1580
Oct  4 00:59:55 duo kernel: 00203246 eab3eec0 ec409800 ec409800 ec6a3f2c c451f468 f47b491c 000002ff
Oct  4 00:59:55 duo kernel: Call Trace:
Oct  4 00:59:55 duo kernel: [<c451f154>] evdev_handle_get_val.isra.7+0x54/0x240
Oct  4 00:59:55 duo kernel: [<c47ee121>] ? mutex_lock_interruptible_nested+0x31/0x330
Oct  4 00:59:55 duo kernel: [<c47ef168>] ? mutex_unlock+0x8/0x10
Oct  4 00:59:55 duo kernel: [<c451f367>] ? evdev_ioctl+0x27/0x7f0
Oct  4 00:59:55 duo kernel: [<c451f468>] evdev_ioctl+0x128/0x7f0
Oct  4 00:59:55 duo kernel: [<c40e9c5c>] ? cache_free_debugcheck+0x2ac/0x340
Oct  4 00:59:55 duo kernel: [<c451f340>] ? evdev_handle_get_val.isra.7+0x240/0x240
Oct  4 00:59:55 duo kernel: [<c40fead2>] do_vfs_ioctl+0x2f2/0x520
Oct  4 00:59:55 duo kernel: [<c40f8178>] ? final_putname+0x18/0x40
Oct  4 00:59:55 duo kernel: [<c40f8178>] ? final_putname+0x18/0x40
Oct  4 00:59:55 duo kernel: [<c40ee12a>] ? do_sys_open+0x17a/0x200

Quoted 9 lines

Oct  4 00:59:55 duo kernel: [<c40fed36>] SyS_ioctl+0x36/0x70
Oct  4 00:59:55 duo kernel: [<c47f105e>] syscall_call+0x7/0x7
Oct  4 00:59:55 duo kernel: [<c47f0000>] ? hrtimer_nanosleep_restart+0x60/0xa0
Oct  4 00:59:55 duo kernel: Code: fb ff ff 8b 43 54 2b 43 50 88 43 4e 5b 5d f3 c3 90 90 90 90 90 90 90 90 90 90 90 90 55 89 e5 57 89 c7 56 89 d6 53 89 cb c1 e9 02 <f3> a5 89 d9 83 e1 03 74 02 f3 a4 5b 5e 5f 5d c3 90 55 89 e5 57
Oct  4 00:59:55 duo kernel: EIP: [<c42765ff>] memcpy+0xf/0x20 SS:ESP 0068:ec6a3e74
Oct  4 00:59:55 duo kernel: CR2: 00000000f47b5000
Oct  4 00:59:55 duo kernel: ---[ end trace fee349319591dc44 ]---
Oct  4 01:04:08 duo rsyslogd: [origin software="rsyslogd" swVersion="8.4.0" x-pid="3490" x-info="http://www.rsyslog.com"] start

Does the patch below help by any chance?

Thanks.

Signature · 17 lines

Dmitry


Input: evdev - fix EVIOCG{type} ioctl

From: Dmitry Torokhov <[email protected]>

The 'max' size passed into the function is measured in number of bits
(KEY_MAX, LED_MAX, etc) so we nedd to convert it accoidingly before tyring
to copy the data out, otherwise we will try copying too much and end up
with up with a page fault.

Reported-by: Pavel Machek <[email protected]>
Signed-off-by: Dmitry Torokhov <[email protected]>
---
 drivers/input/evdev.c |   13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

drivers/input/evdev.c +8 -5

index de05545..bc20348 100644
@@ -738,20 +738,23 @@ static int evdev_handle_set_keycode_v2(struct input_dev *dev, void __user *p)
  */
 static int evdev_handle_get_val(struct evdev_client *client,
 				struct input_dev *dev, unsigned int type,
-				unsigned long *bits, unsigned int max,
-				unsigned int size, void __user *p, int compat)
+				unsigned long *bits, unsigned int maxbit,
+				unsigned int maxlen, void __user *p,
+				int compat)
 {
 	int ret;
 	unsigned long *mem;
+	size_t len;
 
-	mem = kmalloc(sizeof(unsigned long) * max, GFP_KERNEL);
+	len = BITS_TO_LONGS(maxbit) * sizeof(unsigned long);
+	mem = kmalloc(len, GFP_KERNEL);
 	if (!mem)
 		return -ENOMEM;
 
 	spin_lock_irq(&dev->event_lock);
 	spin_lock(&client->buffer_lock);
 
-	memcpy(mem, bits, sizeof(unsigned long) * max);
+	memcpy(mem, bits, len);
 
 	spin_unlock(&dev->event_lock);

@@ -759,7 +762,7 @@ static int evdev_handle_get_val(struct evdev_client *client,
 
 	spin_unlock_irq(&client->buffer_lock);
 
-	ret = bits_to_user(mem, max, size, p, compat);
+	ret = bits_to_user(mem, maxbit, maxlen, p, compat);
 	if (ret < 0)
 		evdev_queue_syn_dropped(client);

Pavel Machek

author

2014-10-06 20:45 UTC #2 lore raw

Hi!

Quoted 3 lines

Quoted 1 line
From the backtrace, it looks evdev related...?
Hmm, looks like it...

I don't think I can repeat that. I was doing crazy stuff at that moment. (Typo fixes suggested below).

Thanks,
Pavel

Input: evdev - fix EVIOCG{type} ioctl

From: Dmitry Torokhov <[email protected]>

The 'max' size passed into the function is measured in number of bits (KEY_MAX, LED_MAX, etc) so we nedd to convert it accoidingly before tyring

### need accordingly(?) trying

to copy the data out, otherwise we will try copying too much and end up with up with a page fault.

Reported-by Pavel Machek <[email protected]>

Signed-off-by Dmitry Torokhov <[email protected]>

Signature · 2 lines

(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Dmitry Torokhov

2014-10-06 21:03 UTC #3 lore raw

Quoted 12 lines · Pavel Machek

Hi!
Quoted 3 lines
Quoted 1 line
From the backtrace, it looks evdev related...?
Hmm, looks like it...
I don't think I can repeat that. I was doing crazy stuff at that moment. (Typo fixes suggested below).
Thanks,
Pavel

Quoted 8 lines

Input: evdev - fix EVIOCG{type} ioctl
From: Dmitry Torokhov <[email protected]>
The 'max' size passed into the function is measured in number of bits (KEY_MAX, LED_MAX, etc) so we nedd to convert it accoidingly before tyring
### need accordingly(?) trying

Thanks, I'll fix them up.

Signature · 1 line

Dmitry

Pavel Machek

author

2014-10-06 21:14 UTC #4 lore raw

Quoted 15 lines · Dmitry Torokhov

Quoted 14 lines · Pavel Machek
Hi!
Quoted 3 lines
Quoted 1 line
From the backtrace, it looks evdev related...?
Hmm, looks like it...
I don't think I can repeat that. I was doing crazy stuff at that moment. (Typo fixes suggested below).
Thanks,
Pavel
Input: evdev - fix EVIOCG{type} ioctl

Quoted 8 lines

Quoted 6 lines
From: Dmitry Torokhov <[email protected]>
The 'max' size passed into the function is measured in number of bits (KEY_MAX, LED_MAX, etc) so we nedd to convert it accoidingly before tyring
### need accordingly(?) trying
Thanks, I'll fix them up.

No problem. BTW, I guess this should go to 3.17-stable at least, and probably older stable releases, too...?

Thanks,
Pavel

Signature · 2 lines

(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Dmitry Torokhov

2014-10-06 21:31 UTC #5 lore raw

Quoted 21 lines · Pavel Machek

Quoted 20 lines · Dmitry Torokhov
Quoted 19 lines · Pavel Machek
Hi!
Quoted 3 lines
Quoted 1 line
From the backtrace, it looks evdev related...?
Hmm, looks like it...
I don't think I can repeat that. I was doing crazy stuff at that moment. (Typo fixes suggested below).
Thanks,
Pavel
Input: evdev - fix EVIOCG{type} ioctl
From: Dmitry Torokhov <[email protected]>
The 'max' size passed into the function is measured in number of bits (KEY_MAX, LED_MAX, etc) so we nedd to convert it accoidingly before tyring

Quoted 6 lines

Quoted 3 lines
Quoted 1 line
### need accordingly(?) trying
Thanks, I'll fix them up.
No problem. BTW, I guess this should go to 3.17-stable at least, and probably older stable releases, too...?

Yep. I'll wait for a bit though to give a chance more people to look it over before committing to my tree.

BTW, can I put you down as reviewed-by?

Signature · 1 line

Dmitry

Pavel Machek

author

2014-10-06 22:47 UTC #6 lore raw

Quoted 26 lines · Dmitry Torokhov

Quoted 25 lines · Pavel Machek
Quoted 23 lines · Dmitry Torokhov
Quoted 12 lines · Pavel Machek
Hi!
Quoted 3 lines
Quoted 1 line
From the backtrace, it looks evdev related...?
Hmm, looks like it...
I don't think I can repeat that. I was doing crazy stuff at that moment. (Typo fixes suggested below).
Thanks,
Pavel
Quoted 8 lines
Input: evdev - fix EVIOCG{type} ioctl
From: Dmitry Torokhov <[email protected]>
The 'max' size passed into the function is measured in number of bits (KEY_MAX, LED_MAX, etc) so we nedd to convert it accoidingly before tyring
### need accordingly(?) trying
Thanks, I'll fix them up.

Quoted 7 lines

Quoted 2 lines
No problem. BTW, I guess this should go to 3.17-stable at least, and probably older stable releases, too...?
Yep. I'll wait for a bit though to give a chance more people to look it over before committing to my tree.
BTW, can I put you down as reviewed-by?

I'm not an input expert, but yes, it looks ok to me.
Pavel

Signature · 2 lines

(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

David Herrmann

Reviewed-by

2014-10-07 16:16 UTC #7 lore raw

In reply to Dmitry Torokhov

Quoted 98 lines · Dmitry Torokhov

Quoted 3 lines · Pavel Machek

Hi!
From the backtrace, it looks evdev related...?

Hmm, looks like it...

Quoted 39 lines


Oct  4 00:59:47 duo wpa_supplicant[3824]: wlan0: SME: Trying to authenticate with 00:11:95:05:30:d7 (SSID='pavel' freq=2412 MHz)
Oct  4 00:59:47 duo wpa_supplicant[3824]: wlan0: Trying to associate with 00:11:95:05:30:d7 (SSID='pavel' freq=2412 MHz)
Oct  4 00:59:47 duo NetworkManager[3465]: <info> (wlan0): supplicant interface state: scanning -> authenticating
Oct  4 00:59:47 duo wpa_supplicant[3824]: wlan0: Associated with 00:11:95:05:30:d7
Oct  4 00:59:47 duo wpa_supplicant[3824]: wlan0: CTRL-EVENT-CONNECTED - Connection to 00:11:95:05:30:d7 completed (reauth) [id=0 id_str=]
Oct  4 00:59:47 duo NetworkManager[3465]: <info> (wlan0): supplicant interface state: authenticating -> associating
Oct  4 00:59:47 duo NetworkManager[3465]: <info> (wlan0): supplicant interface state: associating -> completed
Oct  4 00:59:55 duo kernel: BUG: unable to handle kernel paging request at f47b5000
Oct  4 00:59:55 duo kernel: IP: [<c42765ff>] memcpy+0xf/0x20
Oct  4 00:59:55 duo kernel: *pde = 373f3067 *pte = 347b5060
Oct  4 00:59:55 duo kernel: Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
Oct  4 00:59:55 duo kernel: Modules linked in:
Oct  4 00:59:55 duo kernel: CPU: 0 PID: 22293 Comm: Xorg Not tainted 3.17.0-rc5+ #399
Oct  4 00:59:55 duo kernel: Hardware name: LENOVO 17097HU/17097HU, BIOS 7BETD8WW (2.19 ) 03/31/2011
Oct  4 00:59:55 duo kernel: task: eb4b1580 ti: ec6a2000 task.ti: ec6a2000
Oct  4 00:59:55 duo kernel: EIP: 0060:[<c42765ff>] EFLAGS: 00213006 CPU: 0
Oct  4 00:59:55 duo kernel: EIP is at memcpy+0xf/0x20
Oct  4 00:59:55 duo kernel: EAX: f5c42000 EBX: 00000bfc ECX: 00000146 EDX: f47b491c
Oct  4 00:59:55 duo kernel: ESI: f47b5000 EDI: f5c426e4 EBP: ec6a3e80 ESP: ec6a3e74
Oct  4 00:59:55 duo kernel: DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Oct  4 00:59:55 duo kernel: CR0: 80050033 CR2: f47b5000 CR3: 2c77d000 CR4: 00000710
Oct  4 00:59:55 duo kernel: Stack:
Oct  4 00:59:55 duo kernel: ec409800 f47b499c 00000bfc ec6a3ec4 c451f154 ec40980c f5c42000 c47ee121
Oct  4 00:59:55 duo kernel: 00000001 00000001 00000000 00203246 c47ef168 c451f367 f47cdcb4 eb4b1580
Oct  4 00:59:55 duo kernel: 00203246 eab3eec0 ec409800 ec409800 ec6a3f2c c451f468 f47b491c 000002ff
Oct  4 00:59:55 duo kernel: Call Trace:
Oct  4 00:59:55 duo kernel: [<c451f154>] evdev_handle_get_val.isra.7+0x54/0x240
Oct  4 00:59:55 duo kernel: [<c47ee121>] ? mutex_lock_interruptible_nested+0x31/0x330
Oct  4 00:59:55 duo kernel: [<c47ef168>] ? mutex_unlock+0x8/0x10
Oct  4 00:59:55 duo kernel: [<c451f367>] ? evdev_ioctl+0x27/0x7f0
Oct  4 00:59:55 duo kernel: [<c451f468>] evdev_ioctl+0x128/0x7f0
Oct  4 00:59:55 duo kernel: [<c40e9c5c>] ? cache_free_debugcheck+0x2ac/0x340
Oct  4 00:59:55 duo kernel: [<c451f340>] ? evdev_handle_get_val.isra.7+0x240/0x240
Oct  4 00:59:55 duo kernel: [<c40fead2>] do_vfs_ioctl+0x2f2/0x520
Oct  4 00:59:55 duo kernel: [<c40f8178>] ? final_putname+0x18/0x40
Oct  4 00:59:55 duo kernel: [<c40f8178>] ? final_putname+0x18/0x40
Oct  4 00:59:55 duo kernel: [<c40ee12a>] ? do_sys_open+0x17a/0x200

Quoted 9 lines

Oct  4 00:59:55 duo kernel: [<c40fed36>] SyS_ioctl+0x36/0x70
Oct  4 00:59:55 duo kernel: [<c47f105e>] syscall_call+0x7/0x7
Oct  4 00:59:55 duo kernel: [<c47f0000>] ? hrtimer_nanosleep_restart+0x60/0xa0
Oct  4 00:59:55 duo kernel: Code: fb ff ff 8b 43 54 2b 43 50 88 43 4e 5b 5d f3 c3 90 90 90 90 90 90 90 90 90 90 90 90 55 89 e5 57 89 c7 56 89 d6 53 89 cb c1 e9 02 <f3> a5 89 d9 83 e1 03 74 02 f3 a4 5b 5e 5f 5d c3 90 55 89 e5 57
Oct  4 00:59:55 duo kernel: EIP: [<c42765ff>] memcpy+0xf/0x20 SS:ESP 0068:ec6a3e74
Oct  4 00:59:55 duo kernel: CR2: 00000000f47b5000
Oct  4 00:59:55 duo kernel: ---[ end trace fee349319591dc44 ]---
Oct  4 01:04:08 duo rsyslogd: [origin software="rsyslogd" swVersion="8.4.0" x-pid="3490" x-info="http://www.rsyslog.com"] start

Does the patch below help by any chance?

Thanks.

--
Dmitry

Input: evdev - fix EVIOCG{type} ioctl

From: Dmitry Torokhov <[email protected]>

The 'max' size passed into the function is measured in number of bits (KEY_MAX, LED_MAX, etc) so we nedd to convert it accoidingly before tyring to copy the data out, otherwise we will try copying too much and end up with up with a page fault.

Reported-by Pavel Machek <[email protected]>

Signed-off-by Dmitry Torokhov <[email protected]>

---
 drivers/input/evdev.c |   13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

drivers/input/evdev.c +4 -3

index de05545..bc20348 100644
@@ -738,20 +738,23 @@ static int evdev_handle_set_keycode_v2(struct input_dev *dev, void __user *p)
  */
 static int evdev_handle_get_val(struct evdev_client *client,
                                struct input_dev *dev, unsigned int type,
-                               unsigned long *bits, unsigned int max,
-                               unsigned int size, void __user *p, int compat)
+                               unsigned long *bits, unsigned int maxbit,
+                               unsigned int maxlen, void __user *p,
+                               int compat)
 {
        int ret;
        unsigned long *mem;
+       size_t len;
 
-       mem = kmalloc(sizeof(unsigned long) * max, GFP_KERNEL);

drivers/input/evdev.c static int evdev_handle_set_keycode_v2(struct input_dev *dev, void __user *p) · line 757

Quoted 10 lines

drivers/input/evdev.c +3 -1

+       len = BITS_TO_LONGS(maxbit) * sizeof(unsigned long);
+       mem = kmalloc(len, GFP_KERNEL);
        if (!mem)
                return -ENOMEM;
 
        spin_lock_irq(&dev->event_lock);
        spin_lock(&client->buffer_lock);
 
-       memcpy(mem, bits, sizeof(unsigned long) * max);
+       memcpy(mem, bits, len);

So this is where it breaks? Because we copy from "bits", which is an array in the input-device? Very unlikely to trigger, I guess. Sure, so far we overallocate and copy way to much into the array, but the bits_to_user() truncates it properly. So afaics, this only fails if the kernel memory isn't accessible, and thus faults.

Patch looks good! Nice catch:

Reviewed-by David Herrmann <[email protected]>

Thanks
David

Quoted 12 lines

drivers/input/evdev.c +1 -1

        spin_unlock(&dev->event_lock);

@@ -759,7 +762,7 @@ static int evdev_handle_get_val(struct evdev_client *client,
 
        spin_unlock_irq(&client->buffer_lock);
 
-       ret = bits_to_user(mem, max, size, p, compat);
+       ret = bits_to_user(mem, maxbit, maxlen, p, compat);
        if (ret < 0)
                evdev_queue_syn_dropped(client);