AI_ONLY_REPORT
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->uip_len` in `uip_process()`,  
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  
(`IPV4_CONFIG_DHCP`), and the ability to send a crafted IPv4/UDP DHCP reply  
that reaches the DHCP parse path, including matching the expected  
`DHCP_REPLY`/`xid`/`chaddr` checks and any ordinary packet validation  
enforced by the build.
Component affected: `iscsi-initiator-utils` (`iscsiuio/src/uip/uip.c` in  
`uip_process()`, with confirmed downstream impact in  
`iscsiuio/src/apps/dhcpc/dhcpc.c` `parse_msg()` / `parse_options()`)
Version affected: `iscsi-initiator-utils-6.2.1.11-0.git4b3e853.el10` when  
`iscsiuio` is used with IPv4 DHCP (`IPV4_CONFIG_DHCP`)
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, `uip_process()` updates  
`ustack->uip_len` 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  
`total_length=20` reaches a subtraction against the IPv4 UDP header size  
(`28` bytes), so the `u16_t` length wraps from `20 - 28` to `65528`. That  
wrapped length is later returned by `uip_datalen()` and consumed by the  
DHCP parser as trusted payload length.
```c
if ((tcp_ipv4_hdr->len[0] << 8) +
tcp_ipv4_hdr->len[1] <= ustack->uip_len) {
ustack->uip_len = (tcp_ipv4_hdr->len[0] << 8) +
tcp_ipv4_hdr->len[1];
}
...
ustack->uip_len = ustack->uip_len - uip_ip_udph_len;
ustack->uip_appdata = ustack->network_layer + uip_ip_udph_len;
...
u16_t uip_datalen(struct uip_stack *ustack)
{
return ustack->uip_len;
}
...
if (m->op == DHCP_REPLY &&
memcmp(m->xid, xid, sizeof(xid)) == 0 &&
memcmp(m->chaddr, s->mac_addr, s->mac_len) == 0) {
memcpy(s->ipaddr, m->yiaddr, 4);
return parse_options(s, &m->options[4], uip_datalen(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  
(`IPV4_CONFIG_DHCP`).
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 `parse_msg()`.
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>`, `total_length=20`, UDP  
header bytes still present in the frame payload, `src port=67`, `dst  
port=68`, `op=DHCP_REPLY`, matching `xid` and `chaddr`, and enough trailing  
bytes that DHCP option parsing continues beyond the logical IP length.
4. Observe `uip_process()` reach the UDP path and underflow  
`ustack->uip_len`.
5. Observe `dhcpc_appcall -> parse_msg -> parse_options(...,  
uip_datalen())` 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->uip_len`, 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 @@ udp_input:
   ustack->uip_len = ustack->uip_len - uip_ip_udph_len;
+    if (ustack->uip_len < uip_ip_udph_len) {
+        ++ustack->stats.udp.drop;
+        ILOG_DEBUG(PFX "udp: invalid IPv4 total length %u (< %u).",
+                   ustack->uip_len, uip_ip_udph_len);
+        goto drop;
+    }
+    ustack->uip_len = ustack->uip_len - uip_ip_udph_len;


@@ -1848,7 +1854,13 @@ found:
   ustack->uip_len = ustack->uip_len - c - uip_iph_len;
+    if (ustack->uip_len < (u16_t)(c + uip_iph_len)) {
+        ++ustack->stats.tcp.drop;
+        ILOG_DEBUG(PFX "tcp: invalid IPv4 total length %u (hdr=%u).",
+                   ustack->uip_len, (u16_t)(c + uip_iph_len));
+        goto drop;
+    }
+    ustack->uip_len = ustack->uip_len - c - uip_iph_len;
```


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