{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:12",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.1.180-1"
            }
          ],
          "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"
            },
            {
              "fixed": "7.1.4-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:  debugobjects: Plug race against a concurrent OOM disable  syzbot reported a puzzling splat:     WARNING: kernel/time/hrtimer.c:443 at stub_timer+0xa/0x20  stub_timer() is installed as timer callback function in hrtimer_fixup_assert_init(), which is invoked when debug_object_assert_init() can't find a shadow object. In that case debug objects emits a warning about it before invoking the fixup.  Though the provided console log lacks this warning and instead has the following a few seconds before the splat:       ODEBUG: Out of memory. ODEBUG disabled  So the object was looked up in debug_object_assert_init() and the lookup failed due a concurrent out of memory situation which disabled debug objects and freed the shadow objects:  debug_object_assert_init()         if (!debug_objects_enabled)         \treturn;                         obj = alloc();                 \t\t\t\tif (!obj) { \t\t\t\t\t\t\t// Out of memory                                                 \tdebug_objects_enabled = false;                                                         free_objects();         obj = lookup_or_alloc();          // The lookup failed because the other side         // removed the objects, so this returns         // an error code as the object in question         // is not statically initialized  \tif (!IS_ERR_OR_NULL(obj))         \treturn;         if (!obj) {         \tdebug_oom();                 return;         }          print(...)            if (!debug_objects_enabled)                 return;          fixup(...)  The debug object splat is skipped because debug_objects_enabled is false, but the fixup callback is invoked unconditionally, which makes the timer disfunctional.  This is only a problem in debug_object_assert_init() and debug_object_activate() as both have to handle statically initialized objects and therefore must handle the error pointer return case gracefully. All other places only handle the found/not found case and the NULL pointer return is a signal for OOM. Otherwise they get a valid shadow object.  Plug the hole by checking whether debug objects are still enabled before invoking the print and fixup function in those two places.",
  "id": "DEBIAN-CVE-2026-68090",
  "modified": "2026-09-14T16:47:38.109054710Z",
  "published": "2026-08-10T12:17:21.717Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-68090"
    }
  ],
  "upstream": [
    "CVE-2026-68090"
  ]
}