[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
qcow2 api not secured by mutex lock
From: |
Vladimir Sementsov-Ogievskiy |
Subject: |
qcow2 api not secured by mutex lock |
Date: |
Wed, 18 Dec 2019 10:28:48 +0000 |
Hi!
Some time ago, we've faced and fixed the fact that qcow2 bitmap api doesn't
call qcow2_co_mutex_lock, before accessing qcow2 metadata. This was solved by
moving qcow2_co_remove_persistent_dirty_bitmap and
qcow2_co_can_store_new_dirty_bitmap to coroutine and call qcow2_co_mutex_lock.
Now I decided to look at big picture (it is attached).
Boxes are qcow2 driver api, green border means that function calls
qcow2_co_mutex_lock
(it doesn't guarantee, that exactly child node call is locked, but it is
something).
In the picture there are just all functions, calling qcow2_cache_get/put.. Not
all the
functions, that needs locking, but again, it is something.
So, accordingly to the picture, it seems that the following functions lacks
locking:
qcow2_co_create
qcow2_snapshot_*
(but it is both drained and aio context locked, so should be safe, yes?)
qcow2_reopen_bitmaps_rw
qcow2_store_persistent_dirty_bitmaps
qcow2_amend_options
qcow2_make_empty
===
Checking green nodes:
qcow2_co_invalidate_cache actually calls qcow2_close unlocked, it's another
reason to fix qcow2_store_persistent_dirty_bitmaps
qcow2_write_snapshots actually called unlocked from
qcow2_check_fix_snapshot_table.. It seems unsafe.
===
Not complete audit of course.. What do you think about it? I think, I at least
should move
qcow2_store_persistent_dirty_bitmaps and qcow2_reopen_bitmaps_rw to coroutine,
like qcow2_co_remove_persistent_dirty_bitmap.
--
Best regards,
Vladimir
master-block-qcow2-filtered.svg
Description: master-block-qcow2-filtered.svg
- qcow2 api not secured by mutex lock,
Vladimir Sementsov-Ogievskiy <=