Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

      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