Look up another CVE · open CVE-2024-49940 in the interactive tracker
CVE-2024-49940
l2tp: prevent possible tunnel refcount underflow
Published 2024-10-21 (24 months ago) by the Linux kernel CNA. Subsystem net/l2tp. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2024-49940 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | vulnerable | 6.1.190-1 | No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication. |
| Debian 13trixie | fixed | 6.11.4-1 | Update the kernel and reboot. Fixed in 6.11.4-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 6.11.4-1 | Update the kernel and reboot. Fixed in 6.11.4-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 6.11.4-1 | Update the kernel and reboot. Fixed in 6.11.4-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
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.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
net/l2tp/l2tp_core.c
net/l2tp/l2tp_core.h
net/l2tp/l2tp_netlink.c
net/l2tp/l2tp_ppp.c
- What this is
- NETWORKING [GENERAL]MAINTAINERS section matched on net/ · netdev@vger.kernel.org · Maintained
- Kernel module
- l2tp_core
Check it on the machine
grep -w CONFIG_L2TP /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
lsmod | grep -w l2tp_corePrints a line if that module is loaded right now, and nothing if it is not. One that is not loaded can still be loaded later by anything that needs it.
Show whether Debian builds this, per release
Debian builds this as a loadable module. Every release below compiles it as a module on every flavour, so whether the code is in the running kernel depends on whether that module is loaded.
- bookworm, trixie, forky, sidm
- m
- a loadable module on every flavour - check lsmod, can be blacklisted
- Build switch
- CONFIG_L2TP
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2024-10-21 (24 months ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.24%, higher than 14.1% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- net/l2tp
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 4.15 | 6.11.3 | f7415e60c25a |
| 4.15 | 6.12 | 24256415d186 |
| 3.2.99 | 0 | 0 |
| 3.16.54 | 0 | 0 |
| 4.4.225 | 0 | 0 |
| 4.9.225 | 0 | 0 |
| 4.14.182 | 0 | 0 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The refcount underflow is triggered by local session creation — either the L2TP generic-netlink `L2TP_CMD_SESSION_CREATE` command or a `connect()` on an `AF_PPPOX`/`PX_PROTO_OL2TP` socket. A remote peer cannot itself drive `l2tp_session_create()`/`l2tp_session_register()`, though remote packets in `l2tp_udp_encap_recv()` are what subsequently dereference the prematurely freed tunnel.
- AC:LAttack complexity, low
- The attacker fully controls both sides: they choose the session ID, so they can deterministically force `l2tp_session_register()` to fail (`-EEXIST` on a colliding L2TPv3 ID, or `-ENODEV`), and they can run concurrent create/teardown threads to widen the window between `l2tp_session_create()` and the tunnel refcount bump. No condition outside attacker influence is required, and L2TP is a stock distro module.
- PR:LPrivileges required, low
- `pppol2tp_create()`/`pppox_create()` perform no capability check, so a plain unprivileged local user can reach `l2tp_session_create()` and `l2tp_session_register()` through `connect()`. The netlink path is `GENL_UNS_ADMIN_PERM` (CAP_NET_ADMIN against the netns user_ns), which any unprivileged user obtains via `unshare -Urn`.
- UI:NUser interaction, none
- The attacker performs the entire sequence — tunnel setup, session creation with a colliding ID, and session teardown — from their own process. No victim action or cooperating user is involved.
- S:UScope, unchanged
- The underflow and the resulting use-after-free are confined to the kernel's own l2tp objects within the same security authority; no VM, IOMMU, or sandbox boundary is crossed.
- C:HConfidentiality impact, high
- The dropped-too-early tunnel reference frees `struct l2tp_tunnel` while `session->tunnel` and the datapath still reference it, giving a use-after-free on a kmalloc'd object that can be reclaimed with attacker-sprayed data and then read back (e.g. `tunnel->sock`, `tunnel->encap`, `tunnel->version` used in `l2tp_recv_common()`/`l2tp_xmit_skb()`), enabling kernel memory disclosure.
- I:HIntegrity impact, high
- A use-after-free on the tunnel object lets an attacker reoccupy the freed slab and control fields such as `tunnel->sock`, which the transmit and receive paths dereference and pass to socket operations, yielding a write/control-flow-hijack primitive. Additionally the extra `l2tp_tunnel_dec_refcount()` corrupts kernel reference-counting state itself.
- A:HAvailability impact, high
- Premature tunnel free reliably produces an oops/panic when the still-live session or a received L2TP packet dereferences the dangling `session->tunnel`, and the `refcount_t` underflow itself raises a WARN that panics on `panic_on_warn` systems.