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=-13.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 0E5E1C433E0 for ; Tue, 5 Jan 2021 11:59:07 +0000 (UTC) Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 907F422A83 for ; Tue, 5 Jan 2021 11:59:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 907F422A83 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=raspberrypi.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=driverdev-devel-bounces@linuxdriverproject.org Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 0768A857C2; Tue, 5 Jan 2021 11:59:06 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOYd09sQRCI2; Tue, 5 Jan 2021 11:59:04 +0000 (UTC) Received: from ash.osuosl.org (ash.osuosl.org [140.211.166.34]) by whitealder.osuosl.org (Postfix) with ESMTP id BC09284353; Tue, 5 Jan 2021 11:59:04 +0000 (UTC) Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by ash.osuosl.org (Postfix) with ESMTP id 120731BF23F for ; Tue, 5 Jan 2021 11:59:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 0EAC4870C8 for ; Tue, 5 Jan 2021 11:59:03 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-DV9Z9dvYoS for ; Tue, 5 Jan 2021 11:59:02 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail-ot1-f54.google.com (mail-ot1-f54.google.com [209.85.210.54]) by hemlock.osuosl.org (Postfix) with ESMTPS id 2FCC0870C3 for ; Tue, 5 Jan 2021 11:59:02 +0000 (UTC) Received: by mail-ot1-f54.google.com with SMTP id o11so29028632ote.4 for ; Tue, 05 Jan 2021 03:59:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raspberrypi.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Pk4Qq2YKL30G+6a6HOVm8kHQKCseUHAE6YvgfBgjVZk=; b=h6IbyPCaSChmAyVG/ynnFKP/3nQ/ZGwZiHvQExwhDecZ36WXISf6yENgPUjIw/mBUG 15nJQ2YfvOq2FN95133nZDbb7CSSzHtrX0CGg6VaUYSGD8AL+IDGSazn8N8KeW2akXWU oUFe4lghga2pNZJD1/ib6soFiUfTXN86hXKNpPTFjdFniM61DmnMmdI5FaYnAgbYUI4o 8xI+uCOHw7gmBzFM8gOSvsbe4ftCz94bq22kt0zL9iLjzAcrbD88jY6fO51lEebJzbJr 4suwEb5eaQZFiOkEi0jWHbFHsTJSWmPrIHxoWfiLR1ay5KPfIKcocc4vwLc6RFgi0Hrc folw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Pk4Qq2YKL30G+6a6HOVm8kHQKCseUHAE6YvgfBgjVZk=; b=QMrxaabo7Q047SEOZomtVQYpyrYKMIv+qStehDqoFs5u1P+H+5ezIVb3kDufhEm8fh RoJWIhPlOZRG2hHmwL3TJHI13LBagJifN6yOE1fwH+LyYs4PrUkW/d5W5GpHzOd+dLTQ TwO8amaoaB8u65QzIqp6hIA06PKENaxVGJAvlDG3JiluKPCenSeo/YwC/MHCCcd4yojx 0+Q0PE5plRVd4/yvhZWZLEF1J3c9OcJb/p8vpoTwQ50MADLdO6B8RjkoYRmjmb1qAQcj pCuL3e62qNSe8FP/SkInGnLueEzxuBbEjrB7uRTjwksa0YQmsS9kDWOXE6IgJWTHkzMj zIkQ== X-Gm-Message-State: AOAM530iMLZJsMns4Q8gCYk7XXtS9Nh/1iEFEXYTb0cmrjGZsoaGl31h hzb+64djWYfOstQCbSRxtf5DB0t+GLJvnIcpoxrN12EqfgfDjQ== X-Google-Smtp-Source: ABdhPJxLzR1Pw8N/NP8hPCrIiJC/HSISpbPs+Yx5Rm1iWHE64RNsD/a+GMpBjYOlTJ0kFQYWR5qFHDexfDktJK0BVOM= X-Received: by 2002:a9d:27ea:: with SMTP id c97mr53960788otb.173.1609847622735; Tue, 05 Jan 2021 03:53:42 -0800 (PST) MIME-Version: 1.0 References: <20210104120929.294063-1-phil@raspberrypi.com> <20210104120929.294063-2-phil@raspberrypi.com> <20210104183134.GV2809@kadam> <989ef44f-2afe-5147-1277-74df56797a4c@raspberrypi.com> <20210105110140.GW2809@kadam> In-Reply-To: <20210105110140.GW2809@kadam> From: Phil Elwell Date: Tue, 5 Jan 2021 11:53:32 +0000 Message-ID: Subject: Re: [PATCH 1/2] staging: vchiq: Fix bulk userdata handling To: Dan Carpenter X-BeenThere: driverdev-devel@linuxdriverproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux Driver Project Developer List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devel@driverdev.osuosl.org, Arnd Bergmann , Greg Kroah-Hartman , "maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE" , linux-arm-kernel@lists.infradead.org, Nicolas Saenz Julienne , "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: driverdev-devel-bounces@linuxdriverproject.org Sender: "devel" On Tue, 5 Jan 2021 at 11:04, Dan Carpenter wrote: > > On Mon, Jan 04, 2021 at 07:26:42PM +0000, Phil Elwell wrote: > > On 04/01/2021 18:31, Dan Carpenter wrote: > > > On Mon, Jan 04, 2021 at 12:09:27PM +0000, Phil Elwell wrote: > > > > The addition of the local 'userdata' pointer to > > > > vchiq_irq_queue_bulk_tx_rx omitted the case where neither BLOCKING nor > > > > WAITING modes are used, in which case the value provided by the > > > > caller is replaced with a NULL. > > > > > > > > Fixes: 4184da4f316a ("staging: vchiq: fix __user annotations") > > > > > > > > Signed-off-by: Phil Elwell > > > > --- > > > > drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c | 4 +++- > > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c > > > > index f500a7043805..2a8883673ba1 100644 > > > > --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c > > > > +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c > > > > @@ -958,7 +958,7 @@ static int vchiq_irq_queue_bulk_tx_rx(struct vchiq_instance *instance, > > > > struct vchiq_service *service; > > > > struct bulk_waiter_node *waiter = NULL; > > > > bool found = false; > > > > - void *userdata = NULL; > > > > + void *userdata; > > > > int status = 0; > > > > int ret; > > > > @@ -997,6 +997,8 @@ static int vchiq_irq_queue_bulk_tx_rx(struct vchiq_instance *instance, > > > > "found bulk_waiter %pK for pid %d", waiter, > > > > current->pid); > > > > userdata = &waiter->bulk_waiter; > > > > + } else { > > > > + userdata = args->userdata; > > > > > > "args->userdata" is marked as a user pointer so we really don't want to > > > mix user and kernel pointers here. Presumably this opens up a large > > > security hole. > > > > It's an opaque, pointer-sized token that only exists to bereturned to userspace (or not, > > without this patch) - it's hard to see that as a security hole. > > I was assuming the bug here was a NULL dereference... Apparently that's > not the case? The commit message needs to be updated to be more clear > about how the bug looks like to the user. > > Are we using the "&waiter->bulk_waiter" as a "token to be returned to > userspace" as well? It looks like maybe it is in vchiq_put_completion(). > That defeats KASLR and is a different sort of security problem. > > Mixing __user pointers and regular pointers is dangerous and has lead to > security problems in this driver in the past. But also mixing mixing > tokens with pointers just makes the code hard to read. Instead of > undoing Arnd's work where he split the user space and kernel pointers > apart we should go ahead and spit it up even more. At least add a giant > FIXME comment and an item in the TODO list so we don't forget to do this > before removing the code from staging. Those all sound like valid comments to have made against the original patch, but that seems to have received little attention. I'll just leave this here - perhaps Arnd has the patience to finish the job. Phil _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel 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=-14.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham 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 D7559C433DB for ; Tue, 5 Jan 2021 11:55:17 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 80A9C229CA for ; Tue, 5 Jan 2021 11:55:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 80A9C229CA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=raspberrypi.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=twpudHYSdbOhRety8j9En8c6FVN+xmAwJLSjLlUfM48=; b=tMUcSBxh6Dc0c+rr4op4H3KqB wgdakUjri5xdDJ5A1wzL5bSKycU8ZxTvryMQTv78kru7d0Yi+YgclBHL0PI51DvrMXT4VXsbq6GRJ oP95vQHurPSHMXfQjZNnmhgx68TvVR071QOZGiUveh+0qmOC7XCnFOhB2hjC8efcumgCfPcUFh9I4 5K2RS/ZqOHYrOMYRD5vdmwwWS1cLcwbpnvWVEeqQZzuTeKqsOBWYl6d/4VjCXqpz9yyytcsZgXnF3 Aw2O5QpOwnruyQOmv/d9YDck2Ze7XCSPuhk36Fu62I/nkBHyAhupAZZdrcjkECRoAsNLIPKhcXPfZ Rr7pGbSeg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kwkuK-0000En-Af; Tue, 05 Jan 2021 11:53:48 +0000 Received: from mail-ot1-x32d.google.com ([2607:f8b0:4864:20::32d]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kwkuH-0000Dk-Br for linux-arm-kernel@lists.infradead.org; Tue, 05 Jan 2021 11:53:46 +0000 Received: by mail-ot1-x32d.google.com with SMTP id d8so29008253otq.6 for ; Tue, 05 Jan 2021 03:53:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raspberrypi.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Pk4Qq2YKL30G+6a6HOVm8kHQKCseUHAE6YvgfBgjVZk=; b=h6IbyPCaSChmAyVG/ynnFKP/3nQ/ZGwZiHvQExwhDecZ36WXISf6yENgPUjIw/mBUG 15nJQ2YfvOq2FN95133nZDbb7CSSzHtrX0CGg6VaUYSGD8AL+IDGSazn8N8KeW2akXWU oUFe4lghga2pNZJD1/ib6soFiUfTXN86hXKNpPTFjdFniM61DmnMmdI5FaYnAgbYUI4o 8xI+uCOHw7gmBzFM8gOSvsbe4ftCz94bq22kt0zL9iLjzAcrbD88jY6fO51lEebJzbJr 4suwEb5eaQZFiOkEi0jWHbFHsTJSWmPrIHxoWfiLR1ay5KPfIKcocc4vwLc6RFgi0Hrc folw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Pk4Qq2YKL30G+6a6HOVm8kHQKCseUHAE6YvgfBgjVZk=; b=YO2UdrQXuO533aYYgGGg4cs+s4lydXUujNLHGXFMzqxTHRrsvoU2k29OnoHNMjOQp1 nnC0P16jGUJFalFI0kUoBZOaYQQBQkXgs++Rtg/vnxFX14tzV4W/xTqdw5e/1uNAspq2 Wv0d7JgEnXcy3Zr1cbItLZiaG10lIXonqvOLKuLNS8PR+1Gl27x9xbtyd5Gah4NTP7e1 lRkzWgYFlLQC8pdnbOtZPrUM8Yq7hoYrjfAOkX6deEFK+V1d+xHH+bn2HsduVkk7751I PrunFGNE8nXUMYqql1xDPtoJuiiBCxAPR5f+We4yrgXafPWR4QnsORCX4d1fG8EaKNlV gEvg== X-Gm-Message-State: AOAM532Uw9RoeN1w0xI8UMf4/Ny6SQ4TxAr/3l2Otp4aaIN4OJxWd5u2 UiYjFWHmwshhKnAryue6bI+VPC8x0pF9mEEcM7GmDw== X-Google-Smtp-Source: ABdhPJxLzR1Pw8N/NP8hPCrIiJC/HSISpbPs+Yx5Rm1iWHE64RNsD/a+GMpBjYOlTJ0kFQYWR5qFHDexfDktJK0BVOM= X-Received: by 2002:a9d:27ea:: with SMTP id c97mr53960788otb.173.1609847622735; Tue, 05 Jan 2021 03:53:42 -0800 (PST) MIME-Version: 1.0 References: <20210104120929.294063-1-phil@raspberrypi.com> <20210104120929.294063-2-phil@raspberrypi.com> <20210104183134.GV2809@kadam> <989ef44f-2afe-5147-1277-74df56797a4c@raspberrypi.com> <20210105110140.GW2809@kadam> In-Reply-To: <20210105110140.GW2809@kadam> From: Phil Elwell Date: Tue, 5 Jan 2021 11:53:32 +0000 Message-ID: Subject: Re: [PATCH 1/2] staging: vchiq: Fix bulk userdata handling To: Dan Carpenter X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210105_065345_429924_158C7BBF X-CRM114-Status: GOOD ( 31.46 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devel@driverdev.osuosl.org, Arnd Bergmann , Greg Kroah-Hartman , "maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE" , linux-arm-kernel@lists.infradead.org, Nicolas Saenz Julienne , "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, 5 Jan 2021 at 11:04, Dan Carpenter wrote: > > On Mon, Jan 04, 2021 at 07:26:42PM +0000, Phil Elwell wrote: > > On 04/01/2021 18:31, Dan Carpenter wrote: > > > On Mon, Jan 04, 2021 at 12:09:27PM +0000, Phil Elwell wrote: > > > > The addition of the local 'userdata' pointer to > > > > vchiq_irq_queue_bulk_tx_rx omitted the case where neither BLOCKING nor > > > > WAITING modes are used, in which case the value provided by the > > > > caller is replaced with a NULL. > > > > > > > > Fixes: 4184da4f316a ("staging: vchiq: fix __user annotations") > > > > > > > > Signed-off-by: Phil Elwell > > > > --- > > > > drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c | 4 +++- > > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c > > > > index f500a7043805..2a8883673ba1 100644 > > > > --- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c > > > > +++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c > > > > @@ -958,7 +958,7 @@ static int vchiq_irq_queue_bulk_tx_rx(struct vchiq_instance *instance, > > > > struct vchiq_service *service; > > > > struct bulk_waiter_node *waiter = NULL; > > > > bool found = false; > > > > - void *userdata = NULL; > > > > + void *userdata; > > > > int status = 0; > > > > int ret; > > > > @@ -997,6 +997,8 @@ static int vchiq_irq_queue_bulk_tx_rx(struct vchiq_instance *instance, > > > > "found bulk_waiter %pK for pid %d", waiter, > > > > current->pid); > > > > userdata = &waiter->bulk_waiter; > > > > + } else { > > > > + userdata = args->userdata; > > > > > > "args->userdata" is marked as a user pointer so we really don't want to > > > mix user and kernel pointers here. Presumably this opens up a large > > > security hole. > > > > It's an opaque, pointer-sized token that only exists to bereturned to userspace (or not, > > without this patch) - it's hard to see that as a security hole. > > I was assuming the bug here was a NULL dereference... Apparently that's > not the case? The commit message needs to be updated to be more clear > about how the bug looks like to the user. > > Are we using the "&waiter->bulk_waiter" as a "token to be returned to > userspace" as well? It looks like maybe it is in vchiq_put_completion(). > That defeats KASLR and is a different sort of security problem. > > Mixing __user pointers and regular pointers is dangerous and has lead to > security problems in this driver in the past. But also mixing mixing > tokens with pointers just makes the code hard to read. Instead of > undoing Arnd's work where he split the user space and kernel pointers > apart we should go ahead and spit it up even more. At least add a giant > FIXME comment and an item in the TODO list so we don't forget to do this > before removing the code from staging. Those all sound like valid comments to have made against the original patch, but that seems to have received little attention. I'll just leave this here - perhaps Arnd has the patience to finish the job. Phil _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel