linux-kernel - Re: [PATCH] firmware: fix async/manual firmware loading

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAB=NE6UUygCN-DaYHeBZwM0UDCpKqFxPV0w2TvC79csUJkxbRA@mail.gmail.com>
Date:   Thu, 10 Nov 2016 13:22:07 -0800
From:   "Luis R. Rodriguez" <mcgrof@...nel.org>
To:     Yves-Alexis Perez <corsac@...sac.net>
Cc:     Bjorn Andersson <bjorn.andersson@...aro.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Ming Lei <ming.lei@...onical.com>,
        Johannes Berg <johannes@...solutions.net>,
        Jouni Malinen <j@...fi>, Kees Cook <keescook@...omium.org>,
        Jiri Kosina <jkosina@...e.cz>, Jiri Slaby <jslaby@...e.com>,
        Tom Gundersen <teg@...m.no>, Kay Sievers <kay@...y.org>,
        Josh Boyer <jwboyer@...oraproject.org>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Andy Lutomirski <luto@...capital.net>,
        Harald Hoyer <harald@...hat.com>,
        Seth Forshee <seth.forshee@...onical.com>,
        Daniel Wagner <wagi@...om.org>, "4.2+" <stable@...r.kernel.org>
Subject: Re: [PATCH] firmware: fix async/manual firmware loading

On Thu, Nov 10, 2016 at 1:04 PM, Yves-Alexis Perez <corsac@...sac.net> wrote:
> On Thu, 2016-11-10 at 11:48 -0800, Luis R. Rodriguez wrote:
>> > I haven't verified that this particular use case actually worked before,
>> > but this code works with lower timeout values (e.g. 60 in the fallback
>> > case), so this looks isolated.
>>
>> This is true, but as I noted the broken aspect was when the timeout
>> was set to the max value.
>>
>> > The bug was clearly introduced in v4.0 by:
>> >
>> > 68ff2a00dbf5 "firmware_loader: handle timeout via
>> > wait_for_completion_interruptible_timeout()"
>> >
>> > So please add a Fixes: and
>> >
>> > Reviewed-by: Bjorn Andersson <bjorn.andersson@...aro.org>
>>
>> This I agree with, thanks for that, and because of this then:
>>
>> Acked-by: Luis R. Rodriguez <mcgrof@...nel.org>
>>
>> And because of this do recommend it for stable. I would still prefer
>> at least a new re-submit with the respected tags and a changed commit
>> log describing the reason for the fix, how the cast is an issue
>> exactly, and how this is a regression.
>
> Hi all,
>
> I'm still slightly confused, but I can certainly re-submit it. I've added the
> CC: stable because I first experienced it on a stable box, but indeed it was
> during coding a kernel driver so it might not be what's expected in
> “regression” here.

If you look at the code added on commit 68ff2a00dbf5
("firmware_loader: handle timeout via
wait_for_completion_interruptible_timeout()") by Ming you'll see that
the else statement setting the timeout to MAX_JIFFY_OFFSET for the
non-udev event was only added there, so this commit caused the cast to
fail, as such this should be the commit that introduced the issue.

Then

git describe --contains 68ff2a00dbf5
v4.0-rc1~83^2~1

So this was added as of v4.0, so the regression appeared first as of
v4.0. You could try v3.19 or just revert this commit to verify if this
would have fixed the issue you are reporting to confirm this indeed
was the regression, but upon code examination it seems to be the case.

> I'll try to collect the tag and rewrite the commit log, then re-submit,
> hopefully not messing with git send-email this time.

Thanks!

  Luis