usage

Modify the fields in the script:

iface <- If you have multiple adapters, you need to choose which one to use to send packets. e.g. “eth0” on linux or “Hyper-V Virtual Ethernet Adapter” on windows. If you’re going to use your default interface, leave it empty.
ip_addr <- IP address of the target system (IPv6)
num_tries & num_batches <- How many different packet batches to send. more of them = more heap corruptions caused + higher chance of triggering the vulnerability.
mac_addr <- Leave empty, unless scapy complains it can’t find the mac address. See below in troubleshooting.

Run the script:

python3 cve-2024-38063.py

The easiest way to reproduce the vuln is by using bcdedit /set debug on and restarting the machine/VM. This makes the default network adapter driver kdnic.sys, which is very happy to coalesce packets. If you’re trying to reproduce the vuln on a different setup, you’ll need to get the system in a position where it will coalesce the packets you sent. You can read the troubleshooting section below on more details.

In certain situations, windows will coalesce multiple IP packets together and batch process them. It processes the extension headers in each packet first, and only then moves on to process the data in each packet.
During extension header processing, packet objects of these coalesced packets are linked together in a linked list. Each packet object contains a NET_BUFFER object which contains buffered packet data. At offset 0x30 we also have a current-offset field which indicates how far the packet has been parsed. At this stage, the offset value will generally be 0x28, indicating that the IPv6 header has been parsed but nothing else.
When processing the “destination options” extension header in tcpip!Ipv6pReceiveDestinationOptions, a parsing error will result in tcpip!IppSendErrorList being called. This function calls tcpip!IppSendError on each packet object in the linked list (starting from the current one).
Under certain conditions (e.g. if the packet is unicast), tcpip!IppSendError has side effects. It “reverts” the buffered packet data back to the start and resets the current-offset field to zero. However, only the first packet is marked as having an error, while the other ones will continue being processed.
The processing of other packets in the list is now done with unexpected data: the buffered packet data is pointing towards the beginning of the packet (i.e. the IPv6 header) rather than to the extension headers, and the offset field value is zero rather than 0x28.