Date: Fri, 16 Jan 2026 02:25:08 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 292493] [lagg] Protocol replacement synchronization failure leading to Panic Message-ID: <bug-292493-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=292493 Bug ID: 292493 Summary: [lagg] Protocol replacement synchronization failure leading to Panic Product: Base System Version: 14.3-STABLE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: hanguidong02@gmail.com I am opening this new report to draw attention to a synchronization flaw in the Link Aggregation (lagg) subsystem. While this issue was briefly touched upon in Bug 289017 (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=289017) via code analysis, I have since developed a reliable reproduction suite that demonstrates the scope and severity of this vulnerability far exceeds the initial findings. The core issue is a complete lack of synchronization between the control path (SIOCSLAGG ioctl) and the data path (lagg_transmit). When switching protocols (e.g., from FAILOVER to LACP), the kernel detaches the old protocol and sets the state to LAGG_PROTO_NONE before attaching the new one. This transition is not atomic relative to the transmit path. Using a custom multi-threaded PoC (attached below as setup_and_trigger.sh and poc.c), I can reliably crash an unmodified GENERIC kernel (FreeBSD 14.3) within seconds. My dynamic analysis reveals that the race condition manifests in multiple ways depending on the exact timing. I have attached the following reproduction files: 1. setup_and_trigger.sh: Sets up the environment and rapidly toggles lagg protocols. 2. poc.c: A multi-threaded packet sprayer designed to hit the race window. Steps to reproduce: 1. Compile the PoC: clang -O2 -pthread -o poc poc.c 2. Run ./setup_and_trigger.sh in one terminal. 3. Run ./poc in another terminal. 4. The system will panic within seconds. I have verified this crash on FreeBSD 14.3 using QEMU. Code analysis indicates the vulnerable logic also exists in FreeBSD 15.0 and earlier versions. I am currently occupied but plan to test other versions next weekend; however, I expect the attached scripts to work across these versions without modification. Reason for new report: This report includes new findings. The original ticket has seen no developer activity for several months. Updates were posted in December, but have received no response for over a month. -- 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-292493-227>