* [PATCH v1] sd: sdhci: assert data_count is within fifo_buffer
@ 2020-09-03 7:08 P J P
2020-09-03 14:01 ` Philippe Mathieu-Daudé
0 siblings, 1 reply; 5+ messages in thread
From: P J P @ 2020-09-03 7:08 UTC (permalink / raw)
To: Philippe Mathieu-Daudé
Cc: Ruhr-University, QEMU Developers, qemu-block, Prasad J Pandit
From: Prasad J Pandit <pjp@fedoraproject.org>
While doing multi block SDMA, transfer block size may exceed
the 's->fifo_buffer[s->buf_maxsz]' size. It may leave the
current element pointer 's->data_count' pointing out of bounds.
Leading the subsequent DMA r/w operation to OOB access issue.
Assert that 's->data_count' is within fifo_buffer.
-> https://ruhr-uni-bochum.sciebo.de/s/NNWP2GfwzYKeKwE?path=%2Fsdhci_oob_write1
==1459837==ERROR: AddressSanitizer: heap-buffer-overflow
WRITE of size 54722048 at 0x61500001e280 thread T3
#0 __interceptor_memcpy (/lib64/libasan.so.6+0x3a71d)
#1 flatview_read_continue ../exec.c:3245
#2 flatview_read ../exec.c:3278
#3 address_space_read_full ../exec.c:3291
#4 address_space_rw ../exec.c:3319
#5 dma_memory_rw_relaxed ../include/sysemu/dma.h:87
#6 dma_memory_rw ../include/sysemu/dma.h:110
#7 dma_memory_read ../include/sysemu/dma.h:116
#8 sdhci_sdma_transfer_multi_blocks ../hw/sd/sdhci.c:629
#9 sdhci_write ../hw/sd/sdhci.c:1097
#10 memory_region_write_accessor ../softmmu/memory.c:483
...
Reported-by: Ruhr-University <bugs-syssec@rub.de>
Suggested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
---
hw/sd/sdhci.c | 2 ++
1 file changed, 2 insertions(+)
Update v1: use assert(3) calls
-> https://lists.nongnu.org/archive/html/qemu-devel/2020-09/msg00966.html
diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c
index 1785d7e1f7..023acbed41 100644
--- a/hw/sd/sdhci.c
+++ b/hw/sd/sdhci.c
@@ -604,6 +604,7 @@ static void sdhci_sdma_transfer_multi_blocks(SDHCIState *s)
s->blkcnt--;
}
}
+ assert(s->data_count <= s->buf_maxsz && s->data_count > begin);
dma_memory_write(s->dma_as, s->sdmasysad,
&s->fifo_buffer[begin], s->data_count - begin);
s->sdmasysad += s->data_count - begin;
@@ -626,6 +627,7 @@ static void sdhci_sdma_transfer_multi_blocks(SDHCIState *s)
s->data_count = block_size;
boundary_count -= block_size - begin;
}
+ assert(s->data_count <= s->buf_maxsz && s->data_count > begin);
dma_memory_read(s->dma_as, s->sdmasysad,
&s->fifo_buffer[begin], s->data_count - begin);
s->sdmasysad += s->data_count - begin;
--
2.26.2
^ permalink raw reply related [flat|nested] 5+ messages in thread* Re: [PATCH v1] sd: sdhci: assert data_count is within fifo_buffer
2020-09-03 7:08 [PATCH v1] sd: sdhci: assert data_count is within fifo_buffer P J P
@ 2020-09-03 14:01 ` Philippe Mathieu-Daudé
2020-09-03 16:03 ` Philippe Mathieu-Daudé
2020-09-03 17:33 ` P J P
0 siblings, 2 replies; 5+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-09-03 14:01 UTC (permalink / raw)
To: P J P; +Cc: Ruhr-University, QEMU Developers, qemu-block, Prasad J Pandit
On 9/3/20 9:08 AM, P J P wrote:
> From: Prasad J Pandit <pjp@fedoraproject.org>
>
> While doing multi block SDMA, transfer block size may exceed
> the 's->fifo_buffer[s->buf_maxsz]' size. It may leave the
> current element pointer 's->data_count' pointing out of bounds.
> Leading the subsequent DMA r/w operation to OOB access issue.
> Assert that 's->data_count' is within fifo_buffer.
>
> -> https://ruhr-uni-bochum.sciebo.de/s/NNWP2GfwzYKeKwE?path=%2Fsdhci_oob_write1
> ==1459837==ERROR: AddressSanitizer: heap-buffer-overflow
> WRITE of size 54722048 at 0x61500001e280 thread T3
> #0 __interceptor_memcpy (/lib64/libasan.so.6+0x3a71d)
> #1 flatview_read_continue ../exec.c:3245
> #2 flatview_read ../exec.c:3278
> #3 address_space_read_full ../exec.c:3291
> #4 address_space_rw ../exec.c:3319
> #5 dma_memory_rw_relaxed ../include/sysemu/dma.h:87
> #6 dma_memory_rw ../include/sysemu/dma.h:110
> #7 dma_memory_read ../include/sysemu/dma.h:116
> #8 sdhci_sdma_transfer_multi_blocks ../hw/sd/sdhci.c:629
> #9 sdhci_write ../hw/sd/sdhci.c:1097
> #10 memory_region_write_accessor ../softmmu/memory.c:483
> ...
>
> Reported-by: Ruhr-University <bugs-syssec@rub.de>
> Suggested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
> ---
> hw/sd/sdhci.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> Update v1: use assert(3) calls
> -> https://lists.nongnu.org/archive/html/qemu-devel/2020-09/msg00966.html
>
> diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c
> index 1785d7e1f7..023acbed41 100644
> --- a/hw/sd/sdhci.c
> +++ b/hw/sd/sdhci.c
> @@ -604,6 +604,7 @@ static void sdhci_sdma_transfer_multi_blocks(SDHCIState *s)
> s->blkcnt--;
> }
> }
> + assert(s->data_count <= s->buf_maxsz && s->data_count > begin);
> dma_memory_write(s->dma_as, s->sdmasysad,
> &s->fifo_buffer[begin], s->data_count - begin);
> s->sdmasysad += s->data_count - begin;
> @@ -626,6 +627,7 @@ static void sdhci_sdma_transfer_multi_blocks(SDHCIState *s)
> s->data_count = block_size;
> boundary_count -= block_size - begin;
> }
> + assert(s->data_count <= s->buf_maxsz && s->data_count > begin);
> dma_memory_read(s->dma_as, s->sdmasysad,
> &s->fifo_buffer[begin], s->data_count - begin);
> s->sdmasysad += s->data_count - begin;
>
qemu-system-i386: hw/sd/sdhci.c:632: void
sdhci_sdma_transfer_multi_blocks(SDHCIState *): Assertion `s->data_count
<= s->buf_maxsz && s->data_count > begin' failed.
Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
If you don't mind I might split the assert in 2 when applying:
- assert(s->data_count <= s->buf_maxsz && s->data_count > begin);
+ assert(s->data_count <= s->buf_maxsz);
+ assert(s->data_count > begin);
To directly display the problem straight:
qemu-system-i386: hw/sd/sdhci.c:635: void
sdhci_sdma_transfer_multi_blocks(SDHCIState *): Assertion `s->data_count
> begin' failed.
Thanks,
Phil.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v1] sd: sdhci: assert data_count is within fifo_buffer
2020-09-03 14:01 ` Philippe Mathieu-Daudé
@ 2020-09-03 16:03 ` Philippe Mathieu-Daudé
2020-09-03 17:31 ` P J P
2020-09-03 17:33 ` P J P
1 sibling, 1 reply; 5+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-09-03 16:03 UTC (permalink / raw)
To: P J P; +Cc: Ruhr-University, QEMU Developers, qemu-block, Prasad J Pandit
On 9/3/20 4:01 PM, Philippe Mathieu-Daudé wrote:
> On 9/3/20 9:08 AM, P J P wrote:
>> From: Prasad J Pandit <pjp@fedoraproject.org>
>>
>> While doing multi block SDMA, transfer block size may exceed
>> the 's->fifo_buffer[s->buf_maxsz]' size. It may leave the
>> current element pointer 's->data_count' pointing out of bounds.
>> Leading the subsequent DMA r/w operation to OOB access issue.
>> Assert that 's->data_count' is within fifo_buffer.
>>
>> -> https://ruhr-uni-bochum.sciebo.de/s/NNWP2GfwzYKeKwE?path=%2Fsdhci_oob_write1
>> ==1459837==ERROR: AddressSanitizer: heap-buffer-overflow
>> WRITE of size 54722048 at 0x61500001e280 thread T3
>> #0 __interceptor_memcpy (/lib64/libasan.so.6+0x3a71d)
>> #1 flatview_read_continue ../exec.c:3245
>> #2 flatview_read ../exec.c:3278
>> #3 address_space_read_full ../exec.c:3291
>> #4 address_space_rw ../exec.c:3319
>> #5 dma_memory_rw_relaxed ../include/sysemu/dma.h:87
>> #6 dma_memory_rw ../include/sysemu/dma.h:110
>> #7 dma_memory_read ../include/sysemu/dma.h:116
>> #8 sdhci_sdma_transfer_multi_blocks ../hw/sd/sdhci.c:629
>> #9 sdhci_write ../hw/sd/sdhci.c:1097
>> #10 memory_region_write_accessor ../softmmu/memory.c:483
>> ...
>>
>> Reported-by: Ruhr-University <bugs-syssec@rub.de>
>> Suggested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
>> Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
>> ---
>> hw/sd/sdhci.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> Update v1: use assert(3) calls
>> -> https://lists.nongnu.org/archive/html/qemu-devel/2020-09/msg00966.html
>>
>> diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c
>> index 1785d7e1f7..023acbed41 100644
>> --- a/hw/sd/sdhci.c
>> +++ b/hw/sd/sdhci.c
>> @@ -604,6 +604,7 @@ static void sdhci_sdma_transfer_multi_blocks(SDHCIState *s)
>> s->blkcnt--;
>> }
>> }
>> + assert(s->data_count <= s->buf_maxsz && s->data_count > begin);
>> dma_memory_write(s->dma_as, s->sdmasysad,
>> &s->fifo_buffer[begin], s->data_count - begin);
>> s->sdmasysad += s->data_count - begin;
>> @@ -626,6 +627,7 @@ static void sdhci_sdma_transfer_multi_blocks(SDHCIState *s)
>> s->data_count = block_size;
>> boundary_count -= block_size - begin;
>> }
>> + assert(s->data_count <= s->buf_maxsz && s->data_count > begin);
>> dma_memory_read(s->dma_as, s->sdmasysad,
>> &s->fifo_buffer[begin], s->data_count - begin);
>> s->sdmasysad += s->data_count - begin;
>>
>
> qemu-system-i386: hw/sd/sdhci.c:632: void
> sdhci_sdma_transfer_multi_blocks(SDHCIState *): Assertion `s->data_count
> <= s->buf_maxsz && s->data_count > begin' failed.
>
> Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
>
> If you don't mind I might split the assert in 2 when applying:
>
> - assert(s->data_count <= s->buf_maxsz && s->data_count > begin);
> + assert(s->data_count <= s->buf_maxsz);
> + assert(s->data_count > begin);
Doesn't seem enough, guest crash here, having:
(gdb) p begin
$1 = 0
(gdb) p s->data_count
$2 = 0
(gdb) p s->blksize
$3 = 0
Beh, something is wrong in this model, because when using ADMA2
length 0 means 65536 bytes (see '1.13.4. Descriptor Table' in
"SD Host Controller Simplified Specification Version 2.00").
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v1] sd: sdhci: assert data_count is within fifo_buffer
2020-09-03 16:03 ` Philippe Mathieu-Daudé
@ 2020-09-03 17:31 ` P J P
0 siblings, 0 replies; 5+ messages in thread
From: P J P @ 2020-09-03 17:31 UTC (permalink / raw)
To: Philippe Mathieu-Daudé
Cc: Ruhr-University, QEMU Developers, qemu-block, Prasad J Pandit
[-- Attachment #1: Type: text/plain, Size: 1174 bytes --]
+-- On Thu, 3 Sep 2020, Philippe Mathieu-Daudé wrote --+
| > - assert(s->data_count <= s->buf_maxsz && s->data_count > begin);
| > + assert(s->data_count <= s->buf_maxsz);
| > + assert(s->data_count > begin);
|
| Doesn't seem enough, guest crash here, having:
|
| (gdb) p begin
| $1 = 0
| (gdb) p s->data_count
| $2 = 0
I was actually thinking of a case if 's->data_count' and 'begin' are same? It
may lead to an infinite loop condition.
| (gdb) p s->blksize
| $3 = 0
This is strange.
| Beh, something is wrong in this model, because when using ADMA2
| length 0 means 65536 bytes (see '1.13.4. Descriptor Table' in
| "SD Host Controller Simplified Specification Version 2.00").
* DMA length 's->data_count - begin'?
* if s->blksize is 65536, it'd set 'block_size = 0' in transfer_multi_blocks()
#define BLOCK_SIZE_MASK (4 * KiB - 1) <== 0xFFF
static void sdhci_sdma_transfer_multi_blocks(SDHCIState *s)
{
...
const uint16_t block_size = s->blksize & BLOCK_SIZE_MASK; <== 0
Thank you.
--
Prasad J Pandit / Red Hat Product Security Team
8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v1] sd: sdhci: assert data_count is within fifo_buffer
2020-09-03 14:01 ` Philippe Mathieu-Daudé
2020-09-03 16:03 ` Philippe Mathieu-Daudé
@ 2020-09-03 17:33 ` P J P
1 sibling, 0 replies; 5+ messages in thread
From: P J P @ 2020-09-03 17:33 UTC (permalink / raw)
To: Philippe Mathieu-Daudé; +Cc: Ruhr-University, QEMU Developers, qemu-block
[-- Attachment #1: Type: text/plain, Size: 427 bytes --]
+-- On Thu, 3 Sep 2020, Philippe Mathieu-Daudé wrote --+
| If you don't mind I might split the assert in 2 when applying:
|
| - assert(s->data_count <= s->buf_maxsz && s->data_count > begin);
| + assert(s->data_count <= s->buf_maxsz);
| + assert(s->data_count > begin);
Sure, np. Thank you.
--
Prasad J Pandit / Red Hat Product Security Team
8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-09-03 17:35 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-09-03 7:08 [PATCH v1] sd: sdhci: assert data_count is within fifo_buffer P J P
2020-09-03 14:01 ` Philippe Mathieu-Daudé
2020-09-03 16:03 ` Philippe Mathieu-Daudé
2020-09-03 17:31 ` P J P
2020-09-03 17:33 ` P J P
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).