From: Thomas Petazzoni via buildroot <buildroot@buildroot.org>
To: nvd <nvd@nist.gov>
Cc: "buildroot@buildroot.org" <buildroot@buildroot.org>
Subject: Re: [Buildroot] Numerous issues in CVEs for the "sox" project
Date: Sat, 17 May 2025 22:54:05 +0200 [thread overview]
Message-ID: <20250517225405.4d8fb0fe@windsurf> (raw)
In-Reply-To: <20250517220322.4da9bdb3@windsurf>
Hello (again),
I'm following up on this, because the naming situation is even worse as
I just discovered CVE-2021-40426 who also affects sox, but is using yet
another CPE identifier: libsox_project:libsox.
This further justifies a cleanup in the naming of the sox project in
terms of CPE identifiers.
Let me know if you have any questions!
Best regards,
Thomas
On Sat, 17 May 2025 22:03:22 +0200
Thomas Petazzoni <thomas.petazzoni@bootlin.com> wrote:
> Hello,
>
> I am contacting you to report a significant number of issues related to
> the annotation on CVEs reported against the "sox" project in the NVD
> database.
>
> Naming change
> =============
>
> The CPE ID used to identify the project used to be
> sound_exchange_project:sound_exchange, and then got changed in the
> middle to sox_project:sox. This is extremely annoying for consumers of
> the NVD data as they can't match against a single CPE identifier. When
> you do such renames, either the old entries should be amended to also
> have a CPE configuration with the new name, or the new entries should
> have a CPE configuration with the old name.
>
> Regardless of this, the "cut" in the renaming is anyway bogus. CVEs
> with the old sound_exchange_project:sound_exchange identifier:
>
> CVE-2014-8145
> CVE-2017-11332
> CVE-2017-11358
> CVE-2017-11359
> CVE-2017-15370
> CVE-2017-15371
> CVE-2017-15372
> CVE-2017-15642
> CVE-2017-18189
> CVE-2019-1010004
> CVE-2019-13590
> CVE-2019-8354
> CVE-2019-8355
> CVE-2019-8356
> CVE-2019-8357
> CVE-2023-34432
>
> So it was used from 2014 to 2019... and then an outlier in 2023.
>
> Then CVEs with the new sox_project:sox identifier:
>
> CVE-2021-23159
> CVE-2021-23172
> CVE-2021-23210
> CVE-2021-33844
> CVE-2021-3643
> CVE-2022-31650
> CVE-2022-31651
> CVE-2023-26590
> CVE-2023-32627
> CVE-2023-34318
>
> So it started being used in 2021... but that means CVE-2023-34432 is
> clearly bogus.
>
> CPE identifiers with incorrect versions
> =======================================
>
> CVE-2021-23159
> CVE-2021-23172
> CVE-2021-23210
> CVE-2021-33844
>
> are reported as affecting version 14.4.2-7 but that version doesn't
> exist in the upstream sox project. 14.4.2 does and most likely should
> be used here. 14.4.2-7 looks like a Debian-specific version, but does
> not make any sense in this context.
>
> CVE-2023-26590
> CVE-2023-32627
> CVE-2023-34318
>
> are reported as affecting version 14.4.3, but that version doesn't
> exist in the upstream sox project.
>
> See at https://sourceforge.net/projects/sox/files/sox/ the released
> versions of sox.
>
> CPE identifiers should use version ranges
> =========================================
>
> All of:
>
> CVE-2017-11332
> CVE-2017-11358
> CVE-2017-11359
> CVE-2017-15370
> CVE-2017-15371
> CVE-2017-15372
> CVE-2017-15642
> CVE-2019-13590
> CVE-2019-8354
> CVE-2019-8355
> CVE-2019-8356
> CVE-2019-8357
> CVE-2021-23159
> CVE-2021-23172
> CVE-2021-23210
> CVE-2021-33844
> CVE-2021-3643
> CVE-2022-31650
> CVE-2022-31651
> CVE-2023-26590
> CVE-2023-32627
> CVE-2023-34318
>
> pretend that only one specific version is affected by the CVE (14.4.2,
> 14.4.2-7, 14.4.1, 14.4.3), while nothing indicates that just this
> version is affected. Most likely earlier versions are affected as well,
> and therefore the CPE identifier should rather state that all versions
> up to and including 14.4.2 are affected.
>
> Do you think you could address those different issues in the NVD
> database?
>
> Thanks a lot for your support!
>
> Thomas Petazzoni
--
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
prev parent reply other threads:[~2025-05-17 20:54 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-17 20:03 [Buildroot] Numerous issues in CVEs for the "sox" project Thomas Petazzoni via buildroot
2025-05-17 20:54 ` Thomas Petazzoni via buildroot [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250517225405.4d8fb0fe@windsurf \
--to=buildroot@buildroot.org \
--cc=nvd@nist.gov \
--cc=thomas.petazzoni@bootlin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox