From: Kees Cook <keescook@chromium.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: syzbot <syzbot+3de312463756f656b47d@syzkaller.appspotmail.com>,
allison@lohutok.net, andreyknvl@google.com, cai@lca.pw,
gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, linux-usb@vger.kernel.org,
syzkaller-bugs@googlegroups.com, tglx@linutronix.de,
Jiri Kosina <jkosina@suse.cz>
Subject: Re: BUG: bad usercopy in hidraw_ioctl
Date: Thu, 8 Aug 2019 13:27:07 -0700 [thread overview]
Message-ID: <201908081319.E2123D5A@keescook> (raw)
In-Reply-To: <20190807195821.GD5482@bombadil.infradead.org>
On Wed, Aug 07, 2019 at 12:58:21PM -0700, Matthew Wilcox wrote:
> On Wed, Aug 07, 2019 at 12:28:06PM -0700, syzbot wrote:
> > usercopy: Kernel memory exposure attempt detected from wrapped address
> > (offset 0, size 0)!
> > ------------[ cut here ]------------
> > kernel BUG at mm/usercopy.c:98!
>
> This report is confusing because the arguments to usercopy_abort() are wrong.
>
> /* Reject if object wraps past end of memory. */
> if (ptr + n < ptr)
> usercopy_abort("wrapped address", NULL, to_user, 0, ptr + n);
This test actually contains an off-by-one which was recently fixed:
https://lore.kernel.org/linux-mm/1564509253-23287-1-git-send-email-isaacm@codeaurora.org/
So, this is actually a false positive if "ptr + n" yields a 0
(e.g. 0xffffffff + 1 == 0).
> ptr + n is not 'size', it's what wrapped. I don't know what 'offset'
> should be set to, but 'size' should be 'n'. Presumably we don't want to
> report 'ptr' because it'll leak a kernel address ... reporting 'n' will
Right, I left offset 0 (this is normally the offset into a reported area
like a specific kmalloc region, but isn't meaningful here IMO). And I
left the size as "how far we wrapped". (Which is pretty telling: we
wrapped 0 bytes ... *cough*.)
> leak a range for a kernel address, but I think that's OK? Admittedly an
> attacker can pass in various values for 'n', but it'll be quite noisy
> and leave a trace in the kernel logs for forensics to find afterwards.
>
> > Call Trace:
> > check_bogus_address mm/usercopy.c:151 [inline]
> > __check_object_size mm/usercopy.c:260 [inline]
> > __check_object_size.cold+0xb2/0xba mm/usercopy.c:250
> > check_object_size include/linux/thread_info.h:119 [inline]
> > check_copy_size include/linux/thread_info.h:150 [inline]
> > copy_to_user include/linux/uaccess.h:151 [inline]
> > hidraw_ioctl+0x38c/0xae0 drivers/hid/hidraw.c:392
>
> The root problem would appear to be:
>
> else if (copy_to_user(user_arg + offsetof(
> struct hidraw_report_descriptor,
> value[0]),
> dev->hid->rdesc,
> min(dev->hid->rsize, len)))
>
> That 'min' should surely be a 'max'?
>
> Jiri, this looks like it was your code back in 2007.
I think this code is correct and the usercopy reporting fix already in
-mm solves the problem.
--
Kees Cook
next prev parent reply other threads:[~2019-08-08 20:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-07 19:28 BUG: bad usercopy in hidraw_ioctl syzbot
2019-08-07 19:58 ` Matthew Wilcox
2019-08-08 1:49 ` Al Viro
2019-08-08 20:41 ` Kees Cook
2019-08-08 20:27 ` Kees Cook [this message]
2019-08-21 17:00 ` Andrey Konovalov
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=201908081319.E2123D5A@keescook \
--to=keescook@chromium.org \
--cc=allison@lohutok.net \
--cc=andreyknvl@google.com \
--cc=cai@lca.pw \
--cc=gregkh@linuxfoundation.org \
--cc=jkosina@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-usb@vger.kernel.org \
--cc=syzbot+3de312463756f656b47d@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=tglx@linutronix.de \
--cc=willy@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.