[PATCH] arch: parisc: kernel: using strlcpy() instead of strcpy()

[PATCH] arch: parisc: kernel: using strlcpy() instead of strcpy()

[Chen Gang]

'boot_args' is an input args, and 'boot_command_line' has a fix length.

So need use strlcpy() instead of strcpy() to avoid memory overflow.


Signed-off-by: Chen Gang <gang.chen@asianux.com>
---
 arch/parisc/kernel/setup.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/parisc/kernel/setup.c b/arch/parisc/kernel/setup.c
index 60c1ae6..7349a3f 100644
--- a/arch/parisc/kernel/setup.c
+++ b/arch/parisc/kernel/setup.c
@@ -69,7 +69,8 @@ void __init setup_cmdline(char **cmdline_p)
 		/* called from hpux boot loader */
 		boot_command_line[0] = '\0';
 	} else {
-		strcpy(boot_command_line, (char *)__va(boot_args[1]));
+		strlcpy(boot_command_line, (char *)__va(boot_args[1]),
+			COMMAND_LINE_SIZE);
 
 #ifdef CONFIG_BLK_DEV_INITRD
 		if (boot_args[2] != 0) /* did palo pass us a ramdisk? */
-- 
1.7.7.6

Re: [PATCH] arch: parisc: kernel: using strlcpy() instead of strcpy()

[Wang YanQing]

On Thu, May 30, 2013 at 09:18:43AM +0800, Chen Gang wrote:
> 
> 'boot_args' is an input args, and 'boot_command_line' has a fix length.
> 
> So need use strlcpy() instead of strcpy() to avoid memory overflow.
> 
> 
> Signed-off-by: Chen Gang <gang.chen@asianux.com>
> ---
>  arch/parisc/kernel/setup.c |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/parisc/kernel/setup.c b/arch/parisc/kernel/setup.c
> index 60c1ae6..7349a3f 100644
> --- a/arch/parisc/kernel/setup.c
> +++ b/arch/parisc/kernel/setup.c
> @@ -69,7 +69,8 @@ void __init setup_cmdline(char **cmdline_p)
>  		/* called from hpux boot loader */
>  		boot_command_line[0] = '\0';
>  	} else {
> -		strcpy(boot_command_line, (char *)__va(boot_args[1]));
> +		strlcpy(boot_command_line, (char *)__va(boot_args[1]),
> +			COMMAND_LINE_SIZE);

What about add 
boot_command_line[COMMAND_LINE_SIZE - 1] = '\0';
to protect the following another strcpy?

"
strcpy(command_line, boot_command_line);
"
>  
>  #ifdef CONFIG_BLK_DEV_INITRD
>  		if (boot_args[2] != 0) /* did palo pass us a ramdisk? */
> -- 
> 1.7.7.6

Re: [PATCH] arch: parisc: kernel: using strlcpy() instead of strcpy()

[Chen Gang]

On 05/30/2013 11:06 PM, Wang YanQing wrote:
> What about add 
> boot_command_line[COMMAND_LINE_SIZE - 1] = '\0';
> to protect the following another strcpy?
> 
> "
> strcpy(command_line, boot_command_line);
> "

If the 'dest' length is not less than COMMAND_LINE_SIZE, the strlcpy()
will copy 'COMMAND_LINE_SIZE - 1' contents, and always set '\0' in the end.

So the next strcpy() will be safe.


Thanks.
-- 
Chen Gang

Asianux Corporation

Re: [PATCH] arch: parisc: kernel: using strlcpy() instead of strcpy()

[Kyle McMartin]

On Thu, May 30, 2013 at 09:18:43AM +0800, Chen Gang wrote:
> 
> 'boot_args' is an input args, and 'boot_command_line' has a fix length.
> 
> So need use strlcpy() instead of strcpy() to avoid memory overflow.
> 

This is basically impossible, since boot_args is fixed in size by palo,
initialized to zero, and length checked in the bootloader. It's also
only 256+4 bytes compared to the 1024 bytes set aside for
boot_command_line.

That said, it's harmless to use strlcpy here, and obviously (more)
correct. Thanks!

Acked-by: Kyle McMartin <kyle@mcmartin.ca>

Re: [PATCH] arch: parisc: kernel: using strlcpy() instead of strcpy()

[Chen Gang]

On 05/30/2013 11:35 PM, Kyle McMartin wrote:
> On Thu, May 30, 2013 at 09:18:43AM +0800, Chen Gang wrote:
>> > 
>> > 'boot_args' is an input args, and 'boot_command_line' has a fix length.
>> > 
>> > So need use strlcpy() instead of strcpy() to avoid memory overflow.
>> > 
> This is basically impossible, since boot_args is fixed in size by palo,
> initialized to zero, and length checked in the bootloader. It's also
> only 256+4 bytes compared to the 1024 bytes set aside for
> boot_command_line.
> 
> That said, it's harmless to use strlcpy here, and obviously (more)
> correct. Thanks!
> 

OK, thanks.

> Acked-by: Kyle McMartin <kyle@mcmartin.ca>
> 
> 

Thank you. :-)


-- 
Chen Gang

Asianux Corporation