CVE-2023-52893 (GCVE-0-2023-52893)

Vulnerability from cvelistv5 – Published: 2024-08-21 06:10 – Updated: 2026-05-11 19:35

Title

gsmi: fix null-deref in gsmi_get_variable

Summary

In the Linux kernel, the following vulnerability has been resolved: gsmi: fix null-deref in gsmi_get_variable We can get EFI variables without fetching the attribute, so we must allow for that in gsmi. commit 859748255b43 ("efi: pstore: Omit efivars caching EFI varstore access layer") added a new get_variable call with attr=NULL, which triggers panic in gsmi.

Severity

No CVSS data available.

SSVC

Exploitation: none Automatable: no Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2024-09-10 16:03 UTC

Assigner

Linux mitre root

References

7 references

URL	Tags
https://git.kernel.org/stable/c/ee5763ef829bd9230…
https://git.kernel.org/stable/c/32313c11bdc8a02c5…
https://git.kernel.org/stable/c/ffef77794fb5f1245…
https://git.kernel.org/stable/c/ae2a9dcc8caa60b1e…
https://git.kernel.org/stable/c/eb0421d90f916dffe…
https://git.kernel.org/stable/c/6646d769fdb0ce431…
https://git.kernel.org/stable/c/a769b05eeed7accc4…

Impacted products

2 products

Vendor	Product	Version	CPE status
Linux	Linux	Affected: 74c5b31c6618f01079212332b2e5f6c42f2d6307 , < ee5763ef829bd923033510de6d1df7c73f085e4b (git) Affected: 74c5b31c6618f01079212332b2e5f6c42f2d6307 , < 32313c11bdc8a02c577abaf865be3664ab30410a (git) Affected: 74c5b31c6618f01079212332b2e5f6c42f2d6307 , < ffef77794fb5f1245c3249b86342bad2299accb5 (git) Affected: 74c5b31c6618f01079212332b2e5f6c42f2d6307 , < ae2a9dcc8caa60b1e14671294e5ec902ea5d1dfd (git) Affected: 74c5b31c6618f01079212332b2e5f6c42f2d6307 , < eb0421d90f916dffe96b4c049ddf01c0c50620d2 (git) Affected: 74c5b31c6618f01079212332b2e5f6c42f2d6307 , < 6646d769fdb0ce4318ef9afd127f8526d1ca8393 (git) Affected: 74c5b31c6618f01079212332b2e5f6c42f2d6307 , < a769b05eeed7accc4019a1ed9799dd72067f1ce8 (git)	guessed
Linux	Linux	Affected: 3.0 Unaffected: 0 , < 3.0 (semver) Unaffected: 4.14.304 , ≤ 4.14.* (semver) Unaffected: 4.19.271 , ≤ 4.19.* (semver) Unaffected: 5.4.230 , ≤ 5.4.* (semver) Unaffected: 5.10.165 , ≤ 5.10.* (semver) Unaffected: 5.15.90 , ≤ 5.15.* (semver) Unaffected: 6.1.8 , ≤ 6.1.* (semver) Unaffected: 6.2 , ≤ * (original_commit_for_fix)	guessed

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2023-52893",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-09-10T16:03:53.149409Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2024-09-12T17:33:14.166Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/firmware/google/gsmi.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "ee5763ef829bd923033510de6d1df7c73f085e4b",
              "status": "affected",
              "version": "74c5b31c6618f01079212332b2e5f6c42f2d6307",
              "versionType": "git"
            },
            {
              "lessThan": "32313c11bdc8a02c577abaf865be3664ab30410a",
              "status": "affected",
              "version": "74c5b31c6618f01079212332b2e5f6c42f2d6307",
              "versionType": "git"
            },
            {
              "lessThan": "ffef77794fb5f1245c3249b86342bad2299accb5",
              "status": "affected",
              "version": "74c5b31c6618f01079212332b2e5f6c42f2d6307",
              "versionType": "git"
            },
            {
              "lessThan": "ae2a9dcc8caa60b1e14671294e5ec902ea5d1dfd",
              "status": "affected",
              "version": "74c5b31c6618f01079212332b2e5f6c42f2d6307",
              "versionType": "git"
            },
            {
              "lessThan": "eb0421d90f916dffe96b4c049ddf01c0c50620d2",
              "status": "affected",
              "version": "74c5b31c6618f01079212332b2e5f6c42f2d6307",
              "versionType": "git"
            },
            {
              "lessThan": "6646d769fdb0ce4318ef9afd127f8526d1ca8393",
              "status": "affected",
              "version": "74c5b31c6618f01079212332b2e5f6c42f2d6307",
              "versionType": "git"
            },
            {
              "lessThan": "a769b05eeed7accc4019a1ed9799dd72067f1ce8",
              "status": "affected",
              "version": "74c5b31c6618f01079212332b2e5f6c42f2d6307",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/firmware/google/gsmi.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "3.0"
            },
            {
              "lessThan": "3.0",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "4.14.*",
              "status": "unaffected",
              "version": "4.14.304",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "4.19.*",
              "status": "unaffected",
              "version": "4.19.271",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.4.*",
              "status": "unaffected",
              "version": "5.4.230",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.10.*",
              "status": "unaffected",
              "version": "5.10.165",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.15.*",
              "status": "unaffected",
              "version": "5.15.90",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.1.*",
              "status": "unaffected",
              "version": "6.1.8",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.2",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "4.14.304",
                  "versionStartIncluding": "3.0",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "4.19.271",
                  "versionStartIncluding": "3.0",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.4.230",
                  "versionStartIncluding": "3.0",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.10.165",
                  "versionStartIncluding": "3.0",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.15.90",
                  "versionStartIncluding": "3.0",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.1.8",
                  "versionStartIncluding": "3.0",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.2",
                  "versionStartIncluding": "3.0",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ngsmi: fix null-deref in gsmi_get_variable\n\nWe can get EFI variables without fetching the attribute, so we must\nallow for that in gsmi.\n\ncommit 859748255b43 (\"efi: pstore: Omit efivars caching EFI varstore\naccess layer\") added a new get_variable call with attr=NULL, which\ntriggers panic in gsmi."
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-05-11T19:35:00.760Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/ee5763ef829bd923033510de6d1df7c73f085e4b"
        },
        {
          "url": "https://git.kernel.org/stable/c/32313c11bdc8a02c577abaf865be3664ab30410a"
        },
        {
          "url": "https://git.kernel.org/stable/c/ffef77794fb5f1245c3249b86342bad2299accb5"
        },
        {
          "url": "https://git.kernel.org/stable/c/ae2a9dcc8caa60b1e14671294e5ec902ea5d1dfd"
        },
        {
          "url": "https://git.kernel.org/stable/c/eb0421d90f916dffe96b4c049ddf01c0c50620d2"
        },
        {
          "url": "https://git.kernel.org/stable/c/6646d769fdb0ce4318ef9afd127f8526d1ca8393"
        },
        {
          "url": "https://git.kernel.org/stable/c/a769b05eeed7accc4019a1ed9799dd72067f1ce8"
        }
      ],
      "title": "gsmi: fix null-deref in gsmi_get_variable",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2023-52893",
    "datePublished": "2024-08-21T06:10:33.043Z",
    "dateReserved": "2024-08-21T06:07:11.013Z",
    "dateUpdated": "2026-05-11T19:35:00.760Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2023-52893",
      "date": "2026-09-26",
      "epss": "0.0024",
      "percentile": "0.13539"
    },
    "fkie_nvd": {
      "configurations": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "matchCriteriaId": "7484020E-A2C4-48A2-9137-7AA65DB251B7",
                  "versionEndExcluding": "4.14.304",
                  "versionStartIncluding": "3.0",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "matchCriteriaId": "D86DA289-B5BC-4629-BD56-AB453D481393",
                  "versionEndExcluding": "4.19.271",
                  "versionStartIncluding": "4.15",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "matchCriteriaId": "9DB7398D-9781-49C5-B2AE-1969B694B614",
                  "versionEndExcluding": "5.4.230",
                  "versionStartIncluding": "4.20",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "matchCriteriaId": "C6002D5B-9B6A-4788-B943-E3EE01E01303",
                  "versionEndExcluding": "5.10.165",
                  "versionStartIncluding": "5.5",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "matchCriteriaId": "E995CDA5-7223-4FDB-BAD3-81B22C763A43",
                  "versionEndExcluding": "5.15.90",
                  "versionStartIncluding": "5.11",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "matchCriteriaId": "A6AFE6C9-3F59-4711-B2CF-7D6682FF6BD0",
                  "versionEndExcluding": "6.1.8",
                  "versionStartIncluding": "5.16",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:6.2:rc1:*:*:*:*:*:*",
                  "matchCriteriaId": "FF501633-2F44-4913-A8EE-B021929F49F6",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:6.2:rc2:*:*:*:*:*:*",
                  "matchCriteriaId": "2BDA597B-CAC1-4DF0-86F0-42E142C654E9",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:6.2:rc3:*:*:*:*:*:*",
                  "matchCriteriaId": "725C78C9-12CE-406F-ABE8-0813A01D66E8",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:6.2:rc4:*:*:*:*:*:*",
                  "matchCriteriaId": "A127C155-689C-4F67-B146-44A57F4BFD85",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ngsmi: fix null-deref in gsmi_get_variable\n\nWe can get EFI variables without fetching the attribute, so we must\nallow for that in gsmi.\n\ncommit 859748255b43 (\"efi: pstore: Omit efivars caching EFI varstore\naccess layer\") added a new get_variable call with attr=NULL, which\ntriggers panic in gsmi."
        },
        {
          "lang": "es",
          "value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: gsmi: corrige null-deref en gsmi_get_variable Podemos obtener variables EFI sin recuperar el atributo, por lo que debemos permitir eso en gsmi. commit 859748255b43 (\"efi: pstore: Omit efivars caching EFI varstore access Layer\") agreg\u00f3 una nueva llamada get_variable con attr=NULL, lo que desencadena p\u00e1nico en gsmi."
        }
      ],
      "id": "CVE-2023-52893",
      "lastModified": "2024-09-11T16:24:49.853",
      "metrics": {
        "cvssMetricV31": [
          {
            "cvssData": {
              "attackComplexity": "LOW",
              "attackVector": "LOCAL",
              "availabilityImpact": "HIGH",
              "baseScore": 5.5,
              "baseSeverity": "MEDIUM",
              "confidentialityImpact": "NONE",
              "integrityImpact": "NONE",
              "privilegesRequired": "LOW",
              "scope": "UNCHANGED",
              "userInteraction": "NONE",
              "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
              "version": "3.1"
            },
            "exploitabilityScore": 1.8,
            "impactScore": 3.6,
            "source": "nvd@nist.gov",
            "type": "Primary"
          }
        ]
      },
      "published": "2024-08-21T07:15:05.880",
      "references": [
        {
          "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
          "tags": [
            "Patch"
          ],
          "url": "https://git.kernel.org/stable/c/32313c11bdc8a02c577abaf865be3664ab30410a"
        },
        {
          "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
          "tags": [
            "Patch"
          ],
          "url": "https://git.kernel.org/stable/c/6646d769fdb0ce4318ef9afd127f8526d1ca8393"
        },
        {
          "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
          "tags": [
            "Patch"
          ],
          "url": "https://git.kernel.org/stable/c/a769b05eeed7accc4019a1ed9799dd72067f1ce8"
        },
        {
          "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
          "tags": [
            "Patch"
          ],
          "url": "https://git.kernel.org/stable/c/ae2a9dcc8caa60b1e14671294e5ec902ea5d1dfd"
        },
        {
          "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
          "tags": [
            "Patch"
          ],
          "url": "https://git.kernel.org/stable/c/eb0421d90f916dffe96b4c049ddf01c0c50620d2"
        },
        {
          "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
          "tags": [
            "Patch"
          ],
          "url": "https://git.kernel.org/stable/c/ee5763ef829bd923033510de6d1df7c73f085e4b"
        },
        {
          "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
          "tags": [
            "Patch"
          ],
          "url": "https://git.kernel.org/stable/c/ffef77794fb5f1245c3249b86342bad2299accb5"
        }
      ],
      "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "vulnStatus": "Analyzed",
      "weaknesses": [
        {
          "description": [
            {
              "lang": "en",
              "value": "CWE-476"
            }
          ],
          "source": "nvd@nist.gov",
          "type": "Primary"
        }
      ]
    },
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "defaultStatus": "unaffected",
                "product": "Linux",
                "programFiles": [
                  "drivers/firmware/google/gsmi.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "lessThan": "ee5763ef829bd923033510de6d1df7c73f085e4b",
                    "status": "affected",
                    "version": "74c5b31c6618f01079212332b2e5f6c42f2d6307",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "32313c11bdc8a02c577abaf865be3664ab30410a",
                    "status": "affected",
                    "version": "74c5b31c6618f01079212332b2e5f6c42f2d6307",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "ffef77794fb5f1245c3249b86342bad2299accb5",
                    "status": "affected",
                    "version": "74c5b31c6618f01079212332b2e5f6c42f2d6307",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "ae2a9dcc8caa60b1e14671294e5ec902ea5d1dfd",
                    "status": "affected",
                    "version": "74c5b31c6618f01079212332b2e5f6c42f2d6307",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "eb0421d90f916dffe96b4c049ddf01c0c50620d2",
                    "status": "affected",
                    "version": "74c5b31c6618f01079212332b2e5f6c42f2d6307",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "6646d769fdb0ce4318ef9afd127f8526d1ca8393",
                    "status": "affected",
                    "version": "74c5b31c6618f01079212332b2e5f6c42f2d6307",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "a769b05eeed7accc4019a1ed9799dd72067f1ce8",
                    "status": "affected",
                    "version": "74c5b31c6618f01079212332b2e5f6c42f2d6307",
                    "versionType": "git"
                  }
                ]
              },
              {
                "defaultStatus": "affected",
                "product": "Linux",
                "programFiles": [
                  "drivers/firmware/google/gsmi.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "status": "affected",
                    "version": "3.0"
                  },
                  {
                    "lessThan": "3.0",
                    "status": "unaffected",
                    "version": "0",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "4.14.*",
                    "status": "unaffected",
                    "version": "4.14.304",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "4.19.*",
                    "status": "unaffected",
                    "version": "4.19.271",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "5.4.*",
                    "status": "unaffected",
                    "version": "5.4.230",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "5.10.*",
                    "status": "unaffected",
                    "version": "5.10.165",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "5.15.*",
                    "status": "unaffected",
                    "version": "5.15.90",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.1.*",
                    "status": "unaffected",
                    "version": "6.1.8",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "*",
                    "status": "unaffected",
                    "version": "6.2",
                    "versionType": "original_commit_for_fix"
                  }
                ]
              }
            ],
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
          }
        ],
        "configurations": [
          {
            "nodes": [
              {
                "cpeMatch": [
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "7484020E-A2C4-48A2-9137-7AA65DB251B7",
                    "versionEndExcluding": "4.14.304",
                    "versionStartIncluding": "3.0",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "D86DA289-B5BC-4629-BD56-AB453D481393",
                    "versionEndExcluding": "4.19.271",
                    "versionStartIncluding": "4.15",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "9DB7398D-9781-49C5-B2AE-1969B694B614",
                    "versionEndExcluding": "5.4.230",
                    "versionStartIncluding": "4.20",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "C6002D5B-9B6A-4788-B943-E3EE01E01303",
                    "versionEndExcluding": "5.10.165",
                    "versionStartIncluding": "5.5",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "E995CDA5-7223-4FDB-BAD3-81B22C763A43",
                    "versionEndExcluding": "5.15.90",
                    "versionStartIncluding": "5.11",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "A6AFE6C9-3F59-4711-B2CF-7D6682FF6BD0",
                    "versionEndExcluding": "6.1.8",
                    "versionStartIncluding": "5.16",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:6.2:rc1:*:*:*:*:*:*",
                    "matchCriteriaId": "FF501633-2F44-4913-A8EE-B021929F49F6",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:6.2:rc2:*:*:*:*:*:*",
                    "matchCriteriaId": "2BDA597B-CAC1-4DF0-86F0-42E142C654E9",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:6.2:rc3:*:*:*:*:*:*",
                    "matchCriteriaId": "725C78C9-12CE-406F-ABE8-0813A01D66E8",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:6.2:rc4:*:*:*:*:*:*",
                    "matchCriteriaId": "A127C155-689C-4F67-B146-44A57F4BFD85",
                    "vulnerable": true
                  }
                ],
                "negate": false,
                "operator": "OR"
              }
            ]
          }
        ],
        "cveTags": [],
        "descriptions": [
          {
            "lang": "en",
            "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ngsmi: fix null-deref in gsmi_get_variable\n\nWe can get EFI variables without fetching the attribute, so we must\nallow for that in gsmi.\n\ncommit 859748255b43 (\"efi: pstore: Omit efivars caching EFI varstore\naccess layer\") added a new get_variable call with attr=NULL, which\ntriggers panic in gsmi."
          },
          {
            "lang": "es",
            "value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: gsmi: corrige null-deref en gsmi_get_variable Podemos obtener variables EFI sin recuperar el atributo, por lo que debemos permitir eso en gsmi. commit 859748255b43 (\"efi: pstore: Omit efivars caching EFI varstore access Layer\") agreg\u00f3 una nueva llamada get_variable con attr=NULL, lo que desencadena p\u00e1nico en gsmi."
          }
        ],
        "id": "CVE-2023-52893",
        "lastModified": "2026-06-17T06:43:52.630",
        "metrics": {
          "cvssMetricV31": [
            {
              "cvssData": {
                "attackComplexity": "LOW",
                "attackVector": "LOCAL",
                "availabilityImpact": "HIGH",
                "baseScore": 5.5,
                "baseSeverity": "MEDIUM",
                "confidentialityImpact": "NONE",
                "integrityImpact": "NONE",
                "privilegesRequired": "LOW",
                "scope": "UNCHANGED",
                "userInteraction": "NONE",
                "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
                "version": "3.1"
              },
              "exploitabilityScore": 1.8,
              "impactScore": 3.6,
              "source": "nvd@nist.gov",
              "type": "Primary"
            }
          ],
          "ssvcV203": [
            {
              "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "ssvcData": {
                "id": "CVE-2023-52893",
                "options": [
                  {
                    "exploitation": "none"
                  },
                  {
                    "automatable": "no"
                  },
                  {
                    "technicalImpact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-09-10T16:03:53.149409Z",
                "version": "2.0.3"
              }
            }
          ]
        },
        "published": "2024-08-21T07:15:05.880",
        "references": [
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/32313c11bdc8a02c577abaf865be3664ab30410a"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/6646d769fdb0ce4318ef9afd127f8526d1ca8393"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/a769b05eeed7accc4019a1ed9799dd72067f1ce8"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/ae2a9dcc8caa60b1e14671294e5ec902ea5d1dfd"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/eb0421d90f916dffe96b4c049ddf01c0c50620d2"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/ee5763ef829bd923033510de6d1df7c73f085e4b"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/ffef77794fb5f1245c3249b86342bad2299accb5"
          }
        ],
        "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "vulnStatus": "Analyzed",
        "weaknesses": [
          {
            "description": [
              {
                "lang": "en",
                "value": "CWE-476"
              }
            ],
            "source": "nvd@nist.gov",
            "type": "Primary"
          }
        ]
      }
    },
    "redhat_vex": {
      "aggregate_severity": "Moderate",
      "current_release_date": "2026-02-02T10:58:37+00:00",
      "cve": "CVE-2023-52893",
      "id": "CVE-2023-52893",
      "initial_release_date": "2023-01-01T00:00:00+00:00",
      "product_status:known_not_affected": "198",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "kernel: gsmi: fix null-deref in gsmi_get_variable",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2023/cve-2023-52893.json",
      "version": "3"
    },
    "suse_vex": {
      "aggregate_severity": "moderate",
      "current_release_date": "2026-09-11T02:24:22Z",
      "cve": "CVE-2023-52893",
      "id": "CVE-2023-52893",
      "initial_release_date": "2024-08-22T03:14:47Z",
      "product_status:known_affected": "493",
      "product_status:known_not_affected": "63",
      "product_status:recommended": "495",
      "source": "SUSE CSAF VEX",
      "status": "interim",
      "title": "SUSE CVE CVE-2023-52893",
      "url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2023-52893.json",
      "version": "56"
    },
    "vulnrichment": {
      "containers": {
        "adp": [
          {
            "metrics": [
              {
                "other": {
                  "content": {
                    "id": "CVE-2023-52893",
                    "options": [
                      {
                        "Exploitation": "none"
                      },
                      {
                        "Automatable": "no"
                      },
                      {
                        "Technical Impact": "partial"
                      }
                    ],
                    "role": "CISA Coordinator",
                    "timestamp": "2024-09-10T16:03:53.149409Z",
                    "version": "2.0.3"
                  },
                  "type": "ssvc"
                }
              }
            ],
            "providerMetadata": {
              "dateUpdated": "2024-09-11T12:42:18.608Z",
              "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "shortName": "CISA-ADP"
            },
            "title": "CISA ADP Vulnrichment"
          }
        ],
        "cna": {
          "affected": [
            {
              "defaultStatus": "unaffected",
              "product": "Linux",
              "programFiles": [
                "drivers/firmware/google/gsmi.c"
              ],
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "vendor": "Linux",
              "versions": [
                {
                  "lessThan": "ee5763ef829bd923033510de6d1df7c73f085e4b",
                  "status": "affected",
                  "version": "74c5b31c6618f01079212332b2e5f6c42f2d6307",
                  "versionType": "git"
                },
                {
                  "lessThan": "32313c11bdc8a02c577abaf865be3664ab30410a",
                  "status": "affected",
                  "version": "74c5b31c6618f01079212332b2e5f6c42f2d6307",
                  "versionType": "git"
                },
                {
                  "lessThan": "ffef77794fb5f1245c3249b86342bad2299accb5",
                  "status": "affected",
                  "version": "74c5b31c6618f01079212332b2e5f6c42f2d6307",
                  "versionType": "git"
                },
                {
                  "lessThan": "ae2a9dcc8caa60b1e14671294e5ec902ea5d1dfd",
                  "status": "affected",
                  "version": "74c5b31c6618f01079212332b2e5f6c42f2d6307",
                  "versionType": "git"
                },
                {
                  "lessThan": "eb0421d90f916dffe96b4c049ddf01c0c50620d2",
                  "status": "affected",
                  "version": "74c5b31c6618f01079212332b2e5f6c42f2d6307",
                  "versionType": "git"
                },
                {
                  "lessThan": "6646d769fdb0ce4318ef9afd127f8526d1ca8393",
                  "status": "affected",
                  "version": "74c5b31c6618f01079212332b2e5f6c42f2d6307",
                  "versionType": "git"
                },
                {
                  "lessThan": "a769b05eeed7accc4019a1ed9799dd72067f1ce8",
                  "status": "affected",
                  "version": "74c5b31c6618f01079212332b2e5f6c42f2d6307",
                  "versionType": "git"
                }
              ]
            },
            {
              "defaultStatus": "affected",
              "product": "Linux",
              "programFiles": [
                "drivers/firmware/google/gsmi.c"
              ],
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "vendor": "Linux",
              "versions": [
                {
                  "status": "affected",
                  "version": "3.0"
                },
                {
                  "lessThan": "3.0",
                  "status": "unaffected",
                  "version": "0",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "4.14.*",
                  "status": "unaffected",
                  "version": "4.14.304",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "4.19.*",
                  "status": "unaffected",
                  "version": "4.19.271",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "5.4.*",
                  "status": "unaffected",
                  "version": "5.4.230",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "5.10.*",
                  "status": "unaffected",
                  "version": "5.10.165",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "5.15.*",
                  "status": "unaffected",
                  "version": "5.15.90",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "6.1.*",
                  "status": "unaffected",
                  "version": "6.1.8",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "*",
                  "status": "unaffected",
                  "version": "6.2",
                  "versionType": "original_commit_for_fix"
                }
              ]
            }
          ],
          "descriptions": [
            {
              "lang": "en",
              "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ngsmi: fix null-deref in gsmi_get_variable\n\nWe can get EFI variables without fetching the attribute, so we must\nallow for that in gsmi.\n\ncommit 859748255b43 (\"efi: pstore: Omit efivars caching EFI varstore\naccess layer\") added a new get_variable call with attr=NULL, which\ntriggers panic in gsmi."
            }
          ],
          "providerMetadata": {
            "dateUpdated": "2024-12-19T08:28:01.009Z",
            "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "shortName": "Linux"
          },
          "references": [
            {
              "url": "https://git.kernel.org/stable/c/ee5763ef829bd923033510de6d1df7c73f085e4b"
            },
            {
              "url": "https://git.kernel.org/stable/c/32313c11bdc8a02c577abaf865be3664ab30410a"
            },
            {
              "url": "https://git.kernel.org/stable/c/ffef77794fb5f1245c3249b86342bad2299accb5"
            },
            {
              "url": "https://git.kernel.org/stable/c/ae2a9dcc8caa60b1e14671294e5ec902ea5d1dfd"
            },
            {
              "url": "https://git.kernel.org/stable/c/eb0421d90f916dffe96b4c049ddf01c0c50620d2"
            },
            {
              "url": "https://git.kernel.org/stable/c/6646d769fdb0ce4318ef9afd127f8526d1ca8393"
            },
            {
              "url": "https://git.kernel.org/stable/c/a769b05eeed7accc4019a1ed9799dd72067f1ce8"
            }
          ],
          "title": "gsmi: fix null-deref in gsmi_get_variable",
          "x_generator": {
            "engine": "bippy-5f407fcff5a0"
          }
        }
      },
      "cveMetadata": {
        "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "assignerShortName": "Linux",
        "cveId": "CVE-2023-52893",
        "datePublished": "2024-08-21T06:10:33.043Z",
        "dateReserved": "2024-08-21T06:07:11.013Z",
        "dateUpdated": "2024-12-19T08:28:01.009Z",
        "state": "PUBLISHED"
      },
      "dataType": "CVE_RECORD",
      "dataVersion": "5.1"
    }
  }
}

FKIE_CVE-2023-52893

Vulnerability from fkie_nvd - Published: 2024-08-21 07:15 - Updated: 2026-06-17 06:43

Severity

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

Summary

References

URL	Tags
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/32313c11bdc8a02c577abaf865be3664ab30410a	Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/6646d769fdb0ce4318ef9afd127f8526d1ca8393	Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/a769b05eeed7accc4019a1ed9799dd72067f1ce8	Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/ae2a9dcc8caa60b1e14671294e5ec902ea5d1dfd	Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/eb0421d90f916dffe96b4c049ddf01c0c50620d2	Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/ee5763ef829bd923033510de6d1df7c73f085e4b	Patch
416baaa9-dc9f-4396-8d5f-8c081fb06d67	https://git.kernel.org/stable/c/ffef77794fb5f1245c3249b86342bad2299accb5	Patch

Impacted products

Vendor	Product	Version
linux	linux_kernel	*
linux	linux_kernel	*
linux	linux_kernel	*
linux	linux_kernel	*
linux	linux_kernel	*
linux	linux_kernel	*
linux	linux_kernel	6.2
linux	linux_kernel	6.2
linux	linux_kernel	6.2
linux	linux_kernel	6.2

JSON

To clipboard

