Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp6747809rwd; Mon, 19 Jun 2023 11:40:42 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4tIfKS+ZM39Cz8MNZkjw5W0vJB2PopVJh3y77Eflnq04n9gt4ZAPleI4Mcc2uD8QDn0NTb X-Received: by 2002:a17:902:f683:b0:1b4:5699:aac1 with SMTP id l3-20020a170902f68300b001b45699aac1mr13947068plg.12.1687200042285; Mon, 19 Jun 2023 11:40:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1687200042; cv=none; d=google.com; s=arc-20160816; b=DCvawrSvpf7IQ49hAlGF4x/OtsdJMY6u2Ermn75izFoUtFySAfue1MklNxbsAMUOX6 BfAh1lrqmbXJcd16r/lyf/YVWTGQ+EyHlbcAyhcl8vP+0pUz/NG4onAaCPHCV6aoZMRr URxg/cs0TbTUtqsKvi59ZmNEvMYQvVqS0SuZAqHAyu2lGmoQmy2Yz28pGUfVv9j25rNZ qoDjhJ5V0V9UCXP4s3P5m+8/HPOMphpnrHIeMkqTjLHOQUnfGhzTR6Sprn9IpB7lxsmq cZN3PNiFUapbj5R5yEOOedA4WwuDh4NP/o2lKhI5AjE46uuBX8bRT6sS8rNCSq6zI9rL Nd0g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=/WlJr5YKUmRI6iQp5j0GxJOjR9sEGRNrSNhoMxa3/r4=; b=lm8MCG02t8sPZ+OF8bJMHSNA4E8d/PA75/UB4dW1uy+EsqEQLEY+ikTF5CYVmFsnLH ImpOnnc7+MzNksDMj9+84nmeXTHY4Yuocl2vHjbuTv/IQXESQ8tDMoyrP9IERu3aNWql 2+YKKkUQi4Jfu8n05B+2vwsy1cFIVUndykvPXTov6woaOVO2cUMfvSfpPgc1mzjeldHs eoCyrO1brUqnFfA+n7hcTD5M8bPc/HubvGEna1vo+xYZ+Vtm+hrHdSDLA2sXGeVycv5E qLzQ78/hiQT0+VAcA1YnLT2WO9fcrmYf/iilZdbvi9wRLDRjQaVGNcHFei7BFT276M9w oO3g== 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id m11-20020a170902f20b00b001ab2a0e3163si238946plc.598.2023.06.19.11.40.30; Mon, 19 Jun 2023 11:40:42 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231487AbjFSR5Q (ORCPT + 99 others); Mon, 19 Jun 2023 13:57:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41994 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229537AbjFSR5P (ORCPT ); Mon, 19 Jun 2023 13:57:15 -0400 Received: from mail.hallyn.com (mail.hallyn.com [178.63.66.53]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6989312A; Mon, 19 Jun 2023 10:57:12 -0700 (PDT) Received: by mail.hallyn.com (Postfix, from userid 1001) id 808C4518; Mon, 19 Jun 2023 12:57:10 -0500 (CDT) Date: Mon, 19 Jun 2023 12:57:10 -0500 From: "Serge E. Hallyn" To: Ben Dooks Cc: linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, serge@hallyn.com, Paul Moore Subject: Re: [PATCH] capabilities: fix sparse warning about __user access Message-ID: <20230619175710.GA200481@mail.hallyn.com> References: <20230619123535.324632-1-ben.dooks@codethink.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230619123535.324632-1-ben.dooks@codethink.co.uk> X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS, SPF_PASS,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 Mon, Jun 19, 2023 at 01:35:35PM +0100, Ben Dooks wrote: > The two syscalls for capget and capset are producing sparse warnings > as sparse is thinking that the "struct __user_cap_data_struct" is marked > user, which seems to be down to the declaration and typedef at the same > time. > > Fix the following warnings by splutting the struct declaration and then > the user typedef into two: I'm not a fan of making code changes to work around scanners' shortcomings, mainly because eventually I assume the scanners will learn to deal with it. However, I don't like the all-in-one typedef+struct definition either, so let's go with it :) Paul, do you mind picking this up? thanks, -serge > kernel/capability.c:191:35: warning: incorrect type in argument 2 (different address spaces) > kernel/capability.c:191:35: expected void const *from > kernel/capability.c:191:35: got struct __user_cap_data_struct [noderef] __user * > kernel/capability.c:168:14: warning: dereference of noderef expression > kernel/capability.c:168:45: warning: dereference of noderef expression > kernel/capability.c:169:14: warning: dereference of noderef expression > kernel/capability.c:169:45: warning: dereference of noderef expression > kernel/capability.c:170:14: warning: dereference of noderef expression > kernel/capability.c:170:45: warning: dereference of noderef expression > kernel/capability.c:244:29: warning: incorrect type in argument 1 (different address spaces) > kernel/capability.c:244:29: expected void *to > kernel/capability.c:244:29: got struct __user_cap_data_struct [noderef] __user ( * )[2] > kernel/capability.c:247:42: warning: dereference of noderef expression > kernel/capability.c:247:64: warning: dereference of noderef expression > kernel/capability.c:248:42: warning: dereference of noderef expression > kernel/capability.c:248:64: warning: dereference of noderef expression > kernel/capability.c:249:42: warning: dereference of noderef expression > kernel/capability.c:249:64: warning: dereference of noderef expression > > Signed-off-by: Ben Dooks Reviewed-by: Serge Hallyn > --- > include/uapi/linux/capability.h | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/include/uapi/linux/capability.h b/include/uapi/linux/capability.h > index 3d61a0ae055d..5bb906098697 100644 > --- a/include/uapi/linux/capability.h > +++ b/include/uapi/linux/capability.h > @@ -41,11 +41,12 @@ typedef struct __user_cap_header_struct { > int pid; > } __user *cap_user_header_t; > > -typedef struct __user_cap_data_struct { > +struct __user_cap_data_struct { > __u32 effective; > __u32 permitted; > __u32 inheritable; > -} __user *cap_user_data_t; > +}; > +typedef struct __user_cap_data_struct __user *cap_user_data_t; > > > #define VFS_CAP_REVISION_MASK 0xFF000000 > -- > 2.39.2