Bug 2002607
| Summary: | CVE-2021-4145 virt:rhel/qemu-kvm: QEMU: NULL pointer dereference in mirror_wait_on_conflicts() in block/mirror.c [rhel-8.6.0] | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | aihua liang <aliang> |
| Component: | qemu-kvm | Assignee: | Stefano Garzarella <sgarzare> |
| qemu-kvm sub component: | Block Jobs | QA Contact: | aihua liang <aliang> |
| Status: | CLOSED ERRATA | Docs Contact: | |
| Severity: | low | ||
| Priority: | high | CC: | ahadas, aliang, coli, jferlan, jmaloy, kkiwi, ngu, sgarzare, virt-maint, xfu, yfu, yidliu |
| Version: | --- | Keywords: | Security, SecurityTracking, Triaged |
| Target Milestone: | rc | Flags: | pm-rhel:
mirror+
|
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | qemu-kvm-6.2.0-1.module+el8.6.0+13725+61ae1949 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | 2001404 | Environment: | |
| Last Closed: | 2022-05-10 13:20:33 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 2001404, 2027716 | ||
| Bug Blocks: | 1929792, 2034602, 2047203 | ||
|
Comment 1
John Ferlan
2021-09-17 13:55:09 UTC
(In reply to CongLi from comment #2) > (In reply to John Ferlan from comment #1) > > Bulk update: Move RHEL8 bugs to RHEL9. If necessary to resolve in RHEL8, > > then clone to the current RHEL8 release. > > Hi John, > > This bug was cloned from rhel.9 to rhel.8, BZ2001404 is the one in rhel.9. > And this case is added to gating ('acceptance' keyword added in > qa_whiteboard), QE prefer to fix it in both. > Do you agree ? > > > Thanks. Whoops, you're right - my mistake. I didn't look at the qa whiteboard when doing this. FWIW: This I think shows why I'm against cloning from RHEL9 to RHEL8 until there is a fix finalized. The RHEL9 bug is assigned to someone, while the RHEL8 bug is assigned to virt-maint - so now we have some mismatch possible. At least when the assignee/developer does the clone, he/she could assign to themselves and process the fix when the fix is available. Mistakenly moved to RHEL9, moving back. Assigned to Stefano since he owns the cloned from bug 2001404 and can resolve at the same time. Patch merged upstream: https://gitlab.com/qemu-project/qemu/-/commit/66fed30c9cd11854fc878a4eceb507e915d7c9cd In qemu-kvm-6.1.0-2.el9 and qemu-kvm-6.1.0-1.module+el8.6.0+12535+4e2af250, image cluster leak after qemu crash. [root@dell-per440-09 images]# qemu-img check rhel900-64-virtio.qcow2 Leaked cluster 175239 refcount=1 reference=0 Leaked cluster 175240 refcount=1 reference=0 Leaked cluster 175241 refcount=1 reference=0 Leaked cluster 175242 refcount=1 reference=0 Leaked cluster 175243 refcount=1 reference=0 Leaked cluster 175244 refcount=1 reference=0 Leaked cluster 175245 refcount=1 reference=0 Leaked cluster 175246 refcount=1 reference=0 Leaked cluster 175247 refcount=1 reference=0 Leaked cluster 175248 refcount=1 reference=0 Leaked cluster 175249 refcount=1 reference=0 Leaked cluster 175250 refcount=1 reference=0 Leaked cluster 175251 refcount=1 reference=0 Leaked cluster 175252 refcount=1 reference=0 Leaked cluster 175253 refcount=1 reference=0 Leaked cluster 175254 refcount=1 reference=0 Leaked cluster 175255 refcount=1 reference=0 Leaked cluster 175256 refcount=1 reference=0 Leaked cluster 175257 refcount=1 reference=0 Leaked cluster 175258 refcount=1 reference=0 Leaked cluster 175259 refcount=1 reference=0 Leaked cluster 175260 refcount=1 reference=0 Leaked cluster 175261 refcount=1 reference=0 Leaked cluster 175262 refcount=1 reference=0 Leaked cluster 175263 refcount=1 reference=0 Leaked cluster 175264 refcount=1 reference=0 Leaked cluster 175265 refcount=1 reference=0 Leaked cluster 175266 refcount=1 reference=0 Leaked cluster 175267 refcount=1 reference=0 Leaked cluster 175268 refcount=1 reference=0 Leaked cluster 175269 refcount=1 reference=0 Leaked cluster 175270 refcount=1 reference=0 Leaked cluster 175271 refcount=1 reference=0 Leaked cluster 175272 refcount=1 reference=0 Leaked cluster 175273 refcount=1 reference=0 Leaked cluster 175274 refcount=1 reference=0 Leaked cluster 175275 refcount=1 reference=0 Leaked cluster 175276 refcount=1 reference=0 Leaked cluster 175277 refcount=1 reference=0 Leaked cluster 175278 refcount=1 reference=0 Leaked cluster 175279 refcount=1 reference=0 Leaked cluster 175280 refcount=1 reference=0 Leaked cluster 175281 refcount=1 reference=0 Leaked cluster 175282 refcount=1 reference=0 Leaked cluster 175283 refcount=1 reference=0 Leaked cluster 175284 refcount=1 reference=0 Leaked cluster 175285 refcount=1 reference=0 Leaked cluster 175286 refcount=1 reference=0 Leaked cluster 175287 refcount=1 reference=0 Leaked cluster 175288 refcount=1 reference=0 Leaked cluster 175289 refcount=1 reference=0 Leaked cluster 175290 refcount=1 reference=0 Leaked cluster 175291 refcount=1 reference=0 Leaked cluster 175292 refcount=1 reference=0 Leaked cluster 175293 refcount=1 reference=0 Leaked cluster 175294 refcount=1 reference=0 Leaked cluster 175295 refcount=1 reference=0 Leaked cluster 175296 refcount=1 reference=0 Leaked cluster 175297 refcount=1 reference=0 Leaked cluster 175298 refcount=1 reference=0 Leaked cluster 175299 refcount=1 reference=0 Leaked cluster 175300 refcount=1 reference=0 Leaked cluster 175301 refcount=1 reference=0 Leaked cluster 175302 refcount=1 reference=0 Leaked cluster 175303 refcount=1 reference=0 Leaked cluster 175304 refcount=1 reference=0 Leaked cluster 175305 refcount=1 reference=0 Leaked cluster 175306 refcount=1 reference=0 Leaked cluster 175307 refcount=1 reference=0 Leaked cluster 175308 refcount=1 reference=0 Leaked cluster 175309 refcount=1 reference=0 Leaked cluster 175310 refcount=1 reference=0 Leaked cluster 175311 refcount=1 reference=0 Leaked cluster 175312 refcount=1 reference=0 Leaked cluster 175313 refcount=1 reference=0 Leaked cluster 175314 refcount=1 reference=0 Leaked cluster 175315 refcount=1 reference=0 Leaked cluster 175316 refcount=1 reference=0 Leaked cluster 175317 refcount=1 reference=0 Leaked cluster 175318 refcount=1 reference=0 Leaked cluster 175319 refcount=1 reference=0 Leaked cluster 175320 refcount=1 reference=0 Leaked cluster 175321 refcount=1 reference=0 Leaked cluster 175322 refcount=1 reference=0 Leaked cluster 175323 refcount=1 reference=0 Leaked cluster 175324 refcount=1 reference=0 Leaked cluster 175325 refcount=1 reference=0 Leaked cluster 175326 refcount=1 reference=0 Leaked cluster 175327 refcount=1 reference=0 Leaked cluster 175328 refcount=1 reference=0 Leaked cluster 175329 refcount=1 reference=0 Leaked cluster 175330 refcount=1 reference=0 Leaked cluster 175331 refcount=1 reference=0 Leaked cluster 175332 refcount=1 reference=0 Leaked cluster 175333 refcount=1 reference=0 Leaked cluster 175334 refcount=1 reference=0 Leaked cluster 175335 refcount=1 reference=0 Leaked cluster 175336 refcount=1 reference=0 Leaked cluster 175337 refcount=1 reference=0 Leaked cluster 175338 refcount=1 reference=0 Leaked cluster 175339 refcount=1 reference=0 Leaked cluster 175340 refcount=1 reference=0 Leaked cluster 175341 refcount=1 reference=0 Leaked cluster 175342 refcount=1 reference=0 Leaked cluster 175343 refcount=1 reference=0 Leaked cluster 175344 refcount=1 reference=0 Leaked cluster 175345 refcount=1 reference=0 Leaked cluster 175346 refcount=1 reference=0 Leaked cluster 175347 refcount=1 reference=0 Leaked cluster 175348 refcount=1 reference=0 Leaked cluster 175349 refcount=1 reference=0 Leaked cluster 175350 refcount=1 reference=0 Leaked cluster 175351 refcount=1 reference=0 Leaked cluster 175352 refcount=1 reference=0 Leaked cluster 175353 refcount=1 reference=0 Leaked cluster 175354 refcount=1 reference=0 Leaked cluster 175355 refcount=1 reference=0 Leaked cluster 175356 refcount=1 reference=0 Leaked cluster 175357 refcount=1 reference=0 Leaked cluster 175358 refcount=1 reference=0 Leaked cluster 175359 refcount=1 reference=0 Leaked cluster 175360 refcount=1 reference=0 Leaked cluster 175361 refcount=1 reference=0 Leaked cluster 175362 refcount=1 reference=0 Leaked cluster 175363 refcount=1 reference=0 Leaked cluster 175364 refcount=1 reference=0 Leaked cluster 175365 refcount=1 reference=0 Leaked cluster 175366 refcount=1 reference=0 Leaked cluster 175367 refcount=1 reference=0 Leaked cluster 175368 refcount=1 reference=0 Leaked cluster 175369 refcount=1 reference=0 Leaked cluster 175370 refcount=1 reference=0 Leaked cluster 175371 refcount=1 reference=0 Leaked cluster 175372 refcount=1 reference=0 Leaked cluster 175373 refcount=1 reference=0 Leaked cluster 175374 refcount=1 reference=0 Leaked cluster 175375 refcount=1 reference=0 Leaked cluster 175376 refcount=1 reference=0 Leaked cluster 175377 refcount=1 reference=0 Leaked cluster 175378 refcount=1 reference=0 Leaked cluster 175379 refcount=1 reference=0 Leaked cluster 175380 refcount=1 reference=0 Leaked cluster 175381 refcount=1 reference=0 Leaked cluster 175382 refcount=1 reference=0 Leaked cluster 175383 refcount=1 reference=0 Leaked cluster 175384 refcount=1 reference=0 Leaked cluster 175385 refcount=1 reference=0 Leaked cluster 175386 refcount=1 reference=0 Leaked cluster 175387 refcount=1 reference=0 Leaked cluster 175388 refcount=1 reference=0 Leaked cluster 175389 refcount=1 reference=0 Leaked cluster 175390 refcount=1 reference=0 Leaked cluster 175391 refcount=1 reference=0 Leaked cluster 175392 refcount=1 reference=0 Leaked cluster 175393 refcount=1 reference=0 Leaked cluster 175394 refcount=1 reference=0 156 leaked clusters were found on the image. This means waste of disk space, but no harm to data. 175203/327680 = 53.47% allocated, 5.20% fragmented, 0.00% compressed clusters Image end offset: 11494752256 And in latest version:qemu-kvm-core-6.1.0-1.module+el8.6.0+12721+8d053ff2.x86_64 and qemu-kvm-6.1.0-3.el9 also hit this issue. *** Bug 2018367 has been marked as a duplicate of this bug. *** aarch64 also has this error. Set Hardware as all.
qemu-kvm-6.1.0-5.module+el8.6.0+13430+8fdd5f85.aarch64
# gdb qemu-kvm core.qemu-kvm.107.51326643dd1544f68c6d5fc49b025b3c.1272643.1639115805000000
[snip]
Core was generated by `/usr/libexec/qemu-kvm -name guest=avocado-vt-vm1,debug-threads=on -S -object {"'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 mirror_wait_on_conflicts (self=self@entry=0x0, s=s@entry=0xaaaafc61d790, offset=offset@entry=6767378432, bytes=bytes@entry=1) at ../block/mirror.c:172
172 self->waiting_for_op = op;
Mass update of DTM/ITM to +3 values since the rebase of qemu-6.2 into RHEL 8.6 has been delayed or slowed due to process roadblocks (authentication changes, gating issues). This avoids the DevMissed bot and worse the bot that could come along and strip release+. The +3 was chosen mainly to give a cushion. Also added the qemu-6.2 rebase bug 2027716 as a dependent. QE bot(pre verify): Set 'Verified:Tested,SanityOnly' as gating/tier1 test pass. Test on qemu-kvm-6.2.0-1.module+el8.6.0+13725+61ae1949, don't hit the coredump issue any more. For the CVE issue, no resource at present and it takes more time to reporduce, so will reset the ITM. Test the issue that hahan reported in bz2030708 for 900 times with qemu-kvm-6.2.0-2.module+el8.6.0+13738+17338784, all pass So set bug's statu to "Verified". Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: virt:rhel and virt-devel:rhel security, bug fix, and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2022:1759 |