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

[Miaohe Lin]

On 2022/4/25 10:51, HORIGUCHI NAOYA(堀口 直也) wrote:
> On Mon, Apr 25, 2022 at 10:20:23AM +0800, Miaohe Lin wrote:
>> On 2022/4/25 9: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@xxxxxxxxxx>
>>>> Acked-by: David Hildenbrand <david@xxxxxxxxxx>
>>>
>>> Hi Miaohe,
>>>
>>> This bug sounds relatively serious to me, and it seems old, so is it worth
>>> sending to -stable?
>>
>> This bug is really old but it's never seen yet because swapoff is supposed only to
>> be done before rebooting the system. But swapoff can happen anytime. Poor guys might
>> come across it and get wrong data. So I think it's worth sending to -stable.
>>
>> BTW: This patch should be revised in order to go to the stable version.
> 
> I sometimes have the same wonder, but I'm not sure about the rule.  If you
> choose to send another version, could you update subject line (subject line

What I mean is that SWP_PTE_MARKER is newly added and it will conflict with the stable version.
So this patch might need to be revised for specified stable version in order to fix the possible
conflict beforehand. Or that should be done when it goes to the stable ?

> is supposed to show what the patch does rather than what the problem is).

If a specified version for stable is required, I will do this.

Thanks!

> 
> Thanks,
> Naoya Horiguchi
>