Homepage

Multiple Locks of a Critical Resource The advisory has been revoked - it doesn't affect any version of package rv  (opens in a new tab)

Threat Intelligence

EPSS
0.22% (12th 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-CENTOS10-RV-20918638
  • published14 Oct 2026
  • disclosed17 Sept 2026
Report a new vulnerability Found a mistake?

Introduced: 17 Sep 2026

CVE-2026-90247  (opens in a new tab)
CWE-764  (opens in a new tab)

Amendment

The Centos security team deemed this advisory irrelevant for Centos:10.

NVD Description

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

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

bpf: Fix mmap_lock leak in irq_work path

stack_map_get_build_id_offset() introduced a per-CPU irq_work to defer mmap_read_unlock() from NMI context, and bpf_find_vma() later reused the same mmap_unlock_work. Both callers only check whether the work is busy before taking mmap_lock, so a nested caller can reuse the slot before the first caller queues it. Two read locks may then be acquired while only one deferred unlock runs, leaking a read lock and blocking exit_mmap().

Reserve the per-CPU slot before mmap_read_trylock(). Use the same wrapper in stackmap and bpf_find_vma() so both callers release the reservation on trylock failure. Keep rejecting the slot while the irq_work remains busy. Release it after the irq_work callback unlocks the mm.