https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279208
Bug ID: 279208
Summary: filling up arp table with static entries can lead to
crash
Product: Base System
Version: 14.0-RELEASE
Hardware: Any
OS: Any
Status: New
Severity: Affects Many People
Priority: ---
Component: kern
Assignee: [email protected]
Reporter: [email protected]
Loading arp table with the arp -f command leads to a panic. Sometimes panic
occurs immediately, sometimes after loading more entries (more subnets or wider
subnet). Executing few arp -a processes and waiting few minutes does lead to
panic too.
To reproduce I've created an alias on interface and a list of dummy entries:
# ifconfig em0 alias 172.17.1.1/24
# cat 1list
172.17.1.2 13:01:00:00:00:02
172.17.1.3 13:01:00:00:00:03
..
172.17.1.255 13:01:00:00:00:ff
# arp -f 1list
# ps axl |grep arp
0 842 820 1 20 0 12956 2688 sbwait I+ 0 0:00.02 arp -a
Those entries that arp command did show have obvious overflow:
# arp -an
? (172.17.3.254) at 13:03:00:00:00:fe on em0 expires in -1716331940 seconds
[ethernet]
? (172.17.3.222) at 13:03:00:00:00:de on em0 expires in -1716331940 seconds
[ethernet]
Sleeping thread (tid 100853, pid 0) owns a non-sleepable lock
KDB: stack backtrace of thread 100853:
#0 0xffffffff80b5028b at mi_switch+0xbb
#1 0xffffffff80b4fa00 at _sleep+0x1f0
#2 0xffffffff80ba6c11 at taskqueue_thread_loop+0xb1
#3 0xffffffff80afdb7f at fork_exit+0x7f
#4 0xffffffff80fe4b2e at fork_trampoline+0xe
panic: sleeping thread
cpuid = 1
time = 1716332236
KDB: stack backtrace:
#0 0xffffffff80b9009d at kdb_backtrace+0x5d
#1 0xffffffff80b431a2 at vpanic+0x132
#2 0xffffffff80b43063 at panic+0x43
#3 0xffffffff80ba8e9e at propagate_priority+0x29e
#4 0xffffffff80ba99e4 at turnstile_wait+0x314
#5 0xffffffff80b3e9c9 at __rw_rlock_hard+0x279
#6 0xffffffff80d8c2af at dump_lle+0x1f
#7 0xffffffff80c6c38c at htable_foreach_lle+0x5c
#8 0xffffffff80d8c234 at dump_llts_iface+0x54
#9 0xffffffff80d8bfcd at rtnl_handle_getneigh+0x20d
#10 0xffffffff80d882d2 at rtnl_handle_message+0x132
#11 0xffffffff80d85c0b at nl_taskqueue_handler+0x79b
#12 0xffffffff80ba5992 at taskqueue_run_locked+0x182
#13 0xffffffff80ba6c22 at taskqueue_thread_loop+0xc2
#14 0xffffffff80afdb7f at fork_exit+0x7f
#15 0xffffffff80fe4b2e at fork_trampoline+0xe
Uptime: 4m49s
--
You are receiving this mail because:
You are the assignee for the bug.
