[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-commits] [qemu/qemu] 22c36b: block/vvfat.c fix leak when failure o
From: |
Richard Henderson |
Subject: |
[Qemu-commits] [qemu/qemu] 22c36b: block/vvfat.c fix leak when failure occurs |
Date: |
Tue, 23 Nov 2021 08:23:24 -0800 |
Branch: refs/heads/staging
Home: https://github.com/qemu/qemu
Commit: 22c36b75c8a07f34a6516a8d79f38c74530727a1
https://github.com/qemu/qemu/commit/22c36b75c8a07f34a6516a8d79f38c74530727a1
Author: Daniella Lee <daniellalee111@gmail.com>
Date: 2021-11-23 (Tue, 23 Nov 2021)
Changed paths:
M block/vvfat.c
Log Message:
-----------
block/vvfat.c fix leak when failure occurs
Function vvfat_open called function enable_write_target and init_directories,
and these functions malloc new memory for BDRVVVFATState::qcow_filename,
BDRVVVFATState::used_clusters, and BDRVVVFATState::cluster_buff.
When the specified folder does not exist ,it may contains memory leak.
After init_directories function is executed, the vvfat_open return -EIO,
and bdrv_open_driver goto label open_failed,
the program use g_free(bs->opaque) to release BDRVVVFATState struct
without members mentioned.
command line:
qemu-system-x86_64 -hdb <vdisk qcow file> -usb -device usb-storage,drive=fat16
-drive file=fat:rw:fat-type=16:"<path of a host folder does not exist>",
id=fat16,format=raw,if=none
enable_write_target called:
(gdb) bt
at ../block/vvfat.c:3114
flags=155650, errp=0x7fffffffd780) at ../block/vvfat.c:1236
node_name=0x0, options=0x555556fa45d0, open_flags=155650,
errp=0x7fffffffd890) at ../block.c:1558
errp=0x7fffffffd890) at ../block.c:1852
reference=0x0, options=0x555556fa45d0, flags=40962, parent=0x555556f98cd0,
child_class=0x555556b1d6a0 <child_of_bds>, child_role=19,
errp=0x7fffffffda90) at ../block.c:3779
options=0x555556f9cfc0, bdref_key=0x555556239bb8 "file",
parent=0x555556f98cd0, child_class=0x555556b1d6a0 <child_of_bds>,
child_role=19, allow_none=true, errp=0x7fffffffda90) at ../block.c:3419
reference=0x0, options=0x555556f9cfc0, flags=8194, parent=0x0,
child_class=0x0, child_role=0, errp=0x555556c98c40 <error_fatal>)
at ../block.c:3726
options=0x555556f757b0, flags=0, errp=0x555556c98c40 <error_fatal>)
at ../block.c:3872
options=0x555556f757b0, flags=0, errp=0x555556c98c40 <error_fatal>)
at ../block/block-backend.c:436
bs_opts=0x555556f757b0, errp=0x555556c98c40 <error_fatal>)
at ../blockdev.c:608
errp=0x555556c98c40 <error_fatal>) at ../blockdev.c:992
......
Signed-off-by: Daniella Lee <daniellalee111@gmail.com>
Message-Id: <20211119112553.352222-1-daniellalee111@gmail.com>
[hreitz: Took commit message from v1]
Signed-off-by: Hanna Reitz <hreitz@redhat.com>
Commit: cb5a24d7f692ad129f019f3b670531eccfe14415
https://github.com/qemu/qemu/commit/cb5a24d7f692ad129f019f3b670531eccfe14415
Author: Hanna Reitz <hreitz@redhat.com>
Date: 2021-11-23 (Tue, 23 Nov 2021)
Changed paths:
M tests/qemu-iotests/206
M tests/qemu-iotests/206.out
M tests/qemu-iotests/210
M tests/qemu-iotests/210.out
Log Message:
-----------
iotests: Use aes-128-cbc
Our gnutls crypto backend (which is the default as of 8bd0931f6)
supports neither twofish-128 nor the CTR mode. CBC and aes-128 are
supported by all of our backends (as far as I can tell), so use
aes-128-cbc in our iotests.
(We could also use e.g. aes-256-cbc, but the different key sizes would
lead to different key slot offsets and so change the reference output
more, which is why I went with aes-128.)
Signed-off-by: Hanna Reitz <hreitz@redhat.com>
Message-Id: <20211117151707.52549-2-hreitz@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Tested-by: Thomas Huth <thuth@redhat.com>
Commit: 4dd218fd0717ed3cddb69c01eeb9da630107d89d
https://github.com/qemu/qemu/commit/4dd218fd0717ed3cddb69c01eeb9da630107d89d
Author: Hanna Reitz <hreitz@redhat.com>
Date: 2021-11-23 (Tue, 23 Nov 2021)
Changed paths:
M tests/qemu-iotests/149
Log Message:
-----------
iotests/149: Skip on unsupported ciphers
Whenever qemu-img or qemu-io report that some cipher is unsupported,
skip the whole test, because that is probably because qemu has been
configured with the gnutls crypto backend.
We could taylor the algorithm list to what gnutls supports, but this is
a test that is run rather rarely anyway (because it requires
password-less sudo), and so it seems better and easier to skip it. When
this test is intentionally run to check LUKS compatibility, it seems
better not to limit the algorithms but keep the list extensive.
Signed-off-by: Hanna Reitz <hreitz@redhat.com>
Message-Id: <20211117151707.52549-3-hreitz@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Commit: 35133781bdd933cbdd5f9310ceb2e6535b0ba4fc
https://github.com/qemu/qemu/commit/35133781bdd933cbdd5f9310ceb2e6535b0ba4fc
Author: Richard Henderson <richard.henderson@linaro.org>
Date: 2021-11-23 (Tue, 23 Nov 2021)
Changed paths:
M block/vvfat.c
M tests/qemu-iotests/149
M tests/qemu-iotests/206
M tests/qemu-iotests/206.out
M tests/qemu-iotests/210
M tests/qemu-iotests/210.out
Log Message:
-----------
Merge tag 'pull-block-2021-11-23' of https://gitlab.com/hreitz/qemu into
staging
Block patches for 6.2-rc2:
- Fix memory leak in vvfat when vvfat_open() fails
- iotest fixes for the gnutls crypto backend
# gpg: Signature made Tue 23 Nov 2021 04:58:05 PM CET
# gpg: using RSA key CB62D7A0EE3829E45F004D34A1FA40D098019CDF
# gpg: issuer "hreitz@redhat.com"
# gpg: Good signature from "Hanna Reitz <hreitz@redhat.com>" [marginal]
# gpg: WARNING: This key is not certified with sufficiently trusted signatures!
# gpg: It is not certain that the signature belongs to the owner.
# Primary key fingerprint: CB62 D7A0 EE38 29E4 5F00 4D34 A1FA 40D0 9801 9CDF
* tag 'pull-block-2021-11-23' of https://gitlab.com/hreitz/qemu:
iotests/149: Skip on unsupported ciphers
iotests: Use aes-128-cbc
block/vvfat.c fix leak when failure occurs
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Compare: https://github.com/qemu/qemu/compare/73e0f70e097b...35133781bdd9
- [Qemu-commits] [qemu/qemu] 22c36b: block/vvfat.c fix leak when failure occurs,
Richard Henderson <=