Look up another CVE · open CVE-2026-89744 in the interactive tracker
CVE-2026-89744
device property: fix infinite loop in fwnode_for_each_child_node()
Published 2026-09-11 (37 days ago) by the Linux kernel CNA. Subsystem drivers/base. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2026-89744 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 | fixedDLA-4841-1 · 2026-10-17 · text | 6.1.190-1 | Update the kernel and reboot. DLA-4841-1 shipped the fix on 2026-10-17, in 6.1.190-1. A running kernel keeps the old code until the machine restarts. |
| Debian 13trixie | fixedDSA-6528-1 · 2026-09-29 · text | 6.12.111-1 | Update the kernel and reboot. DSA-6528-1 shipped the fix on 2026-09-29, in 6.12.111-1. A running kernel keeps the old code until the machine restarts. |
| 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. |
| Debian 12bookworm · linux-6.12 | fixedDLA-4817-1 · 2026-10-04 · text | 6.12.111-1~deb12u1 | Update the kernel and reboot. DLA-4817-1 shipped the fix on 2026-10-04, in 6.12.111-1~deb12u1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
When iterate over children of a fwnode that has a secondary fwnode, fwnode_get_next_child_node() can enter an infinite loop if the secondary fwnode has more than one child. Parent Child (Primary fwnode) FWa: {FWa1, FWa2, FWa3} (Secondary fwnode) FWb: {FWb1, FWb2} In this case: ┌─> fwnode_get_next_child_node(FWa, FWa1) │ - fwnode_call_ptr_op(FWa, get_next_child_node, FWa1) returns FWa2 │ │ ... │ │ fwnode_get_next_child_node(FWa, FWa3) │ - fwnode_call_ptr_op(FWa, get_next_child_node, FWa3) returns NULL │ - fwnode_call_ptr_op(FWb, get_next_child_node, FWa3) returns FWb1 │ │ fwnode_get_next_child_node(FWa, FWb1) │ - fwnode_call_ptr_op(FWa, get_next_child_node, FWb1) returns FWa1 └────┘ This cause fwnode_for_each_child_node() to loop indefinitely, reapeatedly output {FWa1, FWa2, FWa3, FWb1, FWa1, ...}. The root cause is that when the current child (FWb1) belongs to the secondary fwnode, calling get_next_child_node() on the parimary fwnode incorrectly returns the first child (FWa1) again instead of NULL. Fix this by dynamically checking the parent fwnode of the current child before calling get_next_child_node(). This approach follows the pattern established in commit b5b41ab6b0c1 ("device property: Check fwnode->secondary in fwnode_graph_get_next_endpoint()").
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/base/property.c
- What this is
- SOFTWARE NODES AND DEVICE PROPERTIESMAINTAINERS section matched on drivers/base/property.c · linux-acpi@vger.kernel.org · Maintained
Show whether Debian builds this, per release
Debian builds this code. Every release below compiles the affected file into the kernels it ships.
- bookworm, trixie, forky, sid, bookworm · linux-6.12y
- y
- built into the kernel image on every flavour - only a patch removes it
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 Debian linux-config packages
Signals
- Published
- 2026-09-11 (37 days ago)source
- CVSS
- 8.4 high
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.14%, higher than 3.1% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- drivers/base
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 6.1.167 | 6.1.188 | 04004fa33730 |
| 6.6.130 | 6.6.157 | f4ae79b5f001 |
| 6.12.78 | 6.12.109 | 20ed517e416d |
| 6.18.19 | 6.18.50 | ba69d892ff4e |
| 7.0 | 7.2.4 | 9cb6b223ef02 |
| 7.0 | 7.3 | 190069255582 |
| 5.10.253 | 0 | 0 |
| 5.15.203 | 0 | 0 |
| 6.19.9 | 0 | 0 |
Debian advisories
| Advisory | Date | Shipped to | Debian |
|---|---|---|---|
| DLA-4841-1 | 2026-10-17 | bookworm 6.1.190-1 | tracker |
| DLA-4817-1 | 2026-10-04 | bookworm 6.12.111-1~deb12u1 | tracker |
| DSA-6528-1 | 2026-09-29 | trixie 6.12.111-1 | tracker |
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
- fwnode_get_next_child_node() is reached from local driver-core fw_devlink and device_for_each_child_node() during device_add/bind/probe (GPIO, LEDs, IIO, MFD, camera), not from network or remote protocol parsing.
- AC:LAttack complexity, low
- On OF platforms whose primary node has children and a secondary software node also has children, of_get_next_available_child() treats a non-OF child as prev=NULL and restarts at the first OF child, so the loop is deterministic with no race or layout dependency.
- PR:NPrivileges required, none
- No capability or credential check exists on this path; fw_devlink_parse_fwtree()/fw_devlink_pickup_dangling_consumers() and driver probe walk mixed primary/secondary children automatically at boot and hotplug bind on phones, embedded boards, and Galileo GPIO.
- UI:NUser interaction, none
- Firmware-node child walks run inside kernel device registration, fw_devlink, and driver probe without any victim action such as mounting a filesystem or opening a user-supplied file.
- S:UScope, unchanged
- The hang and firmware-node use-after-free stay inside the host kernel's device-property/OF layer and do not cross a VM, IOMMU, or sandbox boundary.
- C:HConfidentiality impact, high
- Crossing from the last OF child into the secondary node makes software_node_get_next_child() put an already-dropped OF node, underflowing its refcount and freeing it while sibling iteration continues, a use-after-free of firmware-node memory.
- I:HIntegrity impact, high
- The extra put leaves the last primary child freed but still linked in the OF sibling list; the next of_get_next_available_child() follows that dangling sibling into freed device_node memory, enabling heap-spray write and control-flow hijack.
- A:HAvailability impact, high
- fwnode_for_each_child_node() spins forever in probe/fw_devlink process context, causing a soft lockup or hung task, and the OF-node use-after-free can also oops or panic the host.