mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: dan carpenter <d_carpenter@sbcglobal.net>
To: "Paulo Andre'" <l16083@alunos.uevora.pt>,
	Christoph Hellwig <hch@infradead.org>
Cc: kernel-janitor-discuss@lists.sourceforge.net,
	linux-kernel@vger.kernel.org
Subject: Re: Question on verify_area() and friends wrt
Date: Sun, 25 May 2003 00:46:31 +0200	[thread overview]
Message-ID: <200305250045.19458.d_carpenter@sbcglobal.net> (raw)
In-Reply-To: <20030525145319.6f66a8aa.l16083@alunos.uevora.pt>

On Sunday 25 May 2003 03:53 pm, Paulo Andre' wrote:
> Christoph Hellwig <hch@infradead.org> wrote:
> > verify_area only does some checks so you need to check the return
> > value from copy_to_user.  You could switch to __copy_to_user, though.
>
> Why would __copy_to_user be a good choice? AFAIK, __copy_to_user does no
> validy checks (as opposed to copy_to_user which does access_ok()) so,
> considering verify_area() does only some checks, one could argue that
> there's even less checking done if using __copy_to_user. Where am I
> interpreting this wrong (as I certainly am) ?
>

copy_to_user() does the equivelent of a verify_area().  __copy_to_user() 
doesn't 
make the verify_area() check.If a function is going to be making a lot of 
copies to 
the same area, it makes sense to just do one verify_area() and use 
__copy_to_user().
Both copy_to_user() and __copy_to_user() can fail even though the 
verify_area() 
checks pass.

In this case there is only one copy to each area so it doesn't really make
sense to use __copy_to_user().

My patch would look like this:

--- net/bluetooth/hci_core.c.orig       2003-05-25 00:25:16.000000000 +0200
+++ net/bluetooth/hci_core.c    2003-05-25 00:25:34.000000000 +0200
@@ -431,14 +431,14 @@
 
        BT_DBG("num_rsp %d", ir.num_rsp);
 
-       if (!verify_area(VERIFY_WRITE, ptr, sizeof(ir) + 
-                       (sizeof(struct inquiry_info) * ir.num_rsp))) {
-               copy_to_user(ptr, &ir, sizeof(ir));
-               ptr += sizeof(ir);
-               copy_to_user(ptr, buf, sizeof(struct inquiry_info) * 
ir.num_rsp);
-       } else 
+       if (copy_to_user(ptr, &ir, sizeof(ir))) {
                err = -EFAULT;
-
+               goto free:
+       }
+       ptr += sizeof(ir);
+       if (copy_to_user(ptr, buf, sizeof(struct inquiry_info) * ir.num_rsp))
+               err = -EFAULT;
+free:
        kfree(buf);
 
 done:



      reply	other threads:[~2003-05-25 15:56 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-25 11:46 Paulo Andre'
2003-05-25 12:07 ` Christoph Hellwig
2003-05-25 13:53   ` Paulo Andre'
2003-05-24 22:46     ` dan carpenter [this message]

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=200305250045.19458.d_carpenter@sbcglobal.net \
    --to=d_carpenter@sbcglobal.net \
    --cc=hch@infradead.org \
    --cc=kernel-janitor-discuss@lists.sourceforge.net \
    --cc=l16083@alunos.uevora.pt \
    --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 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®