CVE-2024-43806

Summary

When using rustix::fs::Dir using the linux_raw backend, it's possible for the iterator to "get stuck" when an IO error is encountered. Combined with a memory over-allocation issue in rustix::fs::Dir::read_more, this can cause quick and unbounded memory explosion (gigabytes in a few seconds if used on a hot path) and eventually lead to an OOM crash of the application.

Details

Discovery

The symptoms were initially discovered in https://github.com/imsnif/bandwhich/issues/284. That post has lots of details of our investigation. See this post and the Discord thread for details.

Diagnosis

This issue is caused by the combination of two independent bugs:

1. Stuck iterator

• The rustix::fs::Dir iterator can fail to halt after encountering an IO error, causing the caller to be stuck in an infinite loop.

2. Memory over-allocation

• Dir::read_more incorrectly grows the read buffer unconditionally each time it is called, regardless of necessity.

Since <Dir as Iterator>::next calls Dir::read, which in turn calls Dir::read_more, this means an IO error encountered during reading a directory can lead to rapid and unbounded growth of memory use.

PoC

fn main() -> Result<(), Box<dyn std::error::Error>> {
    // create a directory, get a FD to it, then unlink the directory but keep the FD
    std::fs::create_dir("tmp_dir")?;
    let dir_fd = rustix::fs::openat(
        rustix::fs::CWD,
        rustix::cstr!("tmp_dir"),
        rustix::fs::OFlags::RDONLY | rustix::fs::OFlags::CLOEXEC,
        rustix::fs::Mode::empty(),
    )?;
    std::fs::remove_dir("tmp_dir")?;

    // iterator gets stuck in infinite loop and memory explodes
    rustix::fs::Dir::read_from(dir_fd)?
        // the iterator keeps returning `Some(Err(_))`, but never halts by returning `None`
        // therefore if the implementation ignores the error (or otherwise continues
        // after seeing the error instead of breaking), the loop will not halt
        .filter_map(|dirent_maybe_error| dirent_maybe_error.ok())
        .for_each(|dirent| {
            // your happy path
            println!("{dirent:?}");
        });

    Ok(())
}

Impact

If a program tries to access a directory with its file descriptor after the file has been unlinked (or any other action that leaves the Dir iterator in the stuck state), and the implementation does not break after seeing an error, it can cause a memory explosion.

As an example, Linux's various virtual file systems (e.g. /proc, /sys) can contain directories that spontaneously pop in and out of existence. Attempting to iterate over them using rustix::fs::Dir directly or indirectly (e.g. with the procfs crate) can trigger this fault condition if the implementation decides to continue on errors.

An attacker knowledgeable about the implementation details of a vulnerable target can therefore try to trigger this fault condition via any one or a combination of several available APIs. If successful, the application host will quickly run out of memory, after which the application will likely be terminated by an OOM killer, leading to denial of service.

Rustix is a set of safe Rust bindings to POSIX-ish APIs. When using rustix::fs::Dir using the linux_raw backend, it's possible for the iterator to "get stuck" when an IO error is encountered. Combined with a memory over-allocation issue in rustix::fs::Dir::read_more, this can cause quick and unbounded memory explosion (gigabytes in a few seconds if used on a hot path) and eventually lead to an OOM crash of the application. The symptoms were initially discovered in https://github.com/imsnif/bandwhich/issues/284. That post has lots of details of our investigation. Full details can be read on the GHSA-c827-hfw6-qwvm repo advisory. If a program tries to access a directory with its file descriptor after the file has been unlinked (or any other action that leaves the Dir iterator in the stuck state), and the implementation does not break after seeing an error, it can cause a memory explosion. As an example, Linux's various virtual file systems (e.g. /proc, /sys) can contain directories that spontaneously pop in and out of existence. Attempting to iterate over them using rustix::fs::Dir directly or indirectly (e.g. with the procfs crate) can trigger this fault condition if the implementation decides to continue on errors. An attacker knowledgeable about the implementation details of a vulnerable target can therefore try to trigger this fault condition via any one or a combination of several available APIs. If successful, the application host will quickly run out of memory, after which the application will likely be terminated by an OOM killer, leading to denial of service. This issue has been addressed in release versions 0.35.15, 0.36.16, 0.37.25, and 0.38.19. Users are advised to upgrade. There are no known workarounds for this issue.

