Branch: refs/heads/staging-9.1
  Home:   https://github.com/qemu/qemu
  Commit: 09537fbd34736f39b49bce805e04dc6f12d7ce89
      
https://github.com/qemu/qemu/commit/09537fbd34736f39b49bce805e04dc6f12d7ce89
  Author: Peter Maydell <[email protected]>
  Date:   2025-01-29 (Wed, 29 Jan 2025)

  Changed paths:
    M target/arm/helper.c

  Log Message:
  -----------
  target/arm: arm_reset_sve_state() should set FPSR, not FPCR

The pseudocode ResetSVEState() does:
    FPSR = ZeroExtend(0x0800009f<31:0>, 64);
but QEMU's arm_reset_sve_state() called vfp_set_fpcr() by accident.

Before the advent of FEAT_AFP, this was only setting a collection of
RES0 bits, which vfp_set_fpsr() would then ignore, so the only effect
was that we didn't actually set the FPSR the way we are supposed to
do.  Once FEAT_AFP is implemented, setting the bottom bits of FPSR
will change the floating point behaviour.

Call vfp_set_fpsr(), as we ought to.

(Note for stable backports: commit 7f2a01e7368f9 moved this function
from sme_helper.c to helper.c, but it had the same bug before the
move too.)

Cc: [email protected]
Fixes: f84734b87461 ("target/arm: Implement SMSTART, SMSTOP")
Signed-off-by: Peter Maydell <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Message-id: [email protected]
(cherry picked from commit 1edc3d43f20df0d04f8d00b906ba19fed37512a5)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 3b0234c9503628f59384d08f7591474b98a7780d
      
https://github.com/qemu/qemu/commit/3b0234c9503628f59384d08f7591474b98a7780d
  Author: Hongren Zheng <[email protected]>
  Date:   2025-01-29 (Wed, 29 Jan 2025)

  Changed paths:
    M hw/usb/canokey.c
    M hw/usb/canokey.h

  Log Message:
  -----------
  hw/usb/canokey: Fix buffer overflow for OUT packet

When USBPacket in OUT direction has larger payload
than the ep_out_buffer (of size 512), a buffer overflow
would occur.

It could be fixed by limiting the size of usb_packet_copy
to be at most buffer size. Further optimization gets rid
of the ep_out_buffer and directly uses ep_out as the target
buffer.

This is reported by a security researcher who artificially
constructed an OUT packet of size 2047. The report has gone
through the QEMU security process, and as this device is for
testing purpose and no deployment of it in virtualization
environment is observed, it is triaged not to be a security bug.

Cc: [email protected]
Fixes: d7d34918551dc48 ("hw/usb: Add CanoKey Implementation")
Reported-by: Juan Jose Lopez Jaimez <[email protected]>
Signed-off-by: Hongren Zheng <[email protected]>
Message-id: Z4TfMOrZz6IQYl_h@Sun
Reviewed-by: Peter Maydell <[email protected]>
Signed-off-by: Peter Maydell <[email protected]>
(cherry picked from commit 664280abddcb3cacc9c6204706bb739fcc1316f7)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 21406429cbea86dca58fdaf0e3f10cf3fab99397
      
https://github.com/qemu/qemu/commit/21406429cbea86dca58fdaf0e3f10cf3fab99397
  Author: Steve Sistare <[email protected]>
  Date:   2025-02-01 (Sat, 01 Feb 2025)

  Changed paths:
    M system/physmem.c

  Log Message:
  -----------
  physmem: fix qemu_ram_alloc_from_fd size calculation

qemu_ram_alloc_from_fd allocates space if file_size == 0.  If non-zero,
it uses the existing space and verifies it is large enough, but the
verification was broken when the offset parameter was introduced.  As
a result, a file smaller than offset passes the verification and causes
errors later.  Fix that, and update the error message to include offset.

Peter provides this concise reproducer:

  $ touch ramfile
  $ truncate -s 64M ramfile
  $ ./qemu-system-x86_64 -object 
memory-backend-file,mem-path=./ramfile,offset=128M,size=128M,id=mem1,prealloc=on
  qemu-system-x86_64: qemu_prealloc_mem: preallocating memory failed: Bad 
address

With the fix, the error message is:
  qemu-system-x86_64: mem1 backing store size 0x4000000 is too small for 'size' 
option 0x8000000 plus 'offset' option 0x8000000

