http://bugzilla.opensuse.org/show_bug.cgi?id=1019328 Bug ID: 1019328 Summary: VUL-0: CVE-2017-5332, CVE-2017-5333: icoutils: __memcpy_sse2_unaligned(): wrestool killed by SIGSEGV Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.2 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: security-team@suse.de Reporter: mikhail.kasimov@gmail.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- Refs: [1] http://seclists.org/oss-sec/2017/q1/56 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1249276 [3] https://bugzilla.opensuse.org/show_bug.cgi?id=1018756 [1]: ===========================================================

Furthermore I would like to ask if the following two commits from upstream, can have as well an identifier assigned:

http://git.savannah.gnu.org/cgit/icoutils.git/commit?id=1aa9f28f7bcbdfff6a84...

http://git.savannah.gnu.org/cgit/icoutils.git/commit?id=1a108713ac26215c7568...

Yes, but because these are immediately consecutive commits, the CVE mapping may seem unusual. Use CVE-2017-5332 for all of 1aa9f28f7bcbdfff6a84a15ac8d9a87559b1596a and also the index correction in 1a108713ac26215c7568353f6e02e727e6d4b24a. In other words, the change from "entries[c]" to "entries[c-skipped]" in 1a108713ac26215c7568353f6e02e727e6d4b24a cannot have a new CVE ID because the code was never "shipped" with "entries[c]" in use. There aren't two independent problems related to establishing a maximum allowable value of the size variable. Use CVE-2017-5333 for the separate vulnerability fixed by the introduction of the "size >= sizeof(uint16_t)*2" test in 1a108713ac26215c7568353f6e02e727e6d4b24a. - -- CVE Assignment Team M/S M300, 202 Burlington Road, Bedford, MA 01730 USA [ A PGP key is available for encrypted communications at http://cve.mitre.org/cve/request_id.html ] =========================================================== -- You are receiving this mail because: You are on the CC list for the bug.