CVE-2026-98528

What it actually does

Failure to zero an info struct before returning from gpio_desc_to_lineinfo() on SRCU guard acquisition failure allows uninitialized kernel stack bytes to be copied to userspace in lineinfo_get_v1().

Why it matters to the business

Unprivileged local users may obtain fragments of kernel memory, increasing the chance of successful privilege escalation or information theft on affected systems.

How an attack unfolds

An attacker invokes the GPIO character device ioctl that calls lineinfo_get_v1(), forces the error path by racing or holding the chip, and receives the partially uninitialized structure containing prior stack contents.

How to fix it

Update to a Linux kernel containing the commit that makes gpio_desc_to_lineinfo() return int and ensures the memset occurs before the SRCU lock attempt; rebuild and reboot with the fixed kernel.

How to confirm the fix worked

Confirm the presence of the upstream fix in the running kernel source or binary; exercise the ioctl error path under a debugger or memory sanitizer to verify the structure is now zeroed.

Typical attack path

1. Open /dev/gpiochipX as an unprivileged user
2. Issue GPIO_GET_LINEINFO_IOCTL or equivalent v1 request
3. Trigger failure to acquire the SRCU read lock inside gpio_desc_to_lineinfo()
4. Receive the unzeroed info struct containing kernel stack bytes
5. Parse leaked data for pointers, credentials, or other sensitive values

How to detect it

Review audit logs or eBPF traces for GPIO character device opens and ioctls issued by non-root users; correlate with any subsequent unexpected privilege-escalation attempts.

What your security team should do

• Apply the kernel update within the next maintenance window
• Restrict unprivileged access to GPIO character devices via udev rules or device cgroup policies until patched
• Monitor for unusual GPIO ioctl activity from non-root processes