From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Ricardo Leitner Subject: Re: use-after-free in sctp_do_sm Date: Mon, 7 Dec 2015 18:52:11 -0200 Message-ID: <5665F17B.5030908@gmail.com> References: <20151204213428.GH4164@mrl.redhat.com> <56631357.6020304@gmail.com> <20151207131524.GA22989@mrl.redhat.com> <20151207185218.GB22989@mrl.redhat.com> <5665DF20.9020904@gmail.com> <20151207195032.GA22987@mrl.redhat.com> <5665EE26.3000706@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Dmitry Vyukov , netdev , Eric Dumazet , syzkaller , linux-sctp@vger.kernel.org, Kostya Serebryany , Alexander Potapenko , Sasha Levin To: Vlad Yasevich Return-path: Received: from mail-qg0-f48.google.com ([209.85.192.48]:33174 "EHLO mail-qg0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933019AbbLGUwS (ORCPT ); Mon, 7 Dec 2015 15:52:18 -0500 In-Reply-To: <5665EE26.3000706@gmail.com> Sender: netdev-owner@vger.kernel.org List-ID: Em 07-12-2015 18:37, Vlad Yasevich escreveu: > On 12/07/2015 02:50 PM, Marcelo Ricardo Leitner wrote: >> On Mon, Dec 07, 2015 at 02:33:52PM -0500, Vlad Yasevich wrote: >>> On 12/07/2015 01:52 PM, Marcelo Ricardo Leitner wrote: >>>> Vlad, I reviewed the places on which it returns SCTP_DISPOSITION_ABORT, >>>> and if I didn't miss something in there all of them either issue >>>> SCTP_CMD_ASSOC_FAILED or SCTP_CMD_INIT_FAILED before returning it, thus >>>> delaying DELETE_TCB and with that the asoc free. >>> >>> They delay it from the perspective of the command interpreter since the command >>> to delete the TCB happens a little later, but status code is checked after all >>> commands are processed and command processing doesn't change it. So the 'status' >>> code would still be SCTP_DISPOSITION_ABORT after DELETE_TCB command was processed. >>> So, I think we may still have an use-after-free issue here. >> >> Gotcha! That's pretty much it then. From that point of view now, there >> shouldn't be a case that it returns _ABORT without freeing the asoc in >> the same loop. (more below) >> >>>> There is one place, >>>> though, that may not do it that way, it's sctp_sf_abort_violation(), but >>>> then that code only runs if asoc is already NULL by then. >>> >>> I don't believe so. The violation state function can run with a non-NULL association >>> if we are encountering protocol violations after the association is established. >> >> Yup, that's correct. I just tried to reference one case on which it >> would return _ABORT without issuing any of those _FAILEDs before doing >> so (meaning the association could still be valid) but that in that case, >> the asoc was already NULL. > > I think it is possible to hit the 'discard:' tag in that function while still > having a valid association. That happens when ABORT chunk is required to be > authenticated. This that case, instead of generating an ABORT and terminating the > current association, we just drop the packet, but still report an _ABORT disposition code. > > This probably need to change if we are going to catch the _ABORT disposition and > clear the asoc pointer. Oups. Nice one. I'll switch it to SCTP_DISPOSITION_DISCARD if it hits that if() then. Thanks Vlad. Marcelo