CVE-2013-3302 and CVE-2016-8630

cves/kernel/CVE-2013-3302.yml

@@ -19,26 +19,26 @@ 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-15"
 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.
 
   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-04-29'
+announced_date: "2013-04-29"
 published_instructions: |
   Is there a published fix or patch date for this vulnerability?
   Please enter your date in YYYY-MM-DD format.
-published_date: '2013-04-29'
+published_date: "2013-04-29"
 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 +55,13 @@ description_instructions: |
 
   Your target audience is people just like you before you took any course in
   security
-description:
+description: |
+  This CVE is a security issue in the Linux operating system's kernel. 
+  This issue allowed the Linux system to crash or stop working properly.
+  This issue is caused by a race condition where processes are competing 
+  for access for a resource that cannot be shared. If the respource is 
+  reached by two processes it can cause a crash from a NULL pointer 
+  dereference or potentially open the system up to other security issues.
 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 +90,10 @@ fixes_instructions: |
 
   Place any notes you would like to make in the notes field.
 fixes:
-- commit:
-  note:
-- commit:
-  note:
-- commit: ea702b80e0bbb2448e201472127288beb82ca2fe
-  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: ea702b80e0bbb2448e201472127288beb82ca2fe
+    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: |
   The vulnerability-contributing commits.
 
@@ -105,22 +107,22 @@ vcc_instructions: |
 
   Place any notes you would like to make in the notes field.
 vccs:
-- commit: 6f49f46b187df34539f1e5df2469b8a541897700
-  note: Discovered automatically by archeogit.
-- commit: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
-  note: Discovered automatically by archeogit.
-- commit: b8eed28375a43e1c9aaa9d15af2a052aae0d0725
-  note: Discovered automatically by archeogit.
-- commit: 3e84469d0101456caceffc6b22218a49017fcd3f
-  note: Discovered automatically by archeogit.
+  - commit: 6f49f46b187df34539f1e5df2469b8a541897700
+    note: Discovered automatically by archeogit.
+  - commit: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
+    note: Discovered automatically by archeogit.
+  - commit: b8eed28375a43e1c9aaa9d15af2a052aae0d0725
+    note: Discovered automatically by archeogit.
+  - commit: 3e84469d0101456caceffc6b22218a49017fcd3f
+    note: Discovered automatically by archeogit.
 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: 0
 unit_tested:
   question: |
     Were automated unit tests involved in this vulnerability?
@@ -135,10 +137,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: |
+    I was unable to find any unit tests for this module. It does not seem like
+    any automated tests were made to ensure this does not happen again.
+  fix: false
+  fix_answer: |
+    I was unable to find any unit tests for this module. It does not seem like
+    any automated tests were made to ensure this does not happen again.
 discovered:
   question: |
     How was this vulnerability discovered?
@@ -153,10 +159,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: |
+    The commit that fixed the vulnerability states the vulnerability was 
+    reported and tested by CAI Qian <caiqian@redhat.com> but no date is 
+    stated.
+  automated: false
+  contest: false
+  developer: true
 autodiscoverable:
   instructions: |
     Is it plausible that a fully automated tool could have discovered
@@ -173,8 +182,15 @@ autodiscoverable:
 
     The answer field should be boolean. In answer_note, please explain
     why you come to that conclusion.
-  note:
-  answer:
+  note: |
+    As the vulnerability was an example of race condition and NULL
+    pointer dereference, fuzzer tools, static analysis tools and Stress testing 
+    all could highlight potential issues when it comes to race conditions and NULL pointer
+    dereferences. Fuzzers can identify unexpected behavior caused by a race condtion as well as NULL pointer
+    dereferences. Static analysis tools can identify code paths that could lead
+    to race condtions and null pointer dereferences, and stress testing can highlight potential 
+    issues of race condtions by mimicing real-world scenerios and usages.
+  answer: true
 specification:
   instructions: |
     Is there mention of a violation of a specification? For example, the POSIX
@@ -190,8 +206,11 @@ specification:
 
     The answer field should be boolean. In answer_note, please explain
     why you come to that conclusion.
