CVE-2026-63827 (GCVE-0-2026-63827)

Vulnerability from cvelistv5 – Published: 2026-07-19 12:02 – Updated: 2026-08-17 04:51

Title

apparmor: fix use-after-free in rawdata dedup loop

Summary

In the Linux kernel, the following vulnerability has been resolved: apparmor: fix use-after-free in rawdata dedup loop aa_replace_profiles() walks ns->rawdata_list to dedup the incoming policy blob against entries already attached to existing profiles. Per the kernel-doc on struct aa_loaddata, list membership does not hold a reference: profiles hold pcount, and when the last pcount drops, do_ploaddata_rmfs() is queued on a workqueue that takes ns->lock and removes the entry. Between dropping the last pcount and the workqueue running, an entry remains on the list with pcount == 0. aa_get_profile_loaddata() is an unconditional kref_get() on pcount, so when the dedup loop hits such an entry, refcount hardening reports refcount_t: addition on 0; use-after-free. inside aa_replace_profiles(), and the poisoned counter then trips "saturated" and "underflow" warnings on the subsequent uses of the same loaddata. Before commit a0b7091c4de4 ("apparmor: fix race on rawdata dereference") the dedup path used a get_unless_zero-style helper on a single counter, so the existing "if (tmp)" guard was meaningful. The split-refcount refactor introduced aa_get_profile_loaddata(), which has plain kref_get() semantics, and the guard quietly became a no-op. Introduce aa_get_profile_loaddata_not0(), matching the existing _not0 convention used by aa_get_profile_not0(), and use it for the rawdata_list dedup lookup so dying entries are skipped. Reproduced on x86_64 with v7.1-rc5 in QEMU+KVM running Ubuntu 24.04 + stress-ng 0.17.06: stress-ng --apparmor 1 --klog-check --timeout 60s Without this patch the three refcount_t warnings fire within a few seconds. With it the same 60 s run is clean. Coverage is a smoke-test only; a longer soak with CONFIG_KASAN, CONFIG_KCSAN and CONFIG_PROVE_LOCKING would be welcome from anyone with the cycles.

Severity

7.8 (High)


                        
                          CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Assigner

Linux mitre root Scorecard

References

8 references

URL	Tags
https://git.kernel.org/stable/c/643221da57dbb1a8f…
https://git.kernel.org/stable/c/b17f0c59cc1525765…
https://git.kernel.org/stable/c/a7a2890028f16e5b0…
https://git.kernel.org/stable/c/15fd83a1e42ede150…
https://git.kernel.org/stable/c/ce261a20b41db522e…
https://git.kernel.org/stable/c/c3ca2631073b2cef0…
https://git.kernel.org/stable/c/5e34fa9f6f7cd688a…
https://git.kernel.org/stable/c/6f060496d03e4dc56…

Impacted products

2 products

Vendor	Product	Version	CPE status
Linux	Linux	Affected: 3b8e77c7abab40e6de9ad9de730d77984a498840 , < 643221da57dbb1a8fd800610331cf1ec27969f71 (git) Affected: d9d8560b9b7932f8cffc4c068c14289220900f79 , < b17f0c59cc1525765625cf07d0391b7f9c1ed7e5 (git) Affected: 6b6ba87579c7e7c669e0bec91823e7fb693bc5df , < a7a2890028f16e5b0af0bb005d80fcb32559cca3 (git) Affected: 6ef1f2926c41ab96952d9696d55a052f1b3a9418 , < 15fd83a1e42ede15070968806bb6c8b1a5170688 (git) Affected: f9761add6d100962a23996cb68f3d6abdd4d1815 , < ce261a20b41db522e320a41bbf1292bf85af66df (git) Affected: af782cc8871e3683ddd5a3cd2f7df526599863a9 , < c3ca2631073b2cef06824fd2bfc452ff7a1023de (git) Affected: a0b7091c4de45a7325c8780e6934a894f92ac86b , < 5e34fa9f6f7cd688ae153fff13139a5cf2d42339 (git) Affected: a0b7091c4de45a7325c8780e6934a894f92ac86b , < 6f060496d03e4dc560a40f73770bd08335cb7a27 (git) Affected: 763e838adc3c7ec5a7df2990ce84cad951e42721 (git) Affected: 5.10.253 , < 5.10.261 (semver) Affected: 5.15.203 , < 5.15.212 (semver) Affected: 6.1.169 , < 6.1.177 (semver) Affected: 6.6.130 , < 6.6.144 (semver) Affected: 6.12.77 , < 6.12.95 (semver) Affected: 6.18.18 , < 6.18.38 (semver) Affected: 6.19.8 , < 6.20 (semver)	guessed
Linux	Linux	Affected: 7.0 Unaffected: 0 , < 7.0 (semver) Unaffected: 5.10.261 , ≤ 5.10.* (semver) Unaffected: 5.15.212 , ≤ 5.15.* (semver) Unaffected: 6.1.177 , ≤ 6.1.* (semver) Unaffected: 6.6.144 , ≤ 6.6.* (semver) Unaffected: 6.12.95 , ≤ 6.12.* (semver) Unaffected: 6.18.38 , ≤ 6.18.* (semver) Unaffected: 7.1.3 , ≤ 7.1.* (semver) Unaffected: 7.2 , ≤ * (original_commit_for_fix)	guessed

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "security/apparmor/include/policy_unpack.h",
            "security/apparmor/policy.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "643221da57dbb1a8fd800610331cf1ec27969f71",
              "status": "affected",
              "version": "3b8e77c7abab40e6de9ad9de730d77984a498840",
              "versionType": "git"
            },
            {
              "lessThan": "b17f0c59cc1525765625cf07d0391b7f9c1ed7e5",
              "status": "affected",
              "version": "d9d8560b9b7932f8cffc4c068c14289220900f79",
              "versionType": "git"
            },
            {
              "lessThan": "a7a2890028f16e5b0af0bb005d80fcb32559cca3",
              "status": "affected",
              "version": "6b6ba87579c7e7c669e0bec91823e7fb693bc5df",
              "versionType": "git"
            },
            {
              "lessThan": "15fd83a1e42ede15070968806bb6c8b1a5170688",
              "status": "affected",
              "version": "6ef1f2926c41ab96952d9696d55a052f1b3a9418",
              "versionType": "git"
            },
            {
              "lessThan": "ce261a20b41db522e320a41bbf1292bf85af66df",
              "status": "affected",
              "version": "f9761add6d100962a23996cb68f3d6abdd4d1815",
              "versionType": "git"
            },
            {
              "lessThan": "c3ca2631073b2cef06824fd2bfc452ff7a1023de",
              "status": "affected",
              "version": "af782cc8871e3683ddd5a3cd2f7df526599863a9",
              "versionType": "git"
            },
            {
              "lessThan": "5e34fa9f6f7cd688ae153fff13139a5cf2d42339",
              "status": "affected",
              "version": "a0b7091c4de45a7325c8780e6934a894f92ac86b",
              "versionType": "git"
            },
            {
              "lessThan": "6f060496d03e4dc560a40f73770bd08335cb7a27",
              "status": "affected",
              "version": "a0b7091c4de45a7325c8780e6934a894f92ac86b",
              "versionType": "git"
            },
            {
              "status": "affected",
              "version": "763e838adc3c7ec5a7df2990ce84cad951e42721",
              "versionType": "git"
            },
            {
              "lessThan": "5.10.261",
              "status": "affected",
              "version": "5.10.253",
              "versionType": "semver"
            },
            {
              "lessThan": "5.15.212",
              "status": "affected",
              "version": "5.15.203",
              "versionType": "semver"
            },
            {
              "lessThan": "6.1.177",
              "status": "affected",
              "version": "6.1.169",
              "versionType": "semver"
            },
            {
              "lessThan": "6.6.144",
              "status": "affected",
              "version": "6.6.130",
              "versionType": "semver"
            },
            {
              "lessThan": "6.12.95",
              "status": "affected",
              "version": "6.12.77",
              "versionType": "semver"
            },
            {
              "lessThan": "6.18.38",
              "status": "affected",
              "version": "6.18.18",
              "versionType": "semver"
            },
            {
              "lessThan": "6.20",
              "status": "affected",
              "version": "6.19.8",
              "versionType": "semver"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "security/apparmor/include/policy_unpack.h",
            "security/apparmor/policy.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "7.0"
            },
            {
              "lessThan": "7.0",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.10.*",
              "status": "unaffected",
              "version": "5.10.261",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.15.*",
              "status": "unaffected",
              "version": "5.15.212",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.1.*",
              "status": "unaffected",
              "version": "6.1.177",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.144",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.12.*",
              "status": "unaffected",
              "version": "6.12.95",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.18.*",
              "status": "unaffected",
              "version": "6.18.38",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "7.1.*",
              "status": "unaffected",
              "version": "7.1.3",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "7.2",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.10.261",
                  "versionStartIncluding": "5.10.253",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.15.212",
                  "versionStartIncluding": "5.15.203",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.1.177",
                  "versionStartIncluding": "6.1.169",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.6.144",
                  "versionStartIncluding": "6.6.130",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.12.95",
                  "versionStartIncluding": "6.12.77",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.18.38",
                  "versionStartIncluding": "6.18.18",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.1.3",
                  "versionStartIncluding": "7.0",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.2",
                  "versionStartIncluding": "7.0",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionStartIncluding": "6.19.8",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\napparmor: fix use-after-free in rawdata dedup loop\n\naa_replace_profiles() walks ns-\u003erawdata_list to dedup the incoming\npolicy blob against entries already attached to existing profiles.\nPer the kernel-doc on struct aa_loaddata, list membership does not\nhold a reference: profiles hold pcount, and when the last pcount\ndrops, do_ploaddata_rmfs() is queued on a workqueue that takes\nns-\u003elock and removes the entry. Between dropping the last pcount\nand the workqueue running, an entry remains on the list with\npcount == 0.\n\naa_get_profile_loaddata() is an unconditional kref_get() on\npcount, so when the dedup loop hits such an entry, refcount\nhardening reports\n\n  refcount_t: addition on 0; use-after-free.\n\ninside aa_replace_profiles(), and the poisoned counter then\ntrips \"saturated\" and \"underflow\" warnings on the subsequent\nuses of the same loaddata.\n\nBefore commit a0b7091c4de4 (\"apparmor: fix race on rawdata\ndereference\") the dedup path used a get_unless_zero-style helper\non a single counter, so the existing \"if (tmp)\" guard was\nmeaningful. The split-refcount refactor introduced\naa_get_profile_loaddata(), which has plain kref_get() semantics,\nand the guard quietly became a no-op.\n\nIntroduce aa_get_profile_loaddata_not0(), matching the existing\n_not0 convention used by aa_get_profile_not0(), and use it for\nthe rawdata_list dedup lookup so dying entries are skipped.\n\nReproduced on x86_64 with v7.1-rc5 in QEMU+KVM running Ubuntu\n24.04 + stress-ng 0.17.06:\n\n  stress-ng --apparmor 1 --klog-check --timeout 60s\n\nWithout this patch the three refcount_t warnings fire within a\nfew seconds. With it the same 60 s run is clean. Coverage is a\nsmoke-test only; a longer soak with CONFIG_KASAN, CONFIG_KCSAN\nand CONFIG_PROVE_LOCKING would be welcome from anyone with the\ncycles."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 7.8,
            "baseSeverity": "HIGH",
            "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "AV:L - The bug is reached only via local write() to AppArmor policy management interfaces (.load/.replace) under securityfs/apparmorfs, not through any network-facing protocol.\nAC:L - An attacker with policy-admin capability can reliably win the race by concurrently loading/replacing and removing profiles with identical rawdata blobs, as demonstrated by stress-ng reproducing refcount UAF warnings within seconds.\nPR:L - Triggering aa_replace_profiles() requires CAP_MAC_ADMIN plus policy-view rights; on typical AppArmor deployments (e.g. Ubuntu) namespace-root in an unprivileged user namespace can obtain CAP_MAC_ADMIN via unprivileged_userns_apparmor_policy without init-namespace root.\nUI:N - Exploitation is driven entirely by the attacker\u0027s own policy load/replace/remove operations and does not require any action from another user or administrator.\nS:U - Impact is kernel memory corruption and potential local privilege escalation within the same kernel security boundary, not a cross-VM or cross-security-authority escape.\nC:H - The vulnerability is a use-after-free on aa_loaddata profile refcounts; refcount hardening reports \"addition on 0; use-after-free\" and poisons the counter, creating a path to arbitrary kernel memory disclosure.\nI:H - UAF and refcount saturation/underflow on aa_loaddata enable heap corruption primitives that can be leveraged for arbitrary kernel writes and local privilege escalation.\nA:H - The bug reliably triggers refcount_t UAF warnings and corrupts subsequent refcount operations on the same loaddata, causing kernel instability and potential crash/panic under concurrent policy management."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-17T04:51:35.761Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/643221da57dbb1a8fd800610331cf1ec27969f71"
        },
        {
          "url": "https://git.kernel.org/stable/c/b17f0c59cc1525765625cf07d0391b7f9c1ed7e5"
        },
        {
          "url": "https://git.kernel.org/stable/c/a7a2890028f16e5b0af0bb005d80fcb32559cca3"
        },
        {
          "url": "https://git.kernel.org/stable/c/15fd83a1e42ede15070968806bb6c8b1a5170688"
        },
        {
          "url": "https://git.kernel.org/stable/c/ce261a20b41db522e320a41bbf1292bf85af66df"
        },
        {
          "url": "https://git.kernel.org/stable/c/c3ca2631073b2cef06824fd2bfc452ff7a1023de"
        },
        {
          "url": "https://git.kernel.org/stable/c/5e34fa9f6f7cd688ae153fff13139a5cf2d42339"
        },
        {
          "url": "https://git.kernel.org/stable/c/6f060496d03e4dc560a40f73770bd08335cb7a27"
        }
      ],
      "title": "apparmor: fix use-after-free in rawdata dedup loop",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2026-63827",
    "datePublished": "2026-07-19T12:02:22.083Z",
    "dateReserved": "2026-07-19T07:54:57.014Z",
    "dateUpdated": "2026-08-17T04:51:35.761Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-63827",
      "date": "2026-09-29",
      "epss": "0.00124",
      "percentile": "0.01826"
    },
    "microsoft_vex": {
      "current_release_date": "2026-08-14T17:59:26.000Z",
      "cve": "CVE-2026-63827",
      "id": "msrc_CVE-2026-63827",
      "initial_release_date": "2026-07-20T01:08:16.000Z",
      "product_status:fixed": "1",
      "product_status:known_affected": "1",
      "source": "Microsoft CSAF VEX",
      "status": "final",
      "title": "apparmor: fix use-after-free in rawdata dedup loop",
      "url": "https://msrc.microsoft.com/csaf/vex/2026/msrc_cve-2026-63827.json",
      "version": "7"
    },
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "defaultStatus": "unaffected",
                "product": "Linux",
                "programFiles": [
                  "security/apparmor/include/policy_unpack.h",
                  "security/apparmor/policy.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "lessThan": "643221da57dbb1a8fd800610331cf1ec27969f71",
                    "status": "affected",
                    "version": "3b8e77c7abab40e6de9ad9de730d77984a498840",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "b17f0c59cc1525765625cf07d0391b7f9c1ed7e5",
                    "status": "affected",
                    "version": "d9d8560b9b7932f8cffc4c068c14289220900f79",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "a7a2890028f16e5b0af0bb005d80fcb32559cca3",
                    "status": "affected",
                    "version": "6b6ba87579c7e7c669e0bec91823e7fb693bc5df",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "15fd83a1e42ede15070968806bb6c8b1a5170688",
                    "status": "affected",
                    "version": "6ef1f2926c41ab96952d9696d55a052f1b3a9418",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "ce261a20b41db522e320a41bbf1292bf85af66df",
                    "status": "affected",
                    "version": "f9761add6d100962a23996cb68f3d6abdd4d1815",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "c3ca2631073b2cef06824fd2bfc452ff7a1023de",
                    "status": "affected",
                    "version": "af782cc8871e3683ddd5a3cd2f7df526599863a9",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "5e34fa9f6f7cd688ae153fff13139a5cf2d42339",
                    "status": "affected",
                    "version": "a0b7091c4de45a7325c8780e6934a894f92ac86b",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "6f060496d03e4dc560a40f73770bd08335cb7a27",
                    "status": "affected",
                    "version": "a0b7091c4de45a7325c8780e6934a894f92ac86b",
                    "versionType": "git"
                  },
                  {
                    "status": "affected",
                    "version": "763e838adc3c7ec5a7df2990ce84cad951e42721",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "5.10.261",
                    "status": "affected",
                    "version": "5.10.253",
                    "versionType": "semver"
                  },
                  {
                    "lessThan": "5.15.212",
                    "status": "affected",
                    "version": "5.15.203",
                    "versionType": "semver"
                  },
                  {
                    "lessThan": "6.1.177",
                    "status": "affected",
                    "version": "6.1.169",
                    "versionType": "semver"
                  },
                  {
                    "lessThan": "6.6.144",
                    "status": "affected",
                    "version": "6.6.130",
                    "versionType": "semver"
                  },
                  {
                    "lessThan": "6.12.95",
                    "status": "affected",
                    "version": "6.12.77",
                    "versionType": "semver"
                  },
                  {
                    "lessThan": "6.18.38",
                    "status": "affected",
                    "version": "6.18.18",
                    "versionType": "semver"
                  },
                  {
                    "lessThan": "6.20",
                    "status": "affected",
                    "version": "6.19.8",
                    "versionType": "semver"
                  }
                ]
              },
              {
                "defaultStatus": "affected",
                "product": "Linux",
                "programFiles": [
                  "security/apparmor/include/policy_unpack.h",
                  "security/apparmor/policy.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "status": "affected",
                    "version": "7.0"
                  },
                  {
                    "lessThan": "7.0",
                    "status": "unaffected",
                    "version": "0",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "5.10.*",
                    "status": "unaffected",
                    "version": "5.10.261",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "5.15.*",
                    "status": "unaffected",
                    "version": "5.15.212",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.1.*",
                    "status": "unaffected",
                    "version": "6.1.177",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.6.*",
                    "status": "unaffected",
                    "version": "6.6.144",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.12.*",
                    "status": "unaffected",
                    "version": "6.12.95",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.18.*",
                    "status": "unaffected",
                    "version": "6.18.38",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "7.1.*",
                    "status": "unaffected",
                    "version": "7.1.3",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "*",
                    "status": "unaffected",
                    "version": "7.2",
                    "versionType": "original_commit_for_fix"
                  }
                ]
              }
            ],
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
          }
        ],
        "cveTags": [],
        "descriptions": [
          {
            "lang": "en",
            "value": "In the Linux kernel, the following vulnerability has been resolved:\n\napparmor: fix use-after-free in rawdata dedup loop\n\naa_replace_profiles() walks ns-\u003erawdata_list to dedup the incoming\npolicy blob against entries already attached to existing profiles.\nPer the kernel-doc on struct aa_loaddata, list membership does not\nhold a reference: profiles hold pcount, and when the last pcount\ndrops, do_ploaddata_rmfs() is queued on a workqueue that takes\nns-\u003elock and removes the entry. Between dropping the last pcount\nand the workqueue running, an entry remains on the list with\npcount == 0.\n\naa_get_profile_loaddata() is an unconditional kref_get() on\npcount, so when the dedup loop hits such an entry, refcount\nhardening reports\n\n  refcount_t: addition on 0; use-after-free.\n\ninside aa_replace_profiles(), and the poisoned counter then\ntrips \"saturated\" and \"underflow\" warnings on the subsequent\nuses of the same loaddata.\n\nBefore commit a0b7091c4de4 (\"apparmor: fix race on rawdata\ndereference\") the dedup path used a get_unless_zero-style helper\non a single counter, so the existing \"if (tmp)\" guard was\nmeaningful. The split-refcount refactor introduced\naa_get_profile_loaddata(), which has plain kref_get() semantics,\nand the guard quietly became a no-op.\n\nIntroduce aa_get_profile_loaddata_not0(), matching the existing\n_not0 convention used by aa_get_profile_not0(), and use it for\nthe rawdata_list dedup lookup so dying entries are skipped.\n\nReproduced on x86_64 with v7.1-rc5 in QEMU+KVM running Ubuntu\n24.04 + stress-ng 0.17.06:\n\n  stress-ng --apparmor 1 --klog-check --timeout 60s\n\nWithout this patch the three refcount_t warnings fire within a\nfew seconds. With it the same 60 s run is clean. Coverage is a\nsmoke-test only; a longer soak with CONFIG_KASAN, CONFIG_KCSAN\nand CONFIG_PROVE_LOCKING would be welcome from anyone with the\ncycles."
          }
        ],
        "id": "CVE-2026-63827",
        "lastModified": "2026-08-17T05:17:20.337",
        "metrics": {
          "cvssMetricV31": [
            {
              "cvssData": {
                "attackComplexity": "LOW",
                "attackVector": "LOCAL",
                "availabilityImpact": "HIGH",
                "baseScore": 7.8,
                "baseSeverity": "HIGH",
                "confidentialityImpact": "HIGH",
                "integrityImpact": "HIGH",
                "privilegesRequired": "LOW",
                "scope": "UNCHANGED",
                "userInteraction": "NONE",
                "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
                "version": "3.1"
              },
              "exploitabilityScore": 1.8,
              "impactScore": 5.9,
              "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
              "type": "Secondary"
            }
          ]
        },
        "published": "2026-07-19T12:16:55.960",
        "references": [
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/15fd83a1e42ede15070968806bb6c8b1a5170688"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/5e34fa9f6f7cd688ae153fff13139a5cf2d42339"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/643221da57dbb1a8fd800610331cf1ec27969f71"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/6f060496d03e4dc560a40f73770bd08335cb7a27"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/a7a2890028f16e5b0af0bb005d80fcb32559cca3"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/b17f0c59cc1525765625cf07d0391b7f9c1ed7e5"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/c3ca2631073b2cef06824fd2bfc452ff7a1023de"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/ce261a20b41db522e320a41bbf1292bf85af66df"
          }
        ],
        "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "vulnStatus": "Awaiting Analysis"
      }
    },
    "redhat_vex": {
      "aggregate_severity": "None",
      "current_release_date": "2026-07-21T08:06:39+00:00",
      "cve": "CVE-2026-63827",
      "id": "CVE-2026-63827",
      "initial_release_date": "2026-07-19T00:00:00+00:00",
      "product_status:known_not_affected": "274",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "kernel: apparmor: fix use-after-free in rawdata dedup loop",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-63827.json",
      "version": "3"
    },
    "suse_vex": {
      "aggregate_severity": "important",
      "current_release_date": "2026-09-24T23:52:21Z",
      "cve": "CVE-2026-63827",
      "id": "CVE-2026-63827",
      "initial_release_date": "2026-07-19T17:34:37Z",
      "product_status:first_fixed": "98",
      "product_status:known_affected": "513",
      "product_status:known_not_affected": "164",
      "product_status:recommended": "332",
      "source": "SUSE CSAF VEX",
      "status": "interim",
      "title": "SUSE CVE CVE-2026-63827",
      "url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2026-63827.json",
      "version": "23"
    }
  }
}

