This page indexes security issues I discovered and reported in open source software. I triaged the findings, assessed their impact, worked with upstream maintainers and tested proposed fixes. Where applicable, I also worked with MITRE and CNAs during CVE assignment.

The record covers CVE-assigned findings, upstream vulnerability reports and attack-surface research evaluated through project-specific threat models.

The entries identify the verified vulnerability class, affected code path and upstream outcome. Links lead directly to reports containing reproducers, sanitizer traces, debugging evidence and maintainer discussion.

Assigned CVEs

Other public vulnerability reports

dpic parser fuzzing and maintainer collaboration

A focused Honggfuzz and AFL++ campaign against dpic produced the seven CVE-assigned memory-safety reports listed above, covering heap and global buffer overflows and use-after-free conditions. Each report identified the tested revision and affected function and included a reproducer with sanitizer evidence. For the more complex lifetime issue, I also supplied GDB and Valgrind analysis.

In issue 6, the maintainer confirmed the crash, prepared a fix and explained that dpic had not been extensively tested with invalid input. When he began exploring Honggfuzz, I continued the investigation by instrumenting storestring(), tracing its index calculations and demonstrating the write at offset 4096 into a 4096-byte allocation. The exchange turned the fuzzer output into an actionable boundary-condition diagnosis and helped introduce fuzz-driven testing into the maintainer discussion.

FreeBSD research

This work combined manual source-code auditing with hardware-backed fuzzing. I found the ping(8) issues through manual review, while the filesystem and USB kernel issues came from a BeagleBone-based fuzzing setup using GadgetFS to present malformed storage devices to FreeBSD.

Hardware-backed UFS filesystem fuzzing

I used GadgetFS on a BeagleBone to emulate USB mass-storage hardware backed by mutated UFS images. This exercised the real device attachment and mount paths, not only a filesystem parser in isolation. Testing across FreeBSD 12.1 and 13-CURRENT produced eight distinct kernel failure paths involving metadata validation, directory parsing, buffer sizing and virtual-memory fault handling.

Evidence: eight UFS reports

USB device lifecycle handling

The same hardware-backed approach exercised USB device lifecycle paths and exposed a shared unsafe assumption across multiple drivers. PR 239973 documented a null-pointer dereference when device_get_ivars(9) returned NULL.

Attack-surface analysis: A malicious USB peripheral could reach the shared device_get_ivars(9) assumption through multiple driver paths and trigger a kernel fault during device lifecycle processing. FreeBSD evaluated physical USB access against its server-focused threat model. The report preserves the hardware-triggered path, affected driver surface and underlying kernel failure primitive.

ping(8) input validation and memory safety

Through manual source-code auditing, I traced numeric option parsing into packet-size calculations and memory access in ping(8). Five reports covered out-of-bounds access and integer-conversion errors that could bypass validation and produce invalid packet parameters.

Outcome: FreeBSD accepted the -s truncation fix in revision 363102. A broader parameter-validation change covering PRs 239974, 239977 and 239978 landed in revision 367988 and was merged into stable/12.

OpenBSD filesystem research

I also applied the hardware-backed filesystem fuzzing approach to OpenBSD and reproduced kernel crashes through malformed filesystem images presented over emulated storage hardware.

Cross-platform attack-surface research: The work extended the same physical I/O methodology across BSD kernels and produced comparative evidence about malformed-media handling. Maintainer discussion focused on hardening the affected filesystem paths and the project-specific threat model used to evaluate them.

Discussions for my queries and issues on (L|U)nix mailing lists