https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=289017
--- Comment #2 from Qiu-ji Chen <[email protected]> ---
(In reply to Zhenlei Huang from comment #1)
Thank you for the response.
I have successfully verified this TOCTOU issue dynamically, moving beyond the
initial static analysis.
To reproduce the race condition reliably, I set up a QEMU environment with a
custom FreeBSD 14.3 kernel. I injected a busy loop (DELAY) in
lagg_transmit_ethernet specifically between the protocol check (sc_proto !=
NONE) and the function pointer call (lagg_proto_start). I then developed a
multi-threaded PoC where one thread repeatedly toggles the lagg protocol via
SIOCSLAGG while multiple victim threads flood the interface with packets.
This setup successfully triggered a Kernel Panic (Fatal trap 12: page fault
with instruction pointer 0x0), proving that the protocol can indeed be switched
to NONE after the check passes but before usage.
Panic Log:
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address = 0x0
fault code = supervisor read instruction, page not present
instruction pointer = 0x20:0x0
stack pointer = 0x28:0xfffffe0068ff2948
frame pointer = 0x28:0xfffffe0068ff2970
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, IOPL = 0
current process = 873 (poc)
rdi: fffff8000360a200 rsi: fffff800043c8700 rdx: 0000000000000000
rcx: 000000000000005a r8: fffffe000937c060 r9: fffff800043c8760
rax: 0000000000000000 rbx: fffff80003663000 rbp: fffffe0068ff2970
r10: 00000000000000a0 r11: fffff800046f2740 r12: 000000000000000e
r13: 0000000000000008 r14: fffffe0068ff2ac0 r15: fffff80003663000
trap number = 12
panic: page fault
cpuid = 1
time = 1765682403
KDB: stack backtrace:
#0 0xffffffff80ba8f1d at kdb_backtrace+0x5d
#1 0xffffffff80b5aa11 at vpanic+0x161
#2 0xffffffff80b5a8a3 at panic+0x43
#3 0xffffffff8104dbfa at trap_pfault+0x3da
#4 0xffffffff81023dd8 at calltrap+0x8
#5 0xffffffff80c85a50 at ether_output+0x6b0
#6 0xffffffff80d21998 at ip_output+0x13a8
#7 0xffffffff80d52c40 at udp_send+0xb60
#8 0xffffffff80c0145c at sosend_dgram+0x31c
#9 0xffffffff80c0242f at sousrsend+0x5f
#10 0xffffffff80c0aec0 at kern_sendit+0x1c0
#11 0xffffffff80c0b1f2 at sendit+0x1b2
#12 0xffffffff80c0b02d at sys_sendto+0x4d
#13 0xffffffff8104e547 at amd64_syscall+0x117
#14 0xffffffff810246eb at fast_syscall_common+0xf8
Uptime: 1m13s
Automatic reboot in 15 seconds - press a key on the console to abort
--> Press a key on the console to reboot,
--> or switch off the system now.
I verified that this vulnerable logic also persists in 15.0. While I plan to
attempt a reproduction without artificial delays using pure concurrency to
further demonstrate the impact, I believe the current result with the widened
window definitively proves the bug's existence and mechanism.
I suggest prioritizing a fix for this race condition.
--
You are receiving this mail because:
You are the assignee for the bug.
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.