Message ID | 20231030-strncpy-drivers-scsi-ibmvscsi_tgt-ibmvscsi_tgt-c-v1-1-859b5ce257fd@google.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:d641:0:b0:403:3b70:6f57 with SMTP id cy1csp2523613vqb; Mon, 30 Oct 2023 14:43:37 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHyuMXV8BszjheajHp/7s1S/w5CQR+Quqpc9BwoZJvJzmA+L1FpQIUpDrnpxGXnafhDD1dN X-Received: by 2002:a17:903:246:b0:1ca:2743:bf79 with SMTP id j6-20020a170903024600b001ca2743bf79mr14449366plh.39.1698702217380; Mon, 30 Oct 2023 14:43:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1698702217; cv=none; d=google.com; s=arc-20160816; b=YhneyBTJn1wTtknIUQmzd82z92xSmnK59kzuPV4riynQYvIT6ejYdrwwgk6AvWn6Pl bUkpVgNU+owpXag7Yrcwwv5EqiFjup4YWHT/oseFHqKJEvyF6jWSQQoUMYb9zEEcBDDB dgysqodA2YD5EHf6lU4Bd1k8iNvQ6AA4u4Koz5zkUlINjXpI90NRIm4KAmw6hkj2AHbn eOYP/AKfj02SzHSHBYUE8j2dSzewJCukj8tvkELwMlec7TdtGzPrvpIzln5llErWFGOG qLjo/Lb8fy2RLizHNBEcja+hPdFmiwxgPZoIb+JFKQlXaMuGNpPT/DfU5I7UQ71Sd36s Pu4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:message-id:mime-version:date :dkim-signature; bh=e0/kVkiQLU+xIRwt52fqnoXoD0xR1x3vYThaNEUFKi4=; fh=9nN+20GUuauFBbl9lHDsuzt67x5mcfDBSUHGGDSXPyQ=; b=mGLpnMWJWMsPzrUJUF3+HYrU+k1WXlfQ+OCHdmnFJVYPSK6e531uaidd056uhfMN6K KcXQTFdVU6emQlzII+HYoT5Z9qwQrDv2ZbnfxXR2LxkLfKHThwXW9xCH5jM7RiCZSZhQ OkZ1zU5XWukgK51KO+5AvrQSevmU9Yps1ZYuVBBdf+PmqLW5FJNusXht75gS1xCC8F9n Xx6IWFdF7c/bpDCAesBakvU81UADVG76k1raLJCv4hHt8FBApihS+SDfBd28d3FHsofu fQRYhFEKzRjgKcnforA9lftglacWj6jdc1jYZpW7Nc+h8bShWBtYbzSevC2dkbzMT4jM Cadg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=fUFX6S1F; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from snail.vger.email (snail.vger.email. [2620:137:e000::3:7]) by mx.google.com with ESMTPS id c12-20020a170902724c00b001bb9e2c38ecsi5399987pll.264.2023.10.30.14.43.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Oct 2023 14:43:37 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=fUFX6S1F; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id 9643080BBE81; Mon, 30 Oct 2023 14:43:36 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232050AbjJ3Vnd (ORCPT <rfc822;chrisjones.unixmen@gmail.com> + 32 others); Mon, 30 Oct 2023 17:43:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58174 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232021AbjJ3Vnb (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 30 Oct 2023 17:43:31 -0400 Received: from mail-yb1-xb49.google.com (mail-yb1-xb49.google.com [IPv6:2607:f8b0:4864:20::b49]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 61A66FA for <linux-kernel@vger.kernel.org>; Mon, 30 Oct 2023 14:43:29 -0700 (PDT) Received: by mail-yb1-xb49.google.com with SMTP id 3f1490d57ef6-da07b5e6f75so5167991276.0 for <linux-kernel@vger.kernel.org>; Mon, 30 Oct 2023 14:43:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1698702208; x=1699307008; darn=vger.kernel.org; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=e0/kVkiQLU+xIRwt52fqnoXoD0xR1x3vYThaNEUFKi4=; b=fUFX6S1FHiL4JEaW/hEsZKmn6RQRRxqm29qviKpUAA9k7GTUgJ1a0/v2rwnhqKaOph wfTsjdrhFNK5yTofrEIyb8YInqbIHYWCc11ykvkIi9dgvmATf4xiqdsruBoSTF0E1UIv Guxmt97LV/78/CdsuRxH3B9Jn2T2umjDV7ildiux+tzlWSXdNqHGs3goMHLEValVZsrU eVk1syHgeEIm4tTRCuQH8x7yOx3dlPanhd6cYya182BSZd1ixaVbXtfAdvzc7gvAiFtb uLHXvloSKqP3B95fOW2Du8vCTgtVTdWRnPqI1QH8o3DibQz93biK3WooGjwS80R8DtHI nzOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698702208; x=1699307008; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=e0/kVkiQLU+xIRwt52fqnoXoD0xR1x3vYThaNEUFKi4=; b=t/S5wXEfit5EiRygpqCfzbe9lXga9dzQHWZAH3lwNpec31S6jIA9uQyXiXtOvgwSQ7 ECyLgtdHef5MdpPM1X3gK8aAEJ3uHucedYBwdIASwKbGNatQDlpretIeXyOw6iGmTH02 RndeBX5ovNrk0i1w0L0/Yj1vIN8bkJ7v18xWlgjFloIEr1+KwWqaLPn9DYvAqel/3auM M34NI2FpQoODJFHo184aKQwiYBeenQjmLeLpM6pQHoWEQVEdKD2RktvdLdrotEiZee82 2SrKNio2iIAJmTA4FyNM36W4/BwGJdXZevv657iyFh2JJHSd0rwOvB0pP6+r4f3JA8tC XrkA== X-Gm-Message-State: AOJu0YyTYthwA+xR7kb1SGdy7jE4Gz9545xm5LvBeLVKE38jxKYEnDKV XIAR4QjassLYKbxMHDWHaO3p170yyvFGif+1nQ== X-Received: from jstitt-linux1.c.googlers.com ([fda3:e722:ac3:cc00:2b:ff92:c0a8:23b5]) (user=justinstitt job=sendgmr) by 2002:a25:a526:0:b0:da0:c924:4fdc with SMTP id h35-20020a25a526000000b00da0c9244fdcmr19773ybi.6.1698702208605; Mon, 30 Oct 2023 14:43:28 -0700 (PDT) Date: Mon, 30 Oct 2023 21:43:20 +0000 Mime-Version: 1.0 X-B4-Tracking: v=1; b=H4sIAHcjQGUC/1XNQQ6CMBCF4auQWTNJAW2EqxBiSjviLChkpmk0h Ltb3bl73+b9BygJk8JQHSCUWXmLBU1dgX+6uBByKIbWtF1jOoOaJPr9jUE4kyiqV0ae1/wd97S kf3i8uX4Ohq4Xay2U213owa9fcpzO8wNyWWNnggAAAA== X-Developer-Key: i=justinstitt@google.com; a=ed25519; pk=tC3hNkJQTpNX/gLKxTNQKDmiQl6QjBNCGKJINqAdJsE= X-Developer-Signature: v=1; a=ed25519-sha256; t=1698702207; l=3953; i=justinstitt@google.com; s=20230717; h=from:subject:message-id; bh=kOlkCIhi5msaDl4tWCdp680vEgZukUJWPpGc5Vel+XE=; b=Vh/XP+Dr4/JhN7ikIfweMhlTgzvJG5U7crnDcmM2QYApm4PKVv1/jXqzKmK5mqk409uzLD1Wg qe8yhsqwFwAAyBXiU35NozThSakmhUB28vdSQY/kuqTvIo/g0b8V3UV X-Mailer: b4 0.12.3 Message-ID: <20231030-strncpy-drivers-scsi-ibmvscsi_tgt-ibmvscsi_tgt-c-v1-1-859b5ce257fd@google.com> Subject: [PATCH] scsi: ibmvscsi_tgt: replace deprecated strncpy with strscpy From: Justin Stitt <justinstitt@google.com> To: Michael Cyr <mikecyr@linux.ibm.com>, "James E.J. Bottomley" <jejb@linux.ibm.com>, "Martin K. Petersen" <martin.petersen@oracle.com> Cc: linux-scsi@vger.kernel.org, target-devel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org, Justin Stitt <justinstitt@google.com> Content-Type: text/plain; charset="utf-8" X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Mon, 30 Oct 2023 14:43:36 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1781218376207347857 X-GMAIL-MSGID: 1781218376207347857 |
Series |
scsi: ibmvscsi_tgt: replace deprecated strncpy with strscpy
|
|
Commit Message
Justin Stitt
Oct. 30, 2023, 9:43 p.m. UTC
strncpy() is deprecated for use on NUL-terminated destination strings
[1] and as such we should prefer more robust and less ambiguous string
interfaces.
We don't need the NUL-padding behavior that strncpy() provides as vscsi
is NUL-allocated in ibmvscsis_probe() which proceeds to call
ibmvscsis_adapter_info():
| vscsi = kzalloc(sizeof(*vscsi), GFP_KERNEL);
ibmvscsis_probe() -> ibmvscsis_handle_crq() -> ibmvscsis_parse_command()
-> ibmvscsis_mad() -> ibmvscsis_process_mad() -> ibmvscsis_adapter_info()
Following the same idea, `partition_name` is defiend as:
| static char partition_name[PARTITION_NAMELEN] = "UNKNOWN";
... which is NUL-padded already, meaning strscpy() is the best option.
Considering the above, a suitable replacement is `strscpy` [2] due to
the fact that it guarantees NUL-termination on the destination buffer
without unnecessarily NUL-padding.
However, for cap->name let's use strscpy_pad as cap is allocated via
dma_alloc_coherent():
| cap = dma_alloc_coherent(&vscsi->dma_dev->dev, olen, &token,
| GFP_ATOMIC);
Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1]
Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2]
Link: https://github.com/KSPP/linux/issues/90
Cc: linux-hardening@vger.kernel.org
Signed-off-by: Justin Stitt <justinstitt@google.com>
---
Note: build-tested only.
Found with: $ rg "strncpy\("
---
drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
---
base-commit: ffc253263a1375a65fa6c9f62a893e9767fbebfa
change-id: 20231030-strncpy-drivers-scsi-ibmvscsi_tgt-ibmvscsi_tgt-c-8a9bd0e54666
Best regards,
--
Justin Stitt <justinstitt@google.com>
Comments
On Mon, Oct 30, 2023 at 09:43:20PM +0000, Justin Stitt wrote: > strncpy() is deprecated for use on NUL-terminated destination strings > [1] and as such we should prefer more robust and less ambiguous string > interfaces. > > We don't need the NUL-padding behavior that strncpy() provides as vscsi > is NUL-allocated in ibmvscsis_probe() which proceeds to call > ibmvscsis_adapter_info(): > | vscsi = kzalloc(sizeof(*vscsi), GFP_KERNEL); > > ibmvscsis_probe() -> ibmvscsis_handle_crq() -> ibmvscsis_parse_command() > -> ibmvscsis_mad() -> ibmvscsis_process_mad() -> ibmvscsis_adapter_info() > > Following the same idea, `partition_name` is defiend as: > | static char partition_name[PARTITION_NAMELEN] = "UNKNOWN"; > > ... which is NUL-padded already, meaning strscpy() is the best option. > > Considering the above, a suitable replacement is `strscpy` [2] due to > the fact that it guarantees NUL-termination on the destination buffer > without unnecessarily NUL-padding. My only worry here is that I don't see if %NUL termination is _required_ for these variables. (i.e. do we run the risk of truncating these by 1 byte if they're right at the limit?) Are they __nonstring? I *think* they're %NUL terminated since they follow the same sizing as the global "partition_name", but I'm not sure. Can any of the SCSI authors comment on this? > > However, for cap->name let's use strscpy_pad as cap is allocated via > dma_alloc_coherent(): > | cap = dma_alloc_coherent(&vscsi->dma_dev->dev, olen, &token, > | GFP_ATOMIC); This is also true for the "info" allocation (it comes out of DMA). > > Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] > Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] > Link: https://github.com/KSPP/linux/issues/90 > Cc: linux-hardening@vger.kernel.org > Signed-off-by: Justin Stitt <justinstitt@google.com> > --- > Note: build-tested only. > > Found with: $ rg "strncpy\(" > --- > drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c | 14 +++++++------- > 1 file changed, 7 insertions(+), 7 deletions(-) > > diff --git a/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c b/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c > index 385f812b8793..cd223ef696e5 100644 > --- a/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c > +++ b/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c > @@ -1551,17 +1551,17 @@ static long ibmvscsis_adapter_info(struct scsi_info *vscsi, > if (vscsi->client_data.partition_number == 0) > vscsi->client_data.partition_number = > be32_to_cpu(info->partition_number); > - strncpy(vscsi->client_data.srp_version, info->srp_version, > + strscpy(vscsi->client_data.srp_version, info->srp_version, > sizeof(vscsi->client_data.srp_version)); > - strncpy(vscsi->client_data.partition_name, info->partition_name, > + strscpy(vscsi->client_data.partition_name, info->partition_name, > sizeof(vscsi->client_data.partition_name)); > vscsi->client_data.mad_version = be32_to_cpu(info->mad_version); > vscsi->client_data.os_type = be32_to_cpu(info->os_type); > > /* Copy our info */ > - strncpy(info->srp_version, SRP_VERSION, > + strscpy(info->srp_version, SRP_VERSION, > sizeof(info->srp_version)); > - strncpy(info->partition_name, vscsi->dds.partition_name, > + strscpy(info->partition_name, vscsi->dds.partition_name, > sizeof(info->partition_name)); Since "info" is from DMA, let's use the _pad variant here just to be safe. > info->partition_number = cpu_to_be32(vscsi->dds.partition_num); > info->mad_version = cpu_to_be32(MAD_VERSION_1); > @@ -1645,8 +1645,8 @@ static int ibmvscsis_cap_mad(struct scsi_info *vscsi, struct iu_entry *iue) > be64_to_cpu(mad->buffer), > vscsi->dds.window[LOCAL].liobn, token); > if (rc == H_SUCCESS) { > - strncpy(cap->name, dev_name(&vscsi->dma_dev->dev), > - SRP_MAX_LOC_LEN); > + strscpy_pad(cap->name, dev_name(&vscsi->dma_dev->dev), > + sizeof(cap->name)); And this is a safe conversion to sizeof(): struct capabilities { ... char name[SRP_MAX_LOC_LEN]; If we can convince ourselves that non of these are __nonstring types, then I think with the "info" change above, this should be good. -Kees
On 11/30/23 13:25, Kees Cook wrote: > On Mon, Oct 30, 2023 at 09:43:20PM +0000, Justin Stitt wrote: >> strncpy() is deprecated for use on NUL-terminated destination strings >> [1] and as such we should prefer more robust and less ambiguous string >> interfaces. >> >> We don't need the NUL-padding behavior that strncpy() provides as vscsi >> is NUL-allocated in ibmvscsis_probe() which proceeds to call >> ibmvscsis_adapter_info(): >> | vscsi = kzalloc(sizeof(*vscsi), GFP_KERNEL); >> >> ibmvscsis_probe() -> ibmvscsis_handle_crq() -> ibmvscsis_parse_command() >> -> ibmvscsis_mad() -> ibmvscsis_process_mad() -> ibmvscsis_adapter_info() >> >> Following the same idea, `partition_name` is defiend as: >> | static char partition_name[PARTITION_NAMELEN] = "UNKNOWN"; >> >> ... which is NUL-padded already, meaning strscpy() is the best option. >> >> Considering the above, a suitable replacement is `strscpy` [2] due to >> the fact that it guarantees NUL-termination on the destination buffer >> without unnecessarily NUL-padding. > > My only worry here is that I don't see if %NUL termination is _required_ > for these variables. (i.e. do we run the risk of truncating these by 1 > byte if they're right at the limit?) Are they __nonstring? > > I *think* they're %NUL terminated since they follow the same sizing as > the global "partition_name", but I'm not sure. > > Can any of the SCSI authors comment on this? Sorry, for a delayed response. I've just taken over the maintainer role as it had been left unaccounted for sometime. These are meant to be handled as C strings and nul termination is expected. -Tyrel > >> >> However, for cap->name let's use strscpy_pad as cap is allocated via >> dma_alloc_coherent(): >> | cap = dma_alloc_coherent(&vscsi->dma_dev->dev, olen, &token, >> | GFP_ATOMIC); > > This is also true for the "info" allocation (it comes out of DMA). > >> >> Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [1] >> Link: https://manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html [2] >> Link: https://github.com/KSPP/linux/issues/90 >> Cc: linux-hardening@vger.kernel.org >> Signed-off-by: Justin Stitt <justinstitt@google.com> >> --- >> Note: build-tested only. >> >> Found with: $ rg "strncpy\(" >> --- >> drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c | 14 +++++++------- >> 1 file changed, 7 insertions(+), 7 deletions(-) >> >> diff --git a/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c b/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c >> index 385f812b8793..cd223ef696e5 100644 >> --- a/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c >> +++ b/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c >> @@ -1551,17 +1551,17 @@ static long ibmvscsis_adapter_info(struct scsi_info *vscsi, >> if (vscsi->client_data.partition_number == 0) >> vscsi->client_data.partition_number = >> be32_to_cpu(info->partition_number); >> - strncpy(vscsi->client_data.srp_version, info->srp_version, >> + strscpy(vscsi->client_data.srp_version, info->srp_version, >> sizeof(vscsi->client_data.srp_version)); >> - strncpy(vscsi->client_data.partition_name, info->partition_name, >> + strscpy(vscsi->client_data.partition_name, info->partition_name, >> sizeof(vscsi->client_data.partition_name)); >> vscsi->client_data.mad_version = be32_to_cpu(info->mad_version); >> vscsi->client_data.os_type = be32_to_cpu(info->os_type); >> >> /* Copy our info */ >> - strncpy(info->srp_version, SRP_VERSION, >> + strscpy(info->srp_version, SRP_VERSION, >> sizeof(info->srp_version)); >> - strncpy(info->partition_name, vscsi->dds.partition_name, >> + strscpy(info->partition_name, vscsi->dds.partition_name, >> sizeof(info->partition_name)); > > Since "info" is from DMA, let's use the _pad variant here just to be > safe. > >> info->partition_number = cpu_to_be32(vscsi->dds.partition_num); >> info->mad_version = cpu_to_be32(MAD_VERSION_1); >> @@ -1645,8 +1645,8 @@ static int ibmvscsis_cap_mad(struct scsi_info *vscsi, struct iu_entry *iue) >> be64_to_cpu(mad->buffer), >> vscsi->dds.window[LOCAL].liobn, token); >> if (rc == H_SUCCESS) { >> - strncpy(cap->name, dev_name(&vscsi->dma_dev->dev), >> - SRP_MAX_LOC_LEN); >> + strscpy_pad(cap->name, dev_name(&vscsi->dma_dev->dev), >> + sizeof(cap->name)); > > And this is a safe conversion to sizeof(): > > struct capabilities { > ... > char name[SRP_MAX_LOC_LEN]; > > > If we can convince ourselves that non of these are __nonstring types, > then I think with the "info" change above, this should be good. > > -Kees >
diff --git a/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c b/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c index 385f812b8793..cd223ef696e5 100644 --- a/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c +++ b/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c @@ -1551,17 +1551,17 @@ static long ibmvscsis_adapter_info(struct scsi_info *vscsi, if (vscsi->client_data.partition_number == 0) vscsi->client_data.partition_number = be32_to_cpu(info->partition_number); - strncpy(vscsi->client_data.srp_version, info->srp_version, + strscpy(vscsi->client_data.srp_version, info->srp_version, sizeof(vscsi->client_data.srp_version)); - strncpy(vscsi->client_data.partition_name, info->partition_name, + strscpy(vscsi->client_data.partition_name, info->partition_name, sizeof(vscsi->client_data.partition_name)); vscsi->client_data.mad_version = be32_to_cpu(info->mad_version); vscsi->client_data.os_type = be32_to_cpu(info->os_type); /* Copy our info */ - strncpy(info->srp_version, SRP_VERSION, + strscpy(info->srp_version, SRP_VERSION, sizeof(info->srp_version)); - strncpy(info->partition_name, vscsi->dds.partition_name, + strscpy(info->partition_name, vscsi->dds.partition_name, sizeof(info->partition_name)); info->partition_number = cpu_to_be32(vscsi->dds.partition_num); info->mad_version = cpu_to_be32(MAD_VERSION_1); @@ -1645,8 +1645,8 @@ static int ibmvscsis_cap_mad(struct scsi_info *vscsi, struct iu_entry *iue) be64_to_cpu(mad->buffer), vscsi->dds.window[LOCAL].liobn, token); if (rc == H_SUCCESS) { - strncpy(cap->name, dev_name(&vscsi->dma_dev->dev), - SRP_MAX_LOC_LEN); + strscpy_pad(cap->name, dev_name(&vscsi->dma_dev->dev), + sizeof(cap->name)); len = olen - min_len; status = VIOSRP_MAD_SUCCESS; @@ -3650,7 +3650,7 @@ static int ibmvscsis_get_system_info(void) name = of_get_property(rootdn, "ibm,partition-name", NULL); if (name) - strncpy(partition_name, name, sizeof(partition_name)); + strscpy(partition_name, name, sizeof(partition_name)); num = of_get_property(rootdn, "ibm,partition-no", NULL); if (num)