linux-kernel - Re: [PATCH] platform/x86: intel_pmc_core: Fix potential buffer overflows

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: <394f3b53-7896-c602-a6d2-e0e17d1e647e@ispras.ru>
Date:   Wed, 4 Aug 2021 12:43:43 +0300
From:   Evgeny Novikov <novikov@...ras.ru>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Rajneesh Bhardwaj <irenic.rajneesh@...il.com>,
        David E Box <david.e.box@...el.com>,
        Hans de Goede <hdegoede@...hat.com>,
        Mark Gross <mgross@...ux.intel.com>,
        "David E. Box" <david.e.box@...ux.intel.com>,
        Gayatri Kammela <gayatri.kammela@...el.com>,
        Platform Driver <platform-driver-x86@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        ldv-project@...uxtesting.org
Subject: Re: [PATCH] platform/x86: intel_pmc_core: Fix potential buffer
 overflows

On 03.08.2021 21:30, Andy Shevchenko wrote:
> On Tue, Aug 3, 2021 at 9:26 PM Andy Shevchenko
> <andy.shevchenko@...il.com> wrote:
>> On Tue, Aug 3, 2021 at 9:21 PM Evgeny Novikov <novikov@...ras.ru> wrote:
>>> It looks like pmc_core_get_low_power_modes() mixes up modes and
>>> priorities. In addition to invalid behavior, potentially this can
>>> cause buffer overflows since the driver reads priorities from the
>>> register and then it uses them as indexes for array lpm_priority
>>> that can contain 8 elements at most. The patch swaps modes and
>>> priorities.
>>>
>>> Found by Linux Driver Verification project (linuxtesting.org).
>> Seems legit.
> Hold on, but then it follows with another loop where actually it reads
> modes by priority index. Can you elaborate what exactly is the problem
> you think?
>
I agree with you and David that my fix was not valid from the functional

point of view. Indeed, some issues can happen if something unexpected

will be read from the register. For instance, for priority equals to 255 you

will have pri0 = 15 and prio1 = 15. Obviously, you can not access the

lpm_priority array consisting of just 8 elements by these indexes.


Best regards,

Evgeny Novikov