From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755671AbbLDQrz (ORCPT ); Fri, 4 Dec 2015 11:47:55 -0500 Received: from prod-mail-xrelay07.akamai.com ([23.79.238.175]:15630 "EHLO prod-mail-xrelay07.akamai.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753866AbbLDQrx (ORCPT ); Fri, 4 Dec 2015 11:47:53 -0500 Subject: Re: use-after-free in sctp_do_sm To: Dmitry Vyukov , Joe Perches References: <20151203130525.GB4164@mrl.redhat.com> <566098BD.6010803@akamai.com> <1449172984.12092.0.camel@perches.com> <5660A1A7.3080301@akamai.com> <1449174246.12092.8.camel@perches.com> <5660A951.4000808@akamai.com> <1449175884.17296.2.camel@perches.com> Cc: Aaron Conole , Andrew Morton , LKML , Eric Dumazet , syzkaller , Vladislav Yasevich , linux-sctp@vger.kernel.org, netdev , Kostya Serebryany , Alexander Potapenko , Sasha Levin From: Jason Baron X-Enigmail-Draft-Status: N1110 Message-ID: <5661C3B8.2030902@akamai.com> Date: Fri, 4 Dec 2015 11:47:52 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: 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 On 12/04/2015 11:12 AM, Dmitry Vyukov wrote: > On Thu, Dec 3, 2015 at 9:51 PM, Joe Perches wrote: >> (adding lkml as this is likely better discussed there) >> >> On Thu, 2015-12-03 at 15:42 -0500, Jason Baron wrote: >>> On 12/03/2015 03:24 PM, Joe Perches wrote: >>>> On Thu, 2015-12-03 at 15:10 -0500, Jason Baron wrote: >>>>> On 12/03/2015 03:03 PM, Joe Perches wrote: >>>>>> On Thu, 2015-12-03 at 14:32 -0500, Jason Baron wrote: >>>>>>> On 12/03/2015 01:52 PM, Aaron Conole wrote: >>>>>>>> I think that as a minimum, the following patch should be evaluted, >>>>>>>> but am unsure to whom I should submit it (after I test): >>>>>> [] >>>>>>> Agreed - the intention here is certainly to have no side effects. It >>>>>>> looks like 'no_printk()' is used in quite a few other places that would >>>>>>> benefit from this change. So we probably want a generic >>>>>>> 'really_no_printk()' macro. >>>>>> >>>>>> https://lkml.org/lkml/2012/6/17/231 >>>>> >>>>> I don't see this in the tree. >>>> >>>> It never got applied. >>>> >>>>> Also maybe we should just convert >>>>> no_printk() to do what your 'eliminated_printk()'. >>>> >>>> Some of them at least. >>>> >>>>> So we can convert all users with this change? >>>> >>>> I don't think so, I think there are some >>>> function evaluation/side effects that are >>>> required. I believe some do hardware I/O. >>>> >>>> It'd be good to at least isolate them. >>>> >>>> I'm not sure how to find them via some >>>> automated tool/mechanism though. >>>> >>>> I asked Julia Lawall about it once in this >>>> thread: https://lkml.org/lkml/2014/12/3/696 >>>> >>> >>> Seems rather fragile to have side effects that we rely >>> upon hidden in a printk(). >> >> Yup. >> >>> Just convert them and see what breaks :) >> >> I appreciate your optimism. It's very 1995. >> Try it and see what happens. > > > But Aaron says that DYNAMIC_DEBUG is enabled in most major > distributions, and all these side-effects don't happen with > DYNAMIC_DEBUG. When DYNAMIC_DEBUG is enabled we have this wrapper from include/linux/dynamic_debug.h: if (unlikely(descriptor.flags & _DPRINTK_FLAGS_PRINT)) So the compiler is not emitting the side-effects in this case. >This suggests that we can make these side-effects not > happen without DYNAMIC_DEBUG as well. > Or I am missing something here? > When DYNAMIC_DEBUG is disabled we are instead replacing pr_debug() with the 'no_printk()' function as you've pointed out. We are changing this to emit no code at all: http://marc.info/?l=linux-kernel&m=144918276518878&w=2 Thanks, -Jason