Need your own package repository for Alpine,
Cargo,
CocoaPods,
Composer,
Conan,
Conda,
CRAN,
Dart,
Debian,
Docker,
Go,
Helm,
LuaRocks,
Maven,
npm,
NuGet,
P2,
Python,
RedHat,
Ruby,
Terraform,
Vagrant,
Raw & More?
Cloudsmith
provides better DevOps with simple and secure delivery
of your software, from dev to production.
Search by package name:
my-package
(implicit)
name:my-package
(explicit)
Search by package filename:
my-package.ext
(implicit)
filename:my-package.ext
(explicit)
Search by package tag:
latest
(implicit)
tag:latest
(explicit)
Search by package version:
1.0.0
(implicit)
version:1.0.0
(explicit)
prerelease:true
(prereleases)
prerelease:false
(no prereleases)
Search by package architecture:
architecture:x86_64
Search by package distribution:
distribution:el
Search by package license:
license:MIT
Search by package format:
format:deb
Search by package status:
status:in_progress
Search by package file checksum:
checksum:5afba
Search by package security status:
severity:critical
Search by package vulnerabilities:
vulnerabilities:>1
vulnerabilities:<1000
Search by package downloads:
downloads:>8
downloads:<100
Search by package type:
type:binary
type:source
Search by package size (bytes):
size:>50000
size:<10000
Search by dependency name:
dependency:log4j
Search by uploaded date:
uploaded:>"1 day ago"
uploaded:<"August 14, 2018 EST"
Search by entitlement token (identifier):
entitlement:3lKPVJPosCsY
For all queries, you can use:
~foo
for negation
For string queries, you can use:
^foo
to anchor to start of term
foo$
to anchor to end of term
foo*bar
for fuzzy matching
For number/date queries, you can use:
>foo
for values greater than
>=foo
for values greater / equal
<foo
for values less than
<=foo
for values less / equal
Search terms can use boolean logic (AND/OR/NOT).
rust-circle-ci
1.58-nightly-test
One-liner (summary)
Description
This package was uploaded with the following V2 Distribution manifest:
{
"schemaVersion": 2,
"mediaType": "application/vnd.docker.distribution.manifest.v2+json",
"config": {
"mediaType": "application/vnd.docker.container.image.v1+json",
"size": 9680,
"digest": "sha256:60aec537cfb58ba0c32afa9ba76666002b2807fc6273ee2589ebdb7c9f36007e"
},
"layers": [
{
"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
"size": 28567101,
"digest": "sha256:7b1a6ab2e44dbac178598dabe7cff59bd67233dba0b27e4fbd1f9d4b3c877a54"
},
{
"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
"size": 16462554,
"digest": "sha256:614f8a560fc9f8282f56d1bbd3e8f7730d73d3cf7c52ab20557c059ffdf14bd9"
},
{
"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
"size": 153384298,
"digest": "sha256:286237ed3ef6ae343ef95f723e72a27c17063ec19f9bae2f1603d580b01cf021"
},
{
"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
"size": 134420609,
"digest": "sha256:399e2c8e9203c1515d769f48c1f121823e9536cd93b9ef3a5b3da167b00ede19"
},
{
"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
"size": 9665454,
"digest": "sha256:005475ce877254ade8c722d69527b714fbfffa4868a348b7247cdc4d364b27a5"
},
{
"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
"size": 4404295,
"digest": "sha256:50445f39c1992c2bf53605086c6ef3d3d566c1aa0674cdfaff96c890eea87e5e"
},
{
"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
"size": 239,
"digest": "sha256:7e16385a20ca6fc2158feaa149362147726bc2ae20543fd55194cb8573779c8d"
},
{
"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
"size": 216877856,
"digest": "sha256:f9f0c3d8a7a4c8f803ba4b16776c90ac1326fd6f848cde4f5923f662a0b99aaa"
},
{
"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
"size": 32,
"digest": "sha256:4f4fb700ef54461cfa02571ae0db9a0dc1e0cdb5577484a6d75e68dc38e8acc1"
},
{
"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
"size": 360,
"digest": "sha256:795598f3afb614a6ef787d511ecc417fe50119237397ef01d46953eb49e2329d"
},
{
"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
"size": 138597424,
"digest": "sha256:758165efd1d291f870cc4daab7a1d445c96f8bc5829132eebeb7f7c9dfe8649f"
},
{
"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
"size": 45948488,
"digest": "sha256:8b68cae3c61caf326a648b4795579c29fa93ef04d0c92133a5f9798bc1958ac9"
},
{
"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
"size": 203,
"digest": "sha256:7200ebeb4d153ec4b901fdb17ac11b1db7bad2b841d157635b4c1b82e1c78d48"
},
{
"mediaType": "application/vnd.docker.image.rootfs.diff.tar.gzip",
"size": 197,
"digest": "sha256:51cc31dabec58df20e8f6c644eb98f4b7c084d4fafe99efd9d8c3dd4f35fca25"
}
]
}
ID: f7fce8b71e8ef3b3039c8408dc4dae9c3a5f60694cc4170b8f6a119e94e0bbbb Command: /bin/sh -c #(nop) ADD file:5d68d27cc15a80653c93d3a0b262a28112d47a46326ff5fc2dfbf7fa3b9a0ce8 in / |
sha256 | ||
ID: 31ca3bcb9bd3500bcc9e26b559e885178bf96e48b28208ad1900918d522ddc9b Parent: f7fce8b71e8ef3b3039c8408dc4dae9c3a5f60694cc4170b8f6a119e94e0bbbb Command: /bin/sh -c #(nop) CMD ["bash"] |
sha256 | ||
ID: 935b7bc528629d061d59a8d2957e7d9b74da5a0acdd81ffc2c85e4f891f114a5 Parent: 31ca3bcb9bd3500bcc9e26b559e885178bf96e48b28208ad1900918d522ddc9b Command: /bin/sh -c #(nop) LABEL maintainer=Community & Partner Engineering Team <community-partner@circleci.com> |
sha256 | ||
ID: 2b5e88e78655fdf5b51ab7274103009ef2b5728d9844228e1a1a918b3458c59f Parent: 935b7bc528629d061d59a8d2957e7d9b74da5a0acdd81ffc2c85e4f891f114a5 Command: /bin/bash -exo pipefail -c #(nop) SHELL [/bin/bash -exo pipefail -c] |
sha256 | ||
ID: 94da5d0e9eb4b9f09a8bd9bbe9449a5ce926a9d92178d4ac5582e7d28b800dab Parent: 2b5e88e78655fdf5b51ab7274103009ef2b5728d9844228e1a1a918b3458c59f Command: /bin/bash -exo pipefail -c #(nop) ENV DEBIAN_FRONTEND=noninteractive |
sha256 | ||
ID: 3df429eb63f2ce04bb9d530f11ecf361cc6a8f41d0635e9e40f95d51d6f50873 Parent: 94da5d0e9eb4b9f09a8bd9bbe9449a5ce926a9d92178d4ac5582e7d28b800dab Command: /bin/bash -exo pipefail -c echo 'APT::Get::Assume-Yes "true";' > /etc/apt/apt.conf.d/90circleci && echo 'DPkg::Options "--force-confnew";' >> /etc/apt/apt.conf.d/90circleci && apt-get update && apt-get install -y curl locales sudo && locale-gen en_US.UTF-8 && rm -rf /var/lib/apt/lists/* && useradd --uid=3434 --user-group --create-home circleci && echo 'circleci ALL=NOPASSWD: ALL' >> /etc/sudoers.d/50-circleci && echo 'Defaults env_keep += "DEBIAN_FRONTEND"' >> /etc/sudoers.d/env_keep && sudo -u circleci mkdir /home/circleci/project && curl -sSL --fail --retry 3 --output /tmp/dockerize-linux-amd64.tar.gz "https://circle-downloads.s3.amazonaws.com/circleci-images/cache/linux-amd64/dockerize-latest.tar.gz" && tar -C /usr/local/bin -xzvf /tmp/dockerize-linux-amd64.tar.gz && rm -rf /tmp/dockerize-linux-amd64.tar.gz && dockerize --version |
sha256 | ||
ID: 4b9ccf1b631739537091215a8e146062131f12261717f693e693c660b36a0f50 Parent: 3df429eb63f2ce04bb9d530f11ecf361cc6a8f41d0635e9e40f95d51d6f50873 Command: /bin/bash -exo pipefail -c #(nop) ENV PATH=/home/circleci/bin:/home/circleci/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin LANG=en_US.UTF-8 LANGUAGE=en_US:en LC_ALL=en_US.UTF-8 |
sha256 | ||
ID: 071e7208e07603041d70f7fc91c6526583cd269e0f761c7b02349f5981c4c426 Parent: 4b9ccf1b631739537091215a8e146062131f12261717f693e693c660b36a0f50 Command: /bin/bash -exo pipefail -c apt-get update && apt-get install -y autoconf build-essential ca-certificates cmake curl gnupg gzip jq libcurl4-openssl-dev libmariadb-dev libmariadb-dev-compat libpq-dev libssl-dev libsqlite3-dev make nano net-tools netcat openssh-client parallel pkg-config postgresql-client software-properties-common sudo tar tzdata unzip vim-tiny wget zip && add-apt-repository ppa:git-core/ppa && apt-get install -y git && rm -rf /var/lib/apt/lists/* |
sha256 | ||
ID: 7aa1d10a164121b335a709e2fb4fa5ef715cfee91a001cf30e266d4920e4250d Parent: 071e7208e07603041d70f7fc91c6526583cd269e0f761c7b02349f5981c4c426 Command: /bin/bash -exo pipefail -c #(nop) ENV DOCKER_VERSION=5:20.10.12~3-0~ubuntu- |
sha256 | ||
ID: 875602138b81ef76928eba712b7cc4cbd3639dd1afe1c2d16ab7391bd9dae2b2 Parent: 7aa1d10a164121b335a709e2fb4fa5ef715cfee91a001cf30e266d4920e4250d Command: /bin/bash -exo pipefail -c apt-get update && apt-get install -y apt-transport-https ca-certificates curl gnupg-agent software-properties-common && curl -fsSL https://download.docker.com/linux/ubuntu/gpg | apt-key add - && add-apt-repository -y "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" && apt-get install -y docker-ce=${DOCKER_VERSION}$(lsb_release -cs) docker-ce-cli=${DOCKER_VERSION}$(lsb_release -cs) containerd.io && docker --version && rm -rf /var/lib/apt/lists/* |
sha256 | ||
ID: e2d5a26abbfca0dce992724cfee3a265cebbcbc9b6c8f6d62fff24ed062c592e Parent: 875602138b81ef76928eba712b7cc4cbd3639dd1afe1c2d16ab7391bd9dae2b2 Command: /bin/bash -exo pipefail -c #(nop) ENV COMPOSE_VERSION=2.2.3 |
sha256 | ||
ID: 049512bc4145a97ea80e5f783e88731f5aedf6da3ef832ce55cf841183baeadb Parent: e2d5a26abbfca0dce992724cfee3a265cebbcbc9b6c8f6d62fff24ed062c592e Command: /bin/bash -exo pipefail -c #(nop) ENV COMPOSE_SWITCH_VERSION=1.0.4 |
sha256 | ||
ID: 914872def68fbe6c3be0b5fd1f405a586cd6143cdb13580c50340366bf333551 Parent: 049512bc4145a97ea80e5f783e88731f5aedf6da3ef832ce55cf841183baeadb Command: /bin/bash -exo pipefail -c dockerPluginDir=/usr/local/lib/docker/cli-plugins && mkdir -p $dockerPluginDir && curl -sSL "https://github.com/docker/compose/releases/download/v${COMPOSE_VERSION}/docker-compose-linux-$(uname -m)" -o $dockerPluginDir/docker-compose && chmod +x $dockerPluginDir/docker-compose && curl -fL https://github.com/docker/compose-switch/releases/download/v${COMPOSE_SWITCH_VERSION}/docker-compose-linux-amd64 -o /usr/local/bin/compose-switch && docker compose version && chmod +x /usr/local/bin/compose-switch && update-alternatives --install /usr/local/bin/docker-compose docker-compose /usr/local/bin/compose-switch 99 && docker-compose version |
sha256 | ||
ID: 2e8bcab5e99d3efcccc18bdbe6f8618f988e2960edea75a89e6ce6258bee6c88 Parent: 914872def68fbe6c3be0b5fd1f405a586cd6143cdb13580c50340366bf333551 Command: /bin/bash -exo pipefail -c curl -sSL "https://github.com/mikefarah/yq/releases/download/v4.16.2/yq_linux_amd64.tar.gz" | tar -xz -C /usr/local/bin && mv /usr/local/bin/yq{_linux_amd64,} |
sha256 | ||
ID: 367024a4d854980efcd625f83086ffde65eeb7273d6751fc8c6a0ffaf46d79f4 Parent: 2e8bcab5e99d3efcccc18bdbe6f8618f988e2960edea75a89e6ce6258bee6c88 Command: /bin/bash -exo pipefail -c #(nop) USER circleci |
sha256 | ||
ID: 2251e395f955ac21b47ec183c041cb9c4c7fa0545011954112df1c4e71ce50f7 Parent: 367024a4d854980efcd625f83086ffde65eeb7273d6751fc8c6a0ffaf46d79f4 Command: /bin/bash -exo pipefail -c #(nop) WORKDIR /home/circleci/project |
sha256 | ||
ID: 2bb4113d5cc7d8edbc1ce9d1e99e60e8178697f5e6727814e586ae15afdd69e0 Parent: 2251e395f955ac21b47ec183c041cb9c4c7fa0545011954112df1c4e71ce50f7 Command: LABEL maintainer=Community & Partner Engineering Team <community-partner@circleci.com> |
sha256 | ||
ID: 5e0a2d598560f2b4fcf1681606de266533e0bb04f7fe49b064524ed3fb294ad8 Parent: 2bb4113d5cc7d8edbc1ce9d1e99e60e8178697f5e6727814e586ae15afdd69e0 Command: ENV PATH=/home/circleci/.cargo/bin:/home/circleci/bin:/home/circleci/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin |
sha256 | ||
ID: 513f30b153f90256ef8d49b3bdc590d8aa2f7029eb0b3961528c190163d8652f Parent: 5e0a2d598560f2b4fcf1681606de266533e0bb04f7fe49b064524ed3fb294ad8 Command: COPY ../engine/rust-toolchain.toml rust-toolchain.toml # buildkit |
sha256 | ||
ID: d0a585544e9053dccec0e376ab6cd13e56ba3fbb0d71914e42e6f2fb033692d1 Parent: 513f30b153f90256ef8d49b3bdc590d8aa2f7029eb0b3961528c190163d8652f Command: RUN /bin/bash -exo pipefail -c curl -O https://static.rust-lang.org/rustup/dist/x86_64-unknown-linux-gnu/rustup-init && chmod +x rustup-init && ./rustup-init -y --no-modify-path --default-toolchain none && rm rustup-init && rustc --version && cargo --version # buildkit |
sha256 | ||
ID: c5d4ae7feac6d704c55aa75f4ffc4a2ddd3c0bbd8211aac6e59f661ccea11b04 Parent: d0a585544e9053dccec0e376ab6cd13e56ba3fbb0d71914e42e6f2fb033692d1 Command: RUN /bin/bash -exo pipefail -c rustup component add clippy rustfmt # buildkit |
sha256 | ||
ID: d2109831980e17fc5f7cd4b8635f873b42ab2d5940f66e775c5fa9cfaa65a18d Parent: c5d4ae7feac6d704c55aa75f4ffc4a2ddd3c0bbd8211aac6e59f661ccea11b04 Command: RUN /bin/bash -exo pipefail -c sudo apt-get update --allow-releaseinfo-change && sudo apt-get install -y cmake && sudo rm -rf /var/lib/apt/lists/* # buildkit |
sha256 | ||
ID: 618fe3c60beda29062e78aeee5dc37eb3e6674290378fb5294b814c8ac8dfef8 Parent: d2109831980e17fc5f7cd4b8635f873b42ab2d5940f66e775c5fa9cfaa65a18d Command: RUN /bin/bash -exo pipefail -c cargo install --locked --version 0.11.0 cargo-deny # buildkit |
sha256 | ||
ID: 004f7753caad41c0be43c2bf62804ea5f2ea2c2e33ea2cbbcf49b82e5c3f9243 Parent: 618fe3c60beda29062e78aeee5dc37eb3e6674290378fb5294b814c8ac8dfef8 Command: RUN /bin/bash -exo pipefail -c cargo install sccache # buildkit |
sha256 | ||
ID: d5f8a2e1d51188aadbd96aeec7d56b8c96522ecf5a60b88d8f09a2b54faba23d Parent: 004f7753caad41c0be43c2bf62804ea5f2ea2c2e33ea2cbbcf49b82e5c3f9243 Command: RUN /bin/bash -exo pipefail -c rm rust-toolchain.toml # buildkit |
sha256 | ||
ID: 6f4dfaabcf73a4b896b3785336e431de1e4edee5a283feb79c87a6d20832a907 Parent: d5f8a2e1d51188aadbd96aeec7d56b8c96522ecf5a60b88d8f09a2b54faba23d Command: RUN /bin/bash -exo pipefail -c sudo mkdir -p /usr/local/cargo/registry && sudo chown circleci:circleci -R /usr/local/cargo/registry # buildkit |
sha256 | ||
ID: 46287dbf0d6b6f8f41601f0385ae2ffed11af3309891acbccff7366a521ac00f Parent: 6f4dfaabcf73a4b896b3785336e431de1e4edee5a283feb79c87a6d20832a907 Command: ENV RUSTC_WRAPPER=sccache |
sha256 | ||
ID: af1b51a24089199c4f058d0b864e40d0cbb9d23e17960540200863206d1ed49c Parent: 46287dbf0d6b6f8f41601f0385ae2ffed11af3309891acbccff7366a521ac00f Command: ENV SCCACHE_CACHE_SIZE=4G |
sha256 |
![]() |
rust-circle-ci |
1704 |
![]() |
Last scanned
3 months, 3 weeks ago
Scan result
Vulnerable
Vulnerability count
530
Max. severity
HighTarget: | /oci (ubuntu 20.04) | |
HIGH |
CVE-2021-4034: polkit: Local privilege escalation in pkexec due to incorrect handling of argument vectorA local privilege escalation vulnerability was found on polkit's pkexec utility. The pkexec application is a setuid tool designed to allow unprivileged users to run commands as privileged users according predefined policies. The current version of pkexec doesn't handle the calling parameters count correctly and ends trying to execute environment variables as commands. An attacker can leverage this by crafting environment variables in such a way it'll induce pkexec to execute arbitrary code. When successfully executed the attack can cause a local privilege escalation given unprivileged users administrative rights on the target machine.Package Name: libpolkit-agent-1-0 Installed Version: 0.105-26ubuntu1.1 Fixed Version: 0.105-26ubuntu1.2 References: cve.mitre.org linux.oracle.com linux.oracle.com ubuntu.com ubuntu.com www.qualys.com |
|
HIGH |
CVE-2021-4034: polkit: Local privilege escalation in pkexec due to incorrect handling of argument vectorA local privilege escalation vulnerability was found on polkit's pkexec utility. The pkexec application is a setuid tool designed to allow unprivileged users to run commands as privileged users according predefined policies. The current version of pkexec doesn't handle the calling parameters count correctly and ends trying to execute environment variables as commands. An attacker can leverage this by crafting environment variables in such a way it'll induce pkexec to execute arbitrary code. When successfully executed the attack can cause a local privilege escalation given unprivileged users administrative rights on the target machine.Package Name: libpolkit-gobject-1-0 Installed Version: 0.105-26ubuntu1.1 Fixed Version: 0.105-26ubuntu1.2 References: cve.mitre.org linux.oracle.com linux.oracle.com ubuntu.com ubuntu.com www.qualys.com |
|
HIGH |
CVE-2022-0185: kernel: fs_context: heap overflow in legacy parameter handlingA heap-based buffer overflow flaw was found in the way the legacy_parse_param function in the Filesystem Context functionality of the Linux kernel verified the supplied parameters length. An unprivileged (in case of unprivileged user namespaces enabled, otherwise needs namespaced CAP_SYS_ADMIN privilege) local user able to open a filesystem that does not support the Filesystem Context API (and thus fallbacks to legacy handling) could use this flaw to escalate their privileges on the system.Package Name: linux-libc-dev Installed Version: 5.4.0-92.103 Fixed Version: 5.4.0-96.109 References: cve.mitre.org git.kernel.org git.kernel.org github.com linux.oracle.com linux.oracle.com ubuntu.com www.openwall.com www.willsroot.io |
|
HIGH |
CVE-2021-4034: polkit: Local privilege escalation in pkexec due to incorrect handling of argument vectorA local privilege escalation vulnerability was found on polkit's pkexec utility. The pkexec application is a setuid tool designed to allow unprivileged users to run commands as privileged users according predefined policies. The current version of pkexec doesn't handle the calling parameters count correctly and ends trying to execute environment variables as commands. An attacker can leverage this by crafting environment variables in such a way it'll induce pkexec to execute arbitrary code. When successfully executed the attack can cause a local privilege escalation given unprivileged users administrative rights on the target machine.Package Name: policykit-1 Installed Version: 0.105-26ubuntu1.1 Fixed Version: 0.105-26ubuntu1.2 References: cve.mitre.org linux.oracle.com linux.oracle.com ubuntu.com ubuntu.com www.qualys.com |
|
MEDIUM |
CVE-2016-1585In all versions of AppArmor mount rules are accidentally widened when compiled.Package Name: apparmor Installed Version: 2.13.3-7ubuntu5.1 Fixed Version: References: bugs.launchpad.net cve.mitre.org lists.apache.org |
|
MEDIUM |
CVE-2020-13844: kernel: ARM straight-line speculation vulnerabilityArm Armv8-A core implementations utilizing speculative execution past unconditional changes in control flow may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis, aka "straight-line speculation."Package Name: cpp Installed Version: 1.185.1ubuntu2 Fixed Version: References: lists.llvm.org lists.opensuse.org lists.opensuse.org cve.mitre.org developer.arm.com developer.arm.com developer.arm.com gcc.gnu.org git.kernel.org |
|
MEDIUM |
CVE-2020-13844: kernel: ARM straight-line speculation vulnerabilityArm Armv8-A core implementations utilizing speculative execution past unconditional changes in control flow may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis, aka "straight-line speculation."Package Name: cpp-9 Installed Version: 9.3.0-17ubuntu1~20.04 Fixed Version: References: lists.llvm.org lists.opensuse.org lists.opensuse.org cve.mitre.org developer.arm.com developer.arm.com developer.arm.com gcc.gnu.org git.kernel.org |
|
MEDIUM |
CVE-2020-13844: kernel: ARM straight-line speculation vulnerabilityArm Armv8-A core implementations utilizing speculative execution past unconditional changes in control flow may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis, aka "straight-line speculation."Package Name: g++ Installed Version: 1.185.1ubuntu2 Fixed Version: References: lists.llvm.org lists.opensuse.org lists.opensuse.org cve.mitre.org developer.arm.com developer.arm.com developer.arm.com gcc.gnu.org git.kernel.org |
|
MEDIUM |
CVE-2020-13844: kernel: ARM straight-line speculation vulnerabilityArm Armv8-A core implementations utilizing speculative execution past unconditional changes in control flow may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis, aka "straight-line speculation."Package Name: g++-9 Installed Version: 9.3.0-17ubuntu1~20.04 Fixed Version: References: lists.llvm.org lists.opensuse.org lists.opensuse.org cve.mitre.org developer.arm.com developer.arm.com developer.arm.com gcc.gnu.org git.kernel.org |
|
MEDIUM |
CVE-2020-13844: kernel: ARM straight-line speculation vulnerabilityArm Armv8-A core implementations utilizing speculative execution past unconditional changes in control flow may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis, aka "straight-line speculation."Package Name: gcc Installed Version: 1.185.1ubuntu2 Fixed Version: References: lists.llvm.org lists.opensuse.org lists.opensuse.org cve.mitre.org developer.arm.com developer.arm.com developer.arm.com gcc.gnu.org git.kernel.org |
|
MEDIUM |
CVE-2020-13844: kernel: ARM straight-line speculation vulnerabilityArm Armv8-A core implementations utilizing speculative execution past unconditional changes in control flow may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis, aka "straight-line speculation."Package Name: gcc-9 Installed Version: 9.3.0-17ubuntu1~20.04 Fixed Version: References: lists.llvm.org lists.opensuse.org lists.opensuse.org cve.mitre.org developer.arm.com developer.arm.com developer.arm.com gcc.gnu.org git.kernel.org |
|
MEDIUM |
CVE-2020-13844: kernel: ARM straight-line speculation vulnerabilityArm Armv8-A core implementations utilizing speculative execution past unconditional changes in control flow may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis, aka "straight-line speculation."Package Name: gcc-9-base Installed Version: 9.3.0-17ubuntu1~20.04 Fixed Version: References: lists.llvm.org lists.opensuse.org lists.opensuse.org cve.mitre.org developer.arm.com developer.arm.com developer.arm.com gcc.gnu.org git.kernel.org |
|
MEDIUM |
CVE-2021-36222: krb5: Sending a request containing PA-ENCRYPTED-CHALLENGE padata element without using FAST could result in NULL dereference in KDC which leads to DoSec_verify in kdc/kdc_preauth_ec.c in the Key Distribution Center (KDC) in MIT Kerberos 5 (aka krb5) before 1.18.4 and 1.19.x before 1.19.2 allows remote attackers to cause a NULL pointer dereference and daemon crash. This occurs because a return value is not properly managed in a certain situation.Package Name: krb5-locales Installed Version: 1.17-6ubuntu4.1 Fixed Version: References: cve.mitre.org github.com github.com linux.oracle.com linux.oracle.com security.netapp.com security.netapp.com web.mit.edu www.debian.org www.oracle.com |
|
MEDIUM |
CVE-2016-1585In all versions of AppArmor mount rules are accidentally widened when compiled.Package Name: libapparmor1 Installed Version: 2.13.3-7ubuntu5.1 Fixed Version: References: bugs.launchpad.net cve.mitre.org lists.apache.org |
|
MEDIUM |
CVE-2021-23177: libarchive: extracting a symlink with ACLs modifies ACLs of targetAn improper link resolution flaw while extracting an archive can lead to changing the access control list (ACL) of the target of the link. An attacker may provide a malicious archive to a victim user, who would trigger this flaw when trying to extract the archive. A local attacker may use this flaw to change the ACL of a file on the system and gain more privileges.Package Name: libarchive13 Installed Version: 3.4.0-2ubuntu1 Fixed Version: References: cve.mitre.org |
|
MEDIUM |
CVE-2021-31566: libarchive: symbolic links incorrectly followed when changing modes, times, ACL and flags of a file while extracting an archiveAn improper link resolution flaw can occur while extracting an archive leading to changing modes, times, access control lists, and flags of a file outside of the archive. An attacker may provide a malicious archive to a victim user, who would trigger this flaw when trying to extract the archive. A local attacker may use this flaw to gain more privileges in a system.Package Name: libarchive13 Installed Version: 3.4.0-2ubuntu1 Fixed Version: References: cve.mitre.org |
|
MEDIUM |
CVE-2021-36976: libarchive: use-after-free in copy_string()libarchive 3.4.1 through 3.5.1 has a use-after-free in copy_string (called from do_uncompress_block and process_block).Package Name: libarchive13 Installed Version: 3.4.0-2ubuntu1 Fixed Version: References: bugs.chromium.org cve.mitre.org github.com |
|
MEDIUM |
CVE-2020-13844: kernel: ARM straight-line speculation vulnerabilityArm Armv8-A core implementations utilizing speculative execution past unconditional changes in control flow may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis, aka "straight-line speculation."Package Name: libasan5 Installed Version: 9.3.0-17ubuntu1~20.04 Fixed Version: References: lists.llvm.org lists.opensuse.org lists.opensuse.org cve.mitre.org developer.arm.com developer.arm.com developer.arm.com gcc.gnu.org git.kernel.org |
|
MEDIUM |
CVE-2021-38604: glibc: NULL pointer dereference in helper_thread() in mq_notify.c while handling NOTIFY_REMOVED messagesIn librt in the GNU C Library (aka glibc) through 2.34, sysdeps/unix/sysv/linux/mq_notify.c mishandles certain NOTIFY_REMOVED data, leading to a NULL pointer dereference. NOTE: this vulnerability was introduced as a side effect of the CVE-2021-33574 fix.Package Name: libc-bin Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: blog.tuxcare.com cve.mitre.org lists.fedoraproject.org security.netapp.com sourceware.org sourceware.org sourceware.org |
|
MEDIUM |
CVE-2021-3999: glibc: Off-by-one buffer overflow/underflow in getcwd()A flaw was found in glibc. An off-by-one buffer overflow and underflow in getcwd() may lead to memory corruption when the size of the buffer is exactly 1. A local attacker who can control the input buffer and size passed to getcwd() in a setuid program could use this flaw to potentially execute arbitrary code and escalate their privileges on the system.Package Name: libc-bin Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org www.openwall.com |
|
MEDIUM |
CVE-2022-23218: glibc: stack-based buffer overflow in svcunix_create via long pathnamesThe deprecated compatibility function svcunix_create in the sunrpc module of the GNU C Library (aka glibc) through 2.34 copies its path argument on the stack without validating its length, which may result in a buffer overflow, potentially resulting in a denial of service or (if an application is not built with a stack protector enabled) arbitrary code execution.Package Name: libc-bin Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org sourceware.org |
|
MEDIUM |
CVE-2022-23219: glibc: stack-based buffer overflow in sunrpc clnt_create via a long pathnameThe deprecated compatibility function clnt_create in the sunrpc module of the GNU C Library (aka glibc) through 2.34 copies its hostname argument on the stack without validating its length, which may result in a buffer overflow, potentially resulting in a denial of service or (if an application is not built with a stack protector enabled) arbitrary code execution.Package Name: libc-bin Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org sourceware.org |
|
MEDIUM |
CVE-2021-38604: glibc: NULL pointer dereference in helper_thread() in mq_notify.c while handling NOTIFY_REMOVED messagesIn librt in the GNU C Library (aka glibc) through 2.34, sysdeps/unix/sysv/linux/mq_notify.c mishandles certain NOTIFY_REMOVED data, leading to a NULL pointer dereference. NOTE: this vulnerability was introduced as a side effect of the CVE-2021-33574 fix.Package Name: libc-dev-bin Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: blog.tuxcare.com cve.mitre.org lists.fedoraproject.org security.netapp.com sourceware.org sourceware.org sourceware.org |
|
MEDIUM |
CVE-2021-3999: glibc: Off-by-one buffer overflow/underflow in getcwd()A flaw was found in glibc. An off-by-one buffer overflow and underflow in getcwd() may lead to memory corruption when the size of the buffer is exactly 1. A local attacker who can control the input buffer and size passed to getcwd() in a setuid program could use this flaw to potentially execute arbitrary code and escalate their privileges on the system.Package Name: libc-dev-bin Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org www.openwall.com |
|
MEDIUM |
CVE-2022-23218: glibc: stack-based buffer overflow in svcunix_create via long pathnamesThe deprecated compatibility function svcunix_create in the sunrpc module of the GNU C Library (aka glibc) through 2.34 copies its path argument on the stack without validating its length, which may result in a buffer overflow, potentially resulting in a denial of service or (if an application is not built with a stack protector enabled) arbitrary code execution.Package Name: libc-dev-bin Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org sourceware.org |
|
MEDIUM |
CVE-2022-23219: glibc: stack-based buffer overflow in sunrpc clnt_create via a long pathnameThe deprecated compatibility function clnt_create in the sunrpc module of the GNU C Library (aka glibc) through 2.34 copies its hostname argument on the stack without validating its length, which may result in a buffer overflow, potentially resulting in a denial of service or (if an application is not built with a stack protector enabled) arbitrary code execution.Package Name: libc-dev-bin Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org sourceware.org |
|
MEDIUM |
CVE-2021-38604: glibc: NULL pointer dereference in helper_thread() in mq_notify.c while handling NOTIFY_REMOVED messagesIn librt in the GNU C Library (aka glibc) through 2.34, sysdeps/unix/sysv/linux/mq_notify.c mishandles certain NOTIFY_REMOVED data, leading to a NULL pointer dereference. NOTE: this vulnerability was introduced as a side effect of the CVE-2021-33574 fix.Package Name: libc6 Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: blog.tuxcare.com cve.mitre.org lists.fedoraproject.org security.netapp.com sourceware.org sourceware.org sourceware.org |
|
MEDIUM |
CVE-2021-3999: glibc: Off-by-one buffer overflow/underflow in getcwd()A flaw was found in glibc. An off-by-one buffer overflow and underflow in getcwd() may lead to memory corruption when the size of the buffer is exactly 1. A local attacker who can control the input buffer and size passed to getcwd() in a setuid program could use this flaw to potentially execute arbitrary code and escalate their privileges on the system.Package Name: libc6 Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org www.openwall.com |
|
MEDIUM |
CVE-2022-23218: glibc: stack-based buffer overflow in svcunix_create via long pathnamesThe deprecated compatibility function svcunix_create in the sunrpc module of the GNU C Library (aka glibc) through 2.34 copies its path argument on the stack without validating its length, which may result in a buffer overflow, potentially resulting in a denial of service or (if an application is not built with a stack protector enabled) arbitrary code execution.Package Name: libc6 Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org sourceware.org |
|
MEDIUM |
CVE-2022-23219: glibc: stack-based buffer overflow in sunrpc clnt_create via a long pathnameThe deprecated compatibility function clnt_create in the sunrpc module of the GNU C Library (aka glibc) through 2.34 copies its hostname argument on the stack without validating its length, which may result in a buffer overflow, potentially resulting in a denial of service or (if an application is not built with a stack protector enabled) arbitrary code execution.Package Name: libc6 Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org sourceware.org |
|
MEDIUM |
CVE-2021-38604: glibc: NULL pointer dereference in helper_thread() in mq_notify.c while handling NOTIFY_REMOVED messagesIn librt in the GNU C Library (aka glibc) through 2.34, sysdeps/unix/sysv/linux/mq_notify.c mishandles certain NOTIFY_REMOVED data, leading to a NULL pointer dereference. NOTE: this vulnerability was introduced as a side effect of the CVE-2021-33574 fix.Package Name: libc6-dev Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: blog.tuxcare.com cve.mitre.org lists.fedoraproject.org security.netapp.com sourceware.org sourceware.org sourceware.org |
|
MEDIUM |
CVE-2021-3999: glibc: Off-by-one buffer overflow/underflow in getcwd()A flaw was found in glibc. An off-by-one buffer overflow and underflow in getcwd() may lead to memory corruption when the size of the buffer is exactly 1. A local attacker who can control the input buffer and size passed to getcwd() in a setuid program could use this flaw to potentially execute arbitrary code and escalate their privileges on the system.Package Name: libc6-dev Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org www.openwall.com |
|
MEDIUM |
CVE-2022-23218: glibc: stack-based buffer overflow in svcunix_create via long pathnamesThe deprecated compatibility function svcunix_create in the sunrpc module of the GNU C Library (aka glibc) through 2.34 copies its path argument on the stack without validating its length, which may result in a buffer overflow, potentially resulting in a denial of service or (if an application is not built with a stack protector enabled) arbitrary code execution.Package Name: libc6-dev Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org sourceware.org |
|
MEDIUM |
CVE-2022-23219: glibc: stack-based buffer overflow in sunrpc clnt_create via a long pathnameThe deprecated compatibility function clnt_create in the sunrpc module of the GNU C Library (aka glibc) through 2.34 copies its hostname argument on the stack without validating its length, which may result in a buffer overflow, potentially resulting in a denial of service or (if an application is not built with a stack protector enabled) arbitrary code execution.Package Name: libc6-dev Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org sourceware.org |
|
MEDIUM |
CVE-2021-4122: cryptsetup: disable encryption via header rewriteIt was found that a specially crafted LUKS header could trick cryptsetup into disabling encryption during the recovery of the device. An attacker with physical access to the medium, such as a flash disk, could use this flaw to force a user into permanently disabling the encryption layer of that medium.Package Name: libcryptsetup12 Installed Version: 2:2.2.2-3ubuntu2.3 Fixed Version: References: cve.mitre.org mirrors.edge.kernel.org www.openwall.com |
|
MEDIUM |
CVE-2022-23852: expat: integer overflow in function XML_GetBufferExpat (aka libexpat) before 2.4.4 has a signed integer overflow in XML_GetBuffer, for configurations with a nonzero XML_CONTEXT_BYTES.Package Name: libexpat1 Installed Version: 2.2.9-1build1 Fixed Version: References: cve.mitre.org github.com |
|
MEDIUM |
CVE-2020-13844: kernel: ARM straight-line speculation vulnerabilityArm Armv8-A core implementations utilizing speculative execution past unconditional changes in control flow may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis, aka "straight-line speculation."Package Name: libgcc-9-dev Installed Version: 9.3.0-17ubuntu1~20.04 Fixed Version: References: lists.llvm.org lists.opensuse.org lists.opensuse.org cve.mitre.org developer.arm.com developer.arm.com developer.arm.com gcc.gnu.org git.kernel.org |
|
MEDIUM |
CVE-2021-36222: krb5: Sending a request containing PA-ENCRYPTED-CHALLENGE padata element without using FAST could result in NULL dereference in KDC which leads to DoSec_verify in kdc/kdc_preauth_ec.c in the Key Distribution Center (KDC) in MIT Kerberos 5 (aka krb5) before 1.18.4 and 1.19.x before 1.19.2 allows remote attackers to cause a NULL pointer dereference and daemon crash. This occurs because a return value is not properly managed in a certain situation.Package Name: libgssapi-krb5-2 Installed Version: 1.17-6ubuntu4.1 Fixed Version: References: cve.mitre.org github.com github.com linux.oracle.com linux.oracle.com security.netapp.com security.netapp.com web.mit.edu www.debian.org www.oracle.com |
|
MEDIUM |
CVE-2021-36222: krb5: Sending a request containing PA-ENCRYPTED-CHALLENGE padata element without using FAST could result in NULL dereference in KDC which leads to DoSec_verify in kdc/kdc_preauth_ec.c in the Key Distribution Center (KDC) in MIT Kerberos 5 (aka krb5) before 1.18.4 and 1.19.x before 1.19.2 allows remote attackers to cause a NULL pointer dereference and daemon crash. This occurs because a return value is not properly managed in a certain situation.Package Name: libk5crypto3 Installed Version: 1.17-6ubuntu4.1 Fixed Version: References: cve.mitre.org github.com github.com linux.oracle.com linux.oracle.com security.netapp.com security.netapp.com web.mit.edu www.debian.org www.oracle.com |
|
MEDIUM |
CVE-2021-36222: krb5: Sending a request containing PA-ENCRYPTED-CHALLENGE padata element without using FAST could result in NULL dereference in KDC which leads to DoSec_verify in kdc/kdc_preauth_ec.c in the Key Distribution Center (KDC) in MIT Kerberos 5 (aka krb5) before 1.18.4 and 1.19.x before 1.19.2 allows remote attackers to cause a NULL pointer dereference and daemon crash. This occurs because a return value is not properly managed in a certain situation.Package Name: libkrb5-3 Installed Version: 1.17-6ubuntu4.1 Fixed Version: References: cve.mitre.org github.com github.com linux.oracle.com linux.oracle.com security.netapp.com security.netapp.com web.mit.edu www.debian.org www.oracle.com |
|
MEDIUM |
CVE-2021-36222: krb5: Sending a request containing PA-ENCRYPTED-CHALLENGE padata element without using FAST could result in NULL dereference in KDC which leads to DoSec_verify in kdc/kdc_preauth_ec.c in the Key Distribution Center (KDC) in MIT Kerberos 5 (aka krb5) before 1.18.4 and 1.19.x before 1.19.2 allows remote attackers to cause a NULL pointer dereference and daemon crash. This occurs because a return value is not properly managed in a certain situation.Package Name: libkrb5support0 Installed Version: 1.17-6ubuntu4.1 Fixed Version: References: cve.mitre.org github.com github.com linux.oracle.com linux.oracle.com security.netapp.com security.netapp.com web.mit.edu www.debian.org www.oracle.com |
|
MEDIUM |
CVE-2021-27928: mariadb: writable system variables allows a database user with SUPER privilege to execute arbitrary code as the system mysql userA remote code execution issue was discovered in MariaDB 10.2 before 10.2.37, 10.3 before 10.3.28, 10.4 before 10.4.18, and 10.5 before 10.5.9; Percona Server through 2021-03-03; and the wsrep patch through 2021-03-03 for MySQL. An untrusted search path leads to eval injection, in which a database SUPER user can execute OS commands after modifying wsrep_provider and wsrep_notify_cmd. NOTE: this does not affect an Oracle product.Package Name: libmariadb-dev Installed Version: 1:10.3.32-0ubuntu0.20.04.1 Fixed Version: References: packetstormsecurity.com cve.mitre.org jira.mariadb.org linux.oracle.com linux.oracle.com lists.debian.org mariadb.com mariadb.com mariadb.com mariadb.com mariadb.com security.gentoo.org |
|
MEDIUM |
CVE-2021-27928: mariadb: writable system variables allows a database user with SUPER privilege to execute arbitrary code as the system mysql userA remote code execution issue was discovered in MariaDB 10.2 before 10.2.37, 10.3 before 10.3.28, 10.4 before 10.4.18, and 10.5 before 10.5.9; Percona Server through 2021-03-03; and the wsrep patch through 2021-03-03 for MySQL. An untrusted search path leads to eval injection, in which a database SUPER user can execute OS commands after modifying wsrep_provider and wsrep_notify_cmd. NOTE: this does not affect an Oracle product.Package Name: libmariadb-dev-compat Installed Version: 1:10.3.32-0ubuntu0.20.04.1 Fixed Version: References: packetstormsecurity.com cve.mitre.org jira.mariadb.org linux.oracle.com linux.oracle.com lists.debian.org mariadb.com mariadb.com mariadb.com mariadb.com mariadb.com security.gentoo.org |
|
MEDIUM |
CVE-2021-27928: mariadb: writable system variables allows a database user with SUPER privilege to execute arbitrary code as the system mysql userA remote code execution issue was discovered in MariaDB 10.2 before 10.2.37, 10.3 before 10.3.28, 10.4 before 10.4.18, and 10.5 before 10.5.9; Percona Server through 2021-03-03; and the wsrep patch through 2021-03-03 for MySQL. An untrusted search path leads to eval injection, in which a database SUPER user can execute OS commands after modifying wsrep_provider and wsrep_notify_cmd. NOTE: this does not affect an Oracle product.Package Name: libmariadb3 Installed Version: 1:10.3.32-0ubuntu0.20.04.1 Fixed Version: References: packetstormsecurity.com cve.mitre.org jira.mariadb.org linux.oracle.com linux.oracle.com lists.debian.org mariadb.com mariadb.com mariadb.com mariadb.com mariadb.com security.gentoo.org |
|
MEDIUM |
CVE-2021-3997: systemd: Uncontrolled recursion in systemd-tmpfiles when removing filesA flaw was found in systemd. An uncontrolled recursion in systemd-tmpfiles may lead to a denial of service at boot time when too many nested directories are created in /tmp.Package Name: libnss-systemd Installed Version: 245.4-4ubuntu3.14 Fixed Version: 245.4-4ubuntu3.15 References: cve.mitre.org ubuntu.com www.openwall.com |
|
MEDIUM |
CVE-2021-3997: systemd: Uncontrolled recursion in systemd-tmpfiles when removing filesA flaw was found in systemd. An uncontrolled recursion in systemd-tmpfiles may lead to a denial of service at boot time when too many nested directories are created in /tmp.Package Name: libpam-systemd Installed Version: 245.4-4ubuntu3.14 Fixed Version: 245.4-4ubuntu3.15 References: cve.mitre.org ubuntu.com www.openwall.com |
|
MEDIUM |
CVE-2020-16156: perl-CPAN: Bypass of verification of signatures in CHECKSUMS filesCPAN 2.28 allows Signature Verification Bypass.Package Name: libperl5.30 Installed Version: 5.30.0-9ubuntu0.2 Fixed Version: References: blogs.perl.org blog.hackeriet.no cve.mitre.org github.com lists.fedoraproject.org lists.fedoraproject.org metacpan.org |
|
MEDIUM |
CVE-2020-9794An out-of-bounds read was addressed with improved bounds checking. This issue is fixed in iOS 13.5 and iPadOS 13.5, macOS Catalina 10.15.5, tvOS 13.4.5, watchOS 6.2.5, iTunes 12.10.7 for Windows, iCloud for Windows 11.2, iCloud for Windows 7.19. A malicious application may cause a denial of service or potentially disclose memory contents.Package Name: libsqlite3-0 Installed Version: 3.31.1-4ubuntu0.2 Fixed Version: References: cve.mitre.org lists.apache.org support.apple.com support.apple.com support.apple.com support.apple.com support.apple.com support.apple.com support.apple.com vuldb.com |
|
MEDIUM |
CVE-2020-9794An out-of-bounds read was addressed with improved bounds checking. This issue is fixed in iOS 13.5 and iPadOS 13.5, macOS Catalina 10.15.5, tvOS 13.4.5, watchOS 6.2.5, iTunes 12.10.7 for Windows, iCloud for Windows 11.2, iCloud for Windows 7.19. A malicious application may cause a denial of service or potentially disclose memory contents.Package Name: libsqlite3-dev Installed Version: 3.31.1-4ubuntu0.2 Fixed Version: References: cve.mitre.org lists.apache.org support.apple.com support.apple.com support.apple.com support.apple.com support.apple.com support.apple.com support.apple.com vuldb.com |
|
MEDIUM |
CVE-2020-13844: kernel: ARM straight-line speculation vulnerabilityArm Armv8-A core implementations utilizing speculative execution past unconditional changes in control flow may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis, aka "straight-line speculation."Package Name: libstdc++-9-dev Installed Version: 9.3.0-17ubuntu1~20.04 Fixed Version: References: lists.llvm.org lists.opensuse.org lists.opensuse.org cve.mitre.org developer.arm.com developer.arm.com developer.arm.com gcc.gnu.org git.kernel.org |
|
MEDIUM |
CVE-2021-3997: systemd: Uncontrolled recursion in systemd-tmpfiles when removing filesA flaw was found in systemd. An uncontrolled recursion in systemd-tmpfiles may lead to a denial of service at boot time when too many nested directories are created in /tmp.Package Name: libsystemd0 Installed Version: 245.4-4ubuntu3.14 Fixed Version: 245.4-4ubuntu3.15 References: cve.mitre.org ubuntu.com www.openwall.com |
|
MEDIUM |
CVE-2021-3997: systemd: Uncontrolled recursion in systemd-tmpfiles when removing filesA flaw was found in systemd. An uncontrolled recursion in systemd-tmpfiles may lead to a denial of service at boot time when too many nested directories are created in /tmp.Package Name: libudev1 Installed Version: 245.4-4ubuntu3.13 Fixed Version: 245.4-4ubuntu3.15 References: cve.mitre.org ubuntu.com www.openwall.com |
|
MEDIUM |
CVE-2013-7445: kernel: memory exhaustion via crafted Graphics Execution Manager (GEM) objectsThe Direct Rendering Manager (DRM) subsystem in the Linux kernel through 4.x mishandles requests for Graphics Execution Manager (GEM) objects, which allows context-dependent attackers to cause a denial of service (memory consumption) via an application that processes graphics data, as demonstrated by JavaScript code that creates many CANVAS elements for rendering by Chrome or Firefox.Package Name: linux-libc-dev Installed Version: 5.4.0-92.103 Fixed Version: References: bugzilla.kernel.org cve.mitre.org lists.freedesktop.org |
|
MEDIUM |
CVE-2015-8553: CVE-2015-2150 CVE-2015-8553 xen: non-maskable interrupts triggerable by guests (xsa120)Xen allows guest OS users to obtain sensitive information from uninitialized locations in host OS kernel memory by not enabling memory and I/O decoding control bits. NOTE: this vulnerability exists because of an incomplete fix for CVE-2015-0777.Package Name: linux-libc-dev Installed Version: 5.4.0-92.103 Fixed Version: References: thread.gmane.org xenbits.xen.org cve.mitre.org seclists.org www.debian.org |
|
MEDIUM |
CVE-2016-8660: kernel: xfs: local DoS due to a page lock order bug in the XFS seek hole/data implementationThe XFS subsystem in the Linux kernel through 4.8.2 allows local users to cause a denial of service (fdatasync failure and system hang) by using the vfs syscall group in the trinity program, related to a "page lock order bug in the XFS seek hole/data implementation."Package Name: linux-libc-dev Installed Version: 5.4.0-92.103 Fixed Version: References: www.openwall.com www.securityfocus.com bugzilla.redhat.com cve.mitre.org lore.kernel.org marc.info marc.info |
|
MEDIUM |
CVE-2018-17977: kernel: Mishandled interactions among XFRM Netlink messages, IPPROTO_AH packets, and IPPROTO_IP packets resulting in a denial of serviceThe Linux kernel 4.14.67 mishandles certain interaction among XFRM Netlink messages, IPPROTO_AH packets, and IPPROTO_IP packets, which allows local users to cause a denial of service (memory consumption and system hang) by leveraging root access to execute crafted applications, as demonstrated on CentOS 7.Package Name: linux-libc-dev Installed Version: 5.4.0-92.103 Fixed Version: References: www.securityfocus.com bugzilla.suse.com cve.mitre.org www.openwall.com |
|
MEDIUM |
CVE-2020-24504: kernel: Uncontrolled resource consumption in some Intel(R) Ethernet E810 Adapter driversUncontrolled resource consumption in some Intel(R) Ethernet E810 Adapter drivers for Linux before version 1.0.4 may allow an authenticated user to potentially enable denial of service via local access.Package Name: linux-libc-dev Installed Version: 5.4.0-92.103 Fixed Version: References: cve.mitre.org linux.oracle.com linux.oracle.com www.intel.com |
|
MEDIUM |
CVE-2020-27835: kernel: child process is able to access parent mm through hfi dev file handleA use after free in the Linux kernel infiniband hfi1 driver in versions prior to 5.10-rc6 was found in the way user calls Ioctl after open dev file and fork. A local user could use this flaw to crash the system.Package Name: linux-libc-dev Installed Version: 5.4.0-92.103 Fixed Version: References: bugzilla.redhat.com cve.mitre.org git.kernel.org linux.oracle.com linux.oracle.com ubuntu.com |
|
MEDIUM |
CVE-2020-36310: kernel: infinite loop in set_memory_region_test in arch/x86/kvm/svm/svm.c for certain nested page faultsAn issue was discovered in the Linux kernel before 5.8. arch/x86/kvm/svm/svm.c allows a set_memory_region_test infinite loop for certain nested page faults, aka CID-e72436bc3a52.Package Name: linux-libc-dev Installed Version: 5.4.0-92.103 Fixed Version: References: bugzilla.redhat.com cdn.kernel.org cve.mitre.org git.kernel.org git.kernel.org linux.oracle.com linux.oracle.com |
|
MEDIUM |
CVE-2021-26932: ELSA-2021-9136: Unbreakable Enterprise kernel-container security update (IMPORTANT)An issue was discovered in the Linux kernel 3.2 through 5.10.16, as used by Xen. Grant mapping operations often occur in batch hypercalls, where a number of operations are done in a single hypercall, the success or failure of each one is reported to the backend driver, and the backend driver then loops over the results, performing follow-up actions based on the success or failure of each operation. Unfortunately, when running in PV mode, the Linux backend drivers mishandle this: Some errors are ignored, effectively implying their success from the success of related batch elements. In other cases, errors resulting from one batch element lead to further batch elements not being inspected, and hence successful ones to not be possible to properly unmap upon error recovery. Only systems with Linux backends running in PV mode are vulnerable. Linux backends run in HVM / PVH modes are not vulnerable. This affects arch/*/xen/p2m.c and drivers/xen/gntdev.c.Package Name: linux-libc-dev Installed Version: 5.4.0-92.103 Fixed Version: References: xenbits.xen.org cve.mitre.org linux.oracle.com linux.oracle.com lists.debian.org lists.debian.org lists.fedoraproject.org lists.fedoraproject.org security.netapp.com www.openwall.com xenbits.xen.org |
|
MEDIUM |
CVE-2021-28714Guest can force Linux netback driver to hog large amounts of kernel memory T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Incoming data packets for a guest in the Linux kernel's netback driver are buffered until the guest is ready to process them. There are some measures taken for avoiding to pile up too much data, but those can be bypassed by the guest: There is a timeout how long the client side of an interface can stop consuming new packets before it is assumed to have stalled, but this timeout is rather long (60 seconds by default). Using a UDP connection on a fast interface can easily accumulate gigabytes of data in that time. (CVE-2021-28715) The timeout could even never trigger if the guest manages to have only one free slot in its RX queue ring page and the next package would require more than one free slot, which may be the case when using GSO, XDP, or software hashing. (CVE-2021-28714)Package Name: linux-libc-dev Installed Version: 5.4.0-92.103 Fixed Version: References: cve.mitre.org www.debian.org xenbits.xen.org xenbits.xenproject.org |
|
MEDIUM |
CVE-2021-28715Guest can force Linux netback driver to hog large amounts of kernel memory T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Incoming data packets for a guest in the Linux kernel's netback driver are buffered until the guest is ready to process them. There are some measures taken for avoiding to pile up too much data, but those can be bypassed by the guest: There is a timeout how long the client side of an interface can stop consuming new packets before it is assumed to have stalled, but this timeout is rather long (60 seconds by default). Using a UDP connection on a fast interface can easily accumulate gigabytes of data in that time. (CVE-2021-28715) The timeout could even never trigger if the guest manages to have only one free slot in its RX queue ring page and the next package would require more than one free slot, which may be the case when using GSO, XDP, or software hashing. (CVE-2021-28714)Package Name: linux-libc-dev Installed Version: 5.4.0-92.103 Fixed Version: References: cve.mitre.org www.debian.org xenbits.xen.org xenbits.xenproject.org |
|
MEDIUM |
CVE-2021-39685: kernel: USB gadget buffer overflowAn out of bounds memory access flaw in the Linux kernel's USB Peripheral Controller functionality was found in the way users call control request handlers in a specific way for the USB gadget. A local user could use this flaw to crash the system or escalate their privileges on the system.Package Name: linux-libc-dev Installed Version: 5.4.0-92.103 Fixed Version: References: cve.mitre.org git.kernel.org git.kernel.org github.com gitlab.com www.openwall.com |
|
MEDIUM |
CVE-2021-4001: kernel: race condition when the EBPF map is frozenA race condition was found in the Linux kernel's ebpf verifier between bpf_map_update_elem and bpf_map_freeze due to a missing lock in kernel/bpf/syscall.c. In this flaw, a local user with a special privilege (cap_sys_admin or cap_bpf) can modify the frozen mapped address space. This flaw affects kernel versions prior to 5.16 rc2.Package Name: linux-libc-dev Installed Version: 5.4.0-92.103 Fixed Version: References: bugzilla.redhat.com cve.mitre.org git.kernel.org git.kernel.org ubuntu.com |
|
MEDIUM |
CVE-2021-4083: kernel: fget: check that the fd still exists after getting a ref to itA read-after-free memory flaw was found in the Linux kernel's garbage collection for Unix domain socket file handlers in the way users call close() and fget() simultaneously and can potentially trigger a race condition. This flaw allows a local user to crash the system or escalate their privileges on the system. This flaw affects Linux kernel versions prior to 5.16-rc4.Package Name: linux-libc-dev Installed Version: 5.4.0-92.103 Fixed Version: References: bugzilla.redhat.com cve.mitre.org git.kernel.org git.kernel.org |
|
MEDIUM |
CVE-2021-4135: kernel: Heap information leak in map_lookup_elem functionA flaw memory leak in the Linux kernel's eBPF for the Simulated networking device driver in the way user uses BPF for the device such that function nsim_map_alloc_elem being called. A local user could use this flaw to get unauthorized access to some data.Package Name: linux-libc-dev Installed Version: 5.4.0-92.103 Fixed Version: References: cve.mitre.org git.kernel.org git.kernel.org |
|
MEDIUM |
CVE-2021-4150: kernel: Block subsystem mishandles reference countsA use-after-free flaw was found in the add_partition in block/partitions/core.c in the Linux kernel. A local attacker with user privileges could cause a denial of service on the system. The issue results from the lack of code cleanup when device_add call fails when adding a partition to the disk.Package Name: linux-libc-dev Installed Version: 5.4.0-92.103 Fixed Version: References: cve.mitre.org git.kernel.org lkml.org lkml.org |
|
MEDIUM |
CVE-2021-4155: kernel: xfs: raw block device data leak in XFS_IOC_ALLOCSP IOCTLA data leak flaw was found in the way XFS_IOC_ALLOCSP IOCTL in the XFS filesystem allowed for size increase of files with unaligned size. A local attacker could use this flaw to leak data on the XFS filesystem otherwise not accessible to them.Package Name: linux-libc-dev Installed Version: 5.4.0-92.103 Fixed Version: References: cve.mitre.org git.kernel.org git.kernel.org linux.oracle.com linux.oracle.com www.openwall.com |
|
MEDIUM |
CVE-2021-4202: kernel: Race condition in nci_request() leads to use after free while the device is getting removedA use-after-free flaw was found in nci_request in net/nfc/nci/core.c in NFC Controller Interface (NCI) in the Linux kernel. This flaw could allow a local attacker with user privileges to cause a data race problem while the device is getting removed, leading to a privilege escalation problem.Package Name: linux-libc-dev Installed Version: 5.4.0-92.103 Fixed Version: References: cve.mitre.org git.kernel.org git.kernel.org git.kernel.org |
|
MEDIUM |
CVE-2021-43975: kernel: out-of-bounds write in hw_atl_utils_fw_rpc_wait() in drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.cIn the Linux kernel through 5.15.2, hw_atl_utils_fw_rpc_wait in drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c allows an attacker (who can introduce a crafted device) to trigger an out-of-bounds write via a crafted length value.Package Name: linux-libc-dev Installed Version: 5.4.0-92.103 Fixed Version: References: cve.mitre.org git.kernel.org lists.fedoraproject.org lists.fedoraproject.org lore.kernel.org security.netapp.com |
|
MEDIUM |
CVE-2021-44733: kernel: use-after-free in the TEE subsystemA use-after-free exists in drivers/tee/tee_shm.c in the TEE subsystem in the Linux kernel through 5.15.11. This occurs because of a race condition in tee_shm_get_from_id during an attempt to free a shared memory object.Package Name: linux-libc-dev Installed Version: 5.4.0-92.103 Fixed Version: References: bugzilla.redhat.com cve.mitre.org git.kernel.org github.com lore.kernel.org lore.kernel.org security.netapp.com |
|
MEDIUM |
CVE-2021-45095: kernel: refcount leak in pep_sock_accept() in net/phonet/pep.cpep_sock_accept in net/phonet/pep.c in the Linux kernel through 5.15.8 has a refcount leak.Package Name: linux-libc-dev Installed Version: 5.4.0-92.103 Fixed Version: References: cve.mitre.org git.kernel.org github.com lore.kernel.org www.debian.org |
|
MEDIUM |
CVE-2021-45469: kernel: out-of-bounds memory access in __f2fs_setxattr() in fs/f2fs/xattr.c when an inode has an invalid last xattr entryIn __f2fs_setxattr in fs/f2fs/xattr.c in the Linux kernel through 5.15.11, there is an out-of-bounds memory access when an inode has an invalid last xattr entry.Package Name: linux-libc-dev Installed Version: 5.4.0-92.103 Fixed Version: References: www.openwall.com bugzilla.kernel.org cve.mitre.org git.kernel.org lists.fedoraproject.org lists.fedoraproject.org security.netapp.com www.debian.org |
|
MEDIUM |
CVE-2021-45480: kernel: memory leak in the __rds_conn_create() in net/rds/connection.cAn issue was discovered in the Linux kernel before 5.15.11. There is a memory leak in the __rds_conn_create() function in net/rds/connection.c in a certain combination of circumstances.Package Name: linux-libc-dev Installed Version: 5.4.0-92.103 Fixed Version: References: cdn.kernel.org cve.mitre.org git.kernel.org git.kernel.org github.com www.debian.org |
|
MEDIUM |
CVE-2021-38604: glibc: NULL pointer dereference in helper_thread() in mq_notify.c while handling NOTIFY_REMOVED messagesIn librt in the GNU C Library (aka glibc) through 2.34, sysdeps/unix/sysv/linux/mq_notify.c mishandles certain NOTIFY_REMOVED data, leading to a NULL pointer dereference. NOTE: this vulnerability was introduced as a side effect of the CVE-2021-33574 fix.Package Name: locales Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: blog.tuxcare.com cve.mitre.org lists.fedoraproject.org security.netapp.com sourceware.org sourceware.org sourceware.org |
|
MEDIUM |
CVE-2021-3999: glibc: Off-by-one buffer overflow/underflow in getcwd()A flaw was found in glibc. An off-by-one buffer overflow and underflow in getcwd() may lead to memory corruption when the size of the buffer is exactly 1. A local attacker who can control the input buffer and size passed to getcwd() in a setuid program could use this flaw to potentially execute arbitrary code and escalate their privileges on the system.Package Name: locales Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org www.openwall.com |
|
MEDIUM |
CVE-2022-23218: glibc: stack-based buffer overflow in svcunix_create via long pathnamesThe deprecated compatibility function svcunix_create in the sunrpc module of the GNU C Library (aka glibc) through 2.34 copies its path argument on the stack without validating its length, which may result in a buffer overflow, potentially resulting in a denial of service or (if an application is not built with a stack protector enabled) arbitrary code execution.Package Name: locales Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org sourceware.org |
|
MEDIUM |
CVE-2022-23219: glibc: stack-based buffer overflow in sunrpc clnt_create via a long pathnameThe deprecated compatibility function clnt_create in the sunrpc module of the GNU C Library (aka glibc) through 2.34 copies its hostname argument on the stack without validating its length, which may result in a buffer overflow, potentially resulting in a denial of service or (if an application is not built with a stack protector enabled) arbitrary code execution.Package Name: locales Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org sourceware.org |
|
MEDIUM |
CVE-2021-27928: mariadb: writable system variables allows a database user with SUPER privilege to execute arbitrary code as the system mysql userA remote code execution issue was discovered in MariaDB 10.2 before 10.2.37, 10.3 before 10.3.28, 10.4 before 10.4.18, and 10.5 before 10.5.9; Percona Server through 2021-03-03; and the wsrep patch through 2021-03-03 for MySQL. An untrusted search path leads to eval injection, in which a database SUPER user can execute OS commands after modifying wsrep_provider and wsrep_notify_cmd. NOTE: this does not affect an Oracle product.Package Name: mariadb-common Installed Version: 1:10.3.32-0ubuntu0.20.04.1 Fixed Version: References: packetstormsecurity.com cve.mitre.org jira.mariadb.org linux.oracle.com linux.oracle.com lists.debian.org mariadb.com mariadb.com mariadb.com mariadb.com mariadb.com security.gentoo.org |
|
MEDIUM |
CVE-2020-16156: perl-CPAN: Bypass of verification of signatures in CHECKSUMS filesCPAN 2.28 allows Signature Verification Bypass.Package Name: perl Installed Version: 5.30.0-9ubuntu0.2 Fixed Version: References: blogs.perl.org blog.hackeriet.no cve.mitre.org github.com lists.fedoraproject.org lists.fedoraproject.org metacpan.org |
|
MEDIUM |
CVE-2020-16156: perl-CPAN: Bypass of verification of signatures in CHECKSUMS filesCPAN 2.28 allows Signature Verification Bypass.Package Name: perl-base Installed Version: 5.30.0-9ubuntu0.2 Fixed Version: References: blogs.perl.org blog.hackeriet.no cve.mitre.org github.com lists.fedoraproject.org lists.fedoraproject.org metacpan.org |
|
MEDIUM |
CVE-2020-16156: perl-CPAN: Bypass of verification of signatures in CHECKSUMS filesCPAN 2.28 allows Signature Verification Bypass.Package Name: perl-modules-5.30 Installed Version: 5.30.0-9ubuntu0.2 Fixed Version: References: blogs.perl.org blog.hackeriet.no cve.mitre.org github.com lists.fedoraproject.org lists.fedoraproject.org metacpan.org |
|
MEDIUM |
CVE-2020-10756: QEMU: slirp: networking out-of-bounds read information disclosure vulnerabilityAn out-of-bounds read vulnerability was found in the SLiRP networking implementation of the QEMU emulator. This flaw occurs in the icmp6_send_echoreply() routine while replying to an ICMP echo request, also known as ping. This flaw allows a malicious guest to leak the contents of the host memory, resulting in possible information disclosure. This flaw affects versions of libslirp before 4.3.1.Package Name: slirp4netns Installed Version: 0.4.3-1 Fixed Version: References: lists.opensuse.org lists.opensuse.org bugzilla.redhat.com cve.mitre.org linux.oracle.com linux.oracle.com lists.debian.org lists.fedoraproject.org security.netapp.com ubuntu.com ubuntu.com usn.ubuntu.com usn.ubuntu.com www.debian.org www.zerodayinitiative.com |
|
MEDIUM |
CVE-2021-3997: systemd: Uncontrolled recursion in systemd-tmpfiles when removing filesA flaw was found in systemd. An uncontrolled recursion in systemd-tmpfiles may lead to a denial of service at boot time when too many nested directories are created in /tmp.Package Name: systemd Installed Version: 245.4-4ubuntu3.14 Fixed Version: 245.4-4ubuntu3.15 References: cve.mitre.org ubuntu.com www.openwall.com |
|
MEDIUM |
CVE-2021-3997: systemd: Uncontrolled recursion in systemd-tmpfiles when removing filesA flaw was found in systemd. An uncontrolled recursion in systemd-tmpfiles may lead to a denial of service at boot time when too many nested directories are created in /tmp.Package Name: systemd-sysv Installed Version: 245.4-4ubuntu3.14 Fixed Version: 245.4-4ubuntu3.15 References: cve.mitre.org ubuntu.com www.openwall.com |
|
MEDIUM |
CVE-2021-3997: systemd: Uncontrolled recursion in systemd-tmpfiles when removing filesA flaw was found in systemd. An uncontrolled recursion in systemd-tmpfiles may lead to a denial of service at boot time when too many nested directories are created in /tmp.Package Name: systemd-timesyncd Installed Version: 245.4-4ubuntu3.14 Fixed Version: 245.4-4ubuntu3.15 References: cve.mitre.org ubuntu.com www.openwall.com |
|
MEDIUM |
CVE-2021-3984: vim: illegal memory access in find_start_brace() in cindent.c when C-indentingvim is vulnerable to Heap-based Buffer OverflowPackage Name: vim-common Installed Version: 2:8.1.2269-1ubuntu5.4 Fixed Version: 2:8.1.2269-1ubuntu5.6 References: www.openwall.com cve.mitre.org github.com github.com huntr.dev lists.fedoraproject.org ubuntu.com |
|
MEDIUM |
CVE-2021-4019: vim: heap-based buffer overflow in find_help_tags() in help.cvim is vulnerable to Heap-based Buffer OverflowPackage Name: vim-common Installed Version: 2:8.1.2269-1ubuntu5.4 Fixed Version: 2:8.1.2269-1ubuntu5.6 References: www.openwall.com cve.mitre.org github.com github.com huntr.dev lists.fedoraproject.org lists.fedoraproject.org ubuntu.com |
|
MEDIUM |
CVE-2021-4069: vim: use-after-free in ex_open() in src/ex_docmd.cvim is vulnerable to Use After FreePackage Name: vim-common Installed Version: 2:8.1.2269-1ubuntu5.4 Fixed Version: 2:8.1.2269-1ubuntu5.6 References: www.openwall.com cve.mitre.org github.com huntr.dev lists.fedoraproject.org lists.fedoraproject.org ubuntu.com |
|
MEDIUM |
CVE-2021-4166: vim: out-of-bounds read in do_arg_all() in src/arglist.cvim is vulnerable to Out-of-bounds ReadPackage Name: vim-common Installed Version: 2:8.1.2269-1ubuntu5.4 Fixed Version: References: www.openwall.com cve.mitre.org github.com github.com huntr.dev lists.fedoraproject.org lists.fedoraproject.org |
|
MEDIUM |
CVE-2021-3984: vim: illegal memory access in find_start_brace() in cindent.c when C-indentingvim is vulnerable to Heap-based Buffer OverflowPackage Name: vim-tiny Installed Version: 2:8.1.2269-1ubuntu5.4 Fixed Version: 2:8.1.2269-1ubuntu5.6 References: www.openwall.com cve.mitre.org github.com github.com huntr.dev lists.fedoraproject.org ubuntu.com |
|
MEDIUM |
CVE-2021-4019: vim: heap-based buffer overflow in find_help_tags() in help.cvim is vulnerable to Heap-based Buffer OverflowPackage Name: vim-tiny Installed Version: 2:8.1.2269-1ubuntu5.4 Fixed Version: 2:8.1.2269-1ubuntu5.6 References: www.openwall.com cve.mitre.org github.com github.com huntr.dev lists.fedoraproject.org lists.fedoraproject.org ubuntu.com |
|
MEDIUM |
CVE-2021-4069: vim: use-after-free in ex_open() in src/ex_docmd.cvim is vulnerable to Use After FreePackage Name: vim-tiny Installed Version: 2:8.1.2269-1ubuntu5.4 Fixed Version: 2:8.1.2269-1ubuntu5.6 References: www.openwall.com cve.mitre.org github.com huntr.dev lists.fedoraproject.org lists.fedoraproject.org ubuntu.com |
|
MEDIUM |
CVE-2021-4166: vim: out-of-bounds read in do_arg_all() in src/arglist.cvim is vulnerable to Out-of-bounds ReadPackage Name: vim-tiny Installed Version: 2:8.1.2269-1ubuntu5.4 Fixed Version: References: www.openwall.com cve.mitre.org github.com github.com huntr.dev lists.fedoraproject.org lists.fedoraproject.org |
|
MEDIUM |
CVE-2021-31879: wget: authorization header disclosure on redirectGNU Wget through 1.21.1 does not omit the Authorization header upon a redirect to a different origin, a related issue to CVE-2018-1000007.Package Name: wget Installed Version: 1.20.3-1ubuntu2 Fixed Version: References: cve.mitre.org mail.gnu.org savannah.gnu.org security.netapp.com |
|
MEDIUM |
CVE-2021-3984: vim: illegal memory access in find_start_brace() in cindent.c when C-indentingvim is vulnerable to Heap-based Buffer OverflowPackage Name: xxd Installed Version: 2:8.1.2269-1ubuntu5.4 Fixed Version: 2:8.1.2269-1ubuntu5.6 References: www.openwall.com cve.mitre.org github.com github.com huntr.dev lists.fedoraproject.org ubuntu.com |
|
MEDIUM |
CVE-2021-4019: vim: heap-based buffer overflow in find_help_tags() in help.cvim is vulnerable to Heap-based Buffer OverflowPackage Name: xxd Installed Version: 2:8.1.2269-1ubuntu5.4 Fixed Version: 2:8.1.2269-1ubuntu5.6 References: www.openwall.com cve.mitre.org github.com github.com huntr.dev lists.fedoraproject.org lists.fedoraproject.org ubuntu.com |
|
MEDIUM |
CVE-2021-4069: vim: use-after-free in ex_open() in src/ex_docmd.cvim is vulnerable to Use After FreePackage Name: xxd Installed Version: 2:8.1.2269-1ubuntu5.4 Fixed Version: 2:8.1.2269-1ubuntu5.6 References: www.openwall.com cve.mitre.org github.com huntr.dev lists.fedoraproject.org lists.fedoraproject.org ubuntu.com |
|
MEDIUM |
CVE-2021-4166: vim: out-of-bounds read in do_arg_all() in src/arglist.cvim is vulnerable to Out-of-bounds ReadPackage Name: xxd Installed Version: 2:8.1.2269-1ubuntu5.4 Fixed Version: References: www.openwall.com cve.mitre.org github.com github.com huntr.dev lists.fedoraproject.org lists.fedoraproject.org |
|
LOW |
CVE-2019-18276: bash: when effective UID is not equal to its real UID the saved UID is not droppedAn issue was discovered in disable_priv_mode in shell.c in GNU Bash through 5.0 patch 11. By default, if Bash is run with its effective UID not equal to its real UID, it will drop privileges by setting its effective UID to its real UID. However, it does so incorrectly. On Linux and other systems that support "saved UID" functionality, the saved UID is not dropped. An attacker with command execution in the shell can use "enable -f" for runtime loading of a new builtin, which can be a shared object that calls setuid() and therefore regains privileges. However, binaries running with an effective UID of 0 are unaffected.Package Name: bash Installed Version: 5.0-6ubuntu1.1 Fixed Version: References: packetstormsecurity.com cve.mitre.org github.com linux.oracle.com linux.oracle.com lists.apache.org security.gentoo.org security.netapp.com www.youtube.com |
|
LOW |
CVE-2017-13716: binutils: Memory leak with the C++ symbol demangler routine in libibertyThe C++ symbol demangler routine in cplus-dem.c in libiberty, as distributed in GNU Binutils 2.29, allows remote attackers to cause a denial of service (excessive memory allocation and application crash) via a crafted file, as demonstrated by a call from the Binary File Descriptor (BFD) library (aka libbfd).Package Name: binutils Installed Version: 2.34-6ubuntu1.3 Fixed Version: References: cve.mitre.org sourceware.org |
|
LOW |
CVE-2018-20657: libiberty: Memory leak in demangle_template function resulting in a denial of serviceThe demangle_template function in cplus-dem.c in GNU libiberty, as distributed in GNU Binutils 2.31.1, has a memory leak via a crafted string, leading to a denial of service (memory consumption), as demonstrated by cxxfilt, a related issue to CVE-2018-12698.Package Name: binutils Installed Version: 2.34-6ubuntu1.3 Fixed Version: References: www.securityfocus.com access.redhat.com cve.mitre.org gcc.gnu.org linux.oracle.com linux.oracle.com support.f5.com |
|
LOW |
CVE-2019-1010204: binutils: Improper Input Validation, Signed/Unsigned Comparison, Out-of-bounds Read in gold/fileread.cc and elfcpp/elfcpp_file.h leads to denial of serviceGNU binutils gold gold v1.11-v1.16 (GNU binutils v2.21-v2.31.1) is affected by: Improper Input Validation, Signed/Unsigned Comparison, Out-of-bounds Read. The impact is: Denial of service. The component is: gold/fileread.cc:497, elfcpp/elfcpp_file.h:644. The attack vector is: An ELF file with an invalid e_shoff header field must be opened.Package Name: binutils Installed Version: 2.34-6ubuntu1.3 Fixed Version: References: cve.mitre.org linux.oracle.com linux.oracle.com security.netapp.com sourceware.org support.f5.com |
|
LOW |
CVE-2017-13716: binutils: Memory leak with the C++ symbol demangler routine in libibertyThe C++ symbol demangler routine in cplus-dem.c in libiberty, as distributed in GNU Binutils 2.29, allows remote attackers to cause a denial of service (excessive memory allocation and application crash) via a crafted file, as demonstrated by a call from the Binary File Descriptor (BFD) library (aka libbfd).Package Name: binutils-common Installed Version: 2.34-6ubuntu1.3 Fixed Version: References: cve.mitre.org sourceware.org |
|
LOW |
CVE-2018-20657: libiberty: Memory leak in demangle_template function resulting in a denial of serviceThe demangle_template function in cplus-dem.c in GNU libiberty, as distributed in GNU Binutils 2.31.1, has a memory leak via a crafted string, leading to a denial of service (memory consumption), as demonstrated by cxxfilt, a related issue to CVE-2018-12698.Package Name: binutils-common Installed Version: 2.34-6ubuntu1.3 Fixed Version: References: www.securityfocus.com access.redhat.com cve.mitre.org gcc.gnu.org linux.oracle.com linux.oracle.com support.f5.com |
|
LOW |
CVE-2019-1010204: binutils: Improper Input Validation, Signed/Unsigned Comparison, Out-of-bounds Read in gold/fileread.cc and elfcpp/elfcpp_file.h leads to denial of serviceGNU binutils gold gold v1.11-v1.16 (GNU binutils v2.21-v2.31.1) is affected by: Improper Input Validation, Signed/Unsigned Comparison, Out-of-bounds Read. The impact is: Denial of service. The component is: gold/fileread.cc:497, elfcpp/elfcpp_file.h:644. The attack vector is: An ELF file with an invalid e_shoff header field must be opened.Package Name: binutils-common Installed Version: 2.34-6ubuntu1.3 Fixed Version: References: cve.mitre.org linux.oracle.com linux.oracle.com security.netapp.com sourceware.org support.f5.com |
|
LOW |
CVE-2017-13716: binutils: Memory leak with the C++ symbol demangler routine in libibertyThe C++ symbol demangler routine in cplus-dem.c in libiberty, as distributed in GNU Binutils 2.29, allows remote attackers to cause a denial of service (excessive memory allocation and application crash) via a crafted file, as demonstrated by a call from the Binary File Descriptor (BFD) library (aka libbfd).Package Name: binutils-x86-64-linux-gnu Installed Version: 2.34-6ubuntu1.3 Fixed Version: References: cve.mitre.org sourceware.org |
|
LOW |
CVE-2018-20657: libiberty: Memory leak in demangle_template function resulting in a denial of serviceThe demangle_template function in cplus-dem.c in GNU libiberty, as distributed in GNU Binutils 2.31.1, has a memory leak via a crafted string, leading to a denial of service (memory consumption), as demonstrated by cxxfilt, a related issue to CVE-2018-12698.Package Name: binutils-x86-64-linux-gnu Installed Version: 2.34-6ubuntu1.3 Fixed Version: References: www.securityfocus.com access.redhat.com cve.mitre.org gcc.gnu.org linux.oracle.com linux.oracle.com support.f5.com |
|
LOW |
CVE-2019-1010204: binutils: Improper Input Validation, Signed/Unsigned Comparison, Out-of-bounds Read in gold/fileread.cc and elfcpp/elfcpp_file.h leads to denial of serviceGNU binutils gold gold v1.11-v1.16 (GNU binutils v2.21-v2.31.1) is affected by: Improper Input Validation, Signed/Unsigned Comparison, Out-of-bounds Read. The impact is: Denial of service. The component is: gold/fileread.cc:497, elfcpp/elfcpp_file.h:644. The attack vector is: An ELF file with an invalid e_shoff header field must be opened.Package Name: binutils-x86-64-linux-gnu Installed Version: 2.34-6ubuntu1.3 Fixed Version: References: cve.mitre.org linux.oracle.com linux.oracle.com security.netapp.com sourceware.org support.f5.com |
|
LOW |
CVE-2016-2781: coreutils: Non-privileged session can escape to the parent session in chrootchroot in GNU coreutils, when used with --userspec, allows local users to escape to the parent session via a crafted TIOCSTI ioctl call, which pushes characters to the terminal's input buffer.Package Name: coreutils Installed Version: 8.30-3ubuntu2 Fixed Version: References: seclists.org www.openwall.com www.openwall.com cve.mitre.org lists.apache.org lore.kernel.org |
|
LOW |
CVE-2020-35512: dbus: users with the same numeric UID could lead to use-after-free and undefined behaviourA use-after-free flaw was found in D-Bus Development branch <= 1.13.16, dbus-1.12.x stable branch <= 1.12.18, and dbus-1.10.x and older branches <= 1.10.30 when a system has multiple usernames sharing the same UID. When a set of policy rules references these usernames, D-Bus may free some memory in the heap, which is still used by data structures necessary for the other usernames sharing the UID, possibly leading to a crash or other undefined behaviorsPackage Name: dbus Installed Version: 1.12.16-2ubuntu2.1 Fixed Version: References: bugs.gentoo.org bugzilla.redhat.com cve.mitre.org gitlab.freedesktop.org gitlab.freedesktop.org gitlab.freedesktop.org gitlab.freedesktop.org gitlab.freedesktop.org security-tracker.debian.org ubuntu.com |
|
LOW |
CVE-2020-35512: dbus: users with the same numeric UID could lead to use-after-free and undefined behaviourA use-after-free flaw was found in D-Bus Development branch <= 1.13.16, dbus-1.12.x stable branch <= 1.12.18, and dbus-1.10.x and older branches <= 1.10.30 when a system has multiple usernames sharing the same UID. When a set of policy rules references these usernames, D-Bus may free some memory in the heap, which is still used by data structures necessary for the other usernames sharing the UID, possibly leading to a crash or other undefined behaviorsPackage Name: dbus-user-session Installed Version: 1.12.16-2ubuntu2.1 Fixed Version: References: bugs.gentoo.org bugzilla.redhat.com cve.mitre.org gitlab.freedesktop.org gitlab.freedesktop.org gitlab.freedesktop.org gitlab.freedesktop.org gitlab.freedesktop.org security-tracker.debian.org ubuntu.com |
|
LOW |
CVE-2018-1000021: git: client prints server-sent ANSI escape codes to the terminal, allowing for unverified messages to potentially execute arbitrary commandsGIT version 2.15.1 and earlier contains a Input Validation Error vulnerability in Client that can result in problems including messing up terminal configuration to RCE. This attack appear to be exploitable via The user must interact with a malicious git server, (or have their traffic modified in a MITM attack).Package Name: git Installed Version: 1:2.34.1-0ppa1~ubuntu20.04.1 Fixed Version: References: www.batterystapl.es cve.mitre.org |
|
LOW |
CVE-2018-1000021: git: client prints server-sent ANSI escape codes to the terminal, allowing for unverified messages to potentially execute arbitrary commandsGIT version 2.15.1 and earlier contains a Input Validation Error vulnerability in Client that can result in problems including messing up terminal configuration to RCE. This attack appear to be exploitable via The user must interact with a malicious git server, (or have their traffic modified in a MITM attack).Package Name: git-man Installed Version: 1:2.34.1-0ppa1~ubuntu20.04.1 Fixed Version: References: www.batterystapl.es cve.mitre.org |
|
LOW |
CVE-2018-5709: krb5: integer overflow in dbentry->n_key_data in kadmin/dbutil/dump.cAn issue was discovered in MIT Kerberos 5 (aka krb5) through 1.16. There is a variable "dbentry->n_key_data" in kadmin/dbutil/dump.c that can store 16-bit data but unknowingly the developer has assigned a "u4" variable to it, which is for 32-bit data. An attacker can use this vulnerability to affect other artifacts of the database as we know that a Kerberos database dump file contains trusted data.Package Name: krb5-locales Installed Version: 1.17-6ubuntu4.1 Fixed Version: References: cve.mitre.org github.com lists.apache.org |
|
LOW |
CVE-2021-3671: samba: Null pointer dereference on missing sname in TGS-REQA null pointer de-reference was found in the way samba kerberos server handled missing sname in TGS-REQ (Ticket Granting Server - Request). An authenticated user could use this flaw to crash the samba server.Package Name: libasn1-8-heimdal Installed Version: 7.7.0+dfsg-1ubuntu1 Fixed Version: References: bugzilla.redhat.com bugzilla.samba.org cve.mitre.org github.com ubuntu.com ubuntu.com |
|
LOW |
CVE-2017-13716: binutils: Memory leak with the C++ symbol demangler routine in libibertyThe C++ symbol demangler routine in cplus-dem.c in libiberty, as distributed in GNU Binutils 2.29, allows remote attackers to cause a denial of service (excessive memory allocation and application crash) via a crafted file, as demonstrated by a call from the Binary File Descriptor (BFD) library (aka libbfd).Package Name: libbinutils Installed Version: 2.34-6ubuntu1.3 Fixed Version: References: cve.mitre.org sourceware.org |
|
LOW |
CVE-2018-20657: libiberty: Memory leak in demangle_template function resulting in a denial of serviceThe demangle_template function in cplus-dem.c in GNU libiberty, as distributed in GNU Binutils 2.31.1, has a memory leak via a crafted string, leading to a denial of service (memory consumption), as demonstrated by cxxfilt, a related issue to CVE-2018-12698.Package Name: libbinutils Installed Version: 2.34-6ubuntu1.3 Fixed Version: References: www.securityfocus.com access.redhat.com cve.mitre.org gcc.gnu.org linux.oracle.com linux.oracle.com support.f5.com |
|
LOW |
CVE-2019-1010204: binutils: Improper Input Validation, Signed/Unsigned Comparison, Out-of-bounds Read in gold/fileread.cc and elfcpp/elfcpp_file.h leads to denial of serviceGNU binutils gold gold v1.11-v1.16 (GNU binutils v2.21-v2.31.1) is affected by: Improper Input Validation, Signed/Unsigned Comparison, Out-of-bounds Read. The impact is: Denial of service. The component is: gold/fileread.cc:497, elfcpp/elfcpp_file.h:644. The attack vector is: An ELF file with an invalid e_shoff header field must be opened.Package Name: libbinutils Installed Version: 2.34-6ubuntu1.3 Fixed Version: References: cve.mitre.org linux.oracle.com linux.oracle.com security.netapp.com sourceware.org support.f5.com |
|
LOW |
CVE-2016-10228: glibc: iconv program can hang when invoked with the -c optionThe iconv program in the GNU C Library (aka glibc or libc6) 2.31 and earlier, when invoked with multiple suffixes in the destination encoding (TRANSLATE or IGNORE) along with the -c option, enters an infinite loop when processing invalid multi-byte input sequences, leading to a denial of service.Package Name: libc-bin Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: openwall.com www.securityfocus.com cve.mitre.org linux.oracle.com linux.oracle.com lists.apache.org security.gentoo.org sourceware.org sourceware.org sourceware.org |
|
LOW |
CVE-2019-25013: glibc: buffer over-read in iconv when processing invalid multi-byte input sequences in the EUC-KR encodingThe iconv feature in the GNU C Library (aka glibc or libc6) through 2.32, when processing invalid multi-byte input sequences in the EUC-KR encoding, may have a buffer over-read.Package Name: libc-bin Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org linux.oracle.com linux.oracle.com lists.apache.org lists.apache.org lists.apache.org lists.apache.org lists.apache.org lists.apache.org lists.apache.org lists.apache.org lists.apache.org lists.fedoraproject.org lists.fedoraproject.org security.netapp.com sourceware.org sourceware.org |
|
LOW |
CVE-2020-27618: glibc: iconv when processing invalid multi-byte input sequences fails to advance the input state, which could result in an infinite loopThe iconv function in the GNU C Library (aka glibc or libc6) 2.32 and earlier, when processing invalid multi-byte input sequences in IBM1364, IBM1371, IBM1388, IBM1390, and IBM1399 encodings, fails to advance the input state, which could lead to an infinite loop in applications, resulting in a denial of service, a different vulnerability from CVE-2016-10228.Package Name: libc-bin Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org linux.oracle.com linux.oracle.com security.netapp.com sourceware.org sourceware.org |
|
LOW |
CVE-2020-29562: glibc: assertion failure in iconv when converting invalid UCS4The iconv function in the GNU C Library (aka glibc or libc6) 2.30 to 2.32, when converting UCS4 text containing an irreversible character, fails an assertion in the code path and aborts the program, potentially resulting in a denial of service.Package Name: libc-bin Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org lists.apache.org lists.fedoraproject.org security.gentoo.org security.netapp.com sourceware.org sourceware.org |
|
LOW |
CVE-2020-6096: glibc: signed comparison vulnerability in the ARMv7 memcpy functionAn exploitable signed comparison vulnerability exists in the ARMv7 memcpy() implementation of GNU glibc 2.30.9000. Calling memcpy() (on ARMv7 targets that utilize the GNU glibc implementation) with a negative value for the 'num' parameter results in a signed comparison vulnerability. If an attacker underflows the 'num' parameter to memcpy(), this vulnerability could lead to undefined behavior such as writing to out-of-bounds memory and potentially remote code execution. Furthermore, this memcpy() implementation allows for program execution to continue in scenarios where a segmentation fault or crash should have occurred. The dangers occur in that subsequent execution and iterations of this code will be executed with this corrupted data.Package Name: libc-bin Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org lists.apache.org lists.fedoraproject.org lists.fedoraproject.org security.gentoo.org sourceware.org sourceware.org talosintelligence.com ubuntu.com www.talosintelligence.com |
|
LOW |
CVE-2021-27645: glibc: Use-after-free in addgetnetgrentX function in netgroupcache.cThe nameserver caching daemon (nscd) in the GNU C Library (aka glibc or libc6) 2.29 through 2.33, when processing a request for netgroup lookup, may crash due to a double-free, potentially resulting in degraded service or Denial of Service on the local system. This is related to netgroupcache.c.Package Name: libc-bin Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org linux.oracle.com linux.oracle.com lists.fedoraproject.org lists.fedoraproject.org sourceware.org |
|
LOW |
CVE-2021-3326: glibc: Assertion failure in ISO-2022-JP-3 gconv module related to combining charactersThe iconv function in the GNU C Library (aka glibc or libc6) 2.32 and earlier, when processing invalid input sequences in the ISO-2022-JP-3 encoding, fails an assertion in the code path and aborts the program, potentially resulting in a denial of service.Package Name: libc-bin Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: www.openwall.com bugs.chromium.org cve.mitre.org linux.oracle.com linux.oracle.com security.netapp.com sourceware.org sourceware.org sourceware.org |
|
LOW |
CVE-2021-33574: glibc: mq_notify does not handle separately allocated thread attributesThe mq_notify function in the GNU C Library (aka glibc) versions 2.32 and 2.33 has a use-after-free. It may use the notification thread attributes object (passed through its struct sigevent parameter) after it has been freed by the caller, leading to a denial of service (application crash) or possibly unspecified other impact.Package Name: libc-bin Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org linux.oracle.com linux.oracle.com lists.fedoraproject.org security.gentoo.org security.netapp.com sourceware.org sourceware.org |
|
LOW |
CVE-2021-35942: glibc: Arbitrary read in wordexp()The wordexp function in the GNU C Library (aka glibc) through 2.33 may crash or read arbitrary memory in parse_param (in posix/wordexp.c) when called with an untrusted, crafted pattern, potentially resulting in a denial of service or disclosure of information. This occurs because atoi was used but strtoul should have been used to ensure correct calculations.Package Name: libc-bin Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org linux.oracle.com linux.oracle.com security.netapp.com sourceware.org sourceware.org sourceware.org |
|
LOW |
CVE-2016-10228: glibc: iconv program can hang when invoked with the -c optionThe iconv program in the GNU C Library (aka glibc or libc6) 2.31 and earlier, when invoked with multiple suffixes in the destination encoding (TRANSLATE or IGNORE) along with the -c option, enters an infinite loop when processing invalid multi-byte input sequences, leading to a denial of service.Package Name: libc-dev-bin Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: openwall.com www.securityfocus.com cve.mitre.org linux.oracle.com linux.oracle.com lists.apache.org security.gentoo.org sourceware.org sourceware.org sourceware.org |
|
LOW |
CVE-2019-25013: glibc: buffer over-read in iconv when processing invalid multi-byte input sequences in the EUC-KR encodingThe iconv feature in the GNU C Library (aka glibc or libc6) through 2.32, when processing invalid multi-byte input sequences in the EUC-KR encoding, may have a buffer over-read.Package Name: libc-dev-bin Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org linux.oracle.com linux.oracle.com lists.apache.org lists.apache.org lists.apache.org lists.apache.org lists.apache.org lists.apache.org lists.apache.org lists.apache.org lists.apache.org lists.fedoraproject.org lists.fedoraproject.org security.netapp.com sourceware.org sourceware.org |
|
LOW |
CVE-2020-27618: glibc: iconv when processing invalid multi-byte input sequences fails to advance the input state, which could result in an infinite loopThe iconv function in the GNU C Library (aka glibc or libc6) 2.32 and earlier, when processing invalid multi-byte input sequences in IBM1364, IBM1371, IBM1388, IBM1390, and IBM1399 encodings, fails to advance the input state, which could lead to an infinite loop in applications, resulting in a denial of service, a different vulnerability from CVE-2016-10228.Package Name: libc-dev-bin Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org linux.oracle.com linux.oracle.com security.netapp.com sourceware.org sourceware.org |
|
LOW |
CVE-2020-29562: glibc: assertion failure in iconv when converting invalid UCS4The iconv function in the GNU C Library (aka glibc or libc6) 2.30 to 2.32, when converting UCS4 text containing an irreversible character, fails an assertion in the code path and aborts the program, potentially resulting in a denial of service.Package Name: libc-dev-bin Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org lists.apache.org lists.fedoraproject.org security.gentoo.org security.netapp.com sourceware.org sourceware.org |
|
LOW |
CVE-2020-6096: glibc: signed comparison vulnerability in the ARMv7 memcpy functionAn exploitable signed comparison vulnerability exists in the ARMv7 memcpy() implementation of GNU glibc 2.30.9000. Calling memcpy() (on ARMv7 targets that utilize the GNU glibc implementation) with a negative value for the 'num' parameter results in a signed comparison vulnerability. If an attacker underflows the 'num' parameter to memcpy(), this vulnerability could lead to undefined behavior such as writing to out-of-bounds memory and potentially remote code execution. Furthermore, this memcpy() implementation allows for program execution to continue in scenarios where a segmentation fault or crash should have occurred. The dangers occur in that subsequent execution and iterations of this code will be executed with this corrupted data.Package Name: libc-dev-bin Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org lists.apache.org lists.fedoraproject.org lists.fedoraproject.org security.gentoo.org sourceware.org sourceware.org talosintelligence.com ubuntu.com www.talosintelligence.com |
|
LOW |
CVE-2021-27645: glibc: Use-after-free in addgetnetgrentX function in netgroupcache.cThe nameserver caching daemon (nscd) in the GNU C Library (aka glibc or libc6) 2.29 through 2.33, when processing a request for netgroup lookup, may crash due to a double-free, potentially resulting in degraded service or Denial of Service on the local system. This is related to netgroupcache.c.Package Name: libc-dev-bin Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org linux.oracle.com linux.oracle.com lists.fedoraproject.org lists.fedoraproject.org sourceware.org |
|
LOW |
CVE-2021-3326: glibc: Assertion failure in ISO-2022-JP-3 gconv module related to combining charactersThe iconv function in the GNU C Library (aka glibc or libc6) 2.32 and earlier, when processing invalid input sequences in the ISO-2022-JP-3 encoding, fails an assertion in the code path and aborts the program, potentially resulting in a denial of service.Package Name: libc-dev-bin Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: www.openwall.com bugs.chromium.org cve.mitre.org linux.oracle.com linux.oracle.com security.netapp.com sourceware.org sourceware.org sourceware.org |
|
LOW |
CVE-2021-33574: glibc: mq_notify does not handle separately allocated thread attributesThe mq_notify function in the GNU C Library (aka glibc) versions 2.32 and 2.33 has a use-after-free. It may use the notification thread attributes object (passed through its struct sigevent parameter) after it has been freed by the caller, leading to a denial of service (application crash) or possibly unspecified other impact.Package Name: libc-dev-bin Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org linux.oracle.com linux.oracle.com lists.fedoraproject.org security.gentoo.org security.netapp.com sourceware.org sourceware.org |
|
LOW |
CVE-2021-35942: glibc: Arbitrary read in wordexp()The wordexp function in the GNU C Library (aka glibc) through 2.33 may crash or read arbitrary memory in parse_param (in posix/wordexp.c) when called with an untrusted, crafted pattern, potentially resulting in a denial of service or disclosure of information. This occurs because atoi was used but strtoul should have been used to ensure correct calculations.Package Name: libc-dev-bin Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org linux.oracle.com linux.oracle.com security.netapp.com sourceware.org sourceware.org sourceware.org |
|
LOW |
CVE-2016-10228: glibc: iconv program can hang when invoked with the -c optionThe iconv program in the GNU C Library (aka glibc or libc6) 2.31 and earlier, when invoked with multiple suffixes in the destination encoding (TRANSLATE or IGNORE) along with the -c option, enters an infinite loop when processing invalid multi-byte input sequences, leading to a denial of service.Package Name: libc6 Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: openwall.com www.securityfocus.com cve.mitre.org linux.oracle.com linux.oracle.com lists.apache.org security.gentoo.org sourceware.org sourceware.org sourceware.org |
|
LOW |
CVE-2019-25013: glibc: buffer over-read in iconv when processing invalid multi-byte input sequences in the EUC-KR encodingThe iconv feature in the GNU C Library (aka glibc or libc6) through 2.32, when processing invalid multi-byte input sequences in the EUC-KR encoding, may have a buffer over-read.Package Name: libc6 Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org linux.oracle.com linux.oracle.com lists.apache.org lists.apache.org lists.apache.org lists.apache.org lists.apache.org lists.apache.org lists.apache.org lists.apache.org lists.apache.org lists.fedoraproject.org lists.fedoraproject.org security.netapp.com sourceware.org sourceware.org |
|
LOW |
CVE-2020-27618: glibc: iconv when processing invalid multi-byte input sequences fails to advance the input state, which could result in an infinite loopThe iconv function in the GNU C Library (aka glibc or libc6) 2.32 and earlier, when processing invalid multi-byte input sequences in IBM1364, IBM1371, IBM1388, IBM1390, and IBM1399 encodings, fails to advance the input state, which could lead to an infinite loop in applications, resulting in a denial of service, a different vulnerability from CVE-2016-10228.Package Name: libc6 Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org linux.oracle.com linux.oracle.com security.netapp.com sourceware.org sourceware.org |
|
LOW |
CVE-2020-29562: glibc: assertion failure in iconv when converting invalid UCS4The iconv function in the GNU C Library (aka glibc or libc6) 2.30 to 2.32, when converting UCS4 text containing an irreversible character, fails an assertion in the code path and aborts the program, potentially resulting in a denial of service.Package Name: libc6 Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org lists.apache.org lists.fedoraproject.org security.gentoo.org security.netapp.com sourceware.org sourceware.org |
|
LOW |
CVE-2020-6096: glibc: signed comparison vulnerability in the ARMv7 memcpy functionAn exploitable signed comparison vulnerability exists in the ARMv7 memcpy() implementation of GNU glibc 2.30.9000. Calling memcpy() (on ARMv7 targets that utilize the GNU glibc implementation) with a negative value for the 'num' parameter results in a signed comparison vulnerability. If an attacker underflows the 'num' parameter to memcpy(), this vulnerability could lead to undefined behavior such as writing to out-of-bounds memory and potentially remote code execution. Furthermore, this memcpy() implementation allows for program execution to continue in scenarios where a segmentation fault or crash should have occurred. The dangers occur in that subsequent execution and iterations of this code will be executed with this corrupted data.Package Name: libc6 Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org lists.apache.org lists.fedoraproject.org lists.fedoraproject.org security.gentoo.org sourceware.org sourceware.org talosintelligence.com ubuntu.com www.talosintelligence.com |
|
LOW |
CVE-2021-27645: glibc: Use-after-free in addgetnetgrentX function in netgroupcache.cThe nameserver caching daemon (nscd) in the GNU C Library (aka glibc or libc6) 2.29 through 2.33, when processing a request for netgroup lookup, may crash due to a double-free, potentially resulting in degraded service or Denial of Service on the local system. This is related to netgroupcache.c.Package Name: libc6 Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org linux.oracle.com linux.oracle.com lists.fedoraproject.org lists.fedoraproject.org sourceware.org |
|
LOW |
CVE-2021-3326: glibc: Assertion failure in ISO-2022-JP-3 gconv module related to combining charactersThe iconv function in the GNU C Library (aka glibc or libc6) 2.32 and earlier, when processing invalid input sequences in the ISO-2022-JP-3 encoding, fails an assertion in the code path and aborts the program, potentially resulting in a denial of service.Package Name: libc6 Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: www.openwall.com bugs.chromium.org cve.mitre.org linux.oracle.com linux.oracle.com security.netapp.com sourceware.org sourceware.org sourceware.org |
|
LOW |
CVE-2021-33574: glibc: mq_notify does not handle separately allocated thread attributesThe mq_notify function in the GNU C Library (aka glibc) versions 2.32 and 2.33 has a use-after-free. It may use the notification thread attributes object (passed through its struct sigevent parameter) after it has been freed by the caller, leading to a denial of service (application crash) or possibly unspecified other impact.Package Name: libc6 Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org linux.oracle.com linux.oracle.com lists.fedoraproject.org security.gentoo.org security.netapp.com sourceware.org sourceware.org |
|
LOW |
CVE-2021-35942: glibc: Arbitrary read in wordexp()The wordexp function in the GNU C Library (aka glibc) through 2.33 may crash or read arbitrary memory in parse_param (in posix/wordexp.c) when called with an untrusted, crafted pattern, potentially resulting in a denial of service or disclosure of information. This occurs because atoi was used but strtoul should have been used to ensure correct calculations.Package Name: libc6 Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org linux.oracle.com linux.oracle.com security.netapp.com sourceware.org sourceware.org sourceware.org |
|
LOW |
CVE-2016-10228: glibc: iconv program can hang when invoked with the -c optionThe iconv program in the GNU C Library (aka glibc or libc6) 2.31 and earlier, when invoked with multiple suffixes in the destination encoding (TRANSLATE or IGNORE) along with the -c option, enters an infinite loop when processing invalid multi-byte input sequences, leading to a denial of service.Package Name: libc6-dev Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: openwall.com www.securityfocus.com cve.mitre.org linux.oracle.com linux.oracle.com lists.apache.org security.gentoo.org sourceware.org sourceware.org sourceware.org |
|
LOW |
CVE-2019-25013: glibc: buffer over-read in iconv when processing invalid multi-byte input sequences in the EUC-KR encodingThe iconv feature in the GNU C Library (aka glibc or libc6) through 2.32, when processing invalid multi-byte input sequences in the EUC-KR encoding, may have a buffer over-read.Package Name: libc6-dev Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org linux.oracle.com linux.oracle.com lists.apache.org lists.apache.org lists.apache.org lists.apache.org lists.apache.org lists.apache.org lists.apache.org lists.apache.org lists.apache.org lists.fedoraproject.org lists.fedoraproject.org security.netapp.com sourceware.org sourceware.org |
|
LOW |
CVE-2020-27618: glibc: iconv when processing invalid multi-byte input sequences fails to advance the input state, which could result in an infinite loopThe iconv function in the GNU C Library (aka glibc or libc6) 2.32 and earlier, when processing invalid multi-byte input sequences in IBM1364, IBM1371, IBM1388, IBM1390, and IBM1399 encodings, fails to advance the input state, which could lead to an infinite loop in applications, resulting in a denial of service, a different vulnerability from CVE-2016-10228.Package Name: libc6-dev Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org linux.oracle.com linux.oracle.com security.netapp.com sourceware.org sourceware.org |
|
LOW |
CVE-2020-29562: glibc: assertion failure in iconv when converting invalid UCS4The iconv function in the GNU C Library (aka glibc or libc6) 2.30 to 2.32, when converting UCS4 text containing an irreversible character, fails an assertion in the code path and aborts the program, potentially resulting in a denial of service.Package Name: libc6-dev Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org lists.apache.org lists.fedoraproject.org security.gentoo.org security.netapp.com sourceware.org sourceware.org |
|
LOW |
CVE-2020-6096: glibc: signed comparison vulnerability in the ARMv7 memcpy functionAn exploitable signed comparison vulnerability exists in the ARMv7 memcpy() implementation of GNU glibc 2.30.9000. Calling memcpy() (on ARMv7 targets that utilize the GNU glibc implementation) with a negative value for the 'num' parameter results in a signed comparison vulnerability. If an attacker underflows the 'num' parameter to memcpy(), this vulnerability could lead to undefined behavior such as writing to out-of-bounds memory and potentially remote code execution. Furthermore, this memcpy() implementation allows for program execution to continue in scenarios where a segmentation fault or crash should have occurred. The dangers occur in that subsequent execution and iterations of this code will be executed with this corrupted data.Package Name: libc6-dev Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org lists.apache.org lists.fedoraproject.org lists.fedoraproject.org security.gentoo.org sourceware.org sourceware.org talosintelligence.com ubuntu.com www.talosintelligence.com |
|
LOW |
CVE-2021-27645: glibc: Use-after-free in addgetnetgrentX function in netgroupcache.cThe nameserver caching daemon (nscd) in the GNU C Library (aka glibc or libc6) 2.29 through 2.33, when processing a request for netgroup lookup, may crash due to a double-free, potentially resulting in degraded service or Denial of Service on the local system. This is related to netgroupcache.c.Package Name: libc6-dev Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org linux.oracle.com linux.oracle.com lists.fedoraproject.org lists.fedoraproject.org sourceware.org |
|
LOW |
CVE-2021-3326: glibc: Assertion failure in ISO-2022-JP-3 gconv module related to combining charactersThe iconv function in the GNU C Library (aka glibc or libc6) 2.32 and earlier, when processing invalid input sequences in the ISO-2022-JP-3 encoding, fails an assertion in the code path and aborts the program, potentially resulting in a denial of service.Package Name: libc6-dev Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: www.openwall.com bugs.chromium.org cve.mitre.org linux.oracle.com linux.oracle.com security.netapp.com sourceware.org sourceware.org sourceware.org |
|
LOW |
CVE-2021-33574: glibc: mq_notify does not handle separately allocated thread attributesThe mq_notify function in the GNU C Library (aka glibc) versions 2.32 and 2.33 has a use-after-free. It may use the notification thread attributes object (passed through its struct sigevent parameter) after it has been freed by the caller, leading to a denial of service (application crash) or possibly unspecified other impact.Package Name: libc6-dev Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org linux.oracle.com linux.oracle.com lists.fedoraproject.org security.gentoo.org security.netapp.com sourceware.org sourceware.org |
|
LOW |
CVE-2021-35942: glibc: Arbitrary read in wordexp()The wordexp function in the GNU C Library (aka glibc) through 2.33 may crash or read arbitrary memory in parse_param (in posix/wordexp.c) when called with an untrusted, crafted pattern, potentially resulting in a denial of service or disclosure of information. This occurs because atoi was used but strtoul should have been used to ensure correct calculations.Package Name: libc6-dev Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org linux.oracle.com linux.oracle.com security.netapp.com sourceware.org sourceware.org sourceware.org |
|
LOW |
CVE-2017-13716: binutils: Memory leak with the C++ symbol demangler routine in libibertyThe C++ symbol demangler routine in cplus-dem.c in libiberty, as distributed in GNU Binutils 2.29, allows remote attackers to cause a denial of service (excessive memory allocation and application crash) via a crafted file, as demonstrated by a call from the Binary File Descriptor (BFD) library (aka libbfd).Package Name: libctf-nobfd0 Installed Version: 2.34-6ubuntu1.3 Fixed Version: References: cve.mitre.org sourceware.org |
|
LOW |
CVE-2018-20657: libiberty: Memory leak in demangle_template function resulting in a denial of serviceThe demangle_template function in cplus-dem.c in GNU libiberty, as distributed in GNU Binutils 2.31.1, has a memory leak via a crafted string, leading to a denial of service (memory consumption), as demonstrated by cxxfilt, a related issue to CVE-2018-12698.Package Name: libctf-nobfd0 Installed Version: 2.34-6ubuntu1.3 Fixed Version: References: www.securityfocus.com access.redhat.com cve.mitre.org gcc.gnu.org linux.oracle.com linux.oracle.com support.f5.com |
|
LOW |
CVE-2019-1010204: binutils: Improper Input Validation, Signed/Unsigned Comparison, Out-of-bounds Read in gold/fileread.cc and elfcpp/elfcpp_file.h leads to denial of serviceGNU binutils gold gold v1.11-v1.16 (GNU binutils v2.21-v2.31.1) is affected by: Improper Input Validation, Signed/Unsigned Comparison, Out-of-bounds Read. The impact is: Denial of service. The component is: gold/fileread.cc:497, elfcpp/elfcpp_file.h:644. The attack vector is: An ELF file with an invalid e_shoff header field must be opened.Package Name: libctf-nobfd0 Installed Version: 2.34-6ubuntu1.3 Fixed Version: References: cve.mitre.org linux.oracle.com linux.oracle.com security.netapp.com sourceware.org support.f5.com |
|
LOW |
CVE-2017-13716: binutils: Memory leak with the C++ symbol demangler routine in libibertyThe C++ symbol demangler routine in cplus-dem.c in libiberty, as distributed in GNU Binutils 2.29, allows remote attackers to cause a denial of service (excessive memory allocation and application crash) via a crafted file, as demonstrated by a call from the Binary File Descriptor (BFD) library (aka libbfd).Package Name: libctf0 Installed Version: 2.34-6ubuntu1.3 Fixed Version: References: cve.mitre.org sourceware.org |
|
LOW |
CVE-2018-20657: libiberty: Memory leak in demangle_template function resulting in a denial of serviceThe demangle_template function in cplus-dem.c in GNU libiberty, as distributed in GNU Binutils 2.31.1, has a memory leak via a crafted string, leading to a denial of service (memory consumption), as demonstrated by cxxfilt, a related issue to CVE-2018-12698.Package Name: libctf0 Installed Version: 2.34-6ubuntu1.3 Fixed Version: References: www.securityfocus.com access.redhat.com cve.mitre.org gcc.gnu.org linux.oracle.com linux.oracle.com support.f5.com |
|
LOW |
CVE-2019-1010204: binutils: Improper Input Validation, Signed/Unsigned Comparison, Out-of-bounds Read in gold/fileread.cc and elfcpp/elfcpp_file.h leads to denial of serviceGNU binutils gold gold v1.11-v1.16 (GNU binutils v2.21-v2.31.1) is affected by: Improper Input Validation, Signed/Unsigned Comparison, Out-of-bounds Read. The impact is: Denial of service. The component is: gold/fileread.cc:497, elfcpp/elfcpp_file.h:644. The attack vector is: An ELF file with an invalid e_shoff header field must be opened.Package Name: libctf0 Installed Version: 2.34-6ubuntu1.3 Fixed Version: References: cve.mitre.org linux.oracle.com linux.oracle.com security.netapp.com sourceware.org support.f5.com |
|
LOW |
CVE-2020-35512: dbus: users with the same numeric UID could lead to use-after-free and undefined behaviourA use-after-free flaw was found in D-Bus Development branch <= 1.13.16, dbus-1.12.x stable branch <= 1.12.18, and dbus-1.10.x and older branches <= 1.10.30 when a system has multiple usernames sharing the same UID. When a set of policy rules references these usernames, D-Bus may free some memory in the heap, which is still used by data structures necessary for the other usernames sharing the UID, possibly leading to a crash or other undefined behaviorsPackage Name: libdbus-1-3 Installed Version: 1.12.16-2ubuntu2.1 Fixed Version: References: bugs.gentoo.org bugzilla.redhat.com cve.mitre.org gitlab.freedesktop.org gitlab.freedesktop.org gitlab.freedesktop.org gitlab.freedesktop.org gitlab.freedesktop.org security-tracker.debian.org ubuntu.com |
|
LOW |
CVE-2021-43618: gmp: Integer overflow and resultant buffer overflow via crafted inputGNU Multiple Precision Arithmetic Library (GMP) through 6.2.1 has an mpz/inp_raw.c integer overflow and resultant buffer overflow via crafted input, leading to a segmentation fault on 32-bit platforms.Package Name: libgmp-dev Installed Version: 2:6.2.0+dfsg-4 Fixed Version: References: bugs.debian.org cve.mitre.org gmplib.org gmplib.org lists.debian.org |
|
LOW |
CVE-2021-43618: gmp: Integer overflow and resultant buffer overflow via crafted inputGNU Multiple Precision Arithmetic Library (GMP) through 6.2.1 has an mpz/inp_raw.c integer overflow and resultant buffer overflow via crafted input, leading to a segmentation fault on 32-bit platforms.Package Name: libgmp10 Installed Version: 2:6.2.0+dfsg-4 Fixed Version: References: bugs.debian.org cve.mitre.org gmplib.org gmplib.org lists.debian.org |
|
LOW |
CVE-2021-43618: gmp: Integer overflow and resultant buffer overflow via crafted inputGNU Multiple Precision Arithmetic Library (GMP) through 6.2.1 has an mpz/inp_raw.c integer overflow and resultant buffer overflow via crafted input, leading to a segmentation fault on 32-bit platforms.Package Name: libgmpxx4ldbl Installed Version: 2:6.2.0+dfsg-4 Fixed Version: References: bugs.debian.org cve.mitre.org gmplib.org gmplib.org lists.debian.org |
|
LOW |
CVE-2018-5709: krb5: integer overflow in dbentry->n_key_data in kadmin/dbutil/dump.cAn issue was discovered in MIT Kerberos 5 (aka krb5) through 1.16. There is a variable "dbentry->n_key_data" in kadmin/dbutil/dump.c that can store 16-bit data but unknowingly the developer has assigned a "u4" variable to it, which is for 32-bit data. An attacker can use this vulnerability to affect other artifacts of the database as we know that a Kerberos database dump file contains trusted data.Package Name: libgssapi-krb5-2 Installed Version: 1.17-6ubuntu4.1 Fixed Version: References: cve.mitre.org github.com lists.apache.org |
|
LOW |
CVE-2021-3671: samba: Null pointer dereference on missing sname in TGS-REQA null pointer de-reference was found in the way samba kerberos server handled missing sname in TGS-REQ (Ticket Granting Server - Request). An authenticated user could use this flaw to crash the samba server.Package Name: libgssapi3-heimdal Installed Version: 7.7.0+dfsg-1ubuntu1 Fixed Version: References: bugzilla.redhat.com bugzilla.samba.org cve.mitre.org github.com ubuntu.com ubuntu.com |
|
LOW |
CVE-2021-3671: samba: Null pointer dereference on missing sname in TGS-REQA null pointer de-reference was found in the way samba kerberos server handled missing sname in TGS-REQ (Ticket Granting Server - Request). An authenticated user could use this flaw to crash the samba server.Package Name: libhcrypto4-heimdal Installed Version: 7.7.0+dfsg-1ubuntu1 Fixed Version: References: bugzilla.redhat.com bugzilla.samba.org cve.mitre.org github.com ubuntu.com ubuntu.com |
|
LOW |
CVE-2021-3671: samba: Null pointer dereference on missing sname in TGS-REQA null pointer de-reference was found in the way samba kerberos server handled missing sname in TGS-REQ (Ticket Granting Server - Request). An authenticated user could use this flaw to crash the samba server.Package Name: libheimbase1-heimdal Installed Version: 7.7.0+dfsg-1ubuntu1 Fixed Version: References: bugzilla.redhat.com bugzilla.samba.org cve.mitre.org github.com ubuntu.com ubuntu.com |
|
LOW |
CVE-2021-3671: samba: Null pointer dereference on missing sname in TGS-REQA null pointer de-reference was found in the way samba kerberos server handled missing sname in TGS-REQ (Ticket Granting Server - Request). An authenticated user could use this flaw to crash the samba server.Package Name: libheimntlm0-heimdal Installed Version: 7.7.0+dfsg-1ubuntu1 Fixed Version: References: bugzilla.redhat.com bugzilla.samba.org cve.mitre.org github.com ubuntu.com ubuntu.com |
|
LOW |
CVE-2021-3671: samba: Null pointer dereference on missing sname in TGS-REQA null pointer de-reference was found in the way samba kerberos server handled missing sname in TGS-REQ (Ticket Granting Server - Request). An authenticated user could use this flaw to crash the samba server.Package Name: libhx509-5-heimdal Installed Version: 7.7.0+dfsg-1ubuntu1 Fixed Version: References: bugzilla.redhat.com bugzilla.samba.org cve.mitre.org github.com ubuntu.com ubuntu.com |
|
LOW |
CVE-2018-5709: krb5: integer overflow in dbentry->n_key_data in kadmin/dbutil/dump.cAn issue was discovered in MIT Kerberos 5 (aka krb5) through 1.16. There is a variable "dbentry->n_key_data" in kadmin/dbutil/dump.c that can store 16-bit data but unknowingly the developer has assigned a "u4" variable to it, which is for 32-bit data. An attacker can use this vulnerability to affect other artifacts of the database as we know that a Kerberos database dump file contains trusted data.Package Name: libk5crypto3 Installed Version: 1.17-6ubuntu4.1 Fixed Version: References: cve.mitre.org github.com lists.apache.org |
|
LOW |
CVE-2021-3671: samba: Null pointer dereference on missing sname in TGS-REQA null pointer de-reference was found in the way samba kerberos server handled missing sname in TGS-REQ (Ticket Granting Server - Request). An authenticated user could use this flaw to crash the samba server.Package Name: libkrb5-26-heimdal Installed Version: 7.7.0+dfsg-1ubuntu1 Fixed Version: References: bugzilla.redhat.com bugzilla.samba.org cve.mitre.org github.com ubuntu.com ubuntu.com |
|
LOW |
CVE-2018-5709: krb5: integer overflow in dbentry->n_key_data in kadmin/dbutil/dump.cAn issue was discovered in MIT Kerberos 5 (aka krb5) through 1.16. There is a variable "dbentry->n_key_data" in kadmin/dbutil/dump.c that can store 16-bit data but unknowingly the developer has assigned a "u4" variable to it, which is for 32-bit data. An attacker can use this vulnerability to affect other artifacts of the database as we know that a Kerberos database dump file contains trusted data.Package Name: libkrb5-3 Installed Version: 1.17-6ubuntu4.1 Fixed Version: References: cve.mitre.org github.com lists.apache.org |
|
LOW |
CVE-2018-5709: krb5: integer overflow in dbentry->n_key_data in kadmin/dbutil/dump.cAn issue was discovered in MIT Kerberos 5 (aka krb5) through 1.16. There is a variable "dbentry->n_key_data" in kadmin/dbutil/dump.c that can store 16-bit data but unknowingly the developer has assigned a "u4" variable to it, which is for 32-bit data. An attacker can use this vulnerability to affect other artifacts of the database as we know that a Kerberos database dump file contains trusted data.Package Name: libkrb5support0 Installed Version: 1.17-6ubuntu4.1 Fixed Version: References: cve.mitre.org github.com lists.apache.org |
|
LOW |
CVE-2017-11164: pcre: OP_KETRMAX feature in the match function in pcre_exec.cIn PCRE 8.41, the OP_KETRMAX feature in the match function in pcre_exec.c allows stack exhaustion (uncontrolled recursion) when processing a crafted regular expression.Package Name: libpcre3 Installed Version: 2:8.39-12build1 Fixed Version: References: openwall.com www.securityfocus.com cve.mitre.org lists.apache.org |
|
LOW |
CVE-2019-20838: pcre: Buffer over-read in JIT when UTF is disabled and \X or \R has fixed quantifier greater than 1libpcre in PCRE before 8.43 allows a subject buffer over-read in JIT when UTF is disabled, and \X or \R has more than one fixed quantifier, a related issue to CVE-2019-20454.Package Name: libpcre3 Installed Version: 2:8.39-12build1 Fixed Version: References: seclists.org seclists.org bugs.gentoo.org cve.mitre.org linux.oracle.com linux.oracle.com lists.apache.org support.apple.com support.apple.com www.pcre.org |
|
LOW |
CVE-2020-14155: pcre: Integer overflow when parsing callout numeric argumentslibpcre in PCRE before 8.44 allows an integer overflow via a large number after a (?C substring.Package Name: libpcre3 Installed Version: 2:8.39-12build1 Fixed Version: References: seclists.org seclists.org about.gitlab.com bugs.gentoo.org cve.mitre.org linux.oracle.com linux.oracle.com lists.apache.org support.apple.com support.apple.com www.pcre.org |
|
LOW |
CVE-2016-2568: polkit: Program run via pkexec as unprivileged user can escape to parent session via TIOCSTI ioctlpkexec, when used with --user nonpriv, allows local users to escape to the parent session via a crafted TIOCSTI ioctl call, which pushes characters to the terminal's input buffer.Package Name: libpolkit-agent-1-0 Installed Version: 0.105-26ubuntu1.1 Fixed Version: References: seclists.org www.openwall.com access.redhat.com bugs.debian.org bugzilla.redhat.com cve.mitre.org lore.kernel.org ubuntu.com |
|
LOW |
CVE-2016-2568: polkit: Program run via pkexec as unprivileged user can escape to parent session via TIOCSTI ioctlpkexec, when used with --user nonpriv, allows local users to escape to the parent session via a crafted TIOCSTI ioctl call, which pushes characters to the terminal's input buffer.Package Name: libpolkit-gobject-1-0 Installed Version: 0.105-26ubuntu1.1 Fixed Version: References: seclists.org www.openwall.com access.redhat.com bugs.debian.org bugzilla.redhat.com cve.mitre.org lore.kernel.org ubuntu.com |
|
LOW |
CVE-2021-23336: python: Web cache poisoning via urllib.parse.parse_qsl and urllib.parse.parse_qs by using a semicolon in query parametersThe package python/cpython from 0 and before 3.6.13, from 3.7.0 and before 3.7.10, from 3.8.0 and before 3.8.8, from 3.9.0 and before 3.9.2 are vulnerable to Web Cache Poisoning via urllib.parse.parse_qsl and urllib.parse.parse_qs by using a vector called parameter cloaking. When the attacker can separate query parameters using a semicolon (;), they can cause a difference in the interpretation of the request between the proxy (running with default configuration) and the server. This can result in malicious requests being cached as completely safe ones, as the proxy would usually not see the semicolon as a separator, and therefore would not include it in a cache key of an unkeyed parameter.Package Name: libpython3.8-minimal Installed Version: 3.8.10-0ubuntu1~20.04.2 Fixed Version: References: www.openwall.com www.openwall.com cve.mitre.org github.com github.com linux.oracle.com linux.oracle.com lists.apache.org lists.apache.org lists.apache.org lists.debian.org lists.debian.org lists.debian.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org security.gentoo.org security.netapp.com snyk.io snyk.io ubuntu.com www.djangoproject.com www.oracle.com www.oracle.com www.oracle.com |
|
LOW |
CVE-2021-23336: python: Web cache poisoning via urllib.parse.parse_qsl and urllib.parse.parse_qs by using a semicolon in query parametersThe package python/cpython from 0 and before 3.6.13, from 3.7.0 and before 3.7.10, from 3.8.0 and before 3.8.8, from 3.9.0 and before 3.9.2 are vulnerable to Web Cache Poisoning via urllib.parse.parse_qsl and urllib.parse.parse_qs by using a vector called parameter cloaking. When the attacker can separate query parameters using a semicolon (;), they can cause a difference in the interpretation of the request between the proxy (running with default configuration) and the server. This can result in malicious requests being cached as completely safe ones, as the proxy would usually not see the semicolon as a separator, and therefore would not include it in a cache key of an unkeyed parameter.Package Name: libpython3.8-stdlib Installed Version: 3.8.10-0ubuntu1~20.04.2 Fixed Version: References: www.openwall.com www.openwall.com cve.mitre.org github.com github.com linux.oracle.com linux.oracle.com lists.apache.org lists.apache.org lists.apache.org lists.debian.org lists.debian.org lists.debian.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org security.gentoo.org security.netapp.com snyk.io snyk.io ubuntu.com www.djangoproject.com www.oracle.com www.oracle.com www.oracle.com |
|
LOW |
CVE-2021-3671: samba: Null pointer dereference on missing sname in TGS-REQA null pointer de-reference was found in the way samba kerberos server handled missing sname in TGS-REQ (Ticket Granting Server - Request). An authenticated user could use this flaw to crash the samba server.Package Name: libroken18-heimdal Installed Version: 7.7.0+dfsg-1ubuntu1 Fixed Version: References: bugzilla.redhat.com bugzilla.samba.org cve.mitre.org github.com ubuntu.com ubuntu.com |
|
LOW |
CVE-2020-9849An information disclosure issue was addressed with improved state management. This issue is fixed in macOS Big Sur 11.0.1, watchOS 7.0, iOS 14.0 and iPadOS 14.0, iTunes for Windows 12.10.9, iCloud for Windows 11.5, tvOS 14.0. A remote attacker may be able to leak memory.Package Name: libsqlite3-0 Installed Version: 3.31.1-4ubuntu0.2 Fixed Version: References: seclists.org cve.mitre.org lists.apache.org support.apple.com support.apple.com support.apple.com support.apple.com support.apple.com support.apple.com www.rapid7.com |
|
LOW |
CVE-2020-9991This issue was addressed with improved checks. This issue is fixed in macOS Big Sur 11.0.1, watchOS 7.0, iOS 14.0 and iPadOS 14.0, iCloud for Windows 7.21, tvOS 14.0. A remote attacker may be able to cause a denial of service.Package Name: libsqlite3-0 Installed Version: 3.31.1-4ubuntu0.2 Fixed Version: References: seclists.org cve.mitre.org lists.apache.org support.apple.com support.apple.com support.apple.com support.apple.com support.apple.com support.apple.com www.rapid7.com |
|
LOW |
CVE-2020-9849An information disclosure issue was addressed with improved state management. This issue is fixed in macOS Big Sur 11.0.1, watchOS 7.0, iOS 14.0 and iPadOS 14.0, iTunes for Windows 12.10.9, iCloud for Windows 11.5, tvOS 14.0. A remote attacker may be able to leak memory.Package Name: libsqlite3-dev Installed Version: 3.31.1-4ubuntu0.2 Fixed Version: References: seclists.org cve.mitre.org lists.apache.org support.apple.com support.apple.com support.apple.com support.apple.com support.apple.com support.apple.com www.rapid7.com |
|
LOW |
CVE-2020-9991This issue was addressed with improved checks. This issue is fixed in macOS Big Sur 11.0.1, watchOS 7.0, iOS 14.0 and iPadOS 14.0, iCloud for Windows 7.21, tvOS 14.0. A remote attacker may be able to cause a denial of service.Package Name: libsqlite3-dev Installed Version: 3.31.1-4ubuntu0.2 Fixed Version: References: seclists.org cve.mitre.org lists.apache.org support.apple.com support.apple.com support.apple.com support.apple.com support.apple.com support.apple.com www.rapid7.com |
|
LOW |
CVE-2018-1000654: libtasn1: Infinite loop in _asn1_expand_object_id(ptree) leads to memory exhaustionGNU Libtasn1-4.13 libtasn1-4.13 version libtasn1-4.13, libtasn1-4.12 contains a DoS, specifically CPU usage will reach 100% when running asn1Paser against the POC due to an issue in _asn1_expand_object_id(p_tree), after a long time, the program will be killed. This attack appears to be exploitable via parsing a crafted file.Package Name: libtasn1-6 Installed Version: 4.16.0-2 Fixed Version: References: lists.opensuse.org lists.opensuse.org www.securityfocus.com cve.mitre.org gitlab.com lists.apache.org |
|
LOW |
CVE-2018-1000654: libtasn1: Infinite loop in _asn1_expand_object_id(ptree) leads to memory exhaustionGNU Libtasn1-4.13 libtasn1-4.13 version libtasn1-4.13, libtasn1-4.12 contains a DoS, specifically CPU usage will reach 100% when running asn1Paser against the POC due to an issue in _asn1_expand_object_id(p_tree), after a long time, the program will be killed. This attack appears to be exploitable via parsing a crafted file.Package Name: libtasn1-6-dev Installed Version: 4.16.0-2 Fixed Version: References: lists.opensuse.org lists.opensuse.org www.securityfocus.com cve.mitre.org gitlab.com lists.apache.org |
|
LOW |
CVE-2018-1000654: libtasn1: Infinite loop in _asn1_expand_object_id(ptree) leads to memory exhaustionGNU Libtasn1-4.13 libtasn1-4.13 version libtasn1-4.13, libtasn1-4.12 contains a DoS, specifically CPU usage will reach 100% when running asn1Paser against the POC due to an issue in _asn1_expand_object_id(p_tree), after a long time, the program will be killed. This attack appears to be exploitable via parsing a crafted file.Package Name: libtasn1-doc Installed Version: 4.16.0-2 Fixed Version: References: lists.opensuse.org lists.opensuse.org www.securityfocus.com cve.mitre.org gitlab.com lists.apache.org |
|
LOW |
CVE-2021-3671: samba: Null pointer dereference on missing sname in TGS-REQA null pointer de-reference was found in the way samba kerberos server handled missing sname in TGS-REQ (Ticket Granting Server - Request). An authenticated user could use this flaw to crash the samba server.Package Name: libwind0-heimdal Installed Version: 7.7.0+dfsg-1ubuntu1 Fixed Version: References: bugzilla.redhat.com bugzilla.samba.org cve.mitre.org github.com ubuntu.com ubuntu.com |
|
LOW |
CVE-2017-0537An information disclosure vulnerability in the kernel USB gadget driver could enable a local malicious application to access data outside of its permission levels. This issue is rated as Moderate because it first requires compromising a privileged process. Product: Android. Versions: Kernel-3.18. Android ID: A-31614969.Package Name: linux-libc-dev Installed Version: 5.4.0-92.103 Fixed Version: References: www.securityfocus.com www.securitytracker.com android.googlesource.com cve.mitre.org lore.kernel.org source.android.com source.android.com source.android.com |
|
LOW |
CVE-2017-13165An elevation of privilege vulnerability in the kernel file system. Product: Android. Versions: Android kernel. Android ID A-31269937.Package Name: linux-libc-dev Installed Version: 5.4.0-92.103 Fixed Version: References: cve.mitre.org github.com source.android.com |
|
LOW |
CVE-2017-13693: kernel: ACPI operand cache leak in dsutils.cThe acpi_ds_create_operands() function in drivers/acpi/acpica/dsutils.c in the Linux kernel through 4.12.9 does not flush the operand cache and causes a kernel stack dump, which allows local users to obtain sensitive information from kernel memory and bypass the KASLR protection mechanism (in the kernel through 4.9) via a crafted ACPI table.Package Name: linux-libc-dev Installed Version: 5.4.0-92.103 Fixed Version: References: www.securityfocus.com cve.mitre.org github.com patchwork.kernel.org |
|
LOW |
CVE-2018-1121: procps-ng, procps: process hiding through race condition enumerating /procprocps-ng, procps is vulnerable to a process hiding through race condition. Since the kernel's proc_pid_readdir() returns PID entries in ascending numeric order, a process occupying a high PID can use inotify events to determine when the process list is being scanned, and fork/exec to obtain a lower PID, thus avoiding enumeration. An unprivileged attacker can hide a process from procps-ng's utilities by exploiting a race condition in reading /proc/PID entries. This vulnerability affects procps and procps-ng up to version 3.3.15, newer versions might be affected also.Package Name: linux-libc-dev Installed Version: 5.4.0-92.103 Fixed Version: References: seclists.org www.securityfocus.com bugzilla.redhat.com cve.mitre.org www.exploit-db.com www.qualys.com |
|
LOW |
CVE-2018-12928: kernel: NULL pointer dereference in hfs_ext_read_extent in hfs.koIn the Linux kernel 4.15.0, a NULL pointer dereference was discovered in hfs_ext_read_extent in hfs.ko. This can occur during a mount of a crafted hfs filesystem.Package Name: linux-libc-dev Installed Version: 5.4.0-92.103 Fixed Version: References: www.securityfocus.com bugs.launchpad.net cve.mitre.org groups.google.com lore.kernel.org marc.info |
|
LOW |
CVE-2018-12929: kernel: use-after-free in ntfs_read_locked_inode in the ntfs.kontfs_read_locked_inode in the ntfs.ko filesystem driver in the Linux kernel 4.15.0 allows attackers to trigger a use-after-free read and possibly cause a denial of service (kernel oops or panic) via a crafted ntfs filesystem.Package Name: linux-libc-dev Installed Version: 5.4.0-92.103 Fixed Version: References: www.securityfocus.com access.redhat.com bugs.launchpad.net cve.mitre.org marc.info |
|
LOW |
CVE-2018-12930: kernel: stack-based out-of-bounds write in ntfs_end_buffer_async_read in the ntfs.kontfs_end_buffer_async_read in the ntfs.ko filesystem driver in the Linux kernel 4.15.0 allows attackers to trigger a stack-based out-of-bounds write and cause a denial of service (kernel oops or panic) or possibly have unspecified other impact via a crafted ntfs filesystem.Package Name: linux-libc-dev Installed Version: 5.4.0-92.103 Fixed Version: References: www.securityfocus.com access.redhat.com bugs.launchpad.net cve.mitre.org marc.info |
|
LOW |
CVE-2018-12931: kernel: stack-based out-of-bounds write in ntfs_attr_find in the ntfs.kontfs_attr_find in the ntfs.ko filesystem driver in the Linux kernel 4.15.0 allows attackers to trigger a stack-based out-of-bounds write and cause a denial of service (kernel oops or panic) or possibly have unspecified other impact via a crafted ntfs filesystem.Package Name: linux-libc-dev Installed Version: 5.4.0-92.103 Fixed Version: References: www.securityfocus.com access.redhat.com bugs.launchpad.net cve.mitre.org marc.info |
|
LOW |
CVE-2019-14899: VPN: an attacker can inject data into the TCP stream which allows a hijack of active connections inside the VPN tunnelA vulnerability was discovered in Linux, FreeBSD, OpenBSD, MacOS, iOS, and Android that allows a malicious access point, or an adjacent user, to determine if a connected user is using a VPN, make positive inferences about the websites they are visiting, and determine the correct sequence and acknowledgement numbers in use, allowing the bad actor to inject data into the TCP stream. This provides everything that is needed for an attacker to hijack active connections inside the VPN tunnel.Package Name: linux-libc-dev Installed Version: 5.4.0-92.103 Fixed Version: References: seclists.org seclists.org seclists.org seclists.org seclists.org www.openwall.com www.openwall.com bugzilla.redhat.com cve.mitre.org openvpn.net support.apple.com support.apple.com support.apple.com support.apple.com support.apple.com www.openwall.com |
|
LOW |
CVE-2019-15213: kernel: use-after-free caused by malicious USB device in drivers/media/usb/dvb-usb/dvb-usb-init.cAn issue was discovered in the Linux kernel before 5.2.3. There is a use-after-free caused by a malicious USB device in the drivers/media/usb/dvb-usb/dvb-usb-init.c driver.Package Name: linux-libc-dev Installed Version: 5.4.0-92.103 Fixed Version: References: lists.opensuse.org www.openwall.com cdn.kernel.org cve.mitre.org git.kernel.org linux.oracle.com linux.oracle.com lore.kernel.org security.netapp.com syzkaller.appspot.com |
|
LOW |
CVE-2019-16230: kernel: null pointer dereference in drivers/gpu/drm/radeon/radeon_display.c** DISPUTED ** drivers/gpu/drm/radeon/radeon_display.c in the Linux kernel 5.2.14 does not check the alloc_workqueue return value, leading to a NULL pointer dereference. NOTE: A third-party software maintainer states that the work queue allocation is happening during device initialization, which for a graphics card occurs during boot. It is not attacker controllable and OOM at that time is highly unlikely.Package Name: linux-libc-dev Installed Version: 5.4.0-92.103 Fixed Version: References: bugzilla.suse.com cve.mitre.org lkml.org security.netapp.com |
|
LOW |
CVE-2019-19378: kernel: out-of-bounds write in index_rbio_pages in fs/btrfs/raid56.cIn the Linux kernel 5.0.21, mounting a crafted btrfs filesystem image can lead to slab-out-of-bounds write access in index_rbio_pages in fs/btrfs/raid56.c.Package Name: linux-libc-dev Installed Version: 5.4.0-92.103 Fixed Version: References: cve.mitre.org github.com security.netapp.com |
|
LOW |
CVE-2019-19814: kernel: out-of-bounds write in __remove_dirty_segment in fs/f2fs/segment.cIn the Linux kernel 5.0.21, mounting a crafted f2fs filesystem image can cause __remove_dirty_segment slab-out-of-bounds write access because an array is bounded by the number of dirty types (8) but the array index can exceed this.Package Name: linux-libc-dev Installed Version: 5.4.0-92.103 Fixed Version: References: cve.mitre.org github.com security.netapp.com |
|
LOW |
CVE-2020-11725: kernel: improper handling of private_size*count multiplication due to count=info->owner typo** DISPUTED ** snd_ctl_elem_add in sound/core/control.c in the Linux kernel through 5.6.3 has a count=info->owner line, which later affects a private_size*count multiplication for unspecified "interesting side effects." NOTE: kernel engineers dispute this finding, because it could be relevant only if new callers were added that were unfamiliar with the misuse of the info->owner field to represent data unrelated to the "owner" concept. The existing callers, SNDRV_CTL_IOCTL_ELEM_ADD and SNDRV_CTL_IOCTL_ELEM_REPLACE, have been designed to misuse the info->owner field in a safe way.Package Name: linux-libc-dev Installed Version: 5.4.0-92.103 Fixed Version: References: cve.mitre.org github.com lore.kernel.org twitter.com |
|
LOW |
CVE-2020-12363: kernel: Improper input validation in some Intel(R) Graphics DriversImproper input validation in some Intel(R) Graphics Drivers for Windows* before version 26.20.100.7212 and before Linux kernel version 5.5 may allow a privileged user to potentially enable a denial of service via local access.Package Name: linux-libc-dev Installed Version: 5.4.0-92.103 Fixed Version: References: cve.mitre.org linux.oracle.com linux.oracle.com www.intel.com |
|
LOW |
CVE-2020-12364: kernel: Null pointer dereference in some Intel(R) Graphics DriversNull pointer reference in some Intel(R) Graphics Drivers for Windows* before version 26.20.100.7212 and before version Linux kernel version 5.5 may allow a privileged user to potentially enable a denial of service via local access.Package Name: linux-libc-dev Installed Version: 5.4.0-92.103 Fixed Version: References: cve.mitre.org linux.oracle.com linux.oracle.com www.intel.com |
|
LOW |
CVE-2020-14304: kernel: ethtool when reading eeprom of device could lead to memory leakA memory disclosure flaw was found in the Linux kernel's ethernet drivers, in the way it read data from the EEPROM of the device. This flaw allows a local user to read uninitialized values from the kernel memory. The highest threat from this vulnerability is to confidentiality.Package Name: linux-libc-dev Installed Version: 5.4.0-92.103 Fixed Version: References: bugs.debian.org bugzilla.redhat.com cve.mitre.org linux.oracle.com linux.oracle.com lore.kernel.org |
|
LOW |
CVE-2020-35501: kernel: audit not logging access to syscall open_by_handle_at for users with CAP_DAC_READ_SEARCH capabilityA flaw was found in the Linux kernels implementation of audit rules, where a syscall can unexpectedly not be correctly not be logged by the audit subsystemPackage Name: linux-libc-dev Installed Version: 5.4.0-92.103 Fixed Version: References: cve.mitre.org listman.redhat.com www.openwall.com |
|
LOW |
CVE-2021-26934An issue was discovered in the Linux kernel 4.18 through 5.10.16, as used by Xen. The backend allocation (aka be-alloc) mode of the drm_xen_front drivers was not meant to be a supported configuration, but this wasn't stated accordingly in its support status entry.Package Name: linux-libc-dev Installed Version: 5.4.0-92.103 Fixed Version: References: xenbits.xen.org cve.mitre.org lists.fedoraproject.org lists.fedoraproject.org security.netapp.com www.openwall.com xenbits.xen.org |
|
LOW |
CVE-2021-32078: kernel: out-of-bounds read in arch/arm/mach-footbridge/personal-pci.c due to improper input validationAn Out-of-Bounds Read was discovered in arch/arm/mach-footbridge/personal-pci.c in the Linux kernel through 5.12.11 because of the lack of a check for a value that shouldn't be negative, e.g., access to element -2 of an array, aka CID-298a58e165e4.Package Name: linux-libc-dev Installed Version: 5.4.0-92.103 Fixed Version: References: cve.mitre.org git.kernel.org git.kernel.org github.com kirtikumarar.com security.netapp.com |
|
LOW |
CVE-2021-34981: kernel: Bluetooth CMTP Module Double Free Privilege Escalation VulnerabilityA flaw was found in the Linux kernel's CAPI over Bluetooth connection code. An attacker with a local account can escalate privileges when CAPI (ISDN) hardware connection fails.Package Name: linux-libc-dev Installed Version: 5.4.0-92.103 Fixed Version: References: cve.mitre.org git.kernel.org git.kernel.org www.zerodayinitiative.com |
|
LOW |
CVE-2021-3669: kernel: reading /proc/sysvipc/shm does not scale with large shared memory segment countsA flaw was found in the Linux kernel. Measuring usage of the shared memory does not scale with large shared memory segment counts which could lead to resource exhaustion and DoS.Package Name: linux-libc-dev Installed Version: 5.4.0-92.103 Fixed Version: References: cve.mitre.org lore.kernel.org |
|
LOW |
CVE-2021-3772: kernel: sctp: Invalid chunks may be used to remotely remove existing associationsA flaw was found in the Linux SCTP stack. A blind attacker may be able to kill an existing SCTP association through invalid chunks if the attacker knows the IP-addresses and port numbers being used and the attacker can send packets with spoofed IP addresses.Package Name: linux-libc-dev Installed Version: 5.4.0-92.103 Fixed Version: References: cve.mitre.org git.kernel.org ubuntu.com |
|
LOW |
CVE-2016-10228: glibc: iconv program can hang when invoked with the -c optionThe iconv program in the GNU C Library (aka glibc or libc6) 2.31 and earlier, when invoked with multiple suffixes in the destination encoding (TRANSLATE or IGNORE) along with the -c option, enters an infinite loop when processing invalid multi-byte input sequences, leading to a denial of service.Package Name: locales Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: openwall.com www.securityfocus.com cve.mitre.org linux.oracle.com linux.oracle.com lists.apache.org security.gentoo.org sourceware.org sourceware.org sourceware.org |
|
LOW |
CVE-2019-25013: glibc: buffer over-read in iconv when processing invalid multi-byte input sequences in the EUC-KR encodingThe iconv feature in the GNU C Library (aka glibc or libc6) through 2.32, when processing invalid multi-byte input sequences in the EUC-KR encoding, may have a buffer over-read.Package Name: locales Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org linux.oracle.com linux.oracle.com lists.apache.org lists.apache.org lists.apache.org lists.apache.org lists.apache.org lists.apache.org lists.apache.org lists.apache.org lists.apache.org lists.fedoraproject.org lists.fedoraproject.org security.netapp.com sourceware.org sourceware.org |
|
LOW |
CVE-2020-27618: glibc: iconv when processing invalid multi-byte input sequences fails to advance the input state, which could result in an infinite loopThe iconv function in the GNU C Library (aka glibc or libc6) 2.32 and earlier, when processing invalid multi-byte input sequences in IBM1364, IBM1371, IBM1388, IBM1390, and IBM1399 encodings, fails to advance the input state, which could lead to an infinite loop in applications, resulting in a denial of service, a different vulnerability from CVE-2016-10228.Package Name: locales Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org linux.oracle.com linux.oracle.com security.netapp.com sourceware.org sourceware.org |
|
LOW |
CVE-2020-29562: glibc: assertion failure in iconv when converting invalid UCS4The iconv function in the GNU C Library (aka glibc or libc6) 2.30 to 2.32, when converting UCS4 text containing an irreversible character, fails an assertion in the code path and aborts the program, potentially resulting in a denial of service.Package Name: locales Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org lists.apache.org lists.fedoraproject.org security.gentoo.org security.netapp.com sourceware.org sourceware.org |
|
LOW |
CVE-2020-6096: glibc: signed comparison vulnerability in the ARMv7 memcpy functionAn exploitable signed comparison vulnerability exists in the ARMv7 memcpy() implementation of GNU glibc 2.30.9000. Calling memcpy() (on ARMv7 targets that utilize the GNU glibc implementation) with a negative value for the 'num' parameter results in a signed comparison vulnerability. If an attacker underflows the 'num' parameter to memcpy(), this vulnerability could lead to undefined behavior such as writing to out-of-bounds memory and potentially remote code execution. Furthermore, this memcpy() implementation allows for program execution to continue in scenarios where a segmentation fault or crash should have occurred. The dangers occur in that subsequent execution and iterations of this code will be executed with this corrupted data.Package Name: locales Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org lists.apache.org lists.fedoraproject.org lists.fedoraproject.org security.gentoo.org sourceware.org sourceware.org talosintelligence.com ubuntu.com www.talosintelligence.com |
|
LOW |
CVE-2021-27645: glibc: Use-after-free in addgetnetgrentX function in netgroupcache.cThe nameserver caching daemon (nscd) in the GNU C Library (aka glibc or libc6) 2.29 through 2.33, when processing a request for netgroup lookup, may crash due to a double-free, potentially resulting in degraded service or Denial of Service on the local system. This is related to netgroupcache.c.Package Name: locales Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org linux.oracle.com linux.oracle.com lists.fedoraproject.org lists.fedoraproject.org sourceware.org |
|
LOW |
CVE-2021-3326: glibc: Assertion failure in ISO-2022-JP-3 gconv module related to combining charactersThe iconv function in the GNU C Library (aka glibc or libc6) 2.32 and earlier, when processing invalid input sequences in the ISO-2022-JP-3 encoding, fails an assertion in the code path and aborts the program, potentially resulting in a denial of service.Package Name: locales Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: www.openwall.com bugs.chromium.org cve.mitre.org linux.oracle.com linux.oracle.com security.netapp.com sourceware.org sourceware.org sourceware.org |
|
LOW |
CVE-2021-33574: glibc: mq_notify does not handle separately allocated thread attributesThe mq_notify function in the GNU C Library (aka glibc) versions 2.32 and 2.33 has a use-after-free. It may use the notification thread attributes object (passed through its struct sigevent parameter) after it has been freed by the caller, leading to a denial of service (application crash) or possibly unspecified other impact.Package Name: locales Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org linux.oracle.com linux.oracle.com lists.fedoraproject.org security.gentoo.org security.netapp.com sourceware.org sourceware.org |
|
LOW |
CVE-2021-35942: glibc: Arbitrary read in wordexp()The wordexp function in the GNU C Library (aka glibc) through 2.33 may crash or read arbitrary memory in parse_param (in posix/wordexp.c) when called with an untrusted, crafted pattern, potentially resulting in a denial of service or disclosure of information. This occurs because atoi was used but strtoul should have been used to ensure correct calculations.Package Name: locales Installed Version: 2.31-0ubuntu9.2 Fixed Version: References: cve.mitre.org linux.oracle.com linux.oracle.com security.netapp.com sourceware.org sourceware.org sourceware.org |
|
LOW |
CVE-2013-4235: shadow-utils: TOCTOU race conditions by copying and removing directory treesshadow: TOCTOU (time-of-check time-of-use) race condition when copying and removing directory treesPackage Name: login Installed Version: 1:4.8.1-1ubuntu5.20.04.1 Fixed Version: References: access.redhat.com bugzilla.redhat.com cve.mitre.org lists.apache.org security-tracker.debian.org |
|
LOW |
CVE-2020-14145: openssh: Observable discrepancy leading to an information leak in the algorithm negotiationThe client side in OpenSSH 5.7 through 8.4 has an Observable Discrepancy leading to an information leak in the algorithm negotiation. This allows man-in-the-middle attackers to target initial connection attempts (where no host key for the server has been cached by the client). NOTE: some reports state that 8.5 and 8.6 are also affected.Package Name: openssh-client Installed Version: 1:8.2p1-4ubuntu0.4 Fixed Version: References: www.openwall.com anongit.mindrot.org cve.mitre.org docs.ssh-mitm.at github.com github.com linux.oracle.com linux.oracle.com security.gentoo.org security.netapp.com www.fzi.de www.fzi.de |
|
LOW |
CVE-2021-41617: openssh: privilege escalation when AuthorizedKeysCommand or AuthorizedPrincipalsCommand are configuredsshd in OpenSSH 6.2 through 8.x before 8.8, when certain non-default configurations are used, allows privilege escalation because supplemental groups are not initialized as expected. Helper programs for AuthorizedKeysCommand and AuthorizedPrincipalsCommand may run with privileges associated with group memberships of the sshd process, if the configuration specifies running the command as a different user.Package Name: openssh-client Installed Version: 1:8.2p1-4ubuntu0.4 Fixed Version: References: bugzilla.suse.com cve.mitre.org linux.oracle.com linux.oracle.com lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org security.netapp.com www.openssh.com www.openssh.com www.openwall.com |
|
LOW |
CVE-2013-4235: shadow-utils: TOCTOU race conditions by copying and removing directory treesshadow: TOCTOU (time-of-check time-of-use) race condition when copying and removing directory treesPackage Name: passwd Installed Version: 1:4.8.1-1ubuntu5.20.04.1 Fixed Version: References: access.redhat.com bugzilla.redhat.com cve.mitre.org lists.apache.org security-tracker.debian.org |
|
LOW |
CVE-2018-6952: patch: Double free of memory in pch.c:another_hunk() causes a crashA double free exists in the another_hunk function in pch.c in GNU patch through 2.7.6.Package Name: patch Installed Version: 2.7.6-6 Fixed Version: References: www.securityfocus.com access.redhat.com cve.mitre.org linux.oracle.com linux.oracle.com savannah.gnu.org security.gentoo.org |
|
LOW |
CVE-2016-2568: polkit: Program run via pkexec as unprivileged user can escape to parent session via TIOCSTI ioctlpkexec, when used with --user nonpriv, allows local users to escape to the parent session via a crafted TIOCSTI ioctl call, which pushes characters to the terminal's input buffer.Package Name: policykit-1 Installed Version: 0.105-26ubuntu1.1 Fixed Version: References: seclists.org www.openwall.com access.redhat.com bugs.debian.org bugzilla.redhat.com cve.mitre.org lore.kernel.org ubuntu.com |
|
LOW |
CVE-2021-33503: python-urllib3: ReDoS in the parsing of authority part of URLAn issue was discovered in urllib3 before 1.26.5. When provided with a URL containing many @ characters in the authority component, the authority regular expression exhibits catastrophic backtracking, causing a denial of service if a URL were passed as a parameter or redirected to via an HTTP redirect.Package Name: python3-urllib3 Installed Version: 1.25.8-2ubuntu0.1 Fixed Version: References: cve.mitre.org github.com github.com github.com linux.oracle.com linux.oracle.com lists.fedoraproject.org lists.fedoraproject.org nvd.nist.gov security.gentoo.org www.oracle.com |
|
LOW |
CVE-2021-23336: python: Web cache poisoning via urllib.parse.parse_qsl and urllib.parse.parse_qs by using a semicolon in query parametersThe package python/cpython from 0 and before 3.6.13, from 3.7.0 and before 3.7.10, from 3.8.0 and before 3.8.8, from 3.9.0 and before 3.9.2 are vulnerable to Web Cache Poisoning via urllib.parse.parse_qsl and urllib.parse.parse_qs by using a vector called parameter cloaking. When the attacker can separate query parameters using a semicolon (;), they can cause a difference in the interpretation of the request between the proxy (running with default configuration) and the server. This can result in malicious requests being cached as completely safe ones, as the proxy would usually not see the semicolon as a separator, and therefore would not include it in a cache key of an unkeyed parameter.Package Name: python3.8 Installed Version: 3.8.10-0ubuntu1~20.04.2 Fixed Version: References: www.openwall.com www.openwall.com cve.mitre.org github.com github.com linux.oracle.com linux.oracle.com lists.apache.org lists.apache.org lists.apache.org lists.debian.org lists.debian.org lists.debian.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org security.gentoo.org security.netapp.com snyk.io snyk.io ubuntu.com www.djangoproject.com www.oracle.com www.oracle.com www.oracle.com |
|
LOW |
CVE-2021-23336: python: Web cache poisoning via urllib.parse.parse_qsl and urllib.parse.parse_qs by using a semicolon in query parametersThe package python/cpython from 0 and before 3.6.13, from 3.7.0 and before 3.7.10, from 3.8.0 and before 3.8.8, from 3.9.0 and before 3.9.2 are vulnerable to Web Cache Poisoning via urllib.parse.parse_qsl and urllib.parse.parse_qs by using a vector called parameter cloaking. When the attacker can separate query parameters using a semicolon (;), they can cause a difference in the interpretation of the request between the proxy (running with default configuration) and the server. This can result in malicious requests being cached as completely safe ones, as the proxy would usually not see the semicolon as a separator, and therefore would not include it in a cache key of an unkeyed parameter.Package Name: python3.8-minimal Installed Version: 3.8.10-0ubuntu1~20.04.2 Fixed Version: References: www.openwall.com www.openwall.com cve.mitre.org github.com github.com linux.oracle.com linux.oracle.com lists.apache.org lists.apache.org lists.apache.org lists.debian.org lists.debian.org lists.debian.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org lists.fedoraproject.org security.gentoo.org security.netapp.com snyk.io snyk.io ubuntu.com www.djangoproject.com www.oracle.com www.oracle.com www.oracle.com |
|
LOW |
CVE-2019-16167: sysstat: memory corruption due to an integer overflow in remap_struct in sa_common.csysstat before 12.1.6 has memory corruption due to an Integer Overflow in remap_struct() in sa_common.c.Package Name: sysstat Installed Version: 12.2.0-2ubuntu0.1 Fixed Version: References: lists.opensuse.org lists.opensuse.org cve.mitre.org github.com github.com linux.oracle.com linux.oracle.com lists.fedoraproject.org ubuntu.com usn.ubuntu.com |
|
LOW |
CVE-2021-3974: vim: Use after free in regexp_nfa.cvim is vulnerable to Use After FreePackage Name: vim-common Installed Version: 2:8.1.2269-1ubuntu5.4 Fixed Version: 2:8.1.2269-1ubuntu5.6 References: www.openwall.com cve.mitre.org github.com github.com huntr.dev lists.fedoraproject.org lists.fedoraproject.org ubuntu.com |
|
LOW |
CVE-2021-3974: vim: Use after free in regexp_nfa.cvim is vulnerable to Use After FreePackage Name: vim-tiny Installed Version: 2:8.1.2269-1ubuntu5.4 Fixed Version: 2:8.1.2269-1ubuntu5.6 References: www.openwall.com cve.mitre.org github.com github.com huntr.dev lists.fedoraproject.org lists.fedoraproject.org ubuntu.com |
|
LOW |
CVE-2017-15131: xdg-user-dirs, gnome-session: Xsession creation of XDG user directories does not honor system umask policyIt was found that system umask policy is not being honored when creating XDG user directories, since Xsession sources xdg-user-dirs.sh before setting umask policy. This only affects xdg-user-dirs before 0.15.5 as shipped with Red Hat Enterprise Linux.Package Name: xdg-user-dirs Installed Version: 0.17-2ubuntu1 Fixed Version: References: bugs.freedesktop.org access.redhat.com bugzilla.redhat.com cve.mitre.org linux.oracle.com linux.oracle.com lists.apache.org |
|
LOW |
CVE-2021-3974: vim: Use after free in regexp_nfa.cvim is vulnerable to Use After FreePackage Name: xxd Installed Version: 2:8.1.2269-1ubuntu5.4 Fixed Version: 2:8.1.2269-1ubuntu5.6 References: www.openwall.com cve.mitre.org github.com github.com huntr.dev lists.fedoraproject.org lists.fedoraproject.org ubuntu.com |
|
LOW |
CVE-2018-13410** DISPUTED ** Info-ZIP Zip 3.0, when the -T and -TT command-line options are used, allows attackers to cause a denial of service (invalid free and application crash) or possibly have unspecified other impact because of an off-by-one error. NOTE: it is unclear whether there are realistic scenarios in which an untrusted party controls the -TT value, given that the entire purpose of -TT is execution of arbitrary commands.Package Name: zip Installed Version: 3.0-11build1 Fixed Version: References: seclists.org bugzilla.suse.com cve.mitre.org |
|
Target: | home/circleci/.cargo/registry/src/github.com-1ecc6299db9ec823/addr2line-0.17.0/Cargo.lock | |
UNKNOWN |
RUSTSEC-2020-0077: memmap is unmaintainedThe author of the `memmap` crate is unresponsive. Maintained alternatives: - [`mapr`](https://github.com/filecoin-project/mapr) - [`memmap2`](https://github.com/RazrFalcon/memmap2-rs)Package Name: memmap Installed Version: 0.7.0 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2022-0004: Stack overflow in rustc_serialize when parsing deeply nested JSONWhen parsing JSON using `json::Json::from_str`, there is no limit to the depth of the stack, therefore deeply nested objects can cause a stack overflow, which aborts the process. Example code that triggers the vulnerability is fn main() { let _ = rustc_serialize::json::Json::from_str(&"[0,[".repeat(10000)); } [serde](https://crates.io/crates/serde) is recommended as a replacement to rustc_serialize.Package Name: rustc-serialize Installed Version: 0.3.24 Fixed Version: References: None |
|
UNKNOWN |
RUSTSEC-2018-0015: term is looking for a new maintainerThe author of the `term` crate does not have time to maintain it and is looking for a new maintainer. Some maintained alternatives you can potentially switch to instead, depending on your needs: - [`crossterm`](https://github.com/crossterm-rs/crossterm) - [`termcolor`](https://crates.io/crates/termcolor) - [`yansi`](https://crates.io/crates/yansi)Package Name: term Installed Version: 0.4.6 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0071: ## ReferencesUnix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library. The affected functions from time 0.2.7 through 0.2.22 are: - `time::UtcOffset::local_offset_at` - `time::UtcOffset::try_local_offset_at` - `time::UtcOffset::current_local_offset` - `time::UtcOffset::try_current_local_offset` - `time::OffsetDateTime::now_local` - `time::OffsetDateTime::try_now_local` The affected functions in time 0.1 (all versions) are: - `at` - `at_utc` - `now` Non-Unix targets (including Windows and wasm) are unaffected. Pending a proper fix, the internal method that determines the local offset has been modified to always return `None` on the affected operating systems. This has the effect of returning an `Err` on the `try_*` methods and `UTC` on the non-`try_*` methods. Users and library authors with time in their dependency tree should perform `cargo update`, which will pull in the updated, unaffected code. Users of time 0.1 do not have a patch and should upgrade to an unaffected version: time 0.2.23 or greater or the 0.3 series. No workarounds are known. time-rs/time#293Package Name: time Installed Version: 0.1.44 Fixed Version: >= 0.2.23 References: github.com |
|
Target: | home/circleci/.cargo/registry/src/github.com-1ecc6299db9ec823/ansi_term-0.12.1/Cargo.lock | |
UNKNOWN |
RUSTSEC-2022-0006: Data race in `Iter` and `IterMut`In the affected version of this crate, `{Iter, IterMut}::next` used a weaker memory ordering when loading values than what was required, exposing a potential data race when iterating over a `ThreadLocal`'s values. Crates using `Iter::next`, or `IterMut::next` are affected by this issue.Package Name: thread_local Installed Version: 0.3.6 Fixed Version: >= 1.1.4 References: github.com |
|
Target: | home/circleci/.cargo/registry/src/github.com-1ecc6299db9ec823/arrayref-0.3.6/Cargo.lock | |
UNKNOWN |
RUSTSEC-2022-0006: Data race in `Iter` and `IterMut`In the affected version of this crate, `{Iter, IterMut}::next` used a weaker memory ordering when loading values than what was required, exposing a potential data race when iterating over a `ThreadLocal`'s values. Crates using `Iter::next`, or `IterMut::next` are affected by this issue.Package Name: thread_local Installed Version: 0.3.6 Fixed Version: >= 1.1.4 References: github.com |
|
Target: | home/circleci/.cargo/registry/src/github.com-1ecc6299db9ec823/async-io-1.6.0/Cargo.lock | |
UNKNOWN |
RUSTSEC-2021-0119: Out-of-bounds write in nix::unistd::getgrouplistOn certain platforms, if a user has more than 16 groups, the `nix::unistd::getgrouplist` function will call the libc `getgrouplist` function with a length parameter greater than the size of the buffer it provides, resulting in an out-of-bounds write and memory corruption. The libc `getgrouplist` function takes an in/out parameter `ngroups` specifying the size of the group buffer. When the buffer is too small to hold all of the reqested user's group memberships, some libc implementations, including glibc and Solaris libc, will modify `ngroups` to indicate the actual number of groups for the user, in addition to returning an error. The version of `nix::unistd::getgrouplist` in nix 0.16.0 and up will resize the buffer to twice its size, but will not read or modify the `ngroups` variable. Thus, if the user has more than twice as many groups as the initial buffer size of 8, the next call to `getgrouplist` will then write past the end of the buffer. The issue would require editing /etc/groups to exploit, which is usually only editable by the root user.Package Name: nix Installed Version: 0.21.0 Fixed Version: ^0.20.2, ^0.21.2, ^0.22.2, >= 0.23.0 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0023: Incorrect check on buffer length when seeding RNGsSummary: rand_core::le::read_u32_into and read_u64_into have incorrect checks on the source buffer length, allowing the destination buffer to be under-filled. Implications: some downstream RNGs, including Hc128Rng (but not the more widely used ChaCha*Rng), allow seeding using the SeedableRng::from_seed trait-function with too short keys.Package Name: rand_core Installed Version: 0.3.1 Fixed Version: >= 0.6.2 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0023: Incorrect check on buffer length when seeding RNGsSummary: rand_core::le::read_u32_into and read_u64_into have incorrect checks on the source buffer length, allowing the destination buffer to be under-filled. Implications: some downstream RNGs, including Hc128Rng (but not the more widely used ChaCha*Rng), allow seeding using the SeedableRng::from_seed trait-function with too short keys.Package Name: rand_core Installed Version: 0.4.2 Fixed Version: >= 0.6.2 References: github.com |
|
UNKNOWN |
RUSTSEC-2018-0017: `tempdir` crate has been deprecated; use `tempfile` insteadThe [`tempdir`](https://crates.io/crates/tempdir) crate has been deprecated and the functionality is merged into [`tempfile`](https://crates.io/crates/tempfile).Package Name: tempdir Installed Version: 0.3.7 Fixed Version: References: github.com |
|
Target: | home/circleci/.cargo/registry/src/github.com-1ecc6299db9ec823/async-mutex-1.4.0/Cargo.lock | |
UNKNOWN |
RUSTSEC-2020-0072: GenericMutexGuard allows data races of non-Sync types across threads`GenericMutexGuard<T>` was given the `Sync` auto trait as long as `T` is `Send` due to its contained members. However, since the guard is supposed to represent an **acquired lock** and allows concurrent access to the underlying data from different threads, it should only be `Sync` when the underlying data is. This is a soundness issue and allows data races, potentially leading to crashes and segfaults from safe Rust code. The flaw was corrected by adding a `T: Send + Sync` bound for `GenericMutexGuard`'s `Sync` trait. This bug is [similar to one](https://github.com/rust-lang/rust/issues/41622) in `std::sync::Mutex`.Package Name: futures-intrusive Installed Version: 0.3.1 Fixed Version: >= 0.4.0 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0060: futures_task::waker may cause a use-after-free if used on a type that isn't 'staticAffected versions of the crate did not properly implement a `'static` lifetime bound on the `waker` function. This resulted in a use-after-free if `Waker::wake()` is called after original data had been dropped. The flaw was corrected by adding `'static` lifetime bound to the data `waker` takes.Package Name: futures-task Installed Version: 0.3.5 Fixed Version: >= 0.3.6 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0059: MutexGuard::map can cause a data race in safe codeAffected versions of the crate had a Send/Sync implementation for MappedMutexGuard that only considered variance on T, while MappedMutexGuard dereferenced to U. This could of led to data races in safe Rust code when a closure used in MutexGuard::map() returns U that is unrelated to T. The issue was fixed by fixing `Send` and `Sync` implementations, and by adding a `PhantomData<&'a mut U>` marker to the `MappedMutexGuard` type to tell the compiler that the guard is over U too.Package Name: futures-util Installed Version: 0.3.5 Fixed Version: >= 0.3.7 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0070: Some lock_api lock guard objects can cause data racesAffected versions of lock_api had unsound implementations of the `Send` or `Sync` traits for some guard objects, namely: * MappedMutexGuard * MappedRwLockReadGuard * MappedRwLockWriteGuard * RwLockReadGuard * RwLockWriteGuard These guards could allow data races through types that are not safe to `Send` across thread boundaries in safe Rust code. This issue was fixed by changing the trait bounds on the `Mapped` guard types and removing the `Sync` trait for the `RwLock` guards.Package Name: lock_api Installed Version: 0.3.4 Fixed Version: >= 0.4.2 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0021: `nb-connect` invalidly assumes the memory layout of std::net::SocketAddrThe [`nb-connect`](https://crates.io/crates/nb-connect) crate has assumed `std::net::SocketAddrV4` and `std::net::SocketAddrV6` have the same memory layout as the system C representation `sockaddr`. It has simply casted the pointers to convert the socket addresses to the system representation. The standard library does not say anything about the memory layout, and this will cause invalid memory access if the standard library changes the implementation. No warnings or errors will be emitted once the change happens.Package Name: nb-connect Installed Version: 1.0.0 Fixed Version: >= 1.0.3 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0003: Buffer overflow in SmallVec::insert_manyA bug in the `SmallVec::insert_many` method caused it to allocate a buffer that was smaller than needed. It then wrote past the end of the buffer, causing a buffer overflow and memory corruption on the heap. This bug was only triggered if the iterator passed to `insert_many` yielded more items than the lower bound returned from its `size_hint` method. The flaw was corrected in smallvec 0.6.14 and 1.6.1, by ensuring that additional space is always reserved for each item inserted. The fix also simplified the implementation of `insert_many` to use less unsafe code, so it is easier to verify its correctness. Thank you to Yechan Bae (@Qwaz) and the Rust group at Georgia Tech’s SSLab for finding and reporting this bug.Package Name: smallvec Installed Version: 1.4.2 Fixed Version: >= 0.6.14, < 1.0.0, >= 1.6.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0079: `socket2` invalidly assumes the memory layout of std::net::SocketAddrThe [`socket2`](https://crates.io/crates/socket2) crate has assumed `std::net::SocketAddrV4` and `std::net::SocketAddrV6` have the same memory layout as the system C representation `sockaddr`. It has simply casted the pointers to convert the socket addresses to the system representation. The standard library does not say anything about the memory layout, and this will cause invalid memory access if the standard library changes the implementation. No warnings or errors will be emitted once the change happens.Package Name: socket2 Installed Version: 0.3.15 Fixed Version: >= 0.3.16 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0072: Task dropped in wrong thread when aborting `LocalSet` taskWhen aborting a task with `JoinHandle::abort`, the future is dropped in the thread calling abort if the task is not currently being executed. This is incorrect for tasks spawned on a `LocalSet`. This can easily result in race conditions as many projects use `Rc` or `RefCell` in their Tokio tasks for better performance. See [tokio#3929][issue] for more details. [issue]: https://github.com/tokio-rs/tokio/issues/3929Package Name: tokio Installed Version: 0.2.22 Fixed Version: >= 1.5.1, < 1.6.0, >= 1.6.3, < 1.7.0, >= 1.7.2, < 1.8.0, >= 1.8.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0124: Data race when sending and receiving after closing a `oneshot` channelIf a `tokio::sync::oneshot` channel is closed (via the [`oneshot::Receiver::close`] method), a data race may occur if the `oneshot::Sender::send` method is called while the corresponding `oneshot::Receiver` is `await`ed or calling `try_recv`. When these methods are called concurrently on a closed channel, the two halves of the channel can concurrently access a shared memory location, resulting in a data race. This has been observed to [cause memory corruption][corruption]. Note that the race only occurs when **both** halves of the channel are used after the `Receiver` half has called `close`. Code where `close` is not used, or where the `Receiver` is not `await`ed and `try_recv` is not called after calling `close`, is not affected. See [tokio#4225][issue] for more details. [corruption]: https://github.com/tokio-rs/tokio/issues/4225#issuecomment-967434847 [issue]: https://github.com/tokio-rs/tokio/issues/4225 [`oneshot::Receiver::close`]: https://docs.rs/tokio/1.14.0/tokio/sync/oneshot/struct.Receiver.html#method.closePackage Name: tokio Installed Version: 0.2.22 Fixed Version: >= 1.8.4, < 1.9.0, >= 1.13.1 References: github.com |
|
Target: | home/circleci/.cargo/registry/src/github.com-1ecc6299db9ec823/async-std-1.10.0/Cargo.lock | |
UNKNOWN |
RUSTSEC-2021-0060: `aes-soft` has been merged into the `aes` cratePlease use the `aes` crate going forward. The new repository location is at: <https://github.com/RustCrypto/block-ciphers/tree/master/aes> AES-NI is now autodetected at runtime on `i686`/`x86-64` platforms. If AES-NI is not present, the `aes` crate will fallback to a constant-time portable software implementation. To force the use of a constant-time portable implementation on these platforms, even if AES-NI is available, use the new `force-soft` feature of the `aes` crate to disable autodetection.Package Name: aes-soft Installed Version: 0.6.4 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0059: `aesni` has been merged into the `aes` cratePlease use the `aes` crate going forward. The new repository location is at: <https://github.com/RustCrypto/block-ciphers/tree/master/aes> AES-NI is now autodetected at runtime on `i686`/`x86-64` platforms. If AES-NI is not present, the `aes` crate will fallback to a constant-time portable software implementation. To prevent this fallback (and have absence of AES-NI result in an illegal instruction crash instead), continue to pass the same RUSTFLAGS which were previously required for the `aesni` crate to compile: RUSTFLAGS=-Ctarget-feature=+aes,+ssse3Package Name: aesni Installed Version: 0.10.0 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0064: `cpuid-bool` has been renamed to `cpufeatures`Please use the `cpufeatures`` crate going forward: <https://github.com/RustCrypto/utils/tree/master/cpufeatures> There will be no further releases of `cpuid-bool`.Package Name: cpuid-bool Installed Version: 0.1.2 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0064: `cpuid-bool` has been renamed to `cpufeatures`Please use the `cpufeatures`` crate going forward: <https://github.com/RustCrypto/utils/tree/master/cpufeatures> There will be no further releases of `cpuid-bool`.Package Name: cpuid-bool Installed Version: 0.2.0 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0021: `nb-connect` invalidly assumes the memory layout of std::net::SocketAddrThe [`nb-connect`](https://crates.io/crates/nb-connect) crate has assumed `std::net::SocketAddrV4` and `std::net::SocketAddrV6` have the same memory layout as the system C representation `sockaddr`. It has simply casted the pointers to convert the socket addresses to the system representation. The standard library does not say anything about the memory layout, and this will cause invalid memory access if the standard library changes the implementation. No warnings or errors will be emitted once the change happens.Package Name: nb-connect Installed Version: 1.0.2 Fixed Version: >= 1.0.3 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0023: Incorrect check on buffer length when seeding RNGsSummary: rand_core::le::read_u32_into and read_u64_into have incorrect checks on the source buffer length, allowing the destination buffer to be under-filled. Implications: some downstream RNGs, including Hc128Rng (but not the more widely used ChaCha*Rng), allow seeding using the SeedableRng::from_seed trait-function with too short keys.Package Name: rand_core Installed Version: 0.5.1 Fixed Version: >= 0.6.2 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0023: Incorrect check on buffer length when seeding RNGsSummary: rand_core::le::read_u32_into and read_u64_into have incorrect checks on the source buffer length, allowing the destination buffer to be under-filled. Implications: some downstream RNGs, including Hc128Rng (but not the more widely used ChaCha*Rng), allow seeding using the SeedableRng::from_seed trait-function with too short keys.Package Name: rand_core Installed Version: 0.6.1 Fixed Version: >= 0.6.2 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0100: Miscomputed results when using AVX2 backendThe v0.9.7 release of the `sha2` crate introduced a new AVX2-accelerated backend which was automatically enabled for all x86/x86_64 CPUs where AVX2 support was autodetected at runtime. This backend was buggy and would miscompute results for long messages (i.e. messages spanning multiple SHA blocks). The crate has since been yanked, but any users who upgraded to v0.9.7 should immediately upgrade to v0.9.8 and recompute any hashes which were previously computed by v0.9.7.Package Name: sha2 Installed Version: 0.9.2 Fixed Version: >= 0.9.8 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0056: stdweb is unmaintainedThe author of the `stdweb` crate is unresponsive. Maintained alternatives: - [`wasm-bindgen`](https://github.com/rustwasm/wasm-bindgen) - [`js-sys`](https://github.com/rustwasm/wasm-bindgen/tree/master/crates/js-sys) - [`web-sys`](https://github.com/rustwasm/wasm-bindgen/tree/master/crates/web-sys)Package Name: stdweb Installed Version: 0.4.20 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0072: Task dropped in wrong thread when aborting `LocalSet` taskWhen aborting a task with `JoinHandle::abort`, the future is dropped in the thread calling abort if the task is not currently being executed. This is incorrect for tasks spawned on a `LocalSet`. This can easily result in race conditions as many projects use `Rc` or `RefCell` in their Tokio tasks for better performance. See [tokio#3929][issue] for more details. [issue]: https://github.com/tokio-rs/tokio/issues/3929Package Name: tokio Installed Version: 0.2.24 Fixed Version: >= 1.5.1, < 1.6.0, >= 1.6.3, < 1.7.0, >= 1.7.2, < 1.8.0, >= 1.8.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0072: Task dropped in wrong thread when aborting `LocalSet` taskWhen aborting a task with `JoinHandle::abort`, the future is dropped in the thread calling abort if the task is not currently being executed. This is incorrect for tasks spawned on a `LocalSet`. This can easily result in race conditions as many projects use `Rc` or `RefCell` in their Tokio tasks for better performance. See [tokio#3929][issue] for more details. [issue]: https://github.com/tokio-rs/tokio/issues/3929Package Name: tokio Installed Version: 0.3.6 Fixed Version: >= 1.5.1, < 1.6.0, >= 1.6.3, < 1.7.0, >= 1.7.2, < 1.8.0, >= 1.8.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0072: Task dropped in wrong thread when aborting `LocalSet` taskWhen aborting a task with `JoinHandle::abort`, the future is dropped in the thread calling abort if the task is not currently being executed. This is incorrect for tasks spawned on a `LocalSet`. This can easily result in race conditions as many projects use `Rc` or `RefCell` in their Tokio tasks for better performance. See [tokio#3929][issue] for more details. [issue]: https://github.com/tokio-rs/tokio/issues/3929Package Name: tokio Installed Version: 1.0.1 Fixed Version: >= 1.5.1, < 1.6.0, >= 1.6.3, < 1.7.0, >= 1.7.2, < 1.8.0, >= 1.8.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0124: Data race when sending and receiving after closing a `oneshot` channelIf a `tokio::sync::oneshot` channel is closed (via the [`oneshot::Receiver::close`] method), a data race may occur if the `oneshot::Sender::send` method is called while the corresponding `oneshot::Receiver` is `await`ed or calling `try_recv`. When these methods are called concurrently on a closed channel, the two halves of the channel can concurrently access a shared memory location, resulting in a data race. This has been observed to [cause memory corruption][corruption]. Note that the race only occurs when **both** halves of the channel are used after the `Receiver` half has called `close`. Code where `close` is not used, or where the `Receiver` is not `await`ed and `try_recv` is not called after calling `close`, is not affected. See [tokio#4225][issue] for more details. [corruption]: https://github.com/tokio-rs/tokio/issues/4225#issuecomment-967434847 [issue]: https://github.com/tokio-rs/tokio/issues/4225 [`oneshot::Receiver::close`]: https://docs.rs/tokio/1.14.0/tokio/sync/oneshot/struct.Receiver.html#method.closePackage Name: tokio Installed Version: 0.2.24 Fixed Version: >= 1.8.4, < 1.9.0, >= 1.13.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0124: Data race when sending and receiving after closing a `oneshot` channelIf a `tokio::sync::oneshot` channel is closed (via the [`oneshot::Receiver::close`] method), a data race may occur if the `oneshot::Sender::send` method is called while the corresponding `oneshot::Receiver` is `await`ed or calling `try_recv`. When these methods are called concurrently on a closed channel, the two halves of the channel can concurrently access a shared memory location, resulting in a data race. This has been observed to [cause memory corruption][corruption]. Note that the race only occurs when **both** halves of the channel are used after the `Receiver` half has called `close`. Code where `close` is not used, or where the `Receiver` is not `await`ed and `try_recv` is not called after calling `close`, is not affected. See [tokio#4225][issue] for more details. [corruption]: https://github.com/tokio-rs/tokio/issues/4225#issuecomment-967434847 [issue]: https://github.com/tokio-rs/tokio/issues/4225 [`oneshot::Receiver::close`]: https://docs.rs/tokio/1.14.0/tokio/sync/oneshot/struct.Receiver.html#method.closePackage Name: tokio Installed Version: 0.3.6 Fixed Version: >= 1.8.4, < 1.9.0, >= 1.13.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0124: Data race when sending and receiving after closing a `oneshot` channelIf a `tokio::sync::oneshot` channel is closed (via the [`oneshot::Receiver::close`] method), a data race may occur if the `oneshot::Sender::send` method is called while the corresponding `oneshot::Receiver` is `await`ed or calling `try_recv`. When these methods are called concurrently on a closed channel, the two halves of the channel can concurrently access a shared memory location, resulting in a data race. This has been observed to [cause memory corruption][corruption]. Note that the race only occurs when **both** halves of the channel are used after the `Receiver` half has called `close`. Code where `close` is not used, or where the `Receiver` is not `await`ed and `try_recv` is not called after calling `close`, is not affected. See [tokio#4225][issue] for more details. [corruption]: https://github.com/tokio-rs/tokio/issues/4225#issuecomment-967434847 [issue]: https://github.com/tokio-rs/tokio/issues/4225 [`oneshot::Receiver::close`]: https://docs.rs/tokio/1.14.0/tokio/sync/oneshot/struct.Receiver.html#method.closePackage Name: tokio Installed Version: 1.0.1 Fixed Version: >= 1.8.4, < 1.9.0, >= 1.13.1 References: github.com |
|
Target: | home/circleci/.cargo/registry/src/github.com-1ecc6299db9ec823/async-task-4.1.0/Cargo.lock | |
UNKNOWN |
RUSTSEC-2019-0031: spin is no longer actively maintainedThe author of the `spin` crate does not have time or interest to maintain it. Consider the following alternatives (all of which support `no_std`): - [`conquer-once`](https://github.com/oliver-giersch/conquer-once) - [`lock_api`](https://crates.io/crates/lock_api) (a subproject of `parking_lot`) - [`spinning_top`](https://github.com/rust-osdev/spinning_top) spinlock crate built on `lock_api` - [`spinning`](https://github.com/4lDO2/spinning-rs)Package Name: spin Installed Version: 0.9.2 Fixed Version: References: github.com |
|
Target: | home/circleci/.cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.63/Cargo.lock | |
UNKNOWN |
RUSTSEC-2022-0004: Stack overflow in rustc_serialize when parsing deeply nested JSONWhen parsing JSON using `json::Json::from_str`, there is no limit to the depth of the stack, therefore deeply nested objects can cause a stack overflow, which aborts the process. Example code that triggers the vulnerability is fn main() { let _ = rustc_serialize::json::Json::from_str(&"[0,[".repeat(10000)); } [serde](https://crates.io/crates/serde) is recommended as a replacement to rustc_serialize.Package Name: rustc-serialize Installed Version: 0.3.24 Fixed Version: References: None |
|
Target: | home/circleci/.cargo/registry/src/github.com-1ecc6299db9ec823/base64-0.13.0/Cargo.lock | |
UNKNOWN |
RUSTSEC-2021-0093: Data race in crossbeam-dequeIn the affected version of this crate, the result of the race condition is that one or more tasks in the worker queue can be popped twice instead of other tasks that are forgotten and never popped. If tasks are allocated on the heap, this can cause double free and a memory leak. If not, this still can cause a logical bug. Crates using `Stealer::steal`, `Stealer::steal_batch`, or `Stealer::steal_batch_and_pop` are affected by this issue. Credits to @kmaork for discovering, reporting and fixing the bug.Package Name: crossbeam-deque Installed Version: 0.7.3 Fixed Version: >= 0.7.4, < 0.8.0, >= 0.8.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0023: Incorrect check on buffer length when seeding RNGsSummary: rand_core::le::read_u32_into and read_u64_into have incorrect checks on the source buffer length, allowing the destination buffer to be under-filled. Implications: some downstream RNGs, including Hc128Rng (but not the more widely used ChaCha*Rng), allow seeding using the SeedableRng::from_seed trait-function with too short keys.Package Name: rand_core Installed Version: 0.3.1 Fixed Version: >= 0.6.2 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0023: Incorrect check on buffer length when seeding RNGsSummary: rand_core::le::read_u32_into and read_u64_into have incorrect checks on the source buffer length, allowing the destination buffer to be under-filled. Implications: some downstream RNGs, including Hc128Rng (but not the more widely used ChaCha*Rng), allow seeding using the SeedableRng::from_seed trait-function with too short keys.Package Name: rand_core Installed Version: 0.4.2 Fixed Version: >= 0.6.2 References: github.com |
|
Target: | home/circleci/.cargo/registry/src/github.com-1ecc6299db9ec823/bitvec-0.22.3/Cargo.lock | |
UNKNOWN |
RUSTSEC-2021-0093: Data race in crossbeam-dequeIn the affected version of this crate, the result of the race condition is that one or more tasks in the worker queue can be popped twice instead of other tasks that are forgotten and never popped. If tasks are allocated on the heap, this can cause double free and a memory leak. If not, this still can cause a logical bug. Crates using `Stealer::steal`, `Stealer::steal_batch`, or `Stealer::steal_batch_and_pop` are affected by this issue. Credits to @kmaork for discovering, reporting and fixing the bug.Package Name: crossbeam-deque Installed Version: 0.8.0 Fixed Version: >= 0.7.4, < 0.8.0, >= 0.8.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0127: serde_cbor is unmaintainedThe `serde_cbor` crate is unmaintained. The author has archived the github repository. Alternatives proposed by the author: * [`ciborium`](https://crates.io/crates/ciborium) * [`minicbor`](https://crates.io/crates/minicbor)Package Name: serde_cbor Installed Version: 0.11.1 Fixed Version: References: github.com |
|
Target: | home/circleci/.cargo/registry/src/github.com-1ecc6299db9ec823/cargo-deny-0.11.0/Cargo.lock | |
UNKNOWN |
RUSTSEC-2020-0159: ## ReferencesUnix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library. No workarounds are known. - [time-rs/time#293](https://github.com/time-rs/time/issues/293)Package Name: chrono Installed Version: 0.4.19 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0129: Invalid handling of `X509_verify_cert()` internal errors in libsslInternally libssl in OpenSSL calls `X509_verify_cert()` on the client side to verify a certificate supplied by a server. That function may return a negative return value to indicate an internal error (for example out of memory). Such a negative return value is mishandled by OpenSSL and will cause an IO function (such as `SSL_connect()` or `SSL_do_handshake()`) to not indicate success and a subsequent call to `SSL_get_error()` to return the value `SSL_ERROR_WANT_RETRY_VERIFY`. This return value is only supposed to be returned by OpenSSL if the application has previously called `SSL_CTX_set_cert_verify_callback()`. Since most applications do not do this the `SSL_ERROR_WANT_RETRY_VERIFY` return value from `SSL_get_error()` will be totally unexpected and applications may not behave correctly as a result. The exact behaviour will depend on the application but it could result in crashes, infinite loops or other similar incorrect responses. This issue is made more serious in combination with a separate bug in OpenSSL 3.0 that will cause `X509_verify_cert()` to indicate an internal error when processing a certificate chain. This will occur where a certificate does not include the Subject Alternative Name extension but where a Certificate Authority has enforced name constraints. This issue can occur even with valid chains.Package Name: openssl-src Installed Version: 300.0.2+3.0.0 Fixed Version: >= 300.0.4 References: www.openssl.org |
|
UNKNOWN |
RUSTSEC-2021-0023: Incorrect check on buffer length when seeding RNGsSummary: rand_core::le::read_u32_into and read_u64_into have incorrect checks on the source buffer length, allowing the destination buffer to be under-filled. Implications: some downstream RNGs, including Hc128Rng (but not the more widely used ChaCha*Rng), allow seeding using the SeedableRng::from_seed trait-function with too short keys.Package Name: rand_core Installed Version: 0.5.1 Fixed Version: >= 0.6.2 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0051: Obsolete versions of the `rustsec` crate do not support the new V3 advisory formatIf you are seeing this message, you are running an obsolete version of `cargo-audit` which does not support the new V3 advisory format. These versions are end-of-life. This advisory is a notice that that it will soon be unable to parse the advisory database. Please upgrade `cargo-audit` to a newer release.Package Name: rustsec Installed Version: 0.25.1 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2022-0006: Data race in `Iter` and `IterMut`In the affected version of this crate, `{Iter, IterMut}::next` used a weaker memory ordering when loading values than what was required, exposing a potential data race when iterating over a `ThreadLocal`'s values. Crates using `Iter::next`, or `IterMut::next` are affected by this issue.Package Name: thread_local Installed Version: 1.1.3 Fixed Version: >= 1.1.4 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0071: ## ReferencesUnix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library. The affected functions from time 0.2.7 through 0.2.22 are: - `time::UtcOffset::local_offset_at` - `time::UtcOffset::try_local_offset_at` - `time::UtcOffset::current_local_offset` - `time::UtcOffset::try_current_local_offset` - `time::OffsetDateTime::now_local` - `time::OffsetDateTime::try_now_local` The affected functions in time 0.1 (all versions) are: - `at` - `at_utc` - `now` Non-Unix targets (including Windows and wasm) are unaffected. Pending a proper fix, the internal method that determines the local offset has been modified to always return `None` on the affected operating systems. This has the effect of returning an `Err` on the `try_*` methods and `UTC` on the non-`try_*` methods. Users and library authors with time in their dependency tree should perform `cargo update`, which will pull in the updated, unaffected code. Users of time 0.1 do not have a patch and should upgrade to an unaffected version: time 0.2.23 or greater or the 0.3 series. No workarounds are known. time-rs/time#293Package Name: time Installed Version: 0.1.43 Fixed Version: >= 0.2.23 References: github.com |
|
Target: | home/circleci/.cargo/registry/src/github.com-1ecc6299db9ec823/clap-2.33.3/Cargo.lock | |
UNKNOWN |
RUSTSEC-2020-0053: dirs is unmaintained, use dirs-next insteadThe `dirs` crate is not maintained any more; use [`dirs-next`](https://crates.io/crates/dirs-next) instead.Package Name: dirs Installed Version: 1.0.5 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2018-0015: term is looking for a new maintainerThe author of the `term` crate does not have time to maintain it and is looking for a new maintainer. Some maintained alternatives you can potentially switch to instead, depending on your needs: - [`crossterm`](https://github.com/crossterm-rs/crossterm) - [`termcolor`](https://crates.io/crates/termcolor) - [`yansi`](https://crates.io/crates/yansi)Package Name: term Installed Version: 0.5.2 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2022-0006: Data race in `Iter` and `IterMut`In the affected version of this crate, `{Iter, IterMut}::next` used a weaker memory ordering when loading values than what was required, exposing a potential data race when iterating over a `ThreadLocal`'s values. Crates using `Iter::next`, or `IterMut::next` are affected by this issue.Package Name: thread_local Installed Version: 1.0.1 Fixed Version: >= 1.1.4 References: github.com |
|
UNKNOWN |
RUSTSEC-2018-0006: Uncontrolled recursion leads to abort in deserializationAffected versions of this crate did not prevent deep recursion while deserializing data structures. This allows an attacker to make a YAML file with deeply nested structures that causes an abort while deserializing it. The flaw was corrected by checking the recursion depth. Note: `clap 2.33` is not affected by this because it uses `yaml-rust` in a way that doesn't trigger the vulnerability. More specifically: 1. The input to the YAML parser is always trusted - is included at compile time via `include_str!`. 2. The nesting level is never deep enough to trigger the overflow in practice (at most 5).Package Name: yaml-rust Installed Version: 0.3.5 Fixed Version: >= 0.4.1 References: github.com |
|
Target: | home/circleci/.cargo/registry/src/github.com-1ecc6299db9ec823/clap-2.34.0/Cargo.lock | |
UNKNOWN |
RUSTSEC-2020-0053: dirs is unmaintained, use dirs-next insteadThe `dirs` crate is not maintained any more; use [`dirs-next`](https://crates.io/crates/dirs-next) instead.Package Name: dirs Installed Version: 1.0.5 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2018-0015: term is looking for a new maintainerThe author of the `term` crate does not have time to maintain it and is looking for a new maintainer. Some maintained alternatives you can potentially switch to instead, depending on your needs: - [`crossterm`](https://github.com/crossterm-rs/crossterm) - [`termcolor`](https://crates.io/crates/termcolor) - [`yansi`](https://crates.io/crates/yansi)Package Name: term Installed Version: 0.5.2 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2018-0006: Uncontrolled recursion leads to abort in deserializationAffected versions of this crate did not prevent deep recursion while deserializing data structures. This allows an attacker to make a YAML file with deeply nested structures that causes an abort while deserializing it. The flaw was corrected by checking the recursion depth. Note: `clap 2.33` is not affected by this because it uses `yaml-rust` in a way that doesn't trigger the vulnerability. More specifically: 1. The input to the YAML parser is always trusted - is included at compile time via `include_str!`. 2. The nesting level is never deep enough to trigger the overflow in practice (at most 5).Package Name: yaml-rust Installed Version: 0.3.5 Fixed Version: >= 0.4.1 References: github.com |
|
Target: | home/circleci/.cargo/registry/src/github.com-1ecc6299db9ec823/codespan-reporting-0.11.1/Cargo.lock | |
UNKNOWN |
RUSTSEC-2021-0119: Out-of-bounds write in nix::unistd::getgrouplistOn certain platforms, if a user has more than 16 groups, the `nix::unistd::getgrouplist` function will call the libc `getgrouplist` function with a length parameter greater than the size of the buffer it provides, resulting in an out-of-bounds write and memory corruption. The libc `getgrouplist` function takes an in/out parameter `ngroups` specifying the size of the group buffer. When the buffer is too small to hold all of the reqested user's group memberships, some libc implementations, including glibc and Solaris libc, will modify `ngroups` to indicate the actual number of groups for the user, in addition to returning an error. The version of `nix::unistd::getgrouplist` in nix 0.16.0 and up will resize the buffer to twice its size, but will not read or modify the `ngroups` variable. Thus, if the user has more than twice as many groups as the initial buffer size of 8, the next call to `getgrouplist` will then write past the end of the buffer. The issue would require editing /etc/groups to exploit, which is usually only editable by the root user.Package Name: nix Installed Version: 0.18.0 Fixed Version: ^0.20.2, ^0.21.2, ^0.22.2, >= 0.23.0 References: github.com |
|
Target: | home/circleci/.cargo/registry/src/github.com-1ecc6299db9ec823/combine-4.6.2/Cargo.lock | |
UNKNOWN |
RUSTSEC-2021-0093: Data race in crossbeam-dequeIn the affected version of this crate, the result of the race condition is that one or more tasks in the worker queue can be popped twice instead of other tasks that are forgotten and never popped. If tasks are allocated on the heap, this can cause double free and a memory leak. If not, this still can cause a logical bug. Crates using `Stealer::steal`, `Stealer::steal_batch`, or `Stealer::steal_batch_and_pop` are affected by this issue. Credits to @kmaork for discovering, reporting and fixing the bug.Package Name: crossbeam-deque Installed Version: 0.8.0 Fixed Version: >= 0.7.4, < 0.8.0, >= 0.8.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0081: `mio` invalidly assumes the memory layout of std::net::SocketAddrThe [`mio`](https://crates.io/crates/mio) crate has assumed `std::net::SocketAddrV4` and `std::net::SocketAddrV6` have the same memory layout as the system C representation `sockaddr`. It has simply casted the pointers to convert the socket addresses to the system representation. The standard library does not say anything about the memory layout, and this will cause invalid memory access if the standard library changes the implementation. No warnings or errors will be emitted once the change happens.Package Name: mio Installed Version: 0.6.23 Fixed Version: >= 0.7.6 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0021: `nb-connect` invalidly assumes the memory layout of std::net::SocketAddrThe [`nb-connect`](https://crates.io/crates/nb-connect) crate has assumed `std::net::SocketAddrV4` and `std::net::SocketAddrV6` have the same memory layout as the system C representation `sockaddr`. It has simply casted the pointers to convert the socket addresses to the system representation. The standard library does not say anything about the memory layout, and this will cause invalid memory access if the standard library changes the implementation. No warnings or errors will be emitted once the change happens.Package Name: nb-connect Installed Version: 1.0.2 Fixed Version: >= 1.0.3 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0016: `net2` crate has been deprecated; use `socket2` insteadThe [`net2`](https://crates.io/crates/net2) crate has been deprecated and users are encouraged to considered [`socket2`](https://crates.io/crates/socket2) instead.Package Name: net2 Installed Version: 0.2.37 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0023: Incorrect check on buffer length when seeding RNGsSummary: rand_core::le::read_u32_into and read_u64_into have incorrect checks on the source buffer length, allowing the destination buffer to be under-filled. Implications: some downstream RNGs, including Hc128Rng (but not the more widely used ChaCha*Rng), allow seeding using the SeedableRng::from_seed trait-function with too short keys.Package Name: rand_core Installed Version: 0.3.1 Fixed Version: >= 0.6.2 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0023: Incorrect check on buffer length when seeding RNGsSummary: rand_core::le::read_u32_into and read_u64_into have incorrect checks on the source buffer length, allowing the destination buffer to be under-filled. Implications: some downstream RNGs, including Hc128Rng (but not the more widely used ChaCha*Rng), allow seeding using the SeedableRng::from_seed trait-function with too short keys.Package Name: rand_core Installed Version: 0.4.2 Fixed Version: >= 0.6.2 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0127: serde_cbor is unmaintainedThe `serde_cbor` crate is unmaintained. The author has archived the github repository. Alternatives proposed by the author: * [`ciborium`](https://crates.io/crates/ciborium) * [`minicbor`](https://crates.io/crates/minicbor)Package Name: serde_cbor Installed Version: 0.11.1 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2022-0006: Data race in `Iter` and `IterMut`In the affected version of this crate, `{Iter, IterMut}::next` used a weaker memory ordering when loading values than what was required, exposing a potential data race when iterating over a `ThreadLocal`'s values. Crates using `Iter::next`, or `IterMut::next` are affected by this issue.Package Name: thread_local Installed Version: 1.0.1 Fixed Version: >= 1.1.4 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0072: Task dropped in wrong thread when aborting `LocalSet` taskWhen aborting a task with `JoinHandle::abort`, the future is dropped in the thread calling abort if the task is not currently being executed. This is incorrect for tasks spawned on a `LocalSet`. This can easily result in race conditions as many projects use `Rc` or `RefCell` in their Tokio tasks for better performance. See [tokio#3929][issue] for more details. [issue]: https://github.com/tokio-rs/tokio/issues/3929Package Name: tokio Installed Version: 0.2.24 Fixed Version: >= 1.5.1, < 1.6.0, >= 1.6.3, < 1.7.0, >= 1.7.2, < 1.8.0, >= 1.8.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0072: Task dropped in wrong thread when aborting `LocalSet` taskWhen aborting a task with `JoinHandle::abort`, the future is dropped in the thread calling abort if the task is not currently being executed. This is incorrect for tasks spawned on a `LocalSet`. This can easily result in race conditions as many projects use `Rc` or `RefCell` in their Tokio tasks for better performance. See [tokio#3929][issue] for more details. [issue]: https://github.com/tokio-rs/tokio/issues/3929Package Name: tokio Installed Version: 0.3.6 Fixed Version: >= 1.5.1, < 1.6.0, >= 1.6.3, < 1.7.0, >= 1.7.2, < 1.8.0, >= 1.8.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0072: Task dropped in wrong thread when aborting `LocalSet` taskWhen aborting a task with `JoinHandle::abort`, the future is dropped in the thread calling abort if the task is not currently being executed. This is incorrect for tasks spawned on a `LocalSet`. This can easily result in race conditions as many projects use `Rc` or `RefCell` in their Tokio tasks for better performance. See [tokio#3929][issue] for more details. [issue]: https://github.com/tokio-rs/tokio/issues/3929Package Name: tokio Installed Version: 1.0.0 Fixed Version: >= 1.5.1, < 1.6.0, >= 1.6.3, < 1.7.0, >= 1.7.2, < 1.8.0, >= 1.8.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0124: Data race when sending and receiving after closing a `oneshot` channelIf a `tokio::sync::oneshot` channel is closed (via the [`oneshot::Receiver::close`] method), a data race may occur if the `oneshot::Sender::send` method is called while the corresponding `oneshot::Receiver` is `await`ed or calling `try_recv`. When these methods are called concurrently on a closed channel, the two halves of the channel can concurrently access a shared memory location, resulting in a data race. This has been observed to [cause memory corruption][corruption]. Note that the race only occurs when **both** halves of the channel are used after the `Receiver` half has called `close`. Code where `close` is not used, or where the `Receiver` is not `await`ed and `try_recv` is not called after calling `close`, is not affected. See [tokio#4225][issue] for more details. [corruption]: https://github.com/tokio-rs/tokio/issues/4225#issuecomment-967434847 [issue]: https://github.com/tokio-rs/tokio/issues/4225 [`oneshot::Receiver::close`]: https://docs.rs/tokio/1.14.0/tokio/sync/oneshot/struct.Receiver.html#method.closePackage Name: tokio Installed Version: 0.2.24 Fixed Version: >= 1.8.4, < 1.9.0, >= 1.13.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0124: Data race when sending and receiving after closing a `oneshot` channelIf a `tokio::sync::oneshot` channel is closed (via the [`oneshot::Receiver::close`] method), a data race may occur if the `oneshot::Sender::send` method is called while the corresponding `oneshot::Receiver` is `await`ed or calling `try_recv`. When these methods are called concurrently on a closed channel, the two halves of the channel can concurrently access a shared memory location, resulting in a data race. This has been observed to [cause memory corruption][corruption]. Note that the race only occurs when **both** halves of the channel are used after the `Receiver` half has called `close`. Code where `close` is not used, or where the `Receiver` is not `await`ed and `try_recv` is not called after calling `close`, is not affected. See [tokio#4225][issue] for more details. [corruption]: https://github.com/tokio-rs/tokio/issues/4225#issuecomment-967434847 [issue]: https://github.com/tokio-rs/tokio/issues/4225 [`oneshot::Receiver::close`]: https://docs.rs/tokio/1.14.0/tokio/sync/oneshot/struct.Receiver.html#method.closePackage Name: tokio Installed Version: 0.3.6 Fixed Version: >= 1.8.4, < 1.9.0, >= 1.13.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0124: Data race when sending and receiving after closing a `oneshot` channelIf a `tokio::sync::oneshot` channel is closed (via the [`oneshot::Receiver::close`] method), a data race may occur if the `oneshot::Sender::send` method is called while the corresponding `oneshot::Receiver` is `await`ed or calling `try_recv`. When these methods are called concurrently on a closed channel, the two halves of the channel can concurrently access a shared memory location, resulting in a data race. This has been observed to [cause memory corruption][corruption]. Note that the race only occurs when **both** halves of the channel are used after the `Receiver` half has called `close`. Code where `close` is not used, or where the `Receiver` is not `await`ed and `try_recv` is not called after calling `close`, is not affected. See [tokio#4225][issue] for more details. [corruption]: https://github.com/tokio-rs/tokio/issues/4225#issuecomment-967434847 [issue]: https://github.com/tokio-rs/tokio/issues/4225 [`oneshot::Receiver::close`]: https://docs.rs/tokio/1.14.0/tokio/sync/oneshot/struct.Receiver.html#method.closePackage Name: tokio Installed Version: 1.0.0 Fixed Version: >= 1.8.4, < 1.9.0, >= 1.13.1 References: github.com |
|
Target: | home/circleci/.cargo/registry/src/github.com-1ecc6299db9ec823/combine-4.6.3/Cargo.lock | |
UNKNOWN |
RUSTSEC-2020-0081: `mio` invalidly assumes the memory layout of std::net::SocketAddrThe [`mio`](https://crates.io/crates/mio) crate has assumed `std::net::SocketAddrV4` and `std::net::SocketAddrV6` have the same memory layout as the system C representation `sockaddr`. It has simply casted the pointers to convert the socket addresses to the system representation. The standard library does not say anything about the memory layout, and this will cause invalid memory access if the standard library changes the implementation. No warnings or errors will be emitted once the change happens.Package Name: mio Installed Version: 0.6.23 Fixed Version: >= 0.7.6 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0016: `net2` crate has been deprecated; use `socket2` insteadThe [`net2`](https://crates.io/crates/net2) crate has been deprecated and users are encouraged to considered [`socket2`](https://crates.io/crates/socket2) instead.Package Name: net2 Installed Version: 0.2.37 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0023: Incorrect check on buffer length when seeding RNGsSummary: rand_core::le::read_u32_into and read_u64_into have incorrect checks on the source buffer length, allowing the destination buffer to be under-filled. Implications: some downstream RNGs, including Hc128Rng (but not the more widely used ChaCha*Rng), allow seeding using the SeedableRng::from_seed trait-function with too short keys.Package Name: rand_core Installed Version: 0.3.1 Fixed Version: >= 0.6.2 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0023: Incorrect check on buffer length when seeding RNGsSummary: rand_core::le::read_u32_into and read_u64_into have incorrect checks on the source buffer length, allowing the destination buffer to be under-filled. Implications: some downstream RNGs, including Hc128Rng (but not the more widely used ChaCha*Rng), allow seeding using the SeedableRng::from_seed trait-function with too short keys.Package Name: rand_core Installed Version: 0.4.2 Fixed Version: >= 0.6.2 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0127: serde_cbor is unmaintainedThe `serde_cbor` crate is unmaintained. The author has archived the github repository. Alternatives proposed by the author: * [`ciborium`](https://crates.io/crates/ciborium) * [`minicbor`](https://crates.io/crates/minicbor)Package Name: serde_cbor Installed Version: 0.11.2 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0072: Task dropped in wrong thread when aborting `LocalSet` taskWhen aborting a task with `JoinHandle::abort`, the future is dropped in the thread calling abort if the task is not currently being executed. This is incorrect for tasks spawned on a `LocalSet`. This can easily result in race conditions as many projects use `Rc` or `RefCell` in their Tokio tasks for better performance. See [tokio#3929][issue] for more details. [issue]: https://github.com/tokio-rs/tokio/issues/3929Package Name: tokio Installed Version: 0.2.25 Fixed Version: >= 1.5.1, < 1.6.0, >= 1.6.3, < 1.7.0, >= 1.7.2, < 1.8.0, >= 1.8.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0072: Task dropped in wrong thread when aborting `LocalSet` taskWhen aborting a task with `JoinHandle::abort`, the future is dropped in the thread calling abort if the task is not currently being executed. This is incorrect for tasks spawned on a `LocalSet`. This can easily result in race conditions as many projects use `Rc` or `RefCell` in their Tokio tasks for better performance. See [tokio#3929][issue] for more details. [issue]: https://github.com/tokio-rs/tokio/issues/3929Package Name: tokio Installed Version: 0.3.7 Fixed Version: >= 1.5.1, < 1.6.0, >= 1.6.3, < 1.7.0, >= 1.7.2, < 1.8.0, >= 1.8.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0124: Data race when sending and receiving after closing a `oneshot` channelIf a `tokio::sync::oneshot` channel is closed (via the [`oneshot::Receiver::close`] method), a data race may occur if the `oneshot::Sender::send` method is called while the corresponding `oneshot::Receiver` is `await`ed or calling `try_recv`. When these methods are called concurrently on a closed channel, the two halves of the channel can concurrently access a shared memory location, resulting in a data race. This has been observed to [cause memory corruption][corruption]. Note that the race only occurs when **both** halves of the channel are used after the `Receiver` half has called `close`. Code where `close` is not used, or where the `Receiver` is not `await`ed and `try_recv` is not called after calling `close`, is not affected. See [tokio#4225][issue] for more details. [corruption]: https://github.com/tokio-rs/tokio/issues/4225#issuecomment-967434847 [issue]: https://github.com/tokio-rs/tokio/issues/4225 [`oneshot::Receiver::close`]: https://docs.rs/tokio/1.14.0/tokio/sync/oneshot/struct.Receiver.html#method.closePackage Name: tokio Installed Version: 0.2.25 Fixed Version: >= 1.8.4, < 1.9.0, >= 1.13.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0124: Data race when sending and receiving after closing a `oneshot` channelIf a `tokio::sync::oneshot` channel is closed (via the [`oneshot::Receiver::close`] method), a data race may occur if the `oneshot::Sender::send` method is called while the corresponding `oneshot::Receiver` is `await`ed or calling `try_recv`. When these methods are called concurrently on a closed channel, the two halves of the channel can concurrently access a shared memory location, resulting in a data race. This has been observed to [cause memory corruption][corruption]. Note that the race only occurs when **both** halves of the channel are used after the `Receiver` half has called `close`. Code where `close` is not used, or where the `Receiver` is not `await`ed and `try_recv` is not called after calling `close`, is not affected. See [tokio#4225][issue] for more details. [corruption]: https://github.com/tokio-rs/tokio/issues/4225#issuecomment-967434847 [issue]: https://github.com/tokio-rs/tokio/issues/4225 [`oneshot::Receiver::close`]: https://docs.rs/tokio/1.14.0/tokio/sync/oneshot/struct.Receiver.html#method.closePackage Name: tokio Installed Version: 0.3.7 Fixed Version: >= 1.8.4, < 1.9.0, >= 1.13.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0124: Data race when sending and receiving after closing a `oneshot` channelIf a `tokio::sync::oneshot` channel is closed (via the [`oneshot::Receiver::close`] method), a data race may occur if the `oneshot::Sender::send` method is called while the corresponding `oneshot::Receiver` is `await`ed or calling `try_recv`. When these methods are called concurrently on a closed channel, the two halves of the channel can concurrently access a shared memory location, resulting in a data race. This has been observed to [cause memory corruption][corruption]. Note that the race only occurs when **both** halves of the channel are used after the `Receiver` half has called `close`. Code where `close` is not used, or where the `Receiver` is not `await`ed and `try_recv` is not called after calling `close`, is not affected. See [tokio#4225][issue] for more details. [corruption]: https://github.com/tokio-rs/tokio/issues/4225#issuecomment-967434847 [issue]: https://github.com/tokio-rs/tokio/issues/4225 [`oneshot::Receiver::close`]: https://docs.rs/tokio/1.14.0/tokio/sync/oneshot/struct.Receiver.html#method.closePackage Name: tokio Installed Version: 1.12.0 Fixed Version: >= 1.8.4, < 1.9.0, >= 1.13.1 References: github.com |
|
Target: | home/circleci/.cargo/registry/src/github.com-1ecc6299db9ec823/crossbeam-epoch-0.8.2/Cargo.lock | |
UNKNOWN |
RUSTSEC-2021-0023: Incorrect check on buffer length when seeding RNGsSummary: rand_core::le::read_u32_into and read_u64_into have incorrect checks on the source buffer length, allowing the destination buffer to be under-filled. Implications: some downstream RNGs, including Hc128Rng (but not the more widely used ChaCha*Rng), allow seeding using the SeedableRng::from_seed trait-function with too short keys.Package Name: rand_core Installed Version: 0.3.1 Fixed Version: >= 0.6.2 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0023: Incorrect check on buffer length when seeding RNGsSummary: rand_core::le::read_u32_into and read_u64_into have incorrect checks on the source buffer length, allowing the destination buffer to be under-filled. Implications: some downstream RNGs, including Hc128Rng (but not the more widely used ChaCha*Rng), allow seeding using the SeedableRng::from_seed trait-function with too short keys.Package Name: rand_core Installed Version: 0.4.2 Fixed Version: >= 0.6.2 References: github.com |
|
Target: | home/circleci/.cargo/registry/src/github.com-1ecc6299db9ec823/env_logger-0.8.4/Cargo.lock | |
UNKNOWN |
RUSTSEC-2022-0006: Data race in `Iter` and `IterMut`In the affected version of this crate, `{Iter, IterMut}::next` used a weaker memory ordering when loading values than what was required, exposing a potential data race when iterating over a `ThreadLocal`'s values. Crates using `Iter::next`, or `IterMut::next` are affected by this issue.Package Name: thread_local Installed Version: 1.0.1 Fixed Version: >= 1.1.4 References: github.com |
|
Target: | home/circleci/.cargo/registry/src/github.com-1ecc6299db9ec823/failure-0.1.8/Cargo.lock | |
UNKNOWN |
RUSTSEC-2019-0036: Type confusion if __private_get_type_id__ is overriddenSafe Rust code can implement malfunctioning `__private_get_type_id__` and cause type confusion when downcasting, which is an undefined behavior. Users who derive `Fail` trait are not affected.Package Name: failure Installed Version: 0.1.8 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0036: failure is officially deprecated/unmaintainedThe `failure` crate is officially end-of-life: it has been marked as deprecated by the former maintainer, who has announced that there will be no updates or maintenance work on it going forward. The following are some suggested actively developed alternatives to switch to: - [`anyhow`](https://crates.io/crates/anyhow) - [`eyre`](https://crates.io/crates/eyre) - [`fehler`](https://crates.io/crates/fehler) - [`snafu`](https://crates.io/crates/snafu) - [`thiserror`](https://crates.io/crates/thiserror)Package Name: failure Installed Version: 0.1.8 Fixed Version: References: github.com |
|
Target: | home/circleci/.cargo/registry/src/github.com-1ecc6299db9ec823/fern-0.6.0/Cargo.lock | |
UNKNOWN |
RUSTSEC-2020-0091: Dangling reference in `access::Map` with ConstantUsing the `arc_swap::access::Map` with the `Constant` test helper (or with user-provided implementation of the `Access` trait) could sometimes lead to the map returning dangling references. Replaced by implementation without `unsafe`, at the cost of added `Clone` bound on the closure and small penalty on performance.Package Name: arc-swap Installed Version: 0.4.4 Fixed Version: >= 0.4.8, < 1.0.0-0, >= 1.1.0 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0159: ## ReferencesUnix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library. No workarounds are known. - [time-rs/time#293](https://github.com/time-rs/time/issues/293)Package Name: chrono Installed Version: 0.4.11 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0023: Incorrect check on buffer length when seeding RNGsSummary: rand_core::le::read_u32_into and read_u64_into have incorrect checks on the source buffer length, allowing the destination buffer to be under-filled. Implications: some downstream RNGs, including Hc128Rng (but not the more widely used ChaCha*Rng), allow seeding using the SeedableRng::from_seed trait-function with too short keys.Package Name: rand_core Installed Version: 0.3.1 Fixed Version: >= 0.6.2 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0023: Incorrect check on buffer length when seeding RNGsSummary: rand_core::le::read_u32_into and read_u64_into have incorrect checks on the source buffer length, allowing the destination buffer to be under-filled. Implications: some downstream RNGs, including Hc128Rng (but not the more widely used ChaCha*Rng), allow seeding using the SeedableRng::from_seed trait-function with too short keys.Package Name: rand_core Installed Version: 0.4.2 Fixed Version: >= 0.6.2 References: github.com |
|
UNKNOWN |
RUSTSEC-2018-0017: `tempdir` crate has been deprecated; use `tempfile` insteadThe [`tempdir`](https://crates.io/crates/tempdir) crate has been deprecated and the functionality is merged into [`tempfile`](https://crates.io/crates/tempfile).Package Name: tempdir Installed Version: 0.3.7 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0071: ## ReferencesUnix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library. The affected functions from time 0.2.7 through 0.2.22 are: - `time::UtcOffset::local_offset_at` - `time::UtcOffset::try_local_offset_at` - `time::UtcOffset::current_local_offset` - `time::UtcOffset::try_current_local_offset` - `time::OffsetDateTime::now_local` - `time::OffsetDateTime::try_now_local` The affected functions in time 0.1 (all versions) are: - `at` - `at_utc` - `now` Non-Unix targets (including Windows and wasm) are unaffected. Pending a proper fix, the internal method that determines the local offset has been modified to always return `None` on the affected operating systems. This has the effect of returning an `Err` on the `try_*` methods and `UTC` on the non-`try_*` methods. Users and library authors with time in their dependency tree should perform `cargo update`, which will pull in the updated, unaffected code. Users of time 0.1 do not have a patch and should upgrade to an unaffected version: time 0.2.23 or greater or the 0.3 series. No workarounds are known. time-rs/time#293Package Name: time Installed Version: 0.1.42 Fixed Version: >= 0.2.23 References: github.com |
|
Target: | home/circleci/.cargo/registry/src/github.com-1ecc6299db9ec823/flate2-1.0.22/Cargo.lock | |
UNKNOWN |
RUSTSEC-2021-0093: Data race in crossbeam-dequeIn the affected version of this crate, the result of the race condition is that one or more tasks in the worker queue can be popped twice instead of other tasks that are forgotten and never popped. If tasks are allocated on the heap, this can cause double free and a memory leak. If not, this still can cause a logical bug. Crates using `Stealer::steal`, `Stealer::steal_batch`, or `Stealer::steal_batch_and_pop` are affected by this issue. Credits to @kmaork for discovering, reporting and fixing the bug.Package Name: crossbeam-deque Installed Version: 0.7.3 Fixed Version: >= 0.7.4, < 0.8.0, >= 0.8.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0070: Some lock_api lock guard objects can cause data racesAffected versions of lock_api had unsound implementations of the `Send` or `Sync` traits for some guard objects, namely: * MappedMutexGuard * MappedRwLockReadGuard * MappedRwLockWriteGuard * RwLockReadGuard * RwLockWriteGuard These guards could allow data races through types that are not safe to `Send` across thread boundaries in safe Rust code. This issue was fixed by changing the trait bounds on the `Mapped` guard types and removing the `Sync` trait for the `RwLock` guards.Package Name: lock_api Installed Version: 0.3.4 Fixed Version: >= 0.4.2 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0081: `mio` invalidly assumes the memory layout of std::net::SocketAddrThe [`mio`](https://crates.io/crates/mio) crate has assumed `std::net::SocketAddrV4` and `std::net::SocketAddrV6` have the same memory layout as the system C representation `sockaddr`. It has simply casted the pointers to convert the socket addresses to the system representation. The standard library does not say anything about the memory layout, and this will cause invalid memory access if the standard library changes the implementation. No warnings or errors will be emitted once the change happens.Package Name: mio Installed Version: 0.6.23 Fixed Version: >= 0.7.6 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0016: `net2` crate has been deprecated; use `socket2` insteadThe [`net2`](https://crates.io/crates/net2) crate has been deprecated and users are encouraged to considered [`socket2`](https://crates.io/crates/socket2) instead.Package Name: net2 Installed Version: 0.2.37 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0023: Incorrect check on buffer length when seeding RNGsSummary: rand_core::le::read_u32_into and read_u64_into have incorrect checks on the source buffer length, allowing the destination buffer to be under-filled. Implications: some downstream RNGs, including Hc128Rng (but not the more widely used ChaCha*Rng), allow seeding using the SeedableRng::from_seed trait-function with too short keys.Package Name: rand_core Installed Version: 0.5.1 Fixed Version: >= 0.6.2 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0003: Buffer overflow in SmallVec::insert_manyA bug in the `SmallVec::insert_many` method caused it to allocate a buffer that was smaller than needed. It then wrote past the end of the buffer, causing a buffer overflow and memory corruption on the heap. This bug was only triggered if the iterator passed to `insert_many` yielded more items than the lower bound returned from its `size_hint` method. The flaw was corrected in smallvec 0.6.14 and 1.6.1, by ensuring that additional space is always reserved for each item inserted. The fix also simplified the implementation of `insert_many` to use less unsafe code, so it is easier to verify its correctness. Thank you to Yechan Bae (@Qwaz) and the Rust group at Georgia Tech’s SSLab for finding and reporting this bug.Package Name: smallvec Installed Version: 0.6.13 Fixed Version: >= 0.6.14, < 1.0.0, >= 1.6.1 References: github.com |
|
Target: | home/circleci/.cargo/registry/src/github.com-1ecc6299db9ec823/gimli-0.26.1/Cargo.lock | |
UNKNOWN |
RUSTSEC-2020-0077: memmap is unmaintainedThe author of the `memmap` crate is unresponsive. Maintained alternatives: - [`mapr`](https://github.com/filecoin-project/mapr) - [`memmap2`](https://github.com/RazrFalcon/memmap2-rs)Package Name: memmap Installed Version: 0.7.0 Fixed Version: References: github.com |
|
Target: | home/circleci/.cargo/registry/src/github.com-1ecc6299db9ec823/git2-0.13.24/Cargo.lock | |
UNKNOWN |
RUSTSEC-2021-0129: Invalid handling of `X509_verify_cert()` internal errors in libsslInternally libssl in OpenSSL calls `X509_verify_cert()` on the client side to verify a certificate supplied by a server. That function may return a negative return value to indicate an internal error (for example out of memory). Such a negative return value is mishandled by OpenSSL and will cause an IO function (such as `SSL_connect()` or `SSL_do_handshake()`) to not indicate success and a subsequent call to `SSL_get_error()` to return the value `SSL_ERROR_WANT_RETRY_VERIFY`. This return value is only supposed to be returned by OpenSSL if the application has previously called `SSL_CTX_set_cert_verify_callback()`. Since most applications do not do this the `SSL_ERROR_WANT_RETRY_VERIFY` return value from `SSL_get_error()` will be totally unexpected and applications may not behave correctly as a result. The exact behaviour will depend on the application but it could result in crashes, infinite loops or other similar incorrect responses. This issue is made more serious in combination with a separate bug in OpenSSL 3.0 that will cause `X509_verify_cert()` to indicate an internal error when processing a certificate chain. This will occur where a certificate does not include the Subject Alternative Name extension but where a Certificate Authority has enforced name constraints. This issue can occur even with valid chains.Package Name: openssl-src Installed Version: 300.0.2+3.0.0 Fixed Version: >= 300.0.4 References: www.openssl.org |
|
UNKNOWN |
RUSTSEC-2020-0071: ## ReferencesUnix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library. The affected functions from time 0.2.7 through 0.2.22 are: - `time::UtcOffset::local_offset_at` - `time::UtcOffset::try_local_offset_at` - `time::UtcOffset::current_local_offset` - `time::UtcOffset::try_current_local_offset` - `time::OffsetDateTime::now_local` - `time::OffsetDateTime::try_now_local` The affected functions in time 0.1 (all versions) are: - `at` - `at_utc` - `now` Non-Unix targets (including Windows and wasm) are unaffected. Pending a proper fix, the internal method that determines the local offset has been modified to always return `None` on the affected operating systems. This has the effect of returning an `Err` on the `try_*` methods and `UTC` on the non-`try_*` methods. Users and library authors with time in their dependency tree should perform `cargo update`, which will pull in the updated, unaffected code. Users of time 0.1 do not have a patch and should upgrade to an unaffected version: time 0.2.23 or greater or the 0.3 series. No workarounds are known. time-rs/time#293Package Name: time Installed Version: 0.1.43 Fixed Version: >= 0.2.23 References: github.com |
|
Target: | home/circleci/.cargo/registry/src/github.com-1ecc6299db9ec823/h2-0.1.26/Cargo.lock | |
UNKNOWN |
RUSTSEC-2021-0093: Data race in crossbeam-dequeIn the affected version of this crate, the result of the race condition is that one or more tasks in the worker queue can be popped twice instead of other tasks that are forgotten and never popped. If tasks are allocated on the heap, this can cause double free and a memory leak. If not, this still can cause a logical bug. Crates using `Stealer::steal`, `Stealer::steal_batch`, or `Stealer::steal_batch_and_pop` are affected by this issue. Credits to @kmaork for discovering, reporting and fixing the bug.Package Name: crossbeam-deque Installed Version: 0.6.1 Fixed Version: >= 0.7.4, < 0.8.0, >= 0.8.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2019-0033: Integer Overflow in HeaderMap::reserve() can cause Denial of Service`HeaderMap::reserve()` used `usize::next_power_of_two()` to calculate the increased capacity. However, `next_power_of_two()` silently overflows to 0 if given a sufficiently large number in release mode. If the map was not empty when the overflow happens, the library will invoke `self.grow(0)` and start infinite probing. This allows an attacker who controls the argument to `reserve()` to cause a potential denial of service (DoS). The flaw was corrected in 0.1.20 release of `http` crate.Package Name: http Installed Version: 0.1.13 Fixed Version: >= 0.1.20 References: github.com |
|
UNKNOWN |
RUSTSEC-2019-0034: HeaderMap::Drain API is unsoundAffected versions of this crate incorrectly used raw pointer, which introduced unsoundness in its public safe API. [Failing to drop the Drain struct causes double-free](https://github.com/hyperium/http/issues/354), and [it is possible to violate Rust's alias rule and cause data race with Drain's Iterator implementation](https://github.com/hyperium/http/issues/355). The flaw was corrected in 0.1.20 release of `http` crate.Package Name: http Installed Version: 0.1.13 Fixed Version: >= 0.1.20 References: None |
|
UNKNOWN |
RUSTSEC-2019-0011: Flaw in offset_of and span_of causes SIGILL, drops uninitialized memory of arbitrary type on panic in client codeAffected versions of this crate caused traps and/or memory unsafety by zero-initializing references. They also could lead to uninitialized memory being dropped if the field for which the offset is requested was behind a deref coercion, and that deref coercion caused a panic. The flaw was corrected by using `MaybeUninit`.Package Name: memoffset Installed Version: 0.2.1 Fixed Version: >= 0.5.0 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0081: `mio` invalidly assumes the memory layout of std::net::SocketAddrThe [`mio`](https://crates.io/crates/mio) crate has assumed `std::net::SocketAddrV4` and `std::net::SocketAddrV6` have the same memory layout as the system C representation `sockaddr`. It has simply casted the pointers to convert the socket addresses to the system representation. The standard library does not say anything about the memory layout, and this will cause invalid memory access if the standard library changes the implementation. No warnings or errors will be emitted once the change happens.Package Name: mio Installed Version: 0.6.14 Fixed Version: >= 0.7.6 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0080: `miow` invalidly assumes the memory layout of std::net::SocketAddrThe [`miow`](https://crates.io/crates/miow) crate has assumed `std::net::SocketAddrV4` and `std::net::SocketAddrV6` have the same memory layout as the system C representation `sockaddr`. It has simply casted the pointers to convert the socket addresses to the system representation. The standard library does not say anything about the memory layout, and this will cause invalid memory access if the standard library changes the implementation. No warnings or errors will be emitted once the change happens.Package Name: miow Installed Version: 0.2.1 Fixed Version: ^ 0.2.2, >= 0.3.6 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0016: `net2` crate has been deprecated; use `socket2` insteadThe [`net2`](https://crates.io/crates/net2) crate has been deprecated and users are encouraged to considered [`socket2`](https://crates.io/crates/socket2) instead.Package Name: net2 Installed Version: 0.2.32 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0078: `net2` invalidly assumes the memory layout of std::net::SocketAddrThe [`net2`](https://crates.io/crates/net2) crate has assumed `std::net::SocketAddrV4` and `std::net::SocketAddrV6` have the same memory layout as the system C representation `sockaddr`. It has simply casted the pointers to convert the socket addresses to the system representation. The standard library does not say anything about the memory layout, and this will cause invalid memory access if the standard library changes the implementation. No warnings or errors will be emitted once the change happens.Package Name: net2 Installed Version: 0.2.32 Fixed Version: >= 0.2.36 References: github.com |
|
UNKNOWN |
RUSTSEC-2019-0035: Unaligned memory accessAffected versions of this crate violated alignment when casting byte slices to integer slices, resulting in undefined behavior. The flaw was corrected by Ralf Jung and Diggory Hardy.Package Name: rand_core Installed Version: 0.2.2 Fixed Version: ^ 0.3.1, >= 0.4.2 References: github.com |
|
UNKNOWN |
RUSTSEC-2019-0035: Unaligned memory accessAffected versions of this crate violated alignment when casting byte slices to integer slices, resulting in undefined behavior. The flaw was corrected by Ralf Jung and Diggory Hardy.Package Name: rand_core Installed Version: 0.3.0 Fixed Version: ^ 0.3.1, >= 0.4.2 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0023: Incorrect check on buffer length when seeding RNGsSummary: rand_core::le::read_u32_into and read_u64_into have incorrect checks on the source buffer length, allowing the destination buffer to be under-filled. Implications: some downstream RNGs, including Hc128Rng (but not the more widely used ChaCha*Rng), allow seeding using the SeedableRng::from_seed trait-function with too short keys.Package Name: rand_core Installed Version: 0.2.2 Fixed Version: >= 0.6.2 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0023: Incorrect check on buffer length when seeding RNGsSummary: rand_core::le::read_u32_into and read_u64_into have incorrect checks on the source buffer length, allowing the destination buffer to be under-filled. Implications: some downstream RNGs, including Hc128Rng (but not the more widely used ChaCha*Rng), allow seeding using the SeedableRng::from_seed trait-function with too short keys.Package Name: rand_core Installed Version: 0.3.0 Fixed Version: >= 0.6.2 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0072: Task dropped in wrong thread when aborting `LocalSet` taskWhen aborting a task with `JoinHandle::abort`, the future is dropped in the thread calling abort if the task is not currently being executed. This is incorrect for tasks spawned on a `LocalSet`. This can easily result in race conditions as many projects use `Rc` or `RefCell` in their Tokio tasks for better performance. See [tokio#3929][issue] for more details. [issue]: https://github.com/tokio-rs/tokio/issues/3929Package Name: tokio Installed Version: 0.1.11 Fixed Version: >= 1.5.1, < 1.6.0, >= 1.6.3, < 1.7.0, >= 1.7.2, < 1.8.0, >= 1.8.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0124: Data race when sending and receiving after closing a `oneshot` channelIf a `tokio::sync::oneshot` channel is closed (via the [`oneshot::Receiver::close`] method), a data race may occur if the `oneshot::Sender::send` method is called while the corresponding `oneshot::Receiver` is `await`ed or calling `try_recv`. When these methods are called concurrently on a closed channel, the two halves of the channel can concurrently access a shared memory location, resulting in a data race. This has been observed to [cause memory corruption][corruption]. Note that the race only occurs when **both** halves of the channel are used after the `Receiver` half has called `close`. Code where `close` is not used, or where the `Receiver` is not `await`ed and `try_recv` is not called after calling `close`, is not affected. See [tokio#4225][issue] for more details. [corruption]: https://github.com/tokio-rs/tokio/issues/4225#issuecomment-967434847 [issue]: https://github.com/tokio-rs/tokio/issues/4225 [`oneshot::Receiver::close`]: https://docs.rs/tokio/1.14.0/tokio/sync/oneshot/struct.Receiver.html#method.closePackage Name: tokio Installed Version: 0.1.11 Fixed Version: >= 1.8.4, < 1.9.0, >= 1.13.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0019: tokio-rustls reads may cause excessive memory usage`tokio-rustls` does not call `process_new_packets` immediately after `read`, so the expected termination condition `wants_read` always returns true. As long as new incoming data arrives faster than it is processed and the reader does not return pending, data will be buffered. This may cause DoS.Package Name: tokio-rustls Installed Version: 0.5.0 Fixed Version: >= 0.12.3, < 0.13.0, >= 0.13.1 References: github.com |
|
Target: | home/circleci/.cargo/registry/src/github.com-1ecc6299db9ec823/hyper-0.12.36/Cargo.lock | |
UNKNOWN |
RUSTSEC-2020-0159: ## ReferencesUnix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library. No workarounds are known. - [time-rs/time#293](https://github.com/time-rs/time/issues/293)Package Name: chrono Installed Version: 0.4.19 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0093: Data race in crossbeam-dequeIn the affected version of this crate, the result of the race condition is that one or more tasks in the worker queue can be popped twice instead of other tasks that are forgotten and never popped. If tasks are allocated on the heap, this can cause double free and a memory leak. If not, this still can cause a logical bug. Crates using `Stealer::steal`, `Stealer::steal_batch`, or `Stealer::steal_batch_and_pop` are affected by this issue. Credits to @kmaork for discovering, reporting and fixing the bug.Package Name: crossbeam-deque Installed Version: 0.7.3 Fixed Version: >= 0.7.4, < 0.8.0, >= 0.8.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0078: Lenient `hyper` header parsing of `Content-Length` could allow request smuggling`hyper`'s HTTP header parser accepted, according to RFC 7230, illegal contents inside `Content-Length` headers. Due to this, upstream HTTP proxies that ignore the header may still forward them along if it chooses to ignore the error. To be vulnerable, `hyper` must be used as an HTTP/1 server and using an HTTP proxy upstream that ignores the header's contents but still forwards it. Due to all the factors that must line up, an attack exploiting this vulnerability is unlikely.Package Name: hyper Installed Version: 0.12.36 Fixed Version: >= 0.14.10 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0079: Integer overflow in `hyper`'s parsing of the `Transfer-Encoding` header leads to data lossWhen decoding chunk sizes that are too large, `hyper`'s code would encounter an integer overflow. Depending on the situation, this could lead to data loss from an incorrect total size, or in rarer cases, a request smuggling attack. To be vulnerable, you must be using `hyper` for any HTTP/1 purpose, including as a client or server, and consumers must send requests or responses that specify a chunk size greater than 18 exabytes. For a possible request smuggling attack to be possible, any upstream proxies must accept a chunk size greater than 64 bits.Package Name: hyper Installed Version: 0.12.36 Fixed Version: >= 0.14.10 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0070: Some lock_api lock guard objects can cause data racesAffected versions of lock_api had unsound implementations of the `Send` or `Sync` traits for some guard objects, namely: * MappedMutexGuard * MappedRwLockReadGuard * MappedRwLockWriteGuard * RwLockReadGuard * RwLockWriteGuard These guards could allow data races through types that are not safe to `Send` across thread boundaries in safe Rust code. This issue was fixed by changing the trait bounds on the `Mapped` guard types and removing the `Sync` trait for the `RwLock` guards.Package Name: lock_api Installed Version: 0.3.4 Fixed Version: >= 0.4.2 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0081: `mio` invalidly assumes the memory layout of std::net::SocketAddrThe [`mio`](https://crates.io/crates/mio) crate has assumed `std::net::SocketAddrV4` and `std::net::SocketAddrV6` have the same memory layout as the system C representation `sockaddr`. It has simply casted the pointers to convert the socket addresses to the system representation. The standard library does not say anything about the memory layout, and this will cause invalid memory access if the standard library changes the implementation. No warnings or errors will be emitted once the change happens.Package Name: mio Installed Version: 0.6.23 Fixed Version: >= 0.7.6 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0016: `net2` crate has been deprecated; use `socket2` insteadThe [`net2`](https://crates.io/crates/net2) crate has been deprecated and users are encouraged to considered [`socket2`](https://crates.io/crates/socket2) instead.Package Name: net2 Installed Version: 0.2.37 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2022-0006: Data race in `Iter` and `IterMut`In the affected version of this crate, `{Iter, IterMut}::next` used a weaker memory ordering when loading values than what was required, exposing a potential data race when iterating over a `ThreadLocal`'s values. Crates using `Iter::next`, or `IterMut::next` are affected by this issue.Package Name: thread_local Installed Version: 1.0.1 Fixed Version: >= 1.1.4 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0071: ## ReferencesUnix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library. The affected functions from time 0.2.7 through 0.2.22 are: - `time::UtcOffset::local_offset_at` - `time::UtcOffset::try_local_offset_at` - `time::UtcOffset::current_local_offset` - `time::UtcOffset::try_current_local_offset` - `time::OffsetDateTime::now_local` - `time::OffsetDateTime::try_now_local` The affected functions in time 0.1 (all versions) are: - `at` - `at_utc` - `now` Non-Unix targets (including Windows and wasm) are unaffected. Pending a proper fix, the internal method that determines the local offset has been modified to always return `None` on the affected operating systems. This has the effect of returning an `Err` on the `try_*` methods and `UTC` on the non-`try_*` methods. Users and library authors with time in their dependency tree should perform `cargo update`, which will pull in the updated, unaffected code. Users of time 0.1 do not have a patch and should upgrade to an unaffected version: time 0.2.23 or greater or the 0.3 series. No workarounds are known. time-rs/time#293Package Name: time Installed Version: 0.1.44 Fixed Version: >= 0.2.23 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0072: Task dropped in wrong thread when aborting `LocalSet` taskWhen aborting a task with `JoinHandle::abort`, the future is dropped in the thread calling abort if the task is not currently being executed. This is incorrect for tasks spawned on a `LocalSet`. This can easily result in race conditions as many projects use `Rc` or `RefCell` in their Tokio tasks for better performance. See [tokio#3929][issue] for more details. [issue]: https://github.com/tokio-rs/tokio/issues/3929Package Name: tokio Installed Version: 0.1.22 Fixed Version: >= 1.5.1, < 1.6.0, >= 1.6.3, < 1.7.0, >= 1.7.2, < 1.8.0, >= 1.8.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0124: Data race when sending and receiving after closing a `oneshot` channelIf a `tokio::sync::oneshot` channel is closed (via the [`oneshot::Receiver::close`] method), a data race may occur if the `oneshot::Sender::send` method is called while the corresponding `oneshot::Receiver` is `await`ed or calling `try_recv`. When these methods are called concurrently on a closed channel, the two halves of the channel can concurrently access a shared memory location, resulting in a data race. This has been observed to [cause memory corruption][corruption]. Note that the race only occurs when **both** halves of the channel are used after the `Receiver` half has called `close`. Code where `close` is not used, or where the `Receiver` is not `await`ed and `try_recv` is not called after calling `close`, is not affected. See [tokio#4225][issue] for more details. [corruption]: https://github.com/tokio-rs/tokio/issues/4225#issuecomment-967434847 [issue]: https://github.com/tokio-rs/tokio/issues/4225 [`oneshot::Receiver::close`]: https://docs.rs/tokio/1.14.0/tokio/sync/oneshot/struct.Receiver.html#method.closePackage Name: tokio Installed Version: 0.1.22 Fixed Version: >= 1.8.4, < 1.9.0, >= 1.13.1 References: github.com |
|
Target: | home/circleci/.cargo/registry/src/github.com-1ecc6299db9ec823/itertools-0.10.1/Cargo.lock | |
UNKNOWN |
RUSTSEC-2021-0093: Data race in crossbeam-dequeIn the affected version of this crate, the result of the race condition is that one or more tasks in the worker queue can be popped twice instead of other tasks that are forgotten and never popped. If tasks are allocated on the heap, this can cause double free and a memory leak. If not, this still can cause a logical bug. Crates using `Stealer::steal`, `Stealer::steal_batch`, or `Stealer::steal_batch_and_pop` are affected by this issue. Credits to @kmaork for discovering, reporting and fixing the bug.Package Name: crossbeam-deque Installed Version: 0.8.0 Fixed Version: >= 0.7.4, < 0.8.0, >= 0.8.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0023: Incorrect check on buffer length when seeding RNGsSummary: rand_core::le::read_u32_into and read_u64_into have incorrect checks on the source buffer length, allowing the destination buffer to be under-filled. Implications: some downstream RNGs, including Hc128Rng (but not the more widely used ChaCha*Rng), allow seeding using the SeedableRng::from_seed trait-function with too short keys.Package Name: rand_core Installed Version: 0.5.1 Fixed Version: >= 0.6.2 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0127: serde_cbor is unmaintainedThe `serde_cbor` crate is unmaintained. The author has archived the github repository. Alternatives proposed by the author: * [`ciborium`](https://crates.io/crates/ciborium) * [`minicbor`](https://crates.io/crates/minicbor)Package Name: serde_cbor Installed Version: 0.11.1 Fixed Version: References: github.com |
|
Target: | home/circleci/.cargo/registry/src/github.com-1ecc6299db9ec823/kstring-1.0.6/Cargo.lock | |
UNKNOWN |
RUSTSEC-2021-0127: serde_cbor is unmaintainedThe `serde_cbor` crate is unmaintained. The author has archived the github repository. Alternatives proposed by the author: * [`ciborium`](https://crates.io/crates/ciborium) * [`minicbor`](https://crates.io/crates/minicbor)Package Name: serde_cbor Installed Version: 0.11.2 Fixed Version: References: github.com |
|
Target: | home/circleci/.cargo/registry/src/github.com-1ecc6299db9ec823/kv-log-macro-1.0.7/Cargo.lock | |
UNKNOWN |
RUSTSEC-2020-0070: Some lock_api lock guard objects can cause data racesAffected versions of lock_api had unsound implementations of the `Send` or `Sync` traits for some guard objects, namely: * MappedMutexGuard * MappedRwLockReadGuard * MappedRwLockWriteGuard * RwLockReadGuard * RwLockWriteGuard These guards could allow data races through types that are not safe to `Send` across thread boundaries in safe Rust code. This issue was fixed by changing the trait bounds on the `Mapped` guard types and removing the `Sync` trait for the `RwLock` guards.Package Name: lock_api Installed Version: 0.3.4 Fixed Version: >= 0.4.2 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0003: Buffer overflow in SmallVec::insert_manyA bug in the `SmallVec::insert_many` method caused it to allocate a buffer that was smaller than needed. It then wrote past the end of the buffer, causing a buffer overflow and memory corruption on the heap. This bug was only triggered if the iterator passed to `insert_many` yielded more items than the lower bound returned from its `size_hint` method. The flaw was corrected in smallvec 0.6.14 and 1.6.1, by ensuring that additional space is always reserved for each item inserted. The fix also simplified the implementation of `insert_many` to use less unsafe code, so it is easier to verify its correctness. Thank you to Yechan Bae (@Qwaz) and the Rust group at Georgia Tech’s SSLab for finding and reporting this bug.Package Name: smallvec Installed Version: 1.4.0 Fixed Version: >= 0.6.14, < 1.0.0, >= 1.6.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2022-0006: Data race in `Iter` and `IterMut`In the affected version of this crate, `{Iter, IterMut}::next` used a weaker memory ordering when loading values than what was required, exposing a potential data race when iterating over a `ThreadLocal`'s values. Crates using `Iter::next`, or `IterMut::next` are affected by this issue.Package Name: thread_local Installed Version: 1.0.1 Fixed Version: >= 1.1.4 References: github.com |
|
Target: | home/circleci/.cargo/registry/src/github.com-1ecc6299db9ec823/memcached-rs-0.4.2/Cargo.lock | |
UNKNOWN |
RUSTSEC-2021-0023: Incorrect check on buffer length when seeding RNGsSummary: rand_core::le::read_u32_into and read_u64_into have incorrect checks on the source buffer length, allowing the destination buffer to be under-filled. Implications: some downstream RNGs, including Hc128Rng (but not the more widely used ChaCha*Rng), allow seeding using the SeedableRng::from_seed trait-function with too short keys.Package Name: rand_core Installed Version: 0.5.1 Fixed Version: >= 0.6.2 References: github.com |
|
UNKNOWN |
RUSTSEC-2022-0006: Data race in `Iter` and `IterMut`In the affected version of this crate, `{Iter, IterMut}::next` used a weaker memory ordering when loading values than what was required, exposing a potential data race when iterating over a `ThreadLocal`'s values. Crates using `Iter::next`, or `IterMut::next` are affected by this issue.Package Name: thread_local Installed Version: 0.3.6 Fixed Version: >= 1.1.4 References: github.com |
|
Target: | home/circleci/.cargo/registry/src/github.com-1ecc6299db9ec823/mime_guess-2.0.3/Cargo.lock | |
UNKNOWN |
RUSTSEC-2020-0006: Flaw in `realloc` allows reading unknown memoryWhen `realloc`ing, if we allocate new space, we need to copy the old allocation's bytes into the new space. There are `old_size` number of bytes in the old allocation, but we were accidentally copying `new_size` number of bytes, which could lead to copying bytes into the realloc'd space from past the chunk that we're bump allocating out of, from unknown memory. If an attacker can cause `realloc`s, and can read the `realoc`ed data back, this could allow them to read things from other regions of memory that they shouldn't be able to. For example, if some crypto keys happened to live in memory right after a chunk we were bump allocating out of, this could allow the attacker to read the crypto keys. Beyond just fixing the bug and adding a regression test, I've also taken two additional steps: 1. While we were already running the testsuite under `valgrind` in CI, because `valgrind` exits with the same code that the program did, if there are invalid reads/writes that happen not to trigger a segfault, the program can still exit OK and we will be none the wiser. I've enabled the `--error-exitcode=1` flag for `valgrind` in CI so that tests eagerly fail in these scenarios. 2. I've written a quickcheck test to exercise `realloc`. Without the bug fix in this patch, this quickcheck immediately triggers invalid reads when run under `valgrind`. We didn't previously have quickchecks that exercised `realloc` because `realloc` isn't publicly exposed directly, and instead can only be indirectly called. This new quickcheck test exercises `realloc` via `bumpalo::collections::Vec::resize` and `bumpalo::collections::Vec::shrink_to_fit` calls.Package Name: bumpalo Installed Version: 3.2.0 Fixed Version: >= 3.2.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0093: Data race in crossbeam-dequeIn the affected version of this crate, the result of the race condition is that one or more tasks in the worker queue can be popped twice instead of other tasks that are forgotten and never popped. If tasks are allocated on the heap, this can cause double free and a memory leak. If not, this still can cause a logical bug. Crates using `Stealer::steal`, `Stealer::steal_batch`, or `Stealer::steal_batch_and_pop` are affected by this issue. Credits to @kmaork for discovering, reporting and fixing the bug.Package Name: crossbeam-deque Installed Version: 0.7.3 Fixed Version: >= 0.7.4, < 0.8.0, >= 0.8.1 References: github.com |
|
Target: | home/circleci/.cargo/registry/src/github.com-1ecc6299db9ec823/native-tls-0.2.8/Cargo.lock | |
UNKNOWN |
RUSTSEC-2021-0055: NULL pointer deref in signature_algorithms processingAn OpenSSL TLS server may crash if sent a maliciously crafted renegotiation ClientHello message from a client. If a TLSv1.2 renegotiation ClientHello omits the signature_algorithms extension (where it was present in the initial ClientHello), but includes a signature_algorithms_cert extension then a NULL pointer dereference will result, leading to a crash and a denial of service attack. A server is only vulnerable if it has TLSv1.2 and renegotiation enabled (which is the default configuration). OpenSSL TLS clients are not impacted by this issue.Package Name: openssl-src Installed Version: 111.13.0+1.1.1i Fixed Version: >= 111.15 References: www.openssl.org |
|
UNKNOWN |
RUSTSEC-2021-0056: CA certificate check bypass with X509_V_FLAG_X509_STRICTThe X509_V_FLAG_X509_STRICT flag enables additional security checks of the certificates present in a certificate chain. It is not set by default. Starting from OpenSSL version 1.1.1h a check to disallow certificates in the chain that have explicitly encoded elliptic curve parameters was added as an additional strict check. An error in the implementation of this check meant that the result of a previous check to confirm that certificates in the chain are valid CA certificates was overwritten. This effectively bypasses the check that non-CA certificates must not be able to issue other certificates. If a "purpose" has been configured then there is a subsequent opportunity for checks that the certificate is a valid CA. All of the named "purpose" values implemented in libcrypto perform this check. Therefore, where a purpose is set the certificate chain will still be rejected even when the strict flag has been used. A purpose is set by default in libssl client and server certificate verification routines, but it can be overridden or removed by an application. In order to be affected, an application must explicitly set the X509_V_FLAG_X509_STRICT verification flag and either not set a purpose for the certificate verification or, in the case of TLS client or server applications, override the default purpose.Package Name: openssl-src Installed Version: 111.13.0+1.1.1i Fixed Version: >= 111.15 References: www.openssl.org |
|
UNKNOWN |
RUSTSEC-2021-0057: Integer overflow in CipherUpdateCalls to `EVP_CipherUpdate`, `EVP_EncryptUpdate` and `EVP_DecryptUpdate` may overflow the output length argument in some cases where the input length is close to the maximum permissable length for an integer on the platform. In such cases the return value from the function call will be 1 (indicating success), but the output length value will be negative. This could cause applications to behave incorrectly or crash.Package Name: openssl-src Installed Version: 111.13.0+1.1.1i Fixed Version: >= 111.14 References: www.openssl.org |
|
UNKNOWN |
RUSTSEC-2021-0058: Null pointer deref in `X509_issuer_and_serial_hash()`The OpenSSL public API function `X509_issuer_and_serial_hash()` attempts to create a unique hash value based on the issuer and serial number data contained within an X509 certificate. However it fails to correctly handle any errors that may occur while parsing the issuer field (which might occur if the issuer field is maliciously constructed). This may subsequently result in a NULL pointer deref and a crash leading to a potential denial of service attack. The function `X509_issuer_and_serial_hash()` is never directly called by OpenSSL itself so applications are only vulnerable if they use this function directly and they use it on certificates that may have been obtained from untrusted sources.Package Name: openssl-src Installed Version: 111.13.0+1.1.1i Fixed Version: >= 111.14 References: www.openssl.org |
|
UNKNOWN |
RUSTSEC-2021-0097: SM2 Decryption Buffer OverflowIn order to decrypt SM2 encrypted data an application is expected to call the API function `EVP_PKEY_decrypt()`. Typically an application will call this function twice. The first time, on entry, the "out" parameter can be NULL and, on exit, the "outlen" parameter is populated with the buffer size required to hold the decrypted plaintext. The application can then allocate a sufficiently sized buffer and call `EVP_PKEY_decrypt()` again, but this time passing a non-NULL value for the "out" parameter. A bug in the implementation of the SM2 decryption code means that the calculation of the buffer size required to hold the plaintext returned by the first call to `EVP_PKEY_decrypt()` can be smaller than the actual size required by the second call. This can lead to a buffer overflow when `EVP_PKEY_decrypt()` is called by the application a second time with a buffer that is too small. A malicious attacker who is able present SM2 content for decryption to an application could cause attacker chosen data to overflow the buffer by up to a maximum of 62 bytes altering the contents of other data held after the buffer, possibly changing application behaviour or causing the application to crash. The location of the buffer is application dependent but is typically heap allocated.Package Name: openssl-src Installed Version: 111.13.0+1.1.1i Fixed Version: >= 111.16 References: www.openssl.org |
|
UNKNOWN |
RUSTSEC-2021-0098: Read buffer overruns processing ASN.1 stringsASN.1 strings are represented internally within OpenSSL as an ASN1_STRING structure which contains a buffer holding the string data and a field holding the buffer length. This contrasts with normal C strings which are represented as a buffer for the string data which is terminated with a NUL (0) byte. Although not a strict requirement, ASN.1 strings that are parsed using OpenSSL's own "d2i" functions (and other similar parsing functions) as well as any string whose value has been set with the ASN1_STRING_set() function will additionally NUL terminate the byte array in the ASN1_STRING structure. However, it is possible for applications to directly construct valid ASN1_STRING structures which do not NUL terminate the byte array by directly setting the "data" and "length" fields in the ASN1_STRING array. This can also happen by using the `ASN1_STRING_set0()` function. Numerous OpenSSL functions that print ASN.1 data have been found to assume that the ASN1_STRING byte array will be NUL terminated, even though this is not guaranteed for strings that have been directly constructed. Where an application requests an ASN.1 structure to be printed, and where that ASN.1 structure contains ASN1_STRINGs that have been directly constructed by the application without NUL terminating the "data" field, then a read buffer overrun can occur. The same thing can also occur during name constraints processing of certificates (for example if a certificate has been directly constructed by the application instead of loading it via the OpenSSL parsing functions, and the certificate contains non NUL terminated ASN1_STRING structures). It can also occur in the `X509_get1_email()`, `X509_REQ_get1_email()` and `X509_get1_ocsp()` functions. If a malicious actor can cause an application to directly construct an ASN1_STRING and then process it through one of the affected OpenSSL functions then this issue could be hit. This might result in a crash (causing a Denial of Service attack). It could also result in the disclosure of private memory contents (such as private keys, or sensitive plaintext).Package Name: openssl-src Installed Version: 111.13.0+1.1.1i Fixed Version: >= 111.16 References: www.openssl.org |
|
UNKNOWN |
RUSTSEC-2021-0129: Invalid handling of `X509_verify_cert()` internal errors in libsslInternally libssl in OpenSSL calls `X509_verify_cert()` on the client side to verify a certificate supplied by a server. That function may return a negative return value to indicate an internal error (for example out of memory). Such a negative return value is mishandled by OpenSSL and will cause an IO function (such as `SSL_connect()` or `SSL_do_handshake()`) to not indicate success and a subsequent call to `SSL_get_error()` to return the value `SSL_ERROR_WANT_RETRY_VERIFY`. This return value is only supposed to be returned by OpenSSL if the application has previously called `SSL_CTX_set_cert_verify_callback()`. Since most applications do not do this the `SSL_ERROR_WANT_RETRY_VERIFY` return value from `SSL_get_error()` will be totally unexpected and applications may not behave correctly as a result. The exact behaviour will depend on the application but it could result in crashes, infinite loops or other similar incorrect responses. This issue is made more serious in combination with a separate bug in OpenSSL 3.0 that will cause `X509_verify_cert()` to indicate an internal error when processing a certificate chain. This will occur where a certificate does not include the Subject Alternative Name extension but where a Certificate Authority has enforced name constraints. This issue can occur even with valid chains.Package Name: openssl-src Installed Version: 111.13.0+1.1.1i Fixed Version: >= 300.0.4 References: www.openssl.org |
|
UNKNOWN |
RUSTSEC-2021-0023: Incorrect check on buffer length when seeding RNGsSummary: rand_core::le::read_u32_into and read_u64_into have incorrect checks on the source buffer length, allowing the destination buffer to be under-filled. Implications: some downstream RNGs, including Hc128Rng (but not the more widely used ChaCha*Rng), allow seeding using the SeedableRng::from_seed trait-function with too short keys.Package Name: rand_core Installed Version: 0.5.1 Fixed Version: >= 0.6.2 References: github.com |
|
Target: | home/circleci/.cargo/registry/src/github.com-1ecc6299db9ec823/once_cell-1.9.0/Cargo.lock | |
UNKNOWN |
RUSTSEC-2022-0006: Data race in `Iter` and `IterMut`In the affected version of this crate, `{Iter, IterMut}::next` used a weaker memory ordering when loading values than what was required, exposing a potential data race when iterating over a `ThreadLocal`'s values. Crates using `Iter::next`, or `IterMut::next` are affected by this issue.Package Name: thread_local Installed Version: 0.3.6 Fixed Version: >= 1.1.4 References: github.com |
|
Target: | home/circleci/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.10.38/Cargo.lock | |
UNKNOWN |
RUSTSEC-2021-0129: Invalid handling of `X509_verify_cert()` internal errors in libsslInternally libssl in OpenSSL calls `X509_verify_cert()` on the client side to verify a certificate supplied by a server. That function may return a negative return value to indicate an internal error (for example out of memory). Such a negative return value is mishandled by OpenSSL and will cause an IO function (such as `SSL_connect()` or `SSL_do_handshake()`) to not indicate success and a subsequent call to `SSL_get_error()` to return the value `SSL_ERROR_WANT_RETRY_VERIFY`. This return value is only supposed to be returned by OpenSSL if the application has previously called `SSL_CTX_set_cert_verify_callback()`. Since most applications do not do this the `SSL_ERROR_WANT_RETRY_VERIFY` return value from `SSL_get_error()` will be totally unexpected and applications may not behave correctly as a result. The exact behaviour will depend on the application but it could result in crashes, infinite loops or other similar incorrect responses. This issue is made more serious in combination with a separate bug in OpenSSL 3.0 that will cause `X509_verify_cert()` to indicate an internal error when processing a certificate chain. This will occur where a certificate does not include the Subject Alternative Name extension but where a Certificate Authority has enforced name constraints. This issue can occur even with valid chains.Package Name: openssl-src Installed Version: 300.0.2+3.0.0 Fixed Version: >= 300.0.4 References: www.openssl.org |
|
UNKNOWN |
RUSTSEC-2021-0023: Incorrect check on buffer length when seeding RNGsSummary: rand_core::le::read_u32_into and read_u64_into have incorrect checks on the source buffer length, allowing the destination buffer to be under-filled. Implications: some downstream RNGs, including Hc128Rng (but not the more widely used ChaCha*Rng), allow seeding using the SeedableRng::from_seed trait-function with too short keys.Package Name: rand_core Installed Version: 0.3.1 Fixed Version: >= 0.6.2 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0023: Incorrect check on buffer length when seeding RNGsSummary: rand_core::le::read_u32_into and read_u64_into have incorrect checks on the source buffer length, allowing the destination buffer to be under-filled. Implications: some downstream RNGs, including Hc128Rng (but not the more widely used ChaCha*Rng), allow seeding using the SeedableRng::from_seed trait-function with too short keys.Package Name: rand_core Installed Version: 0.4.2 Fixed Version: >= 0.6.2 References: github.com |
|
UNKNOWN |
RUSTSEC-2018-0017: `tempdir` crate has been deprecated; use `tempfile` insteadThe [`tempdir`](https://crates.io/crates/tempdir) crate has been deprecated and the functionality is merged into [`tempfile`](https://crates.io/crates/tempfile).Package Name: tempdir Installed Version: 0.3.7 Fixed Version: References: github.com |
|
Target: | home/circleci/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.7.3/Cargo.lock | |
UNKNOWN |
RUSTSEC-2020-0006: Flaw in `realloc` allows reading unknown memoryWhen `realloc`ing, if we allocate new space, we need to copy the old allocation's bytes into the new space. There are `old_size` number of bytes in the old allocation, but we were accidentally copying `new_size` number of bytes, which could lead to copying bytes into the realloc'd space from past the chunk that we're bump allocating out of, from unknown memory. If an attacker can cause `realloc`s, and can read the `realoc`ed data back, this could allow them to read things from other regions of memory that they shouldn't be able to. For example, if some crypto keys happened to live in memory right after a chunk we were bump allocating out of, this could allow the attacker to read the crypto keys. Beyond just fixing the bug and adding a regression test, I've also taken two additional steps: 1. While we were already running the testsuite under `valgrind` in CI, because `valgrind` exits with the same code that the program did, if there are invalid reads/writes that happen not to trigger a segfault, the program can still exit OK and we will be none the wiser. I've enabled the `--error-exitcode=1` flag for `valgrind` in CI so that tests eagerly fail in these scenarios. 2. I've written a quickcheck test to exercise `realloc`. Without the bug fix in this patch, this quickcheck immediately triggers invalid reads when run under `valgrind`. We didn't previously have quickchecks that exercised `realloc` because `realloc` isn't publicly exposed directly, and instead can only be indirectly called. This new quickcheck test exercises `realloc` via `bumpalo::collections::Vec::resize` and `bumpalo::collections::Vec::shrink_to_fit` calls.Package Name: bumpalo Installed Version: 2.6.0 Fixed Version: >= 3.2.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0023: Incorrect check on buffer length when seeding RNGsSummary: rand_core::le::read_u32_into and read_u64_into have incorrect checks on the source buffer length, allowing the destination buffer to be under-filled. Implications: some downstream RNGs, including Hc128Rng (but not the more widely used ChaCha*Rng), allow seeding using the SeedableRng::from_seed trait-function with too short keys.Package Name: rand_core Installed Version: 0.5.1 Fixed Version: >= 0.6.2 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0056: stdweb is unmaintainedThe author of the `stdweb` crate is unresponsive. Maintained alternatives: - [`wasm-bindgen`](https://github.com/rustwasm/wasm-bindgen) - [`js-sys`](https://github.com/rustwasm/wasm-bindgen/tree/master/crates/js-sys) - [`web-sys`](https://github.com/rustwasm/wasm-bindgen/tree/master/crates/web-sys)Package Name: stdweb Installed Version: 0.4.18 Fixed Version: References: github.com |
|
Target: | home/circleci/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-1.5.1/Cargo.lock | |
UNKNOWN |
RUSTSEC-2021-0093: Data race in crossbeam-dequeIn the affected version of this crate, the result of the race condition is that one or more tasks in the worker queue can be popped twice instead of other tasks that are forgotten and never popped. If tasks are allocated on the heap, this can cause double free and a memory leak. If not, this still can cause a logical bug. Crates using `Stealer::steal`, `Stealer::steal_batch`, or `Stealer::steal_batch_and_pop` are affected by this issue. Credits to @kmaork for discovering, reporting and fixing the bug.Package Name: crossbeam-deque Installed Version: 0.8.0 Fixed Version: >= 0.7.4, < 0.8.0, >= 0.8.1 References: github.com |
|
Target: | home/circleci/.cargo/registry/src/github.com-1ecc6299db9ec823/redis-0.17.0/Cargo.lock | |
UNKNOWN |
RUSTSEC-2020-0091: Dangling reference in `access::Map` with ConstantUsing the `arc_swap::access::Map` with the `Constant` test helper (or with user-provided implementation of the `Access` trait) could sometimes lead to the map returning dangling references. Replaced by implementation without `unsafe`, at the cost of added `Clone` bound on the closure and small penalty on performance.Package Name: arc-swap Installed Version: 0.4.6 Fixed Version: >= 0.4.8, < 1.0.0-0, >= 1.1.0 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0052: Undefined Behavior in bounded channelThe affected version of this crate's the `bounded` channel incorrectly assumes that `Vec::from_iter` has allocated capacity that same as the number of iterator elements. `Vec::from_iter` does not actually guarantee that and may allocate extra memory. The destructor of the `bounded` channel reconstructs `Vec` from the raw pointer based on the incorrect assumes described above. This is unsound and causing deallocation with the incorrect capacity when `Vec::from_iter` has allocated different sizes with the number of iterator elements.Package Name: crossbeam-channel Installed Version: 0.4.2 Fixed Version: >= 0.4.4 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0093: Data race in crossbeam-dequeIn the affected version of this crate, the result of the race condition is that one or more tasks in the worker queue can be popped twice instead of other tasks that are forgotten and never popped. If tasks are allocated on the heap, this can cause double free and a memory leak. If not, this still can cause a logical bug. Crates using `Stealer::steal`, `Stealer::steal_batch`, or `Stealer::steal_batch_and_pop` are affected by this issue. Credits to @kmaork for discovering, reporting and fixing the bug.Package Name: crossbeam-deque Installed Version: 0.7.3 Fixed Version: >= 0.7.4, < 0.8.0, >= 0.8.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0060: futures_task::waker may cause a use-after-free if used on a type that isn't 'staticAffected versions of the crate did not properly implement a `'static` lifetime bound on the `waker` function. This resulted in a use-after-free if `Waker::wake()` is called after original data had been dropped. The flaw was corrected by adding `'static` lifetime bound to the data `waker` takes.Package Name: futures-task Installed Version: 0.3.5 Fixed Version: >= 0.3.6 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0059: MutexGuard::map can cause a data race in safe codeAffected versions of the crate had a Send/Sync implementation for MappedMutexGuard that only considered variance on T, while MappedMutexGuard dereferenced to U. This could of led to data races in safe Rust code when a closure used in MutexGuard::map() returns U that is unrelated to T. The issue was fixed by fixing `Send` and `Sync` implementations, and by adding a `PhantomData<&'a mut U>` marker to the `MappedMutexGuard` type to tell the compiler that the guard is over U too.Package Name: futures-util Installed Version: 0.3.5 Fixed Version: >= 0.3.7 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0070: Some lock_api lock guard objects can cause data racesAffected versions of lock_api had unsound implementations of the `Send` or `Sync` traits for some guard objects, namely: * MappedMutexGuard * MappedRwLockReadGuard * MappedRwLockWriteGuard * RwLockReadGuard * RwLockWriteGuard These guards could allow data races through types that are not safe to `Send` across thread boundaries in safe Rust code. This issue was fixed by changing the trait bounds on the `Mapped` guard types and removing the `Sync` trait for the `RwLock` guards.Package Name: lock_api Installed Version: 0.3.4 Fixed Version: >= 0.4.2 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0081: `mio` invalidly assumes the memory layout of std::net::SocketAddrThe [`mio`](https://crates.io/crates/mio) crate has assumed `std::net::SocketAddrV4` and `std::net::SocketAddrV6` have the same memory layout as the system C representation `sockaddr`. It has simply casted the pointers to convert the socket addresses to the system representation. The standard library does not say anything about the memory layout, and this will cause invalid memory access if the standard library changes the implementation. No warnings or errors will be emitted once the change happens.Package Name: mio Installed Version: 0.6.22 Fixed Version: >= 0.7.6 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0080: `miow` invalidly assumes the memory layout of std::net::SocketAddrThe [`miow`](https://crates.io/crates/miow) crate has assumed `std::net::SocketAddrV4` and `std::net::SocketAddrV6` have the same memory layout as the system C representation `sockaddr`. It has simply casted the pointers to convert the socket addresses to the system representation. The standard library does not say anything about the memory layout, and this will cause invalid memory access if the standard library changes the implementation. No warnings or errors will be emitted once the change happens.Package Name: miow Installed Version: 0.2.1 Fixed Version: ^ 0.2.2, >= 0.3.6 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0016: `net2` crate has been deprecated; use `socket2` insteadThe [`net2`](https://crates.io/crates/net2) crate has been deprecated and users are encouraged to considered [`socket2`](https://crates.io/crates/socket2) instead.Package Name: net2 Installed Version: 0.2.34 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0078: `net2` invalidly assumes the memory layout of std::net::SocketAddrThe [`net2`](https://crates.io/crates/net2) crate has assumed `std::net::SocketAddrV4` and `std::net::SocketAddrV6` have the same memory layout as the system C representation `sockaddr`. It has simply casted the pointers to convert the socket addresses to the system representation. The standard library does not say anything about the memory layout, and this will cause invalid memory access if the standard library changes the implementation. No warnings or errors will be emitted once the change happens.Package Name: net2 Installed Version: 0.2.34 Fixed Version: >= 0.2.36 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0119: Out-of-bounds write in nix::unistd::getgrouplistOn certain platforms, if a user has more than 16 groups, the `nix::unistd::getgrouplist` function will call the libc `getgrouplist` function with a length parameter greater than the size of the buffer it provides, resulting in an out-of-bounds write and memory corruption. The libc `getgrouplist` function takes an in/out parameter `ngroups` specifying the size of the group buffer. When the buffer is too small to hold all of the reqested user's group memberships, some libc implementations, including glibc and Solaris libc, will modify `ngroups` to indicate the actual number of groups for the user, in addition to returning an error. The version of `nix::unistd::getgrouplist` in nix 0.16.0 and up will resize the buffer to twice its size, but will not read or modify the `ngroups` variable. Thus, if the user has more than twice as many groups as the initial buffer size of 8, the next call to `getgrouplist` will then write past the end of the buffer. The issue would require editing /etc/groups to exploit, which is usually only editable by the root user.Package Name: nix Installed Version: 0.17.0 Fixed Version: ^0.20.2, ^0.21.2, ^0.22.2, >= 0.23.0 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0023: Incorrect check on buffer length when seeding RNGsSummary: rand_core::le::read_u32_into and read_u64_into have incorrect checks on the source buffer length, allowing the destination buffer to be under-filled. Implications: some downstream RNGs, including Hc128Rng (but not the more widely used ChaCha*Rng), allow seeding using the SeedableRng::from_seed trait-function with too short keys.Package Name: rand_core Installed Version: 0.3.1 Fixed Version: >= 0.6.2 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0023: Incorrect check on buffer length when seeding RNGsSummary: rand_core::le::read_u32_into and read_u64_into have incorrect checks on the source buffer length, allowing the destination buffer to be under-filled. Implications: some downstream RNGs, including Hc128Rng (but not the more widely used ChaCha*Rng), allow seeding using the SeedableRng::from_seed trait-function with too short keys.Package Name: rand_core Installed Version: 0.4.2 Fixed Version: >= 0.6.2 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0023: Incorrect check on buffer length when seeding RNGsSummary: rand_core::le::read_u32_into and read_u64_into have incorrect checks on the source buffer length, allowing the destination buffer to be under-filled. Implications: some downstream RNGs, including Hc128Rng (but not the more widely used ChaCha*Rng), allow seeding using the SeedableRng::from_seed trait-function with too short keys.Package Name: rand_core Installed Version: 0.5.1 Fixed Version: >= 0.6.2 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0003: Buffer overflow in SmallVec::insert_manyA bug in the `SmallVec::insert_many` method caused it to allocate a buffer that was smaller than needed. It then wrote past the end of the buffer, causing a buffer overflow and memory corruption on the heap. This bug was only triggered if the iterator passed to `insert_many` yielded more items than the lower bound returned from its `size_hint` method. The flaw was corrected in smallvec 0.6.14 and 1.6.1, by ensuring that additional space is always reserved for each item inserted. The fix also simplified the implementation of `insert_many` to use less unsafe code, so it is easier to verify its correctness. Thank you to Yechan Bae (@Qwaz) and the Rust group at Georgia Tech’s SSLab for finding and reporting this bug.Package Name: smallvec Installed Version: 1.4.0 Fixed Version: >= 0.6.14, < 1.0.0, >= 1.6.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0079: `socket2` invalidly assumes the memory layout of std::net::SocketAddrThe [`socket2`](https://crates.io/crates/socket2) crate has assumed `std::net::SocketAddrV4` and `std::net::SocketAddrV6` have the same memory layout as the system C representation `sockaddr`. It has simply casted the pointers to convert the socket addresses to the system representation. The standard library does not say anything about the memory layout, and this will cause invalid memory access if the standard library changes the implementation. No warnings or errors will be emitted once the change happens.Package Name: socket2 Installed Version: 0.3.12 Fixed Version: >= 0.3.16 References: github.com |
|
UNKNOWN |
RUSTSEC-2018-0017: `tempdir` crate has been deprecated; use `tempfile` insteadThe [`tempdir`](https://crates.io/crates/tempdir) crate has been deprecated and the functionality is merged into [`tempfile`](https://crates.io/crates/tempfile).Package Name: tempdir Installed Version: 0.3.7 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2022-0006: Data race in `Iter` and `IterMut`In the affected version of this crate, `{Iter, IterMut}::next` used a weaker memory ordering when loading values than what was required, exposing a potential data race when iterating over a `ThreadLocal`'s values. Crates using `Iter::next`, or `IterMut::next` are affected by this issue.Package Name: thread_local Installed Version: 1.0.1 Fixed Version: >= 1.1.4 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0072: Task dropped in wrong thread when aborting `LocalSet` taskWhen aborting a task with `JoinHandle::abort`, the future is dropped in the thread calling abort if the task is not currently being executed. This is incorrect for tasks spawned on a `LocalSet`. This can easily result in race conditions as many projects use `Rc` or `RefCell` in their Tokio tasks for better performance. See [tokio#3929][issue] for more details. [issue]: https://github.com/tokio-rs/tokio/issues/3929Package Name: tokio Installed Version: 0.2.21 Fixed Version: >= 1.5.1, < 1.6.0, >= 1.6.3, < 1.7.0, >= 1.7.2, < 1.8.0, >= 1.8.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0124: Data race when sending and receiving after closing a `oneshot` channelIf a `tokio::sync::oneshot` channel is closed (via the [`oneshot::Receiver::close`] method), a data race may occur if the `oneshot::Sender::send` method is called while the corresponding `oneshot::Receiver` is `await`ed or calling `try_recv`. When these methods are called concurrently on a closed channel, the two halves of the channel can concurrently access a shared memory location, resulting in a data race. This has been observed to [cause memory corruption][corruption]. Note that the race only occurs when **both** halves of the channel are used after the `Receiver` half has called `close`. Code where `close` is not used, or where the `Receiver` is not `await`ed and `try_recv` is not called after calling `close`, is not affected. See [tokio#4225][issue] for more details. [corruption]: https://github.com/tokio-rs/tokio/issues/4225#issuecomment-967434847 [issue]: https://github.com/tokio-rs/tokio/issues/4225 [`oneshot::Receiver::close`]: https://docs.rs/tokio/1.14.0/tokio/sync/oneshot/struct.Receiver.html#method.closePackage Name: tokio Installed Version: 0.2.21 Fixed Version: >= 1.8.4, < 1.9.0, >= 1.13.1 References: github.com |
|
Target: | home/circleci/.cargo/registry/src/github.com-1ecc6299db9ec823/reqwest-0.9.24/Cargo.lock | |
UNKNOWN |
RUSTSEC-2020-0006: Flaw in `realloc` allows reading unknown memoryWhen `realloc`ing, if we allocate new space, we need to copy the old allocation's bytes into the new space. There are `old_size` number of bytes in the old allocation, but we were accidentally copying `new_size` number of bytes, which could lead to copying bytes into the realloc'd space from past the chunk that we're bump allocating out of, from unknown memory. If an attacker can cause `realloc`s, and can read the `realoc`ed data back, this could allow them to read things from other regions of memory that they shouldn't be able to. For example, if some crypto keys happened to live in memory right after a chunk we were bump allocating out of, this could allow the attacker to read the crypto keys. Beyond just fixing the bug and adding a regression test, I've also taken two additional steps: 1. While we were already running the testsuite under `valgrind` in CI, because `valgrind` exits with the same code that the program did, if there are invalid reads/writes that happen not to trigger a segfault, the program can still exit OK and we will be none the wiser. I've enabled the `--error-exitcode=1` flag for `valgrind` in CI so that tests eagerly fail in these scenarios. 2. I've written a quickcheck test to exercise `realloc`. Without the bug fix in this patch, this quickcheck immediately triggers invalid reads when run under `valgrind`. We didn't previously have quickchecks that exercised `realloc` because `realloc` isn't publicly exposed directly, and instead can only be indirectly called. This new quickcheck test exercises `realloc` via `bumpalo::collections::Vec::resize` and `bumpalo::collections::Vec::shrink_to_fit` calls.Package Name: bumpalo Installed Version: 2.6.0 Fixed Version: >= 3.2.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0093: Data race in crossbeam-dequeIn the affected version of this crate, the result of the race condition is that one or more tasks in the worker queue can be popped twice instead of other tasks that are forgotten and never popped. If tasks are allocated on the heap, this can cause double free and a memory leak. If not, this still can cause a logical bug. Crates using `Stealer::steal`, `Stealer::steal_batch`, or `Stealer::steal_batch_and_pop` are affected by this issue. Credits to @kmaork for discovering, reporting and fixing the bug.Package Name: crossbeam-deque Installed Version: 0.7.2 Fixed Version: >= 0.7.4, < 0.8.0, >= 0.8.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2019-0036: Type confusion if __private_get_type_id__ is overriddenSafe Rust code can implement malfunctioning `__private_get_type_id__` and cause type confusion when downcasting, which is an undefined behavior. Users who derive `Fail` trait are not affected.Package Name: failure Installed Version: 0.1.5 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0036: failure is officially deprecated/unmaintainedThe `failure` crate is officially end-of-life: it has been marked as deprecated by the former maintainer, who has announced that there will be no updates or maintenance work on it going forward. The following are some suggested actively developed alternatives to switch to: - [`anyhow`](https://crates.io/crates/anyhow) - [`eyre`](https://crates.io/crates/eyre) - [`fehler`](https://crates.io/crates/fehler) - [`snafu`](https://crates.io/crates/snafu) - [`thiserror`](https://crates.io/crates/thiserror)Package Name: failure Installed Version: 0.1.5 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0020: Multiple Transfer-Encoding headers misinterprets request payloadhyper's HTTP server code had a flaw that incorrectly understands some requests with multiple transfer-encoding headers to have a chunked payload, when it should have been rejected as illegal. This combined with an upstream HTTP proxy that understands the request payload boundary differently can result in "request smuggling" or "desync attacks".Package Name: hyper Installed Version: 0.12.35 Fixed Version: >= 0.14.3, 0.13.10, 0.12.36 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0078: Lenient `hyper` header parsing of `Content-Length` could allow request smuggling`hyper`'s HTTP header parser accepted, according to RFC 7230, illegal contents inside `Content-Length` headers. Due to this, upstream HTTP proxies that ignore the header may still forward them along if it chooses to ignore the error. To be vulnerable, `hyper` must be used as an HTTP/1 server and using an HTTP proxy upstream that ignores the header's contents but still forwards it. Due to all the factors that must line up, an attack exploiting this vulnerability is unlikely.Package Name: hyper Installed Version: 0.12.35 Fixed Version: >= 0.14.10 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0079: Integer overflow in `hyper`'s parsing of the `Transfer-Encoding` header leads to data lossWhen decoding chunk sizes that are too large, `hyper`'s code would encounter an integer overflow. Depending on the situation, this could lead to data loss from an incorrect total size, or in rarer cases, a request smuggling attack. To be vulnerable, you must be using `hyper` for any HTTP/1 purpose, including as a client or server, and consumers must send requests or responses that specify a chunk size greater than 18 exabytes. For a possible request smuggling attack to be possible, any upstream proxies must accept a chunk size greater than 64 bits.Package Name: hyper Installed Version: 0.12.35 Fixed Version: >= 0.14.10 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0026: linked-hash-map creates uninitialized NonNull pointerAffected versions of this crate called `mem::uninitialized()` to create a `NonNull<T>`, which is undefined behavior. The flaw was corrected by avoiding the use of `mem::uninitialized()`.Package Name: linked-hash-map Installed Version: 0.5.2 Fixed Version: >= 0.5.3 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0070: Some lock_api lock guard objects can cause data racesAffected versions of lock_api had unsound implementations of the `Send` or `Sync` traits for some guard objects, namely: * MappedMutexGuard * MappedRwLockReadGuard * MappedRwLockWriteGuard * RwLockReadGuard * RwLockWriteGuard These guards could allow data races through types that are not safe to `Send` across thread boundaries in safe Rust code. This issue was fixed by changing the trait bounds on the `Mapped` guard types and removing the `Sync` trait for the `RwLock` guards.Package Name: lock_api Installed Version: 0.3.2 Fixed Version: >= 0.4.2 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0081: `mio` invalidly assumes the memory layout of std::net::SocketAddrThe [`mio`](https://crates.io/crates/mio) crate has assumed `std::net::SocketAddrV4` and `std::net::SocketAddrV6` have the same memory layout as the system C representation `sockaddr`. It has simply casted the pointers to convert the socket addresses to the system representation. The standard library does not say anything about the memory layout, and this will cause invalid memory access if the standard library changes the implementation. No warnings or errors will be emitted once the change happens.Package Name: mio Installed Version: 0.6.21 Fixed Version: >= 0.7.6 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0080: `miow` invalidly assumes the memory layout of std::net::SocketAddrThe [`miow`](https://crates.io/crates/miow) crate has assumed `std::net::SocketAddrV4` and `std::net::SocketAddrV6` have the same memory layout as the system C representation `sockaddr`. It has simply casted the pointers to convert the socket addresses to the system representation. The standard library does not say anything about the memory layout, and this will cause invalid memory access if the standard library changes the implementation. No warnings or errors will be emitted once the change happens.Package Name: miow Installed Version: 0.2.1 Fixed Version: ^ 0.2.2, >= 0.3.6 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0016: `net2` crate has been deprecated; use `socket2` insteadThe [`net2`](https://crates.io/crates/net2) crate has been deprecated and users are encouraged to considered [`socket2`](https://crates.io/crates/socket2) instead.Package Name: net2 Installed Version: 0.2.33 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0078: `net2` invalidly assumes the memory layout of std::net::SocketAddrThe [`net2`](https://crates.io/crates/net2) crate has assumed `std::net::SocketAddrV4` and `std::net::SocketAddrV6` have the same memory layout as the system C representation `sockaddr`. It has simply casted the pointers to convert the socket addresses to the system representation. The standard library does not say anything about the memory layout, and this will cause invalid memory access if the standard library changes the implementation. No warnings or errors will be emitted once the change happens.Package Name: net2 Installed Version: 0.2.33 Fixed Version: >= 0.2.36 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0015: Crash causing Denial of Service attackServer or client applications that call the SSL_check_chain() function during or after a TLS 1.3 handshake may crash due to a NULL pointer dereference as a result of incorrect handling of the "signature_algorithms_cert" TLS extension. The crash occurs if an invalid or unrecognised signature algorithm is received from the peer. This could be exploited by a malicious peer in a Denial of Service attack.Package Name: openssl-src Installed Version: 111.6.0+1.1.1d Fixed Version: >= 111.9 References: www.openssl.org |
|
UNKNOWN |
RUSTSEC-2021-0055: NULL pointer deref in signature_algorithms processingAn OpenSSL TLS server may crash if sent a maliciously crafted renegotiation ClientHello message from a client. If a TLSv1.2 renegotiation ClientHello omits the signature_algorithms extension (where it was present in the initial ClientHello), but includes a signature_algorithms_cert extension then a NULL pointer dereference will result, leading to a crash and a denial of service attack. A server is only vulnerable if it has TLSv1.2 and renegotiation enabled (which is the default configuration). OpenSSL TLS clients are not impacted by this issue.Package Name: openssl-src Installed Version: 111.6.0+1.1.1d Fixed Version: >= 111.15 References: www.openssl.org |
|
UNKNOWN |
RUSTSEC-2021-0056: CA certificate check bypass with X509_V_FLAG_X509_STRICTThe X509_V_FLAG_X509_STRICT flag enables additional security checks of the certificates present in a certificate chain. It is not set by default. Starting from OpenSSL version 1.1.1h a check to disallow certificates in the chain that have explicitly encoded elliptic curve parameters was added as an additional strict check. An error in the implementation of this check meant that the result of a previous check to confirm that certificates in the chain are valid CA certificates was overwritten. This effectively bypasses the check that non-CA certificates must not be able to issue other certificates. If a "purpose" has been configured then there is a subsequent opportunity for checks that the certificate is a valid CA. All of the named "purpose" values implemented in libcrypto perform this check. Therefore, where a purpose is set the certificate chain will still be rejected even when the strict flag has been used. A purpose is set by default in libssl client and server certificate verification routines, but it can be overridden or removed by an application. In order to be affected, an application must explicitly set the X509_V_FLAG_X509_STRICT verification flag and either not set a purpose for the certificate verification or, in the case of TLS client or server applications, override the default purpose.Package Name: openssl-src Installed Version: 111.6.0+1.1.1d Fixed Version: >= 111.15 References: www.openssl.org |
|
UNKNOWN |
RUSTSEC-2021-0057: Integer overflow in CipherUpdateCalls to `EVP_CipherUpdate`, `EVP_EncryptUpdate` and `EVP_DecryptUpdate` may overflow the output length argument in some cases where the input length is close to the maximum permissable length for an integer on the platform. In such cases the return value from the function call will be 1 (indicating success), but the output length value will be negative. This could cause applications to behave incorrectly or crash.Package Name: openssl-src Installed Version: 111.6.0+1.1.1d Fixed Version: >= 111.14 References: www.openssl.org |
|
UNKNOWN |
RUSTSEC-2021-0058: Null pointer deref in `X509_issuer_and_serial_hash()`The OpenSSL public API function `X509_issuer_and_serial_hash()` attempts to create a unique hash value based on the issuer and serial number data contained within an X509 certificate. However it fails to correctly handle any errors that may occur while parsing the issuer field (which might occur if the issuer field is maliciously constructed). This may subsequently result in a NULL pointer deref and a crash leading to a potential denial of service attack. The function `X509_issuer_and_serial_hash()` is never directly called by OpenSSL itself so applications are only vulnerable if they use this function directly and they use it on certificates that may have been obtained from untrusted sources.Package Name: openssl-src Installed Version: 111.6.0+1.1.1d Fixed Version: >= 111.14 References: www.openssl.org |
|
UNKNOWN |
RUSTSEC-2021-0097: SM2 Decryption Buffer OverflowIn order to decrypt SM2 encrypted data an application is expected to call the API function `EVP_PKEY_decrypt()`. Typically an application will call this function twice. The first time, on entry, the "out" parameter can be NULL and, on exit, the "outlen" parameter is populated with the buffer size required to hold the decrypted plaintext. The application can then allocate a sufficiently sized buffer and call `EVP_PKEY_decrypt()` again, but this time passing a non-NULL value for the "out" parameter. A bug in the implementation of the SM2 decryption code means that the calculation of the buffer size required to hold the plaintext returned by the first call to `EVP_PKEY_decrypt()` can be smaller than the actual size required by the second call. This can lead to a buffer overflow when `EVP_PKEY_decrypt()` is called by the application a second time with a buffer that is too small. A malicious attacker who is able present SM2 content for decryption to an application could cause attacker chosen data to overflow the buffer by up to a maximum of 62 bytes altering the contents of other data held after the buffer, possibly changing application behaviour or causing the application to crash. The location of the buffer is application dependent but is typically heap allocated.Package Name: openssl-src Installed Version: 111.6.0+1.1.1d Fixed Version: >= 111.16 References: www.openssl.org |
|
UNKNOWN |
RUSTSEC-2021-0098: Read buffer overruns processing ASN.1 stringsASN.1 strings are represented internally within OpenSSL as an ASN1_STRING structure which contains a buffer holding the string data and a field holding the buffer length. This contrasts with normal C strings which are represented as a buffer for the string data which is terminated with a NUL (0) byte. Although not a strict requirement, ASN.1 strings that are parsed using OpenSSL's own "d2i" functions (and other similar parsing functions) as well as any string whose value has been set with the ASN1_STRING_set() function will additionally NUL terminate the byte array in the ASN1_STRING structure. However, it is possible for applications to directly construct valid ASN1_STRING structures which do not NUL terminate the byte array by directly setting the "data" and "length" fields in the ASN1_STRING array. This can also happen by using the `ASN1_STRING_set0()` function. Numerous OpenSSL functions that print ASN.1 data have been found to assume that the ASN1_STRING byte array will be NUL terminated, even though this is not guaranteed for strings that have been directly constructed. Where an application requests an ASN.1 structure to be printed, and where that ASN.1 structure contains ASN1_STRINGs that have been directly constructed by the application without NUL terminating the "data" field, then a read buffer overrun can occur. The same thing can also occur during name constraints processing of certificates (for example if a certificate has been directly constructed by the application instead of loading it via the OpenSSL parsing functions, and the certificate contains non NUL terminated ASN1_STRING structures). It can also occur in the `X509_get1_email()`, `X509_REQ_get1_email()` and `X509_get1_ocsp()` functions. If a malicious actor can cause an application to directly construct an ASN1_STRING and then process it through one of the affected OpenSSL functions then this issue could be hit. This might result in a crash (causing a Denial of Service attack). It could also result in the disclosure of private memory contents (such as private keys, or sensitive plaintext).Package Name: openssl-src Installed Version: 111.6.0+1.1.1d Fixed Version: >= 111.16 References: www.openssl.org |
|
UNKNOWN |
RUSTSEC-2021-0129: Invalid handling of `X509_verify_cert()` internal errors in libsslInternally libssl in OpenSSL calls `X509_verify_cert()` on the client side to verify a certificate supplied by a server. That function may return a negative return value to indicate an internal error (for example out of memory). Such a negative return value is mishandled by OpenSSL and will cause an IO function (such as `SSL_connect()` or `SSL_do_handshake()`) to not indicate success and a subsequent call to `SSL_get_error()` to return the value `SSL_ERROR_WANT_RETRY_VERIFY`. This return value is only supposed to be returned by OpenSSL if the application has previously called `SSL_CTX_set_cert_verify_callback()`. Since most applications do not do this the `SSL_ERROR_WANT_RETRY_VERIFY` return value from `SSL_get_error()` will be totally unexpected and applications may not behave correctly as a result. The exact behaviour will depend on the application but it could result in crashes, infinite loops or other similar incorrect responses. This issue is made more serious in combination with a separate bug in OpenSSL 3.0 that will cause `X509_verify_cert()` to indicate an internal error when processing a certificate chain. This will occur where a certificate does not include the Subject Alternative Name extension but where a Certificate Authority has enforced name constraints. This issue can occur even with valid chains.Package Name: openssl-src Installed Version: 111.6.0+1.1.1d Fixed Version: >= 300.0.4 References: www.openssl.org |
|
UNKNOWN |
RUSTSEC-2021-0023: Incorrect check on buffer length when seeding RNGsSummary: rand_core::le::read_u32_into and read_u64_into have incorrect checks on the source buffer length, allowing the destination buffer to be under-filled. Implications: some downstream RNGs, including Hc128Rng (but not the more widely used ChaCha*Rng), allow seeding using the SeedableRng::from_seed trait-function with too short keys.Package Name: rand_core Installed Version: 0.3.1 Fixed Version: >= 0.6.2 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0023: Incorrect check on buffer length when seeding RNGsSummary: rand_core::le::read_u32_into and read_u64_into have incorrect checks on the source buffer length, allowing the destination buffer to be under-filled. Implications: some downstream RNGs, including Hc128Rng (but not the more widely used ChaCha*Rng), allow seeding using the SeedableRng::from_seed trait-function with too short keys.Package Name: rand_core Installed Version: 0.4.2 Fixed Version: >= 0.6.2 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0023: Incorrect check on buffer length when seeding RNGsSummary: rand_core::le::read_u32_into and read_u64_into have incorrect checks on the source buffer length, allowing the destination buffer to be under-filled. Implications: some downstream RNGs, including Hc128Rng (but not the more widely used ChaCha*Rng), allow seeding using the SeedableRng::from_seed trait-function with too short keys.Package Name: rand_core Installed Version: 0.5.1 Fixed Version: >= 0.6.2 References: github.com |
|
UNKNOWN |
RUSTSEC-2018-0018: smallvec creates uninitialized value of any typeAffected versions of this crate called `mem::uninitialized()` to create values of a user-supplied type `T`. This is unsound e.g. if `T` is a reference type (which must be non-null and thus may not remain uninitialized). The flaw was corrected by avoiding the use of `mem::uninitialized()`, using `MaybeUninit` instead.Package Name: smallvec Installed Version: 0.6.10 Fixed Version: >= 0.6.13 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0003: Buffer overflow in SmallVec::insert_manyA bug in the `SmallVec::insert_many` method caused it to allocate a buffer that was smaller than needed. It then wrote past the end of the buffer, causing a buffer overflow and memory corruption on the heap. This bug was only triggered if the iterator passed to `insert_many` yielded more items than the lower bound returned from its `size_hint` method. The flaw was corrected in smallvec 0.6.14 and 1.6.1, by ensuring that additional space is always reserved for each item inserted. The fix also simplified the implementation of `insert_many` to use less unsafe code, so it is easier to verify its correctness. Thank you to Yechan Bae (@Qwaz) and the Rust group at Georgia Tech’s SSLab for finding and reporting this bug.Package Name: smallvec Installed Version: 0.6.10 Fixed Version: >= 0.6.14, < 1.0.0, >= 1.6.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0079: `socket2` invalidly assumes the memory layout of std::net::SocketAddrThe [`socket2`](https://crates.io/crates/socket2) crate has assumed `std::net::SocketAddrV4` and `std::net::SocketAddrV6` have the same memory layout as the system C representation `sockaddr`. It has simply casted the pointers to convert the socket addresses to the system representation. The standard library does not say anything about the memory layout, and this will cause invalid memory access if the standard library changes the implementation. No warnings or errors will be emitted once the change happens.Package Name: socket2 Installed Version: 0.3.11 Fixed Version: >= 0.3.16 References: github.com |
|
UNKNOWN |
RUSTSEC-2019-0031: spin is no longer actively maintainedThe author of the `spin` crate does not have time or interest to maintain it. Consider the following alternatives (all of which support `no_std`): - [`conquer-once`](https://github.com/oliver-giersch/conquer-once) - [`lock_api`](https://crates.io/crates/lock_api) (a subproject of `parking_lot`) - [`spinning_top`](https://github.com/rust-osdev/spinning_top) spinlock crate built on `lock_api` - [`spinning`](https://github.com/4lDO2/spinning-rs)Package Name: spin Installed Version: 0.5.2 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2022-0006: Data race in `Iter` and `IterMut`In the affected version of this crate, `{Iter, IterMut}::next` used a weaker memory ordering when loading values than what was required, exposing a potential data race when iterating over a `ThreadLocal`'s values. Crates using `Iter::next`, or `IterMut::next` are affected by this issue.Package Name: thread_local Installed Version: 0.3.6 Fixed Version: >= 1.1.4 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0071: ## ReferencesUnix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library. The affected functions from time 0.2.7 through 0.2.22 are: - `time::UtcOffset::local_offset_at` - `time::UtcOffset::try_local_offset_at` - `time::UtcOffset::current_local_offset` - `time::UtcOffset::try_current_local_offset` - `time::OffsetDateTime::now_local` - `time::OffsetDateTime::try_now_local` The affected functions in time 0.1 (all versions) are: - `at` - `at_utc` - `now` Non-Unix targets (including Windows and wasm) are unaffected. Pending a proper fix, the internal method that determines the local offset has been modified to always return `None` on the affected operating systems. This has the effect of returning an `Err` on the `try_*` methods and `UTC` on the non-`try_*` methods. Users and library authors with time in their dependency tree should perform `cargo update`, which will pull in the updated, unaffected code. Users of time 0.1 do not have a patch and should upgrade to an unaffected version: time 0.2.23 or greater or the 0.3 series. No workarounds are known. time-rs/time#293Package Name: time Installed Version: 0.1.42 Fixed Version: >= 0.2.23 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0072: Task dropped in wrong thread when aborting `LocalSet` taskWhen aborting a task with `JoinHandle::abort`, the future is dropped in the thread calling abort if the task is not currently being executed. This is incorrect for tasks spawned on a `LocalSet`. This can easily result in race conditions as many projects use `Rc` or `RefCell` in their Tokio tasks for better performance. See [tokio#3929][issue] for more details. [issue]: https://github.com/tokio-rs/tokio/issues/3929Package Name: tokio Installed Version: 0.1.22 Fixed Version: >= 1.5.1, < 1.6.0, >= 1.6.3, < 1.7.0, >= 1.7.2, < 1.8.0, >= 1.8.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0124: Data race when sending and receiving after closing a `oneshot` channelIf a `tokio::sync::oneshot` channel is closed (via the [`oneshot::Receiver::close`] method), a data race may occur if the `oneshot::Sender::send` method is called while the corresponding `oneshot::Receiver` is `await`ed or calling `try_recv`. When these methods are called concurrently on a closed channel, the two halves of the channel can concurrently access a shared memory location, resulting in a data race. This has been observed to [cause memory corruption][corruption]. Note that the race only occurs when **both** halves of the channel are used after the `Receiver` half has called `close`. Code where `close` is not used, or where the `Receiver` is not `await`ed and `try_recv` is not called after calling `close`, is not affected. See [tokio#4225][issue] for more details. [corruption]: https://github.com/tokio-rs/tokio/issues/4225#issuecomment-967434847 [issue]: https://github.com/tokio-rs/tokio/issues/4225 [`oneshot::Receiver::close`]: https://docs.rs/tokio/1.14.0/tokio/sync/oneshot/struct.Receiver.html#method.closePackage Name: tokio Installed Version: 0.1.22 Fixed Version: >= 1.8.4, < 1.9.0, >= 1.13.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0019: tokio-rustls reads may cause excessive memory usage`tokio-rustls` does not call `process_new_packets` immediately after `read`, so the expected termination condition `wants_read` always returns true. As long as new incoming data arrives faster than it is processed and the reader does not return pending, data will be buffered. This may cause DoS.Package Name: tokio-rustls Installed Version: 0.10.2 Fixed Version: >= 0.12.3, < 0.13.0, >= 0.13.1 References: github.com |
|
Target: | home/circleci/.cargo/registry/src/github.com-1ecc6299db9ec823/ryu-1.0.5/Cargo.lock | |
UNKNOWN |
RUSTSEC-2021-0023: Incorrect check on buffer length when seeding RNGsSummary: rand_core::le::read_u32_into and read_u64_into have incorrect checks on the source buffer length, allowing the destination buffer to be under-filled. Implications: some downstream RNGs, including Hc128Rng (but not the more widely used ChaCha*Rng), allow seeding using the SeedableRng::from_seed trait-function with too short keys.Package Name: rand_core Installed Version: 0.5.1 Fixed Version: >= 0.6.2 References: github.com |
|
Target: | home/circleci/.cargo/registry/src/github.com-1ecc6299db9ec823/sccache-0.2.15/Cargo.lock | |
UNKNOWN |
RUSTSEC-2020-0159: ## ReferencesUnix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library. No workarounds are known. - [time-rs/time#293](https://github.com/time-rs/time/issues/293)Package Name: chrono Installed Version: 0.4.19 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0064: `cpuid-bool` has been renamed to `cpufeatures`Please use the `cpufeatures`` crate going forward: <https://github.com/RustCrypto/utils/tree/master/cpufeatures> There will be no further releases of `cpuid-bool`.Package Name: cpuid-bool Installed Version: 0.1.2 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0093: Data race in crossbeam-dequeIn the affected version of this crate, the result of the race condition is that one or more tasks in the worker queue can be popped twice instead of other tasks that are forgotten and never popped. If tasks are allocated on the heap, this can cause double free and a memory leak. If not, this still can cause a logical bug. Crates using `Stealer::steal`, `Stealer::steal_batch`, or `Stealer::steal_batch_and_pop` are affected by this issue. Credits to @kmaork for discovering, reporting and fixing the bug.Package Name: crossbeam-deque Installed Version: 0.7.3 Fixed Version: >= 0.7.4, < 0.8.0, >= 0.8.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0095: difference is unmaintainedThe author of the `difference` crate is unresponsive. Maintained alternatives: - [`dissimilar`](https://crates.io/crates/dissimilar) - [`similar`](https://crates.io/crates/similar) - [`treediff`](https://crates.io/crates/treediff) - [`diffus`](https://crates.io/crates/diffus)Package Name: difference Installed Version: 2.0.0 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0054: directories is unmaintained, use directories-next insteadThe `directories` crate is not maintained any more; use [`directories-next`](https://crates.io/crates/directories-next) instead.Package Name: directories Installed Version: 3.0.1 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0053: dirs is unmaintained, use dirs-next insteadThe `dirs` crate is not maintained any more; use [`dirs-next`](https://crates.io/crates/dirs-next) instead.Package Name: dirs Installed Version: 1.0.5 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2019-0036: Type confusion if __private_get_type_id__ is overriddenSafe Rust code can implement malfunctioning `__private_get_type_id__` and cause type confusion when downcasting, which is an undefined behavior. Users who derive `Fail` trait are not affected.Package Name: failure Installed Version: 0.1.8 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0036: failure is officially deprecated/unmaintainedThe `failure` crate is officially end-of-life: it has been marked as deprecated by the former maintainer, who has announced that there will be no updates or maintenance work on it going forward. The following are some suggested actively developed alternatives to switch to: - [`anyhow`](https://crates.io/crates/anyhow) - [`eyre`](https://crates.io/crates/eyre) - [`fehler`](https://crates.io/crates/fehler) - [`snafu`](https://crates.io/crates/snafu) - [`thiserror`](https://crates.io/crates/thiserror)Package Name: failure Installed Version: 0.1.8 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0020: Multiple Transfer-Encoding headers misinterprets request payloadhyper's HTTP server code had a flaw that incorrectly understands some requests with multiple transfer-encoding headers to have a chunked payload, when it should have been rejected as illegal. This combined with an upstream HTTP proxy that understands the request payload boundary differently can result in "request smuggling" or "desync attacks".Package Name: hyper Installed Version: 0.12.35 Fixed Version: >= 0.14.3, 0.13.10, 0.12.36 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0078: Lenient `hyper` header parsing of `Content-Length` could allow request smuggling`hyper`'s HTTP header parser accepted, according to RFC 7230, illegal contents inside `Content-Length` headers. Due to this, upstream HTTP proxies that ignore the header may still forward them along if it chooses to ignore the error. To be vulnerable, `hyper` must be used as an HTTP/1 server and using an HTTP proxy upstream that ignores the header's contents but still forwards it. Due to all the factors that must line up, an attack exploiting this vulnerability is unlikely.Package Name: hyper Installed Version: 0.12.35 Fixed Version: >= 0.14.10 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0079: Integer overflow in `hyper`'s parsing of the `Transfer-Encoding` header leads to data lossWhen decoding chunk sizes that are too large, `hyper`'s code would encounter an integer overflow. Depending on the situation, this could lead to data loss from an incorrect total size, or in rarer cases, a request smuggling attack. To be vulnerable, you must be using `hyper` for any HTTP/1 purpose, including as a client or server, and consumers must send requests or responses that specify a chunk size greater than 18 exabytes. For a possible request smuggling attack to be possible, any upstream proxies must accept a chunk size greater than 64 bits.Package Name: hyper Installed Version: 0.12.35 Fixed Version: >= 0.14.10 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0070: Some lock_api lock guard objects can cause data racesAffected versions of lock_api had unsound implementations of the `Send` or `Sync` traits for some guard objects, namely: * MappedMutexGuard * MappedRwLockReadGuard * MappedRwLockWriteGuard * RwLockReadGuard * RwLockWriteGuard These guards could allow data races through types that are not safe to `Send` across thread boundaries in safe Rust code. This issue was fixed by changing the trait bounds on the `Mapped` guard types and removing the `Sync` trait for the `RwLock` guards.Package Name: lock_api Installed Version: 0.3.4 Fixed Version: >= 0.4.2 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0081: `mio` invalidly assumes the memory layout of std::net::SocketAddrThe [`mio`](https://crates.io/crates/mio) crate has assumed `std::net::SocketAddrV4` and `std::net::SocketAddrV6` have the same memory layout as the system C representation `sockaddr`. It has simply casted the pointers to convert the socket addresses to the system representation. The standard library does not say anything about the memory layout, and this will cause invalid memory access if the standard library changes the implementation. No warnings or errors will be emitted once the change happens.Package Name: mio Installed Version: 0.6.23 Fixed Version: >= 0.7.6 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0021: `nb-connect` invalidly assumes the memory layout of std::net::SocketAddrThe [`nb-connect`](https://crates.io/crates/nb-connect) crate has assumed `std::net::SocketAddrV4` and `std::net::SocketAddrV6` have the same memory layout as the system C representation `sockaddr`. It has simply casted the pointers to convert the socket addresses to the system representation. The standard library does not say anything about the memory layout, and this will cause invalid memory access if the standard library changes the implementation. No warnings or errors will be emitted once the change happens.Package Name: nb-connect Installed Version: 1.0.2 Fixed Version: >= 1.0.3 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0016: `net2` crate has been deprecated; use `socket2` insteadThe [`net2`](https://crates.io/crates/net2) crate has been deprecated and users are encouraged to considered [`socket2`](https://crates.io/crates/socket2) instead.Package Name: net2 Installed Version: 0.2.37 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0119: Out-of-bounds write in nix::unistd::getgrouplistOn certain platforms, if a user has more than 16 groups, the `nix::unistd::getgrouplist` function will call the libc `getgrouplist` function with a length parameter greater than the size of the buffer it provides, resulting in an out-of-bounds write and memory corruption. The libc `getgrouplist` function takes an in/out parameter `ngroups` specifying the size of the group buffer. When the buffer is too small to hold all of the reqested user's group memberships, some libc implementations, including glibc and Solaris libc, will modify `ngroups` to indicate the actual number of groups for the user, in addition to returning an error. The version of `nix::unistd::getgrouplist` in nix 0.16.0 and up will resize the buffer to twice its size, but will not read or modify the `ngroups` variable. Thus, if the user has more than twice as many groups as the initial buffer size of 8, the next call to `getgrouplist` will then write past the end of the buffer. The issue would require editing /etc/groups to exploit, which is usually only editable by the root user.Package Name: nix Installed Version: 0.14.1 Fixed Version: ^0.20.2, ^0.21.2, ^0.22.2, >= 0.23.0 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0119: Out-of-bounds write in nix::unistd::getgrouplistOn certain platforms, if a user has more than 16 groups, the `nix::unistd::getgrouplist` function will call the libc `getgrouplist` function with a length parameter greater than the size of the buffer it provides, resulting in an out-of-bounds write and memory corruption. The libc `getgrouplist` function takes an in/out parameter `ngroups` specifying the size of the group buffer. When the buffer is too small to hold all of the reqested user's group memberships, some libc implementations, including glibc and Solaris libc, will modify `ngroups` to indicate the actual number of groups for the user, in addition to returning an error. The version of `nix::unistd::getgrouplist` in nix 0.16.0 and up will resize the buffer to twice its size, but will not read or modify the `ngroups` variable. Thus, if the user has more than twice as many groups as the initial buffer size of 8, the next call to `getgrouplist` will then write past the end of the buffer. The issue would require editing /etc/groups to exploit, which is usually only editable by the root user.Package Name: nix Installed Version: 0.19.1 Fixed Version: ^0.20.2, ^0.21.2, ^0.22.2, >= 0.23.0 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0023: Incorrect check on buffer length when seeding RNGsSummary: rand_core::le::read_u32_into and read_u64_into have incorrect checks on the source buffer length, allowing the destination buffer to be under-filled. Implications: some downstream RNGs, including Hc128Rng (but not the more widely used ChaCha*Rng), allow seeding using the SeedableRng::from_seed trait-function with too short keys.Package Name: rand_core Installed Version: 0.5.1 Fixed Version: >= 0.6.2 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0023: Incorrect check on buffer length when seeding RNGsSummary: rand_core::le::read_u32_into and read_u64_into have incorrect checks on the source buffer length, allowing the destination buffer to be under-filled. Implications: some downstream RNGs, including Hc128Rng (but not the more widely used ChaCha*Rng), allow seeding using the SeedableRng::from_seed trait-function with too short keys.Package Name: rand_core Installed Version: 0.4.2 Fixed Version: >= 0.6.2 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0023: Incorrect check on buffer length when seeding RNGsSummary: rand_core::le::read_u32_into and read_u64_into have incorrect checks on the source buffer length, allowing the destination buffer to be under-filled. Implications: some downstream RNGs, including Hc128Rng (but not the more widely used ChaCha*Rng), allow seeding using the SeedableRng::from_seed trait-function with too short keys.Package Name: rand_core Installed Version: 0.3.1 Fixed Version: >= 0.6.2 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0100: Miscomputed results when using AVX2 backendThe v0.9.7 release of the `sha2` crate introduced a new AVX2-accelerated backend which was automatically enabled for all x86/x86_64 CPUs where AVX2 support was autodetected at runtime. This backend was buggy and would miscompute results for long messages (i.e. messages spanning multiple SHA blocks). The crate has since been yanked, but any users who upgraded to v0.9.7 should immediately upgrade to v0.9.8 and recompute any hashes which were previously computed by v0.9.7.Package Name: sha2 Installed Version: 0.9.2 Fixed Version: >= 0.9.8 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0125: Panic on incorrect date input to `simple_asn1`Version 0.6.0 of the `simple_asn1` crate panics on certain malformed inputs to its parsing functions, including `from_der` and `der_decode`. Because this crate is frequently used with inputs from the network, this should be considered a security vulnerability. The issue occurs when parsing the old ASN.1 "UTCTime" time format. If an attacker provides a UTCTime where the first character is ASCII but the second character is above 0x7f, a string slice operation in the `from_der_` function will try to slice into the middle of a UTF-8 character, and cause a panic. This error was introduced in commit [`d7d39d709577710e9dc8`](https://github.com/acw/simple_asn1/commit/d7d39d709577710e9dc8833ee57d200eef366db8), which updated `simple_asn1` to use `time` instead of `chrono` because of [`RUSTSEC-2020-159`](https://rustsec.org/advisories/RUSTSEC-2020-0159). Versions of `simple_asn1` before 0.6.0 are not affected by this issue. The [patch](https://github.com/acw/simple_asn1/pull/28) was applied in `simple_asn1` version 0.6.1.Package Name: simple_asn1 Installed Version: 0.4.1 Fixed Version: >=0.6.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0003: Buffer overflow in SmallVec::insert_manyA bug in the `SmallVec::insert_many` method caused it to allocate a buffer that was smaller than needed. It then wrote past the end of the buffer, causing a buffer overflow and memory corruption on the heap. This bug was only triggered if the iterator passed to `insert_many` yielded more items than the lower bound returned from its `size_hint` method. The flaw was corrected in smallvec 0.6.14 and 1.6.1, by ensuring that additional space is always reserved for each item inserted. The fix also simplified the implementation of `insert_many` to use less unsafe code, so it is easier to verify its correctness. Thank you to Yechan Bae (@Qwaz) and the Rust group at Georgia Tech’s SSLab for finding and reporting this bug.Package Name: smallvec Installed Version: 0.6.13 Fixed Version: >= 0.6.14, < 1.0.0, >= 1.6.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2019-0031: spin is no longer actively maintainedThe author of the `spin` crate does not have time or interest to maintain it. Consider the following alternatives (all of which support `no_std`): - [`conquer-once`](https://github.com/oliver-giersch/conquer-once) - [`lock_api`](https://crates.io/crates/lock_api) (a subproject of `parking_lot`) - [`spinning_top`](https://github.com/rust-osdev/spinning_top) spinlock crate built on `lock_api` - [`spinning`](https://github.com/4lDO2/spinning-rs)Package Name: spin Installed Version: 0.5.2 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0080: Links in archive can create arbitrary directoriesWhen unpacking a tarball that contains a symlink the `tar` crate may create directories outside of the directory it's supposed to unpack into. The function errors when it's trying to create a file, but the folders are already created at this point. use std::{io, io::Result}; use tar::{Archive, Builder, EntryType, Header}; fn main() -> Result<()> { let mut buf = Vec::new(); { let mut builder = Builder::new(&mut buf); // symlink: parent -> .. let mut header = Header::new_gnu(); header.set_path("symlink")?; header.set_link_name("..")?; header.set_entry_type(EntryType::Symlink); header.set_size(0); header.set_cksum(); builder.append(&header, io::empty())?; // file: symlink/exploit/foo/bar let mut header = Header::new_gnu(); header.set_path("symlink/exploit/foo/bar")?; header.set_size(0); header.set_cksum(); builder.append(&header, io::empty())?; builder.finish()?; }; Archive::new(&*buf).unpack("demo") } This has been fixed in https://github.com/alexcrichton/tar-rs/pull/259 and is published as `tar` 0.4.36. Thanks to Martin Michaelis (@mgjm) for discovering and reporting this, and Nikhil Benesch (@benesch) for the fix!Package Name: tar Installed Version: 0.4.30 Fixed Version: >= 0.4.36 References: github.com |
|
UNKNOWN |
RUSTSEC-2018-0017: `tempdir` crate has been deprecated; use `tempfile` insteadThe [`tempdir`](https://crates.io/crates/tempdir) crate has been deprecated and the functionality is merged into [`tempfile`](https://crates.io/crates/tempfile).Package Name: tempdir Installed Version: 0.3.7 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2018-0015: term is looking for a new maintainerThe author of the `term` crate does not have time to maintain it and is looking for a new maintainer. Some maintained alternatives you can potentially switch to instead, depending on your needs: - [`crossterm`](https://github.com/crossterm-rs/crossterm) - [`termcolor`](https://crates.io/crates/termcolor) - [`yansi`](https://crates.io/crates/yansi)Package Name: term Installed Version: 0.5.2 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2022-0006: Data race in `Iter` and `IterMut`In the affected version of this crate, `{Iter, IterMut}::next` used a weaker memory ordering when loading values than what was required, exposing a potential data race when iterating over a `ThreadLocal`'s values. Crates using `Iter::next`, or `IterMut::next` are affected by this issue.Package Name: thread_local Installed Version: 1.1.0 Fixed Version: >= 1.1.4 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0071: ## ReferencesUnix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library. The affected functions from time 0.2.7 through 0.2.22 are: - `time::UtcOffset::local_offset_at` - `time::UtcOffset::try_local_offset_at` - `time::UtcOffset::current_local_offset` - `time::UtcOffset::try_current_local_offset` - `time::OffsetDateTime::now_local` - `time::OffsetDateTime::try_now_local` The affected functions in time 0.1 (all versions) are: - `at` - `at_utc` - `now` Non-Unix targets (including Windows and wasm) are unaffected. Pending a proper fix, the internal method that determines the local offset has been modified to always return `None` on the affected operating systems. This has the effect of returning an `Err` on the `try_*` methods and `UTC` on the non-`try_*` methods. Users and library authors with time in their dependency tree should perform `cargo update`, which will pull in the updated, unaffected code. Users of time 0.1 do not have a patch and should upgrade to an unaffected version: time 0.2.23 or greater or the 0.3 series. No workarounds are known. time-rs/time#293Package Name: time Installed Version: 0.1.44 Fixed Version: >= 0.2.23 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0031: HTTP Request smuggling through malformed Transfer Encoding headersHTTP pipelining issues and request smuggling attacks are possible due to incorrect Transfer encoding header parsing. It is possible conduct HTTP request smuggling attacks (CL:TE/TE:TE) by sending invalid Transfer Encoding headers. By manipulating the HTTP response the attacker could poison a web-cache, perform an XSS attack, or obtain sensitive information from requests other than their own.Package Name: tiny_http Installed Version: 0.6.2 Fixed Version: >= 0.8.0, ^0.6.3 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0072: Task dropped in wrong thread when aborting `LocalSet` taskWhen aborting a task with `JoinHandle::abort`, the future is dropped in the thread calling abort if the task is not currently being executed. This is incorrect for tasks spawned on a `LocalSet`. This can easily result in race conditions as many projects use `Rc` or `RefCell` in their Tokio tasks for better performance. See [tokio#3929][issue] for more details. [issue]: https://github.com/tokio-rs/tokio/issues/3929Package Name: tokio Installed Version: 0.1.22 Fixed Version: >= 1.5.1, < 1.6.0, >= 1.6.3, < 1.7.0, >= 1.7.2, < 1.8.0, >= 1.8.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0072: Task dropped in wrong thread when aborting `LocalSet` taskWhen aborting a task with `JoinHandle::abort`, the future is dropped in the thread calling abort if the task is not currently being executed. This is incorrect for tasks spawned on a `LocalSet`. This can easily result in race conditions as many projects use `Rc` or `RefCell` in their Tokio tasks for better performance. See [tokio#3929][issue] for more details. [issue]: https://github.com/tokio-rs/tokio/issues/3929Package Name: tokio Installed Version: 0.2.24 Fixed Version: >= 1.5.1, < 1.6.0, >= 1.6.3, < 1.7.0, >= 1.7.2, < 1.8.0, >= 1.8.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0124: Data race when sending and receiving after closing a `oneshot` channelIf a `tokio::sync::oneshot` channel is closed (via the [`oneshot::Receiver::close`] method), a data race may occur if the `oneshot::Sender::send` method is called while the corresponding `oneshot::Receiver` is `await`ed or calling `try_recv`. When these methods are called concurrently on a closed channel, the two halves of the channel can concurrently access a shared memory location, resulting in a data race. This has been observed to [cause memory corruption][corruption]. Note that the race only occurs when **both** halves of the channel are used after the `Receiver` half has called `close`. Code where `close` is not used, or where the `Receiver` is not `await`ed and `try_recv` is not called after calling `close`, is not affected. See [tokio#4225][issue] for more details. [corruption]: https://github.com/tokio-rs/tokio/issues/4225#issuecomment-967434847 [issue]: https://github.com/tokio-rs/tokio/issues/4225 [`oneshot::Receiver::close`]: https://docs.rs/tokio/1.14.0/tokio/sync/oneshot/struct.Receiver.html#method.closePackage Name: tokio Installed Version: 0.1.22 Fixed Version: >= 1.8.4, < 1.9.0, >= 1.13.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0124: Data race when sending and receiving after closing a `oneshot` channelIf a `tokio::sync::oneshot` channel is closed (via the [`oneshot::Receiver::close`] method), a data race may occur if the `oneshot::Sender::send` method is called while the corresponding `oneshot::Receiver` is `await`ed or calling `try_recv`. When these methods are called concurrently on a closed channel, the two halves of the channel can concurrently access a shared memory location, resulting in a data race. This has been observed to [cause memory corruption][corruption]. Note that the race only occurs when **both** halves of the channel are used after the `Receiver` half has called `close`. Code where `close` is not used, or where the `Receiver` is not `await`ed and `try_recv` is not called after calling `close`, is not affected. See [tokio#4225][issue] for more details. [corruption]: https://github.com/tokio-rs/tokio/issues/4225#issuecomment-967434847 [issue]: https://github.com/tokio-rs/tokio/issues/4225 [`oneshot::Receiver::close`]: https://docs.rs/tokio/1.14.0/tokio/sync/oneshot/struct.Receiver.html#method.closePackage Name: tokio Installed Version: 0.2.24 Fixed Version: >= 1.8.4, < 1.9.0, >= 1.13.1 References: github.com |
|
Target: | home/circleci/.cargo/registry/src/github.com-1ecc6299db9ec823/structopt-0.3.25/Cargo.lock | |
UNKNOWN |
RUSTSEC-2020-0053: dirs is unmaintained, use dirs-next insteadThe `dirs` crate is not maintained any more; use [`dirs-next`](https://crates.io/crates/dirs-next) instead.Package Name: dirs Installed Version: 1.0.5 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2018-0015: term is looking for a new maintainerThe author of the `term` crate does not have time to maintain it and is looking for a new maintainer. Some maintained alternatives you can potentially switch to instead, depending on your needs: - [`crossterm`](https://github.com/crossterm-rs/crossterm) - [`termcolor`](https://crates.io/crates/termcolor) - [`yansi`](https://crates.io/crates/yansi)Package Name: term Installed Version: 0.5.2 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2018-0006: Uncontrolled recursion leads to abort in deserializationAffected versions of this crate did not prevent deep recursion while deserializing data structures. This allows an attacker to make a YAML file with deeply nested structures that causes an abort while deserializing it. The flaw was corrected by checking the recursion depth. Note: `clap 2.33` is not affected by this because it uses `yaml-rust` in a way that doesn't trigger the vulnerability. More specifically: 1. The input to the YAML parser is always trusted - is included at compile time via `include_str!`. 2. The nesting level is never deep enough to trigger the overflow in practice (at most 5).Package Name: yaml-rust Installed Version: 0.3.5 Fixed Version: >= 0.4.1 References: github.com |
|
Target: | home/circleci/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-fs-0.1.7/Cargo.lock | |
UNKNOWN |
RUSTSEC-2021-0093: Data race in crossbeam-dequeIn the affected version of this crate, the result of the race condition is that one or more tasks in the worker queue can be popped twice instead of other tasks that are forgotten and never popped. If tasks are allocated on the heap, this can cause double free and a memory leak. If not, this still can cause a logical bug. Crates using `Stealer::steal`, `Stealer::steal_batch`, or `Stealer::steal_batch_and_pop` are affected by this issue. Credits to @kmaork for discovering, reporting and fixing the bug.Package Name: crossbeam-deque Installed Version: 0.7.2 Fixed Version: >= 0.7.4, < 0.8.0, >= 0.8.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0070: Some lock_api lock guard objects can cause data racesAffected versions of lock_api had unsound implementations of the `Send` or `Sync` traits for some guard objects, namely: * MappedMutexGuard * MappedRwLockReadGuard * MappedRwLockWriteGuard * RwLockReadGuard * RwLockWriteGuard These guards could allow data races through types that are not safe to `Send` across thread boundaries in safe Rust code. This issue was fixed by changing the trait bounds on the `Mapped` guard types and removing the `Sync` trait for the `RwLock` guards.Package Name: lock_api Installed Version: 0.3.3 Fixed Version: >= 0.4.2 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0081: `mio` invalidly assumes the memory layout of std::net::SocketAddrThe [`mio`](https://crates.io/crates/mio) crate has assumed `std::net::SocketAddrV4` and `std::net::SocketAddrV6` have the same memory layout as the system C representation `sockaddr`. It has simply casted the pointers to convert the socket addresses to the system representation. The standard library does not say anything about the memory layout, and this will cause invalid memory access if the standard library changes the implementation. No warnings or errors will be emitted once the change happens.Package Name: mio Installed Version: 0.6.21 Fixed Version: >= 0.7.6 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0080: `miow` invalidly assumes the memory layout of std::net::SocketAddrThe [`miow`](https://crates.io/crates/miow) crate has assumed `std::net::SocketAddrV4` and `std::net::SocketAddrV6` have the same memory layout as the system C representation `sockaddr`. It has simply casted the pointers to convert the socket addresses to the system representation. The standard library does not say anything about the memory layout, and this will cause invalid memory access if the standard library changes the implementation. No warnings or errors will be emitted once the change happens.Package Name: miow Installed Version: 0.2.1 Fixed Version: ^ 0.2.2, >= 0.3.6 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0016: `net2` crate has been deprecated; use `socket2` insteadThe [`net2`](https://crates.io/crates/net2) crate has been deprecated and users are encouraged to considered [`socket2`](https://crates.io/crates/socket2) instead.Package Name: net2 Installed Version: 0.2.33 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0078: `net2` invalidly assumes the memory layout of std::net::SocketAddrThe [`net2`](https://crates.io/crates/net2) crate has assumed `std::net::SocketAddrV4` and `std::net::SocketAddrV6` have the same memory layout as the system C representation `sockaddr`. It has simply casted the pointers to convert the socket addresses to the system representation. The standard library does not say anything about the memory layout, and this will cause invalid memory access if the standard library changes the implementation. No warnings or errors will be emitted once the change happens.Package Name: net2 Installed Version: 0.2.33 Fixed Version: >= 0.2.36 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0023: Incorrect check on buffer length when seeding RNGsSummary: rand_core::le::read_u32_into and read_u64_into have incorrect checks on the source buffer length, allowing the destination buffer to be under-filled. Implications: some downstream RNGs, including Hc128Rng (but not the more widely used ChaCha*Rng), allow seeding using the SeedableRng::from_seed trait-function with too short keys.Package Name: rand_core Installed Version: 0.5.1 Fixed Version: >= 0.6.2 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0003: Buffer overflow in SmallVec::insert_manyA bug in the `SmallVec::insert_many` method caused it to allocate a buffer that was smaller than needed. It then wrote past the end of the buffer, causing a buffer overflow and memory corruption on the heap. This bug was only triggered if the iterator passed to `insert_many` yielded more items than the lower bound returned from its `size_hint` method. The flaw was corrected in smallvec 0.6.14 and 1.6.1, by ensuring that additional space is always reserved for each item inserted. The fix also simplified the implementation of `insert_many` to use less unsafe code, so it is easier to verify its correctness. Thank you to Yechan Bae (@Qwaz) and the Rust group at Georgia Tech’s SSLab for finding and reporting this bug.Package Name: smallvec Installed Version: 0.6.13 Fixed Version: >= 0.6.14, < 1.0.0, >= 1.6.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0072: Task dropped in wrong thread when aborting `LocalSet` taskWhen aborting a task with `JoinHandle::abort`, the future is dropped in the thread calling abort if the task is not currently being executed. This is incorrect for tasks spawned on a `LocalSet`. This can easily result in race conditions as many projects use `Rc` or `RefCell` in their Tokio tasks for better performance. See [tokio#3929][issue] for more details. [issue]: https://github.com/tokio-rs/tokio/issues/3929Package Name: tokio Installed Version: 0.1.22 Fixed Version: >= 1.5.1, < 1.6.0, >= 1.6.3, < 1.7.0, >= 1.7.2, < 1.8.0, >= 1.8.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0124: Data race when sending and receiving after closing a `oneshot` channelIf a `tokio::sync::oneshot` channel is closed (via the [`oneshot::Receiver::close`] method), a data race may occur if the `oneshot::Sender::send` method is called while the corresponding `oneshot::Receiver` is `await`ed or calling `try_recv`. When these methods are called concurrently on a closed channel, the two halves of the channel can concurrently access a shared memory location, resulting in a data race. This has been observed to [cause memory corruption][corruption]. Note that the race only occurs when **both** halves of the channel are used after the `Receiver` half has called `close`. Code where `close` is not used, or where the `Receiver` is not `await`ed and `try_recv` is not called after calling `close`, is not affected. See [tokio#4225][issue] for more details. [corruption]: https://github.com/tokio-rs/tokio/issues/4225#issuecomment-967434847 [issue]: https://github.com/tokio-rs/tokio/issues/4225 [`oneshot::Receiver::close`]: https://docs.rs/tokio/1.14.0/tokio/sync/oneshot/struct.Receiver.html#method.closePackage Name: tokio Installed Version: 0.1.22 Fixed Version: >= 1.8.4, < 1.9.0, >= 1.13.1 References: github.com |
|
Target: | home/circleci/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-process-0.2.5/Cargo.lock | |
UNKNOWN |
RUSTSEC-2020-0091: Dangling reference in `access::Map` with ConstantUsing the `arc_swap::access::Map` with the `Constant` test helper (or with user-provided implementation of the `Access` trait) could sometimes lead to the map returning dangling references. Replaced by implementation without `unsafe`, at the cost of added `Clone` bound on the closure and small penalty on performance.Package Name: arc-swap Installed Version: 0.4.4 Fixed Version: >= 0.4.8, < 1.0.0-0, >= 1.1.0 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0093: Data race in crossbeam-dequeIn the affected version of this crate, the result of the race condition is that one or more tasks in the worker queue can be popped twice instead of other tasks that are forgotten and never popped. If tasks are allocated on the heap, this can cause double free and a memory leak. If not, this still can cause a logical bug. Crates using `Stealer::steal`, `Stealer::steal_batch`, or `Stealer::steal_batch_and_pop` are affected by this issue. Credits to @kmaork for discovering, reporting and fixing the bug.Package Name: crossbeam-deque Installed Version: 0.7.2 Fixed Version: >= 0.7.4, < 0.8.0, >= 0.8.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2019-0036: Type confusion if __private_get_type_id__ is overriddenSafe Rust code can implement malfunctioning `__private_get_type_id__` and cause type confusion when downcasting, which is an undefined behavior. Users who derive `Fail` trait are not affected.Package Name: failure Installed Version: 0.1.6 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0036: failure is officially deprecated/unmaintainedThe `failure` crate is officially end-of-life: it has been marked as deprecated by the former maintainer, who has announced that there will be no updates or maintenance work on it going forward. The following are some suggested actively developed alternatives to switch to: - [`anyhow`](https://crates.io/crates/anyhow) - [`eyre`](https://crates.io/crates/eyre) - [`fehler`](https://crates.io/crates/fehler) - [`snafu`](https://crates.io/crates/snafu) - [`thiserror`](https://crates.io/crates/thiserror)Package Name: failure Installed Version: 0.1.6 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0070: Some lock_api lock guard objects can cause data racesAffected versions of lock_api had unsound implementations of the `Send` or `Sync` traits for some guard objects, namely: * MappedMutexGuard * MappedRwLockReadGuard * MappedRwLockWriteGuard * RwLockReadGuard * RwLockWriteGuard These guards could allow data races through types that are not safe to `Send` across thread boundaries in safe Rust code. This issue was fixed by changing the trait bounds on the `Mapped` guard types and removing the `Sync` trait for the `RwLock` guards.Package Name: lock_api Installed Version: 0.3.3 Fixed Version: >= 0.4.2 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0081: `mio` invalidly assumes the memory layout of std::net::SocketAddrThe [`mio`](https://crates.io/crates/mio) crate has assumed `std::net::SocketAddrV4` and `std::net::SocketAddrV6` have the same memory layout as the system C representation `sockaddr`. It has simply casted the pointers to convert the socket addresses to the system representation. The standard library does not say anything about the memory layout, and this will cause invalid memory access if the standard library changes the implementation. No warnings or errors will be emitted once the change happens.Package Name: mio Installed Version: 0.6.21 Fixed Version: >= 0.7.6 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0080: `miow` invalidly assumes the memory layout of std::net::SocketAddrThe [`miow`](https://crates.io/crates/miow) crate has assumed `std::net::SocketAddrV4` and `std::net::SocketAddrV6` have the same memory layout as the system C representation `sockaddr`. It has simply casted the pointers to convert the socket addresses to the system representation. The standard library does not say anything about the memory layout, and this will cause invalid memory access if the standard library changes the implementation. No warnings or errors will be emitted once the change happens.Package Name: miow Installed Version: 0.2.1 Fixed Version: ^ 0.2.2, >= 0.3.6 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0080: `miow` invalidly assumes the memory layout of std::net::SocketAddrThe [`miow`](https://crates.io/crates/miow) crate has assumed `std::net::SocketAddrV4` and `std::net::SocketAddrV6` have the same memory layout as the system C representation `sockaddr`. It has simply casted the pointers to convert the socket addresses to the system representation. The standard library does not say anything about the memory layout, and this will cause invalid memory access if the standard library changes the implementation. No warnings or errors will be emitted once the change happens.Package Name: miow Installed Version: 0.3.3 Fixed Version: ^ 0.2.2, >= 0.3.6 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0016: `net2` crate has been deprecated; use `socket2` insteadThe [`net2`](https://crates.io/crates/net2) crate has been deprecated and users are encouraged to considered [`socket2`](https://crates.io/crates/socket2) instead.Package Name: net2 Installed Version: 0.2.33 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0078: `net2` invalidly assumes the memory layout of std::net::SocketAddrThe [`net2`](https://crates.io/crates/net2) crate has assumed `std::net::SocketAddrV4` and `std::net::SocketAddrV6` have the same memory layout as the system C representation `sockaddr`. It has simply casted the pointers to convert the socket addresses to the system representation. The standard library does not say anything about the memory layout, and this will cause invalid memory access if the standard library changes the implementation. No warnings or errors will be emitted once the change happens.Package Name: net2 Installed Version: 0.2.33 Fixed Version: >= 0.2.36 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0003: Buffer overflow in SmallVec::insert_manyA bug in the `SmallVec::insert_many` method caused it to allocate a buffer that was smaller than needed. It then wrote past the end of the buffer, causing a buffer overflow and memory corruption on the heap. This bug was only triggered if the iterator passed to `insert_many` yielded more items than the lower bound returned from its `size_hint` method. The flaw was corrected in smallvec 0.6.14 and 1.6.1, by ensuring that additional space is always reserved for each item inserted. The fix also simplified the implementation of `insert_many` to use less unsafe code, so it is easier to verify its correctness. Thank you to Yechan Bae (@Qwaz) and the Rust group at Georgia Tech’s SSLab for finding and reporting this bug.Package Name: smallvec Installed Version: 0.6.13 Fixed Version: >= 0.6.14, < 1.0.0, >= 1.6.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0079: `socket2` invalidly assumes the memory layout of std::net::SocketAddrThe [`socket2`](https://crates.io/crates/socket2) crate has assumed `std::net::SocketAddrV4` and `std::net::SocketAddrV6` have the same memory layout as the system C representation `sockaddr`. It has simply casted the pointers to convert the socket addresses to the system representation. The standard library does not say anything about the memory layout, and this will cause invalid memory access if the standard library changes the implementation. No warnings or errors will be emitted once the change happens.Package Name: socket2 Installed Version: 0.3.11 Fixed Version: >= 0.3.16 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0072: Task dropped in wrong thread when aborting `LocalSet` taskWhen aborting a task with `JoinHandle::abort`, the future is dropped in the thread calling abort if the task is not currently being executed. This is incorrect for tasks spawned on a `LocalSet`. This can easily result in race conditions as many projects use `Rc` or `RefCell` in their Tokio tasks for better performance. See [tokio#3929][issue] for more details. [issue]: https://github.com/tokio-rs/tokio/issues/3929Package Name: tokio Installed Version: 0.1.22 Fixed Version: >= 1.5.1, < 1.6.0, >= 1.6.3, < 1.7.0, >= 1.7.2, < 1.8.0, >= 1.8.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0124: Data race when sending and receiving after closing a `oneshot` channelIf a `tokio::sync::oneshot` channel is closed (via the [`oneshot::Receiver::close`] method), a data race may occur if the `oneshot::Sender::send` method is called while the corresponding `oneshot::Receiver` is `await`ed or calling `try_recv`. When these methods are called concurrently on a closed channel, the two halves of the channel can concurrently access a shared memory location, resulting in a data race. This has been observed to [cause memory corruption][corruption]. Note that the race only occurs when **both** halves of the channel are used after the `Receiver` half has called `close`. Code where `close` is not used, or where the `Receiver` is not `await`ed and `try_recv` is not called after calling `close`, is not affected. See [tokio#4225][issue] for more details. [corruption]: https://github.com/tokio-rs/tokio/issues/4225#issuecomment-967434847 [issue]: https://github.com/tokio-rs/tokio/issues/4225 [`oneshot::Receiver::close`]: https://docs.rs/tokio/1.14.0/tokio/sync/oneshot/struct.Receiver.html#method.closePackage Name: tokio Installed Version: 0.1.22 Fixed Version: >= 1.8.4, < 1.9.0, >= 1.13.1 References: github.com |
|
Target: | home/circleci/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-signal-0.2.9/Cargo.lock | |
UNKNOWN |
RUSTSEC-2020-0091: Dangling reference in `access::Map` with ConstantUsing the `arc_swap::access::Map` with the `Constant` test helper (or with user-provided implementation of the `Access` trait) could sometimes lead to the map returning dangling references. Replaced by implementation without `unsafe`, at the cost of added `Clone` bound on the closure and small penalty on performance.Package Name: arc-swap Installed Version: 0.4.4 Fixed Version: >= 0.4.8, < 1.0.0-0, >= 1.1.0 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0093: Data race in crossbeam-dequeIn the affected version of this crate, the result of the race condition is that one or more tasks in the worker queue can be popped twice instead of other tasks that are forgotten and never popped. If tasks are allocated on the heap, this can cause double free and a memory leak. If not, this still can cause a logical bug. Crates using `Stealer::steal`, `Stealer::steal_batch`, or `Stealer::steal_batch_and_pop` are affected by this issue. Credits to @kmaork for discovering, reporting and fixing the bug.Package Name: crossbeam-deque Installed Version: 0.7.2 Fixed Version: >= 0.7.4, < 0.8.0, >= 0.8.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0070: Some lock_api lock guard objects can cause data racesAffected versions of lock_api had unsound implementations of the `Send` or `Sync` traits for some guard objects, namely: * MappedMutexGuard * MappedRwLockReadGuard * MappedRwLockWriteGuard * RwLockReadGuard * RwLockWriteGuard These guards could allow data races through types that are not safe to `Send` across thread boundaries in safe Rust code. This issue was fixed by changing the trait bounds on the `Mapped` guard types and removing the `Sync` trait for the `RwLock` guards.Package Name: lock_api Installed Version: 0.3.3 Fixed Version: >= 0.4.2 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0081: `mio` invalidly assumes the memory layout of std::net::SocketAddrThe [`mio`](https://crates.io/crates/mio) crate has assumed `std::net::SocketAddrV4` and `std::net::SocketAddrV6` have the same memory layout as the system C representation `sockaddr`. It has simply casted the pointers to convert the socket addresses to the system representation. The standard library does not say anything about the memory layout, and this will cause invalid memory access if the standard library changes the implementation. No warnings or errors will be emitted once the change happens.Package Name: mio Installed Version: 0.6.21 Fixed Version: >= 0.7.6 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0080: `miow` invalidly assumes the memory layout of std::net::SocketAddrThe [`miow`](https://crates.io/crates/miow) crate has assumed `std::net::SocketAddrV4` and `std::net::SocketAddrV6` have the same memory layout as the system C representation `sockaddr`. It has simply casted the pointers to convert the socket addresses to the system representation. The standard library does not say anything about the memory layout, and this will cause invalid memory access if the standard library changes the implementation. No warnings or errors will be emitted once the change happens.Package Name: miow Installed Version: 0.2.1 Fixed Version: ^ 0.2.2, >= 0.3.6 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0016: `net2` crate has been deprecated; use `socket2` insteadThe [`net2`](https://crates.io/crates/net2) crate has been deprecated and users are encouraged to considered [`socket2`](https://crates.io/crates/socket2) instead.Package Name: net2 Installed Version: 0.2.33 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0078: `net2` invalidly assumes the memory layout of std::net::SocketAddrThe [`net2`](https://crates.io/crates/net2) crate has assumed `std::net::SocketAddrV4` and `std::net::SocketAddrV6` have the same memory layout as the system C representation `sockaddr`. It has simply casted the pointers to convert the socket addresses to the system representation. The standard library does not say anything about the memory layout, and this will cause invalid memory access if the standard library changes the implementation. No warnings or errors will be emitted once the change happens.Package Name: net2 Installed Version: 0.2.33 Fixed Version: >= 0.2.36 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0003: Buffer overflow in SmallVec::insert_manyA bug in the `SmallVec::insert_many` method caused it to allocate a buffer that was smaller than needed. It then wrote past the end of the buffer, causing a buffer overflow and memory corruption on the heap. This bug was only triggered if the iterator passed to `insert_many` yielded more items than the lower bound returned from its `size_hint` method. The flaw was corrected in smallvec 0.6.14 and 1.6.1, by ensuring that additional space is always reserved for each item inserted. The fix also simplified the implementation of `insert_many` to use less unsafe code, so it is easier to verify its correctness. Thank you to Yechan Bae (@Qwaz) and the Rust group at Georgia Tech’s SSLab for finding and reporting this bug.Package Name: smallvec Installed Version: 0.6.13 Fixed Version: >= 0.6.14, < 1.0.0, >= 1.6.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0072: Task dropped in wrong thread when aborting `LocalSet` taskWhen aborting a task with `JoinHandle::abort`, the future is dropped in the thread calling abort if the task is not currently being executed. This is incorrect for tasks spawned on a `LocalSet`. This can easily result in race conditions as many projects use `Rc` or `RefCell` in their Tokio tasks for better performance. See [tokio#3929][issue] for more details. [issue]: https://github.com/tokio-rs/tokio/issues/3929Package Name: tokio Installed Version: 0.1.22 Fixed Version: >= 1.5.1, < 1.6.0, >= 1.6.3, < 1.7.0, >= 1.7.2, < 1.8.0, >= 1.8.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0124: Data race when sending and receiving after closing a `oneshot` channelIf a `tokio::sync::oneshot` channel is closed (via the [`oneshot::Receiver::close`] method), a data race may occur if the `oneshot::Sender::send` method is called while the corresponding `oneshot::Receiver` is `await`ed or calling `try_recv`. When these methods are called concurrently on a closed channel, the two halves of the channel can concurrently access a shared memory location, resulting in a data race. This has been observed to [cause memory corruption][corruption]. Note that the race only occurs when **both** halves of the channel are used after the `Receiver` half has called `close`. Code where `close` is not used, or where the `Receiver` is not `await`ed and `try_recv` is not called after calling `close`, is not affected. See [tokio#4225][issue] for more details. [corruption]: https://github.com/tokio-rs/tokio/issues/4225#issuecomment-967434847 [issue]: https://github.com/tokio-rs/tokio/issues/4225 [`oneshot::Receiver::close`]: https://docs.rs/tokio/1.14.0/tokio/sync/oneshot/struct.Receiver.html#method.closePackage Name: tokio Installed Version: 0.1.22 Fixed Version: >= 1.8.4, < 1.9.0, >= 1.13.1 References: github.com |
|
Target: | home/circleci/.cargo/registry/src/github.com-1ecc6299db9ec823/tokio-threadpool-0.1.18/Cargo.lock | |
UNKNOWN |
RUSTSEC-2021-0093: Data race in crossbeam-dequeIn the affected version of this crate, the result of the race condition is that one or more tasks in the worker queue can be popped twice instead of other tasks that are forgotten and never popped. If tasks are allocated on the heap, this can cause double free and a memory leak. If not, this still can cause a logical bug. Crates using `Stealer::steal`, `Stealer::steal_batch`, or `Stealer::steal_batch_and_pop` are affected by this issue. Credits to @kmaork for discovering, reporting and fixing the bug.Package Name: crossbeam-deque Installed Version: 0.7.2 Fixed Version: >= 0.7.4, < 0.8.0, >= 0.8.1 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0023: Incorrect check on buffer length when seeding RNGsSummary: rand_core::le::read_u32_into and read_u64_into have incorrect checks on the source buffer length, allowing the destination buffer to be under-filled. Implications: some downstream RNGs, including Hc128Rng (but not the more widely used ChaCha*Rng), allow seeding using the SeedableRng::from_seed trait-function with too short keys.Package Name: rand_core Installed Version: 0.5.1 Fixed Version: >= 0.6.2 References: github.com |
|
Target: | home/circleci/.cargo/registry/src/github.com-1ecc6299db9ec823/toml_edit-0.6.0/Cargo.lock | |
UNKNOWN |
RUSTSEC-2020-0159: ## ReferencesUnix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library. No workarounds are known. - [time-rs/time#293](https://github.com/time-rs/time/issues/293)Package Name: chrono Installed Version: 0.4.19 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0127: serde_cbor is unmaintainedThe `serde_cbor` crate is unmaintained. The author has archived the github repository. Alternatives proposed by the author: * [`ciborium`](https://crates.io/crates/ciborium) * [`minicbor`](https://crates.io/crates/minicbor)Package Name: serde_cbor Installed Version: 0.11.2 Fixed Version: References: github.com |
|
UNKNOWN |
RUSTSEC-2022-0006: Data race in `Iter` and `IterMut`In the affected version of this crate, `{Iter, IterMut}::next` used a weaker memory ordering when loading values than what was required, exposing a potential data race when iterating over a `ThreadLocal`'s values. Crates using `Iter::next`, or `IterMut::next` are affected by this issue.Package Name: thread_local Installed Version: 1.1.3 Fixed Version: >= 1.1.4 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0071: ## ReferencesUnix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library. The affected functions from time 0.2.7 through 0.2.22 are: - `time::UtcOffset::local_offset_at` - `time::UtcOffset::try_local_offset_at` - `time::UtcOffset::current_local_offset` - `time::UtcOffset::try_current_local_offset` - `time::OffsetDateTime::now_local` - `time::OffsetDateTime::try_now_local` The affected functions in time 0.1 (all versions) are: - `at` - `at_utc` - `now` Non-Unix targets (including Windows and wasm) are unaffected. Pending a proper fix, the internal method that determines the local offset has been modified to always return `None` on the affected operating systems. This has the effect of returning an `Err` on the `try_*` methods and `UTC` on the non-`try_*` methods. Users and library authors with time in their dependency tree should perform `cargo update`, which will pull in the updated, unaffected code. Users of time 0.1 do not have a patch and should upgrade to an unaffected version: time 0.2.23 or greater or the 0.3 series. No workarounds are known. time-rs/time#293Package Name: time Installed Version: 0.1.44 Fixed Version: >= 0.2.23 References: github.com |
|
Target: | home/circleci/.cargo/registry/src/github.com-1ecc6299db9ec823/zip-0.5.13/Cargo.lock | |
UNKNOWN |
RUSTSEC-2021-0023: Incorrect check on buffer length when seeding RNGsSummary: rand_core::le::read_u32_into and read_u64_into have incorrect checks on the source buffer length, allowing the destination buffer to be under-filled. Implications: some downstream RNGs, including Hc128Rng (but not the more widely used ChaCha*Rng), allow seeding using the SeedableRng::from_seed trait-function with too short keys.Package Name: rand_core Installed Version: 0.5.1 Fixed Version: >= 0.6.2 References: github.com |
|
UNKNOWN |
RUSTSEC-2020-0071: ## ReferencesUnix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library. The affected functions from time 0.2.7 through 0.2.22 are: - `time::UtcOffset::local_offset_at` - `time::UtcOffset::try_local_offset_at` - `time::UtcOffset::current_local_offset` - `time::UtcOffset::try_current_local_offset` - `time::OffsetDateTime::now_local` - `time::OffsetDateTime::try_now_local` The affected functions in time 0.1 (all versions) are: - `at` - `at_utc` - `now` Non-Unix targets (including Windows and wasm) are unaffected. Pending a proper fix, the internal method that determines the local offset has been modified to always return `None` on the affected operating systems. This has the effect of returning an `Err` on the `try_*` methods and `UTC` on the non-`try_*` methods. Users and library authors with time in their dependency tree should perform `cargo update`, which will pull in the updated, unaffected code. Users of time 0.1 do not have a patch and should upgrade to an unaffected version: time 0.2.23 or greater or the 0.3 series. No workarounds are known. time-rs/time#293Package Name: time Installed Version: 0.1.44 Fixed Version: >= 0.2.23 References: github.com |
|
Target: | home/circleci/.cargo/registry/src/github.com-1ecc6299db9ec823/zstd-0.6.1+zstd.1.4.9/Cargo.lock | |
UNKNOWN |
RUSTSEC-2021-0023: Incorrect check on buffer length when seeding RNGsSummary: rand_core::le::read_u32_into and read_u64_into have incorrect checks on the source buffer length, allowing the destination buffer to be under-filled. Implications: some downstream RNGs, including Hc128Rng (but not the more widely used ChaCha*Rng), allow seeding using the SeedableRng::from_seed trait-function with too short keys.Package Name: rand_core Installed Version: 0.3.1 Fixed Version: >= 0.6.2 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0023: Incorrect check on buffer length when seeding RNGsSummary: rand_core::le::read_u32_into and read_u64_into have incorrect checks on the source buffer length, allowing the destination buffer to be under-filled. Implications: some downstream RNGs, including Hc128Rng (but not the more widely used ChaCha*Rng), allow seeding using the SeedableRng::from_seed trait-function with too short keys.Package Name: rand_core Installed Version: 0.4.2 Fixed Version: >= 0.6.2 References: github.com |
|
UNKNOWN |
RUSTSEC-2022-0006: Data race in `Iter` and `IterMut`In the affected version of this crate, `{Iter, IterMut}::next` used a weaker memory ordering when loading values than what was required, exposing a potential data race when iterating over a `ThreadLocal`'s values. Crates using `Iter::next`, or `IterMut::next` are affected by this issue.Package Name: thread_local Installed Version: 1.0.1 Fixed Version: >= 1.1.4 References: github.com |
|
Target: | home/circleci/.cargo/registry/src/github.com-1ecc6299db9ec823/zstd-0.8.3+zstd.1.5.0/Cargo.lock | |
UNKNOWN |
RUSTSEC-2021-0023: Incorrect check on buffer length when seeding RNGsSummary: rand_core::le::read_u32_into and read_u64_into have incorrect checks on the source buffer length, allowing the destination buffer to be under-filled. Implications: some downstream RNGs, including Hc128Rng (but not the more widely used ChaCha*Rng), allow seeding using the SeedableRng::from_seed trait-function with too short keys.Package Name: rand_core Installed Version: 0.3.1 Fixed Version: >= 0.6.2 References: github.com |
|
UNKNOWN |
RUSTSEC-2021-0023: Incorrect check on buffer length when seeding RNGsSummary: rand_core::le::read_u32_into and read_u64_into have incorrect checks on the source buffer length, allowing the destination buffer to be under-filled. Implications: some downstream RNGs, including Hc128Rng (but not the more widely used ChaCha*Rng), allow seeding using the SeedableRng::from_seed trait-function with too short keys.Package Name: rand_core Installed Version: 0.4.2 Fixed Version: >= 0.6.2 References: github.com |
|
UNKNOWN |
RUSTSEC-2022-0006: Data race in `Iter` and `IterMut`In the affected version of this crate, `{Iter, IterMut}::next` used a weaker memory ordering when loading values than what was required, exposing a potential data race when iterating over a `ThreadLocal`'s values. Crates using `Iter::next`, or `IterMut::next` are affected by this issue.Package Name: thread_local Installed Version: 0.3.6 Fixed Version: >= 1.1.4 References: github.com |
You can embed a badge in another website that shows this or the latest version of this package.
To embed the badge for this specific package version, use the following:
[](https://cloudsmith.io/~consensys/repos/pub/packages/detail/docker/rust-circle-ci/d14e49ef1503fe58a7383479d8bcd55becbab02050a87053e86f6cdf134da2b9/a=amd64;xpo=linux/)
|This version of 'rust-circle-ci' @ Cloudsmith|
.. |This version of 'rust-circle-ci' @ Cloudsmith| image:: https://api-prd.cloudsmith.io/v1/badges/version/consensys/pub/docker/rust-circle-ci/1.58-nightly-test/a=amd64;xpo=linux/?render=true
:target: https://cloudsmith.io/~consensys/repos/pub/packages/detail/docker/rust-circle-ci/d14e49ef1503fe58a7383479d8bcd55becbab02050a87053e86f6cdf134da2b9/a=amd64;xpo=linux/
image::https://api-prd.cloudsmith.io/v1/badges/version/consensys/pub/docker/rust-circle-ci/1.58-nightly-test/a=amd64;xpo=linux/?render=true[link="https://cloudsmith.io/~consensys/repos/pub/packages/detail/docker/rust-circle-ci/d14e49ef1503fe58a7383479d8bcd55becbab02050a87053e86f6cdf134da2b9/a=amd64;xpo=linux/",title="This version of 'rust-circle-ci' @ Cloudsmith"]
<a href="https://cloudsmith.io/~consensys/repos/pub/packages/detail/docker/rust-circle-ci/d14e49ef1503fe58a7383479d8bcd55becbab02050a87053e86f6cdf134da2b9/a=amd64;xpo=linux/"><img src="https://api-prd.cloudsmith.io/v1/badges/version/consensys/pub/docker/rust-circle-ci/1.58-nightly-test/a=amd64;xpo=linux/?render=true" alt="This version of 'rust-circle-ci' @ Cloudsmith" /></a>
rendered as:
To embed the badge for the latest package version, use the following:
[](https://cloudsmith.io/~consensys/repos/pub/packages/detail/docker/rust-circle-ci/latest/a=amd64;xpo=linux/)
|Latest version of 'rust-circle-ci' @ Cloudsmith|
.. |Latest version of 'rust-circle-ci' @ Cloudsmith| image:: https://api-prd.cloudsmith.io/v1/badges/version/consensys/pub/docker/rust-circle-ci/latest/a=amd64;xpo=linux/?render=true&show_latest=true
:target: https://cloudsmith.io/~consensys/repos/pub/packages/detail/docker/rust-circle-ci/latest/a=amd64;xpo=linux/
image::https://api-prd.cloudsmith.io/v1/badges/version/consensys/pub/docker/rust-circle-ci/latest/a=amd64;xpo=linux/?render=true&show_latest=true[link="https://cloudsmith.io/~consensys/repos/pub/packages/detail/docker/rust-circle-ci/latest/a=amd64;xpo=linux/",title="Latest version of 'rust-circle-ci' @ Cloudsmith"]
<a href="https://cloudsmith.io/~consensys/repos/pub/packages/detail/docker/rust-circle-ci/latest/a=amd64;xpo=linux/"><img src="https://api-prd.cloudsmith.io/v1/badges/version/consensys/pub/docker/rust-circle-ci/latest/a=amd64;xpo=linux/?render=true&show_latest=true" alt="Latest version of 'rust-circle-ci' @ Cloudsmith" /></a>
rendered as:
These instructions assume you have setup the repository first (or read it).
To pull rust-circle-ci @ reference/tag rust-1-60-nightly:
docker pull docker.consensys.net/pub/rust-circle-ci:rust-1-60-nightly
You can also pull the latest version of this image (if it exists):
docker pull docker.consensys.net/pub/rust-circle-ci:latest
To refer to this image after pulling in a Dockerfile, specify the following:
FROM docker.consensys.net/pub/rust-circle-ci:rust-1-60-nightly
Note: You should replace rust-1-60-nightly with an alternative reference to pull, such as: 1.58-nightly-test.