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;
MIME-Version: 1.0
References: <eeab973d-f634-a182-6d76-f3912f8cf887@kernel.dk>
 <a607c149-6bf6-0fd0-0e31-100378504da2@kernel.dk> <99068691-01ea-d2b5-3dd3-1a2852fe5723@kernel.dk>
 <CAHk-=wggE0PF4fAi8cFEpi=ryyV=WyYupddcHHbE3nggQJgYig@mail.gmail.com>
In-Reply-To: <CAHk-=wggE0PF4fAi8cFEpi=ryyV=WyYupddcHHbE3nggQJgYig@mail.gmail.com>
From:   Andy Shevchenko <andy.shevchenko@gmail.com>
Date:   Sun, 25 Jul 2021 00:02:32 +0300
Message-ID: <CAHp75VdXMB7EaBVpvMY=sjbnoUrYY1RC7zzsh3ZsMoNgJo7TRA@mail.gmail.com>
Subject: Re: 5.14-rc failure to resume
To:     Linus Torvalds <torvalds@linux-foundation.org>
Cc:     Jens Axboe <axboe@kernel.dk>, LKML <linux-kernel@vger.kernel.org>,
        Daniel Scally <djrscally@gmail.com>,
        "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Sat, Jul 24, 2021 at 11:48 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Sat, Jul 24, 2021 at 12:44 PM Jens Axboe <axboe@kernel.dk> 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