GHSA-Q89P-4X7P-F9V9

Vulnerability from github – Published: 2026-07-01 15:35 – Updated: 2026-07-01 15:35
VLAI
Details

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

sched_ext: Don't warn on NULL cgrp_moving_from in scx_cgroup_move_task()

A WARN fires when systemd's user manager writes "+cpu +memory +pids" to its own subtree_control while a sched_ext scheduler is loaded:

WARNING: at kernel/sched/ext.c:3227 scx_cgroup_move_task+0xa8/0xb0 scx_cgroup_move_task+0xa8/0xb0 sched_move_task+0x134/0x290 cpu_cgroup_attach+0x39/0x70 cgroup_migrate_execute+0x37d/0x450 cgroup_update_dfl_csses+0x1e3/0x270 cgroup_subtree_control_write+0x3e7/0x440

scx_cgroup_can_attach() arms cgrp_moving_from only when a task's cpu cgroup changes. It can still be NULL when scx_cgroup_move_task() runs, through this sequence:

Step Result


  1. cpu enabled on cgroup G cpu css = A
  2. cpu toggled off then on for G A killed, B created (same cgroup)
  3. an exiting task keeps A alive migration skips it, A now stale
  4. +memory migrates G stale A vs current B pulls cpu in
  5. cpu attach runs for all tasks hits a live, cpu-unchanged task
  6. scx_cgroup_move_task() on it cgrp_moving_from NULL -> WARN

The mismatch is that scx_cgroup_can_attach() keys on cgroup identity while migration drives the move on css identity, so a NULL cgrp_moving_from here is a legitimate css-only migration, not a missing prep.

The call is already gated on cgrp_moving_from, so just drop the warning. ops.cgroup_prep_move() and ops.cgroup_move() stay paired.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-53328"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-01T14:16:40Z",
    "severity": null
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\nsched_ext: Don\u0027t warn on NULL cgrp_moving_from in scx_cgroup_move_task()\n\nA WARN fires when systemd\u0027s user manager writes \"+cpu +memory +pids\" to\nits own subtree_control while a sched_ext scheduler is loaded:\n\n  WARNING: at kernel/sched/ext.c:3227 scx_cgroup_move_task+0xa8/0xb0\n   scx_cgroup_move_task+0xa8/0xb0\n   sched_move_task+0x134/0x290\n   cpu_cgroup_attach+0x39/0x70\n   cgroup_migrate_execute+0x37d/0x450\n   cgroup_update_dfl_csses+0x1e3/0x270\n   cgroup_subtree_control_write+0x3e7/0x440\n\nscx_cgroup_can_attach() arms cgrp_moving_from only when a task\u0027s cpu\ncgroup changes. It can still be NULL when scx_cgroup_move_task() runs,\nthrough this sequence:\n\n  Step                               Result\n  ---------------------------------  ----------------------------------\n  1. cpu enabled on cgroup G         cpu css = A\n  2. cpu toggled off then on for G   A killed, B created (same cgroup)\n  3. an exiting task keeps A alive   migration skips it, A now stale\n  4. +memory migrates G              stale A vs current B pulls cpu in\n  5. cpu attach runs for all tasks   hits a live, cpu-unchanged task\n  6. scx_cgroup_move_task() on it    cgrp_moving_from NULL -\u003e WARN\n\nThe mismatch is that scx_cgroup_can_attach() keys on cgroup identity\nwhile migration drives the move on css identity, so a NULL cgrp_moving_from\nhere is a legitimate css-only migration, not a missing prep.\n\nThe call is already gated on cgrp_moving_from, so just drop the warning.\nops.cgroup_prep_move() and ops.cgroup_move() stay paired.",
  "id": "GHSA-q89p-4x7p-f9v9",
  "modified": "2026-07-01T15:35:18Z",
  "published": "2026-07-01T15:35:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53328"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/02e545c4297a26dbbc41df81b831e7f605bcd306"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/0ffcad63b19a1cadb475c9f405a93607fdcd0d7c"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/bc75f5951fac4e49d175c4433fc08fb1ec01172f"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/cdff2eb97be147d2ce52ac1327841068781f25dc"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

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.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…