2019-01-08 13:40:43

by Kyungtae Kim

[permalink] [raw]
Subject: general protection fault in spk_ttyio_ldisc_close

We report a bug in linux-4.20: "general protection fault in
spk_ttyio_ldisc_close"

kernel config: https://kt0755.github.io/etc/config_v4.20_stable
repro: https://kt0755.github.io/etc/repro.a670e.c

This occurs when the function kfree is about to execute
(driver/staging/speakup/spk_ttyio.c:68).
Particularly, kfree takes the argument like speakup_tty->disc_data.
But speakup_tty is invalid, so the pointer dereference causes GPF.
At a glance, it seems that speakup_tty was deallocated somewhere ahead of kfree.

=========================================
general protection fault: 0000 [#1] PREEMPT SMP KASAN PTI
CPU: 0 PID: 13246 Comm: syz-executor7 Not tainted 4.20.0-rc2 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
RIP: 0010:spk_ttyio_ldisc_close+0x3f/0x80 drivers/staging/speakup/spk_ttyio.c:68
Code: 35 95 8c e8 43 03 60 01 48 8b 1d dc 2e 3f 07 48 ba 00 00 00 00
00 fc ff df 48 8d bb 70 05 00 00 48 89 f8 48 c1 e8 03 48 01 d0 <80> 38
00 75 26 48 8b bb 70 05 00 00 e8 a0 68 4f fa 48 c7 c7 c0 35
RSP: 0018:ffff88810e6f7960 EFLAGS: 00010282
RAX: dffffc00000000ae RBX: 0000000000000000 RCX: 1ffff11021cdef00
RDX: dffffc0000000000 RSI: 0000000000000008 RDI: 0000000000000570
RBP: ffff88810e6f7968 R08: fffffbfff192a6b9 R09: fffffbfff192a6b9
R10: ffff88810e6f7950 R11: fffffbfff192a6b8 R12: ffff8881063ee6b0
R13: ffffffff87471020 R14: ffff8881063eeea8 R15: ffff888116ec7b80
FS: 00007f607f746700(0000) GS:ffff88811a000000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000006fb2e0 CR3: 000000010f186000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
tty_ldisc_close drivers/tty/tty_ldisc.c:477 [inline]
tty_ldisc_kill+0xef/0x1a0 drivers/tty/tty_ldisc.c:623
tty_ldisc_release+0x111/0x230 drivers/tty/tty_ldisc.c:790
tty_release_struct+0x1f/0x60 drivers/tty/tty_io.c:1595
tty_release+0xb80/0x11c0 drivers/tty/tty_io.c:1768
__fput+0x2b8/0x7a0 fs/file_table.c:278
____fput+0x1a/0x20 fs/file_table.c:309
task_work_run+0x15b/0x1e0 kernel/task_work.c:113
exit_task_work include/linux/task_work.h:22 [inline]
do_exit+0x8d6/0x30d0 kernel/exit.c:867
do_group_exit+0x13d/0x370 kernel/exit.c:970
get_signal+0x6bb/0x1890 kernel/signal.c:2517
do_signal+0x8c/0x1a10 arch/x86/kernel/signal.c:816
exit_to_usermode_loop+0x186/0x1d0 arch/x86/entry/common.c:162
prepare_exit_to_usermode arch/x86/entry/common.c:197 [inline]
syscall_return_slowpath arch/x86/entry/common.c:268 [inline]
do_syscall_64+0x445/0x4f0 arch/x86/entry/common.c:293
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4497b9
Code: e8 8c 9f 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48
89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d
01 f0 ff ff 0f 83 9b 6b fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f607f745ce8 EFLAGS: 00000246 ORIG_RAX: 00000000000000ca
RAX: fffffffffffffe00 RBX: 000000000071bf80 RCX: 00000000004497b9
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000000071bf80
RBP: 000000000071bf80 R08: 0000000000000000 R09: 000000000071bf58
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000000 R14: 00007f607f7469c0 R15: 00007f607f746700
Modules linked in:
Dumping ftrace buffer:
(ftrace buffer empty)
=========================================

Thanks,
Kyungtae Kim


2019-01-08 13:51:48

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: general protection fault in spk_ttyio_ldisc_close

On Tue, Jan 08, 2019 at 08:37:37AM -0500, Kyungtae Kim wrote:
> We report a bug in linux-4.20: "general protection fault in
> spk_ttyio_ldisc_close"
>
> kernel config: https://kt0755.github.io/etc/config_v4.20_stable
> repro: https://kt0755.github.io/etc/repro.a670e.c
>
> This occurs when the function kfree is about to execute
> (driver/staging/speakup/spk_ttyio.c:68).
> Particularly, kfree takes the argument like speakup_tty->disc_data.
> But speakup_tty is invalid, so the pointer dereference causes GPF.
> At a glance, it seems that speakup_tty was deallocated somewhere ahead of kfree.

How did you trigger this? Did you shut down and close the device
already somehow? Do you have a real tty device that is driven by the
device?

thanks,

greg k-h

2019-01-08 14:16:37

by Kyungtae Kim

[permalink] [raw]
Subject: Re: general protection fault in spk_ttyio_ldisc_close

On Tue, Jan 8, 2019 at 8:50 AM Greg KH <[email protected]> wrote:
>
> On Tue, Jan 08, 2019 at 08:37:37AM -0500, Kyungtae Kim wrote:
> > We report a bug in linux-4.20: "general protection fault in
> > spk_ttyio_ldisc_close"
> >
> > kernel config: https://kt0755.github.io/etc/config_v4.20_stable
> > repro: https://kt0755.github.io/etc/repro.a670e.c
> >
> > This occurs when the function kfree is about to execute
> > (driver/staging/speakup/spk_ttyio.c:68).
> > Particularly, kfree takes the argument like speakup_tty->disc_data.
> > But speakup_tty is invalid, so the pointer dereference causes GPF.
> > At a glance, it seems that speakup_tty was deallocated somewhere ahead of kfree.
>
> How did you trigger this? Did you shut down and close the device
> already somehow? Do you have a real tty device that is driven by the
> device?
>
> thanks,
>
> greg k-h

For this crash, we did without real speakup tty device.
I'm currently trying to figure out how this actually happens.

Thanks,
Kyungtae Kim

2019-01-08 14:27:41

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: general protection fault in spk_ttyio_ldisc_close

On Tue, Jan 08, 2019 at 09:15:02AM -0500, Kyungtae Kim wrote:
> On Tue, Jan 8, 2019 at 8:50 AM Greg KH <[email protected]> wrote:
> >
> > On Tue, Jan 08, 2019 at 08:37:37AM -0500, Kyungtae Kim wrote:
> > > We report a bug in linux-4.20: "general protection fault in
> > > spk_ttyio_ldisc_close"
> > >
> > > kernel config: https://kt0755.github.io/etc/config_v4.20_stable
> > > repro: https://kt0755.github.io/etc/repro.a670e.c
> > >
> > > This occurs when the function kfree is about to execute
> > > (driver/staging/speakup/spk_ttyio.c:68).
> > > Particularly, kfree takes the argument like speakup_tty->disc_data.
> > > But speakup_tty is invalid, so the pointer dereference causes GPF.
> > > At a glance, it seems that speakup_tty was deallocated somewhere ahead of kfree.
> >
> > How did you trigger this? Did you shut down and close the device
> > already somehow? Do you have a real tty device that is driven by the
> > device?
> >
> > thanks,
> >
> > greg k-h
>
> For this crash, we did without real speakup tty device.

How did you bind a non-real speakup tty device to the driver?

> I'm currently trying to figure out how this actually happens.

That would be great to figure out :)

