{"id":"CVE-2024-43806","aliases":["AZL-48300","AZL-48304","AZL-48312","AZL-48318","AZL-48324","AZL-48327","AZL-48330","AZL-48333","DEBIAN-CVE-2024-43806","EUVD-2023-2715","GHSA-c827-hfw6-qwvm","SUSE-SU-2024:3404-1","SUSE-SU-2025:02809-1","SUSE-SU-2025:02810-1","SUSE-SU-2025:02811-1","SUSE-SU-2025:20057-1","SUSE-SU-2025:20858-1","SUSE-SU-2025:4411-1","SUSE-SU-2026:20755-1","SUSE-SU-2026:20910-1","SUSE-SU-2026:3022-1","UBUNTU-CVE-2024-43806","openSUSE-SU-2024:14306-1","openSUSE-SU-2024:14354-1","openSUSE-SU-2025:15294-1","openSUSE-SU-2026:20396-1"],"status":"published","title":"`rustix::fs::Dir` iterator with the `linux_raw` backend can cause memory explosion","description":"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.","severity":{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-12","score":0.0048,"percentile":0.41932,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-400"],"published":"2023-10-18T18:27:47Z","modified":"2026-11-05T05:40:51Z","fixes":[{"ecosystem":"crates.io","package":"rustix","fixed_in":["0.35.15","0.36.16","0.37.25","0.38.19"],"sources":["ghsa","osv"]},{"ecosystem":"Azure Linux:2","package":"cloud-hypervisor","fixed_in":["32.0-7"],"sources":["osv"]},{"ecosystem":"Azure Linux:2","package":"rust","fixed_in":["1.72.0-9"],"sources":["osv"]},{"ecosystem":"Azure Linux:3","package":"virtiofsd","fixed_in":["1.8.0-3"],"sources":["osv"]},{"ecosystem":"Azure Linux:2","package":"virtiofsd","fixed_in":["1.8.0-3"],"sources":["osv"]},{"ecosystem":"Azure Linux:2","package":"kata-containers-cc","fixed_in":["3.2.0.azl2-7"],"sources":["osv"]},{"ecosystem":"Azure Linux:3","package":"flux","fixed_in":["0.194.5-4"],"sources":["osv"]},{"ecosystem":"Azure Linux:3","package":"kata-containers-cc","fixed_in":["3.2.0.azl4-1"],"sources":["osv"]},{"ecosystem":"Azure Linux:3","package":"kata-containers","fixed_in":["3.2.0.azl4-1"],"sources":["osv"]},{"ecosystem":"Debian:13","package":"rust-rustix","fixed_in":["0.38.21-1"],"sources":["osv"]},{"ecosystem":"Debian:14","package":"rust-rustix","fixed_in":["0.38.21-1"],"sources":["osv"]},{"ecosystem":"SUSE:Linux Enterprise Module for Basesystem 15 SP5","package":"rage-encryption","fixed_in":["0.10.0+0-150500.3.6.1"],"sources":["osv"]},{"ecosystem":"SUSE:Linux Enterprise Module for Basesystem 15 SP6","package":"rage-encryption","fixed_in":["0.10.0+0-150500.3.6.1"],"sources":["osv"]},{"ecosystem":"openSUSE:Leap 15.5","package":"rage-encryption","fixed_in":["0.10.0+0-150500.3.6.1"],"sources":["osv"]},{"ecosystem":"openSUSE:Leap 15.6","package":"rage-encryption","fixed_in":["0.10.0+0-150500.3.6.1"],"sources":["osv"]},{"ecosystem":"openSUSE:Tumbleweed","package":"389-ds","fixed_in":["3.1.1~git13.a9c7ff9-1.1"],"sources":["osv"]},{"ecosystem":"openSUSE:Tumbleweed","package":"rage-encryption","fixed_in":["0.10.0+0-3.1"],"sources":["osv"]}],"affected":[{"source":"ghsa","ecosystem":"crates.io","package":"rustix","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.35.11"},{"fixed":"0.35.15"}]}]},{"source":"ghsa","ecosystem":"crates.io","package":"rustix","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.36.0"},{"fixed":"0.36.16"}]}]},{"source":"ghsa","ecosystem":"crates.io","package":"rustix","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.37.0"},{"fixed":"0.37.25"}]}]},{"source":"ghsa","ecosystem":"crates.io","package":"rustix","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0.38.0"},{"fixed":"0.38.19"}]}]},{"source":"osv","ecosystem":"Azure Linux:2","package":"cloud-hypervisor","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"32.0-7"}]}]},{"source":"osv","ecosystem":"Azure Linux:2","package":"rust","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.72.0-9"}]}]},{"source":"osv","ecosystem":"Azure Linux:3","package":"virtiofsd","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.8.0-3"}]}]},{"source":"osv","ecosystem":"Azure Linux:2","package":"virtiofsd","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.8.0-3"}]}]},{"source":"osv","ecosystem":"Azure Linux:2","package":"kata-containers-cc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.2.0.azl2-7"}]}]},{"source":"osv","ecosystem":"Azure Linux:3","package":"flux","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.194.5-4"}]}]},{"source":"osv","ecosystem":"Azure Linux:3","package":"kata-containers-cc","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.2.0.azl4-1"}]}]},{"source":"osv","ecosystem":"Azure Linux:3","package":"kata-containers","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.2.0.azl4-1"}]}]},{"source":"osv","ecosystem":"Debian:12","package":"rust-rustix","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["0.35.12-1","0.37.20-1","0.37.20-2","0.38.17-1","0.38.21-1","0.38.25-1","0.38.30-1","0.38.32-1","0.38.32-1+hurd.1","0.38.32-1+hurd.2","0.38.37-1","0.38.37-2","0.38.37-3","0.38.37-4","0.38.9-1","1.0.8-1","1.0.8-2","1.0.8-3","1.1.2-1","1.1.2-2","1.1.3-1","1.1.3-1+hurd.1","1.1.4+dfsg-1","1.1.5+ds-1"]},{"source":"osv","ecosystem":"Debian:13","package":"rust-rustix","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.38.21-1"}]}]},{"source":"osv","ecosystem":"Debian:14","package":"rust-rustix","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.38.21-1"}]}]},{"source":"osv","ecosystem":"crates.io","package":"rustix","ranges":[{"type":"SEMVER","events":[{"introduced":"0.35.11"},{"fixed":"0.35.15"}]}]},{"source":"osv","ecosystem":"crates.io","package":"rustix","ranges":[{"type":"SEMVER","events":[{"introduced":"0.36.0"},{"fixed":"0.36.16"}]}]},{"source":"osv","ecosystem":"crates.io","package":"rustix","ranges":[{"type":"SEMVER","events":[{"introduced":"0.37.0"},{"fixed":"0.37.25"}]}]},{"source":"osv","ecosystem":"crates.io","package":"rustix","ranges":[{"type":"SEMVER","events":[{"introduced":"0.38.0"},{"fixed":"0.38.19"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Module for Basesystem 15 SP5","package":"rage-encryption","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.10.0+0-150500.3.6.1"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Module for Basesystem 15 SP6","package":"rage-encryption","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.10.0+0-150500.3.6.1"}]}]},{"source":"osv","ecosystem":"openSUSE:Leap 15.5","package":"rage-encryption","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.10.0+0-150500.3.6.1"}]}]},{"source":"osv","ecosystem":"openSUSE:Leap 15.6","package":"rage-encryption","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.10.0+0-150500.3.6.1"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Micro 5.3","package":"rust-keylime","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.2.7+141-150400.3.7.1"}]}],"bundled":6},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Micro 5.4","package":"rust-keylime","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.2.7+141-150400.3.5.1"}]}],"bundled":6},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Micro 5.5","package":"rust-keylime","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.2.7+141-150500.3.5.1"}]}],"bundled":6},{"source":"osv","ecosystem":"SUSE:Linux Micro 6.0","package":"rust-keylime","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.2.6+13-1.1"}]}],"bundled":2},{"source":"osv","ecosystem":"SUSE:Linux Micro 6.1","package":"rust-keylime","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.2.8+12-slfo.1.1_1.1"}]}],"bundled":5},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Micro 5.3","package":"librsvg","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.52.12-150400.3.9.1"}]}],"bundled":2},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Micro 5.4","package":"librsvg","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.52.12-150400.3.9.1"}]}],"bundled":2},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Micro 5.5","package":"librsvg","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.52.12-150400.3.9.1"}]}],"bundled":2},{"source":"osv","ecosystem":"SUSE:Linux Micro 6.2","package":"librsvg","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.60.2-160000.1.1"}]}],"bundled":2},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 16.0","package":"librsvg","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.60.2-160000.1.1"}]}],"bundled":2},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP applications 16.0","package":"librsvg","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.60.2-160000.1.1"}]}],"bundled":2},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Module for Development Tools 15 SP7","package":"sccache","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.16.0~0-150600.10.11.1"}]}],"bundled":14},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 15 SP6-LTSS","package":"sccache","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.16.0~0-150600.10.11.1"}]}],"bundled":14},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP Applications 15 SP6","package":"sccache","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.16.0~0-150600.10.11.1"}]}],"bundled":14},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"rust-rustix","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["0.37.20-2","0.38.25-1","0.38.30-1"]},{"source":"osv","ecosystem":"Ubuntu:25.10","package":"rust-rustix","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["0.38.37-1","0.38.37-2","0.38.37-3","0.38.37-4"]},{"source":"osv","ecosystem":"Ubuntu:26.10","package":"rust-rustix","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["1.1.3-1","1.1.4+dfsg-1"]},{"source":"osv","ecosystem":"Ubuntu:26.04:LTS","package":"rust-rustix","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["0.38.37-4","1.1.2-1","1.1.2-2","1.1.3-1"]},{"source":"osv","ecosystem":"openSUSE:Tumbleweed","package":"389-ds","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.1~git13.a9c7ff9-1.1"}]}]},{"source":"osv","ecosystem":"openSUSE:Tumbleweed","package":"rage-encryption","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.10.0+0-3.1"}]}]},{"source":"osv","ecosystem":"openSUSE:Tumbleweed","package":"rust-keylime","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.2.7+70-2.1"}]}],"bundled":2},{"source":"osv","ecosystem":"openSUSE:Leap 16.0","package":"librsvg","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"2.60.2-160000.1.1"}]}],"bundled":2}],"products":[{"vendor":"bytecodealliance","product":"rustix"}],"references":[{"url":"https://github.com/bytecodealliance/rustix/security/advisories/GHSA-c827-hfw6-qwvm","tags":["x_refsource_CONFIRM","advisory","web","report"]},{"url":"https://github.com/imsnif/bandwhich/issues/284","tags":["x_refsource_MISC","report","web"]},{"url":"https://github.com/imsnif/bandwhich/issues/284#issuecomment-1754321993","tags":["web"]},{"url":"https://github.com/bytecodealliance/rustix/commit/31fd98ca723b93cc6101a3e29843ea5cf094e159","tags":["web"]},{"url":"https://github.com/bytecodealliance/rustix/commit/87481a97f4364d12d5d6f30cdd025a0fc509b8ec","tags":["web"]},{"url":"https://github.com/bytecodealliance/rustix/commit/df3c3a192cf144af0da8a57417fb4addbdc611f6","tags":["web"]},{"url":"https://github.com/bytecodealliance/rustix/commit/eecece4a84fc58eafdc809cc2cedd374dee876a5","tags":["web"]},{"url":"https://discord.com/channels/273534239310479360/1161137828395237556","tags":["web"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2024-43806","tags":["web","advisory"]},{"url":"https://github.com/advisories/GHSA-c827-hfw6-qwvm"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2024/43xxx/CVE-2024-43806.json","tags":["advisory"]},{"url":"https://security-tracker.debian.org/tracker/CVE-2024-43806","tags":["advisory"]},{"url":"https://github.com/bytecodealliance/rustix","tags":["package"]},{"url":"https://www.suse.com/support/update/announcement/2024/suse-su-20243404-1/","tags":["advisory"]},{"url":"https://bugzilla.suse.com/1229959","tags":["report"]},{"url":"https://www.suse.com/security/cve/CVE-2024-43806","tags":["web"]},{"url":"https://www.suse.com/support/update/announcement/2025/suse-su-202502809-1/","tags":["advisory"]},{"url":"https://bugzilla.suse.com/1210344","tags":["report"]},{"url":"https://bugzilla.suse.com/1223234","tags":["report"]},{"url":"https://bugzilla.suse.com/1229952","tags":["report"]},{"url":"https://bugzilla.suse.com/1230029","tags":["report"]},{"url":"https://bugzilla.suse.com/1242623","tags":["report"]},{"url":"https://bugzilla.suse.com/1243861","tags":["report"]},{"url":"https://bugzilla.suse.com/1247193","tags":["report"]},{"url":"https://www.suse.com/security/cve/CVE-2023-26964","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-12224","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2024-32650","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-3416","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-58266","tags":["web"]},{"url":"https://www.suse.com/support/update/announcement/2025/suse-su-202502810-1/","tags":["advisory"]},{"url":"https://www.suse.com/support/update/announcement/2025/suse-su-202502811-1/","tags":["advisory"]},{"url":"https://www.suse.com/support/update/announcement/2025/suse-su-202520057-1/","tags":["advisory"]},{"url":"https://www.suse.com/support/update/announcement/2025/suse-su-202520858-1/","tags":["advisory"]},{"url":"https://bugzilla.suse.com/1248006","tags":["report"]},{"url":"https://www.suse.com/security/cve/CVE-2024-58266","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2025-55159","tags":["web"]},{"url":"https://www.suse.com/support/update/announcement/2025/suse-su-20254411-1/","tags":["advisory"]},{"url":"https://bugzilla.suse.com/1229950","tags":["report"]},{"url":"https://bugzilla.suse.com/1243867","tags":["report"]},{"url":"https://www.suse.com/support/update/announcement/2026/suse-su-202620755-1/","tags":["advisory"]},{"url":"https://bugzilla.suse.com/1229376","tags":["report"]},{"url":"https://www.suse.com/support/update/announcement/2026/suse-su-202620910-1/","tags":["advisory"]},{"url":"https://www.suse.com/support/update/announcement/2026/suse-su-20263022-1/","tags":["advisory"]},{"url":"https://bugzilla.suse.com/1210346","tags":["report"]},{"url":"https://bugzilla.suse.com/1223238","tags":["report"]},{"url":"https://bugzilla.suse.com/1229955","tags":["report"]},{"url":"https://bugzilla.suse.com/1242611","tags":["report"]},{"url":"https://bugzilla.suse.com/1243868","tags":["report"]},{"url":"https://bugzilla.suse.com/1257923","tags":["report"]},{"url":"https://bugzilla.suse.com/1270206","tags":["report"]},{"url":"https://bugzilla.suse.com/1270512","tags":["report"]},{"url":"https://bugzilla.suse.com/1270559","tags":["report"]},{"url":"https://bugzilla.suse.com/1270693","tags":["report"]},{"url":"https://bugzilla.suse.com/1270736","tags":["report"]},{"url":"https://bugzilla.suse.com/1270869","tags":["report"]},{"url":"https://bugzilla.suse.com/1270938","tags":["report"]},{"url":"https://bugzilla.suse.com/1270948","tags":["report"]},{"url":"https://www.suse.com/security/cve/CVE-2026-25727","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-41676","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-41677","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-41678","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-41681","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-41898","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-42327","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-44662","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-45784","tags":["web"]},{"url":"https://ubuntu.com/security/CVE-2024-43806","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2024-43806","tags":["report"]},{"url":"","tags":["advisory"]},{"url":"https://lists.opensuse.org/archives/list/security-announce@lists.opensuse.org/thread/TXPZZSAXTA6CTQAGWASRTKWJQ3DFB7GG/","tags":["advisory"]}],"sources":{"cve":[{"id":"CVE-2024-43806","title":"`rustix::fs::Dir` iterator with the `linux_raw` backend can cause memory explosion","description":"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.","status":"published","published":"2024-08-26T18:43:22.626Z","modified":"2024-08-26T19:40:46.911Z","cvss":[{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","level":"medium","assessor":"cna"}],"cwes":["CWE-400"],"updated_at":"2026-11-02T14:33:58.839967Z"}],"euvd":[{"id":"EUVD-2023-2715","description":"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.","status":"published","published":"2024-08-26T18:43:22Z","modified":"2024-08-26T19:40:46Z","cvss":[{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","level":"medium"}],"updated_at":"2026-11-03T00:56:10.956482Z"}],"ghsa":[{"id":"GHSA-c827-hfw6-qwvm","title":"rustix's `rustix::fs::Dir` iterator with the `linux_raw` backend can cause memory explosion","description":"### Summary\n\nWhen 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.\n\n### Details\n\n#### Discovery\n\nThe symptoms were initially discovered in https://github.com/imsnif/bandwhich/issues/284. That post has lots of details of our investigation. See [this post](https://github.com/imsnif/bandwhich/issues/284#issuecomment-1754321993) and the [Discord thread](https://discord.com/channels/273534239310479360/1161137828395237556) for details.\n\n#### Diagnosis\n\nThis issue is caused by the combination of two independent bugs:\n\n1. Stuck iterator\n- The `rustix::fs::Dir` iterator can fail to halt after encountering an IO error, causing the caller to be stuck in an infinite loop.\n2. Memory over-allocation\n- `Dir::read_more` incorrectly grows the read buffer unconditionally each time it is called, regardless of necessity.\n\nSince `\u003cDir as Iterator\u003e::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.\n\n### PoC\n\n```rust\nfn main() -\u003e Result\u003c(), Box\u003cdyn std::error::Error\u003e\u003e {\n    // create a directory, get a FD to it, then unlink the directory but keep the FD\n    std::fs::create_dir(\"tmp_dir\")?;\n    let dir_fd = rustix::fs::openat(\n        rustix::fs::CWD,\n        rustix::cstr!(\"tmp_dir\"),\n        rustix::fs::OFlags::RDONLY | rustix::fs::OFlags::CLOEXEC,\n        rustix::fs::Mode::empty(),\n    )?;\n    std::fs::remove_dir(\"tmp_dir\")?;\n\n    // iterator gets stuck in infinite loop and memory explodes\n    rustix::fs::Dir::read_from(dir_fd)?\n        // the iterator keeps returning `Some(Err(_))`, but never halts by returning `None`\n        // therefore if the implementation ignores the error (or otherwise continues\n        // after seeing the error instead of breaking), the loop will not halt\n        .filter_map(|dirent_maybe_error| dirent_maybe_error.ok())\n        .for_each(|dirent| {\n            // your happy path\n            println!(\"{dirent:?}\");\n        });\n\n    Ok(())\n}\n```\n\n### Impact\n\nIf 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.\n\nAs 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.\n\nAn 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.","status":"published","published":"2023-10-18T18:27:47Z","modified":"2024-08-27T14:22:20Z","cvss":[{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","level":"medium"}],"cwes":["CWE-400"],"updated_at":"2026-11-02T14:38:00.257632Z"}],"nvd":[{"id":"CVE-2024-43806","description":"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.","status":"published","published":"2024-08-26T19:15:08.19Z","modified":"2026-06-17T07:51:44.96Z","cvss":[{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","level":"medium","assessor":"secondary"}],"cwes":["CWE-400"],"updated_at":"2026-11-02T14:10:21.771404Z"}],"osv":[{"id":"CVE-2024-43806","title":"`rustix::fs::Dir` iterator with the `linux_raw` backend can cause memory explosion","description":"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.","status":"published","published":"2024-08-26T18:43:22.626Z","modified":"2026-10-28T02:30:29.187418079Z","cvss":[{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","level":"medium"}],"cwes":["CWE-400"],"updated_at":"2026-11-02T15:44:42.322107Z"},{"id":"DEBIAN-CVE-2024-43806","description":"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.","status":"published","published":"2024-08-26T19:15:08.19Z","modified":"2026-11-02T12:03:00.332355618Z","cvss":[{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","level":"medium"}],"updated_at":"2026-11-02T15:45:43.473331Z"},{"id":"GHSA-c827-hfw6-qwvm","title":"rustix's `rustix::fs::Dir` iterator with the `linux_raw` backend can cause memory explosion","description":"### Summary\n\nWhen 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.\n\n### Details\n\n#### Discovery\n\nThe symptoms were initially discovered in https://github.com/imsnif/bandwhich/issues/284. That post has lots of details of our investigation. See [this post](https://github.com/imsnif/bandwhich/issues/284#issuecomment-1754321993) and the [Discord thread](https://discord.com/channels/273534239310479360/1161137828395237556) for details.\n\n#### Diagnosis\n\nThis issue is caused by the combination of two independent bugs:\n\n1. Stuck iterator\n- The `rustix::fs::Dir` iterator can fail to halt after encountering an IO error, causing the caller to be stuck in an infinite loop.\n2. Memory over-allocation\n- `Dir::read_more` incorrectly grows the read buffer unconditionally each time it is called, regardless of necessity.\n\nSince `\u003cDir as Iterator\u003e::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.\n\n### PoC\n\n```rust\nfn main() -\u003e Result\u003c(), Box\u003cdyn std::error::Error\u003e\u003e {\n    // create a directory, get a FD to it, then unlink the directory but keep the FD\n    std::fs::create_dir(\"tmp_dir\")?;\n    let dir_fd = rustix::fs::openat(\n        rustix::fs::CWD,\n        rustix::cstr!(\"tmp_dir\"),\n        rustix::fs::OFlags::RDONLY | rustix::fs::OFlags::CLOEXEC,\n        rustix::fs::Mode::empty(),\n    )?;\n    std::fs::remove_dir(\"tmp_dir\")?;\n\n    // iterator gets stuck in infinite loop and memory explodes\n    rustix::fs::Dir::read_from(dir_fd)?\n        // the iterator keeps returning `Some(Err(_))`, but never halts by returning `None`\n        // therefore if the implementation ignores the error (or otherwise continues\n        // after seeing the error instead of breaking), the loop will not halt\n        .filter_map(|dirent_maybe_error| dirent_maybe_error.ok())\n        .for_each(|dirent| {\n            // your happy path\n            println!(\"{dirent:?}\");\n        });\n\n    Ok(())\n}\n```\n\n### Impact\n\nIf 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.\n\nAs 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.\n\nAn 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.","status":"published","published":"2023-10-18T18:27:47Z","modified":"2026-09-10T03:50:03.698097046Z","cvss":[{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","level":"medium"}],"cwes":["CWE-400"],"updated_at":"2026-11-02T15:46:44.927642Z"},{"id":"UBUNTU-CVE-2024-43806","description":"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.","status":"published","published":"2024-08-26T19:15:00Z","modified":"2026-10-17T12:56:45.227501695Z","cvss":[{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","level":"medium"}],"updated_at":"2026-11-02T16:54:58.679387Z"},{"id":"AZL-48300","title":"CVE-2024-43806 affecting package cloud-hypervisor for versions less than 32.0-7","description":"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.","status":"published","published":"2024-08-26T19:15:08Z","modified":"2026-04-21T04:32:58.96276Z","updated_at":"2026-11-02T15:28:06.032783Z"},{"id":"AZL-48304","title":"CVE-2024-43806 affecting package rust for versions less than 1.72.0-9","description":"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.","status":"published","published":"2024-08-26T19:15:08Z","modified":"2026-04-21T04:32:59.425229Z","updated_at":"2026-11-02T15:28:06.032783Z"},{"id":"AZL-48312","title":"CVE-2024-43806 affecting package virtiofsd for versions less than 1.8.0-3","description":"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.","status":"published","published":"2024-08-26T19:15:08Z","modified":"2026-11-05T05:40:51Z","updated_at":"2026-11-05T16:41:20.514083Z"},{"id":"AZL-48318","title":"CVE-2024-43806 affecting package virtiofsd for versions less than 1.8.0-3","description":"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.","status":"published","published":"2024-08-26T19:15:08Z","modified":"2026-04-21T04:32:59.739696Z","updated_at":"2026-11-02T15:28:06.032783Z"},{"id":"AZL-48324","title":"CVE-2024-43806 affecting package kata-containers-cc for versions less than 3.2.0.azl2-7","description":"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.","status":"published","published":"2024-08-26T19:15:08Z","modified":"2026-04-21T04:32:59.901767Z","updated_at":"2026-11-02T15:28:06.032783Z"},{"id":"AZL-48327","title":"CVE-2024-43806 affecting package flux for versions less than 0.194.5-4","description":"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.","status":"published","published":"2024-08-26T19:15:08Z","modified":"2026-11-05T05:40:51Z","updated_at":"2026-11-05T16:41:20.514083Z"},{"id":"AZL-48330","title":"CVE-2024-43806 affecting package kata-containers-cc for versions less than 3.2.0.azl4-1","description":"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.","status":"published","published":"2024-08-26T19:15:08Z","modified":"2026-04-21T04:47:48.391931Z","updated_at":"2026-11-02T15:28:06.032783Z"},{"id":"AZL-48333","title":"CVE-2024-43806 affecting package kata-containers for versions less than 3.2.0.azl4-1","description":"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.","status":"published","published":"2024-08-26T19:15:08Z","modified":"2026-04-21T04:49:31.835691Z","updated_at":"2026-11-02T15:28:06.032783Z"},{"id":"openSUSE-SU-2024:14306-1","title":"389-ds-3.1.1~git13.a9c7ff9-1.1 on GA media","description":"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.","status":"published","published":"2024-09-04T00:00:00Z","modified":"2025-05-07T18:16:13.50104Z","updated_at":"2026-11-02T16:58:36.662953Z"},{"id":"openSUSE-SU-2024:14354-1","title":"rage-encryption-0.10.0+0-3.1 on GA media","description":"These are all security issues fixed in the rage-encryption-0.10.0+0-3.1 package on the GA media of openSUSE Tumbleweed.","status":"published","published":"2024-09-20T00:00:00Z","modified":"2026-02-04T02:33:54.337841Z","updated_at":"2026-11-02T16:58:36.976155Z"},{"id":"openSUSE-SU-2025:15294-1","title":"keylime-ima-policy-0.2.7+70-2.1 on GA media","description":"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.","status":"published","published":"2025-07-03T00:00:00Z","modified":"2026-03-23T04:53:36.233749Z","updated_at":"2026-11-02T16:58:37.810934Z"},{"id":"openSUSE-SU-2026:20396-1","title":"Security update for librsvg","description":"This update for librsvg fixes the following issues:\n\nUpdate to version 2.60.2:\n\n- CVE-2024-12224: Fixed idna accepts Punycode labels that do not produce any non-ASCII when decoded (bsc#1243867).\n- CVE-2024-43806: Fixed memory explosion in rustix (bsc#1229950).\n","status":"published","published":"2026-03-19T08:11:15Z","modified":"2026-03-29T17:23:45.050754Z","updated_at":"2026-11-02T16:58:41.463445Z"},{"id":"SUSE-SU-2024:3404-1","title":"Security update for rage-encryption","description":"This update for rage-encryption fixes the following issues:\n\n- Update to version 0.10.0\n- CVE-2024-43806: Fixed rustix::fs::Dir iterator with the linux_raw backend that can cause memory exhaustion. (bsc#1229959) \n","status":"published","published":"2024-09-23T13:56:03Z","modified":"2026-02-04T03:24:08.216812Z","updated_at":"2026-11-02T15:53:55.639015Z"},{"id":"SUSE-SU-2025:02809-1","title":"Security update for rust-keylime","description":"This update for rust-keylime fixes the following issues:\n\n- Update to version 0.2.7+141:\n  * CVE-2025-58266: shlex: Fixed command injection (bsc#1247193)\n    \n- Update to version 0.2.7+117:\n  * CVE-2023-26964: rust-keylime: hyper,h2: stream stacking when H2 processing HTTP2 RST_STREAM frames (bsc#1210344).\n  * CVE-2024-12224: rust-keylime: idna: idna accepts Punycode labels that do not produce any non-ASCII when decoded (bsc#1243861).\n  * CVE-2024-32650: rust-keylime: rust-rustls: Infinite loop in rustls::conn::ConnectionCommon:complete_io() with proper client input (bsc#1223234).\n  * CVE-2024-43806: rust-keylime: rustix: rustix::fs::Dir iterator with the linux_raw backend can cause memory explosion (bsc#1229952).\n  * CVE-2025-3416: rust-keylime: openssl: Use-After-Free in Md::fetch and Cipher::fetch in rust-openssl crate (bsc#1242623).\n  * rust-shlex: Multiple issues involving quote API ( RUSTSEC-2024-0006, GHSA-r7qv-8r2h-pg27, bsc#1230029)\n","status":"published","published":"2025-08-15T12:51:37Z","modified":"2026-03-23T04:49:46.369393Z","updated_at":"2026-11-02T15:53:57.111474Z"},{"id":"SUSE-SU-2025:02810-1","title":"Security update for rust-keylime","description":"This update for rust-keylime fixes the following issues:\n\n- Update to version 0.2.7+141:\n  * CVE-2025-58266: shlex: Fixed command injection (bsc#1247193)\n    \n- Update to version 0.2.7+117:\n  * CVE-2023-26964: rust-keylime: hyper,h2: stream stacking when H2 processing HTTP2 RST_STREAM frames (bsc#1210344).\n  * CVE-2024-12224: rust-keylime: idna: idna accepts Punycode labels that do not produce any non-ASCII when decoded (bsc#1243861).\n  * CVE-2024-32650: rust-keylime: rust-rustls: Infinite loop in rustls::conn::ConnectionCommon:complete_io() with proper client input (bsc#1223234).\n  * CVE-2024-43806: rust-keylime: rustix: rustix::fs::Dir iterator with the linux_raw backend can cause memory explosion (bsc#1229952).\n  * CVE-2025-3416: rust-keylime: openssl: Use-After-Free in Md::fetch and Cipher::fetch in rust-openssl crate (bsc#1242623).\n  * rust-shlex: Multiple issues involving quote API ( RUSTSEC-2024-0006, GHSA-r7qv-8r2h-pg27, bsc#1230029)\n","status":"published","published":"2025-08-15T12:51:47Z","modified":"2026-03-23T04:46:48.999985Z","updated_at":"2026-11-02T15:53:57.111474Z"},{"id":"SUSE-SU-2025:02811-1","title":"Security update for rust-keylime","description":"This update for rust-keylime fixes the following issues:\n\n- Update to version 0.2.7+141:\n  * CVE-2025-58266: shlex: Fixed command injection (bsc#1247193)\n    \n- Update to version 0.2.7+117:\n  * CVE-2023-26964: rust-keylime: hyper,h2: stream stacking when H2 processing HTTP2 RST_STREAM frames (bsc#1210344).\n  * CVE-2024-12224: rust-keylime: idna: idna accepts Punycode labels that do not produce any non-ASCII when decoded (bsc#1243861).\n  * CVE-2024-32650: rust-keylime: rust-rustls: Infinite loop in rustls::conn::ConnectionCommon:complete_io() with proper client input (bsc#1223234).\n  * CVE-2024-43806: rust-keylime: rustix: rustix::fs::Dir iterator with the linux_raw backend can cause memory explosion (bsc#1229952).\n  * CVE-2025-3416: rust-keylime: openssl: Use-After-Free in Md::fetch and Cipher::fetch in rust-openssl crate (bsc#1242623).\n  * rust-shlex: Multiple issues involving quote API ( RUSTSEC-2024-0006, GHSA-r7qv-8r2h-pg27, bsc#1230029)\n","status":"published","published":"2025-08-15T12:51:54Z","modified":"2026-03-23T04:46:49.764211Z","updated_at":"2026-11-02T15:53:57.111474Z"},{"id":"SUSE-SU-2025:20057-1","title":"Security update for rust-keylime","description":"This update for rust-keylime fixes the following issues:\n\n- Update vendored crates (CVE-2024-43806, bsc#1229952, bsc#1230029)\n  * rustix 0.37.25\n  * rustix 0.38.34\n  * shlex  1.3.0\n\n- Update to version 0.2.6+13:\n  * Enable test functional/iak-idevid-persisted-and-protected\n  * build(deps): bump uuid from 1.7.0 to 1.10.0\n  * build(deps): bump openssl from 0.10.64 to 0.10.66\n  * keylime-agent/src/revocation: Fix comment indentation\n  * keylime/crypto: Fix indentation of documentation comment\n  * build(deps): bump thiserror from 1.0.59 to 1.0.63\n  * build(deps): bump serde_json from 1.0.116 to 1.0.120\n  * dependabot: Extend to also monitor workflow actions\n  * ci: Disable Packit CI on CentOS Stream 9\n  * ci: use CODECOV_TOKEN when submitting coverage data\n  * revocation: Use into() for unfallible transformation\n  * secure_mount: Fix possible infinite loop\n  * error: Rename enum variants to avoid clippy warning\n\n- Update to version 0.2.6~0:\n  * Bump version to 0.2.6\n  * build(deps): bump libc from 0.2.153 to 0.2.155\n  * build(deps): bump serde from 1.0.196 to 1.0.203\n  * rpm/fedora: Update rust macro usage\n  * config: Support hostnames in registrar_ip option\n  * added use of persisted IAK and IDevID and authorisation values\n  * config changes\n  * Adding /agent/info API to agent\n  * Fix leftover 'unnecessary qualification' warnings on tests\n\n- Update to version 0.2.5~4:\n  * Fix 'unnecessary qualification' warnings\n  * fix IAK template to match IDevID\n  * rpm: fix COPR RPMs build for centos-stream-10\n  * Build COPR RPMs for centos-stream-10\n\n- Update to version 0.2.5~0:\n  * Bump version to 0.2.5\n  * cargo: Relax required version for pest crate\n  * build(deps): bump log from 0.4.20 to 0.4.21\n  * build(deps): bump thiserror from 1.0.56 to 1.0.59\n\n- actix-web update moves rustls as feature (bsc#1223234, CVE-2024-32650)\n\n- Update to version 0.2.4~39:\n  * build(deps): bump openssl from 0.10.63 to 0.10.64\n  * build(deps): bump h2 from 0.3.24 to 0.3.26\n  * build(deps): bump serde_json from 1.0.107 to 1.0.116\n  * build(deps): bump actix-web from 4.4.1 to 4.5.1\n  * crypto: Enable TLS 1.3\n  * build(deps): bump tempfile from 3.9.0 to 3.10.1\n  * build(deps): bump mio from 0.8.4 to 0.8.11\n  * enable hex values to be used for tpm_ownerpassword\n  * config: Support IPv6 with or without brackets\n  * keylime: Implement a simple IP parser to remove brackets\n  * crypto: Implement CertificateBuilder to generate certificates\n  * tests: Fix coverage download by supporting arbitrary URL\n  * cargo: Add testing feature to keylime library\n  * Set X509 SAN with local DNSname/IP/IPv6\n  * Include newest Node20 versions for Github actions\n  * tpm: Add unit test for uncovered public functions\n  * crypto: Implement ECC key generation support\n  * crypto: Add test for match_cert_to_template()\n  * Fix minor typo, format and remove end whitespaces\n  * crypto: Make error types less specific\n  * tests/run.sh: Run tarpaulin with a single thread\n  * payloads: Remove explicit drop of channel transmitter\n  * crypto: Move to keylime library\n  * crypto: Add specific type for every possible error\n  * tpm: Rename origin of error as source in structures\n  * list_parser: Add source for error for backtrace\n  * algorithms: Make errors more specific\n  * typo fix for default path to measured boot log file\n  * README: remove mentions of libarchive as a dependency\n  * Dockerfile.wolfi: Update clang to version 17\n  * docker: Remove libarchive as a dependency\n  * rpm: Remove libarchive from dependencies\n  * cargo: Replace compress-tools with zip crate\n  * cargo: Bump ahash to version 0.8.7\n  * build(deps): bump serde from 1.0.195 to 1.0.196\n  * build(deps): bump libc from 0.2.152 to 0.2.153\n  * build(deps): bump reqwest from 0.11.23 to 0.11.24\n  * docker: Install configuration file in the correct path\n  * config: Make IAK/IDevID disabled by default\n\n- Update to version 0.2.4+git.1706692574.a744517:\n  * Bump version to 0.2.4\n  * build(deps): bump uuid from 1.4.1 to 1.7.0\n  * keylime-agent.conf: Allow setting event logs paths\n  * Mutable log paths: allow IMA and MBA log paths to be overridden by keylime configuration.\n  * workflows: Update checkout action to version 4\n  * build(deps): bump serde from 1.0.188 to 1.0.195\n  * build(deps): bump pest_derive from 2.7.0 to 2.7.6\n  * build(deps): bump openssl from 0.10.62 to 0.10.63\n  * build(deps): bump config from 0.13.3 to 0.13.4\n  * build(deps): bump base64 from 0.21.4 to 0.21.7\n  * build(deps): bump tempfile from 3.8.0 to 3.9.0\n  * build(deps): bump pest from 2.7.0 to 2.7.6\n  * build(deps): bump actix-web from 4.4.0 to 4.4.1\n  * build(deps): bump reqwest from 0.11.22 to 0.11.23\n  * build(deps): bump h2 from 0.3.17 to 0.3.24\n  * build(deps): bump shlex from 1.1.0 to 1.3.0\n  * cargo: Bump tss-esapi to version 7.4.0\n  * workflows: Fix keylime-bot token usage\n  * tpm: Add error context for every possible error\n  * tpm: Add AlgorithmError to TpmError\n  * detect idevid template from certificates\n  * build(deps): bump wiremock from 0.5.18 to 0.5.22\n  * build(deps): bump thiserror from 1.0.48 to 1.0.56\n  * Make use of workspace dependencies\n  * build(deps): bump openssl from 0.10.57 to 0.10.62\n  * packit: Bump Fedora version used for code coverage\n\n- Update to version 0.2.3+git.1701075380.a5dc985:\n  * build(deps): bump actix-rt from 2.8.0 to 2.9.0\n  * Bump version to 0.2.3\n  * build(deps): bump reqwest from 0.11.20 to 0.11.22\n  * Bump configuration version and fix enable_iak_idevid\n  * Enable test functional/iak-idevid-register-with-certificates\n  * Update packit plan with new tests\n  * Add certificates and certificate checking for IDevID and IAK keys (#669)\n\n- Update to version 0.2.2+git.1697658634.9c7c6fa:\n  * build(deps): bump rustix from 0.37.11 to 0.37.25\n  * build(deps): bump tempfile from 3.6.0 to 3.8.0\n  * build(deps): bump base64 from 0.21.0 to 0.21.4\n  * build(deps): bump serde_json from 1.0.96 to 1.0.107\n  * build(deps): bump openssl from 0.10.55 to 0.10.57\n  * cargo: Bump serde to version 1.0.188\n  * tests: Fix tarpaulin issues with dropped -v option\n  * build(deps): bump signal-hook from 0.3.15 to 0.3.17\n  * build(deps): bump actix-web from 4.3.1 to 4.4.0\n  * build(deps): bump thiserror from 1.0.40 to 1.0.48\n  * Remove private_in_public\n  * Initial PR to add support for IDevID and IAK\n  * build(deps): bump uuid from 1.3.1 to 1.4.1\n  * build(deps): bump log from 0.4.17 to 0.4.20\n  * build(deps): bump reqwest from 0.11.16 to 0.11.20\n  * Do not use too specific version on cargo audit workflow\n  * Add workflow to run cargo-audit security audit\n  * README: update dependencies for Debian and Ubuntu\n  * Use latest versions of checkout/upload-artifacts\n  * docker: Add 'keylime' system user\n  * Use \"currently\" for swtpm emulator warning (#632)\n  * Update container workflow actions versions\n  * Build container image and push to quay.io\n  * README: update requirements\n\n- Update to version 0.2.2+git.1689256829.3d2b627:\n  * Bump version to 0.2.2\n  * build(deps): bump tempfile from 3.5.0 to 3.6.0\n  * removing SIGINT stop signals from Dockerfiles and systemd service, as well as adding SIGTERM to IMA emulator as shutdown signal\n\n- Update to version 0.2.1+git.1689167094.67ce0cf:\n  * cargo: Bump serde to version 1.0.166\n  * build(deps): bump libc from 0.2.142 to 0.2.147\n  * adding release Dockerfiles in 3 flavours: fedora, distroless and wolfi\n  * hash: add more configurable hash algorithm for public key digest\n  * cargo: Update clap to version 4.3.11\n  * cargo: Bump tokio crate version to 1.28.2\n  * Add an example of IMA policy\n  * main: Gracefully shutdown on SIGTERM or SIGINT\n  * cargo: Bump proc-macro2 crate version\n  * revocation: Parse revocation actions flexibly\n  * crypto: Add unit tests for x509 functions\n  * crypto: Make internal functions private\n  * config: Add unit test for the list to files mapping\n  * config: Make trusted_client_ca to accept lists\n  * lib: Implement parser for lists from config file\n  * build(deps): bump openssl from 0.10.48 to 0.10.55\n  * Add secure mount sanity test to packit testing.\n  * [packit] Do not let COPR project expire\n\n- Recommends the IMA Policy subpackage only if SELinux is configured\n\n- Update to version 0.2.1+git.1685699835.3c9d17c:\n  * Remove MOUNT_SECURE bool\n  * rpm: Remove unused directory and add dependency for mount\n  * keylime-agent/src: update API version to 2.1 to consistent with https://github.com/keylime/keylime/blob/master/docs/rest_apis.rst\n  * docker/fedora/keylime_rust.Dockerfile: add the logic of cloning and compiling rust-keylime\n  * [tests] Update test coverage task name regexp\n  * [tests] Simply coverage file URL parsing\n\n","status":"published","published":"2025-02-03T08:57:24Z","modified":"2026-03-23T04:48:08.694691Z","updated_at":"2026-11-02T15:53:59.381172Z"},{"id":"SUSE-SU-2025:20858-1","title":"Security update for rust-keylime","description":"This update for rust-keylime fixes the following issues:\n\n- 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)\n- CVE-2025-3416: openssl: Use-After-Free in Md::fetch and Cipher::fetch in rust-openssl crate (bsc#1242623)\n- CVE-2024-58266: shlex: certain bytes allowed to appear unquoted and unescaped in command arguments (bsc#1247193)\n- CVE-2024-43806: rustix: rustix::fs::Dir iterator with the linux_raw backend can cause memory explosion (bsc#1229952)\n- CVE-2024-12224: idna: idna accepts Punycode labels that do not produce any non-ASCII when decoded (bsc#1243861)\n\n- RUSTSEC-2024-0006: Multiple issues involving quote API (bsc#1230029)\n","status":"published","published":"2025-10-14T13:18:43Z","modified":"2026-03-23T04:42:58.932899Z","updated_at":"2026-11-02T15:53:59.92114Z"},{"id":"SUSE-SU-2025:4411-1","title":"Security update for librsvg","description":"This update for librsvg fixes the following issues:\n\nUpdate to version 2.52.12.\n  \n- CVE-2024-12224: idna: incorrect hostname comparisons and URL parsing may be performed due to acceptance of Punycode\n  labels that do not produce any non-ASCII output when decoded (bsc#1243867).\n- CVE-2024-43806: rustix: unbounded memory explosion leading to an application OOM crash when using the `rustix::fs::Dir`\n  iterator with the `linux_raw` backend (bsc#1229950).\n","status":"published","published":"2025-12-16T11:35:35Z","modified":"2026-03-23T04:51:31.072947Z","updated_at":"2026-11-02T15:54:00.344164Z"},{"id":"SUSE-SU-2026:20755-1","title":"Security update for librsvg","description":"This update for librsvg fixes the following issues:\n\nUpdate to version 2.60.2:\n\n- CVE-2024-12224: Fixed idna accepts Punycode labels that do not produce any non-ASCII when decoded (bsc#1243867).\n- CVE-2024-43806: Fixed memory explosion in rustix (bsc#1229950).\n","status":"published","published":"2026-03-19T08:09:57Z","modified":"2026-03-25T17:23:42.75267Z","updated_at":"2026-11-02T15:54:01.953589Z"},{"id":"SUSE-SU-2026:20910-1","title":"Security update for librsvg","description":"This update for librsvg fixes the following issues:\n\nUpdate to version 2.60.2:\n\n- CVE-2024-12224: Fixed idna accepts Punycode labels that do not produce any non-ASCII when decoded (bsc#1243867).\n- CVE-2024-43806: Fixed memory explosion in rustix (bsc#1229950).\n","status":"published","published":"2026-03-19T08:09:57Z","modified":"2026-04-02T17:33:49.956441Z","updated_at":"2026-11-02T15:54:01.953589Z"},{"id":"SUSE-SU-2026:3022-1","title":"Security update for sccache","description":"This update for sccache fixes the following issues:\n\nUpdate to version 0.15.0~17.\n\n- CVE-2023-26964: hyper,h2: high resource consumption due to stream stacking when H2 component processes\n  `HTTP2 RST_STREAM` frames (bsc#1210346).\n- CVE-2024-32650: rust-rustls: infinite loop in `rustls::conn::ConnectionCommon:complete_io()` when processing client\n  input network input (bsc#1223238).\n- CVE-2025-3416: openssl: use-after-free in `Md::fetch` and `Cipher::fetch` (bsc#1242611).\n- CVE-2026-25727: time: stack exhaustion in the RFC 2822 date parser when processing certain user provided input\n  (bsc#1257923).\n- CVE-2026-41676: openssl: short buffer overflow via `Deriver:derive` and `PkeyCtxRef:derive` when using OpenSSL 1.1.1\n  (bsc#1270206).\n- CVE-2026-41677: openssl: out-of-bounds read in PEM password callback when returning an oversized length\n  (bsc#1270559).\n- CVE-2026-41678: openssl: OOB write due to incorrect bounds assertion in `aes::unwrap_key()` (bsc#1270693).\n- CVE-2026-41681: openssl: stack corruption due to `MdCtxRef::digest_final()` writing past caller buffer with no length\n  check (bsc#1270736).\n- CVE-2026-41898: openssl: information leak to network peers due to unchecked callback-returned length in PSK and\n  cookie generate trampolines (bsc#1270869).\n- CVE-2026-42327: openssl: undefined behavior in `X509Ref::ocsp_responders` when processing certificates with non-UTF-8\n  OCSP URLs (bsc#1270512).\n- CVE-2026-44662: openssl: heap buffer overflow when encrypting with AES key-wrap-with-padding (bsc#1270938).\n- CVE-2026-45784: openssl: out-of-bounds write in `CipherCtxRef::cipher_update_inplace` for AES-KW-PAD ciphers\n  (bsc#1270948).\n","status":"published","published":"2026-07-15T09:48:47Z","modified":"2026-07-16T10:00:06.462054885Z","updated_at":"2026-11-02T15:54:04.987808Z"}]}}