deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-7vm2-j586-vcvc
Package: SurrealDB (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 2.3.0, < 2.3.8
Patched in: 2.3.8

Summary: SurrealDB is Vulnerable to Unauthorized Data Exposure via LIVE Query Subscriptions

Details:
`LIVE SELECT` statements are used to capture changes to data within a table in real time. Documents included in `WHERE` conditions and `DELETE` notifications were not properly reduced to respect the querying user's security context. Instead the leaked documents reflect the context of the user triggering the notification.

This allows a record or guest user with permissions to run live query subscriptions on a table to observe unauthorised records within the same table, when another user is altering or deleting these records, bypassing access controls.

### Impact
A record or guest user with permissions to run live query subscriptions on a table is able to observe unauthorised records within the same table, with unauthorised records returned when deleted, or when records matching the WHERE conditions are created, updated, or deleted, by another user. This impacts confidentiality, limited to the table the attacker has access to, and with the data disclosed dependent of the actions taken by other users.

### Patches
A patch has been created for the following versions:

- Versions 2.1.9, 2.2.8 and 2.3.8 and later are not affected by this issue. 
- The first release following v3.0.0-alpha.7 will be patched.

### Workarounds
Assess the impact of users with permissions on table records effectively having full read access to the table, use separate tables if required, with impacts to functionality.
GitHub Security Advisory: GHSA-qhj8-q5r6-8q6j
Package: matrix-sdk-base (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-682: Incorrect Calculation
Vulnerable versions: < 0.14.1
Patched in: 0.14.1

Summary: matrix-sdk-base: Panic in the `RoomMember::normalized_power_level()` method

Details:
In matrix-sdk-base before 0.14.1, calling the `RoomMember::normalized_power_level()` method can cause a panic if a room member has a power level of `Int::Min`.

### Patches
The issue is fixed in matrix-sdk-base 0.14.1.

### Workarounds
The affected method isn’t used internally, so avoiding calling `RoomMember::normalized_power_level()` prevents the panic.
GitHub Security Advisory: GHSA-pfp7-vxgr-83pw
Package: toodee (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-122: Heap-based Buffer Overflow
Vulnerable versions: >= 0.2.0, < 0.6.0
Patched in: 0.6.0

Summary: toodee is vulnerable to Heap Buffer Overflow through its DrainCol Destructor

Details:
An off-by-one error in the `DrainCol::drop` destructor could cause an unsafe memory copy operation to exceed the bounds of the associated vector.

The error was related to the size of the data being copied in one of the `ptr::copy` invocations inside the destructor.

When removing the first column from a TooDee object, the DrainCol return object could cause a heap buffer overflow vulnerability when it is dropped.

The issue was fixed in commit `e6e16d5` by reducing the copied size by one.
GitHub Security Advisory: GHSA-wgq8-vr6r-mqxm
Package: frost-core (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-269: Improper Privilege Management, CWE-325: Missing Cryptographic Step
Vulnerable versions: >= 2.0.0, < 2.2.0
Patched in: 2.2.0

Summary: frost-core: refresh shares with smaller min_signers will reduce security of group

Details:
### Impact

It was not clear that it is not possible to change `min_signers` (i.e. the threshold) with the refresh share functionality (`frost_core::keys::refresh` module). Using a smaller value would not decrease the threshold, and attempts to sign using a smaller threshold would fail. Additionally, after refreshing the shares with a smaller threshold, it would still be possible to sign with the original threshold; however, this could cause a security loss to the participant's shares. We have not determined the exact security implications of doing so and judged simpler to just validate `min_signers`. 

 If for some reason you have done a refresh share procedure with a smaller `min_signers` we strongly recommend migrating to a new key. 

### Patches

Updating to 2.2.0 will ensure that the `min_signers` parameter will be validated. However it won't restore the security of groups refreshed with a smaller `min_signers` parameters.

### Workarounds

You don't need to update if you don't use the refresh share functionality, or if you didn't try to change the `min_signers` parameter using the refresh share functionality.

### References

Thank you [BlockSec](https://blocksec.com/) for reporting the finding
GitHub Security Advisory: GHSA-xqjr-wfx3-gmxv
Package: array-queue (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-665: Improper Initialization
Vulnerable versions: >= 0.3.0, < 0.4.0
Patched in: 0.4.0

Summary: ArrayQueue's push_front is not panic-safe

Details:
The safe API `array_queue::ArrayQueue::push_front` can lead to deallocating uninitialized memory if a panic occurs while invoking the `clone` method on the passed argument.

Specifically, `push_front` receives an argument that is intended to be cloned and pushed, whose type implements the `Clone` trait. Furthermore, the method updates the queue's `start` index before initializing the slot for the newly pushed element. User-defined implementations of `Clone` may include a `clone` method that can panic. If such a panic occurs during initialization, the structure is left with an advanced `start` index pointing to an uninitialized slot. When `ArrayQueue` is later dropped, its destructor treats that slot as initialized and attempts to drop it, resulting in an attempt to free uninitialized memory.

The bug was fixed in commit `728fe1b`.
GitHub Security Advisory: GHSA-3632-54q8-m96x
Package: arenavec (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-122: Heap-based Buffer Overflow, CWE-415: Double Free, CWE-822: Untrusted Pointer Dereference
Vulnerable versions: <= 0.1.1
Patched in: unpatched

Summary: arenavec has multiple memory corruption vulnerabilities in safe APIs

Details:
The crate has the following vulnerabilities:

- The public trait `arenavec::common::AllocHandle` allows the return of raw pointers through its methods `allocate` and `allocate_or_extend`. However, the trait is not marked as unsafe, meaning users of the crate may implement it under the assumption that the library safely handles the returned raw pointers. These raw pointers can later be dereferenced within safe APIs of the crate-such as `arenavec::common::SliceVec::push`-potentially leading to arbitrary memory access.

- The safe API `arenavec::common::SliceVec::reserve` can reach the private function `arenavec::common::allocate_inner`. Incorrect behavior in `allocate_inner` may result in a `SliceVec` with an increased capacity, even though the underlying memory has not actually been expanded. This mismatch between `SliceVec.capacity` and the actual reserved memory can lead to a heap buffer overflow.

- The safe API `arenavec::common::SliceVec::split_off` can duplicate the ownership of the elements in `self` (of type `SliceVec`) if they implement the `Drop` trait. Specifically, when `at == 0`, the method returns a new `SliceVec` with the same length as `self`. Since both `self` and the returned object point to the same heap memory, dropping one will deallocate the shared memory. When the other is subsequently dropped, it will attempt to free the same memory again, resulting in a double free violation.
GitHub Security Advisory: GHSA-xwfj-jgwm-7wp5
Package: tracing-subscriber (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-150: Improper Neutralization of Escape, Meta, or Control Sequences
Vulnerable versions: < 0.3.20
Patched in: 0.3.20

Summary:  Tracing logging user input may result in poisoning logs with ANSI escape sequences

Details:
### Impact

Previous versions of tracing-subscriber were vulnerable to ANSI escape sequence injection attacks. Untrusted user input containing ANSI escape sequences could be injected into terminal output when logged, potentially allowing attackers to:

- Manipulate terminal title bars
- Clear screens or modify terminal display
- Potentially mislead users through terminal manipulation

In isolation, impact is minimal, however security issues have been found in terminal emulators that enabled an attacker to use ANSI escape sequences via logs to exploit vulnerabilities in the terminal emulator.

### Patches

`tracing-subscriber` version 0.3.20 fixes this vulnerability by escaping ANSI control characters in when writing events to destinations that may be printed to the terminal.

### Workarounds

Avoid printing logs to terminal emulators without escaping ANSI control sequences.

### References

https://www.packetlabs.net/posts/weaponizing-ansi-escape-sequences/


### Acknowledgments

We would like to thank [zefr0x](http://github.com/zefr0x) who responsibly reported the issue at `security@tokio.rs`.

If you believe you have found a security vulnerability in any tokio-rs project, please email us at `security@tokio.rs`.
GitHub Security Advisory: GHSA-9q78-27f3-2jmh
Package: webp (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-125: Out-of-bounds Read
Vulnerable versions: < 0.3.1
Patched in: 0.3.1

Summary: webp crate may expose memory contents when encoding an image

Details:
Affected versions of this crate did not check that the input slice passed to `"webp::Encoder::encode()` is large enough for the specified image dimensions.

If the input slice is too short, the library will read out of bounds of the buffer and encode other memory contents as an image, resulting in memory exposure or a segmentation fault.

The flaw was corrected in [pull request #44](https://github.com/jaredforth/webp/pull/44) by always validating the input buffer size when constructing the encoder.
GitHub Security Advisory: GHSA-4855-q42w-5vr4
Package: ntpd-rs (RUST)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-406: Insufficient Control of Network Message Volume (Network Amplification)
Vulnerable versions: >= 1.2.0, < 1.6.2
Patched in: 1.6.2

Summary: DoS Vulnerability in ntpd-rs

Details:
# Summary

A denial of service vulnerability was discovered in ntpd-rs where an attacker can induce a message storm between two NTP servers running ntpd-rs.

# Details

Since ntpd-rs version 1.2.0, when configured as a server, incorrectly responded to all NTP messages sent to the server's port with a time reply, including to responses from other servers. As a consequence, a message with a spoofed IP address of another server could cause two servers running ntpd-rs to continually respond to each other, consuming significant amounts of resources.

# Impact

Any time server running ntpd-rs with version between 1.2.0 and 1.6.1 inclusive which allows non-NTS traffic is affected. Client-only configurations are not affected. Affected users are recommended to upgrade to version 1.6.2 as soon as possible.

# Workarounds

Should upgrading not be possible, the impact of the issue can be mitigated by:
 - Whitelisting access to only IP addresses of clients using the server, using the ignore filter method.
 - Blocking incoming non-request traffic on the NTP server port using a firewall.
 - Disabling public access to the vulnerable NTP server
 - Disabling the server functionality by removing any [server] sections from the configuration.

# Acknowledgements

The ntpd-rs authors thank Eric Sesterhenn from X41 D-Sec GmbH for finding and reporting this issue.
GitHub Security Advisory: GHSA-655h-hg88-5qmf
Package: xcb (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-666: Operation on Resource in Wrong Phase of Lifetime, CWE-672: Operation on a Resource after Expiration or Release
Vulnerable versions: < 1.6.0
Patched in: 1.6.0

Summary: Rust XCB `xcb::Connection::connect_to_fd*` functions violate I/O safety

Details:
The API of `xcb::Connection` has constructors which allow an arbitrary `RawFd` to be used as a socket connection. On either failure of these constructors or on the drop of `Connection`, it closes the associated file descriptor. Thus, a program which uses an `OwnedFd` (such as a `UnixStream`) as the file descriptor can close the file descriptor and continue to attempt using it or close an already-closed file descriptor, violating I/O safety.

Starting in version 1.6.0, `xcb` provides `Connection::connect_with_fd` and `Connection::connect_with_fd_and_extensions` as safe alternatives and deprecates the problematic functions.
GitHub Security Advisory: GHSA-qq4c-hm99-979m
Package: id-map (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-665: Improper Initialization
Vulnerable versions: >= 0.1.6, < 0.2.2
Patched in: 0.2.2

Summary: IdMap from_iter may lead to uninitialized memory being freed on drop

Details:
Due to a flaw in the constructor `id_map::IdMap::from_iter`, ill-formed objects may be created in which the amount of actually initialized memory is less than what is expected by the fields of `IdMap`. Specifically, the field `ids` is initialized based on the capacity of the vector `values`, which is constructed from the provided iterator. However, the length of this vector may be smaller than its capacity.

In such cases, when the resulting `IdMap` is dropped, its destructor incorrectly assumes that `values` contains `ids.len() == values.capacity()` initialized elements and attempts to iterate over and drop them. This leads to dereferencing and attempting to free uninitialized memory, resulting in undefined behavior and potential segmentation faults.

The bug was fixed in commit `fab6922`, and all unsafe code was removed from the crate.

Note that the maintainer recommends using the following alternatives:
- [slab](https://crates.io/crates/slab)
- [slotmap](https://crates.io/crates/slotmap)
GitHub Security Advisory: GHSA-77h3-w9rx-hj3q
Package: scratchpad (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-122: Heap-based Buffer Overflow
Vulnerable versions: <= 1.3.1
Patched in: unpatched

Summary: User-defined implementations of the safe trait scratchpad::Tracking can cause heap buffer overflows

Details:
The `get` and `set` methods of the public trait `scratchpad::Tracking` interact with unsafe code regions in the crate, and they influence the computation of addresses returned as raw pointers. However, the trait itself is not marked as unsafe, meaning users may provide custom implementations under the assumption that the crate upholds all safety guarantees.

This becomes problematic because even safe implementations of `get` and `set`-written without using any unsafe code-can still result in ill-formed raw pointers. These pointers may later be dereferenced within safe APIs of the crate (e.g., `marker::MarkerBack::allocate_slice_copy`), potentially leading to arbitrary memory access or heap buffer overflows.

According to the [penultimate commit](https://github.com/okready/scratchpad/commit/957dee1a3902f48600b06910e8e0b1d5ee7dab83), the crate is in maintenance mode awaiting a cleanup that will reduce the area of unsafe code. Note that the last commits to the repository are from 4 years ago.
GitHub Security Advisory: GHSA-j26p-6wx7-f3pw
Package: youki (RUST)
Severity: HIGH (CVSS 7.0)
CWE: CWE-61: UNIX Symbolic Link (Symlink) Following
Vulnerable versions: < 0.5.5
Patched in: 0.5.5

Summary: Youki: If /proc and /sys in the rootfs are symbolic links, they can potentially be exploited to gain access to the host root filesystem.

Details:
### Summary
If `/proc` and `/sys` in the rootfs are symbolic links, they can potentially be exploited to gain access to the host root filesystem.

### Details

For security reasons, container creation should be prohibited if `/proc` or `/sys` in the rootfs is a symbolic link.
I verified this behavior with `youki`.
When `/proc` or `/sys` is a symbolic link, `runc` fails to create the container, whereas `youki` successfully creates it.

This is the fix related to this issue in `runc`.
* https://github.com/opencontainers/runc/pull/3756
* https://github.com/opencontainers/runc/pull/3773
* https://github.com/opencontainers/runc/blob/main/libcontainer/rootfs_linux.go#L590
* https://github.com/opencontainers/runc/blob/main/tests/integration/mask.bats#L60


### Impact

The following advisory appears to be related to this vulnerability:
* https://github.com/advisories/GHSA-vpvm-3wq2-2wvm
* https://github.com/advisories/GHSA-fh74-hm69-rqjw
GitHub Security Advisory: GHSA-qx2v-8332-m4fv
Package: slab (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer
Vulnerable versions: = 0.4.10
Patched in: 0.4.11

Summary: slab allows out-of-bounds access in `get_disjoint_mut` due to incorrect bounds check

Details:
### Impact

The `get_disjoint_mut` method in slab v0.4.10 incorrectly checked if indices were within the slab's capacity instead of its length, allowing access to uninitialized memory. This could lead to undefined behavior or potential crashes.

### Patches

This has been fixed in slab v0.4.11.

### Workarounds

Avoid using `get_disjoint_mut` with indices that might be beyond the slab's actual length, or upgrade to v0.4.11 or later.

### References

- [https://github.com/tokio-rs/slab/pull/152](https://github.com/tokio-rs/slab/pull/152)
GitHub Security Advisory: GHSA-m3hh-f9gh-74c2
Package: quiche (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop')
Vulnerable versions: >= 0.15.0, < 0.24.5
Patched in: 0.24.5

Summary: quiche connection ID retirement can trigger an infinite loop

Details:
## Impact

Cloudflare quiche was discovered to be vulnerable to an infinite loop when sending packets containing RETIRE_CONNECTION_ID frames.

QUIC connections possess a set of connection identifiers (IDs); see [Section 5.1 of RFC 9000](https://datatracker.ietf.org/doc/html/rfc9000#section-5.1). Once the QUIC handshake completes, a local endpoint is responsible for issuing and retiring Connection IDs that are used by the remote peer to populate the Destination Connection ID field in packets sent from remote to local. Each Connection ID has a sequence number to ensure synchronization between peers

An unauthenticated remote attacker can exploit this vulnerability by first completing a handshake and then sending a specially-crafted set of frames that trigger a connection ID retirement in the victim. When the victim attempts to send a packet containing RETIRE_CONNECTION_ID frames, [Section 19.16 of RFC 9000](https://datatracker.ietf.org/doc/html/rfc9000#section-19.16) requires that the sequence number of the retired connection ID must not be the same as the sequence number of the connection ID used by the packet. In other words, a packet cannot contain a frame that retires itself.  In scenarios such as path migration, it is possible for there to be multiple active paths with different active connection IDs that could be used to retire each other. The exploit triggered an unintentional behaviour of a quiche design feature that supports retirement across paths while maintaining full connection ID  synchronization, leading to an infinite loop.

## Patches

quiche 0.24.5 is the earliest version containing the fix for the issue
GitHub Security Advisory: GHSA-f6rc-24x4-ppxp
Package: risc0-circuit-rv32im-sys (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-369: Divide By Zero
Vulnerable versions: >= 2.0.0, < 3.0.0
Patched in: 3.0.0

Summary: RISC Zero Underconstrained Vulnerability: Division

Details:
Two issues were found: For some inputs to signed integer division, the circuit allowed two outputs, only one of which was valid.  Additionally, the result of division by zero was underconstrained.

This vulnerability was identified using the Picus tool from Veridise. 

Impacted on-chain verifiers have already been disabled via the estop mechanism outlined in the [Verifier Management Design](https://github.com/risc0/risc0-ethereum/blob/release-2.0/contracts/version-management-design.md#base-verifier-implementations). 

## Mitigation

We recommend all impacted users upgrade as soon as possible.

Rust applications using the `risc0-zkvm` crate at versions < 2.2 should upgrade to version 2.2.0 or later. 

Smart contract applications using the official [RISC Zero Verifier Router](https://dev.risczero.com/api/blockchain-integration/contracts/verifier#verifier-router) do not need to take any action: zkVM version 2.2 is active on all official routers, and version 2.1 has been disabled.

Smart contract applications not using the verifier router should update their contracts to send verification calls to the 2.2 version of the verifier.
GitHub Security Advisory: GHSA-f6rc-24x4-ppxp
Package: risc0-circuit-rv32im (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-369: Divide By Zero
Vulnerable versions: >= 2.0.0, < 3.0.0
Patched in: 3.0.0

Summary: RISC Zero Underconstrained Vulnerability: Division

Details:
Two issues were found: For some inputs to signed integer division, the circuit allowed two outputs, only one of which was valid.  Additionally, the result of division by zero was underconstrained.

This vulnerability was identified using the Picus tool from Veridise. 

Impacted on-chain verifiers have already been disabled via the estop mechanism outlined in the [Verifier Management Design](https://github.com/risc0/risc0-ethereum/blob/release-2.0/contracts/version-management-design.md#base-verifier-implementations). 

## Mitigation

We recommend all impacted users upgrade as soon as possible.

Rust applications using the `risc0-zkvm` crate at versions < 2.2 should upgrade to version 2.2.0 or later. 

Smart contract applications using the official [RISC Zero Verifier Router](https://dev.risczero.com/api/blockchain-integration/contracts/verifier#verifier-router) do not need to take any action: zkVM version 2.2 is active on all official routers, and version 2.1 has been disabled.

Smart contract applications not using the verifier router should update their contracts to send verification calls to the 2.2 version of the verifier.
GitHub Security Advisory: GHSA-f6rc-24x4-ppxp
Package: risc0-zkvm (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-369: Divide By Zero
Vulnerable versions: >= 2.0.0, < 2.2.0
Patched in: 2.2.0

Summary: RISC Zero Underconstrained Vulnerability: Division

Details:
Two issues were found: For some inputs to signed integer division, the circuit allowed two outputs, only one of which was valid.  Additionally, the result of division by zero was underconstrained.

This vulnerability was identified using the Picus tool from Veridise. 

Impacted on-chain verifiers have already been disabled via the estop mechanism outlined in the [Verifier Management Design](https://github.com/risc0/risc0-ethereum/blob/release-2.0/contracts/version-management-design.md#base-verifier-implementations). 

## Mitigation

We recommend all impacted users upgrade as soon as possible.

Rust applications using the `risc0-zkvm` crate at versions < 2.2 should upgrade to version 2.2.0 or later. 

Smart contract applications using the official [RISC Zero Verifier Router](https://dev.risczero.com/api/blockchain-integration/contracts/verifier#verifier-router) do not need to take any action: zkVM version 2.2 is active on all official routers, and version 2.1 has been disabled.

Smart contract applications not using the verifier router should update their contracts to send verification calls to the 2.2 version of the verifier.