Vulnerability-Lookup

CVE-2022-48788 (GCVE-0-2022-48788)

Vulnerability from cvelistv5 – Published: 2024-07-16 11:43 – Updated: 2026-08-05 08:52

Title

nvme-rdma: fix possible use-after-free in transport error_recovery work

Summary

In the Linux kernel, the following vulnerability has been resolved: nvme-rdma: fix possible use-after-free in transport error_recovery work While nvme_rdma_submit_async_event_work is checking the ctrl and queue state before preparing the AER command and scheduling io_work, in order to fully prevent a race where this check is not reliable the error recovery work must flush async_event_work before continuing to destroy the admin queue after setting the ctrl state to RESETTING such that there is no race .submit_async_event and the error recovery handler itself changing the ctrl state.

Severity

9.8 (Critical)


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

SSVC

Exploitation: none Automatable: no Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2024-09-10 16:59 UTC

Assigner

Linux mitre root

References

6 references

URL	Tags
https://git.kernel.org/stable/c/5593f72d1922403c1…
https://git.kernel.org/stable/c/d411b2a5da68b8a13…
https://git.kernel.org/stable/c/324f5bdc52ecb6a6d…
https://git.kernel.org/stable/c/646952b2210f19e58…
https://git.kernel.org/stable/c/ea86027ac467a0558…
https://git.kernel.org/stable/c/b6bb1722f34bbdbab…

Impacted products

2 products

