Use of a Non-reentrant Function in a Concurrent Context Affecting kernel-rt package, versions *
Threat Intelligence
The probability is the direct output of the EPSS model, and conveys an overall sense of the threat of exploitation in the wild. The percentile measures the EPSS probability relative to all known EPSS scores. Note: This data is updated daily, relying on the latest available EPSS model version. Check out the EPSS documentation for more details.
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-KERNELRT-18954945
- published19 Aug 2026
- disclosed15 Aug 2026
Introduced: 15 Aug 2026
NewCVE-2026-72063 (opens in a new tab)How to fix?
There is no fixed version for Centos:10 kernel-rt.
NVD Description
Note: Versions mentioned in the description apply only to the upstream kernel-rt package and not the kernel-rt package as distributed by Centos.
See How to fix? for Centos:10 relevant fixed versions and status.
In the Linux kernel, the following vulnerability has been resolved:
gpio: tegra: do not call pinctrl for GPIO direction
tegra_gpio_direction_input() and tegra_gpio_direction_output() already program the GPIO controller direction registers directly. The additional pinctrl_gpio_direction_input/output() calls do not add a Tegra pinctrl operation, because the Tegra pinmux ops provide GPIO request/free handling but no gpio_set_direction hook.
The extra call still enters the pinctrl core and takes pctldev->mutex. Shared GPIO users can call the direction path while holding their per-line spinlock, so this otherwise redundant pinctrl direction call can sleep in an atomic context.
This was found by our static analysis tool and then confirmed by manual review of tegra_gpio_probe(), the Tegra GPIO direction callbacks and the Tegra pinctrl ops. The reviewed path has a default non-sleeping struct gpio_chip while the direction callback still enters the pinctrl mutex path.
A directed runtime validation kept the same non-sleeping chip registration and drove:
gpio_shared_proxy_direction_output() gpiod_direction_output_raw_commit() tegra_gpio_direction_output() pinctrl_gpio_direction_output()
Lockdep reported a sleep-in-atomic warning with the shared GPIO spinlock held and pinctrl_get_device_gpio_range() plus tegra_gpio_direction_output() on the stack.
Do not mark the whole chip as can_sleep to paper over this: can_sleep describes whether get()/set() may sleep, and Tegra value access is MMIO. Remove the redundant pinctrl direction calls and keep pinctrl involvement in the existing request/free path.
References
- https://bugzilla.redhat.com/show_bug.cgi?id=2516434
- https://access.redhat.com/security/cve/CVE-2026-72063
- https://git.kernel.org/stable/c/628c63f96f4564fa145f602af2d41daf9532201f
- https://git.kernel.org/stable/c/ac761e66708d51dac35c4c7f1891ea991dc788f0
- https://git.kernel.org/stable/c/cd17c5a1d9f186b57e9e2949be427803b7110a5c
- https://git.kernel.org/stable/c/d3e91a95b2b0fc6336dbf3ec90d831a1654d2720
- https://git.kernel.org/stable/c/e57a4845b0da60a7b9f052160878097826320954