)]}'
{
  "commit": "4517b74cc07c3b766ca92cf6cea352e65f6e8f9b",
  "tree": "55719399e40a72211ad9dc662cadd2ea05a33a20",
  "parents": [
    "168ff39e4758897d2eee4756977d036d52884c7e",
    "46c1ef0cfcea50aaf0b52316fdab94bf4b45795b"
  ],
  "author": {
    "name": "Jakub Kicinski",
    "email": "kuba@kernel.org",
    "time": "Thu Mar 05 07:53:19 2026 -0800"
  },
  "committer": {
    "name": "Jakub Kicinski",
    "email": "kuba@kernel.org",
    "time": "Thu Mar 05 07:53:20 2026 -0800"
  },
  "message": "Merge branch \u0027net-ipv6-fix-panic-when-ipv4-route-references-loopback-ipv6-nexthop-and-add-selftest\u0027\n\nJiayuan Chen says:\n\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\nnet: ipv6: fix panic when IPv4 route references loopback IPv6 nexthop and add selftest\n\nsyzbot reported a kernel panic [1] when an IPv4 route references\na loopback IPv6 nexthop object:\n\nBUG: unable to handle page fault for address: ffff8d069e7aa000\nPF: supervisor read access in kernel mode\nPF: error_code(0x0000) - not-present page\nPGD 6aa01067 P4D 6aa01067 PUD 0\nOops: Oops: 0000 [#1] SMP PTI\nCPU: 2 UID: 0 PID: 530 Comm: ping Not tainted 6.19.0+ #193 PREEMPT\nRIP: 0010:ip_route_output_key_hash_rcu+0x578/0x9e0\nRSP: 0018:ffffd2ffc1573918 EFLAGS: 00010286\nRAX: ffff8d069e7aa000 RBX: ffffd2ffc1573988 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: ffffd2ffc1573978 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000000 R12: ffff8d060d496000\nR13: 0000000000000000 R14: ffff8d060399a600 R15: ffff8d06019a6ab8\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffff8d069e7aa000 CR3: 0000000106eb0001 CR4: 0000000000770ef0\nPKRU: 55555554\nCall Trace:\n \u003cTASK\u003e\n ip_route_output_key_hash+0x86/0x1a0\n __ip4_datagram_connect+0x2b5/0x4e0\n udp_connect+0x2c/0x60\n inet_dgram_connect+0x88/0xd0\n __sys_connect_file+0x56/0x90\n __sys_connect+0xa8/0xe0\n __x64_sys_connect+0x18/0x30\n x64_sys_call+0xfb9/0x26e0\n do_syscall_64+0xd3/0x1510\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nReproduction:\n\n    ip -6 nexthop add id 100 dev lo\n    ip route add 172.20.20.0/24 nhid 100\n    ping -c1 172.20.20.1     # kernel crash\n\nProblem Description\n\nWhen a standalone IPv6 nexthop object is created with a loopback device,\nfib6_nh_init() misclassifies it as a reject route. Nexthop objects have\nno destination prefix (fc_dst\u003d::), so fib6_is_reject() always matches\nany loopback nexthop. The reject path skips fib_nh_common_init(), leaving\nnhc_pcpu_rth_output unallocated. When an IPv4 route later references\nthis nexthop and triggers a route lookup, __mkroute_output() calls\nraw_cpu_ptr(nhc-\u003enhc_pcpu_rth_output) on a NULL pointer, causing a page\nfault.\n\nThe reject classification was designed for regular IPv6 routes to prevent\nkernel routing loops, but nexthop objects should not be subject to this\ncheck since they carry no destination information. Loop prevention is\nhandled separately when the route itself is created.\n[1] https://syzkaller.appspot.com/bug?extid\u003d334190e097a98a1b81bb\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nLink: https://patch.msgid.link/20260304113817.294966-1-jiayuan.chen@linux.dev\nSigned-off-by: Jakub Kicinski \u003ckuba@kernel.org\u003e\n",
  "tree_diff": []
}