Vendor	Product	Version	CPE status
Linux	Linux	Affected: 7110230719602852481c2793d054f866b2bf4a2b , < 5593f72d1922403c11749532e3a0aa4cf61414e9 (git) Affected: 7110230719602852481c2793d054f866b2bf4a2b , < d411b2a5da68b8a130c23097014434ac140a2ace (git) Affected: 7110230719602852481c2793d054f866b2bf4a2b , < 324f5bdc52ecb6a6dadb31a62823ef8c709d1439 (git) Affected: 7110230719602852481c2793d054f866b2bf4a2b , < 646952b2210f19e584d2bf9eb5d092abdca2fcc1 (git) Affected: 7110230719602852481c2793d054f866b2bf4a2b , < ea86027ac467a055849c4945906f799e7f65ab99 (git) Affected: 7110230719602852481c2793d054f866b2bf4a2b , < b6bb1722f34bbdbabed27acdceaf585d300c5fd2 (git)	guessed
Linux	Linux	Affected: 4.8 Unaffected: 0 , < 4.8 (semver) Unaffected: 4.19.231 , ≤ 4.19.* (semver) Unaffected: 5.4.181 , ≤ 5.4.* (semver) Unaffected: 5.10.102 , ≤ 5.10.* (semver) Unaffected: 5.15.25 , ≤ 5.15.* (semver) Unaffected: 5.16.11 , ≤ 5.16.* (semver) Unaffected: 5.17 , ≤ * (original_commit_for_fix)	guessed

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "providerMetadata": {
          "dateUpdated": "2024-08-03T15:25:00.328Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/5593f72d1922403c11749532e3a0aa4cf61414e9"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/d411b2a5da68b8a130c23097014434ac140a2ace"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/324f5bdc52ecb6a6dadb31a62823ef8c709d1439"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/646952b2210f19e584d2bf9eb5d092abdca2fcc1"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/ea86027ac467a055849c4945906f799e7f65ab99"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/b6bb1722f34bbdbabed27acdceaf585d300c5fd2"
          }
        ],
        "title": "CVE Program Container"
      },
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2022-48788",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-09-10T16:59:45.973242Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2024-09-11T17:34:16.058Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/nvme/host/rdma.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "5593f72d1922403c11749532e3a0aa4cf61414e9",
              "status": "affected",
              "version": "7110230719602852481c2793d054f866b2bf4a2b",
              "versionType": "git"
            },
            {
              "lessThan": "d411b2a5da68b8a130c23097014434ac140a2ace",
              "status": "affected",
              "version": "7110230719602852481c2793d054f866b2bf4a2b",
              "versionType": "git"
            },
            {
              "lessThan": "324f5bdc52ecb6a6dadb31a62823ef8c709d1439",
              "status": "affected",
              "version": "7110230719602852481c2793d054f866b2bf4a2b",
              "versionType": "git"
            },
            {
              "lessThan": "646952b2210f19e584d2bf9eb5d092abdca2fcc1",
              "status": "affected",
              "version": "7110230719602852481c2793d054f866b2bf4a2b",
              "versionType": "git"
            },
            {
              "lessThan": "ea86027ac467a055849c4945906f799e7f65ab99",
              "status": "affected",
              "version": "7110230719602852481c2793d054f866b2bf4a2b",
              "versionType": "git"
            },
            {
              "lessThan": "b6bb1722f34bbdbabed27acdceaf585d300c5fd2",
              "status": "affected",
              "version": "7110230719602852481c2793d054f866b2bf4a2b",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/nvme/host/rdma.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "4.8"
            },
            {
              "lessThan": "4.8",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "4.19.*",
              "status": "unaffected",
              "version": "4.19.231",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.4.*",
              "status": "unaffected",
              "version": "5.4.181",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.10.*",
              "status": "unaffected",
              "version": "5.10.102",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.15.*",
              "status": "unaffected",
              "version": "5.15.25",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.16.*",
              "status": "unaffected",
              "version": "5.16.11",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "5.17",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "4.19.231",
                  "versionStartIncluding": "4.8",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.4.181",
                  "versionStartIncluding": "4.8",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.10.102",
                  "versionStartIncluding": "4.8",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.15.25",
                  "versionStartIncluding": "4.8",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.16.11",
                  "versionStartIncluding": "4.8",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.17",
                  "versionStartIncluding": "4.8",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnvme-rdma: fix possible use-after-free in transport error_recovery work\n\nWhile nvme_rdma_submit_async_event_work is checking the ctrl and queue\nstate before preparing the AER command and scheduling io_work, in order\nto fully prevent a race where this check is not reliable the error\nrecovery work must flush async_event_work before continuing to destroy\nthe admin queue after setting the ctrl state to RESETTING such that\nthere is no race .submit_async_event and the error recovery handler\nitself changing the ctrl state."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "baseScore": 9.8,
            "baseSeverity": "CRITICAL",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          },
          "scenarios": [
            {
              "lang": "en",
              "value": "AV:N - The nvme-rdma host processes RDMA completions and AENs from a remote NVMe-oF peer (InfiniBand/RoCE/iWarp); a malicious or compromised target triggers error recovery and async-event work via network protocol messages on an established connection.\nAC:L - The remote peer controls both sides of the race by sending an AEN (scheduling async_event_work) and inducing a transport error or disconnect (scheduling error_recovery_work), so success does not depend on conditions outside the attacker\u2019s influence.\nPR:N - Exploitation requires no privileges on the victim host; once an NVMe-RDMA session exists, an unauthenticated remote peer can trigger the race solely through fabric protocol behavior.\nUI:N - No additional user action is required at exploit time beyond a pre-existing NVMe-RDMA controller connection typical of datacenter storage attachments.\nS:U - The use-after-free corrupts kernel memory in the local host\u2019s NVMe-RDMA driver and does not cross a distinct security authority such as a VM or IOMMU boundary.\nC:H - Use-after-free of the admin queue async-event SQE and related queue structures enables heap reuse and arbitrary kernel read primitives.\nI:H - The same UAF is exploitable for heap spraying and arbitrary write/control-flow hijacking in kernel context.\nA:H - The UAF can cause kernel oops/panic or hangs during admin-queue teardown even without a full exploit."
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-05T08:52:18.532Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/5593f72d1922403c11749532e3a0aa4cf61414e9"
        },
        {
          "url": "https://git.kernel.org/stable/c/d411b2a5da68b8a130c23097014434ac140a2ace"
        },
        {
          "url": "https://git.kernel.org/stable/c/324f5bdc52ecb6a6dadb31a62823ef8c709d1439"
        },
        {
          "url": "https://git.kernel.org/stable/c/646952b2210f19e584d2bf9eb5d092abdca2fcc1"
        },
        {
          "url": "https://git.kernel.org/stable/c/ea86027ac467a055849c4945906f799e7f65ab99"
        },
        {
          "url": "https://git.kernel.org/stable/c/b6bb1722f34bbdbabed27acdceaf585d300c5fd2"
        }
      ],
      "title": "nvme-rdma: fix possible use-after-free in transport error_recovery work",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2022-48788",
    "datePublished": "2024-07-16T11:43:45.213Z",
    "dateReserved": "2024-07-16T11:38:08.892Z",
    "dateUpdated": "2026-08-05T08:52:18.532Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2022-48788",
      "date": "2026-09-25",
      "epss": "0.00934",
      "percentile": "0.59111"
    },
    "microsoft_vex": {
      "current_release_date": "2026-02-19T01:12:24.000Z",
      "cve": "CVE-2022-48788",
      "id": "msrc_CVE-2022-48788",
      "initial_release_date": "2024-07-01T07:00:00.000Z",
      "product_status:fixed": "3",
      "product_status:known_affected": "3",
      "source": "Microsoft CSAF VEX",
      "status": "final",
      "title": "nvme-rdma: fix possible use-after-free in transport error_recovery work",
      "url": "https://msrc.microsoft.com/csaf/vex/2024/msrc_cve-2022-48788.json",
      "version": "4"
    },
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "defaultStatus": "unaffected",
                "product": "Linux",
                "programFiles": [
                  "drivers/nvme/host/rdma.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "lessThan": "5593f72d1922403c11749532e3a0aa4cf61414e9",
                    "status": "affected",
                    "version": "7110230719602852481c2793d054f866b2bf4a2b",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "d411b2a5da68b8a130c23097014434ac140a2ace",
                    "status": "affected",
                    "version": "7110230719602852481c2793d054f866b2bf4a2b",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "324f5bdc52ecb6a6dadb31a62823ef8c709d1439",
                    "status": "affected",
                    "version": "7110230719602852481c2793d054f866b2bf4a2b",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "646952b2210f19e584d2bf9eb5d092abdca2fcc1",
                    "status": "affected",
                    "version": "7110230719602852481c2793d054f866b2bf4a2b",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "ea86027ac467a055849c4945906f799e7f65ab99",
                    "status": "affected",
                    "version": "7110230719602852481c2793d054f866b2bf4a2b",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "b6bb1722f34bbdbabed27acdceaf585d300c5fd2",
                    "status": "affected",
                    "version": "7110230719602852481c2793d054f866b2bf4a2b",
                    "versionType": "git"
                  }
                ]
              },
              {
                "defaultStatus": "affected",
                "product": "Linux",
                "programFiles": [
                  "drivers/nvme/host/rdma.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "status": "affected",
                    "version": "4.8"
                  },
                  {
                    "lessThan": "4.8",
                    "status": "unaffected",
                    "version": "0",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "4.19.*",
                    "status": "unaffected",
                    "version": "4.19.231",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "5.4.*",
                    "status": "unaffected",
                    "version": "5.4.181",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "5.10.*",
                    "status": "unaffected",
                    "version": "5.10.102",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "5.15.*",
                    "status": "unaffected",
                    "version": "5.15.25",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "5.16.*",
                    "status": "unaffected",
                    "version": "5.16.11",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "*",
                    "status": "unaffected",
                    "version": "5.17",
                    "versionType": "original_commit_for_fix"
                  }
                ]
              }
            ],
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
          }
        ],
        "configurations": [
          {
            "nodes": [
              {
                "cpeMatch": [
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "BED6719E-2004-42C8-8CA4-4E4CD159B63F",
                    "versionEndExcluding": "4.19.231",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "FB33213E-1A45-4E3B-A129-58AAA2EB921D",
                    "versionEndExcluding": "5.4.181",
                    "versionStartIncluding": "4.20",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "DAD66A9A-8D06-48D1-8AA8-FC060496FF53",
                    "versionEndExcluding": "5.10.102",
                    "versionStartIncluding": "5.5",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "D098AA16-8E21-4EB7-AE2F-1EEB58E1A3A3",
                    "versionEndExcluding": "5.15.25",
                    "versionStartIncluding": "5.11",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "0D327234-5D4A-43DC-A6DF-BCA0CEBEC039",
                    "versionEndExcluding": "5.16.11",
                    "versionStartIncluding": "5.16",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:5.17:rc1:*:*:*:*:*:*",
                    "matchCriteriaId": "7BD5F8D9-54FA-4CB0-B4F0-CB0471FDDB2D",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:5.17:rc2:*:*:*:*:*:*",
                    "matchCriteriaId": "E6E34B23-78B4-4516-9BD8-61B33F4AC49A",
                    "vulnerable": true
                  }
                ],
                "negate": false,
                "operator": "OR"
              }
            ]
          }
        ],
        "cveTags": [],
        "descriptions": [
          {
            "lang": "en",
            "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnvme-rdma: fix possible use-after-free in transport error_recovery work\n\nWhile nvme_rdma_submit_async_event_work is checking the ctrl and queue\nstate before preparing the AER command and scheduling io_work, in order\nto fully prevent a race where this check is not reliable the error\nrecovery work must flush async_event_work before continuing to destroy\nthe admin queue after setting the ctrl state to RESETTING such that\nthere is no race .submit_async_event and the error recovery handler\nitself changing the ctrl state."
          },
          {
            "lang": "es",
            "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvme-rdma: soluciona el posible use-after-free en el transporte error_recovery work Mientras nvme_rdma_submit_async_event_work verifica el control y el estado de la cola antes de preparar el comando AER y programar io_work, para evitar completamente una ejecuci\u00f3n donde esta verificaci\u00f3n no es confiable, el trabajo de recuperaci\u00f3n de errores debe eliminar async_event_work antes de continuar destruyendo la cola de administraci\u00f3n despu\u00e9s de configurar el estado de control en RESETTING de manera que no haya ejecuci\u00f3n .submit_async_event y el propio controlador de recuperaci\u00f3n de errores cambie el estado de control."
          }
        ],
        "id": "CVE-2022-48788",
        "lastModified": "2026-08-04T10:17:21.133",
        "metrics": {
          "cvssMetricV31": [
            {
              "cvssData": {
                "attackComplexity": "LOW",
                "attackVector": "NETWORK",
                "availabilityImpact": "HIGH",
                "baseScore": 9.8,
                "baseSeverity": "CRITICAL",
                "confidentialityImpact": "HIGH",
                "integrityImpact": "HIGH",
                "privilegesRequired": "NONE",
                "scope": "UNCHANGED",
                "userInteraction": "NONE",
                "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
                "version": "3.1"
              },
              "exploitabilityScore": 3.9,
              "impactScore": 5.9,
              "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
              "type": "Secondary"
            },
            {
              "cvssData": {
                "attackComplexity": "LOW",
                "attackVector": "LOCAL",
                "availabilityImpact": "HIGH",
                "baseScore": 7.8,
                "baseSeverity": "HIGH",
                "confidentialityImpact": "HIGH",
                "integrityImpact": "HIGH",
                "privilegesRequired": "LOW",
                "scope": "UNCHANGED",
                "userInteraction": "NONE",
                "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
                "version": "3.1"
              },
              "exploitabilityScore": 1.8,
              "impactScore": 5.9,
              "source": "nvd@nist.gov",
              "type": "Primary"
            }
          ],
          "ssvcV203": [
            {
              "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "ssvcData": {
                "id": "CVE-2022-48788",
                "options": [
                  {
                    "exploitation": "none"
                  },
                  {
                    "automatable": "no"
                  },
                  {
                    "technicalImpact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-09-10T16:59:45.973242Z",
                "version": "2.0.3"
              }
            }
          ]
        },
        "published": "2024-07-16T12:15:03.703",
        "references": [
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/324f5bdc52ecb6a6dadb31a62823ef8c709d1439"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/5593f72d1922403c11749532e3a0aa4cf61414e9"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/646952b2210f19e584d2bf9eb5d092abdca2fcc1"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/b6bb1722f34bbdbabed27acdceaf585d300c5fd2"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/d411b2a5da68b8a130c23097014434ac140a2ace"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/ea86027ac467a055849c4945906f799e7f65ab99"
          },
          {
            "source": "af854a3a-2127-422b-91ae-364da2661108",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/324f5bdc52ecb6a6dadb31a62823ef8c709d1439"
          },
          {
            "source": "af854a3a-2127-422b-91ae-364da2661108",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/5593f72d1922403c11749532e3a0aa4cf61414e9"
          },
          {
            "source": "af854a3a-2127-422b-91ae-364da2661108",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/646952b2210f19e584d2bf9eb5d092abdca2fcc1"
          },
          {
            "source": "af854a3a-2127-422b-91ae-364da2661108",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/b6bb1722f34bbdbabed27acdceaf585d300c5fd2"
          },
          {
            "source": "af854a3a-2127-422b-91ae-364da2661108",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/d411b2a5da68b8a130c23097014434ac140a2ace"
          },
          {
            "source": "af854a3a-2127-422b-91ae-364da2661108",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/ea86027ac467a055849c4945906f799e7f65ab99"
          }
        ],
        "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "vulnStatus": "Modified",
        "weaknesses": [
          {
            "description": [
              {
                "lang": "en",
                "value": "CWE-416"
              }
            ],
            "source": "nvd@nist.gov",
            "type": "Primary"
          }
        ]
      }
    },
    "redhat_vex": {
      "aggregate_severity": "Moderate",
      "current_release_date": "2026-08-04T19:47:07+00:00",
      "cve": "CVE-2022-48788",
      "id": "CVE-2022-48788",
      "initial_release_date": "2022-01-01T00:00:00+00:00",
      "product_status:known_affected": "76",
      "product_status:known_not_affected": "122",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "kernel: nvme-rdma: fix possible use-after-free in transport error_recovery work",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2022/cve-2022-48788.json",
      "version": "3"
    },
    "vulnrichment": {
      "containers": {
        "adp": [
          {
            "providerMetadata": {
              "dateUpdated": "2024-08-03T15:25:00.328Z",
              "orgId": "af854a3a-2127-422b-91ae-364da2661108",
              "shortName": "CVE"
            },
            "references": [
              {
                "tags": [
                  "x_transferred"
                ],
                "url": "https://git.kernel.org/stable/c/5593f72d1922403c11749532e3a0aa4cf61414e9"
              },
              {
                "tags": [
                  "x_transferred"
                ],
                "url": "https://git.kernel.org/stable/c/d411b2a5da68b8a130c23097014434ac140a2ace"
              },
              {
                "tags": [
                  "x_transferred"
                ],
                "url": "https://git.kernel.org/stable/c/324f5bdc52ecb6a6dadb31a62823ef8c709d1439"
              },
              {
                "tags": [
                  "x_transferred"
                ],
                "url": "https://git.kernel.org/stable/c/646952b2210f19e584d2bf9eb5d092abdca2fcc1"
              },
              {
                "tags": [
                  "x_transferred"
                ],
                "url": "https://git.kernel.org/stable/c/ea86027ac467a055849c4945906f799e7f65ab99"
              },
              {
                "tags": [
                  "x_transferred"
                ],
                "url": "https://git.kernel.org/stable/c/b6bb1722f34bbdbabed27acdceaf585d300c5fd2"
              }
            ],
            "title": "CVE Program Container"
          },
          {
            "metrics": [
              {
                "other": {
                  "content": {
                    "id": "CVE-2022-48788",
                    "options": [
                      {
                        "Exploitation": "none"
                      },
                      {
                        "Automatable": "no"
                      },
                      {
                        "Technical Impact": "partial"
                      }
                    ],
                    "role": "CISA Coordinator",
                    "timestamp": "2024-09-10T16:59:45.973242Z",
                    "version": "2.0.3"
                  },
                  "type": "ssvc"
                }
              }
            ],
            "providerMetadata": {
              "dateUpdated": "2024-09-11T12:42:21.680Z",
              "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "shortName": "CISA-ADP"
            },
            "title": "CISA ADP Vulnrichment"
          }
        ],
        "cna": {
          "affected": [
            {
              "defaultStatus": "unaffected",
              "product": "Linux",
              "programFiles": [
                "drivers/nvme/host/rdma.c"
              ],
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "vendor": "Linux",
              "versions": [
                {
                  "lessThan": "5593f72d1922403c11749532e3a0aa4cf61414e9",
                  "status": "affected",
                  "version": "7110230719602852481c2793d054f866b2bf4a2b",
                  "versionType": "git"
                },
                {
                  "lessThan": "d411b2a5da68b8a130c23097014434ac140a2ace",
                  "status": "affected",
                  "version": "7110230719602852481c2793d054f866b2bf4a2b",
                  "versionType": "git"
                },
                {
                  "lessThan": "324f5bdc52ecb6a6dadb31a62823ef8c709d1439",
                  "status": "affected",
                  "version": "7110230719602852481c2793d054f866b2bf4a2b",
                  "versionType": "git"
                },
                {
                  "lessThan": "646952b2210f19e584d2bf9eb5d092abdca2fcc1",
                  "status": "affected",
                  "version": "7110230719602852481c2793d054f866b2bf4a2b",
                  "versionType": "git"
                },
                {
                  "lessThan": "ea86027ac467a055849c4945906f799e7f65ab99",
                  "status": "affected",
                  "version": "7110230719602852481c2793d054f866b2bf4a2b",
                  "versionType": "git"
                },
                {
                  "lessThan": "b6bb1722f34bbdbabed27acdceaf585d300c5fd2",
                  "status": "affected",
                  "version": "7110230719602852481c2793d054f866b2bf4a2b",
                  "versionType": "git"
                }
              ]
            },
            {
              "defaultStatus": "affected",
              "product": "Linux",
              "programFiles": [
                "drivers/nvme/host/rdma.c"
              ],
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "vendor": "Linux",
              "versions": [
                {
                  "status": "affected",
                  "version": "4.8"
                },
                {
                  "lessThan": "4.8",
                  "status": "unaffected",
                  "version": "0",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "4.19.*",
                  "status": "unaffected",
                  "version": "4.19.231",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "5.4.*",
                  "status": "unaffected",
                  "version": "5.4.181",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "5.10.*",
                  "status": "unaffected",
                  "version": "5.10.102",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "5.15.*",
                  "status": "unaffected",
                  "version": "5.15.25",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "5.16.*",
                  "status": "unaffected",
                  "version": "5.16.11",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "*",
                  "status": "unaffected",
                  "version": "5.17",
                  "versionType": "original_commit_for_fix"
                }
              ]
            }
          ],
          "cpeApplicability": [
            {
              "nodes": [
                {
                  "cpeMatch": [
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "4.19.231",
                      "versionStartIncluding": "4.8",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "5.4.181",
                      "versionStartIncluding": "4.8",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "5.10.102",
                      "versionStartIncluding": "4.8",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "5.15.25",
                      "versionStartIncluding": "4.8",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "5.16.11",
                      "versionStartIncluding": "4.8",
                      "vulnerable": true
                    },
                    {
                      "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                      "versionEndExcluding": "5.17",
                      "versionStartIncluding": "4.8",
                      "vulnerable": true
                    }
                  ],
                  "negate": false,
                  "operator": "OR"
                }
              ]
            }
          ],
          "descriptions": [
            {
              "lang": "en",
              "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nnvme-rdma: fix possible use-after-free in transport error_recovery work\n\nWhile nvme_rdma_submit_async_event_work is checking the ctrl and queue\nstate before preparing the AER command and scheduling io_work, in order\nto fully prevent a race where this check is not reliable the error\nrecovery work must flush async_event_work before continuing to destroy\nthe admin queue after setting the ctrl state to RESETTING such that\nthere is no race .submit_async_event and the error recovery handler\nitself changing the ctrl state."
            }
          ],
          "metrics": [
            {
              "cvssV3_1": {
                "baseScore": 9.8,
                "baseSeverity": "CRITICAL",
                "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
                "version": "3.1"
              },
              "scenarios": [
                {
                  "lang": "en",
                  "value": "AV:N - The nvme-rdma host processes RDMA completions and AENs from a remote NVMe-oF peer (InfiniBand/RoCE/iWarp); a malicious or compromised target triggers error recovery and async-event work via network protocol messages on an established connection.\nAC:L - The remote peer controls both sides of the race by sending an AEN (scheduling async_event_work) and inducing a transport error or disconnect (scheduling error_recovery_work), so success does not depend on conditions outside the attacker\u2019s influence.\nPR:N - Exploitation requires no privileges on the victim host; once an NVMe-RDMA session exists, an unauthenticated remote peer can trigger the race solely through fabric protocol behavior.\nUI:N - No additional user action is required at exploit time beyond a pre-existing NVMe-RDMA controller connection typical of datacenter storage attachments.\nS:U - The use-after-free corrupts kernel memory in the local host\u2019s NVMe-RDMA driver and does not cross a distinct security authority such as a VM or IOMMU boundary.\nC:H - Use-after-free of the admin queue async-event SQE and related queue structures enables heap reuse and arbitrary kernel read primitives.\nI:H - The same UAF is exploitable for heap spraying and arbitrary write/control-flow hijacking in kernel context.\nA:H - The UAF can cause kernel oops/panic or hangs during admin-queue teardown even without a full exploit."
                }
              ]
            }
          ],
          "providerMetadata": {
            "dateUpdated": "2026-08-05T08:52:18.532Z",
            "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "shortName": "Linux"
          },
          "references": [
            {
              "url": "https://git.kernel.org/stable/c/5593f72d1922403c11749532e3a0aa4cf61414e9"
            },
            {
              "url": "https://git.kernel.org/stable/c/d411b2a5da68b8a130c23097014434ac140a2ace"
            },
            {
              "url": "https://git.kernel.org/stable/c/324f5bdc52ecb6a6dadb31a62823ef8c709d1439"
            },
            {
              "url": "https://git.kernel.org/stable/c/646952b2210f19e584d2bf9eb5d092abdca2fcc1"
            },
            {
              "url": "https://git.kernel.org/stable/c/ea86027ac467a055849c4945906f799e7f65ab99"
            },
            {
              "url": "https://git.kernel.org/stable/c/b6bb1722f34bbdbabed27acdceaf585d300c5fd2"
            }
          ],
          "title": "nvme-rdma: fix possible use-after-free in transport error_recovery work",
          "x_generator": {
            "engine": "bippy-1.2.0"
          }
        }
      },
      "cveMetadata": {
        "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "assignerShortName": "Linux",
        "cveId": "CVE-2022-48788",
        "datePublished": "2024-07-16T11:43:45.213Z",
        "dateReserved": "2024-07-16T11:38:08.892Z",
        "dateUpdated": "2026-08-05T08:52:18.532Z",
        "state": "PUBLISHED"
      },
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}

