[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CVE-2023-43628?
From: |
Greg Troxel |
Subject: |
Re: CVE-2023-43628? |
Date: |
Mon, 11 Dec 2023 08:59:38 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.2 (berkeley-unix) |
Miroslav Lichvar <mlichvar@redhat.com> writes:
> 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.
I suspect you aren't missing anything, and that C code that can
underflow is more or less UB and things being caught is within that, but
not reliable across all environments.
>> 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.
I don't see why you can't complain to MITRE about this, if that's how
you feel. If they don't have a written policy, complaining about that
first seems appropriate.
> 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?
I can see your point, but as I said "people like to assign CVEs". And,
many projects are not making releases, or not making them adequately.
> CVEs are normally requested by upstream maintainers. Cisco is probably
> a CVE numbering authority, but they should ask the maintainers first.
We'll see what Gary says, but I would be extremely surprised if he went
to MITRE and asked for a CVE. I would expect just fixing the bug.
Were it me, I would have just fixed it.
>> 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.
Thanks for clarifying. As you know there's a complicated world of who's
doing what for whom, and expecting upstreams to do free work, so I like
to be clear on the situation. And thank you for being straightforward
and writing from the company account for company work. Not everybody
does that.
My impression is that this CVE being in the database isn't causing any
problems for the gpsd maintainers, and therefore nobody is going to
expend any tilting-at-windmills effort to do anything. Is it causing
you problems, vs just seeming not right?
Re: CVE-2023-43628?, Gary E. Miller, 2023/12/11