Description
In the Linux kernel, the following vulnerability has been resolved:

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

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.
Published: 2026-08-10
Score: n/a
EPSS: n/a
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The vulnerability resides in the PPP over L2TP UDP encapsulation code path in the Linux kernel. An unprivileged user can trigger a use‑after‑free when an L2TP UDP socket that is bound to a PPP channel is closed while the channel is still being processed by the receiving routine. The freed channel memory may be accessed again, causing a crash or, if the attacker can influence the freed memory contents, possible arbitrary code execution. The flaw is a classic use‑after‑free defect and is observed via normal user‑level operations such as closing sockets, so it is reachable by any local user.

Affected Systems

This defect affects the Linux kernel in all versions that implement the PPP over L2TP UDP encapsulation handler. No specific kernel sub‑versions are enumerated in the advisory, so any kernel compiled with that functionality is potentially vulnerable. The advisory lists the Linux kernel as the only affected product.

Risk and Exploitability

The CVSS score and EPSS score are not disclosed, and the vulnerability is not listed in CISA's KEV catalog, indicating that it is not yet publicly exploited. However, the defect is a use‑after‑free reachable through ordinary user actions, suggesting a moderate exploitation risk if an attacker can control the freed memory contents. Attackers would need local access and the ability to perform a race condition between the close operation and the in‑flight processing. Given the lack of public exploits and the need for a race, the overall likelihood of successful exploitation is currently considered low to moderate, but the impact is high if exploited.

Generated by OpenCVE AI on August 10, 2026 at 16:10 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Update the Linux kernel to a version that includes the fix applied in commit 06213c85d8c09
  • If an immediate kernel update is not possible, disable L2TP UDP encapsulation or restrict access to PPP devices so that no unprivileged user can open or close L2TP sockets
  • As a temporary mitigation, ensure that the system is patched with a recent kernel release; if patches are not available, consider switching to a different tunneling protocol that is not affected by this flaw

Generated by OpenCVE AI on August 10, 2026 at 16:10 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Mon, 10 Aug 2026 16:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-416

Mon, 10 Aug 2026 12:30:00 +0000

Type Values Removed Values Added
Description In the Linux kernel, the following vulnerability has been resolved: ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF 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.
Title ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-08-10T12:04:17.771Z

Reserved: 2026-07-30T09:28:09.389Z

Link: CVE-2026-68398

cve-icon Vulnrichment

No data.

cve-icon NVD

No data.

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-08-10T16:15:04Z

Weaknesses