All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <ZPCcRD/zv/l80WWC@redhat.com>

diff --git a/a/1.txt b/N1/1.txt
index ed5068a..56f906a 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -21,7 +21,8 @@ In any case per our stated security policy, we do not consider TCG to
 be providing a security boundary between host and guest, and thus bugs
 in TCG aren't considered security flaws:
 
- https://www.qemu.org/docs/master/system/security.html#non-virtualization-use-case
+ https://www.qemu.org/docs/master/system/security.html#non-
+virtualization-use-case
 
 With regards,
 Daniel
@@ -29,3 +30,61 @@ Daniel
 |: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
 |: https://libvirt.org         -o-            https://fstop138.berrange.com :|
 |: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
+
+-- 
+You received this bug notification because you are a member of qemu-
+devel-ml, which is subscribed to QEMU.
+https://bugs.launchpad.net/bugs/1863025
+
+Title:
+  Use-after-free after flush in TCG accelerator
+
+Status in QEMU:
+  Fix Released
+
+Bug description:
+  I believe I found a UAF in TCG that can lead to a guest VM escape. The
+  security list informed me "This can not be treated as a security
+  issue." and to post it here. I am looking at the 4.2.0 source code.
+  The issue requires a race and I will try to describe it in terms of
+  three concurrent threads.
+
+  Thread A:
+
+  A1. qemu_tcg_cpu_thread_fn runs work loop
+  A2. qemu_wait_io_event => qemu_wait_io_event_common => process_queued_cpu_work
+  A3. start_exclusive critical section entered
+  A4. do_tb_flush is called, TB memory freed/re-allocated
+  A5. end_exclusive exits critical section
+
+  Thread B:
+
+  B1. qemu_tcg_cpu_thread_fn runs work loop
+  B2. tcg_cpu_exec => cpu_exec => tb_find => tb_gen_code
+  B3. tcg_tb_alloc obtains a new TB
+
+  Thread C:
+
+  C1. qemu_tcg_cpu_thread_fn runs work loop
+  C2. cpu_exec_step_atomic executes
+  C3. TB obtained with tb_lookup__cpu_state or tb_gen_code
+  C4. start_exclusive critical section entered
+  C5. cpu_tb_exec executes the TB code
+  C6. end_exclusive exits critical section
+
+  Consider the following sequence of events:
+    B2 => B3 => C3 (same TB as B2) => A3 => A4 (TB freed) => A5 => B2 =>
+    B3 (re-allocates TB from B2) => C4 => C5 (freed/reused TB now executing) => C6
+
+  In short, because thread C uses the TB in the critical section, there
+  is no guarantee that the pointer has not been "freed" (rather the
+  memory is marked as re-usable) and therefore a use-after-free occurs.
+
+  Since the TCG generated code can be in the same memory as the TB data
+  structure, it is possible for an attacker to overwrite the UAF pointer
+  with code generated from TCG. This can overwrite key pointer values
+  and could lead to code execution on the host outside of the TCG
+  sandbox.
+
+To manage notifications about this bug go to:
+https://bugs.launchpad.net/qemu/+bug/1863025/+subscriptions
diff --git a/a/content_digest b/N1/content_digest
index 641d5c6..a58c03c 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -1,14 +1,8 @@
  "ref\0158154486735.14935.3370403781300872079.malonedeb@soybean.canonical.com\0"
- "ref\0169348611423.1472917.10027704436078423318.malone@juju-98d295-prod-launchpad-3\0"
- "ref\0cb2807f0-fc7d-fc03-376e-09c3d5f10a7f@linaro.org\0"
- "From\0Daniel P. Berrang\303\251 <berrange@redhat.com>\0"
+ "From\0Daniel Berrange <1863025@bugs.launchpad.net>\0"
  "Subject\0Re: [Bug 1863025] Re: Use-after-free after flush in TCG accelerator\0"
- "Date\0Thu, 31 Aug 2023 14:57:24 +0100\0"
- "To\0Philippe Mathieu-Daud\303\251 <philmd@linaro.org>\0"
- "Cc\0Bug 1863025 <1863025@bugs.launchpad.net>"
-  qemu-devel@nongnu.org
-  Michael Tokarev <mjt@tls.msk.ru>
- " Mauro Matteo Cascella <mcascell@redhat.com>\0"
+ "Date\0Thu, 31 Aug 2023 13:57:24 -0000\0"
+ "To\0qemu-devel@nongnu.org\0"
  "\00:1\0"
  "b\0"
  "On Thu, Aug 31, 2023 at 03:40:25PM +0200, Philippe Mathieu-Daud\303\251 wrote:\n"
