From 33eb916cc93b9efb7529c44717712f65cd5602f7 Mon Sep 17 00:00:00 2001 From: Nathan Gilbert Date: Mon, 6 Nov 2023 14:56:46 -0500 Subject: [PATCH 1/7] initial commit setting curation level to 2 --- cves/kernel/CVE-2013-3302.yml | 2 +- cves/kernel/CVE-2016-8630.yml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/cves/kernel/CVE-2013-3302.yml b/cves/kernel/CVE-2013-3302.yml index 8b4ec3989..a776be882 100644 --- a/cves/kernel/CVE-2013-3302.yml +++ b/cves/kernel/CVE-2013-3302.yml @@ -19,7 +19,7 @@ curated_instructions: | This will enable additional editorial checks on this file to make sure you fill everything out properly. If you are a student, we cannot accept your work as finished unless curated is properly updated. -curation_level: 0 +curation_level: 2 reported_instructions: | What date was the vulnerability reported to the security team? Look at the security bulletins and bug reports. It is not necessarily the same day that diff --git a/cves/kernel/CVE-2016-8630.yml b/cves/kernel/CVE-2016-8630.yml index 354e56618..09797631b 100644 --- a/cves/kernel/CVE-2016-8630.yml +++ b/cves/kernel/CVE-2016-8630.yml @@ -19,7 +19,7 @@ curated_instructions: | This will enable additional editorial checks on this file to make sure you fill everything out properly. If you are a student, we cannot accept your work as finished unless curated is properly updated. -curation_level: 0 +curation_level: 2 reported_instructions: | What date was the vulnerability reported to the security team? Look at the security bulletins and bug reports. It is not necessarily the same day that From a3ef35145735d64635f2b6fd950f99f97d4300e0 Mon Sep 17 00:00:00 2001 From: Nathan Gilbert Date: Mon, 6 Nov 2023 17:42:50 -0500 Subject: [PATCH 2/7] Modified CVE-2026-8630 with details --- cves/kernel/CVE-2013-3302.yml | 2 +- cves/kernel/CVE-2016-8630.yml | 139 +++++++++++++++++++++++----------- 2 files changed, 97 insertions(+), 44 deletions(-) diff --git a/cves/kernel/CVE-2013-3302.yml b/cves/kernel/CVE-2013-3302.yml index a776be882..8b4ec3989 100644 --- a/cves/kernel/CVE-2013-3302.yml +++ b/cves/kernel/CVE-2013-3302.yml @@ -19,7 +19,7 @@ curated_instructions: | This will enable additional editorial checks on this file to make sure you fill everything out properly. If you are a student, we cannot accept your work as finished unless curated is properly updated. -curation_level: 2 +curation_level: 0 reported_instructions: | What date was the vulnerability reported to the security team? Look at the security bulletins and bug reports. It is not necessarily the same day that diff --git a/cves/kernel/CVE-2016-8630.yml b/cves/kernel/CVE-2016-8630.yml index 09797631b..0291e8b89 100644 --- a/cves/kernel/CVE-2016-8630.yml +++ b/cves/kernel/CVE-2016-8630.yml @@ -26,7 +26,7 @@ reported_instructions: | the CVE was created. Leave blank if no date is given. Please enter your date in YYYY-MM-DD format. -reported_date: +reported_date: '2016-11-28' announced_instructions: | Was there a date that this vulnerability was announced to the world? You can find this in changelogs, blogs, bug reports, or perhaps the CVE date. @@ -55,7 +55,13 @@ description_instructions: | Your target audience is people just like you before you took any course in security -description: +description: | + This CVE is a security issue in the Linux operating system's kernel. + This issue allowed the Linux system to crash or stop working properly. + This issue could be triggered by someone using a certain command that + the code to access a part of memory that does not exist. This causes + the system to become unresponsive. A fix was developed by RedHat to + prevent this issue from causing problems in Linux. bounty_instructions: | If you came across any indications that a bounty was paid out for this vulnerability, fill it out here. Or correct it if the information already here @@ -75,7 +81,7 @@ bugs_instructions: | * Mentioned in mailing list discussions * References from NVD entry * Various other places -bugs: [] +bugs: ["https://github.com/torvalds/linux/commit/41061cdb98a0bec464278b4db8e894a3121671f5".] fixes_instructions: | Please put the commit hash in "commit" below. @@ -84,10 +90,6 @@ fixes_instructions: | Place any notes you would like to make in the notes field. fixes: -- commit: - note: -- commit: - note: - commit: d9092f52d7e61dd1557f2db2400ddb430e85937e note: | Taken from NVD references list with Git commit. If you are @@ -114,7 +116,7 @@ upvotes_instructions: | upvotes to each vulnerability you see. Your peers will tell you how interesting they think this vulnerability is, and you'll add that to the upvotes score on your branch. -upvotes: +upvotes: 1 unit_tested: question: | Were automated unit tests involved in this vulnerability? @@ -129,10 +131,14 @@ unit_tested: For the fix_answer below, check if the fix for the vulnerability involves adding or improving an automated test to ensure this doesn't happen again. - code: - code_answer: - fix: - fix_answer: + code: false + code_answer: | + I was unable to find any unit tests for this module. It does not seem like + any automated tests were made to ensure this does not happen again. + fix: false + fix_answer: | + I was unable to find any unit tests for this module. It does not seem like + any automated tests were made to ensure this does not happen again. discovered: question: | How was this vulnerability discovered? @@ -147,10 +153,17 @@ discovered: If there is no evidence as to how this vulnerability was found, then please explain where you looked. - answer: - automated: - contest: - developer: + answer: | + Searching through the bug report + (https://bugzilla.redhat.com/show_bug.cgi?id=1393350) as well as the GitHub + (https://github.com/torvalds/linux/commit/d9092f52d7e61dd1557f2db2400ddb430e85937e) + and change log (https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.8.7) + I could not determine how this vulnerability was discovered. It could have been + detected early via a code-review or detected later without saying how the vulnerability + was discovered. There is not evidence either way. + automated: nil + contest: nil + developer: nil autodiscoverable: instructions: | Is it plausible that a fully automated tool could have discovered @@ -167,8 +180,16 @@ autodiscoverable: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: - answer: + note: | + As the vulnerability was an example of improper access control and NULL + pointer dereference, fuzzer tools, static analysis tools and compiler + warnings all could highlight potential issues when it comes to NULL pointer + dereferences. Fuzzers can identify unexpected behavior caused by NULL pointer + dereferences. Static analysis tools can identify code paths that could lead + to null pointer dereferences, and compiler warnings can highlight potential + issues in the developers code where potential NULL pointer dereferences + could occur. + answer: true specification: instructions: | Is there mention of a violation of a specification? For example, the POSIX @@ -184,8 +205,10 @@ specification: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: - answer: + note: | + Looking through the all the artifacts I could find I did not find + any that mentioned a violation. + answer: false subsystem: question: | What subsystems was the mistake in? These are WITHIN linux kernel @@ -219,8 +242,10 @@ subsystem: e.g. name: ["subsystemA", "subsystemB"] # ok name: subsystemA # also ok - name: - note: + name: x86 + note: | + Looking at the file path on github. + (https://github.com/torvalds/linux/commit/d9092f52d7e61dd1557f2db2400ddb430e85937e) interesting_commits: question: | Are there any interesting commits between your VCC(s) and fix(es)? @@ -251,8 +276,11 @@ i18n: Answer should be true or false Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: + answer: false + note: | + The vulnerability does not relate to internationalization features in the + Linux kernel. The main vulnerability focuses on a NULL pointer dereference + flaw when the KVM is enabled on the x86 platform. sandbox: question: | Did this vulnerability violate a sandboxing feature that the system @@ -266,8 +294,11 @@ sandbox: Answer should be true or false Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: + answer: false + note: | + This vulnerability does not violate a sandboxing feature. The issue is only + due to a NULL pointer dereference due to a failure to check before + dereferencing. ipc: question: | Did the feature that this vulnerability affected use inter-process @@ -278,8 +309,11 @@ ipc: Answer must be true or false. Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: + answer: false + note: | + This vulnerability is not affected by inter-process communication. The + issue is only due to a NULL pointer dereference due to a failure to check + before dereferencing. discussion: question: | Was there any discussion surrounding this? @@ -305,9 +339,10 @@ discussion: Put any links to disagreements you found in the notes section, or any other comment you want to make. - discussed_as_security: - any_discussion: - note: + discussed_as_security: false + any_discussion: false + note: There were no discussions I could find + vouch: question: | Was there any part of the fix that involved one person vouching for @@ -320,8 +355,12 @@ vouch: Answer must be true or false. Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: + answer: true + note: | + The commit that fixed the issue was signed off by Owen Hofmann , + Paolo Bonzini , and Greg Kroah-Hartman + on Nov 10th 2016 Commit ID: + (0c879624701dc719022950552227516ac87a10d5). stacktrace: question: | Are there any stacktraces in the bug reports? @@ -335,9 +374,10 @@ stacktrace: Answer must be true or false. Write a note about how you came to the conclusions you did, regardless of what your answer was. - any_stacktraces: - stacktrace_with_fix: - note: + any_stacktraces: false + stacktrace_with_fix: fa;se + note: | + I checked the changelog and github commits and could not find a stacktrace. forgotten_check: question: | Does the fix for the vulnerability involve adding a forgotten check? @@ -356,8 +396,11 @@ forgotten_check: Answer must be true or false. Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: + answer: true + note: | + The commit that added the issue was a fix to the conditional removing + other checks, which caused the issue. The fix added a check for memopp + before dereference to prevent a NULL pointer dereference. order_of_operations: question: | Does the fix for the vulnerability involve correcting an order of @@ -369,8 +412,11 @@ order_of_operations: Answer must be true or false. Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: + answer: false + note: | + I do not think this fix involved correcting the order of operations. All + that was changed was an additional check in an if statement that checks + for memopp before dereferencing. lessons: question: | Are there any common lessons we have learned from class that apply to this @@ -448,7 +494,14 @@ mistakes: Write a thoughtful entry here that people in the software engineering industry would find interesting. - answer: + answer: | + The commit that caused this issue was a “fix” to the code that was originally + there. The commit message ("KVM: emulate: do not initialize memopp") removes + a check for non-NULL under incorrect assumptions. An undefined instruction + with a ModR/M byte with Mod=0 and R/M-5 (e.g. 0xc7 0x15) will attempt to + dereference a null pointer here. This seems to have been a mistake in + understanding how the code worked or what assumptions were incorrect. + CWE_instructions: | Please go to http://cwe.mitre.org and find the most specific, appropriate CWE entry that describes your vulnerability. We recommend going to @@ -465,7 +518,7 @@ CWE_instructions: | CWE: [123, 456] # also ok CWE: 123 # also ok CWE: -- 284 +- ["284", "476"] CWE_note: | CWE as registered in the NVD. If you are curating, check that this is correct and replace this comment with "Manually confirmed". @@ -473,5 +526,5 @@ nickname_instructions: | A catchy name for this vulnerability that would draw attention it. If the report mentions a nickname, use that. Must be under 30 characters. Optional. -nickname: +nickname: KernelCrash8630 CVSS: From eeca98fbf342811c24b71f7844169b957314505b Mon Sep 17 00:00:00 2001 From: Nathan Gilbert Date: Mon, 6 Nov 2023 17:47:11 -0500 Subject: [PATCH 3/7] Potential Fix to YAML --- cves/kernel/CVE-2016-8630.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cves/kernel/CVE-2016-8630.yml b/cves/kernel/CVE-2016-8630.yml index 0291e8b89..7ac763c9d 100644 --- a/cves/kernel/CVE-2016-8630.yml +++ b/cves/kernel/CVE-2016-8630.yml @@ -81,7 +81,7 @@ bugs_instructions: | * Mentioned in mailing list discussions * References from NVD entry * Various other places -bugs: ["https://github.com/torvalds/linux/commit/41061cdb98a0bec464278b4db8e894a3121671f5".] +bugs: ["https://github.com/torvalds/linux/commit/41061cdb98a0bec464278b4db8e894a3121671f5"] fixes_instructions: | Please put the commit hash in "commit" below. From 4832371225e9d22a4d29190491b71b9936af57a4 Mon Sep 17 00:00:00 2001 From: Nathan Gilbert Date: Mon, 6 Nov 2023 17:53:22 -0500 Subject: [PATCH 4/7] Potential fix to level 2 compliance --- cves/kernel/CVE-2016-8630.yml | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/cves/kernel/CVE-2016-8630.yml b/cves/kernel/CVE-2016-8630.yml index 7ac763c9d..fcb6a4395 100644 --- a/cves/kernel/CVE-2016-8630.yml +++ b/cves/kernel/CVE-2016-8630.yml @@ -161,9 +161,9 @@ discovered: I could not determine how this vulnerability was discovered. It could have been detected early via a code-review or detected later without saying how the vulnerability was discovered. There is not evidence either way. - automated: nil - contest: nil - developer: nil + automated: false + contest: false + developer: false autodiscoverable: instructions: | Is it plausible that a fully automated tool could have discovered @@ -205,7 +205,7 @@ specification: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: | + answer_note: | Looking through the all the artifacts I could find I did not find any that mentioned a violation. answer: false @@ -375,7 +375,7 @@ stacktrace: Write a note about how you came to the conclusions you did, regardless of what your answer was. any_stacktraces: false - stacktrace_with_fix: fa;se + stacktrace_with_fix: false note: | I checked the changelog and github commits and could not find a stacktrace. forgotten_check: From cff6b62c39872be0084afa73d73a4ca8f00e9556 Mon Sep 17 00:00:00 2001 From: Nathan Gilbert Date: Mon, 6 Nov 2023 17:57:37 -0500 Subject: [PATCH 5/7] Fix to yaml --- cves/kernel/CVE-2016-8630.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cves/kernel/CVE-2016-8630.yml b/cves/kernel/CVE-2016-8630.yml index fcb6a4395..f0989e1be 100644 --- a/cves/kernel/CVE-2016-8630.yml +++ b/cves/kernel/CVE-2016-8630.yml @@ -205,7 +205,7 @@ specification: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - answer_note: | + note: | Looking through the all the artifacts I could find I did not find any that mentioned a violation. answer: false From b8bb8d5fd5243132c8e6ff373d47b501a3c869b1 Mon Sep 17 00:00:00 2001 From: Nathan Gilbert Date: Tue, 7 Nov 2023 15:20:10 -0500 Subject: [PATCH 6/7] Updated CVE-2013-3302 with details --- cves/kernel/CVE-2013-3302.yml | 181 ++++++++++++++++++++++------------ cves/kernel/CVE-2016-8630.yml | 35 ++++--- 2 files changed, 139 insertions(+), 77 deletions(-) diff --git a/cves/kernel/CVE-2013-3302.yml b/cves/kernel/CVE-2013-3302.yml index 8b4ec3989..83d574b29 100644 --- a/cves/kernel/CVE-2013-3302.yml +++ b/cves/kernel/CVE-2013-3302.yml @@ -19,14 +19,14 @@ curated_instructions: | This will enable additional editorial checks on this file to make sure you fill everything out properly. If you are a student, we cannot accept your work as finished unless curated is properly updated. -curation_level: 0 +curation_level: 2 reported_instructions: | What date was the vulnerability reported to the security team? Look at the security bulletins and bug reports. It is not necessarily the same day that the CVE was created. Leave blank if no date is given. Please enter your date in YYYY-MM-DD format. -reported_date: +reported_date: "2013-04-15" announced_instructions: | Was there a date that this vulnerability was announced to the world? You can find this in changelogs, blogs, bug reports, or perhaps the CVE date. @@ -34,11 +34,11 @@ announced_instructions: | This is not the same as published date in the NVD - that is below. Please enter your date in YYYY-MM-DD format. -announced_date: '2013-04-29' +announced_date: "2013-04-29" published_instructions: | Is there a published fix or patch date for this vulnerability? Please enter your date in YYYY-MM-DD format. -published_date: '2013-04-29' +published_date: "2013-04-29" description_instructions: | You can get an initial description from the CVE entry on cve.mitre.org. These descriptions are a fine start, but they can be kind of jargony. @@ -55,7 +55,13 @@ description_instructions: | Your target audience is people just like you before you took any course in security -description: +description: | + This CVE is a security issue in the Linux operating system's kernel. + This issue allowed the Linux system to crash or stop working properly. + This issue is caused by a race condition where processes are competing + for access for a resource that cannot be shared. If the respource is + reached by two processes it can cause a crash from a NULL pointer + dereference or potentially open the system up to other security issues. bounty_instructions: | If you came across any indications that a bounty was paid out for this vulnerability, fill it out here. Or correct it if the information already here @@ -84,14 +90,10 @@ fixes_instructions: | Place any notes you would like to make in the notes field. fixes: -- commit: - note: -- commit: - note: -- commit: ea702b80e0bbb2448e201472127288beb82ca2fe - note: | - Taken from NVD references list with Git commit. If you are - curating, please fact-check that this commit fixes the vulnerability and replace this comment with 'Manually confirmed' + - commit: ea702b80e0bbb2448e201472127288beb82ca2fe + note: | + Taken from NVD references list with Git commit. If you are + curating, please fact-check that this commit fixes the vulnerability and replace this comment with 'Manually confirmed' vcc_instructions: | The vulnerability-contributing commits. @@ -105,14 +107,14 @@ vcc_instructions: | Place any notes you would like to make in the notes field. vccs: -- commit: 6f49f46b187df34539f1e5df2469b8a541897700 - note: Discovered automatically by archeogit. -- commit: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 - note: Discovered automatically by archeogit. -- commit: b8eed28375a43e1c9aaa9d15af2a052aae0d0725 - note: Discovered automatically by archeogit. -- commit: 3e84469d0101456caceffc6b22218a49017fcd3f - note: Discovered automatically by archeogit. + - commit: 6f49f46b187df34539f1e5df2469b8a541897700 + note: Discovered automatically by archeogit. + - commit: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 + note: Discovered automatically by archeogit. + - commit: b8eed28375a43e1c9aaa9d15af2a052aae0d0725 + note: Discovered automatically by archeogit. + - commit: 3e84469d0101456caceffc6b22218a49017fcd3f + note: Discovered automatically by archeogit. upvotes_instructions: | For the first round, ignore this upvotes number. @@ -120,7 +122,7 @@ upvotes_instructions: | upvotes to each vulnerability you see. Your peers will tell you how interesting they think this vulnerability is, and you'll add that to the upvotes score on your branch. -upvotes: +upvotes: 0 unit_tested: question: | Were automated unit tests involved in this vulnerability? @@ -135,10 +137,14 @@ unit_tested: For the fix_answer below, check if the fix for the vulnerability involves adding or improving an automated test to ensure this doesn't happen again. - code: - code_answer: - fix: - fix_answer: + code: false + code_answer: | + I was unable to find any unit tests for this module. It does not seem like + any automated tests were made to ensure this does not happen again. + fix: false + fix_answer: | + I was unable to find any unit tests for this module. It does not seem like + any automated tests were made to ensure this does not happen again. discovered: question: | How was this vulnerability discovered? @@ -153,10 +159,13 @@ discovered: If there is no evidence as to how this vulnerability was found, then please explain where you looked. - answer: - automated: - contest: - developer: + answer: | + The commit that fixed the vulnerability states the vulnerability was + reported and tested by CAI Qian but no date is + stated. + automated: false + contest: false + developer: true autodiscoverable: instructions: | Is it plausible that a fully automated tool could have discovered @@ -173,8 +182,15 @@ autodiscoverable: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: - answer: + note: | + As the vulnerability was an example of race condition and NULL + pointer dereference, fuzzer tools, static analysis tools and Stress testing + all could highlight potential issues when it comes to race conditions and NULL pointer + dereferences. Fuzzers can identify unexpected behavior caused by a race condtion as well as NULL pointer + dereferences. Static analysis tools can identify code paths that could lead + to race condtions and null pointer dereferences, and stress testing can highlight potential + issues of race condtions by mimicing real-world scenerios and usages. + answer: true specification: instructions: | Is there mention of a violation of a specification? For example, the POSIX @@ -190,8 +206,11 @@ specification: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: - answer: + note: | + In one of the bug reports they specify that the issue of the race condition + can cause NULL pointer dereferences as well as open the system up for other + issues. (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-3302, https://www.openwall.com/lists/oss-security/2013/04/15/2) + answer: true subsystem: question: | What subsystems was the mistake in? These are WITHIN linux kernel @@ -225,8 +244,10 @@ subsystem: e.g. name: ["subsystemA", "subsystemB"] # ok name: subsystemA # also ok - name: - note: + name: ["sf", "cifs"] + note: | + Looking at the file path on github. + (https://github.com/torvalds/linux/commit/ea702b80e0bbb2448e201472127288beb82ca2fe) interesting_commits: question: | Are there any interesting commits between your VCC(s) and fix(es)? @@ -241,10 +262,10 @@ interesting_commits: * Other commits that fixed a similar issue as this vulnerability * Anything else you find interesting. commits: - - commit: - note: - - commit: - note: + - commit: + note: + - commit: + note: i18n: question: | Was the feature impacted by this vulnerability about internationalization @@ -257,8 +278,11 @@ i18n: Answer should be true or false Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: + answer: false + note: | + The vulnerability does not relate to internationalization features in the + Linux kernel. The main vulnerability focuses on a race condition that can + cause a failure in the system and open up to a NULL pointer dereference. sandbox: question: | Did this vulnerability violate a sandboxing feature that the system @@ -272,8 +296,11 @@ sandbox: Answer should be true or false Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: + answer: false + note: | + This vulnerability does not violate a sandboxing feature. The issue is only + due to a race condition that can cause a failure in the system and open up + to a NULL pointer dereference. ipc: question: | Did the feature that this vulnerability affected use inter-process @@ -284,8 +311,11 @@ ipc: Answer must be true or false. Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: + answer: true + note: | + The feature that this vulnerability is caused by is a race condition that + the ssocket is NULL when the system tries to connect. The code checks to see + if the ssocket is available too late causing it to fail. discussion: question: | Was there any discussion surrounding this? @@ -311,9 +341,12 @@ discussion: Put any links to disagreements you found in the notes section, or any other comment you want to make. - discussed_as_security: - any_discussion: - note: + discussed_as_security: false + any_discussion: false + note: | + There are notes on the commit that fixes the issue but I could not find any + discussion regarding the issues brought up. + (https://github.com/torvalds/linux/commit/ea702b80e0bbb2448e201472127288beb82ca2fe) vouch: question: | Was there any part of the fix that involved one person vouching for @@ -326,8 +359,11 @@ vouch: Answer must be true or false. Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: + answer: true + note: | + The commit that fixed the issue was signed off by Steve French , + on Dec 30th 2012 Commit ID: + (ea702b80e0bbb2448e201472127288beb82ca2fe). stacktrace: question: | Are there any stacktraces in the bug reports? @@ -341,9 +377,10 @@ stacktrace: Answer must be true or false. Write a note about how you came to the conclusions you did, regardless of what your answer was. - any_stacktraces: - stacktrace_with_fix: - note: + any_stacktraces: false + stacktrace_with_fix: false + note: | + I checked the changelog and github commits and could not find a stacktrace. forgotten_check: question: | Does the fix for the vulnerability involve adding a forgotten check? @@ -362,8 +399,12 @@ forgotten_check: Answer must be true or false. Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: + answer: false + note: | + Although this fix invloves a if statement. The correction to the issue was not + adding a missing check but to move the if statement to a better place where it + will check for a module to be NULL early instead of later where it could be too + late causing a race condition and potentially a NULL pointer dereference. order_of_operations: question: | Does the fix for the vulnerability involve correcting an order of @@ -375,8 +416,12 @@ order_of_operations: Answer must be true or false. Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: + answer: true + note: | + The fix for the vulnerability involves moving code around an if statement that + check to see if the ssocket is NULL. This null check according to the developer + that fixed the issue is happening too late. So the developer moved it from one + section of the code to another to ensure this check happens earlier. lessons: question: | Are there any common lessons we have learned from class that apply to this @@ -454,7 +499,21 @@ mistakes: Write a thoughtful entry here that people in the software engineering industry would find interesting. - answer: + answer: | + The mistake that caused this issue seems to be on misunderstanding of the + systems flow and how things interact inside. As well as a poorly designed + system that led to this issue. The developer (Jeff Layton + ) that fixed the issue says something simular to this, + "In truth, this is a bit of a half-assed fix. The -ENOTSOCK error return + here looks like it could bubble back up to userspace. The locking rules + around the ssocket pointer are really unclear as well. There are cases + where the ssocket pointer is changed without holding the srv_mutex, but + I'm not clear whether there's a potential race here yet or not. + + This code seems like it could benefit from some fundamental re-think of + how the socket handling should behave. Until then though, this patch + should at least fix the above oops in most cases." + (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ea702b80e0bbb2448e201472127288beb82ca2fe) CWE_instructions: | Please go to http://cwe.mitre.org and find the most specific, appropriate CWE entry that describes your vulnerability. We recommend going to @@ -471,7 +530,7 @@ CWE_instructions: | CWE: [123, 456] # also ok CWE: 123 # also ok CWE: -- 362 + - ["362", "476"] CWE_note: | CWE as registered in the NVD. If you are curating, check that this is correct and replace this comment with "Manually confirmed". @@ -479,5 +538,5 @@ nickname_instructions: | A catchy name for this vulnerability that would draw attention it. If the report mentions a nickname, use that. Must be under 30 characters. Optional. -nickname: +nickname: RaceCrash3302 CVSS: diff --git a/cves/kernel/CVE-2016-8630.yml b/cves/kernel/CVE-2016-8630.yml index f0989e1be..4219073e4 100644 --- a/cves/kernel/CVE-2016-8630.yml +++ b/cves/kernel/CVE-2016-8630.yml @@ -26,7 +26,7 @@ reported_instructions: | the CVE was created. Leave blank if no date is given. Please enter your date in YYYY-MM-DD format. -reported_date: '2016-11-28' +reported_date: announced_instructions: | Was there a date that this vulnerability was announced to the world? You can find this in changelogs, blogs, bug reports, or perhaps the CVE date. @@ -34,11 +34,11 @@ announced_instructions: | This is not the same as published date in the NVD - that is below. Please enter your date in YYYY-MM-DD format. -announced_date: '2016-11-28' +announced_date: "2016-11-28" published_instructions: | Is there a published fix or patch date for this vulnerability? Please enter your date in YYYY-MM-DD format. -published_date: '2016-11-28' +published_date: "2016-11-28" description_instructions: | You can get an initial description from the CVE entry on cve.mitre.org. These descriptions are a fine start, but they can be kind of jargony. @@ -81,7 +81,10 @@ bugs_instructions: | * Mentioned in mailing list discussions * References from NVD entry * Various other places -bugs: ["https://github.com/torvalds/linux/commit/41061cdb98a0bec464278b4db8e894a3121671f5"] +bugs: + [ + "https://github.com/torvalds/linux/commit/41061cdb98a0bec464278b4db8e894a3121671f5", + ] fixes_instructions: | Please put the commit hash in "commit" below. @@ -90,10 +93,10 @@ fixes_instructions: | Place any notes you would like to make in the notes field. fixes: -- commit: d9092f52d7e61dd1557f2db2400ddb430e85937e - note: | - Taken from NVD references list with Git commit. If you are - curating, please fact-check that this commit fixes the vulnerability and replace this comment with 'Manually confirmed' + - commit: d9092f52d7e61dd1557f2db2400ddb430e85937e + note: | + Taken from NVD references list with Git commit. If you are + curating, please fact-check that this commit fixes the vulnerability and replace this comment with 'Manually confirmed' vcc_instructions: | The vulnerability-contributing commits. @@ -107,8 +110,8 @@ vcc_instructions: | Place any notes you would like to make in the notes field. vccs: -- commit: 41061cdb98a0bec464278b4db8e894a3121671f5 - note: Discovered automatically by archeogit. + - commit: 41061cdb98a0bec464278b4db8e894a3121671f5 + note: Discovered automatically by archeogit. upvotes_instructions: | For the first round, ignore this upvotes number. @@ -116,7 +119,7 @@ upvotes_instructions: | upvotes to each vulnerability you see. Your peers will tell you how interesting they think this vulnerability is, and you'll add that to the upvotes score on your branch. -upvotes: 1 +upvotes: 0 unit_tested: question: | Were automated unit tests involved in this vulnerability? @@ -260,10 +263,10 @@ interesting_commits: * Other commits that fixed a similar issue as this vulnerability * Anything else you find interesting. commits: - - commit: - note: - - commit: - note: + - commit: + note: + - commit: + note: i18n: question: | Was the feature impacted by this vulnerability about internationalization @@ -518,7 +521,7 @@ CWE_instructions: | CWE: [123, 456] # also ok CWE: 123 # also ok CWE: -- ["284", "476"] + - ["284", "476"] CWE_note: | CWE as registered in the NVD. If you are curating, check that this is correct and replace this comment with "Manually confirmed". From 9c37db2451089e718dd3ad3c7d0f9be69fc60a1c Mon Sep 17 00:00:00 2001 From: Nathan Gilbert Date: Tue, 14 Nov 2023 12:30:11 -0500 Subject: [PATCH 7/7] Fixes bases on comments by aisgbnok --- cves/kernel/CVE-2013-3302.yml | 108 ++++++++++++++++------------------ cves/kernel/CVE-2016-8630.yml | 81 ++++++++++++------------- 2 files changed, 87 insertions(+), 102 deletions(-) diff --git a/cves/kernel/CVE-2013-3302.yml b/cves/kernel/CVE-2013-3302.yml index 83d574b29..fc32609e3 100644 --- a/cves/kernel/CVE-2013-3302.yml +++ b/cves/kernel/CVE-2013-3302.yml @@ -26,7 +26,7 @@ reported_instructions: | the CVE was created. Leave blank if no date is given. Please enter your date in YYYY-MM-DD format. -reported_date: "2013-04-15" +reported_date: "2012-01-30" announced_instructions: | Was there a date that this vulnerability was announced to the world? You can find this in changelogs, blogs, bug reports, or perhaps the CVE date. @@ -56,12 +56,14 @@ description_instructions: | Your target audience is people just like you before you took any course in security description: | - This CVE is a security issue in the Linux operating system's kernel. - This issue allowed the Linux system to crash or stop working properly. - This issue is caused by a race condition where processes are competing - for access for a resource that cannot be shared. If the respource is - reached by two processes it can cause a crash from a NULL pointer + This issue is caused by a race condition for the ssocket. If the respource is + reached and is NULL before it was set then it can cause a crash from a NULL pointer dereference or potentially open the system up to other security issues. + + The fix moves the NULL socket check into the `smb_send_rqst` function, which + handles server requests. This ensures the check is conducted earlier, + preventing a NULL socket from being passed to the `kernel_setsockopt` + function. This mitigates the risk of a kernel crash due to the race condition. bounty_instructions: | If you came across any indications that a bounty was paid out for this vulnerability, fill it out here. Or correct it if the information already here @@ -91,9 +93,7 @@ fixes_instructions: | Place any notes you would like to make in the notes field. fixes: - commit: ea702b80e0bbb2448e201472127288beb82ca2fe - note: | - Taken from NVD references list with Git commit. If you are - curating, please fact-check that this commit fixes the vulnerability and replace this comment with 'Manually confirmed' + note: Manually Confirmed vcc_instructions: | The vulnerability-contributing commits. @@ -108,13 +108,13 @@ vcc_instructions: | Place any notes you would like to make in the notes field. vccs: - commit: 6f49f46b187df34539f1e5df2469b8a541897700 - note: Discovered automatically by archeogit. + note: Manually Confirmed - commit: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 - note: Discovered automatically by archeogit. + note: Manually Confirmed - commit: b8eed28375a43e1c9aaa9d15af2a052aae0d0725 - note: Discovered automatically by archeogit. + note: Manually Confirmed - commit: 3e84469d0101456caceffc6b22218a49017fcd3f - note: Discovered automatically by archeogit. + note: Manually Confirmed upvotes_instructions: | For the first round, ignore this upvotes number. @@ -122,7 +122,7 @@ upvotes_instructions: | upvotes to each vulnerability you see. Your peers will tell you how interesting they think this vulnerability is, and you'll add that to the upvotes score on your branch. -upvotes: 0 +upvotes: 3 unit_tested: question: | Were automated unit tests involved in this vulnerability? @@ -161,11 +161,10 @@ discovered: explain where you looked. answer: | The commit that fixed the vulnerability states the vulnerability was - reported and tested by CAI Qian but no date is - stated. + reported and tested by CAI Qian . automated: false contest: false - developer: true + developer: false autodiscoverable: instructions: | Is it plausible that a fully automated tool could have discovered @@ -183,13 +182,15 @@ autodiscoverable: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. note: | - As the vulnerability was an example of race condition and NULL - pointer dereference, fuzzer tools, static analysis tools and Stress testing - all could highlight potential issues when it comes to race conditions and NULL pointer - dereferences. Fuzzers can identify unexpected behavior caused by a race condtion as well as NULL pointer - dereferences. Static analysis tools can identify code paths that could lead - to race condtions and null pointer dereferences, and stress testing can highlight potential - issues of race condtions by mimicing real-world scenerios and usages. + The vulnerability involves a race condition and NULL pointer dereference. + Detection tools such as fuzzers, static analysis tools, and stress testing + could potentially identify these issues. + + Fuzzers can detect unexpected behavior caused by race conditions and NULL + pointer dereferences. Static analysis tools can identify code paths that may + lead to race conditions and NULL pointer dereferences. Stress testing can + expose potential race condition issues by simulating real-world scenarios + and usage patterns. answer: true specification: instructions: | @@ -206,11 +207,8 @@ specification: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: | - In one of the bug reports they specify that the issue of the race condition - can cause NULL pointer dereferences as well as open the system up for other - issues. (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-3302, https://www.openwall.com/lists/oss-security/2013/04/15/2) - answer: true + note: No mention of a violation of a specification found. + answer: false subsystem: question: | What subsystems was the mistake in? These are WITHIN linux kernel @@ -280,9 +278,10 @@ i18n: what your answer was. answer: false note: | - The vulnerability does not relate to internationalization features in the - Linux kernel. The main vulnerability focuses on a race condition that can - cause a failure in the system and open up to a NULL pointer dereference. + The vulnerability primarily involves a race condition in the Linux kernel, + which could potentially lead to system failure due to NULL pointer + dereference. It does not pertain to the kernel's internationalization + features. sandbox: question: | Did this vulnerability violate a sandboxing feature that the system @@ -298,7 +297,7 @@ sandbox: what your answer was. answer: false note: | - This vulnerability does not violate a sandboxing feature. The issue is only + This vulnerability does not violate a sandboxing feature. The issue is due to a race condition that can cause a failure in the system and open up to a NULL pointer dereference. ipc: @@ -313,9 +312,9 @@ ipc: what your answer was. answer: true note: | - The feature that this vulnerability is caused by is a race condition that - the ssocket is NULL when the system tries to connect. The code checks to see - if the ssocket is available too late causing it to fail. + This vulnerability is caused by a race condition when the ssocket is NULL + when the system tries to connect. The code checks to see if the ssocket is + available too late causing it to fail. discussion: question: | Was there any discussion surrounding this? @@ -401,10 +400,10 @@ forgotten_check: what your answer was. answer: false note: | - Although this fix invloves a if statement. The correction to the issue was not - adding a missing check but to move the if statement to a better place where it - will check for a module to be NULL early instead of later where it could be too - late causing a race condition and potentially a NULL pointer dereference. + While the fix involves an if statement, the issue wasn't a forgotten check, + but the placement of the check. The if statement was moved to check for + NULL earlier in the data flow. This prevents a race condition and potential + NULL pointer dereference. order_of_operations: question: | Does the fix for the vulnerability involve correcting an order of @@ -418,10 +417,11 @@ order_of_operations: what your answer was. answer: true note: | - The fix for the vulnerability involves moving code around an if statement that - check to see if the ssocket is NULL. This null check according to the developer - that fixed the issue is happening too late. So the developer moved it from one - section of the code to another to ensure this check happens earlier. + The fix for the vulnerability involves moving around an if statement that + check to see if the ssocket is NULL in smb_send_kvec to smb_send_rqst. + The initial if statement was checking for NULL too late in the data flow. + This means that they needed the NULL check to be move to much earlier in + the data flow. lessons: question: | Are there any common lessons we have learned from class that apply to this @@ -503,16 +503,10 @@ mistakes: The mistake that caused this issue seems to be on misunderstanding of the systems flow and how things interact inside. As well as a poorly designed system that led to this issue. The developer (Jeff Layton - ) that fixed the issue says something simular to this, - "In truth, this is a bit of a half-assed fix. The -ENOTSOCK error return - here looks like it could bubble back up to userspace. The locking rules - around the ssocket pointer are really unclear as well. There are cases - where the ssocket pointer is changed without holding the srv_mutex, but - I'm not clear whether there's a potential race here yet or not. - - This code seems like it could benefit from some fundamental re-think of - how the socket handling should behave. Until then though, this patch - should at least fix the above oops in most cases." + ) that fixed the issue says something simular to this, + saying that the ssocket locking rules documentation is unclear. They also + think the code seems like it could benefit refactoring the code for how + the socket handling should behave. (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ea702b80e0bbb2448e201472127288beb82ca2fe) CWE_instructions: | Please go to http://cwe.mitre.org and find the most specific, appropriate CWE @@ -531,12 +525,10 @@ CWE_instructions: | CWE: 123 # also ok CWE: - ["362", "476"] -CWE_note: | - CWE as registered in the NVD. If you are curating, check that this - is correct and replace this comment with "Manually confirmed". +CWE_note: Manually Confirmed nickname_instructions: | A catchy name for this vulnerability that would draw attention it. If the report mentions a nickname, use that. Must be under 30 characters. Optional. nickname: RaceCrash3302 -CVSS: +CVSS: CVSS:2.0/AV:L/AC:M/Au:N/C:P/I:P/A:P diff --git a/cves/kernel/CVE-2016-8630.yml b/cves/kernel/CVE-2016-8630.yml index 4219073e4..7fa30edaf 100644 --- a/cves/kernel/CVE-2016-8630.yml +++ b/cves/kernel/CVE-2016-8630.yml @@ -56,12 +56,12 @@ description_instructions: | Your target audience is people just like you before you took any course in security description: | - This CVE is a security issue in the Linux operating system's kernel. - This issue allowed the Linux system to crash or stop working properly. - This issue could be triggered by someone using a certain command that - the code to access a part of memory that does not exist. This causes - the system to become unresponsive. A fix was developed by RedHat to - prevent this issue from causing problems in Linux. + This vulenrability could trigger a NULL pointer dereference due to improper + access control. The code accesses a part of memory that does not exist + causing the NULL poninter dereference. This causes the system to become + unresponsive. A fix was developed by RedHat to prevent this issue from + causing problems in Linux. By adding a checks for memopp before + dereferencing. bounty_instructions: | If you came across any indications that a bounty was paid out for this vulnerability, fill it out here. Or correct it if the information already here @@ -74,17 +74,14 @@ reviews: [] bugs_instructions: | What bugs are involved in this vulnerability? - Please list bug IDs to https://bugzilla.kernel.org/ + Please list bug IDs to https://bugziCVE-lla.kernel.org/ Bug ID's can appear in several places: * Mentioned in commit messages * Mentioned in mailing list discussions * References from NVD entry * Various other places -bugs: - [ - "https://github.com/torvalds/linux/commit/41061cdb98a0bec464278b4db8e894a3121671f5", - ] +bugs: [] fixes_instructions: | Please put the commit hash in "commit" below. @@ -94,9 +91,7 @@ fixes_instructions: | Place any notes you would like to make in the notes field. fixes: - commit: d9092f52d7e61dd1557f2db2400ddb430e85937e - note: | - Taken from NVD references list with Git commit. If you are - curating, please fact-check that this commit fixes the vulnerability and replace this comment with 'Manually confirmed' + note: Manually Confirmed vcc_instructions: | The vulnerability-contributing commits. @@ -111,7 +106,7 @@ vcc_instructions: | Place any notes you would like to make in the notes field. vccs: - commit: 41061cdb98a0bec464278b4db8e894a3121671f5 - note: Discovered automatically by archeogit. + note: Manually Confirmed upvotes_instructions: | For the first round, ignore this upvotes number. @@ -119,7 +114,7 @@ upvotes_instructions: | upvotes to each vulnerability you see. Your peers will tell you how interesting they think this vulnerability is, and you'll add that to the upvotes score on your branch. -upvotes: 0 +upvotes: 1 unit_tested: question: | Were automated unit tests involved in this vulnerability? @@ -157,13 +152,13 @@ discovered: If there is no evidence as to how this vulnerability was found, then please explain where you looked. answer: | - Searching through the bug report - (https://bugzilla.redhat.com/show_bug.cgi?id=1393350) as well as the GitHub - (https://github.com/torvalds/linux/commit/d9092f52d7e61dd1557f2db2400ddb430e85937e) - and change log (https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.8.7) - I could not determine how this vulnerability was discovered. It could have been - detected early via a code-review or detected later without saying how the vulnerability - was discovered. There is not evidence either way. + The vulnerability's discovery method remains unclear after examining the bug + report (https://bugzilla.redhat.com/show_bug.cgi?id=1393350), GitHub commit + (https://github.com/torvalds/linux/commit/d9092f52d7e61dd1557f2db2400ddb430e85937e), + and change log + (https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.8.7). It + might have been detected early via code-review or found later without + disclosure of the discovery method. No concrete evidence was found. automated: false contest: false developer: false @@ -184,14 +179,15 @@ autodiscoverable: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. note: | - As the vulnerability was an example of improper access control and NULL - pointer dereference, fuzzer tools, static analysis tools and compiler - warnings all could highlight potential issues when it comes to NULL pointer - dereferences. Fuzzers can identify unexpected behavior caused by NULL pointer - dereferences. Static analysis tools can identify code paths that could lead - to null pointer dereferences, and compiler warnings can highlight potential - issues in the developers code where potential NULL pointer dereferences - could occur. + The vulnerability involves a NULL pointer dereference due to improper + access control. Detection tools such as fuzzers, static analysis tools, + and compilere warnings could potentially identify these issues. + + Fuzzers can detect unexpected behavior caused by NULL pointer + dereferences. Static analysis tools can identify code paths that may + lead to NULL pointer dereferences. Compiler warnings can highlight + potential issues in the developers code where potential NULL pointer + dereferences could occur. answer: true specification: instructions: | @@ -245,7 +241,7 @@ subsystem: e.g. name: ["subsystemA", "subsystemB"] # ok name: subsystemA # also ok - name: x86 + name: ["x86", "kvm"] note: | Looking at the file path on github. (https://github.com/torvalds/linux/commit/d9092f52d7e61dd1557f2db2400ddb430e85937e) @@ -344,7 +340,7 @@ discussion: comment you want to make. discussed_as_security: false any_discussion: false - note: There were no discussions I could find + note: No discussions were identified. vouch: question: | @@ -417,7 +413,7 @@ order_of_operations: what your answer was. answer: false note: | - I do not think this fix involved correcting the order of operations. All + This fix did not involved correcting the order of operations. All that was changed was an additional check in an if statement that checks for memopp before dereferencing. lessons: @@ -498,12 +494,11 @@ mistakes: Write a thoughtful entry here that people in the software engineering industry would find interesting. answer: | - The commit that caused this issue was a “fix” to the code that was originally - there. The commit message ("KVM: emulate: do not initialize memopp") removes - a check for non-NULL under incorrect assumptions. An undefined instruction - with a ModR/M byte with Mod=0 and R/M-5 (e.g. 0xc7 0x15) will attempt to - dereference a null pointer here. This seems to have been a mistake in - understanding how the code worked or what assumptions were incorrect. + The commit that caused this issue was a “fix” to the code that was + originally there. This seems to have been a mistake in understanding + how the code worked or what assumptions were incorrect. The initial + fix tried removing "unneeded" checks before dereference. But this allows + for a NULL pointer dereference to occur. CWE_instructions: | Please go to http://cwe.mitre.org and find the most specific, appropriate CWE @@ -522,12 +517,10 @@ CWE_instructions: | CWE: 123 # also ok CWE: - ["284", "476"] -CWE_note: | - CWE as registered in the NVD. If you are curating, check that this - is correct and replace this comment with "Manually confirmed". +CWE_note: Manually Confirmed nickname_instructions: | A catchy name for this vulnerability that would draw attention it. If the report mentions a nickname, use that. Must be under 30 characters. Optional. nickname: KernelCrash8630 -CVSS: +CVSS: CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H