Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp616735ybe; Wed, 11 Sep 2019 01:58:33 -0700 (PDT) X-Google-Smtp-Source: APXvYqwrFnkkJ8spUtXNpjNinb7iRXHjVHbpgwtXdvSapFSpIaU50/ocsBtydNP/ggBX9wevtIe3 X-Received: by 2002:a17:906:a3d2:: with SMTP id ca18mr28634558ejb.194.1568192313119; Wed, 11 Sep 2019 01:58:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568192313; cv=none; d=google.com; s=arc-20160816; b=BeO4JQUHHM7Pf3zYrQzLfIrZbmFPhFNLBr+b2XIqVQ99oinPPHObW3ulXcBqSkUIwL AAjcoBjJsDnoWCFo3fv4XCnmaq56F/EOqpkvHUaWkGcc00DYCcDqEUgDbnVeVDejFonJ kf+qdIymEj2V3A4Y/YcafWlr8MSEpPy2zNYmceEn7Ka+17YfgDt2+gKowgDpb2+Pj5FY mtynI2MJ6xYg53qBnyEm9C4O8eAaS3lN1Z6tKEsXxpkT5gw2XIN3l4+Nz4Hx4vUyivLP tPO5rnkHd03VOGJThdV+ohsJkvQjP5mPSFYX96Dbxew34l6XxK5GsnkZjLUDFdyn1aaR T7Qw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=/E13juu/FtC97zR3HMtA4Q3ZzUhvcKxTohP/DIrieFE=; b=PVJy4a8Bw7dCqZPW/BMxTLFr/mztf+JEcLnMeBwgWwiU/YAMwd7ptW+1GR/7Fgh7fx GEEhuZ1mB1P3m5PDnW3F5MNd2hBXAm753S75qqXSQ4W0HXMsLCW9jYRNKQbtTlkrIg/P rEHNTUmDt+8vViNGG3pHNTpU2nYfzyFBSIv1PNFGPkQ1l4C6jdx0ZXRsbk024zxzp4bB Lok7C9qIBSUapETcot39LDCBoQON9GlaQXsSOMQU9bbxeTHc8XaMPQyIuGsYyD3hLhk2 OD73jxjYbFgdeYtM1SXOvKeBRX4CAoDvg3FePc/aTlcFjlJja9b5qJeq5ilNC3OTA8v1 4BYw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@rasmusvillemoes.dk header.s=google header.b=BcqK+uXn; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h4si12206162edd.189.2019.09.11.01.58.08; Wed, 11 Sep 2019 01:58:33 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@rasmusvillemoes.dk header.s=google header.b=BcqK+uXn; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726911AbfIKI4V (ORCPT + 99 others); Wed, 11 Sep 2019 04:56:21 -0400 Received: from mail-lj1-f194.google.com ([209.85.208.194]:36558 "EHLO mail-lj1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726579AbfIKI4V (ORCPT ); Wed, 11 Sep 2019 04:56:21 -0400 Received: by mail-lj1-f194.google.com with SMTP id l20so19220898ljj.3 for ; Wed, 11 Sep 2019 01:56:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rasmusvillemoes.dk; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=/E13juu/FtC97zR3HMtA4Q3ZzUhvcKxTohP/DIrieFE=; b=BcqK+uXn+oKcHQci2VioBov/yYrGjlPkyn/T/kLLSbgWOlSSf+NsSr9tcr+eWTkHB+ jsfLdzZTp6C+J0ho7T2xrzmgZFcpO3Px/xdP0U/++BsKxOVGHFqBD5k1MeTP8WuVczL+ 0urtdMdVcnVQrzmqR98SdvyOPtyUvsVnd8Eb8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=/E13juu/FtC97zR3HMtA4Q3ZzUhvcKxTohP/DIrieFE=; b=VRhXh5x8mSo6WqGXCNsbEgGEnBK5mwjhf3o5d3ZgIEqTRcNtp21JzCf+T7GmUv24Oo /u8xLK5IPopSckiFDwgC91N0y1Dk1gxYlhETnhaYDSPEU28um1X+LFhGhLC9F5ZXM+E6 HO9uCwJIDoWpXV7LANtc6eNiuQ7UmCwLk2l7IJTlCXW6UEshVO2REurohdacA3sRttMT sHSzKQtT2dzv6Qs+kCDTqm9EC2Tpg3yCDzc8JD6H8xvB/v8FUmpMz2JAz1NuAx+u7cfb ezP1AoP24FW+4I4TywB4NMRkeel3H/cSXB8Meo3+SE/udCaoqJ8GsYULr0eMId+ufKZY Sovg== X-Gm-Message-State: APjAAAWeTRJwxeCKVj4Ny6zOcEYzDYpHE4SGSH+96T4vkkZKl617w4ci MzV81R5AtSDkBAZrwnPBOXNHhhqrTHICRZcX X-Received: by 2002:a2e:a313:: with SMTP id l19mr6461495lje.205.1568192177571; Wed, 11 Sep 2019 01:56:17 -0700 (PDT) Received: from [172.16.11.28] ([81.216.59.226]) by smtp.gmail.com with ESMTPSA id t82sm4987346lff.58.2019.09.11.01.56.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Sep 2019 01:56:16 -0700 (PDT) Subject: Re: [PATCH] Staging: exfat: Avoid use of strcpy To: Dan Carpenter , Sandro Volery Cc: valdis.kletnieks@vt.edu, gregkh@linuxfoundation.org, devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org References: <20190911055749.GA10786@volery> <20190911084111.GG15977@kadam> From: Rasmus Villemoes Message-ID: <214f3b20-fac4-df5e-6b3c-a08a19a8ea42@rasmusvillemoes.dk> Date: Wed, 11 Sep 2019 10:56:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190911084111.GG15977@kadam> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/09/2019 10.41, Dan Carpenter wrote: > On Wed, Sep 11, 2019 at 07:57:49AM +0200, Sandro Volery wrote: >> Replaced strcpy with strscpy in exfat_core.c. >> >> Signed-off-by: Sandro Volery >> --- >> drivers/staging/exfat/exfat_core.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/staging/exfat/exfat_core.c b/drivers/staging/exfat/exfat_core.c >> index da8c58149c35..c71b145e8a24 100644 >> --- a/drivers/staging/exfat/exfat_core.c >> +++ b/drivers/staging/exfat/exfat_core.c >> @@ -2964,7 +2964,7 @@ s32 resolve_path(struct inode *inode, char *path, struct chain_t *p_dir, >> if (strlen(path) >= (MAX_NAME_LENGTH * MAX_CHARSET_SIZE)) >> return FFS_INVALIDPATH; >> >> - strcpy(name_buf, path); >> + strscpy(name_buf, path, sizeof(name_buf)); > > It checked strlen() earlier so we know that it can't overflow but, oh > wow, the "name_buf" is a shared buffer. wow wow wow. This seems very > racy. Yeah, and note that the callers of resolve_path do seem to take a lock, but that's not a global lock but a per-superblock (or per-something-else) one... Obviously exfat should not rely on such a single static buffer, but in the meantime, perhaps one should add a name_buf_lock (though I don't know how long name_buf is actually in use, so that needs checking). Apart from the broken/lack of locking, it would be better to combine the copying and length checking into a single check - i.e. do if (strscpy(name_buf, path, sizeof(name_buf)) < 0) return FFS_INVALIDPATH; That's both more efficient and fixes the open-coding of sizeof(name_buf) that is currently used in the if(). Rasmus