Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751438AbdGYJgD convert rfc822-to-8bit (ORCPT ); Tue, 25 Jul 2017 05:36:03 -0400 Received: from smtp-out4.electric.net ([192.162.216.187]:58526 "EHLO smtp-out4.electric.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751034AbdGYJgA (ORCPT ); Tue, 25 Jul 2017 05:36:00 -0400 From: David Laight To: "'Rustad, Mark D'" , Florian Fainelli CC: Salil Mehta , "davem@davemloft.net" , "yisen.zhuang@huawei.com" , "huangdaode@hisilicon.com" , "lipeng321@huawei.com" , "mehta.salil.lnk@gmail.com" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-rdma@vger.kernel.org" , "linuxarm@huawei.com" Subject: RE: [PATCH V4 net-next 7/8] net: hns3: Add Ethtool support to HNS3 driver Thread-Topic: [PATCH V4 net-next 7/8] net: hns3: Add Ethtool support to HNS3 driver Thread-Index: AQHTAzei9/ithVoLOUK1fG1D/dHApKJiGo4AgAHMMYCAAGSssA== Date: Tue, 25 Jul 2017 09:35:51 +0000 Message-ID: <063D6719AE5E284EB5DD2968C1650D6DD003FB65@AcuExch.aculab.com> References: <20170722220942.78852-1-salil.mehta@huawei.com> <20170722220942.78852-8-salil.mehta@huawei.com> <23ddbe00-8bef-a09b-5783-3a5438086bd6@gmail.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.99.200] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-Outbound-IP: 156.67.243.126 X-Env-From: David.Laight@ACULAB.COM X-Proto: esmtps X-Revdns: X-HELO: AcuExch.aculab.com X-TLS: TLSv1:AES128-SHA:128 X-Authenticated_ID: X-PolicySMART: 3396946, 3397078 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 770 Lines: 21 From: Rustad, Mark D > Sent: 24 July 2017 21:32 > > On Jul 23, 2017, at 10:05 AM, Florian Fainelli wrote: > >> + > >> + strncpy(drvinfo->version, HNAE_DRIVER_VERSION, > >> + sizeof(drvinfo->version)); > >> + drvinfo->version[sizeof(drvinfo->version) - 1] = '\0'; > > > > strlcpy() would probably do that for you. > > You need to be careful about strlcpy - it does not completely write the destination buffer as strncpy > does, and so can result in a kernel memory leak if the destination is not known to already be cleared. Not only that, strlcpy() is defined to return the size of the source string. So if the source buffers isn't '\0' terminated it can fault. (Not a problem above.) Neither function is the one you were looking for. David