GSoC 2026: Admin API Fuzzer - Fuzzing Strategy & Initial Setup

[Atharva Patil]

Hello Qubes Team,

My name is Atharva Bodade. I am a Systems Engineering student currently researching GSoC 2026 projects, and I plan to submit a proposal for the "Admin API Fuzzer" project.

I am highly aligned with the security and architectural constraints of Qubes OS. I am currently developing a baseline 32-bit kernel OS from scratch, which has given me strict discipline regarding memory management and system call routing. Additionally, I have a background in vulnerability auditing, which maps directly to the QSBs (QSB-038, QSB-089) mentioned in the project description.

Before drafting my formal proposal, I want to ensure I am targeting the correct attack surfaces. My initial thought is to build the fuzzer by targeting the `qrexec` service request handlers and simulating malformed payload lengths and unsanitized parameters to catch unhandled `PermissionDenied` exceptions and memory leaks.

I am currently setting up my local Qubes test bench to begin analyzing the qubesd daemon responses. Are there any specific fuzzing frameworks (e.g., AFL++, OSS-Fuzz, or a custom Python harness) the core team prefers for integrating with the existing continuous integration pipeline?

Looking forward to contributing.

Best regards,
Atharva Bodade
GitHub: UnsettledAverage73

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Fri, Mar 06, 2026 at 11:05:26PM -0800, Atharva Patil wrote:
> Hello Qubes Team,

Hello!

> My name is Atharva Bodade. I am a Systems Engineering student currently
> researching GSoC 2026 projects, and I plan to submit a proposal for the
> "Admin API Fuzzer" project.
>
> I am highly aligned with the security and architectural constraints of
> Qubes OS. I am currently developing a baseline 32-bit kernel OS from
> scratch, which has given me strict discipline regarding memory management
> and system call routing. Additionally, I have a background in vulnerability
> auditing, which maps directly to the QSBs (QSB-038, QSB-089) mentioned in
> the project description.
>
> Before drafting my formal proposal, I want to ensure I am targeting the
> correct attack surfaces. My initial thought is to build the fuzzer by
> targeting the `qrexec` service request handlers and simulating malformed
> payload lengths and unsanitized parameters to catch unhandled
> `PermissionDenied` exceptions and memory leaks.

Sounds good, take a look also at:
- - documentation: https://doc.qubes-os.org/en/latest/developer/services/admin-api.html
- - implementation: https://github.com/QubesOS/qubes-core-admin/blob/main/qubes/api/admin.py

And also some inspiration in this PR:
https://github.com/QubesOS/qubes-core-admin/pull/751

> I am currently setting up my local Qubes test bench to begin analyzing the
> qubesd daemon responses. Are there any specific fuzzing frameworks (e.g.,
> AFL++, OSS-Fuzz, or a custom Python harness) the core team prefers for
> integrating with the existing continuous integration pipeline?

We do use OSS-Fuzz in few repositories, but I'm not sure how realistic
is that for qubesd - mostly due to using Python, and heavily relying on
running inside Qubes OS, not a container.
So, I wouldn't be too attached to this one, feel free to propose
whatever you feel is most appropriate.


- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmmuyQEACgkQ24/THMrX
1ywCsgf9EDTI/bAmthqlKHl5xDE3x8rnfdepqiq4lcPQlWuhV7b+QTbwzhFLmjgb
Z7Stug2VuhD2vg8hXU0oGuUjNYedKVtZNxFUBo3wvX67hC00CB3uL5fIQlsHYldw
h+lfntZtfcd/JZ9GnEhN8r0mwy1IeMxBrgyi40X+YYj/0zva1H3qSsE6/f8pcNMn
2S3KLsj6kxeJr768mzH3sQcMVzrJuZvepQZyRg7lOns0zG2+cs3gq+PXldLRdIpt
pYkoPyel2nyFHKTPy3r3yRuRoCiinY5SYR15hySoVvcynDPvxHG7DydvCyI5E7A1
yf7BkGTWFYeAvZz5c3Hz1KNOFN3Glg==
=YLpV
-----END PGP SIGNATURE-----