CVE-2026-43392 Affecting kernel-uek-modules-wireless package, versions <0:6.12.0-204.92.4.2.el9uek


Severity

Recommended
high

Based on Oracle Linux security rating.

Threat Intelligence

EPSS
0.13% (3rd 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-ORACLE9-KERNELUEKMODULESWIRELESS-17867836
  • published6 Jul 2026
  • disclosed8 May 2026

Introduced: 8 May 2026

CVE-2026-43392  (opens in a new tab)

How to fix?

Upgrade Oracle:9 kernel-uek-modules-wireless to version 0:6.12.0-204.92.4.2.el9uek or higher.
This issue was patched in ELSA-2026-50372.

NVD Description

Note: Versions mentioned in the description apply only to the upstream kernel-uek-modules-wireless package and not the kernel-uek-modules-wireless package as distributed by Oracle. See How to fix? for Oracle:9 relevant fixed versions and status.

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

sched_ext: Fix starvation of scx_enable() under fair-class saturation

During scx_enable(), the READY -> ENABLED task switching loop changes the calling thread's sched_class from fair to ext. Since fair has higher priority than ext, saturating fair-class workloads can indefinitely starve the enable thread, hanging the system. This was introduced when the enable path switched from preempt_disable() to scx_bypass() which doesn't protect against fair-class starvation. Note that the original preempt_disable() protection wasn't complete either - in partial switch modes, the calling thread could still be starved after preempt_enable() as it may have been switched to ext class.

Fix it by offloading the enable body to a dedicated system-wide RT (SCHED_FIFO) kthread which cannot be starved by either fair or ext class tasks. scx_enable() lazily creates the kthread on first use and passes the ops pointer through a struct scx_enable_cmd containing the kthread_work, then synchronously waits for completion.

The workfn runs on a different kthread from sch->helper (which runs disable_work), so it can safely flush disable_work on the error path without deadlock.

CVSS Base Scores

version 3.1