diff --git a/cves/kernel/CVE-2016-2545.yml b/cves/kernel/CVE-2016-2545.yml index f0e0c6f16..2eb2069e8 100644 --- a/cves/kernel/CVE-2016-2545.yml +++ b/cves/kernel/CVE-2016-2545.yml @@ -19,14 +19,16 @@ 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-01-12' +# I believe this is the report +# https://www.spinics.net/lists/alsa-devel/msg45082.html 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. @@ -38,7 +40,8 @@ announced_date: '2016-04-27' published_instructions: | Is there a published fix or patch date for this vulnerability? Please enter your date in YYYY-MM-DD format. -published_date: '2016-04-27' +published_date: '2016-01-13' +# Based on git commit. 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 +58,19 @@ description_instructions: | Your target audience is people just like you before you took any course in security -description: +description: | + The snd_timer_interrupt function, part of the Linux kernel's sound subsystem, + handles sound timer interrupts. A specific linked list within this function + is improperly managed. Local users can exploit this by crafting a special + ioctl call, leading to a use-after-free vulnerability. A use-after-free + vulnerability occurs when memory is accessed after it has been freed, which + can lead to a variety of issues, including program crashes and unpredictable + behavior. + + In this case, the exploitation leads to a race condition, a situation where + the system's behavior is dependent on the sequence or timing of other + uncontrollable events. This race condition can cause the system to crash, + resulting in a denial of service. 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 @@ -64,7 +79,7 @@ bounty: amt: announced: url: -reviews: [] +reviews: [ ] bugs_instructions: | What bugs are involved in this vulnerability? @@ -75,7 +90,8 @@ bugs_instructions: | * Mentioned in mailing list discussions * References from NVD entry * Various other places -bugs: [] +bugs: + - https://bugzilla.redhat.com/show_bug.cgi?id=1311560 fixes_instructions: | Please put the commit hash in "commit" below. @@ -84,14 +100,8 @@ fixes_instructions: | Place any notes you would like to make in the notes field. fixes: -- commit: - note: -- commit: - note: -- commit: ee8413b01045c74340aa13ad5bdf905de32be736 - note: | - Taken from NVD references list with Git commit. If you are - curating, please fact-check that this commit fixes the vulnerability and replace this comment with 'Manually confirmed' + - commit: ee8413b01045c74340aa13ad5bdf905de32be736 + note: Manually Confirmed vcc_instructions: | The vulnerability-contributing commits. @@ -105,8 +115,8 @@ vcc_instructions: | Place any notes you would like to make in the notes field. vccs: -- commit: 9244b2c3079faac79b3b961116bd548c45087e2c - note: Discovered automatically by archeogit. + - commit: 9244b2c3079faac79b3b961116bd548c45087e2c + note: Manually Confirmed upvotes_instructions: | For the first round, ignore this upvotes number. @@ -114,7 +124,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? @@ -129,10 +139,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: No related unit tests could be found. + fix: false + fix_answer: No automated tests added. discovered: question: | How was this vulnerability discovered? @@ -147,10 +157,13 @@ discovered: If there is no evidence as to how this vulnerability was found, then please explain where you looked. - answer: - automated: - contest: - developer: + answer: | + This vulnerability was found by Dmitry Vyukov, a Google employee, by + utilizing Google's syzkaller fuzzer. + https://www.spinics.net/lists/alsa-devel/msg45082.html + automated: true + contest: false + developer: true autodiscoverable: instructions: | Is it plausible that a fully automated tool could have discovered @@ -167,8 +180,11 @@ autodiscoverable: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: - answer: + note: | + The vulnerability was discovered using Google's syzkaller fuzzer. This + demonstrates that it's not only possible, but proven, that automated tools + can be used to uncover similar vulnerabilities. + answer: true specification: instructions: | Is there mention of a violation of a specification? For example, the POSIX @@ -184,8 +200,10 @@ specification: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: - answer: + note: | + No related specification violations found in bug reports, kernel lore + discussions, commit messages, or mailing lists. + answer: false subsystem: question: | What subsystems was the mistake in? These are WITHIN linux kernel @@ -219,8 +237,10 @@ subsystem: e.g. name: ["subsystemA", "subsystemB"] # ok name: subsystemA # also ok - name: - note: + name: sound + note: | + The vulnerability is in the timers abstract layer of the Advanced Linux + Sound Architecture (ALSA). interesting_commits: question: | Are there any interesting commits between your VCC(s) and fix(es)? @@ -235,10 +255,8 @@ interesting_commits: * Other commits that fixed a similar issue as this vulnerability * Anything else you find interesting. commits: - - commit: - note: - - commit: - note: + - commit: + note: i18n: question: | Was the feature impacted by this vulnerability about internationalization @@ -251,8 +269,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 relates to a linked list. sandbox: question: | Did this vulnerability violate a sandboxing feature that the system @@ -266,8 +284,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: | + The vulnerability is a race condition in the snd_timer_interrupt function, + which is not related to sandboxing features. ipc: question: | Did the feature that this vulnerability affected use inter-process @@ -278,8 +298,15 @@ 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 snd_timer_interrupt function, a low-level timer interrupt, directly + interacts with hardware. Given its nature, it is highly unlikely + that it employs any form of userspace inter-process communication (IPC) such + as sockets, pipes, message queues, or shared memory. Therefore, any + potential IPC usage within the broader Advanced Linux Sound Architecture + (ALSA) system, which manages sound timers, would be unrelated to this + specific function. discussion: question: | Was there any discussion surrounding this? @@ -305,9 +332,14 @@ 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: | + While I don't believe this was explicitly discussed as a security issue, + it was discovered and discussed as a use-after-free memory vulnerability, + which does have security implications. + https://www.spinics.net/lists/alsa-devel/msg45082.html + https://lore.kernel.org/lkml/lsq.1454975631.69933183@decadent.org.uk/ vouch: question: | Was there any part of the fix that involved one person vouching for @@ -320,8 +352,17 @@ vouch: Answer must be true or false. Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: + answer: true + note: | + The patch commit itself was overseen by numerous employees from reputable + organizations. The vulnerability was discovered by Dmitry Vyukov, an + employee at Google, using the syzkaller fuzzer. The patch was subsequently + developed by Takashi Iwai from SUSE. Dmitry Vyukov then tested this patch. + The final sign-off on the patch was done by Ben Hutchings, a Debian + Developer. + + Further examination of various discussions would likely reveal that this fix + was reviewed by an even larger number of individuals. stacktrace: question: | Are there any stacktraces in the bug reports? @@ -335,9 +376,12 @@ 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: true + stacktrace_with_fix: true + note: | + The stacktrace in the bug report points to the file `sound/core/timer.c` + where the vulnerability resides and where the fix was applied. + https://www.spinics.net/lists/alsa-devel/msg45082.html forgotten_check: question: | Does the fix for the vulnerability involve adding a forgotten check? @@ -356,8 +400,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: | + The fix was to use a slightly different function variant for deleting + entries from the linked list. The fix did not include adding any checks. order_of_operations: question: | Does the fix for the vulnerability involve correcting an order of @@ -369,8 +415,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: false + note: | + The fix does not involve moving code around or changing the order of how + things are done. lessons: question: | Are there any common lessons we have learned from class that apply to this @@ -399,8 +447,10 @@ lessons: applies: note: distrust_input: - applies: - note: + applies: true + note: | + The snd_timer_interrupt function lacks control over its input, leading to + a use-after-free vulnerability. security_by_obscurity: applies: note: @@ -411,8 +461,10 @@ lessons: applies: note: secure_by_default: - applies: - note: + applies: true + note: | + A safer function list_del_init was available but was not used correctly + leading to the vulnerability. yagni: applies: note: @@ -448,13 +500,22 @@ mistakes: Write a thoughtful entry here that people in the software engineering industry would find interesting. - answer: + answer: | + The vulnerability in this case was caused by a lapse. The developers were + already using the safer function list_del_init in other parts of the code, + but they overlooked its use in this specific instance,leading to the + vulnerability. + + The commit 9244b2c, referenced above, introduced a change in the list + handling from list_for_each to list_for_each_entry across the + Advanced Linux Sound Architecture (ALSA). However, the developers failed to + recognize that the list_del function needed to be replaced with + list_del_init to prevent this vulnerability. CWE_instructions: | - Please go to http://cwe.mitre.org and find the most specific, appropriate CWE + Please go to https://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. + view of the vulnerabilities. If you have anything to note about why you classified it this way, write something in CWE_note. This field is optional. @@ -465,13 +526,11 @@ CWE_instructions: | CWE: [123, 456] # also ok CWE: 123 # also ok CWE: -- 362 -CWE_note: | - CWE as registered in the NVD. If you are curating, check that this - is correct and replace this comment with "Manually confirmed". + - 362 +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: CVSS:3.0/AV:L/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H diff --git a/cves/kernel/CVE-2022-28389.yml b/cves/kernel/CVE-2022-28389.yml index e802acce9..7f8b0115b 100644 --- a/cves/kernel/CVE-2022-28389.yml +++ b/cves/kernel/CVE-2022-28389.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: '2022-02-28' announced_instructions: | Was there a date that this vulnerability was announced to the world? You can find this in changelogs, blogs, bug reports, or perhaps the CVE date. @@ -38,9 +38,10 @@ announced_date: '2022-04-03' published_instructions: | Is there a published fix or patch date for this vulnerability? Please enter your date in YYYY-MM-DD format. -published_date: '2022-04-03' +published_date: '2022-03-31' +# Based on git commit. description_instructions: | - You can get an initial description from the CVE entry on cve.mitre.org. These + You can get an initial description from the CVE entry on cve.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 @@ -55,7 +56,23 @@ description_instructions: | Your target audience is people just like you before you took any course in security -description: +description: | + The mca_usb driver, a component of the Linux kernel, interfaces with the + Microchip CAN BUS Analyzer Tool via USB, utilizing the SocketCAN framework. + A double free error was identified in the mcba_usb_start_xmit() function, + where the same memory block was erroneously freed twice. This mishap can + lead to a double allocation scenario. + + Double allocation occurs when a program, unaware of a previous deallocation, + allocates the same memory block again. This can result in multiple programs + being assigned the same memory block, leading to data overwrites. It can + also cause a program to access memory that has already been freed, leading + to crashes. + + The significance of this vulnerability lies in its potential exploitation + by an attacker to induce a denial-of-service (DoS) attack or execute + arbitrary code. For instance, an attacker could send a specially crafted + CAN frame to the mca_usb device, exploiting this vulnerability. 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 @@ -64,7 +81,7 @@ bounty: amt: announced: url: -reviews: [] +reviews: [ ] bugs_instructions: | What bugs are involved in this vulnerability? @@ -75,23 +92,19 @@ bugs_instructions: | * Mentioned in mailing list discussions * References from NVD entry * Various other places -bugs: [] +bugs: + - https://bugzilla.redhat.com/show_bug.cgi?id=2073086 + - https://bugzilla.redhat.com/show_bug.cgi?id=2073087 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/ + hexadecimal string/ Place any notes you would like to make in the notes field. fixes: -- commit: - note: -- commit: - note: -- commit: 04c9b00ba83594a29813d6b1fb8fdc93a3915174 - note: | - Taken from NVD references list with Git commit. If you are - curating, please fact-check that this commit fixes the vulnerability and replace this comment with 'Manually confirmed' + - commit: 04c9b00ba83594a29813d6b1fb8fdc93a3915174 + note: Manually Confirmed vcc_instructions: | The vulnerability-contributing commits. @@ -105,8 +118,8 @@ vcc_instructions: | Place any notes you would like to make in the notes field. vccs: -- commit: 51f3baad7de943780ce0c17bd7975df567dd6e14 - note: Discovered automatically by archeogit. + - commit: 51f3baad7de943780ce0c17bd7975df567dd6e14 + note: Manually Confirmed upvotes_instructions: | For the first round, ignore this upvotes number. @@ -114,7 +127,7 @@ upvotes_instructions: | upvotes to each vulnerability you see. Your peers will tell you how interesting they think this vulnerability is, and you'll add that to the upvotes score on your branch. -upvotes: +upvotes: 1 unit_tested: question: | Were automated unit tests involved in this vulnerability? @@ -129,10 +142,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: No related unit tests could be found. + fix: false + fix_answer: No automated tests added. discovered: question: | How was this vulnerability discovered? @@ -141,16 +154,20 @@ discovered: 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. + vulnerability 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: + answer: | + This issue was discovered while Hangyu Hua was discussing an incorrect patch + with Marc Kleine-Budde. + https://lore.kernel.org/all/20220225060019.21220-1-hbh25y@gmail.com/ + automated: false + contest: false + developer: false + # I am unsure. Marc Kleine-Budde was from Pengutronix. autodiscoverable: instructions: | Is it plausible that a fully automated tool could have discovered @@ -167,8 +184,12 @@ autodiscoverable: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: - answer: + note: | + It is plausible that a fully automated tool could have discovered this + vulnerability. A double free can be detected using memory debugging tools + like Valgrind, static analysis tools, and even some fuzzers may be used to + generate random inputs that may trigger the vulnerability. + answer: true specification: instructions: | Is there mention of a violation of a specification? For example, the POSIX @@ -184,8 +205,10 @@ specification: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: - answer: + note: | + No related specification violations found in bug reports, kernel lore + discussions, commit messages, or mailing lists. + answer: false subsystem: question: | What subsystems was the mistake in? These are WITHIN linux kernel @@ -219,8 +242,10 @@ subsystem: e.g. name: ["subsystemA", "subsystemB"] # ok name: subsystemA # also ok - name: - note: + name: [ "drivers", "usb", "net" ] + note: | + The mca_usb driver is a SocketCAN driver, which handles both USB and + networking. interesting_commits: question: | Are there any interesting commits between your VCC(s) and fix(es)? @@ -235,10 +260,10 @@ interesting_commits: * Other commits that fixed a similar issue as this vulnerability * Anything else you find interesting. commits: - - commit: - note: - - commit: - note: + - commit: 91c02557174be7f72e46ed7311e3bea1939840b0 + note: | + A memory leak in the same mcba_usb driver was found a year prior to + this vulnerability. It was reported by Syzbot. i18n: question: | Was the feature impacted by this vulnerability about internationalization @@ -251,8 +276,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 relates to memory allocation. sandbox: question: | Did this vulnerability violate a sandboxing feature that the system @@ -266,8 +291,11 @@ sandbox: Answer should be true or false Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: + answer: false + note: | + This vulnerability relates to a network driver that communicates with using + the USB subsystem. It does not affect the permissions of other users or + processes. It does not relate to any sandboxing features. ipc: question: | Did the feature that this vulnerability affected use inter-process @@ -278,8 +306,10 @@ 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 mcba_usb driver primarily interacts with the Linux kernel through its + netdev_ops structure, not through inter-process communication (IPC). discussion: question: | Was there any discussion surrounding this? @@ -305,9 +335,16 @@ 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: | + This was found while discussing a separate patch for a memory leak in + esd_usb2_start_xmit. + https://lore.kernel.org/all/20220225060019.21220-1-hbh25y@gmail.com/ + + There was discussion regarding this vulnerability such as how to resolve the + possible double free. + https://lore.kernel.org/all/20220311080208.45047-1-hbh25y@gmail.com/ vouch: question: | Was there any part of the fix that involved one person vouching for @@ -319,9 +356,15 @@ vouch: * 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: + Write a note about how you came to the conclusions you did, regardless of + what your answer was. + answer: true + note: | + Marc Kleine-Budde helped Hangyu Hua find the issue in a lore discussion, + https://lore.kernel.org/all/20220228075146.hvui3iow7niupij4@pengutronix.de/ + + In the commit message both Hangyu Hua and Marc Kleine-Budde signed off on + the fix. stacktrace: question: | Are there any stacktraces in the bug reports? @@ -335,9 +378,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 noticed in any bug reports or discussions. forgotten_check: question: | Does the fix for the vulnerability involve adding a forgotten check? @@ -356,8 +399,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: | + The fix removed a redundant function call that led to memory being freed + twice. The fix did not include adding any checks. order_of_operations: question: | Does the fix for the vulnerability involve correcting an order of @@ -369,8 +414,11 @@ order_of_operations: Answer must be true or false. Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: + answer: true + note: | + There was discussion about the order of calling certain functions. The final + fix removed a single function call, but it does relate to the ordering of + how and when memory is freed. lessons: question: | Are there any common lessons we have learned from class that apply to this @@ -448,13 +496,19 @@ mistakes: Write a thoughtful entry here that people in the software engineering industry would find interesting. - answer: + answer: | + This vulnerability seems to be caused by a coding mistake, specifically a + logic error. The call to dev_kfree_skb() in mcba_usb_start_xmit() led to a + double free. This was likely a slip where they did not realize memory was + already being freed. + + More robust testing practices and more stringent code reviews could have + caught this mistake before deployment. CWE_instructions: | - Please go to http://cwe.mitre.org and find the most specific, appropriate CWE + Please go to https://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. + view of the vulnerabilities. If you have anything to note about why you classified it this way, write something in CWE_note. This field is optional. @@ -465,13 +519,12 @@ CWE_instructions: | CWE: [123, 456] # also ok CWE: 123 # also ok CWE: -- 415 -CWE_note: | - CWE as registered in the NVD. If you are curating, check that this - is correct and replace this comment with "Manually confirmed". + - 415 +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:N/I:N/A:H +nickname: McDoubleFree +# I have no clue. mcba + double free = McDoubleFree +CVSS: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H \ No newline at end of file