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.

Start My Free Trial
Search Help

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).

Set Me Up
 Public — consensys consensys (ConsenSys) / pub
docker-public: The public docker image registry of ConsenSys.
Packages 68 Package Groups 2 Signing Keys

Docker logo rust-circle-ci  1.58-nightly-test

Download

One-liner (summary)

A certifiably-awesome package curated by Jakub Trąd, hosted by Cloudsmith.

Description

A certifiably-awesome package curated by Jakub Trąd, hosted by Cloudsmith.

License

Unknown

Size

713.7 MB

Downloads

1704

Tags

image amd64 linux rust-1-60-nightly

Status  Completed
GPG Signature
Download
Storage Region  Dublin, Ireland
Type  Binary (contains binaries and binary artifacts)
Uploaded At 3 months, 3 weeks ago
Uploaded By jakub-trad
Slug Id rust-circle-ci-v4r
Unique Id bcx4Xz83k2xO
Version (Raw) 1.58-nightly-test
Version (Parsed)
  • Major: 1
  • Minor: 58
  • Pre (Str): nightly-test
  • Type: SemVer (Compat)
Orig Version (Raw) d14e49ef1503fe58a7383479d8bcd55becbab02050a87053e86f6cdf134da2b9
Orig Version (Parsed)
  • Type: Unknown
  extended metadata
Manifest Type V2 Distribution
Architecture amd64
Config
Cmd
bash
Env
COMPOSE_SWITCH_VERSION=1.0.4 | COMPOSE_VERSION=2.2.3 | DEBIAN_FRONTEND=noninteractive | DOCKER_VERSION=5:20.10.12~3-0~ubuntu- | LANG=en_US.UTF-8 | LANGUAGE=en_US:en | LC_ALL=en_US.UTF-8 | PATH=/home/circleci/.cargo/bin:/home/circleci/bin:/home/circleci/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin | RUSTC_WRAPPER=sccache | SCCACHE_CACHE_SIZE=4G
Labels
'maintainer' 'Community & Partner Engineering Team <community-partner@circleci.com>'
Shell
-c | -exo | /bin/bash | pipefail
User
circleci
Working Dir
/home/circleci/project
Created 2022-01-28 11:19:09 UTC
Os linux

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
  Docker logo
rust-circle-ci
 1.58-nightly-test
image amd64 linux rust-1-60-nightly
713.7 MB — 3 months, 3 weeks ago
1704 jakub-trad
Only packages within the same repository are displayed. The current package you're viewing is highlighted.

Last scanned

3 months, 3 weeks ago

Scan result

Vulnerable

Vulnerability count

530

Max. severity

High
Target: /oci (ubuntu 20.04)
HIGH

CVE-2021-4034: polkit: Local privilege escalation in pkexec due to incorrect handling of argument vector

A 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 vector

A 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 handling

A 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 vector

A 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-1585

In 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 vulnerability

Arm 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 vulnerability

Arm 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 vulnerability

Arm 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 vulnerability

Arm 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 vulnerability

Arm 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 vulnerability

Arm 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 vulnerability

Arm 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 DoS

ec_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-1585

In 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 target

An 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 archive

An 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 vulnerability

Arm 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 messages

In 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 pathnames

The 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 pathname

The 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 messages

In 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 pathnames

The 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 pathname

The 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 messages

In 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 pathnames

The 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 pathname

The 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 messages

In 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 pathnames

The 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 pathname

The 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 rewrite

It 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_GetBuffer

Expat (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 vulnerability

Arm 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 DoS

ec_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 DoS

ec_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 DoS

ec_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 DoS

ec_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 user

A 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 user

A 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 user

A 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 files

A 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 files

A 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 files

CPAN 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-9794

An 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-9794

An 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 vulnerability

Arm 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 files

A 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 files

A 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) objects

The 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 implementation

The 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 service

The 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 drivers

Uncontrolled 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 handle

A 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 faults

An 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-28714

Guest 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-28715

Guest 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 overflow

An 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 frozen

A 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 it

A 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 function

