GHSA-7CJR-2C82-2WH7

Vulnerability from github – Published: 2026-05-01 15:30 – Updated: 2026-05-01 15:30
VLAI?
Details

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

counter: rz-mtu3-cnt: do not use struct rz_mtu3_channel's dev member

The counter driver can use HW channels 1 and 2, while the PWM driver can use HW channels 0, 1, 2, 3, 4, 6, 7.

The dev member is assigned both by the counter driver and the PWM driver for channels 1 and 2, to their own struct device instance, overwriting the previous value.

The sub-drivers race to assign their own struct device pointer to the same struct rz_mtu3_channel's dev member.

The dev member of struct rz_mtu3_channel is used by the counter sub-driver for runtime PM.

Depending on the probe order of the counter and PWM sub-drivers, the dev member may point to the wrong struct device instance, causing the counter sub-driver to do runtime PM actions on the wrong device.

To fix this, use the parent pointer of the counter, which is assigned during probe to the correct struct device, not the struct device pointer inside the shared struct rz_mtu3_channel.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-31740"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-01T15:16:36Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ncounter: rz-mtu3-cnt: do not use struct rz_mtu3_channel\u0027s dev member\n\nThe counter driver can use HW channels 1 and 2, while the PWM driver can\nuse HW channels 0, 1, 2, 3, 4, 6, 7.\n\nThe dev member is assigned both by the counter driver and the PWM driver\nfor channels 1 and 2, to their own struct device instance, overwriting\nthe previous value.\n\nThe sub-drivers race to assign their own struct device pointer to the\nsame struct rz_mtu3_channel\u0027s dev member.\n\nThe dev member of struct rz_mtu3_channel is used by the counter\nsub-driver for runtime PM.\n\nDepending on the probe order of the counter and PWM sub-drivers, the\ndev member may point to the wrong struct device instance, causing the\ncounter sub-driver to do runtime PM actions on the wrong device.\n\nTo fix this, use the parent pointer of the counter, which is assigned\nduring probe to the correct struct device, not the struct device pointer\ninside the shared struct rz_mtu3_channel.",
  "id": "GHSA-7cjr-2c82-2wh7",
  "modified": "2026-05-01T15:30:34Z",
  "published": "2026-05-01T15:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31740"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/28a371be901ef44ee03726c2575d7d6795521fe0"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/2932095c114b98cbb40ccf34fc00d613cb17cead"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/633dfbf0eb2766c597c1a59dd83035c82e14791d"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/63be324c795262f0e316c6fe9b329d83afa1ec93"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6562290225c197e2e193a53de2a517815288dcd1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Detection rules are retrieved from Rulezet.