CVE-2026-10636: Use-After-Free in Zephyr IPv4 IGMP Implementation

Technical summary

CVE-2026-10636 is a use-after-free vulnerability in igmp_send() within subsys/net/ip/igmp.c. The vulnerable pattern occurs when igmp_send() calls net_send_data(pkt) and then attempts to dereference the packet via net_pkt_iface(pkt) afterward. Under the default synchronous transmission configuration (NET_TC_TX_COUNT=0), the L2 driver or network stack immediately releases the packet's final reference during transmission, returning the net_pkt slab block to the free list. The subsequent dereference returns a dangling pointer. When CONFIG_NET_STATISTICS_PER_INTERFACE is enabled, this dangling pointer is further dereferenced for writing to a statistics counter, creating a potential controlled-write condition if asynchronous TX and concurrent slab reuse occur. The IGMP send path is reachable without authentication from inbound IGMP membership queries (224.0.0.1) via the net_ipv4_igmp_input call chain, as well as from local multicast join/leave operations. The analogous IPv6 MLD implementation (mld_send in subsys/net/ip/ipv6_mld.c) contains the same unfixed pattern.

Business impact

For organizations deploying Zephyr-based IoT, embedded, or real-time systems relying on IGMP multicast functionality, this vulnerability introduces availability risk. Affected devices may experience sporadic crashes or network statistics corruption when IGMP membership queries are received or local multicast operations occur. While the CVSS score reflects low severity due to the specificity of triggering conditions and difficulty in achieving controlled writes, the unpredictability of memory corruption in embedded systems—particularly in long-running deployments—warrants attention. The vulnerability does not enable direct confidentiality or integrity breaches, but denial of service and subtle state corruption could impact service continuity or complicate troubleshooting in multicast-heavy environments.

Affected systems

Zephyr releases v2.6.0 through v4.4.0 are affected by this vulnerability. Any device or application using Zephyr with IPv4 IGMP support enabled is in scope. The vulnerability is particularly relevant to deployments using multicast join/leave operations or operating in networks where IGMP membership queries are regularly transmitted. Systems with CONFIG_NET_STATISTICS_PER_INTERFACE enabled face higher risk due to the potential for memory writes to dangling pointers. The analogous unfixed pattern in IPv6 MLD suggests that IPv6 multicast deployments may carry similar risk, though that is not formally covered by this CVE.

Exploitability

Exploitability is constrained by multiple factors. The vulnerability requires either inbound IGMP membership queries to 224.0.0.1 (which may occur naturally in multicast networks but are not guaranteed) or local multicast operations initiated on the device itself. Achieving a controllable write that leads to privilege escalation or code execution requires both asynchronous TX configuration and concurrent slab reuse—conditions unlikely to align on demand. A remote attacker can send IGMP membership queries without authentication, making the denial-of-service path more feasible than controlled exploitation. Local processes can trigger the vulnerability through multicast APIs. Overall, the vulnerability is more reliably exploitable for denial of service than for information disclosure or code execution, which explains the LOW CVSS severity rating despite the use-after-free class.

Remediation

The fix involves caching the network interface pointer before calling net_send_data(), eliminating the use-after-free read. This approach is confirmed to resolve the issue in patched versions. Organizations should verify patch availability from the Zephyr project for their specific release branch and apply updates as part of their maintenance cycle. The same pattern exists in the IPv6 MLD code path; consider whether separate patches address that component or if a comprehensive fix is available. For systems unable to immediately patch, limiting IGMP query reception (through network filtering or disabling IGMP if multicast is not required) reduces exposure, though this is not a substitute for patching.

Patch guidance

Consult the Zephyr project's official security advisories and release notes to identify patched versions for your release branch. Verify against the vendor advisory that the patch addresses igmp_send() and caches the interface pointer prior to net_send_data(). Test patches in a non-production environment to ensure compatibility with your application and multicast configuration. If your Zephyr deployment does not require IPv4 IGMP functionality, disabling CONFIG_NET_IPV4_IGMP at build time is a mitigation, though not all deployments may have that flexibility. Apply patches in priority order to devices in multicast-heavy network segments or those running long-lived processes where memory corruption could accumulate.

Detection guidance

Detection of exploitation is challenging because the vulnerability typically manifests as unpredictable crashes or network statistics anomalies rather than clear attack signatures. Monitor for: (1) unexplained device reboots or kernel panics coinciding with IGMP activity or multicast operations; (2) corruption or unexpected values in network statistics counters when CONFIG_NET_STATISTICS_PER_INTERFACE is enabled; (3) sporadic network connectivity loss in multicast-dependent services. Memory sanitizers or debugging builds with KASAN (Kernel Address Sanitizer) equivalents may detect the use-after-free if available for your Zephyr platform. Logging of IGMP membership queries and local multicast operations can help correlate crash timing with potential triggers. Post-incident analysis via core dumps, if available, may reveal the pattern of use-after-free through freed-memory markers in the slab allocator state.

Why prioritize this

While CVSS 3.7 (LOW) reflects the difficulty in achieving controlled exploitation, prioritization should account for environmental factors. Systems operating in managed multicast networks, or those running long-term deployments where sporadic memory corruption could degrade reliability, should prioritize patching. Devices exposed to external IGMP queries (e.g., at network borders) merit earlier remediation than internal-only systems. The availability impact and the risk of silent state corruption in statistics—particularly in systems monitoring multicast health—justify treating this as a medium-priority patch for multicast-dependent infrastructure, even if the base score is low. Organizations with strict uptime requirements should escalate this CVE in their patching calendar.

Risk score, explained

The CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L score of 3.7 reflects a network-reachable vulnerability (AV:N) with high attack complexity (AC:H) due to the specific conditions required to trigger memory corruption, no privilege requirement (PR:N), no user interaction (UI:N), unchanged scope (S:U), and a low availability impact (A:L) because reliable denial of service or controlled writes are not assured. The absence of confidentiality (C:N) and integrity (I:N) impact reflects the difficulty in weaponizing the use-after-free for data theft or code execution. The score appropriately downgrades the inherent severity of a use-after-free class vulnerability due to the mitigating factors of exploit complexity and the need for specific triggering conditions or configurations.

Frequently asked questions