Help finding ultimate source of a stack location....

[henrygab]

Can you help get me closer to a rule that points directly at the source of an error?

---

Background

This is based on a real-world investigation into an alert from Likely Bugs/Memory Management/StackAddressEscapes.ql. In alerts generated by that rule, the function that is pointed to as potentially erroneous is the function that is actually assigning the function's parameter (which at least one caller passed a stack address for). Unfortunately, the project is mature, so the function's definition will not be changed. Thus, I want to find the ultimate source ... which code caused a stack pointer to actually be used?

For this project, there are three functions, each of which takes a buffer pointer as the third parameter. Someone somewhere is passing a stack address for that third parameter. Unfortunately, there are many, many callers of those functions. I'm hoping to either generate project-specific rules (strawman / first-draft below) that catch calls to these three functions, where the third parameter is a stack location. I will then update the rule to include caller functions which are simply proxies ... eventually reaching full coverage. (see first question.)

Preferably, an alert would be generated that pinpoints the source location that causes the use of the stack location for these parameters. (see second question.)

---

Specific depot / functions

In particular, this alert fires in the TinyUSB project.

To start, I want to add alerts for any caller of the following three functions, where the caller provides a stack location as the 3rd parameter (buffer):

• bool dcd_edpt_xfer(uint8_t rhport, uint8_t ep_addr, uint8_t * buffer, uint16_t total_bytes);
• bool usbd_edpt_xfer(uint8_t rhport, uint8_t ep_addr, uint8_t * buffer, uint16_t total_bytes);
• bool tud_control_xfer(uint8_t rhport, tusb_control_request_t const * request, void* buffer, uint16_t len);

This is because, unless additional checks are done to wait for the completion of the request, such callers would invite stack corruption (as noted in StackAddressEscapes.ql).

---

First-pass at Query (for review)

This first draft matches when the buffer pointer is stored in the stack. I'm looking for it to match when the pointer itself points to a stack location....

/**
 * @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
 
 predicate isStackPointer(Expr e) {
    exists(StackVariable sv | e = sv.getAnAccess())
 }

from Call call, Expr use, string msg
where
    // limit call to the three interesting functions
    (
        call.getTarget().getName() = "dcd_edpt_xfer" or
        call.getTarget().getName() = "usbd_edpt_xfer" or
        call.getTarget().getName() = "tud_control_xfer"
    )
    and
    // limit use to be the third parameter of those functions (aka `buffer`)
    call.getArgument(2) = use /* all these take `buffer` as the 3rd argument, zero-indexed */
    and
    // limit use to cases where the parameter is a stack pointer
    isStackPointer(use)
    and
    msg = "A stack address ($@) is passed as `buffer` to " + call.getTarget().getName() + "."
select use, msg, call

---

Question:

1. My first draft fires when the place storing the pointer parameter is on the stack. How do I modify this to only fire when the address pointed-to is on the stack?
2. Is there an easy way to have the alerts identify the "ultimate source" that provided a pointer to the stack?

... ultimate source example ...

For example:

// 
static struct { void* forAsyncProcessing; } s_bufferToProcess;
bool usbd_edpt_xfer(uint8_t rhport, uint8_t ep_addr, uint8_t * buffer, uint16_t total_bytes) {
    // validates things, then a line that willl cause alert from StackAddressEscapes.ql
    s_bufferToProcess.forAsyncProcessing = buffer;
}
bool usbd_edpt_xfer_wrapper(uint8_t rhport, uint8_t ep_addr, uint8_t * buffer, uint16_t total_bytes) {
    // does some stuff... and then calls the function mentioned in the draft new rule
    usbd_edpt_xfer(rhport, ep_addr, buffer, total_bytes);
}
static uint8_t static_buffer[10];
void foo() {
    // this should not fire
    usbd_edpt_xfer_wrapper(0, 0, &(static_buffer[0]), 10);
}
void bar() {
    uint8_t stack_buffer[10];
    // this should cause the rule to fire, pointing to next line as problem
    usbd_edpt_xfer_wrapper(0, 0, &(stack_buffer[0]), 10);
}

---

I feel close ... the query is finding callers who first store the pointer on the stack (vs. the pointed-to-location being on stack), and it feels like I just need a nudge in the right direction.

Any help improving these and getting them to do the right thing is greatly appreciated!

[smowton]