MSRC_CVE-2022-48788

Vulnerability from csaf_microsoft - Published: 2024-07-01 07:00 - Updated: 2026-02-19 01:12

Summary

nvme-rdma: fix possible use-after-free in transport error_recovery work

Scope

1 vulnerability in this advisory, including CVE-2022-48788.

CVE-2022-48788

7.8 (High)


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

Fixed: 3 products Known affected: 3 products

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

Open the full advisory

NCSC-2024-0339

Vulnerability from csaf_ncscnl - Published: 2024-08-13 18:23 - Updated: 2024-08-13 18:23

Summary

Kwetsbaarheden verholpen in Microsoft Mariner

Scope

86 vulnerabilities in this advisory, including CVE-2022-48788.

CVE-2022-48788

Open the full advisory

OESA-2024-1895 (CVE-2021-47612)

Vulnerability from osv_openeuler – Published: 2024-07-26 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:

nfc: fix segfault in nfc_genl_dump_devices_done

When kmalloc in nfc_genl_dump_devices() fails then nfc_genl_dump_devices_done() segfaults as below

KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 0 PID: 25 Comm: kworker/0:1 Not tainted 5.16.0-rc4-01180-g2a987e65025e-dirty #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-6.fc35 04/01/2014 Workqueue: events netlink_sock_destruct_work RIP: 0010:klist_iter_exit+0x26/0x80 Call Trace: <TASK> class_dev_iter_exit+0x15/0x20 nfc_genl_dump_devices_done+0x3b/0x50 genl_lock_done+0x84/0xd0 netlink_sock_destruct+0x8f/0x270 __sk_destruct+0x64/0x3b0 sk_destruct+0xa8/0xd0 __sk_free+0x2e8/0x3d0 sk_free+0x51/0x90 netlink_sock_destruct_work+0x1c/0x20 process_one_work+0x411/0x710 worker_thread+0x6fd/0xa80(CVE-2021-47612)

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

Drivers: hv: vmbus: Fix memory leak in vmbus_add_channel_kobj

kobject_init_and_add() takes reference even when it fails. According to the doc of kobject_init_and_add()?

If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object.

Fix memory leak by calling kobject_put().(CVE-2022-48775)

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

nvme-rdma: fix possible use-after-free in transport error_recovery work

While nvme_rdma_submit_async_event_work is checking the ctrl and queue state before preparing the AER command and scheduling io_work, in order to fully prevent a race where this check is not reliable the error recovery work must flush async_event_work before continuing to destroy the admin queue after setting the ctrl state to RESETTING such that there is no race .submit_async_event and the error recovery handler itself changing the ctrl state.(CVE-2022-48788)

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

usb: gadget: Fix use-after-free bug by not setting udc->dev.driver

The syzbot fuzzer found a use-after-free bug:

BUG: KASAN: use-after-free in dev_uevent+0x712/0x780 drivers/base/core.c:2320 Read of size 8 at addr ffff88802b934098 by task udevd/3689

CPU: 2 PID: 3689 Comm: udevd Not tainted 5.17.0-rc4-syzkaller-00229-g4f12b742eb2b #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0x8d/0x303 mm/kasan/report.c:255 __kasan_report mm/kasan/report.c:442 [inline] kasan_report.cold+0x83/0xdf mm/kasan/report.c:459 dev_uevent+0x712/0x780 drivers/base/core.c:2320 uevent_show+0x1b8/0x380 drivers/base/core.c:2391 dev_attr_show+0x4b/0x90 drivers/base/core.c:2094

Although the bug manifested in the driver core, the real cause was a race with the gadget core. dev_uevent() does:

if (dev-&gt;driver)
    add_uevent_var(env, &quot;DRIVER=%s&quot;, dev-&gt;driver-&gt;name);

and between the test and the dereference of dev->driver, the gadget core sets dev->driver to NULL.

The race wouldn't occur if the gadget core registered its devices on a real bus, using the standard synchronization techniques of the driver core. However, it's not necessary to make such a large change in order to fix this bug; all we need to do is make sure that udc->dev.driver is always NULL.

In fact, there is no reason for udc->dev.driver ever to be set to anything, let alone to the value it currently gets: the address of the gadget's driver. After all, a gadget driver only knows how to manage a gadget, not how to manage a UDC.

This patch simply removes the statements in the gadget core that touch udc->dev.driver.(CVE-2022-48838)

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

sctp: fix kernel-infoleak for SCTP sockets

syzbot reported a kernel infoleak [1] of 4 bytes.

After analysis, it turned out r->idiag_expires is not initialized if inet_sctp_diag_fill() calls inet_diag_msg_common_fill()

Make sure to clear idiag_timer/idiag_retrans/idiag_expires and let inet_diag_msg_sctpasoc_fill() fill them again if needed.

[1]

BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:121 [inline] BUG: KMSAN: kernel-infoleak in copyout lib/iov_iter.c:154 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x6ef/0x25a0 lib/iov_iter.c:668 instrument_copy_to_user include/linux/instrumented.h:121 [inline] copyout lib/iov_iter.c:154 [inline] _copy_to_iter+0x6ef/0x25a0 lib/iov_iter.c:668 copy_to_iter include/linux/uio.h:162 [inline] simple_copy_to_iter+0xf3/0x140 net/core/datagram.c:519 __skb_datagram_iter+0x2d5/0x11b0 net/core/datagram.c:425 skb_copy_datagram_iter+0xdc/0x270 net/core/datagram.c:533 skb_copy_datagram_msg include/linux/skbuff.h:3696 [inline] netlink_recvmsg+0x669/0x1c80 net/netlink/af_netlink.c:1977 sock_recvmsg_nosec net/socket.c:948 [inline] sock_recvmsg net/socket.c:966 [inline] __sys_recvfrom+0x795/0xa10 net/socket.c:2097 __do_sys_recvfrom net/socket.c:2115 [inline] __se_sys_recvfrom net/socket.c:2111 [inline] __x64_sys_recvfrom+0x19d/0x210 net/socket.c:2111 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xae

Uninit was created at: slab_post_alloc_hook mm/slab.h:737 [inline] slab_alloc_node mm/slub.c:3247 [inline] __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4975 kmalloc_reserve net/core/skbuff.c:354 [inline] __alloc_skb+0x545/0xf90 net/core/skbuff.c:426 alloc_skb include/linux/skbuff.h:1158 [inline] netlink_dump+0x3e5/0x16c0 net/netlink/af_netlink.c:2248 __netlink_dump_start+0xcf8/0xe90 net/netlink/af_netlink.c:2373 netlink_dump_start include/linux/netlink.h:254 [inline] inet_diag_handler_cmd+0x2e7/0x400 net/ipv4/inet_diag.c:1341 sock_diag_rcv_msg+0x24a/0x620 netlink_rcv_skb+0x40c/0x7e0 net/netlink/af_netlink.c:2494 sock_diag_rcv+0x63/0x80 net/core/sock_diag.c:277 netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline] netlink_unicast+0x1093/0x1360 net/netlink/af_netlink.c:1343 netlink_sendmsg+0x14d9/0x1720 net/netlink/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:705 [inline] sock_sendmsg net/socket.c:725 [inline] sock_write_iter+0x594/0x690 net/socket.c:1061 do_iter_readv_writev+0xa7f/0xc70 do_iter_write+0x52c/0x1500 fs/read_write.c:851 vfs_writev fs/read_write.c:924 [inline] do_writev+0x645/0xe00 fs/read_write.c:967 __do_sys_writev fs/read_write.c:1040 [inline] __se_sys_writev fs/read_write.c:1037 [inline] __x64_sys_writev+0xe5/0x120 fs/read_write.c:1037 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xae

Bytes 68-71 of 2508 are uninitialized Memory access of size 2508 starts at ffff888114f9b000 Data copied to user address 00007f7fe09ff2e0

CPU: 1 PID: 3478 Comm: syz-executor306 Not tainted 5.17.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011(CVE-2022-48855)

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

gianfar: ethtool: Fix refcount leak in gfar_get_ts_info

The of_find_compatible_node() function returns a node pointer with refcount incremented, We should use of_node_put() on it when done Add the missing of_node_put() to release the refcount.(CVE-2022-48856)

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

tipc: fix kernel panic when enabling bearer

When enabling a bearer on a node, a kernel panic is observed:

