-
Bug
-
Resolution: Done-Errata
-
Critical
-
rhel-9.4.z
-
None
-
qemu-kvm-8.2.0-11.el9_4.15
-
Yes
-
Moderate
-
7eeb62b0ce3a8f64647bf53f93903abd1fbb0b94
-
rhel-virt-networking
-
None
-
False
-
False
-
-
None
-
Red Hat Virtualization
-
None
-
Pass
-
RegressionOnly
-
Unspecified
-
Unspecified
-
Unspecified
-
x86_64
-
None
Note: this appears to be https://access.redhat.com/security/cve/CVE-2024-4693 / https://bugzilla.redhat.com/show_bug.cgi?id=2279965, but I've filled in all of the questions below for the sake of completeness.
What were you trying to do that didn't work?
Running Cisco's Firepower virtual firewall, with virtio-net-pci devices, marked in a disconnected state (i.e. the device was presented, but we intentionally did not "connect" the vnic to an actual network under the covers.
This worked in qemu 6.2.x, but fails with 8.2.0-11.el9_4.10
What is the impact of this issue to you?
Customers sometimes (for some reason unknown to us) want to be able to deploy this specific workload with some of the vnics in a "connected" state and some in a "disconnected" state. I believe this allows the user to "provision" virtual interfaces on their virtual firewall, and then "Connect" them to a "new" network to be provisioned in the future, without taking the virtual appliance down.
This would be similar to plugging in a new cable, for a new network, on a real physical firewall.
Please provide the package NVR for which the bug is seen:
qemu-kvm 8.2.0-11.el9_4.10
How reproducible is this bug?:
100% with the latest Cisco firepower image (Cisco_Secure_Firewall_Threat_Defense_Virtual-7.6.1-291.qcow2)
Steps to reproduce
- Deploy 4x vnic, 4x vcpu, 64G memory pc-type VM with Cisco_Secure_Firewall_Threat_Defense_Virtual-7.6.1-291.qcow2
- Wait for the VM to come up, which goes through the configuration stage. This takes many minutes to complete
- Once the VM is fully configured, shut down the VM, and virtually disconnect the one of the vNICs.
- When booting the VM back up, watch the console, and you'll see right before QEMU crashes that it is trying to start DPDK and bind to the interfaces.
- As soon as this happens, qemu will exit with status "shutting down, reason=crashed"
- stack trace (attached below) will fire into /var/log/messages
Expected results
VM does not crash from a guest-side operation
Actual results
QEMU crashes with the following stack trace:
Jul 07 20:05:08 Frisco-10-1 systemd-coredump[2679129]: Process 2675741 (qemu-kvm) of user 107 dumped core.
Stack trace of thread 2675768:
#0 0x000056518a5c2bc1 kvm_virtio_pci_vector_use_one (qemu-kvm)
#1 0x000056518a719278 memory_region_write_accessor (qemu-kvm)
#2 0x000056518a718cae access_with_adjusted_size (qemu-kvm)
#3 0x000056518a718f99 memory_region_dispatch_write (qemu-kvm)
#4 0x000056518a72280c flatview_write_continue (qemu-kvm)
#5 0x000056518a722963 flatview_write (qemu-kvm)
#6 0x000056518a723286 address_space_write (qemu-kvm)
#7 0x000056518a769926 kvm_cpu_exec (qemu-kvm)
#8 0x000056518a76a74d kvm_vcpu_thread_fn (qemu-kvm)
#9 0x000056518a954cb4 qemu_thread_start (qemu-kvm)
#10 0x00007f80630081ca start_thread (libpthread.so.0)
#11 0x00007f8062c398d3 __clone (libc.so.6)
Stack trace of thread 2675741:
#0 0x00007f8062d32bb6 ppoll (libc.so.6)
#1 0x000056518a969f55 qemu_poll_ns (qemu-kvm)
#2 0x000056518a967a15 main_loop_wait (qemu-kvm)
#3 0x000056518a5ebe99 qemu_main_loop (qemu-kvm)
#4 0x000056518a76f4ba qemu_default_main (qemu-kvm)
#5 0x00007f8062c3a7e5 __libc_start_main (libc.so.6)
#6 0x000056518a4bc14e _start (qemu-kvm)
Stack trace of thread 2675753:
#0 0x00007f8062c3941d syscall (libc.so.6)
#1 0x000056518a95562f qemu_event_wait (qemu-kvm)
#2 0x000056518a95f682 call_rcu_thread (qemu-kvm)
#3 0x000056518a954cb4 qemu_thread_start (qemu-kvm)
#4 0x00007f80630081ca start_thread (libpthread.so.0)
#5 0x00007f8062c398d3 __clone (libc.so.6)
Stack trace of thread 2675754:
#0 0x00007f8062c3941d syscall (libc.so.6)
#1 0x00007f8065095253 g_cond_wait (libglib-2.0.so.0)
#2 0x000056518a97c527 writeout_thread (qemu-kvm)
#3 0x00007f80650764ea g_thread_proxy (libglib-2.0.so.0)
#4 0x00007f80630081ca start_thread (libpthread.so.0)
#5 0x00007f8062c398d3 __clone (libc.so.6)
Stack trace of thread 2675771:
#0 0x00007f8062c3922b ioctl (libc.so.6)
#1 0x000056518a769044 kvm_vcpu_ioctl (qemu-kvm)
#2 0x000056518a769401 kvm_cpu_exec (qemu-kvm)
#3 0x000056518a76a74d kvm_vcpu_thread_fn (qemu-kvm)
#4 0x000056518a954cb4 qemu_thread_start (qemu-kvm)
#5 0x00007f80630081ca start_thread (libpthread.so.0)
#6 0x00007f8062c398d3 __clone (libc.so.6)
Stack trace of thread 2675755:
#0 0x00007f8062d32ac1 __poll (libc.so.6)
#1 0x00007f806504de16 g_main_context_iterate.isra.20 (libglib-2.0.so.0)
#2 0x00007f806504df40 g_main_context_iteration (libglib-2.0.so.0)
#3 0x00007f806504df91 glib_worker_main (libglib-2.0.so.0)
#4 0x00007f80650764ea g_thread_proxy (libglib-2.0.so.0)
#5 0x00007f80630081ca start_thread (libpthread.so.0)
#6 0x00007f8062c398d3 __clone (libc.so.6)
Stack trace of thread 2675756:
#0 0x00007f8062d32ac1 __poll (libc.so.6)
#1 0x00007f806504de16 g_main_context_iterate.isra.20 (libglib-2.0.so.0)
#2 0x00007f806504e1d2 g_main_loop_run (libglib-2.0.so.0)
#3 0x00007f80658d763a gdbus_shared_thread_func (libgio-2.0.so.0)
#4 0x00007f80650764ea g_thread_proxy (libglib-2.0.so.0)
#5 0x00007f80630081ca start_thread (libpthread.so.0)
#6 0x00007f8062c398d3 __clone (libc.so.6)
Stack trace of thread 2675769:
#0 0x00007f8062c3922b ioctl (libc.so.6)
#1 0x000056518a769044 kvm_vcpu_ioctl (qemu-kvm)
#2 0x000056518a769401 kvm_cpu_exec (qemu-kvm)
#3 0x000056518a76a74d kvm_vcpu_thread_fn (qemu-kvm)
#4 0x000056518a954cb4 qemu_thread_start (qemu-kvm)
#5 0x00007f80630081ca start_thread (libpthread.so.0)
#6 0x00007f8062c398d3 __clone (libc.so.6)
Stack trace of thread 2675773:
#0 0x00007f806300e47c pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
#1 0x000056518a9551f9 qemu_cond_wait_impl (qemu-kvm)
#2 0x000056518a4e4273 vnc_worker_thread_loop (qemu-kvm)
#3 0x000056518a4e4cb0 vnc_worker_thread (qemu-kvm)
#4 0x000056518a954cb4 qemu_thread_start (qemu-kvm)
#5 0x00007f80630081ca start_thread (libpthread.so.0)
#6 0x00007f8062c398d3 __clone (libc.so.6)
Stack trace of thread 2675767:
#0 0x00007f8062d32ac1 __poll (libc.so.6)
#1 0x00007f806504de16 g_main_context_iterate.isra.20 (libglib-2.0.so.0)
#2 0x00007f806504e1d2 g_main_loop_run (libglib-2.0.so.0)
#3 0x000056518a7a2369 iothread_run (qemu-kvm)
#4 0x000056518a954cb4 qemu_thread_start (qemu-kvm)
#5 0x00007f80630081ca start_thread (libpthread.so.0)
#6 0x00007f8062c398d3 __clone (libc.so.6)
Stack trace of thread 2675770:
#0 0x00007f8062c3922b ioctl (libc.so.6)
#1 0x000056518a769044 kvm_vcpu_ioctl (qemu-kvm)
#2 0x000056518a769401 kvm_cpu_exec (qemu-kvm)
#3 0x000056518a76a74d kvm_vcpu_thread_fn (qemu-kvm)
#4 0x000056518a954cb4 qemu_thread_start (qemu-kvm)
#5 0x00007f80630081ca start_thread (libpthread.so.0)
#6 0x00007f8062c398d3 __clone (libc.so.6)
Jul 07 20:05:08 Frisco-10-1 systemd[1]: systemd-coredump@19-2679125-0.service: Succeeded.
- is related to
-
RHEL-106968 Handle MR 467 for RHEL / qemu-kvm
-
- Closed
-
- links to
-
RHBA-2025:153508
qemu-kvm update
