linux-kernel - Re: [PATCH] mm: fix pfn calculation mistake in __ioremap_check

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]

Date:   Mon, 7 Jun 2021 06:55:39 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Yaohui Wang <yaohuiwang@...ux.alibaba.com>,
        dave.hansen@...ux.intel.com
Cc:     luto@...nel.org, peterz@...radead.org,
        linux-kernel@...r.kernel.org, yaohuiwang@...ux.alibaba-inc.com,
        luoben@...ux.alibaba.com
Subject: Re: [PATCH] mm: fix pfn calculation mistake in __ioremap_check_ram

On 6/7/21 2:19 AM, Yaohui Wang wrote:
> According to the source code in function
> arch/x86/mm/ioremap.c:__ioremap_caller, after __ioremap_check_mem, if the
> mem range is IORES_MAP_SYSTEM_RAM, then __ioremap_caller should fail. But
> because of the pfn calculation problem, __ioremap_caller can success
> on IORES_MAP_SYSTEM_RAM region when the @size parameter is less than
> PAGE_SIZE. This may cause misuse of the ioremap function and raise the
> risk of performance issues. For example, ioremap(phys, PAGE_SIZE-1) may
> cause the direct memory mapping of @phys to be uncached, and iounmap won't
> revert this change. This patch fixes this issue.
> 
> In arch/x86/mm/ioremap.c:__ioremap_check_ram, start_pfn should wrap down
> the res->start address, and end_pfn should wrap up the res->end address.
> This makes the check more strict and should be more reasonable.

Was this found by inspection, or was there a real-world bug which this
patch addresses?