syzbot reported a kernel panic [1] when an IPv4 route references
a loopback IPv6 nexthop object:
BUG: unable to handle page fault for address: ffff8d069e7aa000
PF: supervisor read access in kernel mode
PF: error_code(0x0000) - not-present page
PGD 6aa01067 P4D 6aa01067 PUD 0
Oops: Oops: 0000 [#1] SMP PTI
CPU: 2 UID: 0 PID: 530 Comm: ping Not tainted 6.19.0+ #193 PREEMPT
RIP: 0010:ip_route_output_key_hash_rcu+0x578/0x9e0
RSP: 0018:ffffd2ffc1573918 EFLAGS: 00010286
RAX: ffff8d069e7aa000 RBX: ffffd2ffc1573988 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffffd2ffc1573978 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8d060d496000
R13: 0000000000000000 R14: ffff8d060399a600 R15: ffff8d06019a6ab8
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffff8d069e7aa000 CR3: 0000000106eb0001 CR4: 0000000000770ef0
PKRU: 55555554
Call Trace:
<TASK>
ip_route_output_key_hash+0x86/0x1a0
__ip4_datagram_connect+0x2b5/0x4e0
udp_connect+0x2c/0x60
inet_dgram_connect+0x88/0xd0
__sys_connect_file+0x56/0x90
__sys_connect+0xa8/0xe0
__x64_sys_connect+0x18/0x30
x64_sys_call+0xfb9/0x26e0
do_syscall_64+0xd3/0x1510
entry_SYSCALL_64_after_hwframe+0x76/0x7e
Reproduction:
ip -6 nexthop add id 100 dev lo
ip route add 172.20.20.0/24 nhid 100
ping -c1 172.20.20.1 # kernel crash
Problem Description
When a standalone IPv6 nexthop object is created with a loopback device,
fib6_nh_init() misclassifies it as a reject route. Nexthop objects have
no destination prefix (fc_dst=::), so fib6_is_reject() always matches
any loopback nexthop. The reject path skips fib_nh_common_init(), leaving
nhc_pcpu_rth_output unallocated. When an IPv4 route later references
this nexthop and triggers a route lookup, __mkroute_output() calls
raw_cpu_ptr(nhc->nhc_pcpu_rth_output) on a NULL pointer, causing a page
fault.
The reject classification was designed for regular IPv6 routes to prevent
kernel routing loops, but nexthop objects should not be subject to this
check since they carry no destination information. Loop prevention is
handled separately when the route itself is created.
Solution
Patch 1: Add an fc_is_nh flag to fib6_config to explicitly identify
nexthop object creation and skip the reject check in fib6_nh_init().
Using fc_dst_len to implicitly distinguish nexthop objects was considered
but rejected as too fragile, since fib6_nh_init() is shared by multiple
callers. Unconditionally calling fib_nh_common_init() for all reject
routes was also considered, but on large machines with many CPUs the
per-CPU nhc_pcpu_rth_output allocation would waste significant memory
for pure IPv6 reject routes that never need it.
Patch 2: Add a selftest reproducing the crash scenario.
[1] https://syzkaller.appspot.com/bug?extid=334190e097a98a1b81bb
Jiayuan Chen (2):
net: ipv6: fix panic when IPv4 route references loopback IPv6 nexthop
selftests: net: add test for IPv4 route with loopback IPv6 nexthop
include/net/ip6_fib.h | 1 +
net/ipv4/nexthop.c | 1 +
net/ipv6/route.c | 8 +++++++-
tools/testing/selftests/net/fib_nexthops.sh | 11 +++++++++++
4 files changed, 20 insertions(+), 1 deletion(-)
--
2.43.0
