Re: [PATCH v3] cxl/core: Fix dport use-after-free via the einj_inject debugfs file

[Guixin Liu <kanie@linux.alibaba.com>]

在 2026/9/11 06:02, Jonathan Cameron 写道:
> On Fri, 28 Aug 2026 15:47:52 +0800
> Guixin Liu <kanie@linux.alibaba.com> wrote:
>
>> The per-dport einj_inject debugfs file retains a pointer to the
>> 'struct cxl_dport', but its lifetime is not tied to the dport. Unbinding
>> the dport host frees the dport and leaves einj_inject behind, so writing
>> the file dereferences freed memory:
>>
>>    BUG: KASAN: slab-use-after-free in cxl_einj_inject+0xa1/0xf0 [cxl_core]
>>    Read of size 1 at addr ffff88810880ac90 by task bash/1690
>>     cxl_einj_inject+0xa1/0xf0 [cxl_core]
>>     debugfs_attr_write+0x61/0xb0
>>     full_proxy_write+0xfc/0x1c0
>>     vfs_write+0x1d4/0xe60
>>    Allocated by task 213:
>>     __devm_cxl_add_dport+0x1e1/0x14d0 [cxl_core]
>>     cxl_port_add_dport+0xd6/0x200 [cxl_port]
>>    Freed by task 1622:
>>     release_nodes+0xfa/0x2c0
>>     devres_release_all+0x113/0x1a0
>>     device_unbind_cleanup+0x76/0x260
>>     unbind_store+0xde/0x100
>>
>> The stale directory also prevents recreation on rebind.
>>
>> Remove the per-dport debugfs directory when the dport host is released.
>>
>> Found by code inspection, then reproduced on a QEMU CXL topology with
>> KASAN (the einj_cxl_is_initialized() guard had to be forced open, as
>> QEMU emits no EINJ table). Unpatched, writing the leftover file after
>> unbind gives the splat above, and rebind hits "already exists in
>> 'cxl'". Patched, the directory goes away with the dport and rebind
>> recreates a working einj_inject.
>>
>> Fixes: 8039804cfa73 ("cxl/core: Add CXL EINJ debugfs files")
>> Signed-off-by: Guixin Liu <kanie@linux.alibaba.com>
>> Reviewed-by: Richard Cheng <icheng@nvidia.com>
>> Reviewed-by: Li Ming <ming.li@zohomail.com>
> ...
>
>> diff --git a/drivers/cxl/core/port.c b/drivers/cxl/core/port.c
>> index 625e4aa427db..62a9c2038d1f 100644
>> --- a/drivers/cxl/core/port.c
>> +++ b/drivers/cxl/core/port.c
>> @@ -814,6 +814,11 @@ static int cxl_einj_inject(void *data, u64 type)
>>   DEFINE_DEBUGFS_ATTRIBUTE(cxl_einj_inject_fops, NULL, cxl_einj_inject,
>>   			 "0x%llx\n");
>>   
>> +static void remove_debugfs(void *dentry)
>> +{
>> +	debugfs_remove_recursive(dentry);
>> +}
>> +
>>   static void cxl_debugfs_create_dport_dir(struct cxl_dport *dport)
>>   {
>>   	struct cxl_port *parent = parent_port_of(dport->port);
>> @@ -834,6 +839,8 @@ static void cxl_debugfs_create_dport_dir(struct cxl_dport *dport)
>>   
>>   	debugfs_create_file("einj_inject", 0200, dir, dport,
>>   			    &cxl_einj_inject_fops);
>> +
>> +	devm_add_action_or_reset(dport_to_host(dport), remove_debugfs, dir);
> I'd move it up a couple of lines so it is closely coupled with the setup function
> for the directory.
Sure, moved in v4, thanks.
>
> This is an interesting corner, we don't fail on debugfs registration failing
> but I think we should potentially fail probe if a cleanup function fails to be
> registered thus leaving us the hanging reference you point out in the first place.
>
> Jonathan
As Li Ming said in v1, missing debugfs dir is acceptable, we should't fail
the whole dport addition flow just because adding debugfs failure.

And if devm_add_action_or_reset() fails, the remove_debugfs() will be 
run to clean the dir. Best Regards, Guixin Liu
>
>>   }
>>   
>>   static int cxl_port_add(struct cxl_port *port,
>>
>> base-commit: 7098e9cd98a05c0c5de2fae0c2465f9d966fdd07