diff mbox series

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

Message ID 96d50cf7-afec-46af-9d98-08099f8dc76e@moroto.mountain
State New
Headers show
Series [1/2] scsi: scsi_debug: fix some bugs in sdebug_error_write() | expand

Commit Message

Dan Carpenter Oct. 20, 2023, 2:15 p.m. UTC
There are two bug in this code:
1) If count is zero, then it will lead to a NULL dereference.  The
kmalloc() will successfully allocate zero bytes and the test for
"if (buf[0] == '-')" will read beyond the end of the zero size buffer
and Oops.
2) The code does not ensure that the user's string is properly NUL
terminated which could lead to a read overflow.

Fortunately, this is debugfs code and only root can write to it so
the security impact of these bugs is negligable.

Fixes: a9996d722b11 ("scsi: scsi_debug: Add interface to manage error injection for a single device")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
---
 drivers/scsi/scsi_debug.c                      | 11 +++--------
 1 file changed, 3 insertions(+), 8 deletions(-)

Comments

Wenchao Hao Oct. 21, 2023, 10:10 a.m. UTC | #1
On Fri, Oct 20, 2023 at 10:15 PM Dan Carpenter <dan.carpenter@linaro.org> wrote:
>
> There are two bug in this code:

Thanks for your fix, some different points of view as follows.

> 1) If count is zero, then it will lead to a NULL dereference.  The
> kmalloc() will successfully allocate zero bytes and the test for
> "if (buf[0] == '-')" will read beyond the end of the zero size buffer
> and Oops.

This sysfs interface is usually used by cmdline, mostly, "echo" is used
to write it and "echo" always writes with '\n' terminated, which would
not cause a write with count=0.

While in terms of security, we should add a check for count==0
condition and return EINVAL.

> 2) The code does not ensure that the user's string is properly NUL
> terminated which could lead to a read overflow.
>

I don't think so, the copy_from_user() would limit the accessed length
to count, so no read overflow would happen.

Userspace's write would allocate a buffer larger than it actually
needed(usually 4K), but the buffer would not be cleared, so some
dirty data would be passed to the kernel space.

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.

You can recurrent the above error with my script attached.

Thanks.

> Fortunately, this is debugfs code and only root can write to it so
> the security impact of these bugs is negligable.
>
> Fixes: a9996d722b11 ("scsi: scsi_debug: Add interface to manage error injection for a single device")
> Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
> ---
>  drivers/scsi/scsi_debug.c                      | 11 +++--------
>  1 file changed, 3 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
> index 67922e2c4c19..0a4e41d84df8 100644
> --- a/drivers/scsi/scsi_debug.c
> +++ b/drivers/scsi/scsi_debug.c
> @@ -1019,14 +1019,9 @@ static ssize_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);
> -       if (!buf)
> -               return -ENOMEM;
> -
> -       if (copy_from_user(buf, ubuf, count)) {
> -               kfree(buf);
> -               return -EFAULT;
> -       }
> +       buf = strndup_user(ubuf, count + 1);
> +       if (IS_ERR(buf))
> +               return PTR_ERR(buf);
>
>         if (buf[0] == '-')
>                 return sdebug_err_remove(sdev, buf, count);
> --
> 2.42.0
>
Dan Carpenter Oct. 23, 2023, 1:39 p.m. UTC | #2
On Sat, Oct 21, 2023 at 06:10:44PM +0800, Wenchao Hao wrote:
> On Fri, Oct 20, 2023 at 10:15 PM Dan Carpenter <dan.carpenter@linaro.org> wrote:
> >
> > There are two bug in this code:
> 
> Thanks for your fix, some different points of view as follows.
> 
> > 1) If count is zero, then it will lead to a NULL dereference.  The
> > kmalloc() will successfully allocate zero bytes and the test for
> > "if (buf[0] == '-')" will read beyond the end of the zero size buffer
> > and Oops.
> 
> This sysfs interface is usually used by cmdline, mostly, "echo" is used
> to write it and "echo" always writes with '\n' terminated, which would
> not cause a write with count=0.
> 

You are saying "sysfs" but this is debugfs.  Sysfs is completely
different.  Also saying that 'and "echo" always writes with '\n'
terminated' is not true either even in sysfs...

> While in terms of security, we should add a check for count==0
> condition and return EINVAL.

