Cloudanix VulnDB

CVE-2026-98593

None

CVSS

—

EPSS

0.2%

Published

Oct 18, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A programming mistake in the Linux kernel on IBM mainframe systems can cause crashes if certain debug features fail during setup and are later accessed.

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

What it actually does

NULL pointer dereference in debug_info_copy() on s390 when an area registered via debug_register_static() fails and leaves bounds intact while clearing pages and entries, allowing subsequent copy operations via view file open or debug_dump() to dereference NULL pointers.

Why it matters to the business

Potential kernel panic or crash on IBM Z mainframe systems running Linux, leading to service disruption or denial of service in environments relying on kernel debug facilities.

How an attack unfolds

An attacker or local process triggers failure of debug_register_static() to leave an area in a partially initialized state, then invokes a copy operation on that area through file access or dump functions, causing the kernel to dereference NULL pointers and crash.

How to fix it

Apply the upstream kernel patch that adds a check to skip the copy loop when the source area has no registered areas; update to a Linux kernel version containing the fix for s390 debug code.

How to confirm the fix worked

Verify kernel source contains the updated debug_info_copy() logic that checks for zero areas before copying; test by attempting debug_register_static() failure followed by copy operations to confirm no crash occurs.

Typical attack path

  1. Trigger failure condition in debug_register_static() to clear area data structures while leaving bounds unchanged
  2. Perform an operation that calls debug_info_copy() such as opening a debug view file or invoking debug_dump()
  3. Kernel dereferences NULL pointers in the copy loop resulting in panic

How to detect it

Review kernel logs for oops or panic messages mentioning debug_info_copy or NULL dereference in s390 debug paths; examine audit or system logs for processes accessing debug view files after failed debug registrations.

What your security team should do

  • Prioritize kernel updates for s390 systems within standard maintenance windows given low EPSS
  • Monitor for kernel oops or panic logs related to debug_info_copy on affected architectures
  • Limit use of debug_register_static() in production code until patched kernels are deployed

The record

In the Linux kernel, the following vulnerability has been resolved: s390/debug: Fix NULL pointer dereference in debug_info_copy() When debug_register_static() fails, it clears areas, active_pages and active_entries but leaves the area bounds unchanged. Copying such an area, either by opening its view file or via debug_dump(), makes debug_info_copy() dereference the NULL pointers. Skip the copy loop when the source has no areas.

Affected packages

Ecosystem Package Introduced Fixed