This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug bpf/24811] New: stapbpf segfault: nested foreach loops can corrupt sorted key data when limit==0
- From: "me at serhei dot io" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Mon, 15 Jul 2019 16:51:15 +0000
- Subject: [Bug bpf/24811] New: stapbpf segfault: nested foreach loops can corrupt sorted key data when limit==0
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=24811
Bug ID: 24811
Summary: stapbpf segfault: nested foreach loops can corrupt
sorted key data when limit==0
Product: systemtap
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: bpf
Assignee: systemtap at sourceware dot org
Reporter: me at serhei dot io
Target Milestone: ---
spotted this while working on pr23858 which is a rabbit hole of tricky
behaviour
The existing if (limit == 0) goto empty; -> empty: keys.pop_back() code
sequence in bpfinterp.cxx map_get_next_key() seemed fishy to me. Turns out you
can cause a segfault with nested foreach loops.
foreach (k1- in a) { // push sorted data for a
flag = flag && k1 == (0-a[k1]) // check data for a
foreach (k2- in b) { // push sorted data for b
flag = flag && k2 == b[k2] // check data for b
foreach (k3- in a limit lim) { // bug -- don't push, pop sorted data for
b
flag = 0 // should not be invoked
} // bug -- after popping, will read sorted data for a on next iteration
} // pop sorted data for b, but with bug pops a
} // pop sorted data for a, but with bug pops <nada> -- segfault?
Filing since I suspect a less convoluted set of loops will cause the same
thing.
--
You are receiving this mail because:
You are the assignee for the bug.