* [2.6.39-rc2, framebuffer] use after free oops @ 2011-04-10 11:10 ` Daniel J Blueman 0 siblings, 0 replies; 15+ messages in thread From: Daniel J Blueman @ 2011-04-10 11:10 UTC (permalink / raw) To: Paul Mundt, linux-fbdev; +Cc: Linux Kernel When building in the eg vga16 and intelfb framebuffers and page debugging, we can get hit by a use-after-free oops [1]; with page debugging disabled, this slips by unnoticed. When intelfb registers, the vga16 framebuffer is detected covering it's I/O regions, so it is removed (in remove_conflicting_framebuffers->unregister_framebuffer). The problem is the fb_info structure is freed (in unregister_framebuffer->vga16fb_destroy->framebuffer_release->kfree) before all open files to it are closed, so we get a use-after-free scenario. Freeing should be deferred until the last user has gone away. What approach would make sense here? Daniel --- [1] checking generic (a0000 10000) vs hw (d0000000 10000000) fb: conflicting fb hw usage inteldrmfb vs VGA16 VGA - removing generic driver Console: switching to colour VGA+ 80x25 BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 IP: [<ffffffff81708394>] mutex_lock_nested+0x94/0x390 PGD 2203ab067 PUD 2203ac067 PMD 0 Oops: 0002 [#2] PREEMPT SMP DEBUG_PAGEALLOC last sysfs file: /sys/devices/pci0000:00/0000:00:1b.0/sound/card0/uevent CPU 3 Modules linked in: arc4 ecb uvcvideo videodev v4l2_compat_ioctl32 i915(+) drm_kms_helper iwlagn mmc_block mac80211 drm video sdhci_pci sdhci mmc_core Pid: 271, comm: plymouthd Tainted: G D 2.6.39-rc2-350cd+ #1 Dell Inc. Latitude E5420/0H5TG2 RIP: 0010:[<ffffffff81708394>] [<ffffffff81708394>] mutex_lock_nested+0x94/0x390 RSP: 0018:ffff88021ee77c08 EFLAGS: 00010046 RAX: 0000000000010000 RBX: 0000000000000008 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffff8170838b RBP: ffff88021ee77c78 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff88021e574020 R13: 0000000000000010 R14: 0000000000000246 R15: ffff88021de6f478 FS: 00007f50d6e9c720(0000) GS:ffff88022ec60000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000010 CR3: 00000002203aa000 CR4: 00000000000406e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process plymouthd (pid: 271, threadinfo ffff88021ee76000, task ffff88021e574020) Stack: ffffffff81375552 0000000000000000 00000000fffffff2 ffff88021de6f478 ffff88021e574020 0000000000000246 0000000000000000 00000000fffffff2 ffff88021ee77c68 0000000000000000 0000000000000008 0000000000000000 Call Trace: [<ffffffff81375552>] ? lock_fb_info+0x22/0x60 [<ffffffff81375552>] lock_fb_info+0x22/0x60 [<ffffffff8137a24b>] fb_set_user_cmap+0x15b/0x1a0 [<ffffffff81376e28>] do_fb_ioctl+0x4b8/0x5e0 [<ffffffff81105dae>] ? might_fault+0x4e/0xa0 [<ffffffff81058e61>] ? get_parent_ip+0x11/0x50 [<ffffffff81058f3d>] ? sub_preempt_count+0x9d/0xd0 [<ffffffff8170a26d>] ? _raw_spin_unlock_irqrestore+0x3d/0x80 [<ffffffff8104840e>] ? __wake_up+0x4e/0x70 [<ffffffff813e47b9>] ? put_ldisc+0x59/0xd0 [<ffffffff813e4839>] ? tty_ldisc_deref+0x9/0x10 [<ffffffff813def59>] ? tty_ioctl+0x299/0xa00 [<ffffffff81377214>] fb_ioctl+0x24/0x30 [<ffffffff81152ec7>] do_vfs_ioctl+0x87/0x330 [<ffffffff81140e85>] ? fget+0x95/0x240 [<ffffffff81140df0>] ? fget_raw+0x240/0x240 [<ffffffff811531ba>] sys_ioctl+0x4a/0x80 [<ffffffff8170adfb>] system_call_fastpath+0x16/0x1b Code: 48 8b 04 25 c8 b5 00 00 8b 80 44 e0 ff ff a9 00 ff ff 07 0f 85 d7 02 00 00 9c 41 5e fa e8 15 d2 98 ff 4c 8d 6b 08 b8 00 00 01 00 <f0> 0f c1 43 08 0f b7 d0 c1 e8 10 39 c2 74 08 f3 90 0f b7 53 08 RIP [<ffffffff81708394>] mutex_lock_nested+0x94/0x390 RSP <ffff88021ee77c08> CR2: 0000000000000010 ---[ end trace cdacd65f5f1b187d ]--- note: plymouthd[271] exited with preempt_count 1 -- Daniel J Blueman ^ permalink raw reply [flat|nested] 15+ messages in thread
* [2.6.39-rc2, framebuffer] use after free oops @ 2011-04-10 11:10 ` Daniel J Blueman 0 siblings, 0 replies; 15+ messages in thread From: Daniel J Blueman @ 2011-04-10 11:10 UTC (permalink / raw) To: Paul Mundt, linux-fbdev; +Cc: Linux Kernel When building in the eg vga16 and intelfb framebuffers and page debugging, we can get hit by a use-after-free oops [1]; with page debugging disabled, this slips by unnoticed. When intelfb registers, the vga16 framebuffer is detected covering it's I/O regions, so it is removed (in remove_conflicting_framebuffers->unregister_framebuffer). The problem is the fb_info structure is freed (in unregister_framebuffer->vga16fb_destroy->framebuffer_release->kfree) before all open files to it are closed, so we get a use-after-free scenario. Freeing should be deferred until the last user has gone away. What approach would make sense here? Daniel --- [1] checking generic (a0000 10000) vs hw (d0000000 10000000) fb: conflicting fb hw usage inteldrmfb vs VGA16 VGA - removing generic driver Console: switching to colour VGA+ 80x25 BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 IP: [<ffffffff81708394>] mutex_lock_nested+0x94/0x390 PGD 2203ab067 PUD 2203ac067 PMD 0 Oops: 0002 [#2] PREEMPT SMP DEBUG_PAGEALLOC last sysfs file: /sys/devices/pci0000:00/0000:00:1b.0/sound/card0/uevent CPU 3 Modules linked in: arc4 ecb uvcvideo videodev v4l2_compat_ioctl32 i915(+) drm_kms_helper iwlagn mmc_block mac80211 drm video sdhci_pci sdhci mmc_core Pid: 271, comm: plymouthd Tainted: G D 2.6.39-rc2-350cd+ #1 Dell Inc. Latitude E5420/0H5TG2 RIP: 0010:[<ffffffff81708394>] [<ffffffff81708394>] mutex_lock_nested+0x94/0x390 RSP: 0018:ffff88021ee77c08 EFLAGS: 00010046 RAX: 0000000000010000 RBX: 0000000000000008 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffff8170838b RBP: ffff88021ee77c78 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff88021e574020 R13: 0000000000000010 R14: 0000000000000246 R15: ffff88021de6f478 FS: 00007f50d6e9c720(0000) GS:ffff88022ec60000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000010 CR3: 00000002203aa000 CR4: 00000000000406e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process plymouthd (pid: 271, threadinfo ffff88021ee76000, task ffff88021e574020) Stack: ffffffff81375552 0000000000000000 00000000fffffff2 ffff88021de6f478 ffff88021e574020 0000000000000246 0000000000000000 00000000fffffff2 ffff88021ee77c68 0000000000000000 0000000000000008 0000000000000000 Call Trace: [<ffffffff81375552>] ? lock_fb_info+0x22/0x60 [<ffffffff81375552>] lock_fb_info+0x22/0x60 [<ffffffff8137a24b>] fb_set_user_cmap+0x15b/0x1a0 [<ffffffff81376e28>] do_fb_ioctl+0x4b8/0x5e0 [<ffffffff81105dae>] ? might_fault+0x4e/0xa0 [<ffffffff81058e61>] ? get_parent_ip+0x11/0x50 [<ffffffff81058f3d>] ? sub_preempt_count+0x9d/0xd0 [<ffffffff8170a26d>] ? _raw_spin_unlock_irqrestore+0x3d/0x80 [<ffffffff8104840e>] ? __wake_up+0x4e/0x70 [<ffffffff813e47b9>] ? put_ldisc+0x59/0xd0 [<ffffffff813e4839>] ? tty_ldisc_deref+0x9/0x10 [<ffffffff813def59>] ? tty_ioctl+0x299/0xa00 [<ffffffff81377214>] fb_ioctl+0x24/0x30 [<ffffffff81152ec7>] do_vfs_ioctl+0x87/0x330 [<ffffffff81140e85>] ? fget+0x95/0x240 [<ffffffff81140df0>] ? fget_raw+0x240/0x240 [<ffffffff811531ba>] sys_ioctl+0x4a/0x80 [<ffffffff8170adfb>] system_call_fastpath+0x16/0x1b Code: 48 8b 04 25 c8 b5 00 00 8b 80 44 e0 ff ff a9 00 ff ff 07 0f 85 d7 02 00 00 9c 41 5e fa e8 15 d2 98 ff 4c 8d 6b 08 b8 00 00 01 00 <f0> 0f c1 43 08 0f b7 d0 c1 e8 10 39 c2 74 08 f3 90 0f b7 53 08 RIP [<ffffffff81708394>] mutex_lock_nested+0x94/0x390 RSP <ffff88021ee77c08> CR2: 0000000000000010 ---[ end trace cdacd65f5f1b187d ]--- note: plymouthd[271] exited with preempt_count 1 -- Daniel J Blueman ^ permalink raw reply [flat|nested] 15+ messages in thread
* [2.6.39-rc2, framebuffer] use after free oops 2011-04-10 11:10 ` Daniel J Blueman @ 2011-04-20 5:50 ` Daniel J Blueman -1 siblings, 0 replies; 15+ messages in thread From: Daniel J Blueman @ 2011-04-20 5:50 UTC (permalink / raw) To: Paul Mundt, linux-fbdev, Linux Kernel Any ideas on how best to address this issue [0], since it causes silent corruption, or at best crashes? Thanks, Daniel --- [0] When building in the eg vga16 and intelfb framebuffers and page debugging, we can get hit by a use-after-free oops [1]; with page debugging disabled, this slips by unnoticed. When intelfb registers, the vga16 framebuffer is detected covering it's I/O regions, so it is removed (in remove_conflicting_framebuffers->unregister_framebuffer). The problem is the fb_info structure is freed (in unregister_framebuffer->vga16fb_destroy->framebuffer_release->kfree) before all open files to it are closed, so we get a use-after-free scenario. Freeing should be deferred until the last user has gone away. What approach would make sense here? Daniel --- [1] checking generic (a0000 10000) vs hw (d0000000 10000000) fb: conflicting fb hw usage inteldrmfb vs VGA16 VGA - removing generic driver Console: switching to colour VGA+ 80x25 BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 IP: [<ffffffff81708394>] mutex_lock_nested+0x94/0x390 PGD 2203ab067 PUD 2203ac067 PMD 0 Oops: 0002 [#2] PREEMPT SMP DEBUG_PAGEALLOC last sysfs file: /sys/devices/pci0000:00/0000:00:1b.0/sound/card0/uevent CPU 3 Modules linked in: arc4 ecb uvcvideo videodev v4l2_compat_ioctl32 i915(+) drm_kms_helper iwlagn mmc_block mac80211 drm video sdhci_pci sdhci mmc_core Pid: 271, comm: plymouthd Tainted: G D 2.6.39-rc2-350cd+ #1 Dell Inc. Latitude E5420/0H5TG2 RIP: 0010:[<ffffffff81708394>] [<ffffffff81708394>] mutex_lock_nested+0x94/0x390 RSP: 0018:ffff88021ee77c08 EFLAGS: 00010046 RAX: 0000000000010000 RBX: 0000000000000008 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffff8170838b RBP: ffff88021ee77c78 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff88021e574020 R13: 0000000000000010 R14: 0000000000000246 R15: ffff88021de6f478 FS: 00007f50d6e9c720(0000) GS:ffff88022ec60000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000010 CR3: 00000002203aa000 CR4: 00000000000406e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process plymouthd (pid: 271, threadinfo ffff88021ee76000, task ffff88021e574020) Stack: ffffffff81375552 0000000000000000 00000000fffffff2 ffff88021de6f478 ffff88021e574020 0000000000000246 0000000000000000 00000000fffffff2 ffff88021ee77c68 0000000000000000 0000000000000008 0000000000000000 Call Trace: [<ffffffff81375552>] ? lock_fb_info+0x22/0x60 [<ffffffff81375552>] lock_fb_info+0x22/0x60 [<ffffffff8137a24b>] fb_set_user_cmap+0x15b/0x1a0 [<ffffffff81376e28>] do_fb_ioctl+0x4b8/0x5e0 [<ffffffff81105dae>] ? might_fault+0x4e/0xa0 [<ffffffff81058e61>] ? get_parent_ip+0x11/0x50 [<ffffffff81058f3d>] ? sub_preempt_count+0x9d/0xd0 [<ffffffff8170a26d>] ? _raw_spin_unlock_irqrestore+0x3d/0x80 [<ffffffff8104840e>] ? __wake_up+0x4e/0x70 [<ffffffff813e47b9>] ? put_ldisc+0x59/0xd0 [<ffffffff813e4839>] ? tty_ldisc_deref+0x9/0x10 [<ffffffff813def59>] ? tty_ioctl+0x299/0xa00 [<ffffffff81377214>] fb_ioctl+0x24/0x30 [<ffffffff81152ec7>] do_vfs_ioctl+0x87/0x330 [<ffffffff81140e85>] ? fget+0x95/0x240 [<ffffffff81140df0>] ? fget_raw+0x240/0x240 [<ffffffff811531ba>] sys_ioctl+0x4a/0x80 [<ffffffff8170adfb>] system_call_fastpath+0x16/0x1b Code: 48 8b 04 25 c8 b5 00 00 8b 80 44 e0 ff ff a9 00 ff ff 07 0f 85 d7 02 00 00 9c 41 5e fa e8 15 d2 98 ff 4c 8d 6b 08 b8 00 00 01 00 <f0> 0f c1 43 08 0f b7 d0 c1 e8 10 39 c2 74 08 f3 90 0f b7 53 08 RIP [<ffffffff81708394>] mutex_lock_nested+0x94/0x390 RSP <ffff88021ee77c08> CR2: 0000000000000010 ---[ end trace cdacd65f5f1b187d ]--- note: plymouthd[271] exited with preempt_count 1 -- Daniel J Blueman -- Daniel J Blueman ^ permalink raw reply [flat|nested] 15+ messages in thread
* [2.6.39-rc2, framebuffer] use after free oops @ 2011-04-20 5:50 ` Daniel J Blueman 0 siblings, 0 replies; 15+ messages in thread From: Daniel J Blueman @ 2011-04-20 5:50 UTC (permalink / raw) To: Paul Mundt, linux-fbdev, Linux Kernel Any ideas on how best to address this issue [0], since it causes silent corruption, or at best crashes? Thanks, Daniel --- [0] When building in the eg vga16 and intelfb framebuffers and page debugging, we can get hit by a use-after-free oops [1]; with page debugging disabled, this slips by unnoticed. When intelfb registers, the vga16 framebuffer is detected covering it's I/O regions, so it is removed (in remove_conflicting_framebuffers->unregister_framebuffer). The problem is the fb_info structure is freed (in unregister_framebuffer->vga16fb_destroy->framebuffer_release->kfree) before all open files to it are closed, so we get a use-after-free scenario. Freeing should be deferred until the last user has gone away. What approach would make sense here? Daniel --- [1] checking generic (a0000 10000) vs hw (d0000000 10000000) fb: conflicting fb hw usage inteldrmfb vs VGA16 VGA - removing generic driver Console: switching to colour VGA+ 80x25 BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 IP: [<ffffffff81708394>] mutex_lock_nested+0x94/0x390 PGD 2203ab067 PUD 2203ac067 PMD 0 Oops: 0002 [#2] PREEMPT SMP DEBUG_PAGEALLOC last sysfs file: /sys/devices/pci0000:00/0000:00:1b.0/sound/card0/uevent CPU 3 Modules linked in: arc4 ecb uvcvideo videodev v4l2_compat_ioctl32 i915(+) drm_kms_helper iwlagn mmc_block mac80211 drm video sdhci_pci sdhci mmc_core Pid: 271, comm: plymouthd Tainted: G D 2.6.39-rc2-350cd+ #1 Dell Inc. Latitude E5420/0H5TG2 RIP: 0010:[<ffffffff81708394>] [<ffffffff81708394>] mutex_lock_nested+0x94/0x390 RSP: 0018:ffff88021ee77c08 EFLAGS: 00010046 RAX: 0000000000010000 RBX: 0000000000000008 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffff8170838b RBP: ffff88021ee77c78 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff88021e574020 R13: 0000000000000010 R14: 0000000000000246 R15: ffff88021de6f478 FS: 00007f50d6e9c720(0000) GS:ffff88022ec60000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000010 CR3: 00000002203aa000 CR4: 00000000000406e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process plymouthd (pid: 271, threadinfo ffff88021ee76000, task ffff88021e574020) Stack: ffffffff81375552 0000000000000000 00000000fffffff2 ffff88021de6f478 ffff88021e574020 0000000000000246 0000000000000000 00000000fffffff2 ffff88021ee77c68 0000000000000000 0000000000000008 0000000000000000 Call Trace: [<ffffffff81375552>] ? lock_fb_info+0x22/0x60 [<ffffffff81375552>] lock_fb_info+0x22/0x60 [<ffffffff8137a24b>] fb_set_user_cmap+0x15b/0x1a0 [<ffffffff81376e28>] do_fb_ioctl+0x4b8/0x5e0 [<ffffffff81105dae>] ? might_fault+0x4e/0xa0 [<ffffffff81058e61>] ? get_parent_ip+0x11/0x50 [<ffffffff81058f3d>] ? sub_preempt_count+0x9d/0xd0 [<ffffffff8170a26d>] ? _raw_spin_unlock_irqrestore+0x3d/0x80 [<ffffffff8104840e>] ? __wake_up+0x4e/0x70 [<ffffffff813e47b9>] ? put_ldisc+0x59/0xd0 [<ffffffff813e4839>] ? tty_ldisc_deref+0x9/0x10 [<ffffffff813def59>] ? tty_ioctl+0x299/0xa00 [<ffffffff81377214>] fb_ioctl+0x24/0x30 [<ffffffff81152ec7>] do_vfs_ioctl+0x87/0x330 [<ffffffff81140e85>] ? fget+0x95/0x240 [<ffffffff81140df0>] ? fget_raw+0x240/0x240 [<ffffffff811531ba>] sys_ioctl+0x4a/0x80 [<ffffffff8170adfb>] system_call_fastpath+0x16/0x1b Code: 48 8b 04 25 c8 b5 00 00 8b 80 44 e0 ff ff a9 00 ff ff 07 0f 85 d7 02 00 00 9c 41 5e fa e8 15 d2 98 ff 4c 8d 6b 08 b8 00 00 01 00 <f0> 0f c1 43 08 0f b7 d0 c1 e8 10 39 c2 74 08 f3 90 0f b7 53 08 RIP [<ffffffff81708394>] mutex_lock_nested+0x94/0x390 RSP <ffff88021ee77c08> CR2: 0000000000000010 ---[ end trace cdacd65f5f1b187d ]--- note: plymouthd[271] exited with preempt_count 1 -- Daniel J Blueman -- Daniel J Blueman ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [2.6.39-rc2, framebuffer] use after free oops 2011-04-20 5:50 ` Daniel J Blueman @ 2011-04-20 6:05 ` Bruno Prémont -1 siblings, 0 replies; 15+ messages in thread From: Bruno Prémont @ 2011-04-20 6:05 UTC (permalink / raw) To: Daniel J Blueman; +Cc: Paul Mundt, linux-fbdev, Linux Kernel On Wed, 20 Apr 2011 13:50:10 Daniel J Blueman <daniel.blueman@gmail.com> wrote: > Any ideas on how best to address this issue [0], since it causes > silent corruption, or at best crashes? There is probably no easy short-term fix to this... The complex fix would be to implement some deferred free with driver-local ref-counting though to be complete it would have to be done for pretty much every FB driver! The mid-term fix would be to have fb_info ref-counted by FB subsystem (I'm working on it, slowly). This way freeing would be deferred to when last references is being dropped. The driver then just has to know when it can't touch underlying hardware anymore (and do the right thing with framebuffer memory in case it is still mmapped somewhere). Bruno > Thanks, > Daniel > > --- [0] > > When building in the eg vga16 and intelfb framebuffers and page > debugging, we can get hit by a use-after-free oops [1]; with page > debugging disabled, this slips by unnoticed. > > When intelfb registers, the vga16 framebuffer is detected covering > it's I/O regions, so it is removed (in > remove_conflicting_framebuffers->unregister_framebuffer). The problem > is the fb_info structure is freed (in > unregister_framebuffer->vga16fb_destroy->framebuffer_release->kfree) > before all open files to it are closed, so we get a use-after-free > scenario. > > Freeing should be deferred until the last user has gone away. What > approach would make sense here? > > Daniel > > --- [1] > > checking generic (a0000 10000) vs hw (d0000000 10000000) > fb: conflicting fb hw usage inteldrmfb vs VGA16 VGA - removing generic driver > Console: switching to colour VGA+ 80x25 > BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 > IP: [<ffffffff81708394>] mutex_lock_nested+0x94/0x390 > PGD 2203ab067 PUD 2203ac067 PMD 0 > Oops: 0002 [#2] PREEMPT SMP DEBUG_PAGEALLOC > last sysfs file: /sys/devices/pci0000:00/0000:00:1b.0/sound/card0/uevent > CPU 3 > Modules linked in: arc4 ecb uvcvideo videodev v4l2_compat_ioctl32 > i915(+) drm_kms_helper iwlagn mmc_block mac80211 drm video sdhci_pci > sdhci mmc_core > > Pid: 271, comm: plymouthd Tainted: G D 2.6.39-rc2-350cd+ #1 > Dell Inc. Latitude E5420/0H5TG2 > RIP: 0010:[<ffffffff81708394>] [<ffffffff81708394>] > mutex_lock_nested+0x94/0x390 > RSP: 0018:ffff88021ee77c08 EFLAGS: 00010046 > RAX: 0000000000010000 RBX: 0000000000000008 RCX: 0000000000000000 > RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffff8170838b > RBP: ffff88021ee77c78 R08: 0000000000000000 R09: 0000000000000000 > R10: 0000000000000000 R11: 0000000000000000 R12: ffff88021e574020 > R13: 0000000000000010 R14: 0000000000000246 R15: ffff88021de6f478 > FS: 00007f50d6e9c720(0000) GS:ffff88022ec60000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 0000000000000010 CR3: 00000002203aa000 CR4: 00000000000406e0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > Process plymouthd (pid: 271, threadinfo ffff88021ee76000, task ffff88021e574020) > Stack: > ffffffff81375552 0000000000000000 00000000fffffff2 ffff88021de6f478 > ffff88021e574020 0000000000000246 0000000000000000 00000000fffffff2 > ffff88021ee77c68 0000000000000000 0000000000000008 0000000000000000 > Call Trace: > [<ffffffff81375552>] ? lock_fb_info+0x22/0x60 > [<ffffffff81375552>] lock_fb_info+0x22/0x60 > [<ffffffff8137a24b>] fb_set_user_cmap+0x15b/0x1a0 > [<ffffffff81376e28>] do_fb_ioctl+0x4b8/0x5e0 > [<ffffffff81105dae>] ? might_fault+0x4e/0xa0 > [<ffffffff81058e61>] ? get_parent_ip+0x11/0x50 > [<ffffffff81058f3d>] ? sub_preempt_count+0x9d/0xd0 > [<ffffffff8170a26d>] ? _raw_spin_unlock_irqrestore+0x3d/0x80 > [<ffffffff8104840e>] ? __wake_up+0x4e/0x70 > [<ffffffff813e47b9>] ? put_ldisc+0x59/0xd0 > [<ffffffff813e4839>] ? tty_ldisc_deref+0x9/0x10 > [<ffffffff813def59>] ? tty_ioctl+0x299/0xa00 > [<ffffffff81377214>] fb_ioctl+0x24/0x30 > [<ffffffff81152ec7>] do_vfs_ioctl+0x87/0x330 > [<ffffffff81140e85>] ? fget+0x95/0x240 > [<ffffffff81140df0>] ? fget_raw+0x240/0x240 > [<ffffffff811531ba>] sys_ioctl+0x4a/0x80 > [<ffffffff8170adfb>] system_call_fastpath+0x16/0x1b > Code: 48 8b 04 25 c8 b5 00 00 8b 80 44 e0 ff ff a9 00 ff ff 07 0f 85 > d7 02 00 00 9c 41 5e fa e8 15 d2 98 ff 4c 8d 6b 08 b8 00 00 01 00 <f0> > 0f c1 43 08 0f b7 d0 c1 e8 10 39 c2 74 08 f3 90 0f b7 53 08 > RIP [<ffffffff81708394>] mutex_lock_nested+0x94/0x390 > RSP <ffff88021ee77c08> > CR2: 0000000000000010 > ---[ end trace cdacd65f5f1b187d ]--- > note: plymouthd[271] exited with preempt_count 1 > -- > Daniel J Blueman > > > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [2.6.39-rc2, framebuffer] use after free oops @ 2011-04-20 6:05 ` Bruno Prémont 0 siblings, 0 replies; 15+ messages in thread From: Bruno Prémont @ 2011-04-20 6:05 UTC (permalink / raw) To: Daniel J Blueman; +Cc: Paul Mundt, linux-fbdev, Linux Kernel On Wed, 20 Apr 2011 13:50:10 Daniel J Blueman <daniel.blueman@gmail.com> wrote: > Any ideas on how best to address this issue [0], since it causes > silent corruption, or at best crashes? There is probably no easy short-term fix to this... The complex fix would be to implement some deferred free with driver-local ref-counting though to be complete it would have to be done for pretty much every FB driver! The mid-term fix would be to have fb_info ref-counted by FB subsystem (I'm working on it, slowly). This way freeing would be deferred to when last references is being dropped. The driver then just has to know when it can't touch underlying hardware anymore (and do the right thing with framebuffer memory in case it is still mmapped somewhere). Bruno > Thanks, > Daniel > > --- [0] > > When building in the eg vga16 and intelfb framebuffers and page > debugging, we can get hit by a use-after-free oops [1]; with page > debugging disabled, this slips by unnoticed. > > When intelfb registers, the vga16 framebuffer is detected covering > it's I/O regions, so it is removed (in > remove_conflicting_framebuffers->unregister_framebuffer). The problem > is the fb_info structure is freed (in > unregister_framebuffer->vga16fb_destroy->framebuffer_release->kfree) > before all open files to it are closed, so we get a use-after-free > scenario. > > Freeing should be deferred until the last user has gone away. What > approach would make sense here? > > Daniel > > --- [1] > > checking generic (a0000 10000) vs hw (d0000000 10000000) > fb: conflicting fb hw usage inteldrmfb vs VGA16 VGA - removing generic driver > Console: switching to colour VGA+ 80x25 > BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 > IP: [<ffffffff81708394>] mutex_lock_nested+0x94/0x390 > PGD 2203ab067 PUD 2203ac067 PMD 0 > Oops: 0002 [#2] PREEMPT SMP DEBUG_PAGEALLOC > last sysfs file: /sys/devices/pci0000:00/0000:00:1b.0/sound/card0/uevent > CPU 3 > Modules linked in: arc4 ecb uvcvideo videodev v4l2_compat_ioctl32 > i915(+) drm_kms_helper iwlagn mmc_block mac80211 drm video sdhci_pci > sdhci mmc_core > > Pid: 271, comm: plymouthd Tainted: G D 2.6.39-rc2-350cd+ #1 > Dell Inc. Latitude E5420/0H5TG2 > RIP: 0010:[<ffffffff81708394>] [<ffffffff81708394>] > mutex_lock_nested+0x94/0x390 > RSP: 0018:ffff88021ee77c08 EFLAGS: 00010046 > RAX: 0000000000010000 RBX: 0000000000000008 RCX: 0000000000000000 > RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffff8170838b > RBP: ffff88021ee77c78 R08: 0000000000000000 R09: 0000000000000000 > R10: 0000000000000000 R11: 0000000000000000 R12: ffff88021e574020 > R13: 0000000000000010 R14: 0000000000000246 R15: ffff88021de6f478 > FS: 00007f50d6e9c720(0000) GS:ffff88022ec60000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 0000000000000010 CR3: 00000002203aa000 CR4: 00000000000406e0 > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > Process plymouthd (pid: 271, threadinfo ffff88021ee76000, task ffff88021e574020) > Stack: > ffffffff81375552 0000000000000000 00000000fffffff2 ffff88021de6f478 > ffff88021e574020 0000000000000246 0000000000000000 00000000fffffff2 > ffff88021ee77c68 0000000000000000 0000000000000008 0000000000000000 > Call Trace: > [<ffffffff81375552>] ? lock_fb_info+0x22/0x60 > [<ffffffff81375552>] lock_fb_info+0x22/0x60 > [<ffffffff8137a24b>] fb_set_user_cmap+0x15b/0x1a0 > [<ffffffff81376e28>] do_fb_ioctl+0x4b8/0x5e0 > [<ffffffff81105dae>] ? might_fault+0x4e/0xa0 > [<ffffffff81058e61>] ? get_parent_ip+0x11/0x50 > [<ffffffff81058f3d>] ? sub_preempt_count+0x9d/0xd0 > [<ffffffff8170a26d>] ? _raw_spin_unlock_irqrestore+0x3d/0x80 > [<ffffffff8104840e>] ? __wake_up+0x4e/0x70 > [<ffffffff813e47b9>] ? put_ldisc+0x59/0xd0 > [<ffffffff813e4839>] ? tty_ldisc_deref+0x9/0x10 > [<ffffffff813def59>] ? tty_ioctl+0x299/0xa00 > [<ffffffff81377214>] fb_ioctl+0x24/0x30 > [<ffffffff81152ec7>] do_vfs_ioctl+0x87/0x330 > [<ffffffff81140e85>] ? fget+0x95/0x240 > [<ffffffff81140df0>] ? fget_raw+0x240/0x240 > [<ffffffff811531ba>] sys_ioctl+0x4a/0x80 > [<ffffffff8170adfb>] system_call_fastpath+0x16/0x1b > Code: 48 8b 04 25 c8 b5 00 00 8b 80 44 e0 ff ff a9 00 ff ff 07 0f 85 > d7 02 00 00 9c 41 5e fa e8 15 d2 98 ff 4c 8d 6b 08 b8 00 00 01 00 <f0> > 0f c1 43 08 0f b7 d0 c1 e8 10 39 c2 74 08 f3 90 0f b7 53 08 > RIP [<ffffffff81708394>] mutex_lock_nested+0x94/0x390 > RSP <ffff88021ee77c08> > CR2: 0000000000000010 > ---[ end trace cdacd65f5f1b187d ]--- > note: plymouthd[271] exited with preempt_count 1 > -- > Daniel J Blueman > > > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [2.6.39-rc2, framebuffer] use after free oops 2011-04-20 6:05 ` Bruno Prémont @ 2011-04-20 9:56 ` Alan Cox -1 siblings, 0 replies; 15+ messages in thread From: Alan Cox @ 2011-04-20 9:56 UTC (permalink / raw) To: Bruno Prémont Cc: Daniel J Blueman, Paul Mundt, linux-fbdev, Linux Kernel On Wed, 20 Apr 2011 08:05:35 +0200 Bruno Prémont <bonbons@linux-vserver.org> wrote: > On Wed, 20 Apr 2011 13:50:10 Daniel J Blueman <daniel.blueman@gmail.com> wrote: > > Any ideas on how best to address this issue [0], since it causes > > silent corruption, or at best crashes? > > There is probably no easy short-term fix to this... The short term fix would be to deliberately leak the buffer. That should go into 2.6.39-rc right now with a comment explaining the situation. Otherwise who knows what corruption may occur to user data if unlucky. The other 'cheat' might be to tweak the API so the removal API isn't a 'destroy' interface but a 'shut down' and has a matching 'restart' one for when the intelfb unloads at which point vga16fb can carry on with the original fb_info 8) Alan ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [2.6.39-rc2, framebuffer] use after free oops @ 2011-04-20 9:56 ` Alan Cox 0 siblings, 0 replies; 15+ messages in thread From: Alan Cox @ 2011-04-20 9:56 UTC (permalink / raw) To: Bruno Prémont Cc: Daniel J Blueman, Paul Mundt, linux-fbdev, Linux Kernel On Wed, 20 Apr 2011 08:05:35 +0200 Bruno Prémont <bonbons@linux-vserver.org> wrote: > On Wed, 20 Apr 2011 13:50:10 Daniel J Blueman <daniel.blueman@gmail.com> wrote: > > Any ideas on how best to address this issue [0], since it causes > > silent corruption, or at best crashes? > > There is probably no easy short-term fix to this... The short term fix would be to deliberately leak the buffer. That should go into 2.6.39-rc right now with a comment explaining the situation. Otherwise who knows what corruption may occur to user data if unlucky. The other 'cheat' might be to tweak the API so the removal API isn't a 'destroy' interface but a 'shut down' and has a matching 'restart' one for when the intelfb unloads at which point vga16fb can carry on with the original fb_info 8) Alan ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [2.6.39-rc2, framebuffer] use after free oops 2011-04-20 9:56 ` Alan Cox @ 2011-05-06 2:38 ` Daniel J Blueman -1 siblings, 0 replies; 15+ messages in thread From: Daniel J Blueman @ 2011-05-06 2:38 UTC (permalink / raw) To: Alan Cox, Bruno Prémont, Paul Mundt, linux-fbdev, Linux Kernel On 20 April 2011 17:56, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote: > On Wed, 20 Apr 2011 08:05:35 +0200 > Bruno Prémont <bonbons@linux-vserver.org> wrote: > >> On Wed, 20 Apr 2011 13:50:10 Daniel J Blueman <daniel.blueman@gmail.com> wrote: >> > Any ideas on how best to address this issue [0], since it causes >> > silent corruption, or at best crashes? >> >> There is probably no easy short-term fix to this... > > The short term fix would be to deliberately leak the buffer. That should > go into 2.6.39-rc right now with a comment explaining the situation. > Otherwise who knows what corruption may occur to user data if unlucky. > > The other 'cheat' might be to tweak the API so the removal API isn't a > 'destroy' interface but a 'shut down' and has a matching 'restart' one > for when the intelfb unloads at which point vga16fb can carry on with the > original fb_info 8) It looks like Andy Whitcroft addressed this issue some time ago, but forgot to send the fix upstream: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-natty.git;a=patch;hÅa742b5f78e161d6a13853a7e3e6e1dfa429e69;hp&a1443f67eea17d4b78ef75df701782cc8bf35b Let's hope it can hit -rc7 since it's been in Ubuntu's kernel tree for considerable time, and fixes a silent corrupter: http://groups.google.com/group/linux.kernel/browse_thread/thread/fc9083f6f380ed5b/f801112b840785cb?show_docidø01112b840785cb Thanks, Daniel -- Daniel J Blueman ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [2.6.39-rc2, framebuffer] use after free oops @ 2011-05-06 2:38 ` Daniel J Blueman 0 siblings, 0 replies; 15+ messages in thread From: Daniel J Blueman @ 2011-05-06 2:38 UTC (permalink / raw) To: Alan Cox, Bruno Prémont, Paul Mundt, linux-fbdev, Linux Kernel On 20 April 2011 17:56, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote: > On Wed, 20 Apr 2011 08:05:35 +0200 > Bruno Prémont <bonbons@linux-vserver.org> wrote: > >> On Wed, 20 Apr 2011 13:50:10 Daniel J Blueman <daniel.blueman@gmail.com> wrote: >> > Any ideas on how best to address this issue [0], since it causes >> > silent corruption, or at best crashes? >> >> There is probably no easy short-term fix to this... > > The short term fix would be to deliberately leak the buffer. That should > go into 2.6.39-rc right now with a comment explaining the situation. > Otherwise who knows what corruption may occur to user data if unlucky. > > The other 'cheat' might be to tweak the API so the removal API isn't a > 'destroy' interface but a 'shut down' and has a matching 'restart' one > for when the intelfb unloads at which point vga16fb can carry on with the > original fb_info 8) It looks like Andy Whitcroft addressed this issue some time ago, but forgot to send the fix upstream: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-natty.git;a=patch;h=c5a742b5f78e161d6a13853a7e3e6e1dfa429e69;hp=26a1443f67eea17d4b78ef75df701782cc8bf35b Let's hope it can hit -rc7 since it's been in Ubuntu's kernel tree for considerable time, and fixes a silent corrupter: http://groups.google.com/group/linux.kernel/browse_thread/thread/fc9083f6f380ed5b/f801112b840785cb?show_docid=f801112b840785cb Thanks, Daniel -- Daniel J Blueman ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [2.6.39-rc2, framebuffer] use after free oops 2011-05-06 2:38 ` Daniel J Blueman @ 2011-05-07 15:24 ` Anca Emanuel -1 siblings, 0 replies; 15+ messages in thread From: Anca Emanuel @ 2011-05-07 15:24 UTC (permalink / raw) To: Daniel J Blueman Cc: Alan Cox, Bruno Prémont, Paul Mundt, linux-fbdev, Linux Kernel, Dave Airlie Hi, Daniel J Blueman. Did you test https://lkml.org/lkml/2011/5/5/208 ? And it works for you ? Then please reply with your error and an Tested-by. And CC: "Dave Airlie" <airlied@redhat.com> ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [2.6.39-rc2, framebuffer] use after free oops @ 2011-05-07 15:24 ` Anca Emanuel 0 siblings, 0 replies; 15+ messages in thread From: Anca Emanuel @ 2011-05-07 15:24 UTC (permalink / raw) To: Daniel J Blueman Cc: Alan Cox, Bruno Prémont, Paul Mundt, linux-fbdev, Linux Kernel, Dave Airlie Hi, Daniel J Blueman. Did you test https://lkml.org/lkml/2011/5/5/208 ? And it works for you ? Then please reply with your error and an Tested-by. And CC: "Dave Airlie" <airlied@redhat.com> ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [2.6.39-rc2, framebuffer] use after free oops 2011-05-07 15:24 ` Anca Emanuel @ 2011-05-08 11:25 ` Daniel J Blueman -1 siblings, 0 replies; 15+ messages in thread From: Daniel J Blueman @ 2011-05-08 11:25 UTC (permalink / raw) To: linux-fbdev, Linux Kernel, Dave Airlie, Paul Mundt Cc: Alan Cox, Bruno Prémont, Anca Emanuel On 7 May 2011 23:24, Anca Emanuel <anca.emanuel@gmail.com> wrote: > Hi, Daniel J Blueman. > > Did you test https://lkml.org/lkml/2011/5/5/208 ? And it works for you ? > Then please reply with your error and an Tested-by. > > And CC: "Dave Airlie" <airlied@redhat.com> Tested against 2.6.39-rc6. Instrumentation and debug catches the (silent without debug) use-after-free case, which now doesn't show up with this patch, so looks good. Probably good sense to get into -stable too. Tested-by: Daniel J Blueman <daniel.blueman@gmail.com> Thanks, Daniel -- Daniel J Blueman ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [2.6.39-rc2, framebuffer] use after free oops @ 2011-05-08 11:25 ` Daniel J Blueman 0 siblings, 0 replies; 15+ messages in thread From: Daniel J Blueman @ 2011-05-08 11:25 UTC (permalink / raw) To: linux-fbdev, Linux Kernel, Dave Airlie, Paul Mundt Cc: Alan Cox, Bruno Prémont, Anca Emanuel On 7 May 2011 23:24, Anca Emanuel <anca.emanuel@gmail.com> wrote: > Hi, Daniel J Blueman. > > Did you test https://lkml.org/lkml/2011/5/5/208 ? And it works for you ? > Then please reply with your error and an Tested-by. > > And CC: "Dave Airlie" <airlied@redhat.com> Tested against 2.6.39-rc6. Instrumentation and debug catches the (silent without debug) use-after-free case, which now doesn't show up with this patch, so looks good. Probably good sense to get into -stable too. Tested-by: Daniel J Blueman <daniel.blueman@gmail.com> Thanks, Daniel -- Daniel J Blueman ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <BANLkTikpswH4cyCVx7h74ttcivdnXZQrUg@mail.gmail.com>]
[parent not found: <20110510105001.401d0f66@lxorguk.ukuu.org.uk>]
[parent not found: <BANLkTikVSGUs=S3=1nR9gwr4iuAsWM9FuQ@mail.gmail.com>]
[parent not found: <BANLkTim49ZU06Upg77-hOzc60tGEYO80wg@mail.gmail.com>]
[parent not found: <4DCA8717.5050808@canonical.com>]
[parent not found: <20110511140213.73fe6d49@lxorguk.ukuu.org.uk>]
[parent not found: <BANLkTinDYcB6xSmPeRtPQcKERxxZaGk=4Q@mail.gmail.com>]
* Re: [2.6.39-rc2, framebuffer] use after free oops [not found] ` <BANLkTinDYcB6xSmPeRtPQcKERxxZaGk=4Q@mail.gmail.com> @ 2011-05-11 17:04 ` Anca Emanuel 0 siblings, 0 replies; 15+ messages in thread From: Anca Emanuel @ 2011-05-11 17:04 UTC (permalink / raw) To: Linus Torvalds Cc: Alan Cox, Tim Gardner, Daniel J Blueman, Paul Mundt, Dave Airlie, Bruno Prémont, Andy Whitcroft, LKML On Wed, May 11, 2011 at 7:17 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Wed, May 11, 2011 at 6:02 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote: >> >> We need some kind of patch for this release, even one where we leak the >> memory to avoid the scribbles. Random scribbling into freed memory could >> hit anything including user data or file system meta data - not good. > > Yeah. > > I looked at just not freeing things, but that ends up being ugly, > because the actual low-level allocation is being done by the > framebuffer driver itself (and it gets freed in fb_destroy). Now, it's > all supposed to use "framebuffer_release()", and maybe they all even > do, but it just made me worry. > > So I ended up looking at just the refcount thing. > > This is my trial. It should get the /proc locking right too. But it is > *ENTIRELY* untested. I looked at the Ubuntu patch, but that one mixed > up the refcounting with some other issues. I'm sure they are perfectly > valid fixes too, and should probably be done, but they are also an > unrelated thing. And the patch from Ubuntu seems to leave the /proc > accesses unprotected. > > The one registered_fb[] access (well, at least in fbmem.c) I didn't > fix is FBIOPUT_CON2FBMAP, which the Ubuntu patch didn't fix either. It > would be easy to lock the accesses there, but I don't know what the > f*ck the code wants to do (it only looks at the entry, but it actually > *uses* the 'info' that was passed in), so I just passed on that as > "insane code that makes no sense". > > The "remove_conflicting_framebuffers()" function should be locked too, > but I didn't bother, because it would mean splitting > unregister_framebuffer() into some helper functions. So that's a > "fixme later". > > Whatever. The patch looks sane. > > So *if* this works, I think it's better. I did actually go through the > patches side-by-side, and they end up very similar (apart from where > they aren't - the unrelated fb locking changes, and the fact that my > registration lock is much bigger and covers more). Which is > understandable, the way I did it was look for accesses to > "registered_fb[]", and I assume that is what Andy did too. > > Testing? I obviously don't see the problem in the first place, so.. > > Linus > With 2.6.39-rc7 I get [ 19.420036] BUG: unable to handle kernel NULL pointer dereference at (null) [ 19.420063] IP: [<ffffffff815a9d3a>] __mutex_lock_slowpath+0xca/0x180 [ 19.420077] PGD 7bbfc067 PUD 7bbfd067 PMD 0 [ 19.420089] Oops: 0002 [#1] SMP [ 19.420097] last sysfs file: /sys/devices/virtual/vtconsole/vtcon1/uevent [ 19.420107] CPU 1 [ 19.420111] Modules linked in: parport_pc ppdev snd_hda_codec_realtek snd_hda_intel snd_hda_codec adt7475 hwmon_vid snd_hwdep snd_pcm snd_seq_midi snd_rawmidi nouveau ttm drm_kms_helper snd_seq_midi_event drm i2c_algo_bit snd_seq snd_timer snd_seq_device psmouse snd serio_raw soundcore video snd_page_alloc intel_agp intel_gtt lp parport r8169 pata_marvell ahci mii libahci btrfs zlib_deflate crc32c libcrc32c [ 19.420211] [ 19.420216] Pid: 268, comm: plymouthd Not tainted 2.6.39-rc7 #1 MICRO-STAR INTERNATIONAL CO.,LTD MS-7360/MS-7360 [ 19.420231] RIP: 0010:[<ffffffff815a9d3a>] [<ffffffff815a9d3a>] __mutex_lock_slowpath+0xca/0x180 [ 19.420244] RSP: 0018:ffff880036ef1e28 EFLAGS: 00010246 [ 19.420251] RAX: 0000000000000000 RBX: ffff88007f817008 RCX: 0000000000000001 [ 19.420260] RDX: ffff880036ef1e38 RSI: ffff88006dd87600 RDI: ffff88007f81700c [ 19.420269] RBP: ffff880036ef1e88 R08: 00000000ffffffff R09: 0000000000000000 [ 19.420279] R10: ffff88006dd87610 R11: 0000000000000246 R12: ffff8800369dc440 [ 19.420404] R13: ffff88007f81700c R14: 00000000ffffffff R15: ffff88007f817010 [ 19.420414] FS: 00007f9f557b6720(0000) GS:ffff88007fc80000(0000) knlGS:0000000000000000 [ 19.420424] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 19.420432] CR2: 0000000000000000 CR3: 000000007bbfb000 CR4: 00000000000006e0 [ 19.420441] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 19.420450] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 19.420460] Process plymouthd (pid: 268, threadinfo ffff880036ef0000, task ffff8800369dc440) [ 19.420469] Stack: [ 19.420473] ffff880036ef1e78 ffff880036ef0000 ffff88007f817010 0000000000000000 [ 19.420487] ffff880036ef1e58 0000000000000000 ffff88006dd87610 ffff88007f817008 [ 19.420503] ffff88007f817008 ffff88007d3d9480 ffff88007be34d90 ffff88007be34d90 [ 19.420518] Call Trace: [ 19.420525] [<ffffffff815a97bb>] mutex_lock+0x2b/0x50 [ 19.420535] [<ffffffff8130acc9>] fb_release+0x29/0x70 [ 19.420545] [<ffffffff8115d04a>] fput+0xea/0x220 [ 19.420553] [<ffffffff81159296>] filp_close+0x66/0x90 [ 19.420561] [<ffffffff81159867>] sys_close+0xb7/0x120 [ 19.420569] [<ffffffff815b30c2>] system_call_fastpath+0x16/0x1b [ 19.420576] Code: 90 4c 8d 6b 04 4c 8d 7b 08 41 be ff ff ff ff 4c 89 ef e8 5a 13 00 00 48 8b 43 10 48 8d 55 b0 4c 89 7d b0 48 89 53 10 48 89 45 b8 [ 19.420658] 89 10 44 89 f0 4c 89 65 c0 87 03 83 f8 01 75 24 eb 2c 0f 1f [ 19.420698] RIP [<ffffffff815a9d3a>] __mutex_lock_slowpath+0xca/0x180 [ 19.420709] RSP <ffff880036ef1e28> [ 19.420714] CR2: 0000000000000000 [ 19.501432] r8169 0000:04:00.0: eth0: link up [ 19.501773] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 21.049817] [drm] nouveau 0000:01:00.0: EvoCh 2 Mthd 0x0080 Data 0x00000000 (0x000b 0x05) [ 21.053688] ---[ end trace 15bf5450f28092e3 ]--- Full dmesg at: http://pastebin.com/BTzX30be After your patch: I get an hard freeze. I can only get a photo If you are interested. ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2011-05-11 17:04 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-04-10 11:10 [2.6.39-rc2, framebuffer] use after free oops Daniel J Blueman
2011-04-10 11:10 ` Daniel J Blueman
2011-04-20 5:50 ` Daniel J Blueman
2011-04-20 5:50 ` Daniel J Blueman
2011-04-20 6:05 ` Bruno Prémont
2011-04-20 6:05 ` Bruno Prémont
2011-04-20 9:56 ` Alan Cox
2011-04-20 9:56 ` Alan Cox
2011-05-06 2:38 ` Daniel J Blueman
2011-05-06 2:38 ` Daniel J Blueman
2011-05-07 15:24 ` Anca Emanuel
2011-05-07 15:24 ` Anca Emanuel
2011-05-08 11:25 ` Daniel J Blueman
2011-05-08 11:25 ` Daniel J Blueman
[not found] ` <BANLkTikpswH4cyCVx7h74ttcivdnXZQrUg@mail.gmail.com>
[not found] ` <20110510105001.401d0f66@lxorguk.ukuu.org.uk>
[not found] ` <BANLkTikVSGUs=S3=1nR9gwr4iuAsWM9FuQ@mail.gmail.com>
[not found] ` <BANLkTim49ZU06Upg77-hOzc60tGEYO80wg@mail.gmail.com>
[not found] ` <4DCA8717.5050808@canonical.com>
[not found] ` <20110511140213.73fe6d49@lxorguk.ukuu.org.uk>
[not found] ` <BANLkTinDYcB6xSmPeRtPQcKERxxZaGk=4Q@mail.gmail.com>
2011-05-11 17:04 ` Anca Emanuel
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.