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:

Security Team CVE Tracker

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

Kernel Team CVE Tracker

The kernel team specific version of the above, updated more frequently, using a branch of the above data. This branch is merged with the official Security Teams CVE tracker database.

Kernel Team

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.


  1. Pick a CVE to work on.
    1. 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.

  2. Save the patch to a file.
    1. Go to the cve tracker page (

    2. Follow the CVE link in the left column for the CVE you are working to the details page.
    3. Follow the link for "Patches: Upstream:" to the upstream git web commit
    4. Click the "patch" link in the top part of the page.
    5. Select "Save As" from your browser and save the patch.
  3. Create a LP bug.
    1. Use the "create-cve-tracker" tool. Note the cve-id is "20xx-xxxx", it does not include the "CVE-" text. For example:
         create-cve-tracker --cve=2010-4079
    2. The bug description should be updated with information taken from the patch commit description.
    3. As you work the bug on each distro series indicate in the appropriate task the relevance of the patch to that series. For example:
      • If the bug has already been applied, mark that series task as "Fix Released".
      • If the patch is not relevant to that series, mark the task as "Invalid".
      • If the patch is valid and has not been applied already (via a stable upstream release) then:
        1. Mark the status as "In Progress"
        2. Mark the importance as the same as the CVE priority
        3. Assign yourself to the task.
  4. Add the Launchpad Bug link to the kernel team's CVE spreadsheet in the Bug Number column for the CVE.

  5. Modify the patch, prior to applying the patch. The maint-modify-patch script in kteam-tools is handy for adding these changes to the patch file. See the --help for all the command line options and examples.

    1. Add the buglink to the patch
         maint-modify-patch --bug=123456
    2. Add your sob to the patch
         maint-modify-patch --sob=bjf
    3. Add the CVE number to the Subject line
    4. Add the CVE number to the bug comment body above the buglink
         maint-modify-patch --cve=2011-1234
    5. Add the upstream commit from which the patch was either cherry-picked or backported above your s.o.b.
         maint-modify-patch --cp=<SHA1>
    6. Add a comment if the patch was accepted into one or more stable kernels.
  6. Apply the patch.
    1. Clone a copy of the appropriate series repo.
    2. If the series repo contains a "master-next" branch, that is where you should be working. That contains the most up-do-date set of commits including stable upstream release commits that have been applied since the start of the last Kernel SRU cycle.
    3. Determine if the patch should be applied.
    4. Apply the patch.
         git am <the patch file>
    5. If the patch does not apply cleanly for any reason, create a copy of the original patch file, making whatever necessary changes there. You will want to keep separate patch files for each series.
    6. Do a test build of a kernel with your patch.
    7. If at all possible, boot test the test kernel.
  7. Add the patches to the LP tracking bug as attachments.
  8. Email the patches to the Kernel Team mailing list for review.
    1. There should be a separate email for each unique patch. If a single patch applies without changes to multiple series then you'd just send one email for that patch.
    2. The subject line of the patches email *must* contain the series that it applies to and the CVE number.
  9. Update the Security Team's CVE tracking data for the CVE.
    1. Personally, I don't mess with trying to merge with the security team's tree. I checkout a new copy of the kernel team tree, make the appropriate changes for the one CVE that i've completed and push those changes back to the kernel teams tree.
    2. Also, for the ubuntu-cve-tracker and upstream "released" versions: use "~" instead of "-" when specifying an rc release. i.e. 2.6.39~rc1 instead of 2.6.39-rc1. It's just regular debian-style versioning, 2.6.39-rc1 > 2.6.39 which isn't the intention.

    3. The following give you some idea of the commands you need to use to update the tracking data.
         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

NOTE: 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.

Kernel/Dev/FixingCVEs (last edited 2011-05-18 22:25:50 by brad-figg)