Look up another CVE · open CVE-2026-68398 in the interactive tracker

CVE-2026-68398

ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF

7.8 EPSS 0.2% AV:L

Published 2026-08-10 (2 months ago) by the Linux kernel CNA. Subsystem drivers/net. Debian urgency: not yet assigned.

What to do, per Debian release

Debian's own status for CVE-2026-68398 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	fixedDLA-4777-1 · 2026-09-08 · text	6.1.187-1	Update the kernel and reboot. DLA-4777-1 shipped the fix on 2026-09-08, in 6.1.187-1. A running kernel keeps the old code until the machine restarts.
Debian 13trixie	fixed	6.12.101-1	Update the kernel and reboot. Fixed in 6.12.101-1. A running kernel keeps the old code until the machine restarts.
Debian 14forky	fixed	7.1.6-1	Update the kernel and reboot. Fixed in 7.1.6-1. A running kernel keeps the old code until the machine restarts.
Debian unstablesid	fixed	7.1.6-1	Update the kernel and reboot. Fixed in 7.1.6-1. A running kernel keeps the old code until the machine restarts.
Debian 12bookworm · linux-6.12	fixedDLA-4745-1 · 2026-08-18 · text	6.12.101-1~deb12u1	Update the kernel and reboot. DLA-4745-1 shipped the fix on 2026-08-18, in 6.12.101-1~deb12u1. A running kernel keeps the old code until the machine restarts.

The vulnerability

What the bug is

pppol2tp_recv() runs in the L2TP UDP-encap softirq RX path: l2tp_udp_encap_recv() -> l2tp_recv_common() -> pppol2tp_recv() -> ppp_input(&po->chan) It runs under rcu_read_lock() holding only an l2tp_session reference and takes NO reference on the internal PPP channel (struct channel, chan->ppp) that ppp_input() dereferences. The pppox socket is SOCK_RCU_FREE, so 'po' and the embedded ppp_channel are RCU-safe. But the internal struct channel is a separate allocation that ppp_release_channel() frees with a plain kfree(): close(data socket) -> pppol2tp_release() -> pppox_unbind_sock() -> ppp_unregister_channel() -> ppp_release_channel() -> kfree(pch) For a channel that is bound (PPPIOCGCHAN) but not attached to a ppp unit (no PPPIOCCONNECT, pch->ppp == NULL) and not bridged, teardown skips both ppp_disconnect_channel()'s synchronize_net() and ppp_unbridge_channels()'s synchronize_rcu(), so the kfree() has no grace period. rcu_read_lock() in pppol2tp_recv() does not protect against a plain kfree(), so an in-flight ppp_input() on one CPU can dereference the channel just freed by close() on another CPU. The bug is reachable by an unprivileged user. Defer the channel free to an RCU callback via call_rcu() so the grace period fences any in-flight ppp_input(). The disconnect and unbridge teardown paths already fence with synchronize_net()/synchronize_rcu(); call_rcu() does the same here without stalling the close() path.

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.

drivers/net/ppp/ppp_generic.c

What this is: PPP PROTOCOL DRIVERS AND COMPRESSORSMAINTAINERS section matched on drivers/net/ppp/ppp_* · linux-ppp@vger.kernel.org · Orphan
Kernel module: ppp_generic

Check it on the machine

grep -wE 'CONFIG_PPP|CONFIG_PPPOE|CONFIG_PPPOL2TP|CONFIG_PPP_ASYNC|CONFIG_PPP_BSDCOMP|CONFIG_PPP_DEFLATE|CONFIG_PPP_MPPE|CONFIG_PPP_SYNC_TTY|CONFIG_PPTP' /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 ppp_generic

Prints 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, but not on every flavour. At least one release below builds the code on some of its kernel flavours and not on others, so the answer depends on the architecture and flavour installed.

bookwormMnot built on amd64/cloud-amd64, arm64/cloud-arm64
trixieMnot built on amd64/cloud-amd64, arm64/cloud-arm64, s390x/s390x
forky, sid, bookworm · linux-6.12Mnot built on amd64/cloud-amd64, arm64/cloud-arm64

M: a module where it is built at all; some flavours do not build it

Build switches: CONFIG_PPP, CONFIG_PPPOE, CONFIG_PPPOL2TP, CONFIG_PPP_ASYNC, CONFIG_PPP_BSDCOMP, CONFIG_PPP_DEFLATE, CONFIG_PPP_MPPE, CONFIG_PPP_SYNC_TTY, CONFIG_PPTP
Reads as: all on means the file is compiled; any one off means it is not.

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

Debian tracker CVE record NVD kernel CNA record

Signals

Published: 2026-08-10 (2 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.19%, higher than 8.6% of all CVEssource
CISA KEV: not listedthe KEV catalogue
Debian urgency: not yet assignedsource
Subsystem: drivers/net

Upstream fixes

The versions the CNA records as introducing and fixing this, and the commit for each. source

Introduced	Fixed in	Commit
4.15	5.15.216	4e47f1ac188e
4.15	6.1.183	110b765744b1
4.15	6.6.148	4bb84e964ff0
4.15	6.12.101	3ab32218d718
4.15	6.18.42	c9574b8a8ede
4.15	7.1.6	06213c85d8c0
4.15	7.2	ec4215683e47
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

Debian advisories

Advisory	Date	Shipped to	Debian
DLA-4777-1	2026-09-08	bookworm 6.1.187-1	tracker
DLA-4745-1	2026-08-18	bookworm 6.12.101-1~deb12u1	tracker

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 free side of the race is a local close() of the pppol2tp socket, which no remote peer can invoke; the full attack (create tunnel/session via AF_PPPOX socket, drive RX with loopback UDP datagrams, close concurrently) is performed entirely through local syscalls.
AC:LAttack complexity, low: The attacker controls both sides of the race, feeding the UDP-encap RX softirq from one thread while closing the pppox socket on another, and can retry the loop indefinitely until the window is hit.
PR:LPrivileges required, low: No capability check exists on this path: pppox_create()/pppol2tp_connect() and ppp_register_net_channel() need no CAP_NET_ADMIN, and PPPIOCGCHAN is handled by pppox_ioctl() on the socket itself, so /dev/ppp access is not required; the fix commit states the bug is reachable by an unprivileged user.
UI:NUser interaction, none: The attacker performs every step — socket creation, session setup, packet injection and close() — with no action by any other user or administrator.
S:UScope, unchanged: The use-after-free corrupts kernel slab memory within the same kernel security authority; no VM, IOMMU or sandbox boundary is crossed.
C:HConfidentiality impact, high: After the channel is freed and its slab object reallocated, ppp_input() reads pch->bridge and pch->ppp from attacker-groomed memory and can route received frames to an arbitrary attacker-chosen structure, giving a path to disclosing kernel memory.
I:HIntegrity impact, high: skb_queue_tail(&pch->file.rq, skb) writes a linked-list insertion into the freed object and wake_up_interruptible(&pch->file.rwait) traverses a freed waitqueue, so heap grooming yields controlled writes and function-pointer traversal usable for privilege escalation.
A:HAvailability impact, high: Dereferencing and writing to the kfree()d struct channel from softirq context reliably corrupts the slab and panics or oopses the kernel, and the race can be re-triggered at will.