From 4c0bf9259ab80ebe21b3c8ae01dc81c7021f051c Mon Sep 17 00:00:00 2001 From: Nolan White Date: Mon, 6 Nov 2023 13:38:07 -0500 Subject: [PATCH 01/17] Update curation levels for CVE-2022-0487 and CVE-2013-2140 --- cves/kernel/CVE-2013-2140.yml | 2 +- cves/kernel/CVE-2022-0487.yml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/cves/kernel/CVE-2013-2140.yml b/cves/kernel/CVE-2013-2140.yml index 68258af47..448a0a14a 100644 --- a/cves/kernel/CVE-2013-2140.yml +++ b/cves/kernel/CVE-2013-2140.yml @@ -19,7 +19,7 @@ curated_instructions: | This will enable additional editorial checks on this file to make sure you fill everything out properly. If you are a student, we cannot accept your work as finished unless curated is properly updated. -curation_level: 0 +curation_level: 2 reported_instructions: | What date was the vulnerability reported to the security team? Look at the security bulletins and bug reports. It is not necessarily the same day that diff --git a/cves/kernel/CVE-2022-0487.yml b/cves/kernel/CVE-2022-0487.yml index 30b616f76..5e5fdbf80 100644 --- a/cves/kernel/CVE-2022-0487.yml +++ b/cves/kernel/CVE-2022-0487.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 89e3f366c5d998655c740702a9614ecc7f31c986 Mon Sep 17 00:00:00 2001 From: Nolan White Date: Mon, 6 Nov 2023 23:56:51 -0500 Subject: [PATCH 02/17] Answer questions for CVE-2022-0487 --- cves/kernel/CVE-2022-0487.yml | 121 ++++++++++++++++++---------------- 1 file changed, 65 insertions(+), 56 deletions(-) diff --git a/cves/kernel/CVE-2022-0487.yml b/cves/kernel/CVE-2022-0487.yml index 5e5fdbf80..08e09a843 100644 --- a/cves/kernel/CVE-2022-0487.yml +++ b/cves/kernel/CVE-2022-0487.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: '2022-01-11' 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: | + A use-after-free vulnerability was found in the Linux kernel’s + moxart_remove function in drivers/mmc/host/moxart-mmc.c. This flaw allows + a local attacker with a user privilege to create issues with confidentiality. + [IMPROVE THIS 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 @@ -84,14 +88,9 @@ fixes_instructions: | Place any notes you would like to make in the notes field. fixes: -- commit: - note: -- commit: - note: -- commit: 42933c8aa14be1caa9eda41f65cde8a3a95d3e39 +- commit: bd2db32e7c3e35bd4d9b8bbff689434a50893546 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. @@ -105,14 +104,8 @@ vcc_instructions: | Place any notes you would like to make in the notes field. vccs: -- commit: 99451dceeb5fdd789f0a2eeb3ee029e80d2ccc40 - note: Discovered automatically by archeogit. -- commit: 01a7e8e066a505933b43a8df6da1ae1a1e7bddf2 - note: Discovered automatically by archeogit. -- commit: 6827ca573c03385439fdfc8b512d556dc7c54fc9 - note: Discovered automatically by archeogit. -- commit: ba9d5f83735fc00297e39ba5cd9ece1c61eb3995 - note: Discovered automatically by archeogit. +- commit: 6b28f2c4da7e196062d84b143294cf6d86f6e02c + note: Manually confirmed. upvotes_instructions: | For the first round, ignore this upvotes number. @@ -135,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: false + code_answer: No automated tests were found in the surrounding directory. + fix: false + fix_answer: The fix only moved when the memory is freed. discovered: question: | How was this vulnerability discovered? @@ -153,10 +146,15 @@ discovered: If there is no evidence as to how this vulnerability was found, then please explain where you looked. - answer: - automated: - contest: - developer: + answer: | + Little information was given about the specifics of how this vulnerability + was discovered, but it was originally reported to SUSE Linux's security + from hackyzh002@gmail.com and credited Zhihua Yao of KunLun Lab. KunLun Lab + appears to be a service offered by Beijing CyberKunlun to help + organizations find, evaluate, and defend against software vulnerabilities. + automated: false + contest: false + developer: false autodiscoverable: instructions: | Is it plausible that a fully automated tool could have discovered @@ -173,8 +171,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 dynamic use-after-free (UAF) detector could have + been used to discover this vulnerability. Unlike a a static UAF detector, + a dynamic UAF is capable of discovering UAFs when the freeing of memory + occurs inside of different function the UAF. + answer: true specification: instructions: | Is there mention of a violation of a specification? For example, the POSIX @@ -190,8 +192,8 @@ specification: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: - answer: + note: No mention was made of a specification in the commit messages or other references. + answer: false subsystem: question: | What subsystems was the mistake in? These are WITHIN linux kernel @@ -225,8 +227,8 @@ subsystem: e.g. name: ["subsystemA", "subsystemB"] # ok name: subsystemA # also ok - name: - note: + name: drivers + note: Specifically, multimedia card host controller drivers. interesting_commits: question: | Are there any interesting commits between your VCC(s) and fix(es)? @@ -257,8 +259,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: | + This vulnerability only relates to the use of memory after it has been + freed. sandbox: question: | Did this vulnerability violate a sandboxing feature that the system @@ -272,8 +276,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: This vulnerability was in a device driver. ipc: question: | Did the feature that this vulnerability affected use inter-process @@ -284,8 +288,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 vulnerability existed in code for a device driver which was + communicating with hardware, not other processes. discussion: question: | Was there any discussion surrounding this? @@ -326,8 +332,10 @@ 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 authored by Greg Kroah-Hartman and signed off by him and Ulf + Hansson. stacktrace: question: | Are there any stacktraces in the bug reports? @@ -362,8 +370,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: false + note: The fix involved moving an existing line of code, not adding a check. order_of_operations: question: | Does the fix for the vulnerability involve correcting an order of @@ -375,8 +383,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 moves the freeing of memory to occur after the function is done + using it. lessons: question: | Are there any common lessons we have learned from class that apply to this @@ -393,37 +403,37 @@ 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: + applies: false note: least_privilege: - applies: + applies: false note: frameworks_are_optional: - applies: + applies: false note: native_wrappers: - applies: + applies: false note: distrust_input: - applies: + applies: false note: security_by_obscurity: - applies: + applies: false note: serial_killer: - applies: + applies: false note: environment_variables: - applies: + applies: false note: secure_by_default: - applies: + applies: false note: yagni: - applies: + applies: false note: complex_inputs: - applies: + applies: false note: mistakes: question: | @@ -473,8 +483,7 @@ CWE_instructions: | CWE: - 416 CWE_note: | - CWE as registered in the NVD. If you are curating, check that this - is correct and replace this comment with "Manually confirmed". + Manually confirmed. nickname_instructions: | A catchy name for this vulnerability that would draw attention it. If the report mentions a nickname, use that. From 77e8c791a47641db4b255c91af14d1b5efaf8568 Mon Sep 17 00:00:00 2001 From: Nolan White Date: Tue, 7 Nov 2023 00:17:27 -0500 Subject: [PATCH 03/17] Fill out stacktrace information for CVE-2022-0487 --- cves/kernel/CVE-2022-0487.yml | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/cves/kernel/CVE-2022-0487.yml b/cves/kernel/CVE-2022-0487.yml index 08e09a843..e057e0407 100644 --- a/cves/kernel/CVE-2022-0487.yml +++ b/cves/kernel/CVE-2022-0487.yml @@ -349,9 +349,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: false + stacktrace_with_fix: false + note: | + No discussions about this vulnerability in its bug reports included a + stacktrace. forgotten_check: question: | Does the fix for the vulnerability involve adding a forgotten check? From fe6f98752dc384279efd30777e7c56f9d63b5c35 Mon Sep 17 00:00:00 2001 From: Nolan White Date: Tue, 7 Nov 2023 18:47:40 -0500 Subject: [PATCH 04/17] Fill out description and discussion for CVE-2022-0487 --- cves/kernel/CVE-2022-0487.yml | 44 ++++++++++++++++++++++++++++------- 1 file changed, 36 insertions(+), 8 deletions(-) diff --git a/cves/kernel/CVE-2022-0487.yml b/cves/kernel/CVE-2022-0487.yml index e057e0407..dc9eea550 100644 --- a/cves/kernel/CVE-2022-0487.yml +++ b/cves/kernel/CVE-2022-0487.yml @@ -56,10 +56,23 @@ description_instructions: | Your target audience is people just like you before you took any course in security description: | - A use-after-free vulnerability was found in the Linux kernel’s - moxart_remove function in drivers/mmc/host/moxart-mmc.c. This flaw allows - a local attacker with a user privilege to create issues with confidentiality. - [IMPROVE THIS DESCRIPTION] + A vulnerability was found in the Linux kernel’s driver for MOXA ART + multimedia card readers where when disconnecting the card reader, data is + written to one of the device's hardware registers after the memory storing + the location of that hardware register was freed up to be used by other + programs. Since the memory for the hardware register's location has been + freed up for other programs to use, the data may be written somewhere + unintended. + + It was identified that an attacker with user privileges could use this + vulnerability to create issues with system confidentiality. No further + information was given on the specifics of the impact. + + A use-after-free vulnerability occurs + when a program releases memory that it was using back to the system + declaring that it is done using it, but then uses that memory again via an + old pointer to that memory address. This introduces a vulnerability because + that memory may already be in use by another program. 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 @@ -228,7 +241,7 @@ subsystem: name: ["subsystemA", "subsystemB"] # ok name: subsystemA # also ok name: drivers - note: Specifically, multimedia card host controller drivers. + note: Specifically, multimedia card reader (host controller) drivers. interesting_commits: question: | Are there any interesting commits between your VCC(s) and fix(es)? @@ -317,9 +330,24 @@ 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: | + There was some initial pushback against creating a CVE for this, but the + discussion never resolves in the comments so presumably it was resolved + in a private space. + + There was also some discussion about which versions of Linux were affected. + + Lastly, there was some confusion about whether this CVE referred to a UAF + vulnerability in the Realtek USB Memstick Card Interface driver or the + MOXA ART MMC host driver. It was determined that it was the latter, but + many places, including the National Vulnerability Database, still list + the former as the vulnerability. + + References: + https://bugzilla.suse.com/show_bug.cgi?id=1194516#c15 + https://bugzilla.redhat.com/show_bug.cgi?id=2044561 vouch: question: | Was there any part of the fix that involved one person vouching for From 5db83cfe92116674270323a508c3a1c27e90b550 Mon Sep 17 00:00:00 2001 From: Nolan White Date: Tue, 7 Nov 2023 19:29:22 -0500 Subject: [PATCH 05/17] Fill out mistakes and revise description for CVE-2022-0487 --- cves/kernel/CVE-2022-0487.yml | 28 +++++++++++++++------------- 1 file changed, 15 insertions(+), 13 deletions(-) diff --git a/cves/kernel/CVE-2022-0487.yml b/cves/kernel/CVE-2022-0487.yml index dc9eea550..854c8e6c1 100644 --- a/cves/kernel/CVE-2022-0487.yml +++ b/cves/kernel/CVE-2022-0487.yml @@ -58,21 +58,18 @@ description_instructions: | description: | A vulnerability was found in the Linux kernel’s driver for MOXA ART multimedia card readers where when disconnecting the card reader, data is - written to one of the device's hardware registers after the memory storing - the location of that hardware register was freed up to be used by other - programs. Since the memory for the hardware register's location has been - freed up for other programs to use, the data may be written somewhere - unintended. + read from and written to one of the device's hardware registers after the + memory storing the location of that hardware register is freed up to be + used by other programs. Since the memory for the hardware register's + location has been freed up for other programs to use, the data there may + not be what is expected and overwriting it could impact other programs. + This is known as a use-after-free (UAF) vulnerability. It was identified that an attacker with user privileges could use this vulnerability to create issues with system confidentiality. No further - information was given on the specifics of the impact. - - A use-after-free vulnerability occurs - when a program releases memory that it was using back to the system - declaring that it is done using it, but then uses that memory again via an - old pointer to that memory address. This introduces a vulnerability because - that memory may already be in use by another program. + information was given on the specifics of the impact, but perhaps there + was reason to believe that memory may contain sensitive data at the time + of use. 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 @@ -494,7 +491,12 @@ mistakes: Write a thoughtful entry here that people in the software engineering industry would find interesting. - answer: + answer: | + It seems that what led to this vulnerability was a slip in judgement when + freeing all of the data about the multimedia card reader. Looking at the + code, a portion of the multimedia card reader data is stored in a separate + variable that is implicitly freed by freeing all of the data, and the use + of that portion of the data is where the use-after-free occurs. 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 5b76a871611dd9d02e798cbc286d9e7ffa9ae937 Mon Sep 17 00:00:00 2001 From: Nolan White Date: Tue, 7 Nov 2023 23:08:54 -0500 Subject: [PATCH 06/17] Curate CVE-2013-2140 --- cves/kernel/CVE-2013-2140.yml | 165 +++++++++++++++++++++------------- 1 file changed, 102 insertions(+), 63 deletions(-) diff --git a/cves/kernel/CVE-2013-2140.yml b/cves/kernel/CVE-2013-2140.yml index 448a0a14a..413751ab3 100644 --- a/cves/kernel/CVE-2013-2140.yml +++ b/cves/kernel/CVE-2013-2140.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: '2013-06-05' 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,24 @@ description_instructions: | Your target audience is people just like you before you took any course in security -description: +description: | + A vulnerability was found in the Linux kernel's driver for Xen Project virtual + disks in which a guest user can erase arbitrary blocks of memory called "sectors" + on read only disks, causing data loss. + + The Xen Project is an open source project focused on running multiple operating + systems on the same hardware concurrently, and one part of how it accomplishes + this is allowing the definition of virtual disks that interface with the hardware + so each operating system does not have to. This also allows Xen to mediate each + operating system's access to the hardware through the virtual disks. + + The issue present in Linux's driver for these virtual disks was in the operation + for discarding or trimming sectors from the disk. Trimming in the context of disks + means the operating system informs the disk that specific sectors on the disk are + no longer being used and can be erased. The problem lied in the fact that this + operation did not check for the read only status of the disk before performing the + operation, so if an admin provided a guest user read only access to the disk, the + user could still use the discard operation to delete arbitrary data on the disk. bounty_instructions: | If you came across any indications that a bounty was paid out for this vulnerability, fill it out here. Or correct it if the information already here @@ -84,14 +101,9 @@ fixes_instructions: | Place any notes you would like to make in the notes field. fixes: -- commit: - note: -- commit: - note: - commit: 604c499cbbcc3d5fe5fb8d53306aa0fae1990109 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. @@ -106,11 +118,7 @@ vcc_instructions: | Place any notes you would like to make in the notes field. vccs: - commit: b3cb0d6adc4bbc70b5e37e49a6068e973545ead7 - note: Discovered automatically by archeogit. -- commit: 421463526fd1d8b5cb575baca12667c1005a110b - note: Discovered automatically by archeogit. -- commit: 4dae76705fc8f9854bb732f9944e7ff9ba7a8e9f - note: Discovered automatically by archeogit. + note: Manually confirmed. upvotes_instructions: | For the first round, ignore this upvotes number. @@ -133,10 +141,14 @@ unit_tested: For the fix_answer below, check if the fix for the vulnerability involves adding or improving an automated test to ensure this doesn't happen again. - code: - code_answer: - fix: - fix_answer: + code: false + code_answer: | + No automated tests were found in the code surrounding the fix. + fix: false + fix_answer: | + No automated tests were updated in this comming, but Konrad Wilk does + mention that he prepared a test-case. Unfortunately, no further information + on this test case could be found. discovered: question: | How was this vulnerability discovered? @@ -151,10 +163,16 @@ 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 originally discovered by Konrad Wilk, who also + introduced it when implementing the original function. There is no + description of how the vulnerability was discovered, but at that time Wilk + was the director of Xen, the project this driver is part of. Being more + involved with project requirements may have alerted him to this issue since + he wrote the function originally, but this is just speculation. + automated: false + contest: false + developer: true autodiscoverable: instructions: | Is it plausible that a fully automated tool could have discovered @@ -171,8 +189,8 @@ autodiscoverable: The answer field should be boolean. In answer_note, please explain why you come to that conclusion. - note: - answer: + note: This vulnerability was due to overlooking a domain-specific requirement. + answer: false specification: instructions: | Is there mention of a violation of a specification? For example, the POSIX @@ -188,8 +206,8 @@ 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 being violated. + answer: false subsystem: question: | What subsystems was the mistake in? These are WITHIN linux kernel @@ -223,8 +241,8 @@ subsystem: e.g. name: ["subsystemA", "subsystemB"] # ok name: subsystemA # also ok - name: - note: + name: drivers + note: Specifically, block device drivers (i.e. hard drives, SSDs, RAM). interesting_commits: question: | Are there any interesting commits between your VCC(s) and fix(es)? @@ -240,9 +258,10 @@ interesting_commits: * Anything else you find interesting. commits: - commit: - note: - - commit: - note: + note: | + There was nothing particularly interesting between the VCC and fix. It + seems that this was simply an overlooked or emerging requirement that + needed to be addressed. i18n: question: | Was the feature impacted by this vulnerability about internationalization @@ -255,8 +274,11 @@ i18n: Answer should be true or false Write a note about how you came to the conclusions you did, regardless of what your answer was. - answer: - note: + answer: false + note: | + The only input for the function the vulnerability is located in + is the sector number to start discarding from and the number of sectors + to discard. This does not relate to i18n. sandbox: question: | Did this vulnerability violate a sandboxing feature that the system @@ -270,8 +292,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 deals with a device driver, not a sandboxing + feature. ipc: question: | Did the feature that this vulnerability affected use inter-process @@ -282,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 vulnerability is in a driver that communicates with devices, not + processes. discussion: question: | Was there any discussion surrounding this? @@ -309,9 +335,11 @@ 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: | + No significant discussion was found. The issue was reported, a fix was + provided, then the fix was accepted. vouch: question: | Was there any part of the fix that involved one person vouching for @@ -324,8 +352,10 @@ 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: | + Konrad Wilk implemented and committed the fix, and both Wilk and Greg + Kroah-Hartman signed off on the commit. stacktrace: question: | Are there any stacktraces in the bug reports? @@ -339,9 +369,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 found in any discussions about the vulnerability. forgotten_check: question: | Does the fix for the vulnerability involve adding a forgotten check? @@ -360,8 +391,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: | + It was not checked if the virtual block device was read only or if the + sectors were in bounds before discarding them. order_of_operations: question: | Does the fix for the vulnerability involve correcting an order of @@ -373,8 +406,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 only adds new checks on the request input. lessons: question: | Are there any common lessons we have learned from class that apply to this @@ -391,37 +424,40 @@ 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: + applies: false note: least_privilege: - applies: + applies: false note: frameworks_are_optional: - applies: + applies: false note: native_wrappers: - applies: + applies: false note: distrust_input: - applies: - note: + applies: true + note: | + The vulnerability occurred because the code assumed that the request to + discard sectors on the virtual block device would not occur on read only + devices and that it would only request to discard valid sectors. security_by_obscurity: - applies: + applies: false note: serial_killer: - applies: + applies: false note: environment_variables: - applies: + applies: false note: secure_by_default: - applies: + applies: false note: yagni: - applies: + applies: false note: complex_inputs: - applies: + applies: false note: mistakes: question: | @@ -452,7 +488,11 @@ mistakes: Write a thoughtful entry here that people in the software engineering industry would find interesting. - answer: + answer: | + It seems that this vulnerability was the result of overlooking error + paths. There was no evidence prior to the fix that the code was attempting + to prevent sectors being discarded on a read only device, nor was it + checking that the sectors being discarded actually existed. CWE_instructions: | Please go to http://cwe.mitre.org and find the most specific, appropriate CWE entry that describes your vulnerability. We recommend going to @@ -471,8 +511,7 @@ CWE_instructions: | CWE: - 20 CWE_note: | - CWE as registered in the NVD. If you are curating, check that this - is correct and replace this comment with "Manually confirmed". + Manually confirmed. nickname_instructions: | A catchy name for this vulnerability that would draw attention it. If the report mentions a nickname, use that. From 9d9774580bf2d05ee536c591d61da9fbf0e8b768 Mon Sep 17 00:00:00 2001 From: Nolan White Date: Tue, 7 Nov 2023 23:15:03 -0500 Subject: [PATCH 07/17] Update interesting commits section of CVE-2022-0487 --- cves/kernel/CVE-2022-0487.yml | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/cves/kernel/CVE-2022-0487.yml b/cves/kernel/CVE-2022-0487.yml index 854c8e6c1..959587765 100644 --- a/cves/kernel/CVE-2022-0487.yml +++ b/cves/kernel/CVE-2022-0487.yml @@ -254,9 +254,11 @@ interesting_commits: * Anything else you find interesting. commits: - commit: - note: - - commit: - note: + note: | + There were no particularly interesting commits between the VCC and fix. + This device driver was not updated frequently in that timeframe, and + resolving the vulnerability was quick and straightforward once it was + reported. i18n: question: | Was the feature impacted by this vulnerability about internationalization From 6675a479e70caa1058ccf5f99f2037feabaa9fdd Mon Sep 17 00:00:00 2001 From: Nolan White Date: Tue, 7 Nov 2023 23:20:01 -0500 Subject: [PATCH 08/17] Add nicknames for CVE-2022-0487 and CVE-2013-2140 --- cves/kernel/CVE-2013-2140.yml | 2 +- cves/kernel/CVE-2022-0487.yml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/cves/kernel/CVE-2013-2140.yml b/cves/kernel/CVE-2013-2140.yml index 413751ab3..51983b2ab 100644 --- a/cves/kernel/CVE-2013-2140.yml +++ b/cves/kernel/CVE-2013-2140.yml @@ -516,5 +516,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: Virtual Insanity CVSS: diff --git a/cves/kernel/CVE-2022-0487.yml b/cves/kernel/CVE-2022-0487.yml index 959587765..6e1b312ec 100644 --- a/cves/kernel/CVE-2022-0487.yml +++ b/cves/kernel/CVE-2022-0487.yml @@ -522,5 +522,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: Two-Face CVSS: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N From 62fceda8c51115c8e4ce14590fc177a7f2d865ae Mon Sep 17 00:00:00 2001 From: Nolan White Date: Wed, 8 Nov 2023 13:17:25 -0500 Subject: [PATCH 09/17] Improve some of the content and wording in CVE-2022-0487 --- cves/kernel/CVE-2022-0487.yml | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/cves/kernel/CVE-2022-0487.yml b/cves/kernel/CVE-2022-0487.yml index 6e1b312ec..4aa84153f 100644 --- a/cves/kernel/CVE-2022-0487.yml +++ b/cves/kernel/CVE-2022-0487.yml @@ -70,6 +70,10 @@ description: | information was given on the specifics of the impact, but perhaps there was reason to believe that memory may contain sensitive data at the time of use. + + There was some confusion about which vulnerability this CVE applied to, + so some sources may state it applies to a nearly identical UAF + vulnerability in Realtek USB Memstick Card Interface driver. 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 @@ -141,7 +145,7 @@ unit_tested: code: false code_answer: No automated tests were found in the surrounding directory. fix: false - fix_answer: The fix only moved when the memory is freed. + fix_answer: The fix only changes when the memory is freed. discovered: question: | How was this vulnerability discovered? @@ -184,8 +188,10 @@ autodiscoverable: note: | It is plausible that a dynamic use-after-free (UAF) detector could have been used to discover this vulnerability. Unlike a a static UAF detector, - a dynamic UAF is capable of discovering UAFs when the freeing of memory - occurs inside of different function the UAF. + which looks at the raw source code for a variable being used after it was + explicitly freed earlier in the procdeure, a dynamic UAF detector is capable + of discovering UAFs when the freeing of memory occurs in a different + procedure than the UAF. answer: true specification: instructions: | @@ -361,8 +367,8 @@ vouch: Write a note about how you came to the conclusions you did, regardless of what your answer was. answer: true note: | - It was authored by Greg Kroah-Hartman and signed off by him and Ulf - Hansson. + It was authored by Greg Kroah-Hartman and signed off by Kroah-Hartman and + Ulf Hansson. stacktrace: question: | Are there any stacktraces in the bug reports? From b26f874935b3ac5a6f888ed797dabd4800887f2e Mon Sep 17 00:00:00 2001 From: Nolan White Date: Tue, 14 Nov 2023 12:50:30 -0500 Subject: [PATCH 10/17] Revise CVE-2013-2140 discovery information --- cves/kernel/CVE-2013-2140.yml | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/cves/kernel/CVE-2013-2140.yml b/cves/kernel/CVE-2013-2140.yml index 51983b2ab..ed3a665dd 100644 --- a/cves/kernel/CVE-2013-2140.yml +++ b/cves/kernel/CVE-2013-2140.yml @@ -164,12 +164,13 @@ discovered: If there is no evidence as to how this vulnerability was found, then please explain where you looked. answer: | - The vulnerability was originally discovered by Konrad Wilk, who also - introduced it when implementing the original function. There is no - description of how the vulnerability was discovered, but at that time Wilk - was the director of Xen, the project this driver is part of. Being more - involved with project requirements may have alerted him to this issue since - he wrote the function originally, but this is just speculation. + The vulnerability was originally reported by Konrad Wilk on 2013-06-05, + the same developer who introduced it when implementing the original + function; however, after reviewing the emails exchanged in the intial + report, there is no description of how the vulnerability was discovered. + + References: + https://seclists.org/oss-sec/2013/q2/488 automated: false contest: false developer: true From d2dbabb53cd89cb595510c03d8464d8a07feeeff Mon Sep 17 00:00:00 2001 From: Nolan White Date: Tue, 14 Nov 2023 12:54:39 -0500 Subject: [PATCH 11/17] Fix typo in unit test information for CVE-2013-2140 --- cves/kernel/CVE-2013-2140.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cves/kernel/CVE-2013-2140.yml b/cves/kernel/CVE-2013-2140.yml index ed3a665dd..5224b9a8d 100644 --- a/cves/kernel/CVE-2013-2140.yml +++ b/cves/kernel/CVE-2013-2140.yml @@ -146,7 +146,7 @@ unit_tested: No automated tests were found in the code surrounding the fix. fix: false fix_answer: | - No automated tests were updated in this comming, but Konrad Wilk does + No automated tests were updated in this commit, but Konrad Wilk does mention that he prepared a test-case. Unfortunately, no further information on this test case could be found. discovered: From d77989f91fbf95cf3a40c3765c328717ab456df0 Mon Sep 17 00:00:00 2001 From: Nolan White Date: Tue, 14 Nov 2023 12:56:16 -0500 Subject: [PATCH 12/17] Replace "block device" with "disk" in CVE-2013-2140 --- cves/kernel/CVE-2013-2140.yml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/cves/kernel/CVE-2013-2140.yml b/cves/kernel/CVE-2013-2140.yml index 5224b9a8d..6e1660eb0 100644 --- a/cves/kernel/CVE-2013-2140.yml +++ b/cves/kernel/CVE-2013-2140.yml @@ -394,7 +394,7 @@ forgotten_check: what your answer was. answer: true note: | - It was not checked if the virtual block device was read only or if the + It was not checked if the virtual disk was read only or if the sectors were in bounds before discarding them. order_of_operations: question: | @@ -440,8 +440,8 @@ lessons: applies: true note: | The vulnerability occurred because the code assumed that the request to - discard sectors on the virtual block device would not occur on read only - devices and that it would only request to discard valid sectors. + discard sectors on the virtual disk would not occur on read only devices + and that it would only request to discard valid sectors. security_by_obscurity: applies: false note: From 411326c594c49cb50b6ba67e7e93db1109cc1769 Mon Sep 17 00:00:00 2001 From: Nolan White Date: Tue, 14 Nov 2023 13:21:45 -0500 Subject: [PATCH 13/17] Reword description for CVE-2013-2140 --- cves/kernel/CVE-2013-2140.yml | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/cves/kernel/CVE-2013-2140.yml b/cves/kernel/CVE-2013-2140.yml index 6e1660eb0..d03346e95 100644 --- a/cves/kernel/CVE-2013-2140.yml +++ b/cves/kernel/CVE-2013-2140.yml @@ -57,22 +57,24 @@ description_instructions: | security description: | A vulnerability was found in the Linux kernel's driver for Xen Project virtual - disks in which a guest user can erase arbitrary blocks of memory called "sectors" + disks in which a guest user could erase arbitrary blocks of memory called "sectors" on read only disks, causing data loss. The Xen Project is an open source project focused on running multiple operating - systems on the same hardware concurrently, and one part of how it accomplishes - this is allowing the definition of virtual disks that interface with the hardware - so each operating system does not have to. This also allows Xen to mediate each - operating system's access to the hardware through the virtual disks. + systems on the same hardware at the same time. One part of how it accomplishes + this is allowing the creation of virtual disks that interface with the physical + storage disks so that each operating system does not have to. Virtual disks also + allow Xen to mediate each operating system's access to the actual disks. The issue present in Linux's driver for these virtual disks was in the operation for discarding or trimming sectors from the disk. Trimming in the context of disks - means the operating system informs the disk that specific sectors on the disk are - no longer being used and can be erased. The problem lied in the fact that this - operation did not check for the read only status of the disk before performing the - operation, so if an admin provided a guest user read only access to the disk, the - user could still use the discard operation to delete arbitrary data on the disk. + is when the operating system informs the disk that specific sectors on it are + no longer being used and can be erased. The problem with this operation in this + driver was that it did not check for the read only status of the disk before + performing the operation. If an admin provided a guest user read only access + to the disk, the user could still use the discard operation to delete arbitrary + data on the actual disk. This could impact not only the operating system using + the virtual disk, but other operating systems using Xen to access the actual disk. 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 From f156e49e5ab9749c47c9033b27318543dbff0c25 Mon Sep 17 00:00:00 2001 From: Nolan White Date: Tue, 14 Nov 2023 13:23:13 -0500 Subject: [PATCH 14/17] Reword interesting commits comments for CVE-2013-2140 --- cves/kernel/CVE-2013-2140.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cves/kernel/CVE-2013-2140.yml b/cves/kernel/CVE-2013-2140.yml index d03346e95..95788d621 100644 --- a/cves/kernel/CVE-2013-2140.yml +++ b/cves/kernel/CVE-2013-2140.yml @@ -264,7 +264,7 @@ interesting_commits: note: | There was nothing particularly interesting between the VCC and fix. It seems that this was simply an overlooked or emerging requirement that - needed to be addressed. + was promptly addressed once discovered. i18n: question: | Was the feature impacted by this vulnerability about internationalization From cee3f5c9ad3d56d937993bc499ea168edb4aa6a8 Mon Sep 17 00:00:00 2001 From: Nolan White Date: Tue, 14 Nov 2023 13:31:27 -0500 Subject: [PATCH 15/17] Update upvotes for CVE-2013-2140 --- cves/kernel/CVE-2013-2140.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cves/kernel/CVE-2013-2140.yml b/cves/kernel/CVE-2013-2140.yml index 95788d621..16a545fe3 100644 --- a/cves/kernel/CVE-2013-2140.yml +++ b/cves/kernel/CVE-2013-2140.yml @@ -128,7 +128,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: | Were automated unit tests involved in this vulnerability? From 7e3563be79b72eb36ea9328beda59639a89b9c87 Mon Sep 17 00:00:00 2001 From: Nolan White Date: Tue, 14 Nov 2023 13:48:11 -0500 Subject: [PATCH 16/17] Add more detail to discovery information for CVE-2022-0487 --- cves/kernel/CVE-2022-0487.yml | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/cves/kernel/CVE-2022-0487.yml b/cves/kernel/CVE-2022-0487.yml index 4aa84153f..99d905b0b 100644 --- a/cves/kernel/CVE-2022-0487.yml +++ b/cves/kernel/CVE-2022-0487.yml @@ -163,9 +163,13 @@ discovered: answer: | Little information was given about the specifics of how this vulnerability was discovered, but it was originally reported to SUSE Linux's security - from hackyzh002@gmail.com and credited Zhihua Yao of KunLun Lab. KunLun Lab - appears to be a service offered by Beijing CyberKunlun to help - organizations find, evaluate, and defend against software vulnerabilities. + from hackyzh002@gmail.com on 2022-01-11 and credited Zhihua Yao of KunLun Lab. + KunLun Lab appears to be a third-party service offered by Beijing CyberKunlun + to help organizations find, evaluate, and defend against software vulnerabilities. + + References: + https://bugzilla.suse.com/show_bug.cgi?id=1194516 + https://www.cyberkl.com/en/index#laboratory automated: false contest: false developer: false From 1b67b06f2aefe14cdc11394bd7aa86ff6b51768a Mon Sep 17 00:00:00 2001 From: Nolan White Date: Fri, 17 Nov 2023 13:02:17 -0500 Subject: [PATCH 17/17] Update CVE-2013-2140 upvotes --- cves/kernel/CVE-2013-2140.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cves/kernel/CVE-2013-2140.yml b/cves/kernel/CVE-2013-2140.yml index 16a545fe3..667841a1d 100644 --- a/cves/kernel/CVE-2013-2140.yml +++ b/cves/kernel/CVE-2013-2140.yml @@ -128,7 +128,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: 4 +upvotes: 8 unit_tested: question: | Were automated unit tests involved in this vulnerability?