Skip to content
  • Naveen N. Rao's avatar
    ftrace: Fix NULL pointer dereference in t_probe_next() · 7bd46644
    Naveen N. Rao authored
    LTP testsuite on powerpc results in the below crash:
    
      Unable to handle kernel paging request for data at address 0x00000000
      Faulting instruction address: 0xc00000000029d800
      Oops: Kernel access of bad area, sig: 11 [#1]
      LE SMP NR_CPUS=2048 NUMA PowerNV
      ...
      CPU: 68 PID: 96584 Comm: cat Kdump: loaded Tainted: G        W
      NIP:  c00000000029d800 LR: c00000000029dac4 CTR: c0000000001e6ad0
      REGS: c0002017fae8ba10 TRAP: 0300   Tainted: G        W
      MSR:  9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE>  CR: 28022422  XER: 20040000
      CFAR: c00000000029d90c DAR: 0000000000000000 DSISR: 40000000 IRQMASK: 0
      ...
      NIP [c00000000029d800] t_probe_next+0x60/0x180
      LR [c00000000029dac4] t_mod_start+0x1a4/0x1f0
      Call Trace:
      [c0002017fae8bc90] [c000000000cdbc40] _cond_resched+0x10/0xb0 (unreliable)
      [c0002017fae8bce0] [c0000000002a15b0] t_start+0xf0/0x1c0
      [c0002017fae8bd30] [c0000000004ec2b4] seq_read+0x184/0x640
      [c0002017fae8bdd0] [c0000000004a57bc] sys_read+0x10c/0x300
      [c0002017fae8be30] [c00000000000b388] system_call+0x5c/0x70
    
    The test (ftrace_set_ftrace_filter.sh) is part of ftrace stress tests
    and the crash happens when the test does 'cat
    $TRACING_PATH/set_ftrace_filter'.
    
    The address points to the second line below, in t_probe_next(), where
    filter_hash is dereferenced:
      hash = iter->probe->ops.func_hash->filter_hash;
      size = 1 << hash->size_bits;
    
    This happens due to a race with register_ftrace_function_probe(). A new
    ftrace_func_probe is created and added into the func_probes list in
    trace_array under ftrace_lock. However, before initializing the filter,
    we drop ftrace_lock, and re-acquire it after acquiring regex_lock. If
    another process is trying to read set_ftrace_filter, it will be able to
    acquire ftrace_lock during this window and it will end up seeing a NULL
    filter_hash.
    
    Fix this by just checking for a NULL filter_hash in t_probe_next(). If
    the filter_hash is NULL, then this probe is just being added and we can
    simply return from here.
    
    Link: http://lkml.kernel.org/r/05e021f757625cbbb006fad41380323dbe4e3b43.1562249521.git.naveen.n.rao@linux.vnet.ibm.com
    
    Cc: stable@vger.kernel.org
    Fixes: 7b60f3d8
    
     ("ftrace: Dynamically create the probe ftrace_ops for the trace_array")
    Signed-off-by: default avatarNaveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
    Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
    7bd46644