From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Baron Date: Thu, 03 Dec 2015 20:42:57 +0000 Subject: Re: use-after-free in sctp_do_sm Message-Id: <5660A951.4000808@akamai.com> List-Id: 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> In-Reply-To: <1449174246.12092.8.camel@perches.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Joe Perches , Aaron Conole , Dmitry Vyukov Cc: Eric Dumazet , syzkaller , Vladislav Yasevich , linux-sctp@vger.kernel.org, netdev , Kostya Serebryany , Alexander Potapenko , Sasha Levin 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(). Just convert them and see what breaks :) From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason Baron Subject: Re: use-after-free in sctp_do_sm Date: Thu, 3 Dec 2015 15:42:57 -0500 Message-ID: <5660A951.4000808@akamai.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: Eric Dumazet , syzkaller , Vladislav Yasevich , linux-sctp@vger.kernel.org, netdev , Kostya Serebryany , Alexander Potapenko , Sasha Levin To: Joe Perches , Aaron Conole , Dmitry Vyukov Return-path: Received: from prod-mail-xrelay05.akamai.com ([23.79.238.179]:64693 "EHLO prod-mail-xrelay05.akamai.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752369AbbLCUnD (ORCPT ); Thu, 3 Dec 2015 15:43:03 -0500 In-Reply-To: <1449174246.12092.8.camel@perches.com> Sender: netdev-owner@vger.kernel.org List-ID: 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(). Just convert them and see what breaks :)