From: "David S. Miller" <davem@davemloft.net>
To: sparclinux@vger.kernel.org
Subject: Re: TUNSETIFF: data not copied back to userspace
Date: Mon, 14 Feb 2005 23:02:33 +0000 [thread overview]
Message-ID: <20050214150233.2ec4a292.davem@davemloft.net> (raw)
In-Reply-To: <Pine.LNX.4.61.0502141928510.11663@l01.thnet>
On Mon, 14 Feb 2005 23:59:32 +0100 (CET)
Michael Tautschnig <michael.tautschnig@zt-consulting.com> wrote:
> switch (cmd) {
> case SIOCGIFFLAGS:
> case SIOCGIFMETRIC:
> case SIOCGIFMTU:
> case SIOCGIFMEM:
> case SIOCGIFHWADDR:
> case SIOCGIFINDEX:
> case SIOCGIFADDR:
> case SIOCGIFBRDADDR:
> case SIOCGIFDSTADDR:
> case SIOCGIFNETMASK:
> case SIOCGIFTXQLEN:
> if (copy_to_user(uifr32, &ifr, sizeof(*uifr32)))
> return -EFAULT;
> break;
> case SIOCGIFMAP:
>
> - the (modified) struct is copied in all cases listed above. But what do
> you mean by "the strict definition of TUNSETIFF"?
So add "case TUNSETIFF" to the switch statement above.
You discovered the fix for your own bug, so why not implement
it and submit the resulting patch here? :-)
> Why should be be _IOWR there?
ioctl's are mostly defined in with a set of macros that describe
whether data goes in or out (or both) from/to userspace. The
_IORW macros set the direction to indicate that data goes both
in and out.
These macros are defined in include/asm/ioctl.h
include/linux/if_tun.h defines TUNSETIFF using the _IOW() macro.
Which indicates that data only comes in from userspace. This definition
is incorrect, it should use _IORW() as Eric stated, but it can't be changed
because this ioctl value is hardcoded into many existing applications which
would break if we "fixed" this.
next prev parent reply other threads:[~2005-02-14 23:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-14 19:41 TUNSETIFF: data not copied back to userspace Michael Tautschnig
2005-02-14 20:45 ` Eric Brower
2005-02-14 22:59 ` Michael Tautschnig
2005-02-14 23:02 ` David S. Miller [this message]
2005-02-14 23:18 ` Michael Tautschnig
2005-02-14 23:30 ` David S. Miller
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=20050214150233.2ec4a292.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=sparclinux@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.