{"id":170830,"date":"2026-05-16T18:24:39","date_gmt":"2026-05-16T16:24:39","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/model-ugroz-i-osobennosti-oczenki-uyazvimostej-v-yadre-linux"},"modified":"2026-05-16T18:24:39","modified_gmt":"2026-05-16T16:24:39","slug":"model-ugroz-i-osobennosti-oczenki-uyazvimostej-v-yadre-linux","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/news\/model-ugroz-i-osobennosti-oczenki-uyazvimostej-v-yadre-linux","title":{"rendered":"Threat Model and Vulnerability Assessment Features in the Linux Kernel","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Linus Torvalds has accepted a document into the kernel that regulates the process of handling security-related errors, defines the threat model, explains which errors in the kernel are considered vulnerabilities, and discusses actions with errors identified using AI. The document was prepared by Willy Tarreau, author of HAProxy and a long-time Linux kernel developer responsible for maintaining several stable kernel branches. It is based on agreements reached during discussions of recently discovered critical vulnerabilities in the kernel (1, 2, 3, 4), revealed prior to the publication of fixes, for which working exploits were immediately created thanks to AI. <\/p>\n
The majority of security-related errors are recommended to be handled publicly to attract the widest possible audience and find optimal solutions. Only urgent notifications about vulnerabilities that are easily exploitable, pose a threat to many users, and allow for privilege escalation or capabilities will be sent to a separate private mailing list. <\/p>\n
Vulnerabilities identified using AI assistants should always be discussed publicly, as such issues are often discovered simultaneously by several researchers. It is important not to disclose the exploit in the report \u2014 just mention that it is available and provide it privately upon request from the reviewer. <\/p>\n
The rules for submitting reports created with the help of AI assistants are described separately. Many such reports are submitted, and they occasionally help identify bugs in poorly reviewed parts of the code, but maintainers often ignore them due to low quality and inaccuracies. The main requirements for reports generated with AI assistance include: <\/p>\n
\n
Conciseness, without fluff, and stating the essence and important details at the very beginning.\n
Plain text only, without Markdown tags or decoration.\n
Understanding the threat model and specifying verifiable facts (for example, 'the flaw allows any user to obtain CAP_NET_ADMIN'), rather than theoretical musings and conjectures about the consequences of the vulnerability.\n
Before submitting the report, it is essential to thoroughly test the functionality of the exploit generated through AI and ensure the ability to reproduce the issue.\n
Leveraging AI for developing and testing a fix for the identified problem. <\/ul>\n
Statistics show that most error reports sent in the guise of vulnerability resolutions are not actually such and should be processed as regular errors. A threat model for the Linux kernel is described to differentiate vulnerabilities from regular errors. Among the potential violations that may be considered vulnerabilities are: <\/p>\n
\n
User-level isolation: file access is restricted to the owner only, process memory is inaccessible to other users, ptrace is prohibited for other users' processes, isolation of IPC and network communications.\n
Protection based on capabilities: without CAP_SYS_ADMIN, one cannot change kernel configurations, memory, or system state; without CAP_NET_ADMIN, one cannot change network settings or intercept traffic; without CAP_SYS_PTRACE, one cannot trace other users' processes.\n
User ID namespace (CONFIG_USER_NS) allows unprivileged users to create their isolated environments, which cannot affect the global namespace, such as changing the time, loading modules, or mounting block devices.\n
Debugging interfaces (\/proc\/kmsg, perf, debugfs), which can provide access to sensitive information, are available only after explicit access is granted by an administrator. <\/ul>\n
Capabilities that are not considered vulnerabilities: <\/p>\n
\n
Using outdated kernel branches.\n
Building with developer options or security-reducing options enabled (for example, CONFIG_NOMMU).\n
Setting unsafe sysctl configurations, command-line options, filesystem permissions, capabilities, or providing unprivileged users access to privileged interfaces (such as write access to procfs and debugfs).\n
Issues in functions intended solely for development and debugging of the kernel, such as LOCKDEP, KASAN, and FAULT_INJECTION, which are not meant to be included in production configurations.\n
Issues in drivers, modules, and subsystems located in the STAGING section or marked as experimental, unsafe, or non-functional.\n
Use of third-party kernel modules or unofficial kernel forks.\n
Requirement for excessive privileges, such as the need to perform actions with root rights or from a user with CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_SYS_RAWIO, and CAP_SYS_MODULE privileges.\n
Theoretical attacks requiring laboratory conditions, billions of attempts, emulation, or hardware modification, disproportionate costs, and unrealistic configurations (e.g., systems with tens of thousands of CPU cores).\n
Bypassing protection mechanisms (e.g., ASLR) without demonstrating an exploit. Lack of checks on arguments and return error codes that have no obvious consequences.\n
Random information leaks that are out of the attacker's control, such as residual data in error messages and leaks of kernel memory addresses\/pointers without a direct exploitability.\n
Errors when mounting corrupted disk images if the driver is not stated as suitable for use with untrusted media. Issues with disk images identified and resolved through the fsck utility.\n
Attacks requiring physical access to the hardware, modification of hardware, or connection of hardware devices, such as DMA attack boards and logic analyzers, if the system is not specifically configured to protect against such attacks (IOMMU).\n
Regressions with functionality and performance, fixable by adjusting rights and limits. <\/ul>\n