`CON34-C`: Implementation seems to check incorrect aspects of thread storage duration objects

未關閉

#801 建立於 2024年11月20日 1 則留言 0 個 reaction 已指派 0 人在 GitHub 檢視

已經有一個關聯 PR 被合併了。

#778 來自 @lcartey —— 已合併

評估

難度: 4/5
預估耗時: 3-5 天
新手友好度: 35/100

Issue 類型: 缺陷
描述清晰度: 基本清楚
活躍度: 停滯
技術堆疊: c
領域: tooling

研究方向

從 CON34-C 的實作及其針對 tss_t 值的現有驗證開始，接著將其與此 issue 中的符合規範和不符合規範範例進行比較。當預期的 thread-storage 違規被回報，且無關的未初始化值案例不被歸因於 CON34-C 時，修改即完成；使用該規則可用的測試進行驗證。

由索引模型根據 Issue 內容生成。

描述

false positive/false negative Standard-CERT-C

Affected rules

CON34-C

Description

The documentation seems to describe the risk of passing a tss_t into a thread. The risk here is that the new thread will have no value.

In the "compliant" case it says the appropriate fix is to use tss_get() to get the value in the current thread, then pass that value into the new thread.

In our implementation, we check that any tss_t values are definitely given a value before retrieved and passed into a thread creation statement. This is not the intention of the rule, adds additional implementation complexity, and reveals no violations in MRVA.

Example

tss_t key;
void f1() {
  // Should be marked non-compliant: new thread has no value for tss_get(key)
  // Currently not reported
  thrd_create(..., &key);
}

void f2() {
  // While the following code is suspect, it is NOT the intention of the rule is not to disallow this:
  tss_t localkey;
  tss_set(localkey, malloc(...));
  void* v = tss_get(localkey);
  thrd_create(..., v);

  // The fact that v is uninitialized has nothing to do with threads. For instance, this is also erroneous:
  printf("%d", *v);

  // Further, the above code has nothing to do with thread storage duration, and isn't necessarily invalid:
  static void *shared_buf = malloc(...);
  thrd_create(..., shared_buf); // Reasonable pattern
}

主要語言: CodeQL
星號: 227
分支: 82
平均合併: 6 天 7 小時
30 天內合併 PR: 9