From: "Daniel Sangorrin" <daniel.sangorrin@toshiba.co.jp>
To: sz.lin@moxa.com, ben.hutchings@codethink.co.u, wens@csie.org
Cc: cip-dev@lists.cip-project.org
Subject: [cip-dev] [cip-kernel-sec 3/3] issues: fill in the description field of remaining CVEs
Date: Fri, 25 Sep 2020 12:59:27 +0900 [thread overview]
Message-ID: <20200925035927.1958987-4-daniel.sangorrin@toshiba.co.jp> (raw)
In-Reply-To: <20200925035927.1958987-1-daniel.sangorrin@toshiba.co.jp>
[-- Attachment #1: Type: text/plain, Size: 6404 bytes --]
From: nguyen van hieu <hieu2.nguyenvan@toshiba.co.jp>
I noticed that some issues have the description field empty
when using the --show-description option.
Signed-off-by: nguyen van hieu <hieu2.nguyenvan@toshiba.co.jp>
Signed-off-by: Daniel Sangorrin <daniel.sangorrin@toshiba.co.jp>
---
issues/CVE-2016-6213.yml | 5 ++++-
issues/CVE-2017-1000364.yml | 5 ++++-
issues/CVE-2017-1000365.yml | 6 +++++-
issues/CVE-2017-1000379.yml | 5 ++++-
issues/CVE-2017-16538.yml | 5 ++++-
issues/CVE-2019-15214.yml | 6 +++++-
issues/CVE-2019-20794.yml | 6 +++++-
issues/CVE-2020-11725.yml | 8 +++++++-
8 files changed, 38 insertions(+), 8 deletions(-)
diff --git a/issues/CVE-2016-6213.yml b/issues/CVE-2016-6213.yml
index 31762df..58bf472 100644
--- a/issues/CVE-2016-6213.yml
+++ b/issues/CVE-2016-6213.yml
@@ -1,4 +1,7 @@
-description: ''
+description: |-
+ fs/namespace.c in the Linux kernel before 4.9 does not restrict how many mounts may exist in a mount namespace,
+ which allows local users to cause a denial of service (memory consumption and deadlock) via MS_BIND mount system calls,
+ as demonstrated by a loop that triggers exponential growth in the number of mounts.
references:
- http://www.openwall.com/lists/oss-security/2016/07/13/6
- https://lkml.org/lkml/2016/8/28/269
diff --git a/issues/CVE-2017-1000364.yml b/issues/CVE-2017-1000364.yml
index 8841754..c566c5b 100644
--- a/issues/CVE-2017-1000364.yml
+++ b/issues/CVE-2017-1000364.yml
@@ -1,4 +1,7 @@
-description: ''
+description: |-
+ An issue was discovered in the size of the stack guard page on Linux, specifically a 4k stack guard
+ page is not sufficiently large and can be "jumped" over (the stack guard page is bypassed),
+ this affects Linux Kernel versions 4.11.5 and earlier (the stackguard page was introduced in 2010).
references:
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000364
- http://www.ubuntu.com/usn/usn-3324-1
diff --git a/issues/CVE-2017-1000365.yml b/issues/CVE-2017-1000365.yml
index 6cbae0b..f87ca53 100644
--- a/issues/CVE-2017-1000365.yml
+++ b/issues/CVE-2017-1000365.yml
@@ -1,4 +1,8 @@
-description: ''
+description: |-
+ The Linux Kernel imposes a size restriction on the arguments and environmental strings passed through
+ RLIMIT_STACK/RLIM_INFINITY (1/4 of the size), but does not take the argument and environment pointers
+ into account, which allows attackers to bypass this limitation. This affects Linux Kernel versions 4.11.5 and earlier.
+ It appears that this feature was introduced in the Linux Kernel version 2.6.23.
references:
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000365
- https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt
diff --git a/issues/CVE-2017-1000379.yml b/issues/CVE-2017-1000379.yml
index 93258d8..2ae11b1 100644
--- a/issues/CVE-2017-1000379.yml
+++ b/issues/CVE-2017-1000379.yml
@@ -1,4 +1,7 @@
-description: ''
+description: |-
+ The Linux Kernel running on AMD64 systems will sometimes map the contents of PIE executable,
+ the heap or ld.so to where the stack is mapped allowing attackers to more easily manipulate the stack.
+ Linux Kernel version 4.11.5 is affected.
references:
- https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000379
diff --git a/issues/CVE-2017-16538.yml b/issues/CVE-2017-16538.yml
index 793db3f..c466041 100644
--- a/issues/CVE-2017-16538.yml
+++ b/issues/CVE-2017-16538.yml
@@ -1,4 +1,7 @@
-description: ''
+description: |-
+ drivers/media/usb/dvb-usb-v2/lmedm04.c in the Linux kernel through 4.13.11 allows local users to cause a denial of service
+ (general protection fault and system crash) or possibly have unspecified other impact via a crafted USB device,
+ related to a missing warm-start check and incorrect attach timing (dm04_lme2510_frontend_attach versus dm04_lme2510_tuner).
references:
- https://patchwork.linuxtv.org/patch/44566/
- https://patchwork.linuxtv.org/patch/44567/
diff --git a/issues/CVE-2019-15214.yml b/issues/CVE-2019-15214.yml
index c92091b..cb6006d 100644
--- a/issues/CVE-2019-15214.yml
+++ b/issues/CVE-2019-15214.yml
@@ -1,4 +1,8 @@
-description: ''
+description: |-
+ An issue was discovered in the Linux kernel before 5.0.10.
+ There is a use-after-free in the sound subsystem because
+ card disconnection causes certain data structures to be deleted too early.
+ This is related to sound/core/init.c and sound/core/info.c.
references:
- https://syzkaller.appspot.com/bug?id=75903e0021cef79bc434d068b5169b599b2a46a9
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-15214
diff --git a/issues/CVE-2019-20794.yml b/issues/CVE-2019-20794.yml
index 43e3ccf..8f30e12 100644
--- a/issues/CVE-2019-20794.yml
+++ b/issues/CVE-2019-20794.yml
@@ -1,4 +1,8 @@
-description: ''
+description: |-
+ An issue was discovered in the Linux kernel 4.18 through 5.6.11 when unprivileged user namespaces are allowed.
+ A user can create their own PID namespace, and mount a FUSE filesystem. Upon interaction with this FUSE filesystem,
+ if the userspace component is terminated via a kill of the PID namespace's pid 1, it will result in a hung task,
+ and resources being permanently locked up until system reboot. This can result in resource exhaustion.
references:
- https://github.com/sargun/fuse-example
- https://sourceforge.net/p/fuse/mailman/message/36598753/
diff --git a/issues/CVE-2020-11725.yml b/issues/CVE-2020-11725.yml
index ca2b80d..3cae05d 100644
--- a/issues/CVE-2020-11725.yml
+++ b/issues/CVE-2020-11725.yml
@@ -1,4 +1,10 @@
-description: ''
+description: |-
+ ** DISPUTED ** snd_ctl_elem_add in sound/core/control.c in the Linux kernel through 5.6.3 has a count=info->owner line,
+ which later affects a private_size*count multiplication for unspecified "interesting side effects."
+ NOTE: kernel engineers dispute this finding, because it could be relevant only if new callers were added
+ that were unfamiliar with the misuse of the info->owner field to represent data unrelated to the "owner" concept.
+ The existing callers, SNDRV_CTL_IOCTL_ELEM_ADD and SNDRV_CTL_IOCTL_ELEM_REPLACE,
+ have been designed to misuse the info->owner field in a safe way.
references:
- https://twitter.com/yabbadabbadrew/status/1248632267028582400
- https://lore.kernel.org/alsa-devel/s5h4ktmlfpx.wl-tiwai@suse.de/
--
2.25.1
[-- Attachment #2: Type: text/plain, Size: 420 bytes --]
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5475): https://lists.cip-project.org/g/cip-dev/message/5475
Mute This Topic: https://lists.cip-project.org/mt/77073076/4520388
Group Owner: cip-dev+owner@lists.cip-project.org
Unsubscribe: https://lists.cip-project.org/g/cip-dev/leave/8129055/727948398/xyzzy [cip-dev@archiver.kernel.org]
-=-=-=-=-=-=-=-=-=-=-=-
next prev parent reply other threads:[~2020-09-25 4:00 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-25 3:59 [cip-dev] improve show-description results Daniel Sangorrin
2020-09-25 3:59 ` [cip-dev] [cip-kernel-sec 1/3] report_affected: word-wrap for the 'description' Daniel Sangorrin
2020-10-08 7:58 ` Chen-Yu Tsai (Moxa)
2020-09-25 3:59 ` [cip-dev] [cip-kernel-sec 2/3] report_affected: Delete extra blank lines between CVEs Daniel Sangorrin
2020-10-08 7:59 ` Chen-Yu Tsai (Moxa)
2020-10-08 8:00 ` Chen-Yu Tsai (Moxa)
2020-09-25 3:59 ` Daniel Sangorrin [this message]
2020-10-08 8:18 ` [cip-dev] [cip-kernel-sec 3/3] issues: fill in the description field of remaining CVEs Chen-Yu Tsai (Moxa)
2020-10-14 4:16 ` Daniel Sangorrin
2020-10-14 4:21 ` Chen-Yu Tsai (Moxa)
2020-09-30 3:29 ` [cip-dev] improve show-description results Chen-Yu Tsai (Moxa)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200925035927.1958987-4-daniel.sangorrin@toshiba.co.jp \
--to=daniel.sangorrin@toshiba.co.jp \
--cc=ben.hutchings@codethink.co.u \
--cc=cip-dev@lists.cip-project.org \
--cc=sz.lin@moxa.com \
--cc=wens@csie.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).