From: Juergen Gross <jgross@suse.com>
To: David Vrabel <david.vrabel@citrix.com>,
linux-kernel@vger.kernel.org, xen-devel@lists.xensource.com,
konrad.wilk@oracle.com
Subject: Re: [Xen-devel] [PATCH] xen: avoid writing to freed memory after race in p2m handling
Date: Tue, 14 Oct 2014 11:49:15 +0200 [thread overview]
Message-ID: <543CF19B.3040305@suse.com> (raw)
In-Reply-To: <543CED29.4050905@citrix.com>
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.
I think ballooning alone can't trigger this race, as it is calling
set_phys_to_machine() under lock only.
Juergen
>
> David
>
>> --- a/arch/x86/xen/p2m.c
>> +++ b/arch/x86/xen/p2m.c
>> @@ -566,6 +566,7 @@ static bool alloc_p2m(unsigned long pfn)
>> /* Separately check the mid mfn level */
>> unsigned long missing_mfn;
>> unsigned long mid_mfn_mfn;
>> + unsigned long old_mfn;
>>
>> mid_mfn = alloc_p2m_page();
>> if (!mid_mfn)
>> @@ -575,10 +576,13 @@ static bool alloc_p2m(unsigned long pfn)
>>
>> missing_mfn = virt_to_mfn(p2m_mid_missing_mfn);
>> mid_mfn_mfn = virt_to_mfn(mid_mfn);
>> - if (cmpxchg(top_mfn_p, missing_mfn, mid_mfn_mfn) != missing_mfn)
>> + old_mfn = cmpxchg(top_mfn_p, missing_mfn, mid_mfn_mfn);
>> + if (old_mfn != missing_mfn) {
>> free_p2m_page(mid_mfn);
>> - else
>> + mid_mfn = mfn_to_virt(old_mfn);
>> + } else {
>> p2m_top_mfn_p[topidx] = mid_mfn;
>> + }
>> }
>>
>> if (p2m_top[topidx][mididx] == p2m_identity ||
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
next prev parent reply other threads:[~2014-10-14 9:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-14 9:00 [PATCH] xen: avoid writing to freed memory after race in p2m handling Juergen Gross
2014-10-14 9:30 ` [Xen-devel] " David Vrabel
2014-10-14 9:30 ` David Vrabel
2014-10-14 9:49 ` Juergen Gross [this message]
2014-10-14 16:43 ` David Vrabel
2014-10-14 16:43 ` David Vrabel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=543CF19B.3040305@suse.com \
--to=jgross@suse.com \
--cc=david.vrabel@citrix.com \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.