Vulnerability-Lookup

CVE-2026-43248 (GCVE-0-2026-43248)

Vulnerability from cvelistv5 – Published: 2026-05-06 11:28 – Updated: 2026-10-30 12:25

Title

vhost: move vdpa group bound check to vhost_vdpa

Summary

In the Linux kernel, the following vulnerability has been resolved: vhost: move vdpa group bound check to vhost_vdpa Remove duplication by consolidating these here. This reduces the posibility of a parent driver missing them. While we're at it, fix a bug in vdpa_sim where a valid ASID can be assigned to a group equal to ngroups, causing an out of bound write.

Severity

7.8 (High)


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

SSVC

Exploitation: none Automatable: no Technical Impact: total

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-10-16 15:16 UTC

CWE

CWE-787 - Out-of-bounds Write

Assigner

Linux CNA under the mitre root

CNA scorecard D 53/100 over 7018 records in the last 180 days details

References

6 references

URL	Tags
https://git.kernel.org/stable/c/69ec8dd6696069c2f…
https://git.kernel.org/stable/c/566899af053246406…
https://git.kernel.org/stable/c/ddb57354634b6ba85…
https://git.kernel.org/stable/c/7441d35d14d9a3d66…
https://git.kernel.org/stable/c/406db68f9cb976a8d…
https://git.kernel.org/stable/c/cd025c1e876b4e262…

Impacted products

2 products

Vendor	Product	Version	CPE status
Linux	Linux	Affected: bda324fd037a6b0d44da5699574ce741ca161bc4 , < 69ec8dd6696069c2f18430d0e05f81d604484ee8 (git) Affected: bda324fd037a6b0d44da5699574ce741ca161bc4 , < 566899af053246406f2faf931044d2b0af8f34d2 (git) Affected: bda324fd037a6b0d44da5699574ce741ca161bc4 , < ddb57354634b6ba851b79da45f1de42c646f27d0 (git) Affected: bda324fd037a6b0d44da5699574ce741ca161bc4 , < 7441d35d14d9a3d66d925d90cb73c75394e6d454 (git) Affected: bda324fd037a6b0d44da5699574ce741ca161bc4 , < 406db68f9cb976a8ddfafd631197264f2307e9c9 (git) Affected: bda324fd037a6b0d44da5699574ce741ca161bc4 , < cd025c1e876b4e262e71398236a1550486a73ede (git)	guessed
Linux	Linux	Affected: 5.19 Unaffected: 0 , < 5.19 (semver) Unaffected: 6.1.191 , ≤ 6.1.* (semver) Unaffected: 6.6.160 , ≤ 6.6.* (semver) Unaffected: 6.12.75 , ≤ 6.12.* (semver) Unaffected: 6.18.16 , ≤ 6.18.* (semver) Unaffected: 6.19.6 , ≤ 6.19.* (semver) Unaffected: 7.0 , ≤ * (original_commit_for_fix)	guessed

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-43248",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-10-16T15:16:04.394477Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "problemTypes": [
          {
            "descriptions": [
              {
                "cweId": "CWE-787",
                "description": "CWE-787 Out-of-bounds Write",
                "lang": "en",
                "type": "CWE"
              }
            ]
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-10-19T19:16:25.299Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/vdpa/mlx5/net/mlx5_vnet.c",
            "drivers/vdpa/vdpa_sim/vdpa_sim.c",
            "drivers/vhost/vdpa.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "69ec8dd6696069c2f18430d0e05f81d604484ee8",
              "status": "affected",
              "version": "bda324fd037a6b0d44da5699574ce741ca161bc4",
              "versionType": "git"
            },
            {
              "lessThan": "566899af053246406f2faf931044d2b0af8f34d2",
              "status": "affected",
              "version": "bda324fd037a6b0d44da5699574ce741ca161bc4",
              "versionType": "git"
            },
            {
              "lessThan": "ddb57354634b6ba851b79da45f1de42c646f27d0",
              "status": "affected",
              "version": "bda324fd037a6b0d44da5699574ce741ca161bc4",
              "versionType": "git"
            },
            {
              "lessThan": "7441d35d14d9a3d66d925d90cb73c75394e6d454",
              "status": "affected",
              "version": "bda324fd037a6b0d44da5699574ce741ca161bc4",
              "versionType": "git"
            },
            {
              "lessThan": "406db68f9cb976a8ddfafd631197264f2307e9c9",
              "status": "affected",
              "version": "bda324fd037a6b0d44da5699574ce741ca161bc4",
              "versionType": "git"
            },
            {
              "lessThan": "cd025c1e876b4e262e71398236a1550486a73ede",
              "status": "affected",
              "version": "bda324fd037a6b0d44da5699574ce741ca161bc4",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/vdpa/mlx5/net/mlx5_vnet.c",
            "drivers/vdpa/vdpa_sim/vdpa_sim.c",
            "drivers/vhost/vdpa.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "5.19"
            },
            {
              "lessThan": "5.19",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.1.*",
              "status": "unaffected",
              "version": "6.1.191",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.160",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.12.*",
              "status": "unaffected",
              "version": "6.12.75",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.18.*",
              "status": "unaffected",
              "version": "6.18.16",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.19.*",
              "status": "unaffected",
              "version": "6.19.6",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "7.0",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.1.191",
                  "versionStartIncluding": "5.19",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.6.160",
                  "versionStartIncluding": "5.19",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.12.75",
                  "versionStartIncluding": "5.19",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.18.16",
                  "versionStartIncluding": "5.19",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.19.6",
                  "versionStartIncluding": "5.19",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "7.0",
                  "versionStartIncluding": "5.19",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nvhost: move vdpa group bound check to vhost_vdpa\n\nRemove duplication by consolidating these here.  This reduces the\nposibility of a parent driver missing them.\n\nWhile we\u0027re at it, fix a bug in vdpa_sim where a valid ASID can be\nassigned to a group equal to ngroups, causing an out of bound write."
        }
      ],
      "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 vulnerable path is reached through local `ioctl()` calls on a `/dev/vhost-vdpa-*` character device, not by network or adjacent traffic.\nAC:L - The attacker controls the ioctl arguments, including the group index and ASID, and no race or external timing condition is required once the device is accessible.\nPR:L - Creating or binding vDPA devices is administrative, but a delegated/local VM or vDPA process with access to the vhost-vdpa device can trigger the ioctl without further kernel capability checks. Choosing the higher severity option, this is Low rather than High.\nUI:N - No victim user action is needed; the local attacker directly opens the device, becomes vhost owner, and issues the ioctl.\nS:U - The impact is corruption of host kernel memory from a local host device interface, which is a standard kernel privilege/security-domain impact rather than a VM escape or separate authority crossing.\nC:H - The missing group bound permits out-of-bounds kernel heap access in the parent set_group_asid path, and such memory corruption can reasonably be developed into kernel memory disclosure.\nI:H - The bug permits an out-of-bounds kernel write of ASID/group state or adjacent locking/state fields, making kernel memory corruption and potential control-flow or privilege manipulation plausible.\nA:H - Even without full exploitation, the out-of-bounds write can corrupt kernel heap state and can reasonably crash or panic the kernel."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-30T12:25:16.645Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/69ec8dd6696069c2f18430d0e05f81d604484ee8"
        },
        {
          "url": "https://git.kernel.org/stable/c/566899af053246406f2faf931044d2b0af8f34d2"
        },
        {
          "url": "https://git.kernel.org/stable/c/ddb57354634b6ba851b79da45f1de42c646f27d0"
        },
        {
          "url": "https://git.kernel.org/stable/c/7441d35d14d9a3d66d925d90cb73c75394e6d454"
        },
        {
          "url": "https://git.kernel.org/stable/c/406db68f9cb976a8ddfafd631197264f2307e9c9"
        },
        {
          "url": "https://git.kernel.org/stable/c/cd025c1e876b4e262e71398236a1550486a73ede"
        }
      ],
      "title": "vhost: move vdpa group bound check to vhost_vdpa",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2026-43248",
    "datePublished": "2026-05-06T11:28:39.578Z",
    "dateReserved": "2026-05-01T14:12:55.996Z",
    "dateUpdated": "2026-10-30T12:25:16.645Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-43248",
      "date": "2026-11-01",
      "epss": "0.00164",
      "percentile": "0.05604"
    },
    "microsoft_vex": {
      "current_release_date": "2026-09-24T02:44:25.000Z",
      "cve": "CVE-2026-43248",
      "id": "msrc_CVE-2026-43248",
      "initial_release_date": "2026-05-07T01:04:12.000Z",
      "product_status:known_affected": "10",
      "source": "Microsoft CSAF VEX",
      "status": "final",
      "title": "vhost: move vdpa group bound check to vhost_vdpa",
      "url": "https://msrc.microsoft.com/csaf/vex/2026/msrc_cve-2026-43248.json",
      "version": "14"
    },
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "defaultStatus": "unaffected",
                "product": "Linux",
                "programFiles": [
                  "drivers/vdpa/mlx5/net/mlx5_vnet.c",
                  "drivers/vdpa/vdpa_sim/vdpa_sim.c",
                  "drivers/vhost/vdpa.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "lessThan": "69ec8dd6696069c2f18430d0e05f81d604484ee8",
                    "status": "affected",
                    "version": "bda324fd037a6b0d44da5699574ce741ca161bc4",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "566899af053246406f2faf931044d2b0af8f34d2",
                    "status": "affected",
                    "version": "bda324fd037a6b0d44da5699574ce741ca161bc4",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "ddb57354634b6ba851b79da45f1de42c646f27d0",
                    "status": "affected",
                    "version": "bda324fd037a6b0d44da5699574ce741ca161bc4",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "7441d35d14d9a3d66d925d90cb73c75394e6d454",
                    "status": "affected",
                    "version": "bda324fd037a6b0d44da5699574ce741ca161bc4",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "406db68f9cb976a8ddfafd631197264f2307e9c9",
                    "status": "affected",
                    "version": "bda324fd037a6b0d44da5699574ce741ca161bc4",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "cd025c1e876b4e262e71398236a1550486a73ede",
                    "status": "affected",
                    "version": "bda324fd037a6b0d44da5699574ce741ca161bc4",
                    "versionType": "git"
                  }
                ]
              },
              {
                "defaultStatus": "affected",
                "product": "Linux",
                "programFiles": [
                  "drivers/vdpa/mlx5/net/mlx5_vnet.c",
                  "drivers/vdpa/vdpa_sim/vdpa_sim.c",
                  "drivers/vhost/vdpa.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "status": "affected",
                    "version": "5.19"
                  },
                  {
                    "lessThan": "5.19",
                    "status": "unaffected",
                    "version": "0",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.1.*",
                    "status": "unaffected",
                    "version": "6.1.191",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.6.*",
                    "status": "unaffected",
                    "version": "6.6.160",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.12.*",
                    "status": "unaffected",
                    "version": "6.12.75",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.18.*",
                    "status": "unaffected",
                    "version": "6.18.16",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.19.*",
                    "status": "unaffected",
                    "version": "6.19.6",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "*",
                    "status": "unaffected",
                    "version": "7.0",
                    "versionType": "original_commit_for_fix"
                  }
                ]
              }
            ],
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
          }
        ],
        "configurations": [
          {
            "nodes": [
              {
                "cpeMatch": [
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "CB25F456-468E-423D-B234-D169351C7208",
                    "versionEndExcluding": "6.12.75",
                    "versionStartIncluding": "5.19",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "B4B8CDA9-BADF-4CF5-8B3B-702DE8EEA40B",
                    "versionEndExcluding": "6.18.16",
                    "versionStartIncluding": "6.13",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "373EEEDA-FAA1-4FB4-B6ED-DB4DD99DBE67",
                    "versionEndExcluding": "6.19.6",
                    "versionStartIncluding": "6.19",
                    "vulnerable": true
                  }
                ],
                "negate": false,
                "operator": "OR"
              }
            ]
          }
        ],
        "cveTags": [],
        "descriptions": [
          {
            "lang": "en",
            "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nvhost: move vdpa group bound check to vhost_vdpa\n\nRemove duplication by consolidating these here.  This reduces the\nposibility of a parent driver missing them.\n\nWhile we\u0027re at it, fix a bug in vdpa_sim where a valid ASID can be\nassigned to a group equal to ngroups, causing an out of bound write."
          }
        ],
        "id": "CVE-2026-43248",
        "lastModified": "2026-10-30T13:18:49.010",
        "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"
            }
          ],
          "ssvcV203": [
            {
              "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "ssvcData": {
                "id": "CVE-2026-43248",
                "options": [
                  {
                    "exploitation": "none"
                  },
                  {
                    "automatable": "no"
                  },
                  {
                    "technicalImpact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-10-16T15:16:04.394477Z",
                "version": "2.0.3"
              }
            }
          ]
        },
        "published": "2026-05-06T12:16:45.380",
        "references": [
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/406db68f9cb976a8ddfafd631197264f2307e9c9"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/566899af053246406f2faf931044d2b0af8f34d2"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "url": "https://git.kernel.org/stable/c/69ec8dd6696069c2f18430d0e05f81d604484ee8"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/7441d35d14d9a3d66d925d90cb73c75394e6d454"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/cd025c1e876b4e262e71398236a1550486a73ede"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/ddb57354634b6ba851b79da45f1de42c646f27d0"
          }
        ],
        "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "vulnStatus": "Modified",
        "weaknesses": [
          {
            "description": [
              {
                "lang": "en",
                "value": "CWE-787"
              }
            ],
            "source": "nvd@nist.gov",
            "type": "Primary"
          },
          {
            "description": [
              {
                "lang": "en",
                "value": "CWE-787"
              }
            ],
            "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
            "type": "Secondary"
          }
        ]
      }
    },
    "redhat_vex": {
      "aggregate_severity": "Moderate",
      "current_release_date": "2026-09-15T11:38:03+00:00",
      "cve": "CVE-2026-43248",
      "id": "CVE-2026-43248",
      "initial_release_date": "2026-05-06T00:00:00+00:00",
      "product_status:fixed": "612",
      "product_status:known_affected": "22",
      "product_status:known_not_affected": "90",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "kernel: vhost: move vdpa group bound check to vhost_vdpa",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-43248.json",
      "version": "3"
    },
    "vulnrichment": {
      "containers": {
        "adp": [
          {
            "metrics": [
              {
                "other": {
                  "content": {
                    "id": "CVE-2026-43248",
                    "options": [
                      {
                        "Exploitation": "none"
                      },
                      {
                        "Automatable": "no"
                      },
                      {
                        "Technical Impact": "total"
                      }
                    ],
                    "role": "CISA Coordinator",
                    "timestamp": "2026-10-16T15:16:04.394477Z",
                    "version": "2.0.3"
                  },
                  "type": "ssvc"
                }
              }
            ],
            "problemTypes": [
              {
                "descriptions": [
                  {
                    "cweId": "CWE-787",
                    "description": "CWE-787 Out-of-bounds Write",
                    "lang": "en",
                    "type": "CWE"
                  }
                ]
              }
            ],
            "providerMetadata": {
              "dateUpdated": "2026-10-16T15:16:05.377Z",
              "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "shortName": "CISA-ADP"
            },
            "title": "CISA ADP Vulnrichment"
          }
        ],
        "cna": {
          "affected": [
            {
              "defaultStatus": "unaffected",
              "product": "Linux",
              "programFiles": [
                "drivers/vdpa/mlx5/net/mlx5_vnet.c",
                "drivers/vdpa/vdpa_sim/vdpa_sim.c",
                "drivers/vhost/vdpa.c"
              ],
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "vendor": "Linux",
              "versions": [
                {
                  "lessThan": "69ec8dd6696069c2f18430d0e05f81d604484ee8",
                  "status": "affected",
                  "version": "bda324fd037a6b0d44da5699574ce741ca161bc4",
                  "versionType": "git"
                },
                {
                  "lessThan": "566899af053246406f2faf931044d2b0af8f34d2",
                  "status": "affected",
                  "version": "bda324fd037a6b0d44da5699574ce741ca161bc4",
                  "versionType": "git"
                },
                {
                  "lessThan": "ddb57354634b6ba851b79da45f1de42c646f27d0",
                  "status": "affected",
                  "version": "bda324fd037a6b0d44da5699574ce741ca161bc4",
                  "versionType": "git"
                },
                {
                  "lessThan": "7441d35d14d9a3d66d925d90cb73c75394e6d454",
                  "status": "affected",
                  "version": "bda324fd037a6b0d44da5699574ce741ca161bc4",
                  "versionType": "git"
                },
                {
                  "lessThan": "406db68f9cb976a8ddfafd631197264f2307e9c9",
                  "status": "affected",
                  "version": "bda324fd037a6b0d44da5699574ce741ca161bc4",
                  "versionType": "git"
                },
                {
                  "lessThan": "cd025c1e876b4e262e71398236a1550486a73ede",
                  "status": "affected",
                  "version": "bda324fd037a6b0d44da5699574ce741ca161bc4",
                  "versionType": "git"
                }
              ]
            },
            {
              "defaultStatus": "affected",
              "product": "Linux",
              "programFiles": [
                "drivers/vdpa/mlx5/net/mlx5_vnet.c",
                "drivers/vdpa/vdpa_sim/vdpa_sim.c",
                "drivers/vhost/vdpa.c"
              ],
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "vendor": "Linux",
              "versions": [
                {
                  "status": "affected",
                  "version": "5.19"
                },
                {
                  "lessThan": "5.19",
                  "status": "unaffected",
                  "version": "0",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "6.1.*",
                  "status": "unaffected",
                  "version": "6.1.191",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "6.6.*",
                  "status": "unaffected",
                  "version": "6.6.160",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "6.12.*",
                  "status": "unaffected",
                  "version": "6.12.75",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "6.18.*",
                  "status": "unaffected",
                  "version": "6.18.16",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "6.19.*",
                  "status": "unaffected",
                  "version": "6.19.6",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "*",
                  "status": "unaffected",
                  "version": "7.0",
                  "versionType": "original_commit_for_fix"
                }
              ]
            }
          ],
          "cpeApplicability": [
            {
              "nodes": [
                {
                  "cpeMatch": [
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "6.1.191",
                      "versionStartIncluding": "5.19",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "6.6.160",
                      "versionStartIncluding": "5.19",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "6.12.75",
                      "versionStartIncluding": "5.19",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "6.18.16",
                      "versionStartIncluding": "5.19",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "6.19.6",
                      "versionStartIncluding": "5.19",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "7.0",
                      "versionStartIncluding": "5.19",
                      "vulnerable": true
                    }
                  ],
                  "negate": false,
                  "operator": "OR"
                }
              ]
            }
          ],
          "descriptions": [
            {
              "lang": "en",
              "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nvhost: move vdpa group bound check to vhost_vdpa\n\nRemove duplication by consolidating these here.  This reduces the\nposibility of a parent driver missing them.\n\nWhile we\u0027re at it, fix a bug in vdpa_sim where a valid ASID can be\nassigned to a group equal to ngroups, causing an out of bound write."
            }
          ],
          "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 vulnerable path is reached through local `ioctl()` calls on a `/dev/vhost-vdpa-*` character device, not by network or adjacent traffic.\nAC:L - The attacker controls the ioctl arguments, including the group index and ASID, and no race or external timing condition is required once the device is accessible.\nPR:L - Creating or binding vDPA devices is administrative, but a delegated/local VM or vDPA process with access to the vhost-vdpa device can trigger the ioctl without further kernel capability checks. Choosing the higher severity option, this is Low rather than High.\nUI:N - No victim user action is needed; the local attacker directly opens the device, becomes vhost owner, and issues the ioctl.\nS:U - The impact is corruption of host kernel memory from a local host device interface, which is a standard kernel privilege/security-domain impact rather than a VM escape or separate authority crossing.\nC:H - The missing group bound permits out-of-bounds kernel heap access in the parent set_group_asid path, and such memory corruption can reasonably be developed into kernel memory disclosure.\nI:H - The bug permits an out-of-bounds kernel write of ASID/group state or adjacent locking/state fields, making kernel memory corruption and potential control-flow or privilege manipulation plausible.\nA:H - Even without full exploitation, the out-of-bounds write can corrupt kernel heap state and can reasonably crash or panic the kernel."
                }
              ]
            }
          ],
          "providerMetadata": {
            "dateUpdated": "2026-10-30T12:25:16.645Z",
            "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "shortName": "Linux"
          },
          "references": [
            {
              "url": "https://git.kernel.org/stable/c/69ec8dd6696069c2f18430d0e05f81d604484ee8"
            },
            {
              "url": "https://git.kernel.org/stable/c/566899af053246406f2faf931044d2b0af8f34d2"
            },
            {
              "url": "https://git.kernel.org/stable/c/ddb57354634b6ba851b79da45f1de42c646f27d0"
            },
            {
              "url": "https://git.kernel.org/stable/c/7441d35d14d9a3d66d925d90cb73c75394e6d454"
            },
            {
              "url": "https://git.kernel.org/stable/c/406db68f9cb976a8ddfafd631197264f2307e9c9"
            },
            {
              "url": "https://git.kernel.org/stable/c/cd025c1e876b4e262e71398236a1550486a73ede"
            }
          ],
          "title": "vhost: move vdpa group bound check to vhost_vdpa",
          "x_generator": {
            "engine": "bippy-1.2.0"
          }
        }
      },
      "cveMetadata": {
        "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "assignerShortName": "Linux",
        "cveId": "CVE-2026-43248",
        "datePublished": "2026-05-06T11:28:39.578Z",
        "dateReserved": "2026-05-01T14:12:55.996Z",
        "dateUpdated": "2026-10-30T12:25:16.645Z",
        "state": "PUBLISHED"
      },
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}

MSRC_CVE-2026-43248

Vulnerability from csaf_microsoft - Published: 2026-05-07 01:04 - Updated: 2026-09-24 02:44

Summary

vhost: move vdpa group bound check to vhost_vdpa

Scope

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

CVE-2026-43248

7.8 (High)


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

Known affected: 10 products

Open the full advisory

OESA-2026-2675 (CVE-2025-38389)

Vulnerability from osv_openeuler – Published: 2026-06-12 11:11 – Updated: 2026-08-06 11:11 – 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:

drm/i915/gt: Fix timeline left held on VMA alloc error

The following error has been reported sporadically by CI when a test unbinds the i915 driver on a ring submission platform:

<4> [239.330153] ------------[ cut here ]------------ <4> [239.330166] i915 0000:00:02.0: [drm] drm_WARN_ON(dev_priv->mm.shrink_count) <4> [239.330196] WARNING: CPU: 1 PID: 18570 at drivers/gpu/drm/i915/i915_gem.c:1309 i915_gem_cleanup_early+0x13e/0x150 [i915] ... <4> [239.330640] RIP: 0010:i915_gem_cleanup_early+0x13e/0x150 [i915] ... <4> [239.330942] Call Trace: <4> [239.330944] <TASK> <4> [239.330949] i915_driver_late_release+0x2b/0xa0 [i915] <4> [239.331202] i915_driver_release+0x86/0xa0 [i915] <4> [239.331482] devm_drm_dev_init_release+0x61/0x90 <4> [239.331494] devm_action_release+0x15/0x30 <4> [239.331504] release_nodes+0x3d/0x120 <4> [239.331517] devres_release_all+0x96/0xd0 <4> [239.331533] device_unbind_cleanup+0x12/0x80 <4> [239.331543] device_release_driver_internal+0x23a/0x280 <4> [239.331550] ? bus_find_device+0xa5/0xe0 <4> [239.331563] device_driver_detach+0x14/0x20 ... <4> [357.719679] ---[ end trace 0000000000000000 ]---

If the test also unloads the i915 module then that's followed with:

<3> [357.787478] ============================================================================= <3> [357.788006] BUG i915_vma (Tainted: G U W N ): Objects remaining on __kmem_cache_shutdown() <3> [357.788031] ----------------------------------------------------------------------------- <3> [357.788204] Object 0xffff888109e7f480 @offset=29824 <3> [357.788670] Allocated in i915_vma_instance+0xee/0xc10 [i915] age=292729 cpu=4 pid=2244 <4> [357.788994] i915_vma_instance+0xee/0xc10 [i915] <4> [357.789290] init_status_page+0x7b/0x420 [i915] <4> [357.789532] intel_engines_init+0x1d8/0x980 [i915] <4> [357.789772] intel_gt_init+0x175/0x450 [i915] <4> [357.790014] i915_gem_init+0x113/0x340 [i915] <4> [357.790281] i915_driver_probe+0x847/0xed0 [i915] <4> [357.790504] i915_pci_probe+0xe6/0x220 [i915] ...

Closer analysis of CI results history has revealed a dependency of the error on a few IGT tests, namely: - igt@api_intel_allocator@fork-simple-stress-signal, - igt@api_intel_allocator@two-level-inception-interruptible, - igt@gem_linear_blits@interruptible, - igt@prime_mmap_coherency@ioctl-errors, which invisibly trigger the issue, then exhibited with first driver unbind attempt.

All of the above tests perform actions which are actively interrupted with signals. Further debugging has allowed to narrow that scope down to DRM_IOCTL_I915_GEM_EXECBUFFER2, and ring_context_alloc(), specific to ring submission, in particular.

If successful then that function, or its execlists or GuC submission equivalent, is supposed to be called only once per GEM context engine, followed by raise of a flag that prevents the function from being called again. The function is expected to unwind its internal errors itself, so it may be safely called once more after it returns an error.

In case of ring submission, the function first gets a reference to the engine's legacy timeline and then allocates a VMA. If the VMA allocation fails, e.g. when i915_vma_instance() called from inside is interrupted with a signal, then ring_context_alloc() fails, leaving the timeline held referenced. On next I915_GEM_EXECBUFFER2 IOCTL, another reference to the timeline is got, and only that last one is put on successful completion. As a consequence, the legacy timeline, with its underlying engine status page's VMA object, is still held and not released on driver unbind.

Get the legacy timeline only after successful allocation of the context engine's VMA.

v2: Add a note on other submission methods (Krzysztof Karas): Both execlists and GuC submission use lrc_alloc() which seems free from a similar issue.

(cherry picked from commit cc43422b3cc79eacff4c5a8ba0d224688ca9dd4f)(CVE-2025-38389)

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

ima: don't clear IMA_DIGSIG flag when setting or removing non-IMA xattr

Currently when both IMA and EVM are in fix mode, the IMA signature will be reset to IMA hash if a program first stores IMA signature in security.ima and then writes/removes some other security xattr for the file.

For example, on Fedora, after booting the kernel with "ima_appraise=fix evm=fix ima_policy=appraise_tcb" and installing rpm-plugin-ima, installing/reinstalling a package will not make good reference IMA signature generated. Instead IMA hash is generated,

# getfattr -m - -d -e hex /usr/bin/bash
# file: usr/bin/bash
security.ima=0x0404...

This happens because when setting security.selinux, the IMA_DIGSIG flag that had been set early was cleared. As a result, IMA hash is generated when the file is closed.

Similarly, IMA signature can be cleared on file close after removing security xattr like security.evm or setting/removing ACL.

Prevent replacing the IMA file signature with a file hash, by preventing the IMA_DIGSIG flag from being reset.

Here's a minimal C reproducer which sets security.selinux as the last step which can also replaced by removing security.evm or setting ACL,

#include &lt;stdio.h&gt;
#include &lt;sys/xattr.h&gt;
#include &lt;fcntl.h&gt;
#include &lt;unistd.h&gt;
#include &lt;string.h&gt;
#include &lt;stdlib.h&gt;

int main() {
    const char* file_path = &quot;/usr/sbin/test_binary&quot;;
    const char* hex_string = &quot;030204d33204490066306402304&quot;;
    int length = strlen(hex_string);
    char* ima_attr_value;
    int fd;

    fd = open(file_path, O_WRONLY|O_CREAT|O_EXCL, 0644);
    if (fd == -1) {
        perror(&quot;Error opening file&quot;);
        return 1;
    }

    ima_attr_value = (char*)malloc(length / 2 );
    for (int i = 0, j = 0; i &lt; length; i += 2, j++) {
        sscanf(hex_string + i, &quot;%2hhx&quot;, &amp;ima_attr_value[j]);
    }

    if (fsetxattr(fd, &quot;security.ima&quot;, ima_attr_value, length/2, 0) == -1) {
        perror(&quot;Error setting extended attribute&quot;);
        close(fd);
        return 1;
    }

    const char* selinux_value= &quot;system_u:object_r:bin_t:s0&quot;;
    if (fsetxattr(fd, &quot;security.selinux&quot;, selinux_value, strlen(selinux_value), 0) == -1) {
        perror(&quot;Error setting extended attribute&quot;);
        close(fd);
        return 1;
    }

    close(fd);

    return 0;
}(CVE-2025-68183)

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

crash: fix crashkernel resource shrink

When crashkernel is configured with a high reservation, shrinking its value below the low crashkernel reservation causes two issues:

Invalid crashkernel resource objects
Kernel crash if crashkernel shrinking is done twice

For example, with crashkernel=200M,high, the kernel reserves 200MB of high memory and some default low memory (say 256MB). The reservation appears as:

cat /proc/iomem | grep -i crash af000000-beffffff : Crash kernel 433000000-43f7fffff : Crash kernel

If crashkernel is then shrunk to 50MB (echo 52428800 > /sys/kernel/kexec_crash_size), /proc/iomem still shows 256MB reserved: af000000-beffffff : Crash kernel

Instead, it should show 50MB: af000000-b21fffff : Crash kernel

Further shrinking crashkernel to 40MB causes a kernel crash with the following trace (x86):

BUG: kernel NULL pointer dereference, address: 0000000000000038 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI <snip...> Call Trace: <TASK> ? __die_body.cold+0x19/0x27 ? page_fault_oops+0x15a/0x2f0 ? search_module_extables+0x19/0x60 ? search_bpf_extables+0x5f/0x80 ? exc_page_fault+0x7e/0x180 ? asm_exc_page_fault+0x26/0x30 ? __release_resource+0xd/0xb0 release_resource+0x26/0x40 __crash_shrink_memory+0xe5/0x110 crash_shrink_memory+0x12a/0x190 kexec_crash_size_store+0x41/0x80 kernfs_fop_write_iter+0x141/0x1f0 vfs_write+0x294/0x460 ksys_write+0x6d/0xf0 <snip...>

This happens because __crash_shrink_memory()/kernel/crash_core.c incorrectly updates the crashk_res resource object even when crashk_low_res should be updated.

Fix this by ensuring the correct crashkernel resource object is updated when shrinking crashkernel memory.(CVE-2025-68198)

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

ipvs: fix ipv4 null-ptr-deref in route error path

The IPv4 code path in __ip_vs_get_out_rt() calls dst_link_failure() without ensuring skb->dev is set, leading to a NULL pointer dereference in fib_compute_spec_dst() when ipv4_link_failure() attempts to send ICMP destination unreachable messages.

The issue emerged after commit ed0de45a1008 ("ipv4: recompile ip options in ipv4_link_failure") started calling __ip_options_compile() from ipv4_link_failure(). This code path eventually calls fib_compute_spec_dst() which dereferences skb->dev. An attempt was made to fix the NULL skb->dev dereference in commit 0113d9c9d1cc ("ipv4: fix null-deref in ipv4_link_failure"), but it only addressed the immediate dev_net(skb->dev) dereference by using a fallback device. The fix was incomplete because fib_compute_spec_dst() later in the call chain still accesses skb->dev directly, which remains NULL when IPVS calls dst_link_failure().

