Messages in this thread | | | From | Paolo Bonzini <> | Subject | Re: CVE-2023-52437: Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d" [resend] | Date | Wed, 21 Feb 2024 10:09:05 +0100 |
| |
Resending with LKML in Cc, since posting to the linux-cve-announce mailing list is restricted to moderators.
On 2/20/24 19:34, Greg Kroah-Hartman wrote: > Description > =========== > > In the Linux kernel, the following vulnerability has been resolved: > > Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d" > > This reverts commit 5e2cf333b7bd5d3e62595a44d598a254c697cd74. > > That commit introduced the following race and can cause system hung. > > md_write_start: raid5d: > // mddev->in_sync == 1 > set "MD_SB_CHANGE_PENDING" > // running before md_write_start wakeup it > waiting "MD_SB_CHANGE_PENDING" cleared > >>>>>>>>> hung > wakeup mddev->thread > ... > waiting "MD_SB_CHANGE_PENDING" cleared > >>>> hung, raid5d should clear this flag > but get hung by same flag. > > The issue reverted commit fixing is fixed by last patch in a new way.
Sometimes less than optimal descriptions end up even in Linux commit messages, and I understand that you're "not going to be adding anything additional to the report" other than the git commit message. [1] But this description is not just "suboptimal" English, it also makes zero sense since it refers to a "last patch" that does not exist.
There are dozens of distros, both commercial and non-commercial, whose users need a *real* description of what is being fixed. By writing CVE descriptions that make no sense, you're creating more work for everyone involved, without putting in place a process to clarify these things except through "the maintainers of the relevant subsystem affected"---who are not CC'd to these messages and therefore might not even know that the CVE announcement exists.
My suggestion is to CC the author of the fix and the maintainer, and if possible even go through a pre-verification phase similar to what's done for AUTOSEL patches. If some commit messages are irredeemable, or some situations are just too complex, and no one is willing to put the work that's required to do the work properly, the maintainer should have the possibility to NACK the creation of an unusable CVE entry like this one.
(Somewhat related to this, how are you going to handle patch dependencies? Sasha's GSD updates has a separate entry for each commit, the result being "vulnerabilities" with "no functional change" in their description. Are they instead going to be rolled into a single entry like this one now that you're actually creating CVEs?)
I am cautiously optimistic that this can be worked out and I agree with you that lots of bug fixes going into stable have potential security impact. But as this example shows, there's still more than a few kinks to be ironed out.
> The Linux kernel CVE team has assigned CVE-2023-52437 to this issue. > > > Affected and fixed versions > =========================== > > Issue introduced in 5.15.75 with commit 9e86dffd0b02 and fixed in 5.15.148 with commit 84c39986fe6d > Issue introduced in 6.1 with commit 5e2cf333b7bd and fixed in 6.1.74 with commit bed0acf330b2 > Issue introduced in 6.1 with commit 5e2cf333b7bd and fixed in 6.1.75 with commit cfa468382858 > Issue introduced in 6.1 with commit 5e2cf333b7bd and fixed in 6.6.13 with commit e16a0bbdb7e5 > Issue introduced in 6.1 with commit 5e2cf333b7bd and fixed in 6.6.14 with commit aab69ef76970 > Issue introduced in 6.1 with commit 5e2cf333b7bd and fixed in 6.7.1 with commit 0de40f76d567 > Issue introduced in 6.1 with commit 5e2cf333b7bd and fixed in 6.7.2 with commit 87165c64fe1a
So which one is it of these 6.{1,6,7}.y releases that fixed the issue?
> The Linux kernel CVE team recommends that you update to the latest > stable kernel version for this, and many other bugfixes. Individual > changes are never tested alone, but rather are part of a larger kernel > release. Cherry-picking individual commits is not recommended or > supported by the Linux kernel community at all. If however, updating to > the latest release is impossible, the individual changes to resolve this > issue can be found at these commits: > https://git.kernel.org/stable/c/84c39986fe6dd77aa15f08712339f5d4eb7dbe27 > https://git.kernel.org/stable/c/bed0acf330b2c50c688f6d9cfbcac2aa57a8e613 > https://git.kernel.org/stable/c/cfa46838285814c3a27faacf7357f0a65bb5d152 > https://git.kernel.org/stable/c/e16a0bbdb7e590a6607b0d82915add738c03c069 > https://git.kernel.org/stable/c/aab69ef769707ad987ff905d79e0bd6591812580 > https://git.kernel.org/stable/c/0de40f76d567133b871cd6ad46bb87afbce46983 > https://git.kernel.org/stable/c/87165c64fe1a98bbab7280c58df3c83be2c98478 > https://git.kernel.org/stable/c/bed9e27baf52a09b7ba2a3714f1e24e17ced386d
Half of these are reverting the revert. I understand that "cherry-picking individual commits is not recommended" but it looks like this is a bug in whatever scripts you are using. Are they public, so that fixes can be developed in the open?
Also, commit 87165c64fe1a9 (the revert of the revert) was marked 5.19+ but 5.15.148 does have the original revert. Does that mean that 5.15.148 still has the "issue with raid5 with journal device" (another hang, see https://lore.kernel.org/linux-raid/20240123005700.9302-1-dan@danm.net/) mentioned in the commit message for 87165c64fe1a9? If so, that contradicts the fact that updating to the latest release of a given LTS branch is the best course of action, since for some users 5.15.147 might be better than 5.15.148.
Paolo
[1] https://lwn.net/ml/linux-kernel/2024021518-stature-frightful-e7fc@gregkh/ [2] https://lwn.net/ml/linux-kernel/2024021430-blanching-spotter-c7c8@gregkh/
| |