github / github/codeql

False Negative: CloseReader.ql misses unclosed streams once construction moves into helpers or alternate APIs.

未關閉
#21,532 1 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視
question
主要語言
CodeQL
星號
10.1k
分支
2.1k
平均合併
2 天 15 小時
30 天內合併 PR
141

描述

Version
codeql 2.24.3

## Checker
- Checker id: `Likely Bugs/Resource Leaks/CloseReader.ql`
- Checker description: This checker detects instances of Reader, InputStream, or ZipFile objects that are created but not guaranteed to be closed on method exit, potentially causing resource leaks.

## Description of the false negative
All four samples still leave a reader or stream resource unclosed. The differences are superficial: one allocation is hidden behind a helper, one uses `Files.newInputStream(...)` instead of `new FileInputStream(...)`, one leaks a custom `InputStream`, and one leaks a `BufferedReader` built around a parameter stream.

None of those variations change the resource-management obligation.

## Affected test cases
### `PosCase1_Var4.java`
The stream is created in `openStream()` and immediately discarded by the caller. That is still a leak.

### `PosCase1_Var5.java`
`Files.newInputStream(...)` returns an `InputStream` that still needs to be closed.

### `PosCase2.java`
The custom stream object is allocated, used, and never closed.

### `PosCase4.java`
The `BufferedReader` wraps a parameter stream and is never closed, so the wrapper resource itself leaks.

## Reproduction code
### `PosCase1_Var4.java`
```java
// FileInputStream created but not closed should be flagged as resource leak.
package scensct.var.pos;

import java.io.FileInputStream;
import java.io.IOException;

public class PosCase1_Var4 {
// Variant 4: Extract creation to a helper method
private FileInputStream openStream() throws IOException {
return new FileInputStream("test.txt");
}

public void readFile() throws IOException {
openStream(); // Returned stream is not assigned or closed
}
}
```

### `PosCase1_Var5.java`
```java
// FileInputStream created but not closed should be flagged as resource leak.
package scensct.var.pos;

import java.io.FileInputStream;
import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Paths;

public class PosCase1_Var5 {
// Variant 5: Use Files.newInputStream (still an InputStream)
public void readFile() throws IOException {
Files.newInputStream(Paths.get("test.txt"));
// Not closed
}
}
```

### `PosCase2.java`
```java
// Custom InputStream without close() method created but not closed should be flagged.
package scensct.core.pos;

import java.io.InputStream;
import java.io.IOException;

public class PosCase2 {
// Custom InputStream that does not declare close()
static class CustomStream extends InputStream {
@Override
public int read() {
return -1;
}
// No close() method overridden
}

public void useStream() {
InputStream stream = new CustomStream(); // Instantiation with assignment
try {
stream.read(); // Use the stream to emphasize it's a resource
} catch (IOException e) {
// Ignore for test purposes
}
// Not closed
}
}
```

### `PosCase4.java`
```java
// Wrapper BufferedReader around parameter InputStream not closed should be flagged.
package scensct.core.pos;

import java.io.BufferedReader;
import java.io.InputStream;
import java.io.InputStreamReader;

public class PosCase4 {
public void wrapParameter(InputStream paramStream) {
BufferedReader reader = new BufferedReader(new InputStreamReader(paramStream)); // Wrapper assigned but not closed
}
}
```

## Cause analysis
The misses point to incomplete source modeling in `Likely Bugs/Resource Leaks/CloseReader.ql`. The rule seems strongest on very direct allocation forms, but it loses coverage once the resource comes back from a helper or from another factory API.

That is a problem for a leak checker. Real code uses utility methods and alternative constructors all the time, and the need to close the returned resource does not disappear when the allocation becomes one step less direct.

貢獻指南

開啟貢獻指南

研究方向

Start with Likely Bugs/Resource Leaks/CloseReader.ql and compare its source modeling with the four examples: PosCase1_Var4.java, PosCase1_Var5.java, PosCase2.java, and PosCase4.java. Run the affected query tests and confirm that each unclosed helper result, factory-created stream, custom InputStream, and BufferedReader wrapper is reported without regressing existing cases.

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

評估

技術堆疊
java
領域
security
Issue 類型
缺陷
難度
4/5
預估耗時
3-5 天
活躍度
冷清
描述清晰度
描述清楚
新手友好度
48/100

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。