[ 4.498085] RIP: 0010:tipc_mon_prep+0x4e/0x130 [tipc] ... [ 4.520030] Call Trace: [ 4.520689] <IRQ> [ 4.521236] tipc_link_build_proto_msg+0x375/0x750 [tipc] [ 4.522654] tipc_link_build_state_msg+0x48/0xc0 [tipc] [ 4.524034] __tipc_node_link_up+0xd7/0x290 [tipc] [ 4.525292] tipc_rcv+0x5da/0x730 [tipc] [ 4.526346] ? __netif_receive_skb_core+0xb7/0xfc0 [ 4.527601] tipc_l2_rcv_msg+0x5e/0x90 [tipc] [ 4.528737] __netif_receive_skb_list_core+0x20b/0x260 [ 4.530068] netif_receive_skb_list_internal+0x1bf/0x2e0 [ 4.531450] ? dev_gro_receive+0x4c2/0x680 [ 4.532512] napi_complete_done+0x6f/0x180 [ 4.533570] virtnet_poll+0x29c/0x42e [virtio_net] ...

The node in question is receiving activate messages in another thread after changing bearer status to allow message sending/ receiving in current thread:

     thread 1           |              thread 2
     --------           |              --------
                        |

tipc_enable_bearer() | test_and_set_bit_lock() | tipc_bearer_xmit_skb() | | tipc_l2_rcv_msg() | tipc_rcv() | __tipc_node_link_up() | tipc_link_build_state_msg() | tipc_link_build_proto_msg() | tipc_mon_prep() | { | ... | // null-pointer dereference | u16 gen = mon->dom_gen; | ... | } // Not being executed yet | tipc_mon_create() | { | ... | // allocate | mon = kzalloc(); | ... | } |

Monitoring pointer in thread 2 is dereferenced before monitoring data is allocated in thread 1. This causes kernel panic.

This commit fixes it by allocating the monitoring data before enabling the bearer to receive messages.(CVE-2022-48865)

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

netrom: fix possible dead-lock in nr_rt_ioctl()

syzbot loves netrom, and found a possible deadlock in nr_rt_ioctl [1]

Make sure we always acquire nr_node_list_lock before nr_node_lock(nr_node)

[1] WARNING: possible circular locking dependency detected 6.9.0-rc7-syzkaller-02147-g654de42f3fc6 #0 Not tainted

syz-executor350/5129 is trying to acquire lock: ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_node_lock include/net/netrom.h:152 [inline] ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:464 [inline] ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697

but task is already holding lock: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline] ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_rt_ioctl+0x10a/0x1090 net/netrom/nr_route.c:697

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (nr_node_list_lock){+...}-{2:2}: lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline] _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178 spin_lock_bh include/linux/spinlock.h:356 [inline] nr_remove_node net/netrom/nr_route.c:299 [inline] nr_del_node+0x4b4/0x820 net/netrom/nr_route.c:355 nr_rt_ioctl+0xa95/0x1090 net/netrom/nr_route.c:683 sock_do_ioctl+0x158/0x460 net/socket.c:1222 sock_ioctl+0x629/0x8e0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f

-> #0 (&nr_node->node_lock){+...}-{2:2}: check_prev_add kernel/locking/lockdep.c:3134 [inline] check_prevs_add kernel/locking/lockdep.c:3253 [inline] validate_chain+0x18cb/0x58e0 kernel/locking/lockdep.c:3869 __lock_acquire+0x1346/0x1fd0 kernel/locking/lockdep.c:5137 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline] _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178 spin_lock_bh include/linux/spinlock.h:356 [inline] nr_node_lock include/net/netrom.h:152 [inline] nr_dec_obs net/netrom/nr_route.c:464 [inline] nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697 sock_do_ioctl+0x158/0x460 net/socket.c:1222 sock_ioctl+0x629/0x8e0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f

other info that might help us debug this:

Possible unsafe locking scenario:

   CPU0                    CPU1
   ----                    ----

lock(nr_node_list_lock); lock(&nr_node->node_lock); lock(nr_node_list_lock); lock(&nr_node->node_lock);

*** DEADLOCK ***

1 lock held by syz-executor350/5129: #0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] #0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline] #0: ffffffff8f70 ---truncated---(CVE-2024-38589)

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

crypto: qat - Fix ADF_DEV_RESET_SYNC memory leak

Using completion_done to determine whether the caller has gone away only works after a complete call. Furthermore it's still possible that the caller has not yet called wait_for_completion, resulting in another potential UAF.

Fix this by making the caller use cancel_work_sync and then freeing the memory safely.(CVE-2024-39493)

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

ima: Fix use-after-free on a dentry's dname.name

