diff options
| author | Sasha Levin <sashal@kernel.org> | 2025-09-29 07:32:38 -0400 |
|---|---|---|
| committer | Greg Kroah-Hartman <gregkh@linuxfoundation.org> | 2025-10-15 12:04:17 +0200 |
| commit | 8da2138409dcdeb773dc0c4eff7a8f51c8a0c137 (patch) | |
| tree | 7fb0dc1892f71171d9c8efc27c09b5616bb431fd /tools/perf/scripts/python | |
| parent | d7c7b38a3014db8084f563cb45989f8bd00ea39a (diff) | |
| download | kernel-8da2138409dcdeb773dc0c4eff7a8f51c8a0c137.tar.gz | |
tracing: Fix lock imbalance in s_start() memory allocation failure path
commit 61e19cd2e5c5235326a13a68df1a2f8ec4eeed7b upstream.
When s_start() fails to allocate memory for set_event_iter, it returns NULL
before acquiring event_mutex. However, the corresponding s_stop() function
always tries to unlock the mutex, causing a lock imbalance warning:
WARNING: bad unlock balance detected!
6.17.0-rc7-00175-g2b2e0c04f78c #7 Not tainted
-------------------------------------
syz.0.85611/376514 is trying to release lock (event_mutex) at:
[<ffffffff8dafc7a4>] traverse.part.0.constprop.0+0x2c4/0x650 fs/seq_file.c:131
but there are no more locks to release!
The issue was introduced by commit b355247df104 ("tracing: Cache ':mod:'
events for modules not loaded yet") which added the kzalloc() allocation before
the mutex lock, creating a path where s_start() could return without locking
the mutex while s_stop() would still try to unlock it.
Fix this by unconditionally acquiring the mutex immediately after allocation,
regardless of whether the allocation succeeded.
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/20250929113238.3722055-1-sashal@kernel.org
Fixes: b355247df104 ("tracing: Cache ":mod:" events for modules not loaded yet")
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'tools/perf/scripts/python')
0 files changed, 0 insertions, 0 deletions
