CVE-2026-64251: pwrseq: core: fix use-after-free in pwrseq_debugfs_seq_next()
In the Linux kernel, the following vulnerability has been resolved:
pwrseq: core: fix use-after-free in pwrseqdebugfsseqnext()
pwrseqdebugfsseqnext() declares 'next' with free(putdevice), which causes putdevice() to be called on the returned pointer when the variable goes out of scope. This results in a use-after-free since the seqfile framework receives a pointer whose reference has already been dropped.
Simply removing free(putdevice) would fix the UAF but would leak the reference acquired by busfindnextdevice(), as stop() only calls upread(&pwrseqsem) and never releases the device reference.
Fix this by making the reference counting consistent across all seqfile callbacks, matching the standard pattern used by PCI and SCSI:
- start(): use getdevice() so it returns a referenced pointer. - next(): explicitly putdevice(curr) to release the previous device's reference (no NULL check needed - the seqfile framework only calls next() while the previous return was non-NULL). - stop(): putdevice(data) to release the last iterated device's reference, with a NULL guard since stop() may be called with NULL when start() returned NULL or next() reached end-of-sequence.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pwrseq core (Linux kernel)to a version that resolves this vulnerability.Patch pwrseq: core: fix use-after-free in pwrseq_debugfs_seq_next() - Configuration
Apply the resolved fix so pwrseq_debugfs_seq_next() declares 'next' using __free(put_device) (with a NULL guard because stop() may be called with NULL), matching the standard seq_file callback pattern used by PCI.
pwrseq_debugfs_seq_next() (seq_file callbacks) next() reference handling = Use __free(put_device) on next() per seq_file standard pattern and ensure consistent NULL/guard behavior (stop() may be called with NULL) - Operational
Re-test the pwrseq debugfs seq_file iteration flow (start()/next()/stop()) to confirm the device reference counting is consistent and the UAF is eliminated (especially the paths where start() returns NULL or next() reaches end-of-sequence).
Event History
Frequently Asked Questions
Who can realistically exploit this issue?
Exploitation requires local access and low privileges; no user interaction is required. The affected path is the pwrseq debugfs sequence iterator, so systems where that debugfs interface is accessible to low-privileged local users are the relevant exposure case.
Is a default configuration known to be affected?
The data does not identify a configuration in which the affected debugfs path is enabled or accessible by default. Review whether the pwrseq debugfs sequence interface is present and whether untrusted local users can read it.
What can be done until the fix is deployed?
If patching cannot be applied immediately, restrict untrusted local access to the pwrseq debugfs interface and limit access to debugfs generally. This reduces the ability of low-privileged users to invoke the affected iterator.
How can I determine whether the fix is present?
Check the kernel source or applied stable patches for the referenced fixes. A fixed implementation holds device references returned by start(), releases the prior reference in next(), and releases the final reference in stop().