->d_name.name can change on rename and the earlier value can be freed; there are conditions sufficient to stabilize it (->d_lock on dentry, ->d_lock on its parent, ->i_rwsem exclusive on the parent's inode, rename_lock), but none of those are met at any of the sites. Take a stable snapshot of the name instead.(CVE-2024-39494)

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

vmci: prevent speculation leaks by sanitizing event in event_deliver()

Coverity spotted that event_msg is controlled by user-space, event_msg->event_data.event is passed to event_deliver() and used as an index without sanitization.

This change ensures that the event index is sanitized to mitigate any possibility of speculative information leaks.

This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc.

Only compile tested, no access to HW.(CVE-2024-39499)

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

USB: class: cdc-wdm: Fix CPU lockup caused by excessive log messages

The syzbot fuzzer found that the interrupt-URB completion callback in the cdc-wdm driver was taking too long, and the driver's immediate resubmission of interrupt URBs with -EPROTO status combined with the dummy-hcd emulation to cause a CPU lockup:

cdc_wdm 1-1:1.0: nonzero urb status received: -71 cdc_wdm 1-1:1.0: wdm_int_callback - 0 bytes watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [syz-executor782:6625] CPU#0 Utilization every 4s during lockup: #1: 98% system, 0% softirq, 3% hardirq, 0% idle #2: 98% system, 0% softirq, 3% hardirq, 0% idle #3: 98% system, 0% softirq, 3% hardirq, 0% idle #4: 98% system, 0% softirq, 3% hardirq, 0% idle #5: 98% system, 1% softirq, 3% hardirq, 0% idle Modules linked in: irq event stamp: 73096 hardirqs last enabled at (73095): [<ffff80008037bc00>] console_emit_next_record kernel/printk/printk.c:2935 [inline] hardirqs last enabled at (73095): [<ffff80008037bc00>] console_flush_all+0x650/0xb74 kernel/printk/printk.c:2994 hardirqs last disabled at (73096): [<ffff80008af10b00>] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline] hardirqs last disabled at (73096): [<ffff80008af10b00>] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551 softirqs last enabled at (73048): [<ffff8000801ea530>] softirq_handle_end kernel/softirq.c:400 [inline] softirqs last enabled at (73048): [<ffff8000801ea530>] handle_softirqs+0xa60/0xc34 kernel/softirq.c:582 softirqs last disabled at (73043): [<ffff800080020de8>] __do_softirq+0x14/0x20 kernel/softirq.c:588 CPU: 0 PID: 6625 Comm: syz-executor782 Tainted: G W 6.10.0-rc2-syzkaller-g8867bbd4a056 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024

Testing showed that the problem did not occur if the two error messages -- the first two lines above -- were removed; apparently adding material to the kernel log takes a surprisingly large amount of time.

In any case, the best approach for preventing these lockups and to avoid spamming the log with thousands of error messages per second is to ratelimit the two dev_err() calls. Therefore we replace them with dev_err_ratelimited().(CVE-2024-40904)

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

wifi: mac80211: Fix deadlock in ieee80211_sta_ps_deliver_wakeup()

The ieee80211_sta_ps_deliver_wakeup() function takes sta->ps_lock to synchronizes with ieee80211_tx_h_unicast_ps_buf() which is called from softirq context. However using only spin_lock() to get sta->ps_lock in ieee80211_sta_ps_deliver_wakeup() does not prevent softirq to execute on this same CPU, to run ieee80211_tx_h_unicast_ps_buf() and try to take this same lock ending in deadlock. Below is an example of rcu stall that arises in such situation.

rcu: INFO: rcu_sched self-detected stall on CPU rcu: 2-....: (42413413 ticks this GP) idle=b154/1/0x4000000000000000 softirq=1763/1765 fqs=21206996 rcu: (t=42586894 jiffies g=2057 q=362405 ncpus=4) CPU: 2 PID: 719 Comm: wpa_supplicant Tainted: G W 6.4.0-02158-g1b062f552873 #742 Hardware name: RPT (r1) (DT) pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : queued_spin_lock_slowpath+0x58/0x2d0 lr : invoke_tx_handlers_early+0x5b4/0x5c0 sp : ffff00001ef64660 x29: ffff00001ef64660 x28: ffff000009bc1070 x27: ffff000009bc0ad8 x26: ffff000009bc0900 x25: ffff00001ef647a8 x24: 0000000000000000 x23: ffff000009bc0900 x22: ffff000009bc0900 x21: ffff00000ac0e000 x20: ffff00000a279e00 x19: ffff00001ef646e8 x18: 0000000000000000 x17: ffff800016468000 x16: ffff00001ef608c0 x15: 0010533c93f64f80 x14: 0010395c9faa3946 x13: 0000000000000000 x12: 00000000fa83b2da x11: 000000012edeceea x10: ffff0000010fbe00 x9 : 0000000000895440 x8 : 000000000010533c x7 : ffff00000ad8b740 x6 : ffff00000c350880 x5 : 0000000000000007 x4 : 0000000000000001 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffff00000ac0e0e8 Call trace: queued_spin_lock_slowpath+0x58/0x2d0 ieee80211_tx+0x80/0x12c ieee80211_tx_pending+0x110/0x278 tasklet_action_common.constprop.0+0x10c/0x144 tasklet_action+0x20/0x28 _stext+0x11c/0x284 _dosoftirq+0xc/0x14 call_on_irq_stack+0x24/0x34 do_softirq_own_stack+0x18/0x20 do_softirq+0x74/0x7c local_bh_enable_ip+0xa0/0xa4 _ieee80211_wake_txqs+0x3b0/0x4b8 __ieee80211_wake_queue+0x12c/0x168 ieee80211_add_pending_skbs+0xec/0x138 ieee80211_sta_ps_deliver_wakeup+0x2a4/0x480 ieee80211_mps_sta_status_update.part.0+0xd8/0x11c ieee80211_mps_sta_status_update+0x18/0x24 sta_apply_parameters+0x3bc/0x4c0 ieee80211_change_station+0x1b8/0x2dc nl80211_set_station+0x444/0x49c genl_family_rcv_msg_doit.isra.0+0xa4/0xfc genl_rcv_msg+0x1b0/0x244 netlink_rcv_skb+0x38/0x10c genl_rcv+0x34/0x48 netlink_unicast+0x254/0x2bc netlink_sendmsg+0x190/0x3b4 _syssendmsg+0x1e8/0x218 _sys_sendmsg+0x68/0x8c __sys_sendmsg+0x44/0x84 __arm64_sys_sendmsg+0x20/0x28 do_el0_svc+0x6c/0xe8 el0_svc+0x14/0x48 el0t_64_sync_handler+0xb0/0xb4 el0t_64_sync+0x14c/0x150

Using spin_lock_bh()/spin_unlock_bh() instead prevents softirq to raise on the same CPU that is holding the lock.(CVE-2024-40912)

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

wifi: iwlwifi: mvm: check n_ssids before accessing the ssids

In some versions of cfg80211, the ssids poinet might be a valid one even though n_ssids is 0. Accessing the pointer in this case will cuase an out-of-bound access. Fix this by checking n_ssids first.(CVE-2024-40929)

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

drm/exynos/vidi: fix memory leak in .get_modes()

The duplicated EDID is never freed. Fix it.(CVE-2024-40932)

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

wifi: iwlwifi: mvm: don't read past the mfuart notifcation

In case the firmware sends a notification that claims it has more data than it has, we will read past that was allocated for the notification. Remove the print of the buffer, we won't see it by default. If needed, we can see the content with tracing.

This was reported by KFENCE.(CVE-2024-40941)

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

ocfs2: fix races between hole punching and AIO+DIO

After commit "ocfs2: return real error code in ocfs2_dio_wr_get_block", fstests/generic/300 become from always failed to sometimes failed:

======================================================================== [ 473.293420 ] run fstests generic/300

[ 475.296983 ] JBD2: Ignoring recovery information on journal [ 475.302473 ] ocfs2: Mounting device (253,1) on (node local, slot 0) with ordered data mode. [ 494.290998 ] OCFS2: ERROR (device dm-1): ocfs2_change_extent_flag: Owner 5668 has an extent at cpos 78723 which can no longer be found [ 494.291609 ] On-disk corruption discovered. Please run fsck.ocfs2 once the filesystem is unmounted. [ 494.292018 ] OCFS2: File system is now read-only. [ 494.292224 ] (kworker/19:11,2628,19):ocfs2_mark_extent_written:5272 ERROR: status = -30 [ 494.292602 ] (kworker/19:11,2628,19):ocfs2_dio_end_io_write:2374 ERROR: status = -3 fio: io_u error on file /mnt/scratch/racer: Read-only file system: write offset=460849152, buflen=131072 =========================================================================

In __blockdev_direct_IO, ocfs2_dio_wr_get_block is called to add unwritten extents to a list. extents are also inserted into extent tree in ocfs2_write_begin_nolock. Then another thread call fallocate to puch a hole at one of the unwritten extent. The extent at cpos was removed by ocfs2_remove_extent(). At end io worker thread, ocfs2_search_extent_list found there is no such extent at the cpos.

T1                        T2                T3
                          inode lock
                            ...
                            insert extents
                            ...
                          inode unlock

ocfs2_fallocate __ocfs2_change_file_space inode lock lock ip_alloc_sem ocfs2_remove_inode_range inode ocfs2_remove_btree_range ocfs2_remove_extent ^---remove the extent at cpos 78723 ... unlock ip_alloc_sem inode unlock ocfs2_dio_end_io ocfs2_dio_end_io_write lock ip_alloc_sem ocfs2_mark_extent_written ocfs2_change_extent_flag ocfs2_search_extent_list ^---failed to find extent ... unlock ip_alloc_sem

In most filesystems, fallocate is not compatible with racing with AIO+DIO, so fix it by adding to wait for all dio before fallocate/punch_hole like ext4.(CVE-2024-40943)

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

MIPS: Octeon: Add PCIe link status check

The standard PCIe configuration read-write interface is used to access the configuration space of the peripheral PCIe devices of the mips processor after the PCIe link surprise down, it can generate kernel panic caused by "Data bus error". So it is necessary to add PCIe link status check for system protection. When the PCIe link is down or in training, assigning a value of 0 to the configuration address can prevent read-write behavior to the configuration space of peripheral PCIe devices, thereby preventing kernel panic.(CVE-2024-40968)

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

powerpc/pseries: Enforce hcall result buffer validity and size

plpar_hcall(), plpar_hcall9(), and related functions expect callers to provide valid result buffers of certain minimum size. Currently this is communicated only through comments in the code and the compiler has no idea.

For example, if I write a bug like this:

long retbuf[PLPAR_HCALL_BUFSIZE]; // should be PLPAR_HCALL9_BUFSIZE plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, ...);

This compiles with no diagnostics emitted, but likely results in stack corruption at runtime when plpar_hcall9() stores results past the end of the array. (To be clear this is a contrived example and I have not found a real instance yet.)

To make this class of error less likely, we can use explicitly-sized array parameters instead of pointers in the declarations for the hcall APIs. When compiled with -Warray-bounds[1], the code above now provokes a diagnostic like this:

error: array argument is too small; is of size 32, callee requires at least 72 [-Werror,-Warray-bounds] 60 | plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, | ^ ~~~~~~

[1] Enabled for LLVM builds but not GCC for now. See commit 0da6e5fd6c37 ("gcc: disable '-Warray-bounds' for gcc-13 too") and related changes.(CVE-2024-40974)

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

ACPICA: Revert "ACPICA: avoid Info: mapping multiple BARs. Your kernel is fine."

Undo the modifications made in commit d410ee5109a1 ("ACPICA: avoid "Info: mapping multiple BARs. Your kernel is fine.""). The initial purpose of this commit was to stop memory mappings for operation regions from overlapping page boundaries, as it can trigger warnings if different page attributes are present.

However, it was found that when this situation arises, mapping continues until the boundary's end, but there is still an attempt to read/write the entire length of the map, leading to a NULL pointer deference. For example, if a four-byte mapping request is made but only one byte is mapped because it hits the current page boundary's end, a four-byte read/write attempt is still made, resulting in a NULL pointer deference.

Instead, map the entire length, as the ACPI specification does not mandate that it must be within the same page boundary. It is permissible for it to be mapped across different regions.(CVE-2024-40984)

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

drm/amdgpu: fix UBSAN warning in kv_dpm.c

Adds bounds check for sumo_vid_mapping_entry.(CVE-2024-40987)

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

netpoll: Fix race condition in netpoll_owner_active

KCSAN detected a race condition in netpoll:

BUG: KCSAN: data-race in net_rx_action / netpoll_send_skb
write (marked) to 0xffff8881164168b0 of 4 bytes by interrupt on cpu 10:
net_rx_action (./include/linux/netpoll.h:90 net/core/dev.c:6712 net/core/dev.c:6822)

<snip> read to 0xffff8881164168b0 of 4 bytes by task 1 on cpu 2: netpoll_send_skb (net/core/netpoll.c:319 net/core/netpoll.c:345 net/core/netpoll.c:393) netpoll_send_udp (net/core/netpoll.c:?) <snip> value changed: 0x0000000a -> 0xffffffff

This happens because netpoll_owner_active() needs to check if the current CPU is the owner of the lock, touching napi->poll_owner non atomically. The ->poll_owner field contains the current CPU holding the lock.

Use an atomic read to check if the poll owner is the current CPU.(CVE-2024-41005)

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

tcp: avoid too many retransmit packets

If a TCP socket is using TCP_USER_TIMEOUT, and the other peer retracted its window to zero, tcp_retransmit_timer() can retransmit a packet every two jiffies (2 ms for HZ=1000), for about 4 minutes after TCP_USER_TIMEOUT has 'expired'.

The fix is to make sure tcp_rtx_probe0_timed_out() takes icsk->icsk_user_timeout into account.

Before blamed commit, the socket would not timeout after icsk->icsk_user_timeout, but would use standard exponential backoff for the retransmits.

Also worth noting that before commit e89688e3e978 ("net: tcp: fix unexcepted socket die when snd_wnd is 0"), the issue would last 2 minutes instead of 4.(CVE-2024-41007)

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-47612	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-48775	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-48788	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-48838	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-48855	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-48856	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-48865	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-38589	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-39493	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-39494	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-39499	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-40904	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-40912	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-40929	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-40932	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-40941	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-40943	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-40968	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-40974	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-40984	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-40987	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-41005	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-41007	ADVISORY

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-4.19.90-2407.5.0.0287.oe2003sp4.aarch64.rpm",
          "bpftool-debuginfo-4.19.90-2407.5.0.0287.oe2003sp4.aarch64.rpm",
          "kernel-4.19.90-2407.5.0.0287.oe2003sp4.aarch64.rpm",
          "kernel-debuginfo-4.19.90-2407.5.0.0287.oe2003sp4.aarch64.rpm",
          "kernel-debugsource-4.19.90-2407.5.0.0287.oe2003sp4.aarch64.rpm",
          "kernel-devel-4.19.90-2407.5.0.0287.oe2003sp4.aarch64.rpm",
          "kernel-source-4.19.90-2407.5.0.0287.oe2003sp4.aarch64.rpm",
          "kernel-tools-4.19.90-2407.5.0.0287.oe2003sp4.aarch64.rpm",
          "kernel-tools-debuginfo-4.19.90-2407.5.0.0287.oe2003sp4.aarch64.rpm",
          "kernel-tools-devel-4.19.90-2407.5.0.0287.oe2003sp4.aarch64.rpm",
          "perf-4.19.90-2407.5.0.0287.oe2003sp4.aarch64.rpm",
          "perf-debuginfo-4.19.90-2407.5.0.0287.oe2003sp4.aarch64.rpm",
          "python2-perf-4.19.90-2407.5.0.0287.oe2003sp4.aarch64.rpm",
          "python2-perf-debuginfo-4.19.90-2407.5.0.0287.oe2003sp4.aarch64.rpm",
          "python3-perf-4.19.90-2407.5.0.0287.oe2003sp4.aarch64.rpm",
          "python3-perf-debuginfo-4.19.90-2407.5.0.0287.oe2003sp4.aarch64.rpm"
        ],
        "src": [
          "kernel-4.19.90-2407.5.0.0287.oe2003sp4.src.rpm"
        ],
        "x86_64": [
          "bpftool-4.19.90-2407.5.0.0287.oe2003sp4.x86_64.rpm",
          "bpftool-debuginfo-4.19.90-2407.5.0.0287.oe2003sp4.x86_64.rpm",
          "kernel-4.19.90-2407.5.0.0287.oe2003sp4.x86_64.rpm",
          "kernel-debuginfo-4.19.90-2407.5.0.0287.oe2003sp4.x86_64.rpm",
          "kernel-debugsource-4.19.90-2407.5.0.0287.oe2003sp4.x86_64.rpm",
          "kernel-devel-4.19.90-2407.5.0.0287.oe2003sp4.x86_64.rpm",
          "kernel-source-4.19.90-2407.5.0.0287.oe2003sp4.x86_64.rpm",
          "kernel-tools-4.19.90-2407.5.0.0287.oe2003sp4.x86_64.rpm",
          "kernel-tools-debuginfo-4.19.90-2407.5.0.0287.oe2003sp4.x86_64.rpm",
          "kernel-tools-devel-4.19.90-2407.5.0.0287.oe2003sp4.x86_64.rpm",
          "perf-4.19.90-2407.5.0.0287.oe2003sp4.x86_64.rpm",
          "perf-debuginfo-4.19.90-2407.5.0.0287.oe2003sp4.x86_64.rpm",
          "python2-perf-4.19.90-2407.5.0.0287.oe2003sp4.x86_64.rpm",
          "python2-perf-debuginfo-4.19.90-2407.5.0.0287.oe2003sp4.x86_64.rpm",
          "python3-perf-4.19.90-2407.5.0.0287.oe2003sp4.x86_64.rpm",
          "python3-perf-debuginfo-4.19.90-2407.5.0.0287.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-2407.5.0.0287.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\nnfc: fix segfault in nfc_genl_dump_devices_done\r\n\r\nWhen kmalloc in nfc_genl_dump_devices() fails then\nnfc_genl_dump_devices_done() segfaults as below\r\n\r\nKASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]\nCPU: 0 PID: 25 Comm: kworker/0:1 Not tainted 5.16.0-rc4-01180-g2a987e65025e-dirty #5\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-6.fc35 04/01/2014\nWorkqueue: events netlink_sock_destruct_work\nRIP: 0010:klist_iter_exit+0x26/0x80\nCall Trace:\n\u0026lt;TASK\u0026gt;\nclass_dev_iter_exit+0x15/0x20\nnfc_genl_dump_devices_done+0x3b/0x50\ngenl_lock_done+0x84/0xd0\nnetlink_sock_destruct+0x8f/0x270\n__sk_destruct+0x64/0x3b0\nsk_destruct+0xa8/0xd0\n__sk_free+0x2e8/0x3d0\nsk_free+0x51/0x90\nnetlink_sock_destruct_work+0x1c/0x20\nprocess_one_work+0x411/0x710\nworker_thread+0x6fd/0xa80(CVE-2021-47612)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nDrivers: hv: vmbus: Fix memory leak in vmbus_add_channel_kobj\r\n\r\nkobject_init_and_add() takes reference even when it fails.\nAccording to the doc of kobject_init_and_add()?\r\n\r\n   If this function returns an error, kobject_put() must be called to\n   properly clean up the memory associated with the object.\r\n\r\nFix memory leak by calling kobject_put().(CVE-2022-48775)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnvme-rdma: fix possible use-after-free in transport error_recovery work\r\n\r\nWhile nvme_rdma_submit_async_event_work is checking the ctrl and queue\nstate before preparing the AER command and scheduling io_work, in order\nto fully prevent a race where this check is not reliable the error\nrecovery work must flush async_event_work before continuing to destroy\nthe admin queue after setting the ctrl state to RESETTING such that\nthere is no race .submit_async_event and the error recovery handler\nitself changing the ctrl state.(CVE-2022-48788)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: gadget: Fix use-after-free bug by not setting udc-\u0026gt;dev.driver\r\n\r\nThe syzbot fuzzer found a use-after-free bug:\r\n\r\nBUG: KASAN: use-after-free in dev_uevent+0x712/0x780 drivers/base/core.c:2320\nRead of size 8 at addr ffff88802b934098 by task udevd/3689\r\n\r\nCPU: 2 PID: 3689 Comm: udevd Not tainted 5.17.0-rc4-syzkaller-00229-g4f12b742eb2b #0\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106\n print_address_description.constprop.0.cold+0x8d/0x303 mm/kasan/report.c:255\n __kasan_report mm/kasan/report.c:442 [inline]\n kasan_report.cold+0x83/0xdf mm/kasan/report.c:459\n dev_uevent+0x712/0x780 drivers/base/core.c:2320\n uevent_show+0x1b8/0x380 drivers/base/core.c:2391\n dev_attr_show+0x4b/0x90 drivers/base/core.c:2094\r\n\r\nAlthough the bug manifested in the driver core, the real cause was a\nrace with the gadget core.  dev_uevent() does:\r\n\r\n\tif (dev-\u0026gt;driver)\n\t\tadd_uevent_var(env, \u0026quot;DRIVER=%s\u0026quot;, dev-\u0026gt;driver-\u0026gt;name);\r\n\r\nand between the test and the dereference of dev-\u0026gt;driver, the gadget\ncore sets dev-\u0026gt;driver to NULL.\r\n\r\nThe race wouldn\u0026apos;t occur if the gadget core registered its devices on\na real bus, using the standard synchronization techniques of the\ndriver core.  However, it\u0026apos;s not necessary to make such a large change\nin order to fix this bug; all we need to do is make sure that\nudc-\u0026gt;dev.driver is always NULL.\r\n\r\nIn fact, there is no reason for udc-\u0026gt;dev.driver ever to be set to\nanything, let alone to the value it currently gets: the address of the\ngadget\u0026apos;s driver.  After all, a gadget driver only knows how to manage\na gadget, not how to manage a UDC.\r\n\r\nThis patch simply removes the statements in the gadget core that touch\nudc-\u0026gt;dev.driver.(CVE-2022-48838)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsctp: fix kernel-infoleak for SCTP sockets\r\n\r\nsyzbot reported a kernel infoleak [1] of 4 bytes.\r\n\r\nAfter analysis, it turned out r-\u0026gt;idiag_expires is not initialized\nif inet_sctp_diag_fill() calls inet_diag_msg_common_fill()\r\n\r\nMake sure to clear idiag_timer/idiag_retrans/idiag_expires\nand let inet_diag_msg_sctpasoc_fill() fill them again if needed.\r\n\r\n[1]\r\n\r\nBUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:121 [inline]\nBUG: KMSAN: kernel-infoleak in copyout lib/iov_iter.c:154 [inline]\nBUG: KMSAN: kernel-infoleak in _copy_to_iter+0x6ef/0x25a0 lib/iov_iter.c:668\n instrument_copy_to_user include/linux/instrumented.h:121 [inline]\n copyout lib/iov_iter.c:154 [inline]\n _copy_to_iter+0x6ef/0x25a0 lib/iov_iter.c:668\n copy_to_iter include/linux/uio.h:162 [inline]\n simple_copy_to_iter+0xf3/0x140 net/core/datagram.c:519\n __skb_datagram_iter+0x2d5/0x11b0 net/core/datagram.c:425\n skb_copy_datagram_iter+0xdc/0x270 net/core/datagram.c:533\n skb_copy_datagram_msg include/linux/skbuff.h:3696 [inline]\n netlink_recvmsg+0x669/0x1c80 net/netlink/af_netlink.c:1977\n sock_recvmsg_nosec net/socket.c:948 [inline]\n sock_recvmsg net/socket.c:966 [inline]\n __sys_recvfrom+0x795/0xa10 net/socket.c:2097\n __do_sys_recvfrom net/socket.c:2115 [inline]\n __se_sys_recvfrom net/socket.c:2111 [inline]\n __x64_sys_recvfrom+0x19d/0x210 net/socket.c:2111\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82\n entry_SYSCALL_64_after_hwframe+0x44/0xae\r\n\r\nUninit was created at:\n slab_post_alloc_hook mm/slab.h:737 [inline]\n slab_alloc_node mm/slub.c:3247 [inline]\n __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4975\n kmalloc_reserve net/core/skbuff.c:354 [inline]\n __alloc_skb+0x545/0xf90 net/core/skbuff.c:426\n alloc_skb include/linux/skbuff.h:1158 [inline]\n netlink_dump+0x3e5/0x16c0 net/netlink/af_netlink.c:2248\n __netlink_dump_start+0xcf8/0xe90 net/netlink/af_netlink.c:2373\n netlink_dump_start include/linux/netlink.h:254 [inline]\n inet_diag_handler_cmd+0x2e7/0x400 net/ipv4/inet_diag.c:1341\n sock_diag_rcv_msg+0x24a/0x620\n netlink_rcv_skb+0x40c/0x7e0 net/netlink/af_netlink.c:2494\n sock_diag_rcv+0x63/0x80 net/core/sock_diag.c:277\n netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]\n netlink_unicast+0x1093/0x1360 net/netlink/af_netlink.c:1343\n netlink_sendmsg+0x14d9/0x1720 net/netlink/af_netlink.c:1919\n sock_sendmsg_nosec net/socket.c:705 [inline]\n sock_sendmsg net/socket.c:725 [inline]\n sock_write_iter+0x594/0x690 net/socket.c:1061\n do_iter_readv_writev+0xa7f/0xc70\n do_iter_write+0x52c/0x1500 fs/read_write.c:851\n vfs_writev fs/read_write.c:924 [inline]\n do_writev+0x645/0xe00 fs/read_write.c:967\n __do_sys_writev fs/read_write.c:1040 [inline]\n __se_sys_writev fs/read_write.c:1037 [inline]\n __x64_sys_writev+0xe5/0x120 fs/read_write.c:1037\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82\n entry_SYSCALL_64_after_hwframe+0x44/0xae\r\n\r\nBytes 68-71 of 2508 are uninitialized\nMemory access of size 2508 starts at ffff888114f9b000\nData copied to user address 00007f7fe09ff2e0\r\n\r\nCPU: 1 PID: 3478 Comm: syz-executor306 Not tainted 5.17.0-rc4-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011(CVE-2022-48855)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngianfar: ethtool: Fix refcount leak in gfar_get_ts_info\r\n\r\nThe of_find_compatible_node() function returns a node pointer with\nrefcount incremented, We should use of_node_put() on it when done\nAdd the missing of_node_put() to release the refcount.(CVE-2022-48856)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntipc: fix kernel panic when enabling bearer\r\n\r\nWhen enabling a bearer on a node, a kernel panic is observed:\r\n\r\n[    4.498085] RIP: 0010:tipc_mon_prep+0x4e/0x130 [tipc]\n...\n[    4.520030] Call Trace:\n[    4.520689]  \u0026lt;IRQ\u0026gt;\n[    4.521236]  tipc_link_build_proto_msg+0x375/0x750 [tipc]\n[    4.522654]  tipc_link_build_state_msg+0x48/0xc0 [tipc]\n[    4.524034]  __tipc_node_link_up+0xd7/0x290 [tipc]\n[    4.525292]  tipc_rcv+0x5da/0x730 [tipc]\n[    4.526346]  ? __netif_receive_skb_core+0xb7/0xfc0\n[    4.527601]  tipc_l2_rcv_msg+0x5e/0x90 [tipc]\n[    4.528737]  __netif_receive_skb_list_core+0x20b/0x260\n[    4.530068]  netif_receive_skb_list_internal+0x1bf/0x2e0\n[    4.531450]  ? dev_gro_receive+0x4c2/0x680\n[    4.532512]  napi_complete_done+0x6f/0x180\n[    4.533570]  virtnet_poll+0x29c/0x42e [virtio_net]\n...\r\n\r\nThe node in question is receiving activate messages in another\nthread after changing bearer status to allow message sending/\nreceiving in current thread:\r\n\r\n         thread 1           |              thread 2\n         --------           |              --------\n                            |\ntipc_enable_bearer()        |\n  test_and_set_bit_lock()   |\n    tipc_bearer_xmit_skb()  |\n                            | tipc_l2_rcv_msg()\n                            |   tipc_rcv()\n                            |     __tipc_node_link_up()\n                            |       tipc_link_build_state_msg()\n                            |         tipc_link_build_proto_msg()\n                            |           tipc_mon_prep()\n                            |           {\n                            |             ...\n                            |             // null-pointer dereference\n                            |             u16 gen = mon-\u0026gt;dom_gen;\n                            |             ...\n                            |           }\n  // Not being executed yet |\n  tipc_mon_create()         |\n  {                         |\n    ...                     |\n    // allocate             |\n    mon = kzalloc();        |\n    ...                     |\n  }                         |\r\n\r\nMonitoring pointer in thread 2 is dereferenced before monitoring data\nis allocated in thread 1. This causes kernel panic.\r\n\r\nThis commit fixes it by allocating the monitoring data before enabling\nthe bearer to receive messages.(CVE-2022-48865)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetrom: fix possible dead-lock in nr_rt_ioctl()\r\n\r\nsyzbot loves netrom, and found a possible deadlock in nr_rt_ioctl [1]\r\n\r\nMake sure we always acquire nr_node_list_lock before nr_node_lock(nr_node)\r\n\r\n[1]\nWARNING: possible circular locking dependency detected\n6.9.0-rc7-syzkaller-02147-g654de42f3fc6 #0 Not tainted\n------------------------------------------------------\nsyz-executor350/5129 is trying to acquire lock:\n ffff8880186e2070 (\u0026amp;nr_node-\u0026gt;node_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]\n ffff8880186e2070 (\u0026amp;nr_node-\u0026gt;node_lock){+...}-{2:2}, at: nr_node_lock include/net/netrom.h:152 [inline]\n ffff8880186e2070 (\u0026amp;nr_node-\u0026gt;node_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:464 [inline]\n ffff8880186e2070 (\u0026amp;nr_node-\u0026gt;node_lock){+...}-{2:2}, at: nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697\r\n\r\nbut task is already holding lock:\n ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]\n ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline]\n ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_rt_ioctl+0x10a/0x1090 net/netrom/nr_route.c:697\r\n\r\nwhich lock already depends on the new lock.\r\n\r\nthe existing dependency chain (in reverse order) is:\r\n\r\n-\u0026gt; #1 (nr_node_list_lock){+...}-{2:2}:\n        lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754\n        __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline]\n        _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178\n        spin_lock_bh include/linux/spinlock.h:356 [inline]\n        nr_remove_node net/netrom/nr_route.c:299 [inline]\n        nr_del_node+0x4b4/0x820 net/netrom/nr_route.c:355\n        nr_rt_ioctl+0xa95/0x1090 net/netrom/nr_route.c:683\n        sock_do_ioctl+0x158/0x460 net/socket.c:1222\n        sock_ioctl+0x629/0x8e0 net/socket.c:1341\n        vfs_ioctl fs/ioctl.c:51 [inline]\n        __do_sys_ioctl fs/ioctl.c:904 [inline]\n        __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890\n        do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n        do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83\n       entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\n-\u0026gt; #0 (\u0026amp;nr_node-\u0026gt;node_lock){+...}-{2:2}:\n        check_prev_add kernel/locking/lockdep.c:3134 [inline]\n        check_prevs_add kernel/locking/lockdep.c:3253 [inline]\n        validate_chain+0x18cb/0x58e0 kernel/locking/lockdep.c:3869\n        __lock_acquire+0x1346/0x1fd0 kernel/locking/lockdep.c:5137\n        lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754\n        __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline]\n        _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178\n        spin_lock_bh include/linux/spinlock.h:356 [inline]\n        nr_node_lock include/net/netrom.h:152 [inline]\n        nr_dec_obs net/netrom/nr_route.c:464 [inline]\n        nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697\n        sock_do_ioctl+0x158/0x460 net/socket.c:1222\n        sock_ioctl+0x629/0x8e0 net/socket.c:1341\n        vfs_ioctl fs/ioctl.c:51 [inline]\n        __do_sys_ioctl fs/ioctl.c:904 [inline]\n        __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890\n        do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n        do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83\n       entry_SYSCALL_64_after_hwframe+0x77/0x7f\r\n\r\nother info that might help us debug this:\r\n\r\n Possible unsafe locking scenario:\r\n\r\n       CPU0                    CPU1\n       ----                    ----\n  lock(nr_node_list_lock);\n                               lock(\u0026amp;nr_node-\u0026gt;node_lock);\n                               lock(nr_node_list_lock);\n  lock(\u0026amp;nr_node-\u0026gt;node_lock);\r\n\r\n *** DEADLOCK ***\r\n\r\n1 lock held by syz-executor350/5129:\n  #0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]\n  #0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline]\n  #0: ffffffff8f70\n---truncated---(CVE-2024-38589)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncrypto: qat - Fix ADF_DEV_RESET_SYNC memory leak\r\n\r\nUsing completion_done to determine whether the caller has gone\naway only works after a complete call.  Furthermore it\u0026apos;s still\npossible that the caller has not yet called wait_for_completion,\nresulting in another potential UAF.\r\n\r\nFix this by making the caller use cancel_work_sync and then freeing\nthe memory safely.(CVE-2024-39493)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nima: Fix use-after-free on a dentry\u0026apos;s dname.name\r\n\r\n-\u0026gt;d_name.name can change on rename and the earlier value can be freed;\nthere are conditions sufficient to stabilize it (-\u0026gt;d_lock on dentry,\n-\u0026gt;d_lock on its parent, -\u0026gt;i_rwsem exclusive on the parent\u0026apos;s inode,\nrename_lock), but none of those are met at any of the sites. Take a stable\nsnapshot of the name instead.(CVE-2024-39494)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nvmci: prevent speculation leaks by sanitizing event in event_deliver()\r\n\r\nCoverity spotted that event_msg is controlled by user-space,\nevent_msg-\u0026gt;event_data.event is passed to event_deliver() and used\nas an index without sanitization.\r\n\r\nThis change ensures that the event index is sanitized to mitigate any\npossibility of speculative information leaks.\r\n\r\nThis bug was discovered and resolved using Coverity Static Analysis\nSecurity Testing (SAST) by Synopsys, Inc.\r\n\r\nOnly compile tested, no access to HW.(CVE-2024-39499)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nUSB: class: cdc-wdm: Fix CPU lockup caused by excessive log messages\r\n\r\nThe syzbot fuzzer found that the interrupt-URB completion callback in\nthe cdc-wdm driver was taking too long, and the driver\u0026apos;s immediate\nresubmission of interrupt URBs with -EPROTO status combined with the\ndummy-hcd emulation to cause a CPU lockup:\r\n\r\ncdc_wdm 1-1:1.0: nonzero urb status received: -71\ncdc_wdm 1-1:1.0: wdm_int_callback - 0 bytes\nwatchdog: BUG: soft lockup - CPU#0 stuck for 26s! [syz-executor782:6625]\nCPU#0 Utilization every 4s during lockup:\n\t#1:  98% system,\t  0% softirq,\t  3% hardirq,\t  0% idle\n\t#2:  98% system,\t  0% softirq,\t  3% hardirq,\t  0% idle\n\t#3:  98% system,\t  0% softirq,\t  3% hardirq,\t  0% idle\n\t#4:  98% system,\t  0% softirq,\t  3% hardirq,\t  0% idle\n\t#5:  98% system,\t  1% softirq,\t  3% hardirq,\t  0% idle\nModules linked in:\nirq event stamp: 73096\nhardirqs last  enabled at (73095): [\u0026lt;ffff80008037bc00\u0026gt;] console_emit_next_record kernel/printk/printk.c:2935 [inline]\nhardirqs last  enabled at (73095): [\u0026lt;ffff80008037bc00\u0026gt;] console_flush_all+0x650/0xb74 kernel/printk/printk.c:2994\nhardirqs last disabled at (73096): [\u0026lt;ffff80008af10b00\u0026gt;] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]\nhardirqs last disabled at (73096): [\u0026lt;ffff80008af10b00\u0026gt;] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551\nsoftirqs last  enabled at (73048): [\u0026lt;ffff8000801ea530\u0026gt;] softirq_handle_end kernel/softirq.c:400 [inline]\nsoftirqs last  enabled at (73048): [\u0026lt;ffff8000801ea530\u0026gt;] handle_softirqs+0xa60/0xc34 kernel/softirq.c:582\nsoftirqs last disabled at (73043): [\u0026lt;ffff800080020de8\u0026gt;] __do_softirq+0x14/0x20 kernel/softirq.c:588\nCPU: 0 PID: 6625 Comm: syz-executor782 Tainted: G        W          6.10.0-rc2-syzkaller-g8867bbd4a056 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024\r\n\r\nTesting showed that the problem did not occur if the two error\nmessages -- the first two lines above -- were removed; apparently adding\nmaterial to the kernel log takes a surprisingly large amount of time.\r\n\r\nIn any case, the best approach for preventing these lockups and to\navoid spamming the log with thousands of error messages per second is\nto ratelimit the two dev_err() calls.  Therefore we replace them with\ndev_err_ratelimited().(CVE-2024-40904)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: mac80211: Fix deadlock in ieee80211_sta_ps_deliver_wakeup()\r\n\r\nThe ieee80211_sta_ps_deliver_wakeup() function takes sta-\u0026gt;ps_lock to\nsynchronizes with ieee80211_tx_h_unicast_ps_buf() which is called from\nsoftirq context. However using only spin_lock() to get sta-\u0026gt;ps_lock in\nieee80211_sta_ps_deliver_wakeup() does not prevent softirq to execute\non this same CPU, to run ieee80211_tx_h_unicast_ps_buf() and try to\ntake this same lock ending in deadlock. Below is an example of rcu stall\nthat arises in such situation.\r\n\r\n rcu: INFO: rcu_sched self-detected stall on CPU\n rcu:    2-....: (42413413 ticks this GP) idle=b154/1/0x4000000000000000 softirq=1763/1765 fqs=21206996\n rcu:    (t=42586894 jiffies g=2057 q=362405 ncpus=4)\n CPU: 2 PID: 719 Comm: wpa_supplicant Tainted: G        W          6.4.0-02158-g1b062f552873 #742\n Hardware name: RPT (r1) (DT)\n pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : queued_spin_lock_slowpath+0x58/0x2d0\n lr : invoke_tx_handlers_early+0x5b4/0x5c0\n sp : ffff00001ef64660\n x29: ffff00001ef64660 x28: ffff000009bc1070 x27: ffff000009bc0ad8\n x26: ffff000009bc0900 x25: ffff00001ef647a8 x24: 0000000000000000\n x23: ffff000009bc0900 x22: ffff000009bc0900 x21: ffff00000ac0e000\n x20: ffff00000a279e00 x19: ffff00001ef646e8 x18: 0000000000000000\n x17: ffff800016468000 x16: ffff00001ef608c0 x15: 0010533c93f64f80\n x14: 0010395c9faa3946 x13: 0000000000000000 x12: 00000000fa83b2da\n x11: 000000012edeceea x10: ffff0000010fbe00 x9 : 0000000000895440\n x8 : 000000000010533c x7 : ffff00000ad8b740 x6 : ffff00000c350880\n x5 : 0000000000000007 x4 : 0000000000000001 x3 : 0000000000000000\n x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffff00000ac0e0e8\n Call trace:\n  queued_spin_lock_slowpath+0x58/0x2d0\n  ieee80211_tx+0x80/0x12c\n  ieee80211_tx_pending+0x110/0x278\n  tasklet_action_common.constprop.0+0x10c/0x144\n  tasklet_action+0x20/0x28\n  _stext+0x11c/0x284\n  ____do_softirq+0xc/0x14\n  call_on_irq_stack+0x24/0x34\n  do_softirq_own_stack+0x18/0x20\n  do_softirq+0x74/0x7c\n  __local_bh_enable_ip+0xa0/0xa4\n  _ieee80211_wake_txqs+0x3b0/0x4b8\n  __ieee80211_wake_queue+0x12c/0x168\n  ieee80211_add_pending_skbs+0xec/0x138\n  ieee80211_sta_ps_deliver_wakeup+0x2a4/0x480\n  ieee80211_mps_sta_status_update.part.0+0xd8/0x11c\n  ieee80211_mps_sta_status_update+0x18/0x24\n  sta_apply_parameters+0x3bc/0x4c0\n  ieee80211_change_station+0x1b8/0x2dc\n  nl80211_set_station+0x444/0x49c\n  genl_family_rcv_msg_doit.isra.0+0xa4/0xfc\n  genl_rcv_msg+0x1b0/0x244\n  netlink_rcv_skb+0x38/0x10c\n  genl_rcv+0x34/0x48\n  netlink_unicast+0x254/0x2bc\n  netlink_sendmsg+0x190/0x3b4\n  ____sys_sendmsg+0x1e8/0x218\n  ___sys_sendmsg+0x68/0x8c\n  __sys_sendmsg+0x44/0x84\n  __arm64_sys_sendmsg+0x20/0x28\n  do_el0_svc+0x6c/0xe8\n  el0_svc+0x14/0x48\n  el0t_64_sync_handler+0xb0/0xb4\n  el0t_64_sync+0x14c/0x150\r\n\r\nUsing spin_lock_bh()/spin_unlock_bh() instead prevents softirq to raise\non the same CPU that is holding the lock.(CVE-2024-40912)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: iwlwifi: mvm: check n_ssids before accessing the ssids\r\n\r\nIn some versions of cfg80211, the ssids poinet might be a valid one even\nthough n_ssids is 0. Accessing the pointer in this case will cuase an\nout-of-bound access. Fix this by checking n_ssids first.(CVE-2024-40929)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/exynos/vidi: fix memory leak in .get_modes()\r\n\r\nThe duplicated EDID is never freed. Fix it.(CVE-2024-40932)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: iwlwifi: mvm: don\u0026apos;t read past the mfuart notifcation\r\n\r\nIn case the firmware sends a notification that claims it has more data\nthan it has, we will read past that was allocated for the notification.\nRemove the print of the buffer, we won\u0026apos;t see it by default. If needed,\nwe can see the content with tracing.\r\n\r\nThis was reported by KFENCE.(CVE-2024-40941)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nocfs2: fix races between hole punching and AIO+DIO\r\n\r\nAfter commit \u0026quot;ocfs2: return real error code in ocfs2_dio_wr_get_block\u0026quot;,\nfstests/generic/300 become from always failed to sometimes failed:\r\n\r\n========================================================================\n[  473.293420 ] run fstests generic/300\r\n\r\n[  475.296983 ] JBD2: Ignoring recovery information on journal\n[  475.302473 ] ocfs2: Mounting device (253,1) on (node local, slot 0) with ordered data mode.\n[  494.290998 ] OCFS2: ERROR (device dm-1): ocfs2_change_extent_flag: Owner 5668 has an extent at cpos 78723 which can no longer be found\n[  494.291609 ] On-disk corruption discovered. Please run fsck.ocfs2 once the filesystem is unmounted.\n[  494.292018 ] OCFS2: File system is now read-only.\n[  494.292224 ] (kworker/19:11,2628,19):ocfs2_mark_extent_written:5272 ERROR: status = -30\n[  494.292602 ] (kworker/19:11,2628,19):ocfs2_dio_end_io_write:2374 ERROR: status = -3\nfio: io_u error on file /mnt/scratch/racer: Read-only file system: write offset=460849152, buflen=131072\n=========================================================================\r\n\r\nIn __blockdev_direct_IO, ocfs2_dio_wr_get_block is called to add unwritten\nextents to a list.  extents are also inserted into extent tree in\nocfs2_write_begin_nolock.  Then another thread call fallocate to puch a\nhole at one of the unwritten extent.  The extent at cpos was removed by\nocfs2_remove_extent().  At end io worker thread, ocfs2_search_extent_list\nfound there is no such extent at the cpos.\r\n\r\n    T1                        T2                T3\n                              inode lock\n                                ...\n                                insert extents\n                                ...\n                              inode unlock\nocfs2_fallocate\n __ocfs2_change_file_space\n  inode lock\n  lock ip_alloc_sem\n  ocfs2_remove_inode_range inode\n   ocfs2_remove_btree_range\n    ocfs2_remove_extent\n    ^---remove the extent at cpos 78723\n  ...\n  unlock ip_alloc_sem\n  inode unlock\n                                       ocfs2_dio_end_io\n                                        ocfs2_dio_end_io_write\n                                         lock ip_alloc_sem\n                                         ocfs2_mark_extent_written\n                                          ocfs2_change_extent_flag\n                                           ocfs2_search_extent_list\n                                           ^---failed to find extent\n                                          ...\n                                          unlock ip_alloc_sem\r\n\r\nIn most filesystems, fallocate is not compatible with racing with AIO+DIO,\nso fix it by adding to wait for all dio before fallocate/punch_hole like\next4.(CVE-2024-40943)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nMIPS: Octeon: Add PCIe link status check\r\n\r\nThe standard PCIe configuration read-write interface is used to\naccess the configuration space of the peripheral PCIe devices\nof the mips processor after the PCIe link surprise down, it can\ngenerate kernel panic caused by \u0026quot;Data bus error\u0026quot;. So it is\nnecessary to add PCIe link status check for system protection.\nWhen the PCIe link is down or in training, assigning a value\nof 0 to the configuration address can prevent read-write behavior\nto the configuration space of peripheral PCIe devices, thereby\npreventing kernel panic.(CVE-2024-40968)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npowerpc/pseries: Enforce hcall result buffer validity and size\r\n\r\nplpar_hcall(), plpar_hcall9(), and related functions expect callers to\nprovide valid result buffers of certain minimum size. Currently this\nis communicated only through comments in the code and the compiler has\nno idea.\r\n\r\nFor example, if I write a bug like this:\r\n\r\n  long retbuf[PLPAR_HCALL_BUFSIZE]; // should be PLPAR_HCALL9_BUFSIZE\n  plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, ...);\r\n\r\nThis compiles with no diagnostics emitted, but likely results in stack\ncorruption at runtime when plpar_hcall9() stores results past the end\nof the array. (To be clear this is a contrived example and I have not\nfound a real instance yet.)\r\n\r\nTo make this class of error less likely, we can use explicitly-sized\narray parameters instead of pointers in the declarations for the hcall\nAPIs. When compiled with -Warray-bounds[1], the code above now\nprovokes a diagnostic like this:\r\n\r\nerror: array argument is too small;\nis of size 32, callee requires at least 72 [-Werror,-Warray-bounds]\n   60 |                 plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf,\n      |                 ^                                   ~~~~~~\r\n\r\n[1] Enabled for LLVM builds but not GCC for now. See commit\n    0da6e5fd6c37 (\u0026quot;gcc: disable \u0026apos;-Warray-bounds\u0026apos; for gcc-13 too\u0026quot;) and\n    related changes.(CVE-2024-40974)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nACPICA: Revert \u0026quot;ACPICA: avoid Info: mapping multiple BARs. Your kernel is fine.\u0026quot;\r\n\r\nUndo the modifications made in commit d410ee5109a1 (\u0026quot;ACPICA: avoid\n\u0026quot;Info: mapping multiple BARs. Your kernel is fine.\u0026quot;\u0026quot;). The initial\npurpose of this commit was to stop memory mappings for operation\nregions from overlapping page boundaries, as it can trigger warnings\nif different page attributes are present.\r\n\r\nHowever, it was found that when this situation arises, mapping\ncontinues until the boundary\u0026apos;s end, but there is still an attempt to\nread/write the entire length of the map, leading to a NULL pointer\ndeference. For example, if a four-byte mapping request is made but\nonly one byte is mapped because it hits the current page boundary\u0026apos;s\nend, a four-byte read/write attempt is still made, resulting in a NULL\npointer deference.\r\n\r\nInstead, map the entire length, as the ACPI specification does not\nmandate that it must be within the same page boundary. It is\npermissible for it to be mapped across different regions.(CVE-2024-40984)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: fix UBSAN warning in kv_dpm.c\r\n\r\nAdds bounds check for sumo_vid_mapping_entry.(CVE-2024-40987)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetpoll: Fix race condition in netpoll_owner_active\r\n\r\nKCSAN detected a race condition in netpoll:\r\n\r\n\tBUG: KCSAN: data-race in net_rx_action / netpoll_send_skb\n\twrite (marked) to 0xffff8881164168b0 of 4 bytes by interrupt on cpu 10:\n\tnet_rx_action (./include/linux/netpoll.h:90 net/core/dev.c:6712 net/core/dev.c:6822)\n\u0026lt;snip\u0026gt;\n\tread to 0xffff8881164168b0 of 4 bytes by task 1 on cpu 2:\n\tnetpoll_send_skb (net/core/netpoll.c:319 net/core/netpoll.c:345 net/core/netpoll.c:393)\n\tnetpoll_send_udp (net/core/netpoll.c:?)\n\u0026lt;snip\u0026gt;\n\tvalue changed: 0x0000000a -\u0026gt; 0xffffffff\r\n\r\nThis happens because netpoll_owner_active() needs to check if the\ncurrent CPU is the owner of the lock, touching napi-\u0026gt;poll_owner\nnon atomically. The -\u0026gt;poll_owner field contains the current CPU holding\nthe lock.\r\n\r\nUse an atomic read to check if the poll owner is the current CPU.(CVE-2024-41005)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ntcp: avoid too many retransmit packets\r\n\r\nIf a TCP socket is using TCP_USER_TIMEOUT, and the other peer\nretracted its window to zero, tcp_retransmit_timer() can\nretransmit a packet every two jiffies (2 ms for HZ=1000),\nfor about 4 minutes after TCP_USER_TIMEOUT has \u0026apos;expired\u0026apos;.\r\n\r\nThe fix is to make sure tcp_rtx_probe0_timed_out() takes\nicsk-\u0026gt;icsk_user_timeout into account.\r\n\r\nBefore blamed commit, the socket would not timeout after\nicsk-\u0026gt;icsk_user_timeout, but would use standard exponential\nbackoff for the retransmits.\r\n\r\nAlso worth noting that before commit e89688e3e978 (\u0026quot;net: tcp:\nfix unexcepted socket die when snd_wnd is 0\u0026quot;), the issue\nwould last 2 minutes instead of 4.(CVE-2024-41007)",
  "id": "OESA-2024-1895",
  "modified": "2026-08-06T11:07:21Z",
  "published": "2024-07-26T11:07:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-1895"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47612"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48775"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48788"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48838"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48855"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48856"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48865"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38589"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39493"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39494"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39499"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40904"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40912"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40929"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40932"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40941"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40943"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40968"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40974"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40984"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-40987"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41005"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-41007"
    }
  ],
  "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-47612",
    "CVE-2022-48775",
    "CVE-2022-48788",
    "CVE-2022-48838",
    "CVE-2022-48855",
    "CVE-2022-48856",
    "CVE-2022-48865",
    "CVE-2024-38589",
    "CVE-2024-39493",
    "CVE-2024-39494",
    "CVE-2024-39499",
    "CVE-2024-40904",
    "CVE-2024-40912",
    "CVE-2024-40929",
    "CVE-2024-40932",
    "CVE-2024-40941",
    "CVE-2024-40943",
    "CVE-2024-40968",
    "CVE-2024-40974",
    "CVE-2024-40984",
    "CVE-2024-40987",
    "CVE-2024-41005",
    "CVE-2024-41007"
  ]
}

