CVE-2024-38588

In the Linux kernel, the following vulnerability has been resolved:

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

KASAN reports a bug:

BUG: KASAN: use-after-free in ftracelocation+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> dumpstacklvl+0x68/0xa0 printreport+0xcf/0x610 kasanreport+0xb5/0xe0 ftracelocation+0x90/0x120 registerkprobe+0x14b/0xa40 kprobeinit+0x2d/0xff0 [kprobeexample] dooneinitcall+0x8f/0x2d0 doinitmodule+0x13a/0x3c0 loadmodule+0x3082/0x33d0 initmodulefromfile+0xd2/0x130 _x64sysfinitmodule+0x306/0x440 dosyscall64+0x68/0x140 entrySYSCALL64after_hwframe+0x71/0x79

The root cause is that, in lookuprec(), 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 ftracerelease_mod() as the corresponding module is being deleted:

       CPU1                       |      CPU2

registerkprobes() { | deletemodule() { checkkprobeaddresssafe() { | archcheckftracelocation() { | ftracelocation() { | lookuprec() // USE! | ftracereleasemod() // Free!

To fix this issue: 1. Hold rcu lock as accessing ftrace pages in ftracelocationrange(); 2. Use ftracelocationrange() instead of lookuprec() in ftracelocation(); 3. Call synchronizercu() before freeing any ftrace pages both in ftraceprocesslocs()/ftracereleasemod()/ftracefree_mem().