Re: memory leak in create_ctx
From: Jakub Kicinski
Date: Tue Jun 11 2019 - 13:21:22 EST
On Tue, 11 Jun 2019 13:45:11 +0200, Dmitry Vyukov wrote:
> Do you see the bug? Jakub said he can't repro.
> The repro has these suspicious bpf syscalls and there is currently
> some nasty bpf bug that plagues us and leads to random assorted
> splats.
Ah, must be the BPF interaction indeed :S The reproducer text uses
incorrect names:
bpf$MAP_CREATE(0x0, &(0x7f0000000280)={0xf, 0x4, 0x4, 0x400, 0x0, 0x1}, 0x3c)
# ^ this is a map create SOCKMAP
socket$rxrpc(0x21, 0x2, 0x800000000a)
r0 = socket$inet6_tcp(0xa, 0x1, 0x0)
setsockopt$inet6_tcp_int(r0, 0x6, 0x13, &(0x7f00000000c0)=0x100000001, 0x1d4)
connect$inet6(r0, &(0x7f0000000140), 0x1c)
bpf$MAP_CREATE(0x0, &(0x7f0000000000)={0x5, 0x0, 0x0, 0x0, 0x80}, 0x3c)
# ^ another map create (perf event array?)
bpf$MAP_CREATE(0x2, &(0x7f0000003000)={0x3, 0x0, 0x77fffb, 0x0, 0x10020000000, 0x0}, 0x2c)
# ^ but this is MAP_UPDATE, not MAP_CREATE, it probably inserts the r0
# into the map
setsockopt$inet6_tcp_TCP_ULP(r0, 0x6, 0x1f, &(0x7f0000000040)='tls\x00', 0x4)
That threw me off.
> I've run the repro as "./syz-execprog -repeat=0 -procs=6 repro" and
> in 10 mins I got the following splat, which indeed suggests a bpf bug.
> But we of course can have both bpf stack overflow and a memory leak in tls.