{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "7.0.10-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "In the Linux kernel, the following vulnerability has been resolved:  s390/ap: use generic driver_override infrastructure  When the AP masks are updated via apmask_store() or aqmask_store(), ap_bus_revise_bindings() is called after ap_attr_mutex has been released.  This calls __ap_revise_reserved(), which accesses the driver_override field without holding any lock, racing against a concurrent driver_override_store() that may free the old string, resulting in a potential UAF.  Fix this by using the driver-core driver_override infrastructure, which protects all accesses with an internal spinlock.  Note that unlike most other buses, the AP bus does not check driver_override in its match() callback; the override is checked in ap_device_probe() and __ap_revise_reserved() instead.  Also note that we do not enable the driver_override feature of struct bus_type, as AP - in contrast to most other buses - passes \"\" to sysfs_emit() when the driver_override pointer is NULL. Thus, printing \"\\n\" instead of \"(null)\\n\".  Additionally, AP has a custom counter that is modified in the corresponding custom driver_override_store().",
  "id": "DEBIAN-CVE-2026-53116",
  "modified": "2026-09-14T16:47:32.591380465Z",
  "published": "2026-06-24T17:17:25.993Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-53116"
    }
  ],
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "upstream": [
    "CVE-2026-53116"
  ]
}