{"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\/de\/blog\/news\/analiz-ispravleniya-oshibok-v-yadre-linux-v-srednem-oshibki-zamechayut-cherez-2-goda","title":{"rendered":"Die Analyse der Fehlerbehebung im Linux-Kernel \u2014 im Durchschnitt werden Fehler nach 2 Jahren bemerkt.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Die Ergebnisse der Studie zur Erkennungs- und Behebungszeit von Fehlern im Linux-Kernel wurden ver\u00f6ffentlicht. Die Daten stammen aus der Analyse von 125.000 Fehlern, die im Git-Repository mit dem Tag \u201eFixes:\u201c gekennzeichnet sind, welches auf den Commit verweist, in dem der Fehler aufgetreten ist. Die durchschnittliche Erkennungszeit f\u00fcr Fehler im Kernel betrug 2,1 Jahre. Betrachtet man nur die im Jahr 2025 behobenen Fehler, betrug dieser Wert 2,8 Jahre. <\/p>\n
30% der Fehler wurden von denselben Entwicklern behoben, die die Fehler verursacht haben. 56,9% der Fehler werden innerhalb eines Jahres behoben. 13,5% der Fehler blieben mehr als 5 Jahre unentdeckt (wenn man nur die im Jahr 2025 behobenen Fehler betrachtet, sind es 19,4%). Aufgrund der ungleichm\u00e4\u00dfigen Verteilung betrug die mediane Zeit, die ein Fehler im Kernel-Code besteht, 8 Monate f\u00fcr die Stichprobe aus dem Jahr 2005 und 1 Jahr f\u00fcr die im Jahr 2025 behobenen Fehler. Der am l\u00e4ngsten bestehende Fehler im Code war ein Puffer\u00fcberlauf in ethtool, der nach 20,7 Jahren behoben wurde.
<\/center> <\/p>\n
Die Dynamik der Fehlerekennung weicht deutlich vom Durchschnittswert in einigen Subsystemen ab, beispielsweise dauert die Identifizierung von Problemen im CAN-Bus-Treiber und im SCTP-Stack im Durchschnitt etwa 4 Jahre, im IPv4-Stack 3,6 Jahre, USB und TTY 3,5 Jahre, Netfilter und Netzwerk-Stack 2,9 Jahre, VM 1,8 Jahre, GPU 1,4 Jahre, BPF 1,1 Jahre.
<\/center> <\/p>\n
Die Erkennungszeit korreliert mit den Fehlerarten: Die durchschnittliche Erkennungszeit f\u00fcr Fehler im Zusammenhang mit Race Conditions betrug 5,1 Jahre, f\u00fcr Ganzzahl\u00fcberl\u00e4ufe 3,9 Jahre, f\u00fcr Zugriffe nach Freigabe von Speicher 3,2 Jahre, f\u00fcr Puffer\u00fcberl\u00e4ufe und Speicherlecks 3,1 Jahre, f\u00fcr Referenzz\u00e4hlungen 2,8 Jahre, und f\u00fcr das Dereferenzieren von Nullzeigern und Deadlocks 2,2 Jahre. <\/p>\n
In der erhaltenen Statistik l\u00e4sst sich auch der Einfluss neuer Werkzeuge zur automatisierten Fehlersuche, statischen Analyse und Code-Tests, wie Syzkaller, KASAN, KMSAN und KCSAN, erkennen. Beispielsweise wurden im Jahr 2010 keine Fehlerbehebungen verzeichnet, die im Laufe eines Jahres gefunden wurden. W\u00e4hrend im Jahr 2014 innerhalb eines Jahres 31% der Fehler identifiziert wurden, waren es im Jahr 2018 54% und im Jahr 2022 69% der Fehler. <\/p>\n
Die erhaltenen Statistiken wurden zur Erstellung des Machine-Learning-Modells VulnBERT verwendet, das die Vorhersage von Schwachstellen in Commits erm\u00f6glicht. Bei Tests an Commits aus dem Jahr 2024 betrug die Genauigkeit der Fehlerentdeckung 92,2 % bei einer Fehlalarmrate von 1,2 % (zum Vergleich: das zuvor verf\u00fcgbare Modell CodeBERT entdeckte 89,2 % der Probleme bei einer Fehlalarmrate von 48,1 %). \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
![\"Die](\"\/wp-content\/uploads\/2026\/01\/18910bd9fa4c34878e303160eb662f2a.png\")
<\/center> <\/p>\n![\"Die](\"\/wp-content\/uploads\/2026\/01\/d1059c4d97733e42698d5252931431d7.png\")
<\/center> <\/p>\n