linux-kernel - Re: [PATCH v3 1/3] mm/swapfile: unuse_pte can map random data if swap read fails

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: <45a5052b-5c6e-1d5e-6c90-eb3ff2ed1130@huawei.com>
Date:   Tue, 26 Apr 2022 15:06:38 +0800
From:   Miaohe Lin <linmiaohe@...wei.com>
To:     HORIGUCHI NAOYA(堀口 直也) 
        <naoya.horiguchi@....com>
CC:     David Hildenbrand <david@...hat.com>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "willy@...radead.org" <willy@...radead.org>,
        "vbabka@...e.cz" <vbabka@...e.cz>,
        "dhowells@...hat.com" <dhowells@...hat.com>,
        "neilb@...e.de" <neilb@...e.de>,
        "apopple@...dia.com" <apopple@...dia.com>,
        "surenb@...gle.com" <surenb@...gle.com>,
        "minchan@...nel.org" <minchan@...nel.org>,
        "peterx@...hat.com" <peterx@...hat.com>,
        "sfr@...b.auug.org.au" <sfr@...b.auug.org.au>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 1/3] mm/swapfile: unuse_pte can map random data if swap
 read fails

On 2022/4/26 8:31, HORIGUCHI NAOYA(堀口 直也) wrote:
> On Mon, Apr 25, 2022 at 04:47:41PM +0800, Miaohe Lin wrote:
>> On 2022/4/25 15:45, David Hildenbrand wrote:
>>> On 25.04.22 03:08, HORIGUCHI NAOYA(堀口 直也) wrote:
>>>> On Sun, Apr 24, 2022 at 05:11:03PM +0800, Miaohe Lin wrote:
>>>>> There is a bug in unuse_pte(): when swap page happens to be unreadable,
>>>>> page filled with random data is mapped into user address space.  In case
>>>>> of error, a special swap entry indicating swap read fails is set to the
>>>>> page table.  So the swapcache page can be freed and the user won't end up
>>>>> with a permanently mounted swap because a sector is bad.  And if the page
>>>>> is accessed later, the user process will be killed so that corrupted data
>>>>> is never consumed.  On the other hand, if the page is never accessed, the
>>>>> user won't even notice it.
>>>>>
>>>>> Signed-off-by: Miaohe Lin <linmiaohe@...wei.com>
>>>>> Acked-by: David Hildenbrand <david@...hat.com>
>>>>
>>>> Hi Miaohe,
>>>>
>>>> This bug sounds relatively serious to me, and it seems old, so is it worth
>>>> sending to -stable?
>>>
>>> I'm not sure if this is worth -stable, but no strong opinion.
>>
>> I have no strong opinion too. I'm just afraid someone might run into it. But swapoff is
>> expected to be a rare operation anyway...
>>
>>>
>>> The do_swap_page() part was added in 2005:
>>>
>>> commit b81074800b98ac50b64d4c8d34e8abf0fda5e3d1
>>> Author: Kirill Korotaev <dev@...ru>
>>> Date:   Mon May 16 21:53:50 2005 -0700
>>>
>>>     [PATCH] do_swap_page() can map random data if swap read fails
>>>     
>>>     There is a bug in do_swap_page(): when swap page happens to be unreadable,
>>>     page filled with random data is mapped into user address space.  The fix is
>>>     to check for PageUptodate and send SIGBUS in case of error.
>>>     
>>>     Signed-Off-By: Kirill Korotaev <dev@...ru>
>>>     Signed-Off-By: Alexey Kuznetsov <kuznet@....inr.ac.ru>
>>>     Acked-by: Hugh Dickins <hugh@...itas.com>
>>>     Signed-off-by: Andrew Morton <akpm@...l.org>
>>>     Signed-off-by: Linus Torvalds <torvalds@...l.org>
>>>
>>> So the do_swap_page() part has been fixed for quite a while already.
>>
>> Does this mean only do_swap_page maps random data if swap read fails is observed from that time on?
>> So this might not be worth -stable as it's never seen more than a decade?
> 
> OK, both choices seems possible, so not sending to -stable is fine to me.
> It's finally up to you.

I tend not to send it to -stable due to the above concern now.

Thanks!

> 
> Thanks,
> Naoya Horiguchi
>