Re: [PATCH v3 16/27] KVM: Make device name configurable

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Leaked debugfs directory and Use-After-Free on module initialization failure.
--

commit 04c2f7cc9b71f864ca5d4b3147f1edb93f37b395
Author: Steffen Eiden <seiden@linux.ibm.com>

KVM: Make device name configurable

This commit allows KVM implementations to configure the device name, which
is particularly useful for architectures providing multiple implementations.
It introduces kvm_init_with_dev() and updates kvm_init_debug() to accept a
device name.

> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
[ ... ]
> @@ -6505,7 +6512,7 @@ int kvm_init(unsigned vcpu_size, unsigned vcpu_align, struct module *module)
>  	kvm_preempt_ops.sched_in = kvm_sched_in;
>  	kvm_preempt_ops.sched_out = kvm_sched_out;
>  
> -	kvm_init_debug();
> +	kvm_init_debug(kvm_dev.name);

[Severity: High]
This is a pre-existing issue, but does the error handling in
kvm_init_with_dev() leak the debugfs directory on failure?

kvm_init_debug() creates the debugfs directory and populates it with
stats files. If any of the subsequent initializations fail (such as
kvm_vfio_ops_init(), kvm_gmem_init(), or misc_register()), the rollback
path jumps to error labels like err_vfio or err_register.

None of these error paths appear to call debugfs_remove_recursive() or
an equivalent cleanup function for the debugfs directory. If KVM is
compiled as a module and fails to initialize, the module memory is freed.
Would this leave stale debugfs entries behind, potentially causing a
use-after-free if a user accesses those files and triggers the fops
pointing to the freed module memory?

>  
>  	r = kvm_vfio_ops_init();
>  	if (WARN_ON_ONCE(r))

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260529155050.2902245-1-seiden@linux.ibm.com?part=16