CVE-2026-99281

Naməlum

Təsvir

Linux kernel-də aşağıdakı zəiflik aradan qaldırılıb: tun: Sahibsiz cihazla əlaqə yaratmaq üçün CAP_NET_ADMIN tələb olunur İyirmi il əvvəl ca6bb5d7ab22 ("[NET]: Require CAP_NET_ADMIN to create tuntap devices.") commit-i ilə tuntap cihazının yaradılması üçün CAP_NET_ADMIN tələbi tətbiq edilmişdi. Məqsəd /dev/net/tun üzərindəki icazələrin 0666-ya qədər yumşaldılmasına şərait yaratmaq və beləliklə, TUNSETOWNER ilə təyin edilmiş tun cihazlarının sahiblərinin həmin cihazları açıb istifadə edə bilməsini təmin etmək idi. Həmin vaxt nəzərdən qaçan məqam odur ki, heç bir sahibi olmayan daimi cihazlar artıq faktiki olaraft hər kəs tərəfindən istifadə edilə bildiyi üçün, cihaz düyününü (device node) aça bilən hər kəs həmin cihazlara qoşula bilirdi. Hətta o zaman, açmaq üçün CAP_NET_ADMIN tələb olunacağı yanlış fərziyyəsinə əsaslanaraq, açıq şəkildə sahibi təyin edilməmiş daimi cihazlardan istifadə etmək ciddi bir userspace xətası sayılmırdı. Netdevice-ın yaradılması/konfiqurasiyası ilə paketləri ona ötürən prosesi ayırmaq məntiqli olan hallar mövcuddur. Bundan bir il sonra 8c644623fe7e ("[NET]: Allow group ownership of TUN/TAP devices.") commit-i ilə TUNSETGROUP əlavə edildi. Commit mesajında qeyd olunmuşdu ki, həm uid, həm də gid təyin edilibsə, hər ikisi uyğun gəlməlidir (özlüyündə qəribə seçimdir) — lakin hər ikisinin təyin edilmədiyi halda heç bir icazənin tələb olunmadığı qeyd edilməmişdi. Sonra 2012-ci ildə c8d68e6be1c3 ("tuntap: multiqueue support") commit-i yeni növbələrin (queues) cihaz yaradıldığı andan etibarən ona qoşulmasına icazə verdi və userspace üçün yaradılma ilə sonrakı TUNSET{OWNER,GROUP} arasındakı yarış vəziyyətini (race condition) bağlamağın yolu qalmadı. 2024-cü ildə 3ca459eaba1bf ("tun: fix group permission check") commit-i vəziyyəti daha məntiqli etməyə çalışdı: standart POSIX icazələrinə uyğun olaraq yalnız istifadəçinin *və ya* qrupun uyğun gəlməsini tələb etdi və həm istifadəçi, həm də qrup girişi təsdiqləmədikdə CAP_NET_ADMIN tələb etdi (lakin CAP_NET_ADMIN yoxlamasını birinci yerləşdirdiyi üçün, imkan istifadə edilmədiyi halda belə səhvən istifadə edildiyini bildirirdi). Bu düzəliş, selinux test dəstində regressiyaya səbəb olduğu iddia edildiyi üçün a70c7b3cbc06 ("tun: revert fix group permission check") commit-i ilə geri qaytarıldı. Həmin test, istifadəçi, qrup və ya CAP_NET_ADMIN tərəfindən təsdiqlənmədikdə belə qoşulmanı uğurlu gözləyirdi: https://lore.kernel.org/netdev/CAFqZXNtkCBT4f+PwyVRmQGoT3p1eVa01fCG_aNtpt6dakXncUg@mail.gmail.com/ Biz UAPI-ni pozmamalıyıq. Lakin təhlükəsizlik boşluğunu qəsdən sınağa çəkən selinux test keysini qorunmalı olan UAPI kimi dəyərləndirməliyik. Bu məqsədlə, mən bunu selinux-testsuite b2f894f0016b ("tests/tun_tap: set an owner on the device for the relabel tests") commit-i ilə düzəltdim. Beləliklə: sahibi və ya qrupu təyin edilməmiş cihazlarda CAP_NET_ADMIN yoxlamasının olmaması problemi aradan qaldırılır, eyni zamanda qəribə tun sahiblik modeli olduğu kimi saxlanılır (hər ikisi təyin edilibsə, həm istifadəçi, həm də qrup uyğun gəlməlidir). Əgər kimsə sonuncunu da düzəltmək istəyirsə (ki, bu, əvvəlki cəhdin geri qaytarılmasının əsl səbəbi deyildi), bunu ayrıca edə bilər. Mövcud cihaza qoşulmaya yalnız sahibi və/və ya qrupu təyin edildikdə və çağırıcı təyin edilmiş bütün şərtlərə uyğun gəldikdə, yaxud çağırıcının CAP_NET_ADMIN imkanı olduqda icazə verilir. Yeganə davranış dəyişikliyi budur ki, sahibi və ya qrupu olmayan cihaz artıq qoşulmaq üçün CAP_NET_ADMIN tələb edir — bu, məhz bağlamaq istədiyimiz boşluqdur. Və bu dəfə CAP_NET_ADMIN yoxlaması düzgün yerə yerləşdirildi.

CiddilikNaməlum
CVSS—
İstismar ehtimalı—
MəhsulLinux
Dərc7 noy 2026
İlk görülmə7 noy 2026

Necə düzəltmək olar

Yeniləyin
  • Linux Linux2f92c0286cfd58bff9d6d54c01a771073d5eb775, e53d1cf05da8ea58a5743b7ce5894fb51b0b9700, ffdf678dd16610e3f006dac904bd37c09684673c və ya daha yeni versiya

Təsirlənən məhsullar

MəhsulTəsirlənən versiyalarDüzəldildiyi versiya
Linux Linuxca6bb5d7ab22ac79f608fe6cbc6b12de6a5a19f0 ≤ v < 2f92c0286cfd58bff9d6d54c01a771073d5eb775, ca6bb5d7ab22ac79f608fe6cbc6b12de6a5a19f0 ≤ v < e53d1cf05da8ea58a5743b7ce5894fb51b0b9700, ca6bb5d7ab22ac79f608fe6cbc6b12de6a5a19f0 ≤ v < ffdf678dd16610e3f006dac904bd37c09684673c, 2.6.182f92c0286cfd58bff9d6d54c01a771073d5eb775, e53d1cf05da8ea58a5743b7ce5894fb51b0b9700, ffdf678dd16610e3f006dac904bd37c09684673c

Versiyanızı yoxlayın

Məhsulu seçin və istifadə etdiyiniz versiyanı yazın; versiyanın təsirlənən aralıqda olub-olmadığını görün.

Intelligence 360 paketində

Attack Surface Management

Domenlərinizə bağlı aktivləri, onlarda işləyən texnologiyaları və məlum zəiflikləri bir siyahıda görün.