Common Weakness Enumeration

CWE-662

Discouraged

Improper Synchronization

Abstraction: Class · Status: Draft

The product utilizes multiple threads, processes, components, or systems to allow temporary access to a shared resource that can only be exclusive to one process at a time, but it does not properly synchronize these actions, which might cause simultaneous accesses of this resource by multiple threads or processes.

72 vulnerabilities reference this CWE, most recent first.

GHSA-9MXW-4856-9CM5

Vulnerability from github – Published: 2021-08-25 20:50 – Updated: 2023-06-13 20:46
VLAI
Summary
Data races in rusb
Details

Affected versions of rusb did not require UsbContext to implement Send and Sync. However, through Device and DeviceHandle it is possible to use UsbContexts across threads. This issue allows non-thread safe UsbContext types to be used concurrently leading to data races and memory corruption. The issue was fixed by adding Send and Sync bounds to UsbContext.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "rusb"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.7.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-36206"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-662",
      "CWE-787"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-08-19T18:51:05Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "Affected versions of rusb did not require UsbContext to implement Send and Sync. However, through Device and DeviceHandle it is possible to use UsbContexts across threads. This issue allows non-thread safe UsbContext types to be used concurrently leading to data races and memory corruption. The issue was fixed by adding Send and Sync bounds to UsbContext.",
  "id": "GHSA-9mxw-4856-9cm5",
  "modified": "2023-06-13T20:46:48Z",
  "published": "2021-08-25T20:50:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-36206"
    },
    {
      "type": "WEB",
      "url": "https://github.com/a1ien/rusb/issues/44"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/a1ien/rusb"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2020-0098.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Data races in rusb"
}

GHSA-CR69-9HHR-PQP9

Vulnerability from github – Published: 2022-11-09 12:00 – Updated: 2022-11-10 19:01
VLAI
Details

