CVE-2026-98302

Linux nüvəsində aşağıdakı zəiflik aradan qaldırılıb: net: fddi: skfp: interfeys bağlı olduqda MAC ünvanının təyin edilməsi zamanı NULL deref xətasının düzəldilməsi skfp_ctl_set_mac_address() funksiyası netif_running() yoxlamasını aparmadan şərtsiz olaraq ResetAdapter() funksiyasını çağırır. ResetAdapter() əvvəlcə smc->hw.hw_state dəyişənini STOPPED olaraq təyin edən card_stop() funksiyasını, daha sonra isə iki ötürmə növbəsini gəzən mac_drv_clear_tx_queue() funksiyasını çağırır: for (i = QUEUE_S; i <= QUEUE_A0; i++) { queue = smc->hw.fp.tx[i] ; ... t = queue->tx_curr_get ; smc->hw.fp.tx[] yalnız init_tx() tərəfindən doldurulur və bu funksiya skfp_open() -> init_smt() -> init_fddi_driver() -> init_fplus() -> init_mac() -> init_tx() ardıcıllığı ilə çağırılır. Özəl sahə alloc_fddidev() tərəfindən ayrılır və sıfırlanır, buna görə də heç vaxt aktivləşdirilməmiş interfeysdə hər iki növbə göstəricisi (pointer) hələ də NULL olur. mac_drv_clear_tx_queue() funksiyasının yuxarı hissəsindəki hw_state testi bunu tutmur, çünki card_stop() yeni saja STOPPED təyin etmişdir; funksiya dövrəyə daxil olur və NULL-u dereference edir. ResetAdapter() özü init_smt() funksiyasını çağırsa da, bunu yalnız növbələr təmizləndikdən sonra edir. Beləliklə, bağlı interfeysdə MAC ünvanının təyin edilməsi sistem çökməsinə (oops) səbəb olur: ip link set dev fddi0 address 02:00:00:00:00:01 BUG: KASAN: null-ptr-deref in mac_drv_clear_tx_queue+0x68/0x2c0 [skfp] Read of size 8 at addr 0000000000000010 by task ip/302 Call Trace: <TASK> mac_drv_clear_tx_queue+0x68/0x2c0 [skfp 6c01d4bab63c36978bd0a7d7e90837adb44cc37b] ResetAdapter+0x29/0x100 [skfp 6c01d4bab63c36978bd0a7d7e90837adb44cc37b] skfp_ctl_set_mac_address+0x57/0x80 [skfp 6c01d4bab63c36978bd0a7d7e90837adb44cc37b] netif_set_mac_address+0x1e4/0x2c0 do_setlink+0x684/0x2680 </TASK> 64-bit sistemdə 0x10 ünvanı struct s_smt_tx_queue strukturundakı üçüncü göstərici olan tx_curr_get-in ofsetidir. ResetAdapter() tərəfindən dərhal sonra çağırılan mac_drv_clear_rx_queue() funksiyası eyni effektiv olmayan hw_state testi altında smc->hw.fp.rx[QUEUE_R1]-i eyni şəkildə dereference edir; sadəcə ötürmə növbəsi daha əvvəl çökür. Hər ikisi aşağıdakı mühafizə mexanizmi ilə təmin edilir. İnterfeys bağlı olduqda adapterin sıfırlanmasının qarşısı alınır. dev_addr_set() şərtsiz saxlanılıb, beləliklə yeni ünvan hələ də dev->dev_addr-da qeyd olunur. Adapterin burada sıfırlanmaması ilə heç nə itirilmir: skfp_open() hər açılışda zavod ünvanını qəsdən yenidən oxuyur: read_address(smc, NULL); eth_hw_addr_set(dev, smc->hw.fddi_canon_addr.a); və onun üzərindəki şərh bildirir ki, bu, məhz bağlama/açma dövrü boyunca belə bir ünvan dəyişikliyini ləğv etmək üçün edilir. İnterfeys bağlı olduğu halda təyin edilmiş ünvan bu dəyişiklikdən əvvəl də növbəti açılış zamanı qala bilməzdi, ona görə də mühafizə mexanizmi işlək davranışları dəyişmir. ndo_set_mac_address()-in aparat tərəfinin netif_running() ilə qorunması standart təcrübədir; skge_set_mac_address() bunu 2eb3e621c4e0 ("skge: set mac address bonding fix") commit-indən bəri həyata keçirir. Növbələri NULL-a yoxlamaqdansa, sıfırlama prosesinin bütövlüklə qorunması drayverin digər hissələrinin gözləntisinə də uyğundur. Əvvəlki açma/bağlama əməliyyatından sonra növbə göstəriciləri köhnəlmiş olsa da, NULL olmadığından sistem çökmür, lakin ResetAdapter() skfp_close() artıq free_irq() çağırmış olduğu halda smt_online() və STI_FBI() ("Enable Board Interrupts") funksiyalarını çağırmağa davam edir - adapter heç bir handler quraşdırılmadan yenidən onlayn vəziyyətə gətirilərdi. ResetAdapter()-in yeganə digər çağırıcısı skfp_interrupt() funksiyasıdır ki, o da qurğu açıq olduğu müddətdə işləyir. KASAN aktiv edilmiş 7.0.0 nüvəsi altında emulyasiya edilmiş SysKonnect FDDI adapterinə qarşı avtomatlaşdırılmış drayver testi vasitəsilə aşkar edilmişdir. Bunun tetiklenmesi üçün CAP_NET_ADMIN imtiyazı tələb olunur.