[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2025060713-aloe-decency-a74c@gregkh>
Date: Sat, 7 Jun 2025 10:17:08 +0200
From: Greg KH <greg@...ah.com>
To: oss-security@...ts.openwall.com
Cc: eschwartz@...too.org
Subject: Re: Re: Re: Linux kernel: HFS+ filesystem
implementation, issues, exposure in distros
On Fri, Jun 06, 2025 at 06:00:09PM +0200, Attila Szasz wrote:
> 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.
For the record, the CNA for kernel.org was NOT contacted here at all for
this issue. You sent a message to security@...nel.org, NOT
cve@...nel.org. security@k.o has nothing to do with CVE assignments and
is NOT responsible for the kernel.org CNA. Our documentation should
state this very clearly, if not, we will be glad to update it where
needed, just let us know.
> 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.
Again, no one asked for a CVE to be assigned, nor did anyone notify the
kernel.org CNA about this issue.
> My understanding is that 4.1 was not satisfied according to them.
Nope, we never were even notified. That being said, we defer to the
filesystem maintainers here, and they have stated many times before that
hand-crafted filesystems are not a vulnerability according to their
rules. That is why we rejected the CVE eventually.
> 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.
Again, you never notified the kernel.org CNA about this, nor do we even
attempt to watch all CVEs that are being created in the system as we
just assume that all CNAs are "good actors" and don't do foolish things
like this :)
> 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.
They created a CVE against the upstream kernel.org codebase without EVER
contacting the kernel.org CNA. That is against the CNA rules, which is
why cve.org reassigned the CVE to kernel.org when notified of this.
> 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.
Again, security@k.o has nothing to do with CVEs.
> 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.
Again, no one ever notified cve@...nel.org about this, so that is why we
did not react until we actually were notified, and then we did act then
to get the CVE assigned back to kernel.org
Hope this helps explain things as to why the kernel.org CNA didn't do
anything here, because again, they were never notified.
Anyway, we know communication mistakes can happen, not a big deal, we
got the CVE reassigned properly, which again, happens every few months
with other companies accidentally assigning CVEs against kernel.org
stuff, and we move on. Given we are running at a rate of 13+ CVEs a
day, stuff like this is bound to happen. All we can do is properly deal
with it when we are notified, like we did.
thanks,
greg k-h
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.
