ghsa-692g-7998-j2vj
Vulnerability from github
Published
2024-06-21 12:31
Modified
2024-09-09 15:30
Details

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

tls: fix missing memory barrier in tls_init

In tls_init(), a write memory barrier is missing, and store-store reordering may cause NULL dereference in tls_{setsockopt,getsockopt}.

CPU0 CPU1 ----- ----- // In tls_init() // In tls_ctx_create() ctx = kzalloc() ctx->sk_proto = READ_ONCE(sk->sk_prot) -(1)

// In update_sk_prot() WRITE_ONCE(sk->sk_prot, tls_prots) -(2)

                               // In sock_common_setsockopt()
                               READ_ONCE(sk->sk_prot)->setsockopt()

                               // In tls_{setsockopt,getsockopt}()
                               ctx->sk_proto->setsockopt()    -(3)

In the above scenario, when (1) and (2) are reordered, (3) can observe the NULL value of ctx->sk_proto, causing NULL dereference.

To fix it, we rely on rcu_assign_pointer() which implies the release barrier semantic. By moving rcu_assign_pointer() after ctx->sk_proto is initialized, we can ensure that ctx->sk_proto are visible when changing sk->sk_prot.

Show details on source website


{
  "affected": [],
  "aliases": [
    "CVE-2024-36489"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-21T11:15:10Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ntls: fix missing memory barrier in tls_init\n\nIn tls_init(), a write memory barrier is missing, and store-store\nreordering may cause NULL dereference in tls_{setsockopt,getsockopt}.\n\nCPU0                               CPU1\n-----                              -----\n// In tls_init()\n// In tls_ctx_create()\nctx = kzalloc()\nctx-\u003esk_proto = READ_ONCE(sk-\u003esk_prot) -(1)\n\n// In update_sk_prot()\nWRITE_ONCE(sk-\u003esk_prot, tls_prots)     -(2)\n\n                                   // In sock_common_setsockopt()\n                                   READ_ONCE(sk-\u003esk_prot)-\u003esetsockopt()\n\n                                   // In tls_{setsockopt,getsockopt}()\n                                   ctx-\u003esk_proto-\u003esetsockopt()    -(3)\n\nIn the above scenario, when (1) and (2) are reordered, (3) can observe\nthe NULL value of ctx-\u003esk_proto, causing NULL dereference.\n\nTo fix it, we rely on rcu_assign_pointer() which implies the release\nbarrier semantic. By moving rcu_assign_pointer() after ctx-\u003esk_proto is\ninitialized, we can ensure that ctx-\u003esk_proto are visible when\nchanging sk-\u003esk_prot.",
  "id": "GHSA-692g-7998-j2vj",
  "modified": "2024-09-09T15:30:37Z",
  "published": "2024-06-21T12:31:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36489"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2c260a24cf1c4d30ea3646124f766ee46169280b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/335c8f1566d8e44c384d16b450a18554896d4e8b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/91e61dd7a0af660408e87372d8330ceb218be302"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ab67c2fd3d070a21914d0c31319d3858ab4e199c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/d72e126e9a36d3d33889829df8fc90100bb0e071"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ef21007a7b581c7fe64d5a10c320880a033c837b"
    }
  ],
  "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"
    }
  ]
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.