Bug 2495867 - CVE-2026-14258 dhcpcd: dhcpcd infinite loop and out-of-bounds read via zero-length IPv6 ND option in Router Advertisement handling [epel-all]
Summary: CVE-2026-14258 dhcpcd: dhcpcd infinite loop and out-of-bounds read via zero-l...
Keywords:
Status: NEW
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: dhcpcd
Version: epel10
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
Assignee: Petr Menšík
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: {"flaws": ["8d9f4304-e7e1-4490-bd6a-7...
Depends On:
Blocks: CVE-2026-14258
TreeView+ depends on / blocked
 
Reported: 2026-07-01 09:15 UTC by TEJ RATHI
Modified: 2026-07-01 09:20 UTC (History)
3 users (show)

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


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github NetworkConfiguration/dhcpcd/commit/75289ca 0 None None None 2026-07-01 09:18:19 UTC
Github NetworkConfiguration dhcpcd issues 415 0 None closed Router advertisements with zero-length options trigger an infinite loop 2026-07-01 09:20:52 UTC

Description TEJ RATHI 2026-07-01 09:15:09 UTC
Disclaimer: Community trackers are created by Red Hat Product Security team on a best effort basis. Package maintainers are required to ascertain if the flaw indeed affects their package, before starting the update process.

AI_ONLY_REPORT
package: dhcpcd-10.0.6-10.el10
------
Summary: Out-of-Bounds Read and Infinite Loop via Zero-Length IPv6 ND  
Option: a crafted IPv6 Router Advertisement containing an ND option with  
`nd_opt_len == 0` can be retained in stored RA state and later re-parsed,  
leading to a reproducible non-advancing loop in RA handling; a related  
length-underflow read path exists in `ipv6nd_env`, but the availability  
impact is the high-confidence result.
Requirements to exploit: An unauthenticated attacker on the same L2 segment  
must be able to send an ICMPv6 Router Advertisement that passes normal RA  
acceptance checks, including hop-limit `255` and a link-local source  
address. The target must be running `dhcpcd` with IPv6 Router Advertisement  
handling enabled on the affected interface.
Component affected: `dhcpcd-10.0.6-10.el10`, `src/ipv6nd.c`, functions  
`ipv6nd_handlera`, `ipv6nd_env`, and `ipv6nd_expirera`
Version affected: `dhcpcd-10.0.6-10.el10` when IPv6 Router Advertisement  
processing is enabled on an interface that accepts local-link RAs
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 adjacency on the local network segment  
because the attacker must inject a Router Advertisement seen by the target  
interface.
AC:L - once on the local link, sending an RA with a zero-length ND  
option is straightforward and does not require a race or unusual  
environmental condition.
PR:N - no authentication or local privileges are required.
UI:N - no user action is needed.
S:U - the impact is confined to the vulnerable daemon's processing scope.
C:N - the available evidence does not establish confidentiality impact.
I:N - the available evidence does not establish integrity impact.
A:H - reparsing the stored malformed RA can leave the parser in a  
non-advancing loop and consume CPU, denying service.
Impact: Important. Red Hat classifies flaws that allow remote users to  
cause a denial of service as Important. Here, the demonstrated impact is an  
unauthenticated adjacent-network denial of service against core RA handling  
in `dhcpcd`. The current evidence does not support code execution or  
confirmed data exposure, so Critical is not warranted.
Embargo: no
Reason: The high-confidence impact is availability-only, exploitation  
requires local-link access, and the fix is a small validation change with  
straightforward operational mitigation.
Acknowledgement: Aisle Research
Vulnerability Details: In `ipv6nd_handlera`, the raw RA payload is stored  
in `rap->data` before all ND options are validated. If a later option has  
`nd_opt_len == 0`, the handler logs the problem and breaks, but the  
malformed packet has already been retained for later processing.
```c
if (rap->data_len == 0) {
rap->data = malloc(len);
memcpy(rap->data, icp, len);
rap->data_len = len;
}
...
olen = (size_t)ndo.nd_opt_len * 8;
if (olen == 0) {
logerrx("%s: zero length option", ifp->name);
break;
}
```
Both `ipv6nd_env` and `ipv6nd_expirera` later re-parse `rap->data`,  
recompute `olen = ndo.nd_opt_len * 8`, and advance with `p += olen` and  
`len -= olen`. Unlike `ipv6nd_handlera`, neither loop rejects `olen == 0`  
before using it. When `nd_opt_len` is zero, `olen` is zero, so the pointer  
and remaining length never change and the parser can spin indefinitely.
This yields a credible CPU denial of service in the RA processing path.  
`ipv6nd_env` also computes `olen - sizeof(ndo)` when calling  
`dhcp_envoption`; that underflows when `olen == 0`, but the available  
evidence does not establish an out-of-bounds read in this package build  
with the same confidence as the non-advancing loop.
Steps to reproduce:
1. Run `dhcpcd` on an interface where IPv6 Router Advertisement handling is  
enabled.
2. From another host on the same L2 segment, send an ICMPv6 Router  
Advertisement that satisfies normal RA acceptance checks, including  
hop-limit `255` and a link-local source address.
3. Include at least one ND option header in that RA with `nd_opt_len = 0`.
4. Allow the malformed RA to reach normal reprocessing paths. The reported  
paths are `ipv6nd_handlera(...)->ipv6nd_expirera(ifp)` in the same handling  
flow and `ROUTERADVERT` environment generation through `ipv6nd_env`.
5. Observe high CPU usage or a non-returning parse loop in RA handling. The  
availability impact does not depend on proving the lower-confidence  
out-of-bounds-read theory.
Mitigation: Until an updated package is available, disable IPv6 Router  
Advertisement processing on interfaces where it is not required, or filter  
untrusted ICMPv6 Router Advertisements on the local segment. This reduces  
exposure but may not be acceptable on systems that rely on SLAAC or  
RA-provided DNS information.
Proposed Fix: Add an explicit `olen == 0` rejection in the reparsing loops  
in `ipv6nd_env` and `ipv6nd_expirera`, matching the validation already  
present in `ipv6nd_handlera`.
```diff
diff --git a/src/ipv6nd.c b/src/ipv6nd.c
— a/src/ipv6nd.c
+++ b/src/ipv6nd.c
@@ -1732,6 +1732,10 @@ ipv6nd_env(FILE *fp, const struct interface *ifp)
memcpy(&ndo, p, sizeof(ndo));
olen = (size_t)(ndo.nd_opt_len * 8);
+			if (olen == 0) {
+				errno = EINVAL;
+				break;
+			}
if (olen > len) {
errno = EINVAL;
break;
@@ -1891,6 +1895,10 @@ ipv6nd_expirera(void *arg)
memcpy(&ndo, p, sizeof(ndo));
olen = (size_t)(ndo.nd_opt_len * 8);
+			if (olen == 0) {
+				errno = EINVAL;
+				break;
+			}
if (olen > len) {
errno = EINVAL;
break;
```
------
This report was generated using AI technology. Always review AI-generated  
content prior to use

Comment 1 Martin Osvald 🛹 2026-07-01 09:17:39 UTC
Fixing commit: https://github.com/NetworkConfiguration/dhcpcd/commit/75289ca


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