On Fri, Dec 30, 2022 at 1:54 AM Hao Sun <sunhao.th@xxxxxxxxx> wrote: > > > > > On 28 Dec 2022, at 2:35 PM, Yonghong Song <yhs@xxxxxxxx> wrote: > > > > > > > > On 12/21/22 8:35 PM, Hao Sun wrote: > >> Hi, > >> This crash can be triggered by executing the C reproducer for > >> multiple times, which just keep loading the following prog as > >> raw tracepoint into kmem_cache_free(). > >> The prog send SIGSEGV to current via bpf_send_signal_thread(), > >> after load this, whoever tries to free mem would trigger this, > >> kernel crashed when this happens to init. > >> Seems we should filter init out in bpf_send_signal_common() by > >> is_global_init(current), or maybe we should check this in the > >> verifier? > > > > The helper is just to send a particular signal to *current* > > thread. In typical use case, it is never a good idea to send > > the signal to a *random* thread. In certain cases, maybe user > > indeed wants to send the signal to init thread to observe > > something. Note that such destructive side effect already > > exists in the bpf land. For example, for a xdp program, > > it could drop all packets to make machine not responsive > > to ssh etc. Therefore, I recommend to keep the existing > > bpf_send_signal_common() helper behavior. > > Sound the two are different cases. Not responsive in XDP seems like > an intended behaviour, panic caused by killing init is buggy. If the > last thread of global init was killed, kernel panic immediately. I don't get it. How was it possible that this prog was executed with current == pid 1 ?
