Received: by 2002:a05:7412:f690:b0:e2:908c:2ebd with SMTP id ej16csp79191rdb; Wed, 18 Oct 2023 19:27:40 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEm63p1DtXk/Ut5HU8u04OtWUYf68BO1KguCMnLXgdbvtVY2Qax7kYwfWnaJTciDbF+w5tJ X-Received: by 2002:a05:6a20:1592:b0:12f:c0c1:d70 with SMTP id h18-20020a056a20159200b0012fc0c10d70mr888636pzj.40.1697682460191; Wed, 18 Oct 2023 19:27:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1697682460; cv=none; d=google.com; s=arc-20160816; b=VgUIGCm5zZgBMeZXp/Y2rOJiF2qu3kqmd+6tzvUL3vajNm4ACEeYoBvhZgMviUUuKF ldcUtAb3mJRXLDCBjOi0n2IlkhMQsaqLFBaqaZVcTxJvU1zxuzwPNhjJ8ASSdvIVaRSE 0Fm3YpBSiijg+yhfwVS0bNpacWrauOsaBemTatdZ+l3Xzrrd80HDYsB6CNhuga35H1dQ IYP2b/dgYW8aVTOKRt8XTt3np4qbsqoG3aqMWyDkdy95t1R4VHaHAPy/13A1DhiEVCmD nzmwZwVZbYFfklV0DtkEi9fuyL7ymXBu9N7MBTJ3xwh890N3GFscX82zGJdDy8EfFoUW aDWA== 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 :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=dxOjzErkh5+zOBFjAXg3fxhcdphmjj8jzIkYzk1WPo4=; fh=DUZaBBCwsb6eIj+xXAgdwD7yo8rx9M0ZrGdk6HDwhA8=; b=CsSnsdIic5iqkeOSvm2xZiMcX/s6sW3whmJedsbtK7qfBl2wQyefrQBcNKCohA3W7/ 4m6pU0IKoDy1Wo2W5ETsCGvlX4CwwHFrKXagUXOfNiYnRPrKbvSbRKh7TS7ByxQUt7gq eAikq4cx5aVIPvXZOXAGXFJwrL4nZSyN6TlYYHqsCoQhKvgwgTSW+/GUbvA3n2eow0yO y+V/V8pPGwfeh4Ea8U7eRc1N/jn1NObNm/FrGAMIgX48TCr8ber95pscgefQvJWNevzU 0iaXEFoBzDgCRIWob8Nf1cR0y+X5RZ8z0ZhZxI/7cBokabisVFzC1peaMQlh8oboa9rd u0qA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=bombadil.20210309 header.b=lGaalIYZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from agentk.vger.email (agentk.vger.email. [23.128.96.32]) by mx.google.com with ESMTPS id n6-20020a635906000000b0057d7cff25besi3251629pgb.829.2023.10.18.19.27.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Oct 2023 19:27:40 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32; Authentication-Results: mx.google.com; dkim=pass header.i=@infradead.org header.s=bombadil.20210309 header.b=lGaalIYZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by agentk.vger.email (Postfix) with ESMTP id 7EDC980E0A7E; Wed, 18 Oct 2023 19:27:36 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231950AbjJSC1Y (ORCPT + 99 others); Wed, 18 Oct 2023 22:27:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35304 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229632AbjJSC1Y (ORCPT ); Wed, 18 Oct 2023 22:27:24 -0400 Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:3::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A288895 for ; Wed, 18 Oct 2023 19:27:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date: Message-ID:Sender:Reply-To:Content-ID:Content-Description; bh=dxOjzErkh5+zOBFjAXg3fxhcdphmjj8jzIkYzk1WPo4=; b=lGaalIYZQEMesgAQnQaBGuUTdI 8sMhhoZrEZ9xoiO5fLnqAeov1dFW2FmOmGBE80ZEDqZZVr8xQgOABwZlbIW+pYAZLil7Q/AtN1gD3 ovYHjlg+y1YVoU2kkSjjOD6SD4cGKsO1C6jKTVfdA+rfPOh1FsgsTKdT+Ji8XAL1Ll97p3MFpcwF+ iBt8Vj9v/rxbxdKqxRxexGqK77JWiWVIUisuHDAwOOZnHvt/5VWwDdFG3EMhnnD8CeX2pH2GaZMWj HUx5p77cbKOK7nCgJ3O7JDaR9/Oot0Ltu0zGQZINulHVk1+nmVPV1d/tghI2CkvxSAveEnvDPwnNP w8dbYStw==; Received: from [50.53.46.231] (helo=[192.168.254.15]) by bombadil.infradead.org with esmtpsa (Exim 4.96 #2 (Red Hat Linux)) id 1qtIkr-00G8AZ-1G; Thu, 19 Oct 2023 02:27:21 +0000 Message-ID: Date: Wed, 18 Oct 2023 19:27:20 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Is strncpy really less secure than strscpy ? To: Bagas Sanjaya , James Dutton , Linux Kernel Mailing List Cc: Justin Stitt , Calvince Otieno , Azeem Shaikh , Kees Cook , Andy Shevchenko References: Content-Language: en-US From: Randy Dunlap In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Wed, 18 Oct 2023 19:27:36 -0700 (PDT) On 10/18/23 18:49, Bagas Sanjaya wrote: > [Disclaimer: I have little to no knowledge of C, so things may be wrong. > Please correct me if it is the case. Also Cc: recent people who work on > strscpy() conversion.] > Also Cc: the STRING maintainers. > On Thu, Oct 19, 2023 at 12:22:33AM +0100, James Dutton wrote: >> Is strncpy really less secure than strscpy ? >> >> If one uses strncpy and thus put a limit on the buffer size during the >> copy, it is safe. There are no writes outside of the buffer. >> If one uses strscpy and thus put a limit on the buffer size during the >> copy, it is safe. There are no writes outside of the buffer. > > Well, assuming that the string is NUL-terminated, the end result should > be the same. > >> But, one can fit more characters in strncpy than strscpy because >> strscpy enforces the final \0 on the end. >> One could argue that strncpy is better because it might save the space >> of one char at the end of a string array. >> There are cases where strncpy might be unsafe. For example copying >> between arrays of different sizes, and that is a case where strscpy >> might be safer, but strncpy can be made safe if one ensures that the >> size used in strncpy is the smallest of the two different array sizes. > > Code example on both cases? > >> >> If one blindly replaces strncpy with strscpy across all uses, one >> could unintentionally be truncating the results and introduce new >> bugs. >> >> The real insecurity surely comes when one tries to use the string. >> For example: >> >> #include >> #include >> >> int main() { >> char a[10] = "HelloThere"; >> char b[10]; >> char c[10] = "Overflow"; >> strncpy(b, a, 10); >> /* This overflows and so in unsafe */ >> printf("a is %s\n", a); >> /* This overflows and so in unsafe */ >> printf("b is %s\n", b); >> /* This is safe */ >> printf("b is %.*s\n", 10, a); >> /* This is safe */ >> printf("b is %.*s\n", 4, a); >> return 0; >> } > > What if printf("a is %.*s\n", a);? > >> >> >> So, why isn't the printk format specifier "%.*s" used more instead of >> "%s" in the kernel? > > Since basically strings are pointers. > > Thanks. > -- ~Randy