lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 14 May 2015 22:37:56 -0700
From:	Alexei Starovoitov <ast@...mgrid.com>
To:	"Wangnan (F)" <wangnan0@...wei.com>, linux-kernel@...r.kernel.org
CC:	lizefan 00213767 <lizefan@...wei.com>
Subject: Re: [BUG] kernel panic after bpf program removed.

On 5/14/15 8:54 PM, Wangnan (F) wrote:
> Hi Alexei Starovoitov and other,
>
> I triggered a kernel panic when developing my 'perf bpf' facility. The
> call stack is listed at the bottom of
> this mail.
>
> I attached two bpf programs on 'kmem_cache_free%return' and
> '__alloc_pages_nodemask'. The programs is very simple.
> The panic is raised after closing the bpf program and the perf event
> file. Looks like the panic is caused
> by racing between closing perf event fd and bpf program fd. I'm unable
> to reproduce this problem with similar
> operations.
>
> Following is the exact instruction cause the panic.

thanks for the report.
Looks like pointer 'prog == 0x6c0' is passed into bpf_prog_put,
which means that event->tp_event was freed and memory reused before
free_event_rcu() was called.

I think it's not perf_event_fd racing with prog_fd, but rather
with kprobe freeing:
__free_event()
   event->destroy(event)
     perf_trace_destroy
       perf_trace_event_unreg
which is dropping event->tp_event->perf_refcount
that allows kprobe freeing to proceed in:
unregister_kprobe_event
   trace_remove_event_call
     probe_remove_event_call
and eventually tp_event to get freed.

I think calling perf_event_free_bpf_prog()
from __free_event() instead of free_event_rcu() will fix the race,
but please double check my analysis.
Also please send me a reproducer script. I'd like to see it crashing
first before the fix and not crashing afterwards.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