From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.1 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D41C9C432C0 for ; Tue, 3 Dec 2019 11:25:05 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 373EF20675 for ; Tue, 3 Dec 2019 11:25:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=hartkopp.net header.i=@hartkopp.net header.b="NYxaSYQQ" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725838AbfLCLZE (ORCPT ); Tue, 3 Dec 2019 06:25:04 -0500 Received: from mo4-p01-ob.smtp.rzone.de ([85.215.255.53]:14188 "EHLO mo4-p01-ob.smtp.rzone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725773AbfLCLZE (ORCPT ); Tue, 3 Dec 2019 06:25:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1575372301; s=strato-dkim-0002; d=hartkopp.net; h=In-Reply-To:Date:Message-ID:From:References:Cc:To:Subject: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=DT5bOPSQH9YmwYqotvzL5p/QFLJOi7z9Q5ao2GvtC/w=; b=NYxaSYQQ/HFVazp/ZlO8YuR8Q3jhV0GK3CqGKj7CfQubbX9kNbWgbP0dqYGmdBpRIx v44ctUhqbYjIDWVrJttB9XoRp12BTetLLYQDSqEHdKP9aENqwG073ucDoEeWsqS55zvK M+1zFfz1g2lTkn+XmRyeKHIsl1L+XLHVf9r6wEykZgBJQfjxABifj2/5SOO+eiqaxj8X uyVmlCpiW+dwvtmJ+S3m1Rr/HCJ5z5Iz/g0+XQPmvFte+TMhzEbPvhYeFIGjnYURQ+an lvMKiC/jHdeDa2jEv+U3o+SEowDjeybTniZJx39vvgAbUbJn113kH9jeDxCGlC2ohDec t9tg== X-RZG-AUTH: ":P2MHfkW8eP4Mre39l357AZT/I7AY/7nT2yrDxb8mjG14FZxedJy6qgO1q3jXdVqE32oRVrGn+26OxA==" X-RZG-CLASS-ID: mo00 Received: from [10.180.55.161] by smtp.strato.de (RZmta 46.0.2 SBL|AUTH) with ESMTPSA id 90101evB3BLu3RS (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Tue, 3 Dec 2019 12:21:56 +0100 (CET) Subject: Re: [PATCH 3/6] can: slcan: Fix use-after-free Read in slcan_open To: Marc Kleine-Budde , netdev@vger.kernel.org Cc: davem@davemloft.net, linux-can@vger.kernel.org, kernel@pengutronix.de, Jouni Hogander , Wolfgang Grandegger , Lukas Bulwahn , linux-stable References: <20191203104703.14620-1-mkl@pengutronix.de> <20191203104703.14620-4-mkl@pengutronix.de> From: Oliver Hartkopp Message-ID: Date: Tue, 3 Dec 2019 12:21:56 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <20191203104703.14620-4-mkl@pengutronix.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On 03/12/2019 11.47, Marc Kleine-Budde wrote: > From: Jouni Hogander > > Slcan_open doesn't clean-up device which registration failed from the > slcan_devs device list. On next open this list is iterated and freed > device is accessed. Fix this by calling slc_free_netdev in error path. > > Driver/net/can/slcan.c is derived from slip.c. Use-after-free error was > identified in slip_open by syzboz. Same bug is in slcan.c. Here is the > trace from the Syzbot slip report: > > __dump_stack lib/dump_stack.c:77 [inline] > dump_stack+0x197/0x210 lib/dump_stack.c:118 > print_address_description.constprop.0.cold+0xd4/0x30b mm/kasan/report.c:374 > __kasan_report.cold+0x1b/0x41 mm/kasan/report.c:506 > kasan_report+0x12/0x20 mm/kasan/common.c:634 > __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132 > sl_sync drivers/net/slip/slip.c:725 [inline] > slip_open+0xecd/0x11b7 drivers/net/slip/slip.c:801 > tty_ldisc_open.isra.0+0xa3/0x110 drivers/tty/tty_ldisc.c:469 > tty_set_ldisc+0x30e/0x6b0 drivers/tty/tty_ldisc.c:596 > tiocsetd drivers/tty/tty_io.c:2334 [inline] > tty_ioctl+0xe8d/0x14f0 drivers/tty/tty_io.c:2594 > vfs_ioctl fs/ioctl.c:46 [inline] > file_ioctl fs/ioctl.c:509 [inline] > do_vfs_ioctl+0xdb6/0x13e0 fs/ioctl.c:696 > ksys_ioctl+0xab/0xd0 fs/ioctl.c:713 > __do_sys_ioctl fs/ioctl.c:720 [inline] > __se_sys_ioctl fs/ioctl.c:718 [inline] > __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718 > do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > > Fixes: ed50e1600b44 ("slcan: Fix memory leak in error path") > Cc: Wolfgang Grandegger > Cc: Marc Kleine-Budde > Cc: David Miller > Cc: Oliver Hartkopp > Cc: Lukas Bulwahn > Signed-off-by: Jouni Hogander > Cc: linux-stable # >= v5.4 I think this problem existed from the initial commit in 2010 and is not restricted to >= v5.4 Together with commit commit ed50e1600b4483c049 ("slcan: Fix memory leak in error path") from Jouni Hogander. Regards, Oliver > Acked-by: Oliver Hartkopp > Signed-off-by: Marc Kleine-Budde > --- > drivers/net/can/slcan.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/net/can/slcan.c b/drivers/net/can/slcan.c > index 0a9f42e5fedf..2e57122f02fb 100644 > --- a/drivers/net/can/slcan.c > +++ b/drivers/net/can/slcan.c > @@ -617,6 +617,7 @@ static int slcan_open(struct tty_struct *tty) > sl->tty = NULL; > tty->disc_data = NULL; > clear_bit(SLF_INUSE, &sl->flags); > + slc_free_netdev(sl->dev); > free_netdev(sl->dev); > > err_exit: >