The crash occurs when: 1. IPVS processes a packet in NAT mode with a misconfigured destination 2. Route lookup fails in __ip_vs_get_out_rt() before establishing a route 3. The error path calls dst_link_failure(skb) with skb->dev == NULL 4. ipv4_link_failure() → ipv4_send_dest_unreach() → __ip_options_compile() → fib_compute_spec_dst() 5. fib_compute_spec_dst() dereferences NULL skb->dev

Apply the same fix used for IPv6 in commit 326bf17ea5d4 ("ipvs: fix ipv6 route unreach panic"): set skb->dev from skb_dst(skb)->dev before calling dst_link_failure().

KASAN: null-ptr-deref in range [0x0000000000000328-0x000000000000032f] CPU: 1 PID: 12732 Comm: syz.1.3469 Not tainted 6.6.114 #2 RIP: 0010:__in_dev_get_rcu include/linux/inetdevice.h:233 RIP: 0010:fib_compute_spec_dst+0x17a/0x9f0 net/ipv4/fib_frontend.c:285 Call Trace: <TASK> spec_dst_fill net/ipv4/ip_options.c:232 spec_dst_fill net/ipv4/ip_options.c:229 __ip_options_compile+0x13a1/0x17d0 net/ipv4/ip_options.c:330 ipv4_send_dest_unreach net/ipv4/route.c:1252 ipv4_link_failure+0x702/0xb80 net/ipv4/route.c:1265 dst_link_failure include/net/dst.h:437 __ip_vs_get_out_rt+0x15fd/0x19e0 net/netfilter/ipvs/ip_vs_xmit.c:412 ip_vs_nat_xmit+0x1d8/0xc80 net/netfilter/ipvs/ip_vs_xmit.c:764(CVE-2025-68813)

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

ipv6: BUG() in pskb_expand_head() as part of calipso_skbuff_setattr()

There exists a kernel oops caused by a BUG_ON(nhead < 0) at net/core/skbuff.c:2232 in pskb_expand_head(). This bug is triggered as part of the calipso_skbuff_setattr() routine when skb_cow() is passed headroom > INT_MAX (i.e. (int)(skb_headroom(skb) + len_delta) < 0).

The root cause of the bug is due to an implicit integer cast in __skb_cow(). The check (headroom > skb_headroom(skb)) is meant to ensure that delta = headroom - skb_headroom(skb) is never negative, otherwise we will trigger a BUG_ON in pskb_expand_head(). However, if headroom > INT_MAX and delta <= -NET_SKB_PAD, the check passes, delta becomes negative, and pskb_expand_head() is passed a negative value for nhead.

Fix the trigger condition in calipso_skbuff_setattr(). Avoid passing "negative" headroom sizes to skb_cow() within calipso_skbuff_setattr() by only using skb_cow() to grow headroom.

PoC: Using netlabelctl tool:

    netlabelctl map del default
    netlabelctl calipso add pass doi:7
    netlabelctl map add default address:0::1/128 protocol:calipso,7

    Then run the following PoC:

    int fd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_UDP);

    // setup msghdr
    int cmsg_size = 2;
    int cmsg_len = 0x60;
    struct msghdr msg;
    struct sockaddr_in6 dest_addr;
    struct cmsghdr * cmsg = (struct cmsghdr *) calloc(1,
                    sizeof(struct cmsghdr) + cmsg_len);
    msg.msg_name = &amp;dest_addr;
    msg.msg_namelen = sizeof(dest_addr);
    msg.msg_iov = NULL;
    msg.msg_iovlen = 0;
    msg.msg_control = cmsg;
    msg.msg_controllen = cmsg_len;
    msg.msg_flags = 0;

    // setup sockaddr
    dest_addr.sin6_family = AF_INET6;
    dest_addr.sin6_port = htons(31337);
    dest_addr.sin6_flowinfo = htonl(31337);
    dest_addr.sin6_addr = in6addr_loopback;
    dest_addr.sin6_scope_id = 31337;

    // setup cmsghdr
    cmsg-&gt;cmsg_len = cmsg_len;
    cmsg-&gt;cmsg_level = IPPROTO_IPV6;
    cmsg-&gt;cmsg_type = IPV6_HOPOPTS;
    char * hop_hdr = (char *)cmsg + sizeof(struct cmsghdr);
    hop_hdr[1] = 0x9; //set hop size - (0x9 + 1) * 8 = 80

    sendmsg(fd, &amp;msg, 0);(CVE-2025-71085)

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

driver core: platform: use generic driver_override infrastructure

When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF.

Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally.

Note that calling match() from __driver_attach() without the device lock held is intentional. 1

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

usbip: validate number_of_packets in usbip_pack_ret_submit()

When a USB/IP client receives a RET_SUBMIT response, usbip_pack_ret_submit() unconditionally overwrites urb->number_of_packets from the network PDU. This value is subsequently used as the loop bound in usbip_recv_iso() and usbip_pad_iso() to iterate over urb->iso_frame_desc[], a flexible array whose size was fixed at URB allocation time based on the original number_of_packets from the CMD_SUBMIT.

A malicious USB/IP server can set number_of_packets in the response to a value larger than what was originally submitted, causing a heap out-of-bounds write when usbip_recv_iso() writes to urb->iso_frame_desc[i] beyond the allocated region.

KASAN confirmed this with kernel 7.0.0-rc5:

BUG: KASAN: slab-out-of-bounds in usbip_recv_iso+0x46a/0x640 Write of size 4 at addr ffff888106351d40 by task vhci_rx/69

The buggy address is located 0 bytes to the right of allocated 320-byte region [ffff888106351c00, ffff888106351d40)

The server side (stub_rx.c) and gadget side (vudc_rx.c) already validate number_of_packets in the CMD_SUBMIT path since commits c6688ef9f297 ("usbip: fix stub_rx: harden CMD_SUBMIT path to handle malicious input") and b78d830f0049 ("usbip: fix vudc_rx: harden CMD_SUBMIT path to handle malicious input"). The server side validates against USBIP_MAX_ISO_PACKETS because no URB exists yet at that point. On the client side we have the original URB, so we can use the tighter bound: the response must not exceed the original number_of_packets.

This mirrors the existing validation of actual_length against transfer_buffer_length in usbip_recv_xbuff(), which checks the response value against the original allocation size.

Kelvin Mbogo's series ("usb: usbip: fix integer overflow in usbip_recv_iso()", v2) hardens the receive-side functions themselves; this patch complements that work by catching the bad value at its source -- in usbip_pack_ret_submit() before the overwrite -- and using the tighter per-URB allocation bound rather than the global USBIP_MAX_ISO_PACKETS limit.

Fix this by checking rpdu->number_of_packets against urb->number_of_packets in usbip_pack_ret_submit() before the overwrite. On violation, clamp to zero so that usbip_recv_iso() and usbip_pad_iso() safely return early.(CVE-2026-31607)

In the Linux kernel, the following vulnerability has been resolved: smb: client: validate the whole DACL before rewriting it in cifsacl. build_sec_desc() and id_mode_to_cifs_acl() derive a DACL pointer from a server-supplied dacloffset and then use the incoming ACL to rebuild the chmod/chown security descriptor. The original fix only checked that the struct smb_acl header fits before reading dacl_ptr->size or dacl_ptr->num_aces. That avoids the immediate header-field OOB read, but the rewrite helpers still walk ACEs based on pdacl->num_aces with no structural validation of the incoming DACL body. A malicious server can return a truncated DACL that still contains a header, claims one or more ACEs, and then drive replace_sids_and_copy_aces() or set_chmod_dacl() past the validated extent while they compare or copy attacker-controlled ACEs.(CVE-2026-31709)

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

netfilter: nf_tables: reject immediate NF_QUEUE verdict

nft_queue is always used from userspace nftables to deliver the NF_QUEUE verdict. Immediately emitting an NF_QUEUE verdict is never used by the userspace nft tools, so reject immediate NF_QUEUE verdicts.

The arp family does not provide queue support, but such an immediate verdict is still reachable. Globally reject NF_QUEUE immediate verdicts to address this issue.(CVE-2026-43024)

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

ipv6: icmp: clear skb2->cb[] in ip6_err_gen_icmpv6_unreach()

Sashiko AI-review observed:

In ip6_err_gen_icmpv6_unreach(), the skb is an outer IPv4 ICMP error packet where its cb contains an IPv4 inet_skb_parm. When skb is cloned into skb2 and passed to icmp6_send(), it uses IP6CB(skb2).

IP6CB interprets the IPv4 inet_skb_parm as an inet6_skb_parm. The cipso offset in inet_skb_parm.opt directly overlaps with dsthao in inet6_skb_parm at offset 18.

If an attacker sends a forged ICMPv4 error with a CIPSO IP option, dsthao would be a non-zero offset. Inside icmp6_send(), mip6_addr_swap() is called and uses ipv6_find_tlv(skb, opt->dsthao, IPV6_TLV_HAO).

This would scan the inner, attacker-controlled IPv6 packet starting at that offset, potentially returning a fake TLV without checking if the remaining packet length can hold the full 18-byte struct ipv6_destopt_hao.

Could mip6_addr_swap() then perform a 16-byte swap that extends past the end of the packet data into skb_shared_info?

Should the cb array also be cleared in ip6_err_gen_icmpv6_unreach() and ip6ip6_err() to prevent this?

This patch implements the first suggestion.

I am not sure if ip6ip6_err() needs to be changed. A separate patch would be better anyway.(CVE-2026-43038)

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

dcache: Limit the minimal number of bucket to two