Rustix is a set of safe Rust bindings to POSIX-ish APIs. When using rustix::fs::Dir using the linux_raw backend, it's possible for the iterator to "get stuck" when an IO error is encountered. Combined with a memory over-allocation issue in rustix::fs::Dir::read_more, this can cause quick and unbounded memory explosion (gigabytes in a few seconds if used on a hot path) and eventually lead to an OOM crash of the application. The symptoms were initially discovered in https://github.com/imsnif/bandwhich/issues/284. That post has lots of details of our investigation. Full details can be read on the GHSA-c827-hfw6-qwvm repo advisory. If a program tries to access a directory with its file descriptor after the file has been unlinked (or any other action that leaves the Dir iterator in the stuck state), and the implementation does not break after seeing an error, it can cause a memory explosion. As an example, Linux's various virtual file systems (e.g. /proc, /sys) can contain directories that spontaneously pop in and out of existence. Attempting to iterate over them using rustix::fs::Dir directly or indirectly (e.g. with the procfs crate) can trigger this fault condition if the implementation decides to continue on errors. An attacker knowledgeable about the implementation details of a vulnerable target can therefore try to trigger this fault condition via any one or a combination of several available APIs. If successful, the application host will quickly run out of memory, after which the application will likely be terminated by an OOM killer, leading to denial of service. This issue has been addressed in release versions 0.35.15, 0.36.16, 0.37.25, and 0.38.19. Users are advised to upgrade. There are no known workarounds for this issue.

Rustix is a set of safe Rust bindings to POSIX-ish APIs. When using rustix::fs::Dir using the linux_raw backend, it's possible for the iterator to "get stuck" when an IO error is encountered. Combined with a memory over-allocation issue in rustix::fs::Dir::read_more, this can cause quick and unbounded memory explosion (gigabytes in a few seconds if used on a hot path) and eventually lead to an OOM crash of the application. The symptoms were initially discovered in https://github.com/imsnif/bandwhich/issues/284. That post has lots of details of our investigation. Full details can be read on the GHSA-c827-hfw6-qwvm repo advisory. If a program tries to access a directory with its file descriptor after the file has been unlinked (or any other action that leaves the Dir iterator in the stuck state), and the implementation does not break after seeing an error, it can cause a memory explosion. As an example, Linux's various virtual file systems (e.g. /proc, /sys) can contain directories that spontaneously pop in and out of existence. Attempting to iterate over them using rustix::fs::Dir directly or indirectly (e.g. with the procfs crate) can trigger this fault condition if the implementation decides to continue on errors. An attacker knowledgeable about the implementation details of a vulnerable target can therefore try to trigger this fault condition via any one or a combination of several available APIs. If successful, the application host will quickly run out of memory, after which the application will likely be terminated by an OOM killer, leading to denial of service. This issue has been addressed in release versions 0.35.15, 0.36.16, 0.37.25, and 0.38.19. Users are advised to upgrade. There are no known workarounds for this issue.

Rustix is a set of safe Rust bindings to POSIX-ish APIs. When using rustix::fs::Dir using the linux_raw backend, it's possible for the iterator to "get stuck" when an IO error is encountered. Combined with a memory over-allocation issue in rustix::fs::Dir::read_more, this can cause quick and unbounded memory explosion (gigabytes in a few seconds if used on a hot path) and eventually lead to an OOM crash of the application. The symptoms were initially discovered in https://github.com/imsnif/bandwhich/issues/284. That post has lots of details of our investigation. Full details can be read on the GHSA-c827-hfw6-qwvm repo advisory. If a program tries to access a directory with its file descriptor after the file has been unlinked (or any other action that leaves the Dir iterator in the stuck state), and the implementation does not break after seeing an error, it can cause a memory explosion. As an example, Linux's various virtual file systems (e.g. /proc, /sys) can contain directories that spontaneously pop in and out of existence. Attempting to iterate over them using rustix::fs::Dir directly or indirectly (e.g. with the procfs crate) can trigger this fault condition if the implementation decides to continue on errors. An attacker knowledgeable about the implementation details of a vulnerable target can therefore try to trigger this fault condition via any one or a combination of several available APIs. If successful, the application host will quickly run out of memory, after which the application will likely be terminated by an OOM killer, leading to denial of service. This issue has been addressed in release versions 0.35.15, 0.36.16, 0.37.25, and 0.38.19. Users are advised to upgrade. There are no known workarounds for this issue.

