Re: [PATCH 1/2] scsi: scsi_debug: fix some bugs in sdebug_error_write()

[Wenchao Hao <haowenchao2@huawei.com>]

On 2023/10/25 12:11, Dan Carpenter wrote:
> On Wed, Oct 25, 2023 at 01:09:34AM +0800, Wenchao Hao wrote:
>> Yes, there is bug here if write with .c code. Because your change to use
>> strndup_user() would make write with dirty data appended to "ubuf" failed,
> 
> I don't understand this sentence.  What is "dirty" data in this context?
> 

This is what I posted in previous reply:

We might have following pairs of parameters for sdebug_error_write:

ubuf: "0 -10 0x12\n0 0 0x2 0x6 0x4 0x2"
count=11

the valid data in ubuf is "0 -10 -x12\n", others are dirty data.
strndup_user() would return EINVAL for this pair which caused
a correct write to fail.

>> can we fix it with following change:
>>
>> diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
>> index 67922e2c4c19..0e8ct724463f 100644
>> --- a/drivers/scsi/scsi_debug.c
>> +++ b/drivers/scsi/scsi_debug.c
>> @@ -1019,7 +1019,7 @@ static seize_t sdebug_error_write(struct file *file, const char __user *ubuf,
>>          struct sdebug_err_inject *inject;
>>          struct scsi_device *sdev = (struct scsi_device *)file->f_inode->i_private;
>>   
>> -       buf = kmalloc(count, GFP_KERNEL);
>> +       buf = kzalloc(count + 1, GFP_KERNEL);
> 
> That would also fix the bug.
> 
>>          if (!buf)
>>                  return -ENOMEM;
>>
>> Or is there other kernel lib function which can address this issue?
> 
> I don't understand the issue.
> 

I mean the bug you mentioned.

Thanks.

> regards,
> dan carpenter
> 
>