Files
openwrt/target
Gennaro Cimmino e59089db5f realtek: l3: skip IPv4 routes without a nexthop device
A blackhole, unreachable or prohibit route has no device behind its
nexthop: fib_create_info() refuses one for these types and skips the
nexthop check that would find one, so fib_nh_dev stays NULL.
otto_l3_fib_add_v4() hands that device to is_vlan_dev() before any
test, and otto_l3_fib_check_v4(), which the delete path runs as well,
does the same in its variable initialisers. On an RTL9303 with the L3
offload built in, "ip route add blackhole 10.99.8.0/24" oopses in the
rtl83xx work queue and panics the box:

  CPU 0 Unable to handle kernel paging request at virtual address
  00000000, epc == 8070fe3c, ra == 80710594
  Workqueue: rtl83xx otto_l3_fib_event_work_do
  epc   : 8070fe3c otto_l3_fib_add_v4+0x1c0/0x794
  Kernel panic - not syncing: Fatal exception

The faulting load is the priv_flags word is_vlan_dev() tests. Such
routes are common on a router, for address space it announces but does
not use.

Handle them where a route through a nexthop object is already handled,
for the same reasons: there is nothing to offload, and the route can
still replace one that was, so the entry for its destination is taken
out, and a host route is trapped where the host table can hold it. The
delete path takes the same exit.

Tested on an RTL9303 (Hasivo S1100W-8XGT-SE) with the L3 offload built
in. Without this change the command above panics the box; with it, a
blackhole /24 stays in the kernel with no entry in hardware, an
offloaded /24 replaced by a blackhole loses its entry and gets it back
when replaced through the gateway again, a blackhole /32 gets a trap
entry in the host table, unreachable and prohibit routes go in as
well, and every delete leaves no entry and no oops. RTL839x, which runs
this code in a stock build, was not tested.

Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Gennaro Cimmino <gcimmino@rayonra.net>
Link: https://github.com/openwrt/openwrt/pull/25513
Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
2026-10-01 19:49:57 +02:00
..
…