Path I've walked to getting desired information into the alert

This is now well past my ken... so my mistakes will be multiplying here as I learn the language.

The existing cpp/stack-address-escapes results in AssignExpr where a stack pointer is stored in a non-stack location. That's good, but painful as the starting point for tracking where this actually occurs.

However, that same primitive seems like it should be usable as a Sink in a DataFlow query.

class StackAddressEscapes extends AssignExpr {
 StackAddressEscapes() {
 this = any(
 AssignExpr assignExpr |
 stackPointerFlowsToUse(assignExpr.getRValue(), _, _, _) and
 not stackReferenceFlowsToUse(assignExpr.getLValue(), _, _, _)
 )
 }
 boolean getEscapeIsLocal() {
 result = any (
 boolean isLocal |
 stackPointerFlowsToUse(this.getRValue(), _, _, isLocal)
 )
 }
 Expr getEscapeSource() {
 result = any (
 Expr source |
 stackPointerFlowsToUse(this.getRValue(), _, source, _)
 )
 }
}

However, I'm stuck trying to understand...

1. How to define StackAddressAllocation class corresponding to AllocationExpr that allocated stack variables (rather than malloc/free/placement new/etc.)?
2. How to use StackAddressAllocation as the source node StackAddressEscapes class with the ` that stack allocation class with the

Unfortunately, my strawman class returns zero results, even when it's not filtering things.

import cpp
import semmle.code.cpp.dataflow.StackAddress
import semmle.code.cpp.dataflow.new.TaintTracking 
 
class StackAllocation extends AllocationExpr {
 StackAllocation() {
 // FIXME -- even with no filter, this gives zero results
 this = any(
 AllocationExpr e |
 // FIXME -- how to filter to things on the stack?
 // e.isStackAllocation() and 
 this = e
 )
 }
}
 
from
 StackAllocation stackAllocation
 , string msg
where
 msg = "Foo"
select
 stackAllocation
 , msg

Thus, I'm hoping for help understanding where I've gone astray....

So if I apply my suggestion to your QL, and fix a couple of minor things (switching call and use in the output since that way around is more natural; amending the alert message format; fixing the query ID to use lower-kebab-case), I think I get results matching what you describe:

/**
 * @name TinyUSB - local variable address passed as buffer for endpoint transfer
 * @description Passing the address of a local variable (stack address) as the
 * `buffer` for these functions can cause stack corruption when the
 * transfer is not completed before the stack location is re-used.
 * Typically, this requires waiting on an ISR to fire, as the transfer
 * may be handled asynchronously by hardware to that buffer.
 * @kind problem
 * @problem.severity warning
 * @precision medium
 * @id cpp/tinyusb/stack-address-as-buffer
 * @tags reliability
 */
import cpp
import semmle.code.cpp.dataflow.StackAddress
from Call call, Expr use, string msg, Expr source
where
 // limit call to the three interesting functions
 call.getTarget().getName() = ["dcd_edpt_xfer", "usbd_edpt_xfer", "tud_control_xfer"] and
 // limit use to be the third parameter of those functions (aka `buffer`)
 call.getArgument(2) = use and
 /* all these take `buffer` as the 3rd argument, zero-indexed */
 // limit use to cases where the parameter is a stack pointer
 stackPointerFlowsToUse(use, _, source, _) and
 msg =
 "A stack address ($@, which points to $@) is passed as `buffer` to " +
 call.getTarget().getName() + "."
select call, msg, use, use.toString(), source, source.toString()

Example result: A stack address (& ..., which points to rsp) is passed as ``buffer`` to tud_control_xfer. at usbtmc_device.c:763:15, which indeed uses a stack-allocated data structure usbtmc_initiate_abort_rsp_t rsp

This is common enough that I suspect you'll need to do some more filtering to eliminate safe uses of stack memory, but is this a start to what you want?

Awesome! Thanks for helping correct my CodeQL grammar.

Yes, the above query gets me closer to the ultimate goal, by showing uses of these functions where the buffer parameter is, in at least one path, a stack location. When the stack location is allocated in that calling function, that's easy to track, and "good enough" to enable the solution (with the occasional addition of more functions listed). 🎉

I can recursively start adding other functions that call into this, looking at their own corresponding incoming parameters.

Is there an existing way to get the path from initial allocation of the stack location, to where it's being used per this query?

Specifically, any alert showing dcd_edpt_xfer() as the culprit is ... less helpful ... because it just indicates that some caller of that function passed a stack location.

I can convert the above query to a class usable as a sink filter. But ... what sort of filter/match can be used to link the original stack allocation location to each use?

Using a Path query seems promising ... but that's possibly my ignorance showing. Am I looking in the right direction, or is there a cleaner path forward (no pun intended)?

Thank you again for the excellent help!

Wow! Some gems in here, giving me lots of pointers to edges of my knowledge. 💕 LOVE IT! 💕

On the positive side, this confirms that the one instance has no identical variants ... only one place passes a stack location to dcd_edpt_xfer() ... hooray!

After I get some time to dig into the above, I will try to update it to match (rather than the particular function manually entered) anything matching the stackAddressEscapes() predicate:

 stackPointerFlowsToUse(assignExpr.getRValue(), _, source, isLocal) and
 not stackReferenceFlowsToUse(assignExpr.getLValue(), _, _, _)

Your guidance has been very helpful. Now it's time for me to explore docs, experiment with modifications, and expand my knowledge. I will update with my path-based solution here ... but if I get blocked and frustration thresholds are reached, I will instead show my attempt(s) and ask for help understanding where I went astray. Again ... thank you! 🎉