In the Linux kernel, the following vulnerability has been resolved: device property: fix infinite loop in fwnode_for_each_child_node() 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()").

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - In the Linux kernel, the following vulnerability has been resolved: device property: fix infinite loop in
    fwnode_for_each_child_node() 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()"). (CVE-2026-89744)

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - device property: fix infinite loop in fwnode_for_each_child_node() 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()). (CVE-2026-89744)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Type	Severity
472583	Google: sys-kernel/csql-kernel-6_6, sys-kernel/lakitu-kernel-6_6, sys-kernel/lakitu-nc-kernel-6_6, sys-kernel/lakitu-vgpu-kernel-6_6: security update to 18867.624.2	Tenable Cloud Security	Google COS Security Checks	Local	high
472583	Google: sys-kernel/csql-kernel-6_6, sys-kernel/lakitu-kernel-6_6, sys-kernel/lakitu-nc-kernel-6_6, sys-kernel/lakitu-vgpu-kernel-6_6: security update to 18867.624.2	Tenable Self-Hosted Container Security	Google COS Security Checks	Local	high
362907	Debian dla-4817 : ata-modules-6.12.107+deb12-armmp-di - security update	Nessus	Debian Local Security Checks	Local	high
469383	Google: sys-kernel/cchost-kernel-6_12, sys-kernel/csql-kernel-6_12, sys-kernel/lakitu-kernel-6_12, sys-kernel/lakitu-nc-kernel-6_12: security update to 19506.505.8	Tenable Cloud Security	Google COS Security Checks	Local	high
469383	Google: sys-kernel/cchost-kernel-6_12, sys-kernel/csql-kernel-6_12, sys-kernel/lakitu-kernel-6_12, sys-kernel/lakitu-nc-kernel-6_12: security update to 19506.505.8	Tenable Self-Hosted Container Security	Google COS Security Checks	Local	high
351155	Debian dsa-6528 : ata-modules-6.12.111+deb13-armmp-di - security update	Nessus	Debian Local Security Checks	Local	high
345305	Linux Distros Unpatched Vulnerability : CVE-2026-89744	Nessus	Misc.	Local	high

Detections

Analytics

CVE-2026-89744

high

Tenable Plugins

high

high

high

high

high

high

high