Regression #12384
closedSegmentation fault when loading ALTQ traffic shaping rules using FAIRQ
0%
Description
This is the return of Bug #11550 in pfSense 2.5.2.
I originally filed my report as a reply to that bug, but I realized later that I probably should have filed a new bug since the original had already been marked as resolved. Apologies for the duplication. My original text is below.
Given that this regression results in a completely broken firewall after upgrading, I've marked it as "urgent", but I hope that's not overreaching on my part.
I'm afraid I have to agree with Roman Nik that this bug is still around in 2.5.2-RELEASE.
I just upgraded from 2.4.5_1 to 2.5.2, and I got bitten by this same bug. After the upgrade, the firewall came back up essentially rule-less because pfctl segfaulted while parsing the ruleset. I first noticed while inspecting the system logs post-upgrade, and I freaked out when I saw internet bots banging on my pfSense SSH port, which is normally completely firewalled off from the WAN interface! After disabling the WAN for safety, I was able to debug the problem and found that the shaper rules were the cause of the segfault.
# cat /etc/version* 2.5.2-RELEASE Fri Jul 02 15:33:00 EDT 2021 fd0f54f44b5ceb91c4579ed9536de58b8925836d 0 # pfctl -vf /tmp/rules.debug [...snip...] set loginterface igb1 set skip on { pfsync0 } altq on igb0 fairq bandwidth 6.25Mb tbrsize 6000 queue { WAN_main } Segmentation fault (core dumped)
Note that the symptoms are identical to those originally reported here: ALTQ using FAIRQ causes a segfault on rule parse.
Once I disabled both of my shapers in pfSense and reloaded the config, the firewall came up normally, and a pfctl -vf /tmp/rules.debug
would return without error.
I've attached the shaper section of my pfSense config for reference.
Files
Updated by Jim Pingle over 2 years ago
- Status changed from New to Feedback
- Priority changed from Urgent to High
Can you replicate this on a CE 2.6.0 or Plus 21.09 snapshot? It may already be corrected there.
Updated by Brett Keller over 2 years ago
I just tested this on the 2.6.0.a.20210916.0100 snapshot, and I can no longer reproduce the problem there, so this does indeed look like it will be fixed in the next stable release. Thank you!
Updated by Jim Pingle over 2 years ago
- Status changed from Feedback to Resolved
Thanks for testing and following up!
I'm going to close this out for now, but if you happen to be able to replicate it again, let us know.