CVE-2012-6545 and CVE-2014-2851

cves/kernel/CVE-2012-6545.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
@@ -34,7 +34,7 @@ announced_instructions: |
   This is not the same as published date in the NVD - that is below.
 
   Please enter your date in YYYY-MM-DD format.
-announced_date: '2013-03-15'
+announced_date: '2013-03-05'
 published_instructions: |
   Is there a published fix or patch date for this vulnerability?
   Please enter your date in YYYY-MM-DD format.
@@ -55,7 +55,8 @@ description_instructions: |
 
   Your target audience is people just like you before you took any course in
   security
-description:
+description: |
+  Some memory was not being initialized correctly, which meant the memory was being leaked. A well thought out program could use this to read sensitive information.
 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,22 +85,12 @@ fixes_instructions: |
 
   Place any notes you would like to make in the notes field.
 fixes:
-- commit:
-  note:
-- commit:
-  note:
 - commit: 9344a972961d1a6d2c04d9008b13617bcb6ec2ef
-  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'
 - commit: f9432c5ec8b1e9a09b9b0e5569e3c73db8de432a
-  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'
 - commit: 9ad2de43f1aee7e7274a4e0d41465489299e344b
-  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.
 
@@ -143,10 +134,12 @@ 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 tests found.
+  fix: false
+  fix_answer: |
+    No tests found.
 discovered:
   question: |
     How was this vulnerability discovered?
@@ -161,10 +154,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: |
+    It seems this was a minor memory leak discovered and fixed by a developer. 
+    The only written history on this are the git commits, and this email sent 
+    by the developer who fixed it: https://www.openwall.com/lists/oss-security/2013/03/05/13. 
+    It was small enough to go unreported for some years.
+  automated: false
+  contest: false
+  developer: true
 autodiscoverable:
   instructions: |
     Is it plausible that a fully automated tool could have discovered
@@ -181,8 +178,11 @@ autodiscoverable:
 
     The answer field should be boolean. In answer_note, please explain
     why you come to that conclusion.
-  note:
-  answer:
+  note: |
+    This was a simple memory leak, so some kind of memory leak discoverer could 
+    have found this. Some code review tools might have been able to pick up on the 
+    missed memory allocation as well.
+  answer: true
 specification:
   instructions: |
     Is there mention of a violation of a specification? For example, the POSIX
@@ -198,8 +198,9 @@ specification:
 
     The answer field should be boolean. In answer_note, please explain
     why you come to that conclusion.
-  note:
-  answer:
+  note: |
+    No specific specifications were mentioned in any documentation.
+  answer: false
 subsystem:
   question: |
     What subsystems was the mistake in? These are WITHIN linux kernel
@@ -233,8 +234,9 @@ subsystem:
     e.g.
         name: ["subsystemA", "subsystemB"] # ok
         name: subsystemA # also ok
-  name:
-  note:
+  name: ['drivers', 'bluetooth']
+  note: |
+    This mistake dealt with connecting to bluetooth.
 interesting_commits:
   question: |
     Are there any interesting commits between your VCC(s) and fix(es)?
@@ -265,8 +267,9 @@ i18n:
     Answer should be true or false
     Write a note about how you came to the conclusions you did, regardless of
     what your answer was.
-  answer:
-  note:
+  answer: false
+  note: |
+    There was no note of internationalization, and this problem had little to no connection to user-language input.
 sandbox:
   question: |
     Did this vulnerability violate a sandboxing feature that the system
@@ -280,8 +283,9 @@ sandbox:
     Answer should be true or false
     Write a note about how you came to the conclusions you did, regardless of
     what your answer was.
-  answer:
-  note:
+  answer: false
+  note: |
+    This mistake was extremely low level.
 ipc:
   question: |
     Did the feature that this vulnerability affected use inter-process
@@ -292,8 +296,9 @@ ipc:
     Answer must be true or false.
     Write a note about how you came to the conclusions you did, regardless of
     what your answer was.
-  answer:
-  note:
+  answer: false
+  note: |
+    This mistake was extremely low level. It dealt with memory management.
 discussion:
   question: |
     Was there any discussion surrounding this?
@@ -319,9 +324,10 @@ discussion:
 
     Put any links to disagreements you found in the notes section, or any other
     comment you want to make.
-  discussed_as_security:
-  any_discussion:
-  note:
+  discussed_as_security: false
+  any_discussion: false
+  note: |
+    The fix went through quite silently.
 vouch:
   question: |
     Was there any part of the fix that involved one person vouching for
@@ -334,8 +340,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: false
+  note: |
+    The only correspondence between two people were questions regarding publishing 
+    the mistake as a CVE.
 stacktrace:
   question: |
     Are there any stacktraces in the bug reports?
@@ -349,9 +357,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: |
+    The fix went unnoticed for many years.
 forgotten_check:
   question: |
     Does the fix for the vulnerability involve adding a forgotten check?
@@ -370,8 +379,9 @@ forgotten_check:
     Answer must be true or false.
     Write a note about how you came to the conclusions you did, regardless of
     what your answer was.
-  answer:
-  note:
+  answer: true
+  note: |
+    The fix was just making sure the memory was set and accounted for.
 order_of_operations:
   question: |
     Does the fix for the vulnerability involve correcting an order of
@@ -383,8 +393,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: |
+    Things were still done in the same order as before the fix.
 lessons:
   question: |
     Are there any common lessons we have learned from class that apply to this
@@ -401,37 +412,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: |
@@ -462,7 +473,9 @@ mistakes:
 
     Write a thoughtful entry here that people in the software engineering
     industry would find interesting.
-  answer:
+  answer: |
+    The main mistake here was mismanaging memory. If the developer can make 
+    sure their memory is accounted for, and there are no leaks, they should be ok.
 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
@@ -480,9 +493,7 @@ CWE_instructions: |
     CWE: 123            # also ok
 CWE:
 - 200
-CWE_note: |
-  CWE as registered in the NVD. If you are curating, check that this
-  is correct and replace this comment with "Manually confirmed".
+CWE_note: 'Manually confirmed'
 nickname_instructions: |
   A catchy name for this vulnerability that would draw attention it.
   If the report mentions a nickname, use that.