l2tp: prevent possible tunnel refcount underflow
Affects the Linux kernel L2TP code when L2TPv3 sessions have colliding IDs. CVSS scores it 7.8 (high). Fixed in kernel releases such as 6.6.160 and 6.11.3, depending on branch.
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Specific setups only
- Fix
- Fixed in 3.3, 3.17, 4.5, 4.10, 4.15, and 2 more
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: no
- Technical impact: partial
Summary
In the Linux kernel, the following vulnerability has been resolved: l2tp: prevent possible tunnel refcount underflow When a session is created, it sets a backpointer to its tunnel. When the session refcount drops to 0, l2tp_session_free drops the tunnel refcount if session->tunnel is non-NULL. However, session->tunnel is set in l2tp_session_create, before the tunnel refcount is incremented by l2tp_session_register, which leaves a small window where session->tunnel is non-NULL when the tunnel refcount hasn't been bumped. Moving the assignment to l2tp_session_register is trivial but l2tp_session_create calls l2tp_session_set_header_len which uses session->tunnel to get the tunnel's encap. Add an encap arg to l2tp_session_set_header_len to avoid using session->tunnel. If l2tpv3 sessions have colliding IDs, it is possible for l2tp_v3_session_get to race with l2tp_session_register and fetch a session which doesn't yet have session->tunnel set. Add a check for this case.
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: none · Automatable: no · Technical impact: partial
- Record last updated
Affected versions
- Linux Linux
From 3.2.99 · fixed in 3.3; From 3.16.54 · fixed in 3.17; From 4.4.225 · fixed in 4.5; From 4.9.225 · fixed in 4.10; From 4.14.182 · fixed in 4.15
- Linux Linux
4.15
- KernelLinux
From 4.15.0 · fixed in 6.6.160; From 6.7.0 · fixed in 6.11.3
References 4
Questions about CVE-2024-49940
What does this mean?
The fix prevents a tunnel reference count in the Linux kernel's L2TP code from possibly underflowing. The advisory's condition is that L2TPv3 sessions have colliding IDs.Source: git.kernel.org
Am I affected, and how do I check?
The listed kernel ranges run from 3.2.99 to before 3.3, 3.16.54 to before 3.17, 4.4.225 to before 4.5, 4.9.225 to before 4.10, and 4.14.182 to before 4.15, plus kernel 4.15.0 to before 6.6.160 and 6.7.0 to before 6.11.3. To check a system, compare its kernel version with `uname -r`, and check whether L2TPv3 is in use.Source: git.kernel.org
What should I do about it?
Upgrade to a kernel release that includes the fix for your branch, such as 6.6.160 or later on the 6.6 line, or 6.11.3 or later on the 6.7 line. Distribution kernels may carry the fix under their own version numbers.Source: git.kernel.org
Is it being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data