summaryrefslogtreecommitdiffstats
path: root/meta/recipes-devtools/qemu/qemu/CVE-2018-19364_p1.patch
diff options
context:
space:
mode:
authorArmin Kuster <akuster@mvista.com>2019-05-29 11:14:38 -0700
committerRichard Purdie <richard.purdie@linuxfoundation.org>2019-07-27 18:05:18 +0100
commitf2961d88af7fa7345f40b1dc3b0edc926c5a2304 (patch)
tree60f354217ea7bdffa7cc9678ab64f65561408908 /meta/recipes-devtools/qemu/qemu/CVE-2018-19364_p1.patch
parentcd7f7bf38584be1df287e77e78bbdf659a07c385 (diff)
downloadpoky-f2961d88af7fa7345f40b1dc3b0edc926c5a2304.tar.gz
qemu: Several CVE fixes
Source: qemu.org MR: 97258, 97342, 97438, 97443 Type: Security Fix Disposition: Backport from git.qemu.org/qemu.git ChangeID: a5e9fd03ca5bebc880dcc3c4567e10a9ae47dba5 Description: These issues affect qemu < 3.1.0 Fixes: CVE-2018-16867 CVE-2018-16872 CVE-2018-18849 CVE-2018-19364 (From OE-Core rev: e3dfe53a334cd952cc2194fd3baad6d082659b7e) Signed-off-by: Armin Kuster <akuster@mvista.com> Signed-off-by: Armin Kuster <akuster808@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'meta/recipes-devtools/qemu/qemu/CVE-2018-19364_p1.patch')
-rw-r--r--meta/recipes-devtools/qemu/qemu/CVE-2018-19364_p1.patch51
1 files changed, 51 insertions, 0 deletions
diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2018-19364_p1.patch b/meta/recipes-devtools/qemu/qemu/CVE-2018-19364_p1.patch
new file mode 100644
index 0000000000..1d77af4e83
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2018-19364_p1.patch
@@ -0,0 +1,51 @@
1From 5b76ef50f62079a2389ba28cacaf6cce68b1a0ed Mon Sep 17 00:00:00 2001
2From: Greg Kurz <groug@kaod.org>
3Date: Wed, 7 Nov 2018 01:00:04 +0100
4Subject: [PATCH] 9p: write lock path in v9fs_co_open2()
5
6The assumption that the fid cannot be used by any other operation is
7wrong. At least, nothing prevents a misbehaving client to create a
8file with a given fid, and to pass this fid to some other operation
9at the same time (ie, without waiting for the response to the creation
10request). The call to v9fs_path_copy() performed by the worker thread
11after the file was created can race with any access to the fid path
12performed by some other thread. This causes use-after-free issues that
13can be detected by ASAN with a custom 9p client.
14
15Unlike other operations that only read the fid path, v9fs_co_open2()
16does modify it. It should hence take the write lock.
17
18Cc: P J P <ppandit@redhat.com>
19Reported-by: zhibin hu <noirfate@gmail.com>
20Signed-off-by: Greg Kurz <groug@kaod.org>
21
22Upstream-status: Backport
23Affects: < 3.1.0
24CVE: CVE-2018-19364 patch #1
25Signed-off-by: Armin Kuster <akuster@mvista.com>
26
27---
28 hw/9pfs/cofile.c | 6 +++---
29 1 file changed, 3 insertions(+), 3 deletions(-)
30
31diff --git a/hw/9pfs/cofile.c b/hw/9pfs/cofile.c
32index 88791bc..9c22837 100644
33--- a/hw/9pfs/cofile.c
34+++ b/hw/9pfs/cofile.c
35@@ -140,10 +140,10 @@ int coroutine_fn v9fs_co_open2(V9fsPDU *pdu, V9fsFidState *fidp,
36 cred.fc_gid = gid;
37 /*
38 * Hold the directory fid lock so that directory path name
39- * don't change. Read lock is fine because this fid cannot
40- * be used by any other operation.
41+ * don't change. Take the write lock to be sure this fid
42+ * cannot be used by another operation.
43 */
44- v9fs_path_read_lock(s);
45+ v9fs_path_write_lock(s);
46 v9fs_co_run_in_worker(
47 {
48 err = s->ops->open2(&s->ctx, &fidp->path,
49--
502.7.4
51