# Google Chrome portal element fuzzing

Fuzzing Chrome's new portal element with domato grammar surfaced a heap use-after-free in content::Portal::Navigate/Activate, crashing the browser process.

- Payout: $8,000
- Severity: high
- Program: Google
- Credited: Pawel Wylecial
- Disclosed: 2019-12-06
- Write-up quality: 7/10
- Original: https://blog.redteam.pl/2019/12/chrome-portal-element-fuzzing.html
- Library page: https://bugbountylibrary.com/r/blog%3Ablog-redteam-pl-2019-12-chrome-portal-element-fuzzing-html
- Tags: domain:browser impact:dos kind:bounty platform:blog sev:high tech:chromium technique:fuzzing technique:source-review vuln:dos vuln:memory-corruption

**Target:** Chrome browser process, HTMLPortalElement (content::Portal)
**Root cause:** Portal::Navigate/Activate dereferences a portal object that has been freed when the page reloads while a navigation is in flight, causing a use-after-free in the browser process.
**Steps:**
1. Add HTMLPortalElement grammar to domato (generator.py, common.txt, html.txt, js.txt, tagattributes.txt).
2. Fuzz portal element attributes and JS methods (src, activate, postMessage, onportalactivate).
3. Minimize crashing testcase: create portal, set src, append to body, change src, then `setTimeout('location.reload(true);',500)`.
4. Load page in Chrome 76.0.3804.0 canary; observe access violation in `chrome!content::Portal::Navigate+0x45`.
**How found:** Noticed random crashes while poking at the new portal element; added portal grammar to domato fuzzer and got multiple crashes within an hour, two of which (heap overflow, UAF) affected the main browser process.
**Insight:** Newly shipped/flagged browser features (like portals) are under-fuzzed; extending an existing grammar fuzzer with the new element's attributes and JS API quickly surfaces browser-process memory bugs before Google's own fuzzing catches up.