From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751677AbbK1A2o (ORCPT ); Fri, 27 Nov 2015 19:28:44 -0500 Received: from lb2-smtp-cloud2.xs4all.net ([194.109.24.25]:57181 "EHLO lb2-smtp-cloud2.xs4all.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751479AbbK1A2l (ORCPT ); Fri, 27 Nov 2015 19:28:41 -0500 Message-ID: <1448670517.6523.67.camel@tiscali.nl> Subject: Re: gigaset: freeing an active object From: Paul Bolle To: Sasha Levin Cc: isdn@linux-pingi.de, davem@davemloft.net, tilman@imap.cc, gigaset307x-common@lists.sourceforge.net, LKML , "netdev@vger.kernel.org" , syzkaller Date: Sat, 28 Nov 2015 01:28:37 +0100 In-Reply-To: <56589DD9.2060508@oracle.com> References: <56587467.8050102@oracle.com> <1448647077.6523.33.camel@tiscali.nl> <56589DD9.2060508@oracle.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.16.5 (3.16.5-3.fc22) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org (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) 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... Paul Bolle