CVE-2026-98248
NoneCVSS
—
EPSS
0.2%
Published
Oct 6, 2026
CISA due date
—
Cloudanix analysis
A bug in the Linux kernel on certain processors could let small data operations accidentally damage nearby memory, potentially crashing machines or allowing attackers to gain extra access.
- Exploitation
- Local Privilege
- Attacker needs
- Local User
- Complexity
- High
- Impact
- Data Tampering
- Component
- OS kernel
- Class
- Memory Corruption
- Remediation
- Patch
- Effort
- Medium
- Patch risk
- Low
What it actually does
Incorrect size suffix on LSE atomic instructions for 8-bit and 16-bit percpu operations causes the kernel to read and write 32 bits of memory instead of the intended smaller width, resulting in unintended adjacent memory corruption on arm64 systems.
Why it matters to the business
Systems running affected arm64 kernels may experience crashes, data corruption, or privilege escalation that disrupts services and requires emergency patching or reboots, especially in cloud and embedded deployments where arm64 is prevalent.
How an attack unfolds
An attacker with the ability to trigger percpu atomic operations on 8-bit or 16-bit variables (for example via crafted network packets or local system calls) causes the kernel to perform oversized memory accesses that corrupt neighboring data structures, potentially leading to control-flow hijacking or denial of service.
How to fix it
Update to a Linux kernel that includes the corrected percpu LSE assembly macros; rebuild and reboot all arm64 systems with the patched kernel. Where immediate updates are not possible, disable LSE atomics via kernel command-line options if supported by the distribution.
How to confirm the fix worked
Boot the patched kernel and confirm via kernel logs or source inspection that the 'sfx' macro argument is appended to op_lse instructions in percpu assembly; run architecture-specific percpu test suites to verify 8-bit and 16-bit operations access only the intended memory width.
Typical attack path
- Identify or reach a code path that performs percpu atomic operations on 8-bit or 16-bit types
- Trigger the LSE-based implementation of the operation
- Cause out-of-bounds 32-bit read/write that corrupts adjacent kernel memory
- Leverage the resulting memory corruption for privilege escalation or kernel panic
How to detect it
Search kernel logs and crash dumps for unexpected memory access violations or corruption patterns involving percpu variables on arm64; review audit logs for processes that heavily exercise atomic operations shortly before anomalies.
What your security team should do
- Prioritize patching of internet-facing and multi-tenant arm64 hosts within the next maintenance window
- Add kernel version checks to vulnerability scanning and asset inventory
- Monitor for unusual kernel oops or memory corruption reports on arm64 systems
The record
In the Linux kernel, the following vulnerability has been resolved: arm64: percpu: Fix LSE operations on {8,16}-bit types The assembly for __percpu_##name##_case_##sz() and __percpu_##name##_return_case_##sz() doesn't use the 'sfx' macro argument to form the LSE instruction. Without 'sfx', a W register argument will imply a 32-bit memory location, and consequently {8,16}-bit ops will erroneously read and write 32 bits of memory when the LSE instruction is used. Fix this by appending 'sfx' to 'op_lse' to LSE instruction. It is not necessary (and not valid) to append 'sfx' to 'op_llsc', as 'op_llsc' is a register-register operation which does not access memory (and does not take a size suffix).
Affected packages
| Ecosystem | Package | Introduced | Fixed |
|---|