Improve CERT DCL30-C stack return analysis

[JeewoongKim]

Description

Fixes #495.

This updates the CERT C DCL30-C function-return query to use the stack-return analysis
from cpp/return-stack-allocated-memory.

The previous implementation used the legacy local data-flow API and missed some stack-derived
pointer returns. (e.g., char a[2] ; return a + 1;)

The changes include:

• switch the query to the IR-based MustFlow analysis
• handle field addresses and pointer offsets
• update the query to a path query
• add regression tests for pointer-offset and field-address returns

The function-return query now focuses on return values. Stack-address escapes through output
parameters are still covered by the separate AppropriateStorageDurationsStackAdressEscape query.

Tested locally:

• codeql test run --show-extractor-output c/cert/test/rules/DCL30-C
• python scripts/validate-rule-package.py c/Declarations8

Change request type

• Release or process automation (GitHub workflows, internal scripts)
• Internal documentation
• External documentation
• Query files (.ql, .qll, .qls or unit tests)
• External scripts (analysis report or other code shipped as part of a release)

Rules with added or modified queries

• No rules added
• Queries have been added for the following rules:
  • rule number here
• Queries have been modified for the following rules:
  • DCL30-C

Release change checklist

Author: Is a change note required?

• Yes
• No

Query development review checklist

Author

• Have all the relevant rule package description files been checked in?
• Have you verified that the metadata properties of each new query is set appropriately?
• Do all the unit tests contain both "COMPLIANT" and "NON_COMPLIANT" cases?
• Are the alert messages properly formatted and consistent with the style guide?
• Have you run the queries on OpenPilot and verified that the performance and results are acceptable?
  As a rule of thumb, predicates specific to the query should take no more than 1 minute, and for simple queries be under 10 seconds. If this is not the case, this should be highlighted and agreed in the code review process.
• Does the query have an appropriate level of in-query comments/documentation?
• Have you considered/identified possible edge cases?
• Does the query not reinvent features in the standard library?
• Can the query be simplified further (not golfed!)

[MichaelRFairhurst]

Hi @JeewoongKim ! Thank you for sending!

My first thought is that I'd rather solve this while still using the C Objects API. It makes sense that c + 1 is a subobject of c, and we have some subobject support already where that could belong.

However, in general, this project would probably benefit from using the ir more often, so from that standpoint I really like your approach.

I'd like to triage the differences this shows in practice before deciding the next direction. I'm wondering if the c + 1 example was the only motivating case or if there were other cases you wanted to expand coverage of.

Thank you again!

[JeewoongKim]

Hi @MichaelRFairhurst,

The concrete false negative I verified was the a + offset case.

I also wanted to cover field-address returns such as &s.x, since the core
ReturnStackAllocatedMemory query referenced by #495 handles both pointer offsets and field addresses.

So a + offset was the motivating false negative, while field-address returns were the additional
coverage I had in mind. The other added cases were mainly boundary checks for the IR-based implementation