Skip to content
Snippets Groups Projects
Select Git revision
  • 48c3a5e28eeed0eded5be445f3f1f9fbdd2edb9f
  • openEuler-1.0-LTS default protected
  • openEuler-22.09
  • OLK-5.10
  • openEuler-22.03-LTS
  • openEuler-22.03-LTS-Ascend
  • master
  • openEuler-22.03-LTS-LoongArch-NW
  • openEuler-22.09-HCK
  • openEuler-20.03-LTS-SP3
  • openEuler-21.09
  • openEuler-21.03
  • openEuler-20.09
  • 4.19.90-2210.5.0
  • 5.10.0-123.0.0
  • 5.10.0-60.63.0
  • 5.10.0-60.62.0
  • 4.19.90-2210.4.0
  • 5.10.0-121.0.0
  • 5.10.0-60.61.0
  • 4.19.90-2210.3.0
  • 5.10.0-60.60.0
  • 5.10.0-120.0.0
  • 5.10.0-60.59.0
  • 5.10.0-119.0.0
  • 4.19.90-2210.2.0
  • 4.19.90-2210.1.0
  • 5.10.0-118.0.0
  • 5.10.0-106.19.0
  • 5.10.0-60.58.0
  • 4.19.90-2209.6.0
  • 5.10.0-106.18.0
  • 5.10.0-106.17.0
33 results

kernel

  • Clone with SSH
  • Clone with HTTPS
  • user avatar
    Steven Rostedt (VMware) authored and Yongqiang Liu committed
    stable inclusion
    from stable-5.10.50
    commit 0531e84bc8ac750b7a15c18d478804c0d98f0a86
    bugzilla: https://gitee.com/openeuler/kernel/issues/I5ETW1
    CVE: NA
    
    --------------------------------
    
    commit 9913d5745bd720c4266805c8d29952a3702e4eca upstream.
    
    All internal use cases for tracepoint_probe_register() is set to not ever
    be called with the same function and data. If it is, it is considered a
    bug, as that means the accounting of handling tracepoints is corrupted.
    If the function and data for a tracepoint is already registered when
    tracepoint_probe_register() is called, it will call WARN_ON_ONCE() and
    return with EEXISTS.
    
    The BPF system call can end up calling tracepoint_probe_register() with
    the same data, which now means that this can trigger the warning because
    of a user space process. As WARN_ON_ONCE() should not be called because
    user space called a system call with bad data, there needs to be a way to
    register a tracepoint without triggering a warning.
    
    Enter tracepoint_probe_register_may_exist(), which can be called, but will
    not cause a WARN_ON() if the probe already exists. It will still error out
    with EEXIST, which will then be sent to the user space that performed the
    BPF system call.
    
    This keeps the previous testing for issues with other users of the
    tracepoint code, while letting BPF call it with duplicated data and not
    warn about it.
    
    Link: https://lore.kernel.org/lkml/20210626135845.4080-1-penguin-kernel@I-love.SAKURA.ne.jp/
    Link: https://syzkaller.appspot.com/bug?id=41f4318cf01762389f4d1c1c459da4f542fe5153
    
    
    
    Cc: stable@vger.kernel.org
    Fixes: c4f6699d ("bpf: introduce BPF_RAW_TRACEPOINT")
    Reported-by: default avatarsyzbot <syzbot+721aa903751db87aa244@syzkaller.appspotmail.com>
    Reported-by: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
    Tested-by: default avatar <syzbot+721aa903751db87aa244@syzkaller.appspotmail.com>
    Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
    Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    
    Signed-off-by: default avatarChen Jun <chenjun102@huawei.com>
    Acked-by: default avatarWeilong Chen <chenweilong@huawei.com>
    Signed-off-by: default avatarChen Jun <chenjun102@huawei.com>
    Signed-off-by: default avatarChen Zhongjin <chenzhongjin@huawei.com>
    Reviewed-by: default avatarXu Kuohai <xukuohai@huawei.com>
    Signed-off-by: default avatarYongqiang Liu <liuyongqiang13@huawei.com>
    48c3a5e2
    History
    Name Last commit Last update
    ..