I attempted to investigate this further, while very reproducible, it's difficult get a good trace. Once the bug is fully engaged, it becomes impossible to break into ddb, the system is completely unresponsive.
However, triggering ddb a few seconds before and stepping through instructions is possible. The breakpoint chain seems to follow below: ffs_read VOP_READ uvn_io uvn_get uvm_fault_lower_io uvm_fault_lower uvm_fault upageflttrap userret followed by an infinite stream of: kernel: double fault trap, code=0 with the ddb pager triggered, but unable to break out of. I hope this information is helpful to someone. Regards Lloyd Lloyd wrote: > bugs@, > > I believe this bug report was overlooked, appears to be a serious one. > > I was reminded because I accidentally left this sparse file in my home > directory and DoS'd my own test box today by running grep in my home dir. > > A standard user is all that's needed, root not required. > > dd to create the sparse file, run grep, attempt ^C will fail.... > > CPU and memory usage climbs to max, active SSH sessions all time out. > > The console displays a blinking cursor at login: but is unresponsive to > any input. A hard reset is required. Fully patched OpenBSD 7.8 amd64. > > Regards > Lloyd > > Lloyd wrote: > > > Appears to be a FFS bug. > > > > No repro if the underlying fs is ext2. > > > > The reported size of the null file is also different. > > > > If the fs is FFS a user executing this command over SSH will freeze > > the console (ttyC0), CPU usage climbs to 100%. > > > > Regards > > Lloyd > > > > H. Hartzer wrote: > > > > > On Wed Oct 22, 2025 at 7:04 PM UTC, Eternity Crew wrote: > > > > > > > The following seems sufficient to cause OpenBSD 7.8 to cease all > > > > normal activities: > > > > > > > > $ dd if=/dev/null of=1 bs=1m seek=8000000; (ulimit -t 1; cmp 1 1) > > > > > > > > Therefore, this is probably a local DoS. > > > > > > > > > Can you confirm if OpenBSD 7.7 handled this differently? > > > > > > -Henrich
