ghsa-4hqc-3j39-58mh
Vulnerability from github
Published
2025-03-06 18:31
Modified
2025-03-06 18:31
Details

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

bpf: Reject struct_ops registration that uses module ptr and the module btf_id is missing

There is a UAF report in the bpf_struct_ops when CONFIG_MODULES=n. In particular, the report is on tcp_congestion_ops that has a "struct module *owner" member.

For struct_ops that has a "struct module *owner" member, it can be extended either by the regular kernel module or by the bpf_struct_ops. bpf_try_module_get() will be used to do the refcounting and different refcount is done based on the owner pointer. When CONFIG_MODULES=n, the btf_id of the "struct module" is missing:

WARN: resolve_btfids: unresolved symbol module

Thus, the bpf_try_module_get() cannot do the correct refcounting.

Not all subsystem's struct_ops requires the "struct module *owner" member. e.g. the recent sched_ext_ops.

This patch is to disable bpf_struct_ops registration if the struct_ops has the "struct module *" member and the "struct module" btf_id is missing. The btf_type_is_fwd() helper is moved to the btf.h header file for this test.

This has happened since the beginning of bpf_struct_ops which has gone through many changes. The Fixes tag is set to a recent commit that this patch can apply cleanly. Considering CONFIG_MODULES=n is not common and the age of the issue, targeting for bpf-next also.

Show details on source website


{
  "affected": [],
  "aliases": [
    "CVE-2024-58060"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-416"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-06T16:15:52Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Reject struct_ops registration that uses module ptr and the module btf_id is missing\n\nThere is a UAF report in the bpf_struct_ops when CONFIG_MODULES=n.\nIn particular, the report is on tcp_congestion_ops that has\na \"struct module *owner\" member.\n\nFor struct_ops that has a \"struct module *owner\" member,\nit can be extended either by the regular kernel module or\nby the bpf_struct_ops. bpf_try_module_get() will be used\nto do the refcounting and different refcount is done\nbased on the owner pointer. When CONFIG_MODULES=n,\nthe btf_id of the \"struct module\" is missing:\n\nWARN: resolve_btfids: unresolved symbol module\n\nThus, the bpf_try_module_get() cannot do the correct refcounting.\n\nNot all subsystem\u0027s struct_ops requires the \"struct module *owner\" member.\ne.g. the recent sched_ext_ops.\n\nThis patch is to disable bpf_struct_ops registration if\nthe struct_ops has the \"struct module *\" member and the\n\"struct module\" btf_id is missing. The btf_type_is_fwd() helper\nis moved to the btf.h header file for this test.\n\nThis has happened since the beginning of bpf_struct_ops which has gone\nthrough many changes. The Fixes tag is set to a recent commit that this\npatch can apply cleanly. Considering CONFIG_MODULES=n is not\ncommon and the age of the issue, targeting for bpf-next also.",
  "id": "GHSA-4hqc-3j39-58mh",
  "modified": "2025-03-06T18:31:09Z",
  "published": "2025-03-06T18:31:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58060"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2324fb4e92092837ee278fdd8d60c48ee1a619ce"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/96ea081ed52bf077cad6d00153b6fba68e510767"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b777b14c2a4a4e2322daf8e8ffd42d2b88831b17"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/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.


Loading…

Loading…