A 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 counts

A 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 IOCTL

A 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 removed

A 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.c

In 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 subsystem

A 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.c

pep_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 entry

In __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.c

An 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 messages

In 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 pathnames

The 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 pathname

The 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 user

A 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 files

CPAN 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 files

CPAN 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 files

CPAN 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 vulnerability

An 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 files

A 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 files

A 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 files

A 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-indenting

vim is vulnerable to Heap-based Buffer Overflow

Package 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.c

vim is vulnerable to Heap-based Buffer Overflow

Package 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.c

vim is vulnerable to Use After Free

Package 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.c

vim is vulnerable to Out-of-bounds Read

Package 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-indenting

vim is vulnerable to Heap-based Buffer Overflow

Package 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.c

vim is vulnerable to Heap-based Buffer Overflow

Package 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.c

vim is vulnerable to Use After Free

Package 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.c

vim is vulnerable to Out-of-bounds Read

Package 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 redirect

GNU 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-indenting

vim is vulnerable to Heap-based Buffer Overflow

Package 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.c

vim is vulnerable to Heap-based Buffer Overflow

Package 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.c

vim is vulnerable to Use After Free

Package 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.c

vim is vulnerable to Out-of-bounds Read

Package 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 dropped

An 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 libiberty

The 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 service

The 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 service

GNU 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 libiberty

The 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 service

The 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 service

GNU 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 libiberty

The 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 service

The 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 service

GNU 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 chroot

chroot 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 behaviour

A 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 behaviors

Package 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 behaviour

A 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 behaviors

Package 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 commands

GIT 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 commands

GIT 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.c

An 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-REQ

A 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 libiberty

The 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 service

The 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 service

GNU 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 option

The 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 encoding

The 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 loop

The 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 UCS4

The 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 function

An 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.c

The 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 characters

The 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 attributes

The 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 option

The 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 encoding

The 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 loop

The 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 UCS4

The 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 function

An 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.c

The 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 characters

The 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 attributes

The 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 option

The 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 encoding

The 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 loop

The 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 UCS4

The 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 function

An 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.c

The 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 characters

The 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 attributes

The 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 option

The 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 encoding

The 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 loop

The 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 UCS4

The 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 function

An 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.c

The 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 characters

The 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 attributes

The 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 libiberty

The 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 service

The 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 service

GNU 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 libiberty

The 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 service

The 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 service

GNU 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 behaviour

A 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 behaviors

Package 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 input

GNU 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 input

GNU 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 input

GNU 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.c

An 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-REQ

A 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-REQ

A 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-REQ

A 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-REQ

A 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-REQ

A 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.c

An 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-REQ

A 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.c

An 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.c

An 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.c

In 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 1

libpcre 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 arguments

libpcre 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 ioctl

pkexec, 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 ioctl

pkexec, 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 parameters

The 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 parameters

The 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-REQ

A 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-9849

An 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-9991

This 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-9849

An 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-9991

This 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 exhaustion

GNU 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 exhaustion

GNU 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 exhaustion

GNU 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-REQ

A 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-0537

An 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-13165

An 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.c

The 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 /proc

procps-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.ko

In 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.ko

ntfs_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.ko

ntfs_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.ko

ntfs_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 tunnel

A 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.c

An 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.c

In 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.c

In 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 Drivers

Improper 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 Drivers

Null 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 leak

A 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 capability

A 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 subsystem

Package 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-26934

An 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 validation

An 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 Vulnerability

A 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 counts

A 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 associations

A 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 option

The 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 encoding

The 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 loop

The 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 UCS4

The 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 function

An 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.c

The 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 characters

The 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 attributes

The 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 trees

shadow: TOCTOU (time-of-check time-of-use) race condition when copying and removing directory trees

Package 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 negotiation

The 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 configured

sshd 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 trees

shadow: TOCTOU (time-of-check time-of-use) race condition when copying and removing directory trees

Package 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 crash

A 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 ioctl

pkexec, 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 URL

An 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 parameters

The 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 parameters

The 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.c

