From patchwork Thu Mar 18 13:43:18 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Arnd Bergmann X-Patchwork-Id: 12148271 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-19.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8CF1AC433E0 for ; Thu, 18 Mar 2021 13:44:31 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 3B98D64F1B for ; Thu, 18 Mar 2021 13:44:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229955AbhCRNn6 (ORCPT ); Thu, 18 Mar 2021 09:43:58 -0400 Received: from mail.kernel.org ([198.145.29.99]:34864 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229736AbhCRNnl (ORCPT ); Thu, 18 Mar 2021 09:43:41 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 97FB860249; Thu, 18 Mar 2021 13:43:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1616075021; bh=ROt+VI0bzs+jRQflvftpNh03+yCXlKdKUPuAx2ZQYyo=; h=From:To:Cc:Subject:Date:From; b=MXIGQ2QLdEwENYHj3FF325RtHFF1Z1xSGUZjZPOqT6CgWPBlLCJJHi2JNZo3uLhUm Oua3+q3Gzckh1aIqXZUtuS8rT5XuPSg2Kft1HbaG5Fsl+p+X1sTxFeYyhTQW4xhzY6 92qBEG6MG3CCX1l07kOl+zWljm7CncvHQDSOowwn5CUHwvYEL0ImYbKeHLjBHMth94 tLu9SAH785bGwRdszTg55CvRED94J7V0UxCyddzqLkx/Qp7zDRHIh0JgwfDEIQY9pT ieYGJWiT/GGcZ4R53eqDU4CLxPcKsAqNjGlPGSdGTi/bnw/i7shsLXzEw7tb7qtjxR 8S9NfgV0iVSvg== From: Arnd Bergmann To: Mauro Carvalho Chehab , Hans Verkuil , Arnd Bergmann Cc: Dmitry Vyukov , syzbot+142888ffec98ab194028@syzkaller.appspotmail.com, Laurent Pinchart , Sakari Ailus , linux-media@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 1/2] media: v4l2-core: ignore native time32 ioctls on 64-bit Date: Thu, 18 Mar 2021 14:43:18 +0100 Message-Id: <20210318134334.2933141-1-arnd@kernel.org> X-Mailer: git-send-email 2.29.2 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org From: Arnd Bergmann Syzbot found that passing ioctl command 0xc0505609 into a 64-bit kernel from a 32-bit process causes uninitialized kernel memory to get passed to drivers instead of the user space data: BUG: KMSAN: uninit-value in check_array_args drivers/media/v4l2-core/v4l2-ioctl.c:3041 [inline] BUG: KMSAN: uninit-value in video_usercopy+0x1631/0x3d30 drivers/media/v4l2-core/v4l2-ioctl.c:3315 CPU: 0 PID: 19595 Comm: syz-executor.4 Not tainted 5.11.0-rc7-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x21c/0x280 lib/dump_stack.c:120 kmsan_report+0xfb/0x1e0 mm/kmsan/kmsan_report.c:118 __msan_warning+0x5f/0xa0 mm/kmsan/kmsan_instr.c:197 check_array_args drivers/media/v4l2-core/v4l2-ioctl.c:3041 [inline] video_usercopy+0x1631/0x3d30 drivers/media/v4l2-core/v4l2-ioctl.c:3315 video_ioctl2+0x9f/0xb0 drivers/media/v4l2-core/v4l2-ioctl.c:3391 v4l2_ioctl+0x255/0x290 drivers/media/v4l2-core/v4l2-dev.c:360 v4l2_compat_ioctl32+0x2c6/0x370 drivers/media/v4l2-core/v4l2-compat-ioctl32.c:1248 __do_compat_sys_ioctl fs/ioctl.c:842 [inline] __se_compat_sys_ioctl+0x53d/0x1100 fs/ioctl.c:793 __ia32_compat_sys_ioctl+0x4a/0x70 fs/ioctl.c:793 do_syscall_32_irqs_on arch/x86/entry/common.c:79 [inline] __do_fast_syscall_32+0x102/0x160 arch/x86/entry/common.c:141 do_fast_syscall_32+0x6a/0xc0 arch/x86/entry/common.c:166 do_SYSENTER_32+0x73/0x90 arch/x86/entry/common.c:209 entry_SYSENTER_compat_after_hwframe+0x4d/0x5c The time32 commands are defined but were never meant to be called on 64-bit machines, as those have always used time64 interfaces. I missed this in my patch that introduced the time64 handling on 32-bit platforms. The problem in this case is the mismatch of one function checking for the numeric value of the command and another function checking for the type of process (native vs compat) instead, with the result being that for this combination, nothing gets copied into the buffer at all. Avoid this by only trying to convert the time32 commands when running on a 32-bit kernel where these are defined in a meaningful way. Fixes: 577c89b0ce72 ("media: v4l2-core: fix v4l2_buffer handling for time64 ABI") Reported-by: syzbot+142888ffec98ab194028@syzkaller.appspotmail.com Tested-by: Hans Verkuil Signed-off-by: Arnd Bergmann Reviewed-by: Laurent Pinchart --- This patch adds two more changes than the version that Hans tested --- drivers/media/v4l2-core/v4l2-ioctl.c | 6 +++--- drivers/media/v4l2-core/v4l2-subdev.c | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c index 31d1342e61e8..2b1bb68dc27f 100644 --- a/drivers/media/v4l2-core/v4l2-ioctl.c +++ b/drivers/media/v4l2-core/v4l2-ioctl.c @@ -3115,7 +3115,7 @@ static int check_array_args(unsigned int cmd, void *parg, size_t *array_size, static unsigned int video_translate_cmd(unsigned int cmd) { switch (cmd) { -#ifdef CONFIG_COMPAT_32BIT_TIME +#if !defined(CONFIG_64BIT) && defined(CONFIG_COMPAT_32BIT_TIME) case VIDIOC_DQEVENT_TIME32: return VIDIOC_DQEVENT; case VIDIOC_QUERYBUF_TIME32: @@ -3169,7 +3169,7 @@ static int video_get_user(void __user *arg, void *parg, err = v4l2_compat_get_user(arg, parg, cmd); } else { switch (cmd) { -#ifdef CONFIG_COMPAT_32BIT_TIME +#if !defined(CONFIG_64BIT) && defined(CONFIG_COMPAT_32BIT_TIME) case VIDIOC_QUERYBUF_TIME32: case VIDIOC_QBUF_TIME32: case VIDIOC_DQBUF_TIME32: @@ -3224,7 +3224,7 @@ static int video_put_user(void __user *arg, void *parg, return v4l2_compat_put_user(arg, parg, cmd); switch (cmd) { -#ifdef CONFIG_COMPAT_32BIT_TIME +#if !defined(CONFIG_64BIT) && defined(CONFIG_COMPAT_32BIT_TIME) case VIDIOC_DQEVENT_TIME32: { struct v4l2_event *ev = parg; struct v4l2_event_time32 ev32; diff --git a/drivers/media/v4l2-core/v4l2-subdev.c b/drivers/media/v4l2-core/v4l2-subdev.c index 336133dbc759..9f5573d3b857 100644 --- a/drivers/media/v4l2-core/v4l2-subdev.c +++ b/drivers/media/v4l2-core/v4l2-subdev.c @@ -428,7 +428,7 @@ static long subdev_do_ioctl(struct file *file, unsigned int cmd, void *arg) return v4l2_event_dequeue(vfh, arg, file->f_flags & O_NONBLOCK); -#ifdef CONFIG_COMPAT_32BIT_TIME +#if !defined(CONFIG_64BIT) && defined(CONFIG_COMPAT_32BIT_TIME) case VIDIOC_DQEVENT_TIME32: { struct v4l2_event_time32 *ev32 = arg; struct v4l2_event ev = { }; From patchwork Thu Mar 18 13:43:19 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Arnd Bergmann X-Patchwork-Id: 12148273 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-19.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3E849C433E0 for ; Thu, 18 Mar 2021 13:45:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0820E64F04 for ; Thu, 18 Mar 2021 13:45:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230182AbhCRNob (ORCPT ); Thu, 18 Mar 2021 09:44:31 -0400 Received: from mail.kernel.org ([198.145.29.99]:34904 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230010AbhCRNn7 (ORCPT ); Thu, 18 Mar 2021 09:43:59 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 8902264E4D; Thu, 18 Mar 2021 13:43:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1616075039; bh=M/awrcCSuKIqOO2dmf7RKrAzqBZawv3ByeWFBOHNV9Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=tvzLhSlOEy7dCNqLkoFPSJ7DAlxsG5RAo0ns+QYpq+UrW9JrAUln88DcFs/NC0OJs T+GBiXt5nHG8vVrImz57sLy1Krri1JXQIwe+PeXmVHvx3XaM85RFib2ALg12XqaaFB fuy9UpJ2ezFNdlKGINaY3k8T2r/k07cicOzR/N3jzogfGsrrnkNeAVCKGZin7M19MH OiE/XtNe3ry+YfI1fjH37CnNaOD5Z4MLNGTwp3GAKm8d7xwpjUQiZ4sXCtLDYS1pHx 3c6BtbyNjxYQBUEr38ghw3WHyIrRrBW3zT3g4bV/xfNTBCHbeZj1QiaCbBBo5m4roi eUPIBahJZqtMQ== From: Arnd Bergmann To: Mauro Carvalho Chehab Cc: Dmitry Vyukov , Arnd Bergmann , syzbot+142888ffec98ab194028@syzkaller.appspotmail.com, Hans Verkuil , Laurent Pinchart , Sakari Ailus , linux-media@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH 2/2] media: v4l2-core: explicitly clear ioctl input data Date: Thu, 18 Mar 2021 14:43:19 +0100 Message-Id: <20210318134334.2933141-2-arnd@kernel.org> X-Mailer: git-send-email 2.29.2 In-Reply-To: <20210318134334.2933141-1-arnd@kernel.org> References: <20210318134334.2933141-1-arnd@kernel.org> MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org From: Arnd Bergmann As seen from a recent syzbot bug report, mistakes in the compat ioctl implementation can lead to uninitialized kernel stack data getting used as input for driver ioctl handlers. The reported bug is now fixed, but it's possible that other related bugs are still present or get added in the future. As the drivers need to check user input already, the possible impact is fairly low, but it might still cause an information leak. To be on the safe side, always clear the entire ioctl buffer before calling the conversion handler functions that are meant to initialize them. Signed-off-by: Arnd Bergmann Reviewed-by: Laurent Pinchart --- drivers/media/v4l2-core/v4l2-ioctl.c | 51 ++++++++++++++++------------ 1 file changed, 29 insertions(+), 22 deletions(-) diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c index 2b1bb68dc27f..6cec92d0972c 100644 --- a/drivers/media/v4l2-core/v4l2-ioctl.c +++ b/drivers/media/v4l2-core/v4l2-ioctl.c @@ -3164,12 +3164,23 @@ static int video_get_user(void __user *arg, void *parg, if (cmd == real_cmd) { if (copy_from_user(parg, (void __user *)arg, n)) - err = -EFAULT; - } else if (in_compat_syscall()) { - err = v4l2_compat_get_user(arg, parg, cmd); - } else { - switch (cmd) { + return -EFAULT; + + /* zero out anything we don't copy from userspace */ + if (n < _IOC_SIZE(real_cmd)) + memset((u8 *)parg + n, 0, _IOC_SIZE(real_cmd) - n); + + return 0; + } + + /* zero out whole buffer first to deal with missing emulation */ + memset(parg, 0, _IOC_SIZE(real_cmd)); + + if (in_compat_syscall()) + return v4l2_compat_get_user(arg, parg, cmd); + #if !defined(CONFIG_64BIT) && defined(CONFIG_COMPAT_32BIT_TIME) + switch (cmd) { case VIDIOC_QUERYBUF_TIME32: case VIDIOC_QBUF_TIME32: case VIDIOC_DQBUF_TIME32: @@ -3182,28 +3193,24 @@ static int video_get_user(void __user *arg, void *parg, *vb = (struct v4l2_buffer) { .index = vb32.index, - .type = vb32.type, - .bytesused = vb32.bytesused, - .flags = vb32.flags, - .field = vb32.field, - .timestamp.tv_sec = vb32.timestamp.tv_sec, - .timestamp.tv_usec = vb32.timestamp.tv_usec, - .timecode = vb32.timecode, - .sequence = vb32.sequence, - .memory = vb32.memory, - .m.userptr = vb32.m.userptr, - .length = vb32.length, - .request_fd = vb32.request_fd, + .type = vb32.type, + .bytesused = vb32.bytesused, + .flags = vb32.flags, + .field = vb32.field, + .timestamp.tv_sec = vb32.timestamp.tv_sec, + .timestamp.tv_usec = vb32.timestamp.tv_usec, + .timecode = vb32.timecode, + .sequence = vb32.sequence, + .memory = vb32.memory, + .m.userptr = vb32.m.userptr, + .length = vb32.length, + .request_fd = vb32.request_fd, }; break; } -#endif - } } +#endif - /* zero out anything we don't copy from userspace */ - if (!err && n < _IOC_SIZE(real_cmd)) - memset((u8 *)parg + n, 0, _IOC_SIZE(real_cmd) - n); return err; }