linux-kernel - Re: [PATCH] platform/x86: peaq-wmi: Add DMI check before binding to the WMI interface

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHp75VfxGqrrk_Cs9w8PVMY2o9=cYE9SENDTUs=39RHmqXDmAQ@mail.gmail.com>
Date:   Thu, 5 Oct 2017 21:19:23 +0300
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Hans de Goede <hdegoede@...hat.com>
Cc:     Darren Hart <dvhart@...radead.org>,
        Andy Shevchenko <andy@...radead.org>,
        Kai Heng Feng <kai.heng.feng@...onical.com>,
        Platform Driver <platform-driver-x86@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        stable@...r.kernel.org
Subject: Re: [PATCH] platform/x86: peaq-wmi: Add DMI check before binding to
 the WMI interface

On Thu, Oct 5, 2017 at 9:04 PM, Hans de Goede <hdegoede@...hat.com> wrote:
> It seems that the WMI GUID used by the PEAQ 2-in-1 WMI hotkeys is not
> as unique as a GUID should be and is used on some other devices too.
>
> This is causing spurious key-press reports on these other devices.
>
> This commits adds a DMI check to the PEAQ 2-in-1 WMI hotkeys driver to
> ensure that it is actually running on a PEAQ 2-in-1, fixing the
> spurious key-presses on these other devices.

Thanks!

One comment though.

>  static void __exit peaq_wmi_exit(void)
>  {
> +       if (!dmi_check_system(peaq_dmi_table))
> +               return;
> +
>         if (!wmi_has_guid(PEAQ_DOLBY_BUTTON_GUID))
>                 return;

I was thinking, after got kbuid bot complains on Kai's patch on
sections mismatch, do we need these checks at all?
How would be possible to get a module loaded in the first place if
system is not in whitelist?

If I'm right, please, drop the check and move table to __initconst.

-- 
With Best Regards,
Andy Shevchenko