An incomplete backport sequence in RHEL 9 y/z-streams left a local_bh imbalance in net/ipv6/seg6_iptunnel.c :: seg6_input_core().

Upstream commit c0b98ac1cc10 ("ipv6: sr: block BH in seg6_output_core() and seg6_input_core()") replaced short preempt_disable() sections with a local_bh_disable() that stays held across the cache miss / route-input path until a matching local_bh_enable() later in the function.

Upstream later landed 40475b63761a ("net: ipv6: seg6_iptunnel: mitigate 2-realloc issue"), which narrows BH disable to the dst_cache_* calls so error paths (including goto drop) are not responsible for re-enabling BH.

The CVE-2026-46099 fix (upstream f9c52a6ba978, "net: ipv6: fix NOREF dst use in seg6 and rpl lwtunnels") adds a NULL dst check after ip6_route_input() + skb_dst_force() that jumps to the drop label on failure. On current upstream and RHEL 10 this is safe because BH is already re-enabled at that point. On RHEL 9.6 through 9.10, the trees have c0b98ac1cc10 and the CVE-2026-46099 hunk but not 40475b63761a, so the new goto drop skips local_bh_enable() and returns with bottom halves still disabled.

This can lead to softirq starvation, lockdep splats, and potential system hangs on systems with SRv6 (Segment Routing v6) configured.

The fix is to backport 40475b63761a or otherwise ensure every path to the drop label runs with BH enabled.