* [PULL 1/3] memory: Fix wrong end address dump
2022-11-08 18:33 [PULL 0/3] Memory/SDHCI/ParallelFlash patches for v7.2.0-rc0 Philippe Mathieu-Daudé
@ 2022-11-08 18:33 ` Philippe Mathieu-Daudé
2022-11-08 18:33 ` [PULL 2/3] hw/sd/sdhci: Do not set Buf Wr Ena before writing block (CVE-2022-3872) Philippe Mathieu-Daudé
` (2 subsequent siblings)
3 siblings, 0 replies; 8+ messages in thread
From: Philippe Mathieu-Daudé @ 2022-11-08 18:33 UTC (permalink / raw)
To: qemu-devel
Cc: Bin Meng, Hanna Reitz, David Hildenbrand, Kevin Wolf, qemu-block,
Peter Xu, Paolo Bonzini, Philippe Mathieu-Daudé,
Zhenzhong Duan
From: Zhenzhong Duan <zhenzhong.duan@intel.com>
The end address of memory region section isn't correctly calculated
which leads to overflowed mtree dump:
Dispatch
Physical sections
......
#70 @0000000000002000..0000000000011fff io [ROOT]
#71 @0000000000005000..0000000000005fff (noname)
#72 @0000000000005000..0000000000014fff io [ROOT]
#73 @0000000000005658..0000000000005658 vmport
#74 @0000000000005659..0000000000015658 io [ROOT]
#75 @0000000000006000..0000000000015fff io [ROOT]
After fix:
#70 @0000000000002000..0000000000004fff io [ROOT]
#71 @0000000000005000..0000000000005fff (noname)
#72 @0000000000005000..0000000000005657 io [ROOT]
#73 @0000000000005658..0000000000005658 vmport
#74 @0000000000005659..0000000000005fff io [ROOT]
#75 @0000000000006000..000000000000ffff io [ROOT]
Fixes: 5e8fd947e2670 ("memory: Rework "info mtree" to print flat views and dispatch trees")
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@intel.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <20220622095912.3430583-1-zhenzhong.duan@intel.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
softmmu/physmem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/softmmu/physmem.c b/softmmu/physmem.c
index d9578ccfd4..1b606a3002 100644
--- a/softmmu/physmem.c
+++ b/softmmu/physmem.c
@@ -3712,7 +3712,7 @@ void mtree_print_dispatch(AddressSpaceDispatch *d, MemoryRegion *root)
" %s%s%s%s%s",
i,
s->offset_within_address_space,
- s->offset_within_address_space + MR_SIZE(s->mr->size),
+ s->offset_within_address_space + MR_SIZE(s->size),
s->mr->name ? s->mr->name : "(noname)",
i < ARRAY_SIZE(names) ? names[i] : "",
s->mr == root ? " [ROOT]" : "",
--
2.38.1
^ permalink raw reply related [flat|nested] 8+ messages in thread
* [PULL 2/3] hw/sd/sdhci: Do not set Buf Wr Ena before writing block (CVE-2022-3872)
2022-11-08 18:33 [PULL 0/3] Memory/SDHCI/ParallelFlash patches for v7.2.0-rc0 Philippe Mathieu-Daudé
2022-11-08 18:33 ` [PULL 1/3] memory: Fix wrong end address dump Philippe Mathieu-Daudé
@ 2022-11-08 18:33 ` Philippe Mathieu-Daudé
2022-11-08 18:33 ` [PULL 3/3] Revert "hw/block/pflash_cfi: Error out if dev length isn't power of 2" Philippe Mathieu-Daudé
2022-11-08 20:49 ` [PULL 0/3] Memory/SDHCI/ParallelFlash patches for v7.2.0-rc0 Stefan Hajnoczi
3 siblings, 0 replies; 8+ messages in thread
From: Philippe Mathieu-Daudé @ 2022-11-08 18:33 UTC (permalink / raw)
To: qemu-devel
Cc: Bin Meng, Hanna Reitz, David Hildenbrand, Kevin Wolf, qemu-block,
Peter Xu, Paolo Bonzini, Philippe Mathieu-Daudé,
RivenDell, Siqi Chen, ningqiang, Mauro Matteo Cascella
When sdhci_write_block_to_card() is called to transfer data from
the FIFO to the SD bus, the data is already present in the buffer
and we have to consume it directly.
See the description of the 'Buffer Write Enable' bit from the
'Present State' register (prnsts::SDHC_SPACE_AVAILABLE) in Table
2.14 from the SDHCI spec v2:
Buffer Write Enable
This status is used for non-DMA write transfers.
The Host Controller can implement multiple buffers to transfer
data efficiently. This read only flag indicates if space is
available for write data. If this bit is 1, data can be written
to the buffer. A change of this bit from 1 to 0 occurs when all
the block data is written to the buffer. A change of this bit
from 0 to 1 occurs when top of block data can be written to the
buffer and generates the Buffer Write Ready interrupt.
In our case, we do not want to overwrite the buffer, so we want
this bit to be 0, then set it to 1 once the data is written onto
the bus.
This is probably a copy/paste error from commit d7dfca0807
("hw/sdhci: introduce standard SD host controller").
OSS-Fuzz Report: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=45986#c4
Reproducers:
$ cat << EOF | \
qemu-system-x86_64 -nodefaults -display none -machine accel=qtest \
-m 512M -device sdhci-pci -device sd-card,drive=mydrive \
-drive if=none,index=0,file=null-co://,format=raw,id=mydrive \
-nographic -qtest stdio
outl 0xcf8 0x80001010
outl 0xcfc 0xe0000000
outl 0xcf8 0x80001001
outl 0xcfc 0x06000000
write 0xe0000058 0x1 0x6e
write 0xe0000059 0x1 0x5a
write 0xe0000028 0x1 0x10
write 0xe000002c 0x1 0x05
write 0x5a6e 0x1 0x21
write 0x5a75 0x1 0x20
write 0xe0000005 0x1 0x02
write 0xe000000c 0x1 0x01
write 0xe000000e 0x1 0x20
write 0xe000000f 0x1 0x00
write 0xe000000c 0x1 0x00
write 0xe0000020 0x1 0x00
EOF
or https://lore.kernel.org/qemu-devel/CAA8xKjXrmS0fkr28AKvNNpyAtM0y0B+5FichpsrhD+mUgnuyKg@mail.gmail.com/
Fixes: CVE-2022-3872
Reported-by: RivenDell <XRivenDell@outlook.com>
Reported-by: Siqi Chen <coc.cyqh@gmail.com>
Reported-by: ningqiang <ningqiang1@huawei.com>
Reported-by: ClusterFuzz
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Tested-by: Mauro Matteo Cascella <mcascell@redhat.com>
Message-Id: <20221107221236.47841-2-philmd@linaro.org>
---
hw/sd/sdhci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c
index 306070c872..f230e7475f 100644
--- a/hw/sd/sdhci.c
+++ b/hw/sd/sdhci.c
@@ -954,7 +954,7 @@ static void sdhci_data_transfer(void *opaque)
sdhci_read_block_from_card(s);
} else {
s->prnsts |= SDHC_DOING_WRITE | SDHC_DAT_LINE_ACTIVE |
- SDHC_SPACE_AVAILABLE | SDHC_DATA_INHIBIT;
+ SDHC_DATA_INHIBIT;
sdhci_write_block_to_card(s);
}
}
--
2.38.1
^ permalink raw reply related [flat|nested] 8+ messages in thread
* [PULL 3/3] Revert "hw/block/pflash_cfi: Error out if dev length isn't power of 2"
2022-11-08 18:33 [PULL 0/3] Memory/SDHCI/ParallelFlash patches for v7.2.0-rc0 Philippe Mathieu-Daudé
2022-11-08 18:33 ` [PULL 1/3] memory: Fix wrong end address dump Philippe Mathieu-Daudé
2022-11-08 18:33 ` [PULL 2/3] hw/sd/sdhci: Do not set Buf Wr Ena before writing block (CVE-2022-3872) Philippe Mathieu-Daudé
@ 2022-11-08 18:33 ` Philippe Mathieu-Daudé
2022-11-08 20:49 ` [PULL 0/3] Memory/SDHCI/ParallelFlash patches for v7.2.0-rc0 Stefan Hajnoczi
3 siblings, 0 replies; 8+ messages in thread
From: Philippe Mathieu-Daudé @ 2022-11-08 18:33 UTC (permalink / raw)
To: qemu-devel
Cc: Bin Meng, Hanna Reitz, David Hildenbrand, Kevin Wolf, qemu-block,
Peter Xu, Paolo Bonzini, Philippe Mathieu-Daudé,
Daniel Henrique Barboza
From: Daniel Henrique Barboza <danielhb413@gmail.com>
Commit 334c388f25 ("pflash_cfi: Error out if device length
isn't a power of two") aimed to finish the effort started by
commit 06f1521795 ("pflash: Require backend size to match device,
improve errors"), but unfortunately we are not quite there since
various machines are still ready to accept incomplete / oversized
pflash backend images, and now fail, i.e. on Debian bullseye:
$ qemu-system-x86_64 \
-drive \
if=pflash,format=raw,unit=0,readonly=on,file=/usr/share/OVMF/OVMF_CODE.fd
qemu-system-x86_64: Device size must be a power of two.
where OVMF_CODE.fd comes from the ovmf package, which doesn't
pad the firmware images to the flash size:
$ ls -lh /usr/share/OVMF/
-rw-r--r-- 1 root root 3.5M Aug 19 2021 OVMF_CODE_4M.fd
-rw-r--r-- 1 root root 1.9M Aug 19 2021 OVMF_CODE.fd
-rw-r--r-- 1 root root 128K Aug 19 2021 OVMF_VARS.fd
Since we entered the freeze period to prepare the v7.2.0 release,
the safest is to revert commit 334c388f25707a234c4a0dea05b9df08d.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1294
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <20221108175755.95141-1-philmd@linaro.org>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Message-Id: <20221108172633.860700-1-danielhb413@gmail.com>
---
hw/block/pflash_cfi01.c | 8 ++------
hw/block/pflash_cfi02.c | 5 -----
2 files changed, 2 insertions(+), 11 deletions(-)
diff --git a/hw/block/pflash_cfi01.c b/hw/block/pflash_cfi01.c
index 9c235bf66e..0cbc2fb4cb 100644
--- a/hw/block/pflash_cfi01.c
+++ b/hw/block/pflash_cfi01.c
@@ -690,7 +690,7 @@ static const MemoryRegionOps pflash_cfi01_ops = {
.endianness = DEVICE_NATIVE_ENDIAN,
};
-static void pflash_cfi01_fill_cfi_table(PFlashCFI01 *pfl, Error **errp)
+static void pflash_cfi01_fill_cfi_table(PFlashCFI01 *pfl)
{
uint64_t blocks_per_device, sector_len_per_device, device_len;
int num_devices;
@@ -708,10 +708,6 @@ static void pflash_cfi01_fill_cfi_table(PFlashCFI01 *pfl, Error **errp)
sector_len_per_device = pfl->sector_len / num_devices;
}
device_len = sector_len_per_device * blocks_per_device;
- if (!is_power_of_2(device_len)) {
- error_setg(errp, "Device size must be a power of two.");
- return;
- }
/* Hardcoded CFI table */
/* Standard "QRY" string */
@@ -869,7 +865,7 @@ static void pflash_cfi01_realize(DeviceState *dev, Error **errp)
*/
pfl->cmd = 0x00;
pfl->status = 0x80; /* WSM ready */
- pflash_cfi01_fill_cfi_table(pfl, errp);
+ pflash_cfi01_fill_cfi_table(pfl);
}
static void pflash_cfi01_system_reset(DeviceState *dev)
diff --git a/hw/block/pflash_cfi02.c b/hw/block/pflash_cfi02.c
index ff2fe154c1..2a99b286b0 100644
--- a/hw/block/pflash_cfi02.c
+++ b/hw/block/pflash_cfi02.c
@@ -880,11 +880,6 @@ static void pflash_cfi02_realize(DeviceState *dev, Error **errp)
return;
}
- if (!is_power_of_2(pfl->chip_len)) {
- error_setg(errp, "Device size must be a power of two.");
- return;
- }
-
memory_region_init_rom_device(&pfl->orig_mem, OBJECT(pfl),
&pflash_cfi02_ops, pfl, pfl->name,
pfl->chip_len, errp);
--
2.38.1
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PULL 0/3] Memory/SDHCI/ParallelFlash patches for v7.2.0-rc0
2022-11-08 18:33 [PULL 0/3] Memory/SDHCI/ParallelFlash patches for v7.2.0-rc0 Philippe Mathieu-Daudé
` (2 preceding siblings ...)
2022-11-08 18:33 ` [PULL 3/3] Revert "hw/block/pflash_cfi: Error out if dev length isn't power of 2" Philippe Mathieu-Daudé
@ 2022-11-08 20:49 ` Stefan Hajnoczi
2022-11-08 20:57 ` Stefan Hajnoczi
3 siblings, 1 reply; 8+ messages in thread
From: Stefan Hajnoczi @ 2022-11-08 20:49 UTC (permalink / raw)
To: Philippe Mathieu-Daudé
Cc: qemu-devel, Bin Meng, Hanna Reitz, David Hildenbrand, Kevin Wolf,
qemu-block, Peter Xu, Paolo Bonzini
On Tue, 8 Nov 2022 at 13:35, Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
>
> The following changes since commit ade760a2f63804b7ab1839fbc3e5ddbf30538718:
>
> Merge tag 'pull-request-2022-11-08' of https://gitlab.com/thuth/qemu into staging (2022-11-08 11:34:06 -0500)
>
> are available in the Git repository at:
>
> https://github.com/philmd/qemu.git tags/memflash-20221108
>
> for you to fetch changes up to cf9b3efd816518f9f210f50a0fa3e46a00b33c27:
>
> Revert "hw/block/pflash_cfi: Error out if dev length isn't power of 2" (2022-11-08 19:29:25 +0100)
>
> ----------------------------------------------------------------
> Memory/SDHCI/ParallelFlash patches queue
>
> - Fix wrong end address dump in 'info mtree' (Zhenzhong Duan)
> - Fix in SDHCI for CVE-2022-3872 (myself)
There is a CI failure:
>>> G_TEST_DBUS_DAEMON=/builds/qemu-project/qemu/tests/dbus-vmstate-daemon.sh MALLOC_PERTURB_=127 QTEST_QEMU_BINARY=./qemu-system-arm QTEST_QEMU_STORAGE_DAEMON_BINARY=./storage-daemon/qemu-storage-daemon QTEST_QEMU_IMG=./qemu-img /builds/qemu-project/qemu/build/tests/qtest/npcm7xx_sdhci-test --tap -k
――――――――――――――――――――――――――――――――――――― ✀ ―――――――――――――――――――――――――――――――――――――
stderr:
** Message: 19:27:52.411: /tmp/sdhci_ZD2EV1
**
ERROR:../tests/qtest/npcm7xx_sdhci-test.c:101:sdwrite_read: assertion
failed: (!memcmp(rmsg, msg, len))
https://gitlab.com/qemu-project/qemu/-/jobs/3292896670
Stefan
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PULL 0/3] Memory/SDHCI/ParallelFlash patches for v7.2.0-rc0
2022-11-08 20:49 ` [PULL 0/3] Memory/SDHCI/ParallelFlash patches for v7.2.0-rc0 Stefan Hajnoczi
@ 2022-11-08 20:57 ` Stefan Hajnoczi
2022-11-09 7:43 ` Philippe Mathieu-Daudé
0 siblings, 1 reply; 8+ messages in thread
From: Stefan Hajnoczi @ 2022-11-08 20:57 UTC (permalink / raw)
To: Philippe Mathieu-Daudé
Cc: qemu-devel, Bin Meng, Hanna Reitz, David Hildenbrand, Kevin Wolf,
qemu-block, Peter Xu, Paolo Bonzini
I've dropped the SDHCI CVE fix due to the CI failure.
The rest of the commits are still in the staging tree and I plan to
include them in v7.2.0-rc0.
Stefan
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PULL 0/3] Memory/SDHCI/ParallelFlash patches for v7.2.0-rc0
2022-11-08 20:57 ` Stefan Hajnoczi
@ 2022-11-09 7:43 ` Philippe Mathieu-Daudé
2023-12-21 21:19 ` Salvatore Bonaccorso
0 siblings, 1 reply; 8+ messages in thread
From: Philippe Mathieu-Daudé @ 2022-11-09 7:43 UTC (permalink / raw)
To: Stefan Hajnoczi
Cc: qemu-devel, Bin Meng, Hanna Reitz, David Hildenbrand, Kevin Wolf,
qemu-block, Peter Xu, Paolo Bonzini
On 8/11/22 21:57, Stefan Hajnoczi wrote:
> I've dropped the SDHCI CVE fix due to the CI failure.
>
> The rest of the commits are still in the staging tree and I plan to
> include them in v7.2.0-rc0.
Thank you Stefan, sorry for not catching that failure sooner.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PULL 0/3] Memory/SDHCI/ParallelFlash patches for v7.2.0-rc0
2022-11-09 7:43 ` Philippe Mathieu-Daudé
@ 2023-12-21 21:19 ` Salvatore Bonaccorso
0 siblings, 0 replies; 8+ messages in thread
From: Salvatore Bonaccorso @ 2023-12-21 21:19 UTC (permalink / raw)
To: Philippe Mathieu-Daudé
Cc: Stefan Hajnoczi, qemu-devel, Bin Meng, Hanna Reitz,
David Hildenbrand, Kevin Wolf, qemu-block, Peter Xu,
Paolo Bonzini
Hi Philippe,
On Wed, Nov 09, 2022 at 08:43:19AM +0100, Philippe Mathieu-Daudé wrote:
> On 8/11/22 21:57, Stefan Hajnoczi wrote:
> > I've dropped the SDHCI CVE fix due to the CI failure.
> >
> > The rest of the commits are still in the staging tree and I plan to
> > include them in v7.2.0-rc0.
>
> Thank you Stefan, sorry for not catching that failure sooner.
I was looking through some older CVE's for qemu which are tracked
still unfixed in Debian and noticed CVE-2022-3872 . Do you happen to
know if the fix for CVE-2022-3872, the dropped one above, was ever
fixed in another way? Or did that felt trough the cracks?
Regards,
Salvatore
^ permalink raw reply [flat|nested] 8+ messages in thread