Rustix is a set of safe Rust bindings to POSIX-ish APIs. When using rustix::fs::Dir using the linux_raw backend, it's possible for the iterator to "get stuck" when an IO error is encountered. Combined with a memory over-allocation issue in rustix::fs::Dir::read_more, this can cause quick and unbounded memory explosion (gigabytes in a few seconds if used on a hot path) and eventually lead to an OOM crash of the application. The symptoms were initially discovered in https://github.com/imsnif/bandwhich/issues/284. That post has lots of details of our investigation. Full details can be read on the GHSA-c827-hfw6-qwvm repo advisory. If a program tries to access a directory with its file descriptor after the file has been unlinked (or any other action that leaves the Dir iterator in the stuck state), and the implementation does not break after seeing an error, it can cause a memory explosion. As an example, Linux's various virtual file systems (e.g. /proc, /sys) can contain directories that spontaneously pop in and out of existence. Attempting to iterate over them using rustix::fs::Dir directly or indirectly (e.g. with the procfs crate) can trigger this fault condition if the implementation decides to continue on errors. An attacker knowledgeable about the implementation details of a vulnerable target can therefore try to trigger this fault condition via any one or a combination of several available APIs. If successful, the application host will quickly run out of memory, after which the application will likely be terminated by an OOM killer, leading to denial of service. This issue has been addressed in release versions 0.35.15, 0.36.16, 0.37.25, and 0.38.19. Users are advised to upgrade. There are no known workarounds for this issue.

Rustix is a set of safe Rust bindings to POSIX-ish APIs. When using rustix::fs::Dir using the linux_raw backend, it's possible for the iterator to "get stuck" when an IO error is encountered. Combined with a memory over-allocation issue in rustix::fs::Dir::read_more, this can cause quick and unbounded memory explosion (gigabytes in a few seconds if used on a hot path) and eventually lead to an OOM crash of the application. The symptoms were initially discovered in https://github.com/imsnif/bandwhich/issues/284. That post has lots of details of our investigation. Full details can be read on the GHSA-c827-hfw6-qwvm repo advisory. If a program tries to access a directory with its file descriptor after the file has been unlinked (or any other action that leaves the Dir iterator in the stuck state), and the implementation does not break after seeing an error, it can cause a memory explosion. As an example, Linux's various virtual file systems (e.g. /proc, /sys) can contain directories that spontaneously pop in and out of existence. Attempting to iterate over them using rustix::fs::Dir directly or indirectly (e.g. with the procfs crate) can trigger this fault condition if the implementation decides to continue on errors. An attacker knowledgeable about the implementation details of a vulnerable target can therefore try to trigger this fault condition via any one or a combination of several available APIs. If successful, the application host will quickly run out of memory, after which the application will likely be terminated by an OOM killer, leading to denial of service. This issue has been addressed in release versions 0.35.15, 0.36.16, 0.37.25, and 0.38.19. Users are advised to upgrade. There are no known workarounds for this issue.

