{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:13",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.12.96-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:  mm/damon/ops-common: handle extreme intervals in damon_hot_score()  Fix three issues in damon_hot_score() that comes from wrong handling of extreme (zero or too high) monitoring intervals user setup.  When the user sets sampling interval zero, damon_max_nr_accesses(), which is called from damon_hot_score(), causes a divide-by-zero.  Needless to say, it is a problem.  When the user sets the aggregation interval zero, the function returns zero.  It is wrong, since the real maximum nr_acceses in the setup should be one.  Worse yet, it can cause another divide-by-zero from its caller, damon_hot_score(), since it uses damon_max_nr_accesses() return value as a denominator.  When the user sets the aggregation interval very high, damon_hot_score() could return a value out of [0, DAMOS_MAX_SCORE] range.  Since the return value is used as an index to the regions_score_histogram array, which is DAMOS_MAX_SCORE+1 size, it causes out of bounds array access.  The issues can be relatively easily reproduced like below.  The sysfs write permission is required, though.      # ./damo start --damos_action lru_prio --damos_quota_space 100M \\             --damos_quota_interval 1s     # cd /sys/kernel/mm/damon/admin/kdamonds/0     # echo 0 \u003e contexts/0/monitoring_attrs/intervals/sample_us     # echo 0 \u003e contexts/0/monitoring_attrs/intervals/aggr_us     # echo commit \u003e state     # dmesg     [...]     [  131.329762] Oops: divide error: 0000 [#1] SMP NOPTI     [...]     [  131.336089] RIP: 0010:damon_hot_score+0x27/0xd0     [...]  Fix the divide-by-zero intervals problems by explicitly handling the zero intervals in damon_max_nr_accesses().  Fix the out-of-bound array access by applying [0, DAMOS_MAX_SCORE] bounds before returning from damon_hot_score().  The issue was discovered [1] by Sashiko.",
  "id": "DEBIAN-CVE-2026-64458",
  "modified": "2026-07-26T08:48:32.987740486Z",
  "published": "2026-07-25T10:17:30.943Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-64458"
    }
  ],
  "upstream": [
    "CVE-2026-64458"
  ]
}