Cloudanix VulnDB

CVE-2026-98435

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A memory-handling mistake in the Linux kernel's error-correction code for certain hardware could let a logged-in attacker crash the machine or take it over.

Exploitation
Local Privilege
Attacker needs
Local User
Complexity
Theoretical
Impact
Denial Of Service
Component
OS kernel
Class
Use After Free
Remediation
Patch
Effort
Medium
Patch risk
Low

What it actually does

The vulnerability is a use-after-free in the Linux kernel EDAC/altera driver caused by anchoring devres groups and managed IRQ requests to a short-lived embedded device structure instead of the long-lived parent device, so that resource teardown occurs at the wrong time.

Why it matters to the business

Systems using Altera-based EDAC hardware risk kernel memory corruption, crashes, or local privilege escalation, which can produce unplanned downtime or full host compromise on affected Linux deployments.

How an attack unfolds

An attacker with local access triggers the altr_portb_setup path so the devres group is released while references still exist, then reuses the freed memory to corrupt kernel structures and escalate privileges.

How to fix it

Apply the upstream kernel commit that anchors devres_open_group, devm_request_irq, and related calls to device->edac->dev inside altr_portb_setup; rebuild and boot the fixed kernel on all affected systems.

How to confirm the fix worked

Confirm the patch is present by inspecting the altr_portb_setup function for references to the parent edac->dev when managing devres groups and IRQ resources, then run regression tests on EDAC error injection.

Typical attack path

  1. Obtain local user access on a Linux system with the vulnerable EDAC/altera driver loaded
  2. Trigger device initialization or error-correction paths that call altr_portb_setup
  3. Force premature release of the devres group tied to the wrong device
  4. Reuse the dangling memory region to corrupt kernel data and execute arbitrary code

How to detect it

Search kernel logs and crash dumps for EDAC/altera or devres-related oops, warnings about mismatched device contexts in resource groups, and unexpected process terminations shortly after EDAC initialization.

What your security team should do

  • Prioritize kernel updates for any hosts exposing Altera EDAC hardware within the next maintenance window
  • Add kernel oops and EDAC driver messages to centralized logging for rapid anomaly detection
  • Review and restrict local user access on systems that load the altera_edac module until patches are deployed

The record

In the Linux kernel, the following vulnerability has been resolved: EDAC/altera: Use parent device for devres in altr_portb_setup() Anchor the devres group and the devm-managed IRQ requests in altr_portb_setup() to the actual parent device (device->edac->dev) instead of the embedded struct device inside the copied per-port altr_edac_device_dev. This keeps devres_open_group(), devm_request_irq(), devres_remove_group() and devres_release_group() all referring to the same long-lived device so the group and the resources allocated inside it are torn down together.

Affected packages

Ecosystem Package Introduced Fixed