{
  "affected": [
    {
      "affectedData": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/firmware/google/gsmi.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "ee5763ef829bd923033510de6d1df7c73f085e4b",
              "status": "affected",
              "version": "74c5b31c6618f01079212332b2e5f6c42f2d6307",
              "versionType": "git"
            },
            {
              "lessThan": "32313c11bdc8a02c577abaf865be3664ab30410a",
              "status": "affected",
              "version": "74c5b31c6618f01079212332b2e5f6c42f2d6307",
              "versionType": "git"
            },
            {
              "lessThan": "ffef77794fb5f1245c3249b86342bad2299accb5",
              "status": "affected",
              "version": "74c5b31c6618f01079212332b2e5f6c42f2d6307",
              "versionType": "git"
            },
            {
              "lessThan": "ae2a9dcc8caa60b1e14671294e5ec902ea5d1dfd",
              "status": "affected",
              "version": "74c5b31c6618f01079212332b2e5f6c42f2d6307",
              "versionType": "git"
            },
            {
              "lessThan": "eb0421d90f916dffe96b4c049ddf01c0c50620d2",
              "status": "affected",
              "version": "74c5b31c6618f01079212332b2e5f6c42f2d6307",
              "versionType": "git"
            },
            {
              "lessThan": "6646d769fdb0ce4318ef9afd127f8526d1ca8393",
              "status": "affected",
              "version": "74c5b31c6618f01079212332b2e5f6c42f2d6307",
              "versionType": "git"
            },
            {
              "lessThan": "a769b05eeed7accc4019a1ed9799dd72067f1ce8",
              "status": "affected",
              "version": "74c5b31c6618f01079212332b2e5f6c42f2d6307",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/firmware/google/gsmi.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "3.0"
            },
            {
              "lessThan": "3.0",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "4.14.*",
              "status": "unaffected",
              "version": "4.14.304",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "4.19.*",
              "status": "unaffected",
              "version": "4.19.271",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.4.*",
              "status": "unaffected",
              "version": "5.4.230",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.10.*",
              "status": "unaffected",
              "version": "5.10.165",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.15.*",
              "status": "unaffected",
              "version": "5.15.90",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.1.*",
              "status": "unaffected",
              "version": "6.1.8",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.2",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
    }
  ],
  "configurations": [
    {
      "nodes": [
        {
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "7484020E-A2C4-48A2-9137-7AA65DB251B7",
              "versionEndExcluding": "4.14.304",
              "versionStartIncluding": "3.0",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "D86DA289-B5BC-4629-BD56-AB453D481393",
              "versionEndExcluding": "4.19.271",
              "versionStartIncluding": "4.15",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "9DB7398D-9781-49C5-B2AE-1969B694B614",
              "versionEndExcluding": "5.4.230",
              "versionStartIncluding": "4.20",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "C6002D5B-9B6A-4788-B943-E3EE01E01303",
              "versionEndExcluding": "5.10.165",
              "versionStartIncluding": "5.5",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "E995CDA5-7223-4FDB-BAD3-81B22C763A43",
              "versionEndExcluding": "5.15.90",
              "versionStartIncluding": "5.11",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "A6AFE6C9-3F59-4711-B2CF-7D6682FF6BD0",
              "versionEndExcluding": "6.1.8",
              "versionStartIncluding": "5.16",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:6.2:rc1:*:*:*:*:*:*",
              "matchCriteriaId": "FF501633-2F44-4913-A8EE-B021929F49F6",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:6.2:rc2:*:*:*:*:*:*",
              "matchCriteriaId": "2BDA597B-CAC1-4DF0-86F0-42E142C654E9",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:6.2:rc3:*:*:*:*:*:*",
              "matchCriteriaId": "725C78C9-12CE-406F-ABE8-0813A01D66E8",
              "vulnerable": true
            },
            {
              "criteria": "cpe:2.3:o:linux:linux_kernel:6.2:rc4:*:*:*:*:*:*",
              "matchCriteriaId": "A127C155-689C-4F67-B146-44A57F4BFD85",
              "vulnerable": true
            }
          ],
          "negate": false,
          "operator": "OR"
        }
      ]
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\ngsmi: fix null-deref in gsmi_get_variable\n\nWe can get EFI variables without fetching the attribute, so we must\nallow for that in gsmi.\n\ncommit 859748255b43 (\"efi: pstore: Omit efivars caching EFI varstore\naccess layer\") added a new get_variable call with attr=NULL, which\ntriggers panic in gsmi."
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: gsmi: corrige null-deref en gsmi_get_variable Podemos obtener variables EFI sin recuperar el atributo, por lo que debemos permitir eso en gsmi. commit 859748255b43 (\"efi: pstore: Omit efivars caching EFI varstore access Layer\") agreg\u00f3 una nueva llamada get_variable con attr=NULL, lo que desencadena p\u00e1nico en gsmi."
    }
  ],
  "id": "CVE-2023-52893",
  "lastModified": "2026-06-17T06:43:52.630",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "LOCAL",
          "availabilityImpact": "HIGH",
          "baseScore": 5.5,
          "baseSeverity": "MEDIUM",
          "confidentialityImpact": "NONE",
          "integrityImpact": "NONE",
          "privilegesRequired": "LOW",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 1.8,
        "impactScore": 3.6,
        "source": "nvd@nist.gov",
        "type": "Primary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2023-52893",
          "options": [
            {
              "exploitation": "none"
            },
            {
              "automatable": "no"
            },
            {
              "technicalImpact": "partial"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2024-09-10T16:03:53.149409Z",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2024-08-21T07:15:05.880",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/32313c11bdc8a02c577abaf865be3664ab30410a"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/6646d769fdb0ce4318ef9afd127f8526d1ca8393"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/a769b05eeed7accc4019a1ed9799dd72067f1ce8"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/ae2a9dcc8caa60b1e14671294e5ec902ea5d1dfd"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/eb0421d90f916dffe96b4c049ddf01c0c50620d2"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/ee5763ef829bd923033510de6d1df7c73f085e4b"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "tags": [
        "Patch"
      ],
      "url": "https://git.kernel.org/stable/c/ffef77794fb5f1245c3249b86342bad2299accb5"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Analyzed",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-476"
        }
      ],
      "source": "nvd@nist.gov",
      "type": "Primary"
    }
  ]
}

GHSA-5C27-9GP6-68Q5

Vulnerability from github – Published: 2024-08-21 09:31 – Updated: 2024-09-11 18:31

Details

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

gsmi: fix null-deref in gsmi_get_variable

We can get EFI variables without fetching the attribute, so we must allow for that in gsmi.

commit 859748255b43 ("efi: pstore: Omit efivars caching EFI varstore access layer") added a new get_variable call with attr=NULL, which triggers panic in gsmi.

Severity

