Skip to content
Snippets Groups Projects
  1. Nov 08, 2023
  2. Nov 07, 2023
  3. Oct 07, 2023
  4. Oct 04, 2023
  5. Oct 03, 2023
  6. Sep 08, 2023
  7. Jun 26, 2023
  8. May 16, 2023
  9. Apr 20, 2023
  10. Mar 22, 2023
  11. Mar 07, 2023
  12. Feb 27, 2023
  13. Feb 02, 2023
    • Emilio Cota's avatar
      cpu: free cpu->tb_jmp_cache with RCU · 4731f89b
      Emilio Cota authored
      
      Fixes the appended use-after-free. The root cause is that
      during tb invalidation we use CPU_FOREACH, and therefore
      to safely free a vCPU we must wait for an RCU grace period
      to elapse.
      
      $ x86_64-linux-user/qemu-x86_64 tests/tcg/x86_64-linux-user/munmap-pthread
      =================================================================
      ==1800604==ERROR: AddressSanitizer: heap-use-after-free on address 0x62d0005f7418 at pc 0x5593da6704eb bp 0x7f4961a7ac70 sp 0x7f4961a7ac60
      READ of size 8 at 0x62d0005f7418 thread T2
          #0 0x5593da6704ea in tb_jmp_cache_inval_tb ../accel/tcg/tb-maint.c:244
          #1 0x5593da6704ea in do_tb_phys_invalidate ../accel/tcg/tb-maint.c:290
          #2 0x5593da670631 in tb_phys_invalidate__locked ../accel/tcg/tb-maint.c:306
          #3 0x5593da670631 in tb_invalidate_phys_page_range__locked ../accel/tcg/tb-maint.c:542
          #4 0x5593da67106d in tb_invalidate_phys_range ../accel/tcg/tb-maint.c:614
          #5 0x5593da6a64d4 in target_munmap ../linux-user/mmap.c:766
          #6 0x5593da6dba05 in do_syscall1 ../linux-user/syscall.c:10105
          #7 0x5593da6f564c in do_syscall ../linux-user/syscall.c:13329
          #8 0x5593da49e80c in cpu_loop ../linux-user/x86_64/../i386/cpu_loop.c:233
          #9 0x5593da6be28c in clone_func ../linux-user/syscall.c:6633
          #10 0x7f496231cb42 in start_thread nptl/pthread_create.c:442
          #11 0x7f49623ae9ff  (/lib/x86_64-linux-gnu/libc.so.6+0x1269ff)
      
      0x62d0005f7418 is located 28696 bytes inside of 32768-byte region [0x62d0005f0400,0x62d0005f8400)
      freed by thread T148 here:
          #0 0x7f49627b6460 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:52
          #1 0x5593da5ac057 in cpu_exec_unrealizefn ../cpu.c:180
          #2 0x5593da81f851  (/home/cota/src/qemu/build/qemu-x86_64+0x484851)
      
      Signed-off-by: default avatarEmilio Cota <cota@braap.org>
      Reviewed-by: default avatarRichard Henderson <richard.henderson@linaro.org>
      Message-Id: <20230111151628.320011-2-cota@braap.org>
      Signed-off-by: default avatarAlex Bennée <alex.bennee@linaro.org>
      Message-Id: <20230124180127.1881110-27-alex.bennee@linaro.org>
      4731f89b
  14. Oct 31, 2022
  15. Oct 26, 2022
  16. Oct 04, 2022
  17. Apr 20, 2022
  18. Apr 06, 2022
  19. Mar 16, 2022
  20. Mar 06, 2022
  21. Feb 08, 2022
    • Peter Maydell's avatar
      cpu.c: Make start-powered-off settable after realize · 0c3c25fc
      Peter Maydell authored
      
      The CPU object's start-powered-off property is currently only
      settable before the CPU object is realized.  For arm machines this is
      awkward, because we would like to decide whether the CPU should be
      powered-off based on how we are booting the guest code, which is
      something done in the machine model code and in common code called by
      the machine model, which runs much later and in completely different
      parts of the codebase from the SoC object code that is responsible
      for creating and realizing the CPU objects.
      
      Allow start-powered-off to be set after realize.  Since this isn't
      something that's supported by the DEFINE_PROP_* macros, we have to
      switch the property definition to use the
      object_class_property_add_bool() function.
      
      Note that it doesn't conceptually make sense to change the setting of
      the property after the machine has been completely initialized,
      beacuse this would mean that the behaviour of the machine when first
      started would differ from its behaviour when the system is
      subsequently reset.  (It would also require the underlying state to
      be migrated, which we don't do.)
      
      Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      Reviewed-by: default avatarRichard Henderson <richard.henderson@linaro.org>
      Tested-by: default avatarEdgar E. Iglesias <edgar.iglesias@xilinx.com>
      Tested-by: default avatarCédric Le Goater <clg@kaod.org>
      Message-id: 20220127154639.2090164-3-peter.maydell@linaro.org
      0c3c25fc
  22. Jan 06, 2022
  23. Dec 18, 2021
  24. Oct 15, 2021
  25. Jul 21, 2021
  26. Jul 10, 2021
  27. May 26, 2021
Loading