In vcu, there is a possible use after free due to a race condition. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS07203410; Issue ID: ALPS07203410.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-32609"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-662"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-11-08T21:15:00Z",
    "severity": "MODERATE"
  },
  "details": "In vcu, there is a possible use after free due to a race condition. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS07203410; Issue ID: ALPS07203410.",
  "id": "GHSA-cr69-9hhr-pqp9",
  "modified": "2022-11-10T19:01:11Z",
  "published": "2022-11-09T12:00:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-32609"
    },
    {
      "type": "WEB",
      "url": "https://corp.mediatek.com/product-security-bulletin/November-2022"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-F25W-4H6F-FRG3

Vulnerability from github – Published: 2022-05-24 17:17 – Updated: 2022-05-24 17:17
VLAI
Details

An issue was discovered in the Linux kernel before 5.4.17. drivers/spi/spi-dw.c allows attackers to cause a panic via concurrent calls to dw_spi_irq and dw_spi_transfer_one, aka CID-19b61392c5a8.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-12769"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-662"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-05-09T21:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in the Linux kernel before 5.4.17. drivers/spi/spi-dw.c allows attackers to cause a panic via concurrent calls to dw_spi_irq and dw_spi_transfer_one, aka CID-19b61392c5a8.",
  "id": "GHSA-f25w-4h6f-frg3",
  "modified": "2022-05-24T17:17:33Z",
  "published": "2022-05-24T17:17:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-12769"
    },
    {
      "type": "WEB",
      "url": "https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.4.17"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=19b61392c5a852b4e8a0bf35aecb969983c5932d"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2020/06/msg00011.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2020/06/msg00013.html"
    },
    {
      "type": "WEB",
      "url": "https://lkml.org/lkml/2020/2/3/559"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20200608-0001"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/4391-1"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2020-06/msg00022.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2020-07/msg00008.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FGXJ-VFG7-CPQQ

Vulnerability from github – Published: 2026-06-25 09:31 – Updated: 2026-06-30 03:37
VLAI
Details

In the Linux kernel, the following vulnerability has been resolved:

KVM: arm64: Take the SRCU lock for page table walks in fault injection and AT emulation

walk_s1() and kvm_walk_nested_s2() expect to be called while holding kvm->srcu to guard against memslot changes. While this is generally the case, __kvm_at_s12() and __kvm_find_s1_desc_level() call into the respective walkers without taking kvm->srcu.

Fix by acquiring kvm->srcu prior to the table walk in both instances.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-53277"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-662",
      "CWE-820"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-25T09:16:45Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: arm64: Take the SRCU lock for page table walks in fault injection and AT emulation\n\nwalk_s1() and kvm_walk_nested_s2() expect to be called while holding\nkvm-\u003esrcu to guard against memslot changes. While this is generally\nthe case, __kvm_at_s12() and __kvm_find_s1_desc_level() call into the\nrespective walkers without taking kvm-\u003esrcu.\n\nFix by acquiring kvm-\u003esrcu prior to the table walk in both instances.",
  "id": "GHSA-fgxj-vfg7-cpqq",
  "modified": "2026-06-30T03:37:13Z",
  "published": "2026-06-25T09:31:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53277"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-53277"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2492725"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/97706097f9b851cfe55c3b00b083dfc2bcf542bc"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ec42b4ed1b072ea2d03f086061aa67bad6d8de39"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/f2ca45b50d4216c9cc7ffabf50d9ad1932209251"
    },
    {
      "type": "WEB",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-53277.json"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-G27Q-PW4H-7P4G

Vulnerability from github – Published: 2022-05-24 19:10 – Updated: 2022-05-24 19:10
VLAI
Details

Missing synchronization vulnerability in GOT2000 series GT27 model communication driver versions 01.19.000 through 01.39.010, GT25 model communication driver versions 01.19.000 through 01.39.010 and GT23 model communication driver versions 01.19.000 through 01.39.010 and GT SoftGOT2000 versions 1.170C through 1.256S allows a remote unauthenticated attacker to cause DoS condition on the MODBUS/TCP slave communication function of the products by rapidly and repeatedly connecting and disconnecting to and from the MODBUS/TCP communication port on a target. Restart or reset is required to recover.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2021-20592"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-662"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-08-05T21:15:00Z",
    "severity": "HIGH"
  },
  "details": "Missing synchronization vulnerability in GOT2000 series GT27 model communication driver versions 01.19.000 through 01.39.010, GT25 model communication driver versions 01.19.000 through 01.39.010 and GT23 model communication driver versions 01.19.000 through 01.39.010 and GT SoftGOT2000 versions 1.170C through 1.256S allows a remote unauthenticated attacker to cause DoS condition on the MODBUS/TCP slave communication function of the products by rapidly and repeatedly connecting and disconnecting to and from the MODBUS/TCP communication port on a target. Restart or reset is required to recover.",
  "id": "GHSA-g27q-pw4h-7p4g",
  "modified": "2022-05-24T19:10:08Z",
  "published": "2022-05-24T19:10:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20592"
    },
    {
      "type": "WEB",
      "url": "https://jvn.jp/vu/JVNVU92414172/index.html"
    },
    {
      "type": "WEB",
      "url": "https://www.mitsubishielectric.com/en/psirt/vulnerability/pdf/2021-007_en.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-G489-XRW3-3V8W

Vulnerability from github – Published: 2021-08-25 20:50 – Updated: 2021-08-19 18:51
VLAI
Summary
Data races in aovec
Details

An issue was discovered in the aovec crate through 2020-12-10 for Rust. Because Aovec does not have bounds on its Send trait or Sync trait, a data race and memory corruption can occur.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "aovec"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-36207"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-662",
      "CWE-787"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-08-19T18:51:25Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "An issue was discovered in the aovec crate through 2020-12-10 for Rust. Because Aovec\u003cT\u003e does not have bounds on its Send trait or Sync trait, a data race and memory corruption can occur.",
  "id": "GHSA-g489-xrw3-3v8w",
  "modified": "2021-08-19T18:51:25Z",
  "published": "2021-08-25T20:50:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-36207"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/krl/aovec"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2020-0099.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Data races in aovec"
}

GHSA-H2V5-WFXF-W2JF

