On 12/9/25 12:09, Ariadne Conill wrote: > Hello, > >> On Dec 9, 2025, at 2:43 AM, Demi Marie Obenour <[email protected]> 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)
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
