CVE-2026-72321 in Linux
Summary
by MITRE • 08/15/2026
In the Linux kernel, the following vulnerability has been resolved:
ipv4: igmp: Fix potential memory leaks in igmp_mod_timer() and igmp_stop_timer()
When a timer is deleted and not re-armed in igmp_mod_timer(), or stopped in igmp_stop_timer(), the code currently decrements the reference counter of the multicast list entry @im using refcount_dec(&im->refcnt).
However, both functions can be called from the RCU reader path: - igmp_mod_timer() via igmp_heard_query() -> for_each_pmc_rcu() - igmp_stop_timer() via igmp_rcv() -> igmp_heard_report()
If the group im was concurrently removed from the list by ip_mc_dec_group(), its reference count might have already been decremented to 1.
In this case, timer_delete() succeeds, and refcount_dec() decrements the refcount from 1 to 0. Since refcount_dec() does not free the object when it hits 0 (unlike ip_ma_put()), the im structure is leaked.
Fix this by using ip_ma_put(im) instead of refcount_dec(&im->refcnt), and deferring the put until after the spinlock is released.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/15/2026
This vulnerability resides within the Linux kernel's Internet Group Management Protocol implementation for IPv4 multicast operations, specifically affecting the multicast list entry management during timer operations. The issue manifests in two critical functions where memory leak conditions can occur due to improper reference counting mechanisms when dealing with concurrent access patterns. The root cause stems from the incorrect handling of multicast group entry references within RCU (Read-Copy-Update) reader paths, creating a scenario where objects remain allocated in memory even after they should have been freed.
The technical flaw occurs when timer deletion operations execute in contexts where the multicast list entry may have already been removed by concurrent processes. The functions igmp_mod_timer() and igmp_stop_timer() both operate within RCU reader sections but use refcount_dec() instead of proper reference counting mechanisms that would safely handle object cleanup. When ip_mc_dec_group() removes a group from the list concurrently with timer operations, the reference count can reach zero during the timer deletion sequence, causing the memory allocation for the multicast entry structure to remain unreleased.
The operational impact of this vulnerability creates persistent memory leaks within kernel space that can accumulate over time and potentially lead to system instability or resource exhaustion. Attackers could theoretically exploit this through sustained multicast traffic patterns that trigger the race condition repeatedly, though direct exploitation would require specific timing conditions. The vulnerability aligns with CWE-401: Improper Release of Memory Before Removing Last Reference, specifically manifesting in kernel memory management contexts where reference counting mechanisms fail to properly handle concurrent access scenarios.
This issue demonstrates a classic race condition problem commonly encountered in kernel development where RCU reader paths interact improperly with reference counting operations. The fix implemented addresses the core problem by replacing direct reference count manipulation with proper object release mechanisms using ip_ma_put() which correctly handles memory deallocation in all contexts including concurrent access scenarios. This approach ensures that multicast entry cleanup occurs only after all spinlock protection is released, preventing premature object destruction during concurrent operations.
The mitigation strategy follows established kernel security practices by ensuring proper reference counting semantics in concurrent environments and aligns with ATT&CK framework techniques related to privilege escalation through kernel memory corruption. The solution prevents the memory leak by ensuring that multicast group entries are properly freed when their reference counts reach zero, regardless of whether they were removed by concurrent processes or by normal timer operations, thereby maintaining system stability and preventing potential denial-of-service conditions.
This vulnerability represents a subtle but significant flaw in kernel memory management that could be leveraged to create persistent resource exhaustion conditions. The fix demonstrates proper handling of reference counting in RCU contexts and aligns with security best practices for kernel development. The implementation ensures that multicast group entries are properly cleaned up through the standard kernel memory management pathways rather than direct reference count manipulation, which could lead to inconsistent object lifecycle management under concurrent access patterns.