Skip to content

CVE-2013-7348 and CVE-2022-3105 #204

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 4 commits into
base: dev
Choose a base branch
from
Open

CVE-2013-7348 and CVE-2022-3105 #204

Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
27f7e34
added CVE's
as9215 Nov 2, 2023
d627464
trying again
as9215 Nov 2, 2023
96e01fe
CVE-2013-7348.yml
as9215 Nov 7, 2023
dd84faf
CVE-2022-3105.yml
as9215 Nov 7, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
95 changes: 47 additions & 48 deletions CVE-2013-7348.yml
View file
Open in desktop
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall, I agree with most of what the other commenters have added here. I'd make sure you add the description of the vulnerability as I don't actually know what it is. I'd recommend re-forking as the format of this file is different from the main repository and you're missing some key points. The answers seem to be before the questions and out of order.

Original file line number Diff line number Diff line change
Expand Up @@ -2,8 +2,8 @@ CVE: CVE-2013-7348
CWE:
- 399
ipc:
note:
answer:
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
Expand All @@ -13,11 +13,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.
CVSS:
CVSS: 4.6
bugs: []
i18n:
note:
answer:
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)?
Expand All @@ -33,22 +33,17 @@ vccs:
- note: Discovered automatically by archeogit.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe add a short explanation of what this commit is, as well as the others in the "fixes" section that just have "manually confirmed" in the note

commit: e23754f880f10124f0a2848f9d17e361a295378e
fixes:
- note:
commit:
- note:
commit:
- 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: 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:
answer:
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?
Was there any part of the fix that involved one person vouching for another's work?


This can include:
Expand All @@ -65,8 +60,8 @@ bounty:
announced:
lessons:
yagni:
note:
applies:
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
Expand All @@ -83,38 +78,38 @@ lessons:
free to give it a small name and add one in the same format as these.
serial_killer:
note:
applies:
applies: False
complex_inputs:
note:
applies:
applies: True
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Make sure to mention why this applies.
Same with distrust input.

distrust_input:
note:
applies:
applies: True
least_privilege:
note:
applies:
applies: False
native_wrappers:
note:
applies:
applies: False
defense_in_depth:
note:
applies:
applies: False
secure_by_default:
note:
applies:
applies: False
environment_variables:
note:
applies:
applies: False
security_by_obscurity:
note:
applies:
applies: False
frameworks_are_optional:
note:
applies:
applies: False
reviews: []
sandbox:
note:
answer:
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?
Expand All @@ -132,7 +127,8 @@ 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:
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?
Expand Down Expand Up @@ -163,8 +159,8 @@ mistakes:
industry would find interesting.
nickname:
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this goes hand in hand with the description, try to come up with something short and clever

subsystem:
name:
note:
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

Expand Down Expand Up @@ -203,8 +199,8 @@ subsystem:
name: ["subsystemA", "subsystemB"] # ok
name: subsystemA # also ok
discovered:
answer:
contest:
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?

Expand All @@ -218,15 +214,19 @@ discovered:

If there is no evidence as to how this vulnerability was found, then please
explain where you looked.
automated:
developer:
automated: nil
developer: nil
discussion:
note:
note: https://mirrors.edge.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.0.10
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A link is good, but I'd recommend also adding a short description.

question: |
Was there any discussion surrounding this?
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.

A discussion can include debates, disputes, or polite talk about how to
resolve uncertainty.

Example include:
* Is this out of our scope?
Expand All @@ -246,8 +246,8 @@ discussion:

Put any links to disagreements you found in the notes section, or any other
comment you want to make.
any_discussion:
discussed_as_security:
any_discussion: True
discussed_as_security: True
stacktrace:
note:
question: |
Expand Down Expand Up @@ -361,8 +361,8 @@ interesting_commits:
* Other commits that fixed a similar issue as this vulnerability
* Anything else you find interesting.
order_of_operations:
note:
answer:
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?
Expand All @@ -373,4 +373,3 @@ 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.