[SRU][F][PATCH 0/3] CVE-2024-38588

[Koichiro Den]

[Impact]

ftrace: Fix possible use-after-free issue in ftrace_location()
KASAN reports a bug:

  BUG: KASAN: use-after-free in ftrace_location+0x90/0x120
  Read of size 8 at addr ffff888141d40010 by task insmod/424
  CPU: 8 PID: 424 Comm: insmod Tainted: G        W          6.9.0-rc2+
  [...]
  Call Trace:
   <TASK>
   dump_stack_lvl+0x68/0xa0
   print_report+0xcf/0x610
   kasan_report+0xb5/0xe0
   ftrace_location+0x90/0x120
   register_kprobe+0x14b/0xa40
   kprobe_init+0x2d/0xff0 [kprobe_example]
   do_one_initcall+0x8f/0x2d0
   do_init_module+0x13a/0x3c0
   load_module+0x3082/0x33d0
   init_module_from_file+0xd2/0x130
   __x64_sys_finit_module+0x306/0x440
   do_syscall_64+0x68/0x140
   entry_SYSCALL_64_after_hwframe+0x71/0x79

The root cause is that, in lookup_rec(), ftrace record of some address
is being searched in ftrace pages of some module, but those ftrace pages
at the same time is being freed in ftrace_release_mod() as the
corresponding module is being deleted:

           CPU1                       |      CPU2
  register_kprobes() {                | delete_module() {
    check_kprobe_address_safe() {     |
      arch_check_ftrace_location() {  |
        ftrace_location() {           |
          lookup_rec() // USE!        |   ftrace_release_mod() // Free!

To fix this issue:
  1. Hold rcu lock as accessing ftrace pages in ftrace_location_range();
  2. Use ftrace_location_range() instead of lookup_rec() in
     ftrace_location();
  3. Call synchronize_rcu() before freeing any ftrace pages both in
     ftrace_process_locs()/ftrace_release_mod()/ftrace_free_mem().

[Fix]

Noble:  fixed via stable
Jammy:  fixed via stable
Focal:  Backport - adjusted contexts due to missing commits, see [Backport]
Bionic: fix sent to esm ML
Xenial: fix sent to esm ML
Trusty: won't fix

[Test Case]

Compile and boot tested

[Where problems could occur]

The primary fix affects those who use kprobes, especially when creating an
event which leads to ftrace based optimization. Even though the fix
itself is unlikely to introduce any regression as it's confined to the sync
issue, the multiple prerequisite commits for the fix touch ftrace
infrastructures, thus an issue with those would be visible to the user
via unpredicted system behavior or a system crash when directly using
any ftrace features.


Artem Savkov (1):
  ftrace: Return the first found result in lookup_rec()

Steven Rostedt (VMware) (1):
  ftrace: Separate out functionality from ftrace_location_range()

Zheng Yejian (1):
  ftrace: Fix possible use-after-free issue in ftrace_location()

 kernel/trace/ftrace.c | 64 ++++++++++++++++++++++++++++---------------
 1 file changed, 42 insertions(+), 22 deletions(-)

-- 
2.43.0