CVE-2022-0487 and CVE-2013-2140

cves/kernel/CVE-2013-2140.yml

@@ -19,14 +19,14 @@ curated_instructions: |
   This will enable additional editorial checks on this file to make sure you
   fill everything out properly. If you are a student, we cannot accept your work
   as finished unless curated is properly updated.
-curation_level: 0
+curation_level: 2
 reported_instructions: |
   What date was the vulnerability reported to the security team? Look at the
   security bulletins and bug reports. It is not necessarily the same day that
   the CVE was created.  Leave blank if no date is given.
 
   Please enter your date in YYYY-MM-DD format.
-reported_date:
+reported_date: '2013-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,26 @@ 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 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 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
+  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
@@ -84,14 +103,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,19 +120,15 @@ 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.
 
   For the second round of reviewing, you will be giving a certain amount of
   upvotes to each vulnerability you see. Your peers will tell you how
   interesting they think this vulnerability is, and you'll add that to the
   upvotes score on your branch.
-upvotes:
+upvotes: 8
 unit_tested:
   question: |
     Were automated unit tests involved in this vulnerability?
@@ -133,10 +143,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 commit, 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 +165,17 @@ discovered:
 
     If there is no evidence as to how this vulnerability was found, then please
     explain where you looked.
-  answer:
-  automated:
-  contest:
-  developer:
+  answer: |
+    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
 autodiscoverable:
   instructions: |
     Is it plausible that a fully automated tool could have discovered
@@ -171,8 +192,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 +209,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 +244,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 +261,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
+      was promptly addressed once discovered.
 i18n:
   question: |
     Was the feature impacted by this vulnerability about internationalization
@@ -255,8 +277,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 +295,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 +309,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 +338,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 +355,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 +372,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 +394,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 disk 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 +409,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 +427,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 disk 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 +491,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,11 +514,10 @@ 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.
   Must be under 30 characters. Optional.
-nickname:
+nickname: Virtual Insanity
 CVSS: