Description

An out-of-bounds read was found in the DHCPv4 packet capture code of wicked. ni_capture_inspect_udp_header() in src/capture.c reports the IP total length as the payload length instead of the length of the remaining UDP payload. Consequently, the DHCP option walker in the DHCPv4 client (wickedd-dhcp4) reads up to ihl + 8 bytes — at most 68 bytes — past the end of the 1500-byte packet receive buffer. An unauthenticated attacker on the same network who sends a crafted DHCP/UDP packet can make the client parse adjacent heap memory as DHCP options, so that heap contents such as allocator metadata or pointer values can be interpreted into lease fields. The over-read is bounded to 68 bytes; no memory write, no attacker control over the adjacent bytes and no remote exfiltration primitive has been demonstrated. This issue affects wicked up to and including version 0.6.80.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.4",
  "pubDate": "2026-08-27T17:19:44.980Z",
  "pubdate": "2026-08-27T17:19:44.980Z",
  "executiveSummary": "An out-of-bounds (OOB) read vulnerability exists in the DHCPv4 packet capture component of wicked, specifically within the ni_capture_inspect_udp_header() function in src/capture.c.\nThe vulnerability occurs because the software incorrectly calculates the payload length by using the total IP packet length instead of the actual remaining UDP payload length.\nThis flaw allows an unauthenticated attacker on the same local network segment to send a maliciously crafted DHCP/UDP packet that forces the DHCPv4 client (wickedd-dhcp4) to perform an OOB read.\nThe client process can read up to 68 bytes beyond the allocated 1500-byte receive buffer, potentially exposing adjacent heap memory contents, including allocator metadata or internal pointer values.\nWhile the current scope of the vulnerability is limited to an OOB read without direct memory write capabilities, attacker control over memory layout, or a confirmed remote exfiltration primitive, the exposure of heap-resident sensitive information poses a risk to system integrity and potentially facilitates further exploitation.\nThe issue affects all versions of wicked up to and including 0.6.80.",
  "technicalDetails": "The root cause of this vulnerability lies in an improper length calculation within the function ni_capture_inspect_udp_header() located in src/capture.c. During the inspection of incoming DHCPv4 packets, the implementation incorrectly utilizes the IP total length field to determine the length of the DHCP payload.\nBy failing to account for the IP header length (IHL) and the UDP header overhead, the code assumes a larger payload than what is actually provided in the packet buffer. This error propagates to the DHCP option walker within the wickedd-dhcp4 client, which iterates through the purported payload to parse DHCP options.\nAn attacker can exploit this by constructing a malicious UDP/DHCP packet where the IP header fields are manipulated to misrepresent the payload size. When this packet is received and processed, the DHCP option walker continues its traversal beyond the legitimate end of the packet receive buffer (a fixed 1500-byte buffer).\nThe iteration can extend up to 'ihl + 8' bytes past the valid buffer boundary, with a maximum over-read of 68 bytes. This forced traversal reads adjacent heap memory, interpreting the data found there as valid DHCP options. This can lead to the accidental exposure or processing of sensitive heap data, such as allocator control structures or pointers, which might be improperly parsed as lease fields by the client.\nThe attack flow follows these steps: 1) The attacker injects a malformed DHCP/UDP packet into the local network segment. 2) The wickedd-dhcp4 process receives the packet into its 1500-byte buffer. 3) The function ni_capture_inspect_udp_header() processes the IP/UDP headers and sets an incorrect length boundary based on the IP header. 4) The DHCP option walker attempts to process DHCP options according to the incorrect boundary. 5) The walker reads past the buffer end into adjacent heap memory. 6) The heap data is parsed as if it were legitimate DHCP option data, potentially allowing an attacker to observe information influenced by the internal state of the heap.\nThis vulnerability is restricted to local network access; the attacker must be positioned on the same network segment to inject the crafted packets. No remote exfiltration primitive has been identified, and the vulnerability is strictly an out-of-bounds read with no demonstrated capability for memory writes or code execution."
}