From a2b96d39f2203995e7dda2f38d87c5d600f5fb54 Mon Sep 17 00:00:00 2001 From: hmh1842 Date: Sun, 5 Nov 2023 15:07:43 -0500 Subject: [PATCH 1/7] setup --- cves/kernel/CVE-2022-3104.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cves/kernel/CVE-2022-3104.yml b/cves/kernel/CVE-2022-3104.yml index 249401879..227123b80 100644 --- a/cves/kernel/CVE-2022-3104.yml +++ b/cves/kernel/CVE-2022-3104.yml @@ -19,7 +19,7 @@ curated_instructions: | This will enable additional editorial checks on this file to make sure you fill everything out properly. If you are a student, we cannot accept your work as finished unless curated is properly updated. -curation_level: 0 +curation_level: 2 reported_instructions: | What date was the vulnerability reported to the security team? Look at the security bulletins and bug reports. It is not necessarily the same day that From 2d56a68e6cc00bfbb280ed4e85f97c83f409dea2 Mon Sep 17 00:00:00 2001 From: hmh1842 Date: Mon, 6 Nov 2023 19:05:50 -0500 Subject: [PATCH 2/7] vul 1 --- cves/kernel/CVE-2022-3104.yml | 139 +++++++++++++++++++++------------- 1 file changed, 88 insertions(+), 51 deletions(-) diff --git a/cves/kernel/CVE-2022-3104.yml b/cves/kernel/CVE-2022-3104.yml index 227123b80..67913d41d 100644 --- a/cves/kernel/CVE-2022-3104.yml +++ b/cves/kernel/CVE-2022-3104.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: '2023-11-06' 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,12 @@ description_instructions: | Your target audience is people just like you before you took any course in security -description: +description: | + In the drivers, does not check if kmalloc returns a NULL value or not. + Results in the code assuming it will always have a value and will + dereference the pointer. If a pointer is deferenced while it's pointing to a + NULL memory address, it will cause an error + 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 +80,7 @@ bugs_instructions: | * Mentioned in mailing list discussions * References from NVD entry * Various other places -bugs: [] +bugs: [NULL Pointer Dereference] fixes_instructions: | Please put the commit hash in "commit" below. @@ -84,14 +89,8 @@ fixes_instructions: | Place any notes you would like to make in the notes field. fixes: -- commit: - note: -- commit: - note: - commit: 4a9800c81d2f34afb66b4b42e0330ae8298019a2 - note: | - Taken from NVD references list with Git commit. If you are - curating, please fact-check that this commit fixes the vulnerability and replace this comment with 'Manually confirmed' + note: Manually confirmed vcc_instructions: | The vulnerability-contributing commits. @@ -104,7 +103,7 @@ vcc_instructions: | anything. Place any notes you would like to make in the notes field. -vccs: +vccs: - commit: ae2e1aad3e48e495878d9f149e437a308bfdaefa note: Discovered automatically by archeogit. upvotes_instructions: | @@ -129,10 +128,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: 1 + code_answer: 1 + fix: 1 + fix_answer: 1 discovered: question: | How was this vulnerability discovered? @@ -147,10 +146,14 @@ discovered: If there is no evidence as to how this vulnerability was found, then please explain where you looked. - answer: - automated: - contest: - developer: + answer: | + I looked in the git.kernal.org and the access.redhat. I looked at the commit + messages in the kernal.org and found Jiasheng Jiang discovered the bug. + This person's email is jiasheng@iscas.ac.cn so i assume he's not a google developer + + automated: false + contest: false + developer: true autodiscoverable: instructions: | Is it plausible that a fully automated tool could have discovered @@ -167,8 +170,10 @@ autodiscoverable: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: - answer: + note: | + You can try using the function with an NULL variable. + An automated tool would test this possibility of a NULL variable/array + answer: 1 specification: instructions: | Is there mention of a violation of a specification? For example, the POSIX @@ -184,8 +189,11 @@ specification: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: - answer: + note: 0 + answer: | + Checked the redhat Common Vulnerability Scoring System (CVSS) Score + and it shows that the impact of the bug is low or None except for + availability. So there is no violation subsystem: question: | What subsystems was the mistake in? These are WITHIN linux kernel @@ -219,8 +227,8 @@ subsystem: e.g. name: ["subsystemA", "subsystemB"] # ok name: subsystemA # also ok - name: - note: + name: drivers + note: It was the top directory of it's in the drivers subsystem interesting_commits: question: | Are there any interesting commits between your VCC(s) and fix(es)? @@ -235,8 +243,10 @@ interesting_commits: * Other commits that fixed a similar issue as this vulnerability * Anything else you find interesting. commits: - - commit: - note: + - commit: b27ee76c74dc831d6e092eaebc2dfc9c0beed1c9 + note: | + Same error as this vulnerbility, NULL pointer deference. + This shows that this is a common error in C programming - commit: note: i18n: @@ -251,8 +261,10 @@ 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: | + my bug involves a pointer pointing at a NULL memory address + so internationalization cannot be part of the problem sandbox: question: | Did this vulnerability violate a sandboxing feature that the system @@ -266,8 +278,10 @@ 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 involves checking an array bounds + and it's in the drivers subsystem so it does not violate the sandboxing feature ipc: question: | Did the feature that this vulnerability affected use inter-process @@ -278,8 +292,11 @@ ipc: Answer must be true or false. Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: + answer: True + note: | + The function does a pr_info and I assume that is relaying info to the dev + but the system would crash instead of printing. The new fix return the function + and doesn't print anything discussion: question: | Was there any discussion surrounding this? @@ -305,9 +322,13 @@ discussion: Put any links to disagreements you found in the notes section, or any other comment you want to make. - discussed_as_security: - any_discussion: - note: + discussed_as_security: false + any_discussion: false + note: | + There is no discussion because the vulnerability is a simple fix. + The added code check if the pointer is NULL and if it is return + and don't run the rest of the function + vouch: question: | Was there any part of the fix that involved one person vouching for @@ -320,8 +341,11 @@ vouch: Answer must be true or false. Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: + answer: true + note: | + on git.kernal.org there is a sign-off and acknowledge-by people + Signed-off by Kees Cook and + Acknowledge-by Dan Carpenter stacktrace: question: | Are there any stacktraces in the bug reports? @@ -335,9 +359,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 mention or link to stacktrace on redhat, kernal.org, or NVD forgotten_check: question: | Does the fix for the vulnerability involve adding a forgotten check? @@ -356,8 +381,10 @@ 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 bug was that the pointer was not check if it was NULL + The fix was checking if the pointer is NULL order_of_operations: question: | Does the fix for the vulnerability involve correcting an order of @@ -369,8 +396,10 @@ order_of_operations: Answer must be true or false. Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: + answer: true + note: | + The fix involved checking if the pointer was NULL. + Before excuting the function check the pointer lessons: question: | Are there any common lessons we have learned from class that apply to this @@ -407,12 +436,14 @@ lessons: serial_killer: applies: note: - environment_variables: - applies: + environment_variables: + applies: note: secure_by_default: - applies: - note: + applies: true + note: | + should check variable before you use/free them to see if they're NULL + especially if you're freeing them yagni: applies: note: @@ -448,7 +479,13 @@ mistakes: Write a thoughtful entry here that people in the software engineering industry would find interesting. - answer: + answer: | + This is a coding mistake, the developer did not take into consideration + that the pointer could be NULL and always assumed it would point + to a valid memory address. This could also be a design mistake where + the design shows no possibility for there to be a NULL pointer in that + situation. But this seems to be an common issue in the C developing world + and the fix is it is quite simple (check for NULL pointer). 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 @@ -473,5 +510,5 @@ nickname_instructions: | A catchy name for this vulnerability that would draw attention it. If the report mentions a nickname, use that. Must be under 30 characters. Optional. -nickname: +nickname: NULL_Dereferencer CVSS: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H From 9de72b0b1d87fc7c26519be0fa45fd5b23babd14 Mon Sep 17 00:00:00 2001 From: hmh1842 Date: Tue, 7 Nov 2023 15:29:05 -0500 Subject: [PATCH 3/7] second --- cves/kernel/CVE-2016-5400.yml | 130 +++++++++++++++++++++------------- cves/kernel/CVE-2022-3104.yml | 2 +- 2 files changed, 82 insertions(+), 50 deletions(-) diff --git a/cves/kernel/CVE-2016-5400.yml b/cves/kernel/CVE-2016-5400.yml index ef58167e1..2e80f3215 100644 --- a/cves/kernel/CVE-2016-5400.yml +++ b/cves/kernel/CVE-2016-5400.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: 2016-06-10 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,11 @@ description_instructions: | Your target audience is people just like you before you took any course in security -description: +description: | + This error is caused by a memory overflow, which means the system ran out of RAM. + The function to copy the information from a USB didn't properly delete (free) + the data when it was suppose to. This allowed a badusb device to emulate a lot of + fake usb devices and overflow the system, causing a memory overflow 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 +79,7 @@ bugs_instructions: | * Mentioned in mailing list discussions * References from NVD entry * Various other places -bugs: [] +bugs: [Memory Overflow, Memory Leak] fixes_instructions: | Please put the commit hash in "commit" below. @@ -89,9 +93,7 @@ fixes: - commit: note: - commit: aa93d1fee85c890a34f2510a310e55ee76a27848 - note: | - Taken from NVD references list with Git commit. If you are - curating, please fact-check that this commit fixes the vulnerability and replace this comment with 'Manually confirmed' + note: 'Manually confirmed' vcc_instructions: | The vulnerability-contributing commits. @@ -129,10 +131,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: 0 + code_answer: 0 + fix: 0 + fix_answer: 0 discovered: question: | How was this vulnerability discovered? @@ -147,10 +149,14 @@ 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 first comment on the issue was about how an attack can use a badusb + device is cause a memory leak. They had found a memory leak and noticing concluded + that you're able to cause if memory overflow if the code is fixed + + automated: false + contest: false + developer: true autodiscoverable: instructions: | Is it plausible that a fully automated tool could have discovered @@ -167,8 +173,10 @@ autodiscoverable: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: - answer: + note: | + Because it involves a buffer overflow so you could test it using + a bad usb device + answer: 1 specification: instructions: | Is there mention of a violation of a specification? For example, the POSIX @@ -184,8 +192,10 @@ specification: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: - answer: + note: | + The improper usage of operations outside the scope of the usb. + The system was writing memory in a place it wasn't suppose to. + answer: 1 subsystem: question: | What subsystems was the mistake in? These are WITHIN linux kernel @@ -219,8 +229,9 @@ subsystem: e.g. name: ["subsystemA", "subsystemB"] # ok name: subsystemA # also ok - name: - note: + name: ["drivers", "usb"] + note: | + This problem was in the drivers directory interesting_commits: question: | Are there any interesting commits between your VCC(s) and fix(es)? @@ -235,8 +246,10 @@ interesting_commits: * Other commits that fixed a similar issue as this vulnerability * Anything else you find interesting. commits: - - commit: - note: + - commit: eca2d34b9d2ce70165a50510659838e28ca22742 + note: | + This commit was in the comments with developers saying it this was also + the fix to the bug even though it was a fix to another big - commit: note: i18n: @@ -251,8 +264,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: "this bugged involved out of bound operations" sandbox: question: | Did this vulnerability violate a sandboxing feature that the system @@ -266,8 +279,8 @@ 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: "The bug involved excuting operations outside of the bound of memory" ipc: question: | Did the feature that this vulnerability affected use inter-process @@ -278,8 +291,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: false + note: "The bug involved excuting operations outside of the bound of memory" discussion: question: | Was there any discussion surrounding this? @@ -305,9 +318,12 @@ discussion: Put any links to disagreements you found in the notes section, or any other comment you want to make. - discussed_as_security: - any_discussion: - note: + discussed_as_security: false + any_discussion: true + note: | + there was a discussion on if the issue was fixed yet and how it was fixed + the reporter of the issue mentioned it was fixed along with another + issue and sent a link to the commit vouch: question: | Was there any part of the fix that involved one person vouching for @@ -320,8 +336,11 @@ vouch: Answer must be true or false. Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: + answer: true + note: | + It was signed off and reviewed on git.kernal + Signed off by James Patrick-Evans + Reviewed-by Kees Cook stacktrace: question: | Are there any stacktraces in the bug reports? @@ -335,9 +354,11 @@ 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: 0 + stacktrace_with_fix: 0 + note: | + Could not find stacktrace on redhat, bugzilla, git.kernal, or in any + of the logs forgotten_check: question: | Does the fix for the vulnerability involve adding a forgotten check? @@ -356,8 +377,10 @@ forgotten_check: Answer must be true or false. Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: + answer: false + note: | + This bug involves operating in out of bounds memory, + there could be a check to check if the system is operating in the correct space order_of_operations: question: | Does the fix for the vulnerability involve correcting an order of @@ -369,8 +392,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: | + This bug involves operating in out of bounds memory lessons: question: | Are there any common lessons we have learned from class that apply to this @@ -386,12 +410,14 @@ 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: - least_privilege: + defense_in_depth: applies: note: + least_privilege: + applies: true + note: | + should keep track of the bounds of the memory you're changing + the bug here changed memory outside bounds so it caused a leak frameworks_are_optional: applies: note: @@ -411,8 +437,10 @@ lessons: applies: note: secure_by_default: - applies: - note: + applies: true + note: | + The code should also be handle errors better since an error + when copying the usb would cuase the leak yagni: applies: note: @@ -448,7 +476,11 @@ mistakes: Write a thoughtful entry here that people in the software engineering industry would find interesting. - answer: + answer: | + The biggest lesson in thie bug is error handling since mishandling the + errors caused the memory leak leading to the buffer overlow. This error + caused it so it wouldn't finish the function therefore the memory was not freed. + 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 @@ -473,5 +505,5 @@ nickname_instructions: | A catchy name for this vulnerability that would draw attention it. If the report mentions a nickname, use that. Must be under 30 characters. Optional. -nickname: +nickname: free_my_memory CVSS: diff --git a/cves/kernel/CVE-2022-3104.yml b/cves/kernel/CVE-2022-3104.yml index 67913d41d..ddcd42a93 100644 --- a/cves/kernel/CVE-2022-3104.yml +++ b/cves/kernel/CVE-2022-3104.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: '2023-11-06' +reported_date: 2023-11-06 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 1a666c38cc2eda741d23cd513709df942628159d Mon Sep 17 00:00:00 2001 From: hmh1842 Date: Tue, 7 Nov 2023 22:23:22 -0500 Subject: [PATCH 4/7] fixing --- cves/kernel/CVE-2016-5400.yml | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/cves/kernel/CVE-2016-5400.yml b/cves/kernel/CVE-2016-5400.yml index 2e80f3215..78687713a 100644 --- a/cves/kernel/CVE-2016-5400.yml +++ b/cves/kernel/CVE-2016-5400.yml @@ -230,8 +230,7 @@ subsystem: name: ["subsystemA", "subsystemB"] # ok name: subsystemA # also ok name: ["drivers", "usb"] - note: | - This problem was in the drivers directory + note: 'This problem was in the drivers directory' interesting_commits: question: | Are there any interesting commits between your VCC(s) and fix(es)? @@ -354,8 +353,8 @@ 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: 0 - stacktrace_with_fix: 0 + any_stacktraces: true + stacktrace_with_fix: false note: | Could not find stacktrace on redhat, bugzilla, git.kernal, or in any of the logs From 82a436c228b3a0a992d638698837a8a8fc30ade2 Mon Sep 17 00:00:00 2001 From: hmh1842 Date: Tue, 7 Nov 2023 22:34:49 -0500 Subject: [PATCH 5/7] test --- cves/kernel/CVE-2016-5400.yml | 14 +++++++------- cves/kernel/CVE-2022-3104.yml | 14 +++++++------- 2 files changed, 14 insertions(+), 14 deletions(-) diff --git a/cves/kernel/CVE-2016-5400.yml b/cves/kernel/CVE-2016-5400.yml index 78687713a..5e5197c0e 100644 --- a/cves/kernel/CVE-2016-5400.yml +++ b/cves/kernel/CVE-2016-5400.yml @@ -93,7 +93,7 @@ fixes: - commit: note: - commit: aa93d1fee85c890a34f2510a310e55ee76a27848 - note: 'Manually confirmed' + note: Manually confirmed vcc_instructions: | The vulnerability-contributing commits. @@ -131,10 +131,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: 0 - code_answer: 0 - fix: 0 - fix_answer: 0 + code: false + code_answer: false + fix: false + fix_answer: false discovered: question: | How was this vulnerability discovered? @@ -176,7 +176,7 @@ autodiscoverable: note: | Because it involves a buffer overflow so you could test it using a bad usb device - answer: 1 + answer: true specification: instructions: | Is there mention of a violation of a specification? For example, the POSIX @@ -195,7 +195,7 @@ specification: note: | The improper usage of operations outside the scope of the usb. The system was writing memory in a place it wasn't suppose to. - answer: 1 + answer: true subsystem: question: | What subsystems was the mistake in? These are WITHIN linux kernel diff --git a/cves/kernel/CVE-2022-3104.yml b/cves/kernel/CVE-2022-3104.yml index ddcd42a93..a188bd8ad 100644 --- a/cves/kernel/CVE-2022-3104.yml +++ b/cves/kernel/CVE-2022-3104.yml @@ -128,10 +128,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: 1 - code_answer: 1 - fix: 1 - fix_answer: 1 + code: true + code_answer: true + fix: true + fix_answer: true discovered: question: | How was this vulnerability discovered? @@ -173,7 +173,7 @@ autodiscoverable: note: | You can try using the function with an NULL variable. An automated tool would test this possibility of a NULL variable/array - answer: 1 + answer: true specification: instructions: | Is there mention of a violation of a specification? For example, the POSIX @@ -189,11 +189,11 @@ specification: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: 0 - answer: | + note: | Checked the redhat Common Vulnerability Scoring System (CVSS) Score and it shows that the impact of the bug is low or None except for availability. So there is no violation + answer: false subsystem: question: | What subsystems was the mistake in? These are WITHIN linux kernel From cd9ab35286d4a8e4c74a879ab6b13d5cb050a479 Mon Sep 17 00:00:00 2001 From: hmh1842 Date: Mon, 13 Nov 2023 20:24:23 -0500 Subject: [PATCH 6/7] feedback corrections --- cves/kernel/CVE-2016-5400.yml | 12 ++++++------ cves/kernel/CVE-2022-3104.yml | 2 +- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/cves/kernel/CVE-2016-5400.yml b/cves/kernel/CVE-2016-5400.yml index 5e5197c0e..3650bd0db 100644 --- a/cves/kernel/CVE-2016-5400.yml +++ b/cves/kernel/CVE-2016-5400.yml @@ -79,7 +79,7 @@ bugs_instructions: | * Mentioned in mailing list discussions * References from NVD entry * Various other places -bugs: [Memory Overflow, Memory Leak] +bugs: [1358184] fixes_instructions: | Please put the commit hash in "commit" below. @@ -391,9 +391,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: false + answer: true note: | - This bug involves operating in out of bounds memory + The big didn't the correct clean up operation order leading to a memory leak lessons: question: | Are there any common lessons we have learned from class that apply to this @@ -410,13 +410,13 @@ 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: - least_privilege: applies: true note: | should keep track of the bounds of the memory you're changing the bug here changed memory outside bounds so it caused a leak + least_privilege: + applies: + note: frameworks_are_optional: applies: note: diff --git a/cves/kernel/CVE-2022-3104.yml b/cves/kernel/CVE-2022-3104.yml index a188bd8ad..3c33c2424 100644 --- a/cves/kernel/CVE-2022-3104.yml +++ b/cves/kernel/CVE-2022-3104.yml @@ -80,7 +80,7 @@ bugs_instructions: | * Mentioned in mailing list discussions * References from NVD entry * Various other places -bugs: [NULL Pointer Dereference] +bugs: [2153062] fixes_instructions: | Please put the commit hash in "commit" below. From c15ff9de4f94e0841b3a478f3768d550ee9bcdaf Mon Sep 17 00:00:00 2001 From: hmh1842 Date: Wed, 15 Nov 2023 20:05:03 -0500 Subject: [PATCH 7/7] updated upvotes --- cves/kernel/CVE-2016-5400.yml | 2 +- cves/kernel/CVE-2022-3104.yml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/cves/kernel/CVE-2016-5400.yml b/cves/kernel/CVE-2016-5400.yml index 3650bd0db..fc117fe81 100644 --- a/cves/kernel/CVE-2016-5400.yml +++ b/cves/kernel/CVE-2016-5400.yml @@ -116,7 +116,7 @@ upvotes_instructions: | upvotes to each vulnerability you see. Your peers will tell you how interesting they think this vulnerability is, and you'll add that to the upvotes score on your branch. -upvotes: +upvotes: 2 unit_tested: question: | Were automated unit tests involved in this vulnerability? diff --git a/cves/kernel/CVE-2022-3104.yml b/cves/kernel/CVE-2022-3104.yml index 3c33c2424..29e7456f6 100644 --- a/cves/kernel/CVE-2022-3104.yml +++ b/cves/kernel/CVE-2022-3104.yml @@ -113,7 +113,7 @@ upvotes_instructions: | upvotes to each vulnerability you see. Your peers will tell you how interesting they think this vulnerability is, and you'll add that to the upvotes score on your branch. -upvotes: +upvotes: 1 unit_tested: question: | Were automated unit tests involved in this vulnerability?