Skip to content

Commit

Permalink
kernelCTF: rules: add warnings about checking for slot dupes
Browse files Browse the repository at this point in the history
  • Loading branch information
koczkatamas authored Jan 17, 2025
1 parent 0cd8308 commit 3e1d549
Showing 1 changed file with 14 additions and 8 deletions.
22 changes: 14 additions & 8 deletions kernelctf/rules.md
Original file line number Diff line number Diff line change
Expand Up @@ -150,6 +150,8 @@ If you are unsure about eligibility, contact us on the [#kernelctf Discord chann

_Note: Minor details of the submission process may change from time to time, please make sure you check this page again for updates when you make a new submission._

Before you start the submission process, please make sure that the target's slot you are planning to exploit is not taken by looking at the [public spreadsheet](https://docs.google.com/spreadsheets/d/e/2PACX-1vS1REdTA29OJftst8xN5B5x8iIUcxuK6bXdzF8G1UXCmRtoNsoQ9MbebdRdFnj6qZ0Yd7LwQfvYC2oF/pubhtml). The server also tries to warn you about this by putting "Slot is taken by expNNN" next to the target.

Submissions can target 0-day and 1-day bugs.

## Non-patched and 0-day submissions
Expand Down Expand Up @@ -181,22 +183,24 @@ In this stage:
2. Submit the flag and the hash via [this form](https://forms.gle/JA3XVBdmSbFmhgZQ9) with the additional details requested.

* Save the link as you’ll have to edit this form later.

3. Check the [public spreadsheet](https://docs.google.com/spreadsheets/d/e/2PACX-1vS1REdTA29OJftst8xN5B5x8iIUcxuK6bXdzF8G1UXCmRtoNsoQ9MbebdRdFnj6qZ0Yd7LwQfvYC2oF/pubhtml) that you actually took a free slot and your submission is not a dupe (if there is a race for a slot, it is possible that someone else was faster than you and took the slot). If your submission was dupe, you have to wait for new, empty slot to be released.

3. Report the vulnerability to [email protected] within 7 days of the first form submission.
4. Report the vulnerability to [email protected] within 7 days of the first form submission.

* Note: A submission will be considered ineligible if it turns out that this requirement was not respected.

4. Make sure that you are credited in the `Reported-By` tag of the patch that fixes the bug.
5. Make sure that you are credited in the `Reported-By` tag of the patch that fixes the bug.

* Use the same email address in the `Reported-By` tag as you use for the form submission or in the "Email address used in Reported-By tag" field of the form.

* If there is no `Reported-By` tag on a patch commit, then a 0-day submission is eligible only if this is the first 0-day submission for that patch commit (based on the first stage submission date).

* If it is unclear who reported the bug, then the 0-day bonus can be split (multiple reporters), reduced, invalidated or the 0-day submission protection can be lost at our discretion.

5. Wait for the patch to land in a release candidate on the mainline tree (and tagged in Git), or committed on a stable tree.
6. Wait for the patch to land in a release candidate on the mainline tree (and tagged in Git), or committed on a stable tree.

6. Modify the form within 7 days by following the previously saved link and fill out the extra details as described below in the 1-day section.
7. Modify the form within 7 days by following the previously saved link and fill out the extra details as described below in the 1-day section.

* If the 7-day deadline is missed, then the first stage 0-day protection expires and other 1-day submissions can take priority over this submission (which makes this submission a duplicate and thus ineligible for reward).

Expand All @@ -208,15 +212,17 @@ A submission will not be eligible as a 0-day submission if the vulnerability det

1. Submit the requested vulnerability details via [this form](https://forms.gle/JA3XVBdmSbFmhgZQ9) (without including additional details on the exploitation technique for now).

2. Send us the description of the vulnerability via [bughunters.google.com](https://bughunters.google.com/) (please follow the process described below).
2. Check the [public spreadsheet](https://docs.google.com/spreadsheets/d/e/2PACX-1vS1REdTA29OJftst8xN5B5x8iIUcxuK6bXdzF8G1UXCmRtoNsoQ9MbebdRdFnj6qZ0Yd7LwQfvYC2oF/pubhtml) that you actually took a free slot and your submission is not a dupe (if there is a race for a slot, it is possible that someone else was faster than you and took the slot). If your submission was dupe, you have to wait for new, empty slot to be released.

3. Send us the description of the vulnerability via [bughunters.google.com](https://bughunters.google.com/) (please follow the process described below).

3. Wait for us to publish the CVE or publish the vulnerability details yourself on [oss-sec](https://seclists.org/oss-sec/).
4. Wait for us to publish the CVE or publish the vulnerability details yourself on [oss-sec](https://seclists.org/oss-sec/).

* If you'd like to speed up the CVE publication process, please make sure you fill out all the details needed for the CVE when you fill out the form. This way the disclosure happens earlier and your submission will be processed faster.

4. After the vulnerability is disclosed via a CVE or oss-sec, wait 30 days (recommendation, see notes below) and send us your exploit with the description of the exploitation technique via a PR to [the security-research repo](https://github.com/google/security-research/) (see required structure below).
5. After the vulnerability is disclosed via a CVE or oss-sec, wait 30 days (recommendation, see notes below) and send us your exploit with the description of the exploitation technique via a PR to [the security-research repo](https://github.com/google/security-research/) (see required structure below).

5. Make sure that the PR is merged (this is a requirement to get a reward).
6. Make sure that the PR is merged (this is a requirement to get a reward).

### Google Bughunter's website submission process

Expand Down

0 comments on commit 3e1d549

Please sign in to comment.