@@ -34,13 +28,72 @@
  "be providing a security boundary between host and guest, and thus bugs\n"
  "in TCG aren't considered security flaws:\n"
  "\n"
- " https://www.qemu.org/docs/master/system/security.html#non-virtualization-use-case\n"
+ " https://www.qemu.org/docs/master/system/security.html#non-\n"
+ "virtualization-use-case\n"
  "\n"
  "With regards,\n"
  "Daniel\n"
  "-- \n"
  "|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|\n"
  "|: https://libvirt.org         -o-            https://fstop138.berrange.com :|\n"
- |: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
+ "|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|\n"
+ "\n"
+ "-- \n"
+ "You received this bug notification because you are a member of qemu-\n"
+ "devel-ml, which is subscribed to QEMU.\n"
+ "https://bugs.launchpad.net/bugs/1863025\n"
+ "\n"
+ "Title:\n"
+ "  Use-after-free after flush in TCG accelerator\n"
+ "\n"
+ "Status in QEMU:\n"
+ "  Fix Released\n"
+ "\n"
+ "Bug description:\n"
+ "  I believe I found a UAF in TCG that can lead to a guest VM escape. The\n"
+ "  security list informed me \"This can not be treated as a security\n"
+ "  issue.\" and to post it here. I am looking at the 4.2.0 source code.\n"
+ "  The issue requires a race and I will try to describe it in terms of\n"
+ "  three concurrent threads.\n"
+ "\n"
+ "  Thread A:\n"
+ "\n"
+ "  A1. qemu_tcg_cpu_thread_fn runs work loop\n"
+ "  A2. qemu_wait_io_event => qemu_wait_io_event_common => process_queued_cpu_work\n"
+ "  A3. start_exclusive critical section entered\n"
+ "  A4. do_tb_flush is called, TB memory freed/re-allocated\n"
+ "  A5. end_exclusive exits critical section\n"
+ "\n"
+ "  Thread B:\n"
+ "\n"
+ "  B1. qemu_tcg_cpu_thread_fn runs work loop\n"
+ "  B2. tcg_cpu_exec => cpu_exec => tb_find => tb_gen_code\n"
+ "  B3. tcg_tb_alloc obtains a new TB\n"
+ "\n"
+ "  Thread C:\n"
+ "\n"
+ "  C1. qemu_tcg_cpu_thread_fn runs work loop\n"
+ "  C2. cpu_exec_step_atomic executes\n"
+ "  C3. TB obtained with tb_lookup__cpu_state or tb_gen_code\n"
+ "  C4. start_exclusive critical section entered\n"
+ "  C5. cpu_tb_exec executes the TB code\n"
+ "  C6. end_exclusive exits critical section\n"
+ "\n"
+ "  Consider the following sequence of events:\n"
+ "  \302\240\302\240B2 => B3 => C3 (same TB as B2) => A3 => A4 (TB freed) => A5 => B2 =>\n"
+ "  \302\240\302\240B3 (re-allocates TB from B2) => C4 => C5 (freed/reused TB now executing) => C6\n"
+ "\n"
+ "  In short, because thread C uses the TB in the critical section, there\n"
+ "  is no guarantee that the pointer has not been \"freed\" (rather the\n"
+ "  memory is marked as re-usable) and therefore a use-after-free occurs.\n"
+ "\n"
+ "  Since the TCG generated code can be in the same memory as the TB data\n"
+ "  structure, it is possible for an attacker to overwrite the UAF pointer\n"
+ "  with code generated from TCG. This can overwrite key pointer values\n"
+ "  and could lead to code execution on the host outside of the TCG\n"
+ "  sandbox.\n"
+ "\n"
+ "To manage notifications about this bug go to:\n"
+ https://bugs.launchpad.net/qemu/+bug/1863025/+subscriptions
 
-2edf53388f1a9b61d37600c323333b3e92847c73af0e7f3647fb458031dcbd17
+0f0ba4e56dd507b34823ba8c662f42e12fc1cca0dd2384b708afac83b0782f87

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.