CVE-2026-98203

What it actually does

The vulnerability permits invalid memory access in the soc_button_array input driver when btns_desc->package.count is zero, allowing dereference of elements[0] without bounds validation and resulting in kernel memory corruption.

Why it matters to the business

Affected Linux systems risk kernel instability or crashes triggered by specific hardware button configurations, leading to unplanned downtime and potential loss of availability on servers or embedded devices.

How an attack unfolds

An attacker with local access supplies or emulates an input device descriptor whose package.count is zero; the driver then indexes into elements[0] without a prior check, corrupting kernel memory or causing a panic. No named threat actors or ransomware campaigns are associated with this issue.

How to fix it

Apply the upstream fix that guards the elements[0] access with a count check. Rebuild and deploy a patched Linux kernel; reboot affected hosts after installation.

How to confirm the fix worked

Inspect the soc_button_array source for the added count != 0 guard before elements[0] access; run regression tests that supply zero-count descriptors and confirm absence of oops or panic.

Typical attack path

1. Obtain local execution on a system running an unpatched kernel
2. Trigger initialization of the soc_button_array driver with a zero-count button descriptor
3. Force the driver to evaluate btns_desc->package.elements[0]
4. Induce kernel memory corruption or denial of service

How to detect it

Review kernel logs for oops or panic entries referencing soc_button_array and package.count or elements access; correlate with recent input device initialization events.

What your security team should do

• Prioritize kernel updates on all Linux hosts within the next maintenance window
• Audit hardware that uses soc_button_array for button array descriptors
• Enable kernel panic logging and monitoring to detect related crashes
• Re-test after patching to confirm the count validation is active