CVE-2026-110912
7.1HighPublished 15 Oct 2026 · NVD status: Deferred · AI triage by gemini-3.8-flash
- Attack vector
- Adjacent network
- Complexity
- Low
- Privileges needed
- None
- User interaction
- None
- Impact
- High impact on confidentiality
- Weakness
- CWE-130
Impact
Unauthenticated attackers on the local network can leak sensitive kernel heap and stack memory, including kernel pointers, by sending a single crafted ARP packet.
Root cause
The ARP input handlers fail to validate address length fields in ARP packets, causing an out-of-bounds memcpy into outgoing ARP replies.
Affected systems
DragonFly BSD through 6.4.2 before commit 4bb22ff
CVSS v4.0 · CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Fix & remediation
Upgrade to the 6.6 stable release once released, or backport commit 4bb22ff to the kernel and recompile.
$ uname -rAI-suggested. Run it in staging first and check it against the vendor advisory. Why?
NVD description
In DragonFly BSD through 6.4.2 before 4bb22ff, the ARP input handlers arpintr() and in_arpinput() (sys/netinet/if_ether.c) do not validate the hardware address length (ar_hln) and protocol address length (ar_pln) fields of incoming ARP packets. in_arpreply() then uses these attacker-controlled values as memcpy lengths when copying from kernel buffers that are only 6 and 4 bytes long, resulting in an out-of-bounds read of kernel heap and stack memory that is copied into the ARP reply sent back to the requester. An unauthenticated attacker on the adjacent network can use a single crafted ARP request to disclose up to roughly 250 bytes of each type of kernel memory, including kernel pointers. This is expected to be fixed in the 6.6 stable release when that is available.