deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-5r4r-9fgh-pw53
Package: memory_pages (RUST)
Severity: LOW (CVSS 2.9)
CWE: CWE-369: Divide By Zero
Vulnerable versions: <= 0.1.0
Patched in: unpatched

Summary: memory_pages division by zero

Details:
In the memory_pages crate 0.1.0 for Rust, division by zero can occur.
GitHub Security Advisory: GHSA-mqwx-r894-9hfp
Package: process-sync (RUST)
Severity: LOW (CVSS 2.9)
CWE: CWE-416: Use After Free
Vulnerable versions: <= 0.2.2
Patched in: unpatched

Summary: Process Sync has a Potential Unsound Issue in SharedMutex

Details:
In the process-sync crate 0.2.2 for Rust, the drop function lacks a check for whether the pthread_mutex is unlocked.
GitHub Security Advisory: GHSA-6v24-6wgf-8vj6
Package: process_lock (RUST)
Severity: LOW (CVSS 2.9)
CWE: CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Vulnerable versions: <= 0.1.0
Patched in: unpatched

Summary: process_lock has a Potential Unsound issue in unlock

Details:
The process_lock crate 0.1.0 for Rust allows data races in unlock.
GitHub Security Advisory: GHSA-3qmp-g57h-rxf2
Package: pingora-core (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')
Vulnerable versions: < 0.5.0
Patched in: 0.5.0

Summary: Duplicate Advisory: Pingora Request Smuggling and Cache Poisoning

Details:
### Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-93c7-7xqw-w357. This link is maintained to preserve external references.

### Original Description

Pingora versions prior to 0.5.0 which used the caching functionality in pingora-proxy did not properly drain the downstream request body on cache hits.

This allows an attacker to craft malicious HTTP/1.1 requests which could lead to request smuggling or cache poisoning.

This flaw was corrected in commit fda3317ec822678564d641e7cf1c9b77ee3759ff by ensuring that the downstream request body is always drained before a connection can be reused.

See [the blog post](https://blog.cloudflare.com/resolving-a-request-smuggling-vulnerability-in-pingora/) for more information.
GitHub Security Advisory: GHSA-w443-5h3j-jqcp
Package: crossbeam-channel (RUST)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-415: Double Free
Vulnerable versions: >= 0.5.11, < 0.5.15
Patched in: 0.5.15

Summary: Duplicate Advisory: crossbeam-channel Vulnerable to Double Free on Drop

Details:
### Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-pg9f-39pc-qf8g. This link is maintained to preserve external references.

### Original Description
In crossbeam-channel rust crate, the internal `Channel` type's `Drop` method has a race condition which could, in some circumstances, lead to a double-free that could result in memory corruption.
GitHub Security Advisory: GHSA-gg76-hg3v-5q6c
Package: macroquad (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-416: Use After Free
Vulnerable versions: <= 0.4.14
Patched in: unpatched

Summary: macroquad vulnerable to multiple soundness issues

Details:
Several soundness issues have been reported. Resolving them doesn't seem to be considered a priority. In particular, unprincipled use of mutable statics is pervasive throughout the library, making it possible to cause use-after-free in safe code.

Currently, no fixed version is available.
GitHub Security Advisory: GHSA-w9q3-g4p5-5q2r
Package: sudo-rs (RUST)
Severity: LOW (CVSS 3.3)
CWE: CWE-497: Exposure of Sensitive System Information to an Unauthorized Control Sphere
Vulnerable versions: < 0.2.6
Patched in: 0.2.6

Summary: sudo-rs Allows Low Privilege Users to Enumerate Privileges of Others

Details:
### Summary
Users with limited sudo privileges (e.g. execution of a single command) can list sudo privileges of other users using the `-U` flag. This doesn't happen with the original sudo.

### PoC

The initial test has been done in a container running Ubuntu 24.04 and installing [oxidizr](https://github.com/jnsgruk/oxidizr), running sudo-rs 0.2.2.

A user (bob) has been added with only ps command executable through sudo:

```
root    ALL=(ALL:ALL) ALL
bob     ALL=(ALL:ALL) /usr/bin/ps
```

The user is not able to read the `/etc/sudoers` file and running `sudo -l -Uroot` with original sudo (version 1.9.15p5) causes the following error:

```
Sorry, user bob is not allowed to execute 'list' as root on 43d4aed3cdbd.
```

The same command with sudo-rs is run without denying the execution:

```
User root may run the following commands on 43d4aed3cdbd:
    (ALL : ALL) ALL
```

The same happens for other non-root users:

```
bob@43d4aed3cdbd:~$ sudo -l -Ufoo
User foo may run the following commands on 43d4aed3cdbd:
    (ALL : ALL) /usr/bin/whoami
```

The behavior has been also been observed for version 0.2.5.

### Impact
Users with limited sudo privileges can enumerate the sudoers file, revealing sensitive information about other users' permissions. Attackers can collect information that can be used to more targeted attacks.

Systems where users either do not have sudo privileges or have the ability to run all commands as root through sudo (the default configuration on most systems) are not affected by this advisory.

### Credits
This issue was identified by [Sonia Zorba](https://www.zonia3000.net/).
GitHub Security Advisory: GHSA-98cv-wqjx-wx8f
Package: sudo-rs (RUST)
Severity: LOW (CVSS 3.3)
CWE: CWE-497: Exposure of Sensitive System Information to an Unauthorized Control Sphere
Vulnerable versions: <= 0.2.5
Patched in: 0.2.6

Summary: sudo-rs Allows Low Privilege Users to Discover the Existence of Files in Inaccessible Folders

Details:
### Summary

Users with no (or very limited) sudo privileges can determine whether files exists in folders that they otherwise cannot access using `sudo --list <pathname>`.

### PoC

As root:
```
# mkdir /tmp/foo
# chmod a-rwx /tmp/foo
# touch /tmp/foo/secret_file
```
As a user without any (or limited) sudo rights:
```
$ sudo --list /tmp/foo/nonexistent_file
sudo-rs: '/tmp/foo/nonexistent_file': command not found
$ $ sudo --list /tmp/foo/secret_file
sudo-rs: Sorry, user eve may not run sudo on host.
```
I.e. the user can distinguish whether files exist.

### Related
Original sudo (vulnerable version tested by us: 1.9.15p5) exhibited similar behaviour for files with the executable bit set.

### Impact
Users with local access to a machine can discover the existence/non-existence of certain files, revealing potentially sensitive information in the file names. This information can also be used in conjunction with other attacks.

### Credits
This issue was identified by sudo-rs developer Marc Schoolderman
GitHub Security Advisory: GHSA-c86p-w88r-qvqr
Package: ring (RUST)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 0.17.13
Patched in: 0.17.13

Summary: Duplicate Advisory: ring has some AES functions that may panic when overflow checking is enabled in

Details:
### Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-4p46-pwfr-66x6. This link is maintained to preserve external references.

### Original Description
A flaw was found in Rust's Ring package. A panic may be triggered when overflow checking is enabled. In the QUIC protocol, this flaw allows an attacker to induce this panic by sending a specially crafted packet. It will likely occur unintentionally in 1 out of every 2**32 packets sent or received.
GitHub Security Advisory: GHSA-6x45-r4pr-5362
Package: trailer (RUST)
Severity: LOW (CVSS 2.9)
CWE: CWE-762: Mismatched Memory Management Routines
Vulnerable versions: <= 0.1.2
Patched in: unpatched

Summary: trailer mishandles allocating with a size of zero

Details:
lib.rs in the trailer crate through 0.1.2 for Rust mishandles allocating with a size of zero.
GitHub Security Advisory: GHSA-8m95-fffc-h4c5
Package: libsql-sqlite3-parser (RUST)
Severity: LOW (CVSS 2.9)
CWE: CWE-228: Improper Handling of Syntactically Invalid Structure
Vulnerable versions: <= 0.13.0
Patched in: unpatched

Summary: libsql-sqlite3-parser crash due to invalid UTF-8 input

Details:
dialect/mod.rs in the libsql-sqlite3-parser crate through 0.13.0 before 14f422a for Rust can crash if the input is not valid UTF-8.
GitHub Security Advisory: GHSA-2w4w-4385-vh4h
Package: wgp (RUST)
Severity: LOW (CVSS 2.9)
CWE: CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Vulnerable versions: <= 0.2.0
Patched in: unpatched

Summary: wgp race condition in inner::drop

Details:
inner::drop in inner.rs in the wgp crate through 0.2.0 for Rust lacks drop_slow thread synchronization.
GitHub Security Advisory: GHSA-4h96-mv53-2c86
Package: fast_id_map (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: <= 0.1.0
Patched in: unpatched

Summary: fast_id_map has a soundness issue and is unmaintained

Details:
`FastMap::get()` lacks sufficient checks to its parameter index and is used to unsafely get a `Vec` element.

`fast_id_map` is unmaintained.
GitHub Security Advisory: GHSA-79m9-55jc-p6mw
Package: scanner (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-125: Out-of-bounds Read
Vulnerable versions: <= 0.1.0
Patched in: unpatched

Summary: scanner has a Public API without sufficient bounds checking

Details:
`Match::get()` and `Match::ptr()` lack sufficient bounds checks, leading to potential out of bounds reads.
GitHub Security Advisory: GHSA-58xc-hpvq-8473
Package: redox_uefi_std (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-122: Heap-based Buffer Overflow
Vulnerable versions: >= 0.1.8, < 0.1.14
Patched in: 0.1.14

Summary: Redox UEFI Safe API can cause heap-buffer-overflow

Details:
ffi::nstr() should be marked unsafe, since a pointer to a buffer without a trailing 0 value will cause a heap buffer overflow.
GitHub Security Advisory: GHSA-m2xr-2vj4-wh94
Package: tanton_engine (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer
Vulnerable versions: <= 1.0.0
Patched in: unpatched

Summary: tanton_engine has unsound public API

Details:
The following functions in the `tanton_engine` crate are unsound due to lack of sufficient boundary
checks in public API:

- `Stack::offset()`
- `ThreadStack::get()`
- `RootMoveList::insert_score_depth()`
- `RootMoveList::insert_score()`

The tanton_engine crate is no longer maintained, so there are no plans to fix this issue.
GitHub Security Advisory: GHSA-jf2r-x3j4-23m7
Package: openvm (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-131: Incorrect Calculation of Buffer Size
Vulnerable versions: = 1.0.0
Patched in: 1.1.0

Summary: OpenVM allows the byte decomposition of pc in AUIPC chip to overflow

Details:
The fix to https://cantina.xyz/code/c486d600-bed0-4fc6-aed1-de759fd29fa2/findings/21 has a typo that still results in the highest limb of `pc` being range checked to 8-bits instead of 6-bits.

In the AIR, we do https://github.com/openvm-org/openvm/blob/0f94c8a3dfa7536c1231465d1bdee5fc607a5993/extensions/rv32im/circuit/src/auipc/core.rs#L135
```
        for (i, limb) in pc_limbs.iter().skip(1).enumerate() {
            if i == pc_limbs.len() - 1 {
```

It should be
```
        for (i, limb) in pc_limbs.iter().enumerate().skip(1) {
```

Right now the if statement is never triggered because the enumeration gives `i=0,1,2` when we instead want `i=1,2,3`. What this means is that `pc_limbs[3]` is range checked to 8-bits instead of 6-bits.

This leads to a vulnerability where the `pc_limbs` decomposition differs from the true `pc`, which means a malicious prover can make the destination register take a different value than the AUIPC instruction dictates, by making the decomposition overflow the BabyBear field.
GitHub Security Advisory: GHSA-v2p5-q653-9j99
Package: obfstr (RUST)
Severity: LOW (CVSS 2.9)
CWE: CWE-843: Access of Resource Using Incompatible Type ('Type Confusion')
Vulnerable versions: < 0.4.4
Patched in: 0.4.4

Summary: obfstr Type Confusion vulnerability

Details:
In the obfstr crate before 0.4.4 for Rust, the obfstr! argument type is not restricted to string slices, leading to invalid UTF-8 conversion that produces an invalid value.
GitHub Security Advisory: GHSA-927q-g9w9-pm54
Package: mp3-metadata (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer
Vulnerable versions: < 0.4.0
Patched in: 0.4.0

Summary: Panic in mp3-metadata due to the lack of bounds checking

Details:
The `get_id3()` methods used by `mp3_metadata::read_from_slice()` does not perform adequate bounds checking when recreating the tag due to the use of desynchronization.

Fixed in [Fix index error](https://github.com/GuillaumeGomez/mp3-metadata/pull/37), released as part of 0.4.0.
GitHub Security Advisory: GHSA-472w-7w45-g3w5
Package: pleezer (RUST)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-460: Improper Cleanup on Thrown Exception, CWE-772: Missing Release of Resource after Effective Lifetime
Vulnerable versions: < 0.16.0
Patched in: 0.16.0

Summary: Pleezer resource exhaustion through uncollected hook script processes

Details:
### Impact
Hook scripts in pleezer can be triggered by various events like track changes and playback state changes. In affected versions, these scripts were spawned without proper process cleanup, leaving zombie processes in the system's process table.

Even during normal usage, every track change and playback event would leave behind zombie processes. This leads to inevitable resource exhaustion over time as the system's process table fills up, eventually preventing new processes from being created. The issue is exacerbated if events occur rapidly, whether through normal use (e.g., skipping through a playlist) or potential manipulation of the Deezer Connect protocol traffic.

This vulnerability affects all users who have configured hook scripts using the `--hook` option.

### Patches
This issue has been fixed in version 0.16.0. Users should upgrade to this version, which properly manages child processes using asynchronous process handling and cleanup.

### Workarounds
Users who cannot upgrade immediately can:
- Disable hook scripts by removing the `--hook` option
- Ensure hook scripts handle their own child process cleanup
- Regularly restart pleezer to clear accumulated zombie processes

### References
- Initial report: https://github.com/roderickvd/pleezer/discussions/83#discussioncomment-12818199
- Fix commit: 436a5f1e4c08989b58dbba2b0ffa423458016c2d
- Fixed release: https://github.com/roderickvd/pleezer/releases/tag/v0.16.0
GitHub Security Advisory: GHSA-pxw4-94j3-v9pf
Package: surrealdb (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop')
Vulnerable versions: < 2.0.5
Patched in: 2.0.5

Summary: SurrealDB CPU exhaustion via custom functions result in total DoS

Details:
SurrealDB allows authenticated users with `OWNER` or `EDITOR` permissions at the root, database or namespace levels to define their own database functions using the `DEFINE FUNCTION` statement

A custom database function comprises a name together with a function body. In the function body, the user programs the functionality of the function in terms of SurrealQL. The language includes a `FOR` keyword, used to implement for-loops.

Whilst the parser and interpreter constrain the number of iterations for a single for-loop, nesting several for-loops with a large number of iterations is possible. Thus, an attacker could define a function that comprises several nested for-loops with an iteration count of 1.000.000 each. 

Executing the function will consume all the CPU time of the server, timeouts configured will not break the CPU consumption, and the function execution monopolizes all CPU time of the SurrealDB server, effectively preventing the server from executing functions, queries, commands of other users, or allowing further connections being established to the server.

Terminating the stuck server requires manual intervention which forces a quit on the server process, as the server application is not responsive any longer.

This issue was discovered and patched during an code audit and penetration test of SurrealDB by cure53, the severity defined within cure53's preliminary finding is high, matched by our CVSS v4 assessment.

### Impact
Denial of Service vulnerability resulting in a stuck SurrealDB server requiring manual restart.

### Patches
A patch has been introduced that adds a check in the `ForEachStatement` that checks if the context has been cancelled or timed out for every iteration.

- Versions 2.0.5, 2.1.5, 2.2.2, and later are not affected by this issue.

### Workarounds
For SurrealDB users that are unable to upgrade, consider setting the `--allow-functions` and/or `--deny-functions` options or corresponding `SURREAL_CAPS_ALLOW_FUNC` and/or `SURREAL_CAPS_DENY_FUNC` environment variables, documented within [capabilities](https://surrealdb.com/docs/surrealdb/security/capabilities#functions), to either block all custom functions, or only allow trusted functions to execute. 


### References
[SurrealQL Documentation - DEFINE FUNCTION Statement](https://surrealdb.com/docs/surrealql/statements/define/function)
[SurrealQL Documentation - FOR Statement](https://surrealdb.com/docs/surrealql/statements/for)
[SurrealDB Documentation - Capabilities](https://surrealdb.com/docs/surrealdb/security/capabilities#functions)
[SurrealDB Documentation - Environment variables](https://surrealdb.com/docs/surrealdb/cli/env#command-environment-variables)
[#5597](https://github.com/surrealdb/surrealdb/pull/5597)
GitHub Security Advisory: GHSA-pxw4-94j3-v9pf
Package: surrealdb (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop')
Vulnerable versions: >= 2.1.0, < 2.1.5
Patched in: 2.1.5

Summary: SurrealDB CPU exhaustion via custom functions result in total DoS

Details:
SurrealDB allows authenticated users with `OWNER` or `EDITOR` permissions at the root, database or namespace levels to define their own database functions using the `DEFINE FUNCTION` statement

A custom database function comprises a name together with a function body. In the function body, the user programs the functionality of the function in terms of SurrealQL. The language includes a `FOR` keyword, used to implement for-loops.

Whilst the parser and interpreter constrain the number of iterations for a single for-loop, nesting several for-loops with a large number of iterations is possible. Thus, an attacker could define a function that comprises several nested for-loops with an iteration count of 1.000.000 each. 

Executing the function will consume all the CPU time of the server, timeouts configured will not break the CPU consumption, and the function execution monopolizes all CPU time of the SurrealDB server, effectively preventing the server from executing functions, queries, commands of other users, or allowing further connections being established to the server.

Terminating the stuck server requires manual intervention which forces a quit on the server process, as the server application is not responsive any longer.

This issue was discovered and patched during an code audit and penetration test of SurrealDB by cure53, the severity defined within cure53's preliminary finding is high, matched by our CVSS v4 assessment.

### Impact
Denial of Service vulnerability resulting in a stuck SurrealDB server requiring manual restart.

### Patches
A patch has been introduced that adds a check in the `ForEachStatement` that checks if the context has been cancelled or timed out for every iteration.

- Versions 2.0.5, 2.1.5, 2.2.2, and later are not affected by this issue.

### Workarounds
For SurrealDB users that are unable to upgrade, consider setting the `--allow-functions` and/or `--deny-functions` options or corresponding `SURREAL_CAPS_ALLOW_FUNC` and/or `SURREAL_CAPS_DENY_FUNC` environment variables, documented within [capabilities](https://surrealdb.com/docs/surrealdb/security/capabilities#functions), to either block all custom functions, or only allow trusted functions to execute. 


### References
[SurrealQL Documentation - DEFINE FUNCTION Statement](https://surrealdb.com/docs/surrealql/statements/define/function)
[SurrealQL Documentation - FOR Statement](https://surrealdb.com/docs/surrealql/statements/for)
[SurrealDB Documentation - Capabilities](https://surrealdb.com/docs/surrealdb/security/capabilities#functions)
[SurrealDB Documentation - Environment variables](https://surrealdb.com/docs/surrealdb/cli/env#command-environment-variables)
[#5597](https://github.com/surrealdb/surrealdb/pull/5597)
GitHub Security Advisory: GHSA-pxw4-94j3-v9pf
Package: surrealdb (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop')
Vulnerable versions: >= 2.2.0, < 2.2.2
Patched in: 2.2.2

Summary: SurrealDB CPU exhaustion via custom functions result in total DoS

Details:
SurrealDB allows authenticated users with `OWNER` or `EDITOR` permissions at the root, database or namespace levels to define their own database functions using the `DEFINE FUNCTION` statement

A custom database function comprises a name together with a function body. In the function body, the user programs the functionality of the function in terms of SurrealQL. The language includes a `FOR` keyword, used to implement for-loops.

Whilst the parser and interpreter constrain the number of iterations for a single for-loop, nesting several for-loops with a large number of iterations is possible. Thus, an attacker could define a function that comprises several nested for-loops with an iteration count of 1.000.000 each. 

Executing the function will consume all the CPU time of the server, timeouts configured will not break the CPU consumption, and the function execution monopolizes all CPU time of the SurrealDB server, effectively preventing the server from executing functions, queries, commands of other users, or allowing further connections being established to the server.

Terminating the stuck server requires manual intervention which forces a quit on the server process, as the server application is not responsive any longer.

This issue was discovered and patched during an code audit and penetration test of SurrealDB by cure53, the severity defined within cure53's preliminary finding is high, matched by our CVSS v4 assessment.

### Impact
Denial of Service vulnerability resulting in a stuck SurrealDB server requiring manual restart.

### Patches
A patch has been introduced that adds a check in the `ForEachStatement` that checks if the context has been cancelled or timed out for every iteration.

- Versions 2.0.5, 2.1.5, 2.2.2, and later are not affected by this issue.

### Workarounds
For SurrealDB users that are unable to upgrade, consider setting the `--allow-functions` and/or `--deny-functions` options or corresponding `SURREAL_CAPS_ALLOW_FUNC` and/or `SURREAL_CAPS_DENY_FUNC` environment variables, documented within [capabilities](https://surrealdb.com/docs/surrealdb/security/capabilities#functions), to either block all custom functions, or only allow trusted functions to execute. 


### References
[SurrealQL Documentation - DEFINE FUNCTION Statement](https://surrealdb.com/docs/surrealql/statements/define/function)
[SurrealQL Documentation - FOR Statement](https://surrealdb.com/docs/surrealql/statements/for)
[SurrealDB Documentation - Capabilities](https://surrealdb.com/docs/surrealdb/security/capabilities#functions)
[SurrealDB Documentation - Environment variables](https://surrealdb.com/docs/surrealdb/cli/env#command-environment-variables)
[#5597](https://github.com/surrealdb/surrealdb/pull/5597)