mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Tom Felker <tfelker2@uiuc.edu>
To: linux-os@analogic.com
Cc: Linux kernel <linux-kernel@vger.kernel.org>
Subject: Re: Bogus buffer length check in linux-2.6.11  read()
Date: Tue, 15 Mar 2005 20:56:16 -0600	[thread overview]
Message-ID: <200503152056.16287.tfelker2@uiuc.edu> (raw)
In-Reply-To: <Pine.LNX.4.61.0503151257450.12264@chaos.analogic.com>

On Tuesday 15 March 2005 11:59 am, linux-os wrote:
> The attached file shows that the kernel thinks it's doing
> something helpful by checking the length of the input
> buffer for a read(). It will return "Bad Address" until
> the length is 1632 bytes.  Apparently the kernel thinks
> 1632 is a good length!
>
> Did anybody consider the overhead necessary to do this
> and the fact that the kernel has no way of knowing if
> the pointer to the buffer is valid until it actually
> does the write. What was wrong with copy_to_user()?
> Why is there the additional bogus check?

I don't think that's what's happening.  The kernel is perfectly happy to read 
data into any virtual address range that your process can legally write to - 
this includes any part of the heap and any part of the stack.  The kernel 
can't check whether writing to the given address would clobber the stack or 
heap - it's your memory, you manage it.  The kernel's notion of an "invalid 
address" is very simple, and doesn't include every address that you would 
consider invalid from a C perspective.

So what's probably happening is that your stack is (1632+256) bytes tall, 
including the buffer you allocated.  (Stack grows downward on i386.)  So 
ideally you read less than 256 bytes.  If you read more than 256 but less 
than 1888 bytes, the read would damage other elements on the stack, but it is 
OK as far as the kernel is concerned.  But if you read more than that, you're 
asking the kernel to write to an address that is higher than the highest 
address of the stack (the address of the bottom element), and this address 
isn't mapped into your process, so you get EINVAL.

If you were to type more than 256 (but less than 1888) characters before 
pressing enter, the read would silently overflow the buffer, thus clobbering 
the stack, including the return address of main().  So when main tried to 
return, you'd get a segfault.  Somebody with assembly skills could probably 
craft a string which, when your program reads it, would take control of the 
program.

-- 
Tom Felker, <tcfelker@mtco.com>
<http://vlevel.sourceforge.net> - Stop fiddling with the volume knob.

No army can withstand the strength of an idea whose time has come.

  reply	other threads:[~2005-03-16  2:56 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-15 17:59 linux-os
2005-03-16  2:56 ` Tom Felker [this message]
2005-03-16 12:29   ` linux-os
2005-03-16 13:30     ` Ian Campbell
2005-03-16 14:11       ` linux-os
2005-03-16 14:42         ` Eric Dumazet
2005-03-16 14:51           ` linux-os
     [not found] <3IoOm-5M2-49@gated-at.bofh.it>
2005-03-15 23:59 ` Robert Hancock
2005-03-16 12:23   ` linux-os
     [not found] ` <3IwVv-4kD-17@gated-at.bofh.it>
     [not found]   ` <3IFYO-3eg-37@gated-at.bofh.it>
     [not found]     ` <3IGUS-46t-27@gated-at.bofh.it>
     [not found]       ` <3IHxD-4Gb-5@gated-at.bofh.it>
2005-03-16 14:37         ` Robert Hancock

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=200503152056.16287.tfelker2@uiuc.edu \
    --to=tfelker2@uiuc.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-os@analogic.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®