mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Andrew Duggan <aduggan@synaptics.com>,
	Chris Healy <cphealy@gmail.com>,
	linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
	Guenter Roeck <linux@roeck-us.net>,
	Nick Dyer <nick@shmanahar.org>
Subject: [RFC] Input: synaptics-rmi4 - fix out-of-bounds memory access
Date: Sat, 19 Nov 2016 19:46:58 -0800	[thread overview]
Message-ID: <1479613618-11440-1-git-send-email-linux@roeck-us.net> (raw)

Kasan reports:

BUG: KASAN: slab-out-of-bounds in __fill_v4l2_buffer+0xc3/0x540
	[videobuf2_v4l2] at addr ffff8806c5e0c6cc
Read of size 4 by task heatmap/14414
CPU: 2 PID: 14414 Comm: heatmap Tainted: G    B      OE 4.9.0-rc5+ #1
Hardware name: MSI MS-7924/H97M-G43(MS-7924), BIOS V2.0 04/15/2014
ffff88010cf57940 ffffffff81606978 ffff8806fe803080 ffff8806c5e0c500
ffff88010cf57968 ffffffff812fd131 ffff88010cf579f8 ffff8806c5e0c500
ffff8806fe803080 ffff88010cf579e8 ffffffff812fd3ca 0000000000000010
Call Trace:
[<ffffffff81606978>] dump_stack+0x63/0x8b
[<ffffffff812fd131>] kasan_object_err+0x21/0x70
[<ffffffff812fd3ca>] kasan_report_error+0x1fa/0x4d0
[<ffffffff812fdaf9>] kasan_report+0x39/0x40
[<ffffffff812fc000>] ? __asan_load4+0x80/0x80
[<ffffffffa0ae0553>] ? __fill_v4l2_buffer+0xc3/0x540 [videobuf2_v4l2]
[<ffffffff812fbfe1>] __asan_load4+0x61/0x80
[<ffffffffa0ae0553>] __fill_v4l2_buffer+0xc3/0x540 [videobuf2_v4l2]
[<ffffffffa0ad038d>] ? __enqueue_in_driver+0xed/0x180 [videobuf2_core]
[<ffffffffa0ad3021>] vb2_core_qbuf+0x191/0x320 [videobuf2_core]
[<ffffffffa0ae1ba9>] vb2_qbuf+0x69/0x90 [videobuf2_v4l2]
[<ffffffffa0ae1c43>] vb2_ioctl_qbuf+0x73/0x80 [videobuf2_v4l2]
[<ffffffffa0a811b0>] v4l_qbuf+0x50/0x60 [videodev]
[<ffffffffa0a8020f>] __video_do_ioctl+0x46f/0x4f0 [videodev]
[<ffffffffa0a7fda0>] ? video_ioctl2+0x20/0x20 [videodev]
[<ffffffff8112c6f4>] ? __wake_up+0x44/0x50
[<ffffffffa0a7fa24>] video_usercopy+0x3b4/0x710 [videodev]
[<ffffffffa0a7fda0>] ? video_ioctl2+0x20/0x20 [videodev]
[<ffffffffa0a7f670>] ? v4l_enum_fmt+0x1290/0x1290 [videodev]
[<ffffffff8132cb80>] ? do_loop_readv_writev+0x130/0x130
[<ffffffffa0a7fd95>] video_ioctl2+0x15/0x20 [videodev]
[<ffffffffa0a78a53>] v4l2_ioctl+0x123/0x160 [videodev]
[<ffffffff8134dcce>] do_vfs_ioctl+0x12e/0x8c0
[<ffffffff8134dba0>] ? ioctl_preallocate+0x140/0x140
[<ffffffff8139927c>] ? __fsnotify_parent+0x2c/0x130
[<ffffffff810d8e1a>] ? SyS_rt_sigaction+0xfa/0x160
[<ffffffff810d8d20>] ? SyS_sigprocmask+0x1f0/0x1f0
[<ffffffff8135e907>] ? __fget_light+0xa7/0xc0
[<ffffffff8134e4d9>] SyS_ioctl+0x79/0x90
[<ffffffff81c9a33b>] entry_SYSCALL_64_fastpath+0x1e/0xad
Object at ffff8806c5e0c500, in cache kmalloc-512 size: 512
Allocated:
PID = 14414
[<ffffffff8105ef2b>] save_stack_trace+0x1b/0x20
[<ffffffff812fc4a6>] save_stack+0x46/0xd0
[<ffffffff812fc71d>] kasan_kmalloc+0xad/0xe0
[<ffffffff812f992f>] __kmalloc+0x12f/0x210
[<ffffffffa0ad44ed>] __vb2_queue_alloc+0x9d/0x6a0 [videobuf2_core]
[<ffffffffa0ad4dca>] vb2_core_reqbufs+0x2da/0x640 [videobuf2_core]
[<ffffffffa0ae0ab8>] vb2_ioctl_reqbufs+0xd8/0x130 [videobuf2_v4l2]
[<ffffffffa0a81fa0>] v4l_reqbufs+0x60/0x70 [videodev]
[<ffffffffa0a8020f>] __video_do_ioctl+0x46f/0x4f0 [videodev]
[<ffffffffa0a7fa24>] video_usercopy+0x3b4/0x710 [videodev]
[<ffffffffa0a7fd95>] video_ioctl2+0x15/0x20 [videodev]
[<ffffffffa0a78a53>] v4l2_ioctl+0x123/0x160 [videodev]
[<ffffffff8134dcce>] do_vfs_ioctl+0x12e/0x8c0
[<ffffffff8134e4d9>] SyS_ioctl+0x79/0x90
[<ffffffff81c9a33b>] entry_SYSCALL_64_fastpath+0x1e/0xad
Freed:
PID = 1717
[<ffffffff8105ef2b>] save_stack_trace+0x1b/0x20
[<ffffffff812fc4a6>] save_stack+0x46/0xd0
[<ffffffff812fcd01>] kasan_slab_free+0x71/0xb0
[<ffffffff812f8b14>] kfree+0x94/0x190
[<ffffffff81295f6a>] kvfree+0x2a/0x40
[<ffffffffa0647e46>] i915_gem_execbuffer2+0x1d6/0x2e0 [i915]
[<ffffffffa051969b>] drm_ioctl+0x35b/0x640 [drm]
[<ffffffff8134dcce>] do_vfs_ioctl+0x12e/0x8c0
[<ffffffff8134e4d9>] SyS_ioctl+0x79/0x90
[<ffffffff81c9a33b>] entry_SYSCALL_64_fastpath+0x1e/0xad