5.5 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2023-52893"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-21T07:15:05Z",
    "severity": "MODERATE"
  },
  "details": "In the Linux kernel, the following vulnerability has been resolved:\n\ngsmi: fix null-deref in gsmi_get_variable\n\nWe can get EFI variables without fetching the attribute, so we must\nallow for that in gsmi.\n\ncommit 859748255b43 (\"efi: pstore: Omit efivars caching EFI varstore\naccess layer\") added a new get_variable call with attr=NULL, which\ntriggers panic in gsmi.",
  "id": "GHSA-5c27-9gp6-68q5",
  "modified": "2024-09-11T18:31:02Z",
  "published": "2024-08-21T09:31:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52893"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/32313c11bdc8a02c577abaf865be3664ab30410a"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/6646d769fdb0ce4318ef9afd127f8526d1ca8393"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/a769b05eeed7accc4019a1ed9799dd72067f1ce8"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ae2a9dcc8caa60b1e14671294e5ec902ea5d1dfd"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/eb0421d90f916dffe96b4c049ddf01c0c50620d2"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ee5763ef829bd923033510de6d1df7c73f085e4b"
    },
    {
      "type": "WEB",
      "url": "https://git.kernel.org/stable/c/ffef77794fb5f1245c3249b86342bad2299accb5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

OESA-2024-2079 (CVE-2022-48795)

Vulnerability from osv_openeuler – Published: 2024-08-30 11:07 – Updated: 2026-08-06 11:07 – 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: Fix data TLB miss in sba_unmap_sg

Rolf Eike Beer reported the following bug:

[1274934.746891] Bad Address (null pointer deref?): Code=15 (Data TLB miss fault) at addr 0000004140000018 [1274934.746891] CPU: 3 PID: 5549 Comm: cmake Not tainted 5.15.4-gentoo-parisc64 #4 [1274934.746891] Hardware name: 9000/785/C8000 [1274934.746891] [1274934.746891] YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI [1274934.746891] PSW: 00001000000001001111111000001110 Not tainted [1274934.746891] r00-03 000000ff0804fe0e 0000000040bc9bc0 00000000406760e4 0000004140000000 [1274934.746891] r04-07 0000000040b693c0 0000004140000000 000000004a2b08b0 0000000000000001 [1274934.746891] r08-11 0000000041f98810 0000000000000000 000000004a0a7000 0000000000000001 [1274934.746891] r12-15 0000000040bddbc0 0000000040c0cbc0 0000000040bddbc0 0000000040bddbc0 [1274934.746891] r16-19 0000000040bde3c0 0000000040bddbc0 0000000040bde3c0 0000000000000007 [1274934.746891] r20-23 0000000000000006 000000004a368950 0000000000000000 0000000000000001 [1274934.746891] r24-27 0000000000001fff 000000000800000e 000000004a1710f0 0000000040b693c0 [1274934.746891] r28-31 0000000000000001 0000000041f988b0 0000000041f98840 000000004a171118 [1274934.746891] sr00-03 00000000066e5800 0000000000000000 0000000000000000 00000000066e5800 [1274934.746891] sr04-07 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [1274934.746891] [1274934.746891] IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000406760e8 00000000406760ec [1274934.746891] IIR: 48780030 ISR: 0000000000000000 IOR: 0000004140000018 [1274934.746891] CPU: 3 CR30: 00000040e3a9c000 CR31: ffffffffffffffff [1274934.746891] ORIG_R28: 0000000040acdd58 [1274934.746891] IAOQ[0]: sba_unmap_sg+0xb0/0x118 [1274934.746891] IAOQ[1]: sba_unmap_sg+0xb4/0x118 [1274934.746891] RP(r2): sba_unmap_sg+0xac/0x118 [1274934.746891] Backtrace: [1274934.746891] [<00000000402740cc>] dma_unmap_sg_attrs+0x6c/0x70 [1274934.746891] [<000000004074d6bc>] scsi_dma_unmap+0x54/0x60 [1274934.746891] [<00000000407a3488>] mptscsih_io_done+0x150/0xd70 [1274934.746891] [<0000000040798600>] mpt_interrupt+0x168/0xa68 [1274934.746891] [<0000000040255a48>] __handle_irq_event_percpu+0xc8/0x278 [1274934.746891] [<0000000040255c34>] handle_irq_event_percpu+0x3c/0xd8 [1274934.746891] [<000000004025ecb4>] handle_percpu_irq+0xb4/0xf0 [1274934.746891] [<00000000402548e0>] generic_handle_irq+0x50/0x70 [1274934.746891] [<000000004019a254>] call_on_stack+0x18/0x24 [1274934.746891] [1274934.746891] Kernel panic - not syncing: Bad Address (null pointer deref?)

The bug is caused by overrunning the sglist and incorrectly testing sg_dma_len(sglist) before nents. Normally this doesn't cause a crash, but in this case sglist crossed a page boundary. This occurs in the following code:

while (sg_dma_len(sglist) &amp;&amp; nents--) {

The fix is simply to test nents first and move the decrement of nents into the loop.(CVE-2022-48795)

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

drm/virtio: Fix GEM handle creation UAF

Userspace can guess the handle value and try to race GEM object creation with handle close, resulting in a use-after-free if we dereference the object after dropping the handle's reference. For that reason, dropping the handle's reference must be done after we are done dereferencing the object.(CVE-2022-48899)

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

thermal: int340x: fix memory leak in int3400_notify()

It is easy to hit the below memory leaks in my TigerLake platform:

unreferenced object 0xffff927c8b91dbc0 (size 32): comm "kworker/0:2", pid 112, jiffies 4294893323 (age 83.604s) hex dump (first 32 bytes): 4e 41 4d 45 3d 49 4e 54 33 34 30 30 20 54 68 65 NAME=INT3400 The 72 6d 61 6c 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 rmal.kkkkkkkkkk. backtrace: [<ffffffff9c502c3e>] __kmalloc_track_caller+0x2fe/0x4a0 [<ffffffff9c7b7c15>] kvasprintf+0x65/0xd0 [<ffffffff9c7b7d6e>] kasprintf+0x4e/0x70 [<ffffffffc04cb662>] int3400_notify+0x82/0x120 [int3400_thermal] [<ffffffff9c8b7358>] acpi_ev_notify_dispatch+0x54/0x71 [<ffffffff9c88f1a7>] acpi_os_execute_deferred+0x17/0x30 [<ffffffff9c2c2c0a>] process_one_work+0x21a/0x3f0 [<ffffffff9c2c2e2a>] worker_thread+0x4a/0x3b0 [<ffffffff9c2cb4dd>] kthread+0xfd/0x130 [<ffffffff9c201c1f>] ret_from_fork+0x1f/0x30

Fix it by calling kfree() accordingly.(CVE-2022-48924)

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

iio: adc: men_z188_adc: Fix a resource leak in an error handling path

If iio_device_register() fails, a previous ioremap() is left unbalanced.

Update the error handling path and add the missing iounmap() call, as already done in the remove function.(CVE-2022-48928)

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

KVM: x86/mmu: make apf token non-zero to fix bug

In current async pagefault logic, when a page is ready, KVM relies on kvm_arch_can_dequeue_async_page_present() to determine whether to deliver a READY event to the Guest. This function test token value of struct kvm_vcpu_pv_apf_data, which must be reset to zero by Guest kernel when a READY event is finished by Guest. If value is zero meaning that a READY event is done, so the KVM can deliver another. But the kvm_arch_setup_async_pf() may produce a valid token with zero value, which is confused with previous mention and may lead the loss of this READY event.

This bug may cause task blocked forever in Guest: INFO: task stress:7532 blocked for more than 1254 seconds. Not tainted 5.10.0 #16 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:stress state:D stack: 0 pid: 7532 ppid: 1409 flags:0x00000080 Call Trace: __schedule+0x1e7/0x650 schedule+0x46/0xb0 kvm_async_pf_task_wait_schedule+0xad/0xe0 ? exit_to_user_mode_prepare+0x60/0x70 __kvm_handle_async_pf+0x4f/0xb0 ? asm_exc_page_fault+0x8/0x30 exc_page_fault+0x6f/0x110 ? asm_exc_page_fault+0x8/0x30 asm_exc_page_fault+0x1e/0x30 RIP: 0033:0x402d00 RSP: 002b:00007ffd31912500 EFLAGS: 00010206 RAX: 0000000000071000 RBX: ffffffffffffffff RCX: 00000000021a32b0 RDX: 000000000007d011 RSI: 000000000007d000 RDI: 00000000021262b0 RBP: 00000000021262b0 R08: 0000000000000003 R09: 0000000000000086 R10: 00000000000000eb R11: 00007fefbdf2baa0 R12: 0000000000000000 R13: 0000000000000002 R14: 000000000007d000 R15: 0000000000001000(CVE-2022-48943)

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

gsmi: fix null-deref in gsmi_get_variable

We can get EFI variables without fetching the attribute, so we must allow for that in gsmi.

commit 859748255b43 ("efi: pstore: Omit efivars caching EFI varstore access layer") added a new get_variable call with attr=NULL, which triggers panic in gsmi.(CVE-2023-52893)

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

xhci: Fix null pointer dereference when host dies

Make sure xhci_free_dev() and xhci_kill_endpoint_urbs() do not race and cause null pointer dereference when host suddenly dies.

Usb core may call xhci_free_dev() which frees the xhci->devs[slot_id] virt device at the same time that xhci_kill_endpoint_urbs() tries to loop through all the device's endpoints, checking if there are any cancelled urbs left to give back.

hold the xhci spinlock while freeing the virt device(CVE-2023-52898)

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

nilfs2: fix general protection fault in nilfs_btree_insert()

If nilfs2 reads a corrupted disk image and tries to reads a b-tree node block by calling __nilfs_btree_get_block() against an invalid virtual block address, it returns -ENOENT because conversion of the virtual block address to a disk block address fails. However, this return value is the same as the internal code that b-tree lookup routines return to indicate that the block being searched does not exist, so functions that operate on that b-tree may misbehave.

When nilfs_btree_insert() receives this spurious 'not found' code from nilfs_btree_do_lookup(), it misunderstands that the 'not found' check was successful and continues the insert operation using incomplete lookup path data, causing the following crash:

general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f] ... RIP: 0010:nilfs_btree_get_nonroot_node fs/nilfs2/btree.c:418 [inline] RIP: 0010:nilfs_btree_prepare_insert fs/nilfs2/btree.c:1077 [inline] RIP: 0010:nilfs_btree_insert+0x6d3/0x1c10 fs/nilfs2/btree.c:1238 Code: bc 24 80 00 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 28 00 74 08 4c 89 ff e8 4b 02 92 fe 4d 8b 3f 49 83 c7 28 4c 89 f8 48 c1 e8 03 <42> 80 3c 28 00 74 08 4c 89 ff e8 2e 02 92 fe 4d 8b 3f 49 83 c7 02 ... Call Trace: <TASK> nilfs_bmap_do_insert fs/nilfs2/bmap.c:121 [inline] nilfs_bmap_insert+0x20d/0x360 fs/nilfs2/bmap.c:147 nilfs_get_block+0x414/0x8d0 fs/nilfs2/inode.c:101 __block_write_begin_int+0x54c/0x1a80 fs/buffer.c:1991 __block_write_begin fs/buffer.c:2041 [inline] block_write_begin+0x93/0x1e0 fs/buffer.c:2102 nilfs_write_begin+0x9c/0x110 fs/nilfs2/inode.c:261 generic_perform_write+0x2e4/0x5e0 mm/filemap.c:3772 __generic_file_write_iter+0x176/0x400 mm/filemap.c:3900 generic_file_write_iter+0xab/0x310 mm/filemap.c:3932 call_write_iter include/linux/fs.h:2186 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x7dc/0xc50 fs/read_write.c:584 ksys_write+0x177/0x2a0 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd ... </TASK>

This patch fixes the root cause of this problem by replacing the error code that __nilfs_btree_get_block() returns on block address conversion failure from -ENOENT to another internal code -EINVAL which means that the b-tree metadata is corrupted.

By returning -EINVAL, it propagates without glitches, and for all relevant b-tree operations, functions in the upper bmap layer output an error message indicating corrupted b-tree metadata via nilfs_bmap_convert_error(), and code -EIO will be eventually returned as it should be.(CVE-2023-52900)

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

drivers: core: synchronize really_probe() and dev_uevent()

Synchronize the dev->driver usage in really_probe() and dev_uevent(). These can run in different threads, what can result in the following race condition for dev->driver uninitialization:

Thread #1:

really_probe() { ... probe_failed: ... device_unbind_cleanup(dev) { ... dev->driver = NULL; // <= Failed probe sets dev->driver to NULL ... } ... }

Thread #2:

dev_uevent() { ... if (dev->driver) // If dev->driver is NULLed from really_probe() from here on, // after above check, the system crashes add_uevent_var(env, "DRIVER=%s", dev->driver->name); ... }

really_probe() holds the lock, already. So nothing needs to be done there. dev_uevent() is called with lock held, often, too. But not always. What implies that we can't add any locking in dev_uevent() itself. So fix this race by adding the lock to the non-protected path. This is the path where above race is observed:

dev_uevent+0x235/0x380 uevent_show+0x10c/0x1f0 <= Add lock here dev_attr_show+0x3a/0xa0 sysfs_kf_seq_show+0x17c/0x250 kernfs_seq_show+0x7c/0x90 seq_read_iter+0x2d7/0x940 kernfs_fop_read_iter+0xc6/0x310 vfs_read+0x5bc/0x6b0 ksys_read+0xeb/0x1b0 __x64_sys_read+0x42/0x50 x64_sys_call+0x27ad/0x2d30 do_syscall_64+0xcd/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Similar cases are reported by syzkaller in

https://syzkaller.appspot.com/bug?extid=ffa8143439596313a85a

But these are regarding the initialization of dev->driver

dev->driver = drv;

As this switches dev->driver to non-NULL these reports can be considered to be false-positives (which should be "fixed" by this commit, as well, though).

The same issue was reported and tried to be fixed back in 2015 in

https://lore.kernel.org/lkml/1421259054-2574-1-git-send-email-a.sangwan@samsung.com/

already.(CVE-2024-39501)

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

ocfs2: add bounds checking to ocfs2_check_dir_entry()

This adds sanity checks for ocfs2_dir_entry to make sure all members of ocfs2_dir_entry don't stray beyond valid memory region.(CVE-2024-41015)

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

s390/sclp: Fix sclp_init() cleanup on failure

If sclp_init() fails it only partially cleans up: if there are multiple failing calls to sclp_init() sclp_state_change_event will be added several times to sclp_reg_list, which results in the following warning:

------------[ cut here ]------------ list_add double add: new=000003ffe1598c10, prev=000003ffe1598bf0, next=000003ffe1598c10. WARNING: CPU: 0 PID: 1 at lib/list_debug.c:35 __list_add_valid_or_report+0xde/0xf8 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.10.0-rc3 Krnl PSW : 0404c00180000000 000003ffe0d6076a (__list_add_valid_or_report+0xe2/0xf8) R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3 ... Call Trace: [<000003ffe0d6076a>] __list_add_valid_or_report+0xe2/0xf8 ([<000003ffe0d60766>] __list_add_valid_or_report+0xde/0xf8) [<000003ffe0a8d37e>] sclp_init+0x40e/0x450 [<000003ffe00009f2>] do_one_initcall+0x42/0x1e0 [<000003ffe15b77a6>] do_initcalls+0x126/0x150 [<000003ffe15b7a0a>] kernel_init_freeable+0x1ba/0x1f8 [<000003ffe0d6650e>] kernel_init+0x2e/0x180 [<000003ffe000301c>] __ret_from_fork+0x3c/0x60 [<000003ffe0d759ca>] ret_from_fork+0xa/0x30

Fix this by removing sclp_state_change_event from sclp_reg_list when sclp_init() fails.(CVE-2024-41068)

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

i2c: pnx: Fix potential deadlock warning from del_timer_sync() call in isr

When del_timer_sync() is called in an interrupt context it throws a warning because of potential deadlock. The timer is used only to exit from wait_for_completion() after a timeout so replacing the call with wait_for_completion_timeout() allows to remove the problematic timer and its related functions altogether.(CVE-2024-42153)

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

protect the fetch of ->fd[fd] in do_dup2() from mispredictions

both callers have verified that fd is not greater than ->max_fds; however, misprediction might end up with tofree = fdt->fd[fd]; being speculatively executed. That's wrong for the same reasons why it's wrong in close_fd()/file_close_fd_locked(); the same solution applies - array_index_nospec(fd, fdt->max_fds) could differ from fd only in case of speculative execution on mispredicted path.(CVE-2024-42265)

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

net/iucv: fix use after free in iucv_sock_close()

iucv_sever_path() is called from process context and from bh context. iucv->path is used as indicator whether somebody else is taking care of severing the path (or it is already removed / never existed). This needs to be done with atomic compare and swap, otherwise there is a small window where iucv_sock_close() will try to work with a path that has already been severed and freed by iucv_callback_connrej() called by iucv_tasklet_fn().

Example: [452744.123844] Call Trace: [452744.123845] ([<0000001e87f03880>] 0x1e87f03880) [452744.123966] [<00000000d593001e>] iucv_path_sever+0x96/0x138 [452744.124330] [<000003ff801ddbca>] iucv_sever_path+0xc2/0xd0 [af_iucv] [452744.124336] [<000003ff801e01b6>] iucv_sock_close+0xa6/0x310 [af_iucv] [452744.124341] [<000003ff801e08cc>] iucv_sock_release+0x3c/0xd0 [af_iucv] [452744.124345] [<00000000d574794e>] __sock_release+0x5e/0xe8 [452744.124815] [<00000000d5747a0c>] sock_close+0x34/0x48 [452744.124820] [<00000000d5421642>] __fput+0xba/0x268 [452744.124826] [<00000000d51b382c>] task_work_run+0xbc/0xf0 [452744.124832] [<00000000d5145710>] do_notify_resume+0x88/0x90 [452744.124841] [<00000000d5978096>] system_call+0xe2/0x2c8 [452744.125319] Last Breaking-Event-Address: [452744.125321] [<00000000d5930018>] iucv_path_sever+0x90/0x138 [452744.125324] [452744.125325] Kernel panic - not syncing: Fatal exception in interrupt

Note that bh_lock_sock() is not serializing the tasklet context against process context, because the check for sock_owned_by_user() and corresponding handling is missing.

Ideas for a future clean-up patch: A) Correct usage of bh_lock_sock() in tasklet context, as described in Re-enqueue, if needed. This may require adding return values to the tasklet functions and thus changes to all users of iucv.

B) Change iucv tasklet into worker and use only lock_sock() in af_iucv.(CVE-2024-42271)

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

mISDN: Fix a use after free in hfcmulti_tx()

Don't dereference sp after calling dev_kfree_skb(sp).(CVE-2024-42280)

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

tipc: Return non-zero value from tipc_udp_addr2str() on error

tipc_udp_addr2str() should return non-zero value if the UDP media address is invalid. Otherwise, a buffer overflow access can occur in tipc_media_addr_printf(). Fix this by returning 1 on an invalid UDP media address.(CVE-2024-42284)

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

RDMA/iwcm: Fix a use-after-free related to destroying CM IDs

iw_conn_req_handler() associates a new struct rdma_id_private (conn_id) with an existing struct iw_cm_id (cm_id) as follows:

    conn_id-&gt;cm_id.iw = cm_id;
    cm_id-&gt;context = conn_id;
    cm_id-&gt;cm_handler = cma_iw_handler;

rdma_destroy_id() frees both the cm_id and the struct rdma_id_private. Make sure that cm_work_handler() does not trigger a use-after-free by only freeing of the struct rdma_id_private after all pending work has finished.(CVE-2024-42285)

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

scsi: qla2xxx: During vport delete send async logout explicitly

During vport delete, it is observed that during unload we hit a crash because of stale entries in outstanding command array. For all these stale I/O entries, eh_abort was issued and aborted (fast_fail_io = 2009h) but I/Os could not complete while vport delete is in process of deleting.

BUG: kernel NULL pointer dereference, address: 000000000000001c #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI Workqueue: qla2xxx_wq qla_do_work [qla2xxx] RIP: 0010:dma_direct_unmap_sg+0x51/0x1e0 RSP: 0018:ffffa1e1e150fc68 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000021 RCX: 0000000000000001 RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8ce208a7a0d0 RBP: ffff8ce208a7a0d0 R08: 0000000000000000 R09: ffff8ce378aac9c8 R10: ffff8ce378aac8a0 R11: ffffa1e1e150f9d8 R12: 0000000000000000 R13: 0000000000000000 R14: ffff8ce378aac9c8 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8d217f000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000001c CR3: 0000002089acc000 CR4: 0000000000350ee0 Call Trace: <TASK> qla2xxx_qpair_sp_free_dma+0x417/0x4e0 ? qla2xxx_qpair_sp_compl+0x10d/0x1a0 ? qla2x00_status_entry+0x768/0x2830 ? newidle_balance+0x2f0/0x430 ? dequeue_entity+0x100/0x3c0 ? qla24xx_process_response_queue+0x6a1/0x19e0 ? __schedule+0x2d5/0x1140 ? qla_do_work+0x47/0x60 ? process_one_work+0x267/0x440 ? process_one_work+0x440/0x440 ? worker_thread+0x2d/0x3d0 ? process_one_work+0x440/0x440 ? kthread+0x156/0x180 ? set_kthread_struct+0x50/0x50 ? ret_from_fork+0x22/0x30 </TASK>

Send out async logout explicitly for all the ports during vport delete.(CVE-2024-42289)

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

f2fs: fix to don't dirty inode for readonly filesystem

syzbot reports f2fs bug as below:

kernel BUG at fs/f2fs/inode.c:933! RIP: 0010:f2fs_evict_inode+0x1576/0x1590 fs/f2fs/inode.c:933 Call Trace: evict+0x2a4/0x620 fs/inode.c:664 dispose_list fs/inode.c:697 [inline] evict_inodes+0x5f8/0x690 fs/inode.c:747 generic_shutdown_super+0x9d/0x2c0 fs/super.c:675 kill_block_super+0x44/0x90 fs/super.c:1667 kill_f2fs_super+0x303/0x3b0 fs/f2fs/super.c:4894 deactivate_locked_super+0xc1/0x130 fs/super.c:484 cleanup_mnt+0x426/0x4c0 fs/namespace.c:1256 task_work_run+0x24a/0x300 kernel/task_work.c:180 ptrace_notify+0x2cd/0x380 kernel/signal.c:2399 ptrace_report_syscall include/linux/ptrace.h:411 [inline] ptrace_report_syscall_exit include/linux/ptrace.h:473 [inline] syscall_exit_work kernel/entry/common.c:251 [inline] syscall_exit_to_user_mode_prepare kernel/entry/common.c:278 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:283 [inline] syscall_exit_to_user_mode+0x15c/0x280 kernel/entry/common.c:296 do_syscall_64+0x50/0x110 arch/x86/entry/common.c:88 entry_SYSCALL_64_after_hwframe+0x63/0x6b

The root cause is: - do_sys_open - f2fs_lookup - __f2fs_find_entry - f2fs_i_depth_write - f2fs_mark_inode_dirty_sync - f2fs_dirty_inode - set_inode_flag(inode, FI_DIRTY_INODE)

umount
kill_f2fs_super
kill_block_super
generic_shutdown_super
- sync_filesystem : sb is readonly, skip sync_filesystem()
- evict_inodes
- iput
- f2fs_evict_inode
- f2fs_bug_on(sbi, is_inode_flag_set(inode, FI_DIRTY_INODE)) : trigger kernel panic

When we try to repair i_current_depth in readonly filesystem, let's skip dirty inode to avoid panic in later f2fs_evict_inode().(CVE-2024-42297)

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

ext4: check dot and dotdot of dx_root before making dir indexed

Syzbot reports a issue as follows:

BUG: unable to handle page fault for address: ffffed11022e24fe PGD 23ffee067 P4D 23ffee067 PUD 0 Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 PID: 5079 Comm: syz-executor306 Not tainted 6.10.0-rc5-g55027e689933 #0 Call Trace: <TASK> make_indexed_dir+0xdaf/0x13c0 fs/ext4/namei.c:2341 ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2451 ext4_rename fs/ext4/namei.c:3936 [inline] ext4_rename2+0x26e5/0x4370 fs/ext4/namei.c:4214 [...] ============================================

The immediate cause of this problem is that there is only one valid dentry for the block to be split during do_split, so split==0 results in out of bounds accesses to the map triggering the issue.

do_split
  unsigned split
  dx_make_map
   count = 1
  split = count/2 = 0;
  continued = hash2 == map[split - 1].hash;
   ---&gt; map[4294967295]

The maximum length of a filename is 255 and the minimum block size is 1024, so it is always guaranteed that the number of entries is greater than or equal to 2 when do_split() is called.

But syzbot's crafted image has no dot and dotdot in dir, and the dentry distribution in dirblock is as follows:

bus dentry1 hole dentry2 free |xx--|xx-------------|...............|xx-------------|...............| 0 12 (8+248)=256 268 256 524 (8+256)=264 788 236 1024

So when renaming dentry1 increases its name_len length by 1, neither hole nor free is sufficient to hold the new dentry, and make_indexed_dir() is called.

In make_indexed_dir() it is assumed that the first two entries of the dirblock must be dot and dotdot, so bus and dentry1 are left in dx_root because they are treated as dot and dotdot, and only dentry2 is moved to the new leaf block. That's why count is equal to 1.

Therefore add the ext4_check_dx_root() helper function to add more sanity checks to dot and dotdot before starting the conversion to avoid the above issue.(CVE-2024-42305)

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

net: usb: qmi_wwan: fix memory leak for not ip packets

Free the unused skb when not ip packets arrive.(CVE-2024-43861)

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

wifi: cfg80211: handle 2x996 RU allocation in cfg80211_calculate_bitrate_he()

Currently NL80211_RATE_INFO_HE_RU_ALLOC_2x996 is not handled in cfg80211_calculate_bitrate_he(), leading to below warning:

kernel: invalid HE MCS: bw:6, ru:6 kernel: WARNING: CPU: 0 PID: 2312 at net/wireless/util.c:1501 cfg80211_calculate_bitrate_he+0x22b/0x270 [cfg80211]

Fix it by handling 2x996 RU allocation in the same way as 160 MHz bandwidth.(CVE-2024-43879)

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

exec: Fix ToCToU between perm check and set-uid/gid usage

When opening a file for exec via do_filp_open(), permission checking is done against the file's metadata at that moment, and on success, a file pointer is passed back. Much later in the execve() code path, the file metadata (specifically mode, uid, and gid) is used to determine if/how to set the uid and gid. However, those values may have changed since the permissions check, meaning the execution may gain unintended privileges.

For example, if a file could change permissions from executable and not set-id:

---------x 1 root root 16048 Aug 7 13:16 target

to set-id and non-executable:

---S------ 1 root root 16048 Aug 7 13:16 target

it is possible to gain root privileges when execution should have been disallowed.

While this race condition is rare in real-world scenarios, it has been observed (and proven exploitable) when package managers are updating the setuid bits of installed programs. Such files start with being world-executable but then are adjusted to be group-exec with a set-uid bit. For example, "chmod o-x,u+s target" makes "target" executable only by uid "root" and gid "cdrom", while also becoming setuid-root:

-rwxr-xr-x 1 root cdrom 16048 Aug 7 13:16 target

becomes:

-rwsr-xr-- 1 root cdrom 16048 Aug 7 13:16 target

But racing the chmod means users without group "cdrom" membership can get the permission to execute "target" just before the chmod, and when the chmod finishes, the exec reaches brpm_fill_uid(), and performs the setuid to root, violating the expressed authorization of "only cdrom group members can setuid to root".

Re-check that we still have execute permissions in case the metadata has changed. It would be better to keep a copy from the perm-check time, but until we can do that refactoring, the least-bad option is to do a full inode_permission() call (under inode lock). It is understood that this is safe against dead-locks, but hardly optimal.(CVE-2024-43882)

Severity

7.8 (High)


                    
                      CVSS:3.1/AV:L/AC:L/PR:L/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-2022-48795	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-48899	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-48924	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-48928	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-48943	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2023-52893	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2023-52898	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2023-52900	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-39501	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-41015	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-41068	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-42153	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-42265	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-42271	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-42280	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-42284	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-42285	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-42289	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-42297	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-42305	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-43861	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-43879	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-43882	ADVISORY

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm",
          "bpftool-debuginfo-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm",
          "kernel-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm",
          "kernel-debuginfo-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm",
          "kernel-debugsource-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm",
          "kernel-devel-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm",
          "kernel-source-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm",
          "kernel-tools-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm",
          "kernel-tools-debuginfo-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm",
          "kernel-tools-devel-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm",
          "perf-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm",
          "perf-debuginfo-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm",
          "python2-perf-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm",
          "python2-perf-debuginfo-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm",
          "python3-perf-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm",
          "python3-perf-debuginfo-4.19.90-2408.5.0.0292.oe2003sp4.aarch64.rpm"
        ],
        "src": [
          "kernel-4.19.90-2408.5.0.0292.oe2003sp4.src.rpm"
        ],
        "x86_64": [
          "bpftool-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm",
          "bpftool-debuginfo-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm",
          "kernel-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm",
          "kernel-debuginfo-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm",
          "kernel-debugsource-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm",
          "kernel-devel-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm",
          "kernel-source-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm",
          "kernel-tools-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm",
          "kernel-tools-debuginfo-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm",
          "kernel-tools-devel-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm",
          "perf-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm",
          "perf-debuginfo-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm",
          "python2-perf-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm",
          "python2-perf-debuginfo-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm",
          "python3-perf-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm",
          "python3-perf-debuginfo-4.19.90-2408.5.0.0292.oe2003sp4.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:20.03-LTS-SP4",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.19.90-2408.5.0.0292.oe2003sp4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nparisc: Fix data TLB miss in sba_unmap_sg\r\n\r\nRolf Eike Beer reported the following bug:\r\n\r\n[1274934.746891] Bad Address (null pointer deref?): Code=15 (Data TLB miss fault) at addr 0000004140000018\n[1274934.746891] CPU: 3 PID: 5549 Comm: cmake Not tainted 5.15.4-gentoo-parisc64 #4\n[1274934.746891] Hardware name: 9000/785/C8000\n[1274934.746891]\n[1274934.746891]      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI\n[1274934.746891] PSW: 00001000000001001111111000001110 Not tainted\n[1274934.746891] r00-03  000000ff0804fe0e 0000000040bc9bc0 00000000406760e4 0000004140000000\n[1274934.746891] r04-07  0000000040b693c0 0000004140000000 000000004a2b08b0 0000000000000001\n[1274934.746891] r08-11  0000000041f98810 0000000000000000 000000004a0a7000 0000000000000001\n[1274934.746891] r12-15  0000000040bddbc0 0000000040c0cbc0 0000000040bddbc0 0000000040bddbc0\n[1274934.746891] r16-19  0000000040bde3c0 0000000040bddbc0 0000000040bde3c0 0000000000000007\n[1274934.746891] r20-23  0000000000000006 000000004a368950 0000000000000000 0000000000000001\n[1274934.746891] r24-27  0000000000001fff 000000000800000e 000000004a1710f0 0000000040b693c0\n[1274934.746891] r28-31  0000000000000001 0000000041f988b0 0000000041f98840 000000004a171118\n[1274934.746891] sr00-03  00000000066e5800 0000000000000000 0000000000000000 00000000066e5800\n[1274934.746891] sr04-07  0000000000000000 0000000000000000 0000000000000000 0000000000000000\n[1274934.746891]\n[1274934.746891] IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000406760e8 00000000406760ec\n[1274934.746891]  IIR: 48780030    ISR: 0000000000000000  IOR: 0000004140000018\n[1274934.746891]  CPU:        3   CR30: 00000040e3a9c000 CR31: ffffffffffffffff\n[1274934.746891]  ORIG_R28: 0000000040acdd58\n[1274934.746891]  IAOQ[0]: sba_unmap_sg+0xb0/0x118\n[1274934.746891]  IAOQ[1]: sba_unmap_sg+0xb4/0x118\n[1274934.746891]  RP(r2): sba_unmap_sg+0xac/0x118\n[1274934.746891] Backtrace:\n[1274934.746891]  [\u0026lt;00000000402740cc\u0026gt;] dma_unmap_sg_attrs+0x6c/0x70\n[1274934.746891]  [\u0026lt;000000004074d6bc\u0026gt;] scsi_dma_unmap+0x54/0x60\n[1274934.746891]  [\u0026lt;00000000407a3488\u0026gt;] mptscsih_io_done+0x150/0xd70\n[1274934.746891]  [\u0026lt;0000000040798600\u0026gt;] mpt_interrupt+0x168/0xa68\n[1274934.746891]  [\u0026lt;0000000040255a48\u0026gt;] __handle_irq_event_percpu+0xc8/0x278\n[1274934.746891]  [\u0026lt;0000000040255c34\u0026gt;] handle_irq_event_percpu+0x3c/0xd8\n[1274934.746891]  [\u0026lt;000000004025ecb4\u0026gt;] handle_percpu_irq+0xb4/0xf0\n[1274934.746891]  [\u0026lt;00000000402548e0\u0026gt;] generic_handle_irq+0x50/0x70\n[1274934.746891]  [\u0026lt;000000004019a254\u0026gt;] call_on_stack+0x18/0x24\n[1274934.746891]\n[1274934.746891] Kernel panic - not syncing: Bad Address (null pointer deref?)\r\n\r\nThe bug is caused by overrunning the sglist and incorrectly testing\nsg_dma_len(sglist) before nents. Normally this doesn\u0026apos;t cause a crash,\nbut in this case sglist crossed a page boundary. This occurs in the\nfollowing code:\r\n\r\n\twhile (sg_dma_len(sglist) \u0026amp;\u0026amp; nents--) {\r\n\r\nThe fix is simply to test nents first and move the decrement of nents\ninto the loop.(CVE-2022-48795)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/virtio: Fix GEM handle creation UAF\r\n\r\nUserspace can guess the handle value and try to race GEM object creation\nwith handle close, resulting in a use-after-free if we dereference the\nobject after dropping the handle\u0026apos;s reference.  For that reason, dropping\nthe handle\u0026apos;s reference must be done *after* we are done dereferencing\nthe object.(CVE-2022-48899)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nthermal: int340x: fix memory leak in int3400_notify()\r\n\r\nIt is easy to hit the below memory leaks in my TigerLake platform:\r\n\r\nunreferenced object 0xffff927c8b91dbc0 (size 32):\n  comm \u0026quot;kworker/0:2\u0026quot;, pid 112, jiffies 4294893323 (age 83.604s)\n  hex dump (first 32 bytes):\n    4e 41 4d 45 3d 49 4e 54 33 34 30 30 20 54 68 65  NAME=INT3400 The\n    72 6d 61 6c 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5  rmal.kkkkkkkkkk.\n  backtrace:\n    [\u0026lt;ffffffff9c502c3e\u0026gt;] __kmalloc_track_caller+0x2fe/0x4a0\n    [\u0026lt;ffffffff9c7b7c15\u0026gt;] kvasprintf+0x65/0xd0\n    [\u0026lt;ffffffff9c7b7d6e\u0026gt;] kasprintf+0x4e/0x70\n    [\u0026lt;ffffffffc04cb662\u0026gt;] int3400_notify+0x82/0x120 [int3400_thermal]\n    [\u0026lt;ffffffff9c8b7358\u0026gt;] acpi_ev_notify_dispatch+0x54/0x71\n    [\u0026lt;ffffffff9c88f1a7\u0026gt;] acpi_os_execute_deferred+0x17/0x30\n    [\u0026lt;ffffffff9c2c2c0a\u0026gt;] process_one_work+0x21a/0x3f0\n    [\u0026lt;ffffffff9c2c2e2a\u0026gt;] worker_thread+0x4a/0x3b0\n    [\u0026lt;ffffffff9c2cb4dd\u0026gt;] kthread+0xfd/0x130\n    [\u0026lt;ffffffff9c201c1f\u0026gt;] ret_from_fork+0x1f/0x30\r\n\r\nFix it by calling kfree() accordingly.(CVE-2022-48924)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\niio: adc: men_z188_adc: Fix a resource leak in an error handling path\r\n\r\nIf iio_device_register() fails, a previous ioremap() is left unbalanced.\r\n\r\nUpdate the error handling path and add the missing iounmap() call, as\nalready done in the remove function.(CVE-2022-48928)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nKVM: x86/mmu: make apf token non-zero to fix bug\r\n\r\nIn current async pagefault logic, when a page is ready, KVM relies on\nkvm_arch_can_dequeue_async_page_present() to determine whether to deliver\na READY event to the Guest. This function test token value of struct\nkvm_vcpu_pv_apf_data, which must be reset to zero by Guest kernel when a\nREADY event is finished by Guest. If value is zero meaning that a READY\nevent is done, so the KVM can deliver another.\nBut the kvm_arch_setup_async_pf() may produce a valid token with zero\nvalue, which is confused with previous mention and may lead the loss of\nthis READY event.\r\n\r\nThis bug may cause task blocked forever in Guest:\n INFO: task stress:7532 blocked for more than 1254 seconds.\n       Not tainted 5.10.0 #16\n \u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\n task:stress          state:D stack:    0 pid: 7532 ppid:  1409\n flags:0x00000080\n Call Trace:\n  __schedule+0x1e7/0x650\n  schedule+0x46/0xb0\n  kvm_async_pf_task_wait_schedule+0xad/0xe0\n  ? exit_to_user_mode_prepare+0x60/0x70\n  __kvm_handle_async_pf+0x4f/0xb0\n  ? asm_exc_page_fault+0x8/0x30\n  exc_page_fault+0x6f/0x110\n  ? asm_exc_page_fault+0x8/0x30\n  asm_exc_page_fault+0x1e/0x30\n RIP: 0033:0x402d00\n RSP: 002b:00007ffd31912500 EFLAGS: 00010206\n RAX: 0000000000071000 RBX: ffffffffffffffff RCX: 00000000021a32b0\n RDX: 000000000007d011 RSI: 000000000007d000 RDI: 00000000021262b0\n RBP: 00000000021262b0 R08: 0000000000000003 R09: 0000000000000086\n R10: 00000000000000eb R11: 00007fefbdf2baa0 R12: 0000000000000000\n R13: 0000000000000002 R14: 000000000007d000 R15: 0000000000001000(CVE-2022-48943)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngsmi: fix null-deref in gsmi_get_variable\r\n\r\nWe can get EFI variables without fetching the attribute, so we must\nallow for that in gsmi.\r\n\r\ncommit 859748255b43 (\u0026quot;efi: pstore: Omit efivars caching EFI varstore\naccess layer\u0026quot;) added a new get_variable call with attr=NULL, which\ntriggers panic in gsmi.(CVE-2023-52893)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nxhci: Fix null pointer dereference when host dies\r\n\r\nMake sure xhci_free_dev() and xhci_kill_endpoint_urbs() do not race\nand cause null pointer dereference when host suddenly dies.\r\n\r\nUsb core may call xhci_free_dev() which frees the xhci-\u0026gt;devs[slot_id]\nvirt device at the same time that xhci_kill_endpoint_urbs() tries to\nloop through all the device\u0026apos;s endpoints, checking if there are any\ncancelled urbs left to give back.\r\n\r\nhold the xhci spinlock while freeing the virt device(CVE-2023-52898)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix general protection fault in nilfs_btree_insert()\r\n\r\nIf nilfs2 reads a corrupted disk image and tries to reads a b-tree node\nblock by calling __nilfs_btree_get_block() against an invalid virtual\nblock address, it returns -ENOENT because conversion of the virtual block\naddress to a disk block address fails.  However, this return value is the\nsame as the internal code that b-tree lookup routines return to indicate\nthat the block being searched does not exist, so functions that operate on\nthat b-tree may misbehave.\r\n\r\nWhen nilfs_btree_insert() receives this spurious \u0026apos;not found\u0026apos; code from\nnilfs_btree_do_lookup(), it misunderstands that the \u0026apos;not found\u0026apos; check was\nsuccessful and continues the insert operation using incomplete lookup path\ndata, causing the following crash:\r\n\r\n general protection fault, probably for non-canonical address\n 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN\n KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]\n ...\n RIP: 0010:nilfs_btree_get_nonroot_node fs/nilfs2/btree.c:418 [inline]\n RIP: 0010:nilfs_btree_prepare_insert fs/nilfs2/btree.c:1077 [inline]\n RIP: 0010:nilfs_btree_insert+0x6d3/0x1c10 fs/nilfs2/btree.c:1238\n Code: bc 24 80 00 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 28 00 74 08 4c 89\n ff e8 4b 02 92 fe 4d 8b 3f 49 83 c7 28 4c 89 f8 48 c1 e8 03 \u0026lt;42\u0026gt; 80 3c\n 28 00 74 08 4c 89 ff e8 2e 02 92 fe 4d 8b 3f 49 83 c7 02\n ...\n Call Trace:\n \u0026lt;TASK\u0026gt;\n  nilfs_bmap_do_insert fs/nilfs2/bmap.c:121 [inline]\n  nilfs_bmap_insert+0x20d/0x360 fs/nilfs2/bmap.c:147\n  nilfs_get_block+0x414/0x8d0 fs/nilfs2/inode.c:101\n  __block_write_begin_int+0x54c/0x1a80 fs/buffer.c:1991\n  __block_write_begin fs/buffer.c:2041 [inline]\n  block_write_begin+0x93/0x1e0 fs/buffer.c:2102\n  nilfs_write_begin+0x9c/0x110 fs/nilfs2/inode.c:261\n  generic_perform_write+0x2e4/0x5e0 mm/filemap.c:3772\n  __generic_file_write_iter+0x176/0x400 mm/filemap.c:3900\n  generic_file_write_iter+0xab/0x310 mm/filemap.c:3932\n  call_write_iter include/linux/fs.h:2186 [inline]\n  new_sync_write fs/read_write.c:491 [inline]\n  vfs_write+0x7dc/0xc50 fs/read_write.c:584\n  ksys_write+0x177/0x2a0 fs/read_write.c:637\n  do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n  do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80\n  entry_SYSCALL_64_after_hwframe+0x63/0xcd\n ...\n \u0026lt;/TASK\u0026gt;\r\n\r\nThis patch fixes the root cause of this problem by replacing the error\ncode that __nilfs_btree_get_block() returns on block address conversion\nfailure from -ENOENT to another internal code -EINVAL which means that the\nb-tree metadata is corrupted.\r\n\r\nBy returning -EINVAL, it propagates without glitches, and for all relevant\nb-tree operations, functions in the upper bmap layer output an error\nmessage indicating corrupted b-tree metadata via\nnilfs_bmap_convert_error(), and code -EIO will be eventually returned as\nit should be.(CVE-2023-52900)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrivers: core: synchronize really_probe() and dev_uevent()\r\n\r\nSynchronize the dev-\u0026gt;driver usage in really_probe() and dev_uevent().\nThese can run in different threads, what can result in the following\nrace condition for dev-\u0026gt;driver uninitialization:\r\n\r\nThread #1:\n==========\r\n\r\nreally_probe() {\n...\nprobe_failed:\n...\ndevice_unbind_cleanup(dev) {\n    ...\n    dev-\u0026gt;driver = NULL;   // \u0026lt;= Failed probe sets dev-\u0026gt;driver to NULL\n    ...\n    }\n...\n}\r\n\r\nThread #2:\n==========\r\n\r\ndev_uevent() {\n...\nif (dev-\u0026gt;driver)\n      // If dev-\u0026gt;driver is NULLed from really_probe() from here on,\n      // after above check, the system crashes\n      add_uevent_var(env, \u0026quot;DRIVER=%s\u0026quot;, dev-\u0026gt;driver-\u0026gt;name);\n...\n}\r\n\r\nreally_probe() holds the lock, already. So nothing needs to be done\nthere. dev_uevent() is called with lock held, often, too. But not\nalways. What implies that we can\u0026apos;t add any locking in dev_uevent()\nitself. So fix this race by adding the lock to the non-protected\npath. This is the path where above race is observed:\r\n\r\n dev_uevent+0x235/0x380\n uevent_show+0x10c/0x1f0  \u0026lt;= Add lock here\n dev_attr_show+0x3a/0xa0\n sysfs_kf_seq_show+0x17c/0x250\n kernfs_seq_show+0x7c/0x90\n seq_read_iter+0x2d7/0x940\n kernfs_fop_read_iter+0xc6/0x310\n vfs_read+0x5bc/0x6b0\n ksys_read+0xeb/0x1b0\n __x64_sys_read+0x42/0x50\n x64_sys_call+0x27ad/0x2d30\n do_syscall_64+0xcd/0x1d0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\nSimilar cases are reported by syzkaller in\r\n\r\nhttps://syzkaller.appspot.com/bug?extid=ffa8143439596313a85a\r\n\r\nBut these are regarding the *initialization* of dev-\u0026gt;driver\r\n\r\ndev-\u0026gt;driver = drv;\r\n\r\nAs this switches dev-\u0026gt;driver to non-NULL these reports can be considered\nto be false-positives (which should be \u0026quot;fixed\u0026quot; by this commit, as well,\nthough).\r\n\r\nThe same issue was reported and tried to be fixed back in 2015 in\r\n\r\nhttps://lore.kernel.org/lkml/1421259054-2574-1-git-send-email-a.sangwan@samsung.com/\r\n\r\nalready.(CVE-2024-39501)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nocfs2: add bounds checking to ocfs2_check_dir_entry()\r\n\r\nThis adds sanity checks for ocfs2_dir_entry to make sure all members of\nocfs2_dir_entry don\u0026apos;t stray beyond valid memory region.(CVE-2024-41015)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/sclp: Fix sclp_init() cleanup on failure\r\n\r\nIf sclp_init() fails it only partially cleans up: if there are multiple\nfailing calls to sclp_init() sclp_state_change_event will be added several\ntimes to sclp_reg_list, which results in the following warning:\r\n\r\n------------[ cut here ]------------\nlist_add double add: new=000003ffe1598c10, prev=000003ffe1598bf0, next=000003ffe1598c10.\nWARNING: CPU: 0 PID: 1 at lib/list_debug.c:35 __list_add_valid_or_report+0xde/0xf8\nCPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.10.0-rc3\nKrnl PSW : 0404c00180000000 000003ffe0d6076a (__list_add_valid_or_report+0xe2/0xf8)\n           R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3\n...\nCall Trace:\n [\u0026lt;000003ffe0d6076a\u0026gt;] __list_add_valid_or_report+0xe2/0xf8\n([\u0026lt;000003ffe0d60766\u0026gt;] __list_add_valid_or_report+0xde/0xf8)\n [\u0026lt;000003ffe0a8d37e\u0026gt;] sclp_init+0x40e/0x450\n [\u0026lt;000003ffe00009f2\u0026gt;] do_one_initcall+0x42/0x1e0\n [\u0026lt;000003ffe15b77a6\u0026gt;] do_initcalls+0x126/0x150\n [\u0026lt;000003ffe15b7a0a\u0026gt;] kernel_init_freeable+0x1ba/0x1f8\n [\u0026lt;000003ffe0d6650e\u0026gt;] kernel_init+0x2e/0x180\n [\u0026lt;000003ffe000301c\u0026gt;] __ret_from_fork+0x3c/0x60\n [\u0026lt;000003ffe0d759ca\u0026gt;] ret_from_fork+0xa/0x30\r\n\r\nFix this by removing sclp_state_change_event from sclp_reg_list when\nsclp_init() fails.(CVE-2024-41068)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ni2c: pnx: Fix potential deadlock warning from del_timer_sync() call in isr\r\n\r\nWhen del_timer_sync() is called in an interrupt context it throws a warning\nbecause of potential deadlock. The timer is used only to exit from\nwait_for_completion() after a timeout so replacing the call with\nwait_for_completion_timeout() allows to remove the problematic timer and\nits related functions altogether.(CVE-2024-42153)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nprotect the fetch of -\u0026gt;fd[fd] in do_dup2() from mispredictions\r\n\r\nboth callers have verified that fd is not greater than -\u0026gt;max_fds;\nhowever, misprediction might end up with\n        tofree = fdt-\u0026gt;fd[fd];\nbeing speculatively executed.  That\u0026apos;s wrong for the same reasons\nwhy it\u0026apos;s wrong in close_fd()/file_close_fd_locked(); the same\nsolution applies - array_index_nospec(fd, fdt-\u0026gt;max_fds) could differ\nfrom fd only in case of speculative execution on mispredicted path.(CVE-2024-42265)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/iucv: fix use after free in iucv_sock_close()\r\n\r\niucv_sever_path() is called from process context and from bh context.\niucv-\u0026gt;path is used as indicator whether somebody else is taking care of\nsevering the path (or it is already removed / never existed).\nThis needs to be done with atomic compare and swap, otherwise there is a\nsmall window where iucv_sock_close() will try to work with a path that has\nalready been severed and freed by iucv_callback_connrej() called by\niucv_tasklet_fn().\r\n\r\nExample:\n[452744.123844] Call Trace:\n[452744.123845] ([\u0026lt;0000001e87f03880\u0026gt;] 0x1e87f03880)\n[452744.123966]  [\u0026lt;00000000d593001e\u0026gt;] iucv_path_sever+0x96/0x138\n[452744.124330]  [\u0026lt;000003ff801ddbca\u0026gt;] iucv_sever_path+0xc2/0xd0 [af_iucv]\n[452744.124336]  [\u0026lt;000003ff801e01b6\u0026gt;] iucv_sock_close+0xa6/0x310 [af_iucv]\n[452744.124341]  [\u0026lt;000003ff801e08cc\u0026gt;] iucv_sock_release+0x3c/0xd0 [af_iucv]\n[452744.124345]  [\u0026lt;00000000d574794e\u0026gt;] __sock_release+0x5e/0xe8\n[452744.124815]  [\u0026lt;00000000d5747a0c\u0026gt;] sock_close+0x34/0x48\n[452744.124820]  [\u0026lt;00000000d5421642\u0026gt;] __fput+0xba/0x268\n[452744.124826]  [\u0026lt;00000000d51b382c\u0026gt;] task_work_run+0xbc/0xf0\n[452744.124832]  [\u0026lt;00000000d5145710\u0026gt;] do_notify_resume+0x88/0x90\n[452744.124841]  [\u0026lt;00000000d5978096\u0026gt;] system_call+0xe2/0x2c8\n[452744.125319] Last Breaking-Event-Address:\n[452744.125321]  [\u0026lt;00000000d5930018\u0026gt;] iucv_path_sever+0x90/0x138\n[452744.125324]\n[452744.125325] Kernel panic - not syncing: Fatal exception in interrupt\r\n\r\nNote that bh_lock_sock() is not serializing the tasklet context against\nprocess context, because the check for sock_owned_by_user() and\ncorresponding handling is missing.\r\n\r\nIdeas for a future clean-up patch:\nA) Correct usage of bh_lock_sock() in tasklet context, as described in\nRe-enqueue, if needed. This may require adding return values to the\ntasklet functions and thus changes to all users of iucv.\r\n\r\nB) Change iucv tasklet into worker and use only lock_sock() in af_iucv.(CVE-2024-42271)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmISDN: Fix a use after free in hfcmulti_tx()\r\n\r\nDon\u0026apos;t dereference *sp after calling dev_kfree_skb(*sp).(CVE-2024-42280)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntipc: Return non-zero value from tipc_udp_addr2str() on error\r\n\r\ntipc_udp_addr2str() should return non-zero value if the UDP media\naddress is invalid. Otherwise, a buffer overflow access can occur in\ntipc_media_addr_printf(). Fix this by returning 1 on an invalid UDP\nmedia address.(CVE-2024-42284)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nRDMA/iwcm: Fix a use-after-free related to destroying CM IDs\r\n\r\niw_conn_req_handler() associates a new struct rdma_id_private (conn_id) with\nan existing struct iw_cm_id (cm_id) as follows:\r\n\r\n        conn_id-\u0026gt;cm_id.iw = cm_id;\n        cm_id-\u0026gt;context = conn_id;\n        cm_id-\u0026gt;cm_handler = cma_iw_handler;\r\n\r\nrdma_destroy_id() frees both the cm_id and the struct rdma_id_private. Make\nsure that cm_work_handler() does not trigger a use-after-free by only\nfreeing of the struct rdma_id_private after all pending work has finished.(CVE-2024-42285)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: qla2xxx: During vport delete send async logout explicitly\r\n\r\nDuring vport delete, it is observed that during unload we hit a crash\nbecause of stale entries in outstanding command array.  For all these stale\nI/O entries, eh_abort was issued and aborted (fast_fail_io = 2009h) but\nI/Os could not complete while vport delete is in process of deleting.\r\n\r\n  BUG: kernel NULL pointer dereference, address: 000000000000001c\n  #PF: supervisor read access in kernel mode\n  #PF: error_code(0x0000) - not-present page\n  PGD 0 P4D 0\n  Oops: 0000 [#1] PREEMPT SMP NOPTI\n  Workqueue: qla2xxx_wq qla_do_work [qla2xxx]\n  RIP: 0010:dma_direct_unmap_sg+0x51/0x1e0\n  RSP: 0018:ffffa1e1e150fc68 EFLAGS: 00010046\n  RAX: 0000000000000000 RBX: 0000000000000021 RCX: 0000000000000001\n  RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff8ce208a7a0d0\n  RBP: ffff8ce208a7a0d0 R08: 0000000000000000 R09: ffff8ce378aac9c8\n  R10: ffff8ce378aac8a0 R11: ffffa1e1e150f9d8 R12: 0000000000000000\n  R13: 0000000000000000 R14: ffff8ce378aac9c8 R15: 0000000000000000\n  FS:  0000000000000000(0000) GS:ffff8d217f000000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 000000000000001c CR3: 0000002089acc000 CR4: 0000000000350ee0\n  Call Trace:\n  \u0026lt;TASK\u0026gt;\n  qla2xxx_qpair_sp_free_dma+0x417/0x4e0\n  ? qla2xxx_qpair_sp_compl+0x10d/0x1a0\n  ? qla2x00_status_entry+0x768/0x2830\n  ? newidle_balance+0x2f0/0x430\n  ? dequeue_entity+0x100/0x3c0\n  ? qla24xx_process_response_queue+0x6a1/0x19e0\n  ? __schedule+0x2d5/0x1140\n  ? qla_do_work+0x47/0x60\n  ? process_one_work+0x267/0x440\n  ? process_one_work+0x440/0x440\n  ? worker_thread+0x2d/0x3d0\n  ? process_one_work+0x440/0x440\n  ? kthread+0x156/0x180\n  ? set_kthread_struct+0x50/0x50\n  ? ret_from_fork+0x22/0x30\n  \u0026lt;/TASK\u0026gt;\r\n\r\nSend out async logout explicitly for all the ports during vport delete.(CVE-2024-42289)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: fix to don\u0026apos;t dirty inode for readonly filesystem\r\n\r\nsyzbot reports f2fs bug as below:\r\n\r\nkernel BUG at fs/f2fs/inode.c:933!\nRIP: 0010:f2fs_evict_inode+0x1576/0x1590 fs/f2fs/inode.c:933\nCall Trace:\n evict+0x2a4/0x620 fs/inode.c:664\n dispose_list fs/inode.c:697 [inline]\n evict_inodes+0x5f8/0x690 fs/inode.c:747\n generic_shutdown_super+0x9d/0x2c0 fs/super.c:675\n kill_block_super+0x44/0x90 fs/super.c:1667\n kill_f2fs_super+0x303/0x3b0 fs/f2fs/super.c:4894\n deactivate_locked_super+0xc1/0x130 fs/super.c:484\n cleanup_mnt+0x426/0x4c0 fs/namespace.c:1256\n task_work_run+0x24a/0x300 kernel/task_work.c:180\n ptrace_notify+0x2cd/0x380 kernel/signal.c:2399\n ptrace_report_syscall include/linux/ptrace.h:411 [inline]\n ptrace_report_syscall_exit include/linux/ptrace.h:473 [inline]\n syscall_exit_work kernel/entry/common.c:251 [inline]\n syscall_exit_to_user_mode_prepare kernel/entry/common.c:278 [inline]\n __syscall_exit_to_user_mode_work kernel/entry/common.c:283 [inline]\n syscall_exit_to_user_mode+0x15c/0x280 kernel/entry/common.c:296\n do_syscall_64+0x50/0x110 arch/x86/entry/common.c:88\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nThe root cause is:\n- do_sys_open\n - f2fs_lookup\n  - __f2fs_find_entry\n   - f2fs_i_depth_write\n    - f2fs_mark_inode_dirty_sync\n     - f2fs_dirty_inode\n      - set_inode_flag(inode, FI_DIRTY_INODE)\r\n\r\n- umount\n - kill_f2fs_super\n  - kill_block_super\n   - generic_shutdown_super\n    - sync_filesystem\n    : sb is readonly, skip sync_filesystem()\n    - evict_inodes\n     - iput\n      - f2fs_evict_inode\n       - f2fs_bug_on(sbi, is_inode_flag_set(inode, FI_DIRTY_INODE))\n       : trigger kernel panic\r\n\r\nWhen we try to repair i_current_depth in readonly filesystem, let\u0026apos;s\nskip dirty inode to avoid panic in later f2fs_evict_inode().(CVE-2024-42297)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\next4: check dot and dotdot of dx_root before making dir indexed\r\n\r\nSyzbot reports a issue as follows:\n============================================\nBUG: unable to handle page fault for address: ffffed11022e24fe\nPGD 23ffee067 P4D 23ffee067 PUD 0\nOops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI\nCPU: 0 PID: 5079 Comm: syz-executor306 Not tainted 6.10.0-rc5-g55027e689933 #0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n make_indexed_dir+0xdaf/0x13c0 fs/ext4/namei.c:2341\n ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2451\n ext4_rename fs/ext4/namei.c:3936 [inline]\n ext4_rename2+0x26e5/0x4370 fs/ext4/namei.c:4214\n[...]\n============================================\r\n\r\nThe immediate cause of this problem is that there is only one valid dentry\nfor the block to be split during do_split, so split==0 results in out of\nbounds accesses to the map triggering the issue.\r\n\r\n    do_split\n      unsigned split\n      dx_make_map\n       count = 1\n      split = count/2 = 0;\n      continued = hash2 == map[split - 1].hash;\n       ---\u0026gt; map[4294967295]\r\n\r\nThe maximum length of a filename is 255 and the minimum block size is 1024,\nso it is always guaranteed that the number of entries is greater than or\nequal to 2 when do_split() is called.\r\n\r\nBut syzbot\u0026apos;s crafted image has no dot and dotdot in dir, and the dentry\ndistribution in dirblock is as follows:\r\n\r\n  bus     dentry1          hole           dentry2           free\n|xx--|xx-------------|...............|xx-------------|...............|\n0   12 (8+248)=256  268     256     524 (8+256)=264 788     236     1024\r\n\r\nSo when renaming dentry1 increases its name_len length by 1, neither hole\nnor free is sufficient to hold the new dentry, and make_indexed_dir() is\ncalled.\r\n\r\nIn make_indexed_dir() it is assumed that the first two entries of the\ndirblock must be dot and dotdot, so bus and dentry1 are left in dx_root\nbecause they are treated as dot and dotdot, and only dentry2 is moved\nto the new leaf block. That\u0026apos;s why count is equal to 1.\r\n\r\nTherefore add the ext4_check_dx_root() helper function to add more sanity\nchecks to dot and dotdot before starting the conversion to avoid the above\nissue.(CVE-2024-42305)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: usb: qmi_wwan: fix memory leak for not ip packets\r\n\r\nFree the unused skb when not ip packets arrive.(CVE-2024-43861)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: cfg80211: handle 2x996 RU allocation in cfg80211_calculate_bitrate_he()\r\n\r\nCurrently NL80211_RATE_INFO_HE_RU_ALLOC_2x996 is not handled in\ncfg80211_calculate_bitrate_he(), leading to below warning:\r\n\r\nkernel: invalid HE MCS: bw:6, ru:6\nkernel: WARNING: CPU: 0 PID: 2312 at net/wireless/util.c:1501 cfg80211_calculate_bitrate_he+0x22b/0x270 [cfg80211]\r\n\r\nFix it by handling 2x996 RU allocation in the same way as 160 MHz bandwidth.(CVE-2024-43879)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nexec: Fix ToCToU between perm check and set-uid/gid usage\r\n\r\nWhen opening a file for exec via do_filp_open(), permission checking is\ndone against the file\u0026apos;s metadata at that moment, and on success, a file\npointer is passed back. Much later in the execve() code path, the file\nmetadata (specifically mode, uid, and gid) is used to determine if/how\nto set the uid and gid. However, those values may have changed since the\npermissions check, meaning the execution may gain unintended privileges.\r\n\r\nFor example, if a file could change permissions from executable and not\nset-id:\r\n\r\n---------x 1 root root 16048 Aug  7 13:16 target\r\n\r\nto set-id and non-executable:\r\n\r\n---S------ 1 root root 16048 Aug  7 13:16 target\r\n\r\nit is possible to gain root privileges when execution should have been\ndisallowed.\r\n\r\nWhile this race condition is rare in real-world scenarios, it has been\nobserved (and proven exploitable) when package managers are updating\nthe setuid bits of installed programs. Such files start with being\nworld-executable but then are adjusted to be group-exec with a set-uid\nbit. For example, \u0026quot;chmod o-x,u+s target\u0026quot; makes \u0026quot;target\u0026quot; executable only\nby uid \u0026quot;root\u0026quot; and gid \u0026quot;cdrom\u0026quot;, while also becoming setuid-root:\r\n\r\n-rwxr-xr-x 1 root cdrom 16048 Aug  7 13:16 target\r\n\r\nbecomes:\r\n\r\n-rwsr-xr-- 1 root cdrom 16048 Aug  7 13:16 target\r\n\r\nBut racing the chmod means users without group \u0026quot;cdrom\u0026quot; membership can\nget the permission to execute \u0026quot;target\u0026quot; just before the chmod, and when\nthe chmod finishes, the exec reaches brpm_fill_uid(), and performs the\nsetuid to root, violating the expressed authorization of \u0026quot;only cdrom\ngroup members can setuid to root\u0026quot;.\r\n\r\nRe-check that we still have execute permissions in case the metadata\nhas changed. It would be better to keep a copy from the perm-check time,\nbut until we can do that refactoring, the least-bad option is to do a\nfull inode_permission() call (under inode lock). It is understood that\nthis is safe against dead-locks, but hardly optimal.(CVE-2024-43882)",
  "id": "OESA-2024-2079",
  "modified": "2026-08-06T11:07:33Z",
  "published": "2024-08-30T11:07:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2079"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48795"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48899"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48924"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48928"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48943"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52893"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52898"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52900"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39501"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41015"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41068"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42153"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42265"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42271"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42280"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42284"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42285"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42289"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42297"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42305"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43861"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43879"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43882"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2022-48795",
    "CVE-2022-48899",
    "CVE-2022-48924",
    "CVE-2022-48928",
    "CVE-2022-48943",
    "CVE-2023-52893",
    "CVE-2023-52898",
    "CVE-2023-52900",
    "CVE-2024-39501",
    "CVE-2024-41015",
    "CVE-2024-41068",
    "CVE-2024-42153",
    "CVE-2024-42265",
    "CVE-2024-42271",
    "CVE-2024-42280",
    "CVE-2024-42284",
    "CVE-2024-42285",
    "CVE-2024-42289",
    "CVE-2024-42297",
    "CVE-2024-42305",
    "CVE-2024-43861",
    "CVE-2024-43879",
    "CVE-2024-43882"
  ]
}

