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: 1923 bytes --]

On 12/9/25 12:09, Ariadne Conill wrote:
> Hello,
> 
>> On Dec 9, 2025, at 2:43 AM, Demi Marie Obenour <demiobenour@gmail.com> 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.
> 
> Yes, there are other issues in the 9p transport that are likely in play here.  In our internal testing, we confirm this is not a full fix for hotplugging 9p transport devices, but no such claim of a complete fix has been made here or in the Matrix thread.
> 
> However, this is one defect that is contributing to the overall hotplugging problem and should be merged regardless: if the driver isn’t telling the other side to disconnect, the other side will never release the grants to begin with.
> 
> Ariadne

I definitely agree that this should be merged!

Is this code-path triggerable by the backend at will, or only during
teardown by the toolstack?
-- 
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 --]