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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 28 Aug 2020 10:41:29 +0300
From:   Kalle Valo <>
To:     Steve deRosier <>
Cc:     Mauro Carvalho Chehab <>,,,
        John Stultz <>,
        Manivannan Sadhasivam <>,
        "David S. Miller" <>,
        Jakub Kicinski <>, Maital Hahn <>,
        "Gustavo A. R. Silva" <>,
        Raz Bouganim <>,
        Tony Lindgren <>,
        Dinghao Liu <>,
        Johannes Berg <>,
        Fuqian Huang <>,
        linux-wireless <>,
        Network Development <>,
        LKML <>
Subject: Re: [PATCH] Revert "wlcore: Adding suppoprt for IGTK key in wlcore driver"

Steve deRosier <> writes:

> On Tue, Aug 25, 2020 at 10:49 PM Mauro Carvalho Chehab
> <> wrote:
>> This patch causes a regression betwen Kernel 5.7 and 5.8 at wlcore:
>> with it applied, WiFi stops working, and the Kernel starts printing
>> this message every second:
>>    wlcore: PHY firmware version: Rev
>>    wlcore: firmware booted (Rev
>>    wlcore: ERROR command execute failure 14
> Only if NO firmware for the device in question supports the `KEY_IGTK`
> value, then this revert is appropriate. Otherwise, it likely isn't.
>  My suspicion is that the feature that `KEY_IGTK` is enabling is
> specific to a newer firmware that Mauro hasn't upgraded to. What the
> OP should do is find the updated firmware and give it a try.
> AND - since there's some firmware the feature doesn't work with, the
> driver should be fixed to detect the running firmware version and not
> do things that the firmware doesn't support.  AND the firmware writer
> should also make it so the firmware doesn't barf on bad input and
> instead rejects it politely.
> But I will say I'm making an educated guess; while I have played with
> the TI devices in the past, it was years ago and I won't claim to be
> an expert. I also am unable to fix it myself at this time.
> I'd just rather see it fixed properly instead of a knee-jerk reaction
> of reverting it simply because the OP doesn't have current firmware.

Yeah, a proper fix for this is of course better but if there's no fix,
say within the next week or so, let's revert this. A new version of the
patch implementing IGTK, with proper feature detection, can be always
added later.


Powered by blists - more mailing lists