CVE-2026-18728: Open-iscsi: open-iscsi: integer underflow in iscsiuio ipv4 dhcp parsing

AIONLYREPORT package: iscsi-initiator-utils-6.2.1.11-0.git4b3e853.el10 ------ Summary: Integer Underflow in IPv4 TCP/UDP Payload Length Calculation: malformed IPv4 packets can underflow ustack->uiplen in uipprocess(), and in DHCP-enabled deployments the wrapped length is later trusted by the DHCP client, leading to out-of-bounds reads and denial of service. Requirements to exploit: Adjacent-network access to the target's L2 segment, a deployment where iscsiuio is using IPv4 DHCP (IPV4CONFIGDHCP), and the ability to send a crafted IPv4/UDP DHCP reply that reaches the DHCP parse path, including matching the expected DHCPREPLY/xid/chaddr checks and any ordinary packet validation enforced by the build. Component affected: iscsi-initiator-utils (iscsiuio/src/uip/uip.c in uipprocess(), with confirmed downstream impact in iscsiuio/src/apps/dhcpc/dhcpc.c parsemsg() / parseoptions()) Version affected: iscsi-initiator-utils-6.2.1.11-0.git4b3e853.el10 when iscsiuio is used with IPv4 DHCP (IPV4CONFIGDHCP) Patch available: no released package fix established; proposed patch included below Version fixed: unknown Upstream coordination: Not notified. CVSS: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H - 6.5 (MEDIUM) AV:A - exploitation requires access to the same L2 or broadcast domain as the target. AC:L - once on the local segment, the malformed packet structure is straightforward, and the required DHCP transaction fields are observable during normal DHCP traffic. PR:N - no authentication or prior access on the target is required. UI:N - no user action is needed. S:U - the impact is confined to the vulnerable component. C:N - the available evidence does not establish confidentiality impact. I:N - the available evidence does not establish integrity impact. A:H - the confirmed outcome is an out-of-bounds read that can crash the DHCP-enabled iscsiuio process. Impact: Moderate. Red Hat commonly treats remote denial of service as Important, but the confirmed impact here is narrower because exploitation requires adjacent-network reachability and a deployment where iscsiuio is actively handling IPv4 DHCP traffic. The available evidence supports a process crash in that configuration, but it does not establish code execution, privilege escalation, or a broader compromise outside the affected service. Embargo: no Reason: The confirmed issue is a configuration-dependent adjacent-network denial of service with straightforward mitigation and no demonstrated confidentiality, integrity, or code execution impact. Acknowledgement: Aisle Research Vulnerability Details: In the IPv4 receive path, uipprocess() updates ustack->uiplen from the IPv4 Total Length field, but it does not verify that the reported length is large enough to contain the required transport headers before subtracting them. In the IPv4 UDP path, a packet with totallength=20 reaches a subtraction against the IPv4 UDP header size (28 bytes), so the u16t length wraps from 20 - 28 to 65528. That wrapped length is later returned by uipdatalen() and consumed by the DHCP parser as trusted payload length. c if ((tcpipv4hdr->len[0] << 8) + tcpipv4hdr->len[1] <= ustack->uiplen) { ustack->uiplen = (tcpipv4hdr->len[0] << 8) + tcpipv4hdr->len[1]; } ... ustack->uiplen = ustack->uiplen - uipipudphlen; ustack->uipappdata = ustack->networklayer + uipipudphlen; ... u16t uipdatalen(struct uipstack ustack) { return ustack->uiplen; } ... if (m->op == DHCPREPLY && memcmp(m->xid, xid, sizeof(xid)) == 0 && memcmp(m->chaddr, s->macaddr, s->maclen) == 0) { memcpy(s->ipaddr, m->yiaddr, 4); return parseoptions(s, &m->options[4], uipdatalen(s->ustack)); } ... while (optptr < end) { ... optptr += optptr[1] + 2; } This creates a confirmed out-of-bounds read and denial-of-service path in the UDP/DHCP case. The TCP path uses the same length-subtraction pattern and should also be hardened, but the available evidence does not establish the same application-level impact there, so the confirmed exploitability and impact in this report are limited to the DHCP-enabled UDP path. Steps to reproduce: 1. Build and run iscsiuio on an interface using IPv4 DHCP (IPV4CONFIGDHCP). 2. Ensure the attacker is on the same L2 segment as the target and can observe the active DHCP exchange needed to match the transaction fields accepted by parsemsg(). 3. Send one crafted Ethernet+IPv4+UDP frame to the target MAC with Ethertype 0x0800, IPv4 vhl=0x45, a valid IPv4 header checksum, proto=17, dst=<target-ip or 255.255.255.255>, totallength=20, UDP header bytes still present in the frame payload, src port=67, dst port=68, op=DHCPREPLY, matching xid and chaddr, and enough trailing bytes that DHCP option parsing continues beyond the logical IP length. 4. Observe uipprocess() reach the UDP path and underflow ustack->uiplen. 5. Observe dhcpcappcall -> parsemsg -> parseoptions(..., uipdatalen()) process the oversized length and read beyond the logical packet bounds; the crash is reproducible under ASAN or Valgrind and may also be visible without instrumentation. Mitigation: Where feasible, avoid IPv4 DHCP on iscsiuio-managed interfaces until a fix is applied. If DHCP must remain enabled, restrict untrusted systems from the local broadcast domain and limit DHCP/BOOTP traffic so only trusted infrastructure can reach the affected host. Proposed Fix: Add lower-bound checks before subtracting transport and IP header sizes from ustack->uiplen, and drop malformed packets when the IPv4 Total Length is too small to contain the required headers. diff diff --git a/iscsiuio/src/uip/uip.c b/iscsiuio/src/uip/uip.c @@ -1482,7 +1482,13 @@ udpinput: ustack->uiplen = ustack->uiplen - uipipudphlen; + if (ustack->uiplen < uipipudphlen) { + ++ustack->stats.udp.drop; + ILOGDEBUG(PFX "udp: invalid IPv4 total length %u (< %u).", + ustack->uiplen, uipipudphlen); + goto drop; + } + ustack->uiplen = ustack->uiplen - uipipudphlen;

@@ -1848,7 +1854,13 @@ found: ustack->uiplen = ustack->uiplen - c - uipiphlen; + if (ustack->uiplen < (u16t)(c + uipiphlen)) { + ++ustack->stats.tcp.drop; + ILOGDEBUG(PFX "tcp: invalid IPv4 total length %u (hdr=%u).", + ustack->uiplen, (u16t)(c + uipiphlen)); + goto drop; + } + ustack->uiplen = ustack->uiplen - c - uipiphlen;

------ This report was generated using AI technology. Always review AI-generated content prior to use

— Red Hat