SUSE-SU-2024:2894-1

Vulnerability from csaf_suse - Published: 2024-08-13 14:07 - Updated: 2026-09-20 16:02

Summary

Security update for the Linux Kernel

Severity

Important

Scope

310 vulnerabilities in this advisory, including CVE-2022-48788.

CVE-2022-48788

5.3 (Medium)


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

Recommended: 50 products

Open the full advisory

SUSE-SU-2024:2902-1

Vulnerability from csaf_suse - Published: 2024-08-14 07:25 - Updated: 2026-09-20 16:03

Summary

Security update for the Linux Kernel

Severity

Important

Scope

182 vulnerabilities in this advisory, including CVE-2022-48788.

CVE-2022-48788

5.3 (Medium)


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

Recommended: 4 products

Open the full advisory

SUSE-SU-2024:2929-1

Vulnerability from csaf_suse - Published: 2024-08-15 09:31 - Updated: 2024-08-15 09:31

Summary

Security update for the Linux Kernel

Severity

Important

Scope

194 vulnerabilities in this advisory, including CVE-2022-48788.

CVE-2022-48788

5.3 (Medium)


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

Recommended: 139 products

Open the full advisory

SUSE-SU-2024:2939-1

Vulnerability from csaf_suse - Published: 2024-08-16 07:05 - Updated: 2026-09-20 16:03