The problematic code is
	b->flags = vbuf->flags;
and all other code in __fill_v4l2_buffer() accessing variables from
struct vb2_v4l2_buffer. That buffer is actually allocated as struct
vb2_buffer. Accessing the flags in struct vb2_v4l2_buffer beyond struct
vb2_buffer is causing the KASAN report.

Fixes: 3a762dbd5347 ("[media] Input: synaptics-rmi4 - add support for F54 ...")
Cc: Nick Dyer <nick@shmanahar.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
RFC because if I have no idea if the fix is correct. Sure, KASAN is silent with
this fix, but what bothers me is that the error is reported when copying
variables from struct vb2_v4l2_buffer to struct v4l2_buffer, not earlier.
This suggests that those variables (flags, field, timecode, sequence) are never
written in the first place. Maybe that is as expected, and the variables are
not supposed to be written, but I don't know that subsystem well enough to
know the expected behavior.

 drivers/input/rmi4/rmi_f54.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/input/rmi4/rmi_f54.c b/drivers/input/rmi4/rmi_f54.c
index cf805b960866..ef91633acb6b 100644
--- a/drivers/input/rmi4/rmi_f54.c
+++ b/drivers/input/rmi4/rmi_f54.c
@@ -363,7 +363,7 @@ static const struct vb2_ops rmi_f54_queue_ops = {
 static const struct vb2_queue rmi_f54_queue = {
 	.type = V4L2_BUF_TYPE_VIDEO_CAPTURE,
 	.io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF | VB2_READ,
-	.buf_struct_size = sizeof(struct vb2_buffer),
+	.buf_struct_size = sizeof(struct vb2_v4l2_buffer),
 	.ops = &rmi_f54_queue_ops,
 	.mem_ops = &vb2_vmalloc_memops,
 	.timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC,
-- 
2.5.0

             reply	other threads:[~2016-11-20  3:47 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-20  3:46 Guenter Roeck [this message]
2016-11-23  1:31 ` Dmitry Torokhov

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=1479613618-11440-1-git-send-email-linux@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=aduggan@synaptics.com \
    --cc=cphealy@gmail.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nick@shmanahar.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

Powered by JetHome