Summary: | [pf] [pfsync] Incomplete state sync causing null pointer dereference | ||
---|---|---|---|
Product: | Base System | Reporter: | adam.stradtner |
Component: | kern | Assignee: | freebsd-net (Nobody) <net> |
Status: | Closed Unable to Reproduce | ||
Severity: | Affects Only Me | CC: | franco, freebsd, kevans, kp |
Priority: | --- | ||
Version: | 13.1-RELEASE | ||
Hardware: | amd64 | ||
OS: | Any |
Description
adam.stradtner
2023-06-22 22:10:41 UTC
Adam sent me a crash dump for further analysis that can be shared as well. Apparently it crashes where no sanity checking takes place in state inspection (so far UDP and ICMP seem to be affected but I wouldn't be surprised it's similar for TCP) leading to the assumption that states are not properly synced for one reason or another. The pfsync code has the latest updates from stable/13. Cheers, Franco Can you reproduce this problem on FreeBSD? Ok, let's make this longer than necessary shall we ;) Which kernel would you prefer? 13.1-RELEASE, 13.2-RELEASE or stable/13? (In reply to Franco Fichtner from comment #3) main, ideally, but I'll take information for any supported branch. So include the (minimised!) reproduction scenario, any required non-default settings and any additional information that can be extracted from the core dump (i.e. backtrace, local variables). Let's start with 13.2-RELEASE then. Will report back. Update: Since rebooting both systems with their identical kernels, I have not been able to reproduce this issue. Somehow a corrupt state (or maybe several corrupt states) was being persisted by always having at least 1 firewall online. At this time I don't know how to reproduce the original issue, but would recommend that some thought be put into validating states that are being synchronized. It seems to be an edge case that I ran into. Appears to be false positive, please close. (In reply to Franco Fichtner from comment #7) Done- feel free to reopen if new information comes to light. |