Checking for zero is a valid approach.  I considered that but my way
was cleaner.

> 
> > 2) The code does not ensure that the user's string is properly NUL
> > terminated which could lead to a read overflow.
> >
> 
> I don't think so, the copy_from_user() would limit the accessed length
> to count, so no read overflow would happen.
> 
> Userspace's write would allocate a buffer larger than it actually
> needed(usually 4K), but the buffer would not be cleared, so some
> dirty data would be passed to the kernel space.
> 
> 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.
> 
> You can recurrent the above error with my script attached.

You're looking for the buffer overflow in the wrong place.

drivers/scsi/scsi_debug.c
  1026          if (copy_from_user(buf, ubuf, count)) {
                                   ^^^
We copy data from the user but it is not NUL terminated.

  1027                  kfree(buf);
  1028                  return -EFAULT;
  1029          }
  1030  
  1031          if (buf[0] == '-')
  1032                  return sdebug_err_remove(sdev, buf, count);
  1033  
  1034          if (sscanf(buf, "%d", &inject_type) != 1) {
                           ^^^
This will read beyond the end of the buffer.  sscanf() relies on a NUL
terminator to know when then end of the string is.

  1035                  kfree(buf);
  1036                  return -EINVAL;
  1037          }

Obviously the user in this situation is like a hacker who wants to do
something bad, not a normal users.  For a normal user this code is fine
as you say.

You will need to test this with .c code instead of shell if you want to
see the bug.

regards,
dan carpenter
Wenchao Hao Nov. 3, 2023, 6 p.m. UTC | #3
On 10/25/23 3:07 PM, Dan Carpenter wrote:
> On Wed, Oct 25, 2023 at 02:10:41PM +0800, Wenchao Hao wrote:
>> 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.
> 
> I mean, I could just tell you that your kzalloc(count + 1, GFP_KERNEL)
> fix will work.  It does work.
> 
> But how is passing "dirty data" a "correct write"?  I feel like it
> should be treated as incorrect and returning -EINVAL is the correct
> behavior.  I'm so confused.  Why are users doing that?
> 
> I have looked at the code and it just doesn't seem that complicated.
> They shouldn't be passing messed up strings and expect the kernel to
> allow it.
> 

First, echo command would call write() system call with string which is
terminated with '\n'. (I come to this conclusion with strace, but did not
check the source code of echo). So when we input echo "0 -10 0x12" > $error,
following pairs would be passed to sdebug_error_write:

ubuf: "0 -10 0x12\n"
count: 11

Second, it seems shell sh would not clean the dirty of previous execution.
For example, dirty data is passed to sdebug_error_write with following steps. 

echo "2 -10 0x1b 0 0 0x2 0x6 0x4 0x2" > /sys/kernel/debug/scsi_debug/3:0:0:0/error
echo "0 -10 0x1b" > /sys/kernel/debug/scsi_debug/3:0:0:0/error

I trace the parameters of sdebug_error_write with probe, following log is printed
when executing above two echo commands:

trace log:

# tracer: nop
#
# entries-in-buffer/entries-written: 2/2   #P:8
#
#                                _-----=> irqs-off/BH-disabled
#                               / _----=> need-resched
#                              | / _---=> hardirq/softirq
#                              || / _--=> preempt-depth
#                              ||| / _-=> migrate-disable
#                              |||| /     delay
#           TASK-PID     CPU#  |||||  TIMESTAMP  FUNCTION
#              | |         |   |||||     |         |
              sh-13912   [007] ..... 482676.030303: sdebug_error_write: (sdebug_error_write+0x0/0x321 [scsi_debug]) comm="sh" count=31 ubuf="2 -10 0x1b 0 0 0x2 0x6 0x4 0x2
"
              sh-13912   [007] ..... 482676.030525: sdebug_error_write: (sdebug_error_write+0x0/0x321 [scsi_debug]) comm="sh" count=11 ubuf="0 -10 0x1b
0 0 0x2 0x6 0x4 0x2
"

Here is command to add kprobe trace:
echo 'p:sdebug_error_write sdebug_error_write comm=$comm count=$arg3:u64 ubuf=+0($arg2):ustring' >> /sys/kernel/debug/tracing/kprobe_events

It is proved that dirty data does exist, so I think we should now use strndup_user() here.

Thanks.

