Look up another CVE · open CVE-2026-89769 in the interactive tracker
CVE-2026-89769
clocksource/drivers/nxp-pit: Fix IRQ leak on cpuhp_setup_state error path
Published 2026-09-11 (37 days ago) by the Linux kernel CNA. Subsystem drivers/clocksource. Debian urgency: unimportant.
What to do, per Debian release
Debian's own status for CVE-2026-89769 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | not affected | 6.1.190-1 | Nothing to do. bookworm never shipped the vulnerable code. |
| Debian 13trixie | not affected | 6.12.113-1 | Nothing to do. trixie never shipped the vulnerable code. |
| Debian 14forky | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 7.2.6-1 | Update the kernel and reboot. Fixed in 7.2.6-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
When cpuhp_setup_state fails after pit_clockevent_per_cpu_init has successfully called request_irq, the error handling jumps directly to out_pit_clocksource_unregister without freeing the registered IRQ. This leaks the IRQ line and, since kfree(pit) follows, leaves a dangling pointer registered as the interrupt handler's dev_id, potentially leading to a use-after-free if the IRQ fires afterwards. Fix it by calling pit_clockevent_per_cpu_exit to properly release the IRQ before falling through to the existing cleanup chain.
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
drivers/clocksource/timer-nxp-pit.c
- What this is
- CLOCKSOURCE, CLOCKEVENT DRIVERSMAINTAINERS section matched on drivers/clocksource/ · linux-kernel@vger.kernel.org · Supported
Check it on the machine
grep -w CONFIG_NXP_PIT_TIMER /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
Show whether Debian builds this, per release
Debian does not build this code in 2 releases. The build rule could not be established for 2 releases, so nothing is claimed about those.
- bookworm, trixie?
- forky, sidn
- ?
- not established - no Makefile entry for the affected file
- n
- not enabled on any flavour - this release does not build the code
Where a release above reads "not established", no build rule for the affected file was found in that release's kernel tree. That is a gap in this lookup, not a finding that the code is absent.
- Build switch
- CONFIG_NXP_PIT_TIMER
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2026-09-11 (37 days ago)source
- CVSS
- 7.4 high
CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.17%, higher than 5.5% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- unimportantsource
- Subsystem
- drivers/clocksource
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.18 | 6.18.50 | d53c29a89a15 |
| 6.18 | 7.2.4 | cdcd86112324 |
| 6.18 | 7.3 | 05520e035f83 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The flaw is in pit_timer_init() of the NXP PIT clocksource driver (S32G2/S32G3 automotive SoCs and Vybrid vf610), reached only via local device-tree platform/timer probe at boot. Network, Bluetooth, USB, or other remote paths cannot reach this cpuhp error path.
- AC:HAttack complexity, high
- The dangling IRQ action is planted only when cpuhp_setup_state() fails after request_irq() (dynamic CPUHP slot exhaustion or irq_force_affinity failure). Those resource/hotplug failures, and a later interrupt on the already-disabled PIT line, are conditions the attacker cannot reliably induce.
- PR:NPrivileges required, none
- pit_timer_probe() and TIMER_OF_DECLARE pit_timer_init() run automatically from kernel timer/platform init on matching device-tree nodes, with no credential, capability, or authentication check before request_irq() and the cpuhp error path.
- UI:NUser interaction, none
- No victim action such as mounting a filesystem, opening a device, or plugging hardware is required. The leaky cleanup runs during unattended probe, and a later PIT IRQ or sched_clock read can consume the dangling state without another user.
- S:UScope, unchanged
- The leaked IRQ handler and kfree'd pit_timer object remain in the host kernel on the same S32G/Vybrid Linux instance. This is standard in-kernel use-after-free, not a VM escape, IOMMU bypass, or cross-OS partition breakout.
- C:HConfidentiality impact, high
- On the cpuhp failure path the driver kfree()s pit while pit_timer_interrupt remains registered with &pit->ced as dev_id, a use-after-free that per kernel CNA guidance enables arbitrary kernel memory disclosure via slab reuse.
- I:HIntegrity impact, high
- The same dangling ISR invokes ced->event_handler on the freed clock_event_device; reclaiming that heap object yields a function-pointer hijack and arbitrary-write primitive consistent with kernel UAF scoring.
- A:HAvailability impact, high
- An IRQ hitting pit_timer_interrupt after kfree, irq_dispose_mapping of a still-requested line, or sched_clock reads of iounmapped PIT MMIO can oops or panic the kernel, fully denying availability on affected automotive and embedded systems.