Re: [PATCH v2 2/2] samples: enhance hung_task detector test with rtmutex support

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

Pre-existing issues:
- [High] Missing `.owner = THIS_MODULE` in `struct file_operations` allows the module to be unloaded while debugfs files are open, leading to a use-after-free on module unload. This problem wasn't introduced by this patch, but the patch replicates the flawed pattern.
--

--- Patch [2]: [PATCH v2 2/2] samples: enhance hung_task detector test with rtmutex support ---
commit 1b388ec83d8aff9dc25159e4fe36a84b7c7583d7
Author: Ruipeng Qi <[email protected]>

samples: enhance hung_task detector test with rtmutex support

This commit extends the hung_task detector test module with an rtmutex test.
When CONFIG_RT_MUTEXES is enabled, it creates an additional rtmutex debugfs
file to allow testing hung-task reporting for rtmutex waits.

> diff --git a/samples/hung_task/hung_task_tests.c b/samples/hung_task/hung_task_tests.c
> index 0360ec916890b..87346d65f860a 100644
> --- a/samples/hung_task/hung_task_tests.c
> +++ b/samples/hung_task/hung_task_tests.c
[ ... ]
> @@ -116,6 +147,13 @@ static const struct file_operations hung_task_mutex_fops = {
>  	.read = read_dummy_mutex,
>  };
>  
> +#ifdef CONFIG_RT_MUTEXES
> +/* File operations for rtmutex */
> +static const struct file_operations hung_task_rtmutex_fops = {
> +	.read = read_dummy_rtmutex,
> +};
> +#endif

[Severity: High]
This is a pre-existing issue, but this new rtmutex file operations struct (as
well as the existing mutex one above it) omits the .owner field.

Without .owner = THIS_MODULE, fops_get() in the debugfs open proxy does not
increment the module reference count. If a user opens the debugfs file and
concurrently unloads the module via rmmod, the module is successfully
unloaded because debugfs_remove_recursive() does not block merely open files.

When the file is eventually closed, full_proxy_release() will unconditionally
dereference real_fops->release. Since real_fops points to the unloaded
module's memory, can this trigger a use-after-free crash on module unload?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2