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 C408AC433F5 for ; Mon, 27 Sep 2021 23:45:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A6C9961178 for ; Mon, 27 Sep 2021 23:45:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238224AbhI0Xr3 (ORCPT ); Mon, 27 Sep 2021 19:47:29 -0400 Received: from us-smtp-delivery-124.mimecast.com ([170.10.133.124]:38672 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238168AbhI0Xr1 (ORCPT ); Mon, 27 Sep 2021 19:47:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1632786348; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=nsnSPMX2S/Qat0JZTZ1IQ/fql2yzNENw+yYwIO5gmA8=; b=EleK6qrBrs4A+zqxEH65X56uM85OJ10FVUvpe6FndAGAPwJxf3fP+kq3HySM7YDv9uu6zI k0D/TJp8bSoh8IH2djagrCVkdNX88f1GYp5cK9aCUPrBsazb/NlcQTU99ADJVioX3XOMjE ejeQFmWvLL7H7zn65KqNe6YOAgn1tkw= Received: from mail-ot1-f69.google.com (mail-ot1-f69.google.com [209.85.210.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-162-WA98VS9uPO24b0K9NptRnA-1; Mon, 27 Sep 2021 19:45:47 -0400 X-MC-Unique: WA98VS9uPO24b0K9NptRnA-1 Received: by mail-ot1-f69.google.com with SMTP id l32-20020a9d1ca0000000b00546e6ec87afso17934475ota.11 for ; Mon, 27 Sep 2021 16:45:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=nsnSPMX2S/Qat0JZTZ1IQ/fql2yzNENw+yYwIO5gmA8=; b=rixdpcsGaCkW7F2GzyCkrzULoAxSPBtGnr1e+n1y4hNDxJq7XDUYSrxthLszM00ewv kdnSlxAbbvWdfkaGk2U8+A7nnHxZo+RuJ5qOwas839P8zuZ5DOTCW6C+viDRV2KU0BW7 aR0j9JnoMrEisPdspMw0iYYoxO4WRfR7RkdOgaTyV8b2leYjBZgCBHIr9YPbj/fgHD1e c43iI07RtDzyWMQDsxoMLPWAZWiVC0bp8Eouf1d2uoxIbNM9g5orRZUFh/Rp8I/bhA/I SfOOvLoImFdAYcnQERXf12TZeOWWvKv1Jj8RbO0Igsz/WWWezZV8O6qEk0WZ6EpTTRw1 Dznw== X-Gm-Message-State: AOAM531Uew6Era7qUfoNTGpS2nj1Dd3eIr65OkwHAXv0e5v205ouUMRN Vf+C0gKiaxPVrWSBeaLniO/MyZrl6c8UqPx1IdXgpQaTWjIoYKQyi04eSo2JLSzORKZ+CJRg12E KEaLyPE9EQEQ4yLDUdyFksX7r X-Received: by 2002:a05:6830:246f:: with SMTP id x47mr2385805otr.287.1632786346785; Mon, 27 Sep 2021 16:45:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzEwgyyipAso5Lnpv6vJwXUFrYJKO6zGLcI7AhX5ImXTFSCGu/useHx1lO4JT1d7wgEAIOV2g== X-Received: by 2002:a05:6830:246f:: with SMTP id x47mr2385776otr.287.1632786346571; Mon, 27 Sep 2021 16:45:46 -0700 (PDT) Received: from treble ([2600:1700:6e32:6c00::15]) by smtp.gmail.com with ESMTPSA id o62sm434028ota.14.2021.09.27.16.45.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Sep 2021 16:45:46 -0700 (PDT) Date: Mon, 27 Sep 2021 16:45:43 -0700 From: Josh Poimboeuf To: Sean Christopherson Cc: Dmitry Vyukov , Marco Elver , syzbot , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com, viro@zeniv.linux.org.uk, the arch/x86 maintainers , Linux ARM , kasan-dev , Peter Zijlstra Subject: Re: [syzbot] upstream test error: KFENCE: use-after-free in kvm_fastop_exception Message-ID: <20210927234543.6waods7rraxseind@treble> References: <000000000000d6b66705cb2fffd4@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 27, 2021 at 04:07:51PM +0000, Sean Christopherson wrote: > I was asking about the exact location to confirm that the explosion is indeed > from exception fixup, which is the "unwinder scenario get confused" I was thinking > of. Based on the disassembly from syzbot, that does indeed appear to be the case > here, i.e. this > > 2a: 4c 8b 21 mov (%rcx),%r12 > > is from exception fixup from somewhere in __d_lookup (can't tell exactly what > it's from, maybe KASAN?). > > > Is there more info on this "the unwinder gets confused"? Bug filed > > somewhere or an email thread? Is it on anybody's radar? > > I don't know if there's a bug report or if this is on anyone's radar. The issue > I've encountered in the past, and what I'm pretty sure is being hit here, is that > the ORC unwinder doesn't play nice with out-of-line fixup code, presumably because > there are no tables for the fixup. I believe kvm_fastop_exception() gets blamed > because it's the first label that's found when searching back through the tables. The ORC unwinder actually knows about .fixup, and unwinding through the .fixup code worked here, as evidenced by the entire stacktrace getting printed. Otherwise there would have been a bunch of question marks in the stack trace. The problem reported here -- falsely printing kvm_fastop_exception -- is actually in the arch-independent printing of symbol names, done by __sprint_symbol(). Most .fixup code fragments are anonymous, in the sense that they don't have symbols associated with them. For x86, here are the only defined symbols in .fixup: ffffffff81e02408 T kvm_fastop_exception ffffffff81e02728 t .E_read_words ffffffff81e0272b t .E_leading_bytes ffffffff81e0272d t .E_trailing_bytes ffffffff81e02734 t .E_write_words ffffffff81e02740 t .E_copy There's a lot of anonymous .fixup code which happens to be placed in the gap between "kvm_fastop_exception" and ".E_read_words". The kernel symbol printing code will go backwards from the given address and will print the first symbol it finds. So any anonymous code in that gap will falsely be reported as kvm_fastop_exception(). I'm thinking the ideal way to fix this would be getting rid of the .fixup section altogether, and instead place a function's corresponding fixup code in a cold part of the original function, with the help of asm_goto and cold label attributes. That way, the original faulting function would be printed instead of an obscure reference to an anonymous .fixup code fragment. It would have other benefits as well. For example, not breaking livepatch... I'll try to play around with it. -- Josh