From: Zheng Yejian
[ Upstream commit e60b613df8b6253def41215402f72986fee3fc8d ]
KASAN reports a bug:
BUG: KASAN: use-after-free in ftrace_location+0x90/0x120
Read of size 8 at addr 888141d40010 by task insmod/424
CPU: 8 PID: 424 Comm: insmod Tainted: GW 6.9.0-rc2+
[
From: Peter Zijlstra
[ Upstream commit aebfd12521d9c7d0b502cf6d06314cfbcdccfe3b ]
Currently a lot of ftrace code assumes __fentry__ is at sym+0. However
with Intel IBT enabled the first instruction of a function will most
likely be ENDBR.
Change ftrace_location() to not only return the __fentry
From: Shivani Agarwal
Hi,
To Fix CVE-2024-38588 e60b613df8b6 is required, but it has a dependency
on aebfd12521d9. Therefore backported both patches for v5.10.
Thanks,
Shivani
Shivani Agarwal (2):
x86/ibt,ftrace: Search for __fentry__ location
ftrace: Fix possible use-after-free issue in
On Tue, Sep 24, 2024 at 7:15 PM Matthew Wilcox wrote:
> On Fri, Sep 13, 2024 at 12:52:39AM +0200, Jann Horn wrote:
> > FWIW, I would still feel happier if this was a 64-bit number, though I
> > guess at least with uprobes the attack surface is not that large even
> > if you can wrap that counter..
On Fri, Sep 13, 2024 at 12:52:39AM +0200, Jann Horn wrote:
> FWIW, I would still feel happier if this was a 64-bit number, though I
> guess at least with uprobes the attack surface is not that large even
> if you can wrap that counter... 2^31 counter increments are not all
> that much, especially i
Arend Van Spriel writes:
> On September 24, 2024 2:09:35 PM Geert Uytterhoeven
> wrote:
>
>> When tracing is disabled, there is no point in asking the user about
>> enabling Broadcom wireless device tracing.
>>
>> Fixes: f5c4f10852d42012 ("brcm80211: Allow trace support to be
>> enabled separate
On September 24, 2024 2:09:35 PM Geert Uytterhoeven
wrote:
When tracing is disabled, there is no point in asking the user about
enabling Broadcom wireless device tracing.
Fixes: f5c4f10852d42012 ("brcm80211: Allow trace support to be enabled
separately from debug")
Acked-by: Arend van Sprie
When tracing is disabled, there is no point in asking the user about
enabling Broadcom wireless device tracing.
Fixes: f5c4f10852d42012 ("brcm80211: Allow trace support to be enabled
separately from debug")
Signed-off-by: Geert Uytterhoeven
---
drivers/net/wireless/broadcom/brcm80211/Kconfig |
When tracing is disabled, there is no point in asking the user about
enabling tracing of all mac80211 debug messages.
Fixes: 3fae0273168026ed ("mac80211: trace debug messages")
Signed-off-by: Geert Uytterhoeven
---
net/mac80211/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
When tracing is disabled, there is no point in asking the user about
enabling extra btree_path tracepoints in bcachefs.
Fixes: 32ed4a620c5405be ("bcachefs: Btree path tracepoints")
Signed-off-by: Geert Uytterhoeven
---
fs/bcachefs/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
di
Another "hung task" error was reported during the test, and i figured out
the deadlock scenario is as follows:
T1 [BP] | T2 [AP] | T3 [hwlatd/1]
| T4
work_for_cpu_fn() | cpuhp_thread_fun() | kthread_fn()
| hwlat_ho
There is another found exception that the "timerlat/1" thread was
scheduled on CPU0, and lead to timer corruption finally:
```
ODEBUG: init active (active state 0) object: 888237c2e108 object type:
hrtimer hint: timerlat_irq+0x0/0x220
WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_p
stop_kthread() is the offline callback for "trace/osnoise:online", since
commit 5bfbcd1ee57b ("tracing/timerlat: Add interface_lock around clearing
of kthread in stop_kthread()"), the following ABBA deadlock scenario is
introduced:
T1| T2 [BP] | T3 [AP]
os
The cpuhp online/offline processing race also exists in percpu-mode hwlat
tracer in theory, apply the fix too.
Fixes: ba998f7d9531 ("trace/hwlat: Support hotplug operations")
Signed-off-by: Wei Li
---
kernel/trace/trace_hwlat.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/trace/t
osnoise_hotplug_workfn() is the asynchronous online callback for
"trace/osnoise:online". It may be congested when a CPU goes online and
offline repeatedly and is invoked for multiple times after a certain
online.
This will lead to kthread leak and timer corruption. Add a check
in start_kthread() t
These issues are found in concurrent CPU-hotplug and tracer-toggling
testing, the test cases are as follows:
Background: *test_hotplug.sh*
```
#!/bin/sh
while true
do
echo 0 > /sys/devices/system/cpu/cpu1/online
echo 1 > /sys/devices/system/cpu/cpu1/online
done
```
Test 1: *test_
Gentle ping
From: Levi Yun
Sent: 13 September 2024 03:13
To: rost...@goodmis.org; mhira...@kernel.org; mathieu.desnoy...@efficios.com;
a.p.zijls...@chello.nl; mi...@elte.hu; Mark Rutland; james.cl...@linaro.org
Cc: nd; linux-ker...@vger.kernel.org; linux-
17 matches
Mail list logo
