From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 39B85C433EF for ; Fri, 12 Nov 2021 19:57:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1B67B60F4B for ; Fri, 12 Nov 2021 19:57:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235416AbhKLUAa (ORCPT ); Fri, 12 Nov 2021 15:00:30 -0500 Received: from out02.mta.xmission.com ([166.70.13.232]:32808 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232474AbhKLUA3 (ORCPT ); Fri, 12 Nov 2021 15:00:29 -0500 Received: from in01.mta.xmission.com ([166.70.13.51]:48836) by out02.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1mlcg4-000QrO-Em; Fri, 12 Nov 2021 12:57:36 -0700 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95]:40172 helo=email.froward.int.ebiederm.org.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1mlcg3-005hJW-74; Fri, 12 Nov 2021 12:57:35 -0700 From: ebiederm@xmission.com (Eric W. Biederman) To: Brian Gerst Cc: Linux Kernel Mailing List , Linus Torvalds , Oleg Nesterov , Al Viro , Kees Cook , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "the arch\/x86 maintainers" , H Peter Anvin , Andy Lutomirski References: <87y26nmwkb.fsf@disp2133> <20211020174406.17889-9-ebiederm@xmission.com> <874k8htmb2.fsf@email.froward.int.ebiederm.org> Date: Fri, 12 Nov 2021 13:57:02 -0600 In-Reply-To: (Brian Gerst's message of "Fri, 12 Nov 2021 12:51:32 -0500") Message-ID: <87ilwxrvu9.fsf@email.froward.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1mlcg3-005hJW-74;;;mid=<87ilwxrvu9.fsf@email.froward.int.ebiederm.org>;;;hst=in01.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX19XfSxruRf8CAAJlBQOOZWkHIpRzckguFY= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH 09/20] signal/vm86_32: Replace open coded BUG_ON with an actual BUG_ON X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Brian Gerst writes: > On Fri, Nov 12, 2021 at 10:41 AM Eric W. Biederman > wrote: >> >> "Eric W. Biederman" writes: >> >> > The function save_v86_state is only called when userspace was >> > operating in vm86 mode before entering the kernel. Not having vm86 >> > state in the task_struct should never happen. So transform the hand >> > rolled BUG_ON into an actual BUG_ON to make it clear what is >> > happening. >> >> Now that this change has been merged into Linus' tree I have a report >> that it is possible to trigger this new BUG_ON. Which obviously is not >> good. >> >> We could revert the change but I think that would just be shooting the >> messenger. >> >> Does anyone have an idea where to start to track down what is going on? >> >> A very quick skim through the code suggests that the only code path >> that calls save_v86_state that has not already accessed is >> current->thread.vm86 is handle_signal. >> >> Another quick look suggests that the only place where X86_VM_MASK gets >> set in eflags is in do_sys_vm86. So it appears do_sys_vm86 must >> be called before v8086_mode returns true in handle_signal. >> >> Which seems to suggest that the bug on can't trigger. >> >> But that is obviously wrong. >> >> I will keep digging but if anyone has some ideas that would be appreciated. >> >> Eric > > It's possible that a null pointer was passed to the vm86 syscall. > Since vm86 mode usually requires memory to be mapped at address 0 this > wouldn't trigger a fault when reading the vm86_struct data. It should > be fine to remove !vm86->user_vm86 from the BUG_ON(), since the write > to userspace can handle a fault. Agreed, and that is plausible. Still user space would have had to have mapped address 0 to get that value set in do_sys_vm86. I will see about cooking up a patch for that case regardless. I am not quite convinced, but perhaps the easiest way to tell is to simply remove the unnecessary test and ask the fuzzer folks to see if they can still hit the BUG_ON. Eric