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
