Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp110653yba; Mon, 20 May 2019 05:54:43 -0700 (PDT) X-Google-Smtp-Source: APXvYqx21tnD6nXwJwz5V3o73ipIU2kw0IeEjqvNU638kNdQKKt4pFpenXpYPgP8SdqvKkeWcpyK X-Received: by 2002:a63:c203:: with SMTP id b3mr45121534pgd.398.1558356883759; Mon, 20 May 2019 05:54:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558356883; cv=none; d=google.com; s=arc-20160816; b=Oqg32xbbVjuMu36A3ZSuweeqo9n4x6UL8RaKg92dyKZQzlKTIRX0iTqxV9njXgttoT BQR83mKEtKRRlVRHr0xsjFWVyyqvqXtbaVqtzYdjtE6j/g3C6CUnQ96OCzDkh6ez5C8J 6ygKFJ6/uFE4yMxDSyd3IVBg7vEBxsulgNf0kWRWyo2Qph0YhugUPqK5eAl3QJCwfdbt 1M9ORbYBQDh8SVnZsirNeAAnRV2o/t0PDzKdbVuYyi3vi4Y7KyYZQoYeuvQDPS3na+x0 G74t2e26gZ8AWSbd5X9/B1SSfogSd6YfapQ8fdrNrpHYahohUiCR0FSZY+yKEIKOw+xk Y1bw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=stmF6/iFtEajVGXFb0sRKumPaKg5Mvhugo0HTgONLcQ=; b=JKwvTMyf6kiJV08SGySeg9k+7zAIDd5tymNHmtGLlDNPAkQAoGtw2cll8dPS7uTfUv OPBLFu6MMhSsYcN7r3EaEASHjCdRaOhht59TBsvXH0/8IP93UDyWKFggUyxqNYBZqOOO B6cWKNDOYb2HhKKOqTqx6UqI9gZW6gQQ2+QZxtVccsU+NYr17lq2aSOJ3x1guDql9XOl WEjHIIzQoIQkmYrfFik+cbKUWu/WCLGtOpLBx1e0z2IUySoKTO/PqqH/MDiofnHZdUal D0EGnwWoazSqsCEeIFxAa6c1evv1NbfsG2uy6UwymT9wZJRnTxwzeF86ZfqEOPPdhg7w pWIw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=qTuHHc0T; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y125si20480637pfb.115.2019.05.20.05.54.29; Mon, 20 May 2019 05:54:43 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=qTuHHc0T; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387688AbfETMSC (ORCPT + 99 others); Mon, 20 May 2019 08:18:02 -0400 Received: from mail.kernel.org ([198.145.29.99]:59090 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1733054AbfETMSA (ORCPT ); Mon, 20 May 2019 08:18:00 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id D2C24213F2; Mon, 20 May 2019 12:17:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1558354679; bh=sxpB7FQt5hq7U4zwTHL6qIJiFR+nyeKVpLctJir5EYE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qTuHHc0TzZ9zz/We1C6Gvk9MEN7uNLT9EUw0IRB3/K/uy0lcn1s066DhaWJedcuLB bQ0N/zj1uF1Z9pWG0GVsadnM0bk32ArE6ExDIE7sKClDq5AO6yFWYe2sy75tqBqTl3 oM3Z/wwFKSEtpKvVu2pjm+8VkVizAthF1QNNX1Ck= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Jiri Slaby , Sergei Trofimovich Subject: [PATCH 4.9 26/44] tty/vt: fix write/write race in ioctl(KDSKBSENT) handler Date: Mon, 20 May 2019 14:14:15 +0200 Message-Id: <20190520115234.061590481@linuxfoundation.org> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190520115230.720347034@linuxfoundation.org> References: <20190520115230.720347034@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Sergei Trofimovich commit 46ca3f735f345c9d87383dd3a09fa5d43870770e upstream. The bug manifests as an attempt to access deallocated memory: BUG: unable to handle kernel paging request at ffff9c8735448000 #PF error: [PROT] [WRITE] PGD 288a05067 P4D 288a05067 PUD 288a07067 PMD 7f60c2063 PTE 80000007f5448161 Oops: 0003 [#1] PREEMPT SMP CPU: 6 PID: 388 Comm: loadkeys Tainted: G C 5.0.0-rc6-00153-g5ded5871030e #91 Hardware name: Gigabyte Technology Co., Ltd. To be filled by O.E.M./H77M-D3H, BIOS F12 11/14/2013 RIP: 0010:__memmove+0x81/0x1a0 Code: 4c 89 4f 10 4c 89 47 18 48 8d 7f 20 73 d4 48 83 c2 20 e9 a2 00 00 00 66 90 48 89 d1 4c 8b 5c 16 f8 4c 8d 54 17 f8 48 c1 e9 03 48 a5 4d 89 1a e9 0c 01 00 00 0f 1f 40 00 48 89 d1 4c 8b 1e 49 RSP: 0018:ffffa1b9002d7d08 EFLAGS: 00010203 RAX: ffff9c873541af43 RBX: ffff9c873541af43 RCX: 00000c6f105cd6bf RDX: 0000637882e986b6 RSI: ffff9c8735447ffb RDI: ffff9c8735447ffb RBP: ffff9c8739cd3800 R08: ffff9c873b802f00 R09: 00000000fffff73b R10: ffffffffb82b35f1 R11: 00505b1b004d5b1b R12: 0000000000000000 R13: ffff9c873541af3d R14: 000000000000000b R15: 000000000000000c FS: 00007f450c390580(0000) GS:ffff9c873f180000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff9c8735448000 CR3: 00000007e213c002 CR4: 00000000000606e0 Call Trace: vt_do_kdgkb_ioctl+0x34d/0x440 vt_ioctl+0xba3/0x1190 ? __bpf_prog_run32+0x39/0x60 ? mem_cgroup_commit_charge+0x7b/0x4e0 tty_ioctl+0x23f/0x920 ? preempt_count_sub+0x98/0xe0 ? __seccomp_filter+0x67/0x600 do_vfs_ioctl+0xa2/0x6a0 ? syscall_trace_enter+0x192/0x2d0 ksys_ioctl+0x3a/0x70 __x64_sys_ioctl+0x16/0x20 do_syscall_64+0x54/0xe0 entry_SYSCALL_64_after_hwframe+0x49/0xbe The bug manifests on systemd systems with multiple vtcon devices: # cat /sys/devices/virtual/vtconsole/vtcon0/name (S) dummy device # cat /sys/devices/virtual/vtconsole/vtcon1/name (M) frame buffer device There systemd runs 'loadkeys' tool in tapallel for each vtcon instance. This causes two parallel ioctl(KDSKBSENT) calls to race into adding the same entry into 'func_table' array at: drivers/tty/vt/keyboard.c:vt_do_kdgkb_ioctl() The function has no locking around writes to 'func_table'. The simplest reproducer is to have initrams with the following init on a 8-CPU machine x86_64: #!/bin/sh loadkeys -q windowkeys ru4 & loadkeys -q windowkeys ru4 & loadkeys -q windowkeys ru4 & loadkeys -q windowkeys ru4 & loadkeys -q windowkeys ru4 & loadkeys -q windowkeys ru4 & loadkeys -q windowkeys ru4 & loadkeys -q windowkeys ru4 & wait The change adds lock on write path only. Reads are still racy. CC: Greg Kroah-Hartman CC: Jiri Slaby Link: https://lkml.org/lkml/2019/2/17/256 Signed-off-by: Sergei Trofimovich Cc: stable Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman --- drivers/tty/vt/keyboard.c | 33 +++++++++++++++++++++++++++------ 1 file changed, 27 insertions(+), 6 deletions(-) --- a/drivers/tty/vt/keyboard.c +++ b/drivers/tty/vt/keyboard.c @@ -121,6 +121,7 @@ static const int NR_TYPES = ARRAY_SIZE(m static struct input_handler kbd_handler; static DEFINE_SPINLOCK(kbd_event_lock); static DEFINE_SPINLOCK(led_lock); +static DEFINE_SPINLOCK(func_buf_lock); /* guard 'func_buf' and friends */ static unsigned long key_down[BITS_TO_LONGS(KEY_CNT)]; /* keyboard key bitmap */ static unsigned char shift_down[NR_SHIFT]; /* shift state counters.. */ static bool dead_key_next; @@ -1959,11 +1960,12 @@ int vt_do_kdgkb_ioctl(int cmd, struct kb char *p; u_char *q; u_char __user *up; - int sz; + int sz, fnw_sz; int delta; char *first_free, *fj, *fnw; int i, j, k; int ret; + unsigned long flags; if (!capable(CAP_SYS_TTY_CONFIG)) perm = 0; @@ -2006,7 +2008,14 @@ int vt_do_kdgkb_ioctl(int cmd, struct kb goto reterr; } + fnw = NULL; + fnw_sz = 0; + /* race aginst other writers */ + again: + spin_lock_irqsave(&func_buf_lock, flags); q = func_table[i]; + + /* fj pointer to next entry after 'q' */ first_free = funcbufptr + (funcbufsize - funcbufleft); for (j = i+1; j < MAX_NR_FUNC && !func_table[j]; j++) ; @@ -2014,10 +2023,12 @@ int vt_do_kdgkb_ioctl(int cmd, struct kb fj = func_table[j]; else fj = first_free; - + /* buffer usage increase by new entry */ delta = (q ? -strlen(q) : 1) + strlen(kbs->kb_string); + if (delta <= funcbufleft) { /* it fits in current buf */ if (j < MAX_NR_FUNC) { + /* make enough space for new entry at 'fj' */ memmove(fj + delta, fj, first_free - fj); for (k = j; k < MAX_NR_FUNC; k++) if (func_table[k]) @@ -2030,20 +2041,28 @@ int vt_do_kdgkb_ioctl(int cmd, struct kb sz = 256; while (sz < funcbufsize - funcbufleft + delta) sz <<= 1; - fnw = kmalloc(sz, GFP_KERNEL); - if(!fnw) { - ret = -ENOMEM; - goto reterr; + if (fnw_sz != sz) { + spin_unlock_irqrestore(&func_buf_lock, flags); + kfree(fnw); + fnw = kmalloc(sz, GFP_KERNEL); + fnw_sz = sz; + if (!fnw) { + ret = -ENOMEM; + goto reterr; + } + goto again; } if (!q) func_table[i] = fj; + /* copy data before insertion point to new location */ if (fj > funcbufptr) memmove(fnw, funcbufptr, fj - funcbufptr); for (k = 0; k < j; k++) if (func_table[k]) func_table[k] = fnw + (func_table[k] - funcbufptr); + /* copy data after insertion point to new location */ if (first_free > fj) { memmove(fnw + (fj - funcbufptr) + delta, fj, first_free - fj); for (k = j; k < MAX_NR_FUNC; k++) @@ -2056,7 +2075,9 @@ int vt_do_kdgkb_ioctl(int cmd, struct kb funcbufleft = funcbufleft - delta + sz - funcbufsize; funcbufsize = sz; } + /* finally insert item itself */ strcpy(func_table[i], kbs->kb_string); + spin_unlock_irqrestore(&func_buf_lock, flags); break; } ret = 0;