{"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\/novosti-interneta\/analiz-ispravleniya-oshibok-v-yadre-linux-v-srednem-oshibki-zamechayut-cherez-2-goda","title":{"rendered":"Analyse von Fehlerbehebungen im Linux-Kernel \u2014 im Durchschnitt werden Fehler nach 2 Jahren bemerkt.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Die Ergebnisse einer Untersuchung 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 und auf den Commit verweisen, in dem der Fehler aufgetreten ist. Die durchschnittliche Zeit zur Fehlererkennung im Kernel betrug 2,1 Jahre. Betrachtet man nur die Fehler, die im Jahr 2025 behoben wurden, liegt dieser Wert bei 2,8 Jahren. <\/p>\n
30 % der Fehler wurden von denselben Entwicklern behoben, die die Fehler auch verursacht haben. 56,9 % der Fehler werden innerhalb eines Jahres behoben. 13,5 % der Fehler blieben \u00fcber 5 Jahre unentdeckt (bei Betrachtung nur der im Jahr 2025 behobenen Fehler sind es 19,4 %). Aufgrund der ungleichm\u00e4\u00dfigen Verteilung betrug die mediane Dauer der Existenz eines Fehlers im Kernel-Code 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 im Code verweilende Fehler war ein Buffer-\u00dcberlauf in ethtool, der nach 20,7 Jahren behoben wurde.
<\/center> <\/p>\n
Die Fehlererkennung variiert erheblich von den Durchschnittswerten einiger Subsysteme. Zum Beispiel dauert die Problemerkennung im CAN-Bus-Treiber und im SCTP-Stack im Schnitt etwa 4 Jahre, im IPv4-Stack etwa 3,6 Jahre, bei USB und TTY etwa 3,5 Jahre, bei Netfilter und dem Netzwerkstack etwa 2,9 Jahre, bei VMs circa 1,8 Jahre, bei GPUs ungef\u00e4hr 1,4 Jahre und bei BPF etwa 1,1 Jahre.
<\/center> <\/p>\n
Die Erkennungszeit korreliert mit den Fehlerarten: Die durchschnittliche Zeit zur Entdeckung von Fehlern, die mit Race Conditions zusammenh\u00e4ngen, betrug 5,1 Jahre, bei Ganzzahl\u00fcberl\u00e4ufen 3,9 Jahre, beim Zugriff nach Freigabe des Speichers 3,2 Jahre, bei Puffer\u00fcberl\u00e4ufen und Speicherlecks 3,1 Jahre, beim Z\u00e4hlen von Referenzen 2,8 Jahre und beim Dereferenzieren von Nullzeigern und bei Deadlocks ungef\u00e4hr 2,2 Jahre. <\/p>\n
In den gesammelten Statistiken zeigt sich auch der Einfluss der Einf\u00fchrung neuer Tools zur automatisierten Fehlersuche, statischen Analyse und Code-Test, wie Syzkaller, KASAN, KMSAN und KCSAN. Zum Beispiel gab es im Jahr 2010 keine dokumentierten Fehlerbehebungen, die im Laufe des Jahres gefunden wurden. Im Jahr 2014 wurden hingegen 31 % der Fehler innerhalb eines Jahres identifiziert, im Jahr 2018 waren es 54 %, und im Jahr 2022 waren es bereits 69 % der Fehler. <\/p>\n
Die erhaltenen Statistiken wurden zur Erstellung des maschinellen Lernmodells VulnBERT verwendet, das die Vorhersage von Schwachstellen in Commits erm\u00f6glicht. Bei Tests an Commits aus dem Jahr 2024 lag die Fehlererkennungsgenauigkeit bei 92,2 % mit einer Fehlalarmquote von 1,2 % (zum Vergleich: Das zuvor verf\u00fcgbare Modell CodeBERT identifizierte 89,2 % der Probleme bei einer Fehlalarmquote von 48,1 %). \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
![\"Analyse](\"\/wp-content\/uploads\/2026\/01\/18910bd9fa4c34878e303160eb662f2a.png\")
<\/center> <\/p>\n![\"Analyse](\"\/wp-content\/uploads\/2026\/01\/d1059c4d97733e42698d5252931431d7.png\")
<\/center> <\/p>\n