Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp2335717ybz; Thu, 23 Apr 2020 16:15:14 -0700 (PDT) X-Google-Smtp-Source: APiQypIjNmhIpJv6xrKk98NoUsTG4zU3yUw/7xQgeuwoAmuvrb9VOfQae2Tr5/4VolqhGFYLyAQK X-Received: by 2002:aa7:d1d6:: with SMTP id g22mr5046479edp.36.1587683713925; Thu, 23 Apr 2020 16:15:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587683713; cv=none; d=google.com; s=arc-20160816; b=fcw1lXU37PbvSFnY1pV7E2u4x9x192hzTLlJoeKEFjE7ptYLtxbNWoER56gb7HFAxM ZYibfh69OfR5ClLlJMzRIs2W40H7QJaSXFylFtcKlAgBcqvA5wBzuOEYzl/UpjmBtsnI gBUFFTXeElQMM0Zux4PJuSoD4g8d9Trai+lHDooSXa+1dKcO0xmusXEgGPpQQgT880xP vBxHbCXHLyg+2K1lyBFbtWXSHgHX63oGKTZ+wT+y09gwNTWPfPV/FjHF3s/jhJM8p3cC SvqDXhezRl/A1NWwj4rlJkEremKQqlyES7rIvPAREGYzayNVOEv6mrC+ZLjNzVbv2Mf8 uDEg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition; bh=Fn8EKLwSBUF0Dgo6CvATsALKrh8+KnOy5+chu2dh18k=; b=GaI+CzOEDpt7pU6BwVJoKEjkFYWlQ3nAyWPHHFCIwdjfMClyM96/6ErVhB7vNH2N57 ZHO52t0bX2X1a6Ph+WyTX+f4bAYwYvysqH5oEI/JobM0nOvcXgXKpeWDHgqJsTZDdXgq NkLqLuH0SQXj/WMoPXA+4J8Bs3co0K09fdMNdZOmuSz5CzCToQ+xLx4Jfjh6rnI0PkWw 99Dmg5tMQVxJPWVSK/efPEA0/x3r1WEcBX68RbVovlEd+LnGlh2Sblgc0WXXE03z9mhZ 3Pu6sCNWRk3/l48deGEeGHmbMwgKz3whbDPI56tMCcrA5BfcGaXgv4vN8Ml3h3ScLJ4P nqvg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f6si1878916edw.325.2020.04.23.16.14.50; Thu, 23 Apr 2020 16:15:13 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728910AbgDWXK3 (ORCPT + 99 others); Thu, 23 Apr 2020 19:10:29 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:50506 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728609AbgDWXGy (ORCPT ); Thu, 23 Apr 2020 19:06:54 -0400 Received: from [192.168.4.242] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1jRkvh-0004uT-CH; Fri, 24 Apr 2020 00:06:49 +0100 Received: from ben by deadeye with local (Exim 4.93) (envelope-from ) id 1jRkvc-00E71g-KF; Fri, 24 Apr 2020 00:06:44 +0100 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, Denis Kirjanov , "Zhang Xiaoxu" , "Hulk Robot" , "Daniel Vetter" Date: Fri, 24 Apr 2020 00:07:25 +0100 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) X-Patchwork-Hint: ignore Subject: [PATCH 3.16 218/245] vgacon: Fix a UAF in vgacon_invert_region In-Reply-To: X-SA-Exim-Connect-IP: 192.168.4.242 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.83-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Zhang Xiaoxu commit 513dc792d6060d5ef572e43852683097a8420f56 upstream. When syzkaller tests, there is a UAF: BUG: KASan: use after free in vgacon_invert_region+0x9d/0x110 at addr ffff880000100000 Read of size 2 by task syz-executor.1/16489 page:ffffea0000004000 count:0 mapcount:-127 mapping: (null) index:0x0 page flags: 0xfffff00000000() page dumped because: kasan: bad access detected CPU: 1 PID: 16489 Comm: syz-executor.1 Not tainted Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014 Call Trace: [] dump_stack+0x1e/0x20 [] kasan_report+0x577/0x950 [] __asan_load2+0x62/0x80 [] vgacon_invert_region+0x9d/0x110 [] invert_screen+0xe5/0x470 [] set_selection+0x44b/0x12f0 [] tioclinux+0xee/0x490 [] vt_ioctl+0xff4/0x2670 [] tty_ioctl+0x46a/0x1a10 [] do_vfs_ioctl+0x5bd/0xc40 [] SyS_ioctl+0x132/0x170 [] system_call_fastpath+0x22/0x27 Memory state around the buggy address: ffff8800000fff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff8800000fff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff880000100000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff It can be reproduce in the linux mainline by the program: #include #include #include #include #include #include #include #include struct tiocl_selection { unsigned short xs; /* X start */ unsigned short ys; /* Y start */ unsigned short xe; /* X end */ unsigned short ye; /* Y end */ unsigned short sel_mode; /* selection mode */ }; #define TIOCL_SETSEL 2 struct tiocl { unsigned char type; unsigned char pad; struct tiocl_selection sel; }; int main() { int fd = 0; const char *dev = "/dev/char/4:1"; struct vt_consize v = {0}; struct tiocl tioc = {0}; fd = open(dev, O_RDWR, 0); v.v_rows = 3346; ioctl(fd, VT_RESIZEX, &v); tioc.type = TIOCL_SETSEL; ioctl(fd, TIOCLINUX, &tioc); return 0; } When resize the screen, update the 'vc->vc_size_row' to the new_row_size, but when 'set_origin' in 'vgacon_set_origin', vgacon use 'vga_vram_base' for 'vc_origin' and 'vc_visible_origin', not 'vc_screenbuf'. It maybe smaller than 'vc_screenbuf'. When TIOCLINUX, use the new_row_size to calc the offset, it maybe larger than the vga_vram_size in vgacon driver, then bad access. Also, if set an larger screenbuf firstly, then set an more larger screenbuf, when copy old_origin to new_origin, a bad access may happen. So, If the screen size larger than vga_vram, resize screen should be failed. This alse fix CVE-2020-8649 and CVE-2020-8647. Linus pointed out that overflow checking seems absent. We're saved by the existing bounds checks in vc_do_resize() with rather strict limits: if (cols > VC_RESIZE_MAXCOL || lines > VC_RESIZE_MAXROW) return -EINVAL; Fixes: 0aec4867dca14 ("[PATCH] SVGATextMode fix") Reference: CVE-2020-8647 and CVE-2020-8649 Reported-by: Hulk Robot Signed-off-by: Zhang Xiaoxu [danvet: augment commit message to point out overflow safety] Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20200304022429.37738-1-zhangxiaoxu5@huawei.com Signed-off-by: Ben Hutchings --- drivers/video/console/vgacon.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/video/console/vgacon.c +++ b/drivers/video/console/vgacon.c @@ -1312,6 +1312,9 @@ static int vgacon_font_get(struct vc_dat static int vgacon_resize(struct vc_data *c, unsigned int width, unsigned int height, unsigned int user) { + if ((width << 1) * height > vga_vram_size) + return -EINVAL; + if (width % 2 || width > screen_info.orig_video_cols || height > (screen_info.orig_video_lines * vga_default_font_height)/ c->vc_font.height)