> regards,
> dan carpenter
>
Wenchao Hao Nov. 3, 2023, 6:13 p.m. UTC | #4
On 11/4/23 2:00 AM, Wenchao Hao wrote:
> On 10/25/23 3:07 PM, Dan Carpenter wrote:
>> On Wed, Oct 25, 2023 at 02:10:41PM +0800, Wenchao Hao wrote:
>>> 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.
>>
>> I mean, I could just tell you that your kzalloc(count + 1, GFP_KERNEL)
>> fix will work.  It does work.
>>
>> But how is passing "dirty data" a "correct write"?  I feel like it
>> should be treated as incorrect and returning -EINVAL is the correct
>> behavior.  I'm so confused.  Why are users doing that?
>>
>> I have looked at the code and it just doesn't seem that complicated.
>> They shouldn't be passing messed up strings and expect the kernel to
>> allow it.
>>
> 
> First, echo command would call write() system call with string which is
> terminated with '\n'. (I come to this conclusion with strace, but did not
> check the source code of echo). So when we input echo "0 -10 0x12" > $error,
> following pairs would be passed to sdebug_error_write:
> 
> ubuf: "0 -10 0x12\n"
> count: 11
> 
> Second, it seems shell sh would not clean the dirty of previous execution.
> For example, dirty data is passed to sdebug_error_write with following steps. 
> 
> echo "2 -10 0x1b 0 0 0x2 0x6 0x4 0x2" > /sys/kernel/debug/scsi_debug/3:0:0:0/error
> echo "0 -10 0x1b" > /sys/kernel/debug/scsi_debug/3:0:0:0/error
> 
> I trace the parameters of sdebug_error_write with probe, following log is printed
> when executing above two echo commands:
> 
> trace log:
> 
> # tracer: nop
> #
> # entries-in-buffer/entries-written: 2/2   #P:8
> #
> #                                _-----=> irqs-off/BH-disabled
> #                               / _----=> need-resched
> #                              | / _---=> hardirq/softirq
> #                              || / _--=> preempt-depth
> #                              ||| / _-=> migrate-disable
> #                              |||| /     delay
> #           TASK-PID     CPU#  |||||  TIMESTAMP  FUNCTION
> #              | |         |   |||||     |         |
>               sh-13912   [007] ..... 482676.030303: sdebug_error_write: (sdebug_error_write+0x0/0x321 [scsi_debug]) comm="sh" count=31 ubuf="2 -10 0x1b 0 0 0x2 0x6 0x4 0x2
> "
>               sh-13912   [007] ..... 482676.030525: sdebug_error_write: (sdebug_error_write+0x0/0x321 [scsi_debug]) comm="sh" count=11 ubuf="0 -10 0x1b
> 0 0 0x2 0x6 0x4 0x2
> "
> 
> Here is command to add kprobe trace:
> echo 'p:sdebug_error_write sdebug_error_write comm=$comm count=$arg3:u64 ubuf=+0($arg2):ustring' >> /sys/kernel/debug/tracing/kprobe_events
> 
> It is proved that dirty data does exist, so I think we should now use strndup_user() here.

Sorry, its "should not use strndup_user()".

Thanks.

> 
> Thanks.
> 
>> regards,
>> dan carpenter
>>
>
Dan Carpenter Nov. 6, 2023, 1:44 p.m. UTC | #5
Oh.  Duh.  The issue is that echo doesn't actually put a NUL terminator
on the end of the string...  Let's go with kzalloc(count + 1, as you
suggest.

regards,
dan carpenter
diff mbox series

Patch

diff --git a/drivers/scsi/scsi_debug.c b/drivers/scsi/scsi_debug.c
index 67922e2c4c19..0a4e41d84df8 100644
--- a/drivers/scsi/scsi_debug.c
+++ b/drivers/scsi/scsi_debug.c
@@ -1019,14 +1019,9 @@  static ssize_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);
-	if (!buf)
-		return -ENOMEM;
-
-	if (copy_from_user(buf, ubuf, count)) {
-		kfree(buf);
-		return -EFAULT;
-	}
+	buf = strndup_user(ubuf, count + 1);
+	if (IS_ERR(buf))
+		return PTR_ERR(buf);
 
 	if (buf[0] == '-')
 		return sdebug_err_remove(sdev, buf, count);