CVE-2013-7348 and CVE-2022-3105

CVE-2013-7348.yml

@@ -0,0 +1,375 @@
+CVE: CVE-2013-7348
+CWE:
+  - 399
+ipc:
+  note: There are no commands within that function that utilizes signals, pipes, message passing, or standard input/output
+  answer: False
+  question: |
+    Did the feature that this vulnerability affected use inter-process
+    communication? IPC includes OS signals, pipes, stdin/stdout, message
+    passing, and clipboard. Writing to files that another program in this
+    software system reads is another form of 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.
+CVSS: 4.6
+bugs: []
+i18n:
+  note: Internationalization pertains to user interfaces and input with different languages and characters. This function does not process user input. However, it does perform i/o functions on files.
+  answer: False
+  question: |
+    Was the feature impacted by this vulnerability about internationalization
+    (i18n)?
+
+    An internationalization feature is one that enables people from all
+    over the world to use the system. This includes translations, locales,
+    typography, unicode, or various other features.
+
+    Answer should be true or false
+    Write a note about how you came to the conclusions you did, regardless of
+    what your answer was.
+vccs:
+  - note: Discovered automatically by archeogit.
+    commit: e23754f880f10124f0a2848f9d17e361a295378e
+fixes:
+  - note: Add locking of q->sysfs_lock into elevator_change() (an exported function) to ensure it is held to protect q->elevator from elevator_init(), even if elevator_change() is called from non-sysfs paths. sysfs path (elv_iosched_store) uses __elevator_change(), non-locking version, as the lock is already taken by elv_iosched_store().
+    commit: 7c8a3679e3d8e9d92d58f282161760a0e247df97
+  - note: This fixes Report Descriptor for Logitech MOMO Force. By default the Logitech MOMO Force (Black) presents a combined accel/brake axis ('Y'). This patch modifies the HID descriptor to present seperate accel/brake axes ('Y' and 'Z').
+    commit: 348cbaa800f8161168b20f85f72abb541c145132
+  - note: Manually confirmed
+    commit: d558023207e008a4476a3b7bb8706b2a2bf5d84f
+vouch:
+  note: While scrolling through kernel.org, there are many commits that consist of upstreams commits with members signing off on, and acknowledging other commits.
+  answer: True
+  question: >
+    Was there any part of the fix that involved one person vouching for another's work?
+
+
+    This can include:
+      * signing off on a commit message
+      * mentioning a discussion with a colleague checking the work
+      * upvoting a solution on a pull request
+
+    Answer must be true or false.
+
+    Write a note about how you came to the conclusions you did, regardless of what your answer was.
+bounty:
+  amt:
+  url:
+  announced:
+lessons:
+  yagni:
+    note: Input sanitization and error handling apply to this vulnerability, because with these practices, the risk posed by this vulnerability could be mitigated.
+    applies: True
+  question: |
+    Are there any common lessons we have learned from class that apply to this
+    vulnerability? In other words, could this vulnerability serve as an example
+    of one of those lessons?
+
+    Leave "applies" blank or put false if you did not see that lesson (you do
+    not need to put a reason). Put "true" if you feel the lesson applies and put
+    a quick explanation of how it applies.
+
+    Don't feel the need to claim that ALL of these apply, but it's pretty likely
+    that one or two of them apply.
+
+    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.
+  serial_killer:
+    note:
+    applies: False
+  complex_inputs:
+    note:
+    applies: True
+  distrust_input:
+    note:
+    applies: True
+  least_privilege:
+    note:
+    applies: False
+  native_wrappers:
+    note:
+    applies: False
+  defense_in_depth:
+    note:
+    applies: False
+  secure_by_default:
+    note:
+    applies: False
+  environment_variables:
+    note:
+    applies: False
+  security_by_obscurity:
+    note:
+    applies: False
+  frameworks_are_optional:
+    note:
+    applies: False
+reviews: []
+sandbox:
+  note: If a threat actor gained control over the kernel, the vulnerability could be exploited to escape a sandbox. This could allow privilege escalation, resource access, and path traversal.
+  answer: True
+  question: |
+    Did this vulnerability violate a sandboxing feature that the system
+    provides?
+
+    A sandboxing feature is one that allows files, users, or other features
+    limited access. Vulnerabilities that violate sandboxes are usually based on
+    access control, checking privileges incorrectly, path traversal, and the
+    like.
+
+    Answer should be true or false
+    Write a note about how you came to the conclusions you did, regardless of
+    what your answer was.
+upvotes: 0
+CWE_note: |
+  CWE as registered in the NVD. If you are curating, check that this
+  is correct and replace this comment with "Manually confirmed".
+mistakes:
+  answer: The vulnerability described in CVE-2013-7348 may have arisen from a combination of coding mistakes, design flaws, and shortcomings in error handling. In this case, the code related to asynchronous I/O (AIO) operations within the Linux kernel may have lacked robust resource management, leading to memory corruption and potential privilege escalation. Coding mistakes, such as improper memory allocation and deallocation, could have played a role, as well as complex code that made it harder to identify vulnerabilities. Additionally, design flaws in the implementation of AIO and resource allocation might have contributed to the issue. Testing gaps and a potential lack of comprehensive security testing could have allowed the vulnerability to go undetected. Adequate documentation, clear security requirements, and heightened security awareness among developers and reviewers are essential in mitigating such vulnerabilities and maintaining robust security in software systems.
+
+  question: |
+    In your opinion, after all of this research, what mistakes were made that
+    led to this vulnerability? Coding mistakes? Design mistakes?
+    Maintainability? Requirements? Miscommunications?
+
+    There can, and usually are, many mistakes behind a vulnerability.
+
+    Remember that mistakes can come in many forms:
+    * slip: failing to complete a properly planned step due to inattention
+              e.g. wrong key in the ignition
+              e.g. using < instead of <=
+    * lapse: failing to complete a properly planned step due to memory failure
+              e.g. forgetting to put car in reverse before backing up
+              e.g. forgetting to check null
+    * planning error: error that occurs when the plan is inadequate
+              e.g. getting stuck in traffic because you didn't consider the
+                   impact of the bridge closing
+              e.g. calling the wrong method
+              e.g. using a poor design
+
+    These are grey areas, of course. But do your best to analyze the mistakes
+    according to this framework.
+
+    Look at the CWE entry for this vulnerability and examine the mitigations
+    they have written there. Are they doing those? Does the fix look proper?
+
+    Write a thoughtful entry here that people in the software engineering
+    industry would find interesting.
+nickname:
+subsystem:
+  name: fs
+  note: This vulnerability involves asynchronous I/O (AIO) implementation, which deals with file I/O operations and resource management. Issues related to file I/O, memory allocation, and resource management are typically associated with the "fs" subsystem, as it deals with the file system operations and related kernel functionality.
+  question: >
+    What subsystems was the mistake in? These are WITHIN linux kernel
+
+
+    Determining the subsystem is a subjective task. This is to help us group
+     similar vulnerabilities, so choose a subsystem that other vulnerabilities would be in. Y
+
+    Some areas to look for pertinent information:
+      - Bug labels
+      - Directory names
+      - How developers refer to an area of the system in comments,
+        commit messages, etc.
+
+    Look at the path of the source code files code that were fixed to get
+
+    directory names. Look at comments in the code. Look at the bug reports how
+
+    the bug report was tagged.
+
+
+    Example linux kernel subsystems are:
+      * drivers
+      * crypto
+      * fs
+      * net
+      * lib
+
+    Name should be:
+      * all lowercase English letters
+      * NOT a specific file
+      * can have digits, and _-@/
+
+    Can be multiple subsystems involved, in which case you can make it an array
+
+    e.g.
+        name: ["subsystemA", "subsystemB"] # ok
+        name: subsystemA # also ok
+discovered:
+  answer: After looking through kernel.org, openwall.com, and github, I wasn't able to find any evidence as to how this vulnerability was found. 
+  contest: nil
+  question: |
+    How was this vulnerability discovered?
+
+    Go to the bug report and read the conversation to find out how this was
+    originally found. Answer in longform below in "answer", fill in the date in
+    YYYY-MM-DD, and then determine if the vulnerability was found by a Google
+    employee (you can tell from their email address). If it's clear that the
+    vulenrability was discovered by a contest, fill in the name there.
+
+    The automated, contest, and developer flags can be true, false, or nil.
+
+    If there is no evidence as to how this vulnerability was found, then please
+    explain where you looked.
+  automated: nil
+  developer: nil
+discussion:
+  note: https://mirrors.edge.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.0.10
+  question: |
+   How was this vulnerability discovered?
+
+    Go to the bug report and read the conversation to find out how this was
+    originally found. Answer in longform below in "answer", fill in the date in
+    YYYY-MM-DD, and then determine if the vulnerability was found by a Google
+    employee (you can tell from their email address). If it's clear that the
+    vulenrability was discovered by a contest, fill in the name there.
+
+
+    Example include:
+      * Is this out of our scope?
+      * Is this a security?
+      * How should we fix this?
+
+    Just because you see multiple comments doesn't mean it's a discussion.
+    For example:
+      * "Fix line 10". "Ok" is not what we call a discussion
+      * "Ping" (reminding people)
+
+    Check the bugs reports, pull requests, and mailing lists archives.
+
+    These answers should be boolean.
+      discussed_as_security: true or false
+      any_discussion: true or false
+
+    Put any links to disagreements you found in the notes section, or any other
+    comment you want to make.
+  any_discussion: True
+  discussed_as_security: True
+stacktrace:
+  note:
+  question: |
+    Are there any stacktraces in the bug reports?
+
+    Secondly, if there is a stacktrace, is the fix in the same file that the
+    stacktrace points to?
+
+    If there are no stacktraces, then both of these are false - but be sure to
+    mention where you checked in the note.
+
+    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:
+description:
+unit_tested:
+  fix:
+  code:
+  question: |
+    Were automated unit tests involved in this vulnerability?
+    Was the original code unit tested, or not unit tested? Did the fix involve
+    improving the automated tests?
+
+    For code: and fix: - your answer should be boolean.
+
+    For the code_answer below, look not only at the fix but the surrounding
+    code near the fix in related directories and determine if and was there were
+    unit tests involved for this subsystem.
+
+    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.
+  fix_answer:
+  code_answer:
+reported_date:
+specification:
+  note:
+  answer:
+  instructions: |
+    Is there mention of a violation of a specification? For example, the POSIX
+    spec, an RFC spec, a network protocol spec, or some other requirements
+    specification.
+
+    Be sure to check the following artifacts for this:
+      * bug reports
+      * security advisories
+      * commit message
+      * mailing lists
+      * anything else
+
+    The answer field should be boolean. In answer_note, please explain
+    why you come to that conclusion.
+announced_date: 2014-04-01
+curation_level: 2
+published_date: 2014-04-01
+forgotten_check:
+  note:
+  answer:
+  question: |
+    Does the fix for the vulnerability involve adding a forgotten check?
+
+    A "forgotten check" can mean many things. It often manifests as the fix
+    inserting an entire if-statement or a conditional to an existing
+    if-statement. Or a call to a method that checks something.
+
+    Example of checks can include:
+      * null pointer checks
+      * check the current role, e.g. root
+      * boundary checks for a number
+      * consult file permissions
+      * check a return value
+
+    Answer must be true or false.
+    Write a note about how you came to the conclusions you did, regardless of
+    what your answer was.
+autodiscoverable:
+  note:
+  answer:
+  instructions: |
+    Is it plausible that a fully automated tool could have discovered
+    this? These are tools that require little knowledge of the domain,
+     e.g. automatic static analysis, compiler warnings, fuzzers.
+
+    Examples for true answers: SQL injection, XSS, buffer overflow
+
+    In systemd, the actually use OZZ Fuzz. If there's a link to it, add it here.
+
+    Examples for false: RFC violations, permissions issues, anything
+    that requires the tool to be "aware" of the project's
+    domain-specific requirements.
+
+    The answer field should be boolean. In answer_note, please explain
+    why you come to that conclusion.
+interesting_commits:
+  commits:
+    - note:
+      commit:
+    - note:
+      commit:
+  question: |
+    Are there any interesting commits between your VCC(s) and fix(es)?
+
+    Use this to specify any commits you think are notable in some way, and
+    explain why in the note.
+
+    Example interesting commits:
+      * Mentioned as a problematic commit in the past
+        e.g. "This fixes regression in commit xys"
+      * A significant rewrite in the git history
+      * Other commits that fixed a similar issue as this vulnerability
+      * Anything else you find interesting.
+order_of_operations:
+  note: The fix involves error handling. It does not include include moving the code.
+  answer: False
+  question: |
+    Does the fix for the vulnerability involve correcting an order of
+    operations?
+
+    This means the fix involves moving code around or changing the order of
+    how things are done.
+
+    Answer must be true or false.
+    Write a note about how you came to the conclusions you did, regardless of
+    what your answer was.