Cc: [email protected]
Fixes: 4b870dc4d0c0 ("hostmem-file: add offset option")
Signed-off-by: Steve Sistare <[email protected]>
Reviewed-by: Peter Xu <[email protected]>
Acked-by: David Hildenbrand <[email protected]>
Link: 
https://lore.kernel.org/r/[email protected]
Signed-off-by: Fabiano Rosas <[email protected]>
(cherry picked from commit 719168fba7c3215cc996dcfd32a6e5e9c7b8eee0)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 89cc037912c4802bde844420f8c4cc6db7ef61c9
      
https://github.com/qemu/qemu/commit/89cc037912c4802bde844420f8c4cc6db7ef61c9
  Author: Ilya Leoshkevich <[email protected]>
  Date:   2025-02-01 (Sat, 01 Feb 2025)

  Changed paths:
    M target/s390x/tcg/mem_helper.c

  Log Message:
  -----------
  target/s390x: Fix MVC not always invalidating translation blocks

Node.js crashes in qemu-system-s390x with random SIGSEGVs / SIGILLs.

The v8 JIT used by Node.js can garbage collect and overwrite unused
code. Overwriting is performed by WritableJitAllocation::CopyCode(),
which ultimately calls memcpy(). For certain sizes, memcpy() uses the
MVC instruction.

QEMU implements MVC and other similar instructions using helpers. While
TCG store ops invalidate affected translation blocks automatically,
helpers must do this manually by calling probe_access_flags(). The MVC
helper does this using the access_prepare() -> access_prepare_nf() ->
s390_probe_access() -> probe_access_flags() call chain.

At the last step of this chain, the store size is replaced with 0. This
causes the probe_access_flags() -> notdirty_write() ->
tb_invalidate_phys_range_fast() chain to miss some translation blocks.

When this happens, QEMU executes a mix of old and new code. This
quickly leads to either a SIGSEGV or a SIGILL in case the old code
ends in the middle of a new instruction.

Fix by passing the true size.

Reported-by: Berthold Gunreben <[email protected]>
Cc: Sarah Kriesch <[email protected]>
Cc: [email protected]
Closes: https://bugzilla.opensuse.org/show_bug.cgi?id=1235709
Signed-off-by: Ilya Leoshkevich <[email protected]>
Reviewed-by: Richard Henderson <[email protected]>
Reviewed-by: David Hildenbrand <[email protected]>
Fixes: e2faabee78ff ("accel/tcg: Forward probe size on to notdirty_write")
Message-ID: <[email protected]>
Signed-off-by: Thomas Huth <[email protected]>
(cherry picked from commit e43ced8be18dda77c229ab09f85136a4d600d40d)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 01d03bafcd0f6a66e1abb59696afd2fb3ee81d27
      
https://github.com/qemu/qemu/commit/01d03bafcd0f6a66e1abb59696afd2fb3ee81d27
  Author: Laurent Vivier <[email protected]>
  Date:   2025-02-01 (Sat, 01 Feb 2025)

  Changed paths:
    M net/net.c

  Log Message:
  -----------
  net: Fix announce_self

b9ad513e1876 ("net: Remove receive_raw()") adds an iovec entry
in qemu_deliver_packet_iov() to add the virtio-net header
in the data when QEMU_NET_PACKET_FLAG_RAW is set but forgets
to increase the number of iovec entries in the array, so
receive_iov() will only send the first entry (the virtio-net
entry, full of 0) and no data. The packet will be discarded.

The only user of QEMU_NET_PACKET_FLAG_RAW is announce_self.

We can see the problem with tcpdump:

- QEMU parameters:

  .. -monitor stdio \
     -netdev bridge,id=netdev0,br=virbr0 \
     -device virtio-net,mac=9a:2b:2c:2d:2e:2f,netdev=netdev0 \

- HMP command:

  (qemu) announce_self

- TCP dump:

  $ sudo tcpdump -nxi virbr0

  without the fix:

    <nothing>

  with the fix:

   ARP, Reverse Request who-is 9a:2b:2c:2d:2e:2f tell 9a:2b:2c:2d:2e:2f, length 
46
        0x0000:  0001 0800 0604 0003 9a2b 2c2d 2e2f 0000
        0x0010:  0000 9a2b 2c2d 2e2f 0000 0000 0000 0000
        0x0020:  0000 0000 0000 0000 0000 0000 0000

