In the Linux kernel, the following vulnerability has been resolved: af_unix: Unify scc_index when finalising SCC in __unix_walk_scc(). Commit bfdb01283ee8 ("af_unix: Assign a unique index to SCC.") changed Tarjan's algorithm to update lowlink with lowlink, which is called lowpoint (unix_vertex.scc_index). unix_vertex_dead() assumes all vertices in an SCC share the same lowpoint, but this is not always true if an SCC has two or more back edges, depending on the order of DFS. For example, the graph below has two back edges from B to A and from C to B. A --> B --> C ^ | ^ | `----' `----' If DFS walks through A -> B -> C -> B (-> C -> B) -> A (-> B -> A), each index and scc_index will be updated as follows. A --> B --> C C = (3, 3) (index, scc_index) B = (2, 2) A = (1, 1) A ... B ... C C = (3, 2)<-. ^ | B = (2, 2) -' `----' A = (1, 1) A ... B ... C C = (3, 2) ^ | . . B = (2, 1)<-. `----' .... A = (1, 1) -' Then, unix_vertex_dead() thinks that B is passed to another SCC with scc_index 2, and the SCC is not garbage-collected. This does not happen if DFS walks in a different order below or starts from B. 1 3 A --> B --> C ^ | ^ | `----' `----' 2 4 Let's unify scc_index across the SCC when finalising it. Note that updating v->index was previously done in unix_scc_dead(), when called from __unix_walk_scc(), just to save one loop. Since __unix_walk_scc() now iterates over the SCC anyway, the update is moved back to __unix_walk_scc() and 'fast' argument is dropped.

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: af_unix: Unify scc_index when
    finalising SCC in __unix_walk_scc(). Commit bfdb01283ee8 ("af_unix: Assign a unique index to SCC.")
    changed Tarjan's algorithm to update lowlink with lowlink, which is called lowpoint
    (unix_vertex.scc_index). unix_vertex_dead() assumes all vertices in an SCC share the same lowpoint, but
    this is not always true if an SCC has two or more back edges, depending on the order of DFS. For example,
    the graph below has two back edges from B to A and from C to B. A --> B --> C ^ | ^ | `----' `----' If DFS
    walks through A -> B -> C -> B (-> C -> B) -> A (-> B -> A), each index and scc_index will be updated as
    follows. A --> B --> C C = (3, 3) (index, scc_index) B = (2, 2) A = (1, 1) A ... B ... C C = (3, 2)<-. ^ |
    B = (2, 2) -' `----' A = (1, 1) A ... B ... C C = (3, 2) ^ | . . B = (2, 1)<-. `----' .... A = (1, 1) -'
    Then, unix_vertex_dead() thinks that B is passed to another SCC with scc_index 2, and the SCC is not
    garbage-collected. This does not happen if DFS walks in a different order below or starts from B. 1 3 A
    --> B --> C ^ | ^ | `----' `----' 2 4 Let's unify scc_index across the SCC when finalising it. Note that
    updating v->index was previously done in unix_scc_dead(), when called from __unix_walk_scc(), just to save
    one loop. Since __unix_walk_scc() now iterates over the SCC anyway, the update is moved back to
    __unix_walk_scc() and 'fast' argument is dropped. (CVE-2026-98289)

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

  - af_unix: Unify scc_index when finalising SCC in __unix_walk_scc(). Commit bfdb01283ee8 (af_unix: Assign a     unique index to SCC.) changed Tarjan's algorithm to update lowlink with lowlink, which is called lowpoint     (unix_vertex.scc_index). unix_vertex_dead() assumes all vertices in an SCC share the same lowpoint, but     this is not always true if an SCC has two or more back edges, depending on the order of DFS. For example,     the graph below has two back edges from B to A and from C to B. A --> B --> C ^ | ^ | `----' `----' If DFS     walks through A -> B -> C -> B (-> C -> B) -> A (-> B -> A), each index and scc_index will be updated as     follows. A --> B --> C C = (3, 3) (index, scc_index) B = (2, 2) A = (1, 1) A ... B ... C C = (3, 2)<-. ^ |     B = (2, 2) -' `----' A = (1, 1) A ... B ... C C = (3, 2) ^ | . . B = (2, 1)<-. `----' .... A = (1, 1) -'     Then, unix_vertex_dead() thinks that B is passed to another SCC with scc_index 2, and the SCC is not     garbage-collected. This does not happen if DFS walks in a different order below or starts from B. 1 3 A
    --> B --> C ^ | ^ | `----' `----' 2 4 Let's unify scc_index across the SCC when finalising it. Note that     updating v->index was previously done in unix_scc_dead(), when called from __unix_walk_scc(), just to save     one loop. Since __unix_walk_scc() now iterates over the SCC anyway, the update is moved back to
    __unix_walk_scc() and 'fast' argument is dropped. (CVE-2026-98289)

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

ID	Name	Product	Family	Type	Severity
475490	Google: sys-kernel/cchost-kernel-6_12, sys-kernel/cchost-kernel-6_18, sys-kernel/csql-kernel-6_12, sys-kernel/csql-kernel-6_18, sys-kernel/lakitu-kernel-6_12, sys-kernel/lakitu-kernel-6_18, sys-kernel/lakitu-nc-kernel-6_12, sys-kernel/lakitu-nc-kernel-6_18: security update to 19999.44.126	Tenable Cloud Security	Google COS Security Checks	Local	medium
475490	Google: sys-kernel/cchost-kernel-6_12, sys-kernel/cchost-kernel-6_18, sys-kernel/csql-kernel-6_12, sys-kernel/csql-kernel-6_18, sys-kernel/lakitu-kernel-6_12, sys-kernel/lakitu-kernel-6_18, sys-kernel/lakitu-nc-kernel-6_12, sys-kernel/lakitu-nc-kernel-6_18: security update to 19999.44.126	Tenable Self-Hosted Container Security	Google COS Security Checks	Local	medium
365258	Amazon Linux 2023 : bpftool6.18, kernel6.18, kernel6.18-devel (ALAS2023-2026-3192)	Nessus	Amazon Linux Local Security Checks	Local	medium
363241	Linux Distros Unpatched Vulnerability : CVE-2026-98289	Nessus	Misc.	Local	medium

Detections

Analytics

CVE-2026-98289

medium

Tenable Plugins

medium

medium

medium

medium