{"id":153453,"date":"2026-01-08T11:11:55","date_gmt":"2026-01-08T09:11:56","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/analiz-ispravleniya-oshibok-v-yadre-linux-v-srednem-oshibki-zamechayut-cherez-2-goda"},"modified":"2026-01-08T11:11:55","modified_gmt":"2026-01-08T09:11:56","slug":"analiz-ispravleniya-oshibok-v-yadre-linux-v-srednem-oshibki-zamechayut-cherez-2-goda","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/news\/analiz-ispravleniya-oshibok-v-yadre-linux-v-srednem-oshibki-zamechayut-cherez-2-goda","title":{"rendered":"L'analisi della correzione degli errori nel kernel Linux \u2014 in media gli errori vengono notati dopo 2 anni","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Sono stati pubblicati i risultati di uno studio sul tempo di rilevamento e risoluzione degli errori nel codice del kernel Linux. I dati sono stati ottenuti analizzando la correzione di 125.000 errori contrassegnati nel repository Git con il tag \"Fixes:\", che fa riferimento al commit in cui \u00e8 emerso l'errore. Il tempo medio di rilevamento degli errori nel kernel \u00e8 stato di 2,1 anni. Considerando solo gli errori corretti nel 2025, questo indicatore \u00e8 salito a 2,8 anni. <\/p>\n
Il 30% degli errori \u00e8 stato corretto dagli stessi sviluppatori che li hanno introdotti. Il 56,9% degli errori viene risolto entro un anno. Il 13,5% degli errori \u00e8 rimasto inosservato per pi\u00f9 di 5 anni (se si considerano solo gli errori corretti nel 2025, la percentuale \u00e8 del 19,4%). A causa della distribuzione non uniforme, il tempo mediano di esistenza di un errore nel codice del kernel \u00e8 stato di 8 mesi per il campione dal 2005 e di 1 anno per gli errori corretti nel 2025. L'errore pi\u00f9 a lungo rimasto nel codice \u00e8 stato un overflow del buffer in ethtool, risolto dopo 20,7 anni.
<\/center> <\/p>\n
La dinamica del rilevamento degli errori differisce significativamente dalla media per alcune sottosistemi, ad esempio, nel driver del bus CAN e nello stack SCTP, il rilevamento dei problemi richiede in media circa 4 anni, nello stack IPv4 \u00e8 di 3,6 anni, USB e TTY 3,5 anni, Netfilter e stack di rete 2,9 anni, VM 1,8 anni, GPU 1,4 anni, BPF 1,1 anno.
<\/center> <\/p>\n
Il tempo di rilevamento \u00e8 correlato ai tipi di errori: il tempo medio di rilevamento per errori legati a condizioni di gara \u00e8 stato di 5,1 anni, per overflow di interi 3,9 anni, per accesso dopo aver liberato la memoria 3,2 anni, per overflow di buffer e perdite di memoria 3,1 anni, per conteggio dei riferimenti 2,8 anni, per dereferenziazione di puntatori nulli e deadlocks 2,2 anni. <\/p>\n
Nelle statistiche ottenute emerge anche l'influenza dell'implementazione di nuovi strumenti per la ricerca automatizzata di errori, analisi statica e testing del codice, come Syzkaller, KASAN, KMSAN e KCSAN. Ad esempio, nel 2010 non sono state registrate correzioni di errori trovati nel corso dell'anno. Nel 2014, il 31% degli errori \u00e8 stato identificato in un anno, nel 2018 il 54% e nel 2022 il 69% degli errori. <\/p>\n
Le statistiche ottenute sono state utilizzate per creare il modello di machine learning VulnBERT, che permette di prevedere la presenza di vulnerabilit\u00e0 nei commit. Durante i test sui commit del 2024, la precisione nella rilevazione degli errori \u00e8 stata del 92,2% con un tasso di falsi positivi dell'1,2% (a titolo di confronto, il modello CodeBERT precedentemente disponibile rilevava l'89,2% dei problemi con un tasso di falsi positivi del 48,1%). \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
![\"L'analisi](\"\/wp-content\/uploads\/2026\/01\/18910bd9fa4c34878e303160eb662f2a.png\")
<\/center> <\/p>\n![\"L'analisi](\"\/wp-content\/uploads\/2026\/01\/d1059c4d97733e42698d5252931431d7.png\")
<\/center> <\/p>\n