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: [email protected]
Reporter: [email protected]
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.