FKIE_CVE-2026-63827

Vulnerability from fkie_nvd - Published: 2026-07-19 12:16 - Updated: 2026-08-17 05:17

Severity

7.8 (High) - CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Summary

References

	URL	Tags
	416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/15fd83a1e42ede15070968806bb6c8b1a5170688
	416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/5e34fa9f6f7cd688ae153fff13139a5cf2d42339
	416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/643221da57dbb1a8fd800610331cf1ec27969f71
	416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/6f060496d03e4dc560a40f73770bd08335cb7a27
	416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/a7a2890028f16e5b0af0bb005d80fcb32559cca3
	416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/b17f0c59cc1525765625cf07d0391b7f9c1ed7e5
	416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/c3ca2631073b2cef06824fd2bfc452ff7a1023de
	416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/ce261a20b41db522e320a41bbf1292bf85af66df

Impacted products

	Vendor	Product	Version

JSON

To clipboard

{
  "affected": [
    {
      "affectedData": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "security/apparmor/include/policy_unpack.h",
            "security/apparmor/policy.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "643221da57dbb1a8fd800610331cf1ec27969f71",
              "status": "affected",
              "version": "3b8e77c7abab40e6de9ad9de730d77984a498840",
              "versionType": "git"
            },
            {
              "lessThan": "b17f0c59cc1525765625cf07d0391b7f9c1ed7e5",
              "status": "affected",
              "version": "d9d8560b9b7932f8cffc4c068c14289220900f79",
              "versionType": "git"
            },
            {
              "lessThan": "a7a2890028f16e5b0af0bb005d80fcb32559cca3",
              "status": "affected",
              "version": "6b6ba87579c7e7c669e0bec91823e7fb693bc5df",
              "versionType": "git"
            },
            {
              "lessThan": "15fd83a1e42ede15070968806bb6c8b1a5170688",
              "status": "affected",
              "version": "6ef1f2926c41ab96952d9696d55a052f1b3a9418",
              "versionType": "git"
            },
            {
              "lessThan": "ce261a20b41db522e320a41bbf1292bf85af66df",
              "status": "affected",
              "version": "f9761add6d100962a23996cb68f3d6abdd4d1815",
              "versionType": "git"
            },
            {
              "lessThan": "c3ca2631073b2cef06824fd2bfc452ff7a1023de",
              "status": "affected",
              "version": "af782cc8871e3683ddd5a3cd2f7df526599863a9",
              "versionType": "git"
            },
            {
              "lessThan": "5e34fa9f6f7cd688ae153fff13139a5cf2d42339",
              "status": "affected",
              "version": "a0b7091c4de45a7325c8780e6934a894f92ac86b",
              "versionType": "git"
            },
            {
              "lessThan": "6f060496d03e4dc560a40f73770bd08335cb7a27",
              "status": "affected",
              "version": "a0b7091c4de45a7325c8780e6934a894f92ac86b",
              "versionType": "git"
            },
            {
              "status": "affected",
              "version": "763e838adc3c7ec5a7df2990ce84cad951e42721",
              "versionType": "git"
            },
            {
              "lessThan": "5.10.261",
              "status": "affected",
              "version": "5.10.253",
              "versionType": "semver"
            },
            {
              "lessThan": "5.15.212",
              "status": "affected",
              "version": "5.15.203",
              "versionType": "semver"
            },
            {
              "lessThan": "6.1.177",
              "status": "affected",
              "version": "6.1.169",
              "versionType": "semver"
            },
            {
              "lessThan": "6.6.144",
              "status": "affected",
              "version": "6.6.130",
              "versionType": "semver"
            },
            {
              "lessThan": "6.12.95",
              "status": "affected",
              "version": "6.12.77",
              "versionType": "semver"
            },
            {
              "lessThan": "6.18.38",
              "status": "affected",
              "version": "6.18.18",
              "versionType": "semver"
            },
            {
              "lessThan": "6.20",
              "status": "affected",
              "version": "6.19.8",
              "versionType": "semver"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "security/apparmor/include/policy_unpack.h",
            "security/apparmor/policy.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "7.0"
            },
            {
              "lessThan": "7.0",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.10.*",
              "status": "unaffected",
              "version": "5.10.261",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.15.*",
              "status": "unaffected",
              "version": "5.15.212",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.1.*",
              "status": "unaffected",
              "version": "6.1.177",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.144",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.12.*",
              "status": "unaffected",
              "version": "6.12.95",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.18.*",
              "status": "unaffected",
              "version": "6.18.38",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "7.1.*",
              "status": "unaffected",
              "version": "7.1.3",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "7.2",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\napparmor: fix use-after-free in rawdata dedup loop\n\naa_replace_profiles() walks ns-\u003erawdata_list to dedup the incoming\npolicy blob against entries already attached to existing profiles.\nPer the kernel-doc on struct aa_loaddata, list membership does not\nhold a reference: profiles hold pcount, and when the last pcount\ndrops, do_ploaddata_rmfs() is queued on a workqueue that takes\nns-\u003elock and removes the entry. Between dropping the last pcount\nand the workqueue running, an entry remains on the list with\npcount == 0.\n\naa_get_profile_loaddata() is an unconditional kref_get() on\npcount, so when the dedup loop hits such an entry, refcount\nhardening reports\n\n  refcount_t: addition on 0; use-after-free.\n\ninside aa_replace_profiles(), and the poisoned counter then\ntrips \"saturated\" and \"underflow\" warnings on the subsequent\nuses of the same loaddata.\n\nBefore commit a0b7091c4de4 (\"apparmor: fix race on rawdata\ndereference\") the dedup path used a get_unless_zero-style helper\non a single counter, so the existing \"if (tmp)\" guard was\nmeaningful. The split-refcount refactor introduced\naa_get_profile_loaddata(), which has plain kref_get() semantics,\nand the guard quietly became a no-op.\n\nIntroduce aa_get_profile_loaddata_not0(), matching the existing\n_not0 convention used by aa_get_profile_not0(), and use it for\nthe rawdata_list dedup lookup so dying entries are skipped.\n\nReproduced on x86_64 with v7.1-rc5 in QEMU+KVM running Ubuntu\n24.04 + stress-ng 0.17.06:\n\n  stress-ng --apparmor 1 --klog-check --timeout 60s\n\nWithout this patch the three refcount_t warnings fire within a\nfew seconds. With it the same 60 s run is clean. Coverage is a\nsmoke-test only; a longer soak with CONFIG_KASAN, CONFIG_KCSAN\nand CONFIG_PROVE_LOCKING would be welcome from anyone with the\ncycles."
    }
  ],
  "id": "CVE-2026-63827",
  "lastModified": "2026-08-17T05:17:20.337",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "LOCAL",
          "availabilityImpact": "HIGH",
          "baseScore": 7.8,
          "baseSeverity": "HIGH",
          "confidentialityImpact": "HIGH",
          "integrityImpact": "HIGH",
          "privilegesRequired": "LOW",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 1.8,
        "impactScore": 5.9,
        "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "type": "Secondary"
      }
    ]
  },
  "published": "2026-07-19T12:16:55.960",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/15fd83a1e42ede15070968806bb6c8b1a5170688"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/5e34fa9f6f7cd688ae153fff13139a5cf2d42339"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/643221da57dbb1a8fd800610331cf1ec27969f71"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/6f060496d03e4dc560a40f73770bd08335cb7a27"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/a7a2890028f16e5b0af0bb005d80fcb32559cca3"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/b17f0c59cc1525765625cf07d0391b7f9c1ed7e5"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/c3ca2631073b2cef06824fd2bfc452ff7a1023de"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/ce261a20b41db522e320a41bbf1292bf85af66df"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Awaiting Analysis"
}

