Add CVE-2013-3228 and CVE-2020-10768

cves/kernel/CVE-2013-3228.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-04-07'
 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: |
+  In the IR subsystem of the Linux kernel (IrDA), a function responsible for receiving messages
+  was affected by an information leak. The message variable's length property needed to be reset to 0.
+  Missing this value reset enabled an information leak where a small part of protected kernel memory
+  could be read, possibly enabling the disclosure of sensative system 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
@@ -75,7 +79,7 @@ bugs_instructions: |
     * Mentioned in mailing list discussions
     * References from NVD entry
     * Various other places
-bugs: []
+bugs: ['https://bugzilla.redhat.com/show_bug.cgi?id=956069']
 fixes_instructions: |
   Please put the commit hash in "commit" below.
 
@@ -84,15 +88,11 @@ fixes_instructions: |
 
   Place any notes you would like to make in the notes field.
 fixes:
-- commit:
-  note:
-- commit:
-  note:
+- commit: f89e8a6432409c6cbd5c2b6bb90ea694fd558de3
+  note: "Fix is merged along with the branch of similar information leak fixes."
 - commit: 5ae94c0d2f0bed41d6718be743985d61b7f5c47d
-  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'
-vcc_instructions: |
+  note: "Initial fixing commit, manually confirmed."
+vccs_instructions: |
   The vulnerability-contributing commits.
 
   These are found by our tools by traversing the Git Blame history, where we
@@ -105,18 +105,19 @@ vcc_instructions: |
 
   Place any notes you would like to make in the notes field.
 vccs:
-- commit: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
-  note: Discovered automatically by archeogit.
 - commit: 0dc47877a3de00ceadea0005189656ae8dc52669
-  note: Discovered automatically by archeogit.
+  note: |
+    Manually confirmed. This makes a patch closeby while skipping over this
+    vulnerability. Note that the vulnerability existed in the kernel for the
+    lifetime of the IrDA module.
 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: 2
 unit_tested:
   question: |
     Were automated unit tests involved in this vulnerability?
@@ -131,10 +132,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: |
+    This aspect of the original code was not unit tested.
+  fix: false
+  fix_answer: |
+    The fix did not involve adding an automated test for related issues.
 discovered:
   question: |
     How was this vulnerability discovered?
@@ -149,10 +152,12 @@ discovered:
 
     If there is no evidence as to how this vulnerability was found, then please
     explain where you looked.
-  answer:
-  automated:
-  contest:
-  developer:
+  answer: 'Many protocols including the IrDA protocol shared a similar
+    receive message function, each one with the same information leak
+    vulnerability. These were discovered together.'
+  automated: false
+  contest: false
+  developer: false
 autodiscoverable:
   instructions: |
     Is it plausible that a fully automated tool could have discovered
@@ -169,8 +174,10 @@ autodiscoverable:
 
     The answer field should be boolean. In answer_note, please explain
     why you come to that conclusion.
-  note:
-  answer:
+  note: |
+    This vulnerability involves reading from an unassigned function parameter
+    value, so a fuzzer could likely have discovered it.
+  answer: true
 specification:
   instructions: |
     Is there mention of a violation of a specification? For example, the POSIX
@@ -186,8 +193,10 @@ specification:
 
     The answer field should be boolean. In answer_note, please explain
     why you come to that conclusion.
-  note:
-  answer:
+  note: |
+    There was no formal specification or documentation surrounding the use of
+    the msg variable and the need to explicitly clear the affected attribute.
+  answer: false
 subsystem:
   question: |
     What subsystems was the mistake in? These are WITHIN linux kernel
@@ -221,8 +230,10 @@ subsystem:
     e.g.
         name: ["subsystemA", "subsystemB"] # ok
         name: subsystemA # also ok
-  name:
-  note:
+  name: net
+  note: |
+    IrDA contains drivers for infrared sensors, and is a subsystem of the kernel's
+    networking (net) subsystem
 interesting_commits:
   question: |
     Are there any interesting commits between your VCC(s) and fix(es)?
@@ -237,10 +248,10 @@ interesting_commits:
       * Other commits that fixed a similar issue as this vulnerability
       * Anything else you find interesting.
   commits:
-  - commit:
-    note:
-  - commit:
-    note:
+  - commit: 0dc47877a3de00ceadea0005189656ae8dc52669
+    note: |
+      This was a significant rewrite of the file containing the vulnerability
+      written in 2008. The vulnerability was not affected by this rewrite.
 i18n:
   question: |
     Was the feature impacted by this vulnerability about internationalization
@@ -253,8 +264,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: |
+    The messages being received are not read for text data, so i18n shouldn't
+    be an issue.
 sandbox:
   question: |
     Did this vulnerability violate a sandboxing feature that the system
@@ -268,8 +281,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: true
+  note: |
+    This vulnerability allowed for user space programs to read sensitive kernel
+    memory, which they should be unauthorized for. This violates fundemental
+    OS-level sandboxing.
 ipc:
   question: |
     Did the feature that this vulnerability affected use inter-process
@@ -280,8 +296,11 @@ ipc:
     Answer must be true or false.
     Write a note about how you came to the conclusions you did, regardless of
     what your answer was.
-  answer:
-  note:
+  answer: true
+  note: |
+    The affected function receives messages from external IR
+    connections, and delivers them to the operating system. It is part of a
+    subsystem enabling IPC as a driver.
 discussion:
   question: |
     Was there any discussion surrounding this?
@@ -307,9 +326,12 @@ discussion:
 
     Put any links to disagreements you found in the notes section, or any other
     comment you want to make.
-  discussed_as_security:
-  any_discussion:
-  note:
+  discussed_as_security: false
+  any_discussion: false
+  note: |
+    No discussion directly related to this vulnerability. A bug report
+    was filed that seemed to be causing crashes in an AWS instance, but
+    it was unclear if this crash was due to this vulnerability.
 vouch:
   question: |
     Was there any part of the fix that involved one person vouching for
@@ -322,8 +344,14 @@ 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 fixing commit was signed by the author, and the committer
+    who would have verified the fix and is vouching for it by
+    making the commit. Sameul Ortiz is also notified of the fix.
+    Cc: Samuel Ortiz <[email protected]>
+    Signed-off-by: Mathias Krause <[email protected]>
+    Signed-off-by: David S. Miller <[email protected]>
 stacktrace:
   question: |
     Are there any stacktraces in the bug reports?
@@ -337,9 +365,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: |
+    The connected bug on bugzilla seems disconnected, and also does not
+    contain any stacktraces.
 forgotten_check:
   question: |
     Does the fix for the vulnerability involve adding a forgotten check?
@@ -358,8 +388,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: false
+  note: |
+    A value needed to be set but there was no check involved.
 order_of_operations:
   question: |
     Does the fix for the vulnerability involve correcting an order of
@@ -371,8 +402,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 was a missing line of code, and rearranging the order of operations
+    was not involved.
 lessons:
   question: |
     Are there any common lessons we have learned from class that apply to this
@@ -389,38 +422,41 @@ 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:
-    note:
+    applies: true
+    note: |
+      The msg parameter contains a large number of attributes that may not be
+      initialized. Needing to handle these to prevent an information leak was
+      unclear initially.
 mistakes:
   question: |
     In your opinion, after all of this research, what mistakes were made that
@@ -450,7 +486,17 @@ mistakes:
 
     Write a thoughtful entry here that people in the software engineering
     industry would find interesting.
-  answer:
+  answer: |
+    This vulnerability is the result of a simple coding slip. An ambiguous
+    input meant it was unclear a particular value needed to be reset to 0.
+    Missing this value reset enabled an information leak with an unusual
+    attack vector that might not be considered during authoring or code reviewing
+    this file. Maybe with better/more accessible documentation of the details of
+    the ambiguous msg input, this would have been caught earlier. The fix is
+    simple and was able to be distributed to many affected protocols at once. Due
+    to the number of common protocols with the same vulnerability, it's possible
+    that copy-pasting was involved at some point and allowed for the proliferation
+    of this problem.
 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
@@ -469,11 +515,10 @@ CWE_instructions: |
 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".
+  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:
+nickname: 
+CVSS: 'AV:L/AC:L/Au:N/C:C/I:N/A:N'