OESA-2024-2080 (CVE-2021-47292)

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

io_uring: fix memleak in io_init_wq_offload()

I got memory leak report when doing fuzz test:

BUG: memory leak unreferenced object 0xffff888107310a80 (size 96): comm "syz-executor.6", pid 4610, jiffies 4295140240 (age 20.135s) hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... backtrace: [<000000001974933b>] kmalloc include/linux/slab.h:591 [inline] [<000000001974933b>] kzalloc include/linux/slab.h:721 [inline] [<000000001974933b>] io_init_wq_offload fs/io_uring.c:7920 [inline] [<000000001974933b>] io_uring_alloc_task_context+0x466/0x640 fs/io_uring.c:7955 [<0000000039d0800d>] __io_uring_add_tctx_node+0x256/0x360 fs/io_uring.c:9016 [<000000008482e78c>] io_uring_add_tctx_node fs/io_uring.c:9052 [inline] [<000000008482e78c>] __do_sys_io_uring_enter fs/io_uring.c:9354 [inline] [<000000008482e78c>] __se_sys_io_uring_enter fs/io_uring.c:9301 [inline] [<000000008482e78c>] __x64_sys_io_uring_enter+0xabc/0xc20 fs/io_uring.c:9301 [<00000000b875f18f>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<00000000b875f18f>] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 [<000000006b0a8484>] entry_SYSCALL_64_after_hwframe+0x44/0xae

CPU0 CPU1 io_uring_enter io_uring_enter io_uring_add_tctx_node io_uring_add_tctx_node __io_uring_add_tctx_node __io_uring_add_tctx_node io_uring_alloc_task_context io_uring_alloc_task_context io_init_wq_offload io_init_wq_offload hash = kzalloc hash = kzalloc ctx->hash_map = hash ctx->hash_map = hash <- one of the hash is leaked

When calling io_uring_enter() in parallel, the 'hash_map' will be leaked, add uring_lock to protect 'hash_map'.(CVE-2021-47292)

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

io_uring: ensure task_work gets run as part of cancelations

If we successfully cancel a work item but that work item needs to be processed through task_work, then we can be sleeping uninterruptibly in io_uring_cancel_generic() and never process it. Hence we don't make forward progress and we end up with an uninterruptible sleep warning.

While in there, correct a comment that should be IFF, not IIF.(CVE-2021-47504)

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

ethtool: ioctl: fix potential NULL deref in ethtool_set_coalesce()

ethtool_set_coalesce() now uses both the .get_coalesce() and .set_coalesce() callbacks. But the check for their availability is buggy, so changing the coalesce settings on a device where the driver provides only one of the callbacks results in a NULL pointer dereference instead of an -EOPNOTSUPP.

Fix the condition so that the availability of both callbacks is ensured. This also matches the netlink code.

Note that reproducing this requires some effort - it only affects the legacy ioctl path, and needs a specific combination of driver options: - have .get_coalesce() and .coalesce_supported but no .set_coalesce(), or - have .set_coalesce() but no .get_coalesce(). Here eg. ethtool doesn't cause the crash as it first attempts to call ethtool_get_coalesce() and bails out on error.(CVE-2021-47556)

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

drm/gma500: Fix BUG: sleeping function called from invalid context errors

gma_crtc_page_flip() was holding the event_lock spinlock while calling crtc_funcs->mode_set_base() which takes ww_mutex.

The only reason to hold event_lock is to clear gma_crtc->page_flip_event on mode_set_base() errors.

Instead unlock it after setting gma_crtc->page_flip_event and on errors re-take the lock and clear gma_crtc->page_flip_event it it is still set.

This fixes the following WARN/stacktrace:

[ 512.122953] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:870 [ 512.123004] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1253, name: gnome-shell [ 512.123031] preempt_count: 1, expected: 0 [ 512.123048] RCU nest depth: 0, expected: 0 [ 512.123066] INFO: lockdep is turned off. [ 512.123080] irq event stamp: 0 [ 512.123094] hardirqs last enabled at (0): [<0000000000000000>] 0x0 [ 512.123134] hardirqs last disabled at (0): [<ffffffff8d0ec28c>] copy_process+0x9fc/0x1de0 [ 512.123176] softirqs last enabled at (0): [<ffffffff8d0ec28c>] copy_process+0x9fc/0x1de0 [ 512.123207] softirqs last disabled at (0): [<0000000000000000>] 0x0 [ 512.123233] Preemption disabled at: [ 512.123241] [<0000000000000000>] 0x0 [ 512.123275] CPU: 3 PID: 1253 Comm: gnome-shell Tainted: G W 5.19.0+ #1 [ 512.123304] Hardware name: Packard Bell dot s/SJE01_CT, BIOS V1.10 07/23/2013 [ 512.123323] Call Trace: [ 512.123346] <TASK> [ 512.123370] dump_stack_lvl+0x5b/0x77 [ 512.123412] __might_resched.cold+0xff/0x13a [ 512.123458] ww_mutex_lock+0x1e/0xa0 [ 512.123495] psb_gem_pin+0x2c/0x150 [gma500_gfx] [ 512.123601] gma_pipe_set_base+0x76/0x240 [gma500_gfx] [ 512.123708] gma_crtc_page_flip+0x95/0x130 [gma500_gfx] [ 512.123808] drm_mode_page_flip_ioctl+0x57d/0x5d0 [ 512.123897] ? drm_mode_cursor2_ioctl+0x10/0x10 [ 512.123936] drm_ioctl_kernel+0xa1/0x150 [ 512.123984] drm_ioctl+0x21f/0x420 [ 512.124025] ? drm_mode_cursor2_ioctl+0x10/0x10 [ 512.124070] ? rcu_read_lock_bh_held+0xb/0x60 [ 512.124104] ? lock_release+0x1ef/0x2d0 [ 512.124161] __x64_sys_ioctl+0x8d/0xd0 [ 512.124203] do_syscall_64+0x58/0x80 [ 512.124239] ? do_syscall_64+0x67/0x80 [ 512.124267] ? trace_hardirqs_on_prepare+0x55/0xe0 [ 512.124300] ? do_syscall_64+0x67/0x80 [ 512.124340] ? rcu_read_lock_sched_held+0x10/0x80 [ 512.124377] entry_SYSCALL_64_after_hwframe+0x63/0xcd [ 512.124411] RIP: 0033:0x7fcc4a70740f [ 512.124442] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 18 48 8b 44 24 18 64 48 2b 04 25 28 00 00 [ 512.124470] RSP: 002b:00007ffda73f5390 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 512.124503] RAX: ffffffffffffffda RBX: 000055cc9e474500 RCX: 00007fcc4a70740f [ 512.124524] RDX: 00007ffda73f5420 RSI: 00000000c01864b0 RDI: 0000000000000009 [ 512.124544] RBP: 00007ffda73f5420 R08: 000055cc9c0b0cb0 R09: 0000000000000034 [ 512.124564] R10: 0000000000000000 R11: 0000000000000246 R12: 00000000c01864b0 [ 512.124584] R13: 0000000000000009 R14: 000055cc9df484d0 R15: 000055cc9af5d0c0 [ 512.124647] </TASK>(CVE-2022-48634)

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

net: sched: fix possible refcount leak in tc_new_tfilter()

tfilter_put need to be called to put the refount got by tp->ops->get to avoid possible refcount leak when chain->tmplt_ops != NULL and chain->tmplt_ops != tp->ops.(CVE-2022-48639)

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

netfilter: nf_tables: fix percpu memory leak at nf_tables_addchain()

It seems to me that percpu memory for chain stats started leaking since commit 3bc158f8d0330f0a ("netfilter: nf_tables: map basechain priority to hardware priority") when nft_chain_offload_priority() returned an error.(CVE-2022-48642)

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

netfilter: nf_tables: fix nft_counters_enabled underflow at nf_tables_addchain()

syzbot is reporting underflow of nft_counters_enabled counter at nf_tables_addchain() [1], for commit 43eb8949cfdffa76 ("netfilter: nf_tables: do not leave chain stats enabled on error") missed that nf_tables_chain_destroy() after nft_basechain_init() in the error path of nf_tables_addchain() decrements the counter because nft_basechain_init() makes nft_is_base_chain() return true by setting NFT_CHAIN_BASE flag.

Increment the counter immediately after returning from nft_basechain_init().(CVE-2022-48643)

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

net/sched: taprio: avoid disabling offload when it was never enabled

In an incredibly strange API design decision, qdisc->destroy() gets called even if qdisc->init() never succeeded, not exclusively since commit 87b60cfacf9f ("net_sched: fix error recovery at qdisc creation"), but apparently also earlier (in the case of qdisc_create_dflt()).

The taprio qdisc does not fully acknowledge this when it attempts full offload, because it starts off with q->flags = TAPRIO_FLAGS_INVALID in taprio_init(), then it replaces q->flags with TCA_TAPRIO_ATTR_FLAGS parsed from netlink (in taprio_change(), tail called from taprio_init()).

But in taprio_destroy(), we call taprio_disable_offload(), and this determines what to do based on FULL_OFFLOAD_IS_ENABLED(q->flags).

But looking at the implementation of FULL_OFFLOAD_IS_ENABLED() (a bitwise check of bit 1 in q->flags), it is invalid to call this macro on q->flags when it contains TAPRIO_FLAGS_INVALID, because that is set to U32_MAX, and therefore FULL_OFFLOAD_IS_ENABLED() will return true on an invalid set of flags.

As a result, it is possible to crash the kernel if user space forces an error between setting q->flags = TAPRIO_FLAGS_INVALID, and the calling of taprio_enable_offload(). This is because drivers do not expect the offload to be disabled when it was never enabled.

The error that we force here is to attach taprio as a non-root qdisc, but instead as child of an mqprio root qdisc:

