Към съдържанието
Търсене

CVE-2026-64374: Linux, отказ на услуга

7.5

CVSS 3.1

Няма данни

Вероятност да бъде експлоатирана в следващите 30 дни (EPSS)

Няма потвърждение

Атакува се

Няма данни

Време до експлоатация

Атакува се по мрежата, без особени условия, без вход и без действие от потребителя.

CVE радар: още уязвимости от този вид

  • Експлоатация: няма данни за експлоатация
  • Атаката може да се автоматизира

Описание

Оригинално описание

In the Linux kernel, the following vulnerability has been resolved: sched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT RT migration is done aggressively. When a CPU schedules out a high priority RT task for a lower priority task, it will look to see if there's any RT tasks that are waiting to run on another CPU that is of higher priority than the task this CPU is about to run. If it finds one, it will pull that task over to the CPU and allow it to run there instead. Normally, this pulling is done by looking at the RT overloaded mask (rto) which contains all the CPUs in the scheduler domain with RT tasks that are waiting to run due to a higher priority RT task currently running on their CPU. The CPU that is about to schedule a lower priority task will grab the rq lock of the overloaded CPU and move the RT task from that CPU's runqueue to the local one and schedule the higher priority RT task. This caused issues when a lot of CPUs would schedule a lower priority task at the same time. They would all try to grab the same runqueue lock of the CPU with the overloaded RT tasks. Only the first CPU that got in will get that task. All the others would wait until they got the runqueue lock and see there's nothing to pull and do nothing. On systems with lots of CPUs, this caused a large latency (up to 500us) which is beyond what PREEMPT_RT is to allow. The solution to that was to create an RT_PUSH_IPI logic. When any CPU wanted to pull a task, instead of grabbing the runqueue lock of the overloaded CPU, it would start by sending an IPI to the overloaded CPU, and that IPI handler would have the CPU with the waiting RT task do a push instead. Then that handler would send an IPI to the next CPU with overloaded RT tasks, and so on. Note, after the first CPU starts this process, if another CPU wanted to do a pull, it would see that the process has already begun and would only increment a counter to have the IPIs continue again. The RT_PUSH_IPI solved the latency pro

Засегнати продукти

  • Linux Linux: b6366f048e0caff28af5335b7af2031266e1b06b преди b99f04ae3d200d2f8844aa29145bd18eccbeecde; b6366f048e0caff28af5335b7af2031266e1b06b преди d8312a56d9a162e3ec76476aa487e7d20bc602e9; b6366f048e0caff28af5335b7af2031266e1b06b преди 44aae426dbfd51286f7eb601cfa14bc32164812a; b6366f048e0caff28af5335b7af2031266e1b06b преди 860aaff72c8446fed5e576249e19952883a18885; b6366f048e0caff28af5335b7af2031266e1b06b преди 89237c8fc15d8016a194076e648ccb57d75e65ae; b6366f048e0caff28af5335b7af2031266e1b06b преди 4bd0da48fbc1dbef6774175129107fbbdd353e26; b6366f048e0caff28af5335b7af2031266e1b06b преди a18f80bf5359238c4f067d691b96af00286fdd89; b6366f048e0caff28af5335b7af2031266e1b06b преди dd29c017aed628076e915fe4cdfb5392fd4c5cab
  • Linux Linux: 4.1; преди 4.1; 5.10.261 до 5.10.*; 5.15.212 до 5.15.*; 6.1.178 до 6.1.*; 6.6.145 до 6.6.*; 6.12.96 до 6.12.*; 6.18.39 до 6.18.*; 7.1.4 до 7.1.*; от 7.2 нататък

Вид слабост

История

  • 25 юли 2026 Публикувано

Други уязвимости в Linux Linux

Първоизточници