Date: Fri, 23 Jan 2026 22:37:12 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 279653] Page fault in in6_selecthlim Message-ID: <bug-279653-7501-X1dllDSYl0@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-279653-7501@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279653 --- Comment #22 from commit-hook@FreeBSD.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=f3de667137e90679cd20fa5c1dcd93a4c51ad848 commit f3de667137e90679cd20fa5c1dcd93a4c51ad848 Author: Gleb Smirnoff <glebius@FreeBSD.org> AuthorDate: 2026-01-23 22:18:18 +0000 Commit: Gleb Smirnoff <glebius@FreeBSD.org> CommitDate: 2026-01-23 22:18:18 +0000 netinet6: free in6_ifextra with epoch_call(9) This is expected to fix the old in6_selecthlim() panics. The nature of the panic is that a packet sending thread will obtain the struct ifnet pointer locklessly and then pick the if_inet6 pointer from it and dereference it. While the struct ifnet is freed via epoch_call(9), the struct in6_ifextra until this change was not. For the forwarded packets, or locally originated non-TCP packets we were probably safe due to the old if_dead trick. But locally originated TCP packets may dereference in6_ifextra via direct call into in6_selecthlim() from the tcp_output(), before ip6_output(). NB: hypothetically a similar problem also applies to IPv4's if_inet pointer, but there are no known panics, yet. PR: 279653 Reviewed by: tuexen Differential Revision: https://reviews.freebsd.org/D54728 sys/netinet6/in6_ifattach.c | 25 ++++++++++++++++++++----- sys/netinet6/in6_var.h | 2 ++ 2 files changed, 22 insertions(+), 5 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-279653-7501-X1dllDSYl0>