GHSA-GPP3-G5WP-8XHW

Vulnerability from github – Published: 2026-07-19 12:30 – Updated: 2026-07-24 15:32

Details

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

apparmor: fix use-after-free in rawdata dedup loop

aa_replace_profiles() walks ns->rawdata_list to dedup the incoming policy blob against entries already attached to existing profiles. Per the kernel-doc on struct aa_loaddata, list membership does not hold a reference: profiles hold pcount, and when the last pcount drops, do_ploaddata_rmfs() is queued on a workqueue that takes ns->lock and removes the entry. Between dropping the last pcount and the workqueue running, an entry remains on the list with pcount == 0.

aa_get_profile_loaddata() is an unconditional kref_get() on pcount, so when the dedup loop hits such an entry, refcount hardening reports

refcount_t: addition on 0; use-after-free.

inside aa_replace_profiles(), and the poisoned counter then trips "saturated" and "underflow" warnings on the subsequent uses of the same loaddata.

Before commit a0b7091c4de4 ("apparmor: fix race on rawdata dereference") the dedup path used a get_unless_zero-style helper on a single counter, so the existing "if (tmp)" guard was meaningful. The split-refcount refactor introduced aa_get_profile_loaddata(), which has plain kref_get() semantics, and the guard quietly became a no-op.

Introduce aa_get_profile_loaddata_not0(), matching the existing _not0 convention used by aa_get_profile_not0(), and use it for the rawdata_list dedup lookup so dying entries are skipped.

Reproduced on x86_64 with v7.1-rc5 in QEMU+KVM running Ubuntu 24.04 + stress-ng 0.17.06:

stress-ng --apparmor 1 --klog-check --timeout 60s

Without this patch the three refcount_t warnings fire within a few seconds. With it the same 60 s run is clean. Coverage is a smoke-test only; a longer soak with CONFIG_KASAN, CONFIG_KCSAN and CONFIG_PROVE_LOCKING would be welcome from anyone with the cycles.

Severity

7.8 (High)


                  
                    CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-63827"
  ],
  "database_specific": {
    "cwe_ids": [],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-19T12:16:55Z",
    "severity": "HIGH"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\napparmor: fix use-after-free in rawdata dedup loop\n\naa_replace_profiles() walks ns-\u003erawdata_list to dedup the incoming\npolicy blob against entries already attached to existing profiles.\nPer the kernel-doc on struct aa_loaddata, list membership does not\nhold a reference: profiles hold pcount, and when the last pcount\ndrops, do_ploaddata_rmfs() is queued on a workqueue that takes\nns-\u003elock and removes the entry. Between dropping the last pcount\nand the workqueue running, an entry remains on the list with\npcount == 0.\n\naa_get_profile_loaddata() is an unconditional kref_get() on\npcount, so when the dedup loop hits such an entry, refcount\nhardening reports\n\n  refcount_t: addition on 0; use-after-free.\n\ninside aa_replace_profiles(), and the poisoned counter then\ntrips \"saturated\" and \"underflow\" warnings on the subsequent\nuses of the same loaddata.\n\nBefore commit a0b7091c4de4 (\"apparmor: fix race on rawdata\ndereference\") the dedup path used a get_unless_zero-style helper\non a single counter, so the existing \"if (tmp)\" guard was\nmeaningful. The split-refcount refactor introduced\naa_get_profile_loaddata(), which has plain kref_get() semantics,\nand the guard quietly became a no-op.\n\nIntroduce aa_get_profile_loaddata_not0(), matching the existing\n_not0 convention used by aa_get_profile_not0(), and use it for\nthe rawdata_list dedup lookup so dying entries are skipped.\n\nReproduced on x86_64 with v7.1-rc5 in QEMU+KVM running Ubuntu\n24.04 + stress-ng 0.17.06:\n\n  stress-ng --apparmor 1 --klog-check --timeout 60s\n\nWithout this patch the three refcount_t warnings fire within a\nfew seconds. With it the same 60 s run is clean. Coverage is a\nsmoke-test only; a longer soak with CONFIG_KASAN, CONFIG_KCSAN\nand CONFIG_PROVE_LOCKING would be welcome from anyone with the\ncycles.",
  "id": "GHSA-gpp3-g5wp-8xhw",
  "modified": "2026-07-24T15:32:43Z",
  "published": "2026-07-19T12:30:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63827"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/15fd83a1e42ede15070968806bb6c8b1a5170688"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/5e34fa9f6f7cd688ae153fff13139a5cf2d42339"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/643221da57dbb1a8fd800610331cf1ec27969f71"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6f060496d03e4dc560a40f73770bd08335cb7a27"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a7a2890028f16e5b0af0bb005d80fcb32559cca3"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/b17f0c59cc1525765625cf07d0391b7f9c1ed7e5"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/c3ca2631073b2cef06824fd2bfc452ff7a1023de"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ce261a20b41db522e320a41bbf1292bf85af66df"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

MSRC_CVE-2026-63827

Vulnerability from csaf_microsoft - Published: 2026-07-20 01:08 - Updated: 2026-08-14 17:59

Summary

apparmor: fix use-after-free in rawdata dedup loop

Scope

1 vulnerability in this advisory, including CVE-2026-63827.

CVE-2026-63827

Fixed: 1 product Known affected: 1 product

https://learn.microsoft.com/en-us/azure/azure-linux/tutoria…

Open the full advisory

OESA-2026-3303 (CVE-2026-31747)

Vulnerability from osv_openeuler – Published: 2026-08-07 02:45 – Updated: 2026-08-07 02:45 – Source website

Summary

kernel security update

Details

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

comedi: me4000: Fix potential overrun of firmware buffer

me4000_xilinx_download() loads the firmware that was requested by request_firmware(). It is possible for it to overrun the source buffer because it blindly trusts the file format. It reads a data stream length from the first 4 bytes into variable file_length and reads the data stream contents of length file_length from offset 16 onwards.

Add a test to ensure that the supplied firmware is long enough to contain the header and the data stream. On failure, log an error and return -EINVAL.

Note: The firmware loading was totally broken before commit ac584af59945 ("staging: comedi: me4000: fix firmware downloading"), but that is the most sensible target for this fix.(CVE-2026-31747)

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

ASoC: soc-core: flush delayed work before removing DAIs and widgets

When a sound card is unbound while a PCM stream is open, a use-after-free can occur in snd_soc_dapm_stream_event(), called from the close_delayed_work workqueue handler.

During unbind, snd_soc_unbind_card() flushes delayed work and then calls soc_cleanup_card_resources(). Inside cleanup, snd_card_disconnect_sync() releases all PCM file descriptors, and the resulting PCM close path can call snd_soc_dapm_stream_stop() which schedules new delayed work with a pmdown_time timer delay. Since this happens after the flush in snd_soc_unbind_card(), the new work is not caught. soc_remove_link_components() then frees DAPM widgets before this work fires, leading to the use-after-free.

The existing flush in soc_free_pcm_runtime() also cannot help as it runs after soc_remove_link_components() has already freed the widgets.

Add a flush in soc_cleanup_card_resources() after snd_card_disconnect_sync() (after which no new PCM closes can schedule further delayed work) and before soc_remove_link_dais() and soc_remove_link_components() (which tear down the structures the delayed work accesses).(CVE-2026-43459)

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

fbdev: udlfb: add vm_ops to dlfb_ops_mmap to prevent use-after-free

dlfb_ops_mmap() uses remap_pfn_range() to map vmalloc framebuffer pages to userspace but sets no vm_ops on the VMA. This means the kernel cannot track active mmaps. When dlfb_realloc_framebuffer() replaces the backing buffer via FBIOPUT_VSCREENINFO, existing mmap PTEs are not invalidated. On USB disconnect, dlfb_ops_destroy() calls vfree() on the old pages while userspace PTEs still reference them, resulting in a use-after-free: the process retains read/write access to freed kernel pages.

Add vm_operations_struct with open/close callbacks that maintain an atomic mmap_count on struct dlfb_data. In dlfb_realloc_framebuffer(), check mmap_count and return -EBUSY if the buffer is currently mapped, preventing buffer replacement while userspace holds stale PTEs.

Tested with PoC using dummy_hcd + raw_gadget USB device emulation.(CVE-2026-43497)

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

RDMA/umem: Fix truncation for block sizes >= 4G

When the iommu is used the linearization of the mapping can give a single block that is very large split across multiple SG entries.

When __rdma_block_iter_next() reassembles the split SG entries it is overflowing the 32 bit stack values and computed the wrong DMA addresses for blocks after the truncation.

Use the right types to hold DMA addresses.(CVE-2026-53133)

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

l2tp: pppol2tp: hold reference to session in pppol2tp_ioctl()

pppol2tp_ioctl() read sock->sk->sk_user_data directly without any locks or reference counting. If a controllable sleep was induced during copy_from_user() (e.g. via a userfaultfd page fault sleep), a concurrent socket close could trigger pppol2tp_session_close() asynchronously. This frees the l2tp_session structure via the l2tp_session_del_work workqueue. Upon resuming, the ioctl thread dereferences the stale session pointer, resulting in a Use-After-Free (UAF).

Fix this by securely fetching the session reference using the RCU-safe, refcounted helper pppol2tp_sock_to_session(sk) on entry. This locks the session's refcount across the sleep. We structured the function to exit via standard err breaks, guaranteeing that l2tp_session_put() is cleanly called on all return paths to drop the reference.

To preserve existing behavior we validate the session and its magic signature only for the specific L2TP commands that require it. This ensures that generic/unknown ioctls called on an unconnected socket still return -ENOIOCTLCMD and correctly fall back to generic handlers (e.g. in sock_do_ioctl()).(CVE-2026-53262)

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

fuse: re-lock request before replacing page cache folio

fuse_try_move_folio() unlocks the request on entry but does not re-lock it on the success path. This means fuse_chan_abort() can end the request and free the fuse_io_args (eg fuse_readpages_end()) while the subsequent copy chain logic after fuse_try_move_folio() accesses the fuse_io_args, leading to use-after-free issues.

Fix this by calling lock_request() before replace_page_cache_folio(). This ensures the request is locked on the success path which will prevent the fuse_io_args from being freed while the later copying logic runs, and also ensures that the ap->folios[i]->mapping is never null since ap->folios[i] will always point to the newfolio after replace_page_cache_folio().(CVE-2026-53388)

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

i2c: core: fix adapter registration race

Adapters can be looked up based on their id using i2c_get_adapter() which takes a reference to the embedded struct device.

Make sure that the adapter (including its struct device) has been initialised before adding it to the IDR to avoid accessing uninitialised data which could, for example, lead to NULL-pointer dereferences or use-after-free.

Note that the i2c-dev chardev, which is registered from a bus notifier, currently uses i2c_get_adapter() so the adapter needs to be added to the IDR before registration.(CVE-2026-53400)

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

gcov: use atomic counter updates to fix concurrent access crashes

GCC's GCOV instrumentation can merge global branch counters with loop induction variables as an optimization. In inflate_fast(), the inner copy loops get transformed so that the GCOV counter value is loaded multiple times to compute the loop base address, start index, and end bound. Since GCOV counters are global (not per-CPU), concurrent execution on different CPUs causes the counter to change between loads, producing inconsistent values and out-of-bounds memory writes.

The crash manifests during IPComp (IP Payload Compression) processing when inflate_fast() runs concurrently on multiple CPUs:

BUG: unable to handle page fault for address: ffffd0a3c0902ffa RIP: inflate_fast+1431 Call Trace: zlib_inflate __deflate_decompress crypto_comp_decompress ipcomp_decompress [xfrm_ipcomp] ipcomp_input [xfrm_ipcomp] xfrm_input

At the crash point, the compiler generated three loads from the same global GCOV counter (__gcov0.inflate_fast+216) to compute base, start, and end for an indexed loop. Another CPU modified the counter between loads, making the values inconsistent - the write went 3.4 MB past a 65 KB buffer.

Add -fprofile-update=prefer-atomic to CFLAGS_GCOV at the global level in the top-level Makefile, guarded by a try-run compile test. The test compiles a minimal program with and without -fprofile-update=prefer-atomic using the full KBUILD_CFLAGS, then compares undefined symbols in the resulting object files. If prefer-atomic introduces new undefined references (such as __atomic_fetch_add_8 on i386 or __aarch64_ldadd8_relax on arm64 with outline-atomics), the flag is not added -- the kernel does not link against libatomic.

On architectures where GCC inlines 64-bit atomic counter updates (x86_64, s390, ...) the test passes and the flag is enabled, preventing the compiler from merging counters with loop induction variables and fixing the observed concurrent-access crash.

On architectures where the flag would introduce libatomic dependencies, it is silently omitted and behaviour is no worse than before this patch.

Move the CFLAGS_GCOV block from its original position (before the arch Makefile include) to after the core KBUILD_CFLAGS assignments but before the scripts/Makefile.gcc-plugins include. This placement ensures the try-run test sees arch-specific flags (-m32, -march=, -mno-outline-atomics) while avoiding GCC plugin flags (-fplugin=) that would break the test on clean builds when plugin shared objects do not yet exist.(CVE-2026-63825)

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

apparmor: fix use-after-free in rawdata dedup loop

aa_get_profile_loaddata() is an unconditional kref_get() on pcount, so when the dedup loop hits such an entry, refcount hardening reports

refcount_t: addition on 0; use-after-free.

inside aa_replace_profiles(), and the poisoned counter then trips "saturated" and "underflow" warnings on the subsequent uses of the same loaddata.

Introduce aa_get_profile_loaddata_not0(), matching the existing _not0 convention used by aa_get_profile_not0(), and use it for the rawdata_list dedup lookup so dying entries are skipped.

Reproduced on x86_64 with v7.1-rc5 in QEMU+KVM running Ubuntu 24.04 + stress-ng 0.17.06:

stress-ng --apparmor 1 --klog-check --timeout 60s

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

scsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf

iscsi_encode_text_output() concatenates "key=value\0" records into login->rsp_buf, an 8192-byte kzalloc(MAX_KEY_VALUE_PAIRS) buffer allocated in iscsit_alloc_login_setup_buffer(). The three sprintf() call sites in this function (lines 1398, 1411, 1424 in v7.1-rc2) never check the remaining buffer capacity:

*length += sprintf(output_buf, &quot;%s=%s&quot;, er-&gt;key, er-&gt;value);
*length += 1;
output_buf = textbuf + *length;

The 8192-byte ceiling at iscsi_target_check_login_request() bounds the input Login PDU payload, but a single PDU can carry up to 2048 minimal four-byte "a=b\0" pairs, each unknown key expanding to a 16-byte "a=NotUnderstood\0" output record via iscsi_add_notunderstood_response(). 2048 * 16 = 32 KiB of output into an 8 KiB buffer, producing a ~24 KiB heap overrun in the kmalloc-8k slab.

The fix introduces a static iscsi_encode_text_record() helper that uses snprintf() with a per-call bounds check against the remaining buffer, and threads a u32 textbuf_size parameter through iscsi_encode_text_output(). Both call sites in iscsi_target_handle_csg_zero() (PHASE_SECURITY) and iscsi_target_handle_csg_one() (PHASE_OPERATIONAL) pass MAX_KEY_VALUE_PAIRS. On overflow the encoder logs the condition, calls iscsi_release_extra_responses() to drop queued records, and returns -1; both caller sites now emit ISCSI_STATUS_CLS_INITIATOR_ERR / ISCSI_LOGIN_STATUS_INIT_ERR via iscsit_tx_login_rsp() before returning, so the initiator sees an explicit failed-login response rather than a silent connection drop. (Prior to this patch only the PHASE_OPERATIONAL caller did that; the PHASE_SECURITY caller is converted to the same shape.)(CVE-2026-63887)

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

scsi: target: iscsi: Fix CRC overread and double-free in iscsit_handle_text_cmd()

Two latent bugs in the Text-phase handler, both present since the original LIO integration in commit e48354ce078c ("iscsi-target: Add iSCSI fabric support for target v4.1"):

1) DataDigest CRC buffer overread (4 bytes past text_in).

