CVE-2026-46193 in Linux
الملخص
بحسب VulDB • 02/06/2026
في نواة لينكس، تم حل الثغرة التالية:
xfrm: ah: أخذ البتات العليا لـ ESN في الاعتبار في الاستدعاءات غير المتزامنة (async callbacks)
يخصص AH تخطيط المصادقة/ICV المؤقت بشكل مختلف عند تمكين ESN: حيث يضيف إعداد ahash غير المتزامن (async) فتحة seqhi بحجم 4 بايت قبل منطقة ICV أو auth_data، لكن استدعاءات إكمال العمليات غير المتزامنة (async completion callbacks) لا تزال تعيد بناء التخطيط المؤقت وكأن seqhi غير موجود.
مع اختيار تنفيذ AH غير متزامن (async)، يؤدي ذلك إلى قيام AH بنسخ أو مقارنة بايتات خاطئة في كل من مساري IPv4 وIPv6. في إعادة إنتاج المشكلة باستخدام UML على AH لـ IPv4 مع ESN و forced async hmac(sha1)، يفشل ping مع فقدان 100% من الحزم، وتظهر سجلات الاستدعاءات انحرافاً قبل الإصلاح:
ah4 output_done: esn=1 err=0 icv_off=20 expected_off=24 ah4 input_done: esn=1 auth_off=20 expected_auth_off=24 icv_off=32 expected_icv_off=36
إعادة بناء التخطيط من جانب الاستدعاءات (callback-side) بنفس الطريقة التي بنى بها مسار الإعداد (setup path) تخطيطه، وذلك بتخطي فتحة ESN seqhi قبل تحديد موقع auth_data أو ICV المحفوظين. ووفقاً لـ RFC 4302، تشارك البتات العليا 32 بت من ESN في حساب AH ICV، لذا يجب أن تأخذ استدعاءات العمليات غير المتزامنة (async callbacks) في الاعتبار فتحة seqhi.
بعد الإصلاح، تظهر إعادة إنتاج المشكلة نفسها باستخدام UML على AH+ESN+forced-async-hmac(sha1) لـ IPv4 الإزاحة المصححة (ah4 output_done: esn=1 err=0 icv_off=24 expected_off=24) وينجح ping؛ كما أن net/ipv4/ah4.o و net/ipv6/ah6.o تُبنى بنظافة عند W=1. لم يتم اختبار AH+ESN لـ IPv6 أثناء التشغيل، ولم يتم اختبار التغيير ضد محرك AH عتادي غير متزامن (async hardware AH engine) حقيقي.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.