Vulnerability from github – Published: 2022-11-09 12:00 – Updated: 2022-11-10 19:01
VLAI
Details

In vcu, there is a possible use after free due to a race condition. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS07203476; Issue ID: ALPS07203476.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-32610"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-662"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-11-08T21:15:00Z",
    "severity": "MODERATE"
  },
  "details": "In vcu, there is a possible use after free due to a race condition. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS07203476; Issue ID: ALPS07203476.",
  "id": "GHSA-h2v5-wfxf-w2jf",
  "modified": "2022-11-10T19:01:11Z",
  "published": "2022-11-09T12:00:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-32610"
    },
    {
      "type": "WEB",
      "url": "https://corp.mediatek.com/product-security-bulletin/November-2022"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-H33Q-MHMP-8P67

Vulnerability from github – Published: 2025-02-21 22:43 – Updated: 2025-04-09 20:12
VLAI
Summary
Vyper has a double eval in For List Iter
Details

Multiple evaluation of a single expression is possible in the iterator target of a for loop. While the iterator expression cannot produce multiple writes, it can consume side effects produced in the loop body (e.g. read a storage variable updated in the loop body) and thus lead to unexpected program behavior. Specifically, reads in iterators which contain an ifexp (e.g. for s: uint256 in ([read(), read()] if True else [])) may interleave reads with writes in the loop body.

The fix is tracked in https://github.com/vyperlang/vyper/pull/4488.

Vulnerability Details

Vyper for loops allow two kinds of iterator targets, namely the range() builtin and an iterable type, like SArray and DArray.

During codegen, iterable lists are required to not produce any side-effects (in the following code, range_scope forces iter_list to be parsed in a constant context, which is checked against is_constant).

def _parse_For_list(self):
    with self.context.range_scope():
        iter_list = Expr(self.stmt.iter, self.context).ir_node
    ...

def range_scope(self):
    prev_value = self.in_range_expr
    self.in_range_expr = True
    yield
    self.in_range_expr = prev_value

def is_constant(self):
    return self.constancy is Constancy.Constant or self.in_range_expr

However, this does not prevent the iterator from consuming side effects provided by the body of the loop. For dynamic arrays, the compiler simply panics:

x: DynArray[uint256, 3]

@external
def test():
    for i: uint256 in (self.usesideeffect() if True else self.usesideeffect()):
        pass

@view
def usesideeffect() -> DynArray[uint256, 3]:
    return self.x

For SArrays on the other hand, iter_list is instantiated in the body of a repeat ir, so it can be evaluated several times.

Here are three illustrating examples. In the first example, the following test case pre-evaluates the iter list and stores the result to a temporary list in memory. So the list is only evaluated once, before entry into the loop body, and the log output will be 0, 0, 0.

event I:
    i: uint256

x: uint256

@deploy
def __init__():
    self.x = 0

@external
def test():
    for i: uint256 in [self.usesideeffect(), self.usesideeffect(), self.usesideeffect()]:
        self.x += 1
        log I(i)

@view
def usesideeffect() -> uint256:
    return self.x

However, in the next two examples, because the iterator target is not a list literal, it will be evaluated in the loop body. In the second example, iter_list is an ifexp, thus it will be evaluated lazily in the loop body. The log output will be 0, 1, 2 due to consumption of side effects.

event I:
    i: uint256

x: uint256

@deploy
def __init__():
    self.x = 0

@external
def test():
    for i: uint256 in ([self.usesideeffect(), self.usesideeffect(), self.usesideeffect()] if True else self.otherclause()):
        self.x += 1
        log I(i)

@view
def usesideeffect() -> uint256:
    return self.x

@view
def otherclause() -> uint256[3]:
    return [0, 0, 0]

In the third example, iter_list is also an ifexp, thus it will only be evaluated in the loop body. The log output will be 0, 1, 2 due to consumption of side effects.

event I:
    i: uint256

x: uint256[3]

@deploy
def __init__():
    self.x = [0, 0, 0]

@external
def test():
    for i: uint256 in (self.usesideeffect() if True else self.otherclause()):
        self.x[0] += 1
        self.x[1] += 1
        self.x[2] += 1
        log I(i)

@view
def usesideeffect() -> uint256[3]:
    return self.x

@view
def otherclause() -> uint256[3]:
    return [0, 0, 0]
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.4.0"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "vyper"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.4.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-27104"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-662"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-02-21T22:43:36Z",
    "nvd_published_at": "2025-02-21T22:15:13Z",
    "severity": "LOW"
  },
  "details": "Multiple evaluation of a single expression is possible in the iterator target of a for loop. While the iterator expression cannot produce multiple writes, it can consume side effects produced in the loop body (e.g. read a storage variable updated in the loop body) and thus lead to unexpected program behavior. Specifically, reads in iterators which contain an ifexp (e.g. `for s: uint256 in ([read(), read()] if True else [])`) may interleave reads with writes in the loop body.\n\nThe fix is tracked in https://github.com/vyperlang/vyper/pull/4488.\n\n### Vulnerability Details\n\nVyper for loops allow two kinds of iterator targets, namely the `range()` builtin and an iterable type, like SArray and DArray. \n\nDuring codegen, iterable lists are required to not produce any side-effects (in the following code, `range_scope` forces `iter_list` to be parsed in a constant context, which is checked against `is_constant`).\n\n```python\ndef _parse_For_list(self):\n    with self.context.range_scope():\n        iter_list = Expr(self.stmt.iter, self.context).ir_node\n    ...\n\ndef range_scope(self):\n    prev_value = self.in_range_expr\n    self.in_range_expr = True\n    yield\n    self.in_range_expr = prev_value\n\ndef is_constant(self):\n    return self.constancy is Constancy.Constant or self.in_range_expr\n```\n\nHowever, this does not prevent the iterator from consuming side effects provided by the body of the loop. For dynamic arrays, the compiler simply panics:\n```vyper\nx: DynArray[uint256, 3]\n\n@external\ndef test():\n    for i: uint256 in (self.usesideeffect() if True else self.usesideeffect()):\n        pass\n\n@view\ndef usesideeffect() -\u003e DynArray[uint256, 3]:\n    return self.x\n```\n\nFor SArrays on the other hand, `iter_list` is instantiated in the body of a `repeat` ir, so it can be evaluated several times.\n\nHere are three illustrating examples. In the first example, the following test case pre-evaluates the iter list and stores the result to a temporary list in memory. So the list is only evaluated once, before entry into the loop body, and the log output will be 0, 0, 0.\n```vyper\nevent I:\n    i: uint256\n\nx: uint256\n\n@deploy\ndef __init__():\n    self.x = 0\n\n@external\ndef test():\n    for i: uint256 in [self.usesideeffect(), self.usesideeffect(), self.usesideeffect()]:\n        self.x += 1\n        log I(i)\n\n@view\ndef usesideeffect() -\u003e uint256:\n    return self.x\n```\n\nHowever, in the next two examples, because the iterator target is not a list literal, it will be evaluated in the loop body. In the second example, `iter_list` is an ifexp, thus it will be evaluated lazily in the loop body. The log output will be 0, 1, 2 due to consumption of side effects.\n\n```vyper\nevent I:\n    i: uint256\n\nx: uint256\n\n@deploy\ndef __init__():\n    self.x = 0\n\n@external\ndef test():\n    for i: uint256 in ([self.usesideeffect(), self.usesideeffect(), self.usesideeffect()] if True else self.otherclause()):\n        self.x += 1\n        log I(i)\n\n@view\ndef usesideeffect() -\u003e uint256:\n    return self.x\n\n@view\ndef otherclause() -\u003e uint256[3]:\n    return [0, 0, 0]\n```\n\nIn the third example, `iter_list` is also an ifexp, thus it will only be evaluated in the loop body. The log output will be 0, 1, 2 due to consumption of side effects.\n\n```vyper\nevent I:\n    i: uint256\n\nx: uint256[3]\n\n@deploy\ndef __init__():\n    self.x = [0, 0, 0]\n\n@external\ndef test():\n    for i: uint256 in (self.usesideeffect() if True else self.otherclause()):\n        self.x[0] += 1\n        self.x[1] += 1\n        self.x[2] += 1\n        log I(i)\n\n@view\ndef usesideeffect() -\u003e uint256[3]:\n    return self.x\n\n@view\ndef otherclause() -\u003e uint256[3]:\n    return [0, 0, 0]\n```",
  "id": "GHSA-h33q-mhmp-8p67",
  "modified": "2025-04-09T20:12:39Z",
  "published": "2025-02-21T22:43:36Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vyperlang/vyper/security/advisories/GHSA-h33q-mhmp-8p67"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-27104"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vyperlang/vyper/pull/4488"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/vyper/PYSEC-2025-30.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vyperlang/vyper"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Vyper has a double eval in For List Iter"
}

