RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2002607 - CVE-2021-4145 virt:rhel/qemu-kvm: QEMU: NULL pointer dereference in mirror_wait_on_conflicts() in block/mirror.c [rhel-8.6.0]
Summary: CVE-2021-4145 virt:rhel/qemu-kvm: QEMU: NULL pointer dereference in mirror_wa...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: qemu-kvm
Version: ---
Hardware: All
OS: Unspecified
high
low
Target Milestone: rc
: ---
Assignee: Stefano Garzarella
QA Contact: aihua liang
URL:
Whiteboard:
: 2018367 (view as bug list)
Depends On: 2001404 2027716
Blocks: 1929792 CVE-2021-4145 2047203
TreeView+ depends on / blocked
 
Reported: 2021-09-09 10:48 UTC by aihua liang
Modified: 2022-05-11 03:14 UTC (History)
12 users (show)

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:
Clone Of: 2001404
Environment:
Last Closed: 2022-05-10 13:20:33 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-96627 0 None None None 2021-09-09 10:51:48 UTC
Red Hat Product Errata RHSA-2022:1759 0 None None None 2022-05-10 13:21:19 UTC

Comment 1 John Ferlan 2021-09-17 13:55:09 UTC 
Bulk update: Move RHEL8 bugs to RHEL9. If necessary to resolve in RHEL8, then clone to the current RHEL8 release.
Comment 3 John Ferlan 2021-09-17 14:57:25 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.
Comment 4 John Ferlan 2021-09-17 15:00:27 UTC 
Mistakenly moved to RHEL9, moving back.
Comment 5 John Ferlan 2021-09-17 15:02:32 UTC 
Assigned to Stefano since he owns the cloned from bug 2001404 and can resolve at the same time.
Comment 6 Stefano Garzarella 2021-09-20 10:28:30 UTC 
Patch merged upstream: https://gitlab.com/qemu-project/qemu/-/commit/66fed30c9cd11854fc878a4eceb507e915d7c9cd
Comment 7 aihua liang 2021-09-26 03:05:24 UTC 
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.
Comment 8 Gu Nini 2021-11-02 01:55:45 UTC 
*** Bug 2018367 has been marked as a duplicate of this bug. ***
Comment 9 Yiding Liu (Fujitsu) 2021-12-10 06:28:16 UTC 
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;
Comment 11 John Ferlan 2021-12-22 18:01:48 UTC 
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.
Comment 14 Yanan Fu 2021-12-24 02:48:33 UTC 
QE bot(pre verify): Set 'Verified:Tested,SanityOnly' as gating/tier1 test pass.
Comment 15 aihua liang 2021-12-24 03:09:59 UTC 
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.
Comment 16 aihua liang 2022-01-07 11:47:27 UTC 
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".
Comment 19 errata-xmlrpc 2022-05-10 13:20:33 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.