Reported-by: Xiaohui Li <[email protected]>
Bug: https://issues.redhat.com/browse/RHEL-73891
Fixes: b9ad513e1876 ("net: Remove receive_raw()")
Cc: [email protected]
Signed-off-by: Laurent Vivier <[email protected]>
Reviewed-by: Akihiko Odaki <[email protected]>
Reviewed-by: Michael Tokarev <[email protected]>
Signed-off-by: Michael Tokarev <[email protected]>
(cherry picked from commit 84dfdcbff33fff185528501be408c25c44499f32)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 4cbe76b9523d354b6594b9e77981a6c6815cdce8
      
https://github.com/qemu/qemu/commit/4cbe76b9523d354b6594b9e77981a6c6815cdce8
  Author: Laurent Vivier <[email protected]>
  Date:   2025-02-01 (Sat, 01 Feb 2025)

  Changed paths:
    M net/dump.c

  Log Message:
  -----------
  net/dump: Correctly compute Ethernet packet offset

When a packet is sent with QEMU_NET_PACKET_FLAG_RAW by QEMU it
never includes virtio-net header even if qemu_get_vnet_hdr_len()
is not 0, and filter-dump is not managing this case.

The only user of QEMU_NET_PACKET_FLAG_RAW is announce_self,
we can show the problem using it and tcpddump:

- QEMU parameters:

  .. -monitor stdio \
     -netdev bridge,id=netdev0,br=virbr0 \
     -device virtio-net,mac=9a:2b:2c:2d:2e:2f,netdev=netdev0 \
     -object filter-dump,netdev=netdev0,file=log.pcap,id=pcap0

- HMP command:

  (qemu) announce_self

- TCP dump:

  $ tcpdump -nxr log.pcap

  without the fix:

    08:00:06:04:00:03 > 2e:2f:80:35:00:01, ethertype Unknown (0x9a2b), length 
50:
         0x0000:  2c2d 2e2f 0000 0000 9a2b 2c2d 2e2f 0000
         0x0010:  0000 0000 0000 0000 0000 0000 0000 0000
         0x0020:  0000 0000

  with the fix:

    ARP, Reverse Request who-is 9a:2b:2c:2d:2e:2f tell 9a:2b:2c:2d:2e:2f, 
length 46
         0x0000:  0001 0800 0604 0003 9a2b 2c2d 2e2f 0000
         0x0010:  0000 9a2b 2c2d 2e2f 0000 0000 0000 0000
         0x0020:  0000 0000 0000 0000 0000 0000 0000

Fixes: 481c52320a26 ("net: Strip virtio-net header when dumping")
Cc: [email protected]
Signed-off-by: Laurent Vivier <[email protected]>
Reviewed-by: Akihiko Odaki <[email protected]>
Reviewed-by: Michael Tokarev <[email protected]>
Signed-off-by: Michael Tokarev <[email protected]>
(cherry picked from commit c6a1b591a68b4d7230d6c3f56965e18080d737e5)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 104c686f46803f89140006f34d89df2995e32a60
      
https://github.com/qemu/qemu/commit/104c686f46803f89140006f34d89df2995e32a60
  Author: Dominik 'Disconnect3d' Czarnota <[email protected]>
  Date:   2025-02-01 (Sat, 01 Feb 2025)

  Changed paths:
    M gdbstub/user-target.c

  Log Message:
  -----------
  gdbstub/user-target: fix gdbserver int format (%d -> %x)

This commit fixes an incorrect format string for formatting integers
provided to GDB when debugging a target run in QEMU user mode.

The correct format is hexadecimal for both success and errno values,
some of which can be seen here [0].

[0] 
https://github.com/bminor/binutils-gdb/blob/e65a355022d0dc6b5707310876a72b5693ec0aa5/gdbserver/hostio.cc#L196-L213

Signed-off-by: Dominik 'Disconnect3d' Czarnota <[email protected]>
Reviewed-by: Alex BennĂ©e <[email protected]>
Fixes: e282010b2e1e ("gdbstub: Add support for info proc mappings")
Cc: [email protected]
Reviewed-by: Ilya Leoshkevich <[email protected]>
Reviewed-by: Michael Tokarev <[email protected]>
Signed-off-by: Michael Tokarev <[email protected]>
(cherry picked from commit 8b647bd352505234cab2acd2422aba183a1aa1fd)
Signed-off-by: Michael Tokarev <[email protected]>


Compare: https://github.com/qemu/qemu/compare/7594c49b9545...104c686f4680

To unsubscribe from these emails, change your notification settings at 
https://github.com/qemu/qemu/settings/notifications

Reply via email to