| Message ID | 20211118120635.4043197-3-philmd@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | hw/block/fdc: Fix CVE-2021-20196 | expand |
On 18.11.21 13:06, Philippe Mathieu-Daudé wrote: > From: Alexander Bulekov <alxndr@bu.edu> > > Without the previous commit, when running 'make check-qtest-i386' > with QEMU configured with '--enable-sanitizers' we get: > > AddressSanitizer:DEADLYSIGNAL > ================================================================= > ==287878==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000344 > ==287878==The signal is caused by a WRITE memory access. > ==287878==Hint: address points to the zero page. > #0 0x564b2e5bac27 in blk_inc_in_flight block/block-backend.c:1346:5 > #1 0x564b2e5bb228 in blk_pwritev_part block/block-backend.c:1317:5 > #2 0x564b2e5bcd57 in blk_pwrite block/block-backend.c:1498:11 > #3 0x564b2ca1cdd3 in fdctrl_write_data hw/block/fdc.c:2221:17 > #4 0x564b2ca1b2f7 in fdctrl_write hw/block/fdc.c:829:9 > #5 0x564b2dc49503 in portio_write softmmu/ioport.c:201:9 > > Add the reproducer for CVE-2021-20196. > > Signed-off-by: Alexander Bulekov <alxndr@bu.edu> > Message-Id: <20210319050906.14875-2-alxndr@bu.edu> > [PMD: Rebased, use global test_image] > Reviewed-by: Darren Kenny <darren.kenny@oracle.com> > Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> > --- > tests/qtest/fdc-test.c | 21 +++++++++++++++++++++ > 1 file changed, 21 insertions(+) Not sure if I’m doing something wrong, but: Using the global test_image brings a problem, namely that this test fails unconditionally (for me at least...?), with the reason being that the global QEMU instance (launched by qtest_start(), quit by qtest_end()) still has that image open, so by launching a second instance concurrently, I get this: qemu-system-x86_64: Failed to get "write" lock Is another process using the image [/tmp/qtest.xV4IxX]? So either we need to use a different image file, or we need to quit the global instance before using it (e.g. putting a qtest_end() at the beginning of test_cve_*()), although the latter just seems wrong. Second, I can’t make this test fail. When I apply this patch first (to master) and run it, I don’t get a SIGSEGV. Hanna
On 11/23/21 14:42, Hanna Reitz wrote: > On 18.11.21 13:06, Philippe Mathieu-Daudé wrote: >> From: Alexander Bulekov <alxndr@bu.edu> >> >> Without the previous commit, when running 'make check-qtest-i386' >> with QEMU configured with '--enable-sanitizers' we get: >> >> AddressSanitizer:DEADLYSIGNAL >> ================================================================= >> ==287878==ERROR: AddressSanitizer: SEGV on unknown address >> 0x000000000344 >> ==287878==The signal is caused by a WRITE memory access. >> ==287878==Hint: address points to the zero page. >> #0 0x564b2e5bac27 in blk_inc_in_flight >> block/block-backend.c:1346:5 >> #1 0x564b2e5bb228 in blk_pwritev_part block/block-backend.c:1317:5 >> #2 0x564b2e5bcd57 in blk_pwrite block/block-backend.c:1498:11 >> #3 0x564b2ca1cdd3 in fdctrl_write_data hw/block/fdc.c:2221:17 >> #4 0x564b2ca1b2f7 in fdctrl_write hw/block/fdc.c:829:9 >> #5 0x564b2dc49503 in portio_write softmmu/ioport.c:201:9 >> >> Add the reproducer for CVE-2021-20196. >> >> Signed-off-by: Alexander Bulekov <alxndr@bu.edu> >> Message-Id: <20210319050906.14875-2-alxndr@bu.edu> >> [PMD: Rebased, use global test_image] >> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> >> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> >> --- >> tests/qtest/fdc-test.c | 21 +++++++++++++++++++++ >> 1 file changed, 21 insertions(+) > > Not sure if I’m doing something wrong, but: > > Using the global test_image brings a problem, namely that this test > fails unconditionally (for me at least...?), with the reason being that > the global QEMU instance (launched by qtest_start(), quit by > qtest_end()) still has that image open, so by launching a second > instance concurrently, I get this: > > qemu-system-x86_64: Failed to get "write" lock > Is another process using the image [/tmp/qtest.xV4IxX]? Hmm I had too many odd problems running qtests in parallel so I switched to 'make check-qtest -j1' more than 1 year ago, which is probably why I haven't noticed that issue. Using another 'test_image' seems against code reuse principle, but at this point in release, duplicating it is simpler. Someone will clean that later =) > So either we need to use a different image file, or we need to quit the > global instance before using it (e.g. putting a qtest_end() at the > beginning of test_cve_*()), although the latter just seems wrong. > > Second, I can’t make this test fail. When I apply this patch first (to > master) and run it, I don’t get a SIGSEGV. Is your QEMU built with --enable-sanitizers ?
On 23.11.21 14:49, Philippe Mathieu-Daudé wrote: > On 11/23/21 14:42, Hanna Reitz wrote: >> On 18.11.21 13:06, Philippe Mathieu-Daudé wrote: >>> From: Alexander Bulekov <alxndr@bu.edu> >>> >>> Without the previous commit, when running 'make check-qtest-i386' >>> with QEMU configured with '--enable-sanitizers' we get: >>> >>> AddressSanitizer:DEADLYSIGNAL >>> ================================================================= >>> ==287878==ERROR: AddressSanitizer: SEGV on unknown address >>> 0x000000000344 >>> ==287878==The signal is caused by a WRITE memory access. >>> ==287878==Hint: address points to the zero page. >>> #0 0x564b2e5bac27 in blk_inc_in_flight >>> block/block-backend.c:1346:5 >>> #1 0x564b2e5bb228 in blk_pwritev_part block/block-backend.c:1317:5 >>> #2 0x564b2e5bcd57 in blk_pwrite block/block-backend.c:1498:11 >>> #3 0x564b2ca1cdd3 in fdctrl_write_data hw/block/fdc.c:2221:17 >>> #4 0x564b2ca1b2f7 in fdctrl_write hw/block/fdc.c:829:9 >>> #5 0x564b2dc49503 in portio_write softmmu/ioport.c:201:9 >>> >>> Add the reproducer for CVE-2021-20196. >>> >>> Signed-off-by: Alexander Bulekov <alxndr@bu.edu> >>> Message-Id: <20210319050906.14875-2-alxndr@bu.edu> >>> [PMD: Rebased, use global test_image] >>> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> >>> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> >>> --- >>> tests/qtest/fdc-test.c | 21 +++++++++++++++++++++ >>> 1 file changed, 21 insertions(+) >> Not sure if I’m doing something wrong, but: >> >> Using the global test_image brings a problem, namely that this test >> fails unconditionally (for me at least...?), with the reason being that >> the global QEMU instance (launched by qtest_start(), quit by >> qtest_end()) still has that image open, so by launching a second >> instance concurrently, I get this: >> >> qemu-system-x86_64: Failed to get "write" lock >> Is another process using the image [/tmp/qtest.xV4IxX]? > Hmm I had too many odd problems running qtests in parallel so I > switched to 'make check-qtest -j1' more than 1 year ago, which > is probably why I haven't noticed that issue. I’ve run the test with QTEST_QEMU_BINARY=$PWD/qemu-system-x86_64 tests/qtest/fdc-test so there definitely weren’t any other tests running at the same time. I don’t know why you don’t encounter this problem, but it’s caused by the concurrent QEMU instance launched in the very same test (qtest_start() in main(), and cleaned up by qtest_end() after g_test_run()). > Using another 'test_image' seems against code reuse principle, > but at this point in release, duplicating it is simpler. Someone > will clean that later =) > >> So either we need to use a different image file, or we need to quit the >> global instance before using it (e.g. putting a qtest_end() at the >> beginning of test_cve_*()), although the latter just seems wrong. >> >> Second, I can’t make this test fail. When I apply this patch first (to >> master) and run it, I don’t get a SIGSEGV. > Is your QEMU built with --enable-sanitizers ? Uh, no. I had (wrongly) assumed there’d be no need, given that the SIGSEGV access address is below 4 kB... I now did configure and compile it with --enable-sanitizers but still can’t reproduce it. Hanna
On 211123 1449, Philippe Mathieu-Daudé wrote: > On 11/23/21 14:42, Hanna Reitz wrote: > > On 18.11.21 13:06, Philippe Mathieu-Daudé wrote: > >> From: Alexander Bulekov <alxndr@bu.edu> > >> > >> Without the previous commit, when running 'make check-qtest-i386' > >> with QEMU configured with '--enable-sanitizers' we get: > >> > >> AddressSanitizer:DEADLYSIGNAL > >> ================================================================= > >> ==287878==ERROR: AddressSanitizer: SEGV on unknown address > >> 0x000000000344 > >> ==287878==The signal is caused by a WRITE memory access. > >> ==287878==Hint: address points to the zero page. > >> #0 0x564b2e5bac27 in blk_inc_in_flight > >> block/block-backend.c:1346:5 > >> #1 0x564b2e5bb228 in blk_pwritev_part block/block-backend.c:1317:5 > >> #2 0x564b2e5bcd57 in blk_pwrite block/block-backend.c:1498:11 > >> #3 0x564b2ca1cdd3 in fdctrl_write_data hw/block/fdc.c:2221:17 > >> #4 0x564b2ca1b2f7 in fdctrl_write hw/block/fdc.c:829:9 > >> #5 0x564b2dc49503 in portio_write softmmu/ioport.c:201:9 > >> > >> Add the reproducer for CVE-2021-20196. > >> > >> Signed-off-by: Alexander Bulekov <alxndr@bu.edu> > >> Message-Id: <20210319050906.14875-2-alxndr@bu.edu> > >> [PMD: Rebased, use global test_image] > >> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> > >> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> > >> --- > >> tests/qtest/fdc-test.c | 21 +++++++++++++++++++++ > >> 1 file changed, 21 insertions(+) > > > > Not sure if I’m doing something wrong, but: > > > > Using the global test_image brings a problem, namely that this test > > fails unconditionally (for me at least...?), with the reason being that > > the global QEMU instance (launched by qtest_start(), quit by > > qtest_end()) still has that image open, so by launching a second > > instance concurrently, I get this: > > > > qemu-system-x86_64: Failed to get "write" lock > > Is another process using the image [/tmp/qtest.xV4IxX]? > > Hmm I had too many odd problems running qtests in parallel so I > switched to 'make check-qtest -j1' more than 1 year ago, which > is probably why I haven't noticed that issue. > > Using another 'test_image' seems against code reuse principle, > but at this point in release, duplicating it is simpler. Someone > will clean that later =) Maybe it makes sense to run this with -snasphot ? > > > So either we need to use a different image file, or we need to quit the > > global instance before using it (e.g. putting a qtest_end() at the > > beginning of test_cve_*()), although the latter just seems wrong. > > > > Second, I can’t make this test fail. When I apply this patch first (to > > master) and run it, I don’t get a SIGSEGV. > > Is your QEMU built with --enable-sanitizers ? >
On 11/23/21 15:14, Hanna Reitz wrote: > On 23.11.21 14:49, Philippe Mathieu-Daudé wrote: >> On 11/23/21 14:42, Hanna Reitz wrote: >>> On 18.11.21 13:06, Philippe Mathieu-Daudé wrote: >>>> From: Alexander Bulekov <alxndr@bu.edu> >>>> >>>> Without the previous commit, when running 'make check-qtest-i386' >>>> with QEMU configured with '--enable-sanitizers' we get: >>>> >>>> AddressSanitizer:DEADLYSIGNAL >>>> ================================================================= >>>> ==287878==ERROR: AddressSanitizer: SEGV on unknown address >>>> 0x000000000344 >>>> ==287878==The signal is caused by a WRITE memory access. >>>> ==287878==Hint: address points to the zero page. >>>> #0 0x564b2e5bac27 in blk_inc_in_flight >>>> block/block-backend.c:1346:5 >>>> #1 0x564b2e5bb228 in blk_pwritev_part >>>> block/block-backend.c:1317:5 >>>> #2 0x564b2e5bcd57 in blk_pwrite block/block-backend.c:1498:11 >>>> #3 0x564b2ca1cdd3 in fdctrl_write_data hw/block/fdc.c:2221:17 >>>> #4 0x564b2ca1b2f7 in fdctrl_write hw/block/fdc.c:829:9 >>>> #5 0x564b2dc49503 in portio_write softmmu/ioport.c:201:9 >>>> >>>> Add the reproducer for CVE-2021-20196. >>>> >>>> Signed-off-by: Alexander Bulekov <alxndr@bu.edu> >>>> Message-Id: <20210319050906.14875-2-alxndr@bu.edu> >>>> [PMD: Rebased, use global test_image] >>>> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> >>>> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> >>>> --- >>>> tests/qtest/fdc-test.c | 21 +++++++++++++++++++++ >>>> 1 file changed, 21 insertions(+) >>> Not sure if I’m doing something wrong, but: >>> >>> Using the global test_image brings a problem, namely that this test >>> fails unconditionally (for me at least...?), with the reason being that >>> the global QEMU instance (launched by qtest_start(), quit by >>> qtest_end()) still has that image open, so by launching a second >>> instance concurrently, I get this: >>> >>> qemu-system-x86_64: Failed to get "write" lock >>> Is another process using the image [/tmp/qtest.xV4IxX]? >> Hmm I had too many odd problems running qtests in parallel so I >> switched to 'make check-qtest -j1' more than 1 year ago, which >> is probably why I haven't noticed that issue. > > I’ve run the test with > > QTEST_QEMU_BINARY=$PWD/qemu-system-x86_64 tests/qtest/fdc-test > > so there definitely weren’t any other tests running at the same time. I > don’t know why you don’t encounter this problem, but it’s caused by the > concurrent QEMU instance launched in the very same test (qtest_start() > in main(), and cleaned up by qtest_end() after g_test_run()). I run all my qtests on top of this patch, otherwise I can't get any coredump: https://lore.kernel.org/qemu-devel/20200707031920.17428-1-f4bug@amsat.org/ But I don't think it mattered here...
On 24.11.21 13:50, Philippe Mathieu-Daudé wrote: > On 11/23/21 15:14, Hanna Reitz wrote: >> On 23.11.21 14:49, Philippe Mathieu-Daudé wrote: >>> On 11/23/21 14:42, Hanna Reitz wrote: >>>> On 18.11.21 13:06, Philippe Mathieu-Daudé wrote: >>>>> From: Alexander Bulekov <alxndr@bu.edu> >>>>> >>>>> Without the previous commit, when running 'make check-qtest-i386' >>>>> with QEMU configured with '--enable-sanitizers' we get: >>>>> >>>>> AddressSanitizer:DEADLYSIGNAL >>>>> ================================================================= >>>>> ==287878==ERROR: AddressSanitizer: SEGV on unknown address >>>>> 0x000000000344 >>>>> ==287878==The signal is caused by a WRITE memory access. >>>>> ==287878==Hint: address points to the zero page. >>>>> #0 0x564b2e5bac27 in blk_inc_in_flight >>>>> block/block-backend.c:1346:5 >>>>> #1 0x564b2e5bb228 in blk_pwritev_part >>>>> block/block-backend.c:1317:5 >>>>> #2 0x564b2e5bcd57 in blk_pwrite block/block-backend.c:1498:11 >>>>> #3 0x564b2ca1cdd3 in fdctrl_write_data hw/block/fdc.c:2221:17 >>>>> #4 0x564b2ca1b2f7 in fdctrl_write hw/block/fdc.c:829:9 >>>>> #5 0x564b2dc49503 in portio_write softmmu/ioport.c:201:9 >>>>> >>>>> Add the reproducer for CVE-2021-20196. >>>>> >>>>> Signed-off-by: Alexander Bulekov <alxndr@bu.edu> >>>>> Message-Id: <20210319050906.14875-2-alxndr@bu.edu> >>>>> [PMD: Rebased, use global test_image] >>>>> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> >>>>> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> >>>>> --- >>>>> tests/qtest/fdc-test.c | 21 +++++++++++++++++++++ >>>>> 1 file changed, 21 insertions(+) >>>> Not sure if I’m doing something wrong, but: >>>> >>>> Using the global test_image brings a problem, namely that this test >>>> fails unconditionally (for me at least...?), with the reason being that >>>> the global QEMU instance (launched by qtest_start(), quit by >>>> qtest_end()) still has that image open, so by launching a second >>>> instance concurrently, I get this: >>>> >>>> qemu-system-x86_64: Failed to get "write" lock >>>> Is another process using the image [/tmp/qtest.xV4IxX]? >>> Hmm I had too many odd problems running qtests in parallel so I >>> switched to 'make check-qtest -j1' more than 1 year ago, which >>> is probably why I haven't noticed that issue. >> I’ve run the test with >> >> QTEST_QEMU_BINARY=$PWD/qemu-system-x86_64 tests/qtest/fdc-test >> >> so there definitely weren’t any other tests running at the same time. I >> don’t know why you don’t encounter this problem, but it’s caused by the >> concurrent QEMU instance launched in the very same test (qtest_start() >> in main(), and cleaned up by qtest_end() after g_test_run()). > I run all my qtests on top of this patch, otherwise I can't > get any coredump: > https://lore.kernel.org/qemu-devel/20200707031920.17428-1-f4bug@amsat.org/ > But I don't think it mattered here... I can give that a try, but since I use coredumpctl, I generally don’t have a problem with one coredump overwriting another (only that I need to give a PID to `coredumpctl gdb` to load not the latest coredump (the qtest) but the one before (qemu)). Hm, perhaps the problem is that I never applied the other series before this one. Also one thing that remains to be tested... Hanna
On 11/24/21 15:00, Hanna Reitz wrote: > On 24.11.21 13:50, Philippe Mathieu-Daudé wrote: >> On 11/23/21 15:14, Hanna Reitz wrote: >>> On 23.11.21 14:49, Philippe Mathieu-Daudé wrote: >>>> On 11/23/21 14:42, Hanna Reitz wrote: >>>>> On 18.11.21 13:06, Philippe Mathieu-Daudé wrote: >>>>>> From: Alexander Bulekov <alxndr@bu.edu> >>>>>> >>>>>> Without the previous commit, when running 'make check-qtest-i386' >>>>>> with QEMU configured with '--enable-sanitizers' we get: >>>>>> >>>>>> AddressSanitizer:DEADLYSIGNAL >>>>>> >>>>>> ================================================================= >>>>>> ==287878==ERROR: AddressSanitizer: SEGV on unknown address >>>>>> 0x000000000344 >>>>>> ==287878==The signal is caused by a WRITE memory access. >>>>>> ==287878==Hint: address points to the zero page. >>>>>> #0 0x564b2e5bac27 in blk_inc_in_flight >>>>>> block/block-backend.c:1346:5 >>>>>> #1 0x564b2e5bb228 in blk_pwritev_part >>>>>> block/block-backend.c:1317:5 >>>>>> #2 0x564b2e5bcd57 in blk_pwrite >>>>>> block/block-backend.c:1498:11 >>>>>> #3 0x564b2ca1cdd3 in fdctrl_write_data >>>>>> hw/block/fdc.c:2221:17 >>>>>> #4 0x564b2ca1b2f7 in fdctrl_write hw/block/fdc.c:829:9 >>>>>> #5 0x564b2dc49503 in portio_write softmmu/ioport.c:201:9 >>>>>> >>>>>> Add the reproducer for CVE-2021-20196. >>>>>> >>>>>> Signed-off-by: Alexander Bulekov <alxndr@bu.edu> >>>>>> Message-Id: <20210319050906.14875-2-alxndr@bu.edu> >>>>>> [PMD: Rebased, use global test_image] >>>>>> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> >>>>>> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> >>>>>> --- >>>>>> tests/qtest/fdc-test.c | 21 +++++++++++++++++++++ >>>>>> 1 file changed, 21 insertions(+) >>>>> Not sure if I’m doing something wrong, but: >>>>> >>>>> Using the global test_image brings a problem, namely that this test >>>>> fails unconditionally (for me at least...?), with the reason being >>>>> that >>>>> the global QEMU instance (launched by qtest_start(), quit by >>>>> qtest_end()) still has that image open, so by launching a second >>>>> instance concurrently, I get this: >>>>> >>>>> qemu-system-x86_64: Failed to get "write" lock >>>>> Is another process using the image [/tmp/qtest.xV4IxX]? >>>> Hmm I had too many odd problems running qtests in parallel so I >>>> switched to 'make check-qtest -j1' more than 1 year ago, which >>>> is probably why I haven't noticed that issue. >>> I’ve run the test with >>> >>> QTEST_QEMU_BINARY=$PWD/qemu-system-x86_64 tests/qtest/fdc-test >>> >>> so there definitely weren’t any other tests running at the same time. I >>> don’t know why you don’t encounter this problem, but it’s caused by the >>> concurrent QEMU instance launched in the very same test (qtest_start() >>> in main(), and cleaned up by qtest_end() after g_test_run()). >> I run all my qtests on top of this patch, otherwise I can't >> get any coredump: >> https://lore.kernel.org/qemu-devel/20200707031920.17428-1-f4bug@amsat.org/ >> >> But I don't think it mattered here... > > I can give that a try, but since I use coredumpctl, I generally don’t > have a problem with one coredump overwriting another (only that I need > to give a PID to `coredumpctl gdb` to load not the latest coredump (the > qtest) but the one before (qemu)). I'm not a Fedora expert and use the default, for some reason only the last coredump is available (which in this case is tests/qtest/fdc-test, not useful at all). > Hm, perhaps the problem is that I never applied the other series before > this one. Also one thing that remains to be tested... Don't waste time now, wait for v4 ;)
diff --git a/tests/qtest/fdc-test.c b/tests/qtest/fdc-test.c index f164d972d10..0f8b9b753f4 100644 --- a/tests/qtest/fdc-test.c +++ b/tests/qtest/fdc-test.c @@ -565,6 +565,26 @@ static void test_cve_2021_3507(void) qtest_quit(s); } +static void test_cve_2021_20196(void) +{ + QTestState *s; + + s = qtest_initf("-nographic -m 32M -nodefaults " + "-drive file=%s,format=raw,if=floppy", test_image); + qtest_outw(s, 0x3f2, 0x0004); + qtest_outw(s, 0x3f4, 0x0200); + qtest_outw(s, 0x3f4, 0x0000); + qtest_outw(s, 0x3f4, 0x0000); + qtest_outw(s, 0x3f4, 0x0000); + qtest_outw(s, 0x3f4, 0x0000); + qtest_outw(s, 0x3f4, 0x0000); + qtest_outw(s, 0x3f4, 0x0000); + qtest_outw(s, 0x3f4, 0x0000); + qtest_outw(s, 0x3f4, 0x0000); + qtest_outw(s, 0x3f2, 0x0001); + qtest_quit(s); +} + int main(int argc, char **argv) { int fd; @@ -596,6 +616,7 @@ int main(int argc, char **argv) qtest_add_func("/fdc/read_no_dma_19", test_read_no_dma_19); qtest_add_func("/fdc/fuzz-registers", fuzz_registers); qtest_add_func("/fdc/fuzz/cve_2021_3507", test_cve_2021_3507); + qtest_add_func("/fdc/fuzz/cve_2021_20196", test_cve_2021_20196); ret = g_test_run();