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 X-Spam-Level: X-Spam-Status: No, score=-2.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no 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 7136EC4338F for ; Sat, 24 Jul 2021 21:03:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 367BA60720 for ; Sat, 24 Jul 2021 21:03:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229707AbhGXUWk (ORCPT ); Sat, 24 Jul 2021 16:22:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45556 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229508AbhGXUWj (ORCPT ); Sat, 24 Jul 2021 16:22:39 -0400 Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D7BD2C061575 for ; Sat, 24 Jul 2021 14:03:09 -0700 (PDT) Received: by mail-pj1-x102b.google.com with SMTP id pf12-20020a17090b1d8cb0290175c085e7a5so14117671pjb.0 for ; Sat, 24 Jul 2021 14:03:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kEcCULqEhyKo2SpGJ7Bqqo2I7j0KMhnjJxCcjjRShVM=; b=O08+G8oEvcc5wa+k03WpMAiABwmJGk/2QcKYkhhhXIIjEYujrBrqnmHOmGl0MVE2Ys X7nboEc6mVsLFFqpQTQgdl3zFQlkwEd1/0Tqe0dBjkkcoL1JgUtCo4jobmr14KhzXmZP VnsJlJyHlFGR9+axQGRoEkupOGlgJKqnV/ke56sf/g9/4cgkCh5AFnSkLD3h4xFAJHzT SJoNzT3fcIS9blGStoxhEtYlJ232UwZ9hxwsEbjzDsrBi9D4AGdA/JCsd/ytImTGHRDq URzGArLt4HvJh1lovFFHG2F8GJkl92y58LN7/8/goLuYz4aUJn+f3UyRMwNBDz/ajE24 ZsvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kEcCULqEhyKo2SpGJ7Bqqo2I7j0KMhnjJxCcjjRShVM=; b=k2Z7X5FGfCr4GIS1gXmDJgKk29RDXljM82pEio1RXVZPY6oDTLqWggoE608xtTJtTk z5pYQIf1AIunHo23zWRH8PJeQ18gc+w467ZEsWQ9fH69MpAuPFm8LZcmsE3yylYcQnaA UYuj1ls+ddiE8afZpwA2Bb6DRmUkiH1txtki651SqP9DVxF0SvPP8qS0nXajlH7B6kjC R/3pCqQWFFD3BRwYqPQRhW+tVMOxvRW8a/6Xji7WyvhTWMc+nR+yEg7FoLX92Lrx9CQm c4v63vSbQaDzxrT1i5grqq89dj/ZTYjt7tBIfHByH7oZmOZj4czqtWiiHdJWKlD5EUOO MYog== X-Gm-Message-State: AOAM53298IHqARUJf1XAy3+ZPb/mOfmhwi6pib/gbqGezXTCm1PiRJkD YpzGXljH9fI1c80N4CFBt4MmxMaxOSG0qyHBEj8= X-Google-Smtp-Source: ABdhPJwtzob59wiKP2UdJSzMit3B6pc7qSsZfnlE6rn42x4zn/OiL5xUloOLwq3ckcRAsS5A+9udDhdAFWlJ8hPfDNE= X-Received: by 2002:aa7:8a04:0:b029:332:950e:d976 with SMTP id m4-20020aa78a040000b0290332950ed976mr10721501pfa.40.1627160589201; Sat, 24 Jul 2021 14:03:09 -0700 (PDT) MIME-Version: 1.0 References: <99068691-01ea-d2b5-3dd3-1a2852fe5723@kernel.dk> In-Reply-To: From: Andy Shevchenko Date: Sun, 25 Jul 2021 00:02:32 +0300 Message-ID: Subject: Re: 5.14-rc failure to resume To: Linus Torvalds Cc: Jens Axboe , LKML , Daniel Scally , "Rafael J. Wysocki" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jul 24, 2021 at 11:48 PM Linus Torvalds wrote: > > On Sat, Jul 24, 2021 at 12:44 PM Jens Axboe wrote: > > > > This does appear to be the culprit. With it reverted on top of current > > master (and with the block and io_uring changes pulled in too), the > > kernel survives many resumes without issue. > > That commit seems fundamentally buggy. > > It makes "acpi_dev_get_next_match_dev()" always do > > acpi_dev_put(adev); > > to put the previous device, but "adev" is perfectly valid as NULL, and > acpi_dev_get_next_match_dev() even tests for it: > > struct device *start = adev ? &adev->dev : NULL; > > so it can - and will - do > > acpi_dev_put(NULL); > > which does > > put_device(&adev->dev); > > and passes in an invalid pointer to put_device(). > > And yes, that adev very much can be NULL, with drivers/acpi/utils.c > even passing it in explicitly: > > struct acpi_device * > acpi_dev_get_first_match_dev(const char *hid, const char *uid, s64 hrv) > { > return acpi_dev_get_next_match_dev(NULL, hid, uid, hrv); > } > EXPORT_SYMBOL(acpi_dev_get_first_match_dev); > > Am I missing something? How does that code work at all for anybody? > > I probably _am_ missing something. Yeah, the two changes (acpi_dev_put() and this fix) were in separate submissions during different times. So, what we have here: 1) this fix misses that one line to be changed and after adding it 2) reveals UAF, or i.o.w. NULL dereference which is a bug in acpi_dev_put(). acpi_dev_put() has to be if (adev) put_device(&adev->dev); -- With Best Regards, Andy Shevchenko