linux-kernel - Re: [Xen-devel] [PATCH] xen: avoid writing to freed memory after race in p2m handling

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] [day] [month] [year] [list]

Message-ID: <543D52C5.3010903@citrix.com>
Date:	Tue, 14 Oct 2014 17:43:49 +0100
From:	David Vrabel <david.vrabel@...rix.com>
To:	Juergen Gross <jgross@...e.com>,
	David Vrabel <david.vrabel@...rix.com>,
	<linux-kernel@...r.kernel.org>, <xen-devel@...ts.xensource.com>,
	<konrad.wilk@...cle.com>
Subject: Re: [Xen-devel] [PATCH] xen: avoid writing to freed memory after
 race in p2m handling

On 14/10/14 10:49, Juergen Gross wrote:
> On 10/14/2014 11:30 AM, David Vrabel wrote:
>> On 14/10/14 10:00, Juergen Gross wrote:
>>> In case a race was detected during allocation of a new p2m tree
>>> element in alloc_p2m() the new allocated mid_mfn page is freed without
>>> updating the pointer to the found value in the tree. This will result
>>> in overwriting the just freed page with the mfn of the p2m leaf.
>>
>> Can this race actually happen?  i.e., does this need tagging for stable?
> 
> Good question. I just stumbled over it while writing the linear p2m-list
> patch.
> 
> Is it possible for gnttab_map_refs() to call set_foreign_p2m_mapping()
> specifying a pfn which has been invalid before? In this case the race
> could happen in dom0.

Yes, if two backends map into ballooned pages from a region of
untouched,  pre-ballooned memory.  But these seems super rare and I
don't think there have been any bug reports that could be attributed to
this, so I don't think a stable backport is needed.

> I think ballooning alone can't trigger this race, as it is calling
> set_phys_to_machine() under lock only.

Agreed.

Applied to stable/for-linus-3.18.

Thanks.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/