If your Open Source project sees a steep increase in number of high quality security reports (mostly done with AI) right now (#curl, Linux kernel, glibc confirmed) please tell me the name of this project.

(I'd like to make a little list for my coming talk on this.)

Apache httpd, curl, Django, Firefox, glibc, GnuTLS, Haproxy, libssh, Linux kernel, python, Temporal, Wireshark, wolfSSL

More?

@bagder OpenLDAP is seeing more AI-assisted bug reports that claim to be security issues, but aren't.

E.g., calling a crash in a commandline tool a DoS (no, it's not a service).

@hyc yeps, the tools still have a hard time to distinguish between bugs and security reports but at least they are nowadays often accurately identifying real flaws, even if not vulnerabilities

@bagder the other one we see is calling assert failures crashes. It's not a SEGV, there's no possibility of data exfiltration or RCE. There's no security exposure, it's just a bug. One that was anticipated hypothetically by the original developer, but whose final disposition wasn't decided upon way back when.

E.g. /* can this even happen? */

They toss in an assert, and it lives quietly in the code for decades before someone definitively shows yes, it can happen...

@hyc @bagder An assert failure controlled by data from a different privilege domain is a DoS/data loss vuln. The meaning of assert is documenting that you believe something can't happen under the intended usage.
@dalias it's a DoS but not the same as an actual crash, which is unanticipated. There is zero security exposure from an assert failure: no data leak, no unauthorized access, no possibility of code injection. The trigger conditions are clearly spelled out in the assert itself, so it's trivially remedied. Calling it a security issue dilutes the word "security" to meaninglessness.
@hyc Not all security issues are code execution. Generally this kind of issue is much lower-severity, but it can cause loss of unsaved data or corruption of existing data by leaving it in an inconsistent state at termination. CVEs are still assigned for DoS vulns.
@dalias in general, I suppose so. For OpenLDAP, we only consider something a security issue if it results in someone getting unauthorized access to data. Anything else is just an ordinary bug, and since our LMDB database guarantees ACID transactions, crashes can't leave data in an inconsistent state so that's a non-issue.