Summary: | <net-analyzer/wireshark-2.2.7: Multiple vulnerabilities | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | Michael Boyle <boylemic> |
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
Status: | RESOLVED FIXED | ||
Severity: | minor | CC: | netmon |
Priority: | Normal | Flags: | stable-bot:
sanity-check+
|
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | B3 [noglsa cve] | ||
Package list: |
net-analyzer/wireshark-2.2.7
|
Runtime testing required: | --- |
Description
Michael Boyle
2017-06-05 02:09:01 UTC
@ Maintainer(s): Can we already start stabilization of =net-analyzer/wireshark-2.2.7? CVE-2017-9343 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-9343): In Wireshark 2.2.0 to 2.2.6 and 2.0.0 to 2.0.12, the MSNIP dissector misuses a NULL pointer. This was addressed in epan/dissectors/packet-msnip.c by validating an IPv4 address. CVE-2017-9344 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-9344): In Wireshark 2.2.0 to 2.2.6 and 2.0.0 to 2.0.12, the Bluetooth L2CAP dissector could divide by zero. This was addressed in epan/dissectors/packet-btl2cap.c by validating an interval value. CVE-2017-9345 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-9345): In Wireshark 2.2.0 to 2.2.6 and 2.0.0 to 2.0.12, the DNS dissector could go into an infinite loop. This was addressed in epan/dissectors/packet-dns.c by trying to detect self-referencing pointers. CVE-2017-9346 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-9346): In Wireshark 2.2.0 to 2.2.6 and 2.0.0 to 2.0.12, the SoulSeek dissector could go into an infinite loop. This was addressed in epan/dissectors/packet-slsk.c by making loop bounds more explicit. CVE-2017-9347 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-9347): In Wireshark 2.2.0 to 2.2.6, the ROS dissector could crash with a NULL pointer dereference. This was addressed in epan/dissectors/asn1/ros/packet-ros-template.c by validating an OID. CVE-2017-9348 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-9348): In Wireshark 2.2.0 to 2.2.6, the DOF dissector could read past the end of a buffer. This was addressed in epan/dissectors/packet-dof.c by validating a size value. CVE-2017-9349 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-9349): In Wireshark 2.2.0 to 2.2.6 and 2.0.0 to 2.0.12, the DICOM dissector has an infinite loop. This was addressed in epan/dissectors/packet-dcm.c by validating a length value. CVE-2017-9350 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-9350): In Wireshark 2.2.0 to 2.2.6 and 2.0.0 to 2.0.12, the openSAFETY dissector could crash or exhaust system memory. This was addressed in epan/dissectors/packet-opensafety.c by checking for a negative length. CVE-2017-9351 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-9351): In Wireshark 2.2.0 to 2.2.6 and 2.0.0 to 2.0.12, the DHCP dissector could read past the end of a buffer. This was addressed in epan/dissectors/packet-bootp.c by extracting the Vendor Class Identifier more carefully. CVE-2017-9352 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-9352): In Wireshark 2.2.0 to 2.2.6 and 2.0.0 to 2.0.12, the Bazaar dissector could go into an infinite loop. This was addressed in epan/dissectors/packet-bzr.c by ensuring that backwards parsing cannot occur. CVE-2017-9353 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-9353): In Wireshark 2.2.0 to 2.2.6, the IPv6 dissector could crash. This was addressed in epan/dissectors/packet-ipv6.c by validating an IPv6 address. CVE-2017-9354 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2017-9354): In Wireshark 2.2.0 to 2.2.6 and 2.0.0 to 2.0.12, the RGMP dissector could crash. This was addressed in epan/dissectors/packet-rgmp.c by validating an IPv4 address. (In reply to Thomas Deutschmann from comment #1) > @ Maintainer(s): Can we already start stabilization of > =net-analyzer/wireshark-2.2.7? Of course you can. @ Arches, please test and mark stable: =net-analyzer/wireshark-2.2.7 amd64 stable x86 stable ppc64 stable arm stable Stable on alpha. ppc stable ia64 stable sparc stable Arches, please finish stabilizing hppa Gentoo Security Padawan ChrisADR It seems hppa was stabilised by git commit ec35de853bc3f1331de3fd5cc6611390d6824b3c (In reply to Andreas Sturmlechner from comment #14) > It seems hppa was stabilised by git commit > ec35de853bc3f1331de3fd5cc6611390d6824b3c Thank you Andreas for the info. Security please vote for the GLSA. Gentoo Security Padawan ChrisADR GLSA Vote: No |