$ tc qdisc add dev swp0 root handle 1: \ mqprio num_tc 8 map 0 1 2 3 4 5 6 7 \ queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 hw 0 $ tc qdisc replace dev swp0 parent 1:1 \ taprio num_tc 8 map 0 1 2 3 4 5 6 7 \ queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 base-time 0 \ sched-entry S 0x7f 990000 sched-entry S 0x80 100000 \ flags 0x0 clockid CLOCK_TAI Unable to handle kernel paging request at virtual address fffffffffffffff8 [fffffffffffffff8] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 96000004 [#1] PREEMPT SMP Call trace: taprio_dump+0x27c/0x310 vsc9959_port_setup_tc+0x1f4/0x460 felix_port_setup_tc+0x24/0x3c dsa_slave_setup_tc+0x54/0x27c taprio_disable_offload.isra.0+0x58/0xe0 taprio_destroy+0x80/0x104 qdisc_create+0x240/0x470 tc_modify_qdisc+0x1fc/0x6b0 rtnetlink_rcv_msg+0x12c/0x390 netlink_rcv_skb+0x5c/0x130 rtnetlink_rcv+0x1c/0x2c

Fix this by keeping track of the operations we made, and undo the offload only if we actually did it.

I've added "bool offloaded" inside a 4 byte hole between "int clockid" and "atomic64_t picos_per_byte". Now the first cache line looks like below:

$ pahole -C taprio_sched net/sched/sch_taprio.o struct taprio_sched { struct Qdisc * * qdiscs; / 0 8 / struct Qdisc * root; / 8 8 / u32 flags; / 16 4 / enum tk_offsets tk_offset; / 20 4 / int clockid; / 24 4 / bool offloaded; / 28 1 /

    /* XXX 3 bytes hole, try to pack */

    atomic64_t                 picos_per_byte;       /*    32     0 */

    /* XXX 8 bytes hole, try to pack */

    spinlock_t                 current_entry_lock;   /*    40     0 */

    /* XXX 8 bytes hole, try to pack */

    struct sched_entry *       current_entry;        /*    48     8 */
    struct sched_gate_list *   oper_sched;           /*    56     8 */
    /* --- cacheline 1 boundary (64 bytes) --- */(CVE-2022-48644)

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

sfc: fix TX channel offset when using legacy interrupts

In legacy interrupt mode the tx_channel_offset was hardcoded to 1, but that's not correct if efx_sepparate_tx_channels is false. In that case, the offset is 0 because the tx queues are in the single existing channel at index 0, together with the rx queue.

Without this fix, as soon as you try to send any traffic, it tries to get the tx queues from an uninitialized channel getting these errors: WARNING: CPU: 1 PID: 0 at drivers/net/ethernet/sfc/tx.c:540 efx_hard_start_xmit+0x12e/0x170 [sfc] [...] RIP: 0010:efx_hard_start_xmit+0x12e/0x170 [sfc] [...] Call Trace: <IRQ> dev_hard_start_xmit+0xd7/0x230 sch_direct_xmit+0x9f/0x360 __dev_queue_xmit+0x890/0xa40 [...] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 [...] RIP: 0010:efx_hard_start_xmit+0x153/0x170 [sfc] [...] Call Trace: <IRQ> dev_hard_start_xmit+0xd7/0x230 sch_direct_xmit+0x9f/0x360 __dev_queue_xmit+0x890/0xa40 ...

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

sfc: fix null pointer dereference in efx_hard_start_xmit

Trying to get the channel from the tx_queue variable here is wrong because we can only be here if tx_queue is NULL, so we shouldn't dereference it. As the above comment in the code says, this is very unlikely to happen, but it's wrong anyway so let's fix it.

I hit this issue because of a different bug that caused tx_queue to be NULL. If that happens, this is the error message that we get here: BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 [...] RIP: 0010:efx_hard_start_xmit+0x153/0x170 sfc

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

dmaengine: ti: k3-udma-private: Fix refcount leak bug in of_xudma_dev_get()

We should call of_node_put() for the reference returned by of_parse_phandle() in fail path or when it is not used anymore. Here we only need to move the of_node_put() before the check.(CVE-2022-48656)

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

gpio: mockup: fix NULL pointer dereference when removing debugfs

We now remove the device's debugfs entries when unbinding the driver. This now causes a NULL-pointer dereference on module exit because the platform devices are unregistered after the global debugfs directory has been recursively removed. Fix it by unregistering the devices first.(CVE-2022-48663)

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

cgroup: Add missing cpus_read_lock() to cgroup_attach_task_all()

syzbot is hitting percpu_rwsem_assert_held(&cpu_hotplug_lock) warning at cpuset_attach() [1], for commit 4f7e7236435ca0ab ("cgroup: Fix threadgroup_rwsem <-> cpus_read_lock() deadlock") missed that cpuset_attach() is also called from cgroup_attach_task_all(). Add cpus_read_lock() like what cgroup_procs_write_start() does.(CVE-2022-48671)

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

of: fdt: fix off-by-one error in unflatten_dt_nodes()

Commit 78c44d910d3e ("drivers/of: Fix depth when unflattening devicetree") forgot to fix up the depth check in the loop body in unflatten_dt_nodes() which makes it possible to overflow the nps[] buffer...

Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool.(CVE-2022-48672)

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

IB/core: Fix a nested dead lock as part of ODP flow

Fix a nested dead lock as part of ODP flow by using mmput_async().

From the below call trace [1] can see that calling mmput() once we have the umem_odp->umem_mutex locked as required by ib_umem_odp_map_dma_and_lock() might trigger in the same task the exit_mmap()->__mmu_notifier_release()->mlx5_ib_invalidate_range() which may dead lock when trying to lock the same mutex.

Moving to use mmput_async() will solve the problem as the above exit_mmap() flow will be called in other task and will be executed once the lock will be available.

[1] [64843.077665] task:kworker/u133:2 state:D stack: 0 pid:80906 ppid: 2 flags:0x00004000 [64843.077672] Workqueue: mlx5_ib_page_fault mlx5_ib_eqe_pf_action [mlx5_ib] [64843.077719] Call Trace: [64843.077722] <TASK> [64843.077724] __schedule+0x23d/0x590 [64843.077729] schedule+0x4e/0xb0 [64843.077735] schedule_preempt_disabled+0xe/0x10 [64843.077740] __mutex_lock.constprop.0+0x263/0x490 [64843.077747] __mutex_lock_slowpath+0x13/0x20 [64843.077752] mutex_lock+0x34/0x40 [64843.077758] mlx5_ib_invalidate_range+0x48/0x270 [mlx5_ib] [64843.077808] __mmu_notifier_release+0x1a4/0x200 [64843.077816] exit_mmap+0x1bc/0x200 [64843.077822] ? walk_page_range+0x9c/0x120 [64843.077828] ? __cond_resched+0x1a/0x50 [64843.077833] ? mutex_lock+0x13/0x40 [64843.077839] ? uprobe_clear_state+0xac/0x120 [64843.077860] mmput+0x5f/0x140 [64843.077867] ib_umem_odp_map_dma_and_lock+0x21b/0x580 [ib_core] [64843.077931] pagefault_real_mr+0x9a/0x140 [mlx5_ib] [64843.077962] pagefault_mr+0xb4/0x550 [mlx5_ib] [64843.077992] pagefault_single_data_segment.constprop.0+0x2ac/0x560 [mlx5_ib] [64843.078022] mlx5_ib_eqe_pf_action+0x528/0x780 [mlx5_ib] [64843.078051] process_one_work+0x22b/0x3d0 [64843.078059] worker_thread+0x53/0x410 [64843.078065] ? process_one_work+0x3d0/0x3d0 [64843.078073] kthread+0x12a/0x150 [64843.078079] ? set_kthread_struct+0x50/0x50 [64843.078085] ret_from_fork+0x22/0x30 [64843.078093] </TASK>(CVE-2022-48675)

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

nvme-tcp: fix UAF when detecting digest errors

We should also bail from the io_work loop when we set rd_enabled to true, so we don't attempt to read data from the socket when the TCP stream is already out-of-sync or corrupted.(CVE-2022-48686)

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

ipv6: sr: fix out-of-bounds read when setting HMAC data.

The SRv6 layer allows defining HMAC data that can later be used to sign IPv6 Segment Routing Headers. This configuration is realised via netlink through four attributes: SEG6_ATTR_HMACKEYID, SEG6_ATTR_SECRET, SEG6_ATTR_SECRETLEN and SEG6_ATTR_ALGID. Because the SECRETLEN attribute is decoupled from the actual length of the SECRET attribute, it is possible to provide invalid combinations (e.g., secret = "", secretlen = 64). This case is not checked in the code and with an appropriately crafted netlink message, an out-of-bounds read of up to 64 bytes (max secret length) can occur past the skb end pointer and into skb_shared_info:

Breakpoint 1, seg6_genl_sethmac (skb=<optimized out>, info=<optimized out>) at net/ipv6/seg6.c:208 208 memcpy(hinfo->secret, secret, slen); (gdb) bt #0 seg6_genl_sethmac (skb=<optimized out>, info=<optimized out>) at net/ipv6/seg6.c:208 #1 0xffffffff81e012e9 in genl_family_rcv_msg_doit (skb=skb@entry=0xffff88800b1f9f00, nlh=nlh@entry=0xffff88800b1b7600, extack=extack@entry=0xffffc90000ba7af0, ops=ops@entry=0xffffc90000ba7a80, hdrlen=4, net=0xffffffff84237580 <init_net>, family=<optimized out>, family=<optimized out>) at net/netlink/genetlink.c:731 #2 0xffffffff81e01435 in genl_family_rcv_msg (extack=0xffffc90000ba7af0, nlh=0xffff88800b1b7600, skb=0xffff88800b1f9f00, family=0xffffffff82fef6c0 <seg6_genl_family>) at net/netlink/genetlink.c:775 #3 genl_rcv_msg (skb=0xffff88800b1f9f00, nlh=0xffff88800b1b7600, extack=0xffffc90000ba7af0) at net/netlink/genetlink.c:792 #4 0xffffffff81dfffc3 in netlink_rcv_skb (skb=skb@entry=0xffff88800b1f9f00, cb=cb@entry=0xffffffff81e01350 <genl_rcv_msg>) at net/netlink/af_netlink.c:2501 #5 0xffffffff81e00919 in genl_rcv (skb=0xffff88800b1f9f00) at net/netlink/genetlink.c:803 #6 0xffffffff81dff6ae in netlink_unicast_kernel (ssk=0xffff888010eec800, skb=0xffff88800b1f9f00, sk=0xffff888004aed000) at net/netlink/af_netlink.c:1319 #7 netlink_unicast (ssk=ssk@entry=0xffff888010eec800, skb=skb@entry=0xffff88800b1f9f00, portid=portid@entry=0, nonblock=<optimized out>) at net/netlink/af_netlink.c:1345 #8 0xffffffff81dff9a4 in netlink_sendmsg (sock=<optimized out>, msg=0xffffc90000ba7e48, len=<optimized out>) at net/netlink/af_netlink.c:1921 ... (gdb) p/x ((struct sk_buff )0xffff88800b1f9f00)->head + ((struct sk_buff )0xffff88800b1f9f00)->end $1 = 0xffff88800b1b76c0 (gdb) p/x secret $2 = 0xffff88800b1b76c0 (gdb) p slen $3 = 64 '@'

The OOB data can then be read back from userspace by dumping HMAC state. This commit fixes this by ensuring SECRETLEN cannot exceed the actual length of SECRET.(CVE-2022-48687)

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

netfilter: nf_tables: clean up hook list when offload flags check fails

splice back the hook list so nft_chain_release_hook() has a chance to release the hooks.

BUG: memory leak unreferenced object 0xffff88810180b100 (size 96): comm "syz-executor133", pid 3619, jiffies 4294945714 (age 12.690s) hex dump (first 32 bytes): 28 64 23 02 81 88 ff ff 28 64 23 02 81 88 ff ff (d#.....(d#..... 90 a8 aa 83 ff ff ff ff 00 00 b5 0f 81 88 ff ff ................ backtrace: [<ffffffff83a8c59b>] kmalloc include/linux/slab.h:600 [inline] [<ffffffff83a8c59b>] nft_netdev_hook_alloc+0x3b/0xc0 net/netfilter/nf_tables_api.c:1901 [<ffffffff83a9239a>] nft_chain_parse_netdev net/netfilter/nf_tables_api.c:1998 [inline] [<ffffffff83a9239a>] nft_chain_parse_hook+0x33a/0x530 net/netfilter/nf_tables_api.c:2073 [<ffffffff83a9b14b>] nf_tables_addchain.constprop.0+0x10b/0x950 net/netfilter/nf_tables_api.c:2218 [<ffffffff83a9c41b>] nf_tables_newchain+0xa8b/0xc60 net/netfilter/nf_tables_api.c:2593 [<ffffffff83a3d6a6>] nfnetlink_rcv_batch+0xa46/0xd20 net/netfilter/nfnetlink.c:517 [<ffffffff83a3db79>] nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:638 [inline] [<ffffffff83a3db79>] nfnetlink_rcv+0x1f9/0x220 net/netfilter/nfnetlink.c:656 [<ffffffff83a13b17>] netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] [<ffffffff83a13b17>] netlink_unicast+0x397/0x4c0 net/netlink/af_netlink.c:1345 [<ffffffff83a13fd6>] netlink_sendmsg+0x396/0x710 net/netlink/af_netlink.c:1921 [<ffffffff83865ab6>] sock_sendmsg_nosec net/socket.c:714 [inline] [<ffffffff83865ab6>] sock_sendmsg+0x56/0x80 net/socket.c:734 [<ffffffff8386601c>] _syssendmsg+0x36c/0x390 net/socket.c:2482 [<ffffffff8386a918>] _sys_sendmsg+0xa8/0x110 net/socket.c:2536 [<ffffffff8386aaa8>] __sys_sendmsg+0x88/0x100 net/socket.c:2565 [<ffffffff845e5955>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<ffffffff845e5955>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 [<ffffffff84800087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd(CVE-2022-48691)

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

misc: fastrpc: Don't remove map on creater_process and device_release

Do not remove the map from the list on error path in fastrpc_init_create_process, instead call fastrpc_map_put, to avoid use-after-free. Do not remove it on fastrpc_device_release either, call fastrpc_map_put instead.

The fastrpc_free_map is the only proper place to remove the map. This is called only after the reference count is 0.(CVE-2022-48873)

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

ixgbe: fix pci device refcount leak

As the comment of pci_get_domain_bus_and_slot() says, it returns a PCI device with refcount incremented, when finish using it, the caller must decrement the reference count by calling pci_dev_put().

In ixgbe_get_first_secondary_devfn() and ixgbe_x550em_a_has_mii(), pci_dev_put() is called to avoid leak.(CVE-2022-48896)

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

drm/msm/dp: do not complete dp_aux_cmd_fifo_tx() if irq is not for aux transfer

There are 3 possible interrupt sources are handled by DP controller, HPDstatus, Controller state changes and Aux read/write transaction. At every irq, DP controller have to check isr status of every interrupt sources and service the interrupt if its isr status bits shows interrupts are pending. There is potential race condition may happen at current aux isr handler implementation since it is always complete dp_aux_cmd_fifo_tx() even irq is not for aux read or write transaction. This may cause aux read transaction return premature if host aux data read is in the middle of waiting for sink to complete transferring data to host while irq happen. This will cause host's receiving buffer contains unexpected data. This patch fixes this problem by checking aux isr and return immediately at aux isr handler if there are no any isr status bits set.

Current there is a bug report regrading eDP edid corruption happen during system booting up. After lengthy debugging to found that VIDEO_READY interrupt was continuously firing during system booting up which cause dp_aux_isr() to complete dp_aux_cmd_fifo_tx() prematurely to retrieve data from aux hardware buffer which is not yet contains complete data transfer from sink. This cause edid corruption.

Follows are the signature at kernel logs when problem happen, EDID has corrupt header panel-simple-dp-aux aux-aea0000.edp: Couldn't identify panel via EDID

Changes in v2: -- do complete if (ret == IRQ_HANDLED) ay dp-aux_isr() -- add more commit text

Changes in v3: -- add Stephen suggested -- dp_aux_isr() return IRQ_XXX back to caller -- dp_ctrl_isr() return IRQ_XXX back to caller

Changes in v4: -- split into two patches

Changes in v5: -- delete empty line between tags

Changes in v6: -- remove extra "that" and fixed line more than 75 char at commit text

Patchwork: https://patchwork.freedesktop.org/patch/516121/(CVE-2022-48898)

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

drm/virtio: Fix GEM handle creation UAF

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

btrfs: get rid of warning on transaction commit when using flushoncommit

When using the flushoncommit mount option, during almost every transaction commit we trigger a warning from __writeback_inodes_sb_nr():

$ cat fs/fs-writeback.c: (...) static void __writeback_inodes_sb_nr(struct super_block *sb, ... { (...) WARN_ON(!rwsem_is_locked(&sb->s_umount)); (...) } (...)

The trace produced in dmesg looks like the following:

[947.473890] WARNING: CPU: 5 PID: 930 at fs/fs-writeback.c:2610 __writeback_inodes_sb_nr+0x7e/0xb3 [947.481623] Modules linked in: nfsd nls_cp437 cifs asn1_decoder cifs_arc4 fscache cifs_md4 ipmi_ssif [947.489571] CPU: 5 PID: 930 Comm: btrfs-transacti Not tainted 95.16.3-srb-asrock-00001-g36437ad63879 #186 [947.497969] RIP: 0010:__writeback_inodes_sb_nr+0x7e/0xb3 [947.502097] Code: 24 10 4c 89 44 24 18 c6 (...) [947.519760] RSP: 0018:ffffc90000777e10 EFLAGS: 00010246 [947.523818] RAX: 0000000000000000 RBX: 0000000000963300 RCX: 0000000000000000 [947.529765] RDX: 0000000000000000 RSI: 000000000000fa51 RDI: ffffc90000777e50 [947.535740] RBP: ffff888101628a90 R08: ffff888100955800 R09: ffff888100956000 [947.541701] R10: 0000000000000002 R11: 0000000000000001 R12: ffff888100963488 [947.547645] R13: ffff888100963000 R14: ffff888112fb7200 R15: ffff888100963460 [947.553621] FS: 0000000000000000(0000) GS:ffff88841fd40000(0000) knlGS:0000000000000000 [947.560537] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [947.565122] CR2: 0000000008be50c4 CR3: 000000000220c000 CR4: 00000000001006e0 [947.571072] Call Trace: [947.572354] <TASK> [947.573266] btrfs_commit_transaction+0x1f1/0x998 [947.576785] ? start_transaction+0x3ab/0x44e [947.579867] ? schedule_timeout+0x8a/0xdd [947.582716] transaction_kthread+0xe9/0x156 [947.585721] ? btrfs_cleanup_transaction.isra.0+0x407/0x407 [947.590104] kthread+0x131/0x139 [947.592168] ? set_kthread_struct+0x32/0x32 [947.595174] ret_from_fork+0x22/0x30 [947.597561] </TASK> [947.598553] ---[ end trace 644721052755541c ]---

This is because we started using writeback_inodes_sb() to flush delalloc when committing a transaction (when using -o flushoncommit), in order to avoid deadlocks with filesystem freeze operations. This change was made by commit ce8ea7cc6eb313 ("btrfs: don't call btrfs_start_delalloc_roots in flushoncommit"). After that change we started producing that warning, and every now and then a user reports this since the warning happens too often, it spams dmesg/syslog, and a user is unsure if this reflects any problem that might compromise the filesystem's reliability.

We can not just lock the sb->s_umount semaphore before calling writeback_inodes_sb(), because that would at least deadlock with filesystem freezing, since at fs/super.c:freeze_super() sync_filesystem() is called while we are holding that semaphore in write mode, and that can trigger a transaction commit, resulting in a deadlock. It would also trigger the same type of deadlock in the unmount path. Possibly, it could also introduce some other locking dependencies that lockdep would report.

To fix this call try_to_writeback_inodes_sb() instead of writeback_inodes_sb(), because that will try to read lock sb->s_umount and then will only call writeback_inodes_sb() if it was able to lock it. This is fine because the cases where it can't read lock sb->s_umount are during a filesystem unmount or during a filesystem freeze - in those cases sb->s_umount is write locked and sync_filesystem() is called, which calls writeback_inodes_sb(). In other words, in all cases where we can't take a read lock on sb->s_umount, writeback is already being triggered elsewhere.

An alternative would be to call btrfs_start_delalloc_roots() with a number of pages different from LONG_MAX, for example matching the number of delalloc bytes we currently have, in ---truncated---(CVE-2022-48920)

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

netfilter: nf_tables: unregister flowtable hooks on netns exit

Unregister flowtable hooks before they are releases via nf_tables_flowtable_destroy() otherwise hook core reports UAF.

BUG: KASAN: use-after-free in nf_hook_entries_grow+0x5a7/0x700 net/netfilter/core.c:142 net/netfilter/core.c:142 Read of size 4 at addr ffff8880736f7438 by task syz-executor579/3666

CPU: 0 PID: 3666 Comm: syz-executor579 Not tainted 5.16.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] __dump_stack lib/dump_stack.c:88 [inline] lib/dump_stack.c:106 dump_stack_lvl+0x1dc/0x2d8 lib/dump_stack.c:106 lib/dump_stack.c:106 print_address_description+0x65/0x380 mm/kasan/report.c:247 mm/kasan/report.c:247 __kasan_report mm/kasan/report.c:433 [inline] __kasan_report mm/kasan/report.c:433 [inline] mm/kasan/report.c:450 kasan_report+0x19a/0x1f0 mm/kasan/report.c:450 mm/kasan/report.c:450 nf_hook_entries_grow+0x5a7/0x700 net/netfilter/core.c:142 net/netfilter/core.c:142 __nf_register_net_hook+0x27e/0x8d0 net/netfilter/core.c:429 net/netfilter/core.c:429 nf_register_net_hook+0xaa/0x180 net/netfilter/core.c:571 net/netfilter/core.c:571 nft_register_flowtable_net_hooks+0x3c5/0x730 net/netfilter/nf_tables_api.c:7232 net/netfilter/nf_tables_api.c:7232 nf_tables_newflowtable+0x2022/0x2cf0 net/netfilter/nf_tables_api.c:7430 net/netfilter/nf_tables_api.c:7430 nfnetlink_rcv_batch net/netfilter/nfnetlink.c:513 [inline] nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:634 [inline] nfnetlink_rcv_batch net/netfilter/nfnetlink.c:513 [inline] net/netfilter/nfnetlink.c:652 nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:634 [inline] net/netfilter/nfnetlink.c:652 nfnetlink_rcv+0x10e6/0x2550 net/netfilter/nfnetlink.c:652 net/netfilter/nfnetlink.c:652

__nft_release_hook() calls nft_unregister_flowtable_net_hooks() which only unregisters the hooks, then after RCU grace period, it is guaranteed that no packets add new entries to the flowtable (no flow offload rules and flowtable hooks are reachable from packet path), so it is safe to call nf_flow_table_free() which cleans up the remaining entries from the flowtable (both software and hardware) and it unbinds the flow_block.(CVE-2022-48935)

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

gsmi: fix null-deref in gsmi_get_variable

We can get EFI variables without fetching the attribute, so we must allow for that in gsmi.

commit 859748255b43 ("efi: pstore: Omit efivars caching EFI varstore access layer") added a new get_variable call with attr=NULL, which triggers panic in gsmi.(CVE-2023-52893)

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

xhci: Fix null pointer dereference when host dies

Make sure xhci_free_dev() and xhci_kill_endpoint_urbs() do not race and cause null pointer dereference when host suddenly dies.

hold the xhci spinlock while freeing the virt device(CVE-2023-52898)

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

usb: xhci: Check endpoint is valid before dereferencing it

When the host controller is not responding, all URBs queued to all endpoints need to be killed. This can cause a kernel panic if we dereference an invalid endpoint.

Fix this by using xhci_get_virt_ep() helper to find the endpoint and checking if the endpoint is valid before dereferencing it.

[233311.853271] xhci-hcd xhci-hcd.1.auto: xHCI host controller not responding, assume dead [233311.853393] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000e8

[233311.853964] pc : xhci_hc_died+0x10c/0x270 [233311.853971] lr : xhci_hc_died+0x1ac/0x270

[233311.854077] Call trace: [233311.854085] xhci_hc_died+0x10c/0x270 [233311.854093] xhci_stop_endpoint_command_watchdog+0x100/0x1a4 [233311.854105] call_timer_fn+0x50/0x2d4 [233311.854112] expire_timers+0xac/0x2e4 [233311.854118] run_timer_softirq+0x300/0xabc [233311.854127] __do_softirq+0x148/0x528 [233311.854135] irq_exit+0x194/0x1a8 [233311.854143] __handle_domain_irq+0x164/0x1d0 [233311.854149] gic_handle_irq.22273+0x10c/0x188 [233311.854156] el1_irq+0xfc/0x1a8 [233311.854175] lpm_cpuidle_enter+0x25c/0x418 [msm_pm] [233311.854185] cpuidle_enter_state+0x1f0/0x764 [233311.854194] do_idle+0x594/0x6ac [233311.854201] cpu_startup_entry+0x7c/0x80 [233311.854209] secondary_start_kernel+0x170/0x198(CVE-2023-52901)

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

io_uring: lock overflowing for IOPOLL

syzbot reports an issue with overflow filling for IOPOLL:

WARNING: CPU: 0 PID: 28 at io_uring/io_uring.c:734 io_cqring_event_overflow+0x1c0/0x230 io_uring/io_uring.c:734 CPU: 0 PID: 28 Comm: kworker/u4:1 Not tainted 6.2.0-rc3-syzkaller-16369-g358a161a6a9e #0 Workqueue: events_unbound io_ring_exit_work Call trace: io_cqring_event_overflow+0x1c0/0x230 io_uring/io_uring.c:734 io_req_cqe_overflow+0x5c/0x70 io_uring/io_uring.c:773 io_fill_cqe_req io_uring/io_uring.h:168 [inline] io_do_iopoll+0x474/0x62c io_uring/rw.c:1065 io_iopoll_try_reap_events+0x6c/0x108 io_uring/io_uring.c:1513 io_uring_try_cancel_requests+0x13c/0x258 io_uring/io_uring.c:3056 io_ring_exit_work+0xec/0x390 io_uring/io_uring.c:2869 process_one_work+0x2d8/0x504 kernel/workqueue.c:2289 worker_thread+0x340/0x610 kernel/workqueue.c:2436 kthread+0x12c/0x158 kernel/kthread.c:376 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:863

There is no real problem for normal IOPOLL as flush is also called with uring_lock taken, but it's getting more complicated for IOPOLL|SQPOLL, for which __io_cqring_overflow_flush() happens from the CQ waiting path.(CVE-2023-52903)

A race condition was found in the Linux kernel's drm/exynos device driver in exynos_drm_crtc_atomic_disable() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.

(CVE-2024-22386)

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

phonet: fix rtm_phonet_notify() skb allocation

fill_route() stores three components in the skb:

struct rtmsg
RTA_DST (u8)
RTA_OIF (u32)

Therefore, rtm_phonet_notify() should use

NLMSG_ALIGN(sizeof(struct rtmsg)) + nla_total_size(1) + nla_total_size(4)(CVE-2024-36946)

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

m68k: Fix spinlock race in kernel thread creation

Context switching does take care to retain the correct lock owner across the switch from 'prev' to 'next' tasks. This does rely on interrupts remaining disabled for the entire duration of the switch.

This condition is guaranteed for normal process creation and context switching between already running processes, because both 'prev' and 'next' already have interrupts disabled in their saved copies of the status register.

The situation is different for newly created kernel threads. The status register is set to PS_S in copy_thread(), which does leave the IPL at 0. Upon restoring the 'next' thread's status register in switch_to() aka resume(), interrupts then become enabled prematurely. resume() then returns via ret_from_kernel_thread() and schedule_tail() where run queue lock is released (see finish_task_switch() and finish_lock_switch()).

A timer interrupt calling scheduler_tick() before the lock is released in finish_task_switch() will find the lock already taken, with the current task as lock owner. This causes a spinlock recursion warning as reported by Guenter Roeck.

As far as I can ascertain, this race has been opened in commit 533e6903bea0 ("m68k: split ret_from_fork(), simplify kernel_thread()") but I haven't done a detailed study of kernel history so it may well predate that commit.

Interrupts cannot be disabled in the saved status register copy for kernel threads (init will complain about interrupts disabled when finally starting user space). Disable interrupts temporarily when switching the tasks' register sets in resume().

Note that a simple oriw 0x700,%sr after restoring sr is not enough here - this leaves enough of a race for the 'spinlock recursion' warning to still be observed.

Tested on ARAnyM and qemu (Quadra 800 emulation).(CVE-2024-38613)

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

ipv6: sr: fix missing sk_buff release in seg6_input_core

The seg6_input() function is responsible for adding the SRH into a packet, delegating the operation to the seg6_input_core(). This function uses the skb_cow_head() to ensure that there is sufficient headroom in the sk_buff for accommodating the link-layer header. In the event that the skb_cow_header() function fails, the seg6_input_core() catches the error but it does not release the sk_buff, which will result in a memory leak.

This issue was introduced in commit af3b5158b89d ("ipv6: sr: fix BUG due to headroom too small after SRH push") and persists even after commit 7a3f5b0de364 ("netfilter: add netfilter hooks to SRv6 data plane"), where the entire seg6_input() code was refactored to deal with netfilter hooks.

The proposed patch addresses the identified memory leak by requiring the seg6_input_core() function to release the sk_buff in the event that skb_cow_head() fails.(CVE-2024-39490)

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

crypto: hisilicon/sec - Fix memory leak for sec resource release

The AIV is one of the SEC resources. When releasing resources, it need to release the AIV resources at the same time. Otherwise, memory leakage occurs.

The aiv resource release is added to the sec resource release function.(CVE-2024-41002)

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

s390/sclp: Fix sclp_init() cleanup on failure

Fix this by removing sclp_state_change_event from sclp_reg_list when sclp_init() fails.(CVE-2024-41068)

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

drm/amd/display: Check pipe offset before setting vblank

pipe_ctx has a size of MAX_PIPES so checking its index before accessing the array.

This fixes an OVERRUN issue reported by Coverity.(CVE-2024-42120)

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

drm/amd/display: Add NULL pointer check for kzalloc

[Why & How] Check return pointer of kzalloc before using it.(CVE-2024-42122)

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

protect the fetch of ->fd[fd] in do_dup2() from mispredictions

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

net/iucv: fix use after free in iucv_sock_close()

Note that bh_lock_sock() is not serializing the tasklet context against process context, because the check for sock_owned_by_user() and corresponding handling is missing.

B) Change iucv tasklet into worker and use only lock_sock() in af_iucv.(CVE-2024-42271)

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

mISDN: Fix a use after free in hfcmulti_tx()

Don't dereference sp after calling dev_kfree_skb(sp).(CVE-2024-42280)

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

bpf: Fix a segment issue when downgrading gso_size

Linearize the skb when downgrading gso_size because it may trigger a BUG_ON() later when the skb is segmented as described in [1,2].(CVE-2024-42281)

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

tipc: Return non-zero value from tipc_udp_addr2str() on error

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

RDMA/iwcm: Fix a use-after-free related to destroying CM IDs

iw_conn_req_handler() associates a new struct rdma_id_private (conn_id) with an existing struct iw_cm_id (cm_id) as follows:

    conn_id-&gt;cm_id.iw = cm_id;
    cm_id-&gt;context = conn_id;
    cm_id-&gt;cm_handler = cma_iw_handler;

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

f2fs: fix to don't dirty inode for readonly filesystem

syzbot reports f2fs bug as below:

The root cause is: - do_sys_open - f2fs_lookup - __f2fs_find_entry - f2fs_i_depth_write - f2fs_mark_inode_dirty_sync - f2fs_dirty_inode - set_inode_flag(inode, FI_DIRTY_INODE)

umount
kill_f2fs_super
kill_block_super
generic_shutdown_super
- sync_filesystem : sb is readonly, skip sync_filesystem()
- evict_inodes
- iput
- f2fs_evict_inode
- f2fs_bug_on(sbi, is_inode_flag_set(inode, FI_DIRTY_INODE)) : trigger kernel panic

When we try to repair i_current_depth in readonly filesystem, let's skip dirty inode to avoid panic in later f2fs_evict_inode().(CVE-2024-42297)

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

ext4: check dot and dotdot of dx_root before making dir indexed

Syzbot reports a issue as follows:

The immediate cause of this problem is that there is only one valid dentry for the block to be split during do_split, so split==0 results in out of bounds accesses to the map triggering the issue.

do_split
  unsigned split
  dx_make_map
   count = 1
  split = count/2 = 0;
  continued = hash2 == map[split - 1].hash;
   ---&gt; map[4294967295]

The maximum length of a filename is 255 and the minimum block size is 1024, so it is always guaranteed that the number of entries is greater than or equal to 2 when do_split() is called.

But syzbot's crafted image has no dot and dotdot in dir, and the dentry distribution in dirblock is as follows:

bus dentry1 hole dentry2 free |xx--|xx-------------|...............|xx-------------|...............| 0 12 (8+248)=256 268 256 524 (8+256)=264 788 236 1024

So when renaming dentry1 increases its name_len length by 1, neither hole nor free is sufficient to hold the new dentry, and make_indexed_dir() is called.

Therefore add the ext4_check_dx_root() helper function to add more sanity checks to dot and dotdot before starting the conversion to avoid the above issue.(CVE-2024-42305)

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

drm/amd/display: Check for NULL pointer

[why & how] Need to make sure plane_state is initialized before accessing its members.

(cherry picked from commit 295d91cbc700651782a60572f83c24861607b648)(CVE-2024-42308)

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

kvm: s390: Reject memory region operations for ucontrol VMs

This change rejects the KVM_SET_USER_MEMORY_REGION and KVM_SET_USER_MEMORY_REGION2 ioctls when called on a ucontrol VM. This is necessary since ucontrol VMs have kvm->arch.gmap set to 0 and would thus result in a null pointer dereference further in. Memory management needs to be performed in userspace and using the ioctls KVM_S390_UCAS_MAP and KVM_S390_UCAS_UNMAP.

Also improve s390 specific documentation for KVM_SET_USER_MEMORY_REGION and KVM_SET_USER_MEMORY_REGION2.

frankja@linux.ibm.com: commit message spelling fix, subject prefix fix

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

ext4: fix infinite loop when replaying fast_commit

When doing fast_commit replay an infinite loop may occur due to an uninitialized extent_status struct. ext4_ext_determine_insert_hole() does not detect the replay and calls ext4_es_find_extent_range(), which will return immediately without initializing the 'es' variable.

Because 'es' contains garbage, an integer overflow may happen causing an infinite loop in this function, easily reproducible using fstest generic/039.

This commit fixes this issue by unconditionally initializing the structure in function ext4_es_find_extent_range().

Thanks to Zhang Yi, for figuring out the real problem!(CVE-2024-43828)

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

media: mediatek: vcodec: Handle invalid decoder vsi

Handle an invalid decoder vsi in vpu_dec_init to ensure the decoder vsi is valid for future use.(CVE-2024-43831)

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

cgroup/cpuset: Prevent UAF in proc_cpuset_show()

An UAF can happen when /proc/cpuset is read as reported in [1].

This can be reproduced by the following methods: 1.add an mdelay(1000) before acquiring the cgroup_lock In the cgroup_path_ns function. 2.$cat /proc/<pid>/cpuset repeatly. 3.$mount -t cgroup -o cpuset cpuset /sys/fs/cgroup/cpuset/ $umount /sys/fs/cgroup/cpuset/ repeatly.

The race that cause this bug can be shown as below:

When the cpuset is initialized, the root node top_cpuset.css.cgrp will point to &cgrp_dfl_root.cgrp. In cgroup v1, the mount operation will allocate cgroup_root, and top_cpuset.css.cgrp will point to the allocated &cgroup_root.cgrp. When the umount operation is executed, top_cpuset.css.cgrp will be rebound to &cgrp_dfl_root.cgrp.

The problem is that when rebinding to cgrp_dfl_root, there are cases where the cgroup_root allocated by setting up the root for cgroup v1 is cached. This could lead to a Use-After-Free (UAF) if it is subsequently freed. The descendant cgroups of cgroup v1 can only be freed after the css is released. However, the css of the root will never be released, yet the cgroup_root should be freed when it is unmounted. This means that obtaining a reference to the css of the root does not guarantee that css.cgrp->root will not be freed.

Fix this problem by using rcu_read_lock in proc_cpuset_show(). As cgroup_root is kfree_rcu after commit d23b5c577715 ("cgroup: Make operations on the cgroup root_list RCU safe"), css->cgroup won't be freed during the critical section. To call cgroup_path_ns_locked, css_set_lock is needed, so it is safe to replace task_get_css with task_css.

[1] https://syzkaller.appspot.com/bug?extid=9b1ff7be974a403aa4cd(CVE-2024-43853)

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

remoteproc: imx_rproc: Skip over memory region when node value is NULL

In imx_rproc_addr_init() "nph = of_count_phandle_with_args()" just counts number of phandles. But phandles may be empty. So of_parse_phandle() in the parsing loop (0 < a < nph) may return NULL which is later dereferenced. Adjust this issue by adding NULL-return check.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Fixed title to fit within the prescribed 70-75 charcters

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

net: usb: qmi_wwan: fix memory leak for not ip packets

Free the unused skb when not ip packets arrive.(CVE-2024-43861)

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

net/mlx5: Always drain health in shutdown callback

There is no point in recovery during device shutdown. if health work started need to wait for it to avoid races and NULL pointer access.

Hence, drain health WQ on shutdown callback.(CVE-2024-43866)

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

wifi: cfg80211: handle 2x996 RU allocation in cfg80211_calculate_bitrate_he()

Currently NL80211_RATE_INFO_HE_RU_ALLOC_2x996 is not handled in cfg80211_calculate_bitrate_he(), leading to below warning:

kernel: invalid HE MCS: bw:6, ru:6 kernel: WARNING: CPU: 0 PID: 2312 at net/wireless/util.c:1501 cfg80211_calculate_bitrate_he+0x22b/0x270 [cfg80211]

Fix it by handling 2x996 RU allocation in the same way as 160 MHz bandwidth.(CVE-2024-43879)

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

exec: Fix ToCToU between perm check and set-uid/gid usage

For example, if a file could change permissions from executable and not set-id:

---------x 1 root root 16048 Aug 7 13:16 target

to set-id and non-executable:

---S------ 1 root root 16048 Aug 7 13:16 target

it is possible to gain root privileges when execution should have been disallowed.

-rwxr-xr-x 1 root cdrom 16048 Aug 7 13:16 target

becomes:

-rwsr-xr-- 1 root cdrom 16048 Aug 7 13:16 target

Severity

7.8 (High)


                    
                      CVSS:3.1/AV:L/AC:L/PR:L/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-2021-47292	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2021-47504	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2021-47556	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-48634	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-48639	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-48642	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-48643	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-48644	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-48647	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-48648	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-48656	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-48663	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-48671	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-48672	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-48675	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-48686	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-48687	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-48691	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-48873	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-48896	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-48898	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-48899	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-48920	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-48935	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2023-52893	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2023-52898	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2023-52901	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2023-52903	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-22386	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-36946	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-38613	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-39490	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-41002	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-41068	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-42120	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-42122	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-42265	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-42271	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-42280	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-42281	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-42284	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-42285	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-42297	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-42305	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-42308	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-43819	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-43828	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-43831	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-43853	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-43860	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-43861	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-43866	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-43879	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-43882	ADVISORY

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "kernel-5.10.0-136.91.0.172.oe2203sp1.aarch64.rpm",
          "kernel-debuginfo-5.10.0-136.91.0.172.oe2203sp1.aarch64.rpm",
          "kernel-debugsource-5.10.0-136.91.0.172.oe2203sp1.aarch64.rpm",
          "kernel-devel-5.10.0-136.91.0.172.oe2203sp1.aarch64.rpm",
          "kernel-headers-5.10.0-136.91.0.172.oe2203sp1.aarch64.rpm",
          "kernel-source-5.10.0-136.91.0.172.oe2203sp1.aarch64.rpm",
          "kernel-tools-5.10.0-136.91.0.172.oe2203sp1.aarch64.rpm",
          "kernel-tools-debuginfo-5.10.0-136.91.0.172.oe2203sp1.aarch64.rpm",
          "kernel-tools-devel-5.10.0-136.91.0.172.oe2203sp1.aarch64.rpm",
          "perf-5.10.0-136.91.0.172.oe2203sp1.aarch64.rpm",
          "perf-debuginfo-5.10.0-136.91.0.172.oe2203sp1.aarch64.rpm",
          "python3-perf-5.10.0-136.91.0.172.oe2203sp1.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-136.91.0.172.oe2203sp1.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-136.91.0.172.oe2203sp1.src.rpm"
        ],
        "x86_64": [
          "kernel-5.10.0-136.91.0.172.oe2203sp1.x86_64.rpm",
          "kernel-debuginfo-5.10.0-136.91.0.172.oe2203sp1.x86_64.rpm",
          "kernel-debugsource-5.10.0-136.91.0.172.oe2203sp1.x86_64.rpm",
          "kernel-devel-5.10.0-136.91.0.172.oe2203sp1.x86_64.rpm",
          "kernel-headers-5.10.0-136.91.0.172.oe2203sp1.x86_64.rpm",
          "kernel-source-5.10.0-136.91.0.172.oe2203sp1.x86_64.rpm",
          "kernel-tools-5.10.0-136.91.0.172.oe2203sp1.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-136.91.0.172.oe2203sp1.x86_64.rpm",
          "kernel-tools-devel-5.10.0-136.91.0.172.oe2203sp1.x86_64.rpm",
          "perf-5.10.0-136.91.0.172.oe2203sp1.x86_64.rpm",
          "perf-debuginfo-5.10.0-136.91.0.172.oe2203sp1.x86_64.rpm",
          "python3-perf-5.10.0-136.91.0.172.oe2203sp1.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-136.91.0.172.oe2203sp1.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:22.03-LTS-SP1",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP1"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.10.0-136.91.0.172.oe2203sp1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nio_uring: fix memleak in io_init_wq_offload()\r\n\r\nI got memory leak report when doing fuzz test:\r\n\r\nBUG: memory leak\nunreferenced object 0xffff888107310a80 (size 96):\ncomm \u0026quot;syz-executor.6\u0026quot;, pid 4610, jiffies 4295140240 (age 20.135s)\nhex dump (first 32 bytes):\n01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N..........\nbacktrace:\n[\u0026lt;000000001974933b\u0026gt;] kmalloc include/linux/slab.h:591 [inline]\n[\u0026lt;000000001974933b\u0026gt;] kzalloc include/linux/slab.h:721 [inline]\n[\u0026lt;000000001974933b\u0026gt;] io_init_wq_offload fs/io_uring.c:7920 [inline]\n[\u0026lt;000000001974933b\u0026gt;] io_uring_alloc_task_context+0x466/0x640 fs/io_uring.c:7955\n[\u0026lt;0000000039d0800d\u0026gt;] __io_uring_add_tctx_node+0x256/0x360 fs/io_uring.c:9016\n[\u0026lt;000000008482e78c\u0026gt;] io_uring_add_tctx_node fs/io_uring.c:9052 [inline]\n[\u0026lt;000000008482e78c\u0026gt;] __do_sys_io_uring_enter fs/io_uring.c:9354 [inline]\n[\u0026lt;000000008482e78c\u0026gt;] __se_sys_io_uring_enter fs/io_uring.c:9301 [inline]\n[\u0026lt;000000008482e78c\u0026gt;] __x64_sys_io_uring_enter+0xabc/0xc20 fs/io_uring.c:9301\n[\u0026lt;00000000b875f18f\u0026gt;] do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n[\u0026lt;00000000b875f18f\u0026gt;] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80\n[\u0026lt;000000006b0a8484\u0026gt;] entry_SYSCALL_64_after_hwframe+0x44/0xae\r\n\r\nCPU0                          CPU1\nio_uring_enter                io_uring_enter\nio_uring_add_tctx_node        io_uring_add_tctx_node\n__io_uring_add_tctx_node      __io_uring_add_tctx_node\nio_uring_alloc_task_context   io_uring_alloc_task_context\nio_init_wq_offload            io_init_wq_offload\nhash = kzalloc                hash = kzalloc\nctx-\u0026gt;hash_map = hash          ctx-\u0026gt;hash_map = hash \u0026lt;- one of the hash is leaked\r\n\r\nWhen calling io_uring_enter() in parallel, the \u0026apos;hash_map\u0026apos; will be leaked,\nadd uring_lock to protect \u0026apos;hash_map\u0026apos;.(CVE-2021-47292)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nio_uring: ensure task_work gets run as part of cancelations\r\n\r\nIf we successfully cancel a work item but that work item needs to be\nprocessed through task_work, then we can be sleeping uninterruptibly\nin io_uring_cancel_generic() and never process it. Hence we don\u0026apos;t\nmake forward progress and we end up with an uninterruptible sleep\nwarning.\r\n\r\nWhile in there, correct a comment that should be IFF, not IIF.(CVE-2021-47504)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nethtool: ioctl: fix potential NULL deref in ethtool_set_coalesce()\r\n\r\nethtool_set_coalesce() now uses both the .get_coalesce() and\n.set_coalesce() callbacks. But the check for their availability is\nbuggy, so changing the coalesce settings on a device where the driver\nprovides only _one_ of the callbacks results in a NULL pointer\ndereference instead of an -EOPNOTSUPP.\r\n\r\nFix the condition so that the availability of both callbacks is\nensured. This also matches the netlink code.\r\n\r\nNote that reproducing this requires some effort - it only affects the\nlegacy ioctl path, and needs a specific combination of driver options:\n- have .get_coalesce() and .coalesce_supported but no\n .set_coalesce(), or\n- have .set_coalesce() but no .get_coalesce(). Here eg. ethtool doesn\u0026apos;t\n  cause the crash as it first attempts to call ethtool_get_coalesce()\n  and bails out on error.(CVE-2021-47556)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/gma500: Fix BUG: sleeping function called from invalid context errors\r\n\r\ngma_crtc_page_flip() was holding the event_lock spinlock while calling\ncrtc_funcs-\u0026gt;mode_set_base() which takes ww_mutex.\r\n\r\nThe only reason to hold event_lock is to clear gma_crtc-\u0026gt;page_flip_event\non mode_set_base() errors.\r\n\r\nInstead unlock it after setting gma_crtc-\u0026gt;page_flip_event and on\nerrors re-take the lock and clear gma_crtc-\u0026gt;page_flip_event it\nit is still set.\r\n\r\nThis fixes the following WARN/stacktrace:\r\n\r\n[  512.122953] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:870\n[  512.123004] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1253, name: gnome-shell\n[  512.123031] preempt_count: 1, expected: 0\n[  512.123048] RCU nest depth: 0, expected: 0\n[  512.123066] INFO: lockdep is turned off.\n[  512.123080] irq event stamp: 0\n[  512.123094] hardirqs last  enabled at (0): [\u0026lt;0000000000000000\u0026gt;] 0x0\n[  512.123134] hardirqs last disabled at (0): [\u0026lt;ffffffff8d0ec28c\u0026gt;] copy_process+0x9fc/0x1de0\n[  512.123176] softirqs last  enabled at (0): [\u0026lt;ffffffff8d0ec28c\u0026gt;] copy_process+0x9fc/0x1de0\n[  512.123207] softirqs last disabled at (0): [\u0026lt;0000000000000000\u0026gt;] 0x0\n[  512.123233] Preemption disabled at:\n[  512.123241] [\u0026lt;0000000000000000\u0026gt;] 0x0\n[  512.123275] CPU: 3 PID: 1253 Comm: gnome-shell Tainted: G        W         5.19.0+ #1\n[  512.123304] Hardware name: Packard Bell dot s/SJE01_CT, BIOS V1.10 07/23/2013\n[  512.123323] Call Trace:\n[  512.123346]  \u0026lt;TASK\u0026gt;\n[  512.123370]  dump_stack_lvl+0x5b/0x77\n[  512.123412]  __might_resched.cold+0xff/0x13a\n[  512.123458]  ww_mutex_lock+0x1e/0xa0\n[  512.123495]  psb_gem_pin+0x2c/0x150 [gma500_gfx]\n[  512.123601]  gma_pipe_set_base+0x76/0x240 [gma500_gfx]\n[  512.123708]  gma_crtc_page_flip+0x95/0x130 [gma500_gfx]\n[  512.123808]  drm_mode_page_flip_ioctl+0x57d/0x5d0\n[  512.123897]  ? drm_mode_cursor2_ioctl+0x10/0x10\n[  512.123936]  drm_ioctl_kernel+0xa1/0x150\n[  512.123984]  drm_ioctl+0x21f/0x420\n[  512.124025]  ? drm_mode_cursor2_ioctl+0x10/0x10\n[  512.124070]  ? rcu_read_lock_bh_held+0xb/0x60\n[  512.124104]  ? lock_release+0x1ef/0x2d0\n[  512.124161]  __x64_sys_ioctl+0x8d/0xd0\n[  512.124203]  do_syscall_64+0x58/0x80\n[  512.124239]  ? do_syscall_64+0x67/0x80\n[  512.124267]  ? trace_hardirqs_on_prepare+0x55/0xe0\n[  512.124300]  ? do_syscall_64+0x67/0x80\n[  512.124340]  ? rcu_read_lock_sched_held+0x10/0x80\n[  512.124377]  entry_SYSCALL_64_after_hwframe+0x63/0xcd\n[  512.124411] RIP: 0033:0x7fcc4a70740f\n[  512.124442] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 \u0026lt;89\u0026gt; c2 3d 00 f0 ff ff 77 18 48 8b 44 24 18 64 48 2b 04 25 28 00 00\n[  512.124470] RSP: 002b:00007ffda73f5390 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\n[  512.124503] RAX: ffffffffffffffda RBX: 000055cc9e474500 RCX: 00007fcc4a70740f\n[  512.124524] RDX: 00007ffda73f5420 RSI: 00000000c01864b0 RDI: 0000000000000009\n[  512.124544] RBP: 00007ffda73f5420 R08: 000055cc9c0b0cb0 R09: 0000000000000034\n[  512.124564] R10: 0000000000000000 R11: 0000000000000246 R12: 00000000c01864b0\n[  512.124584] R13: 0000000000000009 R14: 000055cc9df484d0 R15: 000055cc9af5d0c0\n[  512.124647]  \u0026lt;/TASK\u0026gt;(CVE-2022-48634)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: sched: fix possible refcount leak in tc_new_tfilter()\r\n\r\ntfilter_put need to be called to put the refount got by tp-\u0026gt;ops-\u0026gt;get to\navoid possible refcount leak when chain-\u0026gt;tmplt_ops != NULL and\nchain-\u0026gt;tmplt_ops != tp-\u0026gt;ops.(CVE-2022-48639)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: fix percpu memory leak at nf_tables_addchain()\r\n\r\nIt seems to me that percpu memory for chain stats started leaking since\ncommit 3bc158f8d0330f0a (\u0026quot;netfilter: nf_tables: map basechain priority to\nhardware priority\u0026quot;) when nft_chain_offload_priority() returned an error.(CVE-2022-48642)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: fix nft_counters_enabled underflow at nf_tables_addchain()\r\n\r\nsyzbot is reporting underflow of nft_counters_enabled counter at\nnf_tables_addchain() [1], for commit 43eb8949cfdffa76 (\u0026quot;netfilter:\nnf_tables: do not leave chain stats enabled on error\u0026quot;) missed that\nnf_tables_chain_destroy() after nft_basechain_init() in the error path of\nnf_tables_addchain() decrements the counter because nft_basechain_init()\nmakes nft_is_base_chain() return true by setting NFT_CHAIN_BASE flag.\r\n\r\nIncrement the counter immediately after returning from\nnft_basechain_init().(CVE-2022-48643)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/sched: taprio: avoid disabling offload when it was never enabled\r\n\r\nIn an incredibly strange API design decision, qdisc-\u0026gt;destroy() gets\ncalled even if qdisc-\u0026gt;init() never succeeded, not exclusively since\ncommit 87b60cfacf9f (\u0026quot;net_sched: fix error recovery at qdisc creation\u0026quot;),\nbut apparently also earlier (in the case of qdisc_create_dflt()).\r\n\r\nThe taprio qdisc does not fully acknowledge this when it attempts full\noffload, because it starts off with q-\u0026gt;flags = TAPRIO_FLAGS_INVALID in\ntaprio_init(), then it replaces q-\u0026gt;flags with TCA_TAPRIO_ATTR_FLAGS\nparsed from netlink (in taprio_change(), tail called from taprio_init()).\r\n\r\nBut in taprio_destroy(), we call taprio_disable_offload(), and this\ndetermines what to do based on FULL_OFFLOAD_IS_ENABLED(q-\u0026gt;flags).\r\n\r\nBut looking at the implementation of FULL_OFFLOAD_IS_ENABLED()\n(a bitwise check of bit 1 in q-\u0026gt;flags), it is invalid to call this macro\non q-\u0026gt;flags when it contains TAPRIO_FLAGS_INVALID, because that is set\nto U32_MAX, and therefore FULL_OFFLOAD_IS_ENABLED() will return true on\nan invalid set of flags.\r\n\r\nAs a result, it is possible to crash the kernel if user space forces an\nerror between setting q-\u0026gt;flags = TAPRIO_FLAGS_INVALID, and the calling\nof taprio_enable_offload(). This is because drivers do not expect the\noffload to be disabled when it was never enabled.\r\n\r\nThe error that we force here is to attach taprio as a non-root qdisc,\nbut instead as child of an mqprio root qdisc:\r\n\r\n$ tc qdisc add dev swp0 root handle 1: \\\n\tmqprio num_tc 8 map 0 1 2 3 4 5 6 7 \\\n\tqueues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 hw 0\n$ tc qdisc replace dev swp0 parent 1:1 \\\n\ttaprio num_tc 8 map 0 1 2 3 4 5 6 7 \\\n\tqueues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 base-time 0 \\\n\tsched-entry S 0x7f 990000 sched-entry S 0x80 100000 \\\n\tflags 0x0 clockid CLOCK_TAI\nUnable to handle kernel paging request at virtual address fffffffffffffff8\n[fffffffffffffff8] pgd=0000000000000000, p4d=0000000000000000\nInternal error: Oops: 96000004 [#1] PREEMPT SMP\nCall trace:\n taprio_dump+0x27c/0x310\n vsc9959_port_setup_tc+0x1f4/0x460\n felix_port_setup_tc+0x24/0x3c\n dsa_slave_setup_tc+0x54/0x27c\n taprio_disable_offload.isra.0+0x58/0xe0\n taprio_destroy+0x80/0x104\n qdisc_create+0x240/0x470\n tc_modify_qdisc+0x1fc/0x6b0\n rtnetlink_rcv_msg+0x12c/0x390\n netlink_rcv_skb+0x5c/0x130\n rtnetlink_rcv+0x1c/0x2c\r\n\r\nFix this by keeping track of the operations we made, and undo the\noffload only if we actually did it.\r\n\r\nI\u0026apos;ve added \u0026quot;bool offloaded\u0026quot; inside a 4 byte hole between \u0026quot;int clockid\u0026quot;\nand \u0026quot;atomic64_t picos_per_byte\u0026quot;. Now the first cache line looks like\nbelow:\r\n\r\n$ pahole -C taprio_sched net/sched/sch_taprio.o\nstruct taprio_sched {\n        struct Qdisc * *           qdiscs;               /*     0     8 */\n        struct Qdisc *             root;                 /*     8     8 */\n        u32                        flags;                /*    16     4 */\n        enum tk_offsets            tk_offset;            /*    20     4 */\n        int                        clockid;              /*    24     4 */\n        bool                       offloaded;            /*    28     1 */\r\n\r\n        /* XXX 3 bytes hole, try to pack */\r\n\r\n        atomic64_t                 picos_per_byte;       /*    32     0 */\r\n\r\n        /* XXX 8 bytes hole, try to pack */\r\n\r\n        spinlock_t                 current_entry_lock;   /*    40     0 */\r\n\r\n        /* XXX 8 bytes hole, try to pack */\r\n\r\n        struct sched_entry *       current_entry;        /*    48     8 */\n        struct sched_gate_list *   oper_sched;           /*    56     8 */\n        /* --- cacheline 1 boundary (64 bytes) --- */(CVE-2022-48644)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsfc: fix TX channel offset when using legacy interrupts\r\n\r\nIn legacy interrupt mode the tx_channel_offset was hardcoded to 1, but\nthat\u0026apos;s not correct if efx_sepparate_tx_channels is false. In that case,\nthe offset is 0 because the tx queues are in the single existing channel\nat index 0, together with the rx queue.\r\n\r\nWithout this fix, as soon as you try to send any traffic, it tries to\nget the tx queues from an uninitialized channel getting these errors:\n  WARNING: CPU: 1 PID: 0 at drivers/net/ethernet/sfc/tx.c:540 efx_hard_start_xmit+0x12e/0x170 [sfc]\n  [...]\n  RIP: 0010:efx_hard_start_xmit+0x12e/0x170 [sfc]\n  [...]\n  Call Trace:\n   \u0026lt;IRQ\u0026gt;\n   dev_hard_start_xmit+0xd7/0x230\n   sch_direct_xmit+0x9f/0x360\n   __dev_queue_xmit+0x890/0xa40\n  [...]\n  BUG: unable to handle kernel NULL pointer dereference at 0000000000000020\n  [...]\n  RIP: 0010:efx_hard_start_xmit+0x153/0x170 [sfc]\n  [...]\n  Call Trace:\n   \u0026lt;IRQ\u0026gt;\n   dev_hard_start_xmit+0xd7/0x230\n   sch_direct_xmit+0x9f/0x360\n   __dev_queue_xmit+0x890/0xa40\n  [...](CVE-2022-48647)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsfc: fix null pointer dereference in efx_hard_start_xmit\r\n\r\nTrying to get the channel from the tx_queue variable here is wrong\nbecause we can only be here if tx_queue is NULL, so we shouldn\u0026apos;t\ndereference it. As the above comment in the code says, this is very\nunlikely to happen, but it\u0026apos;s wrong anyway so let\u0026apos;s fix it.\r\n\r\nI hit this issue because of a different bug that caused tx_queue to be\nNULL. If that happens, this is the error message that we get here:\n  BUG: unable to handle kernel NULL pointer dereference at 0000000000000020\n  [...]\n  RIP: 0010:efx_hard_start_xmit+0x153/0x170 [sfc](CVE-2022-48648)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndmaengine: ti: k3-udma-private: Fix refcount leak bug in of_xudma_dev_get()\r\n\r\nWe should call of_node_put() for the reference returned by\nof_parse_phandle() in fail path or when it is not used anymore.\nHere we only need to move the of_node_put() before the check.(CVE-2022-48656)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngpio: mockup: fix NULL pointer dereference when removing debugfs\r\n\r\nWe now remove the device\u0026apos;s debugfs entries when unbinding the driver.\nThis now causes a NULL-pointer dereference on module exit because the\nplatform devices are unregistered *after* the global debugfs directory\nhas been recursively removed. Fix it by unregistering the devices first.(CVE-2022-48663)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncgroup: Add missing cpus_read_lock() to cgroup_attach_task_all()\r\n\r\nsyzbot is hitting percpu_rwsem_assert_held(\u0026amp;cpu_hotplug_lock) warning at\ncpuset_attach() [1], for commit 4f7e7236435ca0ab (\u0026quot;cgroup: Fix\nthreadgroup_rwsem \u0026lt;-\u0026gt; cpus_read_lock() deadlock\u0026quot;) missed that\ncpuset_attach() is also called from cgroup_attach_task_all().\nAdd cpus_read_lock() like what cgroup_procs_write_start() does.(CVE-2022-48671)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nof: fdt: fix off-by-one error in unflatten_dt_nodes()\r\n\r\nCommit 78c44d910d3e (\u0026quot;drivers/of: Fix depth when unflattening devicetree\u0026quot;)\nforgot to fix up the depth check in the loop body in unflatten_dt_nodes()\nwhich makes it possible to overflow the nps[] buffer...\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with the SVACE static\nanalysis tool.(CVE-2022-48672)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nIB/core: Fix a nested dead lock as part of ODP flow\r\n\r\nFix a nested dead lock as part of ODP flow by using mmput_async().\r\n\r\nFrom the below call trace [1] can see that calling mmput() once we have\nthe umem_odp-\u0026gt;umem_mutex locked as required by\nib_umem_odp_map_dma_and_lock() might trigger in the same task the\nexit_mmap()-\u0026gt;__mmu_notifier_release()-\u0026gt;mlx5_ib_invalidate_range() which\nmay dead lock when trying to lock the same mutex.\r\n\r\nMoving to use mmput_async() will solve the problem as the above\nexit_mmap() flow will be called in other task and will be executed once\nthe lock will be available.\r\n\r\n[1]\n[64843.077665] task:kworker/u133:2  state:D stack:    0 pid:80906 ppid:\n2 flags:0x00004000\n[64843.077672] Workqueue: mlx5_ib_page_fault mlx5_ib_eqe_pf_action [mlx5_ib]\n[64843.077719] Call Trace:\n[64843.077722]  \u0026lt;TASK\u0026gt;\n[64843.077724]  __schedule+0x23d/0x590\n[64843.077729]  schedule+0x4e/0xb0\n[64843.077735]  schedule_preempt_disabled+0xe/0x10\n[64843.077740]  __mutex_lock.constprop.0+0x263/0x490\n[64843.077747]  __mutex_lock_slowpath+0x13/0x20\n[64843.077752]  mutex_lock+0x34/0x40\n[64843.077758]  mlx5_ib_invalidate_range+0x48/0x270 [mlx5_ib]\n[64843.077808]  __mmu_notifier_release+0x1a4/0x200\n[64843.077816]  exit_mmap+0x1bc/0x200\n[64843.077822]  ? walk_page_range+0x9c/0x120\n[64843.077828]  ? __cond_resched+0x1a/0x50\n[64843.077833]  ? mutex_lock+0x13/0x40\n[64843.077839]  ? uprobe_clear_state+0xac/0x120\n[64843.077860]  mmput+0x5f/0x140\n[64843.077867]  ib_umem_odp_map_dma_and_lock+0x21b/0x580 [ib_core]\n[64843.077931]  pagefault_real_mr+0x9a/0x140 [mlx5_ib]\n[64843.077962]  pagefault_mr+0xb4/0x550 [mlx5_ib]\n[64843.077992]  pagefault_single_data_segment.constprop.0+0x2ac/0x560\n[mlx5_ib]\n[64843.078022]  mlx5_ib_eqe_pf_action+0x528/0x780 [mlx5_ib]\n[64843.078051]  process_one_work+0x22b/0x3d0\n[64843.078059]  worker_thread+0x53/0x410\n[64843.078065]  ? process_one_work+0x3d0/0x3d0\n[64843.078073]  kthread+0x12a/0x150\n[64843.078079]  ? set_kthread_struct+0x50/0x50\n[64843.078085]  ret_from_fork+0x22/0x30\n[64843.078093]  \u0026lt;/TASK\u0026gt;(CVE-2022-48675)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnvme-tcp: fix UAF when detecting digest errors\r\n\r\nWe should also bail from the io_work loop when we set rd_enabled to true,\nso we don\u0026apos;t attempt to read data from the socket when the TCP stream is\nalready out-of-sync or corrupted.(CVE-2022-48686)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: sr: fix out-of-bounds read when setting HMAC data.\r\n\r\nThe SRv6 layer allows defining HMAC data that can later be used to sign IPv6\nSegment Routing Headers. This configuration is realised via netlink through\nfour attributes: SEG6_ATTR_HMACKEYID, SEG6_ATTR_SECRET, SEG6_ATTR_SECRETLEN and\nSEG6_ATTR_ALGID. Because the SECRETLEN attribute is decoupled from the actual\nlength of the SECRET attribute, it is possible to provide invalid combinations\n(e.g., secret = \u0026quot;\u0026quot;, secretlen = 64). This case is not checked in the code and\nwith an appropriately crafted netlink message, an out-of-bounds read of up\nto 64 bytes (max secret length) can occur past the skb end pointer and into\nskb_shared_info:\r\n\r\nBreakpoint 1, seg6_genl_sethmac (skb=\u0026lt;optimized out\u0026gt;, info=\u0026lt;optimized out\u0026gt;) at net/ipv6/seg6.c:208\n208\t\tmemcpy(hinfo-\u0026gt;secret, secret, slen);\n(gdb) bt\n #0  seg6_genl_sethmac (skb=\u0026lt;optimized out\u0026gt;, info=\u0026lt;optimized out\u0026gt;) at net/ipv6/seg6.c:208\n #1  0xffffffff81e012e9 in genl_family_rcv_msg_doit (skb=skb@entry=0xffff88800b1f9f00, nlh=nlh@entry=0xffff88800b1b7600,\n    extack=extack@entry=0xffffc90000ba7af0, ops=ops@entry=0xffffc90000ba7a80, hdrlen=4, net=0xffffffff84237580 \u0026lt;init_net\u0026gt;, family=\u0026lt;optimized out\u0026gt;,\n    family=\u0026lt;optimized out\u0026gt;) at net/netlink/genetlink.c:731\n #2  0xffffffff81e01435 in genl_family_rcv_msg (extack=0xffffc90000ba7af0, nlh=0xffff88800b1b7600, skb=0xffff88800b1f9f00,\n    family=0xffffffff82fef6c0 \u0026lt;seg6_genl_family\u0026gt;) at net/netlink/genetlink.c:775\n #3  genl_rcv_msg (skb=0xffff88800b1f9f00, nlh=0xffff88800b1b7600, extack=0xffffc90000ba7af0) at net/netlink/genetlink.c:792\n #4  0xffffffff81dfffc3 in netlink_rcv_skb (skb=skb@entry=0xffff88800b1f9f00, cb=cb@entry=0xffffffff81e01350 \u0026lt;genl_rcv_msg\u0026gt;)\n    at net/netlink/af_netlink.c:2501\n #5  0xffffffff81e00919 in genl_rcv (skb=0xffff88800b1f9f00) at net/netlink/genetlink.c:803\n #6  0xffffffff81dff6ae in netlink_unicast_kernel (ssk=0xffff888010eec800, skb=0xffff88800b1f9f00, sk=0xffff888004aed000)\n    at net/netlink/af_netlink.c:1319\n #7  netlink_unicast (ssk=ssk@entry=0xffff888010eec800, skb=skb@entry=0xffff88800b1f9f00, portid=portid@entry=0, nonblock=\u0026lt;optimized out\u0026gt;)\n    at net/netlink/af_netlink.c:1345\n #8  0xffffffff81dff9a4 in netlink_sendmsg (sock=\u0026lt;optimized out\u0026gt;, msg=0xffffc90000ba7e48, len=\u0026lt;optimized out\u0026gt;) at net/netlink/af_netlink.c:1921\n...\n(gdb) p/x ((struct sk_buff *)0xffff88800b1f9f00)-\u0026gt;head + ((struct sk_buff *)0xffff88800b1f9f00)-\u0026gt;end\n$1 = 0xffff88800b1b76c0\n(gdb) p/x secret\n$2 = 0xffff88800b1b76c0\n(gdb) p slen\n$3 = 64 \u0026apos;@\u0026apos;\r\n\r\nThe OOB data can then be read back from userspace by dumping HMAC state. This\ncommit fixes this by ensuring SECRETLEN cannot exceed the actual length of\nSECRET.(CVE-2022-48687)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: clean up hook list when offload flags check fails\r\n\r\nsplice back the hook list so nft_chain_release_hook() has a chance to\nrelease the hooks.\r\n\r\nBUG: memory leak\nunreferenced object 0xffff88810180b100 (size 96):\n  comm \u0026quot;syz-executor133\u0026quot;, pid 3619, jiffies 4294945714 (age 12.690s)\n  hex dump (first 32 bytes):\n    28 64 23 02 81 88 ff ff 28 64 23 02 81 88 ff ff  (d#.....(d#.....\n    90 a8 aa 83 ff ff ff ff 00 00 b5 0f 81 88 ff ff  ................\n  backtrace:\n    [\u0026lt;ffffffff83a8c59b\u0026gt;] kmalloc include/linux/slab.h:600 [inline]\n    [\u0026lt;ffffffff83a8c59b\u0026gt;] nft_netdev_hook_alloc+0x3b/0xc0 net/netfilter/nf_tables_api.c:1901\n    [\u0026lt;ffffffff83a9239a\u0026gt;] nft_chain_parse_netdev net/netfilter/nf_tables_api.c:1998 [inline]\n    [\u0026lt;ffffffff83a9239a\u0026gt;] nft_chain_parse_hook+0x33a/0x530 net/netfilter/nf_tables_api.c:2073\n    [\u0026lt;ffffffff83a9b14b\u0026gt;] nf_tables_addchain.constprop.0+0x10b/0x950 net/netfilter/nf_tables_api.c:2218\n    [\u0026lt;ffffffff83a9c41b\u0026gt;] nf_tables_newchain+0xa8b/0xc60 net/netfilter/nf_tables_api.c:2593\n    [\u0026lt;ffffffff83a3d6a6\u0026gt;] nfnetlink_rcv_batch+0xa46/0xd20 net/netfilter/nfnetlink.c:517\n    [\u0026lt;ffffffff83a3db79\u0026gt;] nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:638 [inline]\n    [\u0026lt;ffffffff83a3db79\u0026gt;] nfnetlink_rcv+0x1f9/0x220 net/netfilter/nfnetlink.c:656\n    [\u0026lt;ffffffff83a13b17\u0026gt;] netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]\n    [\u0026lt;ffffffff83a13b17\u0026gt;] netlink_unicast+0x397/0x4c0 net/netlink/af_netlink.c:1345\n    [\u0026lt;ffffffff83a13fd6\u0026gt;] netlink_sendmsg+0x396/0x710 net/netlink/af_netlink.c:1921\n    [\u0026lt;ffffffff83865ab6\u0026gt;] sock_sendmsg_nosec net/socket.c:714 [inline]\n    [\u0026lt;ffffffff83865ab6\u0026gt;] sock_sendmsg+0x56/0x80 net/socket.c:734\n    [\u0026lt;ffffffff8386601c\u0026gt;] ____sys_sendmsg+0x36c/0x390 net/socket.c:2482\n    [\u0026lt;ffffffff8386a918\u0026gt;] ___sys_sendmsg+0xa8/0x110 net/socket.c:2536\n    [\u0026lt;ffffffff8386aaa8\u0026gt;] __sys_sendmsg+0x88/0x100 net/socket.c:2565\n    [\u0026lt;ffffffff845e5955\u0026gt;] do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n    [\u0026lt;ffffffff845e5955\u0026gt;] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n    [\u0026lt;ffffffff84800087\u0026gt;] entry_SYSCALL_64_after_hwframe+0x63/0xcd(CVE-2022-48691)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmisc: fastrpc: Don\u0026apos;t remove map on creater_process and device_release\r\n\r\nDo not remove the map from the list on error path in\nfastrpc_init_create_process, instead call fastrpc_map_put, to avoid\nuse-after-free. Do not remove it on fastrpc_device_release either,\ncall fastrpc_map_put instead.\r\n\r\nThe fastrpc_free_map is the only proper place to remove the map.\nThis is called only after the reference count is 0.(CVE-2022-48873)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nixgbe: fix pci device refcount leak\r\n\r\nAs the comment of pci_get_domain_bus_and_slot() says, it\nreturns a PCI device with refcount incremented, when finish\nusing it, the caller must decrement the reference count by\ncalling pci_dev_put().\r\n\r\nIn ixgbe_get_first_secondary_devfn() and ixgbe_x550em_a_has_mii(),\npci_dev_put() is called to avoid leak.(CVE-2022-48896)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/msm/dp: do not complete dp_aux_cmd_fifo_tx() if irq is not for aux transfer\r\n\r\nThere are 3 possible interrupt sources are handled by DP controller,\nHPDstatus, Controller state changes and Aux read/write transaction.\nAt every irq, DP controller have to check isr status of every interrupt\nsources and service the interrupt if its isr status bits shows interrupts\nare pending. There is potential race condition may happen at current aux\nisr handler implementation since it is always complete dp_aux_cmd_fifo_tx()\neven irq is not for aux read or write transaction. This may cause aux read\ntransaction return premature if host aux data read is in the middle of\nwaiting for sink to complete transferring data to host while irq happen.\nThis will cause host\u0026apos;s receiving buffer contains unexpected data. This\npatch fixes this problem by checking aux isr and return immediately at\naux isr handler if there are no any isr status bits set.\r\n\r\nCurrent there is a bug report regrading eDP edid corruption happen during\nsystem booting up. After lengthy debugging to found that VIDEO_READY\ninterrupt was continuously firing during system booting up which cause\ndp_aux_isr() to complete dp_aux_cmd_fifo_tx() prematurely to retrieve data\nfrom aux hardware buffer which is not yet contains complete data transfer\nfrom sink. This cause edid corruption.\r\n\r\nFollows are the signature at kernel logs when problem happen,\nEDID has corrupt header\npanel-simple-dp-aux aux-aea0000.edp: Couldn\u0026apos;t identify panel via EDID\r\n\r\nChanges in v2:\n-- do complete if (ret == IRQ_HANDLED) ay dp-aux_isr()\n-- add more commit text\r\n\r\nChanges in v3:\n-- add Stephen suggested\n-- dp_aux_isr() return IRQ_XXX back to caller\n-- dp_ctrl_isr() return IRQ_XXX back to caller\r\n\r\nChanges in v4:\n-- split into two patches\r\n\r\nChanges in v5:\n-- delete empty line between tags\r\n\r\nChanges in v6:\n-- remove extra \u0026quot;that\u0026quot; and fixed line more than 75 char at commit text\r\n\r\nPatchwork: https://patchwork.freedesktop.org/patch/516121/(CVE-2022-48898)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/virtio: Fix GEM handle creation UAF\r\n\r\nUserspace can guess the handle value and try to race GEM object creation\nwith handle close, resulting in a use-after-free if we dereference the\nobject after dropping the handle\u0026apos;s reference.  For that reason, dropping\nthe handle\u0026apos;s reference must be done *after* we are done dereferencing\nthe object.(CVE-2022-48899)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: get rid of warning on transaction commit when using flushoncommit\r\n\r\nWhen using the flushoncommit mount option, during almost every transaction\ncommit we trigger a warning from __writeback_inodes_sb_nr():\r\n\r\n  $ cat fs/fs-writeback.c:\n  (...)\n  static void __writeback_inodes_sb_nr(struct super_block *sb, ...\n  {\n        (...)\n        WARN_ON(!rwsem_is_locked(\u0026amp;sb-\u0026gt;s_umount));\n        (...)\n  }\n  (...)\r\n\r\nThe trace produced in dmesg looks like the following:\r\n\r\n  [947.473890] WARNING: CPU: 5 PID: 930 at fs/fs-writeback.c:2610 __writeback_inodes_sb_nr+0x7e/0xb3\n  [947.481623] Modules linked in: nfsd nls_cp437 cifs asn1_decoder cifs_arc4 fscache cifs_md4 ipmi_ssif\n  [947.489571] CPU: 5 PID: 930 Comm: btrfs-transacti Not tainted 95.16.3-srb-asrock-00001-g36437ad63879 #186\n  [947.497969] RIP: 0010:__writeback_inodes_sb_nr+0x7e/0xb3\n  [947.502097] Code: 24 10 4c 89 44 24 18 c6 (...)\n  [947.519760] RSP: 0018:ffffc90000777e10 EFLAGS: 00010246\n  [947.523818] RAX: 0000000000000000 RBX: 0000000000963300 RCX: 0000000000000000\n  [947.529765] RDX: 0000000000000000 RSI: 000000000000fa51 RDI: ffffc90000777e50\n  [947.535740] RBP: ffff888101628a90 R08: ffff888100955800 R09: ffff888100956000\n  [947.541701] R10: 0000000000000002 R11: 0000000000000001 R12: ffff888100963488\n  [947.547645] R13: ffff888100963000 R14: ffff888112fb7200 R15: ffff888100963460\n  [947.553621] FS:  0000000000000000(0000) GS:ffff88841fd40000(0000) knlGS:0000000000000000\n  [947.560537] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  [947.565122] CR2: 0000000008be50c4 CR3: 000000000220c000 CR4: 00000000001006e0\n  [947.571072] Call Trace:\n  [947.572354]  \u0026lt;TASK\u0026gt;\n  [947.573266]  btrfs_commit_transaction+0x1f1/0x998\n  [947.576785]  ? start_transaction+0x3ab/0x44e\n  [947.579867]  ? schedule_timeout+0x8a/0xdd\n  [947.582716]  transaction_kthread+0xe9/0x156\n  [947.585721]  ? btrfs_cleanup_transaction.isra.0+0x407/0x407\n  [947.590104]  kthread+0x131/0x139\n  [947.592168]  ? set_kthread_struct+0x32/0x32\n  [947.595174]  ret_from_fork+0x22/0x30\n  [947.597561]  \u0026lt;/TASK\u0026gt;\n  [947.598553] ---[ end trace 644721052755541c ]---\r\n\r\nThis is because we started using writeback_inodes_sb() to flush delalloc\nwhen committing a transaction (when using -o flushoncommit), in order to\navoid deadlocks with filesystem freeze operations. This change was made\nby commit ce8ea7cc6eb313 (\u0026quot;btrfs: don\u0026apos;t call btrfs_start_delalloc_roots\nin flushoncommit\u0026quot;). After that change we started producing that warning,\nand every now and then a user reports this since the warning happens too\noften, it spams dmesg/syslog, and a user is unsure if this reflects any\nproblem that might compromise the filesystem\u0026apos;s reliability.\r\n\r\nWe can not just lock the sb-\u0026gt;s_umount semaphore before calling\nwriteback_inodes_sb(), because that would at least deadlock with\nfilesystem freezing, since at fs/super.c:freeze_super() sync_filesystem()\nis called while we are holding that semaphore in write mode, and that can\ntrigger a transaction commit, resulting in a deadlock. It would also\ntrigger the same type of deadlock in the unmount path. Possibly, it could\nalso introduce some other locking dependencies that lockdep would report.\r\n\r\nTo fix this call try_to_writeback_inodes_sb() instead of\nwriteback_inodes_sb(), because that will try to read lock sb-\u0026gt;s_umount\nand then will only call writeback_inodes_sb() if it was able to lock it.\nThis is fine because the cases where it can\u0026apos;t read lock sb-\u0026gt;s_umount\nare during a filesystem unmount or during a filesystem freeze - in those\ncases sb-\u0026gt;s_umount is write locked and sync_filesystem() is called, which\ncalls writeback_inodes_sb(). In other words, in all cases where we can\u0026apos;t\ntake a read lock on sb-\u0026gt;s_umount, writeback is already being triggered\nelsewhere.\r\n\r\nAn alternative would be to call btrfs_start_delalloc_roots() with a\nnumber of pages different from LONG_MAX, for example matching the number\nof delalloc bytes we currently have, in \n---truncated---(CVE-2022-48920)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: unregister flowtable hooks on netns exit\r\n\r\nUnregister flowtable hooks before they are releases via\nnf_tables_flowtable_destroy() otherwise hook core reports UAF.\r\n\r\nBUG: KASAN: use-after-free in nf_hook_entries_grow+0x5a7/0x700 net/netfilter/core.c:142 net/netfilter/core.c:142\nRead of size 4 at addr ffff8880736f7438 by task syz-executor579/3666\r\n\r\nCPU: 0 PID: 3666 Comm: syz-executor579 Not tainted 5.16.0-rc5-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n __dump_stack lib/dump_stack.c:88 [inline] lib/dump_stack.c:106\n dump_stack_lvl+0x1dc/0x2d8 lib/dump_stack.c:106 lib/dump_stack.c:106\n print_address_description+0x65/0x380 mm/kasan/report.c:247 mm/kasan/report.c:247\n __kasan_report mm/kasan/report.c:433 [inline]\n __kasan_report mm/kasan/report.c:433 [inline] mm/kasan/report.c:450\n kasan_report+0x19a/0x1f0 mm/kasan/report.c:450 mm/kasan/report.c:450\n nf_hook_entries_grow+0x5a7/0x700 net/netfilter/core.c:142 net/netfilter/core.c:142\n __nf_register_net_hook+0x27e/0x8d0 net/netfilter/core.c:429 net/netfilter/core.c:429\n nf_register_net_hook+0xaa/0x180 net/netfilter/core.c:571 net/netfilter/core.c:571\n nft_register_flowtable_net_hooks+0x3c5/0x730 net/netfilter/nf_tables_api.c:7232 net/netfilter/nf_tables_api.c:7232\n nf_tables_newflowtable+0x2022/0x2cf0 net/netfilter/nf_tables_api.c:7430 net/netfilter/nf_tables_api.c:7430\n nfnetlink_rcv_batch net/netfilter/nfnetlink.c:513 [inline]\n nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:634 [inline]\n nfnetlink_rcv_batch net/netfilter/nfnetlink.c:513 [inline] net/netfilter/nfnetlink.c:652\n nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:634 [inline] net/netfilter/nfnetlink.c:652\n nfnetlink_rcv+0x10e6/0x2550 net/netfilter/nfnetlink.c:652 net/netfilter/nfnetlink.c:652\r\n\r\n__nft_release_hook() calls nft_unregister_flowtable_net_hooks() which\nonly unregisters the hooks, then after RCU grace period, it is\nguaranteed that no packets add new entries to the flowtable (no flow\noffload rules and flowtable hooks are reachable from packet path), so it\nis safe to call nf_flow_table_free() which cleans up the remaining\nentries from the flowtable (both software and hardware) and it unbinds\nthe flow_block.(CVE-2022-48935)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngsmi: fix null-deref in gsmi_get_variable\r\n\r\nWe can get EFI variables without fetching the attribute, so we must\nallow for that in gsmi.\r\n\r\ncommit 859748255b43 (\u0026quot;efi: pstore: Omit efivars caching EFI varstore\naccess layer\u0026quot;) added a new get_variable call with attr=NULL, which\ntriggers panic in gsmi.(CVE-2023-52893)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nxhci: Fix null pointer dereference when host dies\r\n\r\nMake sure xhci_free_dev() and xhci_kill_endpoint_urbs() do not race\nand cause null pointer dereference when host suddenly dies.\r\n\r\nUsb core may call xhci_free_dev() which frees the xhci-\u0026gt;devs[slot_id]\nvirt device at the same time that xhci_kill_endpoint_urbs() tries to\nloop through all the device\u0026apos;s endpoints, checking if there are any\ncancelled urbs left to give back.\r\n\r\nhold the xhci spinlock while freeing the virt device(CVE-2023-52898)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: xhci: Check endpoint is valid before dereferencing it\r\n\r\nWhen the host controller is not responding, all URBs queued to all\nendpoints need to be killed. This can cause a kernel panic if we\ndereference an invalid endpoint.\r\n\r\nFix this by using xhci_get_virt_ep() helper to find the endpoint and\nchecking if the endpoint is valid before dereferencing it.\r\n\r\n[233311.853271] xhci-hcd xhci-hcd.1.auto: xHCI host controller not responding, assume dead\n[233311.853393] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000e8\r\n\r\n[233311.853964] pc : xhci_hc_died+0x10c/0x270\n[233311.853971] lr : xhci_hc_died+0x1ac/0x270\r\n\r\n[233311.854077] Call trace:\n[233311.854085]  xhci_hc_died+0x10c/0x270\n[233311.854093]  xhci_stop_endpoint_command_watchdog+0x100/0x1a4\n[233311.854105]  call_timer_fn+0x50/0x2d4\n[233311.854112]  expire_timers+0xac/0x2e4\n[233311.854118]  run_timer_softirq+0x300/0xabc\n[233311.854127]  __do_softirq+0x148/0x528\n[233311.854135]  irq_exit+0x194/0x1a8\n[233311.854143]  __handle_domain_irq+0x164/0x1d0\n[233311.854149]  gic_handle_irq.22273+0x10c/0x188\n[233311.854156]  el1_irq+0xfc/0x1a8\n[233311.854175]  lpm_cpuidle_enter+0x25c/0x418 [msm_pm]\n[233311.854185]  cpuidle_enter_state+0x1f0/0x764\n[233311.854194]  do_idle+0x594/0x6ac\n[233311.854201]  cpu_startup_entry+0x7c/0x80\n[233311.854209]  secondary_start_kernel+0x170/0x198(CVE-2023-52901)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nio_uring: lock overflowing for IOPOLL\r\n\r\nsyzbot reports an issue with overflow filling for IOPOLL:\r\n\r\nWARNING: CPU: 0 PID: 28 at io_uring/io_uring.c:734 io_cqring_event_overflow+0x1c0/0x230 io_uring/io_uring.c:734\nCPU: 0 PID: 28 Comm: kworker/u4:1 Not tainted 6.2.0-rc3-syzkaller-16369-g358a161a6a9e #0\nWorkqueue: events_unbound io_ring_exit_work\nCall trace:\n\u00a0io_cqring_event_overflow+0x1c0/0x230 io_uring/io_uring.c:734\n\u00a0io_req_cqe_overflow+0x5c/0x70 io_uring/io_uring.c:773\n\u00a0io_fill_cqe_req io_uring/io_uring.h:168 [inline]\n\u00a0io_do_iopoll+0x474/0x62c io_uring/rw.c:1065\n\u00a0io_iopoll_try_reap_events+0x6c/0x108 io_uring/io_uring.c:1513\n\u00a0io_uring_try_cancel_requests+0x13c/0x258 io_uring/io_uring.c:3056\n\u00a0io_ring_exit_work+0xec/0x390 io_uring/io_uring.c:2869\n\u00a0process_one_work+0x2d8/0x504 kernel/workqueue.c:2289\n\u00a0worker_thread+0x340/0x610 kernel/workqueue.c:2436\n\u00a0kthread+0x12c/0x158 kernel/kthread.c:376\n\u00a0ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:863\r\n\r\nThere is no real problem for normal IOPOLL as flush is also called with\nuring_lock taken, but it\u0026apos;s getting more complicated for IOPOLL|SQPOLL,\nfor which __io_cqring_overflow_flush() happens from the CQ waiting path.(CVE-2023-52903)\r\n\r\nA race condition was found in the Linux kernel\u0026apos;s drm/exynos device driver in\u00a0exynos_drm_crtc_atomic_disable() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.\r\n\r\n\n(CVE-2024-22386)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nphonet: fix rtm_phonet_notify() skb allocation\r\n\r\nfill_route() stores three components in the skb:\r\n\r\n- struct rtmsg\n- RTA_DST (u8)\n- RTA_OIF (u32)\r\n\r\nTherefore, rtm_phonet_notify() should use\r\n\r\nNLMSG_ALIGN(sizeof(struct rtmsg)) +\nnla_total_size(1) +\nnla_total_size(4)(CVE-2024-36946)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nm68k: Fix spinlock race in kernel thread creation\r\n\r\nContext switching does take care to retain the correct lock owner across\nthe switch from \u0026apos;prev\u0026apos; to \u0026apos;next\u0026apos; tasks.  This does rely on interrupts\nremaining disabled for the entire duration of the switch.\r\n\r\nThis condition is guaranteed for normal process creation and context\nswitching between already running processes, because both \u0026apos;prev\u0026apos; and\n\u0026apos;next\u0026apos; already have interrupts disabled in their saved copies of the\nstatus register.\r\n\r\nThe situation is different for newly created kernel threads.  The status\nregister is set to PS_S in copy_thread(), which does leave the IPL at 0.\nUpon restoring the \u0026apos;next\u0026apos; thread\u0026apos;s status register in switch_to() aka\nresume(), interrupts then become enabled prematurely.  resume() then\nreturns via ret_from_kernel_thread() and schedule_tail() where run queue\nlock is released (see finish_task_switch() and finish_lock_switch()).\r\n\r\nA timer interrupt calling scheduler_tick() before the lock is released\nin finish_task_switch() will find the lock already taken, with the\ncurrent task as lock owner.  This causes a spinlock recursion warning as\nreported by Guenter Roeck.\r\n\r\nAs far as I can ascertain, this race has been opened in commit\n533e6903bea0 (\u0026quot;m68k: split ret_from_fork(), simplify kernel_thread()\u0026quot;)\nbut I haven\u0026apos;t done a detailed study of kernel history so it may well\npredate that commit.\r\n\r\nInterrupts cannot be disabled in the saved status register copy for\nkernel threads (init will complain about interrupts disabled when\nfinally starting user space).  Disable interrupts temporarily when\nswitching the tasks\u0026apos; register sets in resume().\r\n\r\nNote that a simple oriw 0x700,%sr after restoring sr is not enough here\n- this leaves enough of a race for the \u0026apos;spinlock recursion\u0026apos; warning to\nstill be observed.\r\n\r\nTested on ARAnyM and qemu (Quadra 800 emulation).(CVE-2024-38613)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: sr: fix missing sk_buff release in seg6_input_core\r\n\r\nThe seg6_input() function is responsible for adding the SRH into a\npacket, delegating the operation to the seg6_input_core(). This function\nuses the skb_cow_head() to ensure that there is sufficient headroom in\nthe sk_buff for accommodating the link-layer header.\nIn the event that the skb_cow_header() function fails, the\nseg6_input_core() catches the error but it does not release the sk_buff,\nwhich will result in a memory leak.\r\n\r\nThis issue was introduced in commit af3b5158b89d (\u0026quot;ipv6: sr: fix BUG due\nto headroom too small after SRH push\u0026quot;) and persists even after commit\n7a3f5b0de364 (\u0026quot;netfilter: add netfilter hooks to SRv6 data plane\u0026quot;),\nwhere the entire seg6_input() code was refactored to deal with netfilter\nhooks.\r\n\r\nThe proposed patch addresses the identified memory leak by requiring the\nseg6_input_core() function to release the sk_buff in the event that\nskb_cow_head() fails.(CVE-2024-39490)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncrypto: hisilicon/sec - Fix memory leak for sec resource release\r\n\r\nThe AIV is one of the SEC resources. When releasing resources,\nit need to release the AIV resources at the same time.\nOtherwise, memory leakage occurs.\r\n\r\nThe aiv resource release is added to the sec resource release\nfunction.(CVE-2024-41002)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/sclp: Fix sclp_init() cleanup on failure\r\n\r\nIf sclp_init() fails it only partially cleans up: if there are multiple\nfailing calls to sclp_init() sclp_state_change_event will be added several\ntimes to sclp_reg_list, which results in the following warning:\r\n\r\n------------[ cut here ]------------\nlist_add double add: new=000003ffe1598c10, prev=000003ffe1598bf0, next=000003ffe1598c10.\nWARNING: CPU: 0 PID: 1 at lib/list_debug.c:35 __list_add_valid_or_report+0xde/0xf8\nCPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.10.0-rc3\nKrnl PSW : 0404c00180000000 000003ffe0d6076a (__list_add_valid_or_report+0xe2/0xf8)\n           R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3\n...\nCall Trace:\n [\u0026lt;000003ffe0d6076a\u0026gt;] __list_add_valid_or_report+0xe2/0xf8\n([\u0026lt;000003ffe0d60766\u0026gt;] __list_add_valid_or_report+0xde/0xf8)\n [\u0026lt;000003ffe0a8d37e\u0026gt;] sclp_init+0x40e/0x450\n [\u0026lt;000003ffe00009f2\u0026gt;] do_one_initcall+0x42/0x1e0\n [\u0026lt;000003ffe15b77a6\u0026gt;] do_initcalls+0x126/0x150\n [\u0026lt;000003ffe15b7a0a\u0026gt;] kernel_init_freeable+0x1ba/0x1f8\n [\u0026lt;000003ffe0d6650e\u0026gt;] kernel_init+0x2e/0x180\n [\u0026lt;000003ffe000301c\u0026gt;] __ret_from_fork+0x3c/0x60\n [\u0026lt;000003ffe0d759ca\u0026gt;] ret_from_fork+0xa/0x30\r\n\r\nFix this by removing sclp_state_change_event from sclp_reg_list when\nsclp_init() fails.(CVE-2024-41068)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Check pipe offset before setting vblank\r\n\r\npipe_ctx has a size of MAX_PIPES so checking its index before accessing\nthe array.\r\n\r\nThis fixes an OVERRUN issue reported by Coverity.(CVE-2024-42120)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Add NULL pointer check for kzalloc\r\n\r\n[Why \u0026amp; How]\nCheck return pointer of kzalloc before using it.(CVE-2024-42122)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nprotect the fetch of -\u0026gt;fd[fd] in do_dup2() from mispredictions\r\n\r\nboth callers have verified that fd is not greater than -\u0026gt;max_fds;\nhowever, misprediction might end up with\n        tofree = fdt-\u0026gt;fd[fd];\nbeing speculatively executed.  That\u0026apos;s wrong for the same reasons\nwhy it\u0026apos;s wrong in close_fd()/file_close_fd_locked(); the same\nsolution applies - array_index_nospec(fd, fdt-\u0026gt;max_fds) could differ\nfrom fd only in case of speculative execution on mispredicted path.(CVE-2024-42265)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/iucv: fix use after free in iucv_sock_close()\r\n\r\niucv_sever_path() is called from process context and from bh context.\niucv-\u0026gt;path is used as indicator whether somebody else is taking care of\nsevering the path (or it is already removed / never existed).\nThis needs to be done with atomic compare and swap, otherwise there is a\nsmall window where iucv_sock_close() will try to work with a path that has\nalready been severed and freed by iucv_callback_connrej() called by\niucv_tasklet_fn().\r\n\r\nExample:\n[452744.123844] Call Trace:\n[452744.123845] ([\u0026lt;0000001e87f03880\u0026gt;] 0x1e87f03880)\n[452744.123966]  [\u0026lt;00000000d593001e\u0026gt;] iucv_path_sever+0x96/0x138\n[452744.124330]  [\u0026lt;000003ff801ddbca\u0026gt;] iucv_sever_path+0xc2/0xd0 [af_iucv]\n[452744.124336]  [\u0026lt;000003ff801e01b6\u0026gt;] iucv_sock_close+0xa6/0x310 [af_iucv]\n[452744.124341]  [\u0026lt;000003ff801e08cc\u0026gt;] iucv_sock_release+0x3c/0xd0 [af_iucv]\n[452744.124345]  [\u0026lt;00000000d574794e\u0026gt;] __sock_release+0x5e/0xe8\n[452744.124815]  [\u0026lt;00000000d5747a0c\u0026gt;] sock_close+0x34/0x48\n[452744.124820]  [\u0026lt;00000000d5421642\u0026gt;] __fput+0xba/0x268\n[452744.124826]  [\u0026lt;00000000d51b382c\u0026gt;] task_work_run+0xbc/0xf0\n[452744.124832]  [\u0026lt;00000000d5145710\u0026gt;] do_notify_resume+0x88/0x90\n[452744.124841]  [\u0026lt;00000000d5978096\u0026gt;] system_call+0xe2/0x2c8\n[452744.125319] Last Breaking-Event-Address:\n[452744.125321]  [\u0026lt;00000000d5930018\u0026gt;] iucv_path_sever+0x90/0x138\n[452744.125324]\n[452744.125325] Kernel panic - not syncing: Fatal exception in interrupt\r\n\r\nNote that bh_lock_sock() is not serializing the tasklet context against\nprocess context, because the check for sock_owned_by_user() and\ncorresponding handling is missing.\r\n\r\nIdeas for a future clean-up patch:\nA) Correct usage of bh_lock_sock() in tasklet context, as described in\nRe-enqueue, if needed. This may require adding return values to the\ntasklet functions and thus changes to all users of iucv.\r\n\r\nB) Change iucv tasklet into worker and use only lock_sock() in af_iucv.(CVE-2024-42271)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmISDN: Fix a use after free in hfcmulti_tx()\r\n\r\nDon\u0026apos;t dereference *sp after calling dev_kfree_skb(*sp).(CVE-2024-42280)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf: Fix a segment issue when downgrading gso_size\r\n\r\nLinearize the skb when downgrading gso_size because it may trigger a\nBUG_ON() later when the skb is segmented as described in [1,2].(CVE-2024-42281)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntipc: Return non-zero value from tipc_udp_addr2str() on error\r\n\r\ntipc_udp_addr2str() should return non-zero value if the UDP media\naddress is invalid. Otherwise, a buffer overflow access can occur in\ntipc_media_addr_printf(). Fix this by returning 1 on an invalid UDP\nmedia address.(CVE-2024-42284)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nRDMA/iwcm: Fix a use-after-free related to destroying CM IDs\r\n\r\niw_conn_req_handler() associates a new struct rdma_id_private (conn_id) with\nan existing struct iw_cm_id (cm_id) as follows:\r\n\r\n        conn_id-\u0026gt;cm_id.iw = cm_id;\n        cm_id-\u0026gt;context = conn_id;\n        cm_id-\u0026gt;cm_handler = cma_iw_handler;\r\n\r\nrdma_destroy_id() frees both the cm_id and the struct rdma_id_private. Make\nsure that cm_work_handler() does not trigger a use-after-free by only\nfreeing of the struct rdma_id_private after all pending work has finished.(CVE-2024-42285)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: fix to don\u0026apos;t dirty inode for readonly filesystem\r\n\r\nsyzbot reports f2fs bug as below:\r\n\r\nkernel BUG at fs/f2fs/inode.c:933!\nRIP: 0010:f2fs_evict_inode+0x1576/0x1590 fs/f2fs/inode.c:933\nCall Trace:\n evict+0x2a4/0x620 fs/inode.c:664\n dispose_list fs/inode.c:697 [inline]\n evict_inodes+0x5f8/0x690 fs/inode.c:747\n generic_shutdown_super+0x9d/0x2c0 fs/super.c:675\n kill_block_super+0x44/0x90 fs/super.c:1667\n kill_f2fs_super+0x303/0x3b0 fs/f2fs/super.c:4894\n deactivate_locked_super+0xc1/0x130 fs/super.c:484\n cleanup_mnt+0x426/0x4c0 fs/namespace.c:1256\n task_work_run+0x24a/0x300 kernel/task_work.c:180\n ptrace_notify+0x2cd/0x380 kernel/signal.c:2399\n ptrace_report_syscall include/linux/ptrace.h:411 [inline]\n ptrace_report_syscall_exit include/linux/ptrace.h:473 [inline]\n syscall_exit_work kernel/entry/common.c:251 [inline]\n syscall_exit_to_user_mode_prepare kernel/entry/common.c:278 [inline]\n __syscall_exit_to_user_mode_work kernel/entry/common.c:283 [inline]\n syscall_exit_to_user_mode+0x15c/0x280 kernel/entry/common.c:296\n do_syscall_64+0x50/0x110 arch/x86/entry/common.c:88\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\r\n\r\nThe root cause is:\n- do_sys_open\n - f2fs_lookup\n  - __f2fs_find_entry\n   - f2fs_i_depth_write\n    - f2fs_mark_inode_dirty_sync\n     - f2fs_dirty_inode\n      - set_inode_flag(inode, FI_DIRTY_INODE)\r\n\r\n- umount\n - kill_f2fs_super\n  - kill_block_super\n   - generic_shutdown_super\n    - sync_filesystem\n    : sb is readonly, skip sync_filesystem()\n    - evict_inodes\n     - iput\n      - f2fs_evict_inode\n       - f2fs_bug_on(sbi, is_inode_flag_set(inode, FI_DIRTY_INODE))\n       : trigger kernel panic\r\n\r\nWhen we try to repair i_current_depth in readonly filesystem, let\u0026apos;s\nskip dirty inode to avoid panic in later f2fs_evict_inode().(CVE-2024-42297)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\next4: check dot and dotdot of dx_root before making dir indexed\r\n\r\nSyzbot reports a issue as follows:\n============================================\nBUG: unable to handle page fault for address: ffffed11022e24fe\nPGD 23ffee067 P4D 23ffee067 PUD 0\nOops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI\nCPU: 0 PID: 5079 Comm: syz-executor306 Not tainted 6.10.0-rc5-g55027e689933 #0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n make_indexed_dir+0xdaf/0x13c0 fs/ext4/namei.c:2341\n ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2451\n ext4_rename fs/ext4/namei.c:3936 [inline]\n ext4_rename2+0x26e5/0x4370 fs/ext4/namei.c:4214\n[...]\n============================================\r\n\r\nThe immediate cause of this problem is that there is only one valid dentry\nfor the block to be split during do_split, so split==0 results in out of\nbounds accesses to the map triggering the issue.\r\n\r\n    do_split\n      unsigned split\n      dx_make_map\n       count = 1\n      split = count/2 = 0;\n      continued = hash2 == map[split - 1].hash;\n       ---\u0026gt; map[4294967295]\r\n\r\nThe maximum length of a filename is 255 and the minimum block size is 1024,\nso it is always guaranteed that the number of entries is greater than or\nequal to 2 when do_split() is called.\r\n\r\nBut syzbot\u0026apos;s crafted image has no dot and dotdot in dir, and the dentry\ndistribution in dirblock is as follows:\r\n\r\n  bus     dentry1          hole           dentry2           free\n|xx--|xx-------------|...............|xx-------------|...............|\n0   12 (8+248)=256  268     256     524 (8+256)=264 788     236     1024\r\n\r\nSo when renaming dentry1 increases its name_len length by 1, neither hole\nnor free is sufficient to hold the new dentry, and make_indexed_dir() is\ncalled.\r\n\r\nIn make_indexed_dir() it is assumed that the first two entries of the\ndirblock must be dot and dotdot, so bus and dentry1 are left in dx_root\nbecause they are treated as dot and dotdot, and only dentry2 is moved\nto the new leaf block. That\u0026apos;s why count is equal to 1.\r\n\r\nTherefore add the ext4_check_dx_root() helper function to add more sanity\nchecks to dot and dotdot before starting the conversion to avoid the above\nissue.(CVE-2024-42305)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Check for NULL pointer\r\n\r\n[why \u0026amp; how]\nNeed to make sure plane_state is initialized\nbefore accessing its members.\r\n\r\n(cherry picked from commit 295d91cbc700651782a60572f83c24861607b648)(CVE-2024-42308)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nkvm: s390: Reject memory region operations for ucontrol VMs\r\n\r\nThis change rejects the KVM_SET_USER_MEMORY_REGION and\nKVM_SET_USER_MEMORY_REGION2 ioctls when called on a ucontrol VM.\nThis is necessary since ucontrol VMs have kvm-\u0026gt;arch.gmap set to 0 and\nwould thus result in a null pointer dereference further in.\nMemory management needs to be performed in userspace and using the\nioctls KVM_S390_UCAS_MAP and KVM_S390_UCAS_UNMAP.\r\n\r\nAlso improve s390 specific documentation for KVM_SET_USER_MEMORY_REGION\nand KVM_SET_USER_MEMORY_REGION2.\r\n\r\n[frankja@linux.ibm.com: commit message spelling fix, subject prefix fix](CVE-2024-43819)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\next4: fix infinite loop when replaying fast_commit\r\n\r\nWhen doing fast_commit replay an infinite loop may occur due to an\nuninitialized extent_status struct.  ext4_ext_determine_insert_hole() does\nnot detect the replay and calls ext4_es_find_extent_range(), which will\nreturn immediately without initializing the \u0026apos;es\u0026apos; variable.\r\n\r\nBecause \u0026apos;es\u0026apos; contains garbage, an integer overflow may happen causing an\ninfinite loop in this function, easily reproducible using fstest generic/039.\r\n\r\nThis commit fixes this issue by unconditionally initializing the structure\nin function ext4_es_find_extent_range().\r\n\r\nThanks to Zhang Yi, for figuring out the real problem!(CVE-2024-43828)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: mediatek: vcodec: Handle invalid decoder vsi\r\n\r\nHandle an invalid decoder vsi in vpu_dec_init to ensure the decoder vsi\nis valid for future use.(CVE-2024-43831)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncgroup/cpuset: Prevent UAF in proc_cpuset_show()\r\n\r\nAn UAF can happen when /proc/cpuset is read as reported in [1].\r\n\r\nThis can be reproduced by the following methods:\n1.add an mdelay(1000) before acquiring the cgroup_lock In the\n cgroup_path_ns function.\n2.$cat /proc/\u0026lt;pid\u0026gt;/cpuset   repeatly.\n3.$mount -t cgroup -o cpuset cpuset /sys/fs/cgroup/cpuset/\n$umount /sys/fs/cgroup/cpuset/   repeatly.\r\n\r\nThe race that cause this bug can be shown as below:\r\n\r\n(umount)\t\t|\t(cat /proc/\u0026lt;pid\u0026gt;/cpuset)\ncss_release\t\t|\tproc_cpuset_show\ncss_release_work_fn\t|\tcss = task_get_css(tsk, cpuset_cgrp_id);\ncss_free_rwork_fn\t|\tcgroup_path_ns(css-\u0026gt;cgroup, ...);\ncgroup_destroy_root\t|\tmutex_lock(\u0026amp;cgroup_mutex);\nrebind_subsystems\t|\ncgroup_free_root \t|\n\t\t\t|\t// cgrp was freed, UAF\n\t\t\t|\tcgroup_path_ns_locked(cgrp,..);\r\n\r\nWhen the cpuset is initialized, the root node top_cpuset.css.cgrp\nwill point to \u0026amp;cgrp_dfl_root.cgrp. In cgroup v1, the mount operation will\nallocate cgroup_root, and top_cpuset.css.cgrp will point to the allocated\n\u0026amp;cgroup_root.cgrp. When the umount operation is executed,\ntop_cpuset.css.cgrp will be rebound to \u0026amp;cgrp_dfl_root.cgrp.\r\n\r\nThe problem is that when rebinding to cgrp_dfl_root, there are cases\nwhere the cgroup_root allocated by setting up the root for cgroup v1\nis cached. This could lead to a Use-After-Free (UAF) if it is\nsubsequently freed. The descendant cgroups of cgroup v1 can only be\nfreed after the css is released. However, the css of the root will never\nbe released, yet the cgroup_root should be freed when it is unmounted.\nThis means that obtaining a reference to the css of the root does\nnot guarantee that css.cgrp-\u0026gt;root will not be freed.\r\n\r\nFix this problem by using rcu_read_lock in proc_cpuset_show().\nAs cgroup_root is kfree_rcu after commit d23b5c577715\n(\u0026quot;cgroup: Make operations on the cgroup root_list RCU safe\u0026quot;),\ncss-\u0026gt;cgroup won\u0026apos;t be freed during the critical section.\nTo call cgroup_path_ns_locked, css_set_lock is needed, so it is safe to\nreplace task_get_css with task_css.\r\n\r\n[1] https://syzkaller.appspot.com/bug?extid=9b1ff7be974a403aa4cd(CVE-2024-43853)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nremoteproc: imx_rproc: Skip over memory region when node value is NULL\r\n\r\nIn imx_rproc_addr_init() \u0026quot;nph = of_count_phandle_with_args()\u0026quot; just counts\nnumber of phandles. But phandles may be empty. So of_parse_phandle() in\nthe parsing loop (0 \u0026lt; a \u0026lt; nph) may return NULL which is later dereferenced.\nAdjust this issue by adding NULL-return check.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.\r\n\r\n[Fixed title to fit within the prescribed 70-75 charcters](CVE-2024-43860)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: usb: qmi_wwan: fix memory leak for not ip packets\r\n\r\nFree the unused skb when not ip packets arrive.(CVE-2024-43861)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5: Always drain health in shutdown callback\r\n\r\nThere is no point in recovery during device shutdown. if health\nwork started need to wait for it to avoid races and NULL pointer\naccess.\r\n\r\nHence, drain health WQ on shutdown callback.(CVE-2024-43866)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: cfg80211: handle 2x996 RU allocation in cfg80211_calculate_bitrate_he()\r\n\r\nCurrently NL80211_RATE_INFO_HE_RU_ALLOC_2x996 is not handled in\ncfg80211_calculate_bitrate_he(), leading to below warning:\r\n\r\nkernel: invalid HE MCS: bw:6, ru:6\nkernel: WARNING: CPU: 0 PID: 2312 at net/wireless/util.c:1501 cfg80211_calculate_bitrate_he+0x22b/0x270 [cfg80211]\r\n\r\nFix it by handling 2x996 RU allocation in the same way as 160 MHz bandwidth.(CVE-2024-43879)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nexec: Fix ToCToU between perm check and set-uid/gid usage\r\n\r\nWhen opening a file for exec via do_filp_open(), permission checking is\ndone against the file\u0026apos;s metadata at that moment, and on success, a file\npointer is passed back. Much later in the execve() code path, the file\nmetadata (specifically mode, uid, and gid) is used to determine if/how\nto set the uid and gid. However, those values may have changed since the\npermissions check, meaning the execution may gain unintended privileges.\r\n\r\nFor example, if a file could change permissions from executable and not\nset-id:\r\n\r\n---------x 1 root root 16048 Aug  7 13:16 target\r\n\r\nto set-id and non-executable:\r\n\r\n---S------ 1 root root 16048 Aug  7 13:16 target\r\n\r\nit is possible to gain root privileges when execution should have been\ndisallowed.\r\n\r\nWhile this race condition is rare in real-world scenarios, it has been\nobserved (and proven exploitable) when package managers are updating\nthe setuid bits of installed programs. Such files start with being\nworld-executable but then are adjusted to be group-exec with a set-uid\nbit. For example, \u0026quot;chmod o-x,u+s target\u0026quot; makes \u0026quot;target\u0026quot; executable only\nby uid \u0026quot;root\u0026quot; and gid \u0026quot;cdrom\u0026quot;, while also becoming setuid-root:\r\n\r\n-rwxr-xr-x 1 root cdrom 16048 Aug  7 13:16 target\r\n\r\nbecomes:\r\n\r\n-rwsr-xr-- 1 root cdrom 16048 Aug  7 13:16 target\r\n\r\nBut racing the chmod means users without group \u0026quot;cdrom\u0026quot; membership can\nget the permission to execute \u0026quot;target\u0026quot; just before the chmod, and when\nthe chmod finishes, the exec reaches brpm_fill_uid(), and performs the\nsetuid to root, violating the expressed authorization of \u0026quot;only cdrom\ngroup members can setuid to root\u0026quot;.\r\n\r\nRe-check that we still have execute permissions in case the metadata\nhas changed. It would be better to keep a copy from the perm-check time,\nbut until we can do that refactoring, the least-bad option is to do a\nfull inode_permission() call (under inode lock). It is understood that\nthis is safe against dead-locks, but hardly optimal.(CVE-2024-43882)",
  "id": "OESA-2024-2080",
  "modified": "2026-08-06T11:07:33Z",
  "published": "2024-08-30T11:07:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2080"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47292"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47504"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47556"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48634"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48639"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48642"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48643"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48644"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48647"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48648"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48656"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48663"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48671"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48672"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48675"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48686"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48687"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48691"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48873"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48896"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48898"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48899"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48920"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48935"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52893"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52898"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52901"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52903"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-22386"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36946"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38613"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39490"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41002"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41068"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42120"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42122"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42265"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42271"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42280"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42281"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42284"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42285"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42297"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42305"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42308"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43819"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43828"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43831"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43853"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43860"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43861"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43866"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43879"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-43882"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2021-47292",
    "CVE-2021-47504",
    "CVE-2021-47556",
    "CVE-2022-48634",
    "CVE-2022-48639",
    "CVE-2022-48642",
    "CVE-2022-48643",
    "CVE-2022-48644",
    "CVE-2022-48647",
    "CVE-2022-48648",
    "CVE-2022-48656",
    "CVE-2022-48663",
    "CVE-2022-48671",
    "CVE-2022-48672",
    "CVE-2022-48675",
    "CVE-2022-48686",
    "CVE-2022-48687",
    "CVE-2022-48691",
    "CVE-2022-48873",
    "CVE-2022-48896",
    "CVE-2022-48898",
    "CVE-2022-48899",
    "CVE-2022-48920",
    "CVE-2022-48935",
    "CVE-2023-52893",
    "CVE-2023-52898",
    "CVE-2023-52901",
    "CVE-2023-52903",
    "CVE-2024-22386",
    "CVE-2024-36946",
    "CVE-2024-38613",
    "CVE-2024-39490",
    "CVE-2024-41002",
    "CVE-2024-41068",
    "CVE-2024-42120",
    "CVE-2024-42122",
    "CVE-2024-42265",
    "CVE-2024-42271",
    "CVE-2024-42280",
    "CVE-2024-42281",
    "CVE-2024-42284",
    "CVE-2024-42285",
    "CVE-2024-42297",
    "CVE-2024-42305",
    "CVE-2024-42308",
    "CVE-2024-43819",
    "CVE-2024-43828",
    "CVE-2024-43831",
    "CVE-2024-43853",
    "CVE-2024-43860",
    "CVE-2024-43861",
    "CVE-2024-43866",
    "CVE-2024-43879",
    "CVE-2024-43882"
  ]
}

