CVE-2022-36788 TriangleMesh clone heap-based buffer overflow vulnerability

[onitake]

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 026c1380e0ad12176dd2fc8cdf8f6f181deeb071, 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?

[petterreinholdtsen]

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 .

[onitake]

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.

[onitake]

@alranel Could you take a quick look at this and help put a patch together? Does my suggestion make sense or am I overlooking something?