GHSA-H63V-34H7-7Q42

Vulnerability from github – Published: 2022-05-24 17:12 – Updated: 2022-05-24 17:12
VLAI
Details

In FreeRADIUS 3.0.x before 3.0.20, the EAP-pwd module used a global OpenSSL BN_CTX instance to handle all handshakes. This mean multiple threads use the same BN_CTX instance concurrently, resulting in crashes when concurrent EAP-pwd handshakes are initiated. This can be abused by an adversary as a Denial-of-Service (DoS) attack.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2019-17185"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-662"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-03-21T01:15:00Z",
    "severity": "MODERATE"
  },
  "details": "In FreeRADIUS 3.0.x before 3.0.20, the EAP-pwd module used a global OpenSSL BN_CTX instance to handle all handshakes. This mean multiple threads use the same BN_CTX instance concurrently, resulting in crashes when concurrent EAP-pwd handshakes are initiated. This can be abused by an adversary as a Denial-of-Service (DoS) attack.",
  "id": "GHSA-h63v-34h7-7q42",
  "modified": "2022-05-24T17:12:07Z",
  "published": "2022-05-24T17:12:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-17185"
    },
    {
      "type": "WEB",
      "url": "https://freeradius.org/security"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FreeRADIUS/freeradius-server/releases/tag/release_3_0_20"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2020-04/msg00039.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-H67M-XG8F-FXCF

Vulnerability from github – Published: 2021-11-10 18:59 – Updated: 2024-11-07 22:17
VLAI
Summary
Deadlock in mutually recursive `tf.function` objects
Details

Impact

The code behind tf.function API can be made to deadlock when two tf.function decorated Python functions are mutually recursive:

import tensorflow as tf

@tf.function()               
def fun1(num):
    if num == 1:
        return
    print(num)
    fun2(num-1)

@tf.function()
def fun2(num):
    if num == 0:
        return
    print(num)
    fun1(num-1)

fun1(9)

This occurs due to using a non-reentrant Lock Python object.

Loading any model which contains mutually recursive functions is vulnerable. An attacker can cause denial of service by causing users to load such models and calling a recursive tf.function, although this is not a frequent scenario.

Patches

We have patched the issue in GitHub commit afac8158d43691661ad083f6dd9e56f327c1dcb7.

The fix will be included in TensorFlow 2.7.0. We will also cherrypick this commit on TensorFlow 2.6.1, TensorFlow 2.5.2, and TensorFlow 2.4.4, as these are also affected and still in supported range.

For more information

Please consult our security guide for more information regarding the security model and how to contact us with issues and questions.

Attribution

This vulnerability has been reported by members of the Aivul Team from Qihoo 360.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.6.0"
            },
            {
              "fixed": "2.6.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.5.0"
            },
            {
              "fixed": "2.5.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.4.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow-cpu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.6.0"
            },
            {
              "fixed": "2.6.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow-cpu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.5.0"
            },
            {
              "fixed": "2.5.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow-cpu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.4.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow-gpu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.6.0"
            },
            {
              "fixed": "2.6.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow-gpu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.5.0"
            },
            {
              "fixed": "2.5.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "tensorflow-gpu"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.4.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-41213"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-662",
      "CWE-667"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-11-08T22:25:35Z",
    "nvd_published_at": "2021-11-05T23:15:00Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nThe [code behind `tf.function` API](https://github.com/tensorflow/tensorflow/blob/8d72537c6abf5a44103b57b9c2e22c14f5f49698/tensorflow/python/eager/def_function.py#L542) can be made to deadlock when two `tf.function` decorated Python functions are mutually recursive:\n\n```python \nimport tensorflow as tf\n\n@tf.function()               \ndef fun1(num):\n    if num == 1:\n        return\n    print(num)\n    fun2(num-1)\n\n@tf.function()\ndef fun2(num):\n    if num == 0:\n        return\n    print(num)\n    fun1(num-1)\n\nfun1(9)\n```\n\nThis occurs due to using a non-reentrant `Lock` Python object.\n\nLoading any model which contains mutually recursive functions is vulnerable. An attacker can cause denial of service by causing users to load such models and calling a recursive `tf.function`, although this is not a frequent scenario.\n\n### Patches\nWe have patched the issue in GitHub commit [afac8158d43691661ad083f6dd9e56f327c1dcb7](https://github.com/tensorflow/tensorflow/commit/afac8158d43691661ad083f6dd9e56f327c1dcb7).\n\nThe fix will be included in TensorFlow 2.7.0. We will also cherrypick this commit on TensorFlow 2.6.1, TensorFlow 2.5.2, and TensorFlow 2.4.4, as these are also affected and still in supported range.\n\n### For more information\nPlease consult [our security guide](https://github.com/tensorflow/tensorflow/blob/master/SECURITY.md) for more information regarding the security model and how to contact us with issues and questions.\n\n### Attribution\nThis vulnerability has been reported by members of the Aivul Team from Qihoo 360.",
  "id": "GHSA-h67m-xg8f-fxcf",
  "modified": "2024-11-07T22:17:51Z",
  "published": "2021-11-10T18:59:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/tensorflow/tensorflow/security/advisories/GHSA-h67m-xg8f-fxcf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-41213"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tensorflow/tensorflow/commit/afac8158d43691661ad083f6dd9e56f327c1dcb7"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow-cpu/PYSEC-2021-622.yaml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow-gpu/PYSEC-2021-820.yaml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow/PYSEC-2021-405.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/tensorflow/tensorflow"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Deadlock in mutually recursive `tf.function` objects"
}

