Merge ~rodrigo-zaiden/ubuntu-cve-tracker:kernel_cna_cves_usn into ubuntu-cve-tracker:master
Status: | Needs review |
---|---|
Proposed branch: | ~rodrigo-zaiden/ubuntu-cve-tracker:kernel_cna_cves_usn |
Merge into: | ubuntu-cve-tracker:master |
Diff against target: |
458 lines (+302/-12) 8 files modified
README.linux (+7/-3) meta_lists/kernel_paths_overrides.json (+93/-0) scripts/cve_lib.py (+4/-6) scripts/kernel_lib.py (+100/-1) scripts/prepare-kernel-usn.py (+8/-1) scripts/pull-usn-desc.py (+8/-0) scripts/sis-generate-usn (+52/-0) scripts/test_kernel_lib.py (+30/-1) |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Alex Murray | Approve | ||
Steve Beattie | Pending | ||
Review via email: mp+462266@code.launchpad.net |
Commit message
scripts: kernel: add automation to generate kernel USN
adding a new parameter: '--kernel-cna-cves' that, when used, will automatically
find which CVEs where published by the Kernel CNA and will generate a standard
paragraph for the USN based on the affected subsystems in the Linux kernel based
on the fix commits for each CVE.
Description of the change
When the Kernel CNA started to publish Linux Kernel CVEs, we noticed that a
big amount of new CVEs are coming each day. With that, it is much harder to
keep track of the USN descriptions as we were used to.
So, the idea with this series of commits, is that, when we want to generate
a Kernel USN with the script 'prepare-
argument '--kernel-cna-cves' that will go over the CVEs that would be included
in the Kernel USN and will check which were published by the Kernel CNA and will
add a standard paragraph will the affected subsystems.
It sounds like:
Several security issues were discovered in the Linux kernel.
An attacker could possibly use these to compromise the system.
This update corrects flaws in the following subsystems:
- Architecture specifics;
- Block layer;
- ACPI drivers;
....
A few more detailed information on how it works in this proposal:
- It starts with passing '--kernel-cna-cves' to 'prepare-
./scripts/
- It them invokes the 'sis-generate-usn' script passing along the argument
--kernel-
1) it check which CVEs that were found being fixed in this kernel release
were published by the Kernel CNA by trying to verify if the CVE file exists
in the https:/
It checks locally if the repository is cloned (more information on that
was added to README.linux) and if it does not find it locally it checks
on the repository online: the local repository could be outdated, or it
really does not exist. This is implemented in cve_lib.py in the method
is_
2) it them checks which are the fix commits for the CVEs, implemented in
cve_lib.py in method get_kernel_
3) it finally look for the affected subsystems based on the fix commit on a
kernel repository local tree. If the repo is not found, it returns an error.
This is in cve_lib.py in method get_affected_
With the affected subsystems in hand, it generated the paragraph with the
template above. In get_affected_
subsystem paths based on the kernel hierarchy that translates the directory
into human readable/
A way to run this for current kernels is:
./scripts/
or, check the pastebins to see how the script is outputing in stdout and in the USN bash for the above command:
prepare-kernel-usn log: https:/
USN bash script: https:/
Unmerged commits
- 6c3a721... by Rodrigo Figueiredo Zaiden
-
unit-tests:0 (build) check-cves:0 (build) check-cve-website-state:0 (build) 1 → 3 of 3 results First • Previous • Next • Last - 744be15... by Rodrigo Figueiredo Zaiden
- ebd52c4... by Rodrigo Figueiredo Zaiden
- e72bfae... by Rodrigo Figueiredo Zaiden
- 0667c23... by Rodrigo Figueiredo Zaiden
- c48b7bc... by Rodrigo Figueiredo Zaiden
- f16b003... by Rodrigo Figueiredo Zaiden
- 56c577d... by Rodrigo Figueiredo Zaiden
- 39b463c... by Rodrigo Figueiredo Zaiden
- a70f0a6... by Rodrigo Figueiredo Zaiden
This sounds like a great quality-of-life improvement for doing kernel USNs - I wonder though if instead of hard-coding the mapping of subsystem paths to descriptions, whether you could use the contents of MAINTAINERS (via ./scripts/ get_maintainer. pl --subsystem -f $path) and then fallback to this if needed?