CVE-2026-68398: ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF

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

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

pppol2tprecv() runs in the L2TP UDP-encap softirq RX path:

l2tpudpencaprecv() -> l2tprecvcommon() -> pppol2tprecv() -> pppinput(&po->chan)

It runs under rcureadlock() holding only an l2tpsession reference and takes NO reference on the internal PPP channel (struct channel, chan->ppp) that pppinput() dereferences.

The pppox socket is SOCKRCUFREE, so 'po' and the embedded pppchannel are RCU-safe. But the internal struct channel is a separate allocation that pppreleasechannel() frees with a plain kfree():

close(data socket) -> pppol2tprelease() -> pppoxunbindsock() -> pppunregisterchannel() -> pppreleasechannel() -> 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 pppdisconnectchannel()'s synchronizenet() and pppunbridgechannels()'s synchronizercu(), so the kfree() has no grace period. rcureadlock() in pppol2tprecv() does not protect against a plain kfree(), so an in-flight pppinput() 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 callrcu() so the grace period fences any in-flight pppinput(). The disconnect and unbridge teardown paths already fence with synchronizenet()/synchronizercu(); callrcu() does the same here without stalling the close() path.