text_in is kzalloc()'d at ALIGN(payload_length, 4). rx_size is then incremented by ISCSI_CRC_LEN to make room for the received DataDigest in the iovec, but the same (now-bumped) rx_size is passed as the buffer length to iscsit_crc_buf():

   if (conn-&gt;conn_ops-&gt;DataDigest) {
           ...
           rx_size += ISCSI_CRC_LEN;
   }
   ...
   if (conn-&gt;conn_ops-&gt;DataDigest) {
           data_crc = iscsit_crc_buf(text_in, rx_size, 0, NULL);

iscsit_crc_buf() walks rx_size bytes of text_in with crc32c(), so when DataDigest is negotiated it reads 4 bytes past the end of the text_in allocation. KASAN reproduces this directly on the unpatched mainline tree as slab-out-of-bounds in crc32c() called from the Text PDU path. The OOB bytes feed crc32c() and are then compared against the initiator-supplied checksum, so the value does not flow back to the attacker, but the kernel does read past the buffer on every Text PDU with DataDigest=CRC32C.

Fix by passing the actual padded payload length (ALIGN(payload_length, 4)) that was used for the kzalloc().

2) Stale cmd->text_in_ptr re-free (double-free) on ERL>0 bad DataDigest drop.

On DataDigest mismatch with ErrorRecoveryLevel > 0 the handler silently drops the PDU and lets the initiator plug the CmdSN gap:

           kfree(text_in);
           return 0;

cmd->text_in_ptr still points at the freed buffer. The next Text Request on the same ITT re-enters iscsit_setup_text_cmd(), which unconditionally does

   kfree(cmd-&gt;text_in_ptr);
   cmd-&gt;text_in_ptr = NULL;

freeing the same pointer a second time. Session teardown via iscsit_release_cmd() has the same shape and hits the same double-free if the connection is dropped before a second Text Request arrives.

On an unmodified mainline tree the bug-1 CRC overread fires first on the initial valid Text Request and perturbs the subsequent state, so #4 was isolated by building a kernel with only the bug-1 hunk of this patch applied plus temporary printk() observability around the three relevant kfree() sites. The observability prints are not part of this patch. On that build, a three-PDU Text Request sequence after login produces two back-to-back splats:

   BUG: KASAN: double-free in iscsit_setup_text_cmd+0x??
   BUG: KASAN: double-free in iscsit_release_cmd+0x??

showing the same pointer freed in the ERL>0 drop path and again in iscsit_setup_text_cmd() (next Text Request on the same ITT) and once more in iscsit_release_cmd() (session teardown). On distro kernels with CONFIG_SLAB_FREELIST_HARDENED=y (default) the double-free becomes a remote kernel BUG(); on non-hardened kernels it corrupts the slab freelist.

Fix by clearing cmd->text_in_ptr after the kfree() in the ERL>0 drop path. With both hunks applied #4 is directly observable on the stock tree without observability printks; fixing bug-1 alone would mask #4 less, not more, so the hunks are submitted together.

Both fixes are one-liners. The Text PDU state machine is unchanged and the wire protocol is unaffected.(CVE-2026-63888)

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

USB: serial: cypress_m8: fix memory corruption with small endpoint

Make sure that the interrupt-out endpoint max packet size is at least eight bytes to avoid user-controlled slab corruption or NULL-pointer dereference should a malicious device report a smaller size.(CVE-2026-63956)

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

Bluetooth: L2CAP: Fix possible crash on l2cap_ecred_conn_rsp

If dcid is received for an already-assigned destination CID the spec requires that both channels to be discarded, but calling l2cap_chan_del may invalidate the tmp cursor created by list_for_each_entry_safe and in fact it is the wrong procedure as the chan->dcid may be assigned previously it really needs to be disconnected.

Calling l2cap_chan_clone directly may still lead to l2cap_chan_del so instead schedule l2cap_chan_timeout with delay 0 to close the channel asynchronously.(CVE-2026-63975)

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

qed: fix double free in qed_cxt_tables_alloc()

If one of the later PF or VF CID bitmap allocations fails, qed_cid_map_alloc() jumps to cid_map_fail and frees the previously allocated CID bitmaps before returning an error. qed_cxt_tables_alloc() then calls qed_cxt_mngr_free(), which invokes qed_cid_map_free() again.

Fix this by setting each CID bitmap pointer to NULL after bitmap_free() to avoid double free.

The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1-rc3.

Runtime reproduction was not attempted because exercising the failing allocation path requires device-specific setup.(CVE-2026-64118)

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

spi: qup: fix error pointer deref after DMA setup failure

The driver falls back to PIO mode if DMA setup fails during probe.

Make sure to the clear the DMA channel pointers on setup failure to avoid dereferencing an error pointer (or attempting to release a channel a second time) on later probe errors or driver unbind.

This issue was flagged by Sashiko when reviewing a devres allocation conversion patch.(CVE-2026-64170)

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

i2c: stub: Reject I2C block transfers with invalid length

The I2C_SMBUS_I2C_BLOCK_DATA case in stub_xfer() uses data->block[0] as the transfer length. The existing check only clamps it to avoid overrunning the chip->words[256] register array, but does not validate it against I2C_SMBUS_BLOCK_MAX (32), which is the limit of the union i2c_smbus_data.block buffer (34 bytes total). The driver is a development/test tool (CONFIG_I2C_STUB=m, not built by default) that must be loaded with a chip_addr= parameter.

A local user with access to /dev/i2c-* can issue an I2C_SMBUS ioctl with I2C_SMBUS_I2C_BLOCK_DATA and data->block[0] > 32, causing stub_xfer() to read or write past the end of the union i2c_smbus_data.block buffer:

BUG: KASAN: stack-out-of-bounds in stub_xfer (drivers/i2c/i2c-stub.c:223) Read of size 1 at addr ffff88800abcfd92 by task exploit/81 Call Trace: <TASK> stub_xfer (drivers/i2c/i2c-stub.c:223) __i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:593) i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:536) i2cdev_ioctl_smbus (drivers/i2c/i2c-dev.c:391) i2cdev_ioctl (drivers/i2c/i2c-dev.c:478) __x64_sys_ioctl (fs/ioctl.c:583) do_syscall_64 (arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) </TASK>

The bug exists because i2c-stub implements .smbus_xfer directly, bypassing the I2C_SMBUS_BLOCK_MAX validation in i2c_smbus_xfer_emulated(). The I2C_SMBUS_BLOCK_DATA case in the same function correctly validates against I2C_SMBUS_BLOCK_MAX, but the I2C_SMBUS_I2C_BLOCK_DATA case does not.

Fix by rejecting transfers with data->block[0] == 0 or data->block[0] > I2C_SMBUS_BLOCK_MAX with -EINVAL, consistent with both the I2C_SMBUS_BLOCK_DATA case in the same function and the I2C_SMBUS_I2C_BLOCK_DATA validation in i2c_smbus_xfer_emulated().(CVE-2026-64191)

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

bpf: Reject BPF_MAP_TYPE_INODE_STORAGE creation if BPF LSM is uninitialized

When CONFIG_BPF_LSM=y is set, BPF inode storage maps (BPF_MAP_TYPE_INODE_STORAGE) are compiled into the kernel. However, if the BPF LSM is not explicitly enabled at boot time (e.g. omitted from the "lsm=" boot parameter), lsm_prepare() is never executed for the BPF LSM.

Consequently, the BPF inode security blob offset (bpf_lsm_blob_sizes.lbs_inode) is never initialized and remains at its default compiled size of 8 bytes instead of being updated to a valid offset past the reserved struct rcu_head (typically 16 bytes or more).

When a privileged user creates and updates a BPF_MAP_TYPE_INODE_STORAGE map, bpf_inode() evaluates inode->i_security + 8. This erroneously aliases the struct rcu_head.func callback pointer at the beginning of the inode->i_security blob. During subsequent map element cleanup or inode destruction, writing NULL to owner_storage clears the queued RCU callback pointer. When rcu_do_batch() later executes the queued callback, it attempts an instruction fetch at address 0x0, triggering an immediate kernel panic.

Fix this by introducing a global bpf_lsm_initialized boolean flag marked with __ro_after_init. Set this flag to true inside bpf_lsm_init() when the LSM framework successfully registers the BPF LSM. Gate map allocation in inode_storage_map_alloc() on this flag, returning -EOPNOTSUPP if the BPF LSM is in turn uninitialized.

This fail-fast approach prevents userspace from allocating inode storage maps when the supporting BPF LSM infrastructure is absent, avoiding zombie map states.(CVE-2026-64192)

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

tracing: Prevent out-of-bounds read in glob matching

String event fields are not necessarily NUL-terminated, so the filter predicate functions (filter_pred_string(), filter_pred_strloc() and filter_pred_strrelloc()) pass the field length to the regex match callbacks, and the length-aware matchers honour it.

regex_match_glob() was the exception: it ignored the length and called glob_match(), which scans the string until it hits a NUL byte. Some string fields are not NUL-terminated. One example is the dynamic char array of the xfs_* namespace tracepoints, which is copied without a trailing NUL. For such a field, glob matching reads past the end of the event field, causing a KASAN slab-out-of-bounds read in glob_match(), reached via regex_match_glob() and filter_match_preds() from the xfs_lookup tracepoint.

Add a length-bounded glob_match_len() and use it from regex_match_glob() so glob matching always stops at the field boundary. The matching loop is factored into a shared helper so glob_match() keeps its behaviour.(CVE-2026-64299)

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

USB: iowarrior: fix use-after-free on disconnect race

mutex_unlock() may access the mutex structure after releasing the lock and therefore cannot be used to manage lifetime of objects directly (unlike spinlocks and refcounts). [1][2]

Use a kref to release the driver data to avoid use-after-free in mutex_unlock() when release() races with disconnect().

[1] a51749ab34d9 ("locking/mutex: Document that mutex_unlock() is non-atomic") [2] 2b9d9e0a9ba0 ("locking/mutex: Clarify that mutex_unlock(), and most other sleeping locks, can still use the lock object after it's unlocked")(CVE-2026-64341)

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

HID: lg-g15: cancel pending work on remove to fix a use-after-free

lg_g15_data is allocated with devm and holds a work item. The report handlers schedule that work straight from device input. lg_g15_event() and lg_g15_v2_event() do it on the backlight cycle key, and lg_g510_leds_event() does it too. The worker dereferences the lg_g15_data back through container_of.

The driver had no remove callback and never cancelled the work. So if a report scheduled the work and the keyboard was then unplugged, devres freed lg_g15_data while the work was still pending or running, and the worker touched freed memory. This is a use-after-free. It is reachable as a race on device unplug.

Add a remove callback that cancels the work before devres frees the state. g15->work is only initialized for the models that schedule it (G15, G15 v2, G510). The G13 and Z-10 leave it zeroed, so guard the cancel on g15->work.func to avoid cancelling a work that was never set up. The g15 NULL test mirrors the one already in lg_g15_raw_event().(CVE-2026-64362)

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

sched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT

RT migration is done aggressively. When a CPU schedules out a high priority RT task for a lower priority task, it will look to see if there's any RT tasks that are waiting to run on another CPU that is of higher priority than the task this CPU is about to run. If it finds one, it will pull that task over to the CPU and allow it to run there instead.

Normally, this pulling is done by looking at the RT overloaded mask (rto) which contains all the CPUs in the scheduler domain with RT tasks that are waiting to run due to a higher priority RT task currently running on their CPU. The CPU that is about to schedule a lower priority task will grab the rq lock of the overloaded CPU and move the RT task from that CPU's runqueue to the local one and schedule the higher priority RT task.

This caused issues when a lot of CPUs would schedule a lower priority task at the same time. They would all try to grab the same runqueue lock of the CPU with the overloaded RT tasks. Only the first CPU that got in will get that task. All the others would wait until they got the runqueue lock and see there's nothing to pull and do nothing. On systems with lots of CPUs, this caused a large latency (up to 500us) which is beyond what PREEMPT_RT is to allow.

The solution to that was to create an RT_PUSH_IPI logic. When any CPU wanted to pull a task, instead of grabbing the runqueue lock of the overloaded CPU, it would start by sending an IPI to the overloaded CPU, and that IPI handler would have the CPU with the waiting RT task do a push instead. Then that handler would send an IPI to the next CPU with overloaded RT tasks, and so on. Note, after the first CPU starts this process, if another CPU wanted to do a pull, it would see that the process has already begun and would only increment a counter to have the IPIs continue again.

The RT_PUSH_IPI solved the latency problem with PREEMPT_RT but could cause a new issue with non PREEMPT_RT. Namely, softirqs run in a threaded context on PREEMPT_RT but they can run in an interrupt context in non-RT.

If an IPI lands on a CPU that has just woken up multiple RT tasks and the current CPU is running a non RT or a low priority RT task, instead of doing a push, it would simply do a schedule on that CPU. But if a softirq was also executing on this CPU, the schedule would need to wait until the softirq finished. Until then, the CPU would still be considered overloaded as there are RT tasks still waiting to run on it.

A live lock occurred on a workload that was doing heavy networking traffic on a large machine where the softirqs would run 500us out of 750us. And it would also be waking up RT tasks, causing the RT pull logic to be constantly executed.

When a softirq triggered on a CPU with RT tasks queued but not running yet, and the other CPUs would see this CPU as being overloaded, they would send an IPI over to it. The CPU would notice that the waiting RT tasks are of higher priority than the currently running task and simply schedule that CPU instead. But because the softirq was executing, before it could schedule, it would receive another IPI to do the same. The amount of IPIs would slow down the currently running softirq so much that before it could return back to task context, it would execute another softirq never allowing the CPU to schedule. This live locked that CPU.

As RT_PUSH_IPI was created to help PREEMPT_RT, make it default off if PREEMPT_RT is not enabled.(CVE-2026-64374)

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

writeback: fix race between cgroup_writeback_umount() and inode_switch_wbs()

When a container exits, the following BUG_ON() is occasionally triggered:

