Re: CVE-2023-43628?

[Miroslav Lichvar]

On Mon, Dec 11, 2023 at 08:13:04AM -0500, Greg Troxel wrote:
> This is a low-quality report because it uses an identifier that does not
> reference a specific version, when surely they testeed a particular git
> commit which could have been identified.  They also failed to identify
> the git commit that was fixed.  Reading the logs, which of course anyone
> can do, it looks like
> 
>   3e5c6c28c422102dd453e31912e1e79d1f7ff7f2

That commit seems to fix it. The first commit that I can reproduce the
issue with is c1c1c2706c4f5b9bf3be437d0a8f0106ef00c5e7. Interestingly
it crashes for me only under valgrind. glibc seems to be detecting
negative values, or maybe I'm missing something.

> > If this doesn't impact an actual release, could you please dispute it
> > with MITRE?
> 
> Does MITRE have a policy of only assigning CVEs for releases?

I don't know if it's written anywhere, but that seems to be the case
for many projects. I don't see why gpsd should be different. Users are
not expected to be using development code in production. If they do
and there is a security issue, it's their problem, not the upstream's.

Expecting development code to be bugfree at every commit is
unreasonable. Thorough testing and fuzzing needs time. What would be
the point of making a release otherwise?

CVEs are normally requested by upstream maintainers. Cisco is probably
a CVE numbering authority, but they should ask the maintainers first.

> A meta question: are you writing as an individual gpsd user, or in your
> capacity as a Red Hat employee?

As a downstream maintainer of the gpsd package in Fedora and
RHEL/Centos.

-- 
Miroslav Lichvar