{"id":100924,"date":"2021-08-05T22:22:35","date_gmt":"2021-08-05T20:22:36","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/kis-kuk-iz-google-prizval-modernizirovat-proczess-raboty-nad-oshibkami-v-yadre-linux"},"modified":"2026-02-08T16:56:03","modified_gmt":"2026-02-08T14:56:03","slug":"kis-kuk-iz-google-prizval-modernizirovat-proczess-raboty-nad-oshibkami-v-yadre-linux","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/news\/kis-kuk-iz-google-prizval-modernizirovat-proczess-raboty-nad-oshibkami-v-yadre-linux","title":{"rendered":"Kis Cook from Google has called for modernization of the bug fixing process in the Linux kernel.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Kees Cook, former lead system administrator of kernel.org and leader of the Ubuntu Security Team, now working at Google to ensure the security of Android and ChromeOS, expressed concerns about the current process of fixing bugs in the stable branches of the kernel. Approximately one hundred fixes are incorporated into the stable branches weekly, and after the window for accepting changes closes for the next release, this number approaches a thousand (maintainers hold back fixes until the window closes and then release the accumulated changes at once after forming '-rc1'), which is too much and requires significant effort to maintain products based on the Linux kernel.<\/p>\n
According to Kees, the process of handling bugs in the kernel does not receive adequate attention, and the kernel lacks at least 100 additional developers for coordinated work in this area. Core kernel developers regularly fix bugs, but there is no guarantee that these fixes will be backported to the kernel variants used by third-party vendors. Users of various products based on the Linux kernel also lack the means to track which bugs have been fixed and which kernel their devices are using. Ultimately, the manufacturers are responsible for the security of their products, but in the face of the very high intensity of fixes published in the stable branches of the kernel, they are confronted with the choice of whether to backport all fixes, selectively port the most critical ones, or ignore all fixes.<\/p>\n
<\/center>The optimal solution would be to transfer only the most critical fixes and vulnerabilities, but the main problem lies in pinpointing such issues from the overall stream. The majority of emerging problems result from the use of the C language, which requires great care when working with memory and pointers. The situation is further complicated by the fact that many potential vulnerability fixes are not assigned CVE identifiers or receive such identifiers some time after the fix is published. Under these conditions, manufacturers find it very difficult to separate secondary fixes from critical issues that impact security. Statistics show that over 40% of vulnerabilities are resolved before receiving a CVE, and on average, there is a three-month delay between the release of a fix and the assignment of a CVE (i.e., initially the fix is perceived as a regular bug, but only months later does it become clear that it concerned a vulnerability).<\/p>\n
As a result, without a separate branch for fixing vulnerabilities and lacking information about the security implications of specific issues, product manufacturers based on the Linux kernel are left with the continuous task of transferring all fixes from the latest stable branches. However, this work requires significant labor resources and faces resistance within companies due to the fear of introducing regressions that could disrupt normal product operation.<\/p>\n
It is worth noting that, according to Linus Torvalds, all bugs are important, and vulnerabilities should not be separated from other types of bugs and prioritized into a separate category. This perspective is explained by the fact that for an ordinary developer who does not specialize in security issues, the connection between a fix and a potential vulnerability is not obvious (for many fixes, only a separate audit can reveal that they relate to security). According to Linus, it is the role of security specialists within communities responsible for maintaining kernel packages in Linux distributions to identify potential vulnerabilities from the general stream of fixes.<\/p>\n
Kees Cook believes that the only solution to maintain kernel security while keeping long-term costs reasonable is for companies to transfer engineers, who are porting patches to local kernel builds, to a coordinated collaborative effort to maintain fixes and vulnerabilities in the main kernel (upstream). Currently, many manufacturers use outdated versions of the kernel in their products and backport patches on their own, which results in engineers at different companies duplicating each other's work to solve the same problem.<\/p>\n
For instance, if 10 companies, each with one engineer backporting the same patches, redirect these engineers to fix bugs in upstream, instead of porting one patch, they could fix 10 different bugs for the common good or participate in reviewing proposed changes to prevent the inclusion of erroneous code in the kernel. Resources could also be directed towards creating new tools for testing and code analysis, which would enable the early detection of recurring types of errors.<\/p>\n
Kees Cook also suggests making more active use of automated and fuzz testing directly during the kernel development process, applying continuous integration systems, and moving away from archaic email-based project management. Currently, effective testing is hindered by the fact that major testing processes are separated from development and occur only after releases are formed. Kees also recommended using languages that ensure better safety during development to reduce the number of errors. a high level of security<\/a>, such as Rust.<\/p>\n
![\"Kis](\"\/wp-content\/uploads\/2021\/08\/3e472a24f4fd9a6b434c706b3dfe3a35.png\")
<\/center>The optimal solution would be to transfer only the most critical fixes and vulnerabilities, but the main problem lies in pinpointing such issues from the overall stream. The majority of emerging problems result from the use of the C language, which requires great care when working with memory and pointers. The situation is further complicated by the fact that many potential vulnerability fixes are not assigned CVE identifiers or receive such identifiers some time after the fix is published. Under these conditions, manufacturers find it very difficult to separate secondary fixes from critical issues that impact security. Statistics show that over 40% of vulnerabilities are resolved before receiving a CVE, and on average, there is a three-month delay between the release of a fix and the assignment of a CVE (i.e., initially the fix is perceived as a regular bug, but only months later does it become clear that it concerned a vulnerability).<\/p>\n