CVE-2026-68398

ملخص

في نواة لينكس، تم حل الثغرة الأمنية التالية: ppp: تأجيل تحرير القناة إلى فترة سماح RCU لإصلاح ثغرة الاستخدام بعد التحرير (UAF) في pppol2tp RX تعمل الدالة pppol2tp_recv() في مسار استقبال L2TP UDP-encap softirq RX: l2tp_udp_encap_recv() -> l2tp_recv_common() -> pppol2tp_recv() -> ppp_input(&po->chan) تعمل هذه الدالة تحت rcu_read_lock() مع الاحتفاظ بمرجع l2tp_session فقط ولا تأخذ أي مرجع على قناة PPP الداخلية (struct channel, chan->ppp) التي تقوم ppp_input() بفك الإشارة إليها. مقبس pppox هو SOCK_RCU_FREE، لذا فإن 'po' و ppp_channel المضمّن آمنان من ناحية RCU. لكن struct channel الداخلية هي تخصيص منفصل تقوم ppp_release_channel() بتحريره باستخدام kfree() عادي: close(data socket) -> pppol2tp_release() -> pppox_unbind_sock() -> ppp_unregister_channel() -> ppp_release_channel() -> kfree(pch) بالنسبة لقناة مرتبطة (PPPIOCGCHAN) ولكنها غير مرفقة بوحدة ppp (بدون PPPIOCCONNECT، pch->ppp == NULL) وغير موصولة بجسر، يتخطى التفكيك كلاً من synchronize_net() الخاصة بـ ppp_disconnect_channel() و synchronize_rcu() الخاصة بـ ppp_unbridge_channels()، لذا فإن kfree() لا يخضع لأي فترة سماح. إن rcu_read_lock() في pppol2tp_recv() لا يحمي من kfree() عادي، لذا فإن ppp_input() قيد التنفيذ على وحدة معالجة مركزية واحدة يمكنها فك الإشارة إلى القناة التي تم تحريرها للتو بواسطة close() على وحدة معالجة مركزية أخرى. يمكن لمستخدم غير مميز الوصول إلى هذا الخطأ. قم بتأجيل تحرير القناة إلى استدعاء RCU عبر call_rcu() بحيث تقوم فترة السماح باحتواء أي ppp_input() قيد التنفيذ. مسارات التفكيك وفصل الجسر تقوم بالفعل بالاحتواء عبر synchronize_net()/synchronize_rcu()؛ تقوم call_rcu() بنفس الأمر هنا دون تعطيل مسار close().

• CVE-2026-68398استغلال

  CVE-2026-68398 ثغرة استخدام بعد التحرير (use-after-free) في Ubuntu PPPoL2TP لتصعيد الامتيازات محليًا