Rustix is a set of safe Rust bindings to POSIX-ish APIs. When using rustix::fs::Dir using the linux_raw backend, it's possible for the iterator to "get stuck" when an IO error is encountered. Combined with a memory over-allocation issue in rustix::fs::Dir::read_more, this can cause quick and unbounded memory explosion (gigabytes in a few seconds if used on a hot path) and eventually lead to an OOM crash of the application. The symptoms were initially discovered in https://github.com/imsnif/bandwhich/issues/284. That post has lots of details of our investigation. Full details can be read on the GHSA-c827-hfw6-qwvm repo advisory. If a program tries to access a directory with its file descriptor after the file has been unlinked (or any other action that leaves the Dir iterator in the stuck state), and the implementation does not break after seeing an error, it can cause a memory explosion. As an example, Linux's various virtual file systems (e.g. /proc, /sys) can contain directories that spontaneously pop in and out of existence. Attempting to iterate over them using rustix::fs::Dir directly or indirectly (e.g. with the procfs crate) can trigger this fault condition if the implementation decides to continue on errors. An attacker knowledgeable about the implementation details of a vulnerable target can therefore try to trigger this fault condition via any one or a combination of several available APIs. If successful, the application host will quickly run out of memory, after which the application will likely be terminated by an OOM killer, leading to denial of service. This issue has been addressed in release versions 0.35.15, 0.36.16, 0.37.25, and 0.38.19. Users are advised to upgrade. There are no known workarounds for this issue.

Rustix is a set of safe Rust bindings to POSIX-ish APIs. When using rustix::fs::Dir using the linux_raw backend, it's possible for the iterator to "get stuck" when an IO error is encountered. Combined with a memory over-allocation issue in rustix::fs::Dir::read_more, this can cause quick and unbounded memory explosion (gigabytes in a few seconds if used on a hot path) and eventually lead to an OOM crash of the application. The symptoms were initially discovered in https://github.com/imsnif/bandwhich/issues/284. That post has lots of details of our investigation. Full details can be read on the GHSA-c827-hfw6-qwvm repo advisory. If a program tries to access a directory with its file descriptor after the file has been unlinked (or any other action that leaves the Dir iterator in the stuck state), and the implementation does not break after seeing an error, it can cause a memory explosion. As an example, Linux's various virtual file systems (e.g. /proc, /sys) can contain directories that spontaneously pop in and out of existence. Attempting to iterate over them using rustix::fs::Dir directly or indirectly (e.g. with the procfs crate) can trigger this fault condition if the implementation decides to continue on errors. An attacker knowledgeable about the implementation details of a vulnerable target can therefore try to trigger this fault condition via any one or a combination of several available APIs. If successful, the application host will quickly run out of memory, after which the application will likely be terminated by an OOM killer, leading to denial of service. This issue has been addressed in release versions 0.35.15, 0.36.16, 0.37.25, and 0.38.19. Users are advised to upgrade. There are no known workarounds for this issue.

Rustix is a set of safe Rust bindings to POSIX-ish APIs. When using rustix::fs::Dir using the linux_raw backend, it's possible for the iterator to "get stuck" when an IO error is encountered. Combined with a memory over-allocation issue in rustix::fs::Dir::read_more, this can cause quick and unbounded memory explosion (gigabytes in a few seconds if used on a hot path) and eventually lead to an OOM crash of the application. The symptoms were initially discovered in https://github.com/imsnif/bandwhich/issues/284. That post has lots of details of our investigation. Full details can be read on the GHSA-c827-hfw6-qwvm repo advisory. If a program tries to access a directory with its file descriptor after the file has been unlinked (or any other action that leaves the Dir iterator in the stuck state), and the implementation does not break after seeing an error, it can cause a memory explosion. As an example, Linux's various virtual file systems (e.g. /proc, /sys) can contain directories that spontaneously pop in and out of existence. Attempting to iterate over them using rustix::fs::Dir directly or indirectly (e.g. with the procfs crate) can trigger this fault condition if the implementation decides to continue on errors. An attacker knowledgeable about the implementation details of a vulnerable target can therefore try to trigger this fault condition via any one or a combination of several available APIs. If successful, the application host will quickly run out of memory, after which the application will likely be terminated by an OOM killer, leading to denial of service. This issue has been addressed in release versions 0.35.15, 0.36.16, 0.37.25, and 0.38.19. Users are advised to upgrade. There are no known workarounds for this issue.

These are all security issues fixed in the 389-ds-3.1.1~git13.a9c7ff9-1.1 package on the GA media of openSUSE Tumbleweed.

These are all security issues fixed in the rage-encryption-0.10.0+0-3.1 package on the GA media of openSUSE Tumbleweed.

