Kernel CVE Process

Registered by Kees Cook on 2011-04-27

Review of the requirements for Kernel and Security Teams when handling kernel CVEs.

Blueprint information

Status:
Not started
Approver:
Brad Figg
Priority:
High
Drafter:
Kees Cook
Direction:
Needs approval
Assignee:
Kees Cook
Definition:
Discussion
Series goal:
Accepted for oneiric
Implementation:
Informational Informational
Milestone target:
None

Related branches

Sprints

Whiteboard

One of the areas needing some improvement is the updating of the CVE information in the Security Teams CVE tracker database.

Now that the Kernel Team creates a unique bug for every CVE that they "fix", is there a way to just take the information from the bug and update the database from it? If there is not enough information in the bug as it exists today, what would need to be added to it to make it usable?

What triggers the creation of LP CVE bugs for the kernel? (I understood it to be from the ubuntu-cve-tracker bzr tree, as in, bug details were populated from u-c-t, not the other way around.)

1. A developer examines u-c-t (the Kernel Teams branch of same), and selects a CVE to work on.
2. The dev then goes to a google docs spreadsheet where they put their name next to the CVE they are going to work.
3. The dev runs "create-cve-tracker --cve=<cve-num>" which creates the LP bug.
4. The dev manually updates the LP bug description from the CVE text.
5. As the dev works the CVE, the status of the various nominated-series are updated.
6. The CVE patches are applied and the kernels are successfully built.
7. The u-c-t (the Kernel Teams branch of) is updated.
8. The patches are submitted to the kernel mailing list for review.
9. Reviewed patches are applied.
That's All Folks!

Information useful for security-team tracking is:
1. CVE name.
2. CVE description (ubuntu-cve-tracker will always use Mitre's description).
3. Priority
4. Reproducer (if any -- not tracked currently by ubuntu-cve-tracker).
5. Name of who discovered/reported it.
6. Upstream (or other sources of) commits that fix it. (Nice to have: upstream stable commits that fix it.)
7. Applicability to each supported Ubuntu kernel.
8. In which published supported Ubuntu kernel version the CVE was first fixed (i.e. non-published versions aren't interesting, just the first one that was actually published to the archive with the fix). (Nice to have: Ubuntu commits that fix it.)

LP cannot link to CVEs it hasn't already loaded from Mitre, so depending on LP for "2" above is not possible (but doesn't matter since u-c-t will always pull this from Mitre). There is no LP-specific field for "5", and "4" would, by it's nature, be free-form too. "6" can't be linked via LP, and LP does not track "8" in any field (it appears only as a comment during upload when setting "Fix Released"). LP does, however, allow for "3" and "6".

Finding a regular method (like maybe Apport's RFC822-style LP-description field/value pairs) to track 1, 5, 6, and 8 in LP would allow the security team to automatically sync from LP to the ubuntu-cve-tracker. If the goal is to remove u-c-t from Kernel Team process step 7, it should likely be removed from step 1 as well, in which case the security team should probably do step 3 (but as the first step), so that the Kernel Team looks for unassigned bugs tagged in a certain way? Not sure...

(?)

Work Items