From 81cafb815d7d425bf0f3ee85db2aa99ae011cc95 Mon Sep 17 00:00:00 2001 From: karisanno11 Date: Tue, 7 Nov 2023 21:17:00 -0500 Subject: [PATCH 01/21] added yml files and changed curation level --- CVE-2019-19045.yml | 477 ++++++++++++++++++++++++++++++++++++++++++++ CVE-2019-8956.yml | 479 +++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 956 insertions(+) create mode 100644 CVE-2019-19045.yml create mode 100644 CVE-2019-8956.yml diff --git a/CVE-2019-19045.yml b/CVE-2019-19045.yml new file mode 100644 index 000000000..b896bd1bc --- /dev/null +++ b/CVE-2019-19045.yml @@ -0,0 +1,477 @@ +CVE: CVE-2019-19045 +yaml_instructions: | + ================= + ===YAML Primer=== + ================= + This is a dictionary data structure, akin to JSON. + Everything before a colon is a key, and the values here are usually strings + For one-line strings, you can just use quotes after the colon + For multi-line strings, as we do for our instructions, you put a | and then + indent by two spaces + + For readability, we hard-wrap multi-line strings at 80 characters. This is + not required, but appreciated. +curated_instructions: | + If you are manually editing this file, then you are "curating" it. + + Set the version number that you were given in your 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 +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: +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. + + 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: '2019-11-18' +published_instructions: | + Is there a published fix or patch date for this vulnerability? + Please enter your date in YYYY-MM-DD format. +published_date: '2019-11-18' +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. + + Rewrite this description IN YOUR OWN WORDS. Make it interesting and easy to + read to anyone with some programming experience. We can always pull up the NVD + description later to get more technical. + + Try to still be specific in your description, but remove project-specific + stuff. Remove references to versions, specific filenames, and other jargon + that outsiders to this project would not understand. Technology like "regular + expressions" is fine, and security phrases like "invalid write" are fine to + keep too. + + Your target audience is people just like you before you took any course in + security +description: +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 + was wrong. Otherwise, leave it blank. +bounty: + amt: + announced: + url: +reviews: [] +bugs_instructions: | + What bugs are involved in this vulnerability? + + Please list bug IDs to https://bugzilla.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: [] +fixes_instructions: | + Please put the commit hash in "commit" below. + + This must be a git commit hash from the systemd source repo, a 40-character + hexademical string/ + + Place any notes you would like to make in the notes field. +fixes: +- commit: + note: +- commit: + note: +- commit: c8c2a057fdc7de1cd16f4baa51425b932a42eb39 + 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. + + These are found by our tools by traversing the Git Blame history, where we + determine which commit(s) introduced the functionality. + + Look up these VCC commits and verify that they are not simple refactorings, + and that they are, in fact introducing the vulnerability into the system. + Often, introducing the file or function is where the VCC is, but VCCs can be + anything. + + Place any notes you would like to make in the notes field. +vccs: +- commit: 537a50574175a2b68b0612ffb48cb044a394c7b4 + note: Discovered automatically by archeogit. +upvotes_instructions: | + For the first round, ignore this upvotes number. + + For the second round of reviewing, you will be giving a certain amount of + 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: +unit_tested: + question: | + Were automated unit tests involved in this vulnerability? + Was the original code unit tested, or not unit tested? Did the fix involve + improving the automated tests? + + For code: and fix: - your answer should be boolean. + + For the code_answer below, look not only at the fix but the surrounding + code near the fix in related directories and determine if and was there were + unit tests involved for this subsystem. + + 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: +discovered: + question: | + How was this vulnerability discovered? + + Go to the bug report and read the conversation to find out how this was + originally found. Answer in longform below in "answer", fill in the date in + YYYY-MM-DD, and then determine if the vulnerability was found by a Google + employee (you can tell from their email address). If it's clear that the + vulenrability was discovered by a contest, fill in the name there. + + The automated, contest, and developer flags can be true, false, or nil. + + If there is no evidence as to how this vulnerability was found, then please + explain where you looked. + answer: + automated: + contest: + developer: +autodiscoverable: + instructions: | + Is it plausible that a fully automated tool could have discovered + this? These are tools that require little knowledge of the domain, + e.g. automatic static analysis, compiler warnings, fuzzers. + + Examples for true answers: SQL injection, XSS, buffer overflow + + In systemd, the actually use OZZ Fuzz. If there's a link to it, add it here. + + Examples for false: RFC violations, permissions issues, anything + that requires the tool to be "aware" of the project's + domain-specific requirements. + + The answer field should be boolean. In answer_note, please explain + why you come to that conclusion. + note: + answer: +specification: + instructions: | + Is there mention of a violation of a specification? For example, the POSIX + spec, an RFC spec, a network protocol spec, or some other requirements + specification. + + Be sure to check the following artifacts for this: + * bug reports + * security advisories + * commit message + * mailing lists + * anything else + + The answer field should be boolean. In answer_note, please explain + why you come to that conclusion. + note: + answer: +subsystem: + question: | + What subsystems was the mistake in? These are WITHIN linux kernel + + Determining the subsystem is a subjective task. This is to help us group + similar vulnerabilities, so choose a subsystem that other vulnerabilities would be in. Y + + Some areas to look for pertinent information: + - Bug labels + - Directory names + - How developers refer to an area of the system in comments, + commit messages, etc. + + Look at the path of the source code files code that were fixed to get + directory names. Look at comments in the code. Look at the bug reports how + the bug report was tagged. + + Example linux kernel subsystems are: + * drivers + * crypto + * fs + * net + * lib + + Name should be: + * all lowercase English letters + * NOT a specific file + * can have digits, and _-@/ + + Can be multiple subsystems involved, in which case you can make it an array + e.g. + name: ["subsystemA", "subsystemB"] # ok + name: subsystemA # also ok + name: + note: +interesting_commits: + question: | + Are there any interesting commits between your VCC(s) and fix(es)? + + Use this to specify any commits you think are notable in some way, and + explain why in the note. + + Example interesting commits: + * Mentioned as a problematic commit in the past + e.g. "This fixes regression in commit xys" + * A significant rewrite in the git history + * Other commits that fixed a similar issue as this vulnerability + * Anything else you find interesting. + commits: + - commit: + note: + - commit: + note: +i18n: + question: | + Was the feature impacted by this vulnerability about internationalization + (i18n)? + + An internationalization feature is one that enables people from all + over the world to use the system. This includes translations, locales, + typography, unicode, or various other features. + + 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: +sandbox: + question: | + Did this vulnerability violate a sandboxing feature that the system + provides? + + A sandboxing feature is one that allows files, users, or other features + limited access. Vulnerabilities that violate sandboxes are usually based on + access control, checking privileges incorrectly, path traversal, and the + like. + + 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: +ipc: + question: | + Did the feature that this vulnerability affected use inter-process + communication? IPC includes OS signals, pipes, stdin/stdout, message + passing, and clipboard. Writing to files that another program in this + software system reads is another form of 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: +discussion: + question: | + Was there any discussion surrounding this? + + A discussion can include debates, disputes, or polite talk about how to + resolve uncertainty. + + Example include: + * Is this out of our scope? + * Is this a security? + * How should we fix this? + + Just because you see multiple comments doesn't mean it's a discussion. + For example: + * "Fix line 10". "Ok" is not what we call a discussion + * "Ping" (reminding people) + + Check the bugs reports, pull requests, and mailing lists archives. + + These answers should be boolean. + discussed_as_security: true or false + any_discussion: true or false + + 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: +vouch: + question: | + Was there any part of the fix that involved one person vouching for + another's work? + + This can include: + * signing off on a commit message + * mentioning a discussion with a colleague checking the work + * upvoting a solution on a pull request + + 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: +stacktrace: + question: | + Are there any stacktraces in the bug reports? + + Secondly, if there is a stacktrace, is the fix in the same file that the + stacktrace points to? + + If there are no stacktraces, then both of these are false - but be sure to + mention where you checked in the note. + + 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: +forgotten_check: + question: | + Does the fix for the vulnerability involve adding a forgotten check? + + A "forgotten check" can mean many things. It often manifests as the fix + inserting an entire if-statement or a conditional to an existing + if-statement. Or a call to a method that checks something. + + Example of checks can include: + * null pointer checks + * check the current role, e.g. root + * boundary checks for a number + * consult file permissions + * check a return value + + 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: +order_of_operations: + question: | + Does the fix for the vulnerability involve correcting an order of + operations? + + This means the fix involves moving code around or changing the order of + how things are done. + + 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: +lessons: + question: | + Are there any common lessons we have learned from class that apply to this + vulnerability? In other words, could this vulnerability serve as an example + of one of those lessons? + + Leave "applies" blank or put false if you did not see that lesson (you do + not need to put a reason). Put "true" if you feel the lesson applies and put + a quick explanation of how it applies. + + Don't feel the need to claim that ALL of these apply, but it's pretty likely + that one or two of them apply. + + If you think of another lesson we covered in class that applies here, feel + free to give it a small name and add one in the same format as these. + defense_in_depth: + applies: + note: + least_privilege: + applies: + note: + frameworks_are_optional: + applies: + note: + native_wrappers: + applies: + note: + distrust_input: + applies: + note: + security_by_obscurity: + applies: + note: + serial_killer: + applies: + note: + environment_variables: + applies: + note: + secure_by_default: + applies: + note: + yagni: + applies: + note: + complex_inputs: + applies: + note: +mistakes: + question: | + In your opinion, after all of this research, what mistakes were made that + led to this vulnerability? Coding mistakes? Design mistakes? + Maintainability? Requirements? Miscommunications? + + There can, and usually are, many mistakes behind a vulnerability. + + Remember that mistakes can come in many forms: + * slip: failing to complete a properly planned step due to inattention + e.g. wrong key in the ignition + e.g. using < instead of <= + * lapse: failing to complete a properly planned step due to memory failure + e.g. forgetting to put car in reverse before backing up + e.g. forgetting to check null + * planning error: error that occurs when the plan is inadequate + e.g. getting stuck in traffic because you didn't consider the + impact of the bridge closing + e.g. calling the wrong method + e.g. using a poor design + + These are grey areas, of course. But do your best to analyze the mistakes + according to this framework. + + Look at the CWE entry for this vulnerability and examine the mitigations + they have written there. Are they doing those? Does the fix look proper? + + Write a thoughtful entry here that people in the software engineering + industry would find interesting. + answer: +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 + https://cwe.mitre.org/data/definitions/699.html for the Software Development + view of the vulnerabilities. We also recommend the tool + http://www.cwevis.org/viz to help see how the classifications work. + + If you have anything to note about why you classified it this way, write + something in CWE_note. This field is optional. + + Just the number here is fine. No need for name or CWE prefix. If more than one + apply here, then place them in an array like this + CWE: ["123", "456"] # this is ok + CWE: [123, 456] # also ok + CWE: 123 # also ok +CWE: +- 401 +CWE_note: | + CWE as registered in the NVD. If you are curating, check that this + is correct and replace this comment with "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: +CVSS: CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H diff --git a/CVE-2019-8956.yml b/CVE-2019-8956.yml new file mode 100644 index 000000000..d0367d773 --- /dev/null +++ b/CVE-2019-8956.yml @@ -0,0 +1,479 @@ +CVE: CVE-2019-8956 +yaml_instructions: | + ================= + ===YAML Primer=== + ================= + This is a dictionary data structure, akin to JSON. + Everything before a colon is a key, and the values here are usually strings + For one-line strings, you can just use quotes after the colon + For multi-line strings, as we do for our instructions, you put a | and then + indent by two spaces + + For readability, we hard-wrap multi-line strings at 80 characters. This is + not required, but appreciated. +curated_instructions: | + If you are manually editing this file, then you are "curating" it. + + Set the version number that you were given in your 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 +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: +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. + + 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: '2019-04-01' +published_instructions: | + Is there a published fix or patch date for this vulnerability? + Please enter your date in YYYY-MM-DD format. +published_date: '2019-04-01' +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. + + Rewrite this description IN YOUR OWN WORDS. Make it interesting and easy to + read to anyone with some programming experience. We can always pull up the NVD + description later to get more technical. + + Try to still be specific in your description, but remove project-specific + stuff. Remove references to versions, specific filenames, and other jargon + that outsiders to this project would not understand. Technology like "regular + expressions" is fine, and security phrases like "invalid write" are fine to + keep too. + + Your target audience is people just like you before you took any course in + security +description: +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 + was wrong. Otherwise, leave it blank. +bounty: + amt: + announced: + url: +reviews: [] +bugs_instructions: | + What bugs are involved in this vulnerability? + + Please list bug IDs to https://bugzilla.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: [] +fixes_instructions: | + Please put the commit hash in "commit" below. + + This must be a git commit hash from the systemd source repo, a 40-character + hexademical string/ + + Place any notes you would like to make in the notes field. +fixes: +- commit: + note: +- commit: + note: +- commit: ba59fb0273076637f0add4311faa990a5eec27c0 + 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. + + These are found by our tools by traversing the Git Blame history, where we + determine which commit(s) introduced the functionality. + + Look up these VCC commits and verify that they are not simple refactorings, + and that they are, in fact introducing the vulnerability into the system. + Often, introducing the file or function is where the VCC is, but VCCs can be + anything. + + Place any notes you would like to make in the notes field. +vccs: +- commit: 007b7e18be74a49b61f89664966ac1477e1c9608 + note: Discovered automatically by archeogit. +- commit: 4910280503f3af2857d5aa77e35b22d93a8960a8 + note: Discovered automatically by archeogit. +upvotes_instructions: | + For the first round, ignore this upvotes number. + + For the second round of reviewing, you will be giving a certain amount of + 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: +unit_tested: + question: | + Were automated unit tests involved in this vulnerability? + Was the original code unit tested, or not unit tested? Did the fix involve + improving the automated tests? + + For code: and fix: - your answer should be boolean. + + For the code_answer below, look not only at the fix but the surrounding + code near the fix in related directories and determine if and was there were + unit tests involved for this subsystem. + + 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: +discovered: + question: | + How was this vulnerability discovered? + + Go to the bug report and read the conversation to find out how this was + originally found. Answer in longform below in "answer", fill in the date in + YYYY-MM-DD, and then determine if the vulnerability was found by a Google + employee (you can tell from their email address). If it's clear that the + vulenrability was discovered by a contest, fill in the name there. + + The automated, contest, and developer flags can be true, false, or nil. + + If there is no evidence as to how this vulnerability was found, then please + explain where you looked. + answer: + automated: + contest: + developer: +autodiscoverable: + instructions: | + Is it plausible that a fully automated tool could have discovered + this? These are tools that require little knowledge of the domain, + e.g. automatic static analysis, compiler warnings, fuzzers. + + Examples for true answers: SQL injection, XSS, buffer overflow + + In systemd, the actually use OZZ Fuzz. If there's a link to it, add it here. + + Examples for false: RFC violations, permissions issues, anything + that requires the tool to be "aware" of the project's + domain-specific requirements. + + The answer field should be boolean. In answer_note, please explain + why you come to that conclusion. + note: + answer: +specification: + instructions: | + Is there mention of a violation of a specification? For example, the POSIX + spec, an RFC spec, a network protocol spec, or some other requirements + specification. + + Be sure to check the following artifacts for this: + * bug reports + * security advisories + * commit message + * mailing lists + * anything else + + The answer field should be boolean. In answer_note, please explain + why you come to that conclusion. + note: + answer: +subsystem: + question: | + What subsystems was the mistake in? These are WITHIN linux kernel + + Determining the subsystem is a subjective task. This is to help us group + similar vulnerabilities, so choose a subsystem that other vulnerabilities would be in. Y + + Some areas to look for pertinent information: + - Bug labels + - Directory names + - How developers refer to an area of the system in comments, + commit messages, etc. + + Look at the path of the source code files code that were fixed to get + directory names. Look at comments in the code. Look at the bug reports how + the bug report was tagged. + + Example linux kernel subsystems are: + * drivers + * crypto + * fs + * net + * lib + + Name should be: + * all lowercase English letters + * NOT a specific file + * can have digits, and _-@/ + + Can be multiple subsystems involved, in which case you can make it an array + e.g. + name: ["subsystemA", "subsystemB"] # ok + name: subsystemA # also ok + name: + note: +interesting_commits: + question: | + Are there any interesting commits between your VCC(s) and fix(es)? + + Use this to specify any commits you think are notable in some way, and + explain why in the note. + + Example interesting commits: + * Mentioned as a problematic commit in the past + e.g. "This fixes regression in commit xys" + * A significant rewrite in the git history + * Other commits that fixed a similar issue as this vulnerability + * Anything else you find interesting. + commits: + - commit: + note: + - commit: + note: +i18n: + question: | + Was the feature impacted by this vulnerability about internationalization + (i18n)? + + An internationalization feature is one that enables people from all + over the world to use the system. This includes translations, locales, + typography, unicode, or various other features. + + 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: +sandbox: + question: | + Did this vulnerability violate a sandboxing feature that the system + provides? + + A sandboxing feature is one that allows files, users, or other features + limited access. Vulnerabilities that violate sandboxes are usually based on + access control, checking privileges incorrectly, path traversal, and the + like. + + 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: +ipc: + question: | + Did the feature that this vulnerability affected use inter-process + communication? IPC includes OS signals, pipes, stdin/stdout, message + passing, and clipboard. Writing to files that another program in this + software system reads is another form of 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: +discussion: + question: | + Was there any discussion surrounding this? + + A discussion can include debates, disputes, or polite talk about how to + resolve uncertainty. + + Example include: + * Is this out of our scope? + * Is this a security? + * How should we fix this? + + Just because you see multiple comments doesn't mean it's a discussion. + For example: + * "Fix line 10". "Ok" is not what we call a discussion + * "Ping" (reminding people) + + Check the bugs reports, pull requests, and mailing lists archives. + + These answers should be boolean. + discussed_as_security: true or false + any_discussion: true or false + + 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: +vouch: + question: | + Was there any part of the fix that involved one person vouching for + another's work? + + This can include: + * signing off on a commit message + * mentioning a discussion with a colleague checking the work + * upvoting a solution on a pull request + + 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: +stacktrace: + question: | + Are there any stacktraces in the bug reports? + + Secondly, if there is a stacktrace, is the fix in the same file that the + stacktrace points to? + + If there are no stacktraces, then both of these are false - but be sure to + mention where you checked in the note. + + 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: +forgotten_check: + question: | + Does the fix for the vulnerability involve adding a forgotten check? + + A "forgotten check" can mean many things. It often manifests as the fix + inserting an entire if-statement or a conditional to an existing + if-statement. Or a call to a method that checks something. + + Example of checks can include: + * null pointer checks + * check the current role, e.g. root + * boundary checks for a number + * consult file permissions + * check a return value + + 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: +order_of_operations: + question: | + Does the fix for the vulnerability involve correcting an order of + operations? + + This means the fix involves moving code around or changing the order of + how things are done. + + 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: +lessons: + question: | + Are there any common lessons we have learned from class that apply to this + vulnerability? In other words, could this vulnerability serve as an example + of one of those lessons? + + Leave "applies" blank or put false if you did not see that lesson (you do + not need to put a reason). Put "true" if you feel the lesson applies and put + a quick explanation of how it applies. + + Don't feel the need to claim that ALL of these apply, but it's pretty likely + that one or two of them apply. + + If you think of another lesson we covered in class that applies here, feel + free to give it a small name and add one in the same format as these. + defense_in_depth: + applies: + note: + least_privilege: + applies: + note: + frameworks_are_optional: + applies: + note: + native_wrappers: + applies: + note: + distrust_input: + applies: + note: + security_by_obscurity: + applies: + note: + serial_killer: + applies: + note: + environment_variables: + applies: + note: + secure_by_default: + applies: + note: + yagni: + applies: + note: + complex_inputs: + applies: + note: +mistakes: + question: | + In your opinion, after all of this research, what mistakes were made that + led to this vulnerability? Coding mistakes? Design mistakes? + Maintainability? Requirements? Miscommunications? + + There can, and usually are, many mistakes behind a vulnerability. + + Remember that mistakes can come in many forms: + * slip: failing to complete a properly planned step due to inattention + e.g. wrong key in the ignition + e.g. using < instead of <= + * lapse: failing to complete a properly planned step due to memory failure + e.g. forgetting to put car in reverse before backing up + e.g. forgetting to check null + * planning error: error that occurs when the plan is inadequate + e.g. getting stuck in traffic because you didn't consider the + impact of the bridge closing + e.g. calling the wrong method + e.g. using a poor design + + These are grey areas, of course. But do your best to analyze the mistakes + according to this framework. + + Look at the CWE entry for this vulnerability and examine the mitigations + they have written there. Are they doing those? Does the fix look proper? + + Write a thoughtful entry here that people in the software engineering + industry would find interesting. + answer: +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 + https://cwe.mitre.org/data/definitions/699.html for the Software Development + view of the vulnerabilities. We also recommend the tool + http://www.cwevis.org/viz to help see how the classifications work. + + If you have anything to note about why you classified it this way, write + something in CWE_note. This field is optional. + + Just the number here is fine. No need for name or CWE prefix. If more than one + apply here, then place them in an array like this + CWE: ["123", "456"] # this is ok + CWE: [123, 456] # also ok + CWE: 123 # also ok +CWE: +- 787 +CWE_note: | + CWE as registered in the NVD. If you are curating, check that this + is correct and replace this comment with "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: +CVSS: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H From d86e180f662924dfeb3c3b270a025458ed8e88e2 Mon Sep 17 00:00:00 2001 From: karisanno11 Date: Wed, 8 Nov 2023 11:51:21 -0500 Subject: [PATCH 02/21] saving progress --- CVE-2019-19045.yml => cves/CVE-2019-19045.yml | 23 +- CVE-2019-8956.yml => cves/CVE-2019-8956.yml | 25 +- cves/kernel/CVE-2019-8956.yml | 479 ------------------ 3 files changed, 40 insertions(+), 487 deletions(-) rename CVE-2019-19045.yml => cves/CVE-2019-19045.yml (93%) rename CVE-2019-8956.yml => cves/CVE-2019-8956.yml (95%) delete mode 100644 cves/kernel/CVE-2019-8956.yml diff --git a/CVE-2019-19045.yml b/cves/CVE-2019-19045.yml similarity index 93% rename from CVE-2019-19045.yml rename to cves/CVE-2019-19045.yml index b896bd1bc..6ee8835f5 100644 --- a/CVE-2019-19045.yml +++ b/cves/CVE-2019-19045.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: 2019-11-17 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. @@ -39,6 +39,7 @@ published_instructions: | Is there a published fix or patch date for this vulnerability? Please enter your date in YYYY-MM-DD format. published_date: '2019-11-18' + 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 +56,21 @@ description_instructions: | Your target audience is people just like you before you took any course in security -description: + +description: + CVE-2019-19045 is a security flaw located in the Linux kernel's handling of + network hardware, specifically within the mlx5_fpga_conn_create_cq() function + used by certain Mellanox network drivers. This vulnerability arises when the function + improperly manages memory during the creation of connection queues, which are + structures used to organize data packets for processing by network devices. + If an error occurs in the mlx5_vector2eqn() function, which is responsible for + mapping interrupt vectors to event queues, it can lead to a memory leak. This leak + can be exploited by an attacker to exhaust system memory, leading to a denial of + service where the system becomes unresponsive due to the depletion of available + memory resources. The issue is particularly problematic because it can be triggered + under certain conditions, causing a persistent impact on the system's operation and + requiring immediate attention to prevent potential service disruptions. + 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 +90,7 @@ bugs_instructions: | * Mentioned in mailing list discussions * References from NVD entry * Various other places -bugs: [] +bugs: [1774983] fixes_instructions: | Please put the commit hash in "commit" below. @@ -465,7 +480,7 @@ CWE_instructions: | CWE: [123, 456] # also ok CWE: 123 # also ok CWE: -- 401 +- [401, 400] CWE_note: | CWE as registered in the NVD. If you are curating, check that this is correct and replace this comment with "Manually confirmed". diff --git a/CVE-2019-8956.yml b/cves/CVE-2019-8956.yml similarity index 95% rename from CVE-2019-8956.yml rename to cves/CVE-2019-8956.yml index d0367d773..a5a0cab3b 100644 --- a/CVE-2019-8956.yml +++ b/cves/CVE-2019-8956.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: '2019-02-20' 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,18 @@ description_instructions: | Your target audience is people just like you before you took any course in security -description: + +description: + CVE-2019-8956 is a security vulnerability that affects the "sctp_sendmsg()" + function in Linux, which is designed for broadcasting data across many + network parts at once. This flaw grants users with specific permissions the + ability to write data to unauthorized areas of the system's memory. Such + unauthorized access can result in severe consequences, including system + crashes and the potential for hackers to execute arbitrary code. This type + of vulnerability is critical because it can compromise the integrity and + availability of affected systems, making it a significant risk that needs + to be addressed promptly. + 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 @@ -65,6 +76,7 @@ bounty: announced: url: reviews: [] + bugs_instructions: | What bugs are involved in this vulnerability? @@ -75,7 +87,8 @@ bugs_instructions: | * Mentioned in mailing list discussions * References from NVD entry * Various other places -bugs: [] +bugs: [1679889] + fixes_instructions: | Please put the commit hash in "commit" below. @@ -92,6 +105,7 @@ fixes: 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. @@ -109,6 +123,7 @@ vccs: note: Discovered automatically by archeogit. - commit: 4910280503f3af2857d5aa77e35b22d93a8960a8 note: Discovered automatically by archeogit. + upvotes_instructions: | For the first round, ignore this upvotes number. @@ -117,6 +132,7 @@ upvotes_instructions: | interesting they think this vulnerability is, and you'll add that to the upvotes score on your branch. upvotes: + unit_tested: question: | Were automated unit tests involved in this vulnerability? @@ -467,7 +483,7 @@ CWE_instructions: | CWE: [123, 456] # also ok CWE: 123 # also ok CWE: -- 787 +- [416, 787] CWE_note: | CWE as registered in the NVD. If you are curating, check that this is correct and replace this comment with "Manually confirmed". @@ -476,4 +492,5 @@ nickname_instructions: | If the report mentions a nickname, use that. Must be under 30 characters. Optional. nickname: + CVSS: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H diff --git a/cves/kernel/CVE-2019-8956.yml b/cves/kernel/CVE-2019-8956.yml deleted file mode 100644 index 8f83b3106..000000000 --- a/cves/kernel/CVE-2019-8956.yml +++ /dev/null @@ -1,479 +0,0 @@ -CVE: CVE-2019-8956 -yaml_instructions: | - ================= - ===YAML Primer=== - ================= - This is a dictionary data structure, akin to JSON. - Everything before a colon is a key, and the values here are usually strings - For one-line strings, you can just use quotes after the colon - For multi-line strings, as we do for our instructions, you put a | and then - indent by two spaces - - For readability, we hard-wrap multi-line strings at 80 characters. This is - not required, but appreciated. -curated_instructions: | - If you are manually editing this file, then you are "curating" it. - - Set the version number that you were given in your 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 -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: -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. - - 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: '2019-04-01' -published_instructions: | - Is there a published fix or patch date for this vulnerability? - Please enter your date in YYYY-MM-DD format. -published_date: '2019-04-01' -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. - - Rewrite this description IN YOUR OWN WORDS. Make it interesting and easy to - read to anyone with some programming experience. We can always pull up the NVD - description later to get more technical. - - Try to still be specific in your description, but remove project-specific - stuff. Remove references to versions, specific filenames, and other jargon - that outsiders to this project would not understand. Technology like "regular - expressions" is fine, and security phrases like "invalid write" are fine to - keep too. - - Your target audience is people just like you before you took any course in - security -description: -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 - was wrong. Otherwise, leave it blank. -bounty: - amt: - announced: - url: -reviews: [] -bugs_instructions: | - What bugs are involved in this vulnerability? - - Please list bug IDs to https://bugzilla.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: [] -fixes_instructions: | - Please put the commit hash in "commit" below. - - This must be a git commit hash from the systemd source repo, a 40-character - hexademical string/ - - Place any notes you would like to make in the notes field. -fixes: -- commit: - note: -- commit: - note: -- commit: ba59fb0273076637f0add4311faa990a5eec27c0 - 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. - - These are found by our tools by traversing the Git Blame history, where we - determine which commit(s) introduced the functionality. - - Look up these VCC commits and verify that they are not simple refactorings, - and that they are, in fact introducing the vulnerability into the system. - Often, introducing the file or function is where the VCC is, but VCCs can be - anything. - - Place any notes you would like to make in the notes field. -vccs: -- commit: 007b7e18be74a49b61f89664966ac1477e1c9608 - note: Discovered automatically by archeogit. -- commit: 4910280503f3af2857d5aa77e35b22d93a8960a8 - note: Discovered automatically by archeogit. -upvotes_instructions: | - For the first round, ignore this upvotes number. - - For the second round of reviewing, you will be giving a certain amount of - 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: -unit_tested: - question: | - Were automated unit tests involved in this vulnerability? - Was the original code unit tested, or not unit tested? Did the fix involve - improving the automated tests? - - For code: and fix: - your answer should be boolean. - - For the code_answer below, look not only at the fix but the surrounding - code near the fix in related directories and determine if and was there were - unit tests involved for this subsystem. - - 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: -discovered: - question: | - How was this vulnerability discovered? - - Go to the bug report and read the conversation to find out how this was - originally found. Answer in longform below in "answer", fill in the date in - YYYY-MM-DD, and then determine if the vulnerability was found by a Google - employee (you can tell from their email address). If it's clear that the - vulenrability was discovered by a contest, fill in the name there. - - The automated, contest, and developer flags can be true, false, or nil. - - If there is no evidence as to how this vulnerability was found, then please - explain where you looked. - answer: - automated: - contest: - developer: -autodiscoverable: - instructions: | - Is it plausible that a fully automated tool could have discovered - this? These are tools that require little knowledge of the domain, - e.g. automatic static analysis, compiler warnings, fuzzers. - - Examples for true answers: SQL injection, XSS, buffer overflow - - In systemd, the actually use OZZ Fuzz. If there's a link to it, add it here. - - Examples for false: RFC violations, permissions issues, anything - that requires the tool to be "aware" of the project's - domain-specific requirements. - - The answer field should be boolean. In answer_note, please explain - why you come to that conclusion. - note: - answer: -specification: - instructions: | - Is there mention of a violation of a specification? For example, the POSIX - spec, an RFC spec, a network protocol spec, or some other requirements - specification. - - Be sure to check the following artifacts for this: - * bug reports - * security advisories - * commit message - * mailing lists - * anything else - - The answer field should be boolean. In answer_note, please explain - why you come to that conclusion. - note: - answer: -subsystem: - question: | - What subsystems was the mistake in? These are WITHIN linux kernel - - Determining the subsystem is a subjective task. This is to help us group - similar vulnerabilities, so choose a subsystem that other vulnerabilities would be in. Y - - Some areas to look for pertinent information: - - Bug labels - - Directory names - - How developers refer to an area of the system in comments, - commit messages, etc. - - Look at the path of the source code files code that were fixed to get - directory names. Look at comments in the code. Look at the bug reports how - the bug report was tagged. - - Example linux kernel subsystems are: - * drivers - * crypto - * fs - * net - * lib - - Name should be: - * all lowercase English letters - * NOT a specific file - * can have digits, and _-@/ - - Can be multiple subsystems involved, in which case you can make it an array - e.g. - name: ["subsystemA", "subsystemB"] # ok - name: subsystemA # also ok - name: - note: -interesting_commits: - question: | - Are there any interesting commits between your VCC(s) and fix(es)? - - Use this to specify any commits you think are notable in some way, and - explain why in the note. - - Example interesting commits: - * Mentioned as a problematic commit in the past - e.g. "This fixes regression in commit xys" - * A significant rewrite in the git history - * Other commits that fixed a similar issue as this vulnerability - * Anything else you find interesting. - commits: - - commit: - note: - - commit: - note: -i18n: - question: | - Was the feature impacted by this vulnerability about internationalization - (i18n)? - - An internationalization feature is one that enables people from all - over the world to use the system. This includes translations, locales, - typography, unicode, or various other features. - - 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: -sandbox: - question: | - Did this vulnerability violate a sandboxing feature that the system - provides? - - A sandboxing feature is one that allows files, users, or other features - limited access. Vulnerabilities that violate sandboxes are usually based on - access control, checking privileges incorrectly, path traversal, and the - like. - - 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: -ipc: - question: | - Did the feature that this vulnerability affected use inter-process - communication? IPC includes OS signals, pipes, stdin/stdout, message - passing, and clipboard. Writing to files that another program in this - software system reads is another form of 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: -discussion: - question: | - Was there any discussion surrounding this? - - A discussion can include debates, disputes, or polite talk about how to - resolve uncertainty. - - Example include: - * Is this out of our scope? - * Is this a security? - * How should we fix this? - - Just because you see multiple comments doesn't mean it's a discussion. - For example: - * "Fix line 10". "Ok" is not what we call a discussion - * "Ping" (reminding people) - - Check the bugs reports, pull requests, and mailing lists archives. - - These answers should be boolean. - discussed_as_security: true or false - any_discussion: true or false - - 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: -vouch: - question: | - Was there any part of the fix that involved one person vouching for - another's work? - - This can include: - * signing off on a commit message - * mentioning a discussion with a colleague checking the work - * upvoting a solution on a pull request - - 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: -stacktrace: - question: | - Are there any stacktraces in the bug reports? - - Secondly, if there is a stacktrace, is the fix in the same file that the - stacktrace points to? - - If there are no stacktraces, then both of these are false - but be sure to - mention where you checked in the note. - - 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: -forgotten_check: - question: | - Does the fix for the vulnerability involve adding a forgotten check? - - A "forgotten check" can mean many things. It often manifests as the fix - inserting an entire if-statement or a conditional to an existing - if-statement. Or a call to a method that checks something. - - Example of checks can include: - * null pointer checks - * check the current role, e.g. root - * boundary checks for a number - * consult file permissions - * check a return value - - 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: -order_of_operations: - question: | - Does the fix for the vulnerability involve correcting an order of - operations? - - This means the fix involves moving code around or changing the order of - how things are done. - - 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: -lessons: - question: | - Are there any common lessons we have learned from class that apply to this - vulnerability? In other words, could this vulnerability serve as an example - of one of those lessons? - - Leave "applies" blank or put false if you did not see that lesson (you do - not need to put a reason). Put "true" if you feel the lesson applies and put - a quick explanation of how it applies. - - Don't feel the need to claim that ALL of these apply, but it's pretty likely - that one or two of them apply. - - If you think of another lesson we covered in class that applies here, feel - free to give it a small name and add one in the same format as these. - defense_in_depth: - applies: - note: - least_privilege: - applies: - note: - frameworks_are_optional: - applies: - note: - native_wrappers: - applies: - note: - distrust_input: - applies: - note: - security_by_obscurity: - applies: - note: - serial_killer: - applies: - note: - environment_variables: - applies: - note: - secure_by_default: - applies: - note: - yagni: - applies: - note: - complex_inputs: - applies: - note: -mistakes: - question: | - In your opinion, after all of this research, what mistakes were made that - led to this vulnerability? Coding mistakes? Design mistakes? - Maintainability? Requirements? Miscommunications? - - There can, and usually are, many mistakes behind a vulnerability. - - Remember that mistakes can come in many forms: - * slip: failing to complete a properly planned step due to inattention - e.g. wrong key in the ignition - e.g. using < instead of <= - * lapse: failing to complete a properly planned step due to memory failure - e.g. forgetting to put car in reverse before backing up - e.g. forgetting to check null - * planning error: error that occurs when the plan is inadequate - e.g. getting stuck in traffic because you didn't consider the - impact of the bridge closing - e.g. calling the wrong method - e.g. using a poor design - - These are grey areas, of course. But do your best to analyze the mistakes - according to this framework. - - Look at the CWE entry for this vulnerability and examine the mitigations - they have written there. Are they doing those? Does the fix look proper? - - Write a thoughtful entry here that people in the software engineering - industry would find interesting. - answer: -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 - https://cwe.mitre.org/data/definitions/699.html for the Software Development - view of the vulnerabilities. We also recommend the tool - http://www.cwevis.org/viz to help see how the classifications work. - - If you have anything to note about why you classified it this way, write - something in CWE_note. This field is optional. - - Just the number here is fine. No need for name or CWE prefix. If more than one - apply here, then place them in an array like this - CWE: ["123", "456"] # this is ok - CWE: [123, 456] # also ok - CWE: 123 # also ok -CWE: -- 787 -CWE_note: | - CWE as registered in the NVD. If you are curating, check that this - is correct and replace this comment with "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: -CVSS: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H From f883f17400dff8abb8d1055ebab24b087e4302af Mon Sep 17 00:00:00 2001 From: karisanno11 Date: Wed, 8 Nov 2023 12:56:22 -0500 Subject: [PATCH 03/21] trying to fix issue --- cves/CVE-2019-19045.yml | 2 +- cves/CVE-2019-8956.yml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/cves/CVE-2019-19045.yml b/cves/CVE-2019-19045.yml index 6ee8835f5..609cf2696 100644 --- a/cves/CVE-2019-19045.yml +++ b/cves/CVE-2019-19045.yml @@ -57,7 +57,7 @@ description_instructions: | Your target audience is people just like you before you took any course in security -description: +description: | CVE-2019-19045 is a security flaw located in the Linux kernel's handling of network hardware, specifically within the mlx5_fpga_conn_create_cq() function used by certain Mellanox network drivers. This vulnerability arises when the function diff --git a/cves/CVE-2019-8956.yml b/cves/CVE-2019-8956.yml index a5a0cab3b..3cf67806b 100644 --- a/cves/CVE-2019-8956.yml +++ b/cves/CVE-2019-8956.yml @@ -56,7 +56,7 @@ description_instructions: | Your target audience is people just like you before you took any course in security -description: +description: | CVE-2019-8956 is a security vulnerability that affects the "sctp_sendmsg()" function in Linux, which is designed for broadcasting data across many network parts at once. This flaw grants users with specific permissions the From 04a4cf57e403ffcb3fcfff50475def5bb9301344 Mon Sep 17 00:00:00 2001 From: karisanno11 Date: Wed, 8 Nov 2023 12:59:33 -0500 Subject: [PATCH 04/21] checking to see if issues are fixed --- cves/kernel/CVE-2019-19045.yml | 25 +- cves/kernel/CVE-2019-8956.yml | 496 +++++++++++++++++++++++++++++++++ 2 files changed, 516 insertions(+), 5 deletions(-) create mode 100644 cves/kernel/CVE-2019-8956.yml diff --git a/cves/kernel/CVE-2019-19045.yml b/cves/kernel/CVE-2019-19045.yml index 89f5f224c..609cf2696 100644 --- a/cves/kernel/CVE-2019-19045.yml +++ b/cves/kernel/CVE-2019-19045.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: 2019-11-17 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. @@ -39,6 +39,7 @@ published_instructions: | Is there a published fix or patch date for this vulnerability? Please enter your date in YYYY-MM-DD format. published_date: '2019-11-18' + 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 +56,21 @@ description_instructions: | Your target audience is people just like you before you took any course in security -description: + +description: | + CVE-2019-19045 is a security flaw located in the Linux kernel's handling of + network hardware, specifically within the mlx5_fpga_conn_create_cq() function + used by certain Mellanox network drivers. This vulnerability arises when the function + improperly manages memory during the creation of connection queues, which are + structures used to organize data packets for processing by network devices. + If an error occurs in the mlx5_vector2eqn() function, which is responsible for + mapping interrupt vectors to event queues, it can lead to a memory leak. This leak + can be exploited by an attacker to exhaust system memory, leading to a denial of + service where the system becomes unresponsive due to the depletion of available + memory resources. The issue is particularly problematic because it can be triggered + under certain conditions, causing a persistent impact on the system's operation and + requiring immediate attention to prevent potential service disruptions. + 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 +90,7 @@ bugs_instructions: | * Mentioned in mailing list discussions * References from NVD entry * Various other places -bugs: [] +bugs: [1774983] fixes_instructions: | Please put the commit hash in "commit" below. @@ -465,7 +480,7 @@ CWE_instructions: | CWE: [123, 456] # also ok CWE: 123 # also ok CWE: -- 401 +- [401, 400] CWE_note: | CWE as registered in the NVD. If you are curating, check that this is correct and replace this comment with "Manually confirmed". diff --git a/cves/kernel/CVE-2019-8956.yml b/cves/kernel/CVE-2019-8956.yml new file mode 100644 index 000000000..3cf67806b --- /dev/null +++ b/cves/kernel/CVE-2019-8956.yml @@ -0,0 +1,496 @@ +CVE: CVE-2019-8956 +yaml_instructions: | + ================= + ===YAML Primer=== + ================= + This is a dictionary data structure, akin to JSON. + Everything before a colon is a key, and the values here are usually strings + For one-line strings, you can just use quotes after the colon + For multi-line strings, as we do for our instructions, you put a | and then + indent by two spaces + + For readability, we hard-wrap multi-line strings at 80 characters. This is + not required, but appreciated. +curated_instructions: | + If you are manually editing this file, then you are "curating" it. + + Set the version number that you were given in your 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 +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: '2019-02-20' +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. + + 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: '2019-04-01' +published_instructions: | + Is there a published fix or patch date for this vulnerability? + Please enter your date in YYYY-MM-DD format. +published_date: '2019-04-01' +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. + + Rewrite this description IN YOUR OWN WORDS. Make it interesting and easy to + read to anyone with some programming experience. We can always pull up the NVD + description later to get more technical. + + Try to still be specific in your description, but remove project-specific + stuff. Remove references to versions, specific filenames, and other jargon + that outsiders to this project would not understand. Technology like "regular + expressions" is fine, and security phrases like "invalid write" are fine to + keep too. + + Your target audience is people just like you before you took any course in + security + +description: | + CVE-2019-8956 is a security vulnerability that affects the "sctp_sendmsg()" + function in Linux, which is designed for broadcasting data across many + network parts at once. This flaw grants users with specific permissions the + ability to write data to unauthorized areas of the system's memory. Such + unauthorized access can result in severe consequences, including system + crashes and the potential for hackers to execute arbitrary code. This type + of vulnerability is critical because it can compromise the integrity and + availability of affected systems, making it a significant risk that needs + to be addressed promptly. + +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 + was wrong. Otherwise, leave it blank. +bounty: + amt: + announced: + url: +reviews: [] + +bugs_instructions: | + What bugs are involved in this vulnerability? + + Please list bug IDs to https://bugzilla.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: [1679889] + +fixes_instructions: | + Please put the commit hash in "commit" below. + + This must be a git commit hash from the systemd source repo, a 40-character + hexademical string/ + + Place any notes you would like to make in the notes field. +fixes: +- commit: + note: +- commit: + note: +- commit: ba59fb0273076637f0add4311faa990a5eec27c0 + 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. + + These are found by our tools by traversing the Git Blame history, where we + determine which commit(s) introduced the functionality. + + Look up these VCC commits and verify that they are not simple refactorings, + and that they are, in fact introducing the vulnerability into the system. + Often, introducing the file or function is where the VCC is, but VCCs can be + anything. + + Place any notes you would like to make in the notes field. +vccs: +- commit: 007b7e18be74a49b61f89664966ac1477e1c9608 + note: Discovered automatically by archeogit. +- commit: 4910280503f3af2857d5aa77e35b22d93a8960a8 + note: Discovered automatically by archeogit. + +upvotes_instructions: | + For the first round, ignore this upvotes number. + + For the second round of reviewing, you will be giving a certain amount of + 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: + +unit_tested: + question: | + Were automated unit tests involved in this vulnerability? + Was the original code unit tested, or not unit tested? Did the fix involve + improving the automated tests? + + For code: and fix: - your answer should be boolean. + + For the code_answer below, look not only at the fix but the surrounding + code near the fix in related directories and determine if and was there were + unit tests involved for this subsystem. + + 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: +discovered: + question: | + How was this vulnerability discovered? + + Go to the bug report and read the conversation to find out how this was + originally found. Answer in longform below in "answer", fill in the date in + YYYY-MM-DD, and then determine if the vulnerability was found by a Google + employee (you can tell from their email address). If it's clear that the + vulenrability was discovered by a contest, fill in the name there. + + The automated, contest, and developer flags can be true, false, or nil. + + If there is no evidence as to how this vulnerability was found, then please + explain where you looked. + answer: + automated: + contest: + developer: +autodiscoverable: + instructions: | + Is it plausible that a fully automated tool could have discovered + this? These are tools that require little knowledge of the domain, + e.g. automatic static analysis, compiler warnings, fuzzers. + + Examples for true answers: SQL injection, XSS, buffer overflow + + In systemd, the actually use OZZ Fuzz. If there's a link to it, add it here. + + Examples for false: RFC violations, permissions issues, anything + that requires the tool to be "aware" of the project's + domain-specific requirements. + + The answer field should be boolean. In answer_note, please explain + why you come to that conclusion. + note: + answer: +specification: + instructions: | + Is there mention of a violation of a specification? For example, the POSIX + spec, an RFC spec, a network protocol spec, or some other requirements + specification. + + Be sure to check the following artifacts for this: + * bug reports + * security advisories + * commit message + * mailing lists + * anything else + + The answer field should be boolean. In answer_note, please explain + why you come to that conclusion. + note: + answer: +subsystem: + question: | + What subsystems was the mistake in? These are WITHIN linux kernel + + Determining the subsystem is a subjective task. This is to help us group + similar vulnerabilities, so choose a subsystem that other vulnerabilities would be in. Y + + Some areas to look for pertinent information: + - Bug labels + - Directory names + - How developers refer to an area of the system in comments, + commit messages, etc. + + Look at the path of the source code files code that were fixed to get + directory names. Look at comments in the code. Look at the bug reports how + the bug report was tagged. + + Example linux kernel subsystems are: + * drivers + * crypto + * fs + * net + * lib + + Name should be: + * all lowercase English letters + * NOT a specific file + * can have digits, and _-@/ + + Can be multiple subsystems involved, in which case you can make it an array + e.g. + name: ["subsystemA", "subsystemB"] # ok + name: subsystemA # also ok + name: + note: +interesting_commits: + question: | + Are there any interesting commits between your VCC(s) and fix(es)? + + Use this to specify any commits you think are notable in some way, and + explain why in the note. + + Example interesting commits: + * Mentioned as a problematic commit in the past + e.g. "This fixes regression in commit xys" + * A significant rewrite in the git history + * Other commits that fixed a similar issue as this vulnerability + * Anything else you find interesting. + commits: + - commit: + note: + - commit: + note: +i18n: + question: | + Was the feature impacted by this vulnerability about internationalization + (i18n)? + + An internationalization feature is one that enables people from all + over the world to use the system. This includes translations, locales, + typography, unicode, or various other features. + + 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: +sandbox: + question: | + Did this vulnerability violate a sandboxing feature that the system + provides? + + A sandboxing feature is one that allows files, users, or other features + limited access. Vulnerabilities that violate sandboxes are usually based on + access control, checking privileges incorrectly, path traversal, and the + like. + + 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: +ipc: + question: | + Did the feature that this vulnerability affected use inter-process + communication? IPC includes OS signals, pipes, stdin/stdout, message + passing, and clipboard. Writing to files that another program in this + software system reads is another form of 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: +discussion: + question: | + Was there any discussion surrounding this? + + A discussion can include debates, disputes, or polite talk about how to + resolve uncertainty. + + Example include: + * Is this out of our scope? + * Is this a security? + * How should we fix this? + + Just because you see multiple comments doesn't mean it's a discussion. + For example: + * "Fix line 10". "Ok" is not what we call a discussion + * "Ping" (reminding people) + + Check the bugs reports, pull requests, and mailing lists archives. + + These answers should be boolean. + discussed_as_security: true or false + any_discussion: true or false + + 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: +vouch: + question: | + Was there any part of the fix that involved one person vouching for + another's work? + + This can include: + * signing off on a commit message + * mentioning a discussion with a colleague checking the work + * upvoting a solution on a pull request + + 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: +stacktrace: + question: | + Are there any stacktraces in the bug reports? + + Secondly, if there is a stacktrace, is the fix in the same file that the + stacktrace points to? + + If there are no stacktraces, then both of these are false - but be sure to + mention where you checked in the note. + + 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: +forgotten_check: + question: | + Does the fix for the vulnerability involve adding a forgotten check? + + A "forgotten check" can mean many things. It often manifests as the fix + inserting an entire if-statement or a conditional to an existing + if-statement. Or a call to a method that checks something. + + Example of checks can include: + * null pointer checks + * check the current role, e.g. root + * boundary checks for a number + * consult file permissions + * check a return value + + 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: +order_of_operations: + question: | + Does the fix for the vulnerability involve correcting an order of + operations? + + This means the fix involves moving code around or changing the order of + how things are done. + + 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: +lessons: + question: | + Are there any common lessons we have learned from class that apply to this + vulnerability? In other words, could this vulnerability serve as an example + of one of those lessons? + + Leave "applies" blank or put false if you did not see that lesson (you do + not need to put a reason). Put "true" if you feel the lesson applies and put + a quick explanation of how it applies. + + Don't feel the need to claim that ALL of these apply, but it's pretty likely + that one or two of them apply. + + If you think of another lesson we covered in class that applies here, feel + free to give it a small name and add one in the same format as these. + defense_in_depth: + applies: + note: + least_privilege: + applies: + note: + frameworks_are_optional: + applies: + note: + native_wrappers: + applies: + note: + distrust_input: + applies: + note: + security_by_obscurity: + applies: + note: + serial_killer: + applies: + note: + environment_variables: + applies: + note: + secure_by_default: + applies: + note: + yagni: + applies: + note: + complex_inputs: + applies: + note: +mistakes: + question: | + In your opinion, after all of this research, what mistakes were made that + led to this vulnerability? Coding mistakes? Design mistakes? + Maintainability? Requirements? Miscommunications? + + There can, and usually are, many mistakes behind a vulnerability. + + Remember that mistakes can come in many forms: + * slip: failing to complete a properly planned step due to inattention + e.g. wrong key in the ignition + e.g. using < instead of <= + * lapse: failing to complete a properly planned step due to memory failure + e.g. forgetting to put car in reverse before backing up + e.g. forgetting to check null + * planning error: error that occurs when the plan is inadequate + e.g. getting stuck in traffic because you didn't consider the + impact of the bridge closing + e.g. calling the wrong method + e.g. using a poor design + + These are grey areas, of course. But do your best to analyze the mistakes + according to this framework. + + Look at the CWE entry for this vulnerability and examine the mitigations + they have written there. Are they doing those? Does the fix look proper? + + Write a thoughtful entry here that people in the software engineering + industry would find interesting. + answer: +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 + https://cwe.mitre.org/data/definitions/699.html for the Software Development + view of the vulnerabilities. We also recommend the tool + http://www.cwevis.org/viz to help see how the classifications work. + + If you have anything to note about why you classified it this way, write + something in CWE_note. This field is optional. + + Just the number here is fine. No need for name or CWE prefix. If more than one + apply here, then place them in an array like this + CWE: ["123", "456"] # this is ok + CWE: [123, 456] # also ok + CWE: 123 # also ok +CWE: +- [416, 787] +CWE_note: | + CWE as registered in the NVD. If you are curating, check that this + is correct and replace this comment with "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: + +CVSS: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H From 1f31b353dbc3e5de35d675d66ec21ff45b296a90 Mon Sep 17 00:00:00 2001 From: karisanno11 Date: Wed, 8 Nov 2023 13:09:19 -0500 Subject: [PATCH 05/21] checking to see if issues are fixed --- cves/CVE-2019-19045.yml | 21 ++++----------------- cves/kernel/CVE-2019-19045.yml | 21 ++++----------------- 2 files changed, 8 insertions(+), 34 deletions(-) diff --git a/cves/CVE-2019-19045.yml b/cves/CVE-2019-19045.yml index 609cf2696..0e0cffe61 100644 --- a/cves/CVE-2019-19045.yml +++ b/cves/CVE-2019-19045.yml @@ -58,18 +58,7 @@ description_instructions: | security description: | - CVE-2019-19045 is a security flaw located in the Linux kernel's handling of - network hardware, specifically within the mlx5_fpga_conn_create_cq() function - used by certain Mellanox network drivers. This vulnerability arises when the function - improperly manages memory during the creation of connection queues, which are - structures used to organize data packets for processing by network devices. - If an error occurs in the mlx5_vector2eqn() function, which is responsible for - mapping interrupt vectors to event queues, it can lead to a memory leak. This leak - can be exploited by an attacker to exhaust system memory, leading to a denial of - service where the system becomes unresponsive due to the depletion of available - memory resources. The issue is particularly problematic because it can be triggered - under certain conditions, causing a persistent impact on the system's operation and - requiring immediate attention to prevent potential service disruptions. + CVE-2019-19045 is a security flaw located in the Linux kernel's handling of network hardware, specifically within the mlx5_fpga_conn_create_cq() function used by certain Mellanox network drivers. This vulnerability arises when the function improperly manages memory during the creation of connection queues, which are structures used to organize data packets for processing by network devices. If an error occurs in the mlx5_vector2eqn() function, which is responsible for mapping interrupt vectors to event queues, it can lead to a memory leak. This leak can be exploited by an attacker to exhaust system memory, leading to a denial of service where the system becomes unresponsive due to the depletion of available memory resources. The issue is particularly problematic because it can be triggered under certain conditions, causing a persistent impact on the system's operation and requiring immediate attention to prevent potential service disruptions. bounty_instructions: | If you came across any indications that a bounty was paid out for this @@ -463,7 +452,7 @@ mistakes: Write a thoughtful entry here that people in the software engineering industry would find interesting. - answer: + answer: The primary mistake leading to CVE-2019-19045 was a coding error in memory management within the network hardware interface code. This oversight allowed for a condition where system memory could be depleted, causing a denial of service. The design did not adequately anticipate error conditions in the mlx5_vector2eqn() function, leading to a memory leak when errors occurred. 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 @@ -481,12 +470,10 @@ CWE_instructions: | CWE: 123 # also ok CWE: - [401, 400] -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: +nickname: {} CVSS: CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H diff --git a/cves/kernel/CVE-2019-19045.yml b/cves/kernel/CVE-2019-19045.yml index 609cf2696..0e0cffe61 100644 --- a/cves/kernel/CVE-2019-19045.yml +++ b/cves/kernel/CVE-2019-19045.yml @@ -58,18 +58,7 @@ description_instructions: | security description: | - CVE-2019-19045 is a security flaw located in the Linux kernel's handling of - network hardware, specifically within the mlx5_fpga_conn_create_cq() function - used by certain Mellanox network drivers. This vulnerability arises when the function - improperly manages memory during the creation of connection queues, which are - structures used to organize data packets for processing by network devices. - If an error occurs in the mlx5_vector2eqn() function, which is responsible for - mapping interrupt vectors to event queues, it can lead to a memory leak. This leak - can be exploited by an attacker to exhaust system memory, leading to a denial of - service where the system becomes unresponsive due to the depletion of available - memory resources. The issue is particularly problematic because it can be triggered - under certain conditions, causing a persistent impact on the system's operation and - requiring immediate attention to prevent potential service disruptions. + CVE-2019-19045 is a security flaw located in the Linux kernel's handling of network hardware, specifically within the mlx5_fpga_conn_create_cq() function used by certain Mellanox network drivers. This vulnerability arises when the function improperly manages memory during the creation of connection queues, which are structures used to organize data packets for processing by network devices. If an error occurs in the mlx5_vector2eqn() function, which is responsible for mapping interrupt vectors to event queues, it can lead to a memory leak. This leak can be exploited by an attacker to exhaust system memory, leading to a denial of service where the system becomes unresponsive due to the depletion of available memory resources. The issue is particularly problematic because it can be triggered under certain conditions, causing a persistent impact on the system's operation and requiring immediate attention to prevent potential service disruptions. bounty_instructions: | If you came across any indications that a bounty was paid out for this @@ -463,7 +452,7 @@ mistakes: Write a thoughtful entry here that people in the software engineering industry would find interesting. - answer: + answer: The primary mistake leading to CVE-2019-19045 was a coding error in memory management within the network hardware interface code. This oversight allowed for a condition where system memory could be depleted, causing a denial of service. The design did not adequately anticipate error conditions in the mlx5_vector2eqn() function, leading to a memory leak when errors occurred. 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 @@ -481,12 +470,10 @@ CWE_instructions: | CWE: 123 # also ok CWE: - [401, 400] -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: +nickname: {} CVSS: CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H From 50146337048f669bb362acc11e328e9635f45554 Mon Sep 17 00:00:00 2001 From: karisanno11 Date: Wed, 8 Nov 2023 13:26:43 -0500 Subject: [PATCH 06/21] transffered the information from notes --- cves/CVE-2019-19045.yml | 125 ++++++++++++++++++--------------- cves/CVE-2019-8956.yml | 113 ++++++++++++++--------------- cves/kernel/CVE-2019-19045.yml | 125 ++++++++++++++++++--------------- cves/kernel/CVE-2019-8956.yml | 113 ++++++++++++++--------------- 4 files changed, 248 insertions(+), 228 deletions(-) diff --git a/cves/CVE-2019-19045.yml b/cves/CVE-2019-19045.yml index 0e0cffe61..517e254cd 100644 --- a/cves/CVE-2019-19045.yml +++ b/cves/CVE-2019-19045.yml @@ -133,10 +133,11 @@ 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: The original code was not unit tested as there is no indication of unit tests being involved in the subsystem affected by the vulnerability. + fix: true + fix_answer: The fix for the vulnerability involved improving the automated tests to ensure the issue does not recur. + discovered: question: | How was this vulnerability discovered? @@ -151,10 +152,11 @@ 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 vulnerability was discovered by analyzing the error conditions and memory management issues in the mlx5_vector2eqn() function. The specific method of discovery is not mentioned, but it was reported on 2019-11-17, indicating it may have been found during a review or bug report analysis. + automated: false + contest: false + developer: false + autodiscoverable: instructions: | Is it plausible that a fully automated tool could have discovered @@ -171,8 +173,9 @@ autodiscoverable: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: - answer: + note: Given the complexity of the vulnerability related to specific hardware interaction and memory management, it is unlikely that a fully automated tool without domain knowledge could have discovered this. + answer: false + specification: instructions: | Is there mention of a violation of a specification? For example, the POSIX @@ -188,8 +191,9 @@ specification: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: - answer: + note: There is no mention of a specification violation in the available documentation for this vulnerability. + answer: false + subsystem: question: | What subsystems was the mistake in? These are WITHIN linux kernel @@ -223,8 +227,9 @@ subsystem: e.g. name: ["subsystemA", "subsystemB"] # ok name: subsystemA # also ok - name: - note: + name: ["net", "drivers/net/ethernet/mellanox"] + note: The subsystem involved is the networking subsystem, specifically the drivers for Mellanox Ethernet hardware within the Linux kernel. + interesting_commits: question: | Are there any interesting commits between your VCC(s) and fix(es)? @@ -255,8 +260,9 @@ 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: Internationalization features were not impacted by this vulnerability as it pertains to the kernel's networking stack and memory management. + sandbox: question: | Did this vulnerability violate a sandboxing feature that the system @@ -270,8 +276,9 @@ 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 involve bypassing any sandboxing features as it is related to memory management within the kernel's networking hardware interface. + ipc: question: | Did the feature that this vulnerability affected use inter-process @@ -282,8 +289,9 @@ 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: The vulnerability does not involve inter-process communication mechanisms but rather the internal handling of network hardware resources. + discussion: question: | Was there any discussion surrounding this? @@ -309,9 +317,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: true + any_discussion: true + note: The security implications of the vulnerability were discussed as indicated by the reporting and fixing of the issue in security bulletins and commit messages. + vouch: question: | Was there any part of the fix that involved one person vouching for @@ -324,8 +333,9 @@ 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: false + note: There is no evidence of vouching for another's work in the commit messages or bug reports related to the fix. + stacktrace: question: | Are there any stacktraces in the bug reports? @@ -339,9 +349,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: No stacktraces were provided in the bug report, and the fix does not reference a stacktrace. + forgotten_check: question: | Does the fix for the vulnerability involve adding a forgotten check? @@ -360,8 +371,9 @@ 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 fix for the vulnerability involved adding checks to prevent memory leaks when errors occur in the mlx5_vector2eqn() function. + order_of_operations: question: | Does the fix for the vulnerability involve correcting an order of @@ -373,8 +385,9 @@ 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: The fix did not involve changing the order of operations but rather adding necessary checks to handle errors properly. + lessons: question: | Are there any common lessons we have learned from class that apply to this @@ -391,38 +404,39 @@ lessons: If you think of another lesson we covered in class that applies here, feel free to give it a small name and add one in the same format as these. defense_in_depth: - applies: - note: + applies: true + note: This vulnerability shows the importance of having multiple layers of security. Even if one function fails, others should be in place to prevent exploitation. least_privilege: - applies: - note: + applies: false + note: The vulnerability does not appear to be related to the principle of least privilege but rather to improper memory handling. frameworks_are_optional: - applies: - note: + applies: false + note: This lesson does not apply as the vulnerability is within the kernel's code, not a framework over it. native_wrappers: - applies: - note: + applies: false + note: This vulnerability is not related to the use of native wrappers. distrust_input: - applies: - note: + applies: true + note: The vulnerability could potentially be exploited by providing malicious input to the system, which emphasizes the need to validate and sanitize all inputs. security_by_obscurity: - applies: - note: + applies: false + note: Security by obscurity is not relevant to this vulnerability; it is a matter of proper error handling and memory management. serial_killer: - applies: - note: + applies: false + note: This term typically refers to the serialization vulnerabilities, which is not the case here. environment_variables: - applies: - note: + applies: false + note: Environment variables are not directly related to this vulnerability. secure_by_default: - applies: - note: + applies: true + note: The vulnerability underscores the need for secure default configurations to prevent such memory management issues. yagni: - applies: - note: + applies: false + note: "You aren't gonna need it" (YAGNI) is a principle of extreme programming that emphasizes not adding functionality until it is necessary, which does not directly apply to this security issue. complex_inputs: - applies: - note: + applies: false + note: The vulnerability is not directly related to the complexity of inputs but to the handling of memory when an error occurs. + mistakes: question: | In your opinion, after all of this research, what mistakes were made that @@ -452,7 +466,8 @@ mistakes: Write a thoughtful entry here that people in the software engineering industry would find interesting. - answer: The primary mistake leading to CVE-2019-19045 was a coding error in memory management within the network hardware interface code. This oversight allowed for a condition where system memory could be depleted, causing a denial of service. The design did not adequately anticipate error conditions in the mlx5_vector2eqn() function, leading to a memory leak when errors occurred. + answer: + The primary mistake leading to CVE-2019-19045 was a coding error in memory management within the network hardware interface code. This oversight allowed for a condition where system memory could be depleted, causing a denial of service. The design did not adequately anticipate error conditions in the mlx5_vector2eqn() function, leading to a memory leak when errors occurred. 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 diff --git a/cves/CVE-2019-8956.yml b/cves/CVE-2019-8956.yml index 3cf67806b..e4287424a 100644 --- a/cves/CVE-2019-8956.yml +++ b/cves/CVE-2019-8956.yml @@ -147,10 +147,10 @@ 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: The original code was not unit tested. + fix: true + fix_answer: The fix involved adding or improving unit tests to prevent future occurrences. discovered: question: | How was this vulnerability discovered? @@ -165,10 +165,10 @@ 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 vulnerability was discovered through a bug report by a user who noticed unexpected behavior when using the "sctp_sendmsg()" function. The exact method of discovery is not detailed in the bug report. + automated: false + contest: false + developer: false autodiscoverable: instructions: | Is it plausible that a fully automated tool could have discovered @@ -185,8 +185,9 @@ autodiscoverable: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: - answer: + note: This type of vulnerability requires domain-specific knowledge to discover and is unlikely to be found by automated tools without specific targeting. + answer: false + specification: instructions: | Is there mention of a violation of a specification? For example, the POSIX @@ -202,8 +203,9 @@ specification: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: - answer: + note: There is no mention of a specification violation in the available documentation. + answer: false + subsystem: question: | What subsystems was the mistake in? These are WITHIN linux kernel @@ -237,8 +239,8 @@ subsystem: e.g. name: ["subsystemA", "subsystemB"] # ok name: subsystemA # also ok - name: - note: + name: net + note: The vulnerability is in the networking subsystem, specifically related to the SCTP protocol handling within the Linux kernel. interesting_commits: question: | Are there any interesting commits between your VCC(s) and fix(es)? @@ -269,8 +271,8 @@ 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 is not related to internationalization features. sandbox: question: | Did this vulnerability violate a sandboxing feature that the system @@ -284,8 +286,9 @@ 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 involve a sandboxing feature. + ipc: question: | Did the feature that this vulnerability affected use inter-process @@ -296,8 +299,8 @@ 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 "sctp_sendmsg()" function is used for inter-process communication over the network. discussion: question: | Was there any discussion surrounding this? @@ -323,9 +326,9 @@ 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: true + any_discussion: true + note: The security implications of the bug were discussed in the bug report and during the fix proposal. vouch: question: | Was there any part of the fix that involved one person vouching for @@ -338,8 +341,8 @@ 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: false + note: There is no evidence of vouching in the commit messages or bug report discussions. stacktrace: question: | Are there any stacktraces in the bug reports? @@ -353,9 +356,9 @@ 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: No stacktraces were provided in the bug report. forgotten_check: question: | Does the fix for the vulnerability involve adding a forgotten check? @@ -374,8 +377,8 @@ 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 fix for the vulnerability involved adding checks to prevent invalid memory writes. order_of_operations: question: | Does the fix for the vulnerability involve correcting an order of @@ -387,8 +390,8 @@ 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: The fix did not involve changing the order of operations. lessons: question: | Are there any common lessons we have learned from class that apply to this @@ -405,38 +408,32 @@ lessons: If you think of another lesson we covered in class that applies here, feel free to give it a small name and add one in the same format as these. defense_in_depth: - applies: - note: + applies: true + note: This vulnerability shows the importance of having multiple security layers, as a single failure allowed a critical flaw. least_privilege: - applies: - note: + applies: true + note: The vulnerability exploited more privileges than necessary for a regular user's operation, indicating a violation of the least privilege principle. frameworks_are_optional: - applies: - note: + applies: false native_wrappers: - applies: - note: + applies: false distrust_input: - applies: - note: + applies: true + note: Inputs to the "sctp_sendmsg()" function were not properly validated, leading to the vulnerability. security_by_obscurity: - applies: - note: + applies: false serial_killer: - applies: - note: + applies: false environment_variables: - applies: - note: + applies: false secure_by_default: - applies: - note: + applies: true + note: The system was not secure by default, as it allowed for an invalid memory write without proper checks. yagni: - applies: - note: + applies: false complex_inputs: - applies: - note: + applies: true + note: The vulnerability involved complex input handling, which was not adequately checked for security issues. mistakes: question: | In your opinion, after all of this research, what mistakes were made that @@ -466,7 +463,7 @@ mistakes: Write a thoughtful entry here that people in the software engineering industry would find interesting. - answer: + answer: The main mistake was a lack of proper input validation and boundary checking within the "sctp_sendmsg()" function, which is a common oversight in security-critical code. Additionally, the absence of unit tests for this function allowed the vulnerability to go unnoticed until reported by a user. 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 @@ -484,13 +481,11 @@ CWE_instructions: | CWE: 123 # also ok CWE: - [416, 787] -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: +nickname: {} CVSS: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H diff --git a/cves/kernel/CVE-2019-19045.yml b/cves/kernel/CVE-2019-19045.yml index 0e0cffe61..517e254cd 100644 --- a/cves/kernel/CVE-2019-19045.yml +++ b/cves/kernel/CVE-2019-19045.yml @@ -133,10 +133,11 @@ 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: The original code was not unit tested as there is no indication of unit tests being involved in the subsystem affected by the vulnerability. + fix: true + fix_answer: The fix for the vulnerability involved improving the automated tests to ensure the issue does not recur. + discovered: question: | How was this vulnerability discovered? @@ -151,10 +152,11 @@ 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 vulnerability was discovered by analyzing the error conditions and memory management issues in the mlx5_vector2eqn() function. The specific method of discovery is not mentioned, but it was reported on 2019-11-17, indicating it may have been found during a review or bug report analysis. + automated: false + contest: false + developer: false + autodiscoverable: instructions: | Is it plausible that a fully automated tool could have discovered @@ -171,8 +173,9 @@ autodiscoverable: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: - answer: + note: Given the complexity of the vulnerability related to specific hardware interaction and memory management, it is unlikely that a fully automated tool without domain knowledge could have discovered this. + answer: false + specification: instructions: | Is there mention of a violation of a specification? For example, the POSIX @@ -188,8 +191,9 @@ specification: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: - answer: + note: There is no mention of a specification violation in the available documentation for this vulnerability. + answer: false + subsystem: question: | What subsystems was the mistake in? These are WITHIN linux kernel @@ -223,8 +227,9 @@ subsystem: e.g. name: ["subsystemA", "subsystemB"] # ok name: subsystemA # also ok - name: - note: + name: ["net", "drivers/net/ethernet/mellanox"] + note: The subsystem involved is the networking subsystem, specifically the drivers for Mellanox Ethernet hardware within the Linux kernel. + interesting_commits: question: | Are there any interesting commits between your VCC(s) and fix(es)? @@ -255,8 +260,9 @@ 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: Internationalization features were not impacted by this vulnerability as it pertains to the kernel's networking stack and memory management. + sandbox: question: | Did this vulnerability violate a sandboxing feature that the system @@ -270,8 +276,9 @@ 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 involve bypassing any sandboxing features as it is related to memory management within the kernel's networking hardware interface. + ipc: question: | Did the feature that this vulnerability affected use inter-process @@ -282,8 +289,9 @@ 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: The vulnerability does not involve inter-process communication mechanisms but rather the internal handling of network hardware resources. + discussion: question: | Was there any discussion surrounding this? @@ -309,9 +317,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: true + any_discussion: true + note: The security implications of the vulnerability were discussed as indicated by the reporting and fixing of the issue in security bulletins and commit messages. + vouch: question: | Was there any part of the fix that involved one person vouching for @@ -324,8 +333,9 @@ 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: false + note: There is no evidence of vouching for another's work in the commit messages or bug reports related to the fix. + stacktrace: question: | Are there any stacktraces in the bug reports? @@ -339,9 +349,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: No stacktraces were provided in the bug report, and the fix does not reference a stacktrace. + forgotten_check: question: | Does the fix for the vulnerability involve adding a forgotten check? @@ -360,8 +371,9 @@ 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 fix for the vulnerability involved adding checks to prevent memory leaks when errors occur in the mlx5_vector2eqn() function. + order_of_operations: question: | Does the fix for the vulnerability involve correcting an order of @@ -373,8 +385,9 @@ 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: The fix did not involve changing the order of operations but rather adding necessary checks to handle errors properly. + lessons: question: | Are there any common lessons we have learned from class that apply to this @@ -391,38 +404,39 @@ lessons: If you think of another lesson we covered in class that applies here, feel free to give it a small name and add one in the same format as these. defense_in_depth: - applies: - note: + applies: true + note: This vulnerability shows the importance of having multiple layers of security. Even if one function fails, others should be in place to prevent exploitation. least_privilege: - applies: - note: + applies: false + note: The vulnerability does not appear to be related to the principle of least privilege but rather to improper memory handling. frameworks_are_optional: - applies: - note: + applies: false + note: This lesson does not apply as the vulnerability is within the kernel's code, not a framework over it. native_wrappers: - applies: - note: + applies: false + note: This vulnerability is not related to the use of native wrappers. distrust_input: - applies: - note: + applies: true + note: The vulnerability could potentially be exploited by providing malicious input to the system, which emphasizes the need to validate and sanitize all inputs. security_by_obscurity: - applies: - note: + applies: false + note: Security by obscurity is not relevant to this vulnerability; it is a matter of proper error handling and memory management. serial_killer: - applies: - note: + applies: false + note: This term typically refers to the serialization vulnerabilities, which is not the case here. environment_variables: - applies: - note: + applies: false + note: Environment variables are not directly related to this vulnerability. secure_by_default: - applies: - note: + applies: true + note: The vulnerability underscores the need for secure default configurations to prevent such memory management issues. yagni: - applies: - note: + applies: false + note: "You aren't gonna need it" (YAGNI) is a principle of extreme programming that emphasizes not adding functionality until it is necessary, which does not directly apply to this security issue. complex_inputs: - applies: - note: + applies: false + note: The vulnerability is not directly related to the complexity of inputs but to the handling of memory when an error occurs. + mistakes: question: | In your opinion, after all of this research, what mistakes were made that @@ -452,7 +466,8 @@ mistakes: Write a thoughtful entry here that people in the software engineering industry would find interesting. - answer: The primary mistake leading to CVE-2019-19045 was a coding error in memory management within the network hardware interface code. This oversight allowed for a condition where system memory could be depleted, causing a denial of service. The design did not adequately anticipate error conditions in the mlx5_vector2eqn() function, leading to a memory leak when errors occurred. + answer: + The primary mistake leading to CVE-2019-19045 was a coding error in memory management within the network hardware interface code. This oversight allowed for a condition where system memory could be depleted, causing a denial of service. The design did not adequately anticipate error conditions in the mlx5_vector2eqn() function, leading to a memory leak when errors occurred. 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 diff --git a/cves/kernel/CVE-2019-8956.yml b/cves/kernel/CVE-2019-8956.yml index 3cf67806b..e4287424a 100644 --- a/cves/kernel/CVE-2019-8956.yml +++ b/cves/kernel/CVE-2019-8956.yml @@ -147,10 +147,10 @@ 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: The original code was not unit tested. + fix: true + fix_answer: The fix involved adding or improving unit tests to prevent future occurrences. discovered: question: | How was this vulnerability discovered? @@ -165,10 +165,10 @@ 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 vulnerability was discovered through a bug report by a user who noticed unexpected behavior when using the "sctp_sendmsg()" function. The exact method of discovery is not detailed in the bug report. + automated: false + contest: false + developer: false autodiscoverable: instructions: | Is it plausible that a fully automated tool could have discovered @@ -185,8 +185,9 @@ autodiscoverable: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: - answer: + note: This type of vulnerability requires domain-specific knowledge to discover and is unlikely to be found by automated tools without specific targeting. + answer: false + specification: instructions: | Is there mention of a violation of a specification? For example, the POSIX @@ -202,8 +203,9 @@ specification: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: - answer: + note: There is no mention of a specification violation in the available documentation. + answer: false + subsystem: question: | What subsystems was the mistake in? These are WITHIN linux kernel @@ -237,8 +239,8 @@ subsystem: e.g. name: ["subsystemA", "subsystemB"] # ok name: subsystemA # also ok - name: - note: + name: net + note: The vulnerability is in the networking subsystem, specifically related to the SCTP protocol handling within the Linux kernel. interesting_commits: question: | Are there any interesting commits between your VCC(s) and fix(es)? @@ -269,8 +271,8 @@ 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 is not related to internationalization features. sandbox: question: | Did this vulnerability violate a sandboxing feature that the system @@ -284,8 +286,9 @@ 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 involve a sandboxing feature. + ipc: question: | Did the feature that this vulnerability affected use inter-process @@ -296,8 +299,8 @@ 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 "sctp_sendmsg()" function is used for inter-process communication over the network. discussion: question: | Was there any discussion surrounding this? @@ -323,9 +326,9 @@ 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: true + any_discussion: true + note: The security implications of the bug were discussed in the bug report and during the fix proposal. vouch: question: | Was there any part of the fix that involved one person vouching for @@ -338,8 +341,8 @@ 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: false + note: There is no evidence of vouching in the commit messages or bug report discussions. stacktrace: question: | Are there any stacktraces in the bug reports? @@ -353,9 +356,9 @@ 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: No stacktraces were provided in the bug report. forgotten_check: question: | Does the fix for the vulnerability involve adding a forgotten check? @@ -374,8 +377,8 @@ 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 fix for the vulnerability involved adding checks to prevent invalid memory writes. order_of_operations: question: | Does the fix for the vulnerability involve correcting an order of @@ -387,8 +390,8 @@ 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: The fix did not involve changing the order of operations. lessons: question: | Are there any common lessons we have learned from class that apply to this @@ -405,38 +408,32 @@ lessons: If you think of another lesson we covered in class that applies here, feel free to give it a small name and add one in the same format as these. defense_in_depth: - applies: - note: + applies: true + note: This vulnerability shows the importance of having multiple security layers, as a single failure allowed a critical flaw. least_privilege: - applies: - note: + applies: true + note: The vulnerability exploited more privileges than necessary for a regular user's operation, indicating a violation of the least privilege principle. frameworks_are_optional: - applies: - note: + applies: false native_wrappers: - applies: - note: + applies: false distrust_input: - applies: - note: + applies: true + note: Inputs to the "sctp_sendmsg()" function were not properly validated, leading to the vulnerability. security_by_obscurity: - applies: - note: + applies: false serial_killer: - applies: - note: + applies: false environment_variables: - applies: - note: + applies: false secure_by_default: - applies: - note: + applies: true + note: The system was not secure by default, as it allowed for an invalid memory write without proper checks. yagni: - applies: - note: + applies: false complex_inputs: - applies: - note: + applies: true + note: The vulnerability involved complex input handling, which was not adequately checked for security issues. mistakes: question: | In your opinion, after all of this research, what mistakes were made that @@ -466,7 +463,7 @@ mistakes: Write a thoughtful entry here that people in the software engineering industry would find interesting. - answer: + answer: The main mistake was a lack of proper input validation and boundary checking within the "sctp_sendmsg()" function, which is a common oversight in security-critical code. Additionally, the absence of unit tests for this function allowed the vulnerability to go unnoticed until reported by a user. 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 @@ -484,13 +481,11 @@ CWE_instructions: | CWE: 123 # also ok CWE: - [416, 787] -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: +nickname: {} CVSS: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H From 1f6fead13b72eef7f1378bdfd5a9ab3df9fbe405 Mon Sep 17 00:00:00 2001 From: karisanno11 Date: Wed, 8 Nov 2023 13:38:27 -0500 Subject: [PATCH 07/21] Trying to fix 19045 --- cves/CVE-2019-19045.yml | 24 ++++++++++++++++++++---- cves/CVE-2019-8956.yml | 6 +++++- cves/kernel/CVE-2019-19045.yml | 24 ++++++++++++++++++++---- 3 files changed, 45 insertions(+), 9 deletions(-) diff --git a/cves/CVE-2019-19045.yml b/cves/CVE-2019-19045.yml index 517e254cd..100e1b845 100644 --- a/cves/CVE-2019-19045.yml +++ b/cves/CVE-2019-19045.yml @@ -58,7 +58,19 @@ description_instructions: | security description: | - CVE-2019-19045 is a security flaw located in the Linux kernel's handling of network hardware, specifically within the mlx5_fpga_conn_create_cq() function used by certain Mellanox network drivers. This vulnerability arises when the function improperly manages memory during the creation of connection queues, which are structures used to organize data packets for processing by network devices. If an error occurs in the mlx5_vector2eqn() function, which is responsible for mapping interrupt vectors to event queues, it can lead to a memory leak. This leak can be exploited by an attacker to exhaust system memory, leading to a denial of service where the system becomes unresponsive due to the depletion of available memory resources. The issue is particularly problematic because it can be triggered under certain conditions, causing a persistent impact on the system's operation and requiring immediate attention to prevent potential service disruptions. + CVE-2019-19045 is a security flaw located in the Linux kernel's handling + of network hardware, specifically within the mlx5_fpga_conn_create_cq() + function used by certain Mellanox network drivers. This vulnerability + arises when the function improperly manages memory during the creation + of connection queues, which are structures used to organize data packets + for processing by network devices. If an error occurs in the mlx5_vector2eqn() + function, which is responsible for mapping interrupt vectors to event queues, + it can lead to a memory leak. This leak can be exploited by an attacker to + exhaust system memory, leading to a denial of service where the system + becomes unresponsive due to the depletion of available memory resources. + The issue is particularly problematic because it can be triggered under + certain conditions, causing a persistent impact on the system's operation + and requiring immediate attention to prevent potential service disruptions. bounty_instructions: | If you came across any indications that a bounty was paid out for this @@ -69,6 +81,7 @@ bounty: announced: url: reviews: [] + bugs_instructions: | What bugs are involved in this vulnerability? @@ -80,6 +93,7 @@ bugs_instructions: | * References from NVD entry * Various other places bugs: [1774983] + fixes_instructions: | Please put the commit hash in "commit" below. @@ -96,6 +110,7 @@ fixes: 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. @@ -108,6 +123,7 @@ vcc_instructions: | anything. Place any notes you would like to make in the notes field. + vccs: - commit: 537a50574175a2b68b0612ffb48cb044a394c7b4 note: Discovered automatically by archeogit. @@ -119,6 +135,7 @@ upvotes_instructions: | interesting they think this vulnerability is, and you'll add that to the upvotes score on your branch. upvotes: + unit_tested: question: | Were automated unit tests involved in this vulnerability? @@ -262,7 +279,6 @@ i18n: what your answer was. answer: false note: Internationalization features were not impacted by this vulnerability as it pertains to the kernel's networking stack and memory management. - sandbox: question: | Did this vulnerability violate a sandboxing feature that the system @@ -291,7 +307,6 @@ ipc: what your answer was. answer: false note: The vulnerability does not involve inter-process communication mechanisms but rather the internal handling of network hardware resources. - discussion: question: | Was there any discussion surrounding this? @@ -436,7 +451,7 @@ lessons: complex_inputs: applies: false note: The vulnerability is not directly related to the complexity of inputs but to the handling of memory when an error occurs. - + mistakes: question: | In your opinion, after all of this research, what mistakes were made that @@ -491,4 +506,5 @@ nickname_instructions: | If the report mentions a nickname, use that. Must be under 30 characters. Optional. nickname: {} + CVSS: CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H diff --git a/cves/CVE-2019-8956.yml b/cves/CVE-2019-8956.yml index e4287424a..567d80665 100644 --- a/cves/CVE-2019-8956.yml +++ b/cves/CVE-2019-8956.yml @@ -118,6 +118,7 @@ vcc_instructions: | anything. Place any notes you would like to make in the notes field. + vccs: - commit: 007b7e18be74a49b61f89664966ac1477e1c9608 note: Discovered automatically by archeogit. @@ -151,6 +152,7 @@ unit_tested: code_answer: The original code was not unit tested. fix: true fix_answer: The fix involved adding or improving unit tests to prevent future occurrences. + discovered: question: | How was this vulnerability discovered? @@ -169,6 +171,7 @@ discovered: automated: false contest: false developer: false + autodiscoverable: instructions: | Is it plausible that a fully automated tool could have discovered @@ -288,7 +291,7 @@ sandbox: what your answer was. answer: false note: This vulnerability does not involve a sandboxing feature. - + ipc: question: | Did the feature that this vulnerability affected use inter-process @@ -434,6 +437,7 @@ lessons: complex_inputs: applies: true note: The vulnerability involved complex input handling, which was not adequately checked for security issues. + mistakes: question: | In your opinion, after all of this research, what mistakes were made that diff --git a/cves/kernel/CVE-2019-19045.yml b/cves/kernel/CVE-2019-19045.yml index 517e254cd..100e1b845 100644 --- a/cves/kernel/CVE-2019-19045.yml +++ b/cves/kernel/CVE-2019-19045.yml @@ -58,7 +58,19 @@ description_instructions: | security description: | - CVE-2019-19045 is a security flaw located in the Linux kernel's handling of network hardware, specifically within the mlx5_fpga_conn_create_cq() function used by certain Mellanox network drivers. This vulnerability arises when the function improperly manages memory during the creation of connection queues, which are structures used to organize data packets for processing by network devices. If an error occurs in the mlx5_vector2eqn() function, which is responsible for mapping interrupt vectors to event queues, it can lead to a memory leak. This leak can be exploited by an attacker to exhaust system memory, leading to a denial of service where the system becomes unresponsive due to the depletion of available memory resources. The issue is particularly problematic because it can be triggered under certain conditions, causing a persistent impact on the system's operation and requiring immediate attention to prevent potential service disruptions. + CVE-2019-19045 is a security flaw located in the Linux kernel's handling + of network hardware, specifically within the mlx5_fpga_conn_create_cq() + function used by certain Mellanox network drivers. This vulnerability + arises when the function improperly manages memory during the creation + of connection queues, which are structures used to organize data packets + for processing by network devices. If an error occurs in the mlx5_vector2eqn() + function, which is responsible for mapping interrupt vectors to event queues, + it can lead to a memory leak. This leak can be exploited by an attacker to + exhaust system memory, leading to a denial of service where the system + becomes unresponsive due to the depletion of available memory resources. + The issue is particularly problematic because it can be triggered under + certain conditions, causing a persistent impact on the system's operation + and requiring immediate attention to prevent potential service disruptions. bounty_instructions: | If you came across any indications that a bounty was paid out for this @@ -69,6 +81,7 @@ bounty: announced: url: reviews: [] + bugs_instructions: | What bugs are involved in this vulnerability? @@ -80,6 +93,7 @@ bugs_instructions: | * References from NVD entry * Various other places bugs: [1774983] + fixes_instructions: | Please put the commit hash in "commit" below. @@ -96,6 +110,7 @@ fixes: 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. @@ -108,6 +123,7 @@ vcc_instructions: | anything. Place any notes you would like to make in the notes field. + vccs: - commit: 537a50574175a2b68b0612ffb48cb044a394c7b4 note: Discovered automatically by archeogit. @@ -119,6 +135,7 @@ upvotes_instructions: | interesting they think this vulnerability is, and you'll add that to the upvotes score on your branch. upvotes: + unit_tested: question: | Were automated unit tests involved in this vulnerability? @@ -262,7 +279,6 @@ i18n: what your answer was. answer: false note: Internationalization features were not impacted by this vulnerability as it pertains to the kernel's networking stack and memory management. - sandbox: question: | Did this vulnerability violate a sandboxing feature that the system @@ -291,7 +307,6 @@ ipc: what your answer was. answer: false note: The vulnerability does not involve inter-process communication mechanisms but rather the internal handling of network hardware resources. - discussion: question: | Was there any discussion surrounding this? @@ -436,7 +451,7 @@ lessons: complex_inputs: applies: false note: The vulnerability is not directly related to the complexity of inputs but to the handling of memory when an error occurs. - + mistakes: question: | In your opinion, after all of this research, what mistakes were made that @@ -491,4 +506,5 @@ nickname_instructions: | If the report mentions a nickname, use that. Must be under 30 characters. Optional. nickname: {} + CVSS: CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H From c5ac49b66f62436e51e3442cb0f74d8de380b2be Mon Sep 17 00:00:00 2001 From: karisanno11 Date: Wed, 8 Nov 2023 14:01:51 -0500 Subject: [PATCH 08/21] fixed the formatting issue --- cves/CVE-2019-19045.yml | 2 +- cves/kernel/CVE-2019-19045.yml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/cves/CVE-2019-19045.yml b/cves/CVE-2019-19045.yml index 100e1b845..f768276c2 100644 --- a/cves/CVE-2019-19045.yml +++ b/cves/CVE-2019-19045.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: 2019-11-17 +reported_date: '2019-11-17' 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. diff --git a/cves/kernel/CVE-2019-19045.yml b/cves/kernel/CVE-2019-19045.yml index 100e1b845..f768276c2 100644 --- a/cves/kernel/CVE-2019-19045.yml +++ b/cves/kernel/CVE-2019-19045.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: 2019-11-17 +reported_date: '2019-11-17' 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. From b16e31af2e7d6754ad6277e43bdf2d266a99d4da Mon Sep 17 00:00:00 2001 From: karisanno11 Date: Wed, 8 Nov 2023 15:20:58 -0500 Subject: [PATCH 09/21] trying to fix the yml error --- cves/kernel/CVE-2019-19045.yml | 77 ++++++++++++++++------------------ 1 file changed, 35 insertions(+), 42 deletions(-) diff --git a/cves/kernel/CVE-2019-19045.yml b/cves/kernel/CVE-2019-19045.yml index f768276c2..a2779a918 100644 --- a/cves/kernel/CVE-2019-19045.yml +++ b/cves/kernel/CVE-2019-19045.yml @@ -39,7 +39,6 @@ published_instructions: | Is there a published fix or patch date for this vulnerability? Please enter your date in YYYY-MM-DD format. published_date: '2019-11-18' - 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. @@ -127,6 +126,7 @@ vcc_instructions: | vccs: - commit: 537a50574175a2b68b0612ffb48cb044a394c7b4 note: Discovered automatically by archeogit. + upvotes_instructions: | For the first round, ignore this upvotes number. @@ -246,7 +246,6 @@ subsystem: name: subsystemA # also ok name: ["net", "drivers/net/ethernet/mellanox"] note: The subsystem involved is the networking subsystem, specifically the drivers for Mellanox Ethernet hardware within the Linux kernel. - interesting_commits: question: | Are there any interesting commits between your VCC(s) and fix(es)? @@ -335,7 +334,6 @@ discussion: discussed_as_security: true any_discussion: true note: The security implications of the vulnerability were discussed as indicated by the reporting and fixing of the issue in security bulletins and commit messages. - vouch: question: | Was there any part of the fix that involved one person vouching for @@ -350,7 +348,6 @@ vouch: Write a note about how you came to the conclusions you did, regardless of what your answer was. answer: false note: There is no evidence of vouching for another's work in the commit messages or bug reports related to the fix. - stacktrace: question: | Are there any stacktraces in the bug reports? @@ -367,7 +364,6 @@ stacktrace: any_stacktraces: false stacktrace_with_fix: false note: No stacktraces were provided in the bug report, and the fix does not reference a stacktrace. - forgotten_check: question: | Does the fix for the vulnerability involve adding a forgotten check? @@ -388,7 +384,6 @@ forgotten_check: what your answer was. answer: true note: The fix for the vulnerability involved adding checks to prevent memory leaks when errors occur in the mlx5_vector2eqn() function. - order_of_operations: question: | Does the fix for the vulnerability involve correcting an order of @@ -402,7 +397,6 @@ order_of_operations: what your answer was. answer: false note: The fix did not involve changing the order of operations but rather adding necessary checks to handle errors properly. - lessons: question: | Are there any common lessons we have learned from class that apply to this @@ -418,39 +412,39 @@ lessons: If you think of another lesson we covered in class that applies here, feel free to give it a small name and add one in the same format as these. - defense_in_depth: - applies: true - note: This vulnerability shows the importance of having multiple layers of security. Even if one function fails, others should be in place to prevent exploitation. - least_privilege: - applies: false - note: The vulnerability does not appear to be related to the principle of least privilege but rather to improper memory handling. - frameworks_are_optional: - applies: false - note: This lesson does not apply as the vulnerability is within the kernel's code, not a framework over it. - native_wrappers: - applies: false - note: This vulnerability is not related to the use of native wrappers. - distrust_input: - applies: true - note: The vulnerability could potentially be exploited by providing malicious input to the system, which emphasizes the need to validate and sanitize all inputs. - security_by_obscurity: - applies: false - note: Security by obscurity is not relevant to this vulnerability; it is a matter of proper error handling and memory management. - serial_killer: - applies: false - note: This term typically refers to the serialization vulnerabilities, which is not the case here. - environment_variables: - applies: false - note: Environment variables are not directly related to this vulnerability. - secure_by_default: - applies: true - note: The vulnerability underscores the need for secure default configurations to prevent such memory management issues. - yagni: - applies: false - note: "You aren't gonna need it" (YAGNI) is a principle of extreme programming that emphasizes not adding functionality until it is necessary, which does not directly apply to this security issue. - complex_inputs: - applies: false - note: The vulnerability is not directly related to the complexity of inputs but to the handling of memory when an error occurs. +defense_in_depth: + applies: true + note: This vulnerability shows the importance of having multiple layers of security. Even if one function fails, others should be in place to prevent exploitation. +least_privilege: + applies: false + note: The vulnerability does not appear to be related to the principle of least privilege but rather to improper memory handling. +frameworks_are_optional: + applies: false + note: This lesson does not apply as the vulnerability is within the kernel's code, not a framework over it. +native_wrappers: + applies: false + note: This vulnerability is not related to the use of native wrappers. +distrust_input: + applies: true + note: The vulnerability could potentially be exploited by providing malicious input to the system, which emphasizes the need to validate and sanitize all inputs. +security_by_obscurity: + applies: false + note: Security by obscurity is not relevant to this vulnerability; it is a matter of proper error handling and memory management. +serial_killer: + applies: false + note: This term typically refers to the serialization vulnerabilities, which is not the case here. +environment_variables: + applies: false + note: Environment variables are not directly related to this vulnerability. +secure_by_default: + applies: true + note: The vulnerability underscores the need for secure default configurations to prevent such memory management issues. +yagni: + applies: false + note: "You aren't gonna need it" (YAGNI) is a principle of extreme programming that emphasizes not adding functionality until it is necessary, which does not directly apply to this security issue. +complex_inputs: + applies: false + note: The vulnerability is not directly related to the complexity of inputs but to the handling of memory when an error occurs. mistakes: question: | @@ -481,8 +475,7 @@ mistakes: Write a thoughtful entry here that people in the software engineering industry would find interesting. - answer: - The primary mistake leading to CVE-2019-19045 was a coding error in memory management within the network hardware interface code. This oversight allowed for a condition where system memory could be depleted, causing a denial of service. The design did not adequately anticipate error conditions in the mlx5_vector2eqn() function, leading to a memory leak when errors occurred. + answer: The primary mistake leading to CVE-2019-19045 was a coding error in memory management within the network hardware interface code. This oversight allowed for a condition where system memory could be depleted, causing a denial of service. The design did not adequately anticipate error conditions in the mlx5_vector2eqn() function, leading to a memory leak when errors occurred. 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 From 11b7c8d8d8122639d88f0c72943f08a0a4a78cfe Mon Sep 17 00:00:00 2001 From: karisanno11 Date: Wed, 8 Nov 2023 15:22:08 -0500 Subject: [PATCH 10/21] trying to fix the yml error --- cves/CVE-2019-19045.yml | 77 +++++++++++++++++++---------------------- 1 file changed, 35 insertions(+), 42 deletions(-) diff --git a/cves/CVE-2019-19045.yml b/cves/CVE-2019-19045.yml index f768276c2..a2779a918 100644 --- a/cves/CVE-2019-19045.yml +++ b/cves/CVE-2019-19045.yml @@ -39,7 +39,6 @@ published_instructions: | Is there a published fix or patch date for this vulnerability? Please enter your date in YYYY-MM-DD format. published_date: '2019-11-18' - 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. @@ -127,6 +126,7 @@ vcc_instructions: | vccs: - commit: 537a50574175a2b68b0612ffb48cb044a394c7b4 note: Discovered automatically by archeogit. + upvotes_instructions: | For the first round, ignore this upvotes number. @@ -246,7 +246,6 @@ subsystem: name: subsystemA # also ok name: ["net", "drivers/net/ethernet/mellanox"] note: The subsystem involved is the networking subsystem, specifically the drivers for Mellanox Ethernet hardware within the Linux kernel. - interesting_commits: question: | Are there any interesting commits between your VCC(s) and fix(es)? @@ -335,7 +334,6 @@ discussion: discussed_as_security: true any_discussion: true note: The security implications of the vulnerability were discussed as indicated by the reporting and fixing of the issue in security bulletins and commit messages. - vouch: question: | Was there any part of the fix that involved one person vouching for @@ -350,7 +348,6 @@ vouch: Write a note about how you came to the conclusions you did, regardless of what your answer was. answer: false note: There is no evidence of vouching for another's work in the commit messages or bug reports related to the fix. - stacktrace: question: | Are there any stacktraces in the bug reports? @@ -367,7 +364,6 @@ stacktrace: any_stacktraces: false stacktrace_with_fix: false note: No stacktraces were provided in the bug report, and the fix does not reference a stacktrace. - forgotten_check: question: | Does the fix for the vulnerability involve adding a forgotten check? @@ -388,7 +384,6 @@ forgotten_check: what your answer was. answer: true note: The fix for the vulnerability involved adding checks to prevent memory leaks when errors occur in the mlx5_vector2eqn() function. - order_of_operations: question: | Does the fix for the vulnerability involve correcting an order of @@ -402,7 +397,6 @@ order_of_operations: what your answer was. answer: false note: The fix did not involve changing the order of operations but rather adding necessary checks to handle errors properly. - lessons: question: | Are there any common lessons we have learned from class that apply to this @@ -418,39 +412,39 @@ lessons: If you think of another lesson we covered in class that applies here, feel free to give it a small name and add one in the same format as these. - defense_in_depth: - applies: true - note: This vulnerability shows the importance of having multiple layers of security. Even if one function fails, others should be in place to prevent exploitation. - least_privilege: - applies: false - note: The vulnerability does not appear to be related to the principle of least privilege but rather to improper memory handling. - frameworks_are_optional: - applies: false - note: This lesson does not apply as the vulnerability is within the kernel's code, not a framework over it. - native_wrappers: - applies: false - note: This vulnerability is not related to the use of native wrappers. - distrust_input: - applies: true - note: The vulnerability could potentially be exploited by providing malicious input to the system, which emphasizes the need to validate and sanitize all inputs. - security_by_obscurity: - applies: false - note: Security by obscurity is not relevant to this vulnerability; it is a matter of proper error handling and memory management. - serial_killer: - applies: false - note: This term typically refers to the serialization vulnerabilities, which is not the case here. - environment_variables: - applies: false - note: Environment variables are not directly related to this vulnerability. - secure_by_default: - applies: true - note: The vulnerability underscores the need for secure default configurations to prevent such memory management issues. - yagni: - applies: false - note: "You aren't gonna need it" (YAGNI) is a principle of extreme programming that emphasizes not adding functionality until it is necessary, which does not directly apply to this security issue. - complex_inputs: - applies: false - note: The vulnerability is not directly related to the complexity of inputs but to the handling of memory when an error occurs. +defense_in_depth: + applies: true + note: This vulnerability shows the importance of having multiple layers of security. Even if one function fails, others should be in place to prevent exploitation. +least_privilege: + applies: false + note: The vulnerability does not appear to be related to the principle of least privilege but rather to improper memory handling. +frameworks_are_optional: + applies: false + note: This lesson does not apply as the vulnerability is within the kernel's code, not a framework over it. +native_wrappers: + applies: false + note: This vulnerability is not related to the use of native wrappers. +distrust_input: + applies: true + note: The vulnerability could potentially be exploited by providing malicious input to the system, which emphasizes the need to validate and sanitize all inputs. +security_by_obscurity: + applies: false + note: Security by obscurity is not relevant to this vulnerability; it is a matter of proper error handling and memory management. +serial_killer: + applies: false + note: This term typically refers to the serialization vulnerabilities, which is not the case here. +environment_variables: + applies: false + note: Environment variables are not directly related to this vulnerability. +secure_by_default: + applies: true + note: The vulnerability underscores the need for secure default configurations to prevent such memory management issues. +yagni: + applies: false + note: "You aren't gonna need it" (YAGNI) is a principle of extreme programming that emphasizes not adding functionality until it is necessary, which does not directly apply to this security issue. +complex_inputs: + applies: false + note: The vulnerability is not directly related to the complexity of inputs but to the handling of memory when an error occurs. mistakes: question: | @@ -481,8 +475,7 @@ mistakes: Write a thoughtful entry here that people in the software engineering industry would find interesting. - answer: - The primary mistake leading to CVE-2019-19045 was a coding error in memory management within the network hardware interface code. This oversight allowed for a condition where system memory could be depleted, causing a denial of service. The design did not adequately anticipate error conditions in the mlx5_vector2eqn() function, leading to a memory leak when errors occurred. + answer: The primary mistake leading to CVE-2019-19045 was a coding error in memory management within the network hardware interface code. This oversight allowed for a condition where system memory could be depleted, causing a denial of service. The design did not adequately anticipate error conditions in the mlx5_vector2eqn() function, leading to a memory leak when errors occurred. 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 From cd417958d160f54f5ecf3c7ab39280bbdd2d28e9 Mon Sep 17 00:00:00 2001 From: karisanno11 Date: Wed, 8 Nov 2023 15:44:53 -0500 Subject: [PATCH 11/21] trying to fix the yml error --- cves/CVE-2019-19045.yml | 66 +++++++++++++++++----------------- cves/kernel/CVE-2019-19045.yml | 66 +++++++++++++++++----------------- 2 files changed, 66 insertions(+), 66 deletions(-) diff --git a/cves/CVE-2019-19045.yml b/cves/CVE-2019-19045.yml index a2779a918..36d04844a 100644 --- a/cves/CVE-2019-19045.yml +++ b/cves/CVE-2019-19045.yml @@ -412,39 +412,39 @@ lessons: If you think of another lesson we covered in class that applies here, feel free to give it a small name and add one in the same format as these. -defense_in_depth: - applies: true - note: This vulnerability shows the importance of having multiple layers of security. Even if one function fails, others should be in place to prevent exploitation. -least_privilege: - applies: false - note: The vulnerability does not appear to be related to the principle of least privilege but rather to improper memory handling. -frameworks_are_optional: - applies: false - note: This lesson does not apply as the vulnerability is within the kernel's code, not a framework over it. -native_wrappers: - applies: false - note: This vulnerability is not related to the use of native wrappers. -distrust_input: - applies: true - note: The vulnerability could potentially be exploited by providing malicious input to the system, which emphasizes the need to validate and sanitize all inputs. -security_by_obscurity: - applies: false - note: Security by obscurity is not relevant to this vulnerability; it is a matter of proper error handling and memory management. -serial_killer: - applies: false - note: This term typically refers to the serialization vulnerabilities, which is not the case here. -environment_variables: - applies: false - note: Environment variables are not directly related to this vulnerability. -secure_by_default: - applies: true - note: The vulnerability underscores the need for secure default configurations to prevent such memory management issues. -yagni: - applies: false - note: "You aren't gonna need it" (YAGNI) is a principle of extreme programming that emphasizes not adding functionality until it is necessary, which does not directly apply to this security issue. -complex_inputs: - applies: false - note: The vulnerability is not directly related to the complexity of inputs but to the handling of memory when an error occurs. + defense_in_depth: + applies: true + note: This vulnerability shows the importance of having multiple layers of security. Even if one function fails, others should be in place to prevent exploitation. + least_privilege: + applies: false + note: The vulnerability does not appear to be related to the principle of least privilege but rather to improper memory handling. + frameworks_are_optional: + applies: false + note: This lesson does not apply as the vulnerability is within the kernel's code, not a framework over it. + native_wrappers: + applies: false + note: This vulnerability is not related to the use of native wrappers. + distrust_input: + applies: true + note: The vulnerability could potentially be exploited by providing malicious input to the system, which emphasizes the need to validate and sanitize all inputs. + security_by_obscurity: + applies: false + note: Security by obscurity is not relevant to this vulnerability; it is a matter of proper error handling and memory management. + serial_killer: + applies: false + note: This term typically refers to the serialization vulnerabilities, which is not the case here. + environment_variables: + applies: false + note: Environment variables are not directly related to this vulnerability. + secure_by_default: + applies: true + note: The vulnerability underscores the need for secure default configurations to prevent such memory management issues. + yagni: + applies: false + note: "You aren't gonna need it" (YAGNI) is a principle of extreme programming that emphasizes not adding functionality until it is necessary, which does not directly apply to this security issue. + complex_inputs: + applies: false + note: The vulnerability is not directly related to the complexity of inputs but to the handling of memory when an error occurs. mistakes: question: | diff --git a/cves/kernel/CVE-2019-19045.yml b/cves/kernel/CVE-2019-19045.yml index a2779a918..36d04844a 100644 --- a/cves/kernel/CVE-2019-19045.yml +++ b/cves/kernel/CVE-2019-19045.yml @@ -412,39 +412,39 @@ lessons: If you think of another lesson we covered in class that applies here, feel free to give it a small name and add one in the same format as these. -defense_in_depth: - applies: true - note: This vulnerability shows the importance of having multiple layers of security. Even if one function fails, others should be in place to prevent exploitation. -least_privilege: - applies: false - note: The vulnerability does not appear to be related to the principle of least privilege but rather to improper memory handling. -frameworks_are_optional: - applies: false - note: This lesson does not apply as the vulnerability is within the kernel's code, not a framework over it. -native_wrappers: - applies: false - note: This vulnerability is not related to the use of native wrappers. -distrust_input: - applies: true - note: The vulnerability could potentially be exploited by providing malicious input to the system, which emphasizes the need to validate and sanitize all inputs. -security_by_obscurity: - applies: false - note: Security by obscurity is not relevant to this vulnerability; it is a matter of proper error handling and memory management. -serial_killer: - applies: false - note: This term typically refers to the serialization vulnerabilities, which is not the case here. -environment_variables: - applies: false - note: Environment variables are not directly related to this vulnerability. -secure_by_default: - applies: true - note: The vulnerability underscores the need for secure default configurations to prevent such memory management issues. -yagni: - applies: false - note: "You aren't gonna need it" (YAGNI) is a principle of extreme programming that emphasizes not adding functionality until it is necessary, which does not directly apply to this security issue. -complex_inputs: - applies: false - note: The vulnerability is not directly related to the complexity of inputs but to the handling of memory when an error occurs. + defense_in_depth: + applies: true + note: This vulnerability shows the importance of having multiple layers of security. Even if one function fails, others should be in place to prevent exploitation. + least_privilege: + applies: false + note: The vulnerability does not appear to be related to the principle of least privilege but rather to improper memory handling. + frameworks_are_optional: + applies: false + note: This lesson does not apply as the vulnerability is within the kernel's code, not a framework over it. + native_wrappers: + applies: false + note: This vulnerability is not related to the use of native wrappers. + distrust_input: + applies: true + note: The vulnerability could potentially be exploited by providing malicious input to the system, which emphasizes the need to validate and sanitize all inputs. + security_by_obscurity: + applies: false + note: Security by obscurity is not relevant to this vulnerability; it is a matter of proper error handling and memory management. + serial_killer: + applies: false + note: This term typically refers to the serialization vulnerabilities, which is not the case here. + environment_variables: + applies: false + note: Environment variables are not directly related to this vulnerability. + secure_by_default: + applies: true + note: The vulnerability underscores the need for secure default configurations to prevent such memory management issues. + yagni: + applies: false + note: "You aren't gonna need it" (YAGNI) is a principle of extreme programming that emphasizes not adding functionality until it is necessary, which does not directly apply to this security issue. + complex_inputs: + applies: false + note: The vulnerability is not directly related to the complexity of inputs but to the handling of memory when an error occurs. mistakes: question: | From 2027e23c7332a8c8802f04755e993716bdfda225 Mon Sep 17 00:00:00 2001 From: karisanno11 Date: Tue, 14 Nov 2023 22:51:56 -0500 Subject: [PATCH 12/21] trying to fix yaml error --- cves/CVE-2019-19045.yml | 62 ++++++++++++++++++++--------------------- 1 file changed, 31 insertions(+), 31 deletions(-) diff --git a/cves/CVE-2019-19045.yml b/cves/CVE-2019-19045.yml index 36d04844a..e19a5e341 100644 --- a/cves/CVE-2019-19045.yml +++ b/cves/CVE-2019-19045.yml @@ -1,5 +1,5 @@ CVE: CVE-2019-19045 -yaml_instructions: | +yaml_instructions: ================= ===YAML Primer=== ================= @@ -11,7 +11,7 @@ yaml_instructions: | For readability, we hard-wrap multi-line strings at 80 characters. This is not required, but appreciated. -curated_instructions: | +curated_instructions: If you are manually editing this file, then you are "curating" it. Set the version number that you were given in your instructions. @@ -20,14 +20,14 @@ curated_instructions: | fill everything out properly. If you are a student, we cannot accept your work as finished unless curated is properly updated. curation_level: 2 -reported_instructions: | +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: '2019-11-17' -announced_instructions: | +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. @@ -35,11 +35,11 @@ announced_instructions: | Please enter your date in YYYY-MM-DD format. announced_date: '2019-11-18' -published_instructions: | +published_instructions: Is there a published fix or patch date for this vulnerability? Please enter your date in YYYY-MM-DD format. published_date: '2019-11-18' -description_instructions: | +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. @@ -56,7 +56,7 @@ description_instructions: | Your target audience is people just like you before you took any course in security -description: | +description: CVE-2019-19045 is a security flaw located in the Linux kernel's handling of network hardware, specifically within the mlx5_fpga_conn_create_cq() function used by certain Mellanox network drivers. This vulnerability @@ -71,7 +71,7 @@ description: | certain conditions, causing a persistent impact on the system's operation and requiring immediate attention to prevent potential service disruptions. -bounty_instructions: | +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 was wrong. Otherwise, leave it blank. @@ -81,7 +81,7 @@ bounty: url: reviews: [] -bugs_instructions: | +bugs_instructions: What bugs are involved in this vulnerability? Please list bug IDs to https://bugzilla.kernel.org/ @@ -93,7 +93,7 @@ bugs_instructions: | * Various other places bugs: [1774983] -fixes_instructions: | +fixes_instructions: Please put the commit hash in "commit" below. This must be a git commit hash from the systemd source repo, a 40-character @@ -106,11 +106,11 @@ fixes: - commit: note: - commit: c8c2a057fdc7de1cd16f4baa51425b932a42eb39 - note: | + 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: | +vcc_instructions: The vulnerability-contributing commits. These are found by our tools by traversing the Git Blame history, where we @@ -127,7 +127,7 @@ vccs: - commit: 537a50574175a2b68b0612ffb48cb044a394c7b4 note: Discovered automatically by archeogit. -upvotes_instructions: | +upvotes_instructions: For the first round, ignore this upvotes number. For the second round of reviewing, you will be giving a certain amount of @@ -137,7 +137,7 @@ upvotes_instructions: | upvotes: unit_tested: - question: | + question: Were automated unit tests involved in this vulnerability? Was the original code unit tested, or not unit tested? Did the fix involve improving the automated tests? @@ -156,7 +156,7 @@ unit_tested: fix_answer: The fix for the vulnerability involved improving the automated tests to ensure the issue does not recur. discovered: - question: | + question: How was this vulnerability discovered? Go to the bug report and read the conversation to find out how this was @@ -175,7 +175,7 @@ discovered: developer: false autodiscoverable: - instructions: | + instructions: Is it plausible that a fully automated tool could have discovered this? These are tools that require little knowledge of the domain, e.g. automatic static analysis, compiler warnings, fuzzers. @@ -194,7 +194,7 @@ autodiscoverable: answer: false specification: - instructions: | + instructions: Is there mention of a violation of a specification? For example, the POSIX spec, an RFC spec, a network protocol spec, or some other requirements specification. @@ -212,7 +212,7 @@ specification: answer: false subsystem: - question: | + question: What subsystems was the mistake in? These are WITHIN linux kernel Determining the subsystem is a subjective task. This is to help us group @@ -247,7 +247,7 @@ subsystem: name: ["net", "drivers/net/ethernet/mellanox"] note: The subsystem involved is the networking subsystem, specifically the drivers for Mellanox Ethernet hardware within the Linux kernel. interesting_commits: - question: | + question: Are there any interesting commits between your VCC(s) and fix(es)? Use this to specify any commits you think are notable in some way, and @@ -265,7 +265,7 @@ interesting_commits: - commit: note: i18n: - question: | + question: Was the feature impacted by this vulnerability about internationalization (i18n)? @@ -279,7 +279,7 @@ i18n: answer: false note: Internationalization features were not impacted by this vulnerability as it pertains to the kernel's networking stack and memory management. sandbox: - question: | + question: Did this vulnerability violate a sandboxing feature that the system provides? @@ -295,7 +295,7 @@ sandbox: note: This vulnerability does not involve bypassing any sandboxing features as it is related to memory management within the kernel's networking hardware interface. ipc: - question: | + question: Did the feature that this vulnerability affected use inter-process communication? IPC includes OS signals, pipes, stdin/stdout, message passing, and clipboard. Writing to files that another program in this @@ -307,7 +307,7 @@ ipc: answer: false note: The vulnerability does not involve inter-process communication mechanisms but rather the internal handling of network hardware resources. discussion: - question: | + question: Was there any discussion surrounding this? A discussion can include debates, disputes, or polite talk about how to @@ -335,7 +335,7 @@ discussion: any_discussion: true note: The security implications of the vulnerability were discussed as indicated by the reporting and fixing of the issue in security bulletins and commit messages. vouch: - question: | + question: Was there any part of the fix that involved one person vouching for another's work? @@ -349,7 +349,7 @@ vouch: answer: false note: There is no evidence of vouching for another's work in the commit messages or bug reports related to the fix. stacktrace: - question: | + question: Are there any stacktraces in the bug reports? Secondly, if there is a stacktrace, is the fix in the same file that the @@ -365,7 +365,7 @@ stacktrace: stacktrace_with_fix: false note: No stacktraces were provided in the bug report, and the fix does not reference a stacktrace. forgotten_check: - question: | + question: Does the fix for the vulnerability involve adding a forgotten check? A "forgotten check" can mean many things. It often manifests as the fix @@ -385,7 +385,7 @@ forgotten_check: answer: true note: The fix for the vulnerability involved adding checks to prevent memory leaks when errors occur in the mlx5_vector2eqn() function. order_of_operations: - question: | + question: Does the fix for the vulnerability involve correcting an order of operations? @@ -398,7 +398,7 @@ order_of_operations: answer: false note: The fix did not involve changing the order of operations but rather adding necessary checks to handle errors properly. lessons: - question: | + question: Are there any common lessons we have learned from class that apply to this vulnerability? In other words, could this vulnerability serve as an example of one of those lessons? @@ -447,7 +447,7 @@ lessons: note: The vulnerability is not directly related to the complexity of inputs but to the handling of memory when an error occurs. mistakes: - question: | + question: In your opinion, after all of this research, what mistakes were made that led to this vulnerability? Coding mistakes? Design mistakes? Maintainability? Requirements? Miscommunications? @@ -476,7 +476,7 @@ mistakes: Write a thoughtful entry here that people in the software engineering industry would find interesting. answer: The primary mistake leading to CVE-2019-19045 was a coding error in memory management within the network hardware interface code. This oversight allowed for a condition where system memory could be depleted, causing a denial of service. The design did not adequately anticipate error conditions in the mlx5_vector2eqn() function, leading to a memory leak when errors occurred. -CWE_instructions: | +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 https://cwe.mitre.org/data/definitions/699.html for the Software Development @@ -494,7 +494,7 @@ CWE_instructions: | CWE: - [401, 400] CWE_note: Manually confirmed -nickname_instructions: | +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. From 7ba66cfad4806bfad8ab8de03b2b4144e270b8de Mon Sep 17 00:00:00 2001 From: karisanno11 Date: Tue, 14 Nov 2023 23:03:00 -0500 Subject: [PATCH 13/21] deleted the duplicate file --- cves/CVE-2019-19045.yml | 503 --------------------------------- cves/CVE-2019-8956.yml | 495 -------------------------------- cves/kernel/CVE-2019-19045.yml | 62 ++-- cves/kernel/CVE-2019-8956.yml | 6 +- 4 files changed, 36 insertions(+), 1030 deletions(-) delete mode 100644 cves/CVE-2019-19045.yml delete mode 100644 cves/CVE-2019-8956.yml diff --git a/cves/CVE-2019-19045.yml b/cves/CVE-2019-19045.yml deleted file mode 100644 index e19a5e341..000000000 --- a/cves/CVE-2019-19045.yml +++ /dev/null @@ -1,503 +0,0 @@ -CVE: CVE-2019-19045 -yaml_instructions: - ================= - ===YAML Primer=== - ================= - This is a dictionary data structure, akin to JSON. - Everything before a colon is a key, and the values here are usually strings - For one-line strings, you can just use quotes after the colon - For multi-line strings, as we do for our instructions, you put a | and then - indent by two spaces - - For readability, we hard-wrap multi-line strings at 80 characters. This is - not required, but appreciated. -curated_instructions: - If you are manually editing this file, then you are "curating" it. - - Set the version number that you were given in your 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 -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: '2019-11-17' -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. - - 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: '2019-11-18' -published_instructions: - Is there a published fix or patch date for this vulnerability? - Please enter your date in YYYY-MM-DD format. -published_date: '2019-11-18' -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. - - Rewrite this description IN YOUR OWN WORDS. Make it interesting and easy to - read to anyone with some programming experience. We can always pull up the NVD - description later to get more technical. - - Try to still be specific in your description, but remove project-specific - stuff. Remove references to versions, specific filenames, and other jargon - that outsiders to this project would not understand. Technology like "regular - expressions" is fine, and security phrases like "invalid write" are fine to - keep too. - - Your target audience is people just like you before you took any course in - security - -description: - CVE-2019-19045 is a security flaw located in the Linux kernel's handling - of network hardware, specifically within the mlx5_fpga_conn_create_cq() - function used by certain Mellanox network drivers. This vulnerability - arises when the function improperly manages memory during the creation - of connection queues, which are structures used to organize data packets - for processing by network devices. If an error occurs in the mlx5_vector2eqn() - function, which is responsible for mapping interrupt vectors to event queues, - it can lead to a memory leak. This leak can be exploited by an attacker to - exhaust system memory, leading to a denial of service where the system - becomes unresponsive due to the depletion of available memory resources. - The issue is particularly problematic because it can be triggered under - certain conditions, causing a persistent impact on the system's operation - and requiring immediate attention to prevent potential service disruptions. - -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 - was wrong. Otherwise, leave it blank. -bounty: - amt: - announced: - url: -reviews: [] - -bugs_instructions: - What bugs are involved in this vulnerability? - - Please list bug IDs to https://bugzilla.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: [1774983] - -fixes_instructions: - Please put the commit hash in "commit" below. - - This must be a git commit hash from the systemd source repo, a 40-character - hexademical string/ - - Place any notes you would like to make in the notes field. -fixes: -- commit: - note: -- commit: - note: -- commit: c8c2a057fdc7de1cd16f4baa51425b932a42eb39 - 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. - - These are found by our tools by traversing the Git Blame history, where we - determine which commit(s) introduced the functionality. - - Look up these VCC commits and verify that they are not simple refactorings, - and that they are, in fact introducing the vulnerability into the system. - Often, introducing the file or function is where the VCC is, but VCCs can be - anything. - - Place any notes you would like to make in the notes field. - -vccs: -- commit: 537a50574175a2b68b0612ffb48cb044a394c7b4 - note: Discovered automatically by archeogit. - -upvotes_instructions: - For the first round, ignore this upvotes number. - - For the second round of reviewing, you will be giving a certain amount of - 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: - -unit_tested: - question: - Were automated unit tests involved in this vulnerability? - Was the original code unit tested, or not unit tested? Did the fix involve - improving the automated tests? - - For code: and fix: - your answer should be boolean. - - For the code_answer below, look not only at the fix but the surrounding - code near the fix in related directories and determine if and was there were - unit tests involved for this subsystem. - - 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: false - code_answer: The original code was not unit tested as there is no indication of unit tests being involved in the subsystem affected by the vulnerability. - fix: true - fix_answer: The fix for the vulnerability involved improving the automated tests to ensure the issue does not recur. - -discovered: - question: - How was this vulnerability discovered? - - Go to the bug report and read the conversation to find out how this was - originally found. Answer in longform below in "answer", fill in the date in - YYYY-MM-DD, and then determine if the vulnerability was found by a Google - employee (you can tell from their email address). If it's clear that the - vulenrability was discovered by a contest, fill in the name there. - - The automated, contest, and developer flags can be true, false, or nil. - - If there is no evidence as to how this vulnerability was found, then please - explain where you looked. - answer: The vulnerability was discovered by analyzing the error conditions and memory management issues in the mlx5_vector2eqn() function. The specific method of discovery is not mentioned, but it was reported on 2019-11-17, indicating it may have been found during a review or bug report analysis. - automated: false - contest: false - developer: false - -autodiscoverable: - instructions: - Is it plausible that a fully automated tool could have discovered - this? These are tools that require little knowledge of the domain, - e.g. automatic static analysis, compiler warnings, fuzzers. - - Examples for true answers: SQL injection, XSS, buffer overflow - - In systemd, the actually use OZZ Fuzz. If there's a link to it, add it here. - - Examples for false: RFC violations, permissions issues, anything - that requires the tool to be "aware" of the project's - domain-specific requirements. - - The answer field should be boolean. In answer_note, please explain - why you come to that conclusion. - note: Given the complexity of the vulnerability related to specific hardware interaction and memory management, it is unlikely that a fully automated tool without domain knowledge could have discovered this. - answer: false - -specification: - instructions: - Is there mention of a violation of a specification? For example, the POSIX - spec, an RFC spec, a network protocol spec, or some other requirements - specification. - - Be sure to check the following artifacts for this: - * bug reports - * security advisories - * commit message - * mailing lists - * anything else - - The answer field should be boolean. In answer_note, please explain - why you come to that conclusion. - note: There is no mention of a specification violation in the available documentation for this vulnerability. - answer: false - -subsystem: - question: - What subsystems was the mistake in? These are WITHIN linux kernel - - Determining the subsystem is a subjective task. This is to help us group - similar vulnerabilities, so choose a subsystem that other vulnerabilities would be in. Y - - Some areas to look for pertinent information: - - Bug labels - - Directory names - - How developers refer to an area of the system in comments, - commit messages, etc. - - Look at the path of the source code files code that were fixed to get - directory names. Look at comments in the code. Look at the bug reports how - the bug report was tagged. - - Example linux kernel subsystems are: - * drivers - * crypto - * fs - * net - * lib - - Name should be: - * all lowercase English letters - * NOT a specific file - * can have digits, and _-@/ - - Can be multiple subsystems involved, in which case you can make it an array - e.g. - name: ["subsystemA", "subsystemB"] # ok - name: subsystemA # also ok - name: ["net", "drivers/net/ethernet/mellanox"] - note: The subsystem involved is the networking subsystem, specifically the drivers for Mellanox Ethernet hardware within the Linux kernel. -interesting_commits: - question: - Are there any interesting commits between your VCC(s) and fix(es)? - - Use this to specify any commits you think are notable in some way, and - explain why in the note. - - Example interesting commits: - * Mentioned as a problematic commit in the past - e.g. "This fixes regression in commit xys" - * A significant rewrite in the git history - * Other commits that fixed a similar issue as this vulnerability - * Anything else you find interesting. - commits: - - commit: - note: - - commit: - note: -i18n: - question: - Was the feature impacted by this vulnerability about internationalization - (i18n)? - - An internationalization feature is one that enables people from all - over the world to use the system. This includes translations, locales, - typography, unicode, or various other features. - - 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: false - note: Internationalization features were not impacted by this vulnerability as it pertains to the kernel's networking stack and memory management. -sandbox: - question: - Did this vulnerability violate a sandboxing feature that the system - provides? - - A sandboxing feature is one that allows files, users, or other features - limited access. Vulnerabilities that violate sandboxes are usually based on - access control, checking privileges incorrectly, path traversal, and the - like. - - 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: false - note: This vulnerability does not involve bypassing any sandboxing features as it is related to memory management within the kernel's networking hardware interface. - -ipc: - question: - Did the feature that this vulnerability affected use inter-process - communication? IPC includes OS signals, pipes, stdin/stdout, message - passing, and clipboard. Writing to files that another program in this - software system reads is another form of 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: false - note: The vulnerability does not involve inter-process communication mechanisms but rather the internal handling of network hardware resources. -discussion: - question: - Was there any discussion surrounding this? - - A discussion can include debates, disputes, or polite talk about how to - resolve uncertainty. - - Example include: - * Is this out of our scope? - * Is this a security? - * How should we fix this? - - Just because you see multiple comments doesn't mean it's a discussion. - For example: - * "Fix line 10". "Ok" is not what we call a discussion - * "Ping" (reminding people) - - Check the bugs reports, pull requests, and mailing lists archives. - - These answers should be boolean. - discussed_as_security: true or false - any_discussion: true or false - - Put any links to disagreements you found in the notes section, or any other - comment you want to make. - discussed_as_security: true - any_discussion: true - note: The security implications of the vulnerability were discussed as indicated by the reporting and fixing of the issue in security bulletins and commit messages. -vouch: - question: - Was there any part of the fix that involved one person vouching for - another's work? - - This can include: - * signing off on a commit message - * mentioning a discussion with a colleague checking the work - * upvoting a solution on a pull request - - 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: false - note: There is no evidence of vouching for another's work in the commit messages or bug reports related to the fix. -stacktrace: - question: - Are there any stacktraces in the bug reports? - - Secondly, if there is a stacktrace, is the fix in the same file that the - stacktrace points to? - - If there are no stacktraces, then both of these are false - but be sure to - mention where you checked in the note. - - 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: false - stacktrace_with_fix: false - note: No stacktraces were provided in the bug report, and the fix does not reference a stacktrace. -forgotten_check: - question: - Does the fix for the vulnerability involve adding a forgotten check? - - A "forgotten check" can mean many things. It often manifests as the fix - inserting an entire if-statement or a conditional to an existing - if-statement. Or a call to a method that checks something. - - Example of checks can include: - * null pointer checks - * check the current role, e.g. root - * boundary checks for a number - * consult file permissions - * check a return value - - 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: true - note: The fix for the vulnerability involved adding checks to prevent memory leaks when errors occur in the mlx5_vector2eqn() function. -order_of_operations: - question: - Does the fix for the vulnerability involve correcting an order of - operations? - - This means the fix involves moving code around or changing the order of - how things are done. - - 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: false - note: The fix did not involve changing the order of operations but rather adding necessary checks to handle errors properly. -lessons: - question: - Are there any common lessons we have learned from class that apply to this - vulnerability? In other words, could this vulnerability serve as an example - of one of those lessons? - - Leave "applies" blank or put false if you did not see that lesson (you do - not need to put a reason). Put "true" if you feel the lesson applies and put - a quick explanation of how it applies. - - Don't feel the need to claim that ALL of these apply, but it's pretty likely - that one or two of them apply. - - If you think of another lesson we covered in class that applies here, feel - free to give it a small name and add one in the same format as these. - defense_in_depth: - applies: true - note: This vulnerability shows the importance of having multiple layers of security. Even if one function fails, others should be in place to prevent exploitation. - least_privilege: - applies: false - note: The vulnerability does not appear to be related to the principle of least privilege but rather to improper memory handling. - frameworks_are_optional: - applies: false - note: This lesson does not apply as the vulnerability is within the kernel's code, not a framework over it. - native_wrappers: - applies: false - note: This vulnerability is not related to the use of native wrappers. - distrust_input: - applies: true - note: The vulnerability could potentially be exploited by providing malicious input to the system, which emphasizes the need to validate and sanitize all inputs. - security_by_obscurity: - applies: false - note: Security by obscurity is not relevant to this vulnerability; it is a matter of proper error handling and memory management. - serial_killer: - applies: false - note: This term typically refers to the serialization vulnerabilities, which is not the case here. - environment_variables: - applies: false - note: Environment variables are not directly related to this vulnerability. - secure_by_default: - applies: true - note: The vulnerability underscores the need for secure default configurations to prevent such memory management issues. - yagni: - applies: false - note: "You aren't gonna need it" (YAGNI) is a principle of extreme programming that emphasizes not adding functionality until it is necessary, which does not directly apply to this security issue. - complex_inputs: - applies: false - note: The vulnerability is not directly related to the complexity of inputs but to the handling of memory when an error occurs. - -mistakes: - question: - In your opinion, after all of this research, what mistakes were made that - led to this vulnerability? Coding mistakes? Design mistakes? - Maintainability? Requirements? Miscommunications? - - There can, and usually are, many mistakes behind a vulnerability. - - Remember that mistakes can come in many forms: - * slip: failing to complete a properly planned step due to inattention - e.g. wrong key in the ignition - e.g. using < instead of <= - * lapse: failing to complete a properly planned step due to memory failure - e.g. forgetting to put car in reverse before backing up - e.g. forgetting to check null - * planning error: error that occurs when the plan is inadequate - e.g. getting stuck in traffic because you didn't consider the - impact of the bridge closing - e.g. calling the wrong method - e.g. using a poor design - - These are grey areas, of course. But do your best to analyze the mistakes - according to this framework. - - Look at the CWE entry for this vulnerability and examine the mitigations - they have written there. Are they doing those? Does the fix look proper? - - Write a thoughtful entry here that people in the software engineering - industry would find interesting. - answer: The primary mistake leading to CVE-2019-19045 was a coding error in memory management within the network hardware interface code. This oversight allowed for a condition where system memory could be depleted, causing a denial of service. The design did not adequately anticipate error conditions in the mlx5_vector2eqn() function, leading to a memory leak when errors occurred. -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 - https://cwe.mitre.org/data/definitions/699.html for the Software Development - view of the vulnerabilities. We also recommend the tool - http://www.cwevis.org/viz to help see how the classifications work. - - If you have anything to note about why you classified it this way, write - something in CWE_note. This field is optional. - - Just the number here is fine. No need for name or CWE prefix. If more than one - apply here, then place them in an array like this - CWE: ["123", "456"] # this is ok - CWE: [123, 456] # also ok - CWE: 123 # also ok -CWE: -- [401, 400] -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: {} - -CVSS: CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H diff --git a/cves/CVE-2019-8956.yml b/cves/CVE-2019-8956.yml deleted file mode 100644 index 567d80665..000000000 --- a/cves/CVE-2019-8956.yml +++ /dev/null @@ -1,495 +0,0 @@ -CVE: CVE-2019-8956 -yaml_instructions: | - ================= - ===YAML Primer=== - ================= - This is a dictionary data structure, akin to JSON. - Everything before a colon is a key, and the values here are usually strings - For one-line strings, you can just use quotes after the colon - For multi-line strings, as we do for our instructions, you put a | and then - indent by two spaces - - For readability, we hard-wrap multi-line strings at 80 characters. This is - not required, but appreciated. -curated_instructions: | - If you are manually editing this file, then you are "curating" it. - - Set the version number that you were given in your 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 -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: '2019-02-20' -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. - - 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: '2019-04-01' -published_instructions: | - Is there a published fix or patch date for this vulnerability? - Please enter your date in YYYY-MM-DD format. -published_date: '2019-04-01' -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. - - Rewrite this description IN YOUR OWN WORDS. Make it interesting and easy to - read to anyone with some programming experience. We can always pull up the NVD - description later to get more technical. - - Try to still be specific in your description, but remove project-specific - stuff. Remove references to versions, specific filenames, and other jargon - that outsiders to this project would not understand. Technology like "regular - expressions" is fine, and security phrases like "invalid write" are fine to - keep too. - - Your target audience is people just like you before you took any course in - security - -description: | - CVE-2019-8956 is a security vulnerability that affects the "sctp_sendmsg()" - function in Linux, which is designed for broadcasting data across many - network parts at once. This flaw grants users with specific permissions the - ability to write data to unauthorized areas of the system's memory. Such - unauthorized access can result in severe consequences, including system - crashes and the potential for hackers to execute arbitrary code. This type - of vulnerability is critical because it can compromise the integrity and - availability of affected systems, making it a significant risk that needs - to be addressed promptly. - -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 - was wrong. Otherwise, leave it blank. -bounty: - amt: - announced: - url: -reviews: [] - -bugs_instructions: | - What bugs are involved in this vulnerability? - - Please list bug IDs to https://bugzilla.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: [1679889] - -fixes_instructions: | - Please put the commit hash in "commit" below. - - This must be a git commit hash from the systemd source repo, a 40-character - hexademical string/ - - Place any notes you would like to make in the notes field. -fixes: -- commit: - note: -- commit: - note: -- commit: ba59fb0273076637f0add4311faa990a5eec27c0 - 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. - - These are found by our tools by traversing the Git Blame history, where we - determine which commit(s) introduced the functionality. - - Look up these VCC commits and verify that they are not simple refactorings, - and that they are, in fact introducing the vulnerability into the system. - Often, introducing the file or function is where the VCC is, but VCCs can be - anything. - - Place any notes you would like to make in the notes field. - -vccs: -- commit: 007b7e18be74a49b61f89664966ac1477e1c9608 - note: Discovered automatically by archeogit. -- commit: 4910280503f3af2857d5aa77e35b22d93a8960a8 - note: Discovered automatically by archeogit. - -upvotes_instructions: | - For the first round, ignore this upvotes number. - - For the second round of reviewing, you will be giving a certain amount of - 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: - -unit_tested: - question: | - Were automated unit tests involved in this vulnerability? - Was the original code unit tested, or not unit tested? Did the fix involve - improving the automated tests? - - For code: and fix: - your answer should be boolean. - - For the code_answer below, look not only at the fix but the surrounding - code near the fix in related directories and determine if and was there were - unit tests involved for this subsystem. - - 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: false - code_answer: The original code was not unit tested. - fix: true - fix_answer: The fix involved adding or improving unit tests to prevent future occurrences. - -discovered: - question: | - How was this vulnerability discovered? - - Go to the bug report and read the conversation to find out how this was - originally found. Answer in longform below in "answer", fill in the date in - YYYY-MM-DD, and then determine if the vulnerability was found by a Google - employee (you can tell from their email address). If it's clear that the - vulenrability was discovered by a contest, fill in the name there. - - The automated, contest, and developer flags can be true, false, or nil. - - If there is no evidence as to how this vulnerability was found, then please - explain where you looked. - answer: The vulnerability was discovered through a bug report by a user who noticed unexpected behavior when using the "sctp_sendmsg()" function. The exact method of discovery is not detailed in the bug report. - automated: false - contest: false - developer: false - -autodiscoverable: - instructions: | - Is it plausible that a fully automated tool could have discovered - this? These are tools that require little knowledge of the domain, - e.g. automatic static analysis, compiler warnings, fuzzers. - - Examples for true answers: SQL injection, XSS, buffer overflow - - In systemd, the actually use OZZ Fuzz. If there's a link to it, add it here. - - Examples for false: RFC violations, permissions issues, anything - that requires the tool to be "aware" of the project's - domain-specific requirements. - - The answer field should be boolean. In answer_note, please explain - why you come to that conclusion. - note: This type of vulnerability requires domain-specific knowledge to discover and is unlikely to be found by automated tools without specific targeting. - answer: false - -specification: - instructions: | - Is there mention of a violation of a specification? For example, the POSIX - spec, an RFC spec, a network protocol spec, or some other requirements - specification. - - Be sure to check the following artifacts for this: - * bug reports - * security advisories - * commit message - * mailing lists - * anything else - - The answer field should be boolean. In answer_note, please explain - why you come to that conclusion. - note: There is no mention of a specification violation in the available documentation. - answer: false - -subsystem: - question: | - What subsystems was the mistake in? These are WITHIN linux kernel - - Determining the subsystem is a subjective task. This is to help us group - similar vulnerabilities, so choose a subsystem that other vulnerabilities would be in. Y - - Some areas to look for pertinent information: - - Bug labels - - Directory names - - How developers refer to an area of the system in comments, - commit messages, etc. - - Look at the path of the source code files code that were fixed to get - directory names. Look at comments in the code. Look at the bug reports how - the bug report was tagged. - - Example linux kernel subsystems are: - * drivers - * crypto - * fs - * net - * lib - - Name should be: - * all lowercase English letters - * NOT a specific file - * can have digits, and _-@/ - - Can be multiple subsystems involved, in which case you can make it an array - e.g. - name: ["subsystemA", "subsystemB"] # ok - name: subsystemA # also ok - name: net - note: The vulnerability is in the networking subsystem, specifically related to the SCTP protocol handling within the Linux kernel. -interesting_commits: - question: | - Are there any interesting commits between your VCC(s) and fix(es)? - - Use this to specify any commits you think are notable in some way, and - explain why in the note. - - Example interesting commits: - * Mentioned as a problematic commit in the past - e.g. "This fixes regression in commit xys" - * A significant rewrite in the git history - * Other commits that fixed a similar issue as this vulnerability - * Anything else you find interesting. - commits: - - commit: - note: - - commit: - note: -i18n: - question: | - Was the feature impacted by this vulnerability about internationalization - (i18n)? - - An internationalization feature is one that enables people from all - over the world to use the system. This includes translations, locales, - typography, unicode, or various other features. - - 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: false - note: The vulnerability is not related to internationalization features. -sandbox: - question: | - Did this vulnerability violate a sandboxing feature that the system - provides? - - A sandboxing feature is one that allows files, users, or other features - limited access. Vulnerabilities that violate sandboxes are usually based on - access control, checking privileges incorrectly, path traversal, and the - like. - - 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: false - note: This vulnerability does not involve a sandboxing feature. - -ipc: - question: | - Did the feature that this vulnerability affected use inter-process - communication? IPC includes OS signals, pipes, stdin/stdout, message - passing, and clipboard. Writing to files that another program in this - software system reads is another form of 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: true - note: The "sctp_sendmsg()" function is used for inter-process communication over the network. -discussion: - question: | - Was there any discussion surrounding this? - - A discussion can include debates, disputes, or polite talk about how to - resolve uncertainty. - - Example include: - * Is this out of our scope? - * Is this a security? - * How should we fix this? - - Just because you see multiple comments doesn't mean it's a discussion. - For example: - * "Fix line 10". "Ok" is not what we call a discussion - * "Ping" (reminding people) - - Check the bugs reports, pull requests, and mailing lists archives. - - These answers should be boolean. - discussed_as_security: true or false - any_discussion: true or false - - Put any links to disagreements you found in the notes section, or any other - comment you want to make. - discussed_as_security: true - any_discussion: true - note: The security implications of the bug were discussed in the bug report and during the fix proposal. -vouch: - question: | - Was there any part of the fix that involved one person vouching for - another's work? - - This can include: - * signing off on a commit message - * mentioning a discussion with a colleague checking the work - * upvoting a solution on a pull request - - 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: false - note: There is no evidence of vouching in the commit messages or bug report discussions. -stacktrace: - question: | - Are there any stacktraces in the bug reports? - - Secondly, if there is a stacktrace, is the fix in the same file that the - stacktrace points to? - - If there are no stacktraces, then both of these are false - but be sure to - mention where you checked in the note. - - 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: false - stacktrace_with_fix: false - note: No stacktraces were provided in the bug report. -forgotten_check: - question: | - Does the fix for the vulnerability involve adding a forgotten check? - - A "forgotten check" can mean many things. It often manifests as the fix - inserting an entire if-statement or a conditional to an existing - if-statement. Or a call to a method that checks something. - - Example of checks can include: - * null pointer checks - * check the current role, e.g. root - * boundary checks for a number - * consult file permissions - * check a return value - - 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: true - note: The fix for the vulnerability involved adding checks to prevent invalid memory writes. -order_of_operations: - question: | - Does the fix for the vulnerability involve correcting an order of - operations? - - This means the fix involves moving code around or changing the order of - how things are done. - - 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: false - note: The fix did not involve changing the order of operations. -lessons: - question: | - Are there any common lessons we have learned from class that apply to this - vulnerability? In other words, could this vulnerability serve as an example - of one of those lessons? - - Leave "applies" blank or put false if you did not see that lesson (you do - not need to put a reason). Put "true" if you feel the lesson applies and put - a quick explanation of how it applies. - - Don't feel the need to claim that ALL of these apply, but it's pretty likely - that one or two of them apply. - - If you think of another lesson we covered in class that applies here, feel - free to give it a small name and add one in the same format as these. - defense_in_depth: - applies: true - note: This vulnerability shows the importance of having multiple security layers, as a single failure allowed a critical flaw. - least_privilege: - applies: true - note: The vulnerability exploited more privileges than necessary for a regular user's operation, indicating a violation of the least privilege principle. - frameworks_are_optional: - applies: false - native_wrappers: - applies: false - distrust_input: - applies: true - note: Inputs to the "sctp_sendmsg()" function were not properly validated, leading to the vulnerability. - security_by_obscurity: - applies: false - serial_killer: - applies: false - environment_variables: - applies: false - secure_by_default: - applies: true - note: The system was not secure by default, as it allowed for an invalid memory write without proper checks. - yagni: - applies: false - complex_inputs: - applies: true - note: The vulnerability involved complex input handling, which was not adequately checked for security issues. - -mistakes: - question: | - In your opinion, after all of this research, what mistakes were made that - led to this vulnerability? Coding mistakes? Design mistakes? - Maintainability? Requirements? Miscommunications? - - There can, and usually are, many mistakes behind a vulnerability. - - Remember that mistakes can come in many forms: - * slip: failing to complete a properly planned step due to inattention - e.g. wrong key in the ignition - e.g. using < instead of <= - * lapse: failing to complete a properly planned step due to memory failure - e.g. forgetting to put car in reverse before backing up - e.g. forgetting to check null - * planning error: error that occurs when the plan is inadequate - e.g. getting stuck in traffic because you didn't consider the - impact of the bridge closing - e.g. calling the wrong method - e.g. using a poor design - - These are grey areas, of course. But do your best to analyze the mistakes - according to this framework. - - Look at the CWE entry for this vulnerability and examine the mitigations - they have written there. Are they doing those? Does the fix look proper? - - Write a thoughtful entry here that people in the software engineering - industry would find interesting. - answer: The main mistake was a lack of proper input validation and boundary checking within the "sctp_sendmsg()" function, which is a common oversight in security-critical code. Additionally, the absence of unit tests for this function allowed the vulnerability to go unnoticed until reported by a user. -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 - https://cwe.mitre.org/data/definitions/699.html for the Software Development - view of the vulnerabilities. We also recommend the tool - http://www.cwevis.org/viz to help see how the classifications work. - - If you have anything to note about why you classified it this way, write - something in CWE_note. This field is optional. - - Just the number here is fine. No need for name or CWE prefix. If more than one - apply here, then place them in an array like this - CWE: ["123", "456"] # this is ok - CWE: [123, 456] # also ok - CWE: 123 # also ok -CWE: -- [416, 787] -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: {} - -CVSS: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H diff --git a/cves/kernel/CVE-2019-19045.yml b/cves/kernel/CVE-2019-19045.yml index 36d04844a..e19a5e341 100644 --- a/cves/kernel/CVE-2019-19045.yml +++ b/cves/kernel/CVE-2019-19045.yml @@ -1,5 +1,5 @@ CVE: CVE-2019-19045 -yaml_instructions: | +yaml_instructions: ================= ===YAML Primer=== ================= @@ -11,7 +11,7 @@ yaml_instructions: | For readability, we hard-wrap multi-line strings at 80 characters. This is not required, but appreciated. -curated_instructions: | +curated_instructions: If you are manually editing this file, then you are "curating" it. Set the version number that you were given in your instructions. @@ -20,14 +20,14 @@ curated_instructions: | fill everything out properly. If you are a student, we cannot accept your work as finished unless curated is properly updated. curation_level: 2 -reported_instructions: | +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: '2019-11-17' -announced_instructions: | +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. @@ -35,11 +35,11 @@ announced_instructions: | Please enter your date in YYYY-MM-DD format. announced_date: '2019-11-18' -published_instructions: | +published_instructions: Is there a published fix or patch date for this vulnerability? Please enter your date in YYYY-MM-DD format. published_date: '2019-11-18' -description_instructions: | +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. @@ -56,7 +56,7 @@ description_instructions: | Your target audience is people just like you before you took any course in security -description: | +description: CVE-2019-19045 is a security flaw located in the Linux kernel's handling of network hardware, specifically within the mlx5_fpga_conn_create_cq() function used by certain Mellanox network drivers. This vulnerability @@ -71,7 +71,7 @@ description: | certain conditions, causing a persistent impact on the system's operation and requiring immediate attention to prevent potential service disruptions. -bounty_instructions: | +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 was wrong. Otherwise, leave it blank. @@ -81,7 +81,7 @@ bounty: url: reviews: [] -bugs_instructions: | +bugs_instructions: What bugs are involved in this vulnerability? Please list bug IDs to https://bugzilla.kernel.org/ @@ -93,7 +93,7 @@ bugs_instructions: | * Various other places bugs: [1774983] -fixes_instructions: | +fixes_instructions: Please put the commit hash in "commit" below. This must be a git commit hash from the systemd source repo, a 40-character @@ -106,11 +106,11 @@ fixes: - commit: note: - commit: c8c2a057fdc7de1cd16f4baa51425b932a42eb39 - note: | + 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: | +vcc_instructions: The vulnerability-contributing commits. These are found by our tools by traversing the Git Blame history, where we @@ -127,7 +127,7 @@ vccs: - commit: 537a50574175a2b68b0612ffb48cb044a394c7b4 note: Discovered automatically by archeogit. -upvotes_instructions: | +upvotes_instructions: For the first round, ignore this upvotes number. For the second round of reviewing, you will be giving a certain amount of @@ -137,7 +137,7 @@ upvotes_instructions: | upvotes: unit_tested: - question: | + question: Were automated unit tests involved in this vulnerability? Was the original code unit tested, or not unit tested? Did the fix involve improving the automated tests? @@ -156,7 +156,7 @@ unit_tested: fix_answer: The fix for the vulnerability involved improving the automated tests to ensure the issue does not recur. discovered: - question: | + question: How was this vulnerability discovered? Go to the bug report and read the conversation to find out how this was @@ -175,7 +175,7 @@ discovered: developer: false autodiscoverable: - instructions: | + instructions: Is it plausible that a fully automated tool could have discovered this? These are tools that require little knowledge of the domain, e.g. automatic static analysis, compiler warnings, fuzzers. @@ -194,7 +194,7 @@ autodiscoverable: answer: false specification: - instructions: | + instructions: Is there mention of a violation of a specification? For example, the POSIX spec, an RFC spec, a network protocol spec, or some other requirements specification. @@ -212,7 +212,7 @@ specification: answer: false subsystem: - question: | + question: What subsystems was the mistake in? These are WITHIN linux kernel Determining the subsystem is a subjective task. This is to help us group @@ -247,7 +247,7 @@ subsystem: name: ["net", "drivers/net/ethernet/mellanox"] note: The subsystem involved is the networking subsystem, specifically the drivers for Mellanox Ethernet hardware within the Linux kernel. interesting_commits: - question: | + question: Are there any interesting commits between your VCC(s) and fix(es)? Use this to specify any commits you think are notable in some way, and @@ -265,7 +265,7 @@ interesting_commits: - commit: note: i18n: - question: | + question: Was the feature impacted by this vulnerability about internationalization (i18n)? @@ -279,7 +279,7 @@ i18n: answer: false note: Internationalization features were not impacted by this vulnerability as it pertains to the kernel's networking stack and memory management. sandbox: - question: | + question: Did this vulnerability violate a sandboxing feature that the system provides? @@ -295,7 +295,7 @@ sandbox: note: This vulnerability does not involve bypassing any sandboxing features as it is related to memory management within the kernel's networking hardware interface. ipc: - question: | + question: Did the feature that this vulnerability affected use inter-process communication? IPC includes OS signals, pipes, stdin/stdout, message passing, and clipboard. Writing to files that another program in this @@ -307,7 +307,7 @@ ipc: answer: false note: The vulnerability does not involve inter-process communication mechanisms but rather the internal handling of network hardware resources. discussion: - question: | + question: Was there any discussion surrounding this? A discussion can include debates, disputes, or polite talk about how to @@ -335,7 +335,7 @@ discussion: any_discussion: true note: The security implications of the vulnerability were discussed as indicated by the reporting and fixing of the issue in security bulletins and commit messages. vouch: - question: | + question: Was there any part of the fix that involved one person vouching for another's work? @@ -349,7 +349,7 @@ vouch: answer: false note: There is no evidence of vouching for another's work in the commit messages or bug reports related to the fix. stacktrace: - question: | + question: Are there any stacktraces in the bug reports? Secondly, if there is a stacktrace, is the fix in the same file that the @@ -365,7 +365,7 @@ stacktrace: stacktrace_with_fix: false note: No stacktraces were provided in the bug report, and the fix does not reference a stacktrace. forgotten_check: - question: | + question: Does the fix for the vulnerability involve adding a forgotten check? A "forgotten check" can mean many things. It often manifests as the fix @@ -385,7 +385,7 @@ forgotten_check: answer: true note: The fix for the vulnerability involved adding checks to prevent memory leaks when errors occur in the mlx5_vector2eqn() function. order_of_operations: - question: | + question: Does the fix for the vulnerability involve correcting an order of operations? @@ -398,7 +398,7 @@ order_of_operations: answer: false note: The fix did not involve changing the order of operations but rather adding necessary checks to handle errors properly. lessons: - question: | + question: Are there any common lessons we have learned from class that apply to this vulnerability? In other words, could this vulnerability serve as an example of one of those lessons? @@ -447,7 +447,7 @@ lessons: note: The vulnerability is not directly related to the complexity of inputs but to the handling of memory when an error occurs. mistakes: - question: | + question: In your opinion, after all of this research, what mistakes were made that led to this vulnerability? Coding mistakes? Design mistakes? Maintainability? Requirements? Miscommunications? @@ -476,7 +476,7 @@ mistakes: Write a thoughtful entry here that people in the software engineering industry would find interesting. answer: The primary mistake leading to CVE-2019-19045 was a coding error in memory management within the network hardware interface code. This oversight allowed for a condition where system memory could be depleted, causing a denial of service. The design did not adequately anticipate error conditions in the mlx5_vector2eqn() function, leading to a memory leak when errors occurred. -CWE_instructions: | +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 https://cwe.mitre.org/data/definitions/699.html for the Software Development @@ -494,7 +494,7 @@ CWE_instructions: | CWE: - [401, 400] CWE_note: Manually confirmed -nickname_instructions: | +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. diff --git a/cves/kernel/CVE-2019-8956.yml b/cves/kernel/CVE-2019-8956.yml index e4287424a..567d80665 100644 --- a/cves/kernel/CVE-2019-8956.yml +++ b/cves/kernel/CVE-2019-8956.yml @@ -118,6 +118,7 @@ vcc_instructions: | anything. Place any notes you would like to make in the notes field. + vccs: - commit: 007b7e18be74a49b61f89664966ac1477e1c9608 note: Discovered automatically by archeogit. @@ -151,6 +152,7 @@ unit_tested: code_answer: The original code was not unit tested. fix: true fix_answer: The fix involved adding or improving unit tests to prevent future occurrences. + discovered: question: | How was this vulnerability discovered? @@ -169,6 +171,7 @@ discovered: automated: false contest: false developer: false + autodiscoverable: instructions: | Is it plausible that a fully automated tool could have discovered @@ -288,7 +291,7 @@ sandbox: what your answer was. answer: false note: This vulnerability does not involve a sandboxing feature. - + ipc: question: | Did the feature that this vulnerability affected use inter-process @@ -434,6 +437,7 @@ lessons: complex_inputs: applies: true note: The vulnerability involved complex input handling, which was not adequately checked for security issues. + mistakes: question: | In your opinion, after all of this research, what mistakes were made that From 349d1fbccbe6ab01c0b9b5bc6f23b761f3d05756 Mon Sep 17 00:00:00 2001 From: karisanno11 Date: Wed, 15 Nov 2023 01:36:07 -0500 Subject: [PATCH 14/21] trying to fix error --- cves/kernel/CVE-2019-19045.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cves/kernel/CVE-2019-19045.yml b/cves/kernel/CVE-2019-19045.yml index e19a5e341..815e263a2 100644 --- a/cves/kernel/CVE-2019-19045.yml +++ b/cves/kernel/CVE-2019-19045.yml @@ -6,7 +6,7 @@ yaml_instructions: This is a dictionary data structure, akin to JSON. Everything before a colon is a key, and the values here are usually strings For one-line strings, you can just use quotes after the colon - For multi-line strings, as we do for our instructions, you put a | and then + For multi-line strings, as we do for our instructions, you put a and then indent by two spaces For readability, we hard-wrap multi-line strings at 80 characters. This is From 9937539e692c914af024a4a6cb38e5c1d496f18e Mon Sep 17 00:00:00 2001 From: karisanno11 Date: Wed, 15 Nov 2023 01:44:41 -0500 Subject: [PATCH 15/21] trying to fix error --- cves/kernel/CVE-2019-19045.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cves/kernel/CVE-2019-19045.yml b/cves/kernel/CVE-2019-19045.yml index 815e263a2..802e61ce9 100644 --- a/cves/kernel/CVE-2019-19045.yml +++ b/cves/kernel/CVE-2019-19045.yml @@ -498,6 +498,6 @@ 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: CVSS: CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H From c3bc24409c6fa603a1e102d90d0b078b7fc70e77 Mon Sep 17 00:00:00 2001 From: karisanno11 Date: Wed, 15 Nov 2023 01:48:15 -0500 Subject: [PATCH 16/21] trying to fix error --- cves/kernel/CVE-2019-19045.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cves/kernel/CVE-2019-19045.yml b/cves/kernel/CVE-2019-19045.yml index 802e61ce9..a01caa37e 100644 --- a/cves/kernel/CVE-2019-19045.yml +++ b/cves/kernel/CVE-2019-19045.yml @@ -441,7 +441,7 @@ lessons: note: The vulnerability underscores the need for secure default configurations to prevent such memory management issues. yagni: applies: false - note: "You aren't gonna need it" (YAGNI) is a principle of extreme programming that emphasizes not adding functionality until it is necessary, which does not directly apply to this security issue. + note: You aren't gonna need it (YAGNI) is a principle of extreme programming that emphasizes not adding functionality until it is necessary, which does not directly apply to this security issue. complex_inputs: applies: false note: The vulnerability is not directly related to the complexity of inputs but to the handling of memory when an error occurs. From c4365625d964817849a0b59da8874c784e47e4bf Mon Sep 17 00:00:00 2001 From: karisanno11 Date: Wed, 15 Nov 2023 01:52:37 -0500 Subject: [PATCH 17/21] trying to fix error --- cves/kernel/CVE-2019-19045.yml | 58 +++++++++++++++++----------------- 1 file changed, 29 insertions(+), 29 deletions(-) diff --git a/cves/kernel/CVE-2019-19045.yml b/cves/kernel/CVE-2019-19045.yml index a01caa37e..516767eb7 100644 --- a/cves/kernel/CVE-2019-19045.yml +++ b/cves/kernel/CVE-2019-19045.yml @@ -1,5 +1,5 @@ CVE: CVE-2019-19045 -yaml_instructions: +yaml_instructions: | ================= ===YAML Primer=== ================= @@ -11,7 +11,7 @@ yaml_instructions: For readability, we hard-wrap multi-line strings at 80 characters. This is not required, but appreciated. -curated_instructions: +curated_instructions: | If you are manually editing this file, then you are "curating" it. Set the version number that you were given in your instructions. @@ -20,14 +20,14 @@ curated_instructions: fill everything out properly. If you are a student, we cannot accept your work as finished unless curated is properly updated. curation_level: 2 -reported_instructions: +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: '2019-11-17' -announced_instructions: +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. @@ -35,11 +35,11 @@ announced_instructions: Please enter your date in YYYY-MM-DD format. announced_date: '2019-11-18' -published_instructions: +published_instructions: | Is there a published fix or patch date for this vulnerability? Please enter your date in YYYY-MM-DD format. published_date: '2019-11-18' -description_instructions: +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. @@ -56,7 +56,7 @@ description_instructions: Your target audience is people just like you before you took any course in security -description: +description: | CVE-2019-19045 is a security flaw located in the Linux kernel's handling of network hardware, specifically within the mlx5_fpga_conn_create_cq() function used by certain Mellanox network drivers. This vulnerability @@ -71,7 +71,7 @@ description: certain conditions, causing a persistent impact on the system's operation and requiring immediate attention to prevent potential service disruptions. -bounty_instructions: +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 was wrong. Otherwise, leave it blank. @@ -81,7 +81,7 @@ bounty: url: reviews: [] -bugs_instructions: +bugs_instructions: | What bugs are involved in this vulnerability? Please list bug IDs to https://bugzilla.kernel.org/ @@ -93,7 +93,7 @@ bugs_instructions: * Various other places bugs: [1774983] -fixes_instructions: +fixes_instructions: | Please put the commit hash in "commit" below. This must be a git commit hash from the systemd source repo, a 40-character @@ -110,7 +110,7 @@ fixes: 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: +vcc_instructions: | The vulnerability-contributing commits. These are found by our tools by traversing the Git Blame history, where we @@ -127,7 +127,7 @@ vccs: - commit: 537a50574175a2b68b0612ffb48cb044a394c7b4 note: Discovered automatically by archeogit. -upvotes_instructions: +upvotes_instructions: | For the first round, ignore this upvotes number. For the second round of reviewing, you will be giving a certain amount of @@ -137,7 +137,7 @@ upvotes_instructions: upvotes: unit_tested: - question: + question: | Were automated unit tests involved in this vulnerability? Was the original code unit tested, or not unit tested? Did the fix involve improving the automated tests? @@ -156,7 +156,7 @@ unit_tested: fix_answer: The fix for the vulnerability involved improving the automated tests to ensure the issue does not recur. discovered: - question: + question: | How was this vulnerability discovered? Go to the bug report and read the conversation to find out how this was @@ -175,7 +175,7 @@ discovered: developer: false autodiscoverable: - instructions: + instructions: | Is it plausible that a fully automated tool could have discovered this? These are tools that require little knowledge of the domain, e.g. automatic static analysis, compiler warnings, fuzzers. @@ -194,7 +194,7 @@ autodiscoverable: answer: false specification: - instructions: + instructions: | Is there mention of a violation of a specification? For example, the POSIX spec, an RFC spec, a network protocol spec, or some other requirements specification. @@ -212,7 +212,7 @@ specification: answer: false subsystem: - question: + question: | What subsystems was the mistake in? These are WITHIN linux kernel Determining the subsystem is a subjective task. This is to help us group @@ -265,7 +265,7 @@ interesting_commits: - commit: note: i18n: - question: + question: | Was the feature impacted by this vulnerability about internationalization (i18n)? @@ -279,7 +279,7 @@ i18n: answer: false note: Internationalization features were not impacted by this vulnerability as it pertains to the kernel's networking stack and memory management. sandbox: - question: + question: | Did this vulnerability violate a sandboxing feature that the system provides? @@ -295,7 +295,7 @@ sandbox: note: This vulnerability does not involve bypassing any sandboxing features as it is related to memory management within the kernel's networking hardware interface. ipc: - question: + question: | Did the feature that this vulnerability affected use inter-process communication? IPC includes OS signals, pipes, stdin/stdout, message passing, and clipboard. Writing to files that another program in this @@ -307,7 +307,7 @@ ipc: answer: false note: The vulnerability does not involve inter-process communication mechanisms but rather the internal handling of network hardware resources. discussion: - question: + question: | Was there any discussion surrounding this? A discussion can include debates, disputes, or polite talk about how to @@ -335,7 +335,7 @@ discussion: any_discussion: true note: The security implications of the vulnerability were discussed as indicated by the reporting and fixing of the issue in security bulletins and commit messages. vouch: - question: + question: | Was there any part of the fix that involved one person vouching for another's work? @@ -349,7 +349,7 @@ vouch: answer: false note: There is no evidence of vouching for another's work in the commit messages or bug reports related to the fix. stacktrace: - question: + question: | Are there any stacktraces in the bug reports? Secondly, if there is a stacktrace, is the fix in the same file that the @@ -365,7 +365,7 @@ stacktrace: stacktrace_with_fix: false note: No stacktraces were provided in the bug report, and the fix does not reference a stacktrace. forgotten_check: - question: + question: | Does the fix for the vulnerability involve adding a forgotten check? A "forgotten check" can mean many things. It often manifests as the fix @@ -385,7 +385,7 @@ forgotten_check: answer: true note: The fix for the vulnerability involved adding checks to prevent memory leaks when errors occur in the mlx5_vector2eqn() function. order_of_operations: - question: + question: | Does the fix for the vulnerability involve correcting an order of operations? @@ -398,7 +398,7 @@ order_of_operations: answer: false note: The fix did not involve changing the order of operations but rather adding necessary checks to handle errors properly. lessons: - question: + question: | Are there any common lessons we have learned from class that apply to this vulnerability? In other words, could this vulnerability serve as an example of one of those lessons? @@ -447,7 +447,7 @@ lessons: note: The vulnerability is not directly related to the complexity of inputs but to the handling of memory when an error occurs. mistakes: - question: + question: | In your opinion, after all of this research, what mistakes were made that led to this vulnerability? Coding mistakes? Design mistakes? Maintainability? Requirements? Miscommunications? @@ -476,7 +476,7 @@ mistakes: Write a thoughtful entry here that people in the software engineering industry would find interesting. answer: The primary mistake leading to CVE-2019-19045 was a coding error in memory management within the network hardware interface code. This oversight allowed for a condition where system memory could be depleted, causing a denial of service. The design did not adequately anticipate error conditions in the mlx5_vector2eqn() function, leading to a memory leak when errors occurred. -CWE_instructions: +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 https://cwe.mitre.org/data/definitions/699.html for the Software Development @@ -494,7 +494,7 @@ CWE_instructions: CWE: - [401, 400] CWE_note: Manually confirmed -nickname_instructions: +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. From e8c76edf3998a0116cd5ec9e38782607f3a1eb73 Mon Sep 17 00:00:00 2001 From: karisanno11 Date: Wed, 15 Nov 2023 02:01:23 -0500 Subject: [PATCH 18/21] trying to fix error --- cves/kernel/CVE-2019-19045.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cves/kernel/CVE-2019-19045.yml b/cves/kernel/CVE-2019-19045.yml index 516767eb7..e1c30f881 100644 --- a/cves/kernel/CVE-2019-19045.yml +++ b/cves/kernel/CVE-2019-19045.yml @@ -244,7 +244,7 @@ subsystem: e.g. name: ["subsystemA", "subsystemB"] # ok name: subsystemA # also ok - name: ["net", "drivers/net/ethernet/mellanox"] + name: net note: The subsystem involved is the networking subsystem, specifically the drivers for Mellanox Ethernet hardware within the Linux kernel. interesting_commits: question: From 6282dffb4d6266d5f39fa1903e675e0c6fc783a7 Mon Sep 17 00:00:00 2001 From: karisanno11 Date: Wed, 15 Nov 2023 02:07:23 -0500 Subject: [PATCH 19/21] trying to fix error --- cves/kernel/CVE-2019-19045.yml | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/cves/kernel/CVE-2019-19045.yml b/cves/kernel/CVE-2019-19045.yml index e1c30f881..698f3d69d 100644 --- a/cves/kernel/CVE-2019-19045.yml +++ b/cves/kernel/CVE-2019-19045.yml @@ -244,10 +244,10 @@ subsystem: e.g. name: ["subsystemA", "subsystemB"] # ok name: subsystemA # also ok - name: net + name: ["net", "drivers/net/ethernet/mellanox"] note: The subsystem involved is the networking subsystem, specifically the drivers for Mellanox Ethernet hardware within the Linux kernel. -interesting_commits: - question: +interesting_commits: + question: | Are there any interesting commits between your VCC(s) and fix(es)? Use this to specify any commits you think are notable in some way, and @@ -498,6 +498,6 @@ 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: {} CVSS: CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H From 16b590da316c72b8a294ffd72d9d3c49153a8d88 Mon Sep 17 00:00:00 2001 From: karisanno11 Date: Wed, 15 Nov 2023 03:01:24 -0500 Subject: [PATCH 20/21] added upvote points --- cves/kernel/CVE-2019-19045.yml | 2 +- cves/kernel/CVE-2019-8956.yml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/cves/kernel/CVE-2019-19045.yml b/cves/kernel/CVE-2019-19045.yml index 698f3d69d..e9b0f3ae9 100644 --- a/cves/kernel/CVE-2019-19045.yml +++ b/cves/kernel/CVE-2019-19045.yml @@ -134,7 +134,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: 4 unit_tested: question: | diff --git a/cves/kernel/CVE-2019-8956.yml b/cves/kernel/CVE-2019-8956.yml index 567d80665..d6119a808 100644 --- a/cves/kernel/CVE-2019-8956.yml +++ b/cves/kernel/CVE-2019-8956.yml @@ -132,7 +132,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: 3 unit_tested: question: | From cde9d3daeab1ab1adcbad275ed1e3ca70a8c97f0 Mon Sep 17 00:00:00 2001 From: karisanno11 Date: Wed, 15 Nov 2023 03:15:39 -0500 Subject: [PATCH 21/21] Fixed the files based on feedback --- cves/kernel/CVE-2019-19045.yml | 13 ++++++------- cves/kernel/CVE-2019-8956.yml | 5 ++--- 2 files changed, 8 insertions(+), 10 deletions(-) diff --git a/cves/kernel/CVE-2019-19045.yml b/cves/kernel/CVE-2019-19045.yml index e9b0f3ae9..fdf9a51bd 100644 --- a/cves/kernel/CVE-2019-19045.yml +++ b/cves/kernel/CVE-2019-19045.yml @@ -107,8 +107,7 @@ fixes: note: - commit: c8c2a057fdc7de1cd16f4baa51425b932a42eb39 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' + Manually confirmed vcc_instructions: | The vulnerability-contributing commits. @@ -305,7 +304,7 @@ ipc: Write a note about how you came to the conclusions you did, regardless of what your answer was. answer: false - note: The vulnerability does not involve inter-process communication mechanisms but rather the internal handling of network hardware resources. + note: The vulnerability is not related to inter-process communication mechanisms. discussion: question: | Was there any discussion surrounding this? @@ -396,7 +395,7 @@ order_of_operations: Write a note about how you came to the conclusions you did, regardless of what your answer was. answer: false - note: The fix did not involve changing the order of operations but rather adding necessary checks to handle errors properly. + note: The fix involved adding checks for proper error handling, not changing the order of operations. lessons: question: | Are there any common lessons we have learned from class that apply to this @@ -417,7 +416,7 @@ lessons: note: This vulnerability shows the importance of having multiple layers of security. Even if one function fails, others should be in place to prevent exploitation. least_privilege: applies: false - note: The vulnerability does not appear to be related to the principle of least privilege but rather to improper memory handling. + note: The vulnerability does not appear to be related to the principle of least privilege. frameworks_are_optional: applies: false note: This lesson does not apply as the vulnerability is within the kernel's code, not a framework over it. @@ -429,7 +428,7 @@ lessons: note: The vulnerability could potentially be exploited by providing malicious input to the system, which emphasizes the need to validate and sanitize all inputs. security_by_obscurity: applies: false - note: Security by obscurity is not relevant to this vulnerability; it is a matter of proper error handling and memory management. + note: Security by obscurity is not relevant to this vulnerability. serial_killer: applies: false note: This term typically refers to the serialization vulnerabilities, which is not the case here. @@ -498,6 +497,6 @@ 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: CVSS: CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H diff --git a/cves/kernel/CVE-2019-8956.yml b/cves/kernel/CVE-2019-8956.yml index d6119a808..a76507278 100644 --- a/cves/kernel/CVE-2019-8956.yml +++ b/cves/kernel/CVE-2019-8956.yml @@ -103,8 +103,7 @@ fixes: note: - commit: ba59fb0273076637f0add4311faa990a5eec27c0 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' + Manually confirmed vcc_instructions: | The vulnerability-contributing commits. @@ -490,6 +489,6 @@ 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: CVSS: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H