================================================================== VFS: Busy inodes after unmount of sdb (ext4) ------------[ cut here ]------------ kernel BUG at fs/super.c:695! CPU: 3 PID: 6 Comm: containerd-shim Tainted: G OE K 6.6 #1 pstate: 63400009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : generic_shutdown_super+0xf0/0x100 lr : generic_shutdown_super+0xf0/0x100 Call trace: generic_shutdown_super+0xf0/0x100 kill_block_super+0x20/0x48 ext4_kill_sb+0x28/0x60 deactivate_locked_super+0x54/0x130 deactivate_super+0x84/0xa0 cleanup_mnt+0xa4/0x140 __cleanup_mnt+0x18/0x28 task_work_run+0x78/0xe0 do_notify_resume+0x204/0x240 ==================================================================

The root cause is a race between cgroup_writeback_umount() and inode_switch_wbs()/cleanup_offline_cgwb(). There is a window between inode_prepare_wbs_switch() returning true and the subsequent wb_queue_isw() call. Following is the process that triggers the issue:

  CPU A (umount)           |          CPU B (writeback)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ inode_switch_wbs/cleanup_offline_cgwb atomic_inc(&isw_nr_in_flight) inode_prepare_wbs_switch -> passes SB_ACTIVE check __iget(inode) generic_shutdown_super sb->s_flags &= ~SB_ACTIVE cgroup_writeback_umount(sb) smp_mb() atomic_read(&isw_nr_in_flight) rcu_barrier() -> no pending RCU callbacks flush_workqueue(isw_wq) -> nothing queued, returns evict_inodes(sb) -> Inode skipped as isw still holds a ref. sop->put_super(sb) / destroys percpu counters / -> VFS: Busy inodes after unmount! wb_queue_isw() queue_work(isw_wq, ...) / later in work function / inode_switch_wbs_work_fn process_inode_switch_wbs iput() -> evict percpu_counter_dec() // UAF!

Fix this by extending the RCU read-side critical section in inode_switch_wbs() and cleanup_offline_cgwb() to cover from inode_prepare_wbs_switch() through wb_queue_isw(). Since there is no sleep in this window, rcu_read_lock() can be used. Then add a synchronize_rcu() in cgroup_writeback_umount() before the existing rcu_barrier(), so that all in-flight switchers that have passed the SB_ACTIVE check have completed queue_work() before flush_workqueue() is called.

The existing rcu_barrier() is intentionally retained so this fix can be backported unchanged to stable kernels (5.10.y, 6.6.y, ...) that still queue switches via queue_rcu_work(). It is a no-op on current mainline (since commit e1b849cfa6b6 ("writeback: Avoid contention on wb->list_lock when switching inodes")) and is removed in a follow-up patch.(CVE-2026-64378)

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

ksmbd: serialize QUERY_DIRECTORY requests per file

smb2_query_dir() stores a pointer to its stack-allocated private data in the ksmbd_file readdir_data. Concurrent QUERY_DIRECTORY requests using the same file handle can overwrite this pointer while an iterate_dir() callback is still using it, resulting in a stack use-after-free.

Add a per-file mutex and hold it while accessing the shared directory enumeration state. The lock covers scan restart, dot entry state, readdir_data setup and iteration, and response construction. This prevents another request from replacing readdir_data.private before the current request has finished using it and also serializes the shared file position.(CVE-2026-64397)

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

hwrng: virtio: clamp device-reported used.len at copy_data()

random_recv_done() stores the device-reported used.len directly into vi->data_avail. copy_data() then indexes vi->data[] using vi->data_idx (advanced by previous copy_data() calls) and issues a memcpy() without re-validating either value against the posted buffer size sizeof(vi->data) (SMP_CACHE_BYTES bytes, typically 32 or 64).

A malicious or buggy virtio-rng backend can set used.len beyond sizeof(vi->data), steering the memcpy() past the end of the inline array into adjacent kmalloc-1k slab bytes. hwrng_fillfn() mixes those bytes into the guest RNG, and guest root can also observe them directly via /dev/hwrng.

Concrete impact is inside the guest:

Memory-safety / hardening: any virtio-rng backend that over-reports used.len causes the driver to read past vi->data into unrelated slab contents. hwrng_fillfn() is a kernel thread that runs as soon as the device is probed; no guest userspace interaction is required to first-trigger the OOB.
Cross-boundary leak (confidential-compute threat model): a malicious hypervisor cooperating with a malicious or compromised guest root userspace can use /dev/hwrng as a leak channel for guest-kernel heap data. The host sets a large used.len, guest root reads /dev/hwrng, and the returned bytes contain guest kernel slab contents that were adjacent to vi->data. In practice, confidential-compute guests (SEV-SNP, TDX) usually disable virtio-rng entirely, so this path is narrow, but the fix is still worth carrying because the underlying memory-safety bug contaminates the guest RNG on any host.

KASAN confirms the OOB on a 7.1-rc4 guest whose virtio-rng backend has been patched to report used.len = 0x10000:

BUG: KASAN: slab-out-of-bounds in virtio_read+0x394/0x5d0 Read of size 64 at addr ffff88800ae0ba20 by task hwrng/52 Call Trace: __asan_memcpy+0x23/0x60 virtio_read+0x394/0x5d0 hwrng_fillfn+0xb2/0x470 kthread+0x2cc/0x3a0 Allocated by task 1: probe_common+0xa5/0x660 virtio_dev_probe+0x549/0xbc0 The buggy address belongs to the object at ffff88800ae0b800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 0 bytes to the right of allocated 544-byte region [ffff88800ae0b800, ffff88800ae0ba20)

Same class of bug as commit c04db81cd028 ("net/9p: Fix buffer overflow in USB transport layer"), which hardened usb9pfs_rx_complete() against unchecked device-reported length in the USB 9p transport.

With the clamp at point of use and array_index_nospec() in place, the same harness boots cleanly: copy_data() returns zero for the bogus report, the device-supplied bytes after data_idx are discarded, and the driver issues a fresh request.(CVE-2026-64456)

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

iio: event: Fix event FIFO reset race

iio_event_getfd() creates the event file descriptor with anon_inode_getfd(), which allocates a new fd, creates the anonymous file and installs it in the process fd table before returning to the caller.

The IIO code resets the event FIFO after anon_inode_getfd() has returned, but before IIO_GET_EVENT_FD_IOCTL has copied the fd number to userspace. But since fd tables are shared between threads, another thread can guess the newly allocated fd number and issue a read() on it as soon as the fd has been installed.

This means the kfifo_to_user() in iio_event_chrdev_read() can run in parallel with the kfifo_reset_out() in iio_event_getfd().

The kfifo documentation says that kfifo_reset_out() is only safe when it is called from the reader thread and there is only one concurrent reader. Otherwise it is dangerous and must be handled in the same way as kfifo_reset().

If that happens, kfifo_to_user() can advance the FIFO out index based on state from before the reset, after the reset has already moved the out index to the current in index. That can leave the FIFO with an out index past the in index. A later read() can then see an underflowed FIFO length and copy more data than the event FIFO buffer contains. This can result in an out-of-bounds read and leak adjacent kernel memory to userspace.

Move the FIFO reset before anon_inode_getfd(). At that point the event fd is marked busy, but the new fd has not been installed yet, so userspace cannot access it while the FIFO is reset.(CVE-2026-64496)

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

posix-cpu-timers: Prevent UAF caused by non-leader exec() race

Wongi and Jungwoo decoded and reported a non-leader exec() related race which can result in an UAF:

sys_timer_delete() exec() posix_cpu_timer_del() // Observes old leader p = pid_task(pid, pid_type); de_thread() switch_leader(); release_task(old_leader) __exit_signal(old_leader) sighand = lock(old_leader, sighand); posix_cpu_timers*_exit(); sighand = lock_task_sighand(p) unhash_task(old_leader); sh = lock(p, sighand) old_leader->sighand = NULL; unlock(sighand); (p->sighand == NULL) unlock(sh) return NULL;

// Returns without action if(!sighand) return 0; free_posix_timer();

This is "harmless" unless the deleted timer was armed and enqueued in p->signal because on exec() a TGID targeted timer is inherited.

As sys_timer_delete() freed the underlying posix timer object run_posix_cpu_timers() or any timerqueue related add/delete operations on other timers will access the freed object's timerqueue node, which results in an UAF.

There is a similar problem vs. posix_cpu_timer_set(). For regular posix timers it just transiently returns -ESRCH to user space, but for the use case in do_cpu_nanosleep() it's the same UAF just that the k_itimer is allocated on the stack.

Also posix_cpu_timer_rearm() fails to rearm the timer, which means it stops to expire.

While debating solutions Frederic pointed out another problem:

posix_cpu_timer_del(tmr) __exit_signal(p) posix_cpu_timers*_exit(p); unhash_task(p); p->sighand = NULL; sh = lock_task_sighand(p) sighand = p->sighand; if (!sighand) return NULL; lock(sighand);

 if (!sh)
WARN_ON_ONCE(timer_queued(tmr));

On weakly ordered architectures it is not guaranteed that posix_cpu_timer_del() will observe the stores in posix_cpu_timers*_exit() when p->sighand is observed as NULL, which means the WARN() can be a false positive.

Solve these issues by:

1) Changing the store in __exit_signal() to smp_store_release().

2) Adding a smp_acquire__after_ctrl_dep() into the !sighand path of lock_task_sighand().

3) Creating a helper function for looking up the task and locking sighand which does not return when sighand == NULL. Instead it retries the task lookup and only if that fails it gives up.

4) Using that helper in the three affected functions.

1/#2 ensures that the reader side which observes sighand == NULL also

observes all preceeding stores, i.e. the stores in posix_cpu_timers*_exit() and the ones in unhash_task().

3 ensures that the above described non-leader exec() situation is handled

gracefully. When the task lookup returns the old leader, but sighand == NULL then it retries. In the non-leader exec() case the subsequent task lookup will observe the new leader due to #1/#2. In normal exit() scenarios the subsequent lookup fails.

When the task lookup fails, the function also checks whether the timer is still enqueued and issues a warning if that's the case. Unfortunately there is nothing which can be done about it, but as the task is already not longer visible the timer should not be accessed anymore. This check also requires memory ordering, which is not provided when the first lookup fails. To achieve that the check is preceeded by a smp_rmb() which pairs with the smp_wmb() in write_seqlock() in __exit_signal(). That ensures that the stores in posix_cpu_timers*_exit() are visible.

The history of the non-leader exec() issue goes back to the early days of posix CPU timers, which stored a pointer to the group leader task in the timer. That obviously fails when a non-leader exec() switches the leader. commit e0a70217107e ("posix-cpu-timers: workaround to suppress the problems with mt exec") added a temporary workaround for that in 2010 which surv ---truncated---(CVE-2026-64560)

Severity

9.8 (Critical)


                    
                      CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

References

URL

