[PATCH] infiniband: hw: cxgb3: cxio_hal.c: Cleaning up missing null-terminate after strncpy call

[PATCH] infiniband: hw: cxgb3: cxio_hal.c: Cleaning up missing null-terminate after strncpy call

[Rickard Strandqvist]

Added a guaranteed null-terminate after call to strncpy.

Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
---
 drivers/infiniband/hw/cxgb3/cxio_hal.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/infiniband/hw/cxgb3/cxio_hal.c b/drivers/infiniband/hw/cxgb3/cxio_hal.c
index de1c61b4..5fc04e4 100644
--- a/drivers/infiniband/hw/cxgb3/cxio_hal.c
+++ b/drivers/infiniband/hw/cxgb3/cxio_hal.c
@@ -933,6 +933,7 @@ int cxio_rdev_open(struct cxio_rdev *rdev_p)
 		netdev_p = rdev_p->t3cdev_p->lldev;
 		strncpy(rdev_p->dev_name, rdev_p->t3cdev_p->name,
 			T3_MAX_DEV_NAME_LEN);
+		rdev_p->dev_name[T3_MAX_DEV_NAME_LEN - 1] = '\0';
 	} else {
 		PDBG("%s t3cdev_p or dev_name must be set\n", __func__);
 		return -EINVAL;
-- 
1.7.10.4

Re: [PATCH] infiniband: hw: cxgb3: cxio_hal.c: Cleaning up missing null-terminate after strncpy call

[Yann Droneaud]

Hi,

Le lundi 18 août 2014 à 00:40 +0200, Rickard Strandqvist a écrit :
> Added a guaranteed null-terminate after call to strncpy.
> 

Good catch. Do you have an automated way to catch such mistake ?

> Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
> ---
>  drivers/infiniband/hw/cxgb3/cxio_hal.c |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/infiniband/hw/cxgb3/cxio_hal.c b/drivers/infiniband/hw/cxgb3/cxio_hal.c
> index de1c61b4..5fc04e4 100644
> --- a/drivers/infiniband/hw/cxgb3/cxio_hal.c
> +++ b/drivers/infiniband/hw/cxgb3/cxio_hal.c
> @@ -933,6 +933,7 @@ int cxio_rdev_open(struct cxio_rdev *rdev_p)
>  		netdev_p = rdev_p->t3cdev_p->lldev;
>  		strncpy(rdev_p->dev_name, rdev_p->t3cdev_p->name,
>  			T3_MAX_DEV_NAME_LEN);
> +		rdev_p->dev_name[T3_MAX_DEV_NAME_LEN - 1] = '\0';

Why not replacing this by

		strlcpy(rdev_p->dev_name, rdev_p->t3cdev_p->name,
			T3_MAX_DEV_NAME_LEN);

Regards.

-- 
Yann Droneaud
OPTEYA

RE: [PATCH] infiniband: hw: cxgb3: cxio_hal.c: Cleaning up missing null-terminate after strncpy call

[Steve Wise]

> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-owner@vger.kernel.org]
> On Behalf Of Rickard Strandqvist
> Sent: Sunday, August 17, 2014 5:40 PM
> To: Steve Wise; Roland Dreier
> Cc: Rickard Strandqvist; Sean Hefty; Hal Rosenstock; linux-rdma@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Subject: [PATCH] infiniband: hw: cxgb3: cxio_hal.c: Cleaning up missing null-terminate
after
> strncpy call
> 
> Added a guaranteed null-terminate after call to strncpy.
> 
> Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
> ---
>  drivers/infiniband/hw/cxgb3/cxio_hal.c |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/infiniband/hw/cxgb3/cxio_hal.c
> b/drivers/infiniband/hw/cxgb3/cxio_hal.c
> index de1c61b4..5fc04e4 100644
> --- a/drivers/infiniband/hw/cxgb3/cxio_hal.c
> +++ b/drivers/infiniband/hw/cxgb3/cxio_hal.c
> @@ -933,6 +933,7 @@ int cxio_rdev_open(struct cxio_rdev *rdev_p)
>  		netdev_p = rdev_p->t3cdev_p->lldev;
>  		strncpy(rdev_p->dev_name, rdev_p->t3cdev_p->name,
>  			T3_MAX_DEV_NAME_LEN);
> +		rdev_p->dev_name[T3_MAX_DEV_NAME_LEN - 1] = '\0';
>  	} else {
>  		PDBG("%s t3cdev_p or dev_name must be set\n", __func__);
>  		return -EINVAL;

cxio_rdev_open() is called only by open_rnic_dev() which allocates the device structure by
calling ib_alloc_device() which uses kzalloc().  So this change really isn't needed, is
it?

Steve.

Re: [PATCH] infiniband: hw: cxgb3: cxio_hal.c: Cleaning up missing null-terminate after strncpy call

[Rickard Strandqvist]

2014-08-18 16:27 GMT+02:00 Steve Wise <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>:
>
>
>> -----Original Message-----
>> From: linux-kernel-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org [mailto:linux-kernel-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org]
>> On Behalf Of Rickard Strandqvist
>> Sent: Sunday, August 17, 2014 5:40 PM
>> To: Steve Wise; Roland Dreier
>> Cc: Rickard Strandqvist; Sean Hefty; Hal Rosenstock; linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-
>> kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> Subject: [PATCH] infiniband: hw: cxgb3: cxio_hal.c: Cleaning up missing null-terminate
> after
>> strncpy call
>>
>> Added a guaranteed null-terminate after call to strncpy.
>>
>> Signed-off-by: Rickard Strandqvist <rickard_strandqvist-IW2WV5XWFqGZkjO+N0TKoMugMpMbD5Xr@public.gmane.org>
>> ---
>>  drivers/infiniband/hw/cxgb3/cxio_hal.c |    1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/infiniband/hw/cxgb3/cxio_hal.c
>> b/drivers/infiniband/hw/cxgb3/cxio_hal.c
>> index de1c61b4..5fc04e4 100644
>> --- a/drivers/infiniband/hw/cxgb3/cxio_hal.c
>> +++ b/drivers/infiniband/hw/cxgb3/cxio_hal.c
>> @@ -933,6 +933,7 @@ int cxio_rdev_open(struct cxio_rdev *rdev_p)
>>               netdev_p = rdev_p->t3cdev_p->lldev;
>>               strncpy(rdev_p->dev_name, rdev_p->t3cdev_p->name,
>>                       T3_MAX_DEV_NAME_LEN);
>> +             rdev_p->dev_name[T3_MAX_DEV_NAME_LEN - 1] = '\0';
>>       } else {
>>               PDBG("%s t3cdev_p or dev_name must be set\n", __func__);
>>               return -EINVAL;
>
> cxio_rdev_open() is called only by open_rnic_dev() which allocates the device structure by
> calling ib_alloc_device() which uses kzalloc().  So this change really isn't needed, is
> it?
>
> Steve.
>



Hi

Sure, strlcpy is preferable in many ways if we only can guarantee that
it is safe.
I have seldom received so much criticism when I start switching to
strlcpy, although much of it was justified :)
Even Linus was getting into the debate.  See more:

https://plus.google.com/111049168280159033135/posts/1amLbuhWbh5


I change to strlcpy only when I'm sure it will not cause any other problems.
But if you or anyone else can guarantee that in this case, so I'd make
a new patch with strlcpy.

And no Steve, or then you have to use:
strncpy(rdev_p->dev_name, rdev_p->t3cdev_p->name,
                        T3_MAX_DEV_NAME_LEN - 1);

But the kzalloc should mean that there will not be a problem to switch
to strlcpy ..

Do we agree, I'll make a new path with strlcpy?


I have run a static code analysis programs cppcheck, including finding
this type of problem.
But since I noticed that there were so many mistakes in addition, I
have now looked through all use of strncpy in kernel


Kind regards
Rickard Strandqvist
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html