|Deletions are marked like this.||Additions are marked like this.|
|Line 6:||Line 6:|
This document is intended to describe the process the Kernel Team uses to work on CVEs. It does not attemp to explain what a CVE is.
Where are the CVEs that need to be worked on?
There are several places where you can find a CVE to work upon. They are:
The Security Team's official page of kernel specific CVEs. This page is semi-automatically updated by members of the Security Team. Contact Kees Cook for more information
This page shows which CVEs are already beeing worked on by someone on the kernel team. It also shows the current progress on the CVE. It is the responsibility of every member of the Kernel Team to keep this spreadsheet up-to-date.
Go to the kernel team's CVE spreadsheet, pick out a CVE to work on and put your username in the "Assignee" column, next to the CVE you picked.
- Create a Launchpad Bug for the targeted CVE.
- Use the CVE id as the title for the bug.
- Use the Description from the CVE tracker link as the bug description.
- Add the tag: "kernel-cve-tracker"
Add the Launchpad Bug link to the kernel team's CVE spreadsheet in the Bug Number column for the CVE.
STEAM='lp:~ubuntu-security/ubuntu-cve-tracker/master' KTEAM='lp:~canonical-kernel-team/ubuntu-cve-tracker/kernel-team' To create the branch: * bzr branch $KTEAM In tracker branch (this syncing should probably be scripted): * bzr pull $KTEAM * bzr commit -m "Saving local changes" * bzr push $KTEAM * bzr missing -q --theirs-only --line $STEAM | tee ../msg If ../msg is not empty * bzr merge $STEAM * bzr commit -m "$(cat ../msg)" * bzr push $KTEAM After changing the anything in an active/CVE-* file !! WARNING: bzr includes *all* files changed in the branch dir to the commit * bzr commit -m "<this is my message to the world>" * bzr push $KTEAM Useful for cleaning up previous commit (commit undone, changes not) * bzr uncommit
Notes to be cleaned up:
- Save the patch to a file.
Go to the cve tracker page (http://people.canonical.com/~ubuntu-security/cve/pkg/linux.html)
- Follow the CVE link in the left column for the CVE you are working to the details page.
- Follow the link for "Patches: Upstream:" to the upstream git web commit
- Click the "patch" link in the top part of the page.
- Select "Save As" from your browser and save the patch.
- Modify the patch
- Add the buglink to the patch
- Add your sob to the patch
- Add the CVE number to the Subject line
- Add the CVE number to the bug comment body above the buglink
- Add the upstream commit from which the patch was either cherry-picked or backported above your s.o.b.
- Add a comment if the patch was accepted into one or more stable kernels.
- Create a LP bug
- Summary is the CVE id: "CVE-2010-XXXX"
- Mark the bug as a security bug
- Further information is taken from the patch commit description.
- Add the tag: "kernel-cve-tracker"
- Add "Link to CVE"
- Nominate for all supported releases.
- If the patch has already been applied to a release, mark that task "fixed-released"
- If the patch is not needed for a particular release it should be marked "invalid"
- For each release that the patch applies to:
- Set status to "Inprogress"
- Set Importance to "Low"
- Set "Assigned to" to yourself
- After applying the patch, add the patch as an attachment to the bug.
Topic branches typically get CVE updates whenever they are rebased against master. For those branches that are not normally rebased against master (such as ti-omap4), then CVEs must be extracted more or less manually from the master branch. Since those patches have already been vetted on the kernel team mailing list, a second round of acknowledgements is not required if they apply cleanly.