Cloudanix VulnDB

CVE-2026-93052

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A timing problem inside the Linux kernel's handling of certain hardware message queues could let programs read old uninitialized data and cause crashes or instability.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Moderate
Impact
Other
Component
OS kernel
Class
Race Condition
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The vulnerability is a missing memory barrier in bcm-vk message queue initialization: atomic_set of msgq_inited does not order stores of queue metadata, so a concurrent reader performing atomic_read can observe the flag set while still seeing stale or uninitialized queue fields.

Why it matters to the business

Systems relying on the bcm-vk driver may suffer kernel instability, incorrect hardware communication, or crashes when multiple threads access the message queue concurrently, increasing operational risk on affected Linux kernels.

How an attack unfolds

An attacker with local code execution triggers bcm_vk_sync_msgq to publish queue data and set the flag while simultaneously invoking bcm_vk_drv_access_ok; without acquire/release ordering the reader can dereference uninitialized queue pointers leading to denial of service or memory corruption.

How to fix it

Upgrade to a Linux kernel containing the commit that replaces atomic_set/atomic_read of msgq_inited with smp_store_release/smp_load_acquire and keeps the clear as atomic_set.

How to confirm the fix worked

Inspect the bcm-vk driver source for acquire/release annotations on msgq_inited; boot the patched kernel and confirm no change in functional behavior while exercising concurrent message-queue paths.

Typical attack path

  1. Obtain local execution on a system using the bcm-vk driver
  2. Create concurrent threads that race bcm_vk_sync_msgq against bcm_vk_drv_access_ok calls
  3. Trigger the window where msgq_inited is visible without ordered queue metadata
  4. Cause use-after-uninit or out-of-bounds access on the stale queue structures

How to detect it

Review kernel logs for bcm-vk related oops, warnings about invalid queue state, or unexpected driver resets; correlate with process activity that exercises the vk message queue.

What your security team should do

  • Identify hosts running kernels that include the bcm-vk driver
  • Schedule kernel updates to a release containing the memory-ordering fix
  • Add kernel message-queue error paths to existing monitoring until patches are deployed

The record

In the Linux kernel, the following vulnerability has been resolved: misc: bcm-vk: Use acquire/release for msgq_inited bcm_vk_sync_msgq() fills the message queue information and then sets msgq_inited. Readers call bcm_vk_drv_access_ok() before accessing the message queues and their cached queue information. atomic_set()/atomic_read() do not order those accesses. A reader can see msgq_inited set while still seeing stale queue information. Use release when publishing the initialized queues and acquire when checking the gate. Keep the clear in bcm_vk_blk_drv_access() as atomic_set(). It closes the gate and does not publish queue state to readers.

Affected packages

Ecosystem Package Introduced Fixed