劳动节期间，对VPS上的debian12进行了升级，内核版本从6.1.164-1(2026-03-09)升级到6.1.170-1(2026-04-30)，修补了CVE-2026-31431本地提权漏洞。运行一段时间后，偶尔发现dmesg显示多条icmp: detected local route for IP1 during ICMP sending, src IP2的信息，网上查了一下资料，已经有人第一时间向debian提交了1135514 bug。
该bug的成因，来自于linux新内核的两个关联补丁在反向移植时覆盖的LTS内核版本范围不一致，v6.13内核引入的第一个补丁解决了启用ip xfrm后访问本机LAN网段不存在的IP时触发的ip_rt_bug问题，该补丁被反向移植到6.12系列后续版本。前述"detected local route"信息是由第二个补丁（v7.0内核引入）产生的，该补丁严格说来应该算是第一个补丁的补丁，目的是为了解决特定情形下第一个补丁未能解决的同一个问题，然而这个特定情形并不存在于生产环境，完全属于人为构造。此外更令人蹊跷的是，该补丁除了被反向移植到6.12系列后续版本外，还被移植到了第一个补丁未覆盖的6.1和6.6这两个LTS内核系列的后续版本。
Debian12升级后的新内核6.1.170-1(2026-04-30)，当有应用程序往本机LAN网段不存在的IP发包时，由于缺失第一个补丁的干预，即便没有启用ip xfrm，也会受到第二个补丁的影响，必然出现"detected local route"信息。对比测试Debian13修补CVE-2026-31431漏洞后的新内核6.12.85-1(2026-04-30)，应用程序往本机LAN网段不存在的IP发包时，经由第一个补丁处理后，直接跳过了第二个补丁，显然不会产生前述bug。事后没几天，官方在修复CVE-2026-43284和CVE-2026-43500 "Dirty Frag"本地提权漏洞的同时，顺手为Debian12新内核打上了前述缺失的第一个补丁，从而修复了该bug，算是告一段落，对应的内核版本为6.1.170-3 (2026-05-08)。
对于内核为6.1.170-1(2026-04-30)版本的debian12来说，实验表明，只需要ping本机LAN网段不存在的IP，dmesg必然会出现"detected local route"信息，其中IP1为本机IP，IP2为ping对应的目标IP，显然和IP1位于同一网段。然而让人意外的是，在我的VPS上，偶尔出现的"detected local route"信息对应的IP1确实是本机IP，但IP2却是看起来不相干的WANIP，和IP1并不属于同一个LAN。经与chatgpt深入沟通，得知是由于VPS所在网关ARP响应不及时引起，当VPS给WANIP发包时，如VPS网关IP对应的neighbour状态不可达，并且网关ARP应答不及时的话，VPS就会因ARP超时进入内核ipv4_link_failure环节，最终触发前述第二个补丁，出现"detected local route"信息，并且对应的IP2就是VPS的发包对象WANIP。
明白了原理，就很方便重现上述现象，将本机LAN网段不存在的IP作为WANIP的gw，或者使用ebtables丢弃网关发来的ARP应答包，此时ping WANIP，就必然会出现IP2为WANIP的"detected local route"信息。显然，VPS环境更易受到宿主机和虚拟网络阻塞影响，在向WANIP发包时，一旦收不到网关IP发来的ARP应答包，同样也会出现IP2为WANIP的"detected local route"信息。阴差阳错之下，这个bug反而成为了检查VPS网络健壮性的手段，然而对于需要检测本机LAN网段IP的应用程序来说，该bug又会淹没正常的dmesg信息，真是让人爱恨交加。不过，该bug从出现到修复，犹如昙花一现，即使触发也没有不良影响，除了恰巧被本人遇到留下此文外，注定了不会引发更多关注。