Type

	https://www.openeuler.org/zh/security/security-bu…	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-31747	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43459	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43497	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-53133	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-53262	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-53388	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-53400	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-63825	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-63827	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-63887	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-63888	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-63956	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-63975	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-64118	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-64170	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-64191	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-64192	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-64299	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-64341	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-64362	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-64374	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-64378	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-64397	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-64456	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-64496	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-64560	ADVISORY

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-5.10.0-327.0.0.228.oe2203sp4.aarch64.rpm",
          "bpftool-debuginfo-5.10.0-327.0.0.228.oe2203sp4.aarch64.rpm",
          "kernel-5.10.0-327.0.0.228.oe2203sp4.aarch64.rpm",
          "kernel-debuginfo-5.10.0-327.0.0.228.oe2203sp4.aarch64.rpm",
          "kernel-debugsource-5.10.0-327.0.0.228.oe2203sp4.aarch64.rpm",
          "kernel-devel-5.10.0-327.0.0.228.oe2203sp4.aarch64.rpm",
          "kernel-headers-5.10.0-327.0.0.228.oe2203sp4.aarch64.rpm",
          "kernel-source-5.10.0-327.0.0.228.oe2203sp4.aarch64.rpm",
          "kernel-tools-5.10.0-327.0.0.228.oe2203sp4.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-327.0.0.228.oe2203sp4.aarch64.rpm",
          "kernel-tools-devel-5.10.0-327.0.0.228.oe2203sp4.aarch64.rpm",
          "perf-5.10.0-327.0.0.228.oe2203sp4.aarch64.rpm",
          "perf-debuginfo-5.10.0-327.0.0.228.oe2203sp4.aarch64.rpm",
          "python3-perf-5.10.0-327.0.0.228.oe2203sp4.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-327.0.0.228.oe2203sp4.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-327.0.0.228.oe2203sp4.src.rpm"
        ],
        "x86_64": [
          "bpftool-5.10.0-327.0.0.228.oe2203sp4.x86_64.rpm",
          "bpftool-debuginfo-5.10.0-327.0.0.228.oe2203sp4.x86_64.rpm",
          "kernel-5.10.0-327.0.0.228.oe2203sp4.x86_64.rpm",
          "kernel-debuginfo-5.10.0-327.0.0.228.oe2203sp4.x86_64.rpm",
          "kernel-debugsource-5.10.0-327.0.0.228.oe2203sp4.x86_64.rpm",
          "kernel-devel-5.10.0-327.0.0.228.oe2203sp4.x86_64.rpm",
          "kernel-headers-5.10.0-327.0.0.228.oe2203sp4.x86_64.rpm",
          "kernel-source-5.10.0-327.0.0.228.oe2203sp4.x86_64.rpm",
          "kernel-tools-5.10.0-327.0.0.228.oe2203sp4.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-327.0.0.228.oe2203sp4.x86_64.rpm",
          "kernel-tools-devel-5.10.0-327.0.0.228.oe2203sp4.x86_64.rpm",
          "perf-5.10.0-327.0.0.228.oe2203sp4.x86_64.rpm",
          "perf-debuginfo-5.10.0-327.0.0.228.oe2203sp4.x86_64.rpm",
          "python3-perf-5.10.0-327.0.0.228.oe2203sp4.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-327.0.0.228.oe2203sp4.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:22.03-LTS-SP4",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.10.0-327.0.0.228.oe2203sp4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "Critical"
  },
  "details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncomedi: me4000: Fix potential overrun of firmware buffer\n\n`me4000_xilinx_download()` loads the firmware that was requested by\n`request_firmware()`.  It is possible for it to overrun the source\nbuffer because it blindly trusts the file format.  It reads a data\nstream length from the first 4 bytes into variable `file_length` and\nreads the data stream contents of length `file_length` from offset 16\nonwards.\n\nAdd a test to ensure that the supplied firmware is long enough to\ncontain the header and the data stream.  On failure, log an error and\nreturn `-EINVAL`.\n\nNote: The firmware loading was totally broken before commit ac584af59945\n(\u0026quot;staging: comedi: me4000: fix firmware downloading\u0026quot;), but that is the\nmost sensible target for this fix.(CVE-2026-31747)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nASoC: soc-core: flush delayed work before removing DAIs and widgets\n\nWhen a sound card is unbound while a PCM stream is open, a\nuse-after-free can occur in snd_soc_dapm_stream_event(), called from\nthe close_delayed_work workqueue handler.\n\nDuring unbind, snd_soc_unbind_card() flushes delayed work and then\ncalls soc_cleanup_card_resources(). Inside cleanup,\nsnd_card_disconnect_sync() releases all PCM file descriptors, and\nthe resulting PCM close path can call snd_soc_dapm_stream_stop()\nwhich schedules new delayed work with a pmdown_time timer delay.\nSince this happens after the flush in snd_soc_unbind_card(), the\nnew work is not caught. soc_remove_link_components() then frees\nDAPM widgets before this work fires, leading to the use-after-free.\n\nThe existing flush in soc_free_pcm_runtime() also cannot help as it\nruns after soc_remove_link_components() has already freed the widgets.\n\nAdd a flush in soc_cleanup_card_resources() after\nsnd_card_disconnect_sync() (after which no new PCM closes can\nschedule further delayed work) and before soc_remove_link_dais()\nand soc_remove_link_components() (which tear down the structures the\ndelayed work accesses).(CVE-2026-43459)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: udlfb: add vm_ops to dlfb_ops_mmap to prevent use-after-free\n\ndlfb_ops_mmap() uses remap_pfn_range() to map vmalloc framebuffer pages\nto userspace but sets no vm_ops on the VMA. This means the kernel cannot\ntrack active mmaps. When dlfb_realloc_framebuffer() replaces the backing\nbuffer via FBIOPUT_VSCREENINFO, existing mmap PTEs are not invalidated.\nOn USB disconnect, dlfb_ops_destroy() calls vfree() on the old pages\nwhile userspace PTEs still reference them, resulting in a use-after-free:\nthe process retains read/write access to freed kernel pages.\n\nAdd vm_operations_struct with open/close callbacks that maintain an\natomic mmap_count on struct dlfb_data. In dlfb_realloc_framebuffer(),\ncheck mmap_count and return -EBUSY if the buffer is currently mapped,\npreventing buffer replacement while userspace holds stale PTEs.\n\nTested with PoC using dummy_hcd + raw_gadget USB device emulation.(CVE-2026-43497)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/umem: Fix truncation for block sizes \u0026gt;= 4G\n\nWhen the iommu is used the linearization of the mapping can give a single\nblock that is very large split across multiple SG entries.\n\nWhen __rdma_block_iter_next() reassembles the split SG entries it is\noverflowing the 32 bit stack values and computed the wrong DMA addresses\nfor blocks after the truncation.\n\nUse the right types to hold DMA addresses.(CVE-2026-53133)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nl2tp: pppol2tp: hold reference to session in pppol2tp_ioctl()\n\npppol2tp_ioctl() read sock-\u0026gt;sk-\u0026gt;sk_user_data directly without any\nlocks or reference counting.  If a controllable sleep was induced during\ncopy_from_user() (e.g. via a userfaultfd page fault sleep), a concurrent\nsocket close could trigger pppol2tp_session_close() asynchronously.  This\nfrees the l2tp_session structure via the l2tp_session_del_work workqueue.\nUpon resuming, the ioctl thread dereferences the stale session pointer,\nresulting in a Use-After-Free (UAF).\n\nFix this by securely fetching the session reference using the RCU-safe,\nrefcounted helper pppol2tp_sock_to_session(sk) on entry.  This locks the\nsession\u0026apos;s refcount across the sleep.  We structured the function to exit\nvia standard err breaks, guaranteeing that l2tp_session_put() is cleanly\ncalled on all return paths to drop the reference.\n\nTo preserve existing behavior we validate the session and its magic\nsignature only for the specific L2TP commands that require it.  This\nensures that generic/unknown ioctls called on an unconnected socket\nstill return -ENOIOCTLCMD and correctly fall back to generic handlers\n(e.g. in sock_do_ioctl()).(CVE-2026-53262)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfuse: re-lock request before replacing page cache folio\n\nfuse_try_move_folio() unlocks the request on entry but does not\nre-lock it on the success path. This means fuse_chan_abort() can end the\nrequest and free the fuse_io_args (eg fuse_readpages_end()) while the\nsubsequent copy chain logic after fuse_try_move_folio() accesses the\nfuse_io_args, leading to use-after-free issues.\n\nFix this by calling lock_request() before replace_page_cache_folio().\nThis ensures the request is locked on the success path which will\nprevent the fuse_io_args from being freed while the later copying logic\nruns, and also ensures that the ap-\u0026gt;folios[i]-\u0026gt;mapping is never null\nsince ap-\u0026gt;folios[i] will always point to the newfolio after\nreplace_page_cache_folio().(CVE-2026-53388)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni2c: core: fix adapter registration race\n\nAdapters can be looked up based on their id using i2c_get_adapter()\nwhich takes a reference to the embedded struct device.\n\nMake sure that the adapter (including its struct device) has been\ninitialised before adding it to the IDR to avoid accessing uninitialised\ndata which could, for example, lead to NULL-pointer dereferences or\nuse-after-free.\n\nNote that the i2c-dev chardev, which is registered from a bus notifier,\ncurrently uses i2c_get_adapter() so the adapter needs to be added to the\nIDR before registration.(CVE-2026-53400)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngcov: use atomic counter updates to fix concurrent access crashes\n\nGCC\u0026apos;s GCOV instrumentation can merge global branch counters with loop\ninduction variables as an optimization.  In inflate_fast(), the inner copy\nloops get transformed so that the GCOV counter value is loaded multiple\ntimes to compute the loop base address, start index, and end bound.  Since\nGCOV counters are global (not per-CPU), concurrent execution on different\nCPUs causes the counter to change between loads, producing inconsistent\nvalues and out-of-bounds memory writes.\n\nThe crash manifests during IPComp (IP Payload Compression) processing when\ninflate_fast() runs concurrently on multiple CPUs:\n\n  BUG: unable to handle page fault for address: ffffd0a3c0902ffa\n  RIP: inflate_fast+1431\n  Call Trace:\n   zlib_inflate\n   __deflate_decompress\n   crypto_comp_decompress\n   ipcomp_decompress [xfrm_ipcomp]\n   ipcomp_input [xfrm_ipcomp]\n   xfrm_input\n\nAt the crash point, the compiler generated three loads from the same\nglobal GCOV counter (__gcov0.inflate_fast+216) to compute base, start, and\nend for an indexed loop.  Another CPU modified the counter between loads,\nmaking the values inconsistent - the write went 3.4 MB past a 65 KB\nbuffer.\n\nAdd -fprofile-update=prefer-atomic to CFLAGS_GCOV at the global level in\nthe top-level Makefile, guarded by a try-run compile test.  The test\ncompiles a minimal program with and without -fprofile-update=prefer-atomic\nusing the full KBUILD_CFLAGS, then compares undefined symbols in the\nresulting object files.  If prefer-atomic introduces new undefined\nreferences (such as __atomic_fetch_add_8 on i386 or __aarch64_ldadd8_relax\non arm64 with outline-atomics), the flag is not added -- the kernel does\nnot link against libatomic.\n\nOn architectures where GCC inlines 64-bit atomic counter updates (x86_64,\ns390, ...) the test passes and the flag is enabled, preventing the\ncompiler from merging counters with loop induction variables and fixing\nthe observed concurrent-access crash.\n\nOn architectures where the flag would introduce libatomic dependencies, it\nis silently omitted and behaviour is no worse than before this patch.\n\nMove the CFLAGS_GCOV block from its original position (before the arch\nMakefile include) to after the core KBUILD_CFLAGS assignments but before\nthe scripts/Makefile.gcc-plugins include.  This placement ensures the\ntry-run test sees arch-specific flags (-m32, -march=,\n-mno-outline-atomics) while avoiding GCC plugin flags (-fplugin=) that\nwould break the test on clean builds when plugin shared objects do not yet\nexist.(CVE-2026-63825)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: fix use-after-free in rawdata dedup loop\n\naa_replace_profiles() walks ns-\u0026gt;rawdata_list to dedup the incoming\npolicy blob against entries already attached to existing profiles.\nPer the kernel-doc on struct aa_loaddata, list membership does not\nhold a reference: profiles hold pcount, and when the last pcount\ndrops, do_ploaddata_rmfs() is queued on a workqueue that takes\nns-\u0026gt;lock and removes the entry. Between dropping the last pcount\nand the workqueue running, an entry remains on the list with\npcount == 0.\n\naa_get_profile_loaddata() is an unconditional kref_get() on\npcount, so when the dedup loop hits such an entry, refcount\nhardening reports\n\n  refcount_t: addition on 0; use-after-free.\n\ninside aa_replace_profiles(), and the poisoned counter then\ntrips \u0026quot;saturated\u0026quot; and \u0026quot;underflow\u0026quot; warnings on the subsequent\nuses of the same loaddata.\n\nBefore commit a0b7091c4de4 (\u0026quot;apparmor: fix race on rawdata\ndereference\u0026quot;) the dedup path used a get_unless_zero-style helper\non a single counter, so the existing \u0026quot;if (tmp)\u0026quot; guard was\nmeaningful. The split-refcount refactor introduced\naa_get_profile_loaddata(), which has plain kref_get() semantics,\nand the guard quietly became a no-op.\n\nIntroduce aa_get_profile_loaddata_not0(), matching the existing\n_not0 convention used by aa_get_profile_not0(), and use it for\nthe rawdata_list dedup lookup so dying entries are skipped.\n\nReproduced on x86_64 with v7.1-rc5 in QEMU+KVM running Ubuntu\n24.04 + stress-ng 0.17.06:\n\n  stress-ng --apparmor 1 --klog-check --timeout 60s\n\nWithout this patch the three refcount_t warnings fire within a\nfew seconds. With it the same 60 s run is clean. Coverage is a\nsmoke-test only; a longer soak with CONFIG_KASAN, CONFIG_KCSAN\nand CONFIG_PROVE_LOCKING would be welcome from anyone with the\ncycles.(CVE-2026-63827)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: iscsi: Bound iscsi_encode_text_output() appends to rsp_buf\n\niscsi_encode_text_output() concatenates \u0026quot;key=value\\0\u0026quot; records into\nlogin-\u0026gt;rsp_buf, an 8192-byte kzalloc(MAX_KEY_VALUE_PAIRS) buffer\nallocated in iscsit_alloc_login_setup_buffer(). The three sprintf() call\nsites in this function (lines 1398, 1411, 1424 in v7.1-rc2) never check\nthe remaining buffer capacity:\n\n\t*length += sprintf(output_buf, \u0026quot;%s=%s\u0026quot;, er-\u0026gt;key, er-\u0026gt;value);\n\t*length += 1;\n\toutput_buf = textbuf + *length;\n\nThe 8192-byte ceiling at iscsi_target_check_login_request() bounds the\n*input* Login PDU payload, but a single PDU can carry up to 2048 minimal\nfour-byte \u0026quot;a=b\\0\u0026quot; pairs, each unknown key expanding to a 16-byte\n\u0026quot;a=NotUnderstood\\0\u0026quot; output record via iscsi_add_notunderstood_response().\n2048 * 16 = 32 KiB of output into an 8 KiB buffer, producing a ~24 KiB\nheap overrun in the kmalloc-8k slab.\n\nThe fix introduces a static iscsi_encode_text_record() helper that uses\nsnprintf() with a per-call bounds check against the remaining buffer,\nand threads a u32 textbuf_size parameter through\niscsi_encode_text_output(). Both call sites in\niscsi_target_handle_csg_zero() (PHASE_SECURITY) and\niscsi_target_handle_csg_one() (PHASE_OPERATIONAL) pass\nMAX_KEY_VALUE_PAIRS. On overflow the encoder logs the condition, calls\niscsi_release_extra_responses() to drop queued records, and returns -1;\nboth caller sites now emit ISCSI_STATUS_CLS_INITIATOR_ERR /\nISCSI_LOGIN_STATUS_INIT_ERR via iscsit_tx_login_rsp() before returning,\nso the initiator sees an explicit failed-login response rather than a\nsilent connection drop. (Prior to this patch only the PHASE_OPERATIONAL\ncaller did that; the PHASE_SECURITY caller is converted to the same\nshape.)(CVE-2026-63887)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: iscsi: Fix CRC overread and double-free in iscsit_handle_text_cmd()\n\nTwo latent bugs in the Text-phase handler, both present since the\noriginal LIO integration in commit e48354ce078c (\u0026quot;iscsi-target: Add\niSCSI fabric support for target v4.1\u0026quot;):\n\n1) DataDigest CRC buffer overread (4 bytes past text_in).\n\n   text_in is kzalloc()\u0026apos;d at ALIGN(payload_length, 4).  rx_size is then\n   incremented by ISCSI_CRC_LEN to make room for the received DataDigest\n   in the iovec, but the same (now-bumped) rx_size is passed as the\n   buffer length to iscsit_crc_buf():\n\n       if (conn-\u0026gt;conn_ops-\u0026gt;DataDigest) {\n               ...\n               rx_size += ISCSI_CRC_LEN;\n       }\n       ...\n       if (conn-\u0026gt;conn_ops-\u0026gt;DataDigest) {\n               data_crc = iscsit_crc_buf(text_in, rx_size, 0, NULL);\n\n   iscsit_crc_buf() walks rx_size bytes of text_in with crc32c(), so\n   when DataDigest is negotiated it reads 4 bytes past the end of the\n   text_in allocation.  KASAN reproduces this directly on the unpatched\n   mainline tree as slab-out-of-bounds in crc32c() called from the Text\n   PDU path.  The OOB bytes feed crc32c() and are then compared against\n   the initiator-supplied checksum, so the value does not flow back to\n   the attacker, but the kernel does read past the buffer on every Text\n   PDU with DataDigest=CRC32C.\n\n   Fix by passing the actual padded payload length\n   (ALIGN(payload_length, 4)) that was used for the kzalloc().\n\n2) Stale cmd-\u0026gt;text_in_ptr re-free (double-free) on ERL\u0026gt;0 bad DataDigest\n   drop.\n\n   On DataDigest mismatch with ErrorRecoveryLevel \u0026gt; 0 the handler\n   silently drops the PDU and lets the initiator plug the CmdSN gap:\n\n               kfree(text_in);\n               return 0;\n\n   cmd-\u0026gt;text_in_ptr still points at the freed buffer.  The next Text\n   Request on the same ITT re-enters iscsit_setup_text_cmd(), which\n   unconditionally does\n\n       kfree(cmd-\u0026gt;text_in_ptr);\n       cmd-\u0026gt;text_in_ptr = NULL;\n\n   freeing the same pointer a second time.  Session teardown via\n   iscsit_release_cmd() has the same shape and hits the same double-free\n   if the connection is dropped before a second Text Request arrives.\n\n   On an unmodified mainline tree the bug-1 CRC overread fires first on\n   the initial valid Text Request and perturbs the subsequent state, so\n   #4 was isolated by building a kernel with only the bug-1 hunk of this\n   patch applied plus temporary printk() observability around the three\n   relevant kfree() sites.  The observability prints are not part of\n   this patch.  On that build, a three-PDU Text Request sequence after\n   login produces two back-to-back splats:\n\n       BUG: KASAN: double-free in iscsit_setup_text_cmd+0x??\n       BUG: KASAN: double-free in iscsit_release_cmd+0x??\n\n   showing the same pointer freed in the ERL\u0026gt;0 drop path and again in\n   iscsit_setup_text_cmd() (next Text Request on the same ITT) and once\n   more in iscsit_release_cmd() (session teardown).  On distro kernels\n   with CONFIG_SLAB_FREELIST_HARDENED=y (default) the double-free\n   becomes a remote kernel BUG(); on non-hardened kernels it corrupts\n   the slab freelist.\n\n   Fix by clearing cmd-\u0026gt;text_in_ptr after the kfree() in the ERL\u0026gt;0 drop\n   path.  With both hunks applied #4 is directly observable on the stock\n   tree without observability printks; fixing bug-1 alone would mask #4\n   less, not more, so the hunks are submitted together.\n\nBoth fixes are one-liners.  The Text PDU state machine is unchanged and\nthe wire protocol is unaffected.(CVE-2026-63888)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nUSB: serial: cypress_m8: fix memory corruption with small endpoint\n\nMake sure that the interrupt-out endpoint max packet size is at least\neight bytes to avoid user-controlled slab corruption or NULL-pointer\ndereference should a malicious device report a smaller size.(CVE-2026-63956)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Fix possible crash on l2cap_ecred_conn_rsp\n\nIf dcid is received for an already-assigned destination CID the spec\nrequires that both channels to be discarded, but calling l2cap_chan_del\nmay invalidate the tmp cursor created by list_for_each_entry_safe and\nin fact it is the wrong procedure as the chan-\u0026gt;dcid may be assigned\npreviously it really needs to be disconnected.\n\nCalling l2cap_chan_clone directly may still lead to l2cap_chan_del so\ninstead schedule l2cap_chan_timeout with delay 0 to close the channel\nasynchronously.(CVE-2026-63975)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nqed: fix double free in qed_cxt_tables_alloc()\n\nIf one of the later PF or VF CID bitmap allocations fails,\nqed_cid_map_alloc() jumps to cid_map_fail and frees the previously\nallocated CID bitmaps before returning an error. qed_cxt_tables_alloc()\nthen calls qed_cxt_mngr_free(), which invokes qed_cid_map_free()\nagain.\n\nFix this by setting each CID bitmap pointer to NULL after bitmap_free()\nto avoid double free.\n\nThe bug was first flagged by an experimental analysis tool we are\ndeveloping for kernel memory-management bugs while analyzing\nv6.13-rc1. The tool is still under development and is not yet publicly\navailable. Manual inspection confirms that the bug is still\npresent in v7.1-rc3.\n\nRuntime reproduction was not attempted because exercising the failing\nallocation path requires device-specific setup.(CVE-2026-64118)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nspi: qup: fix error pointer deref after DMA setup failure\n\nThe driver falls back to PIO mode if DMA setup fails during probe.\n\nMake sure to the clear the DMA channel pointers on setup failure to\navoid dereferencing an error pointer (or attempting to release a channel\na second time) on later probe errors or driver unbind.\n\nThis issue was flagged by Sashiko when reviewing a devres allocation\nconversion patch.(CVE-2026-64170)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ni2c: stub: Reject I2C block transfers with invalid length\n\nThe I2C_SMBUS_I2C_BLOCK_DATA case in stub_xfer() uses data-\u0026gt;block[0]\nas the transfer length. The existing check only clamps it to avoid\noverrunning the chip-\u0026gt;words[256] register array, but does not validate\nit against I2C_SMBUS_BLOCK_MAX (32), which is the limit of the union\ni2c_smbus_data.block buffer (34 bytes total). The driver is a\ndevelopment/test tool (CONFIG_I2C_STUB=m, not built by default)\nthat must be loaded with a chip_addr= parameter.\n\nA local user with access to /dev/i2c-* can issue an I2C_SMBUS ioctl\nwith I2C_SMBUS_I2C_BLOCK_DATA and data-\u0026gt;block[0] \u0026gt; 32, causing\nstub_xfer() to read or write past the end of the union\ni2c_smbus_data.block buffer:\n\n BUG: KASAN: stack-out-of-bounds in stub_xfer (drivers/i2c/i2c-stub.c:223)\n Read of size 1 at addr ffff88800abcfd92 by task exploit/81\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  stub_xfer (drivers/i2c/i2c-stub.c:223)\n  __i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:593)\n  i2c_smbus_xfer (drivers/i2c/i2c-core-smbus.c:536)\n  i2cdev_ioctl_smbus (drivers/i2c/i2c-dev.c:391)\n  i2cdev_ioctl (drivers/i2c/i2c-dev.c:478)\n  __x64_sys_ioctl (fs/ioctl.c:583)\n  do_syscall_64 (arch/x86/entry/syscall_64.c:94)\n  entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\n  \u0026lt;/TASK\u0026gt;\n\nThe bug exists because i2c-stub implements .smbus_xfer directly,\nbypassing the I2C_SMBUS_BLOCK_MAX validation in\ni2c_smbus_xfer_emulated(). The I2C_SMBUS_BLOCK_DATA case in the same\nfunction correctly validates against I2C_SMBUS_BLOCK_MAX, but the\nI2C_SMBUS_I2C_BLOCK_DATA case does not.\n\nFix by rejecting transfers with data-\u0026gt;block[0] == 0 or\ndata-\u0026gt;block[0] \u0026gt; I2C_SMBUS_BLOCK_MAX with -EINVAL, consistent with\nboth the I2C_SMBUS_BLOCK_DATA case in the same function and the\nI2C_SMBUS_I2C_BLOCK_DATA validation in i2c_smbus_xfer_emulated().(CVE-2026-64191)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Reject BPF_MAP_TYPE_INODE_STORAGE creation if BPF LSM is uninitialized\n\nWhen CONFIG_BPF_LSM=y is set, BPF inode storage maps\n(BPF_MAP_TYPE_INODE_STORAGE) are compiled into the kernel. However,\nif the BPF LSM is not explicitly enabled at boot time (e.g. omitted\nfrom the \u0026quot;lsm=\u0026quot; boot parameter), lsm_prepare() is never executed for\nthe BPF LSM.\n\nConsequently, the BPF inode security blob offset\n(bpf_lsm_blob_sizes.lbs_inode) is never initialized and remains at\nits default compiled size of 8 bytes instead of being updated to a\nvalid offset past the reserved struct rcu_head (typically 16 bytes\nor more).\n\nWhen a privileged user creates and updates a BPF_MAP_TYPE_INODE_STORAGE\nmap, bpf_inode() evaluates inode-\u0026gt;i_security + 8. This erroneously\naliases the struct rcu_head.func callback pointer at the beginning\nof the inode-\u0026gt;i_security blob. During subsequent map element cleanup\nor inode destruction, writing NULL to owner_storage clears the queued\nRCU callback pointer. When rcu_do_batch() later executes the queued\ncallback, it attempts an instruction fetch at address 0x0, triggering\nan immediate kernel panic.\n\nFix this by introducing a global bpf_lsm_initialized boolean flag\nmarked with __ro_after_init. Set this flag to true inside bpf_lsm_init()\nwhen the LSM framework successfully registers the BPF LSM. Gate map\nallocation in inode_storage_map_alloc() on this flag, returning\n-EOPNOTSUPP if the BPF LSM is in turn uninitialized.\n\nThis fail-fast approach prevents userspace from allocating inode\nstorage maps when the supporting BPF LSM infrastructure is absent,\navoiding zombie map states.(CVE-2026-64192)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Prevent out-of-bounds read in glob matching\n\nString event fields are not necessarily NUL-terminated, so the filter\npredicate functions (filter_pred_string(), filter_pred_strloc() and\nfilter_pred_strrelloc()) pass the field length to the regex match\ncallbacks, and the length-aware matchers honour it.\n\nregex_match_glob() was the exception: it ignored the length and called\nglob_match(), which scans the string until it hits a NUL byte. Some\nstring fields are not NUL-terminated. One example is the dynamic char\narray of the xfs_* namespace tracepoints, which is copied without a\ntrailing NUL. For such a field, glob matching reads past the end of\nthe event field, causing a KASAN slab-out-of-bounds read in\nglob_match(), reached via regex_match_glob() and filter_match_preds()\nfrom the xfs_lookup tracepoint.\n\nAdd a length-bounded glob_match_len() and use it from regex_match_glob()\nso glob matching always stops at the field boundary. The matching loop\nis factored into a shared helper so glob_match() keeps its behaviour.(CVE-2026-64299)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nUSB: iowarrior: fix use-after-free on disconnect race\n\nmutex_unlock() may access the mutex structure after releasing the lock\nand therefore cannot be used to manage lifetime of objects directly\n(unlike spinlocks and refcounts). [1][2]\n\nUse a kref to release the driver data to avoid use-after-free in\nmutex_unlock() when release() races with disconnect().\n\n[1] a51749ab34d9 (\u0026quot;locking/mutex: Document that mutex_unlock() is non-atomic\u0026quot;)\n[2] 2b9d9e0a9ba0 (\u0026quot;locking/mutex: Clarify that mutex_unlock(), and most\n                   other sleeping locks, can still use the lock object\n                   after it\u0026apos;s unlocked\u0026quot;)(CVE-2026-64341)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nHID: lg-g15: cancel pending work on remove to fix a use-after-free\n\nlg_g15_data is allocated with devm and holds a work item. The report\nhandlers schedule that work straight from device input.\nlg_g15_event() and lg_g15_v2_event() do it on the backlight cycle key,\nand lg_g510_leds_event() does it too. The worker dereferences the\nlg_g15_data back through container_of.\n\nThe driver had no remove callback and never cancelled the work. So if a\nreport scheduled the work and the keyboard was then unplugged, devres\nfreed lg_g15_data while the work was still pending or running, and the\nworker touched freed memory. This is a use-after-free. It is reachable\nas a race on device unplug.\n\nAdd a remove callback that cancels the work before devres frees the\nstate. g15-\u0026gt;work is only initialized for the models that schedule it\n(G15, G15 v2, G510). The G13 and Z-10 leave it zeroed, so guard the\ncancel on g15-\u0026gt;work.func to avoid cancelling a work that was never set\nup. The g15 NULL test mirrors the one already in lg_g15_raw_event().(CVE-2026-64362)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched/rt: Have RT_PUSH_IPI be default off for non PREEMPT_RT\n\nRT migration is done aggressively. When a CPU schedules out a high\npriority RT task for a lower priority task, it will look to see if there\u0026apos;s\nany RT tasks that are waiting to run on another CPU that is of higher\npriority than the task this CPU is about to run. If it finds one, it will\npull that task over to the CPU and allow it to run there instead.\n\nNormally, this pulling is done by looking at the RT overloaded mask (rto)\nwhich contains all the CPUs in the scheduler domain with RT tasks that are\nwaiting to run due to a higher priority RT task currently running on their\nCPU. The CPU that is about to schedule a lower priority task will grab the\nrq lock of the overloaded CPU and move the RT task from that CPU\u0026apos;s runqueue\nto the local one and schedule the higher priority RT task.\n\nThis caused issues when a lot of CPUs would schedule a lower priority task\nat the same time. They would all try to grab the same runqueue lock of\nthe CPU with the overloaded RT tasks. Only the first CPU that got in will\nget that task. All the others would wait until they got the runqueue lock\nand see there\u0026apos;s nothing to pull and do nothing. On systems with lots of\nCPUs, this caused a large latency (up to 500us) which is beyond what\nPREEMPT_RT is to allow.\n\nThe solution to that was to create an RT_PUSH_IPI logic. When any CPU\nwanted to pull a task, instead of grabbing the runqueue lock of the\noverloaded CPU, it would start by sending an IPI to the overloaded CPU,\nand that IPI handler would have the CPU with the waiting RT task do a push\ninstead. Then that handler would send an IPI to the next CPU with\noverloaded RT tasks, and so on. Note, after the first CPU starts this\nprocess, if another CPU wanted to do a pull, it would see that the process\nhas already begun and would only increment a counter to have the IPIs\ncontinue again.\n\nThe RT_PUSH_IPI solved the latency problem with PREEMPT_RT but could cause\na new issue with non PREEMPT_RT. Namely, softirqs run in a threaded\ncontext on PREEMPT_RT but they can run in an interrupt context in non-RT.\n\nIf an IPI lands on a CPU that has just woken up multiple RT tasks and the\ncurrent CPU is running a non RT or a low priority RT task, instead of\ndoing a push, it would simply do a schedule on that CPU. But if a softirq\nwas also executing on this CPU, the schedule would need to wait until the\nsoftirq finished. Until then, the CPU would still be considered overloaded\nas there are RT tasks still waiting to run on it.\n\nA live lock occurred on a workload that was doing heavy networking traffic\non a large machine where the softirqs would run 500us out of 750us. And it\nwould also be waking up RT tasks, causing the RT pull logic to be\nconstantly executed.\n\nWhen a softirq triggered on a CPU with RT tasks queued but not running\nyet, and the other CPUs would see this CPU as being overloaded, they would\nsend an IPI over to it. The CPU would notice that the waiting RT tasks are\nof higher priority than the currently running task and simply schedule\nthat CPU instead. But because the softirq was executing, before it could\nschedule, it would receive another IPI to do the same. The amount of IPIs\nwould slow down the currently running softirq so much that before it could\nreturn back to task context, it would execute another softirq never\nallowing the CPU to schedule. This live locked that CPU.\n\nAs RT_PUSH_IPI was created to help PREEMPT_RT, make it default off if\nPREEMPT_RT is not enabled.(CVE-2026-64374)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nwriteback: fix race between cgroup_writeback_umount() and inode_switch_wbs()\n\nWhen a container exits, the following BUG_ON() is occasionally triggered:\n\n==================================================================\n VFS: Busy inodes after unmount of sdb (ext4)\n ------------[ cut here ]------------\n kernel BUG at fs/super.c:695!\n CPU: 3 PID: 6 Comm: containerd-shim Tainted: G OE K 6.6 #1\n pstate: 63400009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)\n pc : generic_shutdown_super+0xf0/0x100\n lr : generic_shutdown_super+0xf0/0x100\n Call trace:\n  generic_shutdown_super+0xf0/0x100\n  kill_block_super+0x20/0x48\n  ext4_kill_sb+0x28/0x60\n  deactivate_locked_super+0x54/0x130\n  deactivate_super+0x84/0xa0\n  cleanup_mnt+0xa4/0x140\n  __cleanup_mnt+0x18/0x28\n  task_work_run+0x78/0xe0\n  do_notify_resume+0x204/0x240\n==================================================================\n\nThe root cause is a race between cgroup_writeback_umount() and\ninode_switch_wbs()/cleanup_offline_cgwb(). There is a window between\ninode_prepare_wbs_switch() returning true and the subsequent\nwb_queue_isw() call. Following is the process that triggers the issue:\n\n      CPU A (umount)           |          CPU B (writeback)\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n                                 inode_switch_wbs/cleanup_offline_cgwb\n                                  atomic_inc(\u0026amp;isw_nr_in_flight)\n                                  inode_prepare_wbs_switch\n                                   -\u0026gt; passes SB_ACTIVE check\n                                   __iget(inode)\n generic_shutdown_super\n  sb-\u0026gt;s_flags \u0026amp;= ~SB_ACTIVE\n  cgroup_writeback_umount(sb)\n   smp_mb()\n   atomic_read(\u0026amp;isw_nr_in_flight)\n   rcu_barrier()\n    -\u0026gt; no pending RCU callbacks\n   flush_workqueue(isw_wq)\n    -\u0026gt; nothing queued, returns\n  evict_inodes(sb)\n   -\u0026gt; Inode skipped as isw still holds a ref.\n  sop-\u0026gt;put_super(sb)\n   /* destroys percpu counters */\n  -\u0026gt; VFS: Busy inodes after unmount!\n                                  wb_queue_isw()\n                                   queue_work(isw_wq, ...)\n                                  /* later in work function */\n                                  inode_switch_wbs_work_fn\n                                   process_inode_switch_wbs\n                                    iput() -\u0026gt; evict\n                                     percpu_counter_dec() // UAF!\n\nFix this by extending the RCU read-side critical section in\ninode_switch_wbs() and cleanup_offline_cgwb() to cover from\ninode_prepare_wbs_switch() through wb_queue_isw().  Since there is\nno sleep in this window, rcu_read_lock() can be used.  Then add a\nsynchronize_rcu() in cgroup_writeback_umount() before the existing\nrcu_barrier(), so that all in-flight switchers that have passed the\nSB_ACTIVE check have completed queue_work() before flush_workqueue()\nis called.\n\nThe existing rcu_barrier() is intentionally retained so this fix can\nbe backported unchanged to stable kernels (5.10.y, 6.6.y, ...) that\nstill queue switches via queue_rcu_work(). It is a no-op on current\nmainline (since commit e1b849cfa6b6 (\u0026quot;writeback: Avoid contention on\nwb-\u0026gt;list_lock when switching inodes\u0026quot;)) and is removed in a follow-up\npatch.(CVE-2026-64378)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: serialize QUERY_DIRECTORY requests per file\n\nsmb2_query_dir() stores a pointer to its stack-allocated private data in\nthe ksmbd_file readdir_data. Concurrent QUERY_DIRECTORY requests using the\nsame file handle can overwrite this pointer while an iterate_dir() callback\nis still using it, resulting in a stack use-after-free.\n\nAdd a per-file mutex and hold it while accessing the shared directory\nenumeration state. The lock covers scan restart, dot entry state,\nreaddir_data setup and iteration, and response construction. This prevents\nanother request from replacing readdir_data.private before the current\nrequest has finished using it and also serializes the shared file position.(CVE-2026-64397)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhwrng: virtio: clamp device-reported used.len at copy_data()\n\nrandom_recv_done() stores the device-reported used.len directly into\nvi-\u0026gt;data_avail.  copy_data() then indexes vi-\u0026gt;data[] using\nvi-\u0026gt;data_idx (advanced by previous copy_data() calls) and issues a\nmemcpy() without re-validating either value against the posted\nbuffer size sizeof(vi-\u0026gt;data) (SMP_CACHE_BYTES bytes, typically 32\nor 64).\n\nA malicious or buggy virtio-rng backend can set used.len beyond\nsizeof(vi-\u0026gt;data), steering the memcpy() past the end of the inline\narray into adjacent kmalloc-1k slab bytes.  hwrng_fillfn() mixes\nthose bytes into the guest RNG, and guest root can also observe\nthem directly via /dev/hwrng.\n\nConcrete impact is inside the guest:\n\n - Memory-safety / hardening: any virtio-rng backend that\n   over-reports used.len causes the driver to read past vi-\u0026gt;data\n   into unrelated slab contents.  hwrng_fillfn() is a kernel thread\n   that runs as soon as the device is probed; no guest userspace\n   interaction is required to first-trigger the OOB.\n\n - Cross-boundary leak (confidential-compute threat model): a\n   malicious hypervisor cooperating with a malicious or compromised\n   guest root userspace can use /dev/hwrng as a leak channel for\n   guest-kernel heap data.  The host sets a large used.len, guest\n   root reads /dev/hwrng, and the returned bytes contain guest\n   kernel slab contents that were adjacent to vi-\u0026gt;data.  In\n   practice, confidential-compute guests (SEV-SNP, TDX) usually\n   disable virtio-rng entirely, so this path is narrow, but the\n   fix is still worth carrying because the underlying\n   memory-safety bug contaminates the guest RNG on any host.\n\nKASAN confirms the OOB on a 7.1-rc4 guest whose virtio-rng backend\nhas been patched to report used.len = 0x10000:\n\n  BUG: KASAN: slab-out-of-bounds in virtio_read+0x394/0x5d0\n  Read of size 64 at addr ffff88800ae0ba20 by task hwrng/52\n  Call Trace:\n   __asan_memcpy+0x23/0x60\n   virtio_read+0x394/0x5d0\n   hwrng_fillfn+0xb2/0x470\n   kthread+0x2cc/0x3a0\n  Allocated by task 1:\n   probe_common+0xa5/0x660\n   virtio_dev_probe+0x549/0xbc0\n  The buggy address belongs to the object at ffff88800ae0b800\n   which belongs to the cache kmalloc-1k of size 1024\n  The buggy address is located 0 bytes to the right of\n   allocated 544-byte region [ffff88800ae0b800, ffff88800ae0ba20)\n\nSame class of bug as commit c04db81cd028 (\u0026quot;net/9p: Fix buffer\noverflow in USB transport layer\u0026quot;), which hardened\nusb9pfs_rx_complete() against unchecked device-reported length in\nthe USB 9p transport.\n\nWith the clamp at point of use and array_index_nospec() in place,\nthe same harness boots cleanly: copy_data() returns zero for the\nbogus report, the device-supplied bytes after data_idx are\ndiscarded, and the driver issues a fresh request.(CVE-2026-64456)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niio: event: Fix event FIFO reset race\n\n`iio_event_getfd()` creates the event file descriptor with\n`anon_inode_getfd()`, which allocates a new fd, creates the anonymous\nfile and installs it in the process fd table before returning to the\ncaller.\n\nThe IIO code resets the event FIFO after `anon_inode_getfd()` has returned,\nbut before `IIO_GET_EVENT_FD_IOCTL` has copied the fd number to userspace.\nBut since fd tables are shared between threads, another thread can guess\nthe newly allocated fd number and issue a `read()` on it as soon as the fd\nhas been installed.\n\nThis means the `kfifo_to_user()` in `iio_event_chrdev_read()` can run in\nparallel with the `kfifo_reset_out()` in `iio_event_getfd()`.\n\nThe kfifo documentation says that `kfifo_reset_out()` is only safe when it\nis called from the reader thread and there is only one concurrent reader.\nOtherwise it is dangerous and must be handled in the same way as\n`kfifo_reset()`.\n\nIf that happens, `kfifo_to_user()` can advance the FIFO `out` index based\non state from before the reset, after the reset has already moved the `out`\nindex to the current `in` index. That can leave the FIFO with an `out`\nindex past the `in` index. A later `read()` can then see an underflowed\nFIFO length and copy more data than the event FIFO buffer contains. This\ncan result in an out-of-bounds read and leak adjacent kernel memory to\nuserspace.\n\nMove the FIFO reset before `anon_inode_getfd()`. At that point the event fd is\nmarked busy, but the new fd has not been installed yet, so userspace cannot\naccess it while the FIFO is reset.(CVE-2026-64496)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nposix-cpu-timers: Prevent UAF caused by non-leader exec() race\n\nWongi and Jungwoo decoded and reported a non-leader exec() related race\nwhich can result in an UAF:\n\n sys_timer_delete()\t\t\texec()\n   posix_cpu_timer_del()\n   // Observes old leader\n   p = pid_task(pid, pid_type);\t\tde_thread()\n   \t\t\t\t\t  switch_leader();\n\t\t\t\t\t  release_task(old_leader)\n\t\t\t\t\t    __exit_signal(old_leader)\n\t\t\t\t\t      sighand = lock(old_leader, sighand);\n\t\t\t\t\t      posix_cpu_timers*_exit();\n   sighand = lock_task_sighand(p)\t      unhash_task(old_leader);\n     sh = lock(p, sighand)\t    \t      old_leader-\u0026gt;sighand = NULL;\n\t\t\t\t\t      unlock(sighand);\n     (p-\u0026gt;sighand == NULL)\n\tunlock(sh)\n\treturn NULL;\n\n   // Returns without action\n   if(!sighand)\n      return 0;\n   free_posix_timer();\n\nThis is \u0026quot;harmless\u0026quot; unless the deleted timer was armed and enqueued in\np-\u0026gt;signal because on exec() a TGID targeted timer is inherited.\n\nAs sys_timer_delete() freed the underlying posix timer object\nrun_posix_cpu_timers() or any timerqueue related add/delete operations on\nother timers will access the freed object\u0026apos;s timerqueue node, which results\nin an UAF.\n\nThere is a similar problem vs. posix_cpu_timer_set(). For regular posix\ntimers it just transiently returns -ESRCH to user space, but for the use\ncase in do_cpu_nanosleep() it\u0026apos;s the same UAF just that the k_itimer is\nallocated on the stack.\n\nAlso posix_cpu_timer_rearm() fails to rearm the timer, which means it stops\nto expire.\n\nWhile debating solutions Frederic pointed out another problem:\n\n   posix_cpu_timer_del(tmr)\n\t\t\t\t\t__exit_signal(p)\n\t\t\t\t\t  posix_cpu_timers*_exit(p);\n\t\t\t\t\t  unhash_task(p);\n\t\t\t\t\t  p-\u0026gt;sighand = NULL;\n     sh = lock_task_sighand(p)\n        sighand = p-\u0026gt;sighand;\n\tif (!sighand)\n\t    return NULL;\n\tlock(sighand);\n\n     if (!sh)\n\tWARN_ON_ONCE(timer_queued(tmr));\n\nOn weakly ordered architectures it is not guaranteed that\nposix_cpu_timer_del() will observe the stores in posix_cpu_timers*_exit()\nwhen p-\u0026gt;sighand is observed as NULL, which means the WARN() can be a false\npositive.\n\nSolve these issues by:\n\n  1) Changing the store in __exit_signal() to smp_store_release().\n\n  2) Adding a smp_acquire__after_ctrl_dep() into the !sighand path\n     of lock_task_sighand().\n\n  3) Creating a helper function for looking up the task and locking sighand\n     which does not return when sighand == NULL. Instead it retries the\n     task lookup and only if that fails it gives up.\n\n  4) Using that helper in the three affected functions.\n\n#1/#2 ensures that the reader side which observes sighand == NULL also\nobserves all preceeding stores, i.e. the stores in posix_cpu_timers*_exit()\nand the ones in unhash_task().\n\n#3 ensures that the above described non-leader exec() situation is handled\ngracefully. When the task lookup returns the old leader, but sighand ==\nNULL then it retries. In the non-leader exec() case the subsequent task\nlookup will observe the new leader due to #1/#2. In normal exit() scenarios\nthe subsequent lookup fails.\n\nWhen the task lookup fails, the function also checks whether the timer is\nstill enqueued and issues a warning if that\u0026apos;s the case. Unfortunately there\nis nothing which can be done about it, but as the task is already not\nlonger visible the timer should not be accessed anymore. This check also\nrequires memory ordering, which is not provided when the first lookup\nfails. To achieve that the check is preceeded by a smp_rmb() which pairs\nwith the smp_wmb() in write_seqlock() in __exit_signal(). That ensures that\nthe stores in posix_cpu_timers*_exit() are visible.\n\nThe history of the non-leader exec() issue goes back to the early days of\nposix CPU timers, which stored a pointer to the group leader task in the\ntimer. That obviously fails when a non-leader exec() switches the leader.\ncommit e0a70217107e (\u0026quot;posix-cpu-timers: workaround to suppress the problems\nwith mt exec\u0026quot;) added a temporary workaround for that in 2010 which surv\n---truncated---(CVE-2026-64560)",
  "id": "OESA-2026-3303",
  "modified": "2026-08-07T02:45:24Z",
  "published": "2026-08-07T02:45:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3303"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31747"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43459"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43497"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53133"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53262"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53388"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53400"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63825"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63827"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63887"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63888"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63956"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63975"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64118"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64170"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64191"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64192"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64299"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64341"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64362"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64374"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64378"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64397"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64456"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64496"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64560"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2026-31747",
    "CVE-2026-43459",
    "CVE-2026-43497",
    "CVE-2026-53133",
    "CVE-2026-53262",
    "CVE-2026-53388",
    "CVE-2026-53400",
    "CVE-2026-63825",
    "CVE-2026-63827",
    "CVE-2026-63887",
    "CVE-2026-63888",
    "CVE-2026-63956",
    "CVE-2026-63975",
    "CVE-2026-64118",
    "CVE-2026-64170",
    "CVE-2026-64191",
    "CVE-2026-64192",
    "CVE-2026-64299",
    "CVE-2026-64341",
    "CVE-2026-64362",
    "CVE-2026-64374",
    "CVE-2026-64378",
    "CVE-2026-64397",
    "CVE-2026-64456",
    "CVE-2026-64496",
    "CVE-2026-64560"
  ]
}

