qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH-for-6.2 v3 2/2] tests/qtest/fdc-test: Add a regression test f


From: Philippe Mathieu-Daudé
Subject: Re: [PATCH-for-6.2 v3 2/2] tests/qtest/fdc-test: Add a regression test for CVE-2021-20196
Date: Wed, 24 Nov 2021 16:11:58 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0

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 ;)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]