Bug 2556265 (CVE-2026-115484)

Summary:	CVE-2026-115484 open-iscsi: open-iscsi: DHCPv4 option parser heap out-of-bounds read in iscsiuio parse_msg
Product:	[Other] Security Response	Reporter:	OSIDB Bzimport <bzimport>
Component:	vulnerability	Assignee:	Product Security DevOps Team <prodsec-dev>
Status:	NEW ---	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	rhel-process-autobot, watson-tool-maintainers
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:	A flaw was found in the iscsiuio component of open-iscsi. The DHCPv4 option parser incorrectly calculates the length of the options data, causing it to read beyond the allocated buffer into adjacent heap memory. An attacker on the same network segment can send a crafted DHCP response to crash the daemon or corrupt its network configuration.	Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-10-20 15:50:02 UTC

Summary: The DHCPv4 option parser in iscsiuio passes the total UDP payload length to parse_options() instead of the options-only length, causing the parser to walk 240 bytes past the actual end of options data into adjacent heap memory.

Component affected: iscsi-initiator-utils (iscsiuio), iscsiuio/src/apps/dhcpc/dhcpc.c, parse_msg() (line 241) and parse_options() (line 206).

Vulnerability Details:

parse_msg() at line 249 calls:
  parse_options(s, &m->options[4], uip_datalen(s->ustack))

uip_datalen() returns the total UDP payload length, but &m->options[4] points 240 bytes into the DHCP message (236-byte struct dhcp_msg header + 4-byte magic cookie). The end pointer in parse_options() (line 208: end = optptr + len) is therefore 240 bytes past the actual end of the options data.

Additionally, parse_options() reads optptr[1] (option length byte) without verifying 2 bytes remain before end, and all memcpy calls use hardcoded 4-byte sizes without checking the option's declared length field.

This is distinct from CVE-2026-18728, which fixes an integer underflow in uip_process() where uip_len wraps when IPv4 Total Length < 28. This bug is in parse_msg() itself — even with a correctly computed uip_len, the offset subtraction is missing.

Requirements to exploit: Adjacent-network access on the same L2 segment as a system running iscsiuio with IPv4 DHCP enabled. The attacker must spoof a DHCP reply matching the xid and chaddr from a prior DHCP discover (both observable on L2). No authentication or user interaction required.

Version affected: All versions including latest upstream master (a65ce4b). Confirmed unfixed via ASAN-instrumented build on RHEL 10.2 (iscsi-initiator-utils-6.2.1.11-1.git4b3e853.el10_2.2) and upstream master.

Dynamic confirmation: ASAN SEGV in handle_dhcp → memcpy with OOB-derived pointer. Reproducible unit test provided.

CVSS: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H - 7.4
AV:A — L2-adjacent access required
AC:L — standard DHCP spoofing
PR:N / UI:N — no privileges or user interaction
S:U — impact within iscsiuio's own security authority
C:L — heap data leaks into network configuration
I:L — attacker-influenced network config via heap data
A:H — OOB read → SEGV crash confirmed; iSCSI-boot system loses connectivity

Proposed Fix: Subtract the DHCP message header size from the length passed to parse_options:
  return parse_options(s, &m->options[4], uip_datalen(s->ustack) - DHCP_MSG_LEN - 4);

Upstream status: No fix exists. CVE-2026-18728 does NOT cover this bug.
Acknowledgement: Red Hat Product Security