odhcpd is the DHCPv6, DHCPv4, and router-advertisement server used by OpenWrt. In versions 25.12 and prior, odhcpd's DHCPv6 self-loop detection at dhcpv6.c:720 uses a network-byte-order DUID length value directly as the memcmp() size parameter. On little-endian hosts, this causes memcmp() to read far beyond the stack buffer — a single unauthenticated DHCPv6 packet triggers a 2560-byte overread from a 128-byte buffer. At time of publication, there are no publicly available patches.

odhcpd is the DHCPv6, DHCPv4, and router-advertisement server used by OpenWrt. Prior to version 25.12, odhcpd's DHCPv6 IA handler keeps a per-message first lease pointer so multiple IA options in one message reuse the same Reconfigure authentication key. A DHCPv6 REQUEST from an adjacent-network client can make the first IA set first, then make a later same-IAID IA fail the on-link check and free that same lease, leaving first dangling. A following IA in the same packet allocates a new lease and copies first->key, producing a 16-byte heap-use-after-free read. ASan confirms the UAF; native tracing shows the packet shape can deterministically reclaim the freed lease as the destination allocation, producing a zeroed Reconfigure key copy. The validated impact is unauthenticated adjacent-network denial of service and DHCPv6 Reconfigure/ForceRenew key confusion. Arbitrary PC control is not proven for this UAF alone. This issue has been patched in version 25.12.

odhcpd is the DHCPv6, DHCPv4, and router-advertisement server used by OpenWrt. From version 17.01.0 to before version 25.12.3, odhcpd's DHCPv6 IA parser accepts an IANA or IAPD option whose body is shorter than struct dhcpv6iahdr, casts the option header to that full structure, and reads ia->iaid before proving that the IA body contains the IAID field. If an unauthenticated network-adjacent client places a zero-length or otherwise short IA option at the end of odhcpd's 8192-byte receive stack buffer, the IAID read crosses from databuf into adjacent stack memory. The disclosed bytes are then reflected in the DHCPv6 reply IAID; prior ARM validation showed databuf[8192:8196] disclosing the saved stack canary, and wider stack scans can leak ASLR-useful stack/process contents. This issue has been patched in version 25.12.3.

odhcpd is the DHCPv6, DHCPv4, and router-advertisement server used by OpenWrt. Prior to version 25.12, odhcpd's DHCPv6 IA response handler writes past the end of a fixed 512-byte stack buffer (pdbuf) when a single DHCPv6 REQUEST carries enough IA options to nearly exhaust the reply space. Two independent overflow sites exist in the same call chain, both reachable from the network via a single unauthenticated UDP packet. odhcpd runs as root on OpenWrt; embedded targets often lack stack canaries and ASLR, making code execution realistic. This issue has been patched in version 25.12.

odhcpd is the DHCPv6, DHCPv4, and router-advertisement server used by OpenWrt. In commit cfddd56 and earlier, an unauthenticated host on the same link can first obtain two bindings through normal DHCPv6 SOLICIT and REQUEST exchanges and then send a crafted RENEW containing multiple IANA options. An earlier matched IA consumes most of the response buffer, an unmatched IA causes the buildia() status branch to write and return a NOBINDING response larger than the remaining space, and a subsequent matched IA is processed after dhcpv6iahandleIAs() subtracts that over-return from an unsigned sizet. The resulting underflow disables subsequent length checks and permits attacker-controlled IAADDR serialization beyond the 512-byte stack buffer pdbuf in handleclientrequest(). The stack canary terminates odhcpd, and sustained packets can repeatedly disrupt DHCPv6 service while procd respawns the process. The observed configuration does not establish code execution.

On Thu, 11 Jun 2026, 01:41 Hauke Mehrtens, <hauke () hauke-m de> wrote: On 6/10/26 16:14, Lucas Holt wrote: On 6/10/26 8:52 AM, Christian Brabandt wrote: Agree, but they seemed to be swamped by CVE requests for the last couple of months. I have been waiting for up to 3 weeks on the final CVE assignment. I've also had delays getting them, but consider all the AI related reports. We submitted 13 requests for mport package manager recently.

Lucas Holt Luke () FoolishGames com MidnightBSD.org (Free OS) JustJournal.com (Free blogging) Thank you all for the help.

We requested CVE numbers on github about 1 week ago here: https://github.com/openwrt/odhcpd/security/advisories/

We will probably patch the vulnerabilities and also publish them before we have CVE numbers assigned and just update the advisory later. Hello Hauke, I'm operating a CNA (Ygreky) that can assign to projects that do not have any other. Contact vulns () ygreky com if interested. No fees or any conditions for open source.

Kind regards, Marta

On 6/10/26 16:14, Lucas Holt wrote: On 6/10/26 8:52 AM, Christian Brabandt wrote: Agree, but they seemed to be swamped by CVE requests for the last couple of months. I have been waiting for up to 3 weeks on the final CVE assignment. Lucas Holt Luke () FoolishGames com MidnightBSD.org (Free OS) JustJournal.com (Free blogging) Thank you all for the help.

We requested CVE numbers on github about 1 week ago here: https://github.com/openwrt/odhcpd/security/advisories/ Hauke

They did say they already requested CVEs that way.

I just asked some Github staff about the current situation, and apparently May was the highest volume month ever. So, there's a backlog they're trying to work through and catch up.

Someone also pointed me to this guide if you wanted to become a CNA yourself: https://sethmlarson.dev/security-developer-in-residence-weekly-report-17#becoming-a-cve-numbering-authority-as-an-open-source-project

Hopefully the Github team will catch up soon and get back to their usual timeliness.

- Sam

On Wed, 2026-06-10 at 11:27 +0000, Marcus Meissner wrote: Hi,

I concur, if you use github, its easiest workflow wise to use the Github Security Advisories and their CVE allocation ability.

Ciao, Marcus On Wed, Jun 10, 2026 at 05:36:03PM +0800, swing sze wrote: HI,

https://github.com/openwrt/odhcpd/security

Are you using the GitHub Security Advisor feature to submit CVEs?

Hauke Mehrtens <hauke () hauke-m de> 于2026年6月10日周三 16:59写道： Hi,

How to get a CVE number as a community driven open source project (OpenWrt)? We do not have a security department or a big company backing us.

Multiple security problems were reported to OpenWrt in the last few months. We want to assign CVE numbers to these problems, but have problems requesting numbers.

We contacted mitre in the past, but did not got a response within 2 weeks. Using github security advisories worked fine 2 months ago, we got a CVE number in some days. Currently this does not work any more, we are already waiting for 1 week.

How to get a CVE number?

We (OpenWrt) are a community driven open source project and got multiple reports from individuals and organizations like OpenAI.

We requested multiple CVE Numbers on github for this project: https://github.com/openwrt/odhcpd

Hauke

You can try VulnCheck — https://www.vulncheck.com/advisories/report On Jun 9, 2026, at 3:32 PM, Hauke Mehrtens <hauke () hauke-m de> wrote:

Hi,

How to get a CVE number as a community driven open source project (OpenWrt)? We do not have a security department or a big company backing us.

Multiple security problems were reported to OpenWrt in the last few months. We want to assign CVE numbers to these problems, but have problems requesting numbers.

We contacted mitre in the past, but did not got a response within 2 weeks. Using github security advisories worked fine 2 months ago, we got a CVE number in some days. Currently this does not work any more, we are already waiting for 1 week.

How to get a CVE number?

We (OpenWrt) are a community driven open source project and got multiple reports from individuals and organizations like OpenAI.

We requested multiple CVE Numbers on github for this project: https://github.com/openwrt/odhcpd

Hauke