Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1526168 > unrolled thread
| Started by | Guenter Roeck <linux@roeck-us.net> |
|---|---|
| First post | 2016-11-20 04:50 +0100 |
| Last post | 2016-11-23 02:40 +0100 |
| Articles | 2 — 2 participants |
Back to article view | Back to linux.kernel
[RFC] Input: synaptics-rmi4 - fix out-of-bounds memory access Guenter Roeck <linux@roeck-us.net> - 2016-11-20 04:50 +0100
Re: [RFC] Input: synaptics-rmi4 - fix out-of-bounds memory access Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2016-11-23 02:40 +0100
| From | Guenter Roeck <linux@roeck-us.net> |
|---|---|
| Date | 2016-11-20 04:50 +0100 |
| Subject | [RFC] Input: synaptics-rmi4 - fix out-of-bounds memory access |
| Message-ID | <sFriF-5H8-3@gated-at.bofh.it> |
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
[toc] | [next] | [standalone]
| From | Dmitry Torokhov <dmitry.torokhov@gmail.com> |
|---|---|
| Date | 2016-11-23 02:40 +0100 |
| Message-ID | <sGuHv-6BR-5@gated-at.bofh.it> |
| In reply to | #1526168 |
Hi Guenter,
On Sat, Nov 19, 2016 at 07:46:58PM -0800, Guenter Roeck wrote:
> 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.
I think we best ask media folks (CCed).
>
> 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
>
--
Dmitry
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web