Skip to main content

Linux Kernel EUVDEUVD-2026-28563

| CVE-2026-43293 MEDIUM
2026-05-08 Linux GHSA-jr3h-fqrg-28f2
5.5
CVSS 3.1 · NVD
Share

Severity by source

NVD PRIMARY
5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
vuln.today AI
4.1 MEDIUM

Module removal requires CAP_SYS_MODULE (PR:H), and the race condition depends on precise timer-to-teardown timing (AC:H); no confidentiality or integrity impact.

3.1 AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:N/A:H
4.0 AV:L/AC:H/AT:P/PR:H/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
SUSE
MEDIUM
qualitative

Primary rating from NVD.

CVSS VectorNVD

Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

5
Analysis Generated
Jul 23, 2026 - 22:54 vuln.today
CVSS changed
May 14, 2026 - 19:52 NVD
5.5 (MEDIUM)
Patch available
May 08, 2026 - 14:02 EUVD
CVE Published
May 08, 2026 - 13:11 nvd
MEDIUM 5.5
CVE Published
May 08, 2026 - 13:11 nvd
UNKNOWN (no severity yet)

DescriptionCVE.org

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

media: chips-media: wave5: Fix kthread worker destruction in polling mode

Fix the cleanup order in polling mode (irq < 0) to prevent kernel warnings during module removal. Cancel the hrtimer before destroying the kthread worker to ensure work queues are empty.

In polling mode, the driver uses hrtimer to periodically trigger wave5_vpu_timer_callback() which queues work via kthread_queue_work(). The kthread_destroy_worker() function validates that both work queues are empty with WARN_ON(!list_empty(&worker->work_list)) and WARN_ON(!list_empty(&worker->delayed_work_list)).

The original code called kthread_destroy_worker() before hrtimer_cancel(), creating a race condition where the timer could fire during worker destruction and queue new work, triggering the WARN_ON.

This causes the following warning on every module unload in polling mode:

------------[ cut here ]------------ WARNING: CPU: 2 PID: 1034 at kernel/kthread.c:1430 kthread_destroy_worker+0x84/0x98 Modules linked in: wave5(-) rpmsg_ctrl rpmsg_char ... Call trace: kthread_destroy_worker+0x84/0x98 wave5_vpu_remove+0xc8/0xe0 [wave5] platform_remove+0x30/0x58 ... ---[ end trace 0000000000000000 ]---

AnalysisAI

Race condition in the chips-media wave5 VPU driver triggers kernel WARN_ON assertions during module removal when operating in polling mode, causing availability degradation on affected systems. The wave5 driver's cleanup sequence incorrectly called kthread_destroy_worker() before hrtimer_cancel(), allowing the hrtimer to fire mid-teardown and enqueue new work on a being-destroyed kthread worker, violating the empty-queue invariant enforced in kernel/kthread.c:1430. No public exploit exists and no active exploitation is confirmed; this is a low-EPSS (0.02%, 5th percentile) local stability issue affecting embedded media processing systems using chips-media wave5 hardware in polling mode.

Technical ContextAI

The chips-media wave5 is a VPU (Video Processing Unit) driver within the Linux kernel's media subsystem (drivers/media/platform/chips-media/wave5). In polling mode - activated when the device IRQ is unavailable (irq < 0) - the driver uses an hrtimer to periodically invoke wave5_vpu_timer_callback(), which submits work items to a kthread worker via kthread_queue_work(). The kernel's kthread_destroy_worker() (kernel/kthread.c:1430) enforces correctness by asserting via WARN_ON that both work_list and delayed_work_list are empty before proceeding with teardown. The root cause is a cleanup sequencing error consistent with CWE-459 (Incomplete Cleanup) and CWE-362 (Race Condition): the original code destroyed the worker before canceling the timer, leaving a window where the hrtimer could fire during destruction and enqueue new work. Affected CPE covers cpe:2.3:a:linux:linux:*, with the bug introduced at commit ed7276ed2fd02208bfca9f222ef1e7b2743d710d. The fix reverses the order: cancel hrtimer first, then destroy the kthread worker.

RemediationAI

The primary remediation is to upgrade the Linux kernel to a patched stable release: 6.12.75, 6.18.16, 6.19.6, or 7.0 and later, as confirmed by EUVD-2026-28563. The upstream fix commits are available at https://git.kernel.org/stable/c/156020e889edf4593870d926d3c4a6d06baac44a, https://git.kernel.org/stable/c/cc8071b1bac6568ea09d54be2d4f74dba80e17f8, https://git.kernel.org/stable/c/0c2e752688a0ee3b89993e6de6c496d863870c93, and https://git.kernel.org/stable/c/5a0c122e834b2f7f029526422c71be922960bf03. For systems where an immediate kernel upgrade is not feasible, two compensating controls apply: first, avoid dynamic loading and unloading of the wave5 module in environments where polling mode is active - keeping the module permanently loaded eliminates the teardown race, at the cost of losing the ability to hot-remove the driver; second, if the platform supports IRQ assignment for the wave5 device, configuring it to use interrupt-driven mode (irq >= 0) bypasses the polling code path entirely and avoids the vulnerable cleanup sequence, though this depends on hardware and firmware capabilities. Monitor Red Hat and SUSE security advisories for distribution-specific backport packages.

Vendor StatusVendor

SUSE

Severity: Medium
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise Desktop 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed
SUSE Linux Enterprise High Availability Extension 15 SP7 Fixed
SUSE Linux Enterprise High Performance Computing 15 SP7 Fixed

Share

EUVD-2026-28563 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy