[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <07bdaddb-1414-492b-a178-93b38f8ac3a0@gmail.com>
Date: Fri, 6 Jun 2025 18:00:09 +0200
From: Attila Szasz <szasza.contact@...il.com>
To: eschwartz@...too.org, oss-security@...ts.openwall.com
Subject: Re: Re: Linux kernel: HFS+ filesystem implementation, issues,
exposure in distros
> 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.
I don't see how Canonical Product Security is a bad actor here for caring
about the actual security of downstream users and acting in a timely
manner about an issue that they considered to impact Ubuntu Linux,
correctly.
Canonical has a scope of
"All Canonical issues (including Ubuntu Linux) only."
kernel.rg has a scope of
"Any vulnerabilities in the Linux kernel as listed on kernel.org, excluding
end-of-life (EOL) versions."
Both of them were contacted.
4.2.2.1 CNAs SHOULD assign a CVE ID if:
the CNA has reasonable evidence to determine the existence of a
Vulnerability (4.1), and
the Vulnerability has been or is expected to be Publicly Disclosed,
and
the CNA has appropriate scope (3.1).
On 3rd Nov, 2024, Kees Cook writes:
"The hfsplus filesystem currently has no maintainer, and since we don't
view filesystem corruption flaws to be particularly sensitive, probably
the best thing to do would be to send the patch like normal to the public
linux-fsdevel@...r.kernel.org (please keep me and other others in this
email's CC now on the CC for your patch).
Let's see if the VFS maintainers have any other thoughts on this?
(I am forwarding them a copy of the original email now.)"
This is pretty much the last update—no patch is introduced, nor is a CVE
issued. The issue is not viewed as sensitive.
My understanding is that 4.1 was not satisfied according to them.
CVE-2025-0927 was reserved by Canonical on 31st January, 2025, around the
time they fixed the issue internally.
At this point, Canonical, as per 4.2.2.1, assigned a CVE for Canonical
Ubuntu Linux for the issue they deemed a vulnerability in Ubuntu Linux.
The kernel neither assigned nor fixed anything regarding the email that was
sent to them.
After Canonical’s fix went live, the public advisory was published on
18 March, 2025.
Now, according to:
4.2.1.2 For Publicly Disclosed Vulnerabilities, if the CNA with the most
appropriate scope:
preemptively documents that it will not assign, or
responds within 72 hours that it will not assign, or
does not respond within 72 hours,
then an appropriate Root MUST make a Vulnerability determination.
So the kernel.org CNA team would have had 72 hours to respond to the public
disclosure if they thought that the issue was in their scope—but they
didn’t.
I don't know about the Root CNA, but it is not like anybody reached out
to me.
So what the hell happens to consumers of the Ubuntu Linux product
that don't want their boxes rooted by non-sudoers according to the CNA?
How could Canonical be the bad cowboy here? Someone please enlighten me.
In fact, I'm not even sure upstream would have ever fixed this unless
Salvatore
reached out from Debian basically asking what had happened:
https://lore.kernel.org/lkml/Z9xsx-w4YCBuYjx5@eldamar.lan/
Note that the initial report was received by security@ early November,
2024.
Salvatore's message is dated 20th March.
After that, Canonical helps Debian by sharing the fix they used in the
Ubuntu kernel.
Then, on 24th March, 2024, the Linux CNA finally expresses interest in
owning the CVE—that is, 6 days after the disclosure and 72 hours past the
deadline defined in 4.2.1.2.
Only then is the bug finally fixed, on 7th April—156 days after the report,
156 days after receiving the complete writeup and exploit code in the
first place.
The CVE, now transferred to kernel.org's scope is rejected on the
8th of April UTC 4am - from my timezone, on the same day.
Canonical addressed everything within 90 days. What's the problem?
Prioritizing the misinterpretation of a piece of bureaucratic text just
to label a
legitimate Product Security team as a "bad actor" and to focus on
hypothetical penalties—rather than caring about the actual security of
real-world
systems and users—is categorically *stupid*.
The real priority should be ensuring that users and businesses are:
*
properly informed about the risks, and
*
provided with the necessary remediation steps.
Anything else is a distraction from what truly matters.
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.
