diff options
author | Duoming Zhou <duoming@zju.edu.cn> | 2025-09-17 17:56:08 +0800 |
---|---|---|
committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2025-10-06 11:17:52 +0200 |
commit | effb1c19583bca7022fa641a70766de45c6d41ac (patch) | |
tree | ae638e7831931d4f0fbf87e184a12523e991fa83 /tools/perf/scripts/python/call-graph-from-postgresql.py | |
parent | 514a519baa9e2be7ddc2714bd730bc5a883e1244 (diff) |
media: tuner: xc5000: Fix use-after-free in xc5000_release
commit 40b7a19f321e65789612ebaca966472055dab48c upstream.
The original code uses cancel_delayed_work() in xc5000_release(), which
does not guarantee that the delayed work item timer_sleep has fully
completed if it was already running. This leads to use-after-free scenarios
where xc5000_release() may free the xc5000_priv while timer_sleep is still
active and attempts to dereference the xc5000_priv.
A typical race condition is illustrated below:
CPU 0 (release thread) | CPU 1 (delayed work callback)
xc5000_release() | xc5000_do_timer_sleep()
cancel_delayed_work() |
hybrid_tuner_release_state(priv) |
kfree(priv) |
| priv = container_of() // UAF
Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure
that the timer_sleep is properly canceled before the xc5000_priv memory
is deallocated.
A deadlock concern was considered: xc5000_release() is called in a process
context and is not holding any locks that the timer_sleep work item might
also need. Therefore, the use of the _sync() variant is safe here.
This bug was initially identified through static analysis.
Fixes: f7a27ff1fb77 ("[media] xc5000: delay tuner sleep to 5 seconds")
Cc: stable@vger.kernel.org
Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
[hverkuil: fix typo in Subject: tunner -> tuner]
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'tools/perf/scripts/python/call-graph-from-postgresql.py')
0 files changed, 0 insertions, 0 deletions