-  note:
-  answer:
+  note: |
+    In one of the bug reports they specify that the issue of the race condition
+    can cause NULL pointer dereferences as well as open the system up for other 
+    issues. (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-3302, https://www.openwall.com/lists/oss-security/2013/04/15/2)
+  answer: true
 subsystem:
   question: |
     What subsystems was the mistake in? These are WITHIN linux kernel
@@ -225,8 +244,10 @@ subsystem:
     e.g.
         name: ["subsystemA", "subsystemB"] # ok
         name: subsystemA # also ok
-  name:
-  note:
+  name: ["sf", "cifs"]
+  note: |
+    Looking at the file path on github. 
+    (https://github.com/torvalds/linux/commit/ea702b80e0bbb2448e201472127288beb82ca2fe)
 interesting_commits:
   question: |
     Are there any interesting commits between your VCC(s) and fix(es)?
@@ -241,10 +262,10 @@ interesting_commits:
       * Other commits that fixed a similar issue as this vulnerability
       * Anything else you find interesting.
   commits:
-  - commit:
-    note:
-  - commit:
-    note:
+    - commit:
+      note:
+    - commit:
+      note:
 i18n:
   question: |
     Was the feature impacted by this vulnerability about internationalization
@@ -257,8 +278,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 vulnerability does not relate to internationalization features in the
+    Linux kernel. The main vulnerability focuses on a race condition that can 
+    cause a failure in the system and open up to a NULL pointer dereference.
 sandbox:
   question: |
     Did this vulnerability violate a sandboxing feature that the system
@@ -272,8 +296,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 does not violate a sandboxing feature. The issue is only
+    due to a race condition that can cause a failure in the system and open up 
+    to a NULL pointer dereference.
 ipc:
   question: |
     Did the feature that this vulnerability affected use inter-process
@@ -284,8 +311,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 feature that this vulnerability is caused by is a race condition that
+    the ssocket is NULL when the system tries to connect. The code checks to see
+    if the ssocket is available too late causing it to fail.
 discussion:
   question: |
     Was there any discussion surrounding this?
@@ -311,9 +341,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: |
+    There are notes on the commit that fixes the issue but I could not find any 
+    discussion regarding the issues brought up. 
+    (https://github.com/torvalds/linux/commit/ea702b80e0bbb2448e201472127288beb82ca2fe)
 vouch:
   question: |
     Was there any part of the fix that involved one person vouching for
@@ -326,8 +359,11 @@ 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 commit that fixed the issue was signed off by Steve French <smfrench@gmail.com>,
+    on Dec 30th 2012 Commit ID: 
+    (ea702b80e0bbb2448e201472127288beb82ca2fe).
 stacktrace:
   question: |
     Are there any stacktraces in the bug reports?
@@ -341,9 +377,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: |
+    I checked the changelog and github commits and could not find a stacktrace.
 forgotten_check:
   question: |
     Does the fix for the vulnerability involve adding a forgotten check?
@@ -362,8 +399,12 @@ 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: |
+    Although this fix invloves a if statement. The correction to the issue was not
+    adding a missing check but to move the if statement to a better place where it
+    will check for a module to be NULL early instead of later where it could be too
+    late causing a race condition and potentially a NULL pointer dereference.
 order_of_operations:
   question: |
     Does the fix for the vulnerability involve correcting an order of
@@ -375,8 +416,12 @@ 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 for the vulnerability involves moving code around an if statement that
+    check to see if the ssocket is NULL. This null check according to the developer
+    that fixed the issue is happening too late. So the developer moved it from one 
+    section of the code to another to ensure this check happens earlier.
 lessons:
   question: |
     Are there any common lessons we have learned from class that apply to this
@@ -454,7 +499,21 @@ mistakes:
 
     Write a thoughtful entry here that people in the software engineering
     industry would find interesting.
-  answer:
+  answer: |
+    The mistake that caused this issue seems to be on misunderstanding of the
+    systems flow and how things interact inside. As well as a poorly designed
+    system that led to this issue. The developer (Jeff Layton 
+    <jlayton@redhat.com>) that fixed the issue says something simular to this, 
+    "In truth, this is a bit of a half-assed fix. The -ENOTSOCK error return 
+    here looks like it could bubble back up to userspace. The locking rules 
+    around the ssocket pointer are really unclear as well. There are cases 
+    where the ssocket pointer is changed without holding the srv_mutex, but 
+    I'm not clear whether there's a potential race here yet or not.
+
+    This code seems like it could benefit from some fundamental re-think of
+    how the socket handling should behave. Until then though, this patch
+    should at least fix the above oops in most cases."
+    (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ea702b80e0bbb2448e201472127288beb82ca2fe)
 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,13 +530,13 @@ CWE_instructions: |
     CWE: [123, 456]     # also ok
     CWE: 123            # also ok
 CWE:
-- 362
+  - ["362", "476"]
 CWE_note: |
   CWE as registered in the NVD. If you are curating, check that this
   is correct and replace this comment with "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: RaceCrash3302
 CVSS: