Received-SPF: pass (google.com: domain of linux-kernel+bounces-75248-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Message-ID: <5ab460b4-91fb-429b-aa41-cdbb2b1a8e32@redhat.com>
Date: Wed, 21 Feb 2024 19:09:52 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: CVE-2023-52437: Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING
 in raid5d"
Content-Language: en-US
To: Sasha Levin <sashal@kernel.org>
Cc: linux-kernel@vger.kernel.org, cve@kernel.org,
 Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
 Jiri Kosina <jkosina@suse.cz>
References: <7ae646b3-28e4-4344-a7a4-730a0d6e3f38@redhat.com>
 <CABgObfYDcFPRNpGtsY=UbstXbqVCMcxy3LPS_xJ65aFcByC=Nw@mail.gmail.com>
 <ZdXt09vL4GJy6PbP@sashalap> <0e8675e0-165d-4cf7-9755-666278868ab8@redhat.com>
 <ZdX2LcAWR6wyvYC5@sashalap> <bec7c1db-c13e-4b00-a968-4ae69539d7ac@redhat.com>
 <ZdYKSkqRckOc5aRO@sashalap> <a9652aa2-e79b-4144-b3b7-746587af9eca@redhat.com>
 <ZdYSmdUKzQAYpprc@sashalap> <3ebbc121-8cb8-4b8d-ad5d-fb5c576e5171@redhat.com>
 <ZdYjXmA_1OvcS_CZ@sashalap>
From: Paolo Bonzini <pbonzini@redhat.com>
Autocrypt: addr=pbonzini@redhat.com; keydata=
 xsEhBFRCcBIBDqDGsz4K0zZun3jh+U6Z9wNGLKQ0kSFyjN38gMqU1SfP+TUNQepFHb/Gc0E2
 CxXPkIBTvYY+ZPkoTh5xF9oS1jqI8iRLzouzF8yXs3QjQIZ2SfuCxSVwlV65jotcjD2FTN04
 hVopm9llFijNZpVIOGUTqzM4U55sdsCcZUluWM6x4HSOdw5F5Utxfp1wOjD/v92Lrax0hjiX
 DResHSt48q+8FrZzY+AUbkUS+Jm34qjswdrgsC5uxeVcLkBgWLmov2kMaMROT0YmFY6A3m1S
 P/kXmHDXxhe23gKb3dgwxUTpENDBGcfEzrzilWueOeUWiOcWuFOed/C3SyijBx3Av/lbCsHU
 Vx6pMycNTdzU1BuAroB+Y3mNEuW56Yd44jlInzG2UOwt9XjjdKkJZ1g0P9dwptwLEgTEd3Fo
 UdhAQyRXGYO8oROiuh+RZ1lXp6AQ4ZjoyH8WLfTLf5g1EKCTc4C1sy1vQSdzIRu3rBIjAvnC
 tGZADei1IExLqB3uzXKzZ1BZ+Z8hnt2og9hb7H0y8diYfEk2w3R7wEr+Ehk5NQsT2MPI2QBd
 wEv1/Aj1DgUHZAHzG1QN9S8wNWQ6K9DqHZTBnI1hUlkp22zCSHK/6FwUCuYp1zcAEQEAAc0j
 UGFvbG8gQm9uemluaSA8cGJvbnppbmlAcmVkaGF0LmNvbT7CwU0EEwECACMFAlRCcBICGwMH
 CwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRB+FRAMzTZpsbceDp9IIN6BIA0Ol7MoB15E
 11kRz/ewzryFY54tQlMnd4xxfH8MTQ/mm9I482YoSwPMdcWFAKnUX6Yo30tbLiNB8hzaHeRj
 jx12K+ptqYbg+cevgOtbLAlL9kNgLLcsGqC2829jBCUTVeMSZDrzS97ole/YEez2qFpPnTV0
 VrRWClWVfYh+JfzpXmgyhbkuwUxNFk421s4Ajp3d8nPPFUGgBG5HOxzkAm7xb1cjAuJ+oi/K
 CHfkuN+fLZl/u3E/fw7vvOESApLU5o0icVXeakfSz0LsygEnekDbxPnE5af/9FEkXJD5EoYG
 SEahaEtgNrR4qsyxyAGYgZlS70vkSSYJ+iT2rrwEiDlo31MzRo6Ba2FfHBSJ7lcYdPT7bbk9
 AO3hlNMhNdUhoQv7M5HsnqZ6unvSHOKmReNaS9egAGdRN0/GPDWr9wroyJ65ZNQsHl9nXBqE
 AukZNr5oJO5vxrYiAuuTSd6UI/xFkjtkzltG3mw5ao2bBpk/V/YuePrJsnPFHG7NhizrxttB
 nTuOSCMo45pfHQ+XYd5K1+Cv/NzZFNWscm5htJ0HznY+oOsZvHTyGz3v91pn51dkRYN0otqr
 bQ4tlFFuVjArBZcapSIe6NV8C4cEiSTOwE0EVEJx7gEIAMeHcVzuv2bp9HlWDp6+RkZe+vtl
 KwAHplb/WH59j2wyG8V6i33+6MlSSJMOFnYUCCL77bucx9uImI5nX24PIlqT+zasVEEVGSRF
 m8dgkcJDB7Tps0IkNrUi4yof3B3shR+vMY3i3Ip0e41zKx0CvlAhMOo6otaHmcxr35sWq1Jk
 tLkbn3wG+fPQCVudJJECvVQ//UAthSSEklA50QtD2sBkmQ14ZryEyTHQ+E42K3j2IUmOLriF
 dNr9NvE1QGmGyIcbw2NIVEBOK/GWxkS5+dmxM2iD4Jdaf2nSn3jlHjEXoPwpMs0KZsgdU0pP
 JQzMUMwmB1wM8JxovFlPYrhNT9MAEQEAAcLBMwQYAQIACQUCVEJx7gIbDAAKCRB+FRAMzTZp
 sadRDqCctLmYICZu4GSnie4lKXl+HqlLanpVMOoFNnWs9oRP47MbE2wv8OaYh5pNR9VVgyhD
 OG0AU7oidG36OeUlrFDTfnPYYSF/mPCxHttosyt8O5kabxnIPv2URuAxDByz+iVbL+RjKaGM
 GDph56ZTswlx75nZVtIukqzLAQ5fa8OALSGum0cFi4ptZUOhDNz1onz61klD6z3MODi0sBZN
 Aj6guB2L/+2ZwElZEeRBERRd/uommlYuToAXfNRdUwrwl9gRMiA0WSyTb190zneRRDfpSK5d
 usXnM/O+kr3Dm+Ui+UioPf6wgbn3T0o6I5BhVhs4h4hWmIW7iNhPjX1iybXfmb1gAFfjtHfL
 xRUr64svXpyfJMScIQtBAm0ihWPltXkyITA92ngCmPdHa6M1hMh4RDX+Jf1fiWubzp1voAg0
 JBrdmNZSQDz0iKmSrx8xkoXYfA3bgtFN8WJH2xgFL28XnqY4M6dLhJwV3z08tPSRqYFm4NMP
 dRsn0/7oymhneL8RthIvjDDQ5ktUjMe8LtHr70OZE/TT88qvEdhiIVUogHdo4qBrk41+gGQh
 b906Dudw5YhTJFU3nC6bbF2nrLlB4C/XSiH76ZvqzV0Z/cAMBo5NF/w=
In-Reply-To: <ZdYjXmA_1OvcS_CZ@sashalap>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 2/21/24 17:22, Sasha Levin wrote:
> On Wed, Feb 21, 2024 at 04:56:31PM +0100, Paolo Bonzini wrote:
>>> So now you're asking us to drop this additional work on them by
>>> reviewing CVE requests?
>>
>> It doesn't have to be mandatory.  But for people that _do_ want to do
>> the work, they might as well do it before the CVE is publicly announced,
>> rather than after.  At least give us the possibility of doing it without
>> bureaucracy.
> 
> [...]
> 
>>> How were you aware until a few weeks ago where CVE assignments were
>>> handled by different entities?
>>
>> They more often than not CC'd me before the patch was committed and
>> provided me the CVE id, and I was able to provide input or dispute the
>> assignment beforehand.  This is exactly what I'm suggesting that the
>> kernel should do.
> 
> This is fascinating to know, because when multiple members of the
> community asked to review CVEs before they are assigned, certain few
> CNAs blatantly ignored such requests.
>
> Would you want to expand on why you got the courtesy of being able to
> review these assignments, while the rest of us had to jump through the
> hoops of becoming our own CNA just to stop from this crap from happening
> to us?

Probably because I generally get CVEs myself ahead of time for 
corruption or use-after-free bugs (in arch-independent or x86 KVM code). 
  So when somebody comes with a CVE it's usually Project Zero stuff and 
not something like CVE-2024-0562, and we work together.

If you can tell me (even privately) what CNAs these were, I can check. 
But probably the answer is simply that either they have never touched 
KVM, or the issues were under some kind of embargo.

>>> So yes, I disagree with your "all of them" statement. For that matter,
>>> I'd argue that the number of users who need massaged messages are the
>>> vast minority.
>>
>> They don't need massaged messages.  They need correct and complete ones.
>> You're completely removing the human part of the work and expecting
>> the result to be of comparable quality.  That's not going to happen, and
>> this CVE is an example of this.
> 
> I definitely agree that it would be nice to have better messages in
> CVEs, and I'd welcome interested parties to follow the process that was
> in place up until two weeks ago, and request an amendment to a CVE with
> a better description (or dispute an invalid one) with the CNA.
> This is exactly the same process that most of us had to follow in the
> past to address crappy CVE descriptions or bogus CVEs.

And what I am saying is that we need to do better.  Give the maintainer 
an opportunity to say at least yes or no.

>>>> 2) how are you going to handle patch dependencies?  Are they going to
>>>> be rolled into a single entry or split into multiple announcements?
>>>
>>> Likely multiple different entries.
>>
>> So, looking at
>> https://git.kernel.org/pub/scm/linux/security/vulns.git/tree/cve/review/6.7.proposed
>> I see
>>
>> aeb686a98a9e usb: gadget: uvc: Allocate uvc_requests one at a time
>> da324ffce34c usb: gadget: uvc: Fix use-after-free for inflight 
>> usb_requests
>>
>> What vulnerability is the first one fixing?  Looking at your GSD
> 
> Well, if you look at the first patch, it says "This patch is 1 of 2
> patches addressing the use-after-free issue.".

Right, it's *the* issue.  It's one CVE, not two.  The first patch is a 
dependency of the actual fix, it's not its own vulnerability.

>> entries, will there even be CVEs purporting that renaming a variable
>> from "foo" to "bar" is fixing a vulnerability?
> 
> Maybe? Hopefully not if it's not a real security issue.

What if it's a dependency of the actual issue/fix?

>> I like to assume the best of people, so I'll assume that this is just
>> naïveté rather than an intentional attempt at burning everything down.
>> But please, let's take a step back and understand what the proposed
>> workflow fixes and breaks for everyone (especially maintainers and
>> distros).  Then make a proper solution.  In the meanwhile you can keep
>> sending test announcements to linux-cve-announce, and those can be used
>> to debug the process and the scripts.
> 
> No objections on future improvements, right now we're still trying to
> get the basics working which is where the strong pushback on "feature
> requests" is coming from.

Got it.  But multiple commits per CVE is not a feature request, it's 
basic acknowledgement of how Linux is developed.

>> In fact it would be nice if bippy included at the end the command line
>> that was used, to aid the reproduction and fixing of bugs.
> 
> Bippy just maps commits to trees and formats the json, or did I
> misunderstand what you meant?

I would like to run bippy myself to understand how the commits in 
CVE-2023-52437 were chosen.

Paolo