[lkml]   [2019]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: memory leak in create_ctx
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.

 \ /
  Last update: 2019-06-11 19:17    [W:0.042 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site