Cloudanix VulnDB

CVE-2025-68167

None

CVSS

—

EPSS

0.2%

Published

Dec 16, 2025

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A bug in the Linux kernel could make systems using GPIO features crash when certain debug tools are used while the system is low on memory.

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

What it actually does

Uninitialized pointer dereference in gpiolib debugfs seq operations: gpiolib_seq_start() failure leaves s->private unset, and gpiolib_seq_stop() dereferences it without a NULL check, resulting in invalid memory access.

Why it matters to the business

Kernel instability or crash on affected Linux systems when GPIO debugfs interfaces are accessed under memory pressure, causing denial of service and potential loss of availability for dependent services.

How an attack unfolds

An attacker with local access creates memory pressure to force kzalloc failure in gpiolib_seq_start() while a seq_file operation is active on GPIO debugfs, then triggers gpiolib_seq_stop() which blindly dereferences the uninitialized private pointer.

How to fix it

Upgrade affected packages to the listed fixed versions: linux 3.11.0-12.19 (14.04), 4.4.0-2.16 (16.04), 4.13.0-16.19 (18.04), 5.4.0-117.132 (20.04) and corresponding updates for linux-aws, linux-azure, linux-gcp, linux-hwe, linux-kvm, linux-oracle and related meta-packages.

How to confirm the fix worked

Verify running kernel version matches or exceeds the fixed package versions for each distribution release; confirm gpiolib debugfs seq_start and seq_stop paths contain the NULL initialization and check.

Typical attack path

  1. Obtain local shell or process execution on target system
  2. Induce memory exhaustion to cause allocation failure in gpiolib_seq_start()
  3. Perform read or iteration on GPIO debugfs entries to invoke the seq operations
  4. Trigger sequence stop path to dereference the uninitialized pointer

How to detect it

Review kernel logs for oops/panic traces referencing gpiolib_seq_start or gpiolib_seq_stop under memory allocation failure conditions; correlate with processes accessing GPIO debugfs entries.

What your security team should do

  • Prioritize patching all listed Ubuntu 14.04/16.04/18.04/20.04 LTS kernel packages to the exact fixed revisions provided
  • Restrict unprivileged access to /sys/kernel/debug/gpio until patches are applied
  • Monitor for kernel oops or panic events involving gpiolib_seq_stop

The record

In the Linux kernel, the following vulnerability has been resolved: gpiolib: fix invalid pointer access in debugfs If the memory allocation in gpiolib_seq_start() fails, the s->private field remains uninitialized and is later dereferenced without checking in gpiolib_seq_stop(). Initialize s->private to NULL before calling kzalloc() and check it before dereferencing it.

Affected packages

Ecosystem Package Introduced Fixed
Linux Kernel 6.9.0 6.12.58
openSUSE:Leap 16.0 dtb-aarch64 0 6.12.0-160000.9.1
openSUSE:Leap 16.0 kernel-64kb 0 6.12.0-160000.9.1
openSUSE:Leap 16.0 kernel-azure 0 6.12.0-160000.9.1
openSUSE:Leap 16.0 kernel-default 0 6.12.0-160000.9.1
openSUSE:Leap 16.0 kernel-default-base 0 6.12.0-160000.9.1.160000.2.6
openSUSE:Leap 16.0 kernel-docs 0 6.12.0-160000.9.1
openSUSE:Leap 16.0 kernel-kvmsmall 0 6.12.0-160000.9.1
openSUSE:Leap 16.0 kernel-obs-build 0 6.12.0-160000.9.1
openSUSE:Leap 16.0 kernel-obs-qa 0 6.12.0-160000.9.1
openSUSE:Leap 16.0 kernel-rt 0 6.12.0-160000.9.1
openSUSE:Leap 16.0 kernel-source 0 6.12.0-160000.9.1
openSUSE:Leap 16.0 kernel-syms 0 6.12.0-160000.9.1
openSUSE:Leap 16.0 kernel-zfcpdump 0 6.12.0-160000.9.1

Related vulnerabilities