There is an OOB read problem on dentry_hashtable when user sets 'dhash_entries=1': BUG: unable to handle page fault for address: ffff888b30b774b0 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page Oops: Oops: 0000 [#1] SMP PTI RIP: 0010:__d_lookup+0x56/0x120 Call Trace: d_lookup.cold+0x16/0x5d lookup_dcache+0x27/0xf0 lookup_one_qstr_excl+0x2a/0x180 start_dirop+0x55/0xa0 simple_start_creating+0x8d/0xa0 debugfs_start_creating+0x8c/0x180 debugfs_create_dir+0x1d/0x1c0 pinctrl_init+0x6d/0x140 do_one_initcall+0x6d/0x3d0 kernel_init_freeable+0x39f/0x460 kernel_init+0x2a/0x260

There will be only one bucket in dentry_hashtable when dhash_entries is set as one, and d_hash_shift is calculated as 32 by dcache_init(). Then, following process will access more than one buckets(which memory region is not allocated) in dentry_hashtable: d_lookup b = d_hash(hash) dentry_hashtable + ((u32)hashlen >> d_hash_shift) // The C standard defines the behavior of right shift amounts // exceeding the bit width of the operand as undefined. The // result of '(u32)hashlen >> d_hash_shift' becomes 'hashlen', // so 'b' will point to an unallocated memory region. hlist_bl_for_each_entry_rcu(b) hlist_bl_first_rcu(head) h->first // read OOB!

Fix it by limiting the minimal number of dentry_hashtable bucket to two, so that 'd_hash_shift' won't exceeds the bit width of type u32.(CVE-2026-43071)

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

net: af_key: zero aligned sockaddr tail in PF_KEY exports

PF_KEY export paths use pfkey_sockaddr_size() when reserving sockaddr payload space, so IPv6 addresses occupy 32 bytes on the wire. However, pfkey_sockaddr_fill() initializes only the first 28 bytes of struct sockaddr_in6, leaving the final 4 aligned bytes uninitialized.

Not every PF_KEY message is affected. The state and policy dump builders already zero the whole message buffer before filling the sockaddr payloads. Keep the fix to the export paths that still append aligned sockaddr payloads with plain skb_put():

SADB_ACQUIRE
SADB_X_NAT_T_NEW_MAPPING
SADB_X_MIGRATE

Fix those paths by clearing only the aligned sockaddr tail after pfkey_sockaddr_fill().(CVE-2026-43088)

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

xfrm_user: fix info leak in build_mapping()

struct xfrm_usersa_id has a one-byte padding hole after the proto field, which ends up never getting set to zero before copying out to userspace. Fix that up by zeroing out the whole structure before setting individual variables.(CVE-2026-43089)

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

xfrm: account XFRMA_IF_ID in aevent size calculation

xfrm_get_ae() allocates the reply skb with xfrm_aevent_msgsize(), then build_aevent() appends attributes including XFRMA_IF_ID when x->if_id is set.

xfrm_aevent_msgsize() does not include space for XFRMA_IF_ID. For states with if_id, build_aevent() can fail with -EMSGSIZE and hit BUG_ON(err < 0) in xfrm_get_ae(), turning a malformed netlink interaction into a kernel panic.

Account XFRMA_IF_ID in the size calculation unconditionally and replace the BUG_ON with normal error unwinding.(CVE-2026-43107)

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

tcp: fix potential race in tcp_v6_syn_recv_sock()

Code in tcp_v6_syn_recv_sock() after the call to tcp_v4_syn_recv_sock() is done too late.

After tcp_v4_syn_recv_sock(), the child socket is already visible from TCP ehash table and other cpus might use it.

Since newinet->pinet6 is still pointing to the listener ipv6_pinfo bad things can happen as syzbot found.

Move the problematic code in tcp_v6_mapped_child_init() and call this new helper from tcp_v4_syn_recv_sock() before the ehash insertion.

This allows the removal of one tcp_sync_mss(), since tcp_v4_syn_recv_sock() will call it with the correct context.(CVE-2026-43198)

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

net: Drop the lock in skb_may_tx_timestamp()

skb_may_tx_timestamp() may acquire sock::sk_callback_lock. The lock must not be taken in IRQ context, only softirq is okay. A few drivers receive the timestamp via a dedicated interrupt and complete the TX timestamp from that handler. This will lead to a deadlock if the lock is already write-locked on the same CPU.

Taking the lock can be avoided. The socket (pointed by the skb) will remain valid until the skb is released. The ->sk_socket and ->file member will be set to NULL once the user closes the socket which may happen before the timestamp arrives. If we happen to observe the pointer while the socket is closing but before the pointer is set to NULL then we may use it because both pointer (and the file's cred member) are RCU freed.

Drop the lock. Use READ_ONCE() to obtain the individual pointer. Add a matching WRITE_ONCE() where the pointer are cleared.(CVE-2026-43216)

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

vhost: move vdpa group bound check to vhost_vdpa

Remove duplication by consolidating these here. This reduces the posibility of a parent driver missing them.

While we're at it, fix a bug in vdpa_sim where a valid ASID can be assigned to a group equal to ngroups, causing an out of bound write.(CVE-2026-43248)

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

mm/page_alloc: clear page->private in free_pages_prepare()

Several subsystems (slub, shmem, ttm, etc.) use page->private but don't clear it before freeing pages. When these pages are later allocated as high-order pages and split via split_page(), tail pages retain stale page->private values.

This causes a use-after-free in the swap subsystem. The swap code uses page->private to track swap count continuations, assuming freshly allocated pages have page->private == 0. When stale values are present, swap_count_continued() incorrectly assumes the continuation list is valid and iterates over uninitialized page->lru containing LIST_POISON values, causing a crash:

KASAN: maybe wild-memory-access in range [0xdead000000000100-0xdead000000000107] RIP: 0010:__do_sys_swapoff+0x1151/0x1860

Fix this by clearing page->private in free_pages_prepare(), ensuring all freed pages have clean state regardless of previous use.(CVE-2026-43303)

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

scsi: hisi_sas: Fix NULL pointer exception during user_scan()

user_scan() invokes updated sas_user_scan() for channel 0, and if successful, iteratively scans remaining channels (1 to shost->max_channel) via scsi_scan_host_selected() in commit 37c4e72b0651 ("scsi: Fix sas_user_scan() to handle wildcard and multi-channel scans"). However, hisi_sas supports only one channel, and the current value of max_channel is 1. sas_user_scan() for channel 1 will trigger the following NULL pointer exception:

[ 441.554662] Unable to handle kernel NULL pointer dereference at virtual address 00000000000008b0 [ 441.554699] Mem abort info: [ 441.554710] ESR = 0x0000000096000004 [ 441.554718] EC = 0x25: DABT (current EL), IL = 32 bits [ 441.554723] SET = 0, FnV = 0 [ 441.554726] EA = 0, S1PTW = 0 [ 441.554730] FSC = 0x04: level 0 translation fault [ 441.554735] Data abort info: [ 441.554737] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 441.554742] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 441.554747] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 441.554752] user pgtable: 4k pages, 48-bit VAs, pgdp=00000828377a6000 [ 441.554757] [00000000000008b0] pgd=0000000000000000, p4d=0000000000000000 [ 441.554769] Internal error: Oops: 0000000096000004 [#1] SMP [ 441.629589] Modules linked in: arm_spe_pmu arm_smmuv3_pmu tpm_tis_spi hisi_uncore_sllc_pmu hisi_uncore_pa_pmu hisi_uncore_l3c_pmu hisi_uncore_hha_pmu hisi_uncore_ddrc_pmu hisi_uncore_cpa_pmu hns3_pmu hisi_ptt hisi_pcie_pmu tpm_tis_core spidev spi_hisi_sfc_v3xx hisi_uncore_pmu spi_dw_mmio fuse hclge hclge_common hisi_sec2 hisi_hpre hisi_zip hisi_qm hns3 hisi_sas_v3_hw sm3_ce sbsa_gwdt hnae3 hisi_sas_main uacce hisi_dma i2c_hisi dm_mirror dm_region_hash dm_log dm_mod [ 441.670819] CPU: 46 UID: 0 PID: 6994 Comm: bash Kdump: loaded Not tainted 7.0.0-rc2+ #84 PREEMPT [ 441.691327] pstate: 81400009 (Nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 441.698277] pc : sas_find_dev_by_rphy+0x44/0x118 [ 441.702896] lr : sas_find_dev_by_rphy+0x3c/0x118 [ 441.707502] sp : ffff80009abbba40 [ 441.710805] x29: ffff80009abbba40 x28: ffff082819a40008 x27: ffff082810c37c08 [ 441.717930] x26: ffff082810c37c28 x25: ffff082819a40290 x24: ffff082810c37c00 [ 441.725054] x23: 0000000000000000 x22: 0000000000000001 x21: ffff082819a40000 [ 441.732179] x20: ffff082819a40290 x19: 0000000000000000 x18: 0000000000000020 [ 441.739304] x17: 0000000000000000 x16: ffffb5dad6bda690 x15: 00000000ffffffff [ 441.746428] x14: ffff082814c3b26c x13: 00000000ffffffff x12: ffff082814c3b26a [ 441.753553] x11: 00000000000000c0 x10: 000000000000003a x9 : ffffb5dad5ea94f4 [ 441.760678] x8 : 000000000000003a x7 : ffff80009abbbab0 x6 : 0000000000000030 [ 441.767802] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 441.774926] x2 : ffff08280f35a300 x1 : ffffb5dad7127180 x0 : 0000000000000000 [ 441.782053] Call trace: [ 441.784488] sas_find_dev_by_rphy+0x44/0x118 (P) [ 441.789095] sas_target_alloc+0x24/0xb0 [ 441.792920] scsi_alloc_target+0x290/0x330 [ 441.797010] __scsi_scan_target+0x88/0x258 [ 441.801096] scsi_scan_channel+0x74/0xb8 [ 441.805008] scsi_scan_host_selected+0x170/0x188 [ 441.809615] sas_user_scan+0xfc/0x148 [ 441.813267] store_scan+0x10c/0x180 [ 441.816743] dev_attr_store+0x20/0x40 [ 441.820398] sysfs_kf_write+0x84/0xa8 [ 441.824054] kernfs_fop_write_iter+0x130/0x1c8 [ 441.828487] vfs_write+0x2c0/0x370 [ 441.831880] ksys_write+0x74/0x118 [ 441.835271] __arm64_sys_write+0x24/0x38 [ 441.839182] invoke_syscall+0x50/0x120 [ 441.842919] el0_svc_common.constprop.0+0xc8/0xf0 [ 441.847611] do_el0_svc+0x24/0x38 [ 441.850913] el0_svc+0x38/0x158 [ 441.854043] el0t_64_sync_handler+0xa0/0xe8 [ 441.858214] el0t_64_sync+0x1ac/0x1b0 [ 441.861865] Code: aa1303e0 97ff70a8 34ffff80 d10a4273 (f9445a75) [ 441.867946] ---[ end trace 0000000000000000 ]---

Therefore ---truncated---(CVE-2026-43413)

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

ipvs: skip ipv6 extension headers for csum checks

Protocol checksum validation fails for IPv6 if there are extension headers before the protocol header. iph->len already contains its offset, so use it to fix the problem.(CVE-2026-45850)

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

net: hns3: fix double free issue for tx spare buffer

In hns3_set_ringparam(), a temporary copy (tmp_rings) of the ring structure is created for rollback. However, the tx_spare pointer in the original ring handle is incorrectly left pointing to the old backup memory.

Later, if memory allocation fails in hns3_init_all_ring() during the setup, the error path attempts to free all newly allocated rings. Since tx_spare contains a stale (non-NULL) pointer from the backup, it is mistaken for a newly allocated buffer and is erroneously freed, leading to a double-free of the backup memory.

The root cause is that the tx_spare field was not cleared after its value was saved in tmp_rings, leaving a dangling pointer.

Fix this by setting tx_spare to NULL in the original ring structure when the creation of the new tx_spare fails. This ensures the error cleanup path only frees genuinely newly allocated buffers.(CVE-2026-45891)

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

iommu/vt-d: Clear Present bit before tearing down PASID entry

The Intel VT-d Scalable Mode PASID table entry consists of 512 bits (64 bytes). When tearing down an entry, the current implementation zeros the entire 64-byte structure immediately using multiple 64-bit writes.

Since the IOMMU hardware may fetch these 64 bytes using multiple internal transactions (e.g., four 128-bit bursts), updating or zeroing the entire entry while it is active (P=1) risks a "torn" read. If a hardware fetch occurs simultaneously with the CPU zeroing the entry, the hardware could observe an inconsistent state, leading to unpredictable behavior or spurious faults.

Follow the "Guidance to Software for Invalidations" in the VT-d spec (Section 6.5.3.3) by implementing the recommended ownership handshake:

Clear only the 'Present' (P) bit of the PASID entry.
Use a dma_wmb() to ensure the cleared bit is visible to hardware before proceeding.
Execute the required invalidation sequence (PASID cache, IOTLB, and Device-TLB flush) to ensure the hardware has released all cached references.
Only after the flushes are complete, zero out the remaining fields of the PASID entry.

Also, add a dma_wmb() in pasid_set_present() to ensure that all other fields of the PASID entry are visible to the hardware before the Present bit is set.(CVE-2026-45894)

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

quota: fix livelock between quotactl and freeze_super

When a filesystem is frozen, quotactl_block() enters a retry loop waiting for the filesystem to thaw. It acquires s_umount, checks the freeze state, drops s_umount and uses sb_start_write() - sb_end_write() pair to wait for the unfreeze.

However, this retry loop can trigger a livelock issue, specifically on kernels with preemption disabled.

The mechanism is as follows: 1. freeze_super() sets SB_FREEZE_WRITE and calls sb_wait_write(). 2. sb_wait_write() calls percpu_down_write(), which initiates synchronize_rcu(). 3. Simultaneously, quotactl_block() spins in its retry loop, immediately executing the sb_start_write() - sb_end_write() pair. 4. Because the kernel is non-preemptible and the loop contains no scheduling points, quotactl_block() never yields the CPU. This prevents that CPU from reaching an RCU quiescent state. 5. synchronize_rcu() in the freezer thread waits indefinitely for the quotactl_block() CPU to report a quiescent state. 6. quotactl_block() spins indefinitely waiting for the freezer to advance, which it cannot do as it is blocked on the RCU sync.

This results in a hang of the freezer process and 100% CPU usage by the quota process.

While this can occur intermittently on multi-core systems, it is reliably reproducing on a node with the following script, running both the freezer and the quota toggle on the same CPU:

# mkfs.ext4 -O quota /dev/sda 2g && mkdir a_mount # mount /dev/sda -o quota,usrquota,grpquota a_mount # taskset -c 3 bash -c "while true; do xfs_freeze -f a_mount; \ xfs_freeze -u a_mount; done" & # taskset -c 3 bash -c "while true; do quotaon a_mount; \ quotaoff a_mount; done" &

Adding cond_resched() to the retry loop fixes the issue. It acts as an RCU quiescent state, allowing synchronize_rcu() in percpu_down_write() to complete.(CVE-2026-45895)

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

fat: avoid parent link count underflow in rmdir

Corrupted FAT images can leave a directory inode with an incorrect i_nlink (e.g. 2 even though subdirectories exist). rmdir then unconditionally calls drop_nlink(dir) and can drive i_nlink to 0, triggering the WARN_ON in drop_nlink().

Add a sanity check in vfat_rmdir() and msdos_rmdir(): only drop the parent link count when it is at least 3, otherwise report a filesystem error.(CVE-2026-45915)

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

sched/rt: Skip currently executing CPU in rto_next_cpu()

CPU0 becomes overloaded when hosting a CPU-bound RT task, a non-CPU-bound RT task, and a CFS task stuck in kernel space. When other CPUs switch from RT to non-RT tasks, RT load balancing (LB) is triggered; with HAVE_RT_PUSH_IPI enabled, they send IPIs to CPU0 to drive the execution of rto_push_irq_work_func. During push_rt_task on CPU0, if next_task->prio < rq->donor->prio, resched_curr() sets NEED_RESCHED and after the push operation completes, CPU0 calls rto_next_cpu(). Since only CPU0 is overloaded in this scenario, rto_next_cpu() should ideally return -1 (no further IPI needed).

However, multiple CPUs invoking tell_cpu_to_push() during LB increments rd->rto_loop_next. Even when rd->rto_cpu is set to -1, the mismatch between rd->rto_loop and rd->rto_loop_next forces rto_next_cpu() to restart its search from -1. With CPU0 remaining overloaded (satisfying rt_nr_migratory && rt_nr_total > 1), it gets reselected, causing CPU0 to queue irq_work to itself and send self-IPIs repeatedly. As long as CPU0 stays overloaded and other CPUs run pull_rt_tasks(), it falls into an infinite self-IPI loop, which triggers a CPU hardlockup due to continuous self-interrupts.

The trigging scenario is as follows:

     cpu0                      cpu1                    cpu2
                            pull_rt_task
                          tell_cpu_to_push
             &lt;------------irq_work_queue_on

rto_push_irq_work_func push_rt_task resched_curr(rq) pull_rt_task rto_next_cpu tell_cpu_to_push <-------------------------- atomic_inc(rto_loop_next) rd->rto_loop != next rto_next_cpu irq_work_queue_on rto_push_irq_work_func

Fix redundant self-IPI by filtering the initiating CPU in rto_next_cpu(). This solution has been verified to effectively eliminate spurious self-IPIs and prevent CPU hardlockup scenarios.(CVE-2026-45919)

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

ext4: fix dirtyclusters double decrement on fs shutdown

fstests test generic/388 occasionally reproduces a warning in ext4_put_super() associated with the dirty clusters count:

WARNING: CPU: 7 PID: 76064 at fs/ext4/super.c:1324 ext4_put_super+0x48c/0x590 [ext4]

Tracing the failure shows that the warning fires due to an s_dirtyclusters_counter value of -1. IOW, this appears to be a spurious decrement as opposed to some sort of leak. Further tracing of the dirty cluster count deltas and an LLM scan of the resulting output identified the cause as a double decrement in the error path between ext4_mb_mark_diskspace_used() and the caller ext4_mb_new_blocks().

First, note that generic/388 is a shutdown vs. fsstress test and so produces a random set of operations and shutdown injections. In the problematic case, the shutdown triggers an error return from the ext4_handle_dirty_metadata() call(s) made from ext4_mb_mark_context(). The changed value is non-zero at this point, so ext4_mb_mark_diskspace_used() does not exit after the error bubbles up from ext4_mb_mark_context(). Instead, the former decrements both cluster counters and returns the error up to ext4_mb_new_blocks(). The latter falls into the !ar->len out path which decrements the dirty clusters counter a second time, creating the inconsistency.

To avoid this problem and simplify ownership of the cluster reservation in this codepath, lift the counter reduction to a single place in the caller. This makes it more clear that ext4_mb_new_blocks() is responsible for acquiring cluster reservation (via ext4_claim_free_clusters()) in the !delalloc case as well as releasing it, regardless of whether it ends up consumed or returned due to failure.(CVE-2026-45920)

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

ext4: fix e4b bitmap inconsistency reports

A bitmap inconsistency issue was observed during stress tests under mixed huge-page workloads. Ext4 reported multiple e4b bitmap check failures like:

ext4_mb_complex_scan_group:2508: group 350, 8179 free clusters as per group info. But got 8192 blocks

Analysis and experimentation confirmed that the issue is caused by a race condition between page migration and bitmap modification. Although this timing window is extremely narrow, it is still hit in practice:

folio_lock ext4_mb_load_buddy __migrate_folio check ref count folio_mc_copy __filemap_get_folio folio_try_get(folio) ...... mb_mark_used ext4_mb_unload_buddy __folio_migrate_mapping folio_ref_freeze folio_unlock

The root cause of this issue is that the fast path of load_buddy only increments the folio's reference count, which is insufficient to prevent concurrent folio migration. We observed that the folio migration process acquires the folio lock. Therefore, we can determine whether to take the fast path in load_buddy by checking the lock status. If the folio is locked, we opt for the slow path (which acquires the lock) to close this concurrency window.

Additionally, this change addresses the following issues:

When the DOUBLE_CHECK macro is enabled to inspect bitmap-related issues, the following error may be triggered:

corruption in group 324 at byte 784(6272): f in copy != ff on disk/prealloc

Analysis reveals that this is a false positive. There is a specific race window where the bitmap and the group descriptor become momentarily inconsistent, leading to this error report:

ext4_mb_load_buddy ext4_mb_load_buddy __filemap_get_folio(create|lock) folio_lock ext4_mb_init_cache folio_mark_uptodate __filemap_get_folio(no lock) ...... mb_mark_used mb_mark_used_double mb_cmp_bitmaps mb_set_bits(e4b->bd_bitmap) folio_unlock

The original logic assumed that since mb_cmp_bitmaps is called when the bitmap is newly loaded from disk, the folio lock would be sufficient to prevent concurrent access. However, this overlooks a specific race condition: if another process attempts to load buddy and finds the folio is already in an uptodate state, it will immediately begin using it without holding folio lock.(CVE-2026-45942)

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

iommu/vt-d: Clear Present bit before tearing down context entry

When tearing down a context entry, the current implementation zeros the entire 128-bit entry using multiple 64-bit writes. This creates a window where the hardware can fetch a "torn" entry — where some fields are already zeroed while the 'Present' bit is still set — leading to unpredictable behavior or spurious faults.

While x86 provides strong write ordering, the compiler may reorder writes to the two 64-bit halves of the context entry. Even without compiler reordering, the hardware fetch is not guaranteed to be atomic with respect to multiple CPU writes.

Align with the "Guidance to Software for Invalidations" in the VT-d spec (Section 6.5.3.3) by implementing the recommended ownership handshake:

Clear only the 'Present' (P) bit of the context entry first to signal the transition of ownership from hardware to software.
Use dma_wmb() to ensure the cleared bit is visible to the IOMMU.
Perform the required cache and context-cache invalidation to ensure hardware no longer has cached references to the entry.
Fully zero out the entry only after the invalidation is complete.

Also, add a dma_wmb() to context_set_present() to ensure the entry is fully initialized before the 'Present' bit becomes visible.(CVE-2026-45944)

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

ext4: fix memory leak in ext4_ext_shift_extents()

In ext4_ext_shift_extents(), if the extent is NULL in the while loop, the function returns immediately without releasing the path obtained via ext4_find_extent(), leading to a memory leak.

Fix this by jumping to the out label to ensure the path is properly released.(CVE-2026-45948)

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

cpuidle: Skip governor when only one idle state is available

On certain platforms (PowerNV systems without a power-mgt DT node), cpuidle may register only a single idle state. In cases where that single state is a polling state (state 0), the ladder governor may incorrectly treat state 1 as the first usable state and pass an out-of-bounds index. This can lead to a NULL enter callback being invoked, ultimately resulting in a system crash.

[ 13.342636] cpuidle-powernv : Only Snooze is available [ 13.351854] Faulting instruction address: 0x00000000 [ 13.376489] NIP [0000000000000000] 0x0 [ 13.378351] LR [c000000001e01974] cpuidle_enter_state+0x2c4/0x668

Fix this by adding a bail-out in cpuidle_select() that returns state 0 directly when state_count <= 1, bypassing the governor and keeping the tick running.(CVE-2026-45968)

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

ext4: don't set EXT4_GET_BLOCKS_CONVERT when splitting before submitting I/O

When allocating blocks during within-EOF DIO and writeback with dioread_nolock enabled, EXT4_GET_BLOCKS_PRE_IO was set to split an existing large unwritten extent. However, EXT4_GET_BLOCKS_CONVERT was set when calling ext4_split_convert_extents(), which may potentially result in stale data issues.

Assume we have an unwritten extent, and then DIO writes the second half.

[UUUUUUUUUUUUUUUU] on-disk extent U: unwritten extent [UUUUUUUUUUUUUUUU] extent status tree |<- ->| ----> dio write this range

First, ext4_iomap_alloc() call ext4_map_blocks() with EXT4_GET_BLOCKS_PRE_IO, EXT4_GET_BLOCKS_UNWRIT_EXT and EXT4_GET_BLOCKS_CREATE flags set. ext4_map_blocks() find this extent and call ext4_split_convert_extents() with EXT4_GET_BLOCKS_CONVERT and the above flags set.

Then, ext4_split_convert_extents() calls ext4_split_extent() with EXT4_EXT_MAY_ZEROOUT, EXT4_EXT_MARK_UNWRIT2 and EXT4_EXT_DATA_VALID2 flags set, and it calls ext4_split_extent_at() to split the second half with EXT4_EXT_DATA_VALID2, EXT4_EXT_MARK_UNWRIT1, EXT4_EXT_MAY_ZEROOUT and EXT4_EXT_MARK_UNWRIT2 flags set. However, ext4_split_extent_at() failed to insert extent since a temporary lack -ENOSPC. It zeroes out the first half but convert the entire on-disk extent to written since the EXT4_EXT_DATA_VALID2 flag set, but left the second half as unwritten in the extent status tree.

[0000000000SSSSSS] data S: stale data, 0: zeroed [WWWWWWWWWWWWWWWW] on-disk extent W: written extent [WWWWWWWWWWUUUUUU] extent status tree

Finally, if the DIO failed to write data to the disk, the stale data in the second half will be exposed once the cached extent entry is gone.

Fix this issue by not passing EXT4_GET_BLOCKS_CONVERT when splitting an unwritten extent before submitting I/O, and make ext4_split_convert_extents() to zero out the entire extent range to zero for this case, and also mark the extent in the extent status tree for consistency.(CVE-2026-45985)

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

KVM: nSVM: Triple fault if restore host CR3 fails on nested #VMEXIT

If loading L1's CR3 fails on a nested #VMEXIT, nested_svm_vmexit() returns an error code that is ignored by most callers, and continues to run L1 with corrupted state. A sane recovery is not possible in this case, and HW behavior is to cause a shutdown. Inject a triple fault instead, and do not return early from nested_svm_vmexit(). Continue cleaning up the vCPU state (e.g. clear pending exceptions), to handle the failure as gracefully as possible.

From the APM:

Upon #VMEXIT, the processor performs the following actions in order to return to the host execution context:

...

if (illegal host state loaded, or exception while loading host state) shutdown else execute first host instruction following the VMRUN

Remove the return value of nested_svm_vmexit(), which is mostly unchecked anyway.(CVE-2026-46032)

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

fbdev: defio: Disconnect deferred I/O from the lifetime of struct fb_info

Hold state of deferred I/O in struct fb_deferred_io_state. Allocate an instance as part of initializing deferred I/O and remove it only after the final mapping has been closed. If the fb_info and the contained deferred I/O meanwhile goes away, clear struct fb_deferred_io_state.info to invalidate the mapping. Any access will then result in a SIGBUS signal.

Fixes a long-standing problem, where a device hot-unplug happens while user space still has an active mapping of the graphics memory. The hot- unplug frees the instance of struct fb_info. Accessing the memory will operate on undefined state.(CVE-2026-46065)

In the Linux kernel, the vlan_dev_set_egress_priority() function currently keeps cleared egress priority mappings in the hash as tombstones. Repeated set/clear cycles with distinct skb priorities accumulate mapping nodes until device teardown, causing memory leakage. This vulnerability is fixed by deleting mappings instead of keeping tombstones, using RCU protection for safe deallocation.(CVE-2026-46153)

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

eventpoll: fix ep_remove struct eventpoll / struct file UAF

ep_remove() (via ep_remove_file()) cleared file->f_ep under file->f_lock but then kept using @file inside the critical section (is_file_epoll(), hlist_del_rcu() through the head, spin_unlock). A concurrent __fput() taking the eventpoll_release() fastpath in that window observed the transient NULL, skipped eventpoll_release_file() and ran to f_op->release / file_free().

For the epoll-watches-epoll case, f_op->release is ep_eventpoll_release() -> ep_clear_and_put() -> ep_free(), which kfree()s the watched struct eventpoll. Its embedded ->refs hlist_head is exactly where epi->fllink.pprev points, so the subsequent hlist_del_rcu()'s "*pprev = next" scribbles into freed kmalloc-192 memory.

In addition, struct file is SLAB_TYPESAFE_BY_RCU, so the slot backing @file could be recycled by alloc_empty_file() -- reinitializing f_lock and f_ep -- while ep_remove() is still nominally inside that lock. The upshot is an attacker-controllable kmem_cache_free() against the wrong slab cache.

Pin @file via epi_fget() at the top of ep_remove() and gate the critical section on the pin succeeding. With the pin held @file cannot reach refcount zero, which holds __fput() off and transitively keeps the watched struct eventpoll alive across the hlist_del_rcu() and the f_lock use, closing both UAFs.

If the pin fails @file has already reached refcount zero and its __fput() is in flight. Because we bailed before clearing f_ep, that path takes the eventpoll_release() slow path into eventpoll_release_file() and blocks on ep->mtx until the waiter side's ep_clear_and_put() drops it. The bailed epi's share of ep->refcount stays intact, so the trailing ep_refcount_dec_and_test() in ep_clear_and_put() cannot free the eventpoll out from under eventpoll_release_file(); the orphaned epi is then cleaned up there.

A successful pin also proves we are not racing eventpoll_release_file() on this epi, so drop the now-redundant re-check of epi->dying under f_lock. The cheap lockless READ_ONCE(epi->dying) fast-path bailout stays.(CVE-2026-46242)

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix dc_link NULL handling in HPD init amdgpu_dm_hpd_init() may see connectors without a valid dc_link. The code already checks dc_link for the polling decision, but later unconditionally dereferences it when setting up HPD interrupts. Assign dc_link early and skip connectors where it is NULL. Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_irq.c:940 amdgpu_dm_hpd_init() error: we previously assumed 'dc_link' could be null (see line 931) drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_irq.c 923 /* 924 * Analog connectors may be hot-plugged unlike other connector 925 * types that don't support HPD. Only poll analog connectors. 926 / 927 use_polling |= 928 amdgpu_dm_connector->dc_link && ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The patch adds this NULL check but hopefully it can be removed 929 dc_connector_supports_analog(amdgpu_dm_connector->dc_link->link_id.id); 930 931 dc_link = amdgpu_dm_connector->dc_link; dc_link assigned here. 932 933 / 934 * Get a base driver irq reference for hpd ints for the lifetime 935 * of dm. Note that only hpd interrupt types are registered with 936 * base driver; hpd_rx types aren't. IOW, amdgpu_irq_get/put on 937 * hpd_rx isn't available. DM currently controls hpd_rx 938 * explicitly with dc_interrupt_set() 939 / --> 940 if (dc_link->irq_source_hpd != DC_IRQ_SOURCE_INVALID) { ^^^^^^^^^^^^^^^^^^^^^^^ If it's NULL then we are trouble because we dereference it here. 941 irq_type = dc_link->irq_source_hpd - DC_IRQ_SOURCE_HPD1; 942 / 943 * TODO: There's a mismatch between mode_info.num_hpd 944 * and what bios reports as the # of connectors with hpd The Linux kernel CVE team has assigned CVE-2026-46245 to this issue.(CVE-2026-46245)

In the Linux kernel, the following vulnerability has been resolved: procfs: fix missing RCU protection when reading real_parent in do_task_stat() When reading /proc/[pid]/stat, do_task_stat() accesses task->real_parent without proper RCU protection, which leads to: cpu 0 cpu 1 ----- ----- do_task_stat var = task->real_parent release_task call_rcu(delayed_put_task_struct) task_tgid_nr_ns(var) rcu_read_lock <--- Too late to protect task->real_parent! task_pid_ptr <--- UAF! rcu_read_unlock This patch uses task_ppid_nr_ns() instead of task_tgid_nr_ns() to add proper RCU protection for accessing task->real_parent. The Linux kernel CVE team has assigned CVE-2026-46259 to this issue.(CVE-2026-46259)

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-2025-38389	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68183	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68198	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-68813	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-71085	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-31527	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-31607	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-31709	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43024	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43038	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43071	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43088	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43089	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43107	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43198	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43216	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43248	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43303	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43413	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-45850	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-45891	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-45894	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-45895	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-45915	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-45919	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-45920	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-45942	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-45944	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-45948	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-45968	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-45985	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-46032	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-46065	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-46153	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-46242	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-46245	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-46259	ADVISORY

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-6.6.0-145.1.15.153.oe2403sp1.aarch64.rpm",
          "bpftool-debuginfo-6.6.0-145.1.15.153.oe2403sp1.aarch64.rpm",
          "kernel-6.6.0-145.1.15.153.oe2403sp1.aarch64.rpm",
          "kernel-debuginfo-6.6.0-145.1.15.153.oe2403sp1.aarch64.rpm",
          "kernel-debugsource-6.6.0-145.1.15.153.oe2403sp1.aarch64.rpm",
          "kernel-devel-6.6.0-145.1.15.153.oe2403sp1.aarch64.rpm",
          "kernel-headers-6.6.0-145.1.15.153.oe2403sp1.aarch64.rpm",
          "kernel-source-6.6.0-145.1.15.153.oe2403sp1.aarch64.rpm",
          "kernel-tools-6.6.0-145.1.15.153.oe2403sp1.aarch64.rpm",
          "kernel-tools-debuginfo-6.6.0-145.1.15.153.oe2403sp1.aarch64.rpm",
          "kernel-tools-devel-6.6.0-145.1.15.153.oe2403sp1.aarch64.rpm",
          "perf-6.6.0-145.1.15.153.oe2403sp1.aarch64.rpm",
          "perf-debuginfo-6.6.0-145.1.15.153.oe2403sp1.aarch64.rpm",
          "python3-perf-6.6.0-145.1.15.153.oe2403sp1.aarch64.rpm",
          "python3-perf-debuginfo-6.6.0-145.1.15.153.oe2403sp1.aarch64.rpm"
        ],
        "src": [
          "kernel-6.6.0-145.1.15.153.oe2403sp1.src.rpm"
        ],
        "x86_64": [
          "bpftool-6.6.0-145.1.15.153.oe2403sp1.x86_64.rpm",
          "bpftool-debuginfo-6.6.0-145.1.15.153.oe2403sp1.x86_64.rpm",
          "kernel-6.6.0-145.1.15.153.oe2403sp1.x86_64.rpm",
          "kernel-debuginfo-6.6.0-145.1.15.153.oe2403sp1.x86_64.rpm",
          "kernel-debugsource-6.6.0-145.1.15.153.oe2403sp1.x86_64.rpm",
          "kernel-devel-6.6.0-145.1.15.153.oe2403sp1.x86_64.rpm",
          "kernel-headers-6.6.0-145.1.15.153.oe2403sp1.x86_64.rpm",
          "kernel-source-6.6.0-145.1.15.153.oe2403sp1.x86_64.rpm",
          "kernel-tools-6.6.0-145.1.15.153.oe2403sp1.x86_64.rpm",
          "kernel-tools-debuginfo-6.6.0-145.1.15.153.oe2403sp1.x86_64.rpm",
          "kernel-tools-devel-6.6.0-145.1.15.153.oe2403sp1.x86_64.rpm",
          "perf-6.6.0-145.1.15.153.oe2403sp1.x86_64.rpm",
          "perf-debuginfo-6.6.0-145.1.15.153.oe2403sp1.x86_64.rpm",
          "python3-perf-6.6.0-145.1.15.153.oe2403sp1.x86_64.rpm",
          "python3-perf-debuginfo-6.6.0-145.1.15.153.oe2403sp1.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:24.03-LTS-SP1",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS-SP1"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.6.0-145.1.15.153.oe2403sp1"
            }
          ],
          "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\ndrm/i915/gt: Fix timeline left held on VMA alloc error\n\nThe following error has been reported sporadically by CI when a test\nunbinds the i915 driver on a ring submission platform:\n\n\u0026lt;4\u0026gt; [239.330153] ------------[ cut here ]------------\n\u0026lt;4\u0026gt; [239.330166] i915 0000:00:02.0: [drm] drm_WARN_ON(dev_priv-\u0026gt;mm.shrink_count)\n\u0026lt;4\u0026gt; [239.330196] WARNING: CPU: 1 PID: 18570 at drivers/gpu/drm/i915/i915_gem.c:1309 i915_gem_cleanup_early+0x13e/0x150 [i915]\n...\n\u0026lt;4\u0026gt; [239.330640] RIP: 0010:i915_gem_cleanup_early+0x13e/0x150 [i915]\n...\n\u0026lt;4\u0026gt; [239.330942] Call Trace:\n\u0026lt;4\u0026gt; [239.330944]  \u0026lt;TASK\u0026gt;\n\u0026lt;4\u0026gt; [239.330949]  i915_driver_late_release+0x2b/0xa0 [i915]\n\u0026lt;4\u0026gt; [239.331202]  i915_driver_release+0x86/0xa0 [i915]\n\u0026lt;4\u0026gt; [239.331482]  devm_drm_dev_init_release+0x61/0x90\n\u0026lt;4\u0026gt; [239.331494]  devm_action_release+0x15/0x30\n\u0026lt;4\u0026gt; [239.331504]  release_nodes+0x3d/0x120\n\u0026lt;4\u0026gt; [239.331517]  devres_release_all+0x96/0xd0\n\u0026lt;4\u0026gt; [239.331533]  device_unbind_cleanup+0x12/0x80\n\u0026lt;4\u0026gt; [239.331543]  device_release_driver_internal+0x23a/0x280\n\u0026lt;4\u0026gt; [239.331550]  ? bus_find_device+0xa5/0xe0\n\u0026lt;4\u0026gt; [239.331563]  device_driver_detach+0x14/0x20\n...\n\u0026lt;4\u0026gt; [357.719679] ---[ end trace 0000000000000000 ]---\n\nIf the test also unloads the i915 module then that\u0026apos;s followed with:\n\n\u0026lt;3\u0026gt; [357.787478] =============================================================================\n\u0026lt;3\u0026gt; [357.788006] BUG i915_vma (Tainted: G     U  W        N ): Objects remaining on __kmem_cache_shutdown()\n\u0026lt;3\u0026gt; [357.788031] -----------------------------------------------------------------------------\n\u0026lt;3\u0026gt; [357.788204] Object 0xffff888109e7f480 @offset=29824\n\u0026lt;3\u0026gt; [357.788670] Allocated in i915_vma_instance+0xee/0xc10 [i915] age=292729 cpu=4 pid=2244\n\u0026lt;4\u0026gt; [357.788994]  i915_vma_instance+0xee/0xc10 [i915]\n\u0026lt;4\u0026gt; [357.789290]  init_status_page+0x7b/0x420 [i915]\n\u0026lt;4\u0026gt; [357.789532]  intel_engines_init+0x1d8/0x980 [i915]\n\u0026lt;4\u0026gt; [357.789772]  intel_gt_init+0x175/0x450 [i915]\n\u0026lt;4\u0026gt; [357.790014]  i915_gem_init+0x113/0x340 [i915]\n\u0026lt;4\u0026gt; [357.790281]  i915_driver_probe+0x847/0xed0 [i915]\n\u0026lt;4\u0026gt; [357.790504]  i915_pci_probe+0xe6/0x220 [i915]\n...\n\nCloser analysis of CI results history has revealed a dependency of the\nerror on a few IGT tests, namely:\n- igt@api_intel_allocator@fork-simple-stress-signal,\n- igt@api_intel_allocator@two-level-inception-interruptible,\n- igt@gem_linear_blits@interruptible,\n- igt@prime_mmap_coherency@ioctl-errors,\nwhich invisibly trigger the issue, then exhibited with first driver unbind\nattempt.\n\nAll of the above tests perform actions which are actively interrupted with\nsignals.  Further debugging has allowed to narrow that scope down to\nDRM_IOCTL_I915_GEM_EXECBUFFER2, and ring_context_alloc(), specific to ring\nsubmission, in particular.\n\nIf successful then that function, or its execlists or GuC submission\nequivalent, is supposed to be called only once per GEM context engine,\nfollowed by raise of a flag that prevents the function from being called\nagain.  The function is expected to unwind its internal errors itself, so\nit may be safely called once more after it returns an error.\n\nIn case of ring submission, the function first gets a reference to the\nengine\u0026apos;s legacy timeline and then allocates a VMA.  If the VMA allocation\nfails, e.g. when i915_vma_instance() called from inside is interrupted\nwith a signal, then ring_context_alloc() fails, leaving the timeline held\nreferenced.  On next I915_GEM_EXECBUFFER2 IOCTL, another reference to the\ntimeline is got, and only that last one is put on successful completion.\nAs a consequence, the legacy timeline, with its underlying engine status\npage\u0026apos;s VMA object, is still held and not released on driver unbind.\n\nGet the legacy timeline only after successful allocation of the context\nengine\u0026apos;s VMA.\n\nv2: Add a note on other submission methods (Krzysztof Karas):\n    Both execlists and GuC submission use lrc_alloc() which seems free\n    from a similar issue.\n\n(cherry picked from commit cc43422b3cc79eacff4c5a8ba0d224688ca9dd4f)(CVE-2025-38389)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nima: don\u0026apos;t clear IMA_DIGSIG flag when setting or removing non-IMA xattr\n\nCurrently when both IMA and EVM are in fix mode, the IMA signature will\nbe reset to IMA hash if a program first stores IMA signature in\nsecurity.ima and then writes/removes some other security xattr for the\nfile.\n\nFor example, on Fedora, after booting the kernel with \u0026quot;ima_appraise=fix\nevm=fix ima_policy=appraise_tcb\u0026quot; and installing rpm-plugin-ima,\ninstalling/reinstalling a package will not make good reference IMA\nsignature generated. Instead IMA hash is generated,\n\n    # getfattr -m - -d -e hex /usr/bin/bash\n    # file: usr/bin/bash\n    security.ima=0x0404...\n\nThis happens because when setting security.selinux, the IMA_DIGSIG flag\nthat had been set early was cleared. As a result, IMA hash is generated\nwhen the file is closed.\n\nSimilarly, IMA signature can be cleared on file close after removing\nsecurity xattr like security.evm or setting/removing ACL.\n\nPrevent replacing the IMA file signature with a file hash, by preventing\nthe IMA_DIGSIG flag from being reset.\n\nHere\u0026apos;s a minimal C reproducer which sets security.selinux as the last\nstep which can also replaced by removing security.evm or setting ACL,\n\n    #include \u0026lt;stdio.h\u0026gt;\n    #include \u0026lt;sys/xattr.h\u0026gt;\n    #include \u0026lt;fcntl.h\u0026gt;\n    #include \u0026lt;unistd.h\u0026gt;\n    #include \u0026lt;string.h\u0026gt;\n    #include \u0026lt;stdlib.h\u0026gt;\n\n    int main() {\n        const char* file_path = \u0026quot;/usr/sbin/test_binary\u0026quot;;\n        const char* hex_string = \u0026quot;030204d33204490066306402304\u0026quot;;\n        int length = strlen(hex_string);\n        char* ima_attr_value;\n        int fd;\n\n        fd = open(file_path, O_WRONLY|O_CREAT|O_EXCL, 0644);\n        if (fd == -1) {\n            perror(\u0026quot;Error opening file\u0026quot;);\n            return 1;\n        }\n\n        ima_attr_value = (char*)malloc(length / 2 );\n        for (int i = 0, j = 0; i \u0026lt; length; i += 2, j++) {\n            sscanf(hex_string + i, \u0026quot;%2hhx\u0026quot;, \u0026amp;ima_attr_value[j]);\n        }\n\n        if (fsetxattr(fd, \u0026quot;security.ima\u0026quot;, ima_attr_value, length/2, 0) == -1) {\n            perror(\u0026quot;Error setting extended attribute\u0026quot;);\n            close(fd);\n            return 1;\n        }\n\n        const char* selinux_value= \u0026quot;system_u:object_r:bin_t:s0\u0026quot;;\n        if (fsetxattr(fd, \u0026quot;security.selinux\u0026quot;, selinux_value, strlen(selinux_value), 0) == -1) {\n            perror(\u0026quot;Error setting extended attribute\u0026quot;);\n            close(fd);\n            return 1;\n        }\n\n        close(fd);\n\n        return 0;\n    }(CVE-2025-68183)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrash: fix crashkernel resource shrink\n\nWhen crashkernel is configured with a high reservation, shrinking its\nvalue below the low crashkernel reservation causes two issues:\n\n1. Invalid crashkernel resource objects\n2. Kernel crash if crashkernel shrinking is done twice\n\nFor example, with crashkernel=200M,high, the kernel reserves 200MB of high\nmemory and some default low memory (say 256MB).  The reservation appears\nas:\n\ncat /proc/iomem | grep -i crash\naf000000-beffffff : Crash kernel\n433000000-43f7fffff : Crash kernel\n\nIf crashkernel is then shrunk to 50MB (echo 52428800 \u0026gt;\n/sys/kernel/kexec_crash_size), /proc/iomem still shows 256MB reserved:\naf000000-beffffff : Crash kernel\n\nInstead, it should show 50MB:\naf000000-b21fffff : Crash kernel\n\nFurther shrinking crashkernel to 40MB causes a kernel crash with the\nfollowing trace (x86):\n\nBUG: kernel NULL pointer dereference, address: 0000000000000038\nPGD 0 P4D 0\nOops: 0000 [#1] PREEMPT SMP NOPTI\n\u0026lt;snip...\u0026gt;\nCall Trace: \u0026lt;TASK\u0026gt;\n? __die_body.cold+0x19/0x27\n? page_fault_oops+0x15a/0x2f0\n? search_module_extables+0x19/0x60\n? search_bpf_extables+0x5f/0x80\n? exc_page_fault+0x7e/0x180\n? asm_exc_page_fault+0x26/0x30\n? __release_resource+0xd/0xb0\nrelease_resource+0x26/0x40\n__crash_shrink_memory+0xe5/0x110\ncrash_shrink_memory+0x12a/0x190\nkexec_crash_size_store+0x41/0x80\nkernfs_fop_write_iter+0x141/0x1f0\nvfs_write+0x294/0x460\nksys_write+0x6d/0xf0\n\u0026lt;snip...\u0026gt;\n\nThis happens because __crash_shrink_memory()/kernel/crash_core.c\nincorrectly updates the crashk_res resource object even when\ncrashk_low_res should be updated.\n\nFix this by ensuring the correct crashkernel resource object is updated\nwhen shrinking crashkernel memory.(CVE-2025-68198)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvs: fix ipv4 null-ptr-deref in route error path\n\nThe IPv4 code path in __ip_vs_get_out_rt() calls dst_link_failure()\nwithout ensuring skb-\u0026gt;dev is set, leading to a NULL pointer dereference\nin fib_compute_spec_dst() when ipv4_link_failure() attempts to send\nICMP destination unreachable messages.\n\nThe issue emerged after commit ed0de45a1008 (\u0026quot;ipv4: recompile ip options\nin ipv4_link_failure\u0026quot;) started calling __ip_options_compile() from\nipv4_link_failure(). This code path eventually calls fib_compute_spec_dst()\nwhich dereferences skb-\u0026gt;dev. An attempt was made to fix the NULL skb-\u0026gt;dev\ndereference in commit 0113d9c9d1cc (\u0026quot;ipv4: fix null-deref in\nipv4_link_failure\u0026quot;), but it only addressed the immediate dev_net(skb-\u0026gt;dev)\ndereference by using a fallback device. The fix was incomplete because\nfib_compute_spec_dst() later in the call chain still accesses skb-\u0026gt;dev\ndirectly, which remains NULL when IPVS calls dst_link_failure().\n\nThe crash occurs when:\n1. IPVS processes a packet in NAT mode with a misconfigured destination\n2. Route lookup fails in __ip_vs_get_out_rt() before establishing a route\n3. The error path calls dst_link_failure(skb) with skb-\u0026gt;dev == NULL\n4. ipv4_link_failure() \u2192 ipv4_send_dest_unreach() \u2192\n   __ip_options_compile() \u2192 fib_compute_spec_dst()\n5. fib_compute_spec_dst() dereferences NULL skb-\u0026gt;dev\n\nApply the same fix used for IPv6 in commit 326bf17ea5d4 (\u0026quot;ipvs: fix\nipv6 route unreach panic\u0026quot;): set skb-\u0026gt;dev from skb_dst(skb)-\u0026gt;dev before\ncalling dst_link_failure().\n\nKASAN: null-ptr-deref in range [0x0000000000000328-0x000000000000032f]\nCPU: 1 PID: 12732 Comm: syz.1.3469 Not tainted 6.6.114 #2\nRIP: 0010:__in_dev_get_rcu include/linux/inetdevice.h:233\nRIP: 0010:fib_compute_spec_dst+0x17a/0x9f0 net/ipv4/fib_frontend.c:285\nCall Trace:\n  \u0026lt;TASK\u0026gt;\n  spec_dst_fill net/ipv4/ip_options.c:232\n  spec_dst_fill net/ipv4/ip_options.c:229\n  __ip_options_compile+0x13a1/0x17d0 net/ipv4/ip_options.c:330\n  ipv4_send_dest_unreach net/ipv4/route.c:1252\n  ipv4_link_failure+0x702/0xb80 net/ipv4/route.c:1265\n  dst_link_failure include/net/dst.h:437\n  __ip_vs_get_out_rt+0x15fd/0x19e0 net/netfilter/ipvs/ip_vs_xmit.c:412\n  ip_vs_nat_xmit+0x1d8/0xc80 net/netfilter/ipvs/ip_vs_xmit.c:764(CVE-2025-68813)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: BUG() in pskb_expand_head() as part of calipso_skbuff_setattr()\n\nThere exists a kernel oops caused by a BUG_ON(nhead \u0026lt; 0) at\nnet/core/skbuff.c:2232 in pskb_expand_head().\nThis bug is triggered as part of the calipso_skbuff_setattr()\nroutine when skb_cow() is passed headroom \u0026gt; INT_MAX\n(i.e. (int)(skb_headroom(skb) + len_delta) \u0026lt; 0).\n\nThe root cause of the bug is due to an implicit integer cast in\n__skb_cow(). The check (headroom \u0026gt; skb_headroom(skb)) is meant to ensure\nthat delta = headroom - skb_headroom(skb) is never negative, otherwise\nwe will trigger a BUG_ON in pskb_expand_head(). However, if\nheadroom \u0026gt; INT_MAX and delta \u0026lt;= -NET_SKB_PAD, the check passes, delta\nbecomes negative, and pskb_expand_head() is passed a negative value for\nnhead.\n\nFix the trigger condition in calipso_skbuff_setattr(). Avoid passing\n\u0026quot;negative\u0026quot; headroom sizes to skb_cow() within calipso_skbuff_setattr()\nby only using skb_cow() to grow headroom.\n\nPoC:\n\tUsing `netlabelctl` tool:\n\n        netlabelctl map del default\n        netlabelctl calipso add pass doi:7\n        netlabelctl map add default address:0::1/128 protocol:calipso,7\n\n        Then run the following PoC:\n\n        int fd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_UDP);\n\n        // setup msghdr\n        int cmsg_size = 2;\n        int cmsg_len = 0x60;\n        struct msghdr msg;\n        struct sockaddr_in6 dest_addr;\n        struct cmsghdr * cmsg = (struct cmsghdr *) calloc(1,\n                        sizeof(struct cmsghdr) + cmsg_len);\n        msg.msg_name = \u0026amp;dest_addr;\n        msg.msg_namelen = sizeof(dest_addr);\n        msg.msg_iov = NULL;\n        msg.msg_iovlen = 0;\n        msg.msg_control = cmsg;\n        msg.msg_controllen = cmsg_len;\n        msg.msg_flags = 0;\n\n        // setup sockaddr\n        dest_addr.sin6_family = AF_INET6;\n        dest_addr.sin6_port = htons(31337);\n        dest_addr.sin6_flowinfo = htonl(31337);\n        dest_addr.sin6_addr = in6addr_loopback;\n        dest_addr.sin6_scope_id = 31337;\n\n        // setup cmsghdr\n        cmsg-\u0026gt;cmsg_len = cmsg_len;\n        cmsg-\u0026gt;cmsg_level = IPPROTO_IPV6;\n        cmsg-\u0026gt;cmsg_type = IPV6_HOPOPTS;\n        char * hop_hdr = (char *)cmsg + sizeof(struct cmsghdr);\n        hop_hdr[1] = 0x9; //set hop size - (0x9 + 1) * 8 = 80\n\n        sendmsg(fd, \u0026amp;msg, 0);(CVE-2025-71085)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndriver core: platform: use generic driver_override infrastructure\n\nWhen a driver is probed through __driver_attach(), the bus\u0026apos; match()\ncallback is called without the device lock held, thus accessing the\ndriver_override field without a lock, which can cause a UAF.\n\nFix this by using the driver-core driver_override infrastructure taking\ncare of proper locking internally.\n\nNote that calling match() from __driver_attach() without the device lock\nheld is intentional. [1](CVE-2026-31527)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusbip: validate number_of_packets in usbip_pack_ret_submit()\n\nWhen a USB/IP client receives a RET_SUBMIT response,\nusbip_pack_ret_submit() unconditionally overwrites\nurb-\u0026gt;number_of_packets from the network PDU. This value is\nsubsequently used as the loop bound in usbip_recv_iso() and\nusbip_pad_iso() to iterate over urb-\u0026gt;iso_frame_desc[], a flexible\narray whose size was fixed at URB allocation time based on the\n*original* number_of_packets from the CMD_SUBMIT.\n\nA malicious USB/IP server can set number_of_packets in the response\nto a value larger than what was originally submitted, causing a heap\nout-of-bounds write when usbip_recv_iso() writes to\nurb-\u0026gt;iso_frame_desc[i] beyond the allocated region.\n\nKASAN confirmed this with kernel 7.0.0-rc5:\n\n  BUG: KASAN: slab-out-of-bounds in usbip_recv_iso+0x46a/0x640\n  Write of size 4 at addr ffff888106351d40 by task vhci_rx/69\n\n  The buggy address is located 0 bytes to the right of\n   allocated 320-byte region [ffff888106351c00, ffff888106351d40)\n\nThe server side (stub_rx.c) and gadget side (vudc_rx.c) already\nvalidate number_of_packets in the CMD_SUBMIT path since commits\nc6688ef9f297 (\u0026quot;usbip: fix stub_rx: harden CMD_SUBMIT path to handle\nmalicious input\u0026quot;) and b78d830f0049 (\u0026quot;usbip: fix vudc_rx: harden\nCMD_SUBMIT path to handle malicious input\u0026quot;). The server side validates\nagainst USBIP_MAX_ISO_PACKETS because no URB exists yet at that point.\nOn the client side we have the original URB, so we can use the tighter\nbound: the response must not exceed the original number_of_packets.\n\nThis mirrors the existing validation of actual_length against\ntransfer_buffer_length in usbip_recv_xbuff(), which checks the\nresponse value against the original allocation size.\n\nKelvin Mbogo\u0026apos;s series (\u0026quot;usb: usbip: fix integer overflow in\nusbip_recv_iso()\u0026quot;, v2) hardens the receive-side functions themselves;\nthis patch complements that work by catching the bad value at its\nsource -- in usbip_pack_ret_submit() before the overwrite -- and\nusing the tighter per-URB allocation bound rather than the global\nUSBIP_MAX_ISO_PACKETS limit.\n\nFix this by checking rpdu-\u0026gt;number_of_packets against\nurb-\u0026gt;number_of_packets in usbip_pack_ret_submit() before the\noverwrite. On violation, clamp to zero so that usbip_recv_iso() and\nusbip_pad_iso() safely return early.(CVE-2026-31607)\n\nIn the Linux kernel, the following vulnerability has been resolved: smb: client: validate the whole DACL before rewriting it in cifsacl. build_sec_desc() and id_mode_to_cifs_acl() derive a DACL pointer from a server-supplied dacloffset and then use the incoming ACL to rebuild the chmod/chown security descriptor. The original fix only checked that the struct smb_acl header fits before reading dacl_ptr-\u0026gt;size or dacl_ptr-\u0026gt;num_aces. That avoids the immediate header-field OOB read, but the rewrite helpers still walk ACEs based on pdacl-\u0026gt;num_aces with no structural validation of the incoming DACL body. A malicious server can return a truncated DACL that still contains a header, claims one or more ACEs, and then drive replace_sids_and_copy_aces() or set_chmod_dacl() past the validated extent while they compare or copy attacker-controlled ACEs.(CVE-2026-31709)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: reject immediate NF_QUEUE verdict\n\nnft_queue is always used from userspace nftables to deliver the NF_QUEUE\nverdict. Immediately emitting an NF_QUEUE verdict is never used by the\nuserspace nft tools, so reject immediate NF_QUEUE verdicts.\n\nThe arp family does not provide queue support, but such an immediate\nverdict is still reachable. Globally reject NF_QUEUE immediate verdicts\nto address this issue.(CVE-2026-43024)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: icmp: clear skb2-\u0026gt;cb[] in ip6_err_gen_icmpv6_unreach()\n\nSashiko AI-review observed:\n\n  In ip6_err_gen_icmpv6_unreach(), the skb is an outer IPv4 ICMP error packet\n  where its cb contains an IPv4 inet_skb_parm. When skb is cloned into skb2\n  and passed to icmp6_send(), it uses IP6CB(skb2).\n\n  IP6CB interprets the IPv4 inet_skb_parm as an inet6_skb_parm. The cipso\n  offset in inet_skb_parm.opt directly overlaps with dsthao in inet6_skb_parm\n  at offset 18.\n\n  If an attacker sends a forged ICMPv4 error with a CIPSO IP option, dsthao\n  would be a non-zero offset. Inside icmp6_send(), mip6_addr_swap() is called\n  and uses ipv6_find_tlv(skb, opt-\u0026gt;dsthao, IPV6_TLV_HAO).\n\n  This would scan the inner, attacker-controlled IPv6 packet starting at that\n  offset, potentially returning a fake TLV without checking if the remaining\n  packet length can hold the full 18-byte struct ipv6_destopt_hao.\n\n  Could mip6_addr_swap() then perform a 16-byte swap that extends past the end\n  of the packet data into skb_shared_info?\n\n  Should the cb array also be cleared in ip6_err_gen_icmpv6_unreach() and\n  ip6ip6_err() to prevent this?\n\nThis patch implements the first suggestion.\n\nI am not sure if ip6ip6_err() needs to be changed.\nA separate patch would be better anyway.(CVE-2026-43038)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndcache: Limit the minimal number of bucket to two\n\nThere is an OOB read problem on dentry_hashtable when user sets\n\u0026apos;dhash_entries=1\u0026apos;:\n  BUG: unable to handle page fault for address: ffff888b30b774b0\n  #PF: supervisor read access in kernel mode\n  #PF: error_code(0x0000) - not-present page\n  Oops: Oops: 0000 [#1] SMP PTI\n  RIP: 0010:__d_lookup+0x56/0x120\n   Call Trace:\n    d_lookup.cold+0x16/0x5d\n    lookup_dcache+0x27/0xf0\n    lookup_one_qstr_excl+0x2a/0x180\n    start_dirop+0x55/0xa0\n    simple_start_creating+0x8d/0xa0\n    debugfs_start_creating+0x8c/0x180\n    debugfs_create_dir+0x1d/0x1c0\n    pinctrl_init+0x6d/0x140\n    do_one_initcall+0x6d/0x3d0\n    kernel_init_freeable+0x39f/0x460\n    kernel_init+0x2a/0x260\n\nThere will be only one bucket in dentry_hashtable when dhash_entries is\nset as one, and d_hash_shift is calculated as 32 by dcache_init(). Then,\nfollowing process will access more than one buckets(which memory region\nis not allocated) in dentry_hashtable:\n d_lookup\n  b = d_hash(hash)\n    dentry_hashtable + ((u32)hashlen \u0026gt;\u0026gt; d_hash_shift)\n    // The C standard defines the behavior of right shift amounts\n    // exceeding the bit width of the operand as undefined. The\n    // result of \u0026apos;(u32)hashlen \u0026gt;\u0026gt; d_hash_shift\u0026apos; becomes \u0026apos;hashlen\u0026apos;,\n    // so \u0026apos;b\u0026apos; will point to an unallocated memory region.\n  hlist_bl_for_each_entry_rcu(b)\n   hlist_bl_first_rcu(head)\n    h-\u0026gt;first  // read OOB!\n\nFix it by limiting the minimal number of dentry_hashtable bucket to two,\nso that \u0026apos;d_hash_shift\u0026apos; won\u0026apos;t exceeds the bit width of type u32.(CVE-2026-43071)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: af_key: zero aligned sockaddr tail in PF_KEY exports\n\nPF_KEY export paths use `pfkey_sockaddr_size()` when reserving sockaddr\npayload space, so IPv6 addresses occupy 32 bytes on the wire. However,\n`pfkey_sockaddr_fill()` initializes only the first 28 bytes of\n`struct sockaddr_in6`, leaving the final 4 aligned bytes uninitialized.\n\nNot every PF_KEY message is affected. The state and policy dump builders\nalready zero the whole message buffer before filling the sockaddr\npayloads. Keep the fix to the export paths that still append aligned\nsockaddr payloads with plain `skb_put()`:\n\n  - `SADB_ACQUIRE`\n  - `SADB_X_NAT_T_NEW_MAPPING`\n  - `SADB_X_MIGRATE`\n\nFix those paths by clearing only the aligned sockaddr tail after\n`pfkey_sockaddr_fill()`.(CVE-2026-43088)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm_user: fix info leak in build_mapping()\n\nstruct xfrm_usersa_id has a one-byte padding hole after the proto\nfield, which ends up never getting set to zero before copying out to\nuserspace.  Fix that up by zeroing out the whole structure before\nsetting individual variables.(CVE-2026-43089)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: account XFRMA_IF_ID in aevent size calculation\n\nxfrm_get_ae() allocates the reply skb with xfrm_aevent_msgsize(), then\nbuild_aevent() appends attributes including XFRMA_IF_ID when x-\u0026gt;if_id is\nset.\n\nxfrm_aevent_msgsize() does not include space for XFRMA_IF_ID. For states\nwith if_id, build_aevent() can fail with -EMSGSIZE and hit BUG_ON(err \u0026lt; 0)\nin xfrm_get_ae(), turning a malformed netlink interaction into a kernel\npanic.\n\nAccount XFRMA_IF_ID in the size calculation unconditionally and replace\nthe BUG_ON with normal error unwinding.(CVE-2026-43107)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntcp: fix potential race in tcp_v6_syn_recv_sock()\n\nCode in tcp_v6_syn_recv_sock() after the call to tcp_v4_syn_recv_sock()\nis done too late.\n\nAfter tcp_v4_syn_recv_sock(), the child socket is already visible\nfrom TCP ehash table and other cpus might use it.\n\nSince newinet-\u0026gt;pinet6 is still pointing to the listener ipv6_pinfo\nbad things can happen as syzbot found.\n\nMove the problematic code in tcp_v6_mapped_child_init()\nand call this new helper from tcp_v4_syn_recv_sock() before\nthe ehash insertion.\n\nThis allows the removal of one tcp_sync_mss(), since\ntcp_v4_syn_recv_sock() will call it with the correct\ncontext.(CVE-2026-43198)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: Drop the lock in skb_may_tx_timestamp()\n\nskb_may_tx_timestamp() may acquire sock::sk_callback_lock. The lock must\nnot be taken in IRQ context, only softirq is okay. A few drivers receive\nthe timestamp via a dedicated interrupt and complete the TX timestamp\nfrom that handler. This will lead to a deadlock if the lock is already\nwrite-locked on the same CPU.\n\nTaking the lock can be avoided. The socket (pointed by the skb) will\nremain valid until the skb is released. The -\u0026gt;sk_socket and -\u0026gt;file\nmember will be set to NULL once the user closes the socket which may\nhappen before the timestamp arrives.\nIf we happen to observe the pointer while the socket is closing but\nbefore the pointer is set to NULL then we may use it because both\npointer (and the file\u0026apos;s cred member) are RCU freed.\n\nDrop the lock. Use READ_ONCE() to obtain the individual pointer. Add a\nmatching WRITE_ONCE() where the pointer are cleared.(CVE-2026-43216)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvhost: move vdpa group bound check to vhost_vdpa\n\nRemove duplication by consolidating these here.  This reduces the\nposibility of a parent driver missing them.\n\nWhile we\u0026apos;re at it, fix a bug in vdpa_sim where a valid ASID can be\nassigned to a group equal to ngroups, causing an out of bound write.(CVE-2026-43248)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/page_alloc: clear page-\u0026gt;private in free_pages_prepare()\n\nSeveral subsystems (slub, shmem, ttm, etc.) use page-\u0026gt;private but don\u0026apos;t\nclear it before freeing pages.  When these pages are later allocated as\nhigh-order pages and split via split_page(), tail pages retain stale\npage-\u0026gt;private values.\n\nThis causes a use-after-free in the swap subsystem.  The swap code uses\npage-\u0026gt;private to track swap count continuations, assuming freshly\nallocated pages have page-\u0026gt;private == 0.  When stale values are present,\nswap_count_continued() incorrectly assumes the continuation list is valid\nand iterates over uninitialized page-\u0026gt;lru containing LIST_POISON values,\ncausing a crash:\n\n  KASAN: maybe wild-memory-access in range [0xdead000000000100-0xdead000000000107]\n  RIP: 0010:__do_sys_swapoff+0x1151/0x1860\n\nFix this by clearing page-\u0026gt;private in free_pages_prepare(), ensuring all\nfreed pages have clean state regardless of previous use.(CVE-2026-43303)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nscsi: hisi_sas: Fix NULL pointer exception during user_scan()\n\nuser_scan() invokes updated sas_user_scan() for channel 0, and if\nsuccessful, iteratively scans remaining channels (1 to shost-\u0026gt;max_channel)\nvia scsi_scan_host_selected() in commit 37c4e72b0651 (\u0026quot;scsi: Fix\nsas_user_scan() to handle wildcard and multi-channel scans\u0026quot;). However,\nhisi_sas supports only one channel, and the current value of max_channel is\n1. sas_user_scan() for channel 1 will trigger the following NULL pointer\nexception:\n\n[  441.554662] Unable to handle kernel NULL pointer dereference at virtual address 00000000000008b0\n[  441.554699] Mem abort info:\n[  441.554710]   ESR = 0x0000000096000004\n[  441.554718]   EC = 0x25: DABT (current EL), IL = 32 bits\n[  441.554723]   SET = 0, FnV = 0\n[  441.554726]   EA = 0, S1PTW = 0\n[  441.554730]   FSC = 0x04: level 0 translation fault\n[  441.554735] Data abort info:\n[  441.554737]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n[  441.554742]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n[  441.554747]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n[  441.554752] user pgtable: 4k pages, 48-bit VAs, pgdp=00000828377a6000\n[  441.554757] [00000000000008b0] pgd=0000000000000000, p4d=0000000000000000\n[  441.554769] Internal error: Oops: 0000000096000004 [#1]  SMP\n[  441.629589] Modules linked in: arm_spe_pmu arm_smmuv3_pmu tpm_tis_spi hisi_uncore_sllc_pmu hisi_uncore_pa_pmu hisi_uncore_l3c_pmu hisi_uncore_hha_pmu hisi_uncore_ddrc_pmu hisi_uncore_cpa_pmu hns3_pmu hisi_ptt hisi_pcie_pmu tpm_tis_core spidev spi_hisi_sfc_v3xx hisi_uncore_pmu spi_dw_mmio fuse hclge hclge_common hisi_sec2 hisi_hpre hisi_zip hisi_qm hns3 hisi_sas_v3_hw sm3_ce sbsa_gwdt hnae3 hisi_sas_main uacce hisi_dma i2c_hisi dm_mirror dm_region_hash dm_log dm_mod\n[  441.670819] CPU: 46 UID: 0 PID: 6994 Comm: bash Kdump: loaded Not tainted 7.0.0-rc2+ #84 PREEMPT\n[  441.691327] pstate: 81400009 (Nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)\n[  441.698277] pc : sas_find_dev_by_rphy+0x44/0x118\n[  441.702896] lr : sas_find_dev_by_rphy+0x3c/0x118\n[  441.707502] sp : ffff80009abbba40\n[  441.710805] x29: ffff80009abbba40 x28: ffff082819a40008 x27: ffff082810c37c08\n[  441.717930] x26: ffff082810c37c28 x25: ffff082819a40290 x24: ffff082810c37c00\n[  441.725054] x23: 0000000000000000 x22: 0000000000000001 x21: ffff082819a40000\n[  441.732179] x20: ffff082819a40290 x19: 0000000000000000 x18: 0000000000000020\n[  441.739304] x17: 0000000000000000 x16: ffffb5dad6bda690 x15: 00000000ffffffff\n[  441.746428] x14: ffff082814c3b26c x13: 00000000ffffffff x12: ffff082814c3b26a\n[  441.753553] x11: 00000000000000c0 x10: 000000000000003a x9 : ffffb5dad5ea94f4\n[  441.760678] x8 : 000000000000003a x7 : ffff80009abbbab0 x6 : 0000000000000030\n[  441.767802] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000\n[  441.774926] x2 : ffff08280f35a300 x1 : ffffb5dad7127180 x0 : 0000000000000000\n[  441.782053] Call trace:\n[  441.784488]  sas_find_dev_by_rphy+0x44/0x118 (P)\n[  441.789095]  sas_target_alloc+0x24/0xb0\n[  441.792920]  scsi_alloc_target+0x290/0x330\n[  441.797010]  __scsi_scan_target+0x88/0x258\n[  441.801096]  scsi_scan_channel+0x74/0xb8\n[  441.805008]  scsi_scan_host_selected+0x170/0x188\n[  441.809615]  sas_user_scan+0xfc/0x148\n[  441.813267]  store_scan+0x10c/0x180\n[  441.816743]  dev_attr_store+0x20/0x40\n[  441.820398]  sysfs_kf_write+0x84/0xa8\n[  441.824054]  kernfs_fop_write_iter+0x130/0x1c8\n[  441.828487]  vfs_write+0x2c0/0x370\n[  441.831880]  ksys_write+0x74/0x118\n[  441.835271]  __arm64_sys_write+0x24/0x38\n[  441.839182]  invoke_syscall+0x50/0x120\n[  441.842919]  el0_svc_common.constprop.0+0xc8/0xf0\n[  441.847611]  do_el0_svc+0x24/0x38\n[  441.850913]  el0_svc+0x38/0x158\n[  441.854043]  el0t_64_sync_handler+0xa0/0xe8\n[  441.858214]  el0t_64_sync+0x1ac/0x1b0\n[  441.861865] Code: aa1303e0 97ff70a8 34ffff80 d10a4273 (f9445a75)\n[  441.867946] ---[ end trace 0000000000000000 ]---\n\nTherefore\n---truncated---(CVE-2026-43413)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvs: skip ipv6 extension headers for csum checks\n\nProtocol checksum validation fails for IPv6 if there are extension\nheaders before the protocol header. iph-\u0026gt;len already contains its\noffset, so use it to fix the problem.(CVE-2026-45850)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: hns3: fix double free issue for tx spare buffer\n\nIn hns3_set_ringparam(), a temporary copy (tmp_rings) of the ring structure\nis created for rollback. However, the tx_spare pointer in the original\nring handle is incorrectly left pointing to the old backup memory.\n\nLater, if memory allocation fails in hns3_init_all_ring() during the setup,\nthe error path attempts to free all newly allocated rings. Since tx_spare\ncontains a stale (non-NULL) pointer from the backup, it is mistaken for\na newly allocated buffer and is erroneously freed, leading to a double-free\nof the backup memory.\n\nThe root cause is that the tx_spare field was not cleared after its value\nwas saved in tmp_rings, leaving a dangling pointer.\n\nFix this by setting tx_spare to NULL in the original ring structure\nwhen the creation of the new `tx_spare` fails. This ensures the\nerror cleanup path only frees genuinely newly allocated buffers.(CVE-2026-45891)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/vt-d: Clear Present bit before tearing down PASID entry\n\nThe Intel VT-d Scalable Mode PASID table entry consists of 512 bits (64\nbytes). When tearing down an entry, the current implementation zeros the\nentire 64-byte structure immediately using multiple 64-bit writes.\n\nSince the IOMMU hardware may fetch these 64 bytes using multiple\ninternal transactions (e.g., four 128-bit bursts), updating or zeroing\nthe entire entry while it is active (P=1) risks a \u0026quot;torn\u0026quot; read. If a\nhardware fetch occurs simultaneously with the CPU zeroing the entry, the\nhardware could observe an inconsistent state, leading to unpredictable\nbehavior or spurious faults.\n\nFollow the \u0026quot;Guidance to Software for Invalidations\u0026quot; in the VT-d spec\n(Section 6.5.3.3) by implementing the recommended ownership handshake:\n\n1. Clear only the \u0026apos;Present\u0026apos; (P) bit of the PASID entry.\n2. Use a dma_wmb() to ensure the cleared bit is visible to hardware\n   before proceeding.\n3. Execute the required invalidation sequence (PASID cache, IOTLB, and\n   Device-TLB flush) to ensure the hardware has released all cached\n   references.\n4. Only after the flushes are complete, zero out the remaining fields\n   of the PASID entry.\n\nAlso, add a dma_wmb() in pasid_set_present() to ensure that all other\nfields of the PASID entry are visible to the hardware before the Present\nbit is set.(CVE-2026-45894)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nquota: fix livelock between quotactl and freeze_super\n\nWhen a filesystem is frozen, quotactl_block() enters a retry loop\nwaiting for the filesystem to thaw. It acquires s_umount, checks the\nfreeze state, drops s_umount and uses sb_start_write() - sb_end_write()\npair to wait for the unfreeze.\n\nHowever, this retry loop can trigger a livelock issue, specifically on\nkernels with preemption disabled.\n\nThe mechanism is as follows:\n1. freeze_super() sets SB_FREEZE_WRITE and calls sb_wait_write().\n2. sb_wait_write() calls percpu_down_write(), which initiates\n   synchronize_rcu().\n3. Simultaneously, quotactl_block() spins in its retry loop, immediately\n   executing the sb_start_write() - sb_end_write() pair.\n4. Because the kernel is non-preemptible and the loop contains no\n   scheduling points, quotactl_block() never yields the CPU. This\n   prevents that CPU from reaching an RCU quiescent state.\n5. synchronize_rcu() in the freezer thread waits indefinitely for the\n   quotactl_block() CPU to report a quiescent state.\n6. quotactl_block() spins indefinitely waiting for the freezer to\n   advance, which it cannot do as it is blocked on the RCU sync.\n\nThis results in a hang of the freezer process and 100% CPU usage by the\nquota process.\n\nWhile this can occur intermittently on multi-core systems, it is\nreliably reproducing on a node with the following script, running both\nthe freezer and the quota toggle on the same CPU:\n\n  # mkfs.ext4 -O quota /dev/sda 2g \u0026amp;\u0026amp; mkdir a_mount\n  # mount /dev/sda -o quota,usrquota,grpquota a_mount\n  # taskset -c 3 bash -c \u0026quot;while true; do xfs_freeze -f a_mount; \\\n    xfs_freeze -u a_mount; done\u0026quot; \u0026amp;\n  # taskset -c 3 bash -c \u0026quot;while true; do quotaon a_mount; \\\n    quotaoff a_mount; done\u0026quot; \u0026amp;\n\nAdding cond_resched() to the retry loop fixes the issue. It acts as an\nRCU quiescent state, allowing synchronize_rcu() in percpu_down_write()\nto complete.(CVE-2026-45895)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfat: avoid parent link count underflow in rmdir\n\nCorrupted FAT images can leave a directory inode with an incorrect\ni_nlink (e.g. 2 even though subdirectories exist). rmdir then\nunconditionally calls drop_nlink(dir) and can drive i_nlink to 0,\ntriggering the WARN_ON in drop_nlink().\n\nAdd a sanity check in vfat_rmdir() and msdos_rmdir(): only drop the\nparent link count when it is at least 3, otherwise report a filesystem\nerror.(CVE-2026-45915)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nsched/rt: Skip currently executing CPU in rto_next_cpu()\n\nCPU0 becomes overloaded when hosting a CPU-bound RT task, a non-CPU-bound\nRT task, and a CFS task stuck in kernel space. When other CPUs switch from\nRT to non-RT tasks, RT load balancing (LB) is triggered; with\nHAVE_RT_PUSH_IPI enabled, they send IPIs to CPU0 to drive the execution\nof rto_push_irq_work_func. During push_rt_task on CPU0,\nif next_task-\u0026gt;prio \u0026lt; rq-\u0026gt;donor-\u0026gt;prio, resched_curr() sets NEED_RESCHED\nand after the push operation completes, CPU0 calls rto_next_cpu().\nSince only CPU0 is overloaded in this scenario, rto_next_cpu() should\nideally return -1 (no further IPI needed).\n\nHowever, multiple CPUs invoking tell_cpu_to_push() during LB increments\nrd-\u0026gt;rto_loop_next. Even when rd-\u0026gt;rto_cpu is set to -1, the mismatch between\nrd-\u0026gt;rto_loop and rd-\u0026gt;rto_loop_next forces rto_next_cpu() to restart its\nsearch from -1. With CPU0 remaining overloaded (satisfying rt_nr_migratory\n\u0026amp;\u0026amp; rt_nr_total \u0026gt; 1), it gets reselected, causing CPU0 to queue irq_work to\nitself and send self-IPIs repeatedly. As long as CPU0 stays overloaded and\nother CPUs run pull_rt_tasks(), it falls into an infinite self-IPI loop,\nwhich triggers a CPU hardlockup due to continuous self-interrupts.\n\nThe trigging scenario is as follows:\n\n         cpu0                      cpu1                    cpu2\n                                pull_rt_task\n                              tell_cpu_to_push\n                 \u0026lt;------------irq_work_queue_on\nrto_push_irq_work_func\n       push_rt_task\n    resched_curr(rq)                                   pull_rt_task\n    rto_next_cpu                                     tell_cpu_to_push\n                      \u0026lt;-------------------------- atomic_inc(rto_loop_next)\nrd-\u0026gt;rto_loop != next\n     rto_next_cpu\n   irq_work_queue_on\nrto_push_irq_work_func\n\nFix redundant self-IPI by filtering the initiating CPU in rto_next_cpu().\nThis solution has been verified to effectively eliminate spurious self-IPIs\nand prevent CPU hardlockup scenarios.(CVE-2026-45919)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix dirtyclusters double decrement on fs shutdown\n\nfstests test generic/388 occasionally reproduces a warning in\next4_put_super() associated with the dirty clusters count:\n\n  WARNING: CPU: 7 PID: 76064 at fs/ext4/super.c:1324 ext4_put_super+0x48c/0x590 [ext4]\n\nTracing the failure shows that the warning fires due to an\ns_dirtyclusters_counter value of -1. IOW, this appears to be a\nspurious decrement as opposed to some sort of leak. Further tracing\nof the dirty cluster count deltas and an LLM scan of the resulting\noutput identified the cause as a double decrement in the error path\nbetween ext4_mb_mark_diskspace_used() and the caller\next4_mb_new_blocks().\n\nFirst, note that generic/388 is a shutdown vs. fsstress test and so\nproduces a random set of operations and shutdown injections. In the\nproblematic case, the shutdown triggers an error return from the\next4_handle_dirty_metadata() call(s) made from\next4_mb_mark_context(). The changed value is non-zero at this point,\nso ext4_mb_mark_diskspace_used() does not exit after the error\nbubbles up from ext4_mb_mark_context(). Instead, the former\ndecrements both cluster counters and returns the error up to\next4_mb_new_blocks(). The latter falls into the !ar-\u0026gt;len out path\nwhich decrements the dirty clusters counter a second time, creating\nthe inconsistency.\n\nTo avoid this problem and simplify ownership of the cluster\nreservation in this codepath, lift the counter reduction to a single\nplace in the caller. This makes it more clear that\next4_mb_new_blocks() is responsible for acquiring cluster\nreservation (via ext4_claim_free_clusters()) in the !delalloc case\nas well as releasing it, regardless of whether it ends up consumed\nor returned due to failure.(CVE-2026-45920)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix e4b bitmap inconsistency reports\n\nA bitmap inconsistency issue was observed during stress tests under\nmixed huge-page workloads. Ext4 reported multiple e4b bitmap check\nfailures like:\n\next4_mb_complex_scan_group:2508: group 350, 8179 free clusters as\nper group info. But got 8192 blocks\n\nAnalysis and experimentation confirmed that the issue is caused by a\nrace condition between page migration and bitmap modification. Although\nthis timing window is extremely narrow, it is still hit in practice:\n\nfolio_lock                        ext4_mb_load_buddy\n__migrate_folio\n  check ref count\n  folio_mc_copy                     __filemap_get_folio\n                                      folio_try_get(folio)\n                                  ......\n                                  mb_mark_used\n                                  ext4_mb_unload_buddy\n  __folio_migrate_mapping\n    folio_ref_freeze\nfolio_unlock\n\nThe root cause of this issue is that the fast path of load_buddy only\nincrements the folio\u0026apos;s reference count, which is insufficient to prevent\nconcurrent folio migration. We observed that the folio migration process\nacquires the folio lock. Therefore, we can determine whether to take the\nfast path in load_buddy by checking the lock status. If the folio is\nlocked, we opt for the slow path (which acquires the lock) to close this\nconcurrency window.\n\nAdditionally, this change addresses the following issues:\n\nWhen the DOUBLE_CHECK macro is enabled to inspect bitmap-related\nissues, the following error may be triggered:\n\ncorruption in group 324 at byte 784(6272): f in copy != ff on\ndisk/prealloc\n\nAnalysis reveals that this is a false positive. There is a specific race\nwindow where the bitmap and the group descriptor become momentarily\ninconsistent, leading to this error report:\n\next4_mb_load_buddy                   ext4_mb_load_buddy\n  __filemap_get_folio(create|lock)\n    folio_lock\n  ext4_mb_init_cache\n    folio_mark_uptodate\n                                     __filemap_get_folio(no lock)\n                                     ......\n                                     mb_mark_used\n                                       mb_mark_used_double\n  mb_cmp_bitmaps\n                                       mb_set_bits(e4b-\u0026gt;bd_bitmap)\n  folio_unlock\n\nThe original logic assumed that since mb_cmp_bitmaps is called when the\nbitmap is newly loaded from disk, the folio lock would be sufficient to\nprevent concurrent access. However, this overlooks a specific race\ncondition: if another process attempts to load buddy and finds the folio\nis already in an uptodate state, it will immediately begin using it without\nholding folio lock.(CVE-2026-45942)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/vt-d: Clear Present bit before tearing down context entry\n\nWhen tearing down a context entry, the current implementation zeros the\nentire 128-bit entry using multiple 64-bit writes. This creates a window\nwhere the hardware can fetch a \u0026quot;torn\u0026quot; entry \u2014 where some fields are\nalready zeroed while the \u0026apos;Present\u0026apos; bit is still set \u2014 leading to\nunpredictable behavior or spurious faults.\n\nWhile x86 provides strong write ordering, the compiler may reorder writes\nto the two 64-bit halves of the context entry. Even without compiler\nreordering, the hardware fetch is not guaranteed to be atomic with\nrespect to multiple CPU writes.\n\nAlign with the \u0026quot;Guidance to Software for Invalidations\u0026quot; in the VT-d spec\n(Section 6.5.3.3) by implementing the recommended ownership handshake:\n\n1. Clear only the \u0026apos;Present\u0026apos; (P) bit of the context entry first to\n   signal the transition of ownership from hardware to software.\n2. Use dma_wmb() to ensure the cleared bit is visible to the IOMMU.\n3. Perform the required cache and context-cache invalidation to ensure\n   hardware no longer has cached references to the entry.\n4. Fully zero out the entry only after the invalidation is complete.\n\nAlso, add a dma_wmb() to context_set_present() to ensure the entry\nis fully initialized before the \u0026apos;Present\u0026apos; bit becomes visible.(CVE-2026-45944)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix memory leak in ext4_ext_shift_extents()\n\nIn ext4_ext_shift_extents(), if the extent is NULL in the while loop, the\nfunction returns immediately without releasing the path obtained via\next4_find_extent(), leading to a memory leak.\n\nFix this by jumping to the out label to ensure the path is properly\nreleased.(CVE-2026-45948)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncpuidle: Skip governor when only one idle state is available\n\nOn certain platforms (PowerNV systems without a power-mgt DT node),\ncpuidle may register only a single idle state. In cases where that\nsingle state is a polling state (state 0), the ladder governor may\nincorrectly treat state 1 as the first usable state and pass an\nout-of-bounds index. This can lead to a NULL enter callback being\ninvoked, ultimately resulting in a system crash.\n\n[   13.342636] cpuidle-powernv : Only Snooze is available\n[   13.351854] Faulting instruction address: 0x00000000\n[   13.376489] NIP [0000000000000000] 0x0\n[   13.378351] LR  [c000000001e01974] cpuidle_enter_state+0x2c4/0x668\n\nFix this by adding a bail-out in cpuidle_select() that returns state 0\ndirectly when state_count \u0026lt;= 1, bypassing the governor and keeping the\ntick running.(CVE-2026-45968)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: don\u0026apos;t set EXT4_GET_BLOCKS_CONVERT when splitting before submitting I/O\n\nWhen allocating blocks during within-EOF DIO and writeback with\ndioread_nolock enabled, EXT4_GET_BLOCKS_PRE_IO was set to split an\nexisting large unwritten extent. However, EXT4_GET_BLOCKS_CONVERT was\nset when calling ext4_split_convert_extents(), which may potentially\nresult in stale data issues.\n\nAssume we have an unwritten extent, and then DIO writes the second half.\n\n   [UUUUUUUUUUUUUUUU] on-disk extent        U: unwritten extent\n   [UUUUUUUUUUUUUUUU] extent status tree\n            |\u0026lt;-   -\u0026gt;| ----\u0026gt; dio write this range\n\nFirst, ext4_iomap_alloc() call ext4_map_blocks() with\nEXT4_GET_BLOCKS_PRE_IO, EXT4_GET_BLOCKS_UNWRIT_EXT and\nEXT4_GET_BLOCKS_CREATE flags set. ext4_map_blocks() find this extent and\ncall ext4_split_convert_extents() with EXT4_GET_BLOCKS_CONVERT and the\nabove flags set.\n\nThen, ext4_split_convert_extents() calls ext4_split_extent() with\nEXT4_EXT_MAY_ZEROOUT, EXT4_EXT_MARK_UNWRIT2 and EXT4_EXT_DATA_VALID2\nflags set, and it calls ext4_split_extent_at() to split the second half\nwith EXT4_EXT_DATA_VALID2, EXT4_EXT_MARK_UNWRIT1, EXT4_EXT_MAY_ZEROOUT\nand EXT4_EXT_MARK_UNWRIT2 flags set. However, ext4_split_extent_at()\nfailed to insert extent since a temporary lack -ENOSPC. It zeroes out\nthe first half but convert the entire on-disk extent to written since\nthe EXT4_EXT_DATA_VALID2 flag set, but left the second half as unwritten\nin the extent status tree.\n\n   [0000000000SSSSSS]  data                S: stale data, 0: zeroed\n   [WWWWWWWWWWWWWWWW]  on-disk extent      W: written extent\n   [WWWWWWWWWWUUUUUU]  extent status tree\n\nFinally, if the DIO failed to write data to the disk, the stale data in\nthe second half will be exposed once the cached extent entry is gone.\n\nFix this issue by not passing EXT4_GET_BLOCKS_CONVERT when splitting\nan unwritten extent before submitting I/O, and make\next4_split_convert_extents() to zero out the entire extent range\nto zero for this case, and also mark the extent in the extent status\ntree for consistency.(CVE-2026-45985)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: nSVM: Triple fault if restore host CR3 fails on nested #VMEXIT\n\nIf loading L1\u0026apos;s CR3 fails on a nested #VMEXIT, nested_svm_vmexit()\nreturns an error code that is ignored by most callers, and continues to\nrun L1 with corrupted state. A sane recovery is not possible in this\ncase, and HW behavior is to cause a shutdown. Inject a triple fault\ninstead, and do not return early from nested_svm_vmexit(). Continue\ncleaning up the vCPU state (e.g. clear pending exceptions), to handle\nthe failure as gracefully as possible.\n\nFrom the APM:\n\n  Upon #VMEXIT, the processor performs the following actions in order to\n  return to the host execution context:\n\n  ...\n\n  if (illegal host state loaded, or exception while loading host state)\n      shutdown\n  else\n      execute first host instruction following the VMRUN\n\nRemove the return value of nested_svm_vmexit(), which is mostly\nunchecked anyway.(CVE-2026-46032)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: defio: Disconnect deferred I/O from the lifetime of struct fb_info\n\nHold state of deferred I/O in struct fb_deferred_io_state. Allocate an\ninstance as part of initializing deferred I/O and remove it only after\nthe final mapping has been closed. If the fb_info and the contained\ndeferred I/O meanwhile goes away, clear struct fb_deferred_io_state.info\nto invalidate the mapping. Any access will then result in a SIGBUS\nsignal.\n\nFixes a long-standing problem, where a device hot-unplug happens while\nuser space still has an active mapping of the graphics memory. The hot-\nunplug frees the instance of struct fb_info. Accessing the memory will\noperate on undefined state.(CVE-2026-46065)\n\nIn the Linux kernel, the vlan_dev_set_egress_priority() function currently keeps cleared egress priority mappings in the hash as tombstones. Repeated set/clear cycles with distinct skb priorities accumulate mapping nodes until device teardown, causing memory leakage. This vulnerability is fixed by deleting mappings instead of keeping tombstones, using RCU protection for safe deallocation.(CVE-2026-46153)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\neventpoll: fix ep_remove struct eventpoll / struct file UAF\n\nep_remove() (via ep_remove_file()) cleared file-\u0026gt;f_ep under\nfile-\u0026gt;f_lock but then kept using @file inside the critical section\n(is_file_epoll(), hlist_del_rcu() through the head, spin_unlock).\nA concurrent __fput() taking the eventpoll_release() fastpath in\nthat window observed the transient NULL, skipped\neventpoll_release_file() and ran to f_op-\u0026gt;release / file_free().\n\nFor the epoll-watches-epoll case, f_op-\u0026gt;release is\nep_eventpoll_release() -\u0026gt; ep_clear_and_put() -\u0026gt; ep_free(), which\nkfree()s the watched struct eventpoll. Its embedded -\u0026gt;refs\nhlist_head is exactly where epi-\u0026gt;fllink.pprev points, so the\nsubsequent hlist_del_rcu()\u0026apos;s \u0026quot;*pprev = next\u0026quot; scribbles into freed\nkmalloc-192 memory.\n\nIn addition, struct file is SLAB_TYPESAFE_BY_RCU, so the slot\nbacking @file could be recycled by alloc_empty_file() --\nreinitializing f_lock and f_ep -- while ep_remove() is still\nnominally inside that lock. The upshot is an attacker-controllable\nkmem_cache_free() against the wrong slab cache.\n\nPin @file via epi_fget() at the top of ep_remove() and gate the\ncritical section on the pin succeeding. With the pin held @file\ncannot reach refcount zero, which holds __fput() off and\ntransitively keeps the watched struct eventpoll alive across the\nhlist_del_rcu() and the f_lock use, closing both UAFs.\n\nIf the pin fails @file has already reached refcount zero and its\n__fput() is in flight. Because we bailed before clearing f_ep,\nthat path takes the eventpoll_release() slow path into\neventpoll_release_file() and blocks on ep-\u0026gt;mtx until the waiter\nside\u0026apos;s ep_clear_and_put() drops it. The bailed epi\u0026apos;s share of\nep-\u0026gt;refcount stays intact, so the trailing ep_refcount_dec_and_test()\nin ep_clear_and_put() cannot free the eventpoll out from under\neventpoll_release_file(); the orphaned epi is then cleaned up\nthere.\n\nA successful pin also proves we are not racing\neventpoll_release_file() on this epi, so drop the now-redundant\nre-check of epi-\u0026gt;dying under f_lock. The cheap lockless\nREAD_ONCE(epi-\u0026gt;dying) fast-path bailout stays.(CVE-2026-46242)\n\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Fix dc_link NULL handling in HPD init  amdgpu_dm_hpd_init() may see connectors without a valid dc_link.  The code already checks dc_link for the polling decision, but later unconditionally dereferences it when setting up HPD interrupts.  Assign dc_link early and skip connectors where it is NULL.  Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_irq.c:940 amdgpu_dm_hpd_init() error: we previously assumed \u0026apos;dc_link\u0026apos; could be null (see line 931)  drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_irq.c     923                 /*     924                  * Analog connectors may be hot-plugged unlike other connector     925                  * types that don\u0026apos;t support HPD. Only poll analog connectors.     926                  */     927                 use_polling |=     928                         amdgpu_dm_connector-\u0026gt;dc_link \u0026amp;\u0026amp;                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The patch adds this NULL check but hopefully it can be removed      929                         dc_connector_supports_analog(amdgpu_dm_connector-\u0026gt;dc_link-\u0026gt;link_id.id);     930     931                 dc_link = amdgpu_dm_connector-\u0026gt;dc_link;  dc_link assigned here.      932     933                 /*     934                  * Get a base driver irq reference for hpd ints for the lifetime     935                  * of dm. Note that only hpd interrupt types are registered with     936                  * base driver; hpd_rx types aren\u0026apos;t. IOW, amdgpu_irq_get/put on     937                  * hpd_rx isn\u0026apos;t available. DM currently controls hpd_rx     938                  * explicitly with dc_interrupt_set()     939                  */ --\u0026gt; 940                 if (dc_link-\u0026gt;irq_source_hpd != DC_IRQ_SOURCE_INVALID) {                             ^^^^^^^^^^^^^^^^^^^^^^^ If it\u0026apos;s NULL then we are trouble because we dereference it here.      941                         irq_type = dc_link-\u0026gt;irq_source_hpd - DC_IRQ_SOURCE_HPD1;     942                         /*     943                          * TODO: There\u0026apos;s a mismatch between mode_info.num_hpd     944                          * and what bios reports as the # of connectors with hpd  The Linux kernel CVE team has assigned CVE-2026-46245 to this issue.(CVE-2026-46245)\n\nIn the Linux kernel, the following vulnerability has been resolved:  procfs: fix missing RCU protection when reading real_parent in do_task_stat()  When reading /proc/[pid]/stat, do_task_stat() accesses task-\u0026gt;real_parent without proper RCU protection, which leads to:    cpu 0                               cpu 1   -----                               -----   do_task_stat     var = task-\u0026gt;real_parent                                       release_task                                         call_rcu(delayed_put_task_struct)     task_tgid_nr_ns(var)       rcu_read_lock   \u0026lt;--- Too late to protect task-\u0026gt;real_parent!       task_pid_ptr    \u0026lt;--- UAF!       rcu_read_unlock  This patch uses task_ppid_nr_ns() instead of task_tgid_nr_ns() to add proper RCU protection for accessing task-\u0026gt;real_parent.  The Linux kernel CVE team has assigned CVE-2026-46259 to this issue.(CVE-2026-46259)",
  "id": "OESA-2026-2675",
  "modified": "2026-08-06T11:11:36Z",
  "published": "2026-06-12T11:11:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2675"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38389"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68183"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68198"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68813"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71085"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31527"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31607"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31709"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43024"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43038"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43071"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43088"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43089"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43107"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43198"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43216"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43248"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43303"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43413"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45850"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45891"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45894"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45895"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45915"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45919"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45920"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45942"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45944"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45948"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45968"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45985"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46032"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46065"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46153"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46242"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46245"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46259"
    }
  ],
  "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-2025-38389",
    "CVE-2025-68183",
    "CVE-2025-68198",
    "CVE-2025-68813",
    "CVE-2025-71085",
    "CVE-2026-31527",
    "CVE-2026-31607",
    "CVE-2026-31709",
    "CVE-2026-43024",
    "CVE-2026-43038",
    "CVE-2026-43071",
    "CVE-2026-43088",
    "CVE-2026-43089",
    "CVE-2026-43107",
    "CVE-2026-43198",
    "CVE-2026-43216",
    "CVE-2026-43248",
    "CVE-2026-43303",
    "CVE-2026-43413",
    "CVE-2026-45850",
    "CVE-2026-45891",
    "CVE-2026-45894",
    "CVE-2026-45895",
    "CVE-2026-45915",
    "CVE-2026-45919",
    "CVE-2026-45920",
    "CVE-2026-45942",
    "CVE-2026-45944",
    "CVE-2026-45948",
    "CVE-2026-45968",
    "CVE-2026-45985",
    "CVE-2026-46032",
    "CVE-2026-46065",
    "CVE-2026-46153",
    "CVE-2026-46242",
    "CVE-2026-46245",
    "CVE-2026-46259"
  ]
}

OESA-2026-2676 (CVE-2025-39781)

Vulnerability from osv_openeuler – Published: 2026-06-12 11:11 – Updated: 2026-08-06 11:11 – 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:

parisc: Drop WARN_ON_ONCE() from flush_cache_vmap

I have observed warning to occassionally trigger.(CVE-2025-39781)

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

MIPS: ftrace: Fix memory corruption when kernel is located beyond 32 bits

Since commit e424054000878 ("MIPS: Tracing: Reduce the overhead of dynamic Function Tracer"), the macro UASM_i_LA_mostly has been used, and this macro can generate more than 2 instructions. At the same time, the code in ftrace assumes that no more than 2 instructions can be generated, which is why it stores them in an int[2] array. However, as previously noted, the macro UASM_i_LA_mostly (and now UASM_i_LA) causes a buffer overflow when _mcount is beyond 32 bits. This leads to corruption of the variables located in the __read_mostly section.

This corruption was observed because the variable __cpu_primary_thread_mask was corrupted, causing a hang very early during boot.

This fix prevents the corruption by avoiding the generation of instructions if they could exceed 2 instructions in length. Fortunately, insn_la_mcount is only used if the instrumented code is located outside the kernel code section, so dynamic ftrace can still be used, albeit in a more limited scope. This is still preferable to corrupting memory and/or crashing the kernel.(CVE-2025-71109)

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

drm/amd/pm: Disable MMIO access during SMU Mode 1 reset

During Mode 1 reset, the ASIC undergoes a reset cycle and becomes temporarily inaccessible via PCIe. Any attempt to access MMIO registers during this window (e.g., from interrupt handlers or other driver threads) can result in uncompleted PCIe transactions, leading to NMI panics or system hangs.

To prevent this, set the no_hw_access flag to true immediately after triggering the reset. This signals other driver components to skip register accesses while the device is offline.

A memory barrier smp_mb() is added to ensure the flag update is globally visible to all cores before the driver enters the sleep/wait state.

(cherry picked from commit 7edb503fe4b6d67f47d8bb0dfafb8e699bb0f8a4)(CVE-2026-23213)

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

btrfs: reject new transactions if the fs is fully read-only

[BUG] There is a bug report where a heavily fuzzed fs is mounted with all rescue mount options, which leads to the following warnings during unmount:

BTRFS: Transaction aborted (error -22) Modules linked in: CPU: 0 UID: 0 PID: 9758 Comm: repro.out Not tainted 6.19.0-rc5-00002-gb71e635feefc #7 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:find_free_extent_update_loop fs/btrfs/extent-tree.c:4208 [inline] RIP: 0010:find_free_extent+0x52f0/0x5d20 fs/btrfs/extent-tree.c:4611 Call Trace: <TASK> btrfs_reserve_extent+0x2cd/0x790 fs/btrfs/extent-tree.c:4705 btrfs_alloc_tree_block+0x1e1/0x10e0 fs/btrfs/extent-tree.c:5157 btrfs_force_cow_block+0x578/0x2410 fs/btrfs/ctree.c:517 btrfs_cow_block+0x3c4/0xa80 fs/btrfs/ctree.c:708 btrfs_search_slot+0xcad/0x2b50 fs/btrfs/ctree.c:2130 btrfs_truncate_inode_items+0x45d/0x2350 fs/btrfs/inode-item.c:499 btrfs_evict_inode+0x923/0xe70 fs/btrfs/inode.c:5628 evict+0x5f4/0xae0 fs/inode.c:837 __dentry_kill+0x209/0x660 fs/dcache.c:670 finish_dput+0xc9/0x480 fs/dcache.c:879 shrink_dcache_for_umount+0xa0/0x170 fs/dcache.c:1661 generic_shutdown_super+0x67/0x2c0 fs/super.c:621 kill_anon_super+0x3b/0x70 fs/super.c:1289 btrfs_kill_super+0x41/0x50 fs/btrfs/super.c:2127 deactivate_locked_super+0xbc/0x130 fs/super.c:474 cleanup_mnt+0x425/0x4c0 fs/namespace.c:1318 task_work_run+0x1d4/0x260 kernel/task_work.c:233 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0x694/0x22f0 kernel/exit.c:971 do_group_exit+0x21c/0x2d0 kernel/exit.c:1112 __do_sys_exit_group kernel/exit.c:1123 [inline] __se_sys_exit_group kernel/exit.c:1121 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1121 x64_sys_call+0x2210/0x2210 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xe8/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x44f639 Code: Unable to access opcode bytes at 0x44f60f. RSP: 002b:00007ffc15c4e088 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 00000000004c32f0 RCX: 000000000044f639 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 0000000000000001 R08: ffffffffffffffc0 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004c32f0 R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001 </TASK>

Since rescue mount options will mark the full fs read-only, there should be no new transaction triggered.

But during unmount we will evict all inodes, which can trigger a new transaction, and triggers warnings on a heavily corrupted fs.

[CAUSE] Btrfs allows new transaction even on a read-only fs, this is to allow log replay happen even on read-only mounts, just like what ext4/xfs do.

However with rescue mount options, the fs is fully read-only and cannot be remounted read-write, thus in that case we should also reject any new transactions.

[FIX] If we find the fs has rescue mount options, we should treat the fs as error, so that no new transaction can be started.(CVE-2026-23214)

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

driver core: platform: use generic driver_override infrastructure

When a driver is probed through __driver_attach(), the bus' match() callback is called without the device lock held, thus accessing the driver_override field without a lock, which can cause a UAF.

Fix this by using the driver-core driver_override infrastructure taking care of proper locking internally.

Note that calling match() from __driver_attach() without the device lock held is intentional. 1

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

usbip: validate number_of_packets in usbip_pack_ret_submit()

KASAN confirmed this with kernel 7.0.0-rc5:

BUG: KASAN: slab-out-of-bounds in usbip_recv_iso+0x46a/0x640 Write of size 4 at addr ffff888106351d40 by task vhci_rx/69

The buggy address is located 0 bytes to the right of allocated 320-byte region [ffff888106351c00, ffff888106351d40)

This mirrors the existing validation of actual_length against transfer_buffer_length in usbip_recv_xbuff(), which checks the response value against the original allocation size.

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

tipc: fix bc_ackers underflow on duplicate GRP_ACK_MSG

The GRP_ACK_MSG handler in tipc_group_proto_rcv() currently decrements bc_ackers on every inbound group ACK, even when the same member has already acknowledged the current broadcast round.

Because bc_ackers is a u16, a duplicate ACK received after the last legitimate ACK wraps the counter to 65535. Once wrapped, tipc_group_bc_cong() keeps reporting congestion and later group broadcasts on the affected socket stay blocked until the group is recreated.

Fix this by ignoring duplicate or stale ACKs before touching bc_acked or bc_ackers. This makes repeated GRP_ACK_MSG handling idempotent and prevents the underflow path.(CVE-2026-31662)

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

usb: ulpi: fix double free in ulpi_register_interface() error path

When device_register() fails, ulpi_register() calls put_device() on ulpi->dev.

The device release callback ulpi_dev_release() drops the OF node reference and frees ulpi, but the current error path in ulpi_register_interface() then calls kfree(ulpi) again, causing a double free.

Let put_device() handle the cleanup through ulpi_dev_release() and avoid freeing ulpi again in ulpi_register_interface().(CVE-2026-31759)

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

netfilter: nf_tables: reject immediate NF_QUEUE verdict

The arp family does not provide queue support, but such an immediate verdict is still reachable. Globally reject NF_QUEUE immediate verdicts to address this issue.(CVE-2026-43024)

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

ipv6: icmp: clear skb2->cb[] in ip6_err_gen_icmpv6_unreach()

Sashiko AI-review observed:

In ip6_err_gen_icmpv6_unreach(), the skb is an outer IPv4 ICMP error packet where its cb contains an IPv4 inet_skb_parm. When skb is cloned into skb2 and passed to icmp6_send(), it uses IP6CB(skb2).

IP6CB interprets the IPv4 inet_skb_parm as an inet6_skb_parm. The cipso offset in inet_skb_parm.opt directly overlaps with dsthao in inet6_skb_parm at offset 18.

Could mip6_addr_swap() then perform a 16-byte swap that extends past the end of the packet data into skb_shared_info?

Should the cb array also be cleared in ip6_err_gen_icmpv6_unreach() and ip6ip6_err() to prevent this?

This patch implements the first suggestion.

I am not sure if ip6ip6_err() needs to be changed. A separate patch would be better anyway.(CVE-2026-43038)

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

Bluetooth: MGMT: Fix list corruption and UAF in command complete handlers

Commit 302a1f674c00 ("Bluetooth: MGMT: Fix possible UAFs") introduced mgmt_pending_valid(), which not only validates the pending command but also unlinks it from the pending list if it is valid. This change in semantics requires updates to several completion handlers to avoid list corruption and memory safety issues.

This patch addresses two left-over issues from the aforementioned rework:

In mgmt_add_adv_patterns_monitor_complete(), mgmt_pending_remove() is replaced with mgmt_pending_free() in the success path. Since mgmt_pending_valid() already unlinks the command at the beginning of the function, calling mgmt_pending_remove() leads to a double list_del() and subsequent list corruption/kernel panic.
In set_mesh_complete(), the use of mgmt_pending_foreach() in the error path is removed. Since the current command is already unlinked by mgmt_pending_valid(), this foreach loop would incorrectly target other pending mesh commands, potentially freeing them while they are still being processed concurrently (leading to UAFs). The redundant mgmt_cmd_status() is also simplified to use cmd->opcode directly.(CVE-2026-43059)

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

net: ioam6: fix OOB and missing lock

When trace->type.bit6 is set:

if (trace-&gt;type.bit6) {
    ...
    queue = skb_get_tx_queue(dev, skb);
    qdisc = rcu_dereference(queue-&gt;qdisc);

This code can lead to an out-of-bounds access of the dev->_tx[] array when is_input is true. In such a case, the packet is on the RX path and skb->queue_mapping contains the RX queue index of the ingress device. If the ingress device has more RX queues than the egress device (dev) has TX queues, skb_get_queue_mapping(skb) will exceed dev->num_tx_queues. Add a check to avoid this situation since skb_get_tx_queue() does not clamp the index. This issue has also revealed that per queue visibility cannot be accurate and will be replaced later as a new feature.

While at it, add missing lock around qdisc_qstats_qlen_backlog(). The function __ioam6_fill_trace_data() is called from both softirq and process contexts, hence the use of spin_lock_bh() here.(CVE-2026-43083)

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

net: af_key: zero aligned sockaddr tail in PF_KEY exports

SADB_ACQUIRE
SADB_X_NAT_T_NEW_MAPPING
SADB_X_MIGRATE

Fix those paths by clearing only the aligned sockaddr tail after pfkey_sockaddr_fill().(CVE-2026-43088)

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

xfrm_user: fix info leak in build_mapping()

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

ipv6: ioam: fix potential NULL dereferences in __ioam6_fill_trace_data()

We need to check __in6_dev_get() for possible NULL value, as suggested by Yiming Qian.

Also add skb_dst_dev_rcu() instead of skb_dst_dev(), and two missing READ_ONCE().

Note that @dev can't be NULL.(CVE-2026-43101)

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

xfrm: account XFRMA_IF_ID in aevent size calculation

xfrm_get_ae() allocates the reply skb with xfrm_aevent_msgsize(), then build_aevent() appends attributes including XFRMA_IF_ID when x->if_id is set.

Account XFRMA_IF_ID in the size calculation unconditionally and replace the BUG_ON with normal error unwinding.(CVE-2026-43107)

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

net: usb: kaweth: remove TX queue manipulation in kaweth_set_rx_mode

kaweth_set_rx_mode(), the ndo_set_rx_mode callback, calls netif_stop_queue() and netif_wake_queue(). These are TX queue flow control functions unrelated to RX multicast configuration.

The premature netif_wake_queue() can re-enable TX while tx_urb is still in-flight, leading to a double usb_submit_urb() on the same URB:

kaweth_start_xmit() { netif_stop_queue(); usb_submit_urb(kaweth->tx_urb); }

kaweth_set_rx_mode() { netif_stop_queue(); netif_wake_queue(); // wakes TX queue before URB is done }

kaweth_start_xmit() { netif_stop_queue(); usb_submit_urb(kaweth->tx_urb); // URB submitted while active }

This triggers the WARN in usb_submit_urb():

"URB submitted while active"

This is a similar class of bug fixed in rtl8150 by

commit 958baf5eaee3 ("net: usb: Remove disruptive netif_wake_queue in rtl8150_set_multicast").

Also kaweth_set_rx_mode() is already functionally broken, the real set_rx_mode action is performed by kaweth_async_set_rx_mode(), which in turn is not a no-op only at ndo_open() time.(CVE-2026-43180)

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

net: consume xmit errors of GSO frames

udpgro_frglist.sh and udpgro_bench.sh are the flakiest tests currently in NIPA. They fail in the same exact way, TCP GRO test stalls occasionally and the test gets killed after 10min.

These tests use veth to simulate GRO. They attach a trivial ("return XDP_PASS;") XDP program to the veth to force TSO off and NAPI on.

Digging into the failure mode we can see that the connection is completely stuck after a burst of drops. The sender's snd_nxt is at sequence number N [1], but the receiver claims to have received (rcv_nxt) up to N + 3 * MSS [2]. Last piece of the puzzle is that senders rtx queue is not empty (let's say the block in the rtx queue is at sequence number N - 4 * MSS [3]).

In this state, sender sends a retransmission from the rtx queue with a single segment, and sequence numbers N-4MSS:N-3MSS [3]. Receiver sees it and responds with an ACK all the way up to N + 3 * MSS [2]. But sender will reject this ack as TCP_ACK_UNSENT_DATA because it has no recollection of ever sending data that far out [1]. And we are stuck.

The root cause is the mess of the xmit return codes. veth returns an error when it can't xmit a frame. We end up with a loss event like this:

| GSO super frame 1 | GSO super frame 2 | |-----------------------------------------------| | seg | seg | seg | seg | seg | seg | seg | seg | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |

 x    ok    ok    &lt;ok&gt;|  ok    ok    ok   &lt;x&gt;
                      \\
           snd_nxt

"x" means packet lost by veth, and "ok" means it went thru. Since veth has TSO disabled in this test it sees individual segments. Segment 1 is on the retransmit queue and will be resent.

So why did the sender not advance snd_nxt even tho it clearly did send up to seg 8? tcp_write_xmit() interprets the return code from the core to mean that data has not been sent at all. Since TCP deals with GSO super frames, not individual segment the crux of the problem is that loss of a single segment can be interpreted as loss of all. TCP only sees the last return code for the last segment of the GSO frame (in <> brackets in the diagram above).

Of course for the problem to occur we need a setup or a device without a Qdisc. Otherwise Qdisc layer disconnects the protocol layer from the device errors completely.

We have multiple ways to fix this.

1) make veth not return an error when it lost a packet. While this is what I think we did in the past, the issue keeps reappearing and it's annoying to debug. The game of whack a mole is not great.

2) fix the damn return codes We only talk about NETDEV_TX_OK and NETDEV_TX_BUSY in the documentation, so maybe we should make the return code from ndo_start_xmit() a boolean. I like that the most, but perhaps some ancient, not-really-networking protocol would suffer.

3) make TCP ignore the errors It is not entirely clear to me what benefit TCP gets from interpreting the result of ip_queue_xmit()? Specifically once the connection is established and we're pushing data - packet loss is just packet loss?

4) this fix Ignore the rc in the Qdisc-less+GSO case, since it's unreliable. We already always return OK in the TCQ_F_CAN_BYPASS case. In the Qdisc-less case let's be a bit more conservative and only mask the GSO errors. This path is taken by non-IP-"networks" like CAN, MCTP etc, so we could regress some ancient thing. This is the simplest, but also maybe the hackiest fix?

Similar fix has been proposed by Eric in the past but never committed because original reporter was working with an OOT driver and wasn't providing feedback (see Link).(CVE-2026-43194)

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

tcp: fix potential race in tcp_v6_syn_recv_sock()

Code in tcp_v6_syn_recv_sock() after the call to tcp_v4_syn_recv_sock() is done too late.

After tcp_v4_syn_recv_sock(), the child socket is already visible from TCP ehash table and other cpus might use it.

Since newinet->pinet6 is still pointing to the listener ipv6_pinfo bad things can happen as syzbot found.

Move the problematic code in tcp_v6_mapped_child_init() and call this new helper from tcp_v4_syn_recv_sock() before the ehash insertion.

This allows the removal of one tcp_sync_mss(), since tcp_v4_syn_recv_sock() will call it with the correct context.(CVE-2026-43198)

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

net: Drop the lock in skb_may_tx_timestamp()

Drop the lock. Use READ_ONCE() to obtain the individual pointer. Add a matching WRITE_ONCE() where the pointer are cleared.(CVE-2026-43216)

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

vhost: move vdpa group bound check to vhost_vdpa

Remove duplication by consolidating these here. This reduces the posibility of a parent driver missing them.

While we're at it, fix a bug in vdpa_sim where a valid ASID can be assigned to a group equal to ngroups, causing an out of bound write.(CVE-2026-43248)

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

mm/page_alloc: clear page->private in free_pages_prepare()

KASAN: maybe wild-memory-access in range [0xdead000000000100-0xdead000000000107] RIP: 0010:__do_sys_swapoff+0x1151/0x1860

Fix this by clearing page->private in free_pages_prepare(), ensuring all freed pages have clean state regardless of previous use.(CVE-2026-43303)

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

Bluetooth: SMP: force responder MITM requirements before building the pairing response

smp_cmd_pairing_req() currently builds the pairing response from the initiator auth_req before enforcing the local BT_SECURITY_HIGH requirement. If the initiator omits SMP_AUTH_MITM, the response can also omit it even though the local side still requires MITM.

tk_request() then sees an auth value without SMP_AUTH_MITM and may select JUST_CFM, making method selection inconsistent with the pairing policy the responder already enforces.

When the local side requires HIGH security, first verify that MITM can be achieved from the IO capabilities and then force SMP_AUTH_MITM in the response in both rsp.auth_req and auth. This keeps the responder auth bits and later method selection aligned.(CVE-2026-43334)

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

net/mlx5e: RX, Fix XDP multi-buf frag counting for striding RQ

XDP multi-buf programs can modify the layout of the XDP buffer when the program calls bpf_xdp_pull_data() or bpf_xdp_adjust_tail(). The referenced commit in the fixes tag corrected the assumption in the mlx5 driver that the XDP buffer layout doesn't change during a program execution. However, this fix introduced another issue: the dropped fragments still need to be counted on the driver side to avoid page fragment reference counting issues.

The issue was discovered by the drivers/net/xdp.py selftest, more specifically the test_xdp_native_tx_mb: - The mlx5 driver allocates a page_pool page and initializes it with a frag counter of 64 (pp_ref_count=64) and the internal frag counter to 0. - The test sends one packet with no payload. - On RX (mlx5e_skb_from_cqe_mpwrq_nonlinear()), mlx5 configures the XDP buffer with the packet data starting in the first fragment which is the page mentioned above. - The XDP program runs and calls bpf_xdp_pull_data() which moves the header into the linear part of the XDP buffer. As the packet doesn't contain more data, the program drops the tail fragment since it no longer contains any payload (pp_ref_count=63). - mlx5 device skips counting this fragment. Internal frag counter remains 0. - mlx5 releases all 64 fragments of the page but page pp_ref_count is 63 => negative reference counting error.

Resulting splat during the test:

WARNING: CPU: 0 PID: 188225 at ./include/net/page_pool/helpers.h:297 mlx5e_page_release_fragmented.isra.0+0xbd/0xe0 [mlx5_core] Modules linked in: [...] CPU: 0 UID: 0 PID: 188225 Comm: ip Not tainted 6.18.0-rc7_for_upstream_min_debug_2025_12_08_11_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:mlx5e_page_release_fragmented.isra.0+0xbd/0xe0 [mlx5_core] [...] Call Trace: <TASK> mlx5e_free_rx_mpwqe+0x20a/0x250 [mlx5_core] mlx5e_dealloc_rx_mpwqe+0x37/0xb0 [mlx5_core] mlx5e_free_rx_descs+0x11a/0x170 [mlx5_core] mlx5e_close_rq+0x78/0xa0 [mlx5_core] mlx5e_close_queues+0x46/0x2a0 [mlx5_core] mlx5e_close_channel+0x24/0x90 [mlx5_core] mlx5e_close_channels+0x5d/0xf0 [mlx5_core] mlx5e_safe_switch_params+0x2ec/0x380 [mlx5_core] mlx5e_change_mtu+0x11d/0x490 [mlx5_core] mlx5e_change_nic_mtu+0x19/0x30 [mlx5_core] netif_set_mtu_ext+0xfc/0x240 do_setlink.isra.0+0x226/0x1100 rtnl_newlink+0x7a9/0xba0 rtnetlink_rcv_msg+0x220/0x3c0 netlink_rcv_skb+0x4b/0xf0 netlink_unicast+0x255/0x380 netlink_sendmsg+0x1f3/0x420 __sock_sendmsg+0x38/0x60 ____sys_sendmsg+0x1e8/0x240 ___sys_sendmsg+0x7c/0xb0 [...] __sys_sendmsg+0x5f/0xb0 do_syscall_64+0x55/0xc70

The problem applies for XDP_PASS as well which is handled in a different code path in the driver.

This patch fixes the issue by doing page frag counting on all the original XDP buffer fragments for all relevant XDP actions (XDP_TX , XDP_REDIRECT and XDP_PASS). This is basically reverting to the original counting before the commit in the fixes tag.

As frag_page is still pointing to the original tail, the nr_frags parameter to xdp_update_skb_frags_info() needs to be calculated in a different way to reflect the new nr_frags.(CVE-2026-43465)

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

net/mlx5e: Fix DMA FIFO desync on error CQE SQ recovery

In case of a TX error CQE, a recovery flow is triggered, mlx5e_reset_txqsq_cc_pc() resets dma_fifo_cc to 0 but not dma_fifo_pc, desyncing the DMA FIFO producer and consumer.

After recovery, the producer pushes new DMA entries at the old dma_fifo_pc, while the consumer reads from position 0. This causes us to unmap stale DMA addresses from before the recovery.

The DMA FIFO is a purely software construct with no HW counterpart. At the point of reset, all WQEs have been flushed so dma_fifo_cc is already equal to dma_fifo_pc. There is no need to reset either counter, similar to how skb_fifo pc/cc are untouched.

Remove the 'dma_fifo_cc = 0' reset.

This fixes the following WARNING: WARNING: CPU: 0 PID: 0 at drivers/iommu/dma-iommu.c:1240 iommu_dma_unmap_page+0x79/0x90 Modules linked in: mlx5_vdpa vringh vdpa bonding mlx5_ib mlx5_vfio_pci ipip mlx5_fwctl tunnel4 mlx5_core ib_ipoib geneve ip6_gre ip_gre gre nf_tables ip6_tunnel rdma_ucm ib_uverbs ib_umad vfio_pci vfio_pci_core act_mirred act_skbedit act_vlan vhost_net vhost tap ip6table_mangle ip6table_nat ip6table_filter ip6_tables iptable_mangle cls_matchall nfnetlink_cttimeout act_gact cls_flower sch_ingress vhost_iotlb iptable_raw tunnel6 vfio_iommu_type1 vfio openvswitch nsh rpcsec_gss_krb5 auth_rpcgss oid_registry xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat nf_nat xt_addrtype br_netfilter overlay zram zsmalloc rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm ib_core fuse [last unloaded: nf_tables] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5_for_upstream_min_debug_2024_12_30_21_33 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:iommu_dma_unmap_page+0x79/0x90 Code: 2b 4d 3b 21 72 26 4d 3b 61 08 73 20 49 89 d8 44 89 f9 5b 4c 89 f2 4c 89 e6 48 89 ef 5d 41 5c 41 5d 41 5e 41 5f e9 c7 ae 9e ff <0f> 0b 5b 5d 41 5c 41 5d 41 5e 41 5f c3 66 2e 0f 1f 84 00 00 00 00 Call Trace: <IRQ> ? __warn+0x7d/0x110 ? iommu_dma_unmap_page+0x79/0x90 ? report_bug+0x16d/0x180 ? handle_bug+0x4f/0x90 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? iommu_dma_unmap_page+0x79/0x90 ? iommu_dma_unmap_page+0x2e/0x90 dma_unmap_page_attrs+0x10d/0x1b0 mlx5e_tx_wi_dma_unmap+0xbe/0x120 [mlx5_core] mlx5e_poll_tx_cq+0x16d/0x690 [mlx5_core] mlx5e_napi_poll+0x8b/0xac0 [mlx5_core] __napi_poll+0x24/0x190 net_rx_action+0x32a/0x3b0 ? mlx5_eq_comp_int+0x7e/0x270 [mlx5_core] ? notifier_call_chain+0x35/0xa0 handle_softirqs+0xc9/0x270 irq_exit_rcu+0x71/0xd0 common_interrupt+0x7f/0xa0 </IRQ> <TASK> asm_common_interrupt+0x22/0x40(CVE-2026-43466)

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

ipvs: skip ipv6 extension headers for csum checks

Protocol checksum validation fails for IPv6 if there are extension headers before the protocol header. iph->len already contains its offset, so use it to fix the problem.(CVE-2026-45850)

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

apparmor: Fix & Optimize table creation from possibly unaligned memory

Source blob may come from userspace and might be unaligned. Try to optize the copying process by avoiding unaligned memory accesses.

Added Fixes tag
Added "Fix &" to description as this doesn't just optimize but fixes a potential unaligned memory access jj: remove duplicate word "convert" in comment trigger checkpatch warning

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

iommu/vt-d: Clear Present bit before tearing down PASID entry

Follow the "Guidance to Software for Invalidations" in the VT-d spec (Section 6.5.3.3) by implementing the recommended ownership handshake:

Clear only the 'Present' (P) bit of the PASID entry.
Use a dma_wmb() to ensure the cleared bit is visible to hardware before proceeding.
Execute the required invalidation sequence (PASID cache, IOTLB, and Device-TLB flush) to ensure the hardware has released all cached references.
Only after the flushes are complete, zero out the remaining fields of the PASID entry.

Also, add a dma_wmb() in pasid_set_present() to ensure that all other fields of the PASID entry are visible to the hardware before the Present bit is set.(CVE-2026-45894)

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

quota: fix livelock between quotactl and freeze_super

However, this retry loop can trigger a livelock issue, specifically on kernels with preemption disabled.

This results in a hang of the freezer process and 100% CPU usage by the quota process.

While this can occur intermittently on multi-core systems, it is reliably reproducing on a node with the following script, running both the freezer and the quota toggle on the same CPU:

Adding cond_resched() to the retry loop fixes the issue. It acts as an RCU quiescent state, allowing synchronize_rcu() in percpu_down_write() to complete.(CVE-2026-45895)

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

fat: avoid parent link count underflow in rmdir

Add a sanity check in vfat_rmdir() and msdos_rmdir(): only drop the parent link count when it is at least 3, otherwise report a filesystem error.(CVE-2026-45915)

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

ext4: fix dirtyclusters double decrement on fs shutdown

fstests test generic/388 occasionally reproduces a warning in ext4_put_super() associated with the dirty clusters count:

WARNING: CPU: 7 PID: 76064 at fs/ext4/super.c:1324 ext4_put_super+0x48c/0x590 [ext4]

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

iommu/vt-d: Clear Present bit before tearing down context entry

Align with the "Guidance to Software for Invalidations" in the VT-d spec (Section 6.5.3.3) by implementing the recommended ownership handshake:

Clear only the 'Present' (P) bit of the context entry first to signal the transition of ownership from hardware to software.
Use dma_wmb() to ensure the cleared bit is visible to the IOMMU.
Perform the required cache and context-cache invalidation to ensure hardware no longer has cached references to the entry.
Fully zero out the entry only after the invalidation is complete.

Also, add a dma_wmb() to context_set_present() to ensure the entry is fully initialized before the 'Present' bit becomes visible.(CVE-2026-45944)

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

hwrng: core - use RCU and work_struct to fix race condition

Currently, hwrng_fill is not cleared until the hwrng_fillfn() thread exits. Since hwrng_unregister() reads hwrng_fill outside the rng_mutex lock, a concurrent hwrng_unregister() may call kthread_stop() again on the same task.

Additionally, if hwrng_unregister() is called immediately after hwrng_register(), the stopped thread may have never been executed. Thus, hwrng_fill remains dirty even after hwrng_unregister() returns. In this case, subsequent calls to hwrng_register() will fail to start new threads, and hwrng_unregister() will call kthread_stop() on the same freed task. In both cases, a use-after-free occurs:

refcount_t: addition on 0; use-after-free. WARNING: ... at lib/refcount.c:25 refcount_warn_saturate+0xec/0x1c0 Call Trace: kthread_stop+0x181/0x360 hwrng_unregister+0x288/0x380 virtrng_remove+0xe3/0x200

This patch fixes the race by protecting the global hwrng_fill pointer inside the rng_mutex lock, so that hwrng_fillfn() thread is stopped only once, and calls to kthread_run() and kthread_stop() are serialized with the lock held.

To avoid deadlock in hwrng_fillfn() while being stopped with the lock held, we convert current_rng to RCU, so that get_current_rng() can read current_rng without holding the lock. To remove the lock from put_rng(), we also delay the actual cleanup into a work_struct.

Since get_current_rng() no longer returns ERR_PTR values, the IS_ERR() checks are removed from its callers.

With hwrng_fill protected by the rng_mutex lock, hwrng_fillfn() can no longer clear hwrng_fill itself. Therefore, if hwrng_fillfn() returns directly after current_rng is dropped, kthread_stop() would be called on a freed task_struct later. To fix this, hwrng_fillfn() calls schedule() now to keep the task alive until being stopped. The kthread_stop() call is also moved from hwrng_unregister() to drop_current_rng(), ensuring kthread_stop() is called on all possible paths where current_rng becomes NULL, so that the thread would not wait forever.(CVE-2026-45949)

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

cpuidle: Skip governor when only one idle state is available

Fix this by adding a bail-out in cpuidle_select() that returns state 0 directly when state_count <= 1, bypassing the governor and keeping the tick running.(CVE-2026-45968)

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

RDMA/mlx5: Fix UMR hang in LAG error state unload

During firmware reset in LAG mode, a race condition causes the driver to hang indefinitely while waiting for UMR completion during device unload. See [1].

In LAG mode the bond device is only registered on the master, so it never sees sys_error events from the slave. During firmware reset this causes UMR waits to hang forever on unload as the slave is dead but the master hasn't entered error state yet, so UMR posts succeed but completions never arrive.

Fix this by adding a sys_error notifier that gets registered before MLX5_IB_STAGE_IB_REG and stays alive until after ib_unregister_device(). This ensures error events reach the bond device throughout teardown.

[1] Call Trace: __schedule+0x2bd/0x760 schedule+0x37/0xa0 schedule_preempt_disabled+0xa/0x10 __mutex_lock.isra.6+0x2b5/0x4a0 __mlx5_ib_dereg_mr+0x606/0x870 [mlx5_ib] ? __xa_erase+0x4a/0xa0 ? _cond_resched+0x15/0x30 ? wait_for_completion+0x31/0x100 ib_dereg_mr_user+0x48/0xc0 [ib_core] ? rdmacg_uncharge_hierarchy+0xa0/0x100 destroy_hw_idr_uobject+0x20/0x50 [ib_uverbs] uverbs_destroy_uobject+0x37/0x150 [ib_uverbs] __uverbs_cleanup_ufile+0xda/0x140 [ib_uverbs] uverbs_destroy_ufile_hw+0x3a/0xf0 [ib_uverbs] ib_uverbs_remove_one+0xc3/0x140 [ib_uverbs] remove_client_context+0x8b/0xd0 [ib_core] disable_device+0x8c/0x130 [ib_core] __ib_unregister_device+0x10d/0x180 [ib_core] ib_unregister_device+0x21/0x30 [ib_core] __mlx5_ib_remove+0x1e4/0x1f0 [mlx5_ib] auxiliary_bus_remove+0x1e/0x30 device_release_driver_internal+0x103/0x1f0 bus_remove_device+0xf7/0x170 device_del+0x181/0x410 mlx5_rescan_drivers_locked.part.10+0xa9/0x1d0 [mlx5_core] mlx5_disable_lag+0x253/0x260 [mlx5_core] mlx5_lag_disable_change+0x89/0xc0 [mlx5_core] mlx5_eswitch_disable+0x67/0xa0 [mlx5_core] mlx5_unload+0x15/0xd0 [mlx5_core] mlx5_unload_one+0x71/0xc0 [mlx5_core] mlx5_sync_reset_reload_work+0x83/0x100 [mlx5_core] process_one_work+0x1a7/0x360 worker_thread+0x30/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x116/0x130 ? kthread_flush_work_fn+0x10/0x10 ret_from_fork+0x22/0x40(CVE-2026-45973)

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

gfs2: Fix use-after-free in iomap inline data write path

The inline data buffer head (dibh) is being released prematurely in gfs2_iomap_begin() via release_metapath() while iomap->inline_data still points to dibh->b_data. This causes a use-after-free when iomap_write_end_inline() later attempts to write to the inline data area.

The bug sequence: 1. gfs2_iomap_begin() calls gfs2_meta_inode_buffer() to read inode metadata into dibh 2. Sets iomap->inline_data = dibh->b_data + sizeof(struct gfs2_dinode) 3. Calls release_metapath() which calls brelse(dibh), dropping refcount to 0 4. kswapd reclaims the page (~39ms later in the syzbot report) 5. iomap_write_end_inline() tries to memcpy() to iomap->inline_data 6. KASAN detects use-after-free write to freed memory

Fix by storing dibh in iomap->private and incrementing its refcount with get_bh() in gfs2_iomap_begin(). The buffer is then properly released in gfs2_iomap_end() after the inline write completes, ensuring the page stays alive for the entire iomap operation.

Note: A C reproducer is not available for this issue. The fix is based on analysis of the KASAN report and code review showing the buffer head is freed before use.

agruenba: Take buffer head reference in gfs2_iomap_begin() to avoid leaks in gfs2_iomap_get() and gfs2_iomap_alloc().

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

drm/nouveau: fix u32 overflow in pushbuf reloc bounds check

nouveau_gem_pushbuf_reloc_apply() validates each relocation with

if (r-&gt;reloc_bo_offset + 4 &gt; nvbo-&gt;bo.base.size)

but reloc_bo_offset is __u32 (uapi/drm/nouveau_drm.h) and the integer literal 4 promotes to unsigned int, so the addition is performed in 32 bits and wraps before the comparison against the size_t bo size.

Cast to u64 so the addition happens in 64-bit arithmetic.

Add Fixes: tag. - Danilo

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

thermal: core: Fix thermal zone governor cleanup issues

If thermal_zone_device_register_with_trips() fails after adding a thermal governor to the thermal zone being registered, the governor is not removed from it as appropriate which may lead to a memory leak.

In turn, thermal_zone_device_unregister() calls thermal_set_governor() without acquiring the thermal zone lock beforehand which may race with a governor update via sysfs and may lead to a use-after-free in that case.

Address these issues by adding two thermal_set_governor() calls, one to thermal_release() to remove the governor from the given thermal zone, and one to the thermal zone registration error path to cover failures preceding the thermal zone device registration.(CVE-2026-46021)

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

KVM: nSVM: Triple fault if restore host CR3 fails on nested #VMEXIT

From the APM:

Upon #VMEXIT, the processor performs the following actions in order to return to the host execution context:

...

if (illegal host state loaded, or exception while loading host state) shutdown else execute first host instruction following the VMRUN

Remove the return value of nested_svm_vmexit(), which is mostly unchecked anyway.(CVE-2026-46032)

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

crypto: authencesn - reject short ahash digests during instance creation

authencesn requires either a zero authsize or an authsize of at least 4 bytes because the ESN encrypt/decrypt paths always move 4 bytes of high-order sequence number data at the end of the authenticated data.

While crypto_authenc_esn_setauthsize() already rejects explicit non-zero authsizes in the range 1..3, crypto_authenc_esn_create() still copied auth->digestsize into inst->alg.maxauthsize without validating it. The AEAD core then initialized the tfm's default authsize from that value.

As a result, selecting an ahash with digest size 1..3, such as cbcmac(cipher_null), exposed authencesn instances whose default authsize was invalid even though setauthsize() would have rejected the same value. AF_ALG could then trigger the ESN tail handling with a too-short tag and hit an out-of-bounds access.

Reject authencesn instances whose ahash digest size is in the invalid non-zero range 1..3 so that no tfm can inherit an unsupported default authsize.(CVE-2026-46033)

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

ceph: only d_add() negative dentries when they are unhashed

Ceph can call d_add(dentry, NULL) on a negative dentry that is already present in the primary dcache hash.

In the current VFS that is not safe. d_add() goes through __d_add() to __d_rehash(), which unconditionally reinserts dentry->d_hash into the hlist_bl bucket. If the dentry is already hashed, reinserting the same node can corrupt the bucket, including creating a self-loop. Once that happens, __d_lookup() can spin forever in the hlist_bl walk, typically looping only on the d_name.hash mismatch check and eventually triggering RCU stall reports like this one:

rcu: INFO: rcu_sched self-detected stall on CPU rcu: 87-....: (2100 ticks this GP) idle=3a4c/1/0x4000000000000000 softirq=25003319/25003319 fqs=829 rcu: (t=2101 jiffies g=79058445 q=698988 ncpus=192) CPU: 87 UID: 2952868916 PID: 3933303 Comm: php-cgi8.3 Not tainted 6.18.17-i1-amd #950 NONE Hardware name: Dell Inc. PowerEdge R7615/0G9DHV, BIOS 1.6.6 09/22/2023 RIP: 0010:__d_lookup+0x46/0xb0 Code: c1 e8 07 48 8d 04 c2 48 8b 00 49 89 fc 49 89 f5 48 89 c3 48 83 e3 fe 48 83 f8 01 77 0f eb 2d 0f 1f 44 00 00 48 8b 1b 48 85 db <74> 20 39 6b 18 75 f3 48 8d 7b 78 e8 ba 85 d0 00 4c 39 63 10 74 1f RSP: 0018:ff745a70c8253898 EFLAGS: 00000282 RAX: ff26e470054cb208 RBX: ff26e470054cb208 RCX: 000000006e958966 RDX: ff26e48267340000 RSI: ff745a70c82539b0 RDI: ff26e458f74655c0 RBP: 000000006e958966 R08: 0000000000000180 R09: 9cd08d909b919a89 R10: ff26e458f74655c0 R11: 0000000000000000 R12: ff26e458f74655c0 R13: ff745a70c82539b0 R14: d0d0d0d0d0d0d0d0 R15: 2f2f2f2f2f2f2f2f FS: 00007f5770896980(0000) GS:ff26e482c5d88000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f5764de50c0 CR3: 000000a72abb5001 CR4: 0000000000771ef0 PKRU: 55555554 Call Trace: <TASK> lookup_fast+0x9f/0x100 walk_component+0x1f/0x150 link_path_walk+0x20e/0x3d0 path_lookupat+0x68/0x180 filename_lookup+0xdc/0x1e0 vfs_statx+0x6c/0x140 vfs_fstatat+0x67/0xa0 __do_sys_newfstatat+0x24/0x60 do_syscall_64+0x6a/0x230 entry_SYSCALL_64_after_hwframe+0x76/0x7e

This is reachable with reused cached negative dentries. A Ceph lookup or atomic_open can be handed a negative dentry that is already hashed, and fs/ceph/dir.c then hits one of two paths that incorrectly assume "negative" also means "unhashed":

ceph_finish_lookup(): MDS reply is -ENOENT with no trace -> d_add(dentry, NULL)
ceph_lookup(): local ENOENT fast path for a complete directory with shared caps -> d_add(dentry, NULL)

Both paths can therefore re-add an already-hashed negative dentry.

Ceph already uses the correct pattern elsewhere: ceph_fill_trace() only calls d_add(dn, NULL) for a negative null-dentry reply when d_unhashed(dn) is true.

Fix both fs/ceph/dir.c sites the same way: only call d_add() for a negative dentry when it is actually unhashed. If the negative dentry is already hashed, leave it in place and reuse it as-is.

This preserves the existing behavior for unhashed dentries while avoiding d_hash list corruption for reused hashed negatives.(CVE-2026-46052)

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

fbdev: defio: Disconnect deferred I/O from the lifetime of struct fb_info

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

eventpoll: fix ep_remove struct eventpoll / struct file UAF

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-2025-39781	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2025-71109	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-23213	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-23214	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-31527	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-31607	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-31662	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-31709	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-31759	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43024	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43038	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43059	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43083	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43088	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43089	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43101	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43107	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43180	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43194	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43198	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43216	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43248	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43303	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43334	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43465	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-43466	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-45850	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-45893	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-45894	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-45895	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-45915	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-45920	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-45944	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-45949	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-45968	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-45973	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-45984	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-46006	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-46021	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-46032	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-46033	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-46052	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-46065	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-46153	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-46242	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-46245	ADVISORY

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-6.6.0-145.3.15.146.oe2403sp3.aarch64.rpm",
          "bpftool-debuginfo-6.6.0-145.3.15.146.oe2403sp3.aarch64.rpm",
          "kernel-6.6.0-145.3.15.146.oe2403sp3.aarch64.rpm",
          "kernel-debuginfo-6.6.0-145.3.15.146.oe2403sp3.aarch64.rpm",
          "kernel-debugsource-6.6.0-145.3.15.146.oe2403sp3.aarch64.rpm",
          "kernel-devel-6.6.0-145.3.15.146.oe2403sp3.aarch64.rpm",
          "kernel-extra-modules-6.6.0-145.3.15.146.oe2403sp3.aarch64.rpm",
          "kernel-headers-6.6.0-145.3.15.146.oe2403sp3.aarch64.rpm",
          "kernel-source-6.6.0-145.3.15.146.oe2403sp3.aarch64.rpm",
          "kernel-tools-6.6.0-145.3.15.146.oe2403sp3.aarch64.rpm",
          "kernel-tools-debuginfo-6.6.0-145.3.15.146.oe2403sp3.aarch64.rpm",
          "kernel-tools-devel-6.6.0-145.3.15.146.oe2403sp3.aarch64.rpm",
          "perf-6.6.0-145.3.15.146.oe2403sp3.aarch64.rpm",
          "perf-debuginfo-6.6.0-145.3.15.146.oe2403sp3.aarch64.rpm",
          "python3-perf-6.6.0-145.3.15.146.oe2403sp3.aarch64.rpm",
          "python3-perf-debuginfo-6.6.0-145.3.15.146.oe2403sp3.aarch64.rpm"
        ],
        "src": [
          "kernel-6.6.0-145.3.15.146.oe2403sp3.src.rpm"
        ],
        "x86_64": [
          "bpftool-6.6.0-145.3.15.146.oe2403sp3.x86_64.rpm",
          "bpftool-debuginfo-6.6.0-145.3.15.146.oe2403sp3.x86_64.rpm",
          "kernel-6.6.0-145.3.15.146.oe2403sp3.x86_64.rpm",
          "kernel-debuginfo-6.6.0-145.3.15.146.oe2403sp3.x86_64.rpm",
          "kernel-debugsource-6.6.0-145.3.15.146.oe2403sp3.x86_64.rpm",
          "kernel-devel-6.6.0-145.3.15.146.oe2403sp3.x86_64.rpm",
          "kernel-extra-modules-6.6.0-145.3.15.146.oe2403sp3.x86_64.rpm",
          "kernel-headers-6.6.0-145.3.15.146.oe2403sp3.x86_64.rpm",
          "kernel-source-6.6.0-145.3.15.146.oe2403sp3.x86_64.rpm",
          "kernel-tools-6.6.0-145.3.15.146.oe2403sp3.x86_64.rpm",
          "kernel-tools-debuginfo-6.6.0-145.3.15.146.oe2403sp3.x86_64.rpm",
          "kernel-tools-devel-6.6.0-145.3.15.146.oe2403sp3.x86_64.rpm",
          "perf-6.6.0-145.3.15.146.oe2403sp3.x86_64.rpm",
          "perf-debuginfo-6.6.0-145.3.15.146.oe2403sp3.x86_64.rpm",
          "python3-perf-6.6.0-145.3.15.146.oe2403sp3.x86_64.rpm",
          "python3-perf-debuginfo-6.6.0-145.3.15.146.oe2403sp3.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:24.03-LTS-SP3",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-24.03-LTS-SP3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.6.0-145.3.15.146.oe2403sp3"
            }
          ],
          "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\nparisc: Drop WARN_ON_ONCE() from flush_cache_vmap\n\nI have observed warning to occassionally trigger.(CVE-2025-39781)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nMIPS: ftrace: Fix memory corruption when kernel is located beyond 32 bits\n\nSince commit e424054000878 (\u0026quot;MIPS: Tracing: Reduce the overhead of\ndynamic Function Tracer\u0026quot;), the macro UASM_i_LA_mostly has been used,\nand this macro can generate more than 2 instructions. At the same\ntime, the code in ftrace assumes that no more than 2 instructions can\nbe generated, which is why it stores them in an int[2] array. However,\nas previously noted, the macro UASM_i_LA_mostly (and now UASM_i_LA)\ncauses a buffer overflow when _mcount is beyond 32 bits. This leads to\ncorruption of the variables located in the __read_mostly section.\n\nThis corruption was observed because the variable\n__cpu_primary_thread_mask was corrupted, causing a hang very early\nduring boot.\n\nThis fix prevents the corruption by avoiding the generation of\ninstructions if they could exceed 2 instructions in\nlength. Fortunately, insn_la_mcount is only used if the instrumented\ncode is located outside the kernel code section, so dynamic ftrace can\nstill be used, albeit in a more limited scope. This is still\npreferable to corrupting memory and/or crashing the kernel.(CVE-2025-71109)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/pm: Disable MMIO access during SMU Mode 1 reset\n\nDuring Mode 1 reset, the ASIC undergoes a reset cycle and becomes\ntemporarily inaccessible via PCIe. Any attempt to access MMIO registers\nduring this window (e.g., from interrupt handlers or other driver threads)\ncan result in uncompleted PCIe transactions, leading to NMI panics or\nsystem hangs.\n\nTo prevent this, set the `no_hw_access` flag to true immediately after\ntriggering the reset. This signals other driver components to skip\nregister accesses while the device is offline.\n\nA memory barrier `smp_mb()` is added to ensure the flag update is\nglobally visible to all cores before the driver enters the sleep/wait\nstate.\n\n(cherry picked from commit 7edb503fe4b6d67f47d8bb0dfafb8e699bb0f8a4)(CVE-2026-23213)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: reject new transactions if the fs is fully read-only\n\n[BUG]\nThere is a bug report where a heavily fuzzed fs is mounted with all\nrescue mount options, which leads to the following warnings during\nunmount:\n\n  BTRFS: Transaction aborted (error -22)\n  Modules linked in:\n  CPU: 0 UID: 0 PID: 9758 Comm: repro.out Not tainted\n  6.19.0-rc5-00002-gb71e635feefc #7 PREEMPT(full)\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\n  RIP: 0010:find_free_extent_update_loop fs/btrfs/extent-tree.c:4208 [inline]\n  RIP: 0010:find_free_extent+0x52f0/0x5d20 fs/btrfs/extent-tree.c:4611\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   btrfs_reserve_extent+0x2cd/0x790 fs/btrfs/extent-tree.c:4705\n   btrfs_alloc_tree_block+0x1e1/0x10e0 fs/btrfs/extent-tree.c:5157\n   btrfs_force_cow_block+0x578/0x2410 fs/btrfs/ctree.c:517\n   btrfs_cow_block+0x3c4/0xa80 fs/btrfs/ctree.c:708\n   btrfs_search_slot+0xcad/0x2b50 fs/btrfs/ctree.c:2130\n   btrfs_truncate_inode_items+0x45d/0x2350 fs/btrfs/inode-item.c:499\n   btrfs_evict_inode+0x923/0xe70 fs/btrfs/inode.c:5628\n   evict+0x5f4/0xae0 fs/inode.c:837\n   __dentry_kill+0x209/0x660 fs/dcache.c:670\n   finish_dput+0xc9/0x480 fs/dcache.c:879\n   shrink_dcache_for_umount+0xa0/0x170 fs/dcache.c:1661\n   generic_shutdown_super+0x67/0x2c0 fs/super.c:621\n   kill_anon_super+0x3b/0x70 fs/super.c:1289\n   btrfs_kill_super+0x41/0x50 fs/btrfs/super.c:2127\n   deactivate_locked_super+0xbc/0x130 fs/super.c:474\n   cleanup_mnt+0x425/0x4c0 fs/namespace.c:1318\n   task_work_run+0x1d4/0x260 kernel/task_work.c:233\n   exit_task_work include/linux/task_work.h:40 [inline]\n   do_exit+0x694/0x22f0 kernel/exit.c:971\n   do_group_exit+0x21c/0x2d0 kernel/exit.c:1112\n   __do_sys_exit_group kernel/exit.c:1123 [inline]\n   __se_sys_exit_group kernel/exit.c:1121 [inline]\n   __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1121\n   x64_sys_call+0x2210/0x2210 arch/x86/include/generated/asm/syscalls_64.h:232\n   do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n   do_syscall_64+0xe8/0xf80 arch/x86/entry/syscall_64.c:94\n   entry_SYSCALL_64_after_hwframe+0x77/0x7f\n  RIP: 0033:0x44f639\n  Code: Unable to access opcode bytes at 0x44f60f.\n  RSP: 002b:00007ffc15c4e088 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7\n  RAX: ffffffffffffffda RBX: 00000000004c32f0 RCX: 000000000044f639\n  RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001\n  RBP: 0000000000000001 R08: ffffffffffffffc0 R09: 0000000000000000\n  R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004c32f0\n  R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001\n   \u0026lt;/TASK\u0026gt;\n\nSince rescue mount options will mark the full fs read-only, there should\nbe no new transaction triggered.\n\nBut during unmount we will evict all inodes, which can trigger a new\ntransaction, and triggers warnings on a heavily corrupted fs.\n\n[CAUSE]\nBtrfs allows new transaction even on a read-only fs, this is to allow\nlog replay happen even on read-only mounts, just like what ext4/xfs do.\n\nHowever with rescue mount options, the fs is fully read-only and cannot\nbe remounted read-write, thus in that case we should also reject any new\ntransactions.\n\n[FIX]\nIf we find the fs has rescue mount options, we should treat the fs as\nerror, so that no new transaction can be started.(CVE-2026-23214)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndriver core: platform: use generic driver_override infrastructure\n\nWhen a driver is probed through __driver_attach(), the bus\u0026apos; match()\ncallback is called without the device lock held, thus accessing the\ndriver_override field without a lock, which can cause a UAF.\n\nFix this by using the driver-core driver_override infrastructure taking\ncare of proper locking internally.\n\nNote that calling match() from __driver_attach() without the device lock\nheld is intentional. [1](CVE-2026-31527)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusbip: validate number_of_packets in usbip_pack_ret_submit()\n\nWhen a USB/IP client receives a RET_SUBMIT response,\nusbip_pack_ret_submit() unconditionally overwrites\nurb-\u0026gt;number_of_packets from the network PDU. This value is\nsubsequently used as the loop bound in usbip_recv_iso() and\nusbip_pad_iso() to iterate over urb-\u0026gt;iso_frame_desc[], a flexible\narray whose size was fixed at URB allocation time based on the\n*original* number_of_packets from the CMD_SUBMIT.\n\nA malicious USB/IP server can set number_of_packets in the response\nto a value larger than what was originally submitted, causing a heap\nout-of-bounds write when usbip_recv_iso() writes to\nurb-\u0026gt;iso_frame_desc[i] beyond the allocated region.\n\nKASAN confirmed this with kernel 7.0.0-rc5:\n\n  BUG: KASAN: slab-out-of-bounds in usbip_recv_iso+0x46a/0x640\n  Write of size 4 at addr ffff888106351d40 by task vhci_rx/69\n\n  The buggy address is located 0 bytes to the right of\n   allocated 320-byte region [ffff888106351c00, ffff888106351d40)\n\nThe server side (stub_rx.c) and gadget side (vudc_rx.c) already\nvalidate number_of_packets in the CMD_SUBMIT path since commits\nc6688ef9f297 (\u0026quot;usbip: fix stub_rx: harden CMD_SUBMIT path to handle\nmalicious input\u0026quot;) and b78d830f0049 (\u0026quot;usbip: fix vudc_rx: harden\nCMD_SUBMIT path to handle malicious input\u0026quot;). The server side validates\nagainst USBIP_MAX_ISO_PACKETS because no URB exists yet at that point.\nOn the client side we have the original URB, so we can use the tighter\nbound: the response must not exceed the original number_of_packets.\n\nThis mirrors the existing validation of actual_length against\ntransfer_buffer_length in usbip_recv_xbuff(), which checks the\nresponse value against the original allocation size.\n\nKelvin Mbogo\u0026apos;s series (\u0026quot;usb: usbip: fix integer overflow in\nusbip_recv_iso()\u0026quot;, v2) hardens the receive-side functions themselves;\nthis patch complements that work by catching the bad value at its\nsource -- in usbip_pack_ret_submit() before the overwrite -- and\nusing the tighter per-URB allocation bound rather than the global\nUSBIP_MAX_ISO_PACKETS limit.\n\nFix this by checking rpdu-\u0026gt;number_of_packets against\nurb-\u0026gt;number_of_packets in usbip_pack_ret_submit() before the\noverwrite. On violation, clamp to zero so that usbip_recv_iso() and\nusbip_pad_iso() safely return early.(CVE-2026-31607)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntipc: fix bc_ackers underflow on duplicate GRP_ACK_MSG\n\nThe GRP_ACK_MSG handler in tipc_group_proto_rcv() currently decrements\nbc_ackers on every inbound group ACK, even when the same member has\nalready acknowledged the current broadcast round.\n\nBecause bc_ackers is a u16, a duplicate ACK received after the last\nlegitimate ACK wraps the counter to 65535. Once wrapped,\ntipc_group_bc_cong() keeps reporting congestion and later group\nbroadcasts on the affected socket stay blocked until the group is\nrecreated.\n\nFix this by ignoring duplicate or stale ACKs before touching bc_acked or\nbc_ackers. This makes repeated GRP_ACK_MSG handling idempotent and\nprevents the underflow path.(CVE-2026-31662)\n\nIn the Linux kernel, the following vulnerability has been resolved: smb: client: validate the whole DACL before rewriting it in cifsacl. build_sec_desc() and id_mode_to_cifs_acl() derive a DACL pointer from a server-supplied dacloffset and then use the incoming ACL to rebuild the chmod/chown security descriptor. The original fix only checked that the struct smb_acl header fits before reading dacl_ptr-\u0026gt;size or dacl_ptr-\u0026gt;num_aces. That avoids the immediate header-field OOB read, but the rewrite helpers still walk ACEs based on pdacl-\u0026gt;num_aces with no structural validation of the incoming DACL body. A malicious server can return a truncated DACL that still contains a header, claims one or more ACEs, and then drive replace_sids_and_copy_aces() or set_chmod_dacl() past the validated extent while they compare or copy attacker-controlled ACEs.(CVE-2026-31709)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nusb: ulpi: fix double free in ulpi_register_interface() error path\n\nWhen device_register() fails, ulpi_register() calls put_device() on\nulpi-\u0026gt;dev.\n\nThe device release callback ulpi_dev_release() drops the OF node\nreference and frees ulpi, but the current error path in\nulpi_register_interface() then calls kfree(ulpi) again, causing a\ndouble free.\n\nLet put_device() handle the cleanup through ulpi_dev_release() and\navoid freeing ulpi again in ulpi_register_interface().(CVE-2026-31759)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: reject immediate NF_QUEUE verdict\n\nnft_queue is always used from userspace nftables to deliver the NF_QUEUE\nverdict. Immediately emitting an NF_QUEUE verdict is never used by the\nuserspace nft tools, so reject immediate NF_QUEUE verdicts.\n\nThe arp family does not provide queue support, but such an immediate\nverdict is still reachable. Globally reject NF_QUEUE immediate verdicts\nto address this issue.(CVE-2026-43024)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: icmp: clear skb2-\u0026gt;cb[] in ip6_err_gen_icmpv6_unreach()\n\nSashiko AI-review observed:\n\n  In ip6_err_gen_icmpv6_unreach(), the skb is an outer IPv4 ICMP error packet\n  where its cb contains an IPv4 inet_skb_parm. When skb is cloned into skb2\n  and passed to icmp6_send(), it uses IP6CB(skb2).\n\n  IP6CB interprets the IPv4 inet_skb_parm as an inet6_skb_parm. The cipso\n  offset in inet_skb_parm.opt directly overlaps with dsthao in inet6_skb_parm\n  at offset 18.\n\n  If an attacker sends a forged ICMPv4 error with a CIPSO IP option, dsthao\n  would be a non-zero offset. Inside icmp6_send(), mip6_addr_swap() is called\n  and uses ipv6_find_tlv(skb, opt-\u0026gt;dsthao, IPV6_TLV_HAO).\n\n  This would scan the inner, attacker-controlled IPv6 packet starting at that\n  offset, potentially returning a fake TLV without checking if the remaining\n  packet length can hold the full 18-byte struct ipv6_destopt_hao.\n\n  Could mip6_addr_swap() then perform a 16-byte swap that extends past the end\n  of the packet data into skb_shared_info?\n\n  Should the cb array also be cleared in ip6_err_gen_icmpv6_unreach() and\n  ip6ip6_err() to prevent this?\n\nThis patch implements the first suggestion.\n\nI am not sure if ip6ip6_err() needs to be changed.\nA separate patch would be better anyway.(CVE-2026-43038)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: MGMT: Fix list corruption and UAF in command complete handlers\n\nCommit 302a1f674c00 (\u0026quot;Bluetooth: MGMT: Fix possible UAFs\u0026quot;) introduced\nmgmt_pending_valid(), which not only validates the pending command but\nalso unlinks it from the pending list if it is valid. This change in\nsemantics requires updates to several completion handlers to avoid list\ncorruption and memory safety issues.\n\nThis patch addresses two left-over issues from the aforementioned rework:\n\n1. In mgmt_add_adv_patterns_monitor_complete(), mgmt_pending_remove()\nis replaced with mgmt_pending_free() in the success path. Since\nmgmt_pending_valid() already unlinks the command at the beginning of\nthe function, calling mgmt_pending_remove() leads to a double list_del()\nand subsequent list corruption/kernel panic.\n\n2. In set_mesh_complete(), the use of mgmt_pending_foreach() in the error\npath is removed. Since the current command is already unlinked by\nmgmt_pending_valid(), this foreach loop would incorrectly target other\npending mesh commands, potentially freeing them while they are still being\nprocessed concurrently (leading to UAFs). The redundant mgmt_cmd_status()\nis also simplified to use cmd-\u0026gt;opcode directly.(CVE-2026-43059)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: ioam6: fix OOB and missing lock\n\nWhen trace-\u0026gt;type.bit6 is set:\n\n    if (trace-\u0026gt;type.bit6) {\n        ...\n        queue = skb_get_tx_queue(dev, skb);\n        qdisc = rcu_dereference(queue-\u0026gt;qdisc);\n\nThis code can lead to an out-of-bounds access of the dev-\u0026gt;_tx[] array\nwhen is_input is true. In such a case, the packet is on the RX path and\nskb-\u0026gt;queue_mapping contains the RX queue index of the ingress device. If\nthe ingress device has more RX queues than the egress device (dev) has\nTX queues, skb_get_queue_mapping(skb) will exceed dev-\u0026gt;num_tx_queues.\nAdd a check to avoid this situation since skb_get_tx_queue() does not\nclamp the index. This issue has also revealed that per queue visibility\ncannot be accurate and will be replaced later as a new feature.\n\nWhile at it, add missing lock around qdisc_qstats_qlen_backlog(). The\nfunction __ioam6_fill_trace_data() is called from both softirq and\nprocess contexts, hence the use of spin_lock_bh() here.(CVE-2026-43083)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: af_key: zero aligned sockaddr tail in PF_KEY exports\n\nPF_KEY export paths use `pfkey_sockaddr_size()` when reserving sockaddr\npayload space, so IPv6 addresses occupy 32 bytes on the wire. However,\n`pfkey_sockaddr_fill()` initializes only the first 28 bytes of\n`struct sockaddr_in6`, leaving the final 4 aligned bytes uninitialized.\n\nNot every PF_KEY message is affected. The state and policy dump builders\nalready zero the whole message buffer before filling the sockaddr\npayloads. Keep the fix to the export paths that still append aligned\nsockaddr payloads with plain `skb_put()`:\n\n  - `SADB_ACQUIRE`\n  - `SADB_X_NAT_T_NEW_MAPPING`\n  - `SADB_X_MIGRATE`\n\nFix those paths by clearing only the aligned sockaddr tail after\n`pfkey_sockaddr_fill()`.(CVE-2026-43088)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm_user: fix info leak in build_mapping()\n\nstruct xfrm_usersa_id has a one-byte padding hole after the proto\nfield, which ends up never getting set to zero before copying out to\nuserspace.  Fix that up by zeroing out the whole structure before\nsetting individual variables.(CVE-2026-43089)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipv6: ioam: fix potential NULL dereferences in __ioam6_fill_trace_data()\n\nWe need to check __in6_dev_get() for possible NULL value, as\nsuggested by Yiming Qian.\n\nAlso add skb_dst_dev_rcu() instead of skb_dst_dev(),\nand two missing READ_ONCE().\n\nNote that @dev can\u0026apos;t be NULL.(CVE-2026-43101)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: account XFRMA_IF_ID in aevent size calculation\n\nxfrm_get_ae() allocates the reply skb with xfrm_aevent_msgsize(), then\nbuild_aevent() appends attributes including XFRMA_IF_ID when x-\u0026gt;if_id is\nset.\n\nxfrm_aevent_msgsize() does not include space for XFRMA_IF_ID. For states\nwith if_id, build_aevent() can fail with -EMSGSIZE and hit BUG_ON(err \u0026lt; 0)\nin xfrm_get_ae(), turning a malformed netlink interaction into a kernel\npanic.\n\nAccount XFRMA_IF_ID in the size calculation unconditionally and replace\nthe BUG_ON with normal error unwinding.(CVE-2026-43107)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: kaweth: remove TX queue manipulation in kaweth_set_rx_mode\n\nkaweth_set_rx_mode(), the ndo_set_rx_mode callback, calls\nnetif_stop_queue() and netif_wake_queue(). These are TX queue flow\ncontrol functions unrelated to RX multicast configuration.\n\nThe premature netif_wake_queue() can re-enable TX while tx_urb is still\nin-flight, leading to a double usb_submit_urb() on the same URB:\n\nkaweth_start_xmit() {\n    netif_stop_queue();\n    usb_submit_urb(kaweth-\u0026gt;tx_urb);\n}\n\nkaweth_set_rx_mode() {\n    netif_stop_queue();\n    netif_wake_queue();             // wakes TX queue before URB is done\n}\n\nkaweth_start_xmit() {\n    netif_stop_queue();\n    usb_submit_urb(kaweth-\u0026gt;tx_urb); // URB submitted while active\n}\n\nThis triggers the WARN in usb_submit_urb():\n\n  \u0026quot;URB submitted while active\u0026quot;\n\nThis is a similar class of bug fixed in rtl8150 by\n\n- commit 958baf5eaee3 (\u0026quot;net: usb: Remove disruptive netif_wake_queue in rtl8150_set_multicast\u0026quot;).\n\nAlso kaweth_set_rx_mode() is already functionally broken, the\nreal set_rx_mode action is performed by kaweth_async_set_rx_mode(),\nwhich in turn is not a no-op only at ndo_open() time.(CVE-2026-43180)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: consume xmit errors of GSO frames\n\nudpgro_frglist.sh and udpgro_bench.sh are the flakiest tests\ncurrently in NIPA. They fail in the same exact way, TCP GRO\ntest stalls occasionally and the test gets killed after 10min.\n\nThese tests use veth to simulate GRO. They attach a trivial\n(\u0026quot;return XDP_PASS;\u0026quot;) XDP program to the veth to force TSO off\nand NAPI on.\n\nDigging into the failure mode we can see that the connection\nis completely stuck after a burst of drops. The sender\u0026apos;s snd_nxt\nis at sequence number N [1], but the receiver claims to have\nreceived (rcv_nxt) up to N + 3 * MSS [2]. Last piece of the puzzle\nis that senders rtx queue is not empty (let\u0026apos;s say the block in\nthe rtx queue is at sequence number N - 4 * MSS [3]).\n\nIn this state, sender sends a retransmission from the rtx queue\nwith a single segment, and sequence numbers N-4*MSS:N-3*MSS [3].\nReceiver sees it and responds with an ACK all the way up to\nN + 3 * MSS [2]. But sender will reject this ack as TCP_ACK_UNSENT_DATA\nbecause it has no recollection of ever sending data that far out [1].\nAnd we are stuck.\n\nThe root cause is the mess of the xmit return codes. veth returns\nan error when it can\u0026apos;t xmit a frame. We end up with a loss event\nlike this:\n\n  -------------------------------------------------\n  |   GSO super frame 1   |   GSO super frame 2   |\n  |-----------------------------------------------|\n  | seg | seg | seg | seg | seg | seg | seg | seg |\n  |  1  |  2  |  3  |  4  |  5  |  6  |  7  |  8  |\n  -------------------------------------------------\n     x    ok    ok    \u0026lt;ok\u0026gt;|  ok    ok    ok   \u0026lt;x\u0026gt;\n                          \\\\\n\t\t\t   snd_nxt\n\n\u0026quot;x\u0026quot; means packet lost by veth, and \u0026quot;ok\u0026quot; means it went thru.\nSince veth has TSO disabled in this test it sees individual segments.\nSegment 1 is on the retransmit queue and will be resent.\n\nSo why did the sender not advance snd_nxt even tho it clearly did\nsend up to seg 8? tcp_write_xmit() interprets the return code\nfrom the core to mean that data has not been sent at all. Since\nTCP deals with GSO super frames, not individual segment the crux\nof the problem is that loss of a single segment can be interpreted\nas loss of all. TCP only sees the last return code for the last\nsegment of the GSO frame (in \u0026lt;\u0026gt; brackets in the diagram above).\n\nOf course for the problem to occur we need a setup or a device\nwithout a Qdisc. Otherwise Qdisc layer disconnects the protocol\nlayer from the device errors completely.\n\nWe have multiple ways to fix this.\n\n 1) make veth not return an error when it lost a packet.\n    While this is what I think we did in the past, the issue keeps\n    reappearing and it\u0026apos;s annoying to debug. The game of whack\n    a mole is not great.\n\n 2) fix the damn return codes\n    We only talk about NETDEV_TX_OK and NETDEV_TX_BUSY in the\n    documentation, so maybe we should make the return code from\n    ndo_start_xmit() a boolean. I like that the most, but perhaps\n    some ancient, not-really-networking protocol would suffer.\n\n 3) make TCP ignore the errors\n    It is not entirely clear to me what benefit TCP gets from\n    interpreting the result of ip_queue_xmit()? Specifically once\n    the connection is established and we\u0026apos;re pushing data - packet\n    loss is just packet loss?\n\n 4) this fix\n    Ignore the rc in the Qdisc-less+GSO case, since it\u0026apos;s unreliable.\n    We already always return OK in the TCQ_F_CAN_BYPASS case.\n    In the Qdisc-less case let\u0026apos;s be a bit more conservative and only\n    mask the GSO errors. This path is taken by non-IP-\u0026quot;networks\u0026quot;\n    like CAN, MCTP etc, so we could regress some ancient thing.\n    This is the simplest, but also maybe the hackiest fix?\n\nSimilar fix has been proposed by Eric in the past but never committed\nbecause original reporter was working with an OOT driver and wasn\u0026apos;t\nproviding feedback (see Link).(CVE-2026-43194)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ntcp: fix potential race in tcp_v6_syn_recv_sock()\n\nCode in tcp_v6_syn_recv_sock() after the call to tcp_v4_syn_recv_sock()\nis done too late.\n\nAfter tcp_v4_syn_recv_sock(), the child socket is already visible\nfrom TCP ehash table and other cpus might use it.\n\nSince newinet-\u0026gt;pinet6 is still pointing to the listener ipv6_pinfo\nbad things can happen as syzbot found.\n\nMove the problematic code in tcp_v6_mapped_child_init()\nand call this new helper from tcp_v4_syn_recv_sock() before\nthe ehash insertion.\n\nThis allows the removal of one tcp_sync_mss(), since\ntcp_v4_syn_recv_sock() will call it with the correct\ncontext.(CVE-2026-43198)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet: Drop the lock in skb_may_tx_timestamp()\n\nskb_may_tx_timestamp() may acquire sock::sk_callback_lock. The lock must\nnot be taken in IRQ context, only softirq is okay. A few drivers receive\nthe timestamp via a dedicated interrupt and complete the TX timestamp\nfrom that handler. This will lead to a deadlock if the lock is already\nwrite-locked on the same CPU.\n\nTaking the lock can be avoided. The socket (pointed by the skb) will\nremain valid until the skb is released. The -\u0026gt;sk_socket and -\u0026gt;file\nmember will be set to NULL once the user closes the socket which may\nhappen before the timestamp arrives.\nIf we happen to observe the pointer while the socket is closing but\nbefore the pointer is set to NULL then we may use it because both\npointer (and the file\u0026apos;s cred member) are RCU freed.\n\nDrop the lock. Use READ_ONCE() to obtain the individual pointer. Add a\nmatching WRITE_ONCE() where the pointer are cleared.(CVE-2026-43216)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nvhost: move vdpa group bound check to vhost_vdpa\n\nRemove duplication by consolidating these here.  This reduces the\nposibility of a parent driver missing them.\n\nWhile we\u0026apos;re at it, fix a bug in vdpa_sim where a valid ASID can be\nassigned to a group equal to ngroups, causing an out of bound write.(CVE-2026-43248)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nmm/page_alloc: clear page-\u0026gt;private in free_pages_prepare()\n\nSeveral subsystems (slub, shmem, ttm, etc.) use page-\u0026gt;private but don\u0026apos;t\nclear it before freeing pages.  When these pages are later allocated as\nhigh-order pages and split via split_page(), tail pages retain stale\npage-\u0026gt;private values.\n\nThis causes a use-after-free in the swap subsystem.  The swap code uses\npage-\u0026gt;private to track swap count continuations, assuming freshly\nallocated pages have page-\u0026gt;private == 0.  When stale values are present,\nswap_count_continued() incorrectly assumes the continuation list is valid\nand iterates over uninitialized page-\u0026gt;lru containing LIST_POISON values,\ncausing a crash:\n\n  KASAN: maybe wild-memory-access in range [0xdead000000000100-0xdead000000000107]\n  RIP: 0010:__do_sys_swapoff+0x1151/0x1860\n\nFix this by clearing page-\u0026gt;private in free_pages_prepare(), ensuring all\nfreed pages have clean state regardless of previous use.(CVE-2026-43303)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: SMP: force responder MITM requirements before building the pairing response\n\nsmp_cmd_pairing_req() currently builds the pairing response from the\ninitiator auth_req before enforcing the local BT_SECURITY_HIGH\nrequirement. If the initiator omits SMP_AUTH_MITM, the response can\nalso omit it even though the local side still requires MITM.\n\ntk_request() then sees an auth value without SMP_AUTH_MITM and may\nselect JUST_CFM, making method selection inconsistent with the pairing\npolicy the responder already enforces.\n\nWhen the local side requires HIGH security, first verify that MITM can\nbe achieved from the IO capabilities and then force SMP_AUTH_MITM in the\nresponse in both rsp.auth_req and auth. This keeps the responder auth bits\nand later method selection aligned.(CVE-2026-43334)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: RX, Fix XDP multi-buf frag counting for striding RQ\n\nXDP multi-buf programs can modify the layout of the XDP buffer when the\nprogram calls bpf_xdp_pull_data() or bpf_xdp_adjust_tail(). The\nreferenced commit in the fixes tag corrected the assumption in the mlx5\ndriver that the XDP buffer layout doesn\u0026apos;t change during a program\nexecution. However, this fix introduced another issue: the dropped\nfragments still need to be counted on the driver side to avoid page\nfragment reference counting issues.\n\nThe issue was discovered by the drivers/net/xdp.py selftest,\nmore specifically the test_xdp_native_tx_mb:\n- The mlx5 driver allocates a page_pool page and initializes it with\n  a frag counter of 64 (pp_ref_count=64) and the internal frag counter\n  to 0.\n- The test sends one packet with no payload.\n- On RX (mlx5e_skb_from_cqe_mpwrq_nonlinear()), mlx5 configures the XDP\n  buffer with the packet data starting in the first fragment which is the\n  page mentioned above.\n- The XDP program runs and calls bpf_xdp_pull_data() which moves the\n  header into the linear part of the XDP buffer. As the packet doesn\u0026apos;t\n  contain more data, the program drops the tail fragment since it no\n  longer contains any payload (pp_ref_count=63).\n- mlx5 device skips counting this fragment. Internal frag counter\n  remains 0.\n- mlx5 releases all 64 fragments of the page but page pp_ref_count is\n  63 =\u0026gt; negative reference counting error.\n\nResulting splat during the test:\n\n  WARNING: CPU: 0 PID: 188225 at ./include/net/page_pool/helpers.h:297 mlx5e_page_release_fragmented.isra.0+0xbd/0xe0 [mlx5_core]\n  Modules linked in: [...]\n  CPU: 0 UID: 0 PID: 188225 Comm: ip Not tainted 6.18.0-rc7_for_upstream_min_debug_2025_12_08_11_44 #1 NONE\n  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n  RIP: 0010:mlx5e_page_release_fragmented.isra.0+0xbd/0xe0 [mlx5_core]\n  [...]\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   mlx5e_free_rx_mpwqe+0x20a/0x250 [mlx5_core]\n   mlx5e_dealloc_rx_mpwqe+0x37/0xb0 [mlx5_core]\n   mlx5e_free_rx_descs+0x11a/0x170 [mlx5_core]\n   mlx5e_close_rq+0x78/0xa0 [mlx5_core]\n   mlx5e_close_queues+0x46/0x2a0 [mlx5_core]\n   mlx5e_close_channel+0x24/0x90 [mlx5_core]\n   mlx5e_close_channels+0x5d/0xf0 [mlx5_core]\n   mlx5e_safe_switch_params+0x2ec/0x380 [mlx5_core]\n   mlx5e_change_mtu+0x11d/0x490 [mlx5_core]\n   mlx5e_change_nic_mtu+0x19/0x30 [mlx5_core]\n   netif_set_mtu_ext+0xfc/0x240\n   do_setlink.isra.0+0x226/0x1100\n   rtnl_newlink+0x7a9/0xba0\n   rtnetlink_rcv_msg+0x220/0x3c0\n   netlink_rcv_skb+0x4b/0xf0\n   netlink_unicast+0x255/0x380\n   netlink_sendmsg+0x1f3/0x420\n   __sock_sendmsg+0x38/0x60\n   ____sys_sendmsg+0x1e8/0x240\n   ___sys_sendmsg+0x7c/0xb0\n   [...]\n   __sys_sendmsg+0x5f/0xb0\n   do_syscall_64+0x55/0xc70\n\nThe problem applies for XDP_PASS as well which is handled in a different\ncode path in the driver.\n\nThis patch fixes the issue by doing page frag counting on all the\noriginal XDP buffer fragments for all relevant XDP actions (XDP_TX ,\nXDP_REDIRECT and XDP_PASS). This is basically reverting to the original\ncounting before the commit in the fixes tag.\n\nAs frag_page is still pointing to the original tail, the nr_frags\nparameter to xdp_update_skb_frags_info() needs to be calculated\nin a different way to reflect the new nr_frags.(CVE-2026-43465)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix DMA FIFO desync on error CQE SQ recovery\n\nIn case of a TX error CQE, a recovery flow is triggered,\nmlx5e_reset_txqsq_cc_pc() resets dma_fifo_cc to 0 but not dma_fifo_pc,\ndesyncing the DMA FIFO producer and consumer.\n\nAfter recovery, the producer pushes new DMA entries at the old\ndma_fifo_pc, while the consumer reads from position 0.\nThis causes us to unmap stale DMA addresses from before the recovery.\n\nThe DMA FIFO is a purely software construct with no HW counterpart.\nAt the point of reset, all WQEs have been flushed so dma_fifo_cc is\nalready equal to dma_fifo_pc. There is no need to reset either counter,\nsimilar to how skb_fifo pc/cc are untouched.\n\nRemove the \u0026apos;dma_fifo_cc = 0\u0026apos; reset.\n\nThis fixes the following WARNING:\n    WARNING: CPU: 0 PID: 0 at drivers/iommu/dma-iommu.c:1240 iommu_dma_unmap_page+0x79/0x90\n    Modules linked in: mlx5_vdpa vringh vdpa bonding mlx5_ib mlx5_vfio_pci ipip mlx5_fwctl tunnel4 mlx5_core ib_ipoib geneve ip6_gre ip_gre gre nf_tables ip6_tunnel rdma_ucm ib_uverbs ib_umad vfio_pci vfio_pci_core act_mirred act_skbedit act_vlan vhost_net vhost tap ip6table_mangle ip6table_nat ip6table_filter ip6_tables iptable_mangle cls_matchall nfnetlink_cttimeout act_gact cls_flower sch_ingress vhost_iotlb iptable_raw tunnel6 vfio_iommu_type1 vfio openvswitch nsh rpcsec_gss_krb5 auth_rpcgss oid_registry xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat nf_nat xt_addrtype br_netfilter overlay zram zsmalloc rpcrdma ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm ib_core fuse [last unloaded: nf_tables]\n    CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5_for_upstream_min_debug_2024_12_30_21_33 #1\n    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n    RIP: 0010:iommu_dma_unmap_page+0x79/0x90\n    Code: 2b 4d 3b 21 72 26 4d 3b 61 08 73 20 49 89 d8 44 89 f9 5b 4c 89 f2 4c 89 e6 48 89 ef 5d 41 5c 41 5d 41 5e 41 5f e9 c7 ae 9e ff \u0026lt;0f\u0026gt; 0b 5b 5d 41 5c 41 5d 41 5e 41 5f c3 66 2e 0f 1f 84 00 00 00 00\n    Call Trace:\n     \u0026lt;IRQ\u0026gt;\n     ? __warn+0x7d/0x110\n     ? iommu_dma_unmap_page+0x79/0x90\n     ? report_bug+0x16d/0x180\n     ? handle_bug+0x4f/0x90\n     ? exc_invalid_op+0x14/0x70\n     ? asm_exc_invalid_op+0x16/0x20\n     ? iommu_dma_unmap_page+0x79/0x90\n     ? iommu_dma_unmap_page+0x2e/0x90\n     dma_unmap_page_attrs+0x10d/0x1b0\n     mlx5e_tx_wi_dma_unmap+0xbe/0x120 [mlx5_core]\n     mlx5e_poll_tx_cq+0x16d/0x690 [mlx5_core]\n     mlx5e_napi_poll+0x8b/0xac0 [mlx5_core]\n     __napi_poll+0x24/0x190\n     net_rx_action+0x32a/0x3b0\n     ? mlx5_eq_comp_int+0x7e/0x270 [mlx5_core]\n     ? notifier_call_chain+0x35/0xa0\n     handle_softirqs+0xc9/0x270\n     irq_exit_rcu+0x71/0xd0\n     common_interrupt+0x7f/0xa0\n     \u0026lt;/IRQ\u0026gt;\n     \u0026lt;TASK\u0026gt;\n     asm_common_interrupt+0x22/0x40(CVE-2026-43466)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nipvs: skip ipv6 extension headers for csum checks\n\nProtocol checksum validation fails for IPv6 if there are extension\nheaders before the protocol header. iph-\u0026gt;len already contains its\noffset, so use it to fix the problem.(CVE-2026-45850)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\napparmor: Fix \u0026amp; Optimize table creation from possibly unaligned memory\n\nSource blob may come from userspace and might be unaligned.\nTry to optize the copying process by avoiding unaligned memory accesses.\n\n- Added Fixes tag\n- Added \u0026quot;Fix \u0026amp;\u0026quot; to description as this doesn\u0026apos;t just optimize but fixes\n        a potential unaligned memory access\n[jj: remove duplicate word \u0026quot;convert\u0026quot; in comment trigger checkpatch warning](CVE-2026-45893)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/vt-d: Clear Present bit before tearing down PASID entry\n\nThe Intel VT-d Scalable Mode PASID table entry consists of 512 bits (64\nbytes). When tearing down an entry, the current implementation zeros the\nentire 64-byte structure immediately using multiple 64-bit writes.\n\nSince the IOMMU hardware may fetch these 64 bytes using multiple\ninternal transactions (e.g., four 128-bit bursts), updating or zeroing\nthe entire entry while it is active (P=1) risks a \u0026quot;torn\u0026quot; read. If a\nhardware fetch occurs simultaneously with the CPU zeroing the entry, the\nhardware could observe an inconsistent state, leading to unpredictable\nbehavior or spurious faults.\n\nFollow the \u0026quot;Guidance to Software for Invalidations\u0026quot; in the VT-d spec\n(Section 6.5.3.3) by implementing the recommended ownership handshake:\n\n1. Clear only the \u0026apos;Present\u0026apos; (P) bit of the PASID entry.\n2. Use a dma_wmb() to ensure the cleared bit is visible to hardware\n   before proceeding.\n3. Execute the required invalidation sequence (PASID cache, IOTLB, and\n   Device-TLB flush) to ensure the hardware has released all cached\n   references.\n4. Only after the flushes are complete, zero out the remaining fields\n   of the PASID entry.\n\nAlso, add a dma_wmb() in pasid_set_present() to ensure that all other\nfields of the PASID entry are visible to the hardware before the Present\nbit is set.(CVE-2026-45894)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nquota: fix livelock between quotactl and freeze_super\n\nWhen a filesystem is frozen, quotactl_block() enters a retry loop\nwaiting for the filesystem to thaw. It acquires s_umount, checks the\nfreeze state, drops s_umount and uses sb_start_write() - sb_end_write()\npair to wait for the unfreeze.\n\nHowever, this retry loop can trigger a livelock issue, specifically on\nkernels with preemption disabled.\n\nThe mechanism is as follows:\n1. freeze_super() sets SB_FREEZE_WRITE and calls sb_wait_write().\n2. sb_wait_write() calls percpu_down_write(), which initiates\n   synchronize_rcu().\n3. Simultaneously, quotactl_block() spins in its retry loop, immediately\n   executing the sb_start_write() - sb_end_write() pair.\n4. Because the kernel is non-preemptible and the loop contains no\n   scheduling points, quotactl_block() never yields the CPU. This\n   prevents that CPU from reaching an RCU quiescent state.\n5. synchronize_rcu() in the freezer thread waits indefinitely for the\n   quotactl_block() CPU to report a quiescent state.\n6. quotactl_block() spins indefinitely waiting for the freezer to\n   advance, which it cannot do as it is blocked on the RCU sync.\n\nThis results in a hang of the freezer process and 100% CPU usage by the\nquota process.\n\nWhile this can occur intermittently on multi-core systems, it is\nreliably reproducing on a node with the following script, running both\nthe freezer and the quota toggle on the same CPU:\n\n  # mkfs.ext4 -O quota /dev/sda 2g \u0026amp;\u0026amp; mkdir a_mount\n  # mount /dev/sda -o quota,usrquota,grpquota a_mount\n  # taskset -c 3 bash -c \u0026quot;while true; do xfs_freeze -f a_mount; \\\n    xfs_freeze -u a_mount; done\u0026quot; \u0026amp;\n  # taskset -c 3 bash -c \u0026quot;while true; do quotaon a_mount; \\\n    quotaoff a_mount; done\u0026quot; \u0026amp;\n\nAdding cond_resched() to the retry loop fixes the issue. It acts as an\nRCU quiescent state, allowing synchronize_rcu() in percpu_down_write()\nto complete.(CVE-2026-45895)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfat: avoid parent link count underflow in rmdir\n\nCorrupted FAT images can leave a directory inode with an incorrect\ni_nlink (e.g. 2 even though subdirectories exist). rmdir then\nunconditionally calls drop_nlink(dir) and can drive i_nlink to 0,\ntriggering the WARN_ON in drop_nlink().\n\nAdd a sanity check in vfat_rmdir() and msdos_rmdir(): only drop the\nparent link count when it is at least 3, otherwise report a filesystem\nerror.(CVE-2026-45915)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\next4: fix dirtyclusters double decrement on fs shutdown\n\nfstests test generic/388 occasionally reproduces a warning in\next4_put_super() associated with the dirty clusters count:\n\n  WARNING: CPU: 7 PID: 76064 at fs/ext4/super.c:1324 ext4_put_super+0x48c/0x590 [ext4]\n\nTracing the failure shows that the warning fires due to an\ns_dirtyclusters_counter value of -1. IOW, this appears to be a\nspurious decrement as opposed to some sort of leak. Further tracing\nof the dirty cluster count deltas and an LLM scan of the resulting\noutput identified the cause as a double decrement in the error path\nbetween ext4_mb_mark_diskspace_used() and the caller\next4_mb_new_blocks().\n\nFirst, note that generic/388 is a shutdown vs. fsstress test and so\nproduces a random set of operations and shutdown injections. In the\nproblematic case, the shutdown triggers an error return from the\next4_handle_dirty_metadata() call(s) made from\next4_mb_mark_context(). The changed value is non-zero at this point,\nso ext4_mb_mark_diskspace_used() does not exit after the error\nbubbles up from ext4_mb_mark_context(). Instead, the former\ndecrements both cluster counters and returns the error up to\next4_mb_new_blocks(). The latter falls into the !ar-\u0026gt;len out path\nwhich decrements the dirty clusters counter a second time, creating\nthe inconsistency.\n\nTo avoid this problem and simplify ownership of the cluster\nreservation in this codepath, lift the counter reduction to a single\nplace in the caller. This makes it more clear that\next4_mb_new_blocks() is responsible for acquiring cluster\nreservation (via ext4_claim_free_clusters()) in the !delalloc case\nas well as releasing it, regardless of whether it ends up consumed\nor returned due to failure.(CVE-2026-45920)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\niommu/vt-d: Clear Present bit before tearing down context entry\n\nWhen tearing down a context entry, the current implementation zeros the\nentire 128-bit entry using multiple 64-bit writes. This creates a window\nwhere the hardware can fetch a \u0026quot;torn\u0026quot; entry \u2014 where some fields are\nalready zeroed while the \u0026apos;Present\u0026apos; bit is still set \u2014 leading to\nunpredictable behavior or spurious faults.\n\nWhile x86 provides strong write ordering, the compiler may reorder writes\nto the two 64-bit halves of the context entry. Even without compiler\nreordering, the hardware fetch is not guaranteed to be atomic with\nrespect to multiple CPU writes.\n\nAlign with the \u0026quot;Guidance to Software for Invalidations\u0026quot; in the VT-d spec\n(Section 6.5.3.3) by implementing the recommended ownership handshake:\n\n1. Clear only the \u0026apos;Present\u0026apos; (P) bit of the context entry first to\n   signal the transition of ownership from hardware to software.\n2. Use dma_wmb() to ensure the cleared bit is visible to the IOMMU.\n3. Perform the required cache and context-cache invalidation to ensure\n   hardware no longer has cached references to the entry.\n4. Fully zero out the entry only after the invalidation is complete.\n\nAlso, add a dma_wmb() to context_set_present() to ensure the entry\nis fully initialized before the \u0026apos;Present\u0026apos; bit becomes visible.(CVE-2026-45944)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nhwrng: core - use RCU and work_struct to fix race condition\n\nCurrently, hwrng_fill is not cleared until the hwrng_fillfn() thread\nexits. Since hwrng_unregister() reads hwrng_fill outside the rng_mutex\nlock, a concurrent hwrng_unregister() may call kthread_stop() again on\nthe same task.\n\nAdditionally, if hwrng_unregister() is called immediately after\nhwrng_register(), the stopped thread may have never been executed. Thus,\nhwrng_fill remains dirty even after hwrng_unregister() returns. In this\ncase, subsequent calls to hwrng_register() will fail to start new\nthreads, and hwrng_unregister() will call kthread_stop() on the same\nfreed task. In both cases, a use-after-free occurs:\n\nrefcount_t: addition on 0; use-after-free.\nWARNING: ... at lib/refcount.c:25 refcount_warn_saturate+0xec/0x1c0\nCall Trace:\n kthread_stop+0x181/0x360\n hwrng_unregister+0x288/0x380\n virtrng_remove+0xe3/0x200\n\nThis patch fixes the race by protecting the global hwrng_fill pointer\ninside the rng_mutex lock, so that hwrng_fillfn() thread is stopped only\nonce, and calls to kthread_run() and kthread_stop() are serialized\nwith the lock held.\n\nTo avoid deadlock in hwrng_fillfn() while being stopped with the lock\nheld, we convert current_rng to RCU, so that get_current_rng() can read\ncurrent_rng without holding the lock. To remove the lock from put_rng(),\nwe also delay the actual cleanup into a work_struct.\n\nSince get_current_rng() no longer returns ERR_PTR values, the IS_ERR()\nchecks are removed from its callers.\n\nWith hwrng_fill protected by the rng_mutex lock, hwrng_fillfn() can no\nlonger clear hwrng_fill itself. Therefore, if hwrng_fillfn() returns\ndirectly after current_rng is dropped, kthread_stop() would be called on\na freed task_struct later. To fix this, hwrng_fillfn() calls schedule()\nnow to keep the task alive until being stopped. The kthread_stop() call\nis also moved from hwrng_unregister() to drop_current_rng(), ensuring\nkthread_stop() is called on all possible paths where current_rng becomes\nNULL, so that the thread would not wait forever.(CVE-2026-45949)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncpuidle: Skip governor when only one idle state is available\n\nOn certain platforms (PowerNV systems without a power-mgt DT node),\ncpuidle may register only a single idle state. In cases where that\nsingle state is a polling state (state 0), the ladder governor may\nincorrectly treat state 1 as the first usable state and pass an\nout-of-bounds index. This can lead to a NULL enter callback being\ninvoked, ultimately resulting in a system crash.\n\n[   13.342636] cpuidle-powernv : Only Snooze is available\n[   13.351854] Faulting instruction address: 0x00000000\n[   13.376489] NIP [0000000000000000] 0x0\n[   13.378351] LR  [c000000001e01974] cpuidle_enter_state+0x2c4/0x668\n\nFix this by adding a bail-out in cpuidle_select() that returns state 0\ndirectly when state_count \u0026lt;= 1, bypassing the governor and keeping the\ntick running.(CVE-2026-45968)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx5: Fix UMR hang in LAG error state unload\n\nDuring firmware reset in LAG mode, a race condition causes the driver\nto hang indefinitely while waiting for UMR completion during device\nunload. See [1].\n\nIn LAG mode the bond device is only registered on the master, so it\nnever sees sys_error events from the slave.\nDuring firmware reset this causes UMR waits to hang forever on unload\nas the slave is dead but the master hasn\u0026apos;t entered error state yet, so\nUMR posts succeed but completions never arrive.\n\nFix this by adding a sys_error notifier that gets registered before\nMLX5_IB_STAGE_IB_REG and stays alive until after ib_unregister_device().\nThis ensures error events reach the bond device throughout teardown.\n\n[1]\nCall Trace:\n __schedule+0x2bd/0x760\n schedule+0x37/0xa0\n schedule_preempt_disabled+0xa/0x10\n __mutex_lock.isra.6+0x2b5/0x4a0\n __mlx5_ib_dereg_mr+0x606/0x870 [mlx5_ib]\n ? __xa_erase+0x4a/0xa0\n ? _cond_resched+0x15/0x30\n ? wait_for_completion+0x31/0x100\n ib_dereg_mr_user+0x48/0xc0 [ib_core]\n ? rdmacg_uncharge_hierarchy+0xa0/0x100\n destroy_hw_idr_uobject+0x20/0x50 [ib_uverbs]\n uverbs_destroy_uobject+0x37/0x150 [ib_uverbs]\n __uverbs_cleanup_ufile+0xda/0x140 [ib_uverbs]\n uverbs_destroy_ufile_hw+0x3a/0xf0 [ib_uverbs]\n ib_uverbs_remove_one+0xc3/0x140 [ib_uverbs]\n remove_client_context+0x8b/0xd0 [ib_core]\n disable_device+0x8c/0x130 [ib_core]\n __ib_unregister_device+0x10d/0x180 [ib_core]\n ib_unregister_device+0x21/0x30 [ib_core]\n __mlx5_ib_remove+0x1e4/0x1f0 [mlx5_ib]\n auxiliary_bus_remove+0x1e/0x30\n device_release_driver_internal+0x103/0x1f0\n bus_remove_device+0xf7/0x170\n device_del+0x181/0x410\n mlx5_rescan_drivers_locked.part.10+0xa9/0x1d0 [mlx5_core]\n mlx5_disable_lag+0x253/0x260 [mlx5_core]\n mlx5_lag_disable_change+0x89/0xc0 [mlx5_core]\n mlx5_eswitch_disable+0x67/0xa0 [mlx5_core]\n mlx5_unload+0x15/0xd0 [mlx5_core]\n mlx5_unload_one+0x71/0xc0 [mlx5_core]\n mlx5_sync_reset_reload_work+0x83/0x100 [mlx5_core]\n process_one_work+0x1a7/0x360\n worker_thread+0x30/0x390\n ? create_worker+0x1a0/0x1a0\n kthread+0x116/0x130\n ? kthread_flush_work_fn+0x10/0x10\n ret_from_fork+0x22/0x40(CVE-2026-45973)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ngfs2: Fix use-after-free in iomap inline data write path\n\nThe inline data buffer head (dibh) is being released prematurely in\ngfs2_iomap_begin() via release_metapath() while iomap-\u0026gt;inline_data\nstill points to dibh-\u0026gt;b_data. This causes a use-after-free when\niomap_write_end_inline() later attempts to write to the inline data\narea.\n\nThe bug sequence:\n1. gfs2_iomap_begin() calls gfs2_meta_inode_buffer() to read inode\n   metadata into dibh\n2. Sets iomap-\u0026gt;inline_data = dibh-\u0026gt;b_data + sizeof(struct gfs2_dinode)\n3. Calls release_metapath() which calls brelse(dibh), dropping refcount\n   to 0\n4. kswapd reclaims the page (~39ms later in the syzbot report)\n5. iomap_write_end_inline() tries to memcpy() to iomap-\u0026gt;inline_data\n6. KASAN detects use-after-free write to freed memory\n\nFix by storing dibh in iomap-\u0026gt;private and incrementing its refcount\nwith get_bh() in gfs2_iomap_begin(). The buffer is then properly\nreleased in gfs2_iomap_end() after the inline write completes,\nensuring the page stays alive for the entire iomap operation.\n\nNote: A C reproducer is not available for this issue. The fix is based\non analysis of the KASAN report and code review showing the buffer head\nis freed before use.\n\n[agruenba: Take buffer head reference in gfs2_iomap_begin() to avoid\nleaks in gfs2_iomap_get() and gfs2_iomap_alloc().](CVE-2026-45984)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ndrm/nouveau: fix u32 overflow in pushbuf reloc bounds check\n\nnouveau_gem_pushbuf_reloc_apply() validates each relocation with\n\n    if (r-\u0026gt;reloc_bo_offset + 4 \u0026gt; nvbo-\u0026gt;bo.base.size)\n\nbut reloc_bo_offset is __u32 (uapi/drm/nouveau_drm.h) and the integer\nliteral 4 promotes to unsigned int, so the addition is performed in 32\nbits and wraps before the comparison against the size_t bo size.\n\nCast to u64 so the addition happens in 64-bit arithmetic.\n\n[ Add Fixes: tag. - Danilo ](CVE-2026-46006)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nthermal: core: Fix thermal zone governor cleanup issues\n\nIf thermal_zone_device_register_with_trips() fails after adding\na thermal governor to the thermal zone being registered, the\ngovernor is not removed from it as appropriate which may lead to\na memory leak.\n\nIn turn, thermal_zone_device_unregister() calls thermal_set_governor()\nwithout acquiring the thermal zone lock beforehand which may race with\na governor update via sysfs and may lead to a use-after-free in that\ncase.\n\nAddress these issues by adding two thermal_set_governor() calls, one to\nthermal_release() to remove the governor from the given thermal zone,\nand one to the thermal zone registration error path to cover failures\npreceding the thermal zone device registration.(CVE-2026-46021)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nKVM: nSVM: Triple fault if restore host CR3 fails on nested #VMEXIT\n\nIf loading L1\u0026apos;s CR3 fails on a nested #VMEXIT, nested_svm_vmexit()\nreturns an error code that is ignored by most callers, and continues to\nrun L1 with corrupted state. A sane recovery is not possible in this\ncase, and HW behavior is to cause a shutdown. Inject a triple fault\ninstead, and do not return early from nested_svm_vmexit(). Continue\ncleaning up the vCPU state (e.g. clear pending exceptions), to handle\nthe failure as gracefully as possible.\n\nFrom the APM:\n\n  Upon #VMEXIT, the processor performs the following actions in order to\n  return to the host execution context:\n\n  ...\n\n  if (illegal host state loaded, or exception while loading host state)\n      shutdown\n  else\n      execute first host instruction following the VMRUN\n\nRemove the return value of nested_svm_vmexit(), which is mostly\nunchecked anyway.(CVE-2026-46032)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: authencesn - reject short ahash digests during instance creation\n\nauthencesn requires either a zero authsize or an authsize of at least\n4 bytes because the ESN encrypt/decrypt paths always move 4 bytes of\nhigh-order sequence number data at the end of the authenticated data.\n\nWhile crypto_authenc_esn_setauthsize() already rejects explicit\nnon-zero authsizes in the range 1..3, crypto_authenc_esn_create()\nstill copied auth-\u0026gt;digestsize into inst-\u0026gt;alg.maxauthsize without\nvalidating it.  The AEAD core then initialized the tfm\u0026apos;s default\nauthsize from that value.\n\nAs a result, selecting an ahash with digest size 1..3, such as\ncbcmac(cipher_null), exposed authencesn instances whose default\nauthsize was invalid even though setauthsize() would have rejected the\nsame value.  AF_ALG could then trigger the ESN tail handling with a\ntoo-short tag and hit an out-of-bounds access.\n\nReject authencesn instances whose ahash digest size is in the invalid\nnon-zero range 1..3 so that no tfm can inherit an unsupported default\nauthsize.(CVE-2026-46033)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nceph: only d_add() negative dentries when they are unhashed\n\nCeph can call d_add(dentry, NULL) on a negative dentry that is already\npresent in the primary dcache hash.\n\nIn the current VFS that is not safe.  d_add() goes through __d_add()\nto __d_rehash(), which unconditionally reinserts dentry-\u0026gt;d_hash into\nthe hlist_bl bucket.  If the dentry is already hashed, reinserting the\nsame node can corrupt the bucket, including creating a self-loop.\nOnce that happens, __d_lookup() can spin forever in the hlist_bl walk,\ntypically looping only on the d_name.hash mismatch check and\neventually triggering RCU stall reports like this one:\n\n rcu: INFO: rcu_sched self-detected stall on CPU\n rcu:         87-....: (2100 ticks this GP) idle=3a4c/1/0x4000000000000000 softirq=25003319/25003319 fqs=829\n rcu:         (t=2101 jiffies g=79058445 q=698988 ncpus=192)\n CPU: 87 UID: 2952868916 PID: 3933303 Comm: php-cgi8.3 Not tainted 6.18.17-i1-amd #950 NONE\n Hardware name: Dell Inc. PowerEdge R7615/0G9DHV, BIOS 1.6.6 09/22/2023\n RIP: 0010:__d_lookup+0x46/0xb0\n Code: c1 e8 07 48 8d 04 c2 48 8b 00 49 89 fc 49 89 f5 48 89 c3 48 83 e3 fe 48 83 f8 01 77 0f eb 2d 0f 1f 44 00 00 48 8b 1b 48 85 db \u0026lt;74\u0026gt; 20 39 6b 18 75 f3 48 8d 7b 78 e8 ba 85 d0 00 4c 39 63 10 74 1f\n RSP: 0018:ff745a70c8253898 EFLAGS: 00000282\n RAX: ff26e470054cb208 RBX: ff26e470054cb208 RCX: 000000006e958966\n RDX: ff26e48267340000 RSI: ff745a70c82539b0 RDI: ff26e458f74655c0\n RBP: 000000006e958966 R08: 0000000000000180 R09: 9cd08d909b919a89\n R10: ff26e458f74655c0 R11: 0000000000000000 R12: ff26e458f74655c0\n R13: ff745a70c82539b0 R14: d0d0d0d0d0d0d0d0 R15: 2f2f2f2f2f2f2f2f\n FS:  00007f5770896980(0000) GS:ff26e482c5d88000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f5764de50c0 CR3: 000000a72abb5001 CR4: 0000000000771ef0\n PKRU: 55555554\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  lookup_fast+0x9f/0x100\n  walk_component+0x1f/0x150\n  link_path_walk+0x20e/0x3d0\n  path_lookupat+0x68/0x180\n  filename_lookup+0xdc/0x1e0\n  vfs_statx+0x6c/0x140\n  vfs_fstatat+0x67/0xa0\n  __do_sys_newfstatat+0x24/0x60\n  do_syscall_64+0x6a/0x230\n  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nThis is reachable with reused cached negative dentries.  A Ceph lookup\nor atomic_open can be handed a negative dentry that is already hashed,\nand fs/ceph/dir.c then hits one of two paths that incorrectly assume\n\u0026quot;negative\u0026quot; also means \u0026quot;unhashed\u0026quot;:\n\n  - ceph_finish_lookup():\n      MDS reply is -ENOENT with no trace\n      -\u0026gt; d_add(dentry, NULL)\n\n  - ceph_lookup():\n      local ENOENT fast path for a complete directory with shared caps\n      -\u0026gt; d_add(dentry, NULL)\n\nBoth paths can therefore re-add an already-hashed negative dentry.\n\nCeph already uses the correct pattern elsewhere: ceph_fill_trace() only\ncalls d_add(dn, NULL) for a negative null-dentry reply when d_unhashed(dn)\nis true.\n\nFix both fs/ceph/dir.c sites the same way: only call d_add() for a\nnegative dentry when it is actually unhashed.  If the negative dentry\nis already hashed, leave it in place and reuse it as-is.\n\nThis preserves the existing behavior for unhashed dentries while\navoiding d_hash list corruption for reused hashed negatives.(CVE-2026-46052)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: defio: Disconnect deferred I/O from the lifetime of struct fb_info\n\nHold state of deferred I/O in struct fb_deferred_io_state. Allocate an\ninstance as part of initializing deferred I/O and remove it only after\nthe final mapping has been closed. If the fb_info and the contained\ndeferred I/O meanwhile goes away, clear struct fb_deferred_io_state.info\nto invalidate the mapping. Any access will then result in a SIGBUS\nsignal.\n\nFixes a long-standing problem, where a device hot-unplug happens while\nuser space still has an active mapping of the graphics memory. The hot-\nunplug frees the instance of struct fb_info. Accessing the memory will\noperate on undefined state.(CVE-2026-46065)\n\nIn the Linux kernel, the vlan_dev_set_egress_priority() function currently keeps cleared egress priority mappings in the hash as tombstones. Repeated set/clear cycles with distinct skb priorities accumulate mapping nodes until device teardown, causing memory leakage. This vulnerability is fixed by deleting mappings instead of keeping tombstones, using RCU protection for safe deallocation.(CVE-2026-46153)\n\nIn the Linux kernel, the following vulnerability has been resolved:\n\neventpoll: fix ep_remove struct eventpoll / struct file UAF\n\nep_remove() (via ep_remove_file()) cleared file-\u0026gt;f_ep under\nfile-\u0026gt;f_lock but then kept using @file inside the critical section\n(is_file_epoll(), hlist_del_rcu() through the head, spin_unlock).\nA concurrent __fput() taking the eventpoll_release() fastpath in\nthat window observed the transient NULL, skipped\neventpoll_release_file() and ran to f_op-\u0026gt;release / file_free().\n\nFor the epoll-watches-epoll case, f_op-\u0026gt;release is\nep_eventpoll_release() -\u0026gt; ep_clear_and_put() -\u0026gt; ep_free(), which\nkfree()s the watched struct eventpoll. Its embedded -\u0026gt;refs\nhlist_head is exactly where epi-\u0026gt;fllink.pprev points, so the\nsubsequent hlist_del_rcu()\u0026apos;s \u0026quot;*pprev = next\u0026quot; scribbles into freed\nkmalloc-192 memory.\n\nIn addition, struct file is SLAB_TYPESAFE_BY_RCU, so the slot\nbacking @file could be recycled by alloc_empty_file() --\nreinitializing f_lock and f_ep -- while ep_remove() is still\nnominally inside that lock. The upshot is an attacker-controllable\nkmem_cache_free() against the wrong slab cache.\n\nPin @file via epi_fget() at the top of ep_remove() and gate the\ncritical section on the pin succeeding. With the pin held @file\ncannot reach refcount zero, which holds __fput() off and\ntransitively keeps the watched struct eventpoll alive across the\nhlist_del_rcu() and the f_lock use, closing both UAFs.\n\nIf the pin fails @file has already reached refcount zero and its\n__fput() is in flight. Because we bailed before clearing f_ep,\nthat path takes the eventpoll_release() slow path into\neventpoll_release_file() and blocks on ep-\u0026gt;mtx until the waiter\nside\u0026apos;s ep_clear_and_put() drops it. The bailed epi\u0026apos;s share of\nep-\u0026gt;refcount stays intact, so the trailing ep_refcount_dec_and_test()\nin ep_clear_and_put() cannot free the eventpoll out from under\neventpoll_release_file(); the orphaned epi is then cleaned up\nthere.\n\nA successful pin also proves we are not racing\neventpoll_release_file() on this epi, so drop the now-redundant\nre-check of epi-\u0026gt;dying under f_lock. The cheap lockless\nREAD_ONCE(epi-\u0026gt;dying) fast-path bailout stays.(CVE-2026-46242)\n\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Fix dc_link NULL handling in HPD init  amdgpu_dm_hpd_init() may see connectors without a valid dc_link.  The code already checks dc_link for the polling decision, but later unconditionally dereferences it when setting up HPD interrupts.  Assign dc_link early and skip connectors where it is NULL.  Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_irq.c:940 amdgpu_dm_hpd_init() error: we previously assumed \u0026apos;dc_link\u0026apos; could be null (see line 931)  drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_irq.c     923                 /*     924                  * Analog connectors may be hot-plugged unlike other connector     925                  * types that don\u0026apos;t support HPD. Only poll analog connectors.     926                  */     927                 use_polling |=     928                         amdgpu_dm_connector-\u0026gt;dc_link \u0026amp;\u0026amp;                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The patch adds this NULL check but hopefully it can be removed      929                         dc_connector_supports_analog(amdgpu_dm_connector-\u0026gt;dc_link-\u0026gt;link_id.id);     930     931                 dc_link = amdgpu_dm_connector-\u0026gt;dc_link;  dc_link assigned here.      932     933                 /*     934                  * Get a base driver irq reference for hpd ints for the lifetime     935                  * of dm. Note that only hpd interrupt types are registered with     936                  * base driver; hpd_rx types aren\u0026apos;t. IOW, amdgpu_irq_get/put on     937                  * hpd_rx isn\u0026apos;t available. DM currently controls hpd_rx     938                  * explicitly with dc_interrupt_set()     939                  */ --\u0026gt; 940                 if (dc_link-\u0026gt;irq_source_hpd != DC_IRQ_SOURCE_INVALID) {                             ^^^^^^^^^^^^^^^^^^^^^^^ If it\u0026apos;s NULL then we are trouble because we dereference it here.      941                         irq_type = dc_link-\u0026gt;irq_source_hpd - DC_IRQ_SOURCE_HPD1;     942                         /*     943                          * TODO: There\u0026apos;s a mismatch between mode_info.num_hpd     944                          * and what bios reports as the # of connectors with hpd  The Linux kernel CVE team has assigned CVE-2026-46245 to this issue.(CVE-2026-46245)",
  "id": "OESA-2026-2676",
  "modified": "2026-08-06T11:11:36Z",
  "published": "2026-06-12T11:11:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2676"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39781"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71109"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23213"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23214"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31527"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31607"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31662"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31709"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31759"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43024"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43038"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43059"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43083"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43088"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43089"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43101"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43107"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43180"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43194"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43198"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43216"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43248"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43303"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43334"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43465"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43466"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45850"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45893"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45894"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45895"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45915"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45920"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45944"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45949"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45968"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45973"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45984"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46006"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46021"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46032"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46033"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46052"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46065"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46153"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46242"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46245"
    }
  ],
  "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-2025-39781",
    "CVE-2025-71109",
    "CVE-2026-23213",
    "CVE-2026-23214",
    "CVE-2026-31527",
    "CVE-2026-31607",
    "CVE-2026-31662",
    "CVE-2026-31709",
    "CVE-2026-31759",
    "CVE-2026-43024",
    "CVE-2026-43038",
    "CVE-2026-43059",
    "CVE-2026-43083",
    "CVE-2026-43088",
    "CVE-2026-43089",
    "CVE-2026-43101",
    "CVE-2026-43107",
    "CVE-2026-43180",
    "CVE-2026-43194",
    "CVE-2026-43198",
    "CVE-2026-43216",
    "CVE-2026-43248",
    "CVE-2026-43303",
    "CVE-2026-43334",
    "CVE-2026-43465",
    "CVE-2026-43466",
    "CVE-2026-45850",
    "CVE-2026-45893",
    "CVE-2026-45894",
    "CVE-2026-45895",
    "CVE-2026-45915",
    "CVE-2026-45920",
    "CVE-2026-45944",
    "CVE-2026-45949",
    "CVE-2026-45968",
    "CVE-2026-45973",
    "CVE-2026-45984",
    "CVE-2026-46006",
    "CVE-2026-46021",
    "CVE-2026-46032",
    "CVE-2026-46033",
    "CVE-2026-46052",
    "CVE-2026-46065",
    "CVE-2026-46153",
    "CVE-2026-46242",
    "CVE-2026-46245"
  ]
}

OPENSUSE-SU-2026:21388-1

Vulnerability from csaf_opensuse - Published: 2026-07-21 08:27 - Updated: 2026-10-20 09:52

Summary

Security update for the Linux Kernel

Severity

Important

Scope

255 vulnerabilities in this advisory, including CVE-2026-43248.

CVE-2026-43248

5.5 (Medium)


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

Recommended: 136 products

Open the full advisory

RHSA-2026:67470

Vulnerability from csaf_opensuse - Published: 2026-09-15 08:31 - Updated: 2026-11-02 01:25

Summary

Red Hat Security Advisory: kernel security, bug fix, and enhancement update

Severity

Important

Scope

7 vulnerabilities in this advisory, including CVE-2026-43248.

CVE-2026-43248

A flaw was found in the Linux kernel's vhost subsystem. Specifically, a bug in the `vdpa_sim` component allows for an out-of-bounds write when a valid ASID (Address Space ID) is incorrectly assigned to a vDPA (virtio Data Path Acceleration) group. This could lead to memory corruption, potentially resulting in a denial of service or other system instability.

7.3 (High)


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

Fixed: 303 products

https://access.redhat.com/errata/RHSA-2026:67470

Open the full advisory

RHSA-2026:67471

Vulnerability from csaf_opensuse - Published: 2026-09-15 08:14 - Updated: 2026-11-02 01:25

Summary

Red Hat Security Advisory: kernel security, bug fix, and enhancement update

Severity

Important

Scope

25 vulnerabilities in this advisory, including CVE-2026-43248.

CVE-2026-43248

7.3 (High)


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

Fixed: 309 products

https://access.redhat.com/errata/RHSA-2026:67471

Open the full advisory

SUSE-SU-2026:22742-1

Vulnerability from csaf_suse - Published: 2026-07-21 08:27 - Updated: 2026-10-20 09:48

Summary

Security update for the Linux Kernel

Severity

Important

Scope

255 vulnerabilities in this advisory, including CVE-2026-43248.

CVE-2026-43248

5.5 (Medium)


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

Recommended: 8 products

Open the full advisory

SUSE-SU-2026:22769-1

Vulnerability from csaf_suse - Published: 2026-07-21 08:27 - Updated: 2026-10-20 09:48

Summary

Security update for the Linux Kernel

Severity

Important

Scope

255 vulnerabilities in this advisory, including CVE-2026-43248.

CVE-2026-43248

5.5 (Medium)


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

Recommended: 28 products

Open the full advisory

SUSE-SU-2026:22809-1

Vulnerability from csaf_suse - Published: 2026-07-22 13:38 - Updated: 2026-09-20 18:40

Summary

Security update for the Linux Kernel

Severity

Important

Scope

87 vulnerabilities in this advisory, including CVE-2026-43248.

CVE-2026-43248

5.5 (Medium)


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

Recommended: 4 products

Open the full advisory

SUSE-SU-2026:22810-1

Vulnerability from csaf_suse - Published: 2026-07-22 13:52 - Updated: 2026-09-20 18:40

Summary

Security update for the Linux Kernel

Severity

Important

Scope

87 vulnerabilities in this advisory, including CVE-2026-43248.

CVE-2026-43248

5.5 (Medium)


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

Recommended: 9 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.

Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

Order JSON

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

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-43248 (GCVE-0-2026-43248)

OESA-2026-2675 (CVE-2025-38389)

OESA-2026-2676 (CVE-2025-39781)

Tags

Sightings

Nomenclature

Vulnerability timeline

Related by attack behaviour