check-advisories CI is complaining about slice-ring-buffer 0.3.4

[alice-i-cecile]

See https://github.com/bevyengine/bevy/actions/runs/16354938610/job/46210844370?pr=20169

Run cargo deny check advisories
error[vulnerability]: Four unique double-free vulnerabilities triggered via safe APIs
    ┌─ /home/runner/work/bevy/bevy/Cargo.lock:504:1
    │
504 │ slice-ring-buffer 0.3.4 registry+https://github.com/rust-lang/crates.io-index
    │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ security vulnerability detected
    │
    ├ ID: RUSTSEC-2025-0044
    ├ Advisory: https://rustsec.org/advisories/RUSTSEC-2025-0044
    ├ The crate [`slice-ring-buffer`](https://crates.io/crates/slice-ring-buffer) was developed as a fork of [`slice-deque`](https://crates.io/crates/slice-deque) to continue maintenance and provide security patches, since the latter has been officially unmaintained ([RUSTSEC-2020-0158](https://rustsec.org/advisories/RUSTSEC-2020-0158.html)).
      
      While `slice-ring-buffer` has addressed some previously reported memory safety issues inherited from its fork origin ([RUSTSEC-2021-0047](https://rustsec.org/advisories/RUSTSEC-2021-0047.html)), it still retains multiple unresolved memory corruption vulnerabilities.
      
      Specifically, we have discovered four new memory safety bugs, each resulting in double-free violations that can occur when only safe APIs are invoked. These vulnerabilities correspond to four distinct safe APIs in the crate, each exposing unsound and vulnerable behavior due to incorrect usage of unsafe code internally.
      
      Unfortunately, the maintainer doesn't have much availability to resolve these issues so there's no concrete timeline for fixes. Community contributions towards fixing these vulnerabilities would be much appreciated.
    ├ Announcement: https://github.com/LiquidityC/slice_ring_buffer/issues/12
    ├ Solution: No safe upgrade is available!
    ├ slice-ring-buffer v0.3.4
      └── minimp3_fixed v0.5.4
          └── rodio v0.20.1
              └── bevy_audio v0.17.0-dev
                  └── bevy_internal v0.17.0-dev
                      ├── bevy v0.17.0-dev
                      └── bevy_dylib v0.17.0-dev
                          └── bevy v0.17.0-dev (*)

advisories FAILED

This is coming in through rodio, our audio crate.

There are a few possible ways to resolve this:

1. rodio might be swapping to symphonia
2. We could swap to firewheel, which already uses `symphonia
3. We could work upstream to help out the maintainer and fix this.
4. We could ignore this vulnerability, ideally after checking if it affects us.

[alice-i-cecile]

FYI @viridia, since you were asking about this.