Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp3035157rwd; Wed, 14 Jun 2023 10:16:56 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5yWGYXPgDXGtyQHrHFJgrTBikZsSGVrg7oyLgR8TXKzDG60bqoAyChuYK/RDbF4XRtVCEk X-Received: by 2002:a17:90a:8b92:b0:256:2ee5:aebc with SMTP id z18-20020a17090a8b9200b002562ee5aebcmr1646994pjn.18.1686763016547; Wed, 14 Jun 2023 10:16:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686763016; cv=none; d=google.com; s=arc-20160816; b=CUky0PItVZ26Y+9A7FEKFfGJfOK/Wp2HjYEPsTJihx2zSRHEMqqvIIwscmG7p+A6hz RgLJszGfHue5s8nEQkM8TQCJvPPi6QPP6zp0Bxp6BY8W1DcT0ZyoZpsMkxJbGonOc7t6 DRd6fPlvIfcEkK+1r5gK7FjQRJToioUEMj951V5zwIHbyMD5cDQiHldfmqzZrP/FmE+f /E4vLU03CAZu6h3IePL3Jq4D5P32xoqAfl5D3Lm5V6k5p1/XL4BwG5iQqvibkL/xuApg hrK05m5STcmndfVz9/bymj5UJjYU/QxSkn7x0X9ioH9QH291ABMYTRXQoiaz46iRoM2w sp6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=Hzc+M/L0l0b3Z2dsv8ZB/86M29XVdy9lgq8r9zSye1w=; b=TXouzXg1Lc41DHVwaI2tj2ppXbAhErQVOjsVsC254d/gqrBciyGPdT2zUO8jX/O3an iRjeKAVYvGM8TiCAjyfLE0sEjFhMgrTivBOPpSgOg/gwWLKqZGhwxqgwcjEl0q//aLEe dxMJ8C0CA+e9iIaDXbzq/QPcKmwmItlqiXnVeql2dGuStZGk1OmNDlx9LsGco1Q4rGfN zEh8ACRgNjX6JuVUMUUaj6p+duEHNUhCuikHFZ6osUUYxSzluPTEG3brJH0By+8MDI+Z e3dpXkc6ALAUWL6YRPEJr/6aCiXD4pMD8h/DEfRfIcfBCJNhXKrHb8ixg0S/FwHZYOC3 w3vQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id v8-20020a17090a4ec800b002528157a968si7008558pjl.2.2023.06.14.10.16.44; Wed, 14 Jun 2023 10:16:56 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233685AbjFNQaI (ORCPT + 99 others); Wed, 14 Jun 2023 12:30:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43516 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233610AbjFNQaG (ORCPT ); Wed, 14 Jun 2023 12:30:06 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 1D0FB2120 for ; Wed, 14 Jun 2023 09:30:04 -0700 (PDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 40BE01FB; Wed, 14 Jun 2023 09:30:48 -0700 (PDT) Received: from [10.57.85.233] (unknown [10.57.85.233]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 102F13F71E; Wed, 14 Jun 2023 09:30:02 -0700 (PDT) Message-ID: Date: Wed, 14 Jun 2023 17:29:58 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [PATCH] iommu: Fix missing check for return value of iommu_group_get() Content-Language: en-GB To: Chenyuan Mi , joro@8bytes.org Cc: will@kernel.org, iommu@lists.linux.dev, linux-kernel@vger.kernel.org References: <20230614154308.118783-1-cymi20@fudan.edu.cn> From: Robin Murphy In-Reply-To: <20230614154308.118783-1-cymi20@fudan.edu.cn> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2023-06-14 16:43, Chenyuan Mi wrote: > The iommu_group_get() function may return NULL, which may > cause null pointer deference, and most other callsites of > iommu_group_get() do Null check. Add Null check for return > value of iommu_group_get(). > > Found by our static analysis tool. Static analysis is good at highlighting areas of code that might be worth looking at, but you then still need to actually look at the code and understand whether there's a problem or not... > Signed-off-by: Chenyuan Mi > --- > drivers/iommu/iommu.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c > index f1dcfa3f1a1b..ef3483e75511 100644 > --- a/drivers/iommu/iommu.c > +++ b/drivers/iommu/iommu.c > @@ -3217,6 +3217,8 @@ EXPORT_SYMBOL_GPL(iommu_group_release_dma_owner); /** * iommu_group_release_dma_owner() - Release DMA ownership of a group * @dev: The device * * Release the DMA ownership claimed by iommu_group_claim_dma_owner(). */ If dev->iommu_group could have somehow disappeared since iommu_group_claim_dma_owner() succeeded then something has gone so catastrophically wrong that it's not worth even trying to reason about. Or if the caller is passing something here that isn't the same device, then why should we assume it's even a valid device pointer at all, and iommu_group_get() isn't going to crash or return nonzero garbage? > void iommu_device_release_dma_owner(struct device *dev) > { > struct iommu_group *group = iommu_group_get(dev); > + if (!group) > + return; > > mutex_lock(&group->mutex); > if (group->owner_cnt > 1) > @@ -3329,6 +3331,8 @@ void iommu_detach_device_pasid(struct iommu_domain *domain, struct device *dev, > ioasid_t pasid) /* * iommu_detach_device_pasid() - Detach the domain from pasid of device * @domain: the iommu domain. * @dev: the attached device. * @pasid: the pasid of the device. * * The @domain must have been attached to @pasid of the @dev with * iommu_attach_device_pasid(). */ Again, iommu_attach_device_pasid() already validates that the device has a group. If a caller uses the API incorrectly then all bets are off. Plus, look at the callsites of iommu_detach_device_pasid() - they're already holding their own reference to the same group anyway! Thanks, Robin. > { > struct iommu_group *group = iommu_group_get(dev); > + if (!group) > + return; > > mutex_lock(&group->mutex); > __iommu_remove_group_pasid(group, pasid);