CVE-2022-36788 TriangleMesh clone heap-based buffer overflow vulnerability
onitake opened this issue · 3 comments
Security issue
Full report: https://talosintelligence.com/vulnerability_reports/TALOS-2022-1593
CVE: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-36788
Affected versions
- Slic3r libslic3r 1.3.0
- Slic3r libslic3r Master Commit b1a5500
Comments
TALOS claims that the issue was reported on 2022-09-01, but the only commit since then was 026c138, which probably doesn't fix this issue.
According to the report, the potential for a buffer overflow lies in the memory allocation in TriangleMesh::clone .
The size of the array stl.facet_start should not be other.stl.stats.number_of_facets, but stl.stats.facets_malloced if I interpret the report correctly. number_of_facets may be smaller than facets_malloced due to face pruning.
Interestingly, stl_reallocate and stl_allocate are somewhat similar to TriangleMesh::clone, but the mesh shouldn't have any out-of-bounds indexes at that point. Perhaps it would really be better to normalize the mesh fully before cloning it?
This issue will cause slic3r to be dropped from the next stable release of Debian, unless very quickly resolved. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034848 and https://tracker.debian.org/pkg/slic3r .
The naive fix would be to simply replace number_of_facets with facets_malloced in the clone() method.
But I don't feel confident submitting a patch that does this, because I don't know the codebase.