Mitigation
Implementation

Use industry standard APIs to synchronize your code.

CAPEC-25: Forced Deadlock

The adversary triggers and exploits a deadlock condition in the target software to cause a denial of service. A deadlock can occur when two or more competing actions are waiting for each other to finish, and thus neither ever does. Deadlock conditions can be difficult to detect.

CAPEC-26: Leveraging Race Conditions

The adversary targets a race condition occurring when multiple processes access and manipulate the same resource concurrently, and the outcome of the execution depends on the particular order in which the access takes place. The adversary can leverage a race condition by "running the race", modifying the resource and modifying the normal execution flow. For instance, a race condition can occur while accessing a file: the adversary can trick the system by replacing the original file with their version and cause the system to read the malicious file.

CAPEC-27: Leveraging Race Conditions via Symbolic Links

This attack leverages the use of symbolic links (Symlinks) in order to write to sensitive files. An attacker can create a Symlink link to a target file not otherwise accessible to them. When the privileged program tries to create a temporary file with the same name as the Symlink link, it will actually write to the target file pointed to by the attackers' Symlink link. If the attacker can insert malicious content in the temporary file they will be writing to the sensitive file by using the Symlink. The race occurs because the system checks if the temporary file exists, then creates the file. The attacker would typically create the Symlink during the interval between the check and the creation of the temporary file.

CAPEC-29: Leveraging Time-of-Check and Time-of-Use (TOCTOU) Race Conditions

This attack targets a race condition occurring between the time of check (state) for a resource and the time of use of a resource. A typical example is file access. The adversary can leverage a file access race condition by "running the race", meaning that they would modify the resource between the first time the target program accesses the file and the time the target program uses the file. During that period of time, the adversary could replace or modify the file, causing the application to behave unexpectedly.