Answer in brief
CVE-2026-23200 records a Unknown severity vulnerability in ipv6: Fix ECMP sibling count mismatch when clearing RTF_ADDRCONF. The current sources do not mark it as known exploited. The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps Linux/Linux (generic), Linux/Linux (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| Linux/Linuxgeneric | >=cb2b0caa8ca93cbe39177516669bf699c74f7041 <50b7c7a255858a85c4636a1e990ca04591153dca || >=03f642caab84bbfd138e74f671bb436186ea7e82 <d8143c54ceeba232dc8a13aa0afa14a44b371d93 || >=3e5b25da0b4109a3e063759735e6ec4236ea5a05 <b8ad2d53f706aeea833d23d45c0758398fede580 || >=f72514b3c5698e4b900b25345e09f9ed33123de6 <bbf4a17ad9ffc4e3d7ec13d73ecd59dea149ed25 || 61d88ea0f30c88e4ea98793594943aed8f1fc9ab || >=6.17.13 <6.18 | 50b7c7a255858a85c4636a1e990ca04591153dca, d8143c54ceeba232dc8a13aa0afa14a44b371d93, b8ad2d53f706aeea833d23d45c0758398fede580, bbf4a17ad9ffc4e3d7ec13d73ecd59dea149ed25, 6.18 |
| Linux/Linuxgeneric | >=6.6.120 <6.6.124 || >=6.12.63 <6.12.70 || >=6.18.2 <6.18.10 | 6.6.124, 6.12.70, 6.18.10 |
Published upstream
Feb 14, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Nov 5, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Nov 5, 2026
In the Linux kernel, the following vulnerability has been resolved: ipv6: Fix ECMP sibling count mismatch when clearing RTF_ADDRCONF syzbot reported a kernel BUG in fib6_add_rt2node() when adding an IPv6 route. [0] Commit f72514b3c569 ("ipv6: clear RA flags when adding a static route") introduced logic to clear RTF_ADDRCONF from existing routes when a static route with the same nexthop is added. However, this causes a problem when the existing route has a gateway. When RTF_ADDRCONF is cleared from a route that has a gateway, that route becomes eligible for ECMP, i.e. rt6_qualify_for_ecmp() returns true. The issue is that this route was never added to the fib6_siblings list. This leads to a mismatch between the following counts: - The sibling count computed by iterating fib6_next chain, which includes the newly ECMP-eligible route - The actual siblings in fib6_siblings list, which does not include that route When a subsequent ECMP route is added, fib6_add_rt2node() hits BUG_ON(sibling->fib6_nsiblings != rt->fib6_nsiblings) because the counts don't match. Fix this by only clearing RTF_ADDRCONF when the existing route does not have a gateway. Routes without a gateway cannot qualify for ECMP anyway (rt6_qualify_for_ecmp() requires fib_nh_gw_family), so clearing RTF_ADDRCONF on them is safe and matches the original intent of the commit. [0]: kernel BUG at net/ipv6/ip6_fib.c:1217! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 0 UID: 0 PID: 6010 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 RIP: 0010:fib6_add_rt2node+0x3433/0x3470 net/ipv6/ip6_fib.c:1217 [...] Call Trace: <TASK> fib6_add+0x8da/0x18a0 net/ipv6/ip6_fib.c:1532 __ip6_ins_rt net/ipv6/route.c:1351 [inline] ip6_route_add+0xde/0x1b0 net/ipv6/route.c:3946 ipv6_route_ioctl+0x35c/0x480 net/ipv6/route.c:4571 inet6_ioctl+0x219/0x280 net/ipv6/af_inet6.c:577 sock_do_ioctl+0xdc/0x300 net/socket.c:1245 sock_ioctl+0x576/0x790 net/socket.c:1366 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Quoted source text, attributed separately from HOL analysis.