cve-2015-4491 fails with MALLOC_CHECK_=2 and MALLOC_PERTURB_=$((${RANDOM:-256} % 256)), sometimes
Bug #1519030 reported by
Dimitri John Ledkov
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
gdk-pixbuf |
Fix Released
|
Medium
|
|||
gdk-pixbuf (Ubuntu) |
Fix Released
|
Undecided
|
Dimitri John Ledkov |
Bug Description
cve-2015-4491 fails with MALLOC_CHECK_=2 and MALLOC_
it's possibly being killed with OOM, so need to validate that first.
tags: | added: xnox |
tags: |
added: s390x removed: xnox |
Changed in gdk-pixbuf (Ubuntu): | |
status: | In Progress → Triaged |
Changed in gdk-pixbuf: | |
importance: | Unknown → Medium |
status: | Unknown → Confirmed |
Changed in gdk-pixbuf: | |
status: | Confirmed → Fix Released |
To post a comment you must log in.
# for i in `seq 256`; do export MALLOC_PERTURB_=$i; .libs/lt- cve-2015- 4491>/dev/ null && echo $i: good || echo $i: bad; done
1: bad
2: good
3: good
4: bad
5: bad
6: good
7: good
8: good
9: good
10: bad
11: good
12: good
13: good
14: bad
15: good
16: good
17: good
18: good
Leads me to belief that the test is broken, and depends on the actuall memory to be in a consistent state after allocation. It seems that it has been recognised already that the test is borked, and it ends up skipping said test most of the time on s390x with OOM error. In my instance, it's getting OOM killed, rather than getting OOM error. Disabling MALLOC_PERTURB_ passes the test, which I've now done. This bug should be forwared upstream, for further investigation.