CVE-2026-68398

Status: UPDATED  |  Advisory ID: CVE-2026-68398

Key Details

Affected Products, Subsystems & Sectors

What to Know

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

What to Do

Monitor Linux's web page for any future patch releases.

References