Skip to content
VulniPulse
Advisory severityMedium5.5Red Hat Linux

Medium [CVE-2026-52977] Prevent lockup in requeue-PI during signal/ timeout wakeup

This medium-severity Red Hat Linux advisory covers CVE-2026-52977 affecting Red Hat Enterprise Linux 9, Red Hat Enterprise Linux 10, Red Hat package: kernel-rt.

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

CVE-2026-52977 Source published Source updated

VulniPulse record published Record updated

CVE-2026-52977
Affected products & platforms
Red Hat LinuxLinux Kernel
Open source advisory

Summary

In the Linux kernel, the following vulnerability has been resolved: futex: Prevent lockup in requeue-PI during signal/ timeout wakeup During wait-requeue-pi (task A) and requeue-PI (task B) the following race can happen: Task A Task B futex_wait_requeue_pi() futex_setup_timer() futex_do_wait() futex_requeue() CLASS(hb, hb1)(&key1); CLASS(hb, hb2)(&key2); *timeout* futex_requeue_pi_wakeup_sync() requeue_state = Q_REQUEUE_PI_IGNORE *blocks on hb->lock* futex_proxy_trylock_atomic() futex_requeue_pi_prepare() Q_REQUEUE_PI_IGNORE => -EAGAIN double_unlock_hb(hb1, hb2) *retry* Task B acquires both hb locks and attempts to acquire the PI-lock of the top most waiter (task B).

Task A is leaving early due to a signal/ timeout and started removing itself from the queue. It updates its requeue_state but can not remove it from the list because this requires the hb lock which is owned by task B.

Usually task A is able to swoop the lock after task B unlocked it. However if task B is of higher priority then task A may not be able to wake up in time and acquire the lock before task B gets it again.

Especially on a UP system where A is never scheduled. As a result task A blocks on the lock and task B busy loops, trying to make progress but live locks the system instead.

Tragic. This can be fixed by removing the top most waiter from the list in this case.

Is CVE-2026-52977 exploited?

No exploitation is reported in the sources VulniPulse tracks: CVE-2026-52977 is not in the CISA KEV catalog (checked ) and this advisory does not report exploitation. That is not proof the vulnerability cannot be exploited.

How do I fix CVE-2026-52977?

Upgrade to a fixed release named by Red Hat:

  • kernel-0:5.14.0-687.36.1.el9_8
  • RHSA-2026:51035

Confirm against the vendor advisory before you patch.

Affected versions

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

Official advisory · high-confidence parse· fetched 14 days ago·verify at source

Fixed versions
  • kernel-0:5.14.0-687.36.1.el9_8
  • RHSA-2026:51035

Official advisory · high-confidence parse· fetched 14 days ago·verify at source

Mitigation

Upgrade to a fixed release: kernel-0:5.14.0-687.36.1.el9_8, RHSA-2026:51035. That is the remediation for this advisory.

The vendor advisory may list interim mitigations or workarounds not captured here. Review it before change work.

Official advisory · high-confidence parse· fetched 14 days ago·verify at source

Get an email when Red Hat Linux Kernel publishes the next one.

See Red Hat Linux Kernel's last 90 days of advisories first. Then choose one product with live alerts free for life, or a free month of real-time alerts on everything with the severity, the fixed version and the vendor's link (card needed, then US$15/month; we email you before the first charge).

Alert me about Red Hat Linux Kernel
All Red Hat Linux advisories

iPhone and Android apps · New on the App Store

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 34 official vendor sources and 160+ reviewed platform categories.

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.