haoNoQ wrote: I think there should be a way to enable/disable this check separately because memory exhaustion / denial of service isn't necessarily something you care about when you enable taint analysis.
It's essential for web servers when the attacker is interested in interrupting their operation but not necessarily for personal devices where the attacker is interested only in gaining control of the device. For these applications it's more important to catch cases where malloc size and index used for access are coming from "different sources", eg. one is tainted and another isn't, doesn't matter which one. For the same reason, I think the error node needs to be non-fatal. If you make it fatal, you lose the opportunity to catch this other type of bugs on the same path, which are 50% likely to be found on the same path, and are arguably much more severe. Of course when your new check is disabled there won't be a sink so we'll still catch the other bug. But we don't actually want it to work this way; we'd rather have the user control the warnings they want to see with simple on-off flags without weird interactions between those flags. So sink generation should be mostly a thing that "modeling" checkers do, when they're confident that we simply cannot continue analysis further. In this case I don't really see any problems with continuing the analysis so it should probably be a non-fatal error. https://github.com/llvm/llvm-project/pull/92420 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
