qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH] ide:atapi: check io_buffer_index in ide_atapi_cmd_reply_end


From: P J P
Subject: Re: [PATCH] ide:atapi: check io_buffer_index in ide_atapi_cmd_reply_end
Date: Wed, 2 Dec 2020 18:47:29 +0530 (IST)

  Hi,

[doing a combined reply]

+-- On Tue, 1 Dec 2020, Philippe Mathieu-Daudé wrote --+ 
| Is it possible to release the reproducer to the community, so we can work on 
| a fix and test it?

* No, we can not release/share reproducers on a public list.

* We can request reporters to do so by their volition.


| What happens to reproducers when a CVE is assigned, but the bug is marked as 
| "out of the QEMU security boundary"?
|
+-- On Tue, 1 Dec 2020, Peter Maydell wrote --+
| Also, why are we assigning CVEs for bugs we don't consider security bugs?

* We need to mark these componets 'out of security scope' at the source level, 
  rather than on each bug.

* Easiest could be to just have a list of such components in the git text 
  file. At least till the time we device --security build and run time option 
  discussed earlier.
  -> https://lists.nongnu.org/archive/html/qemu-devel/2020-07/msg04680.html

+-- On Tue, 1 Dec 2020, Paolo Bonzini wrote --+
| qtests are not just helpful.  Adding regression tests for bugs is a *basic* 
| software engineering principle.  If you don't have time to write tests, you 
| (or your organization) should find it.

* I've been doing the patch work out of my own interest.

* We generally rely on upstream/engineering for fix patches, because of our 
  narrower understanding of the code base.

+-- On Wed, 2 Dec 2020, Markus Armbruster wrote --+
| Paolo Bonzini <pbonzini@redhat.com> writes:
| > you need at least to enclose the reproducer, otherwise you're posting a 
| > puzzle not a patch. :)
| 
| Indeed. Posting puzzles is a negative-sum game.]

* Agreed. I think the upcoming 'qemu-security' list may help in this regard.  
  As issue reports+reproducer details shall go there.

* Even then, we'll need to ask reporter's permission before sharing their 
  reproducers on a public list OR with non-members.

* Best is if reporters share/release reproducers themselves. Maybe we can have 
  a public git repository and they can send a PR to include their reproducers 
  in the repository.

* That way multiple reproducers for the same issue can be held together.


Thank you.
--
Prasad J Pandit / Red Hat Product Security Team
8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D

reply via email to

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