pfSense

Kernel panics on 2.9.0-RELEASE when pfBlockerNG loads more table entries than the configured "Firewall Maximum Table Entries" limit allows.

The table allocation fails with ENOMEM, but pfr_set_addrs() appears to use the result without checking it. The fault address is 0x9b, which looks like a small offset off a NULL pointer.
pfctl reports the ENOMEM cleanly:

cannot define table pfB_NAmerica_v6: Cannot allocate memory
The line in question reads [152]: table <pfB_NAmerica_v6> persist file
"/var/db/aliastables/pfB_NAmerica_v6.txt" 

so the limit is being detected somewhere in the path - but the kernel still panics on the netlink side.

I hit this twice in about 20 minutes, both times triggered by a pfBlockerNG update. Raising Firewall Maximum Table Entries from the default to 8000000 stopped the panics. My actual usage is 810335 entries (mostly GeoIP continent lists, v4 and v6), so it was roughly 2x over the default limit.

1. Install pfBlockerNG-devel (3.2.17_1) and enable enough GeoIP/IP feeds that the total table entry count exceeds "Firewall Maximum Table Entries". In my case: Top, Africa, Antarctica, Asia, Europe, NAmerica, Oceania, SAmerica - both v4 and v6 - plus CINS, ET Block/Comp, Spamhaus, Alienvault, ISC, and a few custom lists. Total 810335 entries.
2. Run Force Update / Reload.
3. Kernel panics while the tables are being loaded.

Backtrace

Fatal trap 12: page fault while in kernel mode
cpuid = 5; apic id = 12
fault virtual address   = 0x9b
fault code              = supervisor write data, page not present
instruction pointer     = 0x20:0xffffffff81112fbe
current thread          = 0/105625 (kernel/netlink_socket (PID)
panic: page fault

pfr_set_addrs() at pfr_set_addrs+0x33e
pf_handle_table_set_addrs() at pf_handle_table_set_addrs+0xda
nl_receive_message() at nl_receive_message+0x11d
nl_taskqueue_handler() at nl_taskqueue_handler+0x34b
taskqueue_run_locked() at taskqueue_run_locked+0x19e
taskqueue_thread_loop() at taskqueue_thread_loop+0xc2
fork_exit() at fork_exit+0x7b
fork_trampoline() at fork_trampoline+0xe

Both panics have an identical backtrace and the same fault address (0x9b). In the process list at the time of the panic, pfctl is sitting in sbwait on the netlink socket.
After the panic and reboot, the ruleset fails to load at all ("pf rules not loaded"), so the firewall has no internet connectivity until pfBlockerNG is disabled and the filter is reloaded manually. That part is expected given a failed ruleset parse, but it does mean a single oversized table takes the box off the network until someone intervenes at the console.

Exceeding the table-entries limit should fail the table load with ENOMEM and leave the rest of the ruleset alone. It should not panic the kernel.