Summary

Security update for the Linux Kernel

Severity

Important

Scope

531 vulnerabilities in this advisory, including CVE-2022-48788.

CVE-2022-48788

5.3 (Medium)


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

Recommended: 256 products

Open the full advisory

SUSE-SU-2024:2947-1

Vulnerability from csaf_suse - Published: 2024-08-16 13:46 - Updated: 2026-09-20 16:03

Summary

Security update for the Linux Kernel

Severity

Important

Scope

310 vulnerabilities in this advisory, including CVE-2022-48788.

CVE-2022-48788

5.3 (Medium)


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

Recommended: 59 products

Open the full advisory

SUSE-SU-2024:3225-1

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

Summary

Security update for the Linux Kernel

Severity

Important

Scope

51 vulnerabilities in this advisory, including CVE-2022-48788.

CVE-2022-48788

5.3 (Medium)


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

Recommended: 4 products

Open the full advisory

SUSE-SU-2024:3249-1

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

Summary

Security update for the Linux Kernel

Severity

Important

Scope

62 vulnerabilities in this advisory, including CVE-2022-48788.

CVE-2022-48788

5.3 (Medium)


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

Recommended: 207 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-2022-48788 (GCVE-0-2022-48788)

OESA-2024-1895 (CVE-2021-47612)

Tags

Sightings

Nomenclature

Related by attack behaviour