SUSE-SU-2024:3189-1

Vulnerability from csaf_suse - Published: 2024-09-10 08:45 - Updated: 2026-09-20 16:57

Summary

Security update for the Linux Kernel

Severity

Important

Scope

104 vulnerabilities in this advisory, including CVE-2023-52893.

CVE-2023-52893

5.5 (Medium)


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

Recommended: 12 products

Open the full advisory

SUSE-SU-2024:3190-1

Vulnerability from csaf_suse - Published: 2024-09-10 08:46 - Updated: 2026-09-20 16:58

Summary

Security update for the Linux Kernel

Severity

Important

Scope

292 vulnerabilities in this advisory, including CVE-2023-52893.

CVE-2023-52893

5.5 (Medium)


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

Recommended: 59 products

Open the full advisory

SUSE-SU-2024:3209-1

Vulnerability from csaf_suse - Published: 2024-09-11 15:39 - Updated: 2026-09-20 16:58

Summary

Security update for the Linux Kernel

Severity

Important

Scope

292 vulnerabilities in this advisory, including CVE-2023-52893.

CVE-2023-52893

5.5 (Medium)


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

Recommended: 50 products

Open the full advisory

SUSE-SU-2024:3227-1

Vulnerability from csaf_suse - Published: 2024-09-12 13:26 - Updated: 2026-09-20 16:59

