lkml.org 
[lkml]   [2008]   [Aug]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] [MTD] mtdchar.c: Fix regression in MEMGETREGIONINFO ioctl()
On Sat, 23 Aug 2008 01:10:21 -0700 Zev Weiss <zevweiss@gmail.com> wrote:

> Andrew Morton wrote:
> > On Wed, 20 Aug 2008 00:47:23 -0700
> > Zev Weiss <zevweiss@gmail.com> wrote:
> >
> >> From: Zev Weiss <zevweiss@gmail.com>
> >>
> >> The MEMGETREGIONINFO ioctl() in mtdchar.c was clobbering user memory by
> >> overwriting more than intended, due to the size of struct
> >> mtd_erase_region_info changing in commit
> >> 0ecbc81adfcb9f15f86b05ff576b342ce81bbef8.
> >>
> >> Fix uses a member-by-member copy into a local struct region_info_user,
> >> which is then copy_to_user()'d (and matches the size correctly by being
> >> of the same type as the pointer passed in the ioctl() call).
> >>
> >> Signed-off-by: Zev Weiss <zevweiss@gmail.com>
> >> Tested-by: Zev Weiss <zevweiss@gmail.com>
> >> ---
> >> I had been having some problems with userspace memory corruption, and traced
> >> them to a MEMGETREGIONINFO ioctl() on an MTD device. I applied this patch and
> >> it seems to fix the problem, though I am not an expert and there may be a more
> >> correct way to go about doing this. I'm also new at submitting patches, so
> >> hopefully I haven't screwed up the patch-submission etiquette too
> >> horrifically.
> >>
> >> drivers/mtd/mtdchar.c | 11 +++++++++--
> >> 1 files changed, 9 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/mtd/mtdchar.c b/drivers/mtd/mtdchar.c
> >> index 13cc67a..0acb135 100644
> >> --- a/drivers/mtd/mtdchar.c
> >> +++ b/drivers/mtd/mtdchar.c
> >> @@ -411,14 +411,21 @@ static int mtd_ioctl(struct inode *inode, struct file *file,
> >> case MEMGETREGIONINFO:
> >> {
> >> struct region_info_user ur;
> >> + struct mtd_erase_region_info *kr;
> >>
> >> if (copy_from_user(&ur, argp, sizeof(struct region_info_user)))
> >> 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.regionindex]);
> >> +
> >> + ur.offset = kr->offset;
> >> + ur.erasesize = kr->erasesize;
> >> + ur.numblocks = kr->numblocks;
> >> +
> >> + if (copy_to_user(argp, &ur, sizeof(struct region_info_user)))
> >> return -EFAULT;
> >> break;
> >> }
> >
> > ug.
> >
> > Putting a kernel pointer into a shared-with-userspace data structure
> > (struct mtd_erase_region_info) was a big mistake.
> >
> > Copying a `struct region_info_user' back to userspace seems better than
> > copying a `struct mtd_erase_region_info', but what do I know?
> >
> > Actually...
> >
> > Before 0ecbc81adfcb9f15f86b05ff576b342ce81bbef8, `struct
> > mtd_erase_region_info' had three members, all u32. We were copying
> > three u32's out to userspace.
> >
> > After 0ecbc81adfcb9f15f86b05ff576b342ce81bbef8, `struct
> > mtd_erase_region_info' has four members: three u32's and one ulong*.
> > We're copying three u32's and one ulong* out to userspace.
> >
> > After your change, we're copying _four_ u32's out to userspace, so
> > there still is potential for scribbling on unsuspecting userspace?
> >
> > If that reading is right, we need to go back to copying just the three
> > u32's. Perhaps via
> >
> > struct mtd_erase_region_info {
> > struct {
> > u_int32_t offset;
> > u_int32_t erasesize;
> > u_int32_t numblocks;
> > } user_part;
> > unsigned long *lockmap;
> > };
> >
> > or similar.
> >
> > David? Help? 2.6.25.x anmd 2.6.26.x need fixing as well.
> >
> >
>
> 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.

> So yes, it is
> copying 4 bytes more than is strictly necessary, but it seemed like a
> reasonably clean way of going about it (to me, for what that's worth).
>
> In my particular situation it didn't do anything unexpected in my testing (and
> restored the normal behavior I had when previously running 2.6.17.7).
>
> On the other hand, if I'm missing something completely, please let me know,
> and perhaps I can prepare a more suitable fix.

"good enough" is never good enough ;)

What is the ideal implementation? Let's implement that.



\
 
 \ /
  Last update: 2008-08-24 07:31    [W:0.053 / U:0.848 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site