From: Zev Weiss <zevweiss@gmail.com>
Cc: Rodolfo Giometti <giometti@enneenne.com>,
Andrew Morton <akpm@linux-foundation.org>,
David Woodhouse <dwmw2@infradead.org>,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] [MTD] mtdchar.c: Fix regression in MEMGETREGIONINFO ioctl()
Date: Tue, 26 Aug 2008 21:31:00 -0700 [thread overview]
Message-ID: <48B4D884.5040204@gmail.com> (raw)
In-Reply-To: <48B13F88.3080306@gmail.com>
Zev Weiss wrote:
> Andrew Morton wrote:
> > On Sat, 23 Aug 2008 01:10:21 -0700 Zev Weiss <zevweiss@gmail.com> wrote:
> >
> >> Hmm. Well, I may be misunderstanding what you're saying (again, I'm
> very much
> >> a newbie to kernelspace), but I *think* the "copying four u32's out to
> >> userspace" thing isn't really a problem with my patch. It does
> certainly copy
> >> those four u32's, but given that `ur' (struct mtd_region_info_user) is
> >> initialized by copying from userspace, its fourth u32 (the
> `regionindex'
> >> member) should be identical when copied back out to userspace, given
> that it's
> >> not touched in the memberwise modification of the struct.
> >
> > OK, that's fortuitously bug-free in single-threaded userspace but
> > fantastically-improbably-buggy if userspace is threaded.
> >
> > But it's something the kernel shouldn't be doing.
> >
>
> Ah, good point -- that hadn't occurred to me at all. Though it looks
> pretty
> clumsy/simpleminded to me, I guess something like this would avoid
> copying and rewriting the fourth u32 ("Well, duh" may be the appropriate
> response here):
>
> diff --git a/drivers/mtd/mtdchar.c b/drivers/mtd/mtdchar.c
> index 13cc67a..424f318 100644
> --- a/drivers/mtd/mtdchar.c
> +++ b/drivers/mtd/mtdchar.c
> @@ -410,16 +410,20 @@ static int mtd_ioctl(struct inode *inode, struct
> file *file,
>
> case MEMGETREGIONINFO:
> {
> - struct region_info_user ur;
> + u32 ur_idx;
> + struct mtd_erase_region_info *kr;
> + struct region_info_user *ur = (struct region_info_user
> *) argp;
>
> - if (copy_from_user(&ur, argp, sizeof(struct
> region_info_user)))
> + if (get_user(ur_idx,&(ur->regionindex)))
> return -EFAULT;
>
> - if (ur.regionindex >= mtd->numeraseregions)
> - return -EINVAL;
> - if (copy_to_user(argp,
> &(mtd->eraseregions[ur.regionindex]),
> - sizeof(struct mtd_erase_region_info)))
> + kr = &(mtd->eraseregions[ur_idx]);
> +
> + if (put_user(kr->offset, &(ur->offset))
> + || put_user(kr->erasesize, &(ur->erasesize))
> + || put_user(kr->numblocks, &(ur->numblocks)))
> return -EFAULT;
> +
> break;
> }
>
>
> [Note: this is not even so much as compile-tested, and will remain that way
> until Monday, but I think you get the picture.]
>
Well, for what little it's probably worth, I've now tested this patch, with no
resulting surprises (seems to work fine for me). Though I see now that, much to
my chagrin, something in my email chain seems to have spacified my code. If
there's any need I can resend appropriately.
Zev
WARNING: multiple messages have this Message-ID (diff)
From: Zev Weiss <zevweiss@gmail.com>
To: unlisted-recipients:; (no To-header on input)
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
Rodolfo Giometti <giometti@enneenne.com>,
David Woodhouse <dwmw2@infradead.org>
Subject: Re: [PATCH] [MTD] mtdchar.c: Fix regression in MEMGETREGIONINFO ioctl()
Date: Tue, 26 Aug 2008 21:31:00 -0700 [thread overview]
Message-ID: <48B4D884.5040204@gmail.com> (raw)
In-Reply-To: <48B13F88.3080306@gmail.com>
Zev Weiss wrote:
> Andrew Morton wrote:
> > On Sat, 23 Aug 2008 01:10:21 -0700 Zev Weiss <zevweiss@gmail.com> wrote:
> >
> >> Hmm. Well, I may be misunderstanding what you're saying (again, I'm
> very much
> >> a newbie to kernelspace), but I *think* the "copying four u32's out to
> >> userspace" thing isn't really a problem with my patch. It does
> certainly copy
> >> those four u32's, but given that `ur' (struct mtd_region_info_user) is
> >> initialized by copying from userspace, its fourth u32 (the
> `regionindex'
> >> member) should be identical when copied back out to userspace, given
> that it's
> >> not touched in the memberwise modification of the struct.
> >
> > OK, that's fortuitously bug-free in single-threaded userspace but
> > fantastically-improbably-buggy if userspace is threaded.
> >
> > But it's something the kernel shouldn't be doing.
> >
>
> Ah, good point -- that hadn't occurred to me at all. Though it looks
> pretty
> clumsy/simpleminded to me, I guess something like this would avoid
> copying and rewriting the fourth u32 ("Well, duh" may be the appropriate
> response here):
>
> diff --git a/drivers/mtd/mtdchar.c b/drivers/mtd/mtdchar.c
> index 13cc67a..424f318 100644
> --- a/drivers/mtd/mtdchar.c
> +++ b/drivers/mtd/mtdchar.c
> @@ -410,16 +410,20 @@ static int mtd_ioctl(struct inode *inode, struct
> file *file,
>
> case MEMGETREGIONINFO:
> {
> - struct region_info_user ur;
> + u32 ur_idx;
> + struct mtd_erase_region_info *kr;
> + struct region_info_user *ur = (struct region_info_user
> *) argp;
>
> - if (copy_from_user(&ur, argp, sizeof(struct
> region_info_user)))
> + if (get_user(ur_idx,&(ur->regionindex)))
> return -EFAULT;
>
> - if (ur.regionindex >= mtd->numeraseregions)
> - return -EINVAL;
> - if (copy_to_user(argp,
> &(mtd->eraseregions[ur.regionindex]),
> - sizeof(struct mtd_erase_region_info)))
> + kr = &(mtd->eraseregions[ur_idx]);
> +
> + if (put_user(kr->offset, &(ur->offset))
> + || put_user(kr->erasesize, &(ur->erasesize))
> + || put_user(kr->numblocks, &(ur->numblocks)))
> return -EFAULT;
> +
> break;
> }
>
>
> [Note: this is not even so much as compile-tested, and will remain that way
> until Monday, but I think you get the picture.]
>
Well, for what little it's probably worth, I've now tested this patch, with no
resulting surprises (seems to work fine for me). Though I see now that, much to
my chagrin, something in my email chain seems to have spacified my code. If
there's any need I can resend appropriately.
Zev
next prev parent reply other threads:[~2008-08-27 4:31 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-20 7:47 [PATCH] [MTD] mtdchar.c: Fix regression in MEMGETREGIONINFO ioctl() Zev Weiss
2008-08-22 22:34 ` Andrew Morton
2008-08-22 22:34 ` Andrew Morton
2008-08-23 8:10 ` Zev Weiss
2008-08-23 8:10 ` Zev Weiss
2008-08-24 5:27 ` Andrew Morton
2008-08-24 5:27 ` Andrew Morton
2008-08-24 11:01 ` Zev Weiss
2008-08-24 11:01 ` Zev Weiss
2008-08-27 4:31 ` Zev Weiss [this message]
2008-08-27 4:31 ` Zev Weiss
2008-09-01 11:01 ` David Woodhouse
2008-09-01 11:01 ` David Woodhouse
2008-09-01 12:19 ` Zev Weiss
2008-09-01 12:19 ` Zev Weiss
2008-09-01 17:25 ` David Woodhouse
2008-09-01 17:25 ` David Woodhouse
2008-08-25 11:37 ` David Woodhouse
2008-08-25 11:37 ` David Woodhouse
2008-08-24 12:38 ` Jamie Lokier
2008-08-24 12:38 ` Jamie Lokier
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=48B4D884.5040204@gmail.com \
--to=zevweiss@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=dwmw2@infradead.org \
--cc=giometti@enneenne.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.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.