These are all security issues fixed in the keylime-ima-policy-0.2.7+70-2.1 package on the GA media of openSUSE Tumbleweed.

This update for librsvg fixes the following issues:

Update to version 2.60.2:

• CVE-2024-12224: Fixed idna accepts Punycode labels that do not produce any non-ASCII when decoded (bsc#1243867).
• CVE-2024-43806: Fixed memory explosion in rustix (bsc#1229950).

This update for rage-encryption fixes the following issues:

• Update to version 0.10.0
• CVE-2024-43806: Fixed rustix::fs::Dir iterator with the linux_raw backend that can cause memory exhaustion. (bsc#1229959)

This update for rust-keylime fixes the following issues:

• Update to version 0.2.7+141:

  • CVE-2025-58266: shlex: Fixed command injection (bsc#1247193)

• Update to version 0.2.7+117:

  • CVE-2023-26964: rust-keylime: hyper,h2: stream stacking when H2 processing HTTP2 RST_STREAM frames (bsc#1210344).
  • CVE-2024-12224: rust-keylime: idna: idna accepts Punycode labels that do not produce any non-ASCII when decoded (bsc#1243861).
  • CVE-2024-32650: rust-keylime: rust-rustls: Infinite loop in rustls::conn::ConnectionCommon:complete_io() with proper client input (bsc#1223234).
  • CVE-2024-43806: rust-keylime: rustix: rustix::fs::Dir iterator with the linux_raw backend can cause memory explosion (bsc#1229952).
  • CVE-2025-3416: rust-keylime: openssl: Use-After-Free in Md::fetch and Cipher::fetch in rust-openssl crate (bsc#1242623).
  • rust-shlex: Multiple issues involving quote API ( RUSTSEC-2024-0006, GHSA-r7qv-8r2h-pg27, bsc#1230029)

This update for rust-keylime fixes the following issues:

• Update to version 0.2.7+141:

  • CVE-2025-58266: shlex: Fixed command injection (bsc#1247193)

• Update to version 0.2.7+117:

  • CVE-2023-26964: rust-keylime: hyper,h2: stream stacking when H2 processing HTTP2 RST_STREAM frames (bsc#1210344).
  • CVE-2024-12224: rust-keylime: idna: idna accepts Punycode labels that do not produce any non-ASCII when decoded (bsc#1243861).
  • CVE-2024-32650: rust-keylime: rust-rustls: Infinite loop in rustls::conn::ConnectionCommon:complete_io() with proper client input (bsc#1223234).
  • CVE-2024-43806: rust-keylime: rustix: rustix::fs::Dir iterator with the linux_raw backend can cause memory explosion (bsc#1229952).
  • CVE-2025-3416: rust-keylime: openssl: Use-After-Free in Md::fetch and Cipher::fetch in rust-openssl crate (bsc#1242623).
  • rust-shlex: Multiple issues involving quote API ( RUSTSEC-2024-0006, GHSA-r7qv-8r2h-pg27, bsc#1230029)

This update for rust-keylime fixes the following issues:

• Update to version 0.2.7+141:

  • CVE-2025-58266: shlex: Fixed command injection (bsc#1247193)

• Update to version 0.2.7+117:

  • CVE-2023-26964: rust-keylime: hyper,h2: stream stacking when H2 processing HTTP2 RST_STREAM frames (bsc#1210344).
  • CVE-2024-12224: rust-keylime: idna: idna accepts Punycode labels that do not produce any non-ASCII when decoded (bsc#1243861).
  • CVE-2024-32650: rust-keylime: rust-rustls: Infinite loop in rustls::conn::ConnectionCommon:complete_io() with proper client input (bsc#1223234).
  • CVE-2024-43806: rust-keylime: rustix: rustix::fs::Dir iterator with the linux_raw backend can cause memory explosion (bsc#1229952).
  • CVE-2025-3416: rust-keylime: openssl: Use-After-Free in Md::fetch and Cipher::fetch in rust-openssl crate (bsc#1242623).
  • rust-shlex: Multiple issues involving quote API ( RUSTSEC-2024-0006, GHSA-r7qv-8r2h-pg27, bsc#1230029)

This update for rust-keylime fixes the following issues:

• Update vendored crates (CVE-2024-43806, bsc#1229952, bsc#1230029)

  • rustix 0.37.25
  • rustix 0.38.34
  • shlex 1.3.0

• Update to version 0.2.6+13:

  • Enable test functional/iak-idevid-persisted-and-protected
  • build(deps): bump uuid from 1.7.0 to 1.10.0
  • build(deps): bump openssl from 0.10.64 to 0.10.66
  • keylime-agent/src/revocation: Fix comment indentation
  • keylime/crypto: Fix indentation of documentation comment
  • build(deps): bump thiserror from 1.0.59 to 1.0.63
  • build(deps): bump serde_json from 1.0.116 to 1.0.120
  • dependabot: Extend to also monitor workflow actions
  • ci: Disable Packit CI on CentOS Stream 9
  • ci: use CODECOV_TOKEN when submitting coverage data
  • revocation: Use into() for unfallible transformation
  • secure_mount: Fix possible infinite loop
  • error: Rename enum variants to avoid clippy warning

• Update to version 0.2.6~0:

  • Bump version to 0.2.6
  • build(deps): bump libc from 0.2.153 to 0.2.155
  • build(deps): bump serde from 1.0.196 to 1.0.203
  • rpm/fedora: Update rust macro usage
  • config: Support hostnames in registrar_ip option
  • added use of persisted IAK and IDevID and authorisation values
  • config changes
  • Adding /agent/info API to agent
  • Fix leftover 'unnecessary qualification' warnings on tests

• Update to version 0.2.5~4:

  • Fix 'unnecessary qualification' warnings
  • fix IAK template to match IDevID
  • rpm: fix COPR RPMs build for centos-stream-10
  • Build COPR RPMs for centos-stream-10

• Update to version 0.2.5~0:

  • Bump version to 0.2.5
  • cargo: Relax required version for pest crate
  • build(deps): bump log from 0.4.20 to 0.4.21
  • build(deps): bump thiserror from 1.0.56 to 1.0.59

• actix-web update moves rustls as feature (bsc#1223234, CVE-2024-32650)

• Update to version 0.2.4~39:

  • build(deps): bump openssl from 0.10.63 to 0.10.64
  • build(deps): bump h2 from 0.3.24 to 0.3.26
  • build(deps): bump serde_json from 1.0.107 to 1.0.116
  • build(deps): bump actix-web from 4.4.1 to 4.5.1
  • crypto: Enable TLS 1.3
  • build(deps): bump tempfile from 3.9.0 to 3.10.1
  • build(deps): bump mio from 0.8.4 to 0.8.11
  • enable hex values to be used for tpm_ownerpassword
  • config: Support IPv6 with or without brackets
  • keylime: Implement a simple IP parser to remove brackets
  • crypto: Implement CertificateBuilder to generate certificates
  • tests: Fix coverage download by supporting arbitrary URL
  • cargo: Add testing feature to keylime library
  • Set X509 SAN with local DNSname/IP/IPv6
  • Include newest Node20 versions for Github actions
  • tpm: Add unit test for uncovered public functions
  • crypto: Implement ECC key generation support
  • crypto: Add test for match_cert_to_template()
  • Fix minor typo, format and remove end whitespaces
  • crypto: Make error types less specific
  • tests/run.sh: Run tarpaulin with a single thread
  • payloads: Remove explicit drop of channel transmitter
  • crypto: Move to keylime library
  • crypto: Add specific type for every possible error
  • tpm: Rename origin of error as source in structures
  • list_parser: Add source for error for backtrace
  • algorithms: Make errors more specific
  • typo fix for default path to measured boot log file
  • README: remove mentions of libarchive as a dependency
  • Dockerfile.wolfi: Update clang to version 17
  • docker: Remove libarchive as a dependency
  • rpm: Remove libarchive from dependencies
  • cargo: Replace compress-tools with zip crate
  • cargo: Bump ahash to version 0.8.7
  • build(deps): bump serde from 1.0.195 to 1.0.196
  • build(deps): bump libc from 0.2.152 to 0.2.153
  • build(deps): bump reqwest from 0.11.23 to 0.11.24
  • docker: Install configuration file in the correct path
  • config: Make IAK/IDevID disabled by default

• Update to version 0.2.4+git.1706692574.a744517:

  • Bump version to 0.2.4
  • build(deps): bump uuid from 1.4.1 to 1.7.0 *…

This update for rust-keylime fixes the following issues:

• CVE-2025-55159: slab: incorrect bounds check in get_disjoint_mut function can lead to undefined behavior or potential crash due to out-of-bounds access (bsc#1248006)

• CVE-2025-3416: openssl: Use-After-Free in Md::fetch and Cipher::fetch in rust-openssl crate (bsc#1242623)

• CVE-2024-58266: shlex: certain bytes allowed to appear unquoted and unescaped in command arguments (bsc#1247193)

• CVE-2024-43806: rustix: rustix::fs::Dir iterator with the linux_raw backend can cause memory explosion (bsc#1229952)

• CVE-2024-12224: idna: idna accepts Punycode labels that do not produce any non-ASCII when decoded (bsc#1243861)

• RUSTSEC-2024-0006: Multiple issues involving quote API (bsc#1230029)

This update for librsvg fixes the following issues:

Update to version 2.52.12.

• CVE-2024-12224: idna: incorrect hostname comparisons and URL parsing may be performed due to acceptance of Punycode labels that do not produce any non-ASCII output when decoded (bsc#1243867).
• CVE-2024-43806: rustix: unbounded memory explosion leading to an application OOM crash when using the rustix::fs::Dir iterator with the linux_raw backend (bsc#1229950).

This update for librsvg fixes the following issues:

Update to version 2.60.2:

• CVE-2024-12224: Fixed idna accepts Punycode labels that do not produce any non-ASCII when decoded (bsc#1243867).
• CVE-2024-43806: Fixed memory explosion in rustix (bsc#1229950).

This update for librsvg fixes the following issues:

Update to version 2.60.2:

• CVE-2024-12224: Fixed idna accepts Punycode labels that do not produce any non-ASCII when decoded (bsc#1243867).
• CVE-2024-43806: Fixed memory explosion in rustix (bsc#1229950).

This update for sccache fixes the following issues:

Update to version 0.15.0~17.

• CVE-2023-26964: hyper,h2: high resource consumption due to stream stacking when H2 component processes HTTP2 RST_STREAM frames (bsc#1210346).
• CVE-2024-32650: rust-rustls: infinite loop in rustls::conn::ConnectionCommon:complete_io() when processing client input network input (bsc#1223238).
• CVE-2025-3416: openssl: use-after-free in Md::fetch and Cipher::fetch (bsc#1242611).
• CVE-2026-25727: time: stack exhaustion in the RFC 2822 date parser when processing certain user provided input (bsc#1257923).
• CVE-2026-41676: openssl: short buffer overflow via Deriver:derive and PkeyCtxRef:derive when using OpenSSL 1.1.1 (bsc#1270206).
• CVE-2026-41677: openssl: out-of-bounds read in PEM password callback when returning an oversized length (bsc#1270559).
• CVE-2026-41678: openssl: OOB write due to incorrect bounds assertion in aes::unwrap_key() (bsc#1270693).
• CVE-2026-41681: openssl: stack corruption due to MdCtxRef::digest_final() writing past caller buffer with no length check (bsc#1270736).
• CVE-2026-41898: openssl: information leak to network peers due to unchecked callback-returned length in PSK and cookie generate trampolines (bsc#1270869).
• CVE-2026-42327: openssl: undefined behavior in X509Ref::ocsp_responders when processing certificates with non-UTF-8 OCSP URLs (bsc#1270512).
• CVE-2026-44662: openssl: heap buffer overflow when encrypting with AES key-wrap-with-padding (bsc#1270938).
• CVE-2026-45784: openssl: out-of-bounds write in CipherCtxRef::cipher_update_inplace for AES-KW-PAD ciphers (bsc#1270948).