Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751906AbbK1BUc (ORCPT ); Fri, 27 Nov 2015 20:20:32 -0500 Received: from mail-ig0-f176.google.com ([209.85.213.176]:37966 "EHLO mail-ig0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751500AbbK1BU3 (ORCPT ); Fri, 27 Nov 2015 20:20:29 -0500 Subject: Re: gigaset: freeing an active object To: Paul Bolle , Sasha Levin References: <56587467.8050102@oracle.com> <1448647077.6523.33.camel@tiscali.nl> <56589DD9.2060508@oracle.com> <1448670517.6523.67.camel@tiscali.nl> Cc: isdn@linux-pingi.de, davem@davemloft.net, tilman@imap.cc, gigaset307x-common@lists.sourceforge.net, LKML , "netdev@vger.kernel.org" , syzkaller From: Peter Hurley Message-ID: <56590159.4080404@hurleysoftware.com> Date: Fri, 27 Nov 2015 20:20:25 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <1448670517.6523.67.camel@tiscali.nl> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4911 Lines: 122 On 11/27/2015 07:28 PM, Paul Bolle wrote: > (A few quick notes follow. The hope here is basically that my display of > ignorance might trigger others to speak up while I'm still pondering on > this bug.) > > On vr, 2015-11-27 at 13:15 -0500, Sasha Levin wrote: >> On 11/27/2015 12:57 PM, Paul Bolle wrote: >>> On vr, 2015-11-27 at 10:19 -0500, Sasha Levin wrote: >>>> Fuzzing with syzkaller on the latest -next kernel produced this >>>> error: >>> >>> (syzkaller is new to me. I'll have to do some web searches.) >> >> It's a new fancy syscall/ioctl fuzzer, >> https://github.com/google/syzkaller/blob/master/README.md > > Thanks. > > That fuzzer apparently requires either CONFIG_KASAN, CONFIG_KTSAN, or > CONFIG_UBSAN, none of which I'm familiar with. > >>>> [ 413.536749] WARNING: CPU: 6 PID: 25400 at >>>> lib/debugobjects.c:263 >>>> debug_print_object+0x1c4/0x1e0() >>>> [ 413.538111] ODEBUG: free active (active state 0) object type: >>>> timer_list hint: delayed_work_timer_fn+0x0/0x90 > > There are two places that add "free" here, but there's no obvious way to > distinguish between them. Annoying. > > Anyhow, this is interesting. ser-gigaset doesn't use timer_list while > bas-gigaset does. > >>>> [ 413.539598] Modules linked >>>> in:3470693efef57268844f02f5de3ab392d8cf5e209671ddd87163cb964c51065 >>>> 9 > > Not sure what this means. The bug concerns ser-gigaset so it's safe to > assume the fuzzer at one point called > ioctl(fd, TIOCSETD, N_GIGASET_M101) Sasha, It would really help if you included the syzkaller-generated applet with the bug reports; state previously established by the applet can be crucial in understanding why the call stack looks the way it does. Also, every generated applet that triggers a report should become a future regression test; I'm collecting the ones pertinent to tty/serial/ ldisc (so that includes this one; if you could send me the x25 one too would be great). Regards, Peter Hurley > which would trigger the use of ser-gigaset. > >>>> [ 413.540448] CPU: 6 PID: 25400 Comm: syzkaller_execu Not tainted >>>> 4.4.0-rc2-next-20151126-sasha-00005-g00d303e-dirty #2653 >>>> [ 413.547614] Call Trace: >>>> [ 413.548077] [] dump_stack+0x72/0xb7 >>>> [ 413.548765] [] >>>> warn_slowpath_common+0x113/0x140 >>>> [ 413.551151] [] warn_slowpath_fmt+0xcb/0x100 >>>> [ 413.554295] [] >>>> debug_print_object+0x1c4/0x1e0 >>>> [ 413.556592] [] >>>> __debug_check_no_obj_freed+0x215/0x7a0 >>>> [ 413.560526] [] >>>> debug_check_no_obj_freed+0x2c/0x40 >>>> [ 413.561328] [] kfree+0x1fc/0x2f0 > > This should be > kfree(cs->hw.ser) > > Note that cs->hw is a union of struct base_cardstate, struct > ser_cardstate, and struct usb_cardstate. And it's obvious that struct > ser_cardstate is much smaller that struct bas_cardstate. So we're > probably free-ing some memory that, so to speak, includes > bas_cardstate.timer_int_in, a struct timer_list. That's likely way > beyond the end of struct ser_cardstate and so it should still contain > garbage. > >>>> [ 413.561970] [] gigaset_freecshw+0xe1/0x120 >>>> [ 413.562723] [] gigaset_freecs+0x2ad/0x600 >>>> [ 413.564240] [] gigaset_tty_close+0x210/0x280 >>>> [ 413.565774] [] >>>> tty_ldisc_close.isra.1+0xc2/0xd0 >>>> [ 413.566550] [] tty_ldisc_kill+0x4b/0x170 >>>> [ 413.567253] [] tty_ldisc_release+0x183/0x240 >>>> [ 413.568000] [] tty_release+0xd1c/0xe80 >>>> [ 413.570176] [] __fput+0x32a/0x680 >>>> [ 413.570888] [] ____fput+0x1a/0x20 >>>> [ 413.571565] [] task_work_run+0x19c/0x1e0 >>>> [ 413.572290] [] do_exit+0xdf7/0x28f0 >>>> [ 413.576188] [] do_group_exit+0x1b5/0x300 >>>> [ 413.576905] [] get_signal+0x1182/0x1360 >>>> [ 413.577627] [] do_signal+0x93/0x1690 >>>> [ 413.584630] [] >>>> exit_to_usermode_loop+0xc0/0x1e0 >>>> [ 413.585412] [] >>>> prepare_exit_to_usermode+0x10b/0x140 >>>> [ 413.586187] [] retint_user+0x8/0x23 >>> > > I have no idea (yet) what triggers retint_user. > > Anyhow, my first hunch is to do a s/kmalloc/kzalloc/ on > drv->cs = kmalloc(minors * sizeof *drv->cs, GFP_KERNEL) > > in drivers/isdn/gigaset/common.c and see if this still triggers. But to > test that I need to know how to reproduce this. > > To be continued... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/