Re: [PATCH] 9p/xen: mark 9p transport device as closing when removing it

[Demi Marie Obenour <demiobenour@gmail.com>]

[-- Attachment #1.1.1: Type: text/plain, Size: 2657 bytes --]

On 12/18/25 03:14, Jürgen Groß wrote:
> On 09.12.25 11:41, Demi Marie Obenour wrote:
>> On 12/8/25 14:51, Ariadne Conill wrote:
>>> We need to do this so that we can signal to the other end that the
>>> device is being removed, so that it will release its claim on the
>>> underlying memory allocation.  Otherwise releasing the grant-table
>>> entries is deferred resulting in a kernel oops since the pages have
>>> already been freed.
>>
>> I don't think this is sufficient.  The backend can simply refuse
>> to release the grants.  The frontend needs to ensure that the pages
>> are not freed until the grant table entries are freed.  Right now,
>> the backend can cause a use-after-free in the frontend, and my
>> understanding of the Xen Project's security policy is that this is
>> a security vulnerability in the frontend code.
>>
>> My instinct is that the core Xen code should take a reference on
>> each page before granting it to another domain, and not release that
>> reference until the pages are no longer granted.  This should prevent
>> any use-after-free problems if I understand Linux core MM correctly.
> 
> I looked at this in detail now.
> 
> I don't think we have a security bug right now, but the interfaces regarding
> granting pages to other domains should probably be reworked like you suggest.
> 
> Currently it is the caller who needs to handle page references correctly,
> while this should be done by the grant handling (having to either issue
> get_page() or to pass NULL for the page pointer, in case you don't want the
> underlying page to be freed by gnttab_end_foreign_access(), is far from
> intuitive).

Unfortunately, I don't think this is going to work.  Page refcounts
are going away.  Taking a reference on kmalloc()'d memory already
runs into a VM_BUG_ON_FOLIO().  So the only reasonable approach
is a callback that is run when the grant is no longer accessible by
the backend.  It could well be that this is another example of a bug
in 9p that also affects virtio.

More details about the memory management and
virtio-9p situation can be found in the thread at
<https://lore.kernel.org/lkml/20251210-virtio_trans_iter-1-1-92eee6d8b6db@codewreck.org/t/#u>.

A much better API would allow the grantor of a page to revoke the
grantee's access, with subsequent accesses by the grantee redirected
to a scratch page.  For PVH/HVM guests I expect this to be possible,
but for PV guests it would require Xen to modify the guest's own
page tables.  My understanding is that this isn't allowed as it would
break the guest.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]