| Message ID | 20230905072920.615-1-hayama@lineo.co.jp |
|---|---|
| State | Accepted, archived |
| Commit | 2064b2f9b92e2dff45dab633598b5ed37145d0b6 |
| Headers | show |
| Series | [1/3] linux/generate-cve-exclusions: fix mishandling of boundary values | expand |
On 5 Sep 2023, at 08:29, Yuta Hayama <hayama@lineo.co.jp> wrote: > > affected_versions in kernel_cves.json does not mean "first affected version > to last affected version" but actually "first affected version to fixed > version". Therefore, the variable names, conditional expressions, and > CVE_STATUS descriptions should be fixed. I’m happy to believe you on this, but do you have a source? Ross
Hi, On 2023/09/05 20:14, Ross Burton wrote: > On 5 Sep 2023, at 08:29, Yuta Hayama <hayama@lineo.co.jp> wrote: >> >> affected_versions in kernel_cves.json does not mean "first affected version >> to last affected version" but actually "first affected version to fixed >> version". Therefore, the variable names, conditional expressions, and >> CVE_STATUS descriptions should be fixed. > > I’m happy to believe you on this, but do you have a source? Unfortunately, I have not found any official explanation for this. All I know is what I wrote in the following message. And that is what I have been able to confirm empirically. https://lists.openembedded.org/g/openembedded-core/message/186994 I looked again to see if there is any information on this in the Linux Kernel CVEs official, but it seems that at best there is only a hint in the README.md in the git repository. https://github.com/nluedtke/linux_kernel_cves/blob/master/README.md >## Overview of Process > >The process for generating these documents is focused on being as >automated as possible. Below is the general outline of steps. > > 1) Take list of all kernel CVEs > 2) If the issue is marked as Vendor specific, ignore it. > 3) Get the Breaking/Fixing Commits. This is retrieved from the > internal cache first, if not present it pulls from Ubuntu, Debian, > etc to try and fill that information in. > 4) Using those commit ids, get the first tags in the mainline that > they appear. > 5) Using that version timeline, for each stream that would be > vulnerable perform steps 6 through 8. > 6) Find the commit who has the commit message that matches the commit > message from the mainline. This is the fixing commit in that stream. > 7) Record the commit id and get the earliest tag in the stream which > has that commit. > 8) Output information to stream document. > 9) Update JSONs. In 4), it says to look for the tag where the breaking/fixing commits first appears, so we can assume that this is looking for the fixed version, not the last affected version. Well, it doesn't say which field in the json that would be... In addition, there seems to be a key "last_affected_version" in kernel_cves.json. I have no idea how this is obtained, but it seems to literally represent the "last affected version", unlike the second value of "affected_versions". Regards, Yuta Hayama
On 6 Sep 2023, at 02:53, Yuta Hayama <hayama@lineo.co.jp> wrote: > > Hi, > > On 2023/09/05 20:14, Ross Burton wrote: >> On 5 Sep 2023, at 08:29, Yuta Hayama <hayama@lineo.co.jp> wrote: >>> >>> affected_versions in kernel_cves.json does not mean "first affected version >>> to last affected version" but actually "first affected version to fixed >>> version". Therefore, the variable names, conditional expressions, and >>> CVE_STATUS descriptions should be fixed. >> >> I’m happy to believe you on this, but do you have a source? > > Unfortunately, I have not found any official explanation for this. All I know > is what I wrote in the following message. And that is what I have been able to > confirm empirically. > > https://lists.openembedded.org/g/openembedded-core/message/186994 Based on that evidence you appear to be right, yes. I’ve just mailed the maintainer of the JSON to see if he’d like to make a statement either way. Cheers, Ross
On 6 Sep 2023, at 13:30, Ross Burton via lists.openembedded.org <ross.burton=arm.com@lists.openembedded.org> wrote: >>> On 5 Sep 2023, at 08:29, Yuta Hayama <hayama@lineo.co.jp> wrote: >>>> >>>> affected_versions in kernel_cves.json does not mean "first affected version >>>> to last affected version" but actually "first affected version to fixed >>>> version". Therefore, the variable names, conditional expressions, and >>>> CVE_STATUS descriptions should be fixed. >>> >>> I’m happy to believe you on this, but do you have a source? >> >> Unfortunately, I have not found any official explanation for this. All I know >> is what I wrote in the following message. And that is what I have been able to >> confirm empirically. >> >> https://lists.openembedded.org/g/openembedded-core/message/186994 > > Based on that evidence you appear to be right, yes. I’ve just mailed the maintainer of the JSON to see if he’d like to make a statement either way. I got a reply: "The code takes the breaking_cmt to fixing_cmt. So it would be First Affected version to First Fixed version in the mainline.” Yes, you’re correct. Ross
On 2023/09/08 19:57, Ross Burton via lists.openembedded.org wrote: > On 6 Sep 2023, at 13:30, Ross Burton via lists.openembedded.org <ross.burton=arm.com@lists.openembedded.org> wrote: >>>> On 5 Sep 2023, at 08:29, Yuta Hayama <hayama@lineo.co.jp> wrote: >>>>> >>>>> affected_versions in kernel_cves.json does not mean "first affected version >>>>> to last affected version" but actually "first affected version to fixed >>>>> version". Therefore, the variable names, conditional expressions, and >>>>> CVE_STATUS descriptions should be fixed. >>>> >>>> I’m happy to believe you on this, but do you have a source? >>> >>> Unfortunately, I have not found any official explanation for this. All I know >>> is what I wrote in the following message. And that is what I have been able to >>> confirm empirically. >>> >>> https://lists.openembedded.org/g/openembedded-core/message/186994 >> >> Based on that evidence you appear to be right, yes. I’ve just mailed the maintainer of the JSON to see if he’d like to make a statement either way. > > I got a reply: > > "The code takes the breaking_cmt to fixing_cmt. So it would be First Affected version to First Fixed version in the mainline.” > > Yes, you’re correct. Thank you, Ross. I am relieved to hear that I was not mistaken. Also, thank you to the maintainers for applying the patch to the master. Yuta Hayama
diff --git a/meta/recipes-kernel/linux/generate-cve-exclusions.py b/meta/recipes-kernel/linux/generate-cve-exclusions.py index 3bc1c7096f..b936f843e2 100755 --- a/meta/recipes-kernel/linux/generate-cve-exclusions.py +++ b/meta/recipes-kernel/linux/generate-cve-exclusions.py @@ -62,17 +62,17 @@ do_cve_check[prefuncs] += "check_kernel_cve_status_version" continue affected = data["affected_versions"] - first_affected, last_affected = re.search(r"(.+) to (.+)", affected).groups() + first_affected, fixed = re.search(r"(.+) to (.+)", affected).groups() first_affected = parse_version(first_affected) - last_affected = parse_version(last_affected) + fixed = parse_version(fixed) - if not last_affected: + if not fixed: print(f"# {cve} has no known resolution") elif first_affected and version < first_affected: print(f'CVE_STATUS[{cve}] = "fixed-version: only affects {first_affected} onwards"') - elif last_affected < version: + elif fixed <= version: print( - f'CVE_STATUS[{cve}] = "fixed-version: Fixed after version {last_affected}"' + f'CVE_STATUS[{cve}] = "fixed-version: Fixed from version {fixed}"' ) else: if cve in stream_data: @@ -87,9 +87,9 @@ do_cve_check[prefuncs] += "check_kernel_cve_status_version" # TODO print a note that the kernel needs bumping print(f"# {cve} needs backporting (fixed from {backport_ver})") else: - print(f"# {cve} needs backporting (fixed from {last_affected})") + print(f"# {cve} needs backporting (fixed from {fixed})") else: - print(f"# {cve} needs backporting (fixed from {last_affected})") + print(f"# {cve} needs backporting (fixed from {fixed})") print()
affected_versions in kernel_cves.json does not mean "first affected version to last affected version" but actually "first affected version to fixed version". Therefore, the variable names, conditional expressions, and CVE_STATUS descriptions should be fixed. For example, when the script was run against v6.1, if affected_versions was "xxx to 6.1", the output was "cpe-stable-backport: Backported in 6.1", but this should be "fixed-version: Fixed from version 6.1". Signed-off-by: Yuta Hayama <hayama@lineo.co.jp> --- .../linux/generate-cve-exclusions.py | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-)