thanks,

greg k-h

2019-01-08 14:29:07

by Samuel Thibault

[permalink] [raw]
Subject: Re: general protection fault in spk_ttyio_ldisc_close

Greg KH, le mar. 08 janv. 2019 15:25:07 +0100, a ecrit:
> On Tue, Jan 08, 2019 at 09:15:02AM -0500, Kyungtae Kim wrote:
> > On Tue, Jan 8, 2019 at 8:50 AM Greg KH <[email protected]> wrote:
> > >
> > > On Tue, Jan 08, 2019 at 08:37:37AM -0500, Kyungtae Kim wrote:
> > > > We report a bug in linux-4.20: "general protection fault in
> > > > spk_ttyio_ldisc_close"
> > > >
> > > > kernel config: https://kt0755.github.io/etc/config_v4.20_stable
> > > > repro: https://kt0755.github.io/etc/repro.a670e.c
> > > >
> > > > This occurs when the function kfree is about to execute
> > > > (driver/staging/speakup/spk_ttyio.c:68).
> > > > Particularly, kfree takes the argument like speakup_tty->disc_data.
> > > > But speakup_tty is invalid, so the pointer dereference causes GPF.
> > > > At a glance, it seems that speakup_tty was deallocated somewhere ahead of kfree.
> > >
> > > How did you trigger this? Did you shut down and close the device
> > > already somehow? Do you have a real tty device that is driven by the
> > > device?
> > >
> > > thanks,
> > >
> > > greg k-h
> >
> > For this crash, we did without real speakup tty device.
>
> How did you bind a non-real speakup tty device to the driver?

One can tell any device name to the driver and it will attempt to
communicate with it.

Samuel