Re: [PATCH] hw/sd/sdhci: Do not modify BlockSizeRegister if transaction in progress
On 210211 2045, Philippe Mathieu-Daudé wrote: > Hi Alexander, > > On 2/11/21 6:04 PM, Alexander Bulekov wrote: > > On 210208 2034, Philippe Mathieu-Daudé wrote: > >> Per the "SD Host Controller Simplified Specification Version 2.00" > >> spec. 'Table 2-4 : Block Size Register': > >> > >> Transfer Block Size [...] can be accessed only if no > >> transaction is executing (i.e., after a transaction has stopped). > >> Read operations during transfers may return an invalid value, > >> and write operations shall be ignored. > >> > >> Transactions will update 'data_count', so do not modify 'blksize' > >> and 'blkcnt' when 'data_count' is used. This fixes: > >> > >> $ cat << EOF | qemu-system-x86_64 -qtest stdio -monitor none \ > >>-nographic -serial none -M pc-q35-5.0 \ > >>-device sdhci-pci,sd-spec-version=3 \ > >>-device sd-card,drive=mydrive \ > >>-drive if=sd,index=0,file=null-co://,format=raw,id=mydrive > >> outl 0xcf8 0x80001810 > >> outl 0xcfc 0xe1068000 > >> outl 0xcf8 0x80001814 > >> outl 0xcf8 0x80001804 > >> outw 0xcfc 0x7 > >> outl 0xcf8 0x8000fa20 > >> write 0xe106802c 0x1 0x0f > >> write 0xe1068004 0xc 0x2801d10101fbff28a384 > >> write 0xe106800c 0x1f > >> 0x9dacbbcad9e8f7061524334251606f7e8d9cabbac9d8e7f60514233241505f > >> write 0xe1068003 0x28 > >> 0x80d000251480d000252280d000253080d000253e80d000254c80d000255a80d000256880d0002576 > >> write 0xe1068003 0x1 0xfe > >> EOF > >> = > >> ==2686219==ERROR: AddressSanitizer: heap-buffer-overflow on address > >> 0x6153bb00 at pc 0x55ab469f456c bp 0x7ffee71be330 sp 0x7ffee71bdae0 > >> WRITE of size 4 at 0x6153bb00 thread T0 > >> #0 0x55ab469f456b in __asan_memcpy (qemu-system-i386+0x1cea56b) > >> #1 0x55ab483dc396 in stl_he_p include/qemu/bswap.h:353:5 > >> #2 0x55ab483af5e4 in stn_he_p include/qemu/bswap.h:546:1 > >> #3 0x55ab483aeb4b in flatview_read_continue softmmu/physmem.c:2839:13 > >> #4 0x55ab483b0705 in flatview_read softmmu/physmem.c:2877:12 > >> #5 0x55ab483b028e in address_space_read_full > >> softmmu/physmem.c:2890:18 > >> #6 0x55ab483b1294 in address_space_rw softmmu/physmem.c:2918:16 > >> #7 0x55ab479374a2 in dma_memory_rw_relaxed include/sysemu/dma.h:88:12 > >> #8 0x55ab47936f50 in dma_memory_rw include/sysemu/dma.h:127:12 > >> #9 0x55ab4793665f in dma_memory_read include/sysemu/dma.h:145:12 > >> #10 0x55ab4792f176 in sdhci_sdma_transfer_multi_blocks > >> hw/sd/sdhci.c:639:13 > >> #11 0x55ab4793dc9d in sdhci_write hw/sd/sdhci.c:1129:17 > >> #12 0x55ab483f8db8 in memory_region_write_accessor > >> softmmu/memory.c:491:5 > >> #13 0x55ab483f868a in access_with_adjusted_size > >> softmmu/memory.c:552:18 > >> #14 0x55ab483f6da5 in memory_region_dispatch_write > >> softmmu/memory.c:1501:16 > >> #15 0x55ab483c3b11 in flatview_write_continue > >> softmmu/physmem.c:2774:23 > >> #16 0x55ab483b0eb6 in flatview_write softmmu/physmem.c:2814:14 > >> #17 0x55ab483b0a3e in address_space_write softmmu/physmem.c:2906:18 > >> #18 0x55ab48465c56 in qtest_process_command softmmu/qtest.c:654:9 > >> > >> 0x6153bb00 is located 0 bytes to the right of 512-byte region > >> [0x6153b900,0x6153bb00) > >> allocated by thread T0 here: > >> #0 0x55ab469f58a7 in calloc (qemu-system-i386+0x1ceb8a7) > >> #1 0x7f21d678f9b0 in g_malloc0 (/lib64/libglib-2.0.so.0+0x589b0) > >> #2 0x55ab479530ed in sdhci_pci_realize hw/sd/sdhci-pci.c:36:5 > >> #3 0x55ab476f102a in pci_qdev_realize hw/pci/pci.c:2108:9 > >> #4 0x55ab48baaad2 in device_set_realized hw/core/qdev.c:761:13 > >> > >> SUMMARY: AddressSanitizer: heap-buffer-overflow > >> (qemu-system-i386+0x1cea56b) in __asan_memcpy > >> Shadow bytes around the buggy address: > >> 0x0c2a7710: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > >> 0x0c2a7720: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > >> 0x0c2a7730: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > >> 0x0c2a7740: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > >> 0x0c2a7750: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > >> =>0x0c2a7760:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > >> 0x0c2a7770: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > >> 0x0c2a7780: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > >> 0x0c2a7790: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > >> 0x0c2a77a0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > >> 0x0c2a77b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > >> Shadow byte legend (one shadow byte represents 8 application bytes): > >> Addressable: 00 > >> Heap left redzone: fa > >> Freed heap region: fd > >> ==2686219==ABORTING > >> > >> Fixes: CVE-2
Re: [PATCH] hw/sd/sdhci: Do not modify BlockSizeRegister if transaction in progress
Hi Alexander, On 2/11/21 6:04 PM, Alexander Bulekov wrote: > On 210208 2034, Philippe Mathieu-Daudé wrote: >> Per the "SD Host Controller Simplified Specification Version 2.00" >> spec. 'Table 2-4 : Block Size Register': >> >> Transfer Block Size [...] can be accessed only if no >> transaction is executing (i.e., after a transaction has stopped). >> Read operations during transfers may return an invalid value, >> and write operations shall be ignored. >> >> Transactions will update 'data_count', so do not modify 'blksize' >> and 'blkcnt' when 'data_count' is used. This fixes: >> >> $ cat << EOF | qemu-system-x86_64 -qtest stdio -monitor none \ >>-nographic -serial none -M pc-q35-5.0 \ >>-device sdhci-pci,sd-spec-version=3 \ >>-device sd-card,drive=mydrive \ >>-drive if=sd,index=0,file=null-co://,format=raw,id=mydrive >> outl 0xcf8 0x80001810 >> outl 0xcfc 0xe1068000 >> outl 0xcf8 0x80001814 >> outl 0xcf8 0x80001804 >> outw 0xcfc 0x7 >> outl 0xcf8 0x8000fa20 >> write 0xe106802c 0x1 0x0f >> write 0xe1068004 0xc 0x2801d10101fbff28a384 >> write 0xe106800c 0x1f >> 0x9dacbbcad9e8f7061524334251606f7e8d9cabbac9d8e7f60514233241505f >> write 0xe1068003 0x28 >> 0x80d000251480d000252280d000253080d000253e80d000254c80d000255a80d000256880d0002576 >> write 0xe1068003 0x1 0xfe >> EOF >> = >> ==2686219==ERROR: AddressSanitizer: heap-buffer-overflow on address >> 0x6153bb00 at pc 0x55ab469f456c bp 0x7ffee71be330 sp 0x7ffee71bdae0 >> WRITE of size 4 at 0x6153bb00 thread T0 >> #0 0x55ab469f456b in __asan_memcpy (qemu-system-i386+0x1cea56b) >> #1 0x55ab483dc396 in stl_he_p include/qemu/bswap.h:353:5 >> #2 0x55ab483af5e4 in stn_he_p include/qemu/bswap.h:546:1 >> #3 0x55ab483aeb4b in flatview_read_continue softmmu/physmem.c:2839:13 >> #4 0x55ab483b0705 in flatview_read softmmu/physmem.c:2877:12 >> #5 0x55ab483b028e in address_space_read_full softmmu/physmem.c:2890:18 >> #6 0x55ab483b1294 in address_space_rw softmmu/physmem.c:2918:16 >> #7 0x55ab479374a2 in dma_memory_rw_relaxed include/sysemu/dma.h:88:12 >> #8 0x55ab47936f50 in dma_memory_rw include/sysemu/dma.h:127:12 >> #9 0x55ab4793665f in dma_memory_read include/sysemu/dma.h:145:12 >> #10 0x55ab4792f176 in sdhci_sdma_transfer_multi_blocks >> hw/sd/sdhci.c:639:13 >> #11 0x55ab4793dc9d in sdhci_write hw/sd/sdhci.c:1129:17 >> #12 0x55ab483f8db8 in memory_region_write_accessor >> softmmu/memory.c:491:5 >> #13 0x55ab483f868a in access_with_adjusted_size softmmu/memory.c:552:18 >> #14 0x55ab483f6da5 in memory_region_dispatch_write >> softmmu/memory.c:1501:16 >> #15 0x55ab483c3b11 in flatview_write_continue softmmu/physmem.c:2774:23 >> #16 0x55ab483b0eb6 in flatview_write softmmu/physmem.c:2814:14 >> #17 0x55ab483b0a3e in address_space_write softmmu/physmem.c:2906:18 >> #18 0x55ab48465c56 in qtest_process_command softmmu/qtest.c:654:9 >> >> 0x6153bb00 is located 0 bytes to the right of 512-byte region >> [0x6153b900,0x6153bb00) >> allocated by thread T0 here: >> #0 0x55ab469f58a7 in calloc (qemu-system-i386+0x1ceb8a7) >> #1 0x7f21d678f9b0 in g_malloc0 (/lib64/libglib-2.0.so.0+0x589b0) >> #2 0x55ab479530ed in sdhci_pci_realize hw/sd/sdhci-pci.c:36:5 >> #3 0x55ab476f102a in pci_qdev_realize hw/pci/pci.c:2108:9 >> #4 0x55ab48baaad2 in device_set_realized hw/core/qdev.c:761:13 >> >> SUMMARY: AddressSanitizer: heap-buffer-overflow >> (qemu-system-i386+0x1cea56b) in __asan_memcpy >> Shadow bytes around the buggy address: >> 0x0c2a7710: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa >> 0x0c2a7720: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 0x0c2a7730: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 0x0c2a7740: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 0x0c2a7750: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> =>0x0c2a7760:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa >> 0x0c2a7770: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd >> 0x0c2a7780: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd >> 0x0c2a7790: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd >> 0x0c2a77a0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd >> 0x0c2a77b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa >> Shadow byte legend (one shadow byte represents 8 application bytes): >> Addressable: 00 >> Heap left redzone: fa >> Freed heap region: fd >> ==2686219==ABORTING >> >> Fixes: CVE-2020-17380 >> Fixes: CVE-2020-25085 >> Signed-off-by: Philippe Mathieu-Daudé > > I applied this along with > <1612868085-72809-1-git-send-email-bmeng...@gmail.com> > "hw/sd: sdhci: Do not transfer any data when command fails" > > I ran through
Re: [PATCH] hw/sd/sdhci: Do not modify BlockSizeRegister if transaction in progress
On 210208 2034, Philippe Mathieu-Daudé wrote: > Per the "SD Host Controller Simplified Specification Version 2.00" > spec. 'Table 2-4 : Block Size Register': > > Transfer Block Size [...] can be accessed only if no > transaction is executing (i.e., after a transaction has stopped). > Read operations during transfers may return an invalid value, > and write operations shall be ignored. > > Transactions will update 'data_count', so do not modify 'blksize' > and 'blkcnt' when 'data_count' is used. This fixes: > > $ cat << EOF | qemu-system-x86_64 -qtest stdio -monitor none \ >-nographic -serial none -M pc-q35-5.0 \ >-device sdhci-pci,sd-spec-version=3 \ >-device sd-card,drive=mydrive \ >-drive if=sd,index=0,file=null-co://,format=raw,id=mydrive > outl 0xcf8 0x80001810 > outl 0xcfc 0xe1068000 > outl 0xcf8 0x80001814 > outl 0xcf8 0x80001804 > outw 0xcfc 0x7 > outl 0xcf8 0x8000fa20 > write 0xe106802c 0x1 0x0f > write 0xe1068004 0xc 0x2801d10101fbff28a384 > write 0xe106800c 0x1f > 0x9dacbbcad9e8f7061524334251606f7e8d9cabbac9d8e7f60514233241505f > write 0xe1068003 0x28 > 0x80d000251480d000252280d000253080d000253e80d000254c80d000255a80d000256880d0002576 > write 0xe1068003 0x1 0xfe > EOF > = > ==2686219==ERROR: AddressSanitizer: heap-buffer-overflow on address > 0x6153bb00 at pc 0x55ab469f456c bp 0x7ffee71be330 sp 0x7ffee71bdae0 > WRITE of size 4 at 0x6153bb00 thread T0 > #0 0x55ab469f456b in __asan_memcpy (qemu-system-i386+0x1cea56b) > #1 0x55ab483dc396 in stl_he_p include/qemu/bswap.h:353:5 > #2 0x55ab483af5e4 in stn_he_p include/qemu/bswap.h:546:1 > #3 0x55ab483aeb4b in flatview_read_continue softmmu/physmem.c:2839:13 > #4 0x55ab483b0705 in flatview_read softmmu/physmem.c:2877:12 > #5 0x55ab483b028e in address_space_read_full softmmu/physmem.c:2890:18 > #6 0x55ab483b1294 in address_space_rw softmmu/physmem.c:2918:16 > #7 0x55ab479374a2 in dma_memory_rw_relaxed include/sysemu/dma.h:88:12 > #8 0x55ab47936f50 in dma_memory_rw include/sysemu/dma.h:127:12 > #9 0x55ab4793665f in dma_memory_read include/sysemu/dma.h:145:12 > #10 0x55ab4792f176 in sdhci_sdma_transfer_multi_blocks > hw/sd/sdhci.c:639:13 > #11 0x55ab4793dc9d in sdhci_write hw/sd/sdhci.c:1129:17 > #12 0x55ab483f8db8 in memory_region_write_accessor > softmmu/memory.c:491:5 > #13 0x55ab483f868a in access_with_adjusted_size softmmu/memory.c:552:18 > #14 0x55ab483f6da5 in memory_region_dispatch_write > softmmu/memory.c:1501:16 > #15 0x55ab483c3b11 in flatview_write_continue softmmu/physmem.c:2774:23 > #16 0x55ab483b0eb6 in flatview_write softmmu/physmem.c:2814:14 > #17 0x55ab483b0a3e in address_space_write softmmu/physmem.c:2906:18 > #18 0x55ab48465c56 in qtest_process_command softmmu/qtest.c:654:9 > > 0x6153bb00 is located 0 bytes to the right of 512-byte region > [0x6153b900,0x6153bb00) > allocated by thread T0 here: > #0 0x55ab469f58a7 in calloc (qemu-system-i386+0x1ceb8a7) > #1 0x7f21d678f9b0 in g_malloc0 (/lib64/libglib-2.0.so.0+0x589b0) > #2 0x55ab479530ed in sdhci_pci_realize hw/sd/sdhci-pci.c:36:5 > #3 0x55ab476f102a in pci_qdev_realize hw/pci/pci.c:2108:9 > #4 0x55ab48baaad2 in device_set_realized hw/core/qdev.c:761:13 > > SUMMARY: AddressSanitizer: heap-buffer-overflow > (qemu-system-i386+0x1cea56b) in __asan_memcpy > Shadow bytes around the buggy address: > 0x0c2a7710: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > 0x0c2a7720: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x0c2a7730: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x0c2a7740: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x0c2a7750: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > =>0x0c2a7760:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > 0x0c2a7770: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > 0x0c2a7780: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > 0x0c2a7790: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > 0x0c2a77a0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > 0x0c2a77b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > Shadow byte legend (one shadow byte represents 8 application bytes): > Addressable: 00 > Heap left redzone: fa > Freed heap region: fd > ==2686219==ABORTING > > Fixes: CVE-2020-17380 > Fixes: CVE-2020-25085 > Signed-off-by: Philippe Mathieu-Daudé I applied this along with <1612868085-72809-1-git-send-email-bmeng...@gmail.com> "hw/sd: sdhci: Do not transfer any data when command fails" I ran through the entire OSS-Fuzz corpus, and could not reproduce the crash. Tested-by: Alexander Bulekov Thanks > --- > Cc: Mauro Matteo Cascella > Cc: Alexander Bule
Re: [PATCH] hw/sd/sdhci: Do not modify BlockSizeRegister if transaction in progress
On 210209 1745, Bin Meng wrote: > Oops, hitting "send" by mistake ... > > On Tue, Feb 9, 2021 at 5:42 PM Bin Meng wrote: > > > > Hi Philippe, > > > > On Tue, Feb 9, 2021 at 5:38 PM Philippe Mathieu-Daudé > > wrote: > > > > > > On 2/9/21 9:28 AM, Bin Meng wrote: > > > > Hi Philippe, > > > > > > > > On Tue, Feb 9, 2021 at 3:34 AM Philippe Mathieu-Daudé > > > > wrote: > > > >> > > > >> Per the "SD Host Controller Simplified Specification Version 2.00" > > > >> spec. 'Table 2-4 : Block Size Register': > > > >> > > > >> Transfer Block Size [...] can be accessed only if no > > > >> transaction is executing (i.e., after a transaction has stopped). > > > >> Read operations during transfers may return an invalid value, > > > >> and write operations shall be ignored. > > > >> > > > >> Transactions will update 'data_count', so do not modify 'blksize' > > > >> and 'blkcnt' when 'data_count' is used. This fixes: > > > >> > > > >> $ cat << EOF | qemu-system-x86_64 -qtest stdio -monitor none \ > > > >>-nographic -serial none -M pc-q35-5.0 \ > > > >>-device sdhci-pci,sd-spec-version=3 \ > > > >>-device sd-card,drive=mydrive \ > > > >>-drive > > > >> if=sd,index=0,file=null-co://,format=raw,id=mydrive > > > >> outl 0xcf8 0x80001810 > > > >> outl 0xcfc 0xe1068000 > > > >> outl 0xcf8 0x80001814 > > > > > > > > Is this command needed? > > > > > > My guess is this makes the northbridge somehow map the device PCI space. > > > > > > Probably not needed in machines where SDHCI is MMIO mapped. > > > > I think this is not needed. Writing only the CFG_ADDR > > I think this is not needed. Writing only the CFG_ADDR without wring > CFG_DATA does not take any effect. > Ran it through scripts/oss-fuzz/minimize_qtest_trace.py , though that's probably not very useful now: cat << EOF | qemu-system-x86_64 -qtest stdio -monitor none \ -nographic -serial none -M pc-q35-5.0 \ -device sdhci-pci,sd-spec-version=3 \ -device sd-card,drive=mydrive \ -drive if=sd,index=0,file=null-co://,format=raw,id=mydrive outl 0xcf8 0x80001810 outl 0xcfc 0xe1068000 outl 0xcf8 0x80001804 outw 0xcfc 0x7 write 0xe106802c 0x1 0x0f write 0xe1068004 0x1 0x20 write 0xe1068005 0x1 0x01 write 0xe1068007 0x1 0x01 write 0xe106800c 0x1 0x33 write 0xe106800e 0x1 0x20 write 0xe106800f 0x1 0x0 write 0xe106800c 0x1 0x0 write 0xe106802a 0x1 0x11 write 0xe1068003 0x1 0x0 write 0xe1068005 0x1 0x00 write 0xe106800c 0x1 0x22 write 0xe106802a 0x1 0x12 write 0xe1068003 0x1 0x10 EOF > > > > > > > > > > > > >> outl 0xcf8 0x80001804 > > > >> outw 0xcfc 0x7 > > > >> outl 0xcf8 0x8000fa20 > > > > > > > > and this one? > > > > > > Ditto. > > > > > > > > > > >> write 0xe106802c 0x1 0x0f > > > >> write 0xe1068004 0xc 0x2801d10101fbff28a384 > > > > > > > > Are these fuzzy data? > > > > > > Yes, I didn't try to understand what this does, as often > > > non-sense operations. But this is what would craft a malicious > > > attacker. > > > > > > > > > > >> write 0xe106800c 0x1f > > > >> 0x9dacbbcad9e8f7061524334251606f7e8d9cabbac9d8e7f60514233241505f > > > >> write 0xe1068003 0x28 > > > >> 0x80d000251480d000252280d000253080d000253e80d000254c80d000255a80d000256880d0002576 > > > >> write 0xe1068003 0x1 0xfe > > > >> EOF > > > >> = > > > >> ==2686219==ERROR: AddressSanitizer: heap-buffer-overflow on address > > > >> 0x6153bb00 at pc 0x55ab469f456c bp 0x7ffee71be330 sp 0x7ffee71bdae0 > > > >> WRITE of size 4 at 0x6153bb00 thread T0 > > > >> #0 0x55ab469f456b in __asan_memcpy (qemu-system-i386+0x1cea56b) > > > >> #1 0x55ab483dc396 in stl_he_p include/qemu/bswap.h:353:5 > > > >> #2 0x55ab483af5e4 in stn_he_p include/qemu/bswap.h:546:1 > > > >> #3 0x55ab483aeb4b in flatview_read_continue > > > >> softmmu/physmem.c:2839:13 > > > >> #4 0x55ab483b0705 in flatview_read softmmu/physmem.c:2877:12 > > > >> #5 0x55ab483b028e in address_space_read_full > > > >> softmmu/physmem.c:2890:18 > > > >> #6 0x55ab483b1294 in address_space_rw softmmu/physmem.c:2918:16 > > > >> #7 0x55ab479374a2 in dma_memory_rw_relaxed > > > >> include/sysemu/dma.h:88:12 > > > >> #8 0x55ab47936f50 in dma_memory_rw include/sysemu/dma.h:127:12 > > > >> #9 0x55ab4793665f in dma_memory_read include/sysemu/dma.h:145:12 > > > >> #10 0x55ab4792f176 in sdhci_sdma_transfer_multi_blocks > > > >> hw/sd/sdhci.c:639:13 > > > >> #11 0x55ab4793dc9d in sdhci_write hw/sd/sdhci.c:1129:17 > > > >> #12 0x55ab483f8db8 in memory_region_write_accessor > > > >> softmmu/memory.c:491:5 > > > >> #13 0x55ab483f868a in access_with_adjusted_size > > > >> softmmu/memory.c:552:18 > > > >> #14 0x55ab483f6da5 in memory_region_dispatch_write > > > >> softmmu/memory.c:1501:16 > > > >> #15 0x55ab483c3b11 in flatview_write_continue > > >
Re: [PATCH] hw/sd/sdhci: Do not modify BlockSizeRegister if transaction in progress
Oops, hitting "send" by mistake ... On Tue, Feb 9, 2021 at 5:42 PM Bin Meng wrote: > > Hi Philippe, > > On Tue, Feb 9, 2021 at 5:38 PM Philippe Mathieu-Daudé wrote: > > > > On 2/9/21 9:28 AM, Bin Meng wrote: > > > Hi Philippe, > > > > > > On Tue, Feb 9, 2021 at 3:34 AM Philippe Mathieu-Daudé > > > wrote: > > >> > > >> Per the "SD Host Controller Simplified Specification Version 2.00" > > >> spec. 'Table 2-4 : Block Size Register': > > >> > > >> Transfer Block Size [...] can be accessed only if no > > >> transaction is executing (i.e., after a transaction has stopped). > > >> Read operations during transfers may return an invalid value, > > >> and write operations shall be ignored. > > >> > > >> Transactions will update 'data_count', so do not modify 'blksize' > > >> and 'blkcnt' when 'data_count' is used. This fixes: > > >> > > >> $ cat << EOF | qemu-system-x86_64 -qtest stdio -monitor none \ > > >>-nographic -serial none -M pc-q35-5.0 \ > > >>-device sdhci-pci,sd-spec-version=3 \ > > >>-device sd-card,drive=mydrive \ > > >>-drive if=sd,index=0,file=null-co://,format=raw,id=mydrive > > >> outl 0xcf8 0x80001810 > > >> outl 0xcfc 0xe1068000 > > >> outl 0xcf8 0x80001814 > > > > > > Is this command needed? > > > > My guess is this makes the northbridge somehow map the device PCI space. > > > > Probably not needed in machines where SDHCI is MMIO mapped. > > I think this is not needed. Writing only the CFG_ADDR I think this is not needed. Writing only the CFG_ADDR without wring CFG_DATA does not take any effect. > > > > > > > > >> outl 0xcf8 0x80001804 > > >> outw 0xcfc 0x7 > > >> outl 0xcf8 0x8000fa20 > > > > > > and this one? > > > > Ditto. > > > > > > > >> write 0xe106802c 0x1 0x0f > > >> write 0xe1068004 0xc 0x2801d10101fbff28a384 > > > > > > Are these fuzzy data? > > > > Yes, I didn't try to understand what this does, as often > > non-sense operations. But this is what would craft a malicious > > attacker. > > > > > > > >> write 0xe106800c 0x1f > > >> 0x9dacbbcad9e8f7061524334251606f7e8d9cabbac9d8e7f60514233241505f > > >> write 0xe1068003 0x28 > > >> 0x80d000251480d000252280d000253080d000253e80d000254c80d000255a80d000256880d0002576 > > >> write 0xe1068003 0x1 0xfe > > >> EOF > > >> = > > >> ==2686219==ERROR: AddressSanitizer: heap-buffer-overflow on address > > >> 0x6153bb00 at pc 0x55ab469f456c bp 0x7ffee71be330 sp 0x7ffee71bdae0 > > >> WRITE of size 4 at 0x6153bb00 thread T0 > > >> #0 0x55ab469f456b in __asan_memcpy (qemu-system-i386+0x1cea56b) > > >> #1 0x55ab483dc396 in stl_he_p include/qemu/bswap.h:353:5 > > >> #2 0x55ab483af5e4 in stn_he_p include/qemu/bswap.h:546:1 > > >> #3 0x55ab483aeb4b in flatview_read_continue > > >> softmmu/physmem.c:2839:13 > > >> #4 0x55ab483b0705 in flatview_read softmmu/physmem.c:2877:12 > > >> #5 0x55ab483b028e in address_space_read_full > > >> softmmu/physmem.c:2890:18 > > >> #6 0x55ab483b1294 in address_space_rw softmmu/physmem.c:2918:16 > > >> #7 0x55ab479374a2 in dma_memory_rw_relaxed > > >> include/sysemu/dma.h:88:12 > > >> #8 0x55ab47936f50 in dma_memory_rw include/sysemu/dma.h:127:12 > > >> #9 0x55ab4793665f in dma_memory_read include/sysemu/dma.h:145:12 > > >> #10 0x55ab4792f176 in sdhci_sdma_transfer_multi_blocks > > >> hw/sd/sdhci.c:639:13 > > >> #11 0x55ab4793dc9d in sdhci_write hw/sd/sdhci.c:1129:17 > > >> #12 0x55ab483f8db8 in memory_region_write_accessor > > >> softmmu/memory.c:491:5 > > >> #13 0x55ab483f868a in access_with_adjusted_size > > >> softmmu/memory.c:552:18 > > >> #14 0x55ab483f6da5 in memory_region_dispatch_write > > >> softmmu/memory.c:1501:16 > > >> #15 0x55ab483c3b11 in flatview_write_continue > > >> softmmu/physmem.c:2774:23 > > >> #16 0x55ab483b0eb6 in flatview_write softmmu/physmem.c:2814:14 > > >> #17 0x55ab483b0a3e in address_space_write softmmu/physmem.c:2906:18 > > >> #18 0x55ab48465c56 in qtest_process_command softmmu/qtest.c:654:9 > > >> > > >> 0x6153bb00 is located 0 bytes to the right of 512-byte region > > >> [0x6153b900,0x6153bb00) > > >> allocated by thread T0 here: > > >> #0 0x55ab469f58a7 in calloc (qemu-system-i386+0x1ceb8a7) > > >> #1 0x7f21d678f9b0 in g_malloc0 (/lib64/libglib-2.0.so.0+0x589b0) > > >> #2 0x55ab479530ed in sdhci_pci_realize hw/sd/sdhci-pci.c:36:5 > > >> #3 0x55ab476f102a in pci_qdev_realize hw/pci/pci.c:2108:9 > > >> #4 0x55ab48baaad2 in device_set_realized hw/core/qdev.c:761:13 > > >> > > >> SUMMARY: AddressSanitizer: heap-buffer-overflow > > >> (qemu-system-i386+0x1cea56b) in __asan_memcpy > > >> Shadow bytes around the buggy address: > > >> 0x0c2a7710: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > > >> 0x0c2a7720: 00 00 00 00 00 00
Re: [PATCH] hw/sd/sdhci: Do not modify BlockSizeRegister if transaction in progress
Hi Philippe, On Tue, Feb 9, 2021 at 5:38 PM Philippe Mathieu-Daudé wrote: > > On 2/9/21 9:28 AM, Bin Meng wrote: > > Hi Philippe, > > > > On Tue, Feb 9, 2021 at 3:34 AM Philippe Mathieu-Daudé > > wrote: > >> > >> Per the "SD Host Controller Simplified Specification Version 2.00" > >> spec. 'Table 2-4 : Block Size Register': > >> > >> Transfer Block Size [...] can be accessed only if no > >> transaction is executing (i.e., after a transaction has stopped). > >> Read operations during transfers may return an invalid value, > >> and write operations shall be ignored. > >> > >> Transactions will update 'data_count', so do not modify 'blksize' > >> and 'blkcnt' when 'data_count' is used. This fixes: > >> > >> $ cat << EOF | qemu-system-x86_64 -qtest stdio -monitor none \ > >>-nographic -serial none -M pc-q35-5.0 \ > >>-device sdhci-pci,sd-spec-version=3 \ > >>-device sd-card,drive=mydrive \ > >>-drive if=sd,index=0,file=null-co://,format=raw,id=mydrive > >> outl 0xcf8 0x80001810 > >> outl 0xcfc 0xe1068000 > >> outl 0xcf8 0x80001814 > > > > Is this command needed? > > My guess is this makes the northbridge somehow map the device PCI space. > > Probably not needed in machines where SDHCI is MMIO mapped. I think this is not needed. Writing only the CFG_ADDR > > > > >> outl 0xcf8 0x80001804 > >> outw 0xcfc 0x7 > >> outl 0xcf8 0x8000fa20 > > > > and this one? > > Ditto. > > > > >> write 0xe106802c 0x1 0x0f > >> write 0xe1068004 0xc 0x2801d10101fbff28a384 > > > > Are these fuzzy data? > > Yes, I didn't try to understand what this does, as often > non-sense operations. But this is what would craft a malicious > attacker. > > > > >> write 0xe106800c 0x1f > >> 0x9dacbbcad9e8f7061524334251606f7e8d9cabbac9d8e7f60514233241505f > >> write 0xe1068003 0x28 > >> 0x80d000251480d000252280d000253080d000253e80d000254c80d000255a80d000256880d0002576 > >> write 0xe1068003 0x1 0xfe > >> EOF > >> = > >> ==2686219==ERROR: AddressSanitizer: heap-buffer-overflow on address > >> 0x6153bb00 at pc 0x55ab469f456c bp 0x7ffee71be330 sp 0x7ffee71bdae0 > >> WRITE of size 4 at 0x6153bb00 thread T0 > >> #0 0x55ab469f456b in __asan_memcpy (qemu-system-i386+0x1cea56b) > >> #1 0x55ab483dc396 in stl_he_p include/qemu/bswap.h:353:5 > >> #2 0x55ab483af5e4 in stn_he_p include/qemu/bswap.h:546:1 > >> #3 0x55ab483aeb4b in flatview_read_continue softmmu/physmem.c:2839:13 > >> #4 0x55ab483b0705 in flatview_read softmmu/physmem.c:2877:12 > >> #5 0x55ab483b028e in address_space_read_full > >> softmmu/physmem.c:2890:18 > >> #6 0x55ab483b1294 in address_space_rw softmmu/physmem.c:2918:16 > >> #7 0x55ab479374a2 in dma_memory_rw_relaxed include/sysemu/dma.h:88:12 > >> #8 0x55ab47936f50 in dma_memory_rw include/sysemu/dma.h:127:12 > >> #9 0x55ab4793665f in dma_memory_read include/sysemu/dma.h:145:12 > >> #10 0x55ab4792f176 in sdhci_sdma_transfer_multi_blocks > >> hw/sd/sdhci.c:639:13 > >> #11 0x55ab4793dc9d in sdhci_write hw/sd/sdhci.c:1129:17 > >> #12 0x55ab483f8db8 in memory_region_write_accessor > >> softmmu/memory.c:491:5 > >> #13 0x55ab483f868a in access_with_adjusted_size > >> softmmu/memory.c:552:18 > >> #14 0x55ab483f6da5 in memory_region_dispatch_write > >> softmmu/memory.c:1501:16 > >> #15 0x55ab483c3b11 in flatview_write_continue > >> softmmu/physmem.c:2774:23 > >> #16 0x55ab483b0eb6 in flatview_write softmmu/physmem.c:2814:14 > >> #17 0x55ab483b0a3e in address_space_write softmmu/physmem.c:2906:18 > >> #18 0x55ab48465c56 in qtest_process_command softmmu/qtest.c:654:9 > >> > >> 0x6153bb00 is located 0 bytes to the right of 512-byte region > >> [0x6153b900,0x6153bb00) > >> allocated by thread T0 here: > >> #0 0x55ab469f58a7 in calloc (qemu-system-i386+0x1ceb8a7) > >> #1 0x7f21d678f9b0 in g_malloc0 (/lib64/libglib-2.0.so.0+0x589b0) > >> #2 0x55ab479530ed in sdhci_pci_realize hw/sd/sdhci-pci.c:36:5 > >> #3 0x55ab476f102a in pci_qdev_realize hw/pci/pci.c:2108:9 > >> #4 0x55ab48baaad2 in device_set_realized hw/core/qdev.c:761:13 > >> > >> SUMMARY: AddressSanitizer: heap-buffer-overflow > >> (qemu-system-i386+0x1cea56b) in __asan_memcpy > >> Shadow bytes around the buggy address: > >> 0x0c2a7710: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > >> 0x0c2a7720: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > >> 0x0c2a7730: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > >> 0x0c2a7740: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > >> 0x0c2a7750: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > >> =>0x0c2a7760:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > >> 0x0c2a7770: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > >> 0x0c2a7780: fd
Re: [PATCH] hw/sd/sdhci: Do not modify BlockSizeRegister if transaction in progress
On 2/9/21 9:28 AM, Bin Meng wrote: > Hi Philippe, > > On Tue, Feb 9, 2021 at 3:34 AM Philippe Mathieu-Daudé wrote: >> >> Per the "SD Host Controller Simplified Specification Version 2.00" >> spec. 'Table 2-4 : Block Size Register': >> >> Transfer Block Size [...] can be accessed only if no >> transaction is executing (i.e., after a transaction has stopped). >> Read operations during transfers may return an invalid value, >> and write operations shall be ignored. >> >> Transactions will update 'data_count', so do not modify 'blksize' >> and 'blkcnt' when 'data_count' is used. This fixes: >> >> $ cat << EOF | qemu-system-x86_64 -qtest stdio -monitor none \ >>-nographic -serial none -M pc-q35-5.0 \ >>-device sdhci-pci,sd-spec-version=3 \ >>-device sd-card,drive=mydrive \ >>-drive if=sd,index=0,file=null-co://,format=raw,id=mydrive >> outl 0xcf8 0x80001810 >> outl 0xcfc 0xe1068000 >> outl 0xcf8 0x80001814 > > Is this command needed? My guess is this makes the northbridge somehow map the device PCI space. Probably not needed in machines where SDHCI is MMIO mapped. > >> outl 0xcf8 0x80001804 >> outw 0xcfc 0x7 >> outl 0xcf8 0x8000fa20 > > and this one? Ditto. > >> write 0xe106802c 0x1 0x0f >> write 0xe1068004 0xc 0x2801d10101fbff28a384 > > Are these fuzzy data? Yes, I didn't try to understand what this does, as often non-sense operations. But this is what would craft a malicious attacker. > >> write 0xe106800c 0x1f >> 0x9dacbbcad9e8f7061524334251606f7e8d9cabbac9d8e7f60514233241505f >> write 0xe1068003 0x28 >> 0x80d000251480d000252280d000253080d000253e80d000254c80d000255a80d000256880d0002576 >> write 0xe1068003 0x1 0xfe >> EOF >> = >> ==2686219==ERROR: AddressSanitizer: heap-buffer-overflow on address >> 0x6153bb00 at pc 0x55ab469f456c bp 0x7ffee71be330 sp 0x7ffee71bdae0 >> WRITE of size 4 at 0x6153bb00 thread T0 >> #0 0x55ab469f456b in __asan_memcpy (qemu-system-i386+0x1cea56b) >> #1 0x55ab483dc396 in stl_he_p include/qemu/bswap.h:353:5 >> #2 0x55ab483af5e4 in stn_he_p include/qemu/bswap.h:546:1 >> #3 0x55ab483aeb4b in flatview_read_continue softmmu/physmem.c:2839:13 >> #4 0x55ab483b0705 in flatview_read softmmu/physmem.c:2877:12 >> #5 0x55ab483b028e in address_space_read_full softmmu/physmem.c:2890:18 >> #6 0x55ab483b1294 in address_space_rw softmmu/physmem.c:2918:16 >> #7 0x55ab479374a2 in dma_memory_rw_relaxed include/sysemu/dma.h:88:12 >> #8 0x55ab47936f50 in dma_memory_rw include/sysemu/dma.h:127:12 >> #9 0x55ab4793665f in dma_memory_read include/sysemu/dma.h:145:12 >> #10 0x55ab4792f176 in sdhci_sdma_transfer_multi_blocks >> hw/sd/sdhci.c:639:13 >> #11 0x55ab4793dc9d in sdhci_write hw/sd/sdhci.c:1129:17 >> #12 0x55ab483f8db8 in memory_region_write_accessor >> softmmu/memory.c:491:5 >> #13 0x55ab483f868a in access_with_adjusted_size softmmu/memory.c:552:18 >> #14 0x55ab483f6da5 in memory_region_dispatch_write >> softmmu/memory.c:1501:16 >> #15 0x55ab483c3b11 in flatview_write_continue softmmu/physmem.c:2774:23 >> #16 0x55ab483b0eb6 in flatview_write softmmu/physmem.c:2814:14 >> #17 0x55ab483b0a3e in address_space_write softmmu/physmem.c:2906:18 >> #18 0x55ab48465c56 in qtest_process_command softmmu/qtest.c:654:9 >> >> 0x6153bb00 is located 0 bytes to the right of 512-byte region >> [0x6153b900,0x6153bb00) >> allocated by thread T0 here: >> #0 0x55ab469f58a7 in calloc (qemu-system-i386+0x1ceb8a7) >> #1 0x7f21d678f9b0 in g_malloc0 (/lib64/libglib-2.0.so.0+0x589b0) >> #2 0x55ab479530ed in sdhci_pci_realize hw/sd/sdhci-pci.c:36:5 >> #3 0x55ab476f102a in pci_qdev_realize hw/pci/pci.c:2108:9 >> #4 0x55ab48baaad2 in device_set_realized hw/core/qdev.c:761:13 >> >> SUMMARY: AddressSanitizer: heap-buffer-overflow >> (qemu-system-i386+0x1cea56b) in __asan_memcpy >> Shadow bytes around the buggy address: >> 0x0c2a7710: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa >> 0x0c2a7720: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 0x0c2a7730: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 0x0c2a7740: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> 0x0c2a7750: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >> =>0x0c2a7760:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa >> 0x0c2a7770: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd >> 0x0c2a7780: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd >> 0x0c2a7790: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd >> 0x0c2a77a0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd >> 0x0c2a77b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa >> Shadow byte legend (one shadow byte represents 8 application bytes): >> Addressable:
Re: [PATCH] hw/sd/sdhci: Do not modify BlockSizeRegister if transaction in progress
On Mon, Feb 8, 2021 at 9:26 PM Philippe Mathieu-Daudé wrote: > > On Mon, Feb 8, 2021 at 8:59 PM Mauro Matteo Cascella > wrote: > > On Mon, Feb 8, 2021 at 8:35 PM Philippe Mathieu-Daudé > > wrote: > > > > > > Per the "SD Host Controller Simplified Specification Version 2.00" > > > spec. 'Table 2-4 : Block Size Register': > > > > > > Transfer Block Size [...] can be accessed only if no > > > transaction is executing (i.e., after a transaction has stopped). > > > Read operations during transfers may return an invalid value, > > > and write operations shall be ignored. > > > > ... > > > > > > Fixes: CVE-2020-17380 > > > Fixes: CVE-2020-25085 > > > Signed-off-by: Philippe Mathieu-Daudé > > > --- > > > Cc: Mauro Matteo Cascella > > > Cc: Alexander Bulekov > > > Cc: Alistair Francis > > > Cc: Prasad J Pandit > > > Cc: Bandan Das > > > > > > RFC because missing Reported-by tags, launchpad/bugzilla links and > > > qtest reproducer. Sending for review meanwhile. > ... > > For the above CVEs: > > Tested-by: Mauro Matteo Cascella > > Thanks Mauro for testing. Do you know what tags I should add for the credits? > > Phil. > I think the credit should go to Alexander for reporting [1] as well as people from Ruhr-University Bochum for CVE-2020-25085 (I don't know about their emails, though): Reported-by: Alexander Bulekov Reported-by: Sergej Schumilo (Ruhr-University Bochum) Reported-by: Cornelius Aschermann (Ruhr-University Bochum) Reported-by: Simon Wrner (Ruhr-University Bochum) [1] https://bugs.launchpad.net/qemu/+bug/1892960 -- Mauro Matteo Cascella Red Hat Product Security PGP-Key ID: BB3410B0
Re: [PATCH] hw/sd/sdhci: Do not modify BlockSizeRegister if transaction in progress
Hi Philippe, On Tue, Feb 9, 2021 at 3:34 AM Philippe Mathieu-Daudé wrote: > > Per the "SD Host Controller Simplified Specification Version 2.00" > spec. 'Table 2-4 : Block Size Register': > > Transfer Block Size [...] can be accessed only if no > transaction is executing (i.e., after a transaction has stopped). > Read operations during transfers may return an invalid value, > and write operations shall be ignored. > > Transactions will update 'data_count', so do not modify 'blksize' > and 'blkcnt' when 'data_count' is used. This fixes: > > $ cat << EOF | qemu-system-x86_64 -qtest stdio -monitor none \ >-nographic -serial none -M pc-q35-5.0 \ >-device sdhci-pci,sd-spec-version=3 \ >-device sd-card,drive=mydrive \ >-drive if=sd,index=0,file=null-co://,format=raw,id=mydrive > outl 0xcf8 0x80001810 > outl 0xcfc 0xe1068000 > outl 0xcf8 0x80001814 Is this command needed? > outl 0xcf8 0x80001804 > outw 0xcfc 0x7 > outl 0xcf8 0x8000fa20 and this one? > write 0xe106802c 0x1 0x0f > write 0xe1068004 0xc 0x2801d10101fbff28a384 Are these fuzzy data? > write 0xe106800c 0x1f > 0x9dacbbcad9e8f7061524334251606f7e8d9cabbac9d8e7f60514233241505f > write 0xe1068003 0x28 > 0x80d000251480d000252280d000253080d000253e80d000254c80d000255a80d000256880d0002576 > write 0xe1068003 0x1 0xfe > EOF > = > ==2686219==ERROR: AddressSanitizer: heap-buffer-overflow on address > 0x6153bb00 at pc 0x55ab469f456c bp 0x7ffee71be330 sp 0x7ffee71bdae0 > WRITE of size 4 at 0x6153bb00 thread T0 > #0 0x55ab469f456b in __asan_memcpy (qemu-system-i386+0x1cea56b) > #1 0x55ab483dc396 in stl_he_p include/qemu/bswap.h:353:5 > #2 0x55ab483af5e4 in stn_he_p include/qemu/bswap.h:546:1 > #3 0x55ab483aeb4b in flatview_read_continue softmmu/physmem.c:2839:13 > #4 0x55ab483b0705 in flatview_read softmmu/physmem.c:2877:12 > #5 0x55ab483b028e in address_space_read_full softmmu/physmem.c:2890:18 > #6 0x55ab483b1294 in address_space_rw softmmu/physmem.c:2918:16 > #7 0x55ab479374a2 in dma_memory_rw_relaxed include/sysemu/dma.h:88:12 > #8 0x55ab47936f50 in dma_memory_rw include/sysemu/dma.h:127:12 > #9 0x55ab4793665f in dma_memory_read include/sysemu/dma.h:145:12 > #10 0x55ab4792f176 in sdhci_sdma_transfer_multi_blocks > hw/sd/sdhci.c:639:13 > #11 0x55ab4793dc9d in sdhci_write hw/sd/sdhci.c:1129:17 > #12 0x55ab483f8db8 in memory_region_write_accessor > softmmu/memory.c:491:5 > #13 0x55ab483f868a in access_with_adjusted_size softmmu/memory.c:552:18 > #14 0x55ab483f6da5 in memory_region_dispatch_write > softmmu/memory.c:1501:16 > #15 0x55ab483c3b11 in flatview_write_continue softmmu/physmem.c:2774:23 > #16 0x55ab483b0eb6 in flatview_write softmmu/physmem.c:2814:14 > #17 0x55ab483b0a3e in address_space_write softmmu/physmem.c:2906:18 > #18 0x55ab48465c56 in qtest_process_command softmmu/qtest.c:654:9 > > 0x6153bb00 is located 0 bytes to the right of 512-byte region > [0x6153b900,0x6153bb00) > allocated by thread T0 here: > #0 0x55ab469f58a7 in calloc (qemu-system-i386+0x1ceb8a7) > #1 0x7f21d678f9b0 in g_malloc0 (/lib64/libglib-2.0.so.0+0x589b0) > #2 0x55ab479530ed in sdhci_pci_realize hw/sd/sdhci-pci.c:36:5 > #3 0x55ab476f102a in pci_qdev_realize hw/pci/pci.c:2108:9 > #4 0x55ab48baaad2 in device_set_realized hw/core/qdev.c:761:13 > > SUMMARY: AddressSanitizer: heap-buffer-overflow > (qemu-system-i386+0x1cea56b) in __asan_memcpy > Shadow bytes around the buggy address: > 0x0c2a7710: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > 0x0c2a7720: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x0c2a7730: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x0c2a7740: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x0c2a7750: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > =>0x0c2a7760:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > 0x0c2a7770: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > 0x0c2a7780: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > 0x0c2a7790: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > 0x0c2a77a0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > 0x0c2a77b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > Shadow byte legend (one shadow byte represents 8 application bytes): > Addressable: 00 > Heap left redzone: fa > Freed heap region: fd > ==2686219==ABORTING > > Fixes: CVE-2020-17380 > Fixes: CVE-2020-25085 > Signed-off-by: Philippe Mathieu-Daudé > --- > Cc: Mauro Matteo Cascella > Cc: Alexander Bulekov > Cc: Alistair Francis > Cc: Prasad J Pandit > Cc: Bandan Das > > RFC because missing Reported-by tags, launchpad/bugzilla links and > qtest reproducer. Sendin
Re: [PATCH] hw/sd/sdhci: Do not modify BlockSizeRegister if transaction in progress
On Mon, Feb 8, 2021 at 8:59 PM Mauro Matteo Cascella wrote: > On Mon, Feb 8, 2021 at 8:35 PM Philippe Mathieu-Daudé wrote: > > > > Per the "SD Host Controller Simplified Specification Version 2.00" > > spec. 'Table 2-4 : Block Size Register': > > > > Transfer Block Size [...] can be accessed only if no > > transaction is executing (i.e., after a transaction has stopped). > > Read operations during transfers may return an invalid value, > > and write operations shall be ignored. > > ... > > > > Fixes: CVE-2020-17380 > > Fixes: CVE-2020-25085 > > Signed-off-by: Philippe Mathieu-Daudé > > --- > > Cc: Mauro Matteo Cascella > > Cc: Alexander Bulekov > > Cc: Alistair Francis > > Cc: Prasad J Pandit > > Cc: Bandan Das > > > > RFC because missing Reported-by tags, launchpad/bugzilla links and > > qtest reproducer. Sending for review meanwhile. ... > For the above CVEs: > Tested-by: Mauro Matteo Cascella Thanks Mauro for testing. Do you know what tags I should add for the credits? Phil.
Re: [PATCH] hw/sd/sdhci: Do not modify BlockSizeRegister if transaction in progress
On Mon, Feb 8, 2021 at 8:35 PM Philippe Mathieu-Daudé wrote: > > Per the "SD Host Controller Simplified Specification Version 2.00" > spec. 'Table 2-4 : Block Size Register': > > Transfer Block Size [...] can be accessed only if no > transaction is executing (i.e., after a transaction has stopped). > Read operations during transfers may return an invalid value, > and write operations shall be ignored. > > Transactions will update 'data_count', so do not modify 'blksize' > and 'blkcnt' when 'data_count' is used. This fixes: > > $ cat << EOF | qemu-system-x86_64 -qtest stdio -monitor none \ >-nographic -serial none -M pc-q35-5.0 \ >-device sdhci-pci,sd-spec-version=3 \ >-device sd-card,drive=mydrive \ >-drive if=sd,index=0,file=null-co://,format=raw,id=mydrive > outl 0xcf8 0x80001810 > outl 0xcfc 0xe1068000 > outl 0xcf8 0x80001814 > outl 0xcf8 0x80001804 > outw 0xcfc 0x7 > outl 0xcf8 0x8000fa20 > write 0xe106802c 0x1 0x0f > write 0xe1068004 0xc 0x2801d10101fbff28a384 > write 0xe106800c 0x1f > 0x9dacbbcad9e8f7061524334251606f7e8d9cabbac9d8e7f60514233241505f > write 0xe1068003 0x28 > 0x80d000251480d000252280d000253080d000253e80d000254c80d000255a80d000256880d0002576 > write 0xe1068003 0x1 0xfe > EOF > = > ==2686219==ERROR: AddressSanitizer: heap-buffer-overflow on address > 0x6153bb00 at pc 0x55ab469f456c bp 0x7ffee71be330 sp 0x7ffee71bdae0 > WRITE of size 4 at 0x6153bb00 thread T0 > #0 0x55ab469f456b in __asan_memcpy (qemu-system-i386+0x1cea56b) > #1 0x55ab483dc396 in stl_he_p include/qemu/bswap.h:353:5 > #2 0x55ab483af5e4 in stn_he_p include/qemu/bswap.h:546:1 > #3 0x55ab483aeb4b in flatview_read_continue softmmu/physmem.c:2839:13 > #4 0x55ab483b0705 in flatview_read softmmu/physmem.c:2877:12 > #5 0x55ab483b028e in address_space_read_full softmmu/physmem.c:2890:18 > #6 0x55ab483b1294 in address_space_rw softmmu/physmem.c:2918:16 > #7 0x55ab479374a2 in dma_memory_rw_relaxed include/sysemu/dma.h:88:12 > #8 0x55ab47936f50 in dma_memory_rw include/sysemu/dma.h:127:12 > #9 0x55ab4793665f in dma_memory_read include/sysemu/dma.h:145:12 > #10 0x55ab4792f176 in sdhci_sdma_transfer_multi_blocks > hw/sd/sdhci.c:639:13 > #11 0x55ab4793dc9d in sdhci_write hw/sd/sdhci.c:1129:17 > #12 0x55ab483f8db8 in memory_region_write_accessor > softmmu/memory.c:491:5 > #13 0x55ab483f868a in access_with_adjusted_size softmmu/memory.c:552:18 > #14 0x55ab483f6da5 in memory_region_dispatch_write > softmmu/memory.c:1501:16 > #15 0x55ab483c3b11 in flatview_write_continue softmmu/physmem.c:2774:23 > #16 0x55ab483b0eb6 in flatview_write softmmu/physmem.c:2814:14 > #17 0x55ab483b0a3e in address_space_write softmmu/physmem.c:2906:18 > #18 0x55ab48465c56 in qtest_process_command softmmu/qtest.c:654:9 > > 0x6153bb00 is located 0 bytes to the right of 512-byte region > [0x6153b900,0x6153bb00) > allocated by thread T0 here: > #0 0x55ab469f58a7 in calloc (qemu-system-i386+0x1ceb8a7) > #1 0x7f21d678f9b0 in g_malloc0 (/lib64/libglib-2.0.so.0+0x589b0) > #2 0x55ab479530ed in sdhci_pci_realize hw/sd/sdhci-pci.c:36:5 > #3 0x55ab476f102a in pci_qdev_realize hw/pci/pci.c:2108:9 > #4 0x55ab48baaad2 in device_set_realized hw/core/qdev.c:761:13 > > SUMMARY: AddressSanitizer: heap-buffer-overflow > (qemu-system-i386+0x1cea56b) in __asan_memcpy > Shadow bytes around the buggy address: > 0x0c2a7710: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > 0x0c2a7720: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x0c2a7730: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x0c2a7740: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x0c2a7750: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > =>0x0c2a7760:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > 0x0c2a7770: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > 0x0c2a7780: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > 0x0c2a7790: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > 0x0c2a77a0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd > 0x0c2a77b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa > Shadow byte legend (one shadow byte represents 8 application bytes): > Addressable: 00 > Heap left redzone: fa > Freed heap region: fd > ==2686219==ABORTING > > Fixes: CVE-2020-17380 > Fixes: CVE-2020-25085 > Signed-off-by: Philippe Mathieu-Daudé > --- > Cc: Mauro Matteo Cascella > Cc: Alexander Bulekov > Cc: Alistair Francis > Cc: Prasad J Pandit > Cc: Bandan Das > > RFC because missing Reported-by tags, launchpad/bugzilla links and > qtest reproducer. Sending for review meanwhile. > --- > hw/sd/sdhci.c | 6 ++ > 1 file changed, 6 i
[PATCH] hw/sd/sdhci: Do not modify BlockSizeRegister if transaction in progress
Per the "SD Host Controller Simplified Specification Version 2.00" spec. 'Table 2-4 : Block Size Register': Transfer Block Size [...] can be accessed only if no transaction is executing (i.e., after a transaction has stopped). Read operations during transfers may return an invalid value, and write operations shall be ignored. Transactions will update 'data_count', so do not modify 'blksize' and 'blkcnt' when 'data_count' is used. This fixes: $ cat << EOF | qemu-system-x86_64 -qtest stdio -monitor none \ -nographic -serial none -M pc-q35-5.0 \ -device sdhci-pci,sd-spec-version=3 \ -device sd-card,drive=mydrive \ -drive if=sd,index=0,file=null-co://,format=raw,id=mydrive outl 0xcf8 0x80001810 outl 0xcfc 0xe1068000 outl 0xcf8 0x80001814 outl 0xcf8 0x80001804 outw 0xcfc 0x7 outl 0xcf8 0x8000fa20 write 0xe106802c 0x1 0x0f write 0xe1068004 0xc 0x2801d10101fbff28a384 write 0xe106800c 0x1f 0x9dacbbcad9e8f7061524334251606f7e8d9cabbac9d8e7f60514233241505f write 0xe1068003 0x28 0x80d000251480d000252280d000253080d000253e80d000254c80d000255a80d000256880d0002576 write 0xe1068003 0x1 0xfe EOF = ==2686219==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6153bb00 at pc 0x55ab469f456c bp 0x7ffee71be330 sp 0x7ffee71bdae0 WRITE of size 4 at 0x6153bb00 thread T0 #0 0x55ab469f456b in __asan_memcpy (qemu-system-i386+0x1cea56b) #1 0x55ab483dc396 in stl_he_p include/qemu/bswap.h:353:5 #2 0x55ab483af5e4 in stn_he_p include/qemu/bswap.h:546:1 #3 0x55ab483aeb4b in flatview_read_continue softmmu/physmem.c:2839:13 #4 0x55ab483b0705 in flatview_read softmmu/physmem.c:2877:12 #5 0x55ab483b028e in address_space_read_full softmmu/physmem.c:2890:18 #6 0x55ab483b1294 in address_space_rw softmmu/physmem.c:2918:16 #7 0x55ab479374a2 in dma_memory_rw_relaxed include/sysemu/dma.h:88:12 #8 0x55ab47936f50 in dma_memory_rw include/sysemu/dma.h:127:12 #9 0x55ab4793665f in dma_memory_read include/sysemu/dma.h:145:12 #10 0x55ab4792f176 in sdhci_sdma_transfer_multi_blocks hw/sd/sdhci.c:639:13 #11 0x55ab4793dc9d in sdhci_write hw/sd/sdhci.c:1129:17 #12 0x55ab483f8db8 in memory_region_write_accessor softmmu/memory.c:491:5 #13 0x55ab483f868a in access_with_adjusted_size softmmu/memory.c:552:18 #14 0x55ab483f6da5 in memory_region_dispatch_write softmmu/memory.c:1501:16 #15 0x55ab483c3b11 in flatview_write_continue softmmu/physmem.c:2774:23 #16 0x55ab483b0eb6 in flatview_write softmmu/physmem.c:2814:14 #17 0x55ab483b0a3e in address_space_write softmmu/physmem.c:2906:18 #18 0x55ab48465c56 in qtest_process_command softmmu/qtest.c:654:9 0x6153bb00 is located 0 bytes to the right of 512-byte region [0x6153b900,0x6153bb00) allocated by thread T0 here: #0 0x55ab469f58a7 in calloc (qemu-system-i386+0x1ceb8a7) #1 0x7f21d678f9b0 in g_malloc0 (/lib64/libglib-2.0.so.0+0x589b0) #2 0x55ab479530ed in sdhci_pci_realize hw/sd/sdhci-pci.c:36:5 #3 0x55ab476f102a in pci_qdev_realize hw/pci/pci.c:2108:9 #4 0x55ab48baaad2 in device_set_realized hw/core/qdev.c:761:13 SUMMARY: AddressSanitizer: heap-buffer-overflow (qemu-system-i386+0x1cea56b) in __asan_memcpy Shadow bytes around the buggy address: 0x0c2a7710: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c2a7720: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c2a7730: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c2a7740: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c2a7750: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x0c2a7760:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c2a7770: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c2a7780: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c2a7790: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c2a77a0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c2a77b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Heap left redzone: fa Freed heap region: fd ==2686219==ABORTING Fixes: CVE-2020-17380 Fixes: CVE-2020-25085 Signed-off-by: Philippe Mathieu-Daudé --- Cc: Mauro Matteo Cascella Cc: Alexander Bulekov Cc: Alistair Francis Cc: Prasad J Pandit Cc: Bandan Das RFC because missing Reported-by tags, launchpad/bugzilla links and qtest reproducer. Sending for review meanwhile. --- hw/sd/sdhci.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c index 8ffa53999d8..7ac7d9af9e4 100644 --- a/hw/sd/sdhci.c +++ b/hw/sd/sdhci.c @@ -1133,6 +1133,12 @@ sdhci_write(void *opaque, hwaddr offset, uint64_t val, unsigned size) } break;
