VulnSocial

CVE-2026-68398Exploit

LOWCVSS 7.8 · HIGH

Exploit discussion active in current signal (2 latest mentions)

Immediate actions

  • Prioritize remediation for affected systems immediately
  • Hunt for exploitation attempts and persistence artifacts
  • Increase monitoring for publicly documented tradecraft
  • Track advisory updates for patch or workaround availability

Recommended action window: High priority (within 72h)

NVD 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.

Back to dashboard
3.5/ 10 priority

Sources & remediation

Other references

Priority

LOW

Exploitation

NONE

PoC

YES

Patch

NONE

Momentum

STABLE

Threat summary

  • Public PoC and exploit tooling are both present
  • 4 mentions across 2 observed days
  • Momentum state: stable

What's happening

  • Exploit tool or code specified in 4 signals
  • PoC mentioned or linked in 4 signals
  • Technical details provided in 4 signals
  • Peaked 1d ago at 2 mentions (2026-08-14); latest day: 2
  • 4 total mentions across 2 days

Deep dive

Activity timeline4 mentions / 2d
01122Mentions · 2026-08-14: 2Mentions · 2026-08-15: 2PoC Mentioned / Linked · 2026-08-14: 2PoC Mentioned / Linked · 2026-08-15: 2Exploit Tool / Code · 2026-08-14: 2Exploit Tool / Code · 2026-08-15: 2Technical Details · 2026-08-14: 2Technical Details · 2026-08-15: 208-1408-15
Signal classification2 categories
Exploit
250.0%
PoC
250.0%
Referenced assets4 URLs
Classification over time
DateTotalLabels
2026-08-142
Exploit2
2026-08-152
PoC2
Full discourse4 posts
  • Rıdvan Yağlı@ridvanyagli
    PoC

    🔴 Linux kernel'in PPPoL2TP bileşenindeki Use-After-Free (UAF) race condition zafiyeti (CVE-2026-68398) için çalışan bir LPE PoC/exploit yayınlandı. Exploit, ayrıcalıksız bir yerel kullanıcıdan root (UID 0) elde edebiliyor. Araştırmacı, exploit'i Ubuntu 22.04.5 LTS / kernel 5.15.0-187-generic üzerinde QEMU/KVM ortamında doğrulamış. KASLR, SMEP, SMAP ve AppArmor aktif durumda. https://github.com/aramosf/cve-2026-68398

    Post summary

    A Proof‑of‑Concept exploit for CVE-2026-68398, targeting a Use-After-Free in the Linux kernel's PPPoL2TP component, was published on GitHub and demonstrates local privilege escalation to root.

    125090305.7K
    2.4K followersView on X
  • Alejandro Ramos@aramosf
    PoC

    This is my third Proof of Concept (PoC) for privilege escalation in Linux. In this case, it comes from a commit that fixes the problem (still waiting for a CVE...). Linux AF_PACKET hard_header_len race: local root exploit (03390aa): https://github.com/aramosf/03390aa-packet-oob. The two previous ones were: CVE-2026-68138 https://github.com/aramosf/CVE-2026-68138 and CVE-2026-68398 https://github.com/aramosf/CVE-2026-68398. I keep wondering if I'm able to weaponize this with my limited knowledge, what other organizations are doing. We shouldn't be talking about embargoes; we should be talking about how to change processes that have remained unchanged for 20 years and are saturated and broken.

    Post summary

    The author shares a proof‑of‑concept and exploit code for a Linux AF_PACKET race condition that could lead to local root, but there is no evidence of active exploitation or a patch being issued.

    216144244.6K
    11.5K followersView on X
  • dbugs@ptdbugs
    Exploit

    A PoC/exploit has been discovered for vulnerability CVE-2026-68398 Vendor: Linux Product: Linux 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. Link: https://github.com/aramosf/cve-2026-68398 #dbugs_vuln

    Post summary

    A functional exploit (PoC) for CVE-2026‑68398 has been released, complete with code on GitHub and a detailed technical explanation of the kernel UAF. No active exploitation or patch information is reported.

    05132154.1K
    3.6K followersView on X
  • Alejandro Ramos@aramosf
    Exploit

    We keep burning tokens. This repository contains a build-specific local privilege-escalation exploit for Linux, CVE-2026-68398, a use-after-free race between PPPoL2TP: https://github.com/aramosf/CVE-2026-68398 (I have another one ready, but there's no CVE yet? I don't understand it, really... but I'll keep it a little longer) Stay tuned! Vuln discovery and fix are credited to Norbert Szetei

    Post summary

    The tweet announces a GitHub repository that contains a functional local privilege‑escalation exploit for CVE-2026-68398, detailing the use‑after‑free race in PPPoL2TP, with no indication of active exploitation or patch availability.

    01083906
    11.5K followersView on X

Explore more

Back to dashboard