Re: [PATCH 3/5] gdb: extend SECURITY.txt discussion of DWARF/BFD parser bugs

[Siddhesh Poyarekar <sipoyare@redhat.com>]

n 10/14/26 11:12 AM, Tom Tromey wrote:
>>>>>> Siddhesh Poyarekar <sipoyare@redhat.com> writes:
> 
>> On 10/12/26 9:49 AM, Andrew Burgess wrote:
>>> 3. The real change: clearly state that bugs in the DWARF/BFD parser
>>> can be security bugs, but they are unlikely to be considered high
>>> priority, and users should instead use sandboxing to provide
>>> protection.  The text about bugs from well-formed programs is
>>> retained.
> 
>> I don't have a strong opinion on the meat of the change, but I want to
>> point out that this is not sufficient deterrence for people flooding
>> the project with such reports to get CVE creds in their name.  What
>> priority a CVE gets downstream is typically a result of perception and
>> the relatively dumb CVSS scores.  Unfortunately all major
>> distributions are currently lost to that madness and "unlikely to be
>> considered high priority" may not actually pan out that way in
>> practice.
> 
> I agree but we can only control gdb, not what other projects do.  That
> is, I think that CVEs are gamed dishonestly nowadays, but it's not clear
> to me what other options we have for dealing with this.
The glibc CNA plans to onboard the binutils project to the CNA program 
so that we can handle those and stem the CVE gaming for the project.  We 
could extend that to gdb too if there's interest, but we will need 
volunteers from the gdb team on the security team because the gdb 
security policy is a bit more complex to interpret than the binutils 
one, which assumes that all input as trusted.

Of course, we'd still need the policy to define what can be reasonably 
secured and exclude the rest from scope.

Sid