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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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






[Index of Archives]     [Kernel Development]     [Kernel Announce]     [Kernel Newbies]     [Linux Networking Development]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Device Mapper]

  Powered by Linux