Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 15EB0C433FE for ; Thu, 9 Dec 2021 14:11:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238415AbhLIOPC (ORCPT ); Thu, 9 Dec 2021 09:15:02 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57652 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238408AbhLIOPA (ORCPT ); Thu, 9 Dec 2021 09:15:00 -0500 Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AD1BFC061746 for ; Thu, 9 Dec 2021 06:11:26 -0800 (PST) Received: by mail-wm1-x32f.google.com with SMTP id i12so4288203wmq.4 for ; Thu, 09 Dec 2021 06:11:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=a2tXxsXCaxEsDkdFABP3QB5zkyYyslmPCU1sxe4bwWU=; b=hQUZOu9fn+0tSRYNo5YIO/fAqyN3BrECCRn67HUtge3wlFf6nMiMRiCWQ2rkBHM7w7 +W3tLzeCUKHRG2K+DAh/ECpaT25XWOVg4k/fRiEiDLo4bKBXwog9ut1V+bVqDh2WIs2/ 9KhCe9eiPw/ZqgAwPzDSiuZq0U5eFcO9YY5+NZ1U/9yq5fWoUd0jzuoM+thwFfBYv7DT W46iVMJdy1JQ+Gd3LeLe8aRgwSLCf8lhpXmySuYzyjmZ42kxD5l4gPwnVa4sKgqSK/S0 0YWHXR2+4v4NmD1jPUAyMhPaIKSGhLyljBj2swmv81fjhaCuDa8cb3abBV/vqKzTXSzm CuFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=a2tXxsXCaxEsDkdFABP3QB5zkyYyslmPCU1sxe4bwWU=; b=rmiHROiYIgldPKl/BCw9x2zZgwiCw7vPMPJA8lneSMFPQGipCxHb4HGnxO4fHBJYd/ arSaFBD4CAXQhDdC+L12fFjFW6Ee5zSRRZ8QFVltE6agztqYHhMuoknsGWHl7SyD1DK6 v+y60g5ZRp7BVtffyUubRIjruTHC9jhsw8+gZYEhyCT/Ok3QKcIrNG6a5LxpBX46uoRS 4xu81+RDY/T6W/aNkuoNbu4L7Nr6h6V1q+h6vUht/sN27f2JJYx22VUaOjEPFXHUL93T 4A4rJ/EywpeZGRHsYOEXGcGZx9Xf+zK3oCjgWzkN9uQ8to/Q4wIZD7+iYaJS05RuUE/J HP8A== X-Gm-Message-State: AOAM5338/IorfMJpPywIzxDpr03H3cnb1CcliETWJANQ3kU1WXB8s71h MnMbV0aMxaCmLyGHi82jVnTE3vCHEUC2l29p X-Google-Smtp-Source: ABdhPJxlnH8PSplZUk/T4ZpATlfN1OZM+7DPUEepMM3eGDtJOY0WOi+ijEXjclc0iC0C6+IOyyr7ew== X-Received: by 2002:a05:600c:1d91:: with SMTP id p17mr7534226wms.193.1639059084386; Thu, 09 Dec 2021 06:11:24 -0800 (PST) Received: from google.com ([2.31.167.18]) by smtp.gmail.com with ESMTPSA id j18sm11610930wmq.44.2021.12.09.06.11.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Dec 2021 06:11:23 -0800 (PST) Date: Thu, 9 Dec 2021 14:11:21 +0000 From: Lee Jones To: Marcelo Ricardo Leitner Cc: linux-kernel@vger.kernel.org, Vlad Yasevich , Neil Horman , "David S. Miller" , Jakub Kicinski , lksctp developers , "H.P. Yarroll" , Karl Knutson , Jon Grimm , Xingang Guo , Hui Huang , Sridhar Samudrala , Daisy Chang , Ryan Layer , Kevin Gao , netdev@vger.kernel.org Subject: Re: [PATCH 1/1] sctp: Protect cached endpoints to prevent possible UAF Message-ID: References: <20211208165434.2962062-1-lee.jones@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 09 Dec 2021, Marcelo Ricardo Leitner wrote: > On Wed, Dec 08, 2021 at 04:54:34PM +0000, Lee Jones wrote: > > To prevent this from happening we need to take a reference on the > > to-be-used/dereferenced 'struct sctp_endpoint' until such a time when > > we know it can be safely released. > > > > When KASAN is not enabled, a similar, but slightly different NULL > > pointer derefernce crash occurs later along the thread of execution in > > inet_sctp_diag_fill() this time. > > Hey Lee, did you try running lksctp-tools [1] func tests with this patch? > I'm getting failures here. > > [root@vm1 func_tests]# make v4test > ./test_assoc_abort > test_assoc_abort.c 1 PASS : ABORT an association using SCTP_ABORT > test_assoc_abort passes > > ./test_assoc_shutdown > test_assoc_shutdown.c 1 BROK : bind: Address already in use > DUMP_CORE ../../src/testlib/sctputil.h: 145 > /bin/sh: line 1: 3727 Segmentation fault (core dumped) ./$a > test_assoc_shutdown fails > make: *** [Makefile:1648: v4test] Error 1 > > I didn't check it closely but it would seem that the ep is beind held > forever. If I simply retry after a few seconds, it's still there (now the 1st > test fails): > > [root@vm1 func_tests]# make v4test > ./test_assoc_abort > test_assoc_abort.c 1 BROK : bind: Address already in use > DUMP_CORE ../../src/testlib/sctputil.h: 145 > /bin/sh: line 1: 3751 Segmentation fault (core dumped) ./$a > test_assoc_abort fails > > 1.https://github.com/sctp/lksctp-tools No I haven't, but I will do once I get a moment. The only thing I can think of, before I go digging again, is that either the association is never unhashed (so it stays in cache forever - I doubt this, as it would be very bad) or the association was migrated via sctp_assoc_migrate() and the additional reference was not transferred across. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog