linux-kernel - Re: [PATCH 1/3 v3] resource: fix an error which walks through iomem resources

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: <01551d06-c421-5df3-b19f-fc66f3639e4f@redhat.com>
Date:   Tue, 25 Sep 2018 15:08:01 +0800
From:   lijiang <lijiang@...hat.com>
To:     Bjorn Helgaas <helgaas@...nel.org>
Cc:     linux-kernel@...r.kernel.org, kexec@...ts.infradead.org,
        tglx@...utronix.de, mingo@...hat.com, hpa@...or.com,
        x86@...nel.org, akpm@...ux-foundation.org,
        dan.j.williams@...el.com, thomas.lendacky@....com,
        bhelgaas@...gle.com, baiyaowei@...s.chinamobile.com, tiwai@...e.de,
        bp@...e.de, brijesh.singh@....com, dyoung@...hat.com,
        bhe@...hat.com
Subject: Re: [PATCH 1/3 v3] resource: fix an error which walks through iomem
 resources

在 2018年09月25日 01:52, Bjorn Helgaas 写道:
> On Fri, Sep 21, 2018 at 03:32:09PM +0800, Lianbo Jiang wrote:
>> When we walk through iomem resources by calling walk_iomem_res_desc(),
>> the values of the function parameter may be modified in the while loop
>> of __walk_iomem_res_desc(), which will cause us to not get the desired
>> result in some cases.
> 
> If I understand correctly, the issue is caused by the interaction
> between __walk_iomem_res_desc() and find_next_iomem_res() in this
> path:
> 
>   __walk_iomem_res_desc
>     find_next_iomem_res
>       res->flags = p->flags;            # <-- problem
> 
> This path is used by the following interfaces, and I think your patch
> would fix the issue for them:
> 
>   walk_iomem_res_desc()
>   walk_system_ram_res()
>   walk_mem_res()
> 
> However, find_next_iomem_res() is also used directly by
> walk_system_ram_range().  I think that path has the same problem, and
> your patch does not fix that path.
> 
Thanks for your comment. 
Originally, my patch 1 only fixed this issue in kdump path, of course, i can
also improve this patch and fix the same issue in walk_system_ram_range().
If you have fixed this issue, it's good to me.

> I have a few more comments related to the existing code that I'll post
> soon.
> 
>> At present, it only restores the original value of res->end, but it
>> doesn't restore the original value of res->flags in the while loop of
>> __walk_iomem _res_desc(). Whenever the find_next_iomem_res() finds a
>> resource and returns the result, the original values of this resource
>> will be modified, which might lead to an error in the next loop. For
>> example:
>>
>> The original value of resource flags is:
>>  res->flags=0x80000200(initial value)
>>
>> p->flags   _ 0x81000200 _                _ 0x80000200 _
>>           /              \              /              \
>> |________|_______A________|____|_....._|______B_________|..........___|
>> 0                                                            0xffffffff
>>                 (memory address ranges)
>>
>> Note: if ((p->flags & res->flags) != res->flags) continue;
>>
>> When the resource A is found, the original value of this resource flags
>> will be changed to 0x81000200(res->flags=0x81000200), and continue to
>> look for the next resource, when the loop reaches resource B, it can not
>> get the resource B any more(you can refer to the for loop of find_next
>> _iomem_res()), because the value of conditional expression will become
>> true and will also jump the resource B.
>>
>> In fact, we should get the resource A and B when we walk through the
>> whole tree, but it only gets the resource A, the resource B is missed.
>>
>> Signed-off-by: Lianbo Jiang <lijiang@...hat.com>
>> ---
>>  kernel/resource.c | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/kernel/resource.c b/kernel/resource.c
>> index 30e1bc68503b..f5d9fc70a04c 100644
>> --- a/kernel/resource.c
>> +++ b/kernel/resource.c
>> @@ -375,6 +375,7 @@ static int __walk_iomem_res_desc(struct resource *res, unsigned long desc,
>>  				 int (*func)(struct resource *, void *))
>>  {
>>  	u64 orig_end = res->end;
>> +	u64 orig_flags = res->flags;
>>  	int ret = -1;
>>  
>>  	while ((res->start < res->end) &&
>> @@ -385,6 +386,7 @@ static int __walk_iomem_res_desc(struct resource *res, unsigned long desc,
>>  
>>  		res->start = res->end + 1;
>>  		res->end = orig_end;
>> +		res->flags = orig_flags;
>>  	}
>>  
>>  	return ret;