{"vulnerability": "cve-2021-3031", "sightings": [{"uuid": "7034725a-aee9-45ed-a857-c0037bcb1236", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2021-30318", "type": "seen", "source": "https://t.me/cibsecurity/37279", "content": "\u203c CVE-2021-30318 \u203c\n\nImproper validation of input when provisioning the HDCP key can lead to memory corruption in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Voice & Music, Snapdragon Wearables\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2022-02-11T14:28:27.000000Z"}, {"uuid": "6a9e6e13-6b4b-44a2-bb06-a956d34176ef", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2021-30317", "type": "seen", "source": "https://t.me/cibsecurity/37288", "content": "\u203c CVE-2021-30317 \u203c\n\nImproper validation of program headers containing ELF metadata can lead to image verification bypass in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer Electronics Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Voice & Music, Snapdragon Wired Infrastructure and Networking\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2022-02-11T14:28:37.000000Z"}, {"uuid": "7ed2fe01-6fef-412d-847a-350bde02a138", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2021-30313", "type": "seen", "source": "https://t.me/cibsecurity/35397", "content": "\u203c CVE-2021-30313 \u203c\n\nUse after free condition can occur in wired connectivity due to a race condition while creating and deleting folders in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Voice & Music, Snapdragon Wearables, Snapdragon Wired Infrastructure and Networking\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2022-01-13T14:18:12.000000Z"}, {"uuid": "e5818418-2e7e-40a9-aa44-0d38ff0dc83c", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2021-30314", "type": "seen", "source": "https://t.me/cibsecurity/35396", "content": "\u203c CVE-2021-30314 \u203c\n\nLack of validation for third party application accessing the service can lead to information disclosure in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Wearables\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2022-01-13T14:18:10.000000Z"}, {"uuid": "7c9baa89-30bb-4972-87ed-ddd22f4244a2", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2021-30311", "type": "seen", "source": "https://t.me/cibsecurity/35399", "content": "\u203c CVE-2021-30311 \u203c\n\nPossible heap overflow due to lack of index validation before allocating and writing to heap buffer in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Industrial IOT, Snapdragon Mobile\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2022-01-13T14:18:15.000000Z"}, {"uuid": "c0ed6202-89c7-45cd-be61-7d61bc755ac4", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2021-30319", "type": "seen", "source": "https://t.me/cibsecurity/35391", "content": "\u203c CVE-2021-30319 \u203c\n\nPossible integer overflow due to improper validation of command length parameters while processing WMI command in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer Electronics Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Voice & Music\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2022-01-13T14:18:03.000000Z"}, {"uuid": "abf641aa-c6f2-4b1a-9729-933b3e8f56e4", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2021-30312", "type": "seen", "source": "https://t.me/cibsecurity/30853", "content": "\u203c CVE-2021-30312 \u203c\n\nImproper authentication of sub-frames of a multicast AMSDU frame can lead to information disclosure in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Voice & Music, Snapdragon Wearables, Snapdragon Wired Infrastructure and Networking\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2021-10-20T12:35:10.000000Z"}, {"uuid": "2446548b-99b9-4921-bee4-8d3c9c27a8d7", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2021-30310", "type": "seen", "source": "https://t.me/cibsecurity/30856", "content": "\u203c CVE-2021-30310 \u203c\n\nPossible buffer overflow due to Improper validation of received CF-ACK and CF-Poll data frames in Snapdragon Auto, Snapdragon Connectivity, Snapdragon Consumer Electronics Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon IoT, Snapdragon Mobile, Snapdragon Voice & Music\n\n\ud83d\udcd6 Read\n\nvia \"National Vulnerability Database\".", "creation_timestamp": "2021-10-20T12:35:14.000000Z"}, {"uuid": "30a8b79d-b333-414e-b2c6-f9add884e3d1", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2021-3031", "type": "seen", "source": "https://t.me/hacking_Attack/186842", "content": "EtherLeak: IP Total Length Over-read via Ethernet Frame Padding | Netacoding\nhttps://www.reddit.com/r/redteamsec/comments/1tzh41w/etherleak_ip_total_length_overread_via_ethernet/\n\nBackground In 2003, CVE-2003-0001 documented that multiple NIC drivers leaked kernel memory through Ethernet frame padding \u2014 extractable via ICMP Echo. In 2021, Palo Alto disclosed CVE-2021-3031: the same class of issue on PA-series firewalls, affecting every model from PA-200 to PA-7000. In 2026, independent research confirmed the mechanism alive in enterprise network infrastructure. The vulnerability has a name \u2014 EtherLeak \u2014 a simple root cause, and a consistent lifecycle: discovered, patched in one product, rediscovered in another. This post documents the mechanism in full. The Ethernet Minimum Frame Problem Ethernet has a minimum frame size requirement of 60 bytes (excluding the 4-byte FCS). This minimum exists for collision detection in half-duplex environments (the slot time constraint from 10BASE5). When the actual payload is smaller than the minimum, the NIC pads the frame to reach 60 bytes: [ Ethernet Header (14B) ][ IP Header (20B) ][ ICMP Header (8B) ][ Padding (18B) ] = 14 + 20 + 8 + 18 = 60 bytes \u2713  The critical question: what goes into those 18 bytes of padding? The answer depends on the NIC driver and operating system:  Well-implemented stacks: padding is zeroed before transmission. Poorly-implemented or legacy drivers: padding contains whatever was in the DMA ring buffer slot from the previously processed frame.  In the latter case, those 18 bytes can contain fragments of:  Previous frame payloads (management traffic, credentials, session tokens) Source/destination MAC addresses and IP addresses from adjacent frames Partial application-layer data from in-flight management connections  The Vulnerability Mechanism IP Total Length vs. Actual Frame Data The IP header contains a Total Length field (bytes 2-3) declaring the total size of the IP datagram. The ICMP Echo handler uses this field to determine how much payload to echo back: icmp_payload_length = IP_Total_Length - IP_Header_Length - ICMP_Header_Length = IP_Total_Length - 20 - 8 = IP_Total_Length - 28  A standards-compliant implementation validates this value against the actual received frame length. A vulnerable implementation trusts it unconditionally. When an attacker sends a packet with IP_Total_Length inflated beyond the actual IP data: Attacker sends: Actual IP data: 28 bytes (IP header + ICMP header, no payload) IP_Total_Length: 46 (claims 18 bytes of payload exist) Wire frame: 42 bytes actual + 18 bytes NIC padding = 60 bytes Vulnerable handler calculates: icmp_payload = 46 - 28 = 18 bytes Reads 18 bytes starting after the ICMP header \u2192 Reads INTO the NIC padding area \u2192 Echoes back whatever is there  The reply mirrors the inflated IP_Total_Length, confirming the over-read occurred. Threshold Determination The maximum exploitable IP_Total_Length is bounded by the Ethernet minimum frame size: Maximum IP_Total_Length = Ethernet minimum frame - Ethernet header = 60 - 14 = 46 bytes \u2192 Maximum over-read = 46 - 28 = 18 bytes  Values above 46 cause the handler to read beyond the minimum Ethernet frame boundary \u2014 at which point behavior becomes implementation-specific. Empirically, many stacks drop these packets silently.   IP_Total_Length Actual IP Data Over-read Expected Behavior    28 28 0 bytes Normal reply   29 28 1 byte Reply \u2014 1B over-read   36 28 8 bytes Reply \u2014 8B over-read   46 28 18 bytes Reply \u2014 maximum over-read   48+ 28 \u2014 Typically dropped   more on blog...    submitted by    /u/Pale_Surround_3924  (https://www.reddit.com/user/Pale_Surround_3924) \n [link] (https://netacoding.com/posts/etherleak-reloaded/)   [comments] (https://www.reddit.com/r/redteamsec/comments/1tzh41w/etherleak_ip_total_length_overread_via_ethernet/)", "creation_timestamp": "2026-09-01T20:00:07.906760Z"}, {"uuid": "64b9f91b-3cec-4a42-aa56-7d7d2cdc43fa", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2021-3031", "type": "published-proof-of-concept", "source": "https://t.me/hacking_Attack/186842", "content": "EtherLeak: IP Total Length Over-read via Ethernet Frame Padding | Netacoding\nhttps://www.reddit.com/r/redteamsec/comments/1tzh41w/etherleak_ip_total_length_overread_via_ethernet/\n\nBackground In 2003, CVE-2003-0001 documented that multiple NIC drivers leaked kernel memory through Ethernet frame padding \u2014 extractable via ICMP Echo. In 2021, Palo Alto disclosed CVE-2021-3031: the same class of issue on PA-series firewalls, affecting every model from PA-200 to PA-7000. In 2026, independent research confirmed the mechanism alive in enterprise network infrastructure. The vulnerability has a name \u2014 EtherLeak \u2014 a simple root cause, and a consistent lifecycle: discovered, patched in one product, rediscovered in another. This post documents the mechanism in full. The Ethernet Minimum Frame Problem Ethernet has a minimum frame size requirement of 60 bytes (excluding the 4-byte FCS). This minimum exists for collision detection in half-duplex environments (the slot time constraint from 10BASE5). When the actual payload is smaller than the minimum, the NIC pads the frame to reach 60 bytes: [ Ethernet Header (14B) ][ IP Header (20B) ][ ICMP Header (8B) ][ Padding (18B) ] = 14 + 20 + 8 + 18 = 60 bytes \u2713  The critical question: what goes into those 18 bytes of padding? The answer depends on the NIC driver and operating system:  Well-implemented stacks: padding is zeroed before transmission. Poorly-implemented or legacy drivers: padding contains whatever was in the DMA ring buffer slot from the previously processed frame.  In the latter case, those 18 bytes can contain fragments of:  Previous frame payloads (management traffic, credentials, session tokens) Source/destination MAC addresses and IP addresses from adjacent frames Partial application-layer data from in-flight management connections  The Vulnerability Mechanism IP Total Length vs. Actual Frame Data The IP header contains a Total Length field (bytes 2-3) declaring the total size of the IP datagram. The ICMP Echo handler uses this field to determine how much payload to echo back: icmp_payload_length = IP_Total_Length - IP_Header_Length - ICMP_Header_Length = IP_Total_Length - 20 - 8 = IP_Total_Length - 28  A standards-compliant implementation validates this value against the actual received frame length. A vulnerable implementation trusts it unconditionally. When an attacker sends a packet with IP_Total_Length inflated beyond the actual IP data: Attacker sends: Actual IP data: 28 bytes (IP header + ICMP header, no payload) IP_Total_Length: 46 (claims 18 bytes of payload exist) Wire frame: 42 bytes actual + 18 bytes NIC padding = 60 bytes Vulnerable handler calculates: icmp_payload = 46 - 28 = 18 bytes Reads 18 bytes starting after the ICMP header \u2192 Reads INTO the NIC padding area \u2192 Echoes back whatever is there  The reply mirrors the inflated IP_Total_Length, confirming the over-read occurred. Threshold Determination The maximum exploitable IP_Total_Length is bounded by the Ethernet minimum frame size: Maximum IP_Total_Length = Ethernet minimum frame - Ethernet header = 60 - 14 = 46 bytes \u2192 Maximum over-read = 46 - 28 = 18 bytes  Values above 46 cause the handler to read beyond the minimum Ethernet frame boundary \u2014 at which point behavior becomes implementation-specific. Empirically, many stacks drop these packets silently.   IP_Total_Length Actual IP Data Over-read Expected Behavior    28 28 0 bytes Normal reply   29 28 1 byte Reply \u2014 1B over-read   36 28 8 bytes Reply \u2014 8B over-read   46 28 18 bytes Reply \u2014 maximum over-read   48+ 28 \u2014 Typically dropped   more on blog...    submitted by    /u/Pale_Surround_3924  (https://www.reddit.com/user/Pale_Surround_3924) \n [link] (https://netacoding.com/posts/etherleak-reloaded/)   [comments] (https://www.reddit.com/r/redteamsec/comments/1tzh41w/etherleak_ip_total_length_overread_via_ethernet/)", "creation_timestamp": "2026-09-02T01:00:20.736139Z"}]}