[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f85fe431-9400-4262-a5d0-71697abd9e31@gentoo.org>
Date: Thu, 5 Jun 2025 23:24:51 -0400
From: Eli Schwartz <eschwartz@...too.org>
To: oss-security@...ts.openwall.com
Subject: Re: Re: Linux kernel: HFS+ filesystem implementation
issues, exposure in distros
On 6/5/25 10:24 PM, Solar Designer wrote:
> On Tue, Jun 03, 2025 at 12:38:11PM +0200, Attila Szasz wrote:
>> 3) The mismatch in CVE criteria between upstream and downstream distros is
>> a real issue. During the handling of my case, a certain CNA rule was
>> repeatedly cited—without being specified—which led to CVE-2025-0927,
>> initially allocated for Canonical Ubuntu Linux, being reassigned under
>> kernel.org’s CNA. I understand that MITRE's rules around CNA territories
>> and
>> ownership were originally designed to distribute workload and filter out
>> noise, but they should be revisited as they can be ambiguous and
>> misinterpreted.
>> Especially in cases where one CNA’s product embeds another’s. According
>> to my
>> experience, this creates more confusion than clarity.
Presumably the kernel.org stance is that MITRE's territory rules are
working as intended as it allowed them to filter out your "noise", per
their analysis.
> Yes, this appears problematic. I think a distro got to be able to
> assign a CVE against their whole product or a component they have
> without this implying upstream is also affected or agrees the issue is a
> vulnerability, as long as they make it very clear that the CVE is for
> their specific usage of the component. As you wrote in:
>
> https://lore.kernel.org/lkml/6191c255-84cc-4721-91d1-1884472989f7@gmail.com/
> [...]
> Wow.
>
> To be fair, a kernel bug does not imply a kernel vulnerability, which I
> assume is the point the kernel CNA is making by rejecting the CVE.
>
> But them precluding Ubuntu from acknowledging their distro vulnerability
> by having a CVE against Ubuntu feels inappropriate anyhow.
>
> Where you write "obfuscate", I wrote "make it very clear that the CVE is
> for their specific usage of the component". Maybe that's the way to go.
If it is genuinely not a kernel vulnerability, but only a Ubuntu one for
using the kernel outside of its supported operating parameters, then
"make it very clear" does indeed sound correct.
If Ubuntu (or others) believe the kernel.org CNA is incorrect and a)
abusing their authority / b) simply lacking good judgement on security
matters, for something that is a legit kernel vulnerability, isn't that
what the appeals arbitration process is for? Raise the dispute with the
appropriate root, and have them overturn the kernel.org decision.
It is, anyways, inappropriate "cowboy justice" for a CNA to violate its
scope and assign a CVE number they aren't authorized for, just because
they disagree with the other CNA's decision. If Ubuntu (knowingly) isn't
going through the correct process then for that reason alone Ubuntu is
the bad actor here and should be penalized.
--
Eli Schwartz
Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (237 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
