All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Randy.Dunlap" <rddunlap@osdl.org>
To: Robert Hancock <hancockr@shaw.ca>
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: Taking strlen of buffers copied from userspace
Date: Tue, 15 Mar 2005 20:20:35 -0800	[thread overview]
Message-ID: <4237B413.8070501@osdl.org> (raw)
In-Reply-To: <4237763A.6080601@shaw.ca>

Robert Hancock wrote:
> Artem Frolov wrote:
> 
>> Hello,
>>
>> I am in the process of testing static defect analyzer on a Linux
>> kernel source code (see disclosure below).
>>
>> I found some potential array bounds violations. The pattern is as
>> follows: bytes are copied from the user space and then buffer is
>> accessed on index strlen(buf)-1. This is a defect if user data start
>> from 0. So the question is: can we make any assumptions what data may
>> be received from the user or it could be arbitrary?
> 
> 
> In general I don't think any such assumptions should be made. In the 
> case of the two below I'm assuming that root access is required to write 
> those files, preventing any serious security hole, but it shouldn't 
> really be permitted to corrupt kernel memory like this, as would likely 
> happen if somebody wrote some data that contained a null as the first 
> character.
> 
>>
>> For example, in ./drivers/block/cciss.c, function cciss_proc_write
>> (line numbers are taken form 2.6.11.3):
>>    ....
>>    293          if (count > sizeof(cmd)-1) return -EINVAL;
>>    294          if (copy_from_user(cmd, buffer, count)) return -EFAULT;
>>    295          cmd[count] = '\0';
>>    296          len = strlen(cmd);      // above 3 lines ensure safety
>>    297          if (cmd[len-1] == '\n')
>>    298                  cmd[--len] = '\0';
>>    .....
>>
>> Another example is arch/i386/kernel/cpu/mtrr/if.c, function mtrr_write:
>>    ....
>>    107          if (copy_from_user(line, buf, len - 1))
>>    108                  return -EFAULT;
>>    109          ptr = line + strlen(line) - 1;
>>    110          if (*ptr == '\n')
>>    111                  *ptr = '\0';
>>     ....
>>
> 
> This one is also unsafe if somebody writes some data which is not 
> null-terminated (assuming that that's possible), since strlen will run 
> off the end of the buffer. The first example doesn't have that problem.

The latter one does (before the listed code):

	memset(line, 0, LINE_SIZE);
	if (len > LINE_SIZE)
		len = LINE_SIZE;
	if (copy_from_user(line, buf, len - 1))
		return -EFAULT;

so isn't line[LINE_SIZE - 1] always 0 ?

-- 
~Randy

  reply	other threads:[~2005-03-16  4:21 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3Iphf-66y-15@gated-at.bofh.it>
2005-03-15 23:56 ` Taking strlen of buffers copied from userspace Robert Hancock
2005-03-16  4:20   ` Randy.Dunlap [this message]
     [not found] <3IugU-2m4-11@gated-at.bofh.it>
     [not found] ` <3IugU-2m4-9@gated-at.bofh.it>
     [not found]   ` <3IykC-5x0-29@gated-at.bofh.it>
2005-03-16  5:24     ` Robert Hancock
2005-03-16  5:30       ` Randy.Dunlap
2005-03-15 18:27 Artem Frolov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4237B413.8070501@osdl.org \
    --to=rddunlap@osdl.org \
    --cc=hancockr@shaw.ca \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.