Skip to content
VulniPulse
Advisory severityMedium5.5Vendor: LowRed Hat Linux

Medium [CVE-2026-98087] sched/rt,dl: Skip migrate-disabled tasks when picking a push candidate

This medium-severity Red Hat Linux advisory covers CVE-2026-98087 affecting Red Hat Enterprise Linux 8, Red Hat Enterprise Linux 9, Red Hat OpenShift Container Platform 4.

Aggregated and source-linked by VulniPulse. Data sources, validation and limitations.

CVE-2026-98087 Source published Source updated

VulniPulse record published

Affected products & platforms
Red Hat LinuxLinux Kernel
Open source advisory

Android app · Google Play

Monitor future Red Hat Linux CVEs from your phone.

Choose a whole vendor or a precise platform, then receive matching security advisories by phone notification, email, or both. Coverage follows 32 official vendor sources and 160+ reviewed platform categories.

Matching phone alertsOptional email delivery

Summary

In the Linux kernel, the following vulnerability has been resolved: sched/rt,dl: Skip migrate-disabled tasks when picking a push candidate A migrate_disable()'d RT task cannot be moved to another CPU, but the scheduler still keeps such a task on that CPU's pushable list (rq->rt.pushable_tasks) and still marks the runqueue RT-overloaded (rq->rt.overloaded = 1).

So the RT balancer keeps treating this CPU as having a task to move away, and keeps trying to move the task, but the push can never succeed. When the head is pinned, push_rt_task() does not give up either.

It falls back to pushing rq->curr instead, using the per-CPU stopper, as added by commit a7c81556ec4d ("sched: Fix migrate_disable() vs rt/dl balancing"). The CPU spends tens of milliseconds in this retry loop.

The core is isolated for real-time work, but during the loop nearly half of its time is consumed by pushes that cannot succeed. An ftrace capture of the affected CPU, with sched_switch enabled and commit 94894c9c477e ("sched/rt: Skip currently executing CPU in rto_next_cpu()") applied, shows where the CPU time went.

Two SCHED_FIFO tasks at equal priority shared the CPU, taskA migrate_disable()'d and queued, taskB as rq->curr. In one 89 ms window, taskB got only 52 ms of CPU.

The other 37 ms went to the stopper thread.

Affected versions

No affected-version range was extracted from the source record. The vendor advisory is authoritative — check it before change work.

Official advisory · medium-confidence parse· fetched 5 hours ago·verify at source

Fixed versions

No fixed release is recorded yet. That does not prove no patch exists — confirm against the vendor advisory.

Official advisory · medium-confidence parse· fetched 5 hours ago·verify at source

Mitigation

The source record does not include mitigation steps. That is not a statement that no fix exists — read the vendor advisory below for the authoritative guidance.

Official advisory · medium-confidence parse· fetched 5 hours ago·verify at source

Discussion(0)

No comments yet. Share field notes, upgrade gotchas, or questions — verify against the vendor advisory before acting on community advice.

Sign in to join the discussion.