OPENSUSE-SU-2026:11339-1

Vulnerability from csaf_opensuse - Published: 2026-07-22 00:00 - Updated: 2026-09-23 08:32

Summary

kernel-devel-7.1.4-1.1 on GA media

Severity

Moderate

Scope

68 vulnerabilities in this advisory, including CVE-2026-63827.

CVE-2026-63827

7.8 (High)


                
                  CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Recommended: 16 products

Open the full advisory

OPENSUSE-SU-2026:21555-1

Vulnerability from csaf_opensuse - Published: 2026-08-12 01:09 - Updated: 2026-09-26 08:35

Summary

Security update for the Linux Kernel

Severity

Important

Scope

894 vulnerabilities in this advisory, including CVE-2026-63827.

CVE-2026-63827

7.8 (High)


                
                  CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Recommended: 136 products

Open the full advisory

SUSE-SU-2026:23066-1

Vulnerability from csaf_suse - Published: 2026-08-11 20:56 - Updated: 2026-09-26 08:29

Summary

Security update for the Linux Kernel

Severity

Important

Scope

894 vulnerabilities in this advisory, including CVE-2026-63827.

CVE-2026-63827

7.8 (High)


                
                  CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Recommended: 8 products

Open the full advisory

SUSE-SU-2026:23068-1

