Cloudanix VulnDB

CVE-2026-68375

None

CVSS

—

EPSS

0.2%

Published

Aug 10, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux network driver initialization can cause crashes or memory problems if setup fails partway through, which may let an attacker on the machine take control or shut the system down.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Theoretical
Impact
Denial Of Service
Component
OS kernel
Class
Memory Corruption
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Use-after-free or invalid pointer dereference in the bnxt_en auxiliary device release path when auxiliary_device_init() succeeds but subsequent allocations fail, leaving aux_priv->id, aux_priv->edev, edev->net, and edev->ulp_tbl unpopulated.

Why it matters to the business

Kernel panic or memory corruption during network device initialization on affected systems can cause system instability, denial of service, or potential local privilege escalation in environments using bnxt_en drivers.

How an attack unfolds

An attacker with local access triggers bnxt_aux_devices_init() and forces an allocation failure after auxiliary_device_init() but before full population of required fields; the error unwind invokes the release callback which dereferences or clears uninitialized state.

How to fix it

Apply the upstream fix that moves bnxt_en_dev and ULP table allocation before auxiliary_device_init() and handles init failures with direct frees; upgrade to a patched Linux kernel version containing this change.

How to confirm the fix worked

Inspect kernel source for the corrected bnxt_aux_devices_init() ordering, verify the patch commit is present, or confirm the running kernel is newer than the vulnerable version and test device attach under error-injection conditions.

Typical attack path

  1. Obtain local code execution on a system using bnxt_en
  2. Trigger auxiliary device initialization for the bnxt device
  3. Force a post-init allocation failure in bnxt_aux_devices_init()
  4. Allow the error path to call auxiliary_device_uninit() and the release callback
  5. Exploit resulting pointer dereference for corruption or crash

How to detect it

Review kernel logs for oops or panic messages referencing bnxt_aux_dev_release, auxiliary_device_uninit, or bnxt_en during device probe; look for unexpected auxiliary device failures in dmesg or journalctl around bnxt module load times.

What your security team should do

  • Prioritize kernel updates on all systems exposing bnxt_en devices
  • Monitor vendor advisories for distribution-specific backports
  • Enable kernel hardening features such as KASAN and lockdep during testing
  • Restrict unprivileged local access until patches are deployed

The record

In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Handle partially initialized auxiliary devices bnxt_aux_devices_init() calls auxiliary_device_init() before all fields used by bnxt_aux_dev_release() are initialized. After auxiliary_device_init() succeeds, later errors must unwind with auxiliary_device_uninit(), which invokes the release callback. The release callback assumes that aux_priv->id, aux_priv->edev, edev->net and edev->ulp_tbl are all populated. If allocation fails after auxiliary_device_init(), the release path can otherwise dereference or clear partially initialized state. Allocate and attach the bnxt_en_dev and ULP table before calling auxiliary_device_init(), so the release callback only sees a fully initialized auxiliary private object. If auxiliary_device_init() itself fails, free those allocations directly because device_initialize() has not run and the release callback will not be invoked. This issue was found by a static analysis checker and confirmed by manual source review.

Affected packages

Ecosystem Package Introduced Fixed