Does stackPointerFlowsToUse (requires import semmle.code.cpp.dataflow.StackAddress) as used in StackAddressEscapes.ql do what you want? It caters for quite a few cases where a stack address flows to a particular expression (here, use), and provides the parameter source to optionally export a more user-friendly description of the escaping allocation.

[henrygab]

I think so, but ... I'm new at CodeQL, so I'm stumbling over terminology, and how to express concepts correctly. Thank you for any grace offered as I stumble with the terms of art here. I'll try to express my desired result, and what I've tried. CodeQL is an amazing framework, so I'm willing to invest and learn the language. (I've worked through [0.0 .. 2.1] of the UBoot CTF, for example ... great, even without reference answers being available!)

---

More detailed description of how I got here

StackAddressEscapes.ql actually generated alert 195 and alert 196, which started my current journey. If you cannot load those pages directly (never sure what's shown to the public from the security tab), it reports the following:

---

Copy of Alert 195 details

Note: If not accessible, fork https://github.com/hathach/tinyusb and run the existing CodeQL action. The following will appear in the report.

Local variable address stored in non-local memory

src/device/usbd_control.c:108

// If the request's wLength is zero, a status packet is sent instead.
  bool tud_control_xfer(uint8_t rhport, const tusb_control_request_t* request, void* buffer, uint16_t len) {
  _ctrl_xfer.request = (*request);
  _ctrl_xfer.buffer = (uint8_t*) buffer;

[!WARNING]
A stack address which arrived via a parameter may be assigned to a non-local variable.
CodeQL

  _ctrl_xfer.total_xferred = 0U;
  _ctrl_xfer.data_len = tu_min16(len, request->wLength);

---

Copy of Alert 196 details

Note: If not accessible, fork https://github.com/hathach/tinyusb and run the existing CodeQL action. The following will appear in the report.

Local variable address stored in non-local memory

src/portable/st/stm32_fsdev/dcd_stm32_fsdev.c:762

  tusb_dir_t const dir = tu_edpt_dir(ep_addr);
  xfer_ctl_t *xfer = xfer_ctl_ptr(ep_num, dir);

  xfer->buffer = buffer;

[!WARNING]
A stack address which arrived via a parameter may be assigned to a non-local variable.
CodeQL

  xfer->ff = NULL;
  xfer->total_len = total_bytes;
  xfer->queued_len = 0;

---

At least one of these two alerts is valid. There is an actual situation where a stack-based buffer is used, and it's stored in non-stack space, and there is no code which waits for the hardware to complete the request. There is a risk of stack corruption here.

Unfortunately, the alerts fail to give easily actionable information. The use variable points to where the stack parameter (buffer) is being stuffed into the structure for the hardware to handle. If that was architecturally the problem, this would be the important part of the code to change. But, at least in this design, it's not the most critical information. Rather, the reviewer needs to see where that buffer pointer originated (was allocated on a stack), and probably the call tree that got to this spot.

Because this information is missing, the alerts require manually tracing all callers of the function, and checking if the buffer parameter came from a stack allocation. If it came in as a parameter, the manual tracing must be done recursively. As you can imagine, this is not only a time-consuming manual review, but it is inherently more error-prone than having CodeQL point out how it occurred. Worse, in this project, 98% of the time buffer comes from a statically allocated structure (e.g., dead end for bug hunting). After reviewing 75% which are all dead-ends (non-bugs), users may think the alert is too noisy or just plain wrong (human nature).

Again, I found at least one instance where one of the alerts could potentially corrupt stack. But ... there's got to be better information available through CodeQL....

What I want to achieve:

Given the current cpp/stack-address-escape alerts are only showing where the buffer parameter was used, I thought it would be much stronger to show where the buffer parameter was assigned to certain functions' third parameter ... with a rule that explained how it was permitted, but only if the code also waited for hardware completion of the transfer.

The alert generated should focus on three locations:

1. Where the stack-based item was allocated
2. Each function call which passed the relevant pointer-to-stack, until ...
3. The location the pointer-to-stack was stored in a non-stack location

[henrygab]

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

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.

Strawman StackAllocated class

Intended result:

Matches stack-allocated expression in a form that can be used with
TaintTracking and Flow::PathGraph to find which code paths cause
the cpp/stack-address-escape to be triggered.

For first pass, it's acceptable to limit this to variables that are explicitly
allocated on the stack (e.g., not dealing with C++ classes, member
functions, etc.).

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....