Vulnerability from csaf_suse - Published: 2026-08-11 21:26 - Updated: 2026-09-26 08:29

Summary

Security update for the Linux Kernel

Severity

Important

Scope

894 vulnerabilities in this advisory, including CVE-2026-63827.

CVE-2026-63827

7.8 (High)


                
                  CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Recommended: 28 products

Open the full advisory

SUSE-SU-2026:23221-1

Vulnerability from csaf_suse - Published: 2026-08-11 21:26 - Updated: 2026-09-26 08:29

Summary

Security update for the Linux Kernel

Severity

Important

Scope

894 vulnerabilities in this advisory, including CVE-2026-63827.

CVE-2026-63827

7.8 (High)


                
                  CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Recommended: 114 products

Open the full advisory

SUSE-SU-2026:23231-1

Vulnerability from csaf_suse - Published: 2026-08-11 21:26 - Updated: 2026-09-26 08:29

Summary

Security update for the Linux Kernel

Severity

Important

Scope

894 vulnerabilities in this advisory, including CVE-2026-63827.

CVE-2026-63827

7.8 (High)


                
                  CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Recommended: 114 products

Open the full advisory

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.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted

CVE-2026-63827 (GCVE-0-2026-63827)

OESA-2026-3303 (CVE-2026-31747)

1/#2 ensures that the reader side which observes sighand == NULL also

3 ensures that the above described non-leader exec() situation is handled

Tags

Sightings

Nomenclature

Related by attack behaviour