Summary

Security update for the Linux Kernel

Severity

Important

Scope

69 vulnerabilities in this advisory, including CVE-2023-52893.

CVE-2023-52893

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-2024:3251-1

Vulnerability from csaf_suse - Published: 2024-09-16 08:57 - Updated: 2026-09-20 16:59

Summary

Security update for the Linux Kernel

Severity

Important

Scope

105 vulnerabilities in this advisory, including CVE-2023-52893.

CVE-2023-52893

5.5 (Medium)


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

Recommended: 57 products

Open the full advisory

SUSE-SU-2024:3252-1

Vulnerability from csaf_suse - Published: 2024-09-16 08:58 - Updated: 2026-09-20 16:59

Summary

Security update for the Linux Kernel

Severity

Important

Scope

105 vulnerabilities in this advisory, including CVE-2023-52893.

CVE-2023-52893

5.5 (Medium)


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

Recommended: 18 products

Open the full advisory

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

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

Related by attack behaviour

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

Action not permitted

CVE-2023-52893 (GCVE-0-2023-52893)

OESA-2024-2079 (CVE-2022-48795)

Thread #1:

Thread #2:

Syzbot reports a issue as follows:

OESA-2024-2080 (CVE-2021-47292)

Syzbot reports a issue as follows:

Tags

Sightings

Nomenclature

Related by attack behaviour