All of 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.