Bug 2556265 (CVE-2026-115484) - CVE-2026-115484 open-iscsi: open-iscsi: DHCPv4 option parser heap out-of-bounds read in iscsiuio parse_msg
Summary: CVE-2026-115484 open-iscsi: open-iscsi: DHCPv4 option parser heap out-of-boun...
Keywords:
Status: NEW
Alias: CVE-2026-115484
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Product Security DevOps Team
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2026-10-20 15:50 UTC by OSIDB Bzimport
Modified: 2026-10-22 15:32 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

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


Note You need to log in before you can comment on or make changes to this bug.