sysstat 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.c

vim is vulnerable to Use After Free

Package 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.c

vim is vulnerable to Use After Free

Package 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 policy

It 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.c

vim is vulnerable to Use After Free

Package 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 unmaintained

The 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 JSON

When 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 maintainer

The 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: ## References

Unix-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#293

Package 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::getgrouplist

On 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 RNGs

Summary: 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 RNGs

Summary: 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` instead

The [`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 'static

Affected 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 code

Affected 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 races

Affected 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::SocketAddr

The [`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_many

A 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::SocketAddr

The [`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` task

When 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/3929

Package 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` channel

If 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.close

Package 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` crate

Please 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` crate

Please 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,+ssse3

Package 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::SocketAddr

The [`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 RNGs

Summary: 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 RNGs

Summary: 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 backend

The 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 unmaintained

The 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` task

When 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/3929

Package 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` task

When 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/3929

Package 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` task

When 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/3929

Package 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` channel

If 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.close

Package 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` channel

If 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.close

Package 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` channel

If 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.close

Package 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 maintained

The 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 JSON

When 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-deque

In 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 RNGs

Summary: 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 RNGs

Summary: 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-deque

In 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 unmaintained

The `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: ## References

Unix-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 libssl

Internally 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 RNGs

Summary: 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 format

If 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: ## References

Unix-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#293

Package 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 instead

The `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 maintainer

The 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 deserialization

Affected 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 instead

The `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 maintainer

The 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 deserialization

Affected 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::getgrouplist

On 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-deque

In 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::SocketAddr

The [`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::SocketAddr

The [`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` instead

The [`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 RNGs

Summary: 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 RNGs

Summary: 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 unmaintained

The `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` task

When 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/3929

Package 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` task

When 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/3929

Package 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` task

When 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/3929

Package 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` channel

If 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.close

Package 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` channel

If 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.close

Package 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` channel

If 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.close

Package 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::SocketAddr

The [`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` instead

The [`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 RNGs

Summary: 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 RNGs

Summary: 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 unmaintained

The `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` task

When 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/3929

Package 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` task

When 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/3929

Package 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` channel

If 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.close

Package 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` channel

If 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.close

Package 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` channel

If 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.close

Package 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 RNGs

Summary: 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 RNGs

Summary: 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 overridden

Safe 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/unmaintained

The `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 Constant

Using 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: ## References

Unix-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 RNGs

Summary: 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 RNGs

Summary: 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` instead

The [`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: ## References

Unix-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#293

Package 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-deque

In 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 races

Affected 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::SocketAddr

The [`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` instead

The [`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 RNGs

Summary: 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_many

A 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 unmaintained

The 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 libssl

Internally 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: ## References

Unix-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#293

Package 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-deque

In 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 unsound

Affected 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 code

Affected 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::SocketAddr

The [`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::SocketAddr

The [`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` instead

The [`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::SocketAddr

The [`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 access

Affected 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 access

Affected 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 RNGs

Summary: 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 RNGs

Summary: 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` task

When 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/3929

Package 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` channel

If 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.close

Package 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: ## References

Unix-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-deque

In 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 loss

When 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 races

Affected 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::SocketAddr

The [`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` instead

The [`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: ## References

Unix-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#293

Package 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` task

When 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/3929

Package 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` channel

If 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.close

Package 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-deque

In 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 RNGs

Summary: 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 unmaintained

The `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 unmaintained

The `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 races

Affected 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_many

A 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 RNGs

Summary: 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 memory

When `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-deque

In 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 processing

An 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_STRICT

The 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 CipherUpdate

Calls 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 Overflow

In 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 strings

ASN.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 libssl

Internally 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 RNGs

Summary: 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 libssl

Internally 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 RNGs

Summary: 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 RNGs

Summary: 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` instead

The [`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 memory

When `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 RNGs

Summary: 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 unmaintained

The 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-deque

In 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 Constant

Using 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 channel

The 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-deque

In 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 'static

Affected 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 code

Affected 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 races

Affected 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::SocketAddr

The [`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::SocketAddr

The [`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` instead

The [`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::SocketAddr

The [`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::getgrouplist

On 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 RNGs

Summary: 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 RNGs

Summary: 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 RNGs

Summary: 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_many

A 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::SocketAddr

The [`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` instead

The [`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` task

When 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/3929

Package 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` channel

If 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.close

Package 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 memory

When `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-deque

In 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 overridden

Safe 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/unmaintained

The `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 payload

hyper'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 loss

When 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 pointer

Affected 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 races

Affected 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::SocketAddr

The [`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::SocketAddr

The [`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` instead

The [`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::SocketAddr

The [`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 attack

Server 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 processing

An 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_STRICT

The 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 CipherUpdate

Calls 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 Overflow

In 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 strings

ASN.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 libssl

Internally 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 RNGs

Summary: 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 RNGs

Summary: 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 RNGs

Summary: 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 type

Affected 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_many

A 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::SocketAddr

The [`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 maintained

The 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: ## References

Unix-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#293

Package 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` task

When 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/3929

Package 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` channel

If 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.close

Package 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 RNGs

Summary: 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: ## References

Unix-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-deque

In 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 unmaintained

The 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 instead

The `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 instead

The `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 overridden

Safe 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/unmaintained

The `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 payload

hyper'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 loss

When 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 races

Affected 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::SocketAddr

The [`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::SocketAddr

The [`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` instead

The [`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::getgrouplist

On 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::getgrouplist

On 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 RNGs

Summary: 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 RNGs

Summary: 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 RNGs

Summary: 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 backend

The 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_many

A 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 maintained

The 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 directories

When 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` instead

The [`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 maintainer

The 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: ## References

Unix-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#293

Package 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 headers

HTTP 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` task

When 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/3929

Package 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` task

When 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/3929

Package 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` channel

If 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.close

Package 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` channel

If 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.close

Package 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 instead

The `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 maintainer

The 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 deserialization

Affected 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-deque

In 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 races

Affected 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::SocketAddr

The [`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::SocketAddr

The [`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` instead

The [`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::SocketAddr

The [`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 RNGs

Summary: 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_many

A 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` task

When 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/3929

Package 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` channel

If 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.close

Package 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 Constant

Using 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-deque

In 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 overridden

Safe 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/unmaintained

The `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 races

Affected 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::SocketAddr

The [`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::SocketAddr

The [`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::SocketAddr

The [`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` instead

The [`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::SocketAddr

The [`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_many

A 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::SocketAddr

The [`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` task

When 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/3929

Package 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` channel

If 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.close

Package 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 Constant

Using 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-deque

In 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 races

Affected 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::SocketAddr

The [`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::SocketAddr

The [`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` instead

The [`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::SocketAddr

The [`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_many

A 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` task

When 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/3929

Package 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` channel

If 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.close

Package 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-deque

In 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 RNGs

Summary: 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: ## References

Unix-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 unmaintained

The `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: ## References

Unix-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#293

Package 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 RNGs

Summary: 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: ## References

Unix-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#293

Package 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 RNGs

Summary: 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 RNGs

Summary: 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 RNGs

Summary: 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 RNGs

Summary: 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
Loading...

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: 

[![This version of 'rust-circle-ci' @ Cloudsmith](https://api-prd.cloudsmith.io/v1/badges/version/consensys/pub/docker/rust-circle-ci/1.58-nightly-test/a=amd64;xpo=linux/?render=true)](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: This version of 'rust-circle-ci' @ Cloudsmith

To embed the badge for the latest package version, use the following: 

[![Latest version of 'rust-circle-ci' @ Cloudsmith](https://api-prd.cloudsmith.io/v1/badges/version/consensys/pub/docker/rust-circle-ci/latest/a=amd64;xpo=linux/?render=true&show_latest=true)](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: Latest version of 'rust-circle-ci' @ Cloudsmith

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.

Still stuck? Need help? Don't panic. Just contact us for help (even if you're not a customer).
Prev Version
Next Version
Top