Homepage

Missing Synchronization The advisory has been revoked - it doesn't affect any version of package rv  (opens in a new tab)

Threat Intelligence

EPSS
0.1% (1st percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications
  • Snyk IDSNYK-RHEL10-RV-17590291
  • published27 Jun 2026
  • disclosed25 Jun 2026
Report a new vulnerability Found a mistake?

Introduced: 25 Jun 2026

CVE-2026-53153  (opens in a new tab)
CWE-820  (opens in a new tab)

Amendment

The Red Hat security team deemed this advisory irrelevant for RHEL:10.

NVD Description

Note: Versions mentioned in the description apply only to the upstream rv package and not the rv package as distributed by RHEL.

In the Linux kernel, the following vulnerability has been resolved:

mm/list_lru: drain before clearing xarray entry on reparent

memcg_reparent_list_lrus() clears the dying memcg's xarray entry with xas_store(&xas, NULL) before reparenting its per-node lists into the parent. This opens a window where a concurrent list_lru_del() arriving for the dying memcg sees xa_load() == NULL, walks to the parent in lock_list_lru_of_memcg(), takes the parent's per-node lock, and calls list_del_init() on an item still physically linked on the dying memcg's list.

If another in-flight thread holds the dying memcg's per-node lock at the same moment (another list_lru_del, or a list_lru_walk_one running an isolate callback), both threads modify ->next/->prev pointers on the same physical list under different locks. Adjacent items can corrupt each other's links.

Fix it by reversing the order: reparent each per-node list and mark the child's list lru dead and then clear the xarray entry. Any concurrent list_lru op that finds the still-set xarray entry either takes the dying memcg's per-node lock (synchronizing with the drain) or sees LONG_MIN and walks to the parent, where the items now live.