Vulnerability-Lookup

CVE-2023-52853 (GCVE-0-2023-52853)

Vulnerability from cvelistv5 – Published: 2024-05-21 15:31 – Updated: 2026-05-11 19:34

Title

hid: cp2112: Fix duplicate workqueue initialization

Summary

In the Linux kernel, the following vulnerability has been resolved: hid: cp2112: Fix duplicate workqueue initialization Previously the cp2112 driver called INIT_DELAYED_WORK within cp2112_gpio_irq_startup, resulting in duplicate initilizations of the workqueue on subsequent IRQ startups following an initial request. This resulted in a warning in set_work_data in workqueue.c, as well as a rare NULL dereference within process_one_work in workqueue.c. Initialize the workqueue within _probe instead.

Severity

No CVSS data available.

SSVC

Exploitation: none Automatable: no Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2024-05-22 18:51 UTC

Assigner

Linux mitre root

References

8 references

URL	Tags
https://git.kernel.org/stable/c/df0daac2709473531…
https://git.kernel.org/stable/c/727203e6e7e7020e1…
https://git.kernel.org/stable/c/3d959406c8fff2334…
https://git.kernel.org/stable/c/012d0c66f9392a992…
https://git.kernel.org/stable/c/bafb12b629b7c3ad5…
https://git.kernel.org/stable/c/fb5718bc67337dde1…
https://git.kernel.org/stable/c/eb1121fac7986b309…
https://git.kernel.org/stable/c/e3c2d2d144c082dd7…

Impacted products

2 products

Vendor	Product	Version	CPE status
Linux	Linux	Affected: 13de9cca514ed63604263cad87ca8cb36e9b6489 , < df0daac2709473531d6a3472997cc65301ac06d6 (git) Affected: 13de9cca514ed63604263cad87ca8cb36e9b6489 , < 727203e6e7e7020e1246fc1628cbdb8d90177819 (git) Affected: 13de9cca514ed63604263cad87ca8cb36e9b6489 , < 3d959406c8fff2334d83d0c352d54fd6f5b2e7cd (git) Affected: 13de9cca514ed63604263cad87ca8cb36e9b6489 , < 012d0c66f9392a99232ac28217229f32dd3a70cf (git) Affected: 13de9cca514ed63604263cad87ca8cb36e9b6489 , < bafb12b629b7c3ad59812dd1ac1b0618062e0e38 (git) Affected: 13de9cca514ed63604263cad87ca8cb36e9b6489 , < fb5718bc67337dde1528661f419ffcf275757592 (git) Affected: 13de9cca514ed63604263cad87ca8cb36e9b6489 , < eb1121fac7986b30915ba20c5a04cc01fdcf160c (git) Affected: 13de9cca514ed63604263cad87ca8cb36e9b6489 , < e3c2d2d144c082dd71596953193adf9891491f42 (git)	guessed
Linux	Linux	Affected: 4.10 Unaffected: 0 , < 4.10 (semver) Unaffected: 4.19.299 , ≤ 4.19.* (semver) Unaffected: 5.4.261 , ≤ 5.4.* (semver) Unaffected: 5.10.201 , ≤ 5.10.* (semver) Unaffected: 5.15.139 , ≤ 5.15.* (semver) Unaffected: 6.1.63 , ≤ 6.1.* (semver) Unaffected: 6.5.12 , ≤ 6.5.* (semver) Unaffected: 6.6.2 , ≤ 6.6.* (semver) Unaffected: 6.7 , ≤ * (original_commit_for_fix)	guessed

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2023-52853",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-05-22T18:51:33.652573Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2024-06-04T17:23:57.826Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      },
      {
        "providerMetadata": {
          "dateUpdated": "2024-08-02T23:11:36.048Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/df0daac2709473531d6a3472997cc65301ac06d6"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/727203e6e7e7020e1246fc1628cbdb8d90177819"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/3d959406c8fff2334d83d0c352d54fd6f5b2e7cd"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/012d0c66f9392a99232ac28217229f32dd3a70cf"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/bafb12b629b7c3ad59812dd1ac1b0618062e0e38"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/fb5718bc67337dde1528661f419ffcf275757592"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/eb1121fac7986b30915ba20c5a04cc01fdcf160c"
          },
          {
            "tags": [
              "x_transferred"
            ],
            "url": "https://git.kernel.org/stable/c/e3c2d2d144c082dd71596953193adf9891491f42"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "product": "Linux",
          "programFiles": [
            "drivers/hid/hid-cp2112.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "lessThan": "df0daac2709473531d6a3472997cc65301ac06d6",
              "status": "affected",
              "version": "13de9cca514ed63604263cad87ca8cb36e9b6489",
              "versionType": "git"
            },
            {
              "lessThan": "727203e6e7e7020e1246fc1628cbdb8d90177819",
              "status": "affected",
              "version": "13de9cca514ed63604263cad87ca8cb36e9b6489",
              "versionType": "git"
            },
            {
              "lessThan": "3d959406c8fff2334d83d0c352d54fd6f5b2e7cd",
              "status": "affected",
              "version": "13de9cca514ed63604263cad87ca8cb36e9b6489",
              "versionType": "git"
            },
            {
              "lessThan": "012d0c66f9392a99232ac28217229f32dd3a70cf",
              "status": "affected",
              "version": "13de9cca514ed63604263cad87ca8cb36e9b6489",
              "versionType": "git"
            },
            {
              "lessThan": "bafb12b629b7c3ad59812dd1ac1b0618062e0e38",
              "status": "affected",
              "version": "13de9cca514ed63604263cad87ca8cb36e9b6489",
              "versionType": "git"
            },
            {
              "lessThan": "fb5718bc67337dde1528661f419ffcf275757592",
              "status": "affected",
              "version": "13de9cca514ed63604263cad87ca8cb36e9b6489",
              "versionType": "git"
            },
            {
              "lessThan": "eb1121fac7986b30915ba20c5a04cc01fdcf160c",
              "status": "affected",
              "version": "13de9cca514ed63604263cad87ca8cb36e9b6489",
              "versionType": "git"
            },
            {
              "lessThan": "e3c2d2d144c082dd71596953193adf9891491f42",
              "status": "affected",
              "version": "13de9cca514ed63604263cad87ca8cb36e9b6489",
              "versionType": "git"
            }
          ]
        },
        {
          "defaultStatus": "affected",
          "product": "Linux",
          "programFiles": [
            "drivers/hid/hid-cp2112.c"
          ],
          "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
          "vendor": "Linux",
          "versions": [
            {
              "status": "affected",
              "version": "4.10"
            },
            {
              "lessThan": "4.10",
              "status": "unaffected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "4.19.*",
              "status": "unaffected",
              "version": "4.19.299",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.4.*",
              "status": "unaffected",
              "version": "5.4.261",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.10.*",
              "status": "unaffected",
              "version": "5.10.201",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "5.15.*",
              "status": "unaffected",
              "version": "5.15.139",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.1.*",
              "status": "unaffected",
              "version": "6.1.63",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.5.*",
              "status": "unaffected",
              "version": "6.5.12",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "6.6.*",
              "status": "unaffected",
              "version": "6.6.2",
              "versionType": "semver"
            },
            {
              "lessThanOrEqual": "*",
              "status": "unaffected",
              "version": "6.7",
              "versionType": "original_commit_for_fix"
            }
          ]
        }
      ],
      "cpeApplicability": [
        {
          "nodes": [
            {
              "cpeMatch": [
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "4.19.299",
                  "versionStartIncluding": "4.10",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.4.261",
                  "versionStartIncluding": "4.10",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.10.201",
                  "versionStartIncluding": "4.10",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "5.15.139",
                  "versionStartIncluding": "4.10",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.1.63",
                  "versionStartIncluding": "4.10",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.5.12",
                  "versionStartIncluding": "4.10",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.6.2",
                  "versionStartIncluding": "4.10",
                  "vulnerable": true
                },
                {
                  "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                  "versionEndExcluding": "6.7",
                  "versionStartIncluding": "4.10",
                  "vulnerable": true
                }
              ],
              "negate": false,
              "operator": "OR"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nhid: cp2112: Fix duplicate workqueue initialization\n\nPreviously the cp2112 driver called INIT_DELAYED_WORK within\ncp2112_gpio_irq_startup, resulting in duplicate initilizations of the\nworkqueue on subsequent IRQ startups following an initial request. This\nresulted in a warning in set_work_data in workqueue.c, as well as a rare\nNULL dereference within process_one_work in workqueue.c.\n\nInitialize the workqueue within _probe instead."
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-05-11T19:34:17.331Z",
        "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "shortName": "Linux"
      },
      "references": [
        {
          "url": "https://git.kernel.org/stable/c/df0daac2709473531d6a3472997cc65301ac06d6"
        },
        {
          "url": "https://git.kernel.org/stable/c/727203e6e7e7020e1246fc1628cbdb8d90177819"
        },
        {
          "url": "https://git.kernel.org/stable/c/3d959406c8fff2334d83d0c352d54fd6f5b2e7cd"
        },
        {
          "url": "https://git.kernel.org/stable/c/012d0c66f9392a99232ac28217229f32dd3a70cf"
        },
        {
          "url": "https://git.kernel.org/stable/c/bafb12b629b7c3ad59812dd1ac1b0618062e0e38"
        },
        {
          "url": "https://git.kernel.org/stable/c/fb5718bc67337dde1528661f419ffcf275757592"
        },
        {
          "url": "https://git.kernel.org/stable/c/eb1121fac7986b30915ba20c5a04cc01fdcf160c"
        },
        {
          "url": "https://git.kernel.org/stable/c/e3c2d2d144c082dd71596953193adf9891491f42"
        }
      ],
      "title": "hid: cp2112: Fix duplicate workqueue initialization",
      "x_generator": {
        "engine": "bippy-1.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
    "assignerShortName": "Linux",
    "cveId": "CVE-2023-52853",
    "datePublished": "2024-05-21T15:31:48.571Z",
    "dateReserved": "2024-05-21T15:19:24.256Z",
    "dateUpdated": "2026-05-11T19:34:17.331Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2023-52853",
      "date": "2026-09-20",
      "epss": "0.0024",
      "percentile": "0.15377"
    },
    "fkie_nvd": {
      "descriptions": [
        {
          "lang": "en",
          "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nhid: cp2112: Fix duplicate workqueue initialization\n\nPreviously the cp2112 driver called INIT_DELAYED_WORK within\ncp2112_gpio_irq_startup, resulting in duplicate initilizations of the\nworkqueue on subsequent IRQ startups following an initial request. This\nresulted in a warning in set_work_data in workqueue.c, as well as a rare\nNULL dereference within process_one_work in workqueue.c.\n\nInitialize the workqueue within _probe instead."
        },
        {
          "lang": "es",
          "value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: hid: cp2112: corrige la inicializaci\u00f3n duplicada de la cola de trabajo. Anteriormente, el controlador cp2112 llamaba INIT_DELAYED_WORK dentro de cp2112_gpio_irq_startup, lo que generaba inicializaciones duplicadas de la cola de trabajo en inicios IRQ posteriores despu\u00e9s de una solicitud inicial. Esto result\u00f3 en una advertencia en set_work_data en workqueue.c, as\u00ed como en una rara desreferencia NULL dentro de process_one_work en workqueue.c. En su lugar, inicialice la cola de trabajo dentro de _probe."
        }
      ],
      "id": "CVE-2023-52853",
      "lastModified": "2024-11-21T08:40:43.527",
      "published": "2024-05-21T16:15:22.303",
      "references": [
        {
          "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
          "url": "https://git.kernel.org/stable/c/012d0c66f9392a99232ac28217229f32dd3a70cf"
        },
        {
          "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
          "url": "https://git.kernel.org/stable/c/3d959406c8fff2334d83d0c352d54fd6f5b2e7cd"
        },
        {
          "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
          "url": "https://git.kernel.org/stable/c/727203e6e7e7020e1246fc1628cbdb8d90177819"
        },
        {
          "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
          "url": "https://git.kernel.org/stable/c/bafb12b629b7c3ad59812dd1ac1b0618062e0e38"
        },
        {
          "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
          "url": "https://git.kernel.org/stable/c/df0daac2709473531d6a3472997cc65301ac06d6"
        },
        {
          "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
          "url": "https://git.kernel.org/stable/c/e3c2d2d144c082dd71596953193adf9891491f42"
        },
        {
          "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
          "url": "https://git.kernel.org/stable/c/eb1121fac7986b30915ba20c5a04cc01fdcf160c"
        },
        {
          "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
          "url": "https://git.kernel.org/stable/c/fb5718bc67337dde1528661f419ffcf275757592"
        },
        {
          "source": "af854a3a-2127-422b-91ae-364da2661108",
          "url": "https://git.kernel.org/stable/c/012d0c66f9392a99232ac28217229f32dd3a70cf"
        },
        {
          "source": "af854a3a-2127-422b-91ae-364da2661108",
          "url": "https://git.kernel.org/stable/c/3d959406c8fff2334d83d0c352d54fd6f5b2e7cd"
        },
        {
          "source": "af854a3a-2127-422b-91ae-364da2661108",
          "url": "https://git.kernel.org/stable/c/727203e6e7e7020e1246fc1628cbdb8d90177819"
        },
        {
          "source": "af854a3a-2127-422b-91ae-364da2661108",
          "url": "https://git.kernel.org/stable/c/bafb12b629b7c3ad59812dd1ac1b0618062e0e38"
        },
        {
          "source": "af854a3a-2127-422b-91ae-364da2661108",
          "url": "https://git.kernel.org/stable/c/df0daac2709473531d6a3472997cc65301ac06d6"
        },
        {
          "source": "af854a3a-2127-422b-91ae-364da2661108",
          "url": "https://git.kernel.org/stable/c/e3c2d2d144c082dd71596953193adf9891491f42"
        },
        {
          "source": "af854a3a-2127-422b-91ae-364da2661108",
          "url": "https://git.kernel.org/stable/c/eb1121fac7986b30915ba20c5a04cc01fdcf160c"
        },
        {
          "source": "af854a3a-2127-422b-91ae-364da2661108",
          "url": "https://git.kernel.org/stable/c/fb5718bc67337dde1528661f419ffcf275757592"
        }
      ],
      "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "vulnStatus": "Awaiting Analysis"
    },
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "defaultStatus": "unaffected",
                "product": "Linux",
                "programFiles": [
                  "drivers/hid/hid-cp2112.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "lessThan": "df0daac2709473531d6a3472997cc65301ac06d6",
                    "status": "affected",
                    "version": "13de9cca514ed63604263cad87ca8cb36e9b6489",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "727203e6e7e7020e1246fc1628cbdb8d90177819",
                    "status": "affected",
                    "version": "13de9cca514ed63604263cad87ca8cb36e9b6489",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "3d959406c8fff2334d83d0c352d54fd6f5b2e7cd",
                    "status": "affected",
                    "version": "13de9cca514ed63604263cad87ca8cb36e9b6489",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "012d0c66f9392a99232ac28217229f32dd3a70cf",
                    "status": "affected",
                    "version": "13de9cca514ed63604263cad87ca8cb36e9b6489",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "bafb12b629b7c3ad59812dd1ac1b0618062e0e38",
                    "status": "affected",
                    "version": "13de9cca514ed63604263cad87ca8cb36e9b6489",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "fb5718bc67337dde1528661f419ffcf275757592",
                    "status": "affected",
                    "version": "13de9cca514ed63604263cad87ca8cb36e9b6489",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "eb1121fac7986b30915ba20c5a04cc01fdcf160c",
                    "status": "affected",
                    "version": "13de9cca514ed63604263cad87ca8cb36e9b6489",
                    "versionType": "git"
                  },
                  {
                    "lessThan": "e3c2d2d144c082dd71596953193adf9891491f42",
                    "status": "affected",
                    "version": "13de9cca514ed63604263cad87ca8cb36e9b6489",
                    "versionType": "git"
                  }
                ]
              },
              {
                "defaultStatus": "affected",
                "product": "Linux",
                "programFiles": [
                  "drivers/hid/hid-cp2112.c"
                ],
                "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
                "vendor": "Linux",
                "versions": [
                  {
                    "status": "affected",
                    "version": "4.10"
                  },
                  {
                    "lessThan": "4.10",
                    "status": "unaffected",
                    "version": "0",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "4.19.*",
                    "status": "unaffected",
                    "version": "4.19.299",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "5.4.*",
                    "status": "unaffected",
                    "version": "5.4.261",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "5.10.*",
                    "status": "unaffected",
                    "version": "5.10.201",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "5.15.*",
                    "status": "unaffected",
                    "version": "5.15.139",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.1.*",
                    "status": "unaffected",
                    "version": "6.1.63",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.5.*",
                    "status": "unaffected",
                    "version": "6.5.12",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "6.6.*",
                    "status": "unaffected",
                    "version": "6.6.2",
                    "versionType": "semver"
                  },
                  {
                    "lessThanOrEqual": "*",
                    "status": "unaffected",
                    "version": "6.7",
                    "versionType": "original_commit_for_fix"
                  }
                ]
              }
            ],
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
          }
        ],
        "configurations": [
          {
            "nodes": [
              {
                "cpeMatch": [
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "247685A7-0C82-4EBA-AAC2-1A30A4589841",
                    "versionEndExcluding": "4.19.299",
                    "versionStartIncluding": "4.10",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "286E50BB-5A21-49BA-A6E5-526C72ADFE34",
                    "versionEndExcluding": "5.4.261",
                    "versionStartIncluding": "4.20",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "AF1ADC4E-CCC4-498A-876F-5136DDD36C1D",
                    "versionEndExcluding": "5.10.201",
                    "versionStartIncluding": "5.5",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "81424D14-B38F-47B3-A1B8-BC3B60BB96EA",
                    "versionEndExcluding": "5.15.139",
                    "versionStartIncluding": "5.11",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "80E1EA7E-2788-466C-9FFB-34AFA1B052F0",
                    "versionEndExcluding": "6.1.63",
                    "versionStartIncluding": "5.16",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "825F64D9-E99F-49AA-8A7B-EF7C2965C5B2",
                    "versionEndExcluding": "6.5.12",
                    "versionStartIncluding": "6.2",
                    "vulnerable": true
                  },
                  {
                    "criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "4CBFF885-A4D3-4F21-B6FD-4D770034C048",
                    "versionEndExcluding": "6.6.2",
                    "versionStartIncluding": "6.6",
                    "vulnerable": true
                  }
                ],
                "negate": false,
                "operator": "OR"
              }
            ]
          }
        ],
        "cveTags": [],
        "descriptions": [
          {
            "lang": "en",
            "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nhid: cp2112: Fix duplicate workqueue initialization\n\nPreviously the cp2112 driver called INIT_DELAYED_WORK within\ncp2112_gpio_irq_startup, resulting in duplicate initilizations of the\nworkqueue on subsequent IRQ startups following an initial request. This\nresulted in a warning in set_work_data in workqueue.c, as well as a rare\nNULL dereference within process_one_work in workqueue.c.\n\nInitialize the workqueue within _probe instead."
          },
          {
            "lang": "es",
            "value": "En el kernel de Linux, se resolvi\u00f3 la siguiente vulnerabilidad: hid: cp2112: corrige la inicializaci\u00f3n duplicada de la cola de trabajo. Anteriormente, el controlador cp2112 llamaba INIT_DELAYED_WORK dentro de cp2112_gpio_irq_startup, lo que generaba inicializaciones duplicadas de la cola de trabajo en inicios IRQ posteriores despu\u00e9s de una solicitud inicial. Esto result\u00f3 en una advertencia en set_work_data en workqueue.c, as\u00ed como en una rara desreferencia NULL dentro de process_one_work en workqueue.c. En su lugar, inicialice la cola de trabajo dentro de _probe."
          }
        ],
        "id": "CVE-2023-52853",
        "lastModified": "2026-06-17T06:43:44.293",
        "metrics": {
          "cvssMetricV31": [
            {
              "cvssData": {
                "attackComplexity": "LOW",
                "attackVector": "LOCAL",
                "availabilityImpact": "HIGH",
                "baseScore": 5.5,
                "baseSeverity": "MEDIUM",
                "confidentialityImpact": "NONE",
                "integrityImpact": "NONE",
                "privilegesRequired": "LOW",
                "scope": "UNCHANGED",
                "userInteraction": "NONE",
                "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
                "version": "3.1"
              },
              "exploitabilityScore": 1.8,
              "impactScore": 3.6,
              "source": "nvd@nist.gov",
              "type": "Primary"
            }
          ],
          "ssvcV203": [
            {
              "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "ssvcData": {
                "id": "CVE-2023-52853",
                "options": [
                  {
                    "exploitation": "none"
                  },
                  {
                    "automatable": "no"
                  },
                  {
                    "technicalImpact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-05-22T18:51:33.652573Z",
                "version": "2.0.3"
              }
            }
          ]
        },
        "published": "2024-05-21T16:15:22.303",
        "references": [
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/012d0c66f9392a99232ac28217229f32dd3a70cf"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/3d959406c8fff2334d83d0c352d54fd6f5b2e7cd"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/727203e6e7e7020e1246fc1628cbdb8d90177819"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/bafb12b629b7c3ad59812dd1ac1b0618062e0e38"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/df0daac2709473531d6a3472997cc65301ac06d6"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/e3c2d2d144c082dd71596953193adf9891491f42"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/eb1121fac7986b30915ba20c5a04cc01fdcf160c"
          },
          {
            "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/fb5718bc67337dde1528661f419ffcf275757592"
          },
          {
            "source": "af854a3a-2127-422b-91ae-364da2661108",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/012d0c66f9392a99232ac28217229f32dd3a70cf"
          },
          {
            "source": "af854a3a-2127-422b-91ae-364da2661108",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/3d959406c8fff2334d83d0c352d54fd6f5b2e7cd"
          },
          {
            "source": "af854a3a-2127-422b-91ae-364da2661108",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/727203e6e7e7020e1246fc1628cbdb8d90177819"
          },
          {
            "source": "af854a3a-2127-422b-91ae-364da2661108",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/bafb12b629b7c3ad59812dd1ac1b0618062e0e38"
          },
          {
            "source": "af854a3a-2127-422b-91ae-364da2661108",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/df0daac2709473531d6a3472997cc65301ac06d6"
          },
          {
            "source": "af854a3a-2127-422b-91ae-364da2661108",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/e3c2d2d144c082dd71596953193adf9891491f42"
          },
          {
            "source": "af854a3a-2127-422b-91ae-364da2661108",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/eb1121fac7986b30915ba20c5a04cc01fdcf160c"
          },
          {
            "source": "af854a3a-2127-422b-91ae-364da2661108",
            "tags": [
              "Patch"
            ],
            "url": "https://git.kernel.org/stable/c/fb5718bc67337dde1528661f419ffcf275757592"
          }
        ],
        "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "vulnStatus": "Analyzed",
        "weaknesses": [
          {
            "description": [
              {
                "lang": "en",
                "value": "CWE-476"
              }
            ],
            "source": "nvd@nist.gov",
            "type": "Primary"
          }
        ]
      }
    },
    "redhat_vex": {
      "aggregate_severity": "Low",
      "current_release_date": "2025-11-21T10:49:23+00:00",
      "cve": "CVE-2023-52853",
      "id": "CVE-2023-52853",
      "initial_release_date": "2023-01-01T00:00:00+00:00",
      "product_status:known_not_affected": "198",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "kernel: hid: cp2112: Fix duplicate workqueue initialization",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2023/cve-2023-52853.json",
      "version": "3"
    },
    "suse_vex": {
      "aggregate_severity": "moderate",
      "current_release_date": "2026-08-25T02:34:55Z",
      "cve": "CVE-2023-52853",
      "id": "CVE-2023-52853",
      "initial_release_date": "2024-05-23T02:56:41Z",
      "product_status:known_affected": "446",
      "product_status:known_not_affected": "44",
      "product_status:recommended": "861",
      "source": "SUSE CSAF VEX",
      "status": "interim",
      "title": "SUSE CVE CVE-2023-52853",
      "url": "https://ftp.suse.com/pub/projects/security/csaf-vex/cve-2023-52853.json",
      "version": "103"
    },
    "vulnrichment": {
      "containers": {
        "adp": [
          {
            "providerMetadata": {
              "dateUpdated": "2024-08-02T23:11:36.048Z",
              "orgId": "af854a3a-2127-422b-91ae-364da2661108",
              "shortName": "CVE"
            },
            "references": [
              {
                "tags": [
                  "x_transferred"
                ],
                "url": "https://git.kernel.org/stable/c/df0daac2709473531d6a3472997cc65301ac06d6"
              },
              {
                "tags": [
                  "x_transferred"
                ],
                "url": "https://git.kernel.org/stable/c/727203e6e7e7020e1246fc1628cbdb8d90177819"
              },
              {
                "tags": [
                  "x_transferred"
                ],
                "url": "https://git.kernel.org/stable/c/3d959406c8fff2334d83d0c352d54fd6f5b2e7cd"
              },
              {
                "tags": [
                  "x_transferred"
                ],
                "url": "https://git.kernel.org/stable/c/012d0c66f9392a99232ac28217229f32dd3a70cf"
              },
              {
                "tags": [
                  "x_transferred"
                ],
                "url": "https://git.kernel.org/stable/c/bafb12b629b7c3ad59812dd1ac1b0618062e0e38"
              },
              {
                "tags": [
                  "x_transferred"
                ],
                "url": "https://git.kernel.org/stable/c/fb5718bc67337dde1528661f419ffcf275757592"
              },
              {
                "tags": [
                  "x_transferred"
                ],
                "url": "https://git.kernel.org/stable/c/eb1121fac7986b30915ba20c5a04cc01fdcf160c"
              },
              {
                "tags": [
                  "x_transferred"
                ],
                "url": "https://git.kernel.org/stable/c/e3c2d2d144c082dd71596953193adf9891491f42"
              }
            ],
            "title": "CVE Program Container"
          },
          {
            "metrics": [
              {
                "other": {
                  "content": {
                    "id": "CVE-2023-52853",
                    "options": [
                      {
                        "Exploitation": "none"
                      },
                      {
                        "Automatable": "no"
                      },
                      {
                        "Technical Impact": "partial"
                      }
                    ],
                    "role": "CISA Coordinator",
                    "timestamp": "2024-05-22T18:51:33.652573Z",
                    "version": "2.0.3"
                  },
                  "type": "ssvc"
                }
              }
            ],
            "providerMetadata": {
              "dateUpdated": "2024-05-22T18:51:40.750Z",
              "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "shortName": "CISA-ADP"
            },
            "title": "CISA ADP Vulnrichment"
          }
        ],
        "cna": {
          "affected": [
            {
              "defaultStatus": "unaffected",
              "product": "Linux",
              "programFiles": [
                "drivers/hid/hid-cp2112.c"
              ],
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "vendor": "Linux",
              "versions": [
                {
                  "lessThan": "df0daac27094",
                  "status": "affected",
                  "version": "13de9cca514e",
                  "versionType": "git"
                },
                {
                  "lessThan": "727203e6e7e7",
                  "status": "affected",
                  "version": "13de9cca514e",
                  "versionType": "git"
                },
                {
                  "lessThan": "3d959406c8ff",
                  "status": "affected",
                  "version": "13de9cca514e",
                  "versionType": "git"
                },
                {
                  "lessThan": "012d0c66f939",
                  "status": "affected",
                  "version": "13de9cca514e",
                  "versionType": "git"
                },
                {
                  "lessThan": "bafb12b629b7",
                  "status": "affected",
                  "version": "13de9cca514e",
                  "versionType": "git"
                },
                {
                  "lessThan": "fb5718bc6733",
                  "status": "affected",
                  "version": "13de9cca514e",
                  "versionType": "git"
                },
                {
                  "lessThan": "eb1121fac798",
                  "status": "affected",
                  "version": "13de9cca514e",
                  "versionType": "git"
                },
                {
                  "lessThan": "e3c2d2d144c0",
                  "status": "affected",
                  "version": "13de9cca514e",
                  "versionType": "git"
                }
              ]
            },
            {
              "defaultStatus": "affected",
              "product": "Linux",
              "programFiles": [
                "drivers/hid/hid-cp2112.c"
              ],
              "repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
              "vendor": "Linux",
              "versions": [
                {
                  "status": "affected",
                  "version": "4.10"
                },
                {
                  "lessThan": "4.10",
                  "status": "unaffected",
                  "version": "0",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "4.19.*",
                  "status": "unaffected",
                  "version": "4.19.299",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "5.4.*",
                  "status": "unaffected",
                  "version": "5.4.261",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "5.10.*",
                  "status": "unaffected",
                  "version": "5.10.201",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "5.15.*",
                  "status": "unaffected",
                  "version": "5.15.139",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "6.1.*",
                  "status": "unaffected",
                  "version": "6.1.63",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "6.5.*",
                  "status": "unaffected",
                  "version": "6.5.12",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "6.6.*",
                  "status": "unaffected",
                  "version": "6.6.2",
                  "versionType": "semver"
                },
                {
                  "lessThanOrEqual": "*",
                  "status": "unaffected",
                  "version": "6.7",
                  "versionType": "original_commit_for_fix"
                }
              ]
            }
          ],
          "descriptions": [
            {
              "lang": "en",
              "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nhid: cp2112: Fix duplicate workqueue initialization\n\nPreviously the cp2112 driver called INIT_DELAYED_WORK within\ncp2112_gpio_irq_startup, resulting in duplicate initilizations of the\nworkqueue on subsequent IRQ startups following an initial request. This\nresulted in a warning in set_work_data in workqueue.c, as well as a rare\nNULL dereference within process_one_work in workqueue.c.\n\nInitialize the workqueue within _probe instead."
            }
          ],
          "providerMetadata": {
            "dateUpdated": "2024-11-04T14:53:54.174Z",
            "orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
            "shortName": "Linux"
          },
          "references": [
            {
              "url": "https://git.kernel.org/stable/c/df0daac2709473531d6a3472997cc65301ac06d6"
            },
            {
              "url": "https://git.kernel.org/stable/c/727203e6e7e7020e1246fc1628cbdb8d90177819"
            },
            {
              "url": "https://git.kernel.org/stable/c/3d959406c8fff2334d83d0c352d54fd6f5b2e7cd"
            },
            {
              "url": "https://git.kernel.org/stable/c/012d0c66f9392a99232ac28217229f32dd3a70cf"
            },
            {
              "url": "https://git.kernel.org/stable/c/bafb12b629b7c3ad59812dd1ac1b0618062e0e38"
            },
            {
              "url": "https://git.kernel.org/stable/c/fb5718bc67337dde1528661f419ffcf275757592"
            },
            {
              "url": "https://git.kernel.org/stable/c/eb1121fac7986b30915ba20c5a04cc01fdcf160c"
            },
            {
              "url": "https://git.kernel.org/stable/c/e3c2d2d144c082dd71596953193adf9891491f42"
            }
          ],
          "title": "hid: cp2112: Fix duplicate workqueue initialization",
          "x_generator": {
            "engine": "bippy-9e1c9544281a"
          }
        }
      },
      "cveMetadata": {
        "assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
        "assignerShortName": "Linux",
        "cveId": "CVE-2023-52853",
        "datePublished": "2024-05-21T15:31:48.571Z",
        "dateReserved": "2024-05-21T15:19:24.256Z",
        "dateUpdated": "2024-11-04T14:53:54.174Z",
        "state": "PUBLISHED"
      },
      "dataType": "CVE_RECORD",
      "dataVersion": "5.1"
    }
  }
}

OESA-2024-1767 (CVE-2021-47231)

Vulnerability from osv_openeuler – Published: 2024-06-28 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:

can: mcba_usb: fix memory leak in mcba_usb

Syzbot reported memory leak in SocketCAN driver for Microchip CAN BUS Analyzer Tool. The problem was in unfreed usb_coherent.

In mcba_usb_start() 20 coherent buffers are allocated and there is nothing, that frees them:

1) In callback function the urb is resubmitted and that's all 2) In disconnect function urbs are simply killed, but URB_FREE_BUFFER is not set (see mcba_usb_start) and this flag cannot be used with coherent buffers.

Fail log: | [ 1354.053291][ T8413] mcba_usb 1-1:0.0 can0: device disconnected | [ 1367.059384][ T8420] kmemleak: 20 new suspected memory leaks (see /sys/kernel/debug/kmem)

So, all allocated buffers should be freed with usb_free_coherent() explicitly

NOTE: The same pattern for allocating and freeing coherent buffers is used in drivers/net/can/usb/kvaser_usb/kvaser_usb_core.c(CVE-2021-47231)

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

can: j1939: fix Use-after-Free, hold skb ref while in use

This patch fixes a Use-after-Free found by the syzbot.

The problem is that a skb is taken from the per-session skb queue, without incrementing the ref count. This leads to a Use-after-Free if the skb is taken concurrently from the session queue due to a CTS.(CVE-2021-47232)

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

batman-adv: Avoid WARN_ON timing related checks

The soft/batadv interface for a queued OGM can be changed during the time the OGM was queued for transmission and when the OGM is actually transmitted by the worker.

But WARN_ON must be used to denote kernel bugs and not to print simple warnings. A warning can simply be printed using pr_warn.(CVE-2021-47252)

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

media: ngene: Fix out-of-bounds bug in ngene_command_config_free_buf()

Fix an 11-year old bug in ngene_command_config_free_buf() while addressing the following warnings caught with -Warray-bounds:

arch/alpha/include/asm/string.h:22:16: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds] arch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds]

The problem is that the original code is trying to copy 6 bytes of data into a one-byte size member config of the wrong structue FW_CONFIGURE_BUFFERS, in a single call to memcpy(). This causes a legitimate compiler warning because memcpy() overruns the length of &com.cmd.ConfigureBuffers.config. It seems that the right structure is FW_CONFIGURE_FREE_BUFFERS, instead, because it contains 6 more members apart from the header hdr. Also, the name of the function ngene_command_config_free_buf() suggests that the actual intention is to ConfigureFreeBuffers, instead of ConfigureBuffers (which takes place in the function ngene_command_config_buf(), above).

Fix this by enclosing those 6 members of struct FW_CONFIGURE_FREE_BUFFERS into new struct config, and use &com.cmd.ConfigureFreeBuffers.config as the destination address, instead of &com.cmd.ConfigureBuffers.config, when calling memcpy().

This also helps with the ongoing efforts to globally enable -Warray-bounds and get us closer to being able to tighten the FORTIFY_SOURCE routines on memcpy().(CVE-2021-47288)

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

coresight: tmc-etf: Fix global-out-of-bounds in tmc_update_etf_buffer()

commit 6f755e85c332 ("coresight: Add helper for inserting synchronization packets") removed trailing '\0' from barrier_pkt array and updated the call sites like etb_update_buffer() to have proper checks for barrier_pkt size before read but missed updating tmc_update_etf_buffer() which still reads barrier_pkt past the array size resulting in KASAN out-of-bounds bug. Fix this by adding a check for barrier_pkt size before accessing like it is done in etb_update_buffer().

BUG: KASAN: global-out-of-bounds in tmc_update_etf_buffer+0x4b8/0x698 Read of size 4 at addr ffffffd05b7d1030 by task perf/2629

Call trace: dump_backtrace+0x0/0x27c show_stack+0x20/0x2c dump_stack+0x11c/0x188 print_address_description+0x3c/0x4a4 __kasan_report+0x140/0x164 kasan_report+0x10/0x18 __asan_report_load4_noabort+0x1c/0x24 tmc_update_etf_buffer+0x4b8/0x698 etm_event_stop+0x248/0x2d8 etm_event_del+0x20/0x2c event_sched_out+0x214/0x6f0 group_sched_out+0xd0/0x270 ctx_sched_out+0x2ec/0x518 __perf_event_task_sched_out+0x4fc/0xe6c __schedule+0x1094/0x16a0 preempt_schedule_irq+0x88/0x170 arm64_preempt_schedule_irq+0xf0/0x18c el1_irq+0xe8/0x180 perf_event_exec+0x4d8/0x56c setup_new_exec+0x204/0x400 load_elf_binary+0x72c/0x18c0 search_binary_handler+0x13c/0x420 load_script+0x500/0x6c4 search_binary_handler+0x13c/0x420 exec_binprm+0x118/0x654 __do_execve_file+0x77c/0xba4 __arm64_compat_sys_execve+0x98/0xac el0_svc_common+0x1f8/0x5e0 el0_svc_compat_handler+0x84/0xb0 el0_svc_compat+0x10/0x50

The buggy address belongs to the variable: barrier_pkt+0x10/0x40

Memory state around the buggy address: ffffffd05b7d0f00: fa fa fa fa 04 fa fa fa fa fa fa fa 00 00 00 00 ffffffd05b7d0f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffffd05b7d1000: 00 00 00 00 00 00 fa fa fa fa fa fa 00 00 00 03 ^ ffffffd05b7d1080: fa fa fa fa 00 02 fa fa fa fa fa fa 03 fa fa fa ffffffd05b7d1100: fa fa fa fa 00 00 00 00 05 fa fa fa fa fa fa fa ==================================================================(CVE-2021-47346)

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

wl1251: Fix possible buffer overflow in wl1251_cmd_scan

Function wl1251_cmd_scan calls memcpy without checking the length. Harden by checking the length is within the maximum allowed size.(CVE-2021-47347)

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

xhci: Fix command ring pointer corruption while aborting a command

The command ring pointer is located at [6:63] bits of the command ring control register (CRCR). All the control bits like command stop, abort are located at [0:3] bits. While aborting a command, we read the CRCR and set the abort bit and write to the CRCR. The read will always give command ring pointer as all zeros. So we essentially write only the control bits. Since we split the 64 bit write into two 32 bit writes, there is a possibility of xHC command ring stopped before the upper dword (all zeros) is written. If that happens, xHC updates the upper dword of its internal command ring pointer with all zeros. Next time, when the command ring is restarted, we see xHC memory access failures. Fix this issue by only writing to the lower dword of CRCR where all control bits are located.(CVE-2021-47434)

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

mm, slub: fix potential memoryleak in kmem_cache_open()

In error path, the random_seq of slub cache might be leaked. Fix this by using __kmem_cache_release() to release all the relevant resources.(CVE-2021-47466)

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

spi: Fix deadlock when adding SPI controllers on SPI buses

Currently we have a global spi_add_lock which we take when adding new devices so that we can check that we're not trying to reuse a chip select that's already controlled. This means that if the SPI device is itself a SPI controller and triggers the instantiation of further SPI devices we trigger a deadlock as we try to register and instantiate those devices while in the process of doing so for the parent controller and hence already holding the global spi_add_lock. Since we only care about concurrency within a single SPI bus move the lock to be per controller, avoiding the deadlock.

This can be easily triggered in the case of spi-mux.(CVE-2021-47469)

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

ocfs2: fix race between searching chunks and release journal_head from buffer_head

Encountered a race between ocfs2_test_bg_bit_allocatable() and jbd2_journal_put_journal_head() resulting in the below vmcore.

PID: 106879 TASK: ffff880244ba9c00 CPU: 2 COMMAND: "loop3" Call trace: panic oops_end no_context __bad_area_nosemaphore bad_area_nosemaphore __do_page_fault do_page_fault page_fault [exception RIP: ocfs2_block_group_find_clear_bits+316] ocfs2_block_group_find_clear_bits [ocfs2] ocfs2_cluster_group_search [ocfs2] ocfs2_search_chain [ocfs2] ocfs2_claim_suballoc_bits [ocfs2] __ocfs2_claim_clusters [ocfs2] ocfs2_claim_clusters [ocfs2] ocfs2_local_alloc_slide_window [ocfs2] ocfs2_reserve_local_alloc_bits [ocfs2] ocfs2_reserve_clusters_with_limit [ocfs2] ocfs2_reserve_clusters [ocfs2] ocfs2_lock_refcount_allocators [ocfs2] ocfs2_make_clusters_writable [ocfs2] ocfs2_replace_cow [ocfs2] ocfs2_refcount_cow [ocfs2] ocfs2_file_write_iter [ocfs2] lo_rw_aio loop_queue_work kthread_worker_fn kthread ret_from_fork

When ocfs2_test_bg_bit_allocatable() called bh2jh(bg_bh), the bg_bh->b_private NULL as jbd2_journal_put_journal_head() raced and released the jounal head from the buffer head. Needed to take bit lock for the bit 'BH_JournalHead' to fix this race.(CVE-2021-47493)

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

iio: mma8452: Fix trigger reference couting

The mma8452 driver directly assigns a trigger to the struct iio_dev. The IIO core when done using this trigger will call iio_trigger_put() to drop the reference count by 1.

Without the matching iio_trigger_get() in the driver the reference count can reach 0 too early, the trigger gets freed while still in use and a use-after-free occurs.

Fix this by getting a reference to the trigger before assigning it to the IIO device.(CVE-2021-47500)

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

can: sja1000: fix use after free in ems_pcmcia_add_card()

If the last channel is not available then "dev" is freed. Fortunately, we can just use "pdev->irq" instead.

Also we should check if at least one channel was set up.(CVE-2021-47521)

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

scsi: mpt3sas: Fix kernel panic during drive powercycle test

While looping over shost's sdev list it is possible that one of the drives is getting removed and its sas_target object is freed but its sdev object remains intact.

Consequently, a kernel panic can occur while the driver is trying to access the sas_address field of sas_target object without also checking the sas_target object for NULL.(CVE-2021-47565)

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

inet_diag: fix kernel-infoleak for UDP sockets

KMSAN reported a kernel-infoleak [1], that can exploited by unpriv users.

After analysis it turned out UDP was not initializing r->idiag_expires. Other users of inet_sk_diag_fill() might make the same mistake in the future, so fix this in inet_sk_diag_fill().

[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:156 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x69d/0x25c0 lib/iov_iter.c:670 instrument_copy_to_user include/linux/instrumented.h:121 [inline] copyout lib/iov_iter.c:156 [inline] _copy_to_iter+0x69d/0x25c0 lib/iov_iter.c:670 copy_to_iter include/linux/uio.h:155 [inline] simple_copy_to_iter+0xf3/0x140 net/core/datagram.c:519 __skb_datagram_iter+0x2cb/0x1280 net/core/datagram.c:425 skb_copy_datagram_iter+0xdc/0x270 net/core/datagram.c:533 skb_copy_datagram_msg include/linux/skbuff.h:3657 [inline] netlink_recvmsg+0x660/0x1c60 net/netlink/af_netlink.c:1974 sock_recvmsg_nosec net/socket.c:944 [inline] sock_recvmsg net/socket.c:962 [inline] sock_read_iter+0x5a9/0x630 net/socket.c:1035 call_read_iter include/linux/fs.h:2156 [inline] new_sync_read fs/read_write.c:400 [inline] vfs_read+0x1631/0x1980 fs/read_write.c:481 ksys_read+0x28c/0x520 fs/read_write.c:619 __do_sys_read fs/read_write.c:629 [inline] __se_sys_read fs/read_write.c:627 [inline] __x64_sys_read+0xdb/0x120 fs/read_write.c:627 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:524 [inline] slab_alloc_node mm/slub.c:3251 [inline] __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974 kmalloc_reserve net/core/skbuff.c:354 [inline] __alloc_skb+0x545/0xf90 net/core/skbuff.c:426 alloc_skb include/linux/skbuff.h:1126 [inline] netlink_dump+0x3d5/0x16a0 net/netlink/af_netlink.c:2245 __netlink_dump_start+0xd1c/0xee0 net/netlink/af_netlink.c:2370 netlink_dump_start include/linux/netlink.h:254 [inline] inet_diag_handler_cmd+0x2e7/0x400 net/ipv4/inet_diag.c:1343 sock_diag_rcv_msg+0x24a/0x620 netlink_rcv_skb+0x447/0x800 net/netlink/af_netlink.c:2491 sock_diag_rcv+0x63/0x80 net/core/sock_diag.c:276 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0x1095/0x1360 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x16f3/0x1870 net/netlink/af_netlink.c:1916 sock_sendmsg_nosec net/socket.c:704 [inline] sock_sendmsg net/socket.c:724 [inline] sock_write_iter+0x594/0x690 net/socket.c:1057 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+0x63f/0xe30 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 312 are uninitialized Memory access of size 312 starts at ffff88812ab54000 Data copied to user address 0000000020001440

CPU: 1 PID: 6365 Comm: syz-executor801 Not tainted 5.16.0-rc3-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011(CVE-2021-47597)

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

firmware: arm_scpi: Fix string overflow in SCPI genpd driver

Without the bound checks for scpi_pd->name, it could result in the buffer overflow when copying the SCPI device name from the corresponding device tree node as the name string is set at maximum size of 30.

Let us fix it by using devm_kasprintf so that the string buffer is allocated dynamically.(CVE-2021-47609)

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

ASoC: ops: Reject out of bounds values in snd_soc_put_volsw_sx()

We don't currently validate that the values being set are within the range we advertised to userspace as being valid, do so and reject any values that are out of range.(CVE-2022-48737)

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

powerpc64/bpf: Limit 'ldbrx' to processors compliant with ISA v2.06

Johan reported the below crash with test_bpf on ppc64 e5500:

test_bpf: #296 ALU_END_FROM_LE 64: 0x0123456789abcdef -> 0x67452301 jited:1 Oops: Exception in kernel mode, sig: 4 [#1] BE PAGE_SIZE=4K SMP NR_CPUS=24 QEMU e500 Modules linked in: test_bpf(+) CPU: 0 PID: 76 Comm: insmod Not tainted 5.14.0-03771-g98c2059e008a-dirty #1 NIP: 8000000000061c3c LR: 80000000006dea64 CTR: 8000000000061c18 REGS: c0000000032d3420 TRAP: 0700 Not tainted (5.14.0-03771-g98c2059e008a-dirty) MSR: 0000000080089000 <EE,ME> CR: 88002822 XER: 20000000 IRQMASK: 0 <...> NIP [8000000000061c3c] 0x8000000000061c3c LR [80000000006dea64] .__run_one+0x104/0x17c [test_bpf] Call Trace: .__run_one+0x60/0x17c [test_bpf] (unreliable) .test_bpf_init+0x6a8/0xdc8 [test_bpf] .do_one_initcall+0x6c/0x28c .do_init_module+0x68/0x28c .load_module+0x2460/0x2abc .__do_sys_init_module+0x120/0x18c .system_call_exception+0x110/0x1b8 system_call_common+0xf0/0x210 --- interrupt: c00 at 0x101d0acc <...> ---[ end trace 47b2bf19090bb3d0 ]---

Illegal instruction

The illegal instruction turned out to be 'ldbrx' emitted for BPF_FROM_[L|B]E, which was only introduced in ISA v2.06. Guard use of the same and implement an alternative approach for older processors.(CVE-2022-48755)

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

drm/msm/dsi: invalid parameter check in msm_dsi_phy_enable

The function performs a check on the "phy" input parameter, however, it is used before the check.

Initialize the "dev" variable after the sanity check to avoid a possible NULL pointer dereference.

Addresses-Coverity-ID: 1493860 ("Null pointer dereference")(CVE-2022-48756)

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

rpmsg: virtio: Free driver_override when rpmsg_remove()

Free driver_override when rpmsg_remove(), otherwise the following memory leak will occur:

unreferenced object 0xffff0000d55d7080 (size 128): comm "kworker/u8:2", pid 56, jiffies 4294893188 (age 214.272s) hex dump (first 32 bytes): 72 70 6d 73 67 5f 6e 73 00 00 00 00 00 00 00 00 rpmsg_ns........ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000009c94c9c1>] __kmem_cache_alloc_node+0x1f8/0x320 [<000000002300d89b>] __kmalloc_node_track_caller+0x44/0x70 [<00000000228a60c3>] kstrndup+0x4c/0x90 [<0000000077158695>] driver_set_override+0xd0/0x164 [<000000003e9c4ea5>] rpmsg_register_device_override+0x98/0x170 [<000000001c0c89a8>] rpmsg_ns_register_device+0x24/0x30 [<000000008bbf8fa2>] rpmsg_probe+0x2e0/0x3ec [<00000000e65a68df>] virtio_dev_probe+0x1c0/0x280 [<00000000443331cc>] really_probe+0xbc/0x2dc [<00000000391064b1>] __driver_probe_device+0x78/0xe0 [<00000000a41c9a5b>] driver_probe_device+0xd8/0x160 [<000000009c3bd5df>] __device_attach_driver+0xb8/0x140 [<0000000043cd7614>] bus_for_each_drv+0x7c/0xd4 [<000000003b929a36>] __device_attach+0x9c/0x19c [<00000000a94e0ba8>] device_initial_probe+0x14/0x20 [<000000003c999637>] bus_probe_device+0xa0/0xac(CVE-2023-52670)

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

Fix page corruption caused by racy check in __free_pages

When we upgraded our kernel, we started seeing some page corruption like the following consistently:

BUG: Bad page state in process ganesha.nfsd pfn:1304ca page:0000000022261c55 refcount:0 mapcount:-128 mapping:0000000000000000 index:0x0 pfn:0x1304ca flags: 0x17ffffc0000000() raw: 0017ffffc0000000 ffff8a513ffd4c98 ffffeee24b35ec08 0000000000000000 raw: 0000000000000000 0000000000000001 00000000ffffff7f 0000000000000000 page dumped because: nonzero mapcount CPU: 0 PID: 15567 Comm: ganesha.nfsd Kdump: loaded Tainted: P B O 5.10.158-1.nutanix.20221209.el7.x86_64 #1 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 04/05/2016 Call Trace: dump_stack+0x74/0x96 bad_page.cold+0x63/0x94 check_new_page_bad+0x6d/0x80 rmqueue+0x46e/0x970 get_page_from_freelist+0xcb/0x3f0 ? _cond_resched+0x19/0x40 __alloc_pages_nodemask+0x164/0x300 alloc_pages_current+0x87/0xf0 skb_page_frag_refill+0x84/0x110 ...

Sometimes, it would also show up as corruption in the free list pointer and cause crashes.

After bisecting the issue, we found the issue started from commit e320d3012d25 ("mm/page_alloc.c: fix freeing non-compound pages"):

if (put_page_testzero(page))
    free_the_page(page, order);
else if (!PageHead(page))
    while (order-- &gt; 0)
        free_the_page(page + (1 &lt;&lt; order), order);

So the problem is the check PageHead is racy because at this point we already dropped our reference to the page. So even if we came in with compound page, the page can already be freed and PageHead can return false and we will end up freeing all the tail pages causing double free.(CVE-2023-52739)

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

atl1c: Work around the DMA RX overflow issue

This is based on alx driver commit 881d0327db37 ("net: alx: Work around the DMA RX overflow issue").

The alx and atl1c drivers had RX overflow error which was why a custom allocator was created to avoid certain addresses. The simpler workaround then created for alx driver, but not for atl1c due to lack of tester.

Instead of using a custom allocator, check the allocated skb address and use skb_reserve() to move away from problematic 0x...fc0 address.

Tested on AR8131 on Acer 4540.(CVE-2023-52834)

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

hid: cp2112: Fix duplicate workqueue initialization

Previously the cp2112 driver called INIT_DELAYED_WORK within cp2112_gpio_irq_startup, resulting in duplicate initilizations of the workqueue on subsequent IRQ startups following an initial request. This resulted in a warning in set_work_data in workqueue.c, as well as a rare NULL dereference within process_one_work in workqueue.c.

Initialize the workqueue within _probe instead.(CVE-2023-52853)

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

ALSA: usb-audio: Stop parsing channels bits when all channels are found.

If a usb audio device sets more bits than the amount of channels it could write outside of the map array.(CVE-2024-27436)

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

media: tc358743: register v4l2 async device only after successful setup

Ensure the device has been setup correctly before registering the v4l2 async device, thus allowing userspace to access.(CVE-2024-35830)

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

usb: gadget: f_fs: Fix race between aio_cancel() and AIO request complete

FFS based applications can utilize the aio_cancel() callback to dequeue pending USB requests submitted to the UDC. There is a scenario where the FFS application issues an AIO cancel call, while the UDC is handling a soft disconnect. For a DWC3 based implementation, the callstack looks like the following:

DWC3 Gadget                               FFS Application

dwc3_gadget_soft_disconnect() ... --> dwc3_stop_active_transfers() --> dwc3_gadget_giveback(-ESHUTDOWN) --> ffs_epfile_async_io_complete() ffs_aio_cancel() --> usb_ep_free_request() --> usb_ep_dequeue()

There is currently no locking implemented between the AIO completion handler and AIO cancel, so the issue occurs if the completion routine is running in parallel to an AIO cancel call coming from the FFS application. As the completion call frees the USB request (io_data->req) the FFS application is also referencing it for the usb_ep_dequeue() call. This can lead to accessing a stale/hanging pointer.

commit b566d38857fc ("usb: gadget: f_fs: use io_data->status consistently") relocated the usb_ep_free_request() into ffs_epfile_async_io_complete(). However, in order to properly implement locking to mitigate this issue, the spinlock can't be added to ffs_epfile_async_io_complete(), as usb_ep_dequeue() (if successfully dequeuing a USB request) will call the function driver's completion handler in the same context. Hence, leading into a deadlock.

Fix this issue by moving the usb_ep_free_request() back to ffs_user_copy_worker(), and ensuring that it explicitly sets io_data->req to NULL after freeing it within the ffs->eps_lock. This resolves the race condition above, as the ffs_aio_cancel() routine will not continue attempting to dequeue a request that has already been freed, or the ffs_user_copy_work() not freeing the USB request until the AIO cancel is done referencing it.

This fix depends on commit b566d38857fc ("usb: gadget: f_fs: use io_data->status consistently")(CVE-2024-36894)

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

wifi: nl80211: don't free NULL coalescing rule

If the parsing fails, we can dereference a NULL pointer here.(CVE-2024-36941)

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

firewire: ohci: mask bus reset interrupts between ISR and bottom half

In the FireWire OHCI interrupt handler, if a bus reset interrupt has occurred, mask bus reset interrupts until bus_reset_work has serviced and cleared the interrupt.

Normally, we always leave bus reset interrupts masked. We infer the bus reset from the self-ID interrupt that happens shortly thereafter. A scenario where we unmask bus reset interrupts was introduced in 2008 in a007bb857e0b26f5d8b73c2ff90782d9c0972620: If OHCI_PARAM_DEBUG_BUSRESETS (8) is set in the debug parameter bitmask, we will unmask bus reset interrupts so we can log them.

irq_handler logs the bus reset interrupt. However, we can't clear the bus reset event flag in irq_handler, because we won't service the event until later. irq_handler exits with the event flag still set. If the corresponding interrupt is still unmasked, the first bus reset will usually freeze the system due to irq_handler being called again each time it exits. This freeze can be reproduced by loading firewire_ohci with "modprobe firewire_ohci debug=-1" (to enable all debugging output). Apparently there are also some cases where bus_reset_work will get called soon enough to clear the event, and operation will continue normally.

This freeze was first reported a few months after a007bb85 was committed, but until now it was never fixed. The debug level could safely be set to -1 through sysfs after the module was loaded, but this would be ineffectual in logging bus reset interrupts since they were only unmasked during initialization.

irq_handler will now leave the event flag set but mask bus reset interrupts, so irq_handler won't be called again and there will be no freeze. If OHCI_PARAM_DEBUG_BUSRESETS is enabled, bus_reset_work will unmask the interrupt after servicing the event, so future interrupts will be caught as desired.

As a side effect to this change, OHCI_PARAM_DEBUG_BUSRESETS can now be enabled through sysfs in addition to during initial module loading. However, when enabled through sysfs, logging of bus reset interrupts will be effective only starting with the second bus reset, after bus_reset_work has executed.(CVE-2024-36950)

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

net: fix __dst_negative_advice() race

__dst_negative_advice() does not enforce proper RCU rules when sk->dst_cache must be cleared, leading to possible UAF.

RCU rules are that we must first clear sk->sk_dst_cache, then call dst_release(old_dst).

Note that sk_dst_reset(sk) is implementing this protocol correctly, while __dst_negative_advice() uses the wrong order.

Given that ip6_negative_advice() has special logic against RTF_CACHE, this means each of the three ->negative_advice() existing methods must perform the sk_dst_reset() themselves.

Note the check against NULL dst is centralized in __dst_negative_advice(), there is no need to duplicate it in various callbacks.

Many thanks to Clement Lecigne for tracking this issue.

This old bug became visible after the blamed commit, using UDP sockets.(CVE-2024-36971)

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

net: bridge: xmit: make sure we have at least eth header len bytes

syzbot triggered an uninit value[1] error in bridge device's xmit path by sending a short (less than ETH_HLEN bytes) skb. To fix it check if we can actually pull that amount instead of assuming.

Tested with dropwatch: drop at: br_dev_xmit+0xb93/0x12d0 [bridge] (0xffffffffc06739b3) origin: software timestamp: Mon May 13 11:31:53 2024 778214037 nsec protocol: 0x88a8 length: 2 original length: 2 drop reason: PKT_TOO_SMALL

[1] BUG: KMSAN: uninit-value in br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65 br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65 __netdev_start_xmit include/linux/netdevice.h:4903 [inline] netdev_start_xmit include/linux/netdevice.h:4917 [inline] xmit_one net/core/dev.c:3531 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547 __dev_queue_xmit+0x34db/0x5350 net/core/dev.c:4341 dev_queue_xmit include/linux/netdevice.h:3091 [inline] __bpf_tx_skb net/core/filter.c:2136 [inline] __bpf_redirect_common net/core/filter.c:2180 [inline] __bpf_redirect+0x14a6/0x1620 net/core/filter.c:2187 _bpfclone_redirect net/core/filter.c:2460 [inline] bpf_clone_redirect+0x328/0x470 net/core/filter.c:2432 _bpf_prog_run+0x13fe/0xe0f0 kernel/bpf/core.c:1997 __bpf_prog_run512+0xb5/0xe0 kernel/bpf/core.c:2238 bpf_dispatcher_nop_func include/linux/bpf.h:1234 [inline] __bpf_prog_run include/linux/filter.h:657 [inline] bpf_prog_run include/linux/filter.h:664 [inline] bpf_test_run+0x499/0xc30 net/bpf/test_run.c:425 bpf_prog_test_run_skb+0x14ea/0x1f20 net/bpf/test_run.c:1058 bpf_prog_test_run+0x6b7/0xad0 kernel/bpf/syscall.c:4269 __sys_bpf+0x6aa/0xd90 kernel/bpf/syscall.c:5678 __do_sys_bpf kernel/bpf/syscall.c:5767 [inline] __se_sys_bpf kernel/bpf/syscall.c:5765 [inline] __x64_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5765 x64_sys_call+0x96b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:322 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-38538)

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

of: module: add buffer overflow check in of_modalias()

In of_modalias(), if the buffer happens to be too small even for the 1st snprintf() call, the len parameter will become negative and str parameter (if not NULL initially) will point beyond the buffer's end. Add the buffer overflow check after the 1st snprintf() call and fix such check after the strlen() call (accounting for the terminating NUL char).(CVE-2024-38541)

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

drm/amd/display: Fix potential index out of bounds in color transformation function

Fixes index out of bounds issue in the color transformation function. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS).

The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, an error message is logged and the function returns false to indicate an error.

Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:405 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:406 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:407 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max(CVE-2024-38552)

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

ftrace: Fix possible use-after-free issue in ftrace_location()

KASAN reports a bug:

BUG: KASAN: use-after-free in ftrace_location+0x90/0x120 Read of size 8 at addr ffff888141d40010 by task insmod/424 CPU: 8 PID: 424 Comm: insmod Tainted: G W 6.9.0-rc2+ [...] Call Trace: <TASK> dump_stack_lvl+0x68/0xa0 print_report+0xcf/0x610 kasan_report+0xb5/0xe0 ftrace_location+0x90/0x120 register_kprobe+0x14b/0xa40 kprobe_init+0x2d/0xff0 [kprobe_example] do_one_initcall+0x8f/0x2d0 do_init_module+0x13a/0x3c0 load_module+0x3082/0x33d0 init_module_from_file+0xd2/0x130 __x64_sys_finit_module+0x306/0x440 do_syscall_64+0x68/0x140 entry_SYSCALL_64_after_hwframe+0x71/0x79

The root cause is that, in lookup_rec(), ftrace record of some address is being searched in ftrace pages of some module, but those ftrace pages at the same time is being freed in ftrace_release_mod() as the corresponding module is being deleted:

       CPU1                       |      CPU2

register_kprobes() { | delete_module() { check_kprobe_address_safe() { | arch_check_ftrace_location() { | ftrace_location() { | lookup_rec() // USE! | ftrace_release_mod() // Free!

To fix this issue: 1. Hold rcu lock as accessing ftrace pages in ftrace_location_range(); 2. Use ftrace_location_range() instead of lookup_rec() in ftrace_location(); 3. Call synchronize_rcu() before freeing any ftrace pages both in ftrace_process_locs()/ftrace_release_mod()/ftrace_free_mem().(CVE-2024-38588)

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

af_unix: Fix data races in unix_release_sock/unix_stream_sendmsg

A data-race condition has been identified in af_unix. In one data path, the write function unix_release_sock() atomically writes to sk->sk_shutdown using WRITE_ONCE. However, on the reader side, unix_stream_sendmsg() does not read it atomically. Consequently, this issue is causing the following KCSAN splat to occur:

BUG: KCSAN: data-race in unix_release_sock / unix_stream_sendmsg

write (marked) to 0xffff88867256ddbb of 1 bytes by task 7270 on cpu 28:
unix_release_sock (net/unix/af_unix.c:640)
unix_release (net/unix/af_unix.c:1050)
sock_close (net/socket.c:659 net/socket.c:1421)
__fput (fs/file_table.c:422)
__fput_sync (fs/file_table.c:508)
__se_sys_close (fs/open.c:1559 fs/open.c:1541)
__x64_sys_close (fs/open.c:1541)
x64_sys_call (arch/x86/entry/syscall_64.c:33)
do_syscall_64 (arch/x86/entry/common.c:?)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)

read to 0xffff88867256ddbb of 1 bytes by task 989 on cpu 14:
unix_stream_sendmsg (net/unix/af_unix.c:2273)
__sock_sendmsg (net/socket.c:730 net/socket.c:745)
____sys_sendmsg (net/socket.c:2584)
__sys_sendmmsg (net/socket.c:2638 net/socket.c:2724)
__x64_sys_sendmmsg (net/socket.c:2753 net/socket.c:2750 net/socket.c:2750)
x64_sys_call (arch/x86/entry/syscall_64.c:33)
do_syscall_64 (arch/x86/entry/common.c:?)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)

value changed: 0x01 -&gt; 0x03

The line numbers are related to commit dd5a440a31fa ("Linux 6.9-rc7").

Commit e1d09c2c2f57 ("af_unix: Fix data races around sk->sk_shutdown.") addressed a comparable issue in the past regarding sk->sk_shutdown. However, it overlooked resolving this particular data path. This patch only offending unix_stream_sendmsg() function, since the other reads seem to be protected by unix_state_lock() as discussed in(CVE-2024-38596)

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

macintosh/via-macii: Fix "BUG: sleeping function called from invalid context"

The via-macii ADB driver calls request_irq() after disabling hard interrupts. But disabling interrupts isn't necessary here because the VIA shift register interrupt was masked during VIA1 initialization.(CVE-2024-38607)

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/en/security/safety-bull…	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2021-47231	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2021-47232	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2021-47252	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2021-47288	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2021-47346	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2021-47347	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2021-47434	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2021-47466	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2021-47469	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2021-47493	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2021-47500	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2021-47521	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2021-47565	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2021-47597	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2021-47609	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-48737	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-48755	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2022-48756	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2023-52670	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2023-52739	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2023-52834	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2023-52853	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-27436	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-35830	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-36894	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-36941	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-36950	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-36971	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-38538	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-38541	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-38552	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-38588	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-38596	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-38607	ADVISORY

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "perf-debuginfo-4.19.90-2406.4.0.0283.oe2003sp4.aarch64.rpm",
          "kernel-debugsource-4.19.90-2406.4.0.0283.oe2003sp4.aarch64.rpm",
          "kernel-4.19.90-2406.4.0.0283.oe2003sp4.aarch64.rpm",
          "python2-perf-debuginfo-4.19.90-2406.4.0.0283.oe2003sp4.aarch64.rpm",
          "bpftool-4.19.90-2406.4.0.0283.oe2003sp4.aarch64.rpm",
          "kernel-tools-debuginfo-4.19.90-2406.4.0.0283.oe2003sp4.aarch64.rpm",
          "kernel-source-4.19.90-2406.4.0.0283.oe2003sp4.aarch64.rpm",
          "kernel-debuginfo-4.19.90-2406.4.0.0283.oe2003sp4.aarch64.rpm",
          "python2-perf-4.19.90-2406.4.0.0283.oe2003sp4.aarch64.rpm",
          "perf-4.19.90-2406.4.0.0283.oe2003sp4.aarch64.rpm",
          "python3-perf-debuginfo-4.19.90-2406.4.0.0283.oe2003sp4.aarch64.rpm",
          "kernel-tools-devel-4.19.90-2406.4.0.0283.oe2003sp4.aarch64.rpm",
          "kernel-tools-4.19.90-2406.4.0.0283.oe2003sp4.aarch64.rpm",
          "bpftool-debuginfo-4.19.90-2406.4.0.0283.oe2003sp4.aarch64.rpm",
          "python3-perf-4.19.90-2406.4.0.0283.oe2003sp4.aarch64.rpm",
          "kernel-devel-4.19.90-2406.4.0.0283.oe2003sp4.aarch64.rpm"
        ],
        "src": [
          "kernel-4.19.90-2406.4.0.0283.oe2003sp4.src.rpm"
        ],
        "x86_64": [
          "perf-debuginfo-4.19.90-2406.4.0.0283.oe2003sp4.x86_64.rpm",
          "kernel-devel-4.19.90-2406.4.0.0283.oe2003sp4.x86_64.rpm",
          "kernel-4.19.90-2406.4.0.0283.oe2003sp4.x86_64.rpm",
          "perf-4.19.90-2406.4.0.0283.oe2003sp4.x86_64.rpm",
          "bpftool-4.19.90-2406.4.0.0283.oe2003sp4.x86_64.rpm",
          "python2-perf-debuginfo-4.19.90-2406.4.0.0283.oe2003sp4.x86_64.rpm",
          "kernel-source-4.19.90-2406.4.0.0283.oe2003sp4.x86_64.rpm",
          "python2-perf-4.19.90-2406.4.0.0283.oe2003sp4.x86_64.rpm",
          "kernel-tools-debuginfo-4.19.90-2406.4.0.0283.oe2003sp4.x86_64.rpm",
          "kernel-tools-4.19.90-2406.4.0.0283.oe2003sp4.x86_64.rpm",
          "python3-perf-debuginfo-4.19.90-2406.4.0.0283.oe2003sp4.x86_64.rpm",
          "bpftool-debuginfo-4.19.90-2406.4.0.0283.oe2003sp4.x86_64.rpm",
          "kernel-debuginfo-4.19.90-2406.4.0.0283.oe2003sp4.x86_64.rpm",
          "kernel-tools-devel-4.19.90-2406.4.0.0283.oe2003sp4.x86_64.rpm",
          "kernel-debugsource-4.19.90-2406.4.0.0283.oe2003sp4.x86_64.rpm",
          "python3-perf-4.19.90-2406.4.0.0283.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-2406.4.0.0283.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\ncan: mcba_usb: fix memory leak in mcba_usb\r\n\r\nSyzbot reported memory leak in SocketCAN driver for Microchip CAN BUS\nAnalyzer Tool. The problem was in unfreed usb_coherent.\r\n\r\nIn mcba_usb_start() 20 coherent buffers are allocated and there is\nnothing, that frees them:\r\n\r\n1) In callback function the urb is resubmitted and that\u0026apos;s all\n2) In disconnect function urbs are simply killed, but URB_FREE_BUFFER\n   is not set (see mcba_usb_start) and this flag cannot be used with\n   coherent buffers.\r\n\r\nFail log:\n| [ 1354.053291][ T8413] mcba_usb 1-1:0.0 can0: device disconnected\n| [ 1367.059384][ T8420] kmemleak: 20 new suspected memory leaks (see /sys/kernel/debug/kmem)\r\n\r\nSo, all allocated buffers should be freed with usb_free_coherent()\nexplicitly\r\n\r\nNOTE:\nThe same pattern for allocating and freeing coherent buffers\nis used in drivers/net/can/usb/kvaser_usb/kvaser_usb_core.c(CVE-2021-47231)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncan: j1939: fix Use-after-Free, hold skb ref while in use\r\n\r\nThis patch fixes a Use-after-Free found by the syzbot.\r\n\r\nThe problem is that a skb is taken from the per-session skb queue,\nwithout incrementing the ref count. This leads to a Use-after-Free if\nthe skb is taken concurrently from the session queue due to a CTS.(CVE-2021-47232)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbatman-adv: Avoid WARN_ON timing related checks\r\n\r\nThe soft/batadv interface for a queued OGM can be changed during the time\nthe OGM was queued for transmission and when the OGM is actually\ntransmitted by the worker.\r\n\r\nBut WARN_ON must be used to denote kernel bugs and not to print simple\nwarnings. A warning can simply be printed using pr_warn.(CVE-2021-47252)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: ngene: Fix out-of-bounds bug in ngene_command_config_free_buf()\r\n\r\nFix an 11-year old bug in ngene_command_config_free_buf() while\naddressing the following warnings caught with -Warray-bounds:\r\n\r\narch/alpha/include/asm/string.h:22:16: warning: \u0026apos;__builtin_memcpy\u0026apos; offset [12, 16] from the object at \u0026apos;com\u0026apos; is out of the bounds of referenced subobject \u0026apos;config\u0026apos; with type \u0026apos;unsigned char\u0026apos; at offset 10 [-Warray-bounds]\narch/x86/include/asm/string_32.h:182:25: warning: \u0026apos;__builtin_memcpy\u0026apos; offset [12, 16] from the object at \u0026apos;com\u0026apos; is out of the bounds of referenced subobject \u0026apos;config\u0026apos; with type \u0026apos;unsigned char\u0026apos; at offset 10 [-Warray-bounds]\r\n\r\nThe problem is that the original code is trying to copy 6 bytes of\ndata into a one-byte size member _config_ of the wrong structue\nFW_CONFIGURE_BUFFERS, in a single call to memcpy(). This causes a\nlegitimate compiler warning because memcpy() overruns the length\nof \u0026amp;com.cmd.ConfigureBuffers.config. It seems that the right\nstructure is FW_CONFIGURE_FREE_BUFFERS, instead, because it contains\n6 more members apart from the header _hdr_. Also, the name of\nthe function ngene_command_config_free_buf() suggests that the actual\nintention is to ConfigureFreeBuffers, instead of ConfigureBuffers\n(which takes place in the function ngene_command_config_buf(), above).\r\n\r\nFix this by enclosing those 6 members of struct FW_CONFIGURE_FREE_BUFFERS\ninto new struct config, and use \u0026amp;com.cmd.ConfigureFreeBuffers.config as\nthe destination address, instead of \u0026amp;com.cmd.ConfigureBuffers.config,\nwhen calling memcpy().\r\n\r\nThis also helps with the ongoing efforts to globally enable\n-Warray-bounds and get us closer to being able to tighten the\nFORTIFY_SOURCE routines on memcpy().(CVE-2021-47288)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncoresight: tmc-etf: Fix global-out-of-bounds in tmc_update_etf_buffer()\r\n\r\ncommit 6f755e85c332 (\u0026quot;coresight: Add helper for inserting synchronization\npackets\u0026quot;) removed trailing \u0026apos;\\0\u0026apos; from barrier_pkt array and updated the\ncall sites like etb_update_buffer() to have proper checks for barrier_pkt\nsize before read but missed updating tmc_update_etf_buffer() which still\nreads barrier_pkt past the array size resulting in KASAN out-of-bounds\nbug. Fix this by adding a check for barrier_pkt size before accessing\nlike it is done in etb_update_buffer().\r\n\r\n BUG: KASAN: global-out-of-bounds in tmc_update_etf_buffer+0x4b8/0x698\n Read of size 4 at addr ffffffd05b7d1030 by task perf/2629\r\n\r\n Call trace:\n  dump_backtrace+0x0/0x27c\n  show_stack+0x20/0x2c\n  dump_stack+0x11c/0x188\n  print_address_description+0x3c/0x4a4\n  __kasan_report+0x140/0x164\n  kasan_report+0x10/0x18\n  __asan_report_load4_noabort+0x1c/0x24\n  tmc_update_etf_buffer+0x4b8/0x698\n  etm_event_stop+0x248/0x2d8\n  etm_event_del+0x20/0x2c\n  event_sched_out+0x214/0x6f0\n  group_sched_out+0xd0/0x270\n  ctx_sched_out+0x2ec/0x518\n  __perf_event_task_sched_out+0x4fc/0xe6c\n  __schedule+0x1094/0x16a0\n  preempt_schedule_irq+0x88/0x170\n  arm64_preempt_schedule_irq+0xf0/0x18c\n  el1_irq+0xe8/0x180\n  perf_event_exec+0x4d8/0x56c\n  setup_new_exec+0x204/0x400\n  load_elf_binary+0x72c/0x18c0\n  search_binary_handler+0x13c/0x420\n  load_script+0x500/0x6c4\n  search_binary_handler+0x13c/0x420\n  exec_binprm+0x118/0x654\n  __do_execve_file+0x77c/0xba4\n  __arm64_compat_sys_execve+0x98/0xac\n  el0_svc_common+0x1f8/0x5e0\n  el0_svc_compat_handler+0x84/0xb0\n  el0_svc_compat+0x10/0x50\r\n\r\n The buggy address belongs to the variable:\n  barrier_pkt+0x10/0x40\r\n\r\n Memory state around the buggy address:\n  ffffffd05b7d0f00: fa fa fa fa 04 fa fa fa fa fa fa fa 00 00 00 00\n  ffffffd05b7d0f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n \u0026gt;ffffffd05b7d1000: 00 00 00 00 00 00 fa fa fa fa fa fa 00 00 00 03\n                                      ^\n  ffffffd05b7d1080: fa fa fa fa 00 02 fa fa fa fa fa fa 03 fa fa fa\n  ffffffd05b7d1100: fa fa fa fa 00 00 00 00 05 fa fa fa fa fa fa fa\n ==================================================================(CVE-2021-47346)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwl1251: Fix possible buffer overflow in wl1251_cmd_scan\r\n\r\nFunction wl1251_cmd_scan calls memcpy without checking the length.\nHarden by checking the length is within the maximum allowed size.(CVE-2021-47347)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nxhci: Fix command ring pointer corruption while aborting a command\r\n\r\nThe command ring pointer is located at [6:63] bits of the command\nring control register (CRCR). All the control bits like command stop,\nabort are located at [0:3] bits. While aborting a command, we read the\nCRCR and set the abort bit and write to the CRCR. The read will always\ngive command ring pointer as all zeros. So we essentially write only\nthe control bits. Since we split the 64 bit write into two 32 bit writes,\nthere is a possibility of xHC command ring stopped before the upper\ndword (all zeros) is written. If that happens, xHC updates the upper\ndword of its internal command ring pointer with all zeros. Next time,\nwhen the command ring is restarted, we see xHC memory access failures.\nFix this issue by only writing to the lower dword of CRCR where all\ncontrol bits are located.(CVE-2021-47434)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmm, slub: fix potential memoryleak in kmem_cache_open()\r\n\r\nIn error path, the random_seq of slub cache might be leaked.  Fix this\nby using __kmem_cache_release() to release all the relevant resources.(CVE-2021-47466)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nspi: Fix deadlock when adding SPI controllers on SPI buses\r\n\r\nCurrently we have a global spi_add_lock which we take when adding new\ndevices so that we can check that we\u0026apos;re not trying to reuse a chip\nselect that\u0026apos;s already controlled.  This means that if the SPI device is\nitself a SPI controller and triggers the instantiation of further SPI\ndevices we trigger a deadlock as we try to register and instantiate\nthose devices while in the process of doing so for the parent controller\nand hence already holding the global spi_add_lock.  Since we only care\nabout concurrency within a single SPI bus move the lock to be per\ncontroller, avoiding the deadlock.\r\n\r\nThis can be easily triggered in the case of spi-mux.(CVE-2021-47469)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nocfs2: fix race between searching chunks and release journal_head from buffer_head\r\n\r\nEncountered a race between ocfs2_test_bg_bit_allocatable() and\njbd2_journal_put_journal_head() resulting in the below vmcore.\r\n\r\n  PID: 106879  TASK: ffff880244ba9c00  CPU: 2   COMMAND: \u0026quot;loop3\u0026quot;\n  Call trace:\n    panic\n    oops_end\n    no_context\n    __bad_area_nosemaphore\n    bad_area_nosemaphore\n    __do_page_fault\n    do_page_fault\n    page_fault\n      [exception RIP: ocfs2_block_group_find_clear_bits+316]\n    ocfs2_block_group_find_clear_bits [ocfs2]\n    ocfs2_cluster_group_search [ocfs2]\n    ocfs2_search_chain [ocfs2]\n    ocfs2_claim_suballoc_bits [ocfs2]\n    __ocfs2_claim_clusters [ocfs2]\n    ocfs2_claim_clusters [ocfs2]\n    ocfs2_local_alloc_slide_window [ocfs2]\n    ocfs2_reserve_local_alloc_bits [ocfs2]\n    ocfs2_reserve_clusters_with_limit [ocfs2]\n    ocfs2_reserve_clusters [ocfs2]\n    ocfs2_lock_refcount_allocators [ocfs2]\n    ocfs2_make_clusters_writable [ocfs2]\n    ocfs2_replace_cow [ocfs2]\n    ocfs2_refcount_cow [ocfs2]\n    ocfs2_file_write_iter [ocfs2]\n    lo_rw_aio\n    loop_queue_work\n    kthread_worker_fn\n    kthread\n    ret_from_fork\r\n\r\nWhen ocfs2_test_bg_bit_allocatable() called bh2jh(bg_bh), the\nbg_bh-\u0026gt;b_private NULL as jbd2_journal_put_journal_head() raced and\nreleased the jounal head from the buffer head.  Needed to take bit lock\nfor the bit \u0026apos;BH_JournalHead\u0026apos; to fix this race.(CVE-2021-47493)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\niio: mma8452: Fix trigger reference couting\r\n\r\nThe mma8452 driver directly assigns a trigger to the struct iio_dev. The\nIIO core when done using this trigger will call `iio_trigger_put()` to drop\nthe reference count by 1.\r\n\r\nWithout the matching `iio_trigger_get()` in the driver the reference count\ncan reach 0 too early, the trigger gets freed while still in use and a\nuse-after-free occurs.\r\n\r\nFix this by getting a reference to the trigger before assigning it to the\nIIO device.(CVE-2021-47500)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncan: sja1000: fix use after free in ems_pcmcia_add_card()\r\n\r\nIf the last channel is not available then \u0026quot;dev\u0026quot; is freed.  Fortunately,\nwe can just use \u0026quot;pdev-\u0026gt;irq\u0026quot; instead.\r\n\r\nAlso we should check if at least one channel was set up.(CVE-2021-47521)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: mpt3sas: Fix kernel panic during drive powercycle test\r\n\r\nWhile looping over shost\u0026apos;s sdev list it is possible that one\nof the drives is getting removed and its sas_target object is\nfreed but its sdev object remains intact.\r\n\r\nConsequently, a kernel panic can occur while the driver is trying to access\nthe sas_address field of sas_target object without also checking the\nsas_target object for NULL.(CVE-2021-47565)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ninet_diag: fix kernel-infoleak for UDP sockets\r\n\r\nKMSAN reported a kernel-infoleak [1], that can exploited\nby unpriv users.\r\n\r\nAfter analysis it turned out UDP was not initializing\nr-\u0026gt;idiag_expires. Other users of inet_sk_diag_fill()\nmight make the same mistake in the future, so fix this\nin inet_sk_diag_fill().\r\n\r\n[1]\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:156 [inline]\nBUG: KMSAN: kernel-infoleak in _copy_to_iter+0x69d/0x25c0 lib/iov_iter.c:670\n instrument_copy_to_user include/linux/instrumented.h:121 [inline]\n copyout lib/iov_iter.c:156 [inline]\n _copy_to_iter+0x69d/0x25c0 lib/iov_iter.c:670\n copy_to_iter include/linux/uio.h:155 [inline]\n simple_copy_to_iter+0xf3/0x140 net/core/datagram.c:519\n __skb_datagram_iter+0x2cb/0x1280 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:3657 [inline]\n netlink_recvmsg+0x660/0x1c60 net/netlink/af_netlink.c:1974\n sock_recvmsg_nosec net/socket.c:944 [inline]\n sock_recvmsg net/socket.c:962 [inline]\n sock_read_iter+0x5a9/0x630 net/socket.c:1035\n call_read_iter include/linux/fs.h:2156 [inline]\n new_sync_read fs/read_write.c:400 [inline]\n vfs_read+0x1631/0x1980 fs/read_write.c:481\n ksys_read+0x28c/0x520 fs/read_write.c:619\n __do_sys_read fs/read_write.c:629 [inline]\n __se_sys_read fs/read_write.c:627 [inline]\n __x64_sys_read+0xdb/0x120 fs/read_write.c:627\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:524 [inline]\n slab_alloc_node mm/slub.c:3251 [inline]\n __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974\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:1126 [inline]\n netlink_dump+0x3d5/0x16a0 net/netlink/af_netlink.c:2245\n __netlink_dump_start+0xd1c/0xee0 net/netlink/af_netlink.c:2370\n netlink_dump_start include/linux/netlink.h:254 [inline]\n inet_diag_handler_cmd+0x2e7/0x400 net/ipv4/inet_diag.c:1343\n sock_diag_rcv_msg+0x24a/0x620\n netlink_rcv_skb+0x447/0x800 net/netlink/af_netlink.c:2491\n sock_diag_rcv+0x63/0x80 net/core/sock_diag.c:276\n netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]\n netlink_unicast+0x1095/0x1360 net/netlink/af_netlink.c:1345\n netlink_sendmsg+0x16f3/0x1870 net/netlink/af_netlink.c:1916\n sock_sendmsg_nosec net/socket.c:704 [inline]\n sock_sendmsg net/socket.c:724 [inline]\n sock_write_iter+0x594/0x690 net/socket.c:1057\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+0x63f/0xe30 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 312 are uninitialized\nMemory access of size 312 starts at ffff88812ab54000\nData copied to user address 0000000020001440\r\n\r\nCPU: 1 PID: 6365 Comm: syz-executor801 Not tainted 5.16.0-rc3-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011(CVE-2021-47597)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfirmware: arm_scpi: Fix string overflow in SCPI genpd driver\r\n\r\nWithout the bound checks for scpi_pd-\u0026gt;name, it could result in the buffer\noverflow when copying the SCPI device name from the corresponding device\ntree node as the name string is set at maximum size of 30.\r\n\r\nLet us fix it by using devm_kasprintf so that the string buffer is\nallocated dynamically.(CVE-2021-47609)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nASoC: ops: Reject out of bounds values in snd_soc_put_volsw_sx()\r\n\r\nWe don\u0026apos;t currently validate that the values being set are within the range\nwe advertised to userspace as being valid, do so and reject any values\nthat are out of range.(CVE-2022-48737)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npowerpc64/bpf: Limit \u0026apos;ldbrx\u0026apos; to processors compliant with ISA v2.06\r\n\r\nJohan reported the below crash with test_bpf on ppc64 e5500:\r\n\r\n  test_bpf: #296 ALU_END_FROM_LE 64: 0x0123456789abcdef -\u0026gt; 0x67452301 jited:1\n  Oops: Exception in kernel mode, sig: 4 [#1]\n  BE PAGE_SIZE=4K SMP NR_CPUS=24 QEMU e500\n  Modules linked in: test_bpf(+)\n  CPU: 0 PID: 76 Comm: insmod Not tainted 5.14.0-03771-g98c2059e008a-dirty #1\n  NIP:  8000000000061c3c LR: 80000000006dea64 CTR: 8000000000061c18\n  REGS: c0000000032d3420 TRAP: 0700   Not tainted (5.14.0-03771-g98c2059e008a-dirty)\n  MSR:  0000000080089000 \u0026lt;EE,ME\u0026gt;  CR: 88002822  XER: 20000000 IRQMASK: 0\n  \u0026lt;...\u0026gt;\n  NIP [8000000000061c3c] 0x8000000000061c3c\n  LR [80000000006dea64] .__run_one+0x104/0x17c [test_bpf]\n  Call Trace:\n   .__run_one+0x60/0x17c [test_bpf] (unreliable)\n   .test_bpf_init+0x6a8/0xdc8 [test_bpf]\n   .do_one_initcall+0x6c/0x28c\n   .do_init_module+0x68/0x28c\n   .load_module+0x2460/0x2abc\n   .__do_sys_init_module+0x120/0x18c\n   .system_call_exception+0x110/0x1b8\n   system_call_common+0xf0/0x210\n  --- interrupt: c00 at 0x101d0acc\n  \u0026lt;...\u0026gt;\n  ---[ end trace 47b2bf19090bb3d0 ]---\r\n\r\n  Illegal instruction\r\n\r\nThe illegal instruction turned out to be \u0026apos;ldbrx\u0026apos; emitted for\nBPF_FROM_[L|B]E, which was only introduced in ISA v2.06. Guard use of\nthe same and implement an alternative approach for older processors.(CVE-2022-48755)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/msm/dsi: invalid parameter check in msm_dsi_phy_enable\r\n\r\nThe function performs a check on the \u0026quot;phy\u0026quot; input parameter, however, it\nis used before the check.\r\n\r\nInitialize the \u0026quot;dev\u0026quot; variable after the sanity check to avoid a possible\nNULL pointer dereference.\r\n\r\nAddresses-Coverity-ID: 1493860 (\u0026quot;Null pointer dereference\u0026quot;)(CVE-2022-48756)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nrpmsg: virtio: Free driver_override when rpmsg_remove()\r\n\r\nFree driver_override when rpmsg_remove(), otherwise\nthe following memory leak will occur:\r\n\r\nunreferenced object 0xffff0000d55d7080 (size 128):\n  comm \u0026quot;kworker/u8:2\u0026quot;, pid 56, jiffies 4294893188 (age 214.272s)\n  hex dump (first 32 bytes):\n    72 70 6d 73 67 5f 6e 73 00 00 00 00 00 00 00 00  rpmsg_ns........\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n  backtrace:\n    [\u0026lt;000000009c94c9c1\u0026gt;] __kmem_cache_alloc_node+0x1f8/0x320\n    [\u0026lt;000000002300d89b\u0026gt;] __kmalloc_node_track_caller+0x44/0x70\n    [\u0026lt;00000000228a60c3\u0026gt;] kstrndup+0x4c/0x90\n    [\u0026lt;0000000077158695\u0026gt;] driver_set_override+0xd0/0x164\n    [\u0026lt;000000003e9c4ea5\u0026gt;] rpmsg_register_device_override+0x98/0x170\n    [\u0026lt;000000001c0c89a8\u0026gt;] rpmsg_ns_register_device+0x24/0x30\n    [\u0026lt;000000008bbf8fa2\u0026gt;] rpmsg_probe+0x2e0/0x3ec\n    [\u0026lt;00000000e65a68df\u0026gt;] virtio_dev_probe+0x1c0/0x280\n    [\u0026lt;00000000443331cc\u0026gt;] really_probe+0xbc/0x2dc\n    [\u0026lt;00000000391064b1\u0026gt;] __driver_probe_device+0x78/0xe0\n    [\u0026lt;00000000a41c9a5b\u0026gt;] driver_probe_device+0xd8/0x160\n    [\u0026lt;000000009c3bd5df\u0026gt;] __device_attach_driver+0xb8/0x140\n    [\u0026lt;0000000043cd7614\u0026gt;] bus_for_each_drv+0x7c/0xd4\n    [\u0026lt;000000003b929a36\u0026gt;] __device_attach+0x9c/0x19c\n    [\u0026lt;00000000a94e0ba8\u0026gt;] device_initial_probe+0x14/0x20\n    [\u0026lt;000000003c999637\u0026gt;] bus_probe_device+0xa0/0xac(CVE-2023-52670)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nFix page corruption caused by racy check in __free_pages\r\n\r\nWhen we upgraded our kernel, we started seeing some page corruption like\nthe following consistently:\r\n\r\n  BUG: Bad page state in process ganesha.nfsd  pfn:1304ca\n  page:0000000022261c55 refcount:0 mapcount:-128 mapping:0000000000000000 index:0x0 pfn:0x1304ca\n  flags: 0x17ffffc0000000()\n  raw: 0017ffffc0000000 ffff8a513ffd4c98 ffffeee24b35ec08 0000000000000000\n  raw: 0000000000000000 0000000000000001 00000000ffffff7f 0000000000000000\n  page dumped because: nonzero mapcount\n  CPU: 0 PID: 15567 Comm: ganesha.nfsd Kdump: loaded Tainted: P    B      O      5.10.158-1.nutanix.20221209.el7.x86_64 #1\n  Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 04/05/2016\n  Call Trace:\n   dump_stack+0x74/0x96\n   bad_page.cold+0x63/0x94\n   check_new_page_bad+0x6d/0x80\n   rmqueue+0x46e/0x970\n   get_page_from_freelist+0xcb/0x3f0\n   ? _cond_resched+0x19/0x40\n   __alloc_pages_nodemask+0x164/0x300\n   alloc_pages_current+0x87/0xf0\n   skb_page_frag_refill+0x84/0x110\n   ...\r\n\r\nSometimes, it would also show up as corruption in the free list pointer\nand cause crashes.\r\n\r\nAfter bisecting the issue, we found the issue started from commit\ne320d3012d25 (\u0026quot;mm/page_alloc.c: fix freeing non-compound pages\u0026quot;):\r\n\r\n\tif (put_page_testzero(page))\n\t\tfree_the_page(page, order);\n\telse if (!PageHead(page))\n\t\twhile (order-- \u0026gt; 0)\n\t\t\tfree_the_page(page + (1 \u0026lt;\u0026lt; order), order);\r\n\r\nSo the problem is the check PageHead is racy because at this point we\nalready dropped our reference to the page.  So even if we came in with\ncompound page, the page can already be freed and PageHead can return\nfalse and we will end up freeing all the tail pages causing double free.(CVE-2023-52739)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\natl1c: Work around the DMA RX overflow issue\r\n\r\nThis is based on alx driver commit 881d0327db37 (\u0026quot;net: alx: Work around\nthe DMA RX overflow issue\u0026quot;).\r\n\r\nThe alx and atl1c drivers had RX overflow error which was why a custom\nallocator was created to avoid certain addresses. The simpler workaround\nthen created for alx driver, but not for atl1c due to lack of tester.\r\n\r\nInstead of using a custom allocator, check the allocated skb address and\nuse skb_reserve() to move away from problematic 0x...fc0 address.\r\n\r\nTested on AR8131 on Acer 4540.(CVE-2023-52834)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhid: cp2112: Fix duplicate workqueue initialization\r\n\r\nPreviously the cp2112 driver called INIT_DELAYED_WORK within\ncp2112_gpio_irq_startup, resulting in duplicate initilizations of the\nworkqueue on subsequent IRQ startups following an initial request. This\nresulted in a warning in set_work_data in workqueue.c, as well as a rare\nNULL dereference within process_one_work in workqueue.c.\r\n\r\nInitialize the workqueue within _probe instead.(CVE-2023-52853)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: usb-audio: Stop parsing channels bits when all channels are found.\r\n\r\nIf a usb audio device sets more bits than the amount of channels\nit could write outside of the map array.(CVE-2024-27436)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: tc358743: register v4l2 async device only after successful setup\r\n\r\nEnsure the device has been setup correctly before registering the v4l2\nasync device, thus allowing userspace to access.(CVE-2024-35830)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: gadget: f_fs: Fix race between aio_cancel() and AIO request complete\r\n\r\nFFS based applications can utilize the aio_cancel() callback to dequeue\npending USB requests submitted to the UDC.  There is a scenario where the\nFFS application issues an AIO cancel call, while the UDC is handling a\nsoft disconnect.  For a DWC3 based implementation, the callstack looks\nlike the following:\r\n\r\n    DWC3 Gadget                               FFS Application\ndwc3_gadget_soft_disconnect()              ...\n  --\u0026gt; dwc3_stop_active_transfers()\n    --\u0026gt; dwc3_gadget_giveback(-ESHUTDOWN)\n      --\u0026gt; ffs_epfile_async_io_complete()   ffs_aio_cancel()\n        --\u0026gt; usb_ep_free_request()            --\u0026gt; usb_ep_dequeue()\r\n\r\nThere is currently no locking implemented between the AIO completion\nhandler and AIO cancel, so the issue occurs if the completion routine is\nrunning in parallel to an AIO cancel call coming from the FFS application.\nAs the completion call frees the USB request (io_data-\u0026gt;req) the FFS\napplication is also referencing it for the usb_ep_dequeue() call.  This can\nlead to accessing a stale/hanging pointer.\r\n\r\ncommit b566d38857fc (\u0026quot;usb: gadget: f_fs: use io_data-\u0026gt;status consistently\u0026quot;)\nrelocated the usb_ep_free_request() into ffs_epfile_async_io_complete().\nHowever, in order to properly implement locking to mitigate this issue, the\nspinlock can\u0026apos;t be added to ffs_epfile_async_io_complete(), as\nusb_ep_dequeue() (if successfully dequeuing a USB request) will call the\nfunction driver\u0026apos;s completion handler in the same context.  Hence, leading\ninto a deadlock.\r\n\r\nFix this issue by moving the usb_ep_free_request() back to\nffs_user_copy_worker(), and ensuring that it explicitly sets io_data-\u0026gt;req\nto NULL after freeing it within the ffs-\u0026gt;eps_lock.  This resolves the race\ncondition above, as the ffs_aio_cancel() routine will not continue\nattempting to dequeue a request that has already been freed, or the\nffs_user_copy_work() not freeing the USB request until the AIO cancel is\ndone referencing it.\r\n\r\nThis fix depends on\n  commit b566d38857fc (\u0026quot;usb: gadget: f_fs: use io_data-\u0026gt;status\n  consistently\u0026quot;)(CVE-2024-36894)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: nl80211: don\u0026apos;t free NULL coalescing rule\r\n\r\nIf the parsing fails, we can dereference a NULL pointer here.(CVE-2024-36941)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfirewire: ohci: mask bus reset interrupts between ISR and bottom half\r\n\r\nIn the FireWire OHCI interrupt handler, if a bus reset interrupt has\noccurred, mask bus reset interrupts until bus_reset_work has serviced and\ncleared the interrupt.\r\n\r\nNormally, we always leave bus reset interrupts masked. We infer the bus\nreset from the self-ID interrupt that happens shortly thereafter. A\nscenario where we unmask bus reset interrupts was introduced in 2008 in\na007bb857e0b26f5d8b73c2ff90782d9c0972620: If\nOHCI_PARAM_DEBUG_BUSRESETS (8) is set in the debug parameter bitmask, we\nwill unmask bus reset interrupts so we can log them.\r\n\r\nirq_handler logs the bus reset interrupt. However, we can\u0026apos;t clear the bus\nreset event flag in irq_handler, because we won\u0026apos;t service the event until\nlater. irq_handler exits with the event flag still set. If the\ncorresponding interrupt is still unmasked, the first bus reset will\nusually freeze the system due to irq_handler being called again each\ntime it exits. This freeze can be reproduced by loading firewire_ohci\nwith \u0026quot;modprobe firewire_ohci debug=-1\u0026quot; (to enable all debugging output).\nApparently there are also some cases where bus_reset_work will get called\nsoon enough to clear the event, and operation will continue normally.\r\n\r\nThis freeze was first reported a few months after a007bb85 was committed,\nbut until now it was never fixed. The debug level could safely be set\nto -1 through sysfs after the module was loaded, but this would be\nineffectual in logging bus reset interrupts since they were only\nunmasked during initialization.\r\n\r\nirq_handler will now leave the event flag set but mask bus reset\ninterrupts, so irq_handler won\u0026apos;t be called again and there will be no\nfreeze. If OHCI_PARAM_DEBUG_BUSRESETS is enabled, bus_reset_work will\nunmask the interrupt after servicing the event, so future interrupts\nwill be caught as desired.\r\n\r\nAs a side effect to this change, OHCI_PARAM_DEBUG_BUSRESETS can now be\nenabled through sysfs in addition to during initial module loading.\nHowever, when enabled through sysfs, logging of bus reset interrupts will\nbe effective only starting with the second bus reset, after\nbus_reset_work has executed.(CVE-2024-36950)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: fix __dst_negative_advice() race\r\n\r\n__dst_negative_advice() does not enforce proper RCU rules when\nsk-\u0026gt;dst_cache must be cleared, leading to possible UAF.\r\n\r\nRCU rules are that we must first clear sk-\u0026gt;sk_dst_cache,\nthen call dst_release(old_dst).\r\n\r\nNote that sk_dst_reset(sk) is implementing this protocol correctly,\nwhile __dst_negative_advice() uses the wrong order.\r\n\r\nGiven that ip6_negative_advice() has special logic\nagainst RTF_CACHE, this means each of the three -\u0026gt;negative_advice()\nexisting methods must perform the sk_dst_reset() themselves.\r\n\r\nNote the check against NULL dst is centralized in\n__dst_negative_advice(), there is no need to duplicate\nit in various callbacks.\r\n\r\nMany thanks to Clement Lecigne for tracking this issue.\r\n\r\nThis old bug became visible after the blamed commit, using UDP sockets.(CVE-2024-36971)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: bridge: xmit: make sure we have at least eth header len bytes\r\n\r\nsyzbot triggered an uninit value[1] error in bridge device\u0026apos;s xmit path\nby sending a short (less than ETH_HLEN bytes) skb. To fix it check if\nwe can actually pull that amount instead of assuming.\r\n\r\nTested with dropwatch:\n drop at: br_dev_xmit+0xb93/0x12d0 [bridge] (0xffffffffc06739b3)\n origin: software\n timestamp: Mon May 13 11:31:53 2024 778214037 nsec\n protocol: 0x88a8\n length: 2\n original length: 2\n drop reason: PKT_TOO_SMALL\r\n\r\n[1]\nBUG: KMSAN: uninit-value in br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65\n br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65\n __netdev_start_xmit include/linux/netdevice.h:4903 [inline]\n netdev_start_xmit include/linux/netdevice.h:4917 [inline]\n xmit_one net/core/dev.c:3531 [inline]\n dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547\n __dev_queue_xmit+0x34db/0x5350 net/core/dev.c:4341\n dev_queue_xmit include/linux/netdevice.h:3091 [inline]\n __bpf_tx_skb net/core/filter.c:2136 [inline]\n __bpf_redirect_common net/core/filter.c:2180 [inline]\n __bpf_redirect+0x14a6/0x1620 net/core/filter.c:2187\n ____bpf_clone_redirect net/core/filter.c:2460 [inline]\n bpf_clone_redirect+0x328/0x470 net/core/filter.c:2432\n ___bpf_prog_run+0x13fe/0xe0f0 kernel/bpf/core.c:1997\n __bpf_prog_run512+0xb5/0xe0 kernel/bpf/core.c:2238\n bpf_dispatcher_nop_func include/linux/bpf.h:1234 [inline]\n __bpf_prog_run include/linux/filter.h:657 [inline]\n bpf_prog_run include/linux/filter.h:664 [inline]\n bpf_test_run+0x499/0xc30 net/bpf/test_run.c:425\n bpf_prog_test_run_skb+0x14ea/0x1f20 net/bpf/test_run.c:1058\n bpf_prog_test_run+0x6b7/0xad0 kernel/bpf/syscall.c:4269\n __sys_bpf+0x6aa/0xd90 kernel/bpf/syscall.c:5678\n __do_sys_bpf kernel/bpf/syscall.c:5767 [inline]\n __se_sys_bpf kernel/bpf/syscall.c:5765 [inline]\n __x64_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5765\n x64_sys_call+0x96b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:322\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-38538)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nof: module: add buffer overflow check in of_modalias()\r\n\r\nIn of_modalias(), if the buffer happens to be too small even for the 1st\nsnprintf() call, the len parameter will become negative and str parameter\n(if not NULL initially) will point beyond the buffer\u0026apos;s end. Add the buffer\noverflow check after the 1st snprintf() call and fix such check after the\nstrlen() call (accounting for the terminating NUL char).(CVE-2024-38541)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Fix potential index out of bounds in color transformation function\r\n\r\nFixes index out of bounds issue in the color transformation function.\nThe issue could occur when the index \u0026apos;i\u0026apos; exceeds the number of transfer\nfunction points (TRANSFER_FUNC_POINTS).\r\n\r\nThe fix adds a check to ensure \u0026apos;i\u0026apos; is within bounds before accessing the\ntransfer function points. If \u0026apos;i\u0026apos; is out of bounds, an error message is\nlogged and the function returns false to indicate an error.\r\n\r\nReported by smatch:\ndrivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:405 cm_helper_translate_curve_to_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.red\u0026apos; 1025 \u0026lt;= s32max\ndrivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:406 cm_helper_translate_curve_to_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.green\u0026apos; 1025 \u0026lt;= s32max\ndrivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:407 cm_helper_translate_curve_to_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.blue\u0026apos; 1025 \u0026lt;= s32max(CVE-2024-38552)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nftrace: Fix possible use-after-free issue in ftrace_location()\r\n\r\nKASAN reports a bug:\r\n\r\n  BUG: KASAN: use-after-free in ftrace_location+0x90/0x120\n  Read of size 8 at addr ffff888141d40010 by task insmod/424\n  CPU: 8 PID: 424 Comm: insmod Tainted: G        W          6.9.0-rc2+\n  [...]\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   dump_stack_lvl+0x68/0xa0\n   print_report+0xcf/0x610\n   kasan_report+0xb5/0xe0\n   ftrace_location+0x90/0x120\n   register_kprobe+0x14b/0xa40\n   kprobe_init+0x2d/0xff0 [kprobe_example]\n   do_one_initcall+0x8f/0x2d0\n   do_init_module+0x13a/0x3c0\n   load_module+0x3082/0x33d0\n   init_module_from_file+0xd2/0x130\n   __x64_sys_finit_module+0x306/0x440\n   do_syscall_64+0x68/0x140\n   entry_SYSCALL_64_after_hwframe+0x71/0x79\r\n\r\nThe root cause is that, in lookup_rec(), ftrace record of some address\nis being searched in ftrace pages of some module, but those ftrace pages\nat the same time is being freed in ftrace_release_mod() as the\ncorresponding module is being deleted:\r\n\r\n           CPU1                       |      CPU2\n  register_kprobes() {                | delete_module() {\n    check_kprobe_address_safe() {     |\n      arch_check_ftrace_location() {  |\n        ftrace_location() {           |\n          lookup_rec() // USE!        |   ftrace_release_mod() // Free!\r\n\r\nTo fix this issue:\n  1. Hold rcu lock as accessing ftrace pages in ftrace_location_range();\n  2. Use ftrace_location_range() instead of lookup_rec() in\n     ftrace_location();\n  3. Call synchronize_rcu() before freeing any ftrace pages both in\n     ftrace_process_locs()/ftrace_release_mod()/ftrace_free_mem().(CVE-2024-38588)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\naf_unix: Fix data races in unix_release_sock/unix_stream_sendmsg\r\n\r\nA data-race condition has been identified in af_unix. In one data path,\nthe write function unix_release_sock() atomically writes to\nsk-\u0026gt;sk_shutdown using WRITE_ONCE. However, on the reader side,\nunix_stream_sendmsg() does not read it atomically. Consequently, this\nissue is causing the following KCSAN splat to occur:\r\n\r\n\tBUG: KCSAN: data-race in unix_release_sock / unix_stream_sendmsg\r\n\r\n\twrite (marked) to 0xffff88867256ddbb of 1 bytes by task 7270 on cpu 28:\n\tunix_release_sock (net/unix/af_unix.c:640)\n\tunix_release (net/unix/af_unix.c:1050)\n\tsock_close (net/socket.c:659 net/socket.c:1421)\n\t__fput (fs/file_table.c:422)\n\t__fput_sync (fs/file_table.c:508)\n\t__se_sys_close (fs/open.c:1559 fs/open.c:1541)\n\t__x64_sys_close (fs/open.c:1541)\n\tx64_sys_call (arch/x86/entry/syscall_64.c:33)\n\tdo_syscall_64 (arch/x86/entry/common.c:?)\n\tentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\r\n\r\n\tread to 0xffff88867256ddbb of 1 bytes by task 989 on cpu 14:\n\tunix_stream_sendmsg (net/unix/af_unix.c:2273)\n\t__sock_sendmsg (net/socket.c:730 net/socket.c:745)\n\t____sys_sendmsg (net/socket.c:2584)\n\t__sys_sendmmsg (net/socket.c:2638 net/socket.c:2724)\n\t__x64_sys_sendmmsg (net/socket.c:2753 net/socket.c:2750 net/socket.c:2750)\n\tx64_sys_call (arch/x86/entry/syscall_64.c:33)\n\tdo_syscall_64 (arch/x86/entry/common.c:?)\n\tentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\r\n\r\n\tvalue changed: 0x01 -\u0026gt; 0x03\r\n\r\nThe line numbers are related to commit dd5a440a31fa (\u0026quot;Linux 6.9-rc7\u0026quot;).\r\n\r\nCommit e1d09c2c2f57 (\u0026quot;af_unix: Fix data races around sk-\u0026gt;sk_shutdown.\u0026quot;)\naddressed a comparable issue in the past regarding sk-\u0026gt;sk_shutdown.\nHowever, it overlooked resolving this particular data path.\nThis patch only offending unix_stream_sendmsg() function, since the\nother reads seem to be protected by unix_state_lock() as discussed in(CVE-2024-38596)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmacintosh/via-macii: Fix \u0026quot;BUG: sleeping function called from invalid context\u0026quot;\r\n\r\nThe via-macii ADB driver calls request_irq() after disabling hard\ninterrupts. But disabling interrupts isn\u0026apos;t necessary here because the\nVIA shift register interrupt was masked during VIA1 initialization.(CVE-2024-38607)",
  "id": "OESA-2024-1767",
  "modified": "2026-08-06T11:07:14Z",
  "published": "2024-06-28T11:07:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1767"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47231"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47232"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47252"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47288"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47346"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47347"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47434"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47466"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47469"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47493"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47500"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47521"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47565"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47597"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47609"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48737"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48755"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48756"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52670"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52739"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52834"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52853"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27436"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35830"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36894"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36941"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36950"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36971"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38538"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38541"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38552"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38588"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38596"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38607"
    }
  ],
  "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-47231",
    "CVE-2021-47232",
    "CVE-2021-47252",
    "CVE-2021-47288",
    "CVE-2021-47346",
    "CVE-2021-47347",
    "CVE-2021-47434",
    "CVE-2021-47466",
    "CVE-2021-47469",
    "CVE-2021-47493",
    "CVE-2021-47500",
    "CVE-2021-47521",
    "CVE-2021-47565",
    "CVE-2021-47597",
    "CVE-2021-47609",
    "CVE-2022-48737",
    "CVE-2022-48755",
    "CVE-2022-48756",
    "CVE-2023-52670",
    "CVE-2023-52739",
    "CVE-2023-52834",
    "CVE-2023-52853",
    "CVE-2024-27436",
    "CVE-2024-35830",
    "CVE-2024-36894",
    "CVE-2024-36941",
    "CVE-2024-36950",
    "CVE-2024-36971",
    "CVE-2024-38538",
    "CVE-2024-38541",
    "CVE-2024-38552",
    "CVE-2024-38588",
    "CVE-2024-38596",
    "CVE-2024-38607"
  ]
}

OESA-2024-1768 (CVE-2021-47381)

Vulnerability from osv_openeuler – Published: 2024-06-28 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:

ASoC: SOF: Fix DSP oops stack dump output contents

Fix @buf arg given to hex_dump_to_buffer() and stack address used in dump error output.(CVE-2021-47381)

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

scsi: iscsi: Fix iscsi_task use after free

Commit d39df158518c ("scsi: iscsi: Have abort handler get ref to conn") added iscsi_get_conn()/iscsi_put_conn() calls during abort handling but then also changed the handling of the case where we detect an already completed task where we now end up doing a goto to the common put/cleanup code. This results in a iscsi_task use after free, because the common cleanup code will do a put on the iscsi_task.

This reverts the goto and moves the iscsi_get_conn() to after we've checked if the iscsi_task is valid.(CVE-2021-47427)

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

spi: Fix deadlock when adding SPI controllers on SPI buses

This can be easily triggered in the case of spi-mux.(CVE-2021-47469)

(CVE-2023-39180)

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

powerpc/powernv: Add a null pointer check in opal_powercap_init()

kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure.(CVE-2023-52696)

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

i2c: core: Run atomic i2c xfer when !preemptible

Since bae1d3a05a8b, i2c transfers are non-atomic if preemption is disabled. However, non-atomic i2c transfers require preemption (e.g. in wait_for_completion() while waiting for the DMA).

panic() calls preempt_disable_notrace() before calling emergency_restart(). Therefore, if an i2c device is used for the restart, the xfer should be atomic. This avoids warnings like:

[ 12.667612] WARNING: CPU: 1 PID: 1 at kernel/rcu/tree_plugin.h:318 rcu_note_context_switch+0x33c/0x6b0 [ 12.676926] Voluntary context switch within RCU read-side critical section! ... [ 12.742376] schedule_timeout from wait_for_completion_timeout+0x90/0x114 [ 12.749179] wait_for_completion_timeout from tegra_i2c_wait_completion+0x40/0x70 ... [ 12.994527] atomic_notifier_call_chain from machine_restart+0x34/0x58 [ 13.001050] machine_restart from panic+0x2a8/0x32c

Use !preemptible() instead, which is basically the same check as pre-v5.2.(CVE-2023-52791)

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

hid: cp2112: Fix duplicate workqueue initialization

Initialize the workqueue within _probe instead.(CVE-2023-52853)

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

ksmbd: fix UAF issue in ksmbd_tcp_new_connection()

The race is between the handling of a new TCP connection and its disconnection. It leads to UAF on struct tcp_transport in ksmbd_tcp_new_connection() function.(CVE-2024-26592)

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

net/ipv6: avoid possible UAF in ip6_route_mpath_notify()

syzbot found another use-after-free in ip6_route_mpath_notify() [1]

Commit f7225172f25a ("net/ipv6: prevent use after free in ip6_route_mpath_notify") was not able to fix the root cause.

We need to defer the fib6_info_release() calls after ip6_route_mpath_notify(), in the cleanup phase.

[1] BUG: KASAN: slab-use-after-free in rt6_fill_node+0x1460/0x1ac0 Read of size 4 at addr ffff88809a07fc64 by task syz-executor.2/23037

CPU: 0 PID: 23037 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-01035-gea7f3cfaa588 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e7/0x2e0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:377 [inline] print_report+0x167/0x540 mm/kasan/report.c:488 kasan_report+0x142/0x180 mm/kasan/report.c:601 rt6_fill_node+0x1460/0x1ac0 inet6_rt_notify+0x13b/0x290 net/ipv6/route.c:6184 ip6_route_mpath_notify net/ipv6/route.c:5198 [inline] ip6_route_multipath_add net/ipv6/route.c:5404 [inline] inet6_rtm_newroute+0x1d0f/0x2300 net/ipv6/route.c:5517 rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367 netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 _syssendmsg+0x525/0x7d0 net/socket.c:2584 _sys_sendmsg net/socket.c:2638 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667 do_syscall_64+0xf9/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77 RIP: 0033:0x7f73dd87dda9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f73de6550c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f73dd9ac050 RCX: 00007f73dd87dda9 RDX: 0000000000000000 RSI: 0000000020000140 RDI: 0000000000000005 RBP: 00007f73dd8ca47a R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000006e R14: 00007f73dd9ac050 R15: 00007ffdbdeb7858 </TASK>

Allocated by task 23037: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:372 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:389 kasan_kmalloc include/linux/kasan.h:211 [inline] __do_kmalloc_node mm/slub.c:3981 [inline] __kmalloc+0x22e/0x490 mm/slub.c:3994 kmalloc include/linux/slab.h:594 [inline] kzalloc include/linux/slab.h:711 [inline] fib6_info_alloc+0x2e/0xf0 net/ipv6/ip6_fib.c:155 ip6_route_info_create+0x445/0x12b0 net/ipv6/route.c:3758 ip6_route_multipath_add net/ipv6/route.c:5298 [inline] inet6_rtm_newroute+0x744/0x2300 net/ipv6/route.c:5517 rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597 netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367 netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 _syssendmsg+0x525/0x7d0 net/socket.c:2584 _sys_sendmsg net/socket.c:2638 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667 do_syscall_64+0xf9/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77

Freed by task 16: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x4e/0x60 mm/kasan/generic.c:640 poison_slab_object+0xa6/0xe0 m ---truncated---(CVE-2024-26852)

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

inet: inet_defrag: prevent sk release while still in use

ip_local_out() and other functions can pass skb->sk as function argument.

If the skb is a fragment and reassembly happens before such function call returns, the sk must not be released.

This affects skb fragments reassembled via netfilter or similar modules, e.g. openvswitch or ct_act.c, when run as part of tx pipeline.

Eric Dumazet made an initial analysis of this bug. Quoting Eric: Calling ip_defrag() in output path is also implying skb_orphan(), which is buggy because output path relies on sk not disappearing.

A relevant old patch about the issue was : 8282f27449bf ("inet: frag: Always orphan skbs inside ip_defrag()")

[..]

net/ipv4/ip_output.c depends on skb->sk being set, and probably to an inet socket, not an arbitrary one.

If we orphan the packet in ipvlan, then downstream things like FQ packet scheduler will not work properly.

We need to change ip_defrag() to only use skb_orphan() when really needed, ie whenever frag_list is going to be used.

Eric suggested to stash sk in fragment queue and made an initial patch. However there is a problem with this:

If skb is refragmented again right after, ip_do_fragment() will copy head->sk to the new fragments, and sets up destructor to sock_wfree. IOW, we have no choice but to fix up sk_wmem accouting to reflect the fully reassembled skb, else wmem will underflow.

This change moves the orphan down into the core, to last possible moment. As ip_defrag_offset is aliased with sk_buff->sk member, we must move the offset into the FRAG_CB, else skb->sk gets clobbered.

This allows to delay the orphaning long enough to learn if the skb has to be queued or if the skb is completing the reasm queue.

In the former case, things work as before, skb is orphaned. This is safe because skb gets queued/stolen and won't continue past reasm engine.

In the latter case, we will steal the skb->sk reference, reattach it to the head skb, and fix up wmem accouting when inet_frag inflates truesize.(CVE-2024-26921)

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

scsi: core: Fix unremoved procfs host directory regression

Commit fc663711b944 ("scsi: core: Remove the /proc/scsi/${proc_name} directory earlier") fixed a bug related to modules loading/unloading, by adding a call to scsi_proc_hostdir_rm() on scsi_remove_host(). But that led to a potential duplicate call to the hostdir_rm() routine, since it's also called from scsi_host_dev_release(). That triggered a regression report, which was then fixed by commit be03df3d4bfe ("scsi: core: Fix a procfs host directory removal regression"). The fix just dropped the hostdir_rm() call from dev_release().

But it happens that this proc directory is created on scsi_host_alloc(), and that function "pairs" with scsi_host_dev_release(), while scsi_remove_host() pairs with scsi_add_host(). In other words, it seems the reason for removing the proc directory on dev_release() was meant to cover cases in which a SCSI host structure was allocated, but the call to scsi_add_host() didn't happen. And that pattern happens to exist in some error paths, for example.

Syzkaller causes that by using USB raw gadget device, error'ing on usb-storage driver, at usb_stor_probe2(). By checking that path, we can see that the BadDevice label leads to a scsi_host_put() after a SCSI host allocation, but there's no call to scsi_add_host() in such path. That leads to messages like this in dmesg (and a leak of the SCSI host proc structure):

usb-storage 4-1:87.51: USB Mass Storage device detected proc_dir_entry 'scsi/usb-storage' already registered WARNING: CPU: 1 PID: 3519 at fs/proc/generic.c:377 proc_register+0x347/0x4e0 fs/proc/generic.c:376

The proper fix seems to still call scsi_proc_hostdir_rm() on dev_release(), but guard that with the state check for SHOST_CREATED; there is even a comment in scsi_host_dev_release() detailing that: such conditional is meant for cases where the SCSI host was allocated but there was no calls to {add,remove}_host(), like the usb-storage case.

This is what we propose here and with that, the error path of usb-storage does not trigger the warning anymore.(CVE-2024-26935)

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

init/main.c: Fix potential static_command_line memory overflow

We allocate memory of size 'xlen + strlen(boot_command_line) + 1' for static_command_line, but the strings copied into static_command_line are extra_command_line and command_line, rather than extra_command_line and boot_command_line.

When strlen(command_line) > strlen(boot_command_line), static_command_line will overflow.

This patch just recovers strlen(command_line) which was miss-consolidated with strlen(boot_command_line) in the commit f5c7310ac73e ("init/main: add checks for the return value of memblock_alloc*()")(CVE-2024-26988)

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

f2fs: fix to avoid potential panic during recovery

During recovery, if FAULT_BLOCK is on, it is possible that f2fs_reserve_new_block() will return -ENOSPC during recovery, then it may trigger panic.

Also, if fault injection rate is 1 and only FAULT_BLOCK fault type is on, it may encounter deadloop in loop of block reservation.

Let's change as below to fix these issues: - remove bug_on() to avoid panic. - limit the loop count of block reservation to avoid potential deadloop.(CVE-2024-27032)

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

clk: Fix clk_core_get NULL dereference

It is possible for clk_core_get to dereference a NULL in the following sequence:

clk_core_get() of_clk_get_hw_from_clkspec() __of_clk_get_hw_from_provider() __clk_get_hw()

__clk_get_hw() can return NULL which is dereferenced by clk_core_get() at hw->core.

Prior to commit dde4eff47c82 ("clk: Look for parents with clkdev based clk_lookups") the check IS_ERR_OR_NULL() was performed which would have caught the NULL.

Reading the description of this function it talks about returning NULL but that cannot be so at the moment.

Update the function to check for hw before dereferencing it and return NULL if hw is NULL.(CVE-2024-27038)

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

net: phy: fix phy_get_internal_delay accessing an empty array

The phy_get_internal_delay function could try to access to an empty array in the case that the driver is calling phy_get_internal_delay without defining delay_values and rx-internal-delay-ps or tx-internal-delay-ps is defined to 0 in the device-tree. This will lead to "unable to handle kernel NULL pointer dereference at virtual address 0". To avoid this kernel oops, the test should be delay >= 0. As there is already delay < 0 test just before, the test could only be size == 0.(CVE-2024-27047)

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

wifi: rtl8xxxu: add cancel_work_sync() for c2hcmd_work

The workqueue might still be running, when the driver is stopped. To avoid a use-after-free, call cancel_work_sync() in rtl8xxxu_stop().(CVE-2024-27052)

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

wifi: wilc1000: fix RCU usage in connect path

With lockdep enabled, calls to the connect function from cfg802.11 layer lead to the following warning:

============================= WARNING: suspicious RCU usage 6.7.0-rc1-wt+ #333 Not tainted

drivers/net/wireless/microchip/wilc1000/hif.c:386 suspicious rcu_dereference_check() usage! [...] stack backtrace: CPU: 0 PID: 100 Comm: wpa_supplicant Not tainted 6.7.0-rc1-wt+ #333 Hardware name: Atmel SAMA5 unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x48 dump_stack_lvl from wilc_parse_join_bss_param+0x7dc/0x7f4 wilc_parse_join_bss_param from connect+0x2c4/0x648 connect from cfg80211_connect+0x30c/0xb74 cfg80211_connect from nl80211_connect+0x860/0xa94 nl80211_connect from genl_rcv_msg+0x3fc/0x59c genl_rcv_msg from netlink_rcv_skb+0xd0/0x1f8 netlink_rcv_skb from genl_rcv+0x2c/0x3c genl_rcv from netlink_unicast+0x3b0/0x550 netlink_unicast from netlink_sendmsg+0x368/0x688 netlink_sendmsg from _syssendmsg+0x190/0x430 __sys_sendmsg from syssendmsg+0x110/0x158 _sys_sendmsg from sys_sendmsg+0xe8/0x150 sys_sendmsg from ret_fast_syscall+0x0/0x1c

This warning is emitted because in the connect path, when trying to parse target BSS parameters, we dereference a RCU pointer whithout being in RCU critical section. Fix RCU dereference usage by moving it to a RCU read critical section. To avoid wrapping the whole wilc_parse_join_bss_param under the critical section, just use the critical section to copy ies data(CVE-2024-27053)

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

ipv6: fix potential "struct net" leak in inet6_rtm_getaddr()

It seems that if userspace provides a correct IFA_TARGET_NETNSID value but no IFA_ADDRESS and IFA_LOCAL attributes, inet6_rtm_getaddr() returns -EINVAL with an elevated "struct net" refcount.(CVE-2024-27417)

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

genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline

The absence of IRQD_MOVE_PCNTXT prevents immediate effectiveness of interrupt affinity reconfiguration via procfs. Instead, the change is deferred until the next instance of the interrupt being triggered on the original CPU.

When the interrupt next triggers on the original CPU, the new affinity is enforced within __irq_move_irq(). A vector is allocated from the new CPU, but the old vector on the original CPU remains and is not immediately reclaimed. Instead, apicd->move_in_progress is flagged, and the reclaiming process is delayed until the next trigger of the interrupt on the new CPU.

Upon the subsequent triggering of the interrupt on the new CPU, irq_complete_move() adds a task to the old CPU's vector_cleanup list if it remains online. Subsequently, the timer on the old CPU iterates over its vector_cleanup list, reclaiming old vectors.

However, a rare scenario arises if the old CPU is outgoing before the interrupt triggers again on the new CPU.

In that case irq_force_complete_move() is not invoked on the outgoing CPU to reclaim the old apicd->prev_vector because the interrupt isn't currently affine to the outgoing CPU, and irq_needs_fixup() returns false. Even though __vector_schedule_cleanup() is later called on the new CPU, it doesn't reclaim apicd->prev_vector; instead, it simply resets both apicd->move_in_progress and apicd->prev_vector to 0.

As a result, the vector remains unreclaimed in vector_matrix, leading to a CPU vector leak.

To address this issue, move the invocation of irq_force_complete_move() before the irq_needs_fixup() call to reclaim apicd->prev_vector, if the interrupt is currently or used to be affine to the outgoing CPU.

Additionally, reclaim the vector in __vector_schedule_cleanup() as well, following a warning message, although theoretically it should never see apicd->move_in_progress with apicd->prev_cpu pointing to an offline CPU.(CVE-2024-31076)

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

wifi: brcmfmac: Fix use-after-free bug in brcmf_cfg80211_detach

This is the candidate patch of CVE-2023-47233 : https://nvd.nist.gov/vuln/detail/CVE-2023-47233

In brcm80211 driver,it starts with the following invoking chain to start init a timeout worker:

->brcmf_usb_probe ->brcmf_usb_probe_cb ->brcmf_attach ->brcmf_bus_started ->brcmf_cfg80211_attach ->wl_init_priv ->brcmf_init_escan ->INIT_WORK(&cfg->escan_timeout_work, brcmf_cfg80211_escan_timeout_worker);

If we disconnect the USB by hotplug, it will call brcmf_usb_disconnect to make cleanup. The invoking chain is :

brcmf_usb_disconnect ->brcmf_usb_disconnect_cb ->brcmf_detach ->brcmf_cfg80211_detach ->kfree(cfg);

While the timeout woker may still be running. This will cause a use-after-free bug on cfg in brcmf_cfg80211_escan_timeout_worker.

Fix it by deleting the timer and canceling the worker in brcmf_cfg80211_detach.

arend.vanspriel@broadcom.com: keep timer delete as is and cancel work just before free

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

drm/amdgpu: amdgpu_ttm_gart_bind set gtt bound flag

Otherwise after the GTT bo is released, the GTT and gart space is freed but amdgpu_ttm_backend_unbind will not clear the gart page table entry and leave valid mapping entry pointing to the stale system page. Then if GPU access the gart address mistakely, it will read undefined value instead page fault, harder to debug and reproduce the real issue.(CVE-2024-35817)

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

media: tc358743: register v4l2 async device only after successful setup

Ensure the device has been setup correctly before registering the v4l2 async device, thus allowing userspace to access.(CVE-2024-35830)

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

dyndbg: fix old BUG_ON in >control parser

Fix a BUG_ON from 2009. Even if it looks "unreachable" (I didn't really look), lets make sure by removing it, doing pr_err and return -EINVAL instead.(CVE-2024-35947)

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

drm/amd/display: Fix division by zero in setup_dsc_config

When slice_height is 0, the division by slice_height in the calculation of the number of slices will cause a division by zero driver crash. This leaves the kernel in a state that requires a reboot. This patch adds a check to avoid the division by zero.

The stack trace below is for the 6.8.4 Kernel. I reproduced the issue on a Z16 Gen 2 Lenovo Thinkpad with a Apple Studio Display monitor connected via Thunderbolt. The amdgpu driver crashed with this exception when I rebooted the system with the monitor connected.

kernel: ? die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434 arch/x86/kernel/dumpstack.c:447) kernel: ? do_trap (arch/x86/kernel/traps.c:113 arch/x86/kernel/traps.c:154) kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu kernel: ? do_error_trap (./arch/x86/include/asm/traps.h:58 arch/x86/kernel/traps.c:175) kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu kernel: ? exc_divide_error (arch/x86/kernel/traps.c:194 (discriminator 2)) kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu kernel: ? asm_exc_divide_error (./arch/x86/include/asm/idtentry.h:548) kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu kernel: dc_dsc_compute_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1109) amdgpu

After applying this patch, the driver no longer crashes when the monitor is connected and the system is rebooted. I believe this is the same issue reported for 3113.(CVE-2024-36969)

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

net: sched: sch_multiq: fix possible OOB write in multiq_tune()

q->bands will be assigned to qopt->bands to execute subsequent code logic after kmalloc. So the old q->bands should not be used in kmalloc. Otherwise, an out-of-bounds write will occur.(CVE-2024-36978)

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

net: bridge: xmit: make sure we have at least eth header len bytes

syzbot triggered an uninit value[1] error in bridge device's xmit path by sending a short (less than ETH_HLEN bytes) skb. To fix it check if we can actually pull that amount instead of assuming.

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

RDMA/hns: Fix UAF for cq async event

The refcount of CQ is not protected by locks. When CQ asynchronous events and CQ destruction are concurrent, CQ may have been released, which will cause UAF.

Use the xa_lock() to protect the CQ refcount.(CVE-2024-38545)

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

drm/mediatek: Add 0 size check to mtk_drm_gem_obj

Add a check to mtk_drm_gem_init if we attempt to allocate a GEM object of 0 bytes. Currently, no such check exists and the kernel will panic if a userspace application attempts to allocate a 0x0 GBM buffer.

Tested by attempting to allocate a 0x0 GBM buffer on an MT8188 and verifying that we now return EINVAL.(CVE-2024-38549)

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

net/mlx5: Discard command completions in internal error

Fix use after free when FW completion arrives while device is in internal error state. Avoid calling completion handler in this case, since the device will flush the command interface and trigger all completions manually.

Kernel log: ------------[ cut here ]------------ refcount_t: underflow; use-after-free. ... RIP: 0010:refcount_warn_saturate+0xd8/0xe0 ... Call Trace: <IRQ> ? __warn+0x79/0x120 ? refcount_warn_saturate+0xd8/0xe0 ? report_bug+0x17c/0x190 ? handle_bug+0x3c/0x60 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? refcount_warn_saturate+0xd8/0xe0 cmd_ent_put+0x13b/0x160 [mlx5_core] mlx5_cmd_comp_handler+0x5f9/0x670 [mlx5_core] cmd_comp_notifier+0x1f/0x30 [mlx5_core] notifier_call_chain+0x35/0xb0 atomic_notifier_call_chain+0x16/0x20 mlx5_eq_async_int+0xf6/0x290 [mlx5_core] notifier_call_chain+0x35/0xb0 atomic_notifier_call_chain+0x16/0x20 irq_int_handler+0x19/0x30 [mlx5_core] __handle_irq_event_percpu+0x4b/0x160 handle_irq_event+0x2e/0x80 handle_edge_irq+0x98/0x230 __common_interrupt+0x3b/0xa0 common_interrupt+0x7b/0xa0 </IRQ> <TASK> asm_common_interrupt+0x22/0x40(CVE-2024-38555)

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

drivers/perf: hisi_pcie: Fix out-of-bound access when valid event group

The perf tool allows users to create event groups through following cmd [1], but the driver does not check whether the array index is out of bounds when writing data to the event_group array. If the number of events in an event_group is greater than HISI_PCIE_MAX_COUNTERS, the memory write overflow of event_group array occurs.

Add array index check to fix the possible array out of bounds violation, and return directly when write new events are written to array bounds.

There are 9 different events in an event_group. [1] perf stat -e '{pmu/event1/, ... ,pmu/event9/}'(CVE-2024-38569)

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

RDMA/hns: Fix deadlock on SRQ async events.

xa_lock for SRQ table may be required in AEQ. Use xa_store_irq()/ xa_erase_irq() to avoid deadlock.(CVE-2024-38591)

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

ring-buffer: Fix a race between readers and resize checks

The reader code in rb_get_reader_page() swaps a new reader page into the ring buffer by doing cmpxchg on old->list.prev->next to point it to the new page. Following that, if the operation is successful, old->list.next->prev gets updated too. This means the underlying doubly-linked list is temporarily inconsistent, page->prev->next or page->next->prev might not be equal back to page for some page in the ring buffer.

The resize operation in ring_buffer_resize() can be invoked in parallel. It calls rb_check_pages() which can detect the described inconsistency and stop further tracing:

[ 190.271762] ------------[ cut here ]------------ [ 190.271771] WARNING: CPU: 1 PID: 6186 at kernel/trace/ring_buffer.c:1467 rb_check_pages.isra.0+0x6a/0xa0 [ 190.271789] Modules linked in: [...] [ 190.271991] Unloaded tainted modules: intel_uncore_frequency(E):1 skx_edac(E):1 [ 190.272002] CPU: 1 PID: 6186 Comm: cmd.sh Kdump: loaded Tainted: G E 6.9.0-rc6-default #5 158d3e1e6d0b091c34c3b96bfd99a1c58306d79f [ 190.272011] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552c-rebuilt.opensuse.org 04/01/2014 [ 190.272015] RIP: 0010:rb_check_pages.isra.0+0x6a/0xa0 [ 190.272023] Code: [...] [ 190.272028] RSP: 0018:ffff9c37463abb70 EFLAGS: 00010206 [ 190.272034] RAX: ffff8eba04b6cb80 RBX: 0000000000000007 RCX: ffff8eba01f13d80 [ 190.272038] RDX: ffff8eba01f130c0 RSI: ffff8eba04b6cd00 RDI: ffff8eba0004c700 [ 190.272042] RBP: ffff8eba0004c700 R08: 0000000000010002 R09: 0000000000000000 [ 190.272045] R10: 00000000ffff7f52 R11: ffff8eba7f600000 R12: ffff8eba0004c720 [ 190.272049] R13: ffff8eba00223a00 R14: 0000000000000008 R15: ffff8eba067a8000 [ 190.272053] FS: 00007f1bd64752c0(0000) GS:ffff8eba7f680000(0000) knlGS:0000000000000000 [ 190.272057] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 190.272061] CR2: 00007f1bd6662590 CR3: 000000010291e001 CR4: 0000000000370ef0 [ 190.272070] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 190.272073] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 190.272077] Call Trace: [ 190.272098] <TASK> [ 190.272189] ring_buffer_resize+0x2ab/0x460 [ 190.272199] __tracing_resize_ring_buffer.part.0+0x23/0xa0 [ 190.272206] tracing_resize_ring_buffer+0x65/0x90 [ 190.272216] tracing_entries_write+0x74/0xc0 [ 190.272225] vfs_write+0xf5/0x420 [ 190.272248] ksys_write+0x67/0xe0 [ 190.272256] do_syscall_64+0x82/0x170 [ 190.272363] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 190.272373] RIP: 0033:0x7f1bd657d263 [ 190.272381] Code: [...] [ 190.272385] RSP: 002b:00007ffe72b643f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 190.272391] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f1bd657d263 [ 190.272395] RDX: 0000000000000002 RSI: 0000555a6eb538e0 RDI: 0000000000000001 [ 190.272398] RBP: 0000555a6eb538e0 R08: 000000000000000a R09: 0000000000000000 [ 190.272401] R10: 0000555a6eb55190 R11: 0000000000000246 R12: 00007f1bd6662500 [ 190.272404] R13: 0000000000000002 R14: 00007f1bd6667c00 R15: 0000000000000002 [ 190.272412] </TASK> [ 190.272414] ---[ end trace 0000000000000000 ]---

Note that ring_buffer_resize() calls rb_check_pages() only if the parent trace_buffer has recording disabled. Recent commit d78ab792705c ("tracing: Stop current tracer when resizing buffer") causes that it is now always the case which makes it more likely to experience this issue.

The window to hit this race is nonetheless very small. To help reproducing it, one can add a delay loop in rb_get_reader_page():

ret = rb_head_page_replace(reader, cpu_buffer->reader_page); if (!ret) goto spin; for (unsigned i = 0; i < 1U << 26; i++) / inserted delay loop / asm volatile ("" : : : "memory"); rb_list_head(reader->list.next)->prev = &cpu_buffer->reader_page->list;

.. ---truncated---(CVE-2024-38601)

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

serial: max3100: Lock port->lock when calling uart_handle_cts_change()

uart_handle_cts_change() has to be called with port lock taken, Since we run it in a separate work, the lock may not be taken at the time of running. Make sure that it's taken by explicitly doing that. Without it we got a splat:

WARNING: CPU: 0 PID: 10 at drivers/tty/serial/serial_core.c:3491 uart_handle_cts_change+0xa6/0xb0 ... Workqueue: max3100-0 max3100_work [max3100] RIP: 0010:uart_handle_cts_change+0xa6/0xb0 ... max3100_handlerx+0xc5/0x110 [max3100] max3100_work+0x12a/0x340 max3100

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

bpf: Allow delete from sockmap/sockhash only if update is allowed

We have seen an influx of syzkaller reports where a BPF program attached to a tracepoint triggers a locking rule violation by performing a map_delete on a sockmap/sockhash.

We don't intend to support this artificial use scenario. Extend the existing verifier allowed-program-type check for updating sockmap/sockhash to also cover deleting from a map.

From now on only BPF programs which were previously allowed to update sockmap/sockhash can delete from these map types.(CVE-2024-38662)

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/en/security/safety-bull…	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2021-47381	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2021-47427	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2021-47469	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2023-39180	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2023-52696	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2023-52791	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2023-52853	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-26592	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-26852	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-26921	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-26935	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-26988	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-27032	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-27038	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-27047	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-27052	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-27053	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-27417	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-31076	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-35811	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-35817	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-35830	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-35947	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-36969	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-36978	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-38538	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-38545	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-38549	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-38555	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-38569	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-38591	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-38601	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-38634	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2024-38662	ADVISORY

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "kernel-tools-debuginfo-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm",
          "kernel-tools-devel-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm",
          "kernel-debuginfo-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm",
          "kernel-tools-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm",
          "python3-perf-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm",
          "kernel-debugsource-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm",
          "kernel-source-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm",
          "perf-debuginfo-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm",
          "kernel-devel-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm",
          "perf-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm",
          "python3-perf-debuginfo-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm",
          "kernel-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm",
          "kernel-headers-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm"
        ],
        "src": [
          "kernel-5.10.0-136.82.0.163.oe2203sp1.src.rpm"
        ],
        "x86_64": [
          "kernel-tools-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm",
          "kernel-tools-debuginfo-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm",
          "kernel-headers-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm",
          "kernel-debugsource-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm",
          "kernel-tools-devel-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm",
          "perf-debuginfo-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm",
          "python3-perf-debuginfo-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm",
          "kernel-source-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm",
          "python3-perf-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm",
          "perf-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm",
          "kernel-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm",
          "kernel-devel-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm",
          "kernel-debuginfo-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:22.03-LTS-SP1",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP1"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.10.0-136.82.0.163.oe2203sp1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nASoC: SOF: Fix DSP oops stack dump output contents\r\n\r\nFix @buf arg given to hex_dump_to_buffer() and stack address used\nin dump error output.(CVE-2021-47381)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: iscsi: Fix iscsi_task use after free\r\n\r\nCommit d39df158518c (\u0026quot;scsi: iscsi: Have abort handler get ref to conn\u0026quot;)\nadded iscsi_get_conn()/iscsi_put_conn() calls during abort handling but\nthen also changed the handling of the case where we detect an already\ncompleted task where we now end up doing a goto to the common put/cleanup\ncode. This results in a iscsi_task use after free, because the common\ncleanup code will do a put on the iscsi_task.\r\n\r\nThis reverts the goto and moves the iscsi_get_conn() to after we\u0026apos;ve checked\nif the iscsi_task is valid.(CVE-2021-47427)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nspi: Fix deadlock when adding SPI controllers on SPI buses\r\n\r\nCurrently we have a global spi_add_lock which we take when adding new\ndevices so that we can check that we\u0026apos;re not trying to reuse a chip\nselect that\u0026apos;s already controlled.  This means that if the SPI device is\nitself a SPI controller and triggers the instantiation of further SPI\ndevices we trigger a deadlock as we try to register and instantiate\nthose devices while in the process of doing so for the parent controller\nand hence already holding the global spi_add_lock.  Since we only care\nabout concurrency within a single SPI bus move the lock to be per\ncontroller, avoiding the deadlock.\r\n\r\nThis can be easily triggered in the case of spi-mux.(CVE-2021-47469)\r\n\r\n(CVE-2023-39180)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npowerpc/powernv: Add a null pointer check in opal_powercap_init()\r\n\r\nkasprintf() returns a pointer to dynamically allocated memory\nwhich can be NULL upon failure.(CVE-2023-52696)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ni2c: core: Run atomic i2c xfer when !preemptible\r\n\r\nSince bae1d3a05a8b, i2c transfers are non-atomic if preemption is\ndisabled. However, non-atomic i2c transfers require preemption (e.g. in\nwait_for_completion() while waiting for the DMA).\r\n\r\npanic() calls preempt_disable_notrace() before calling\nemergency_restart(). Therefore, if an i2c device is used for the\nrestart, the xfer should be atomic. This avoids warnings like:\r\n\r\n[   12.667612] WARNING: CPU: 1 PID: 1 at kernel/rcu/tree_plugin.h:318 rcu_note_context_switch+0x33c/0x6b0\n[   12.676926] Voluntary context switch within RCU read-side critical section!\n...\n[   12.742376]  schedule_timeout from wait_for_completion_timeout+0x90/0x114\n[   12.749179]  wait_for_completion_timeout from tegra_i2c_wait_completion+0x40/0x70\n...\n[   12.994527]  atomic_notifier_call_chain from machine_restart+0x34/0x58\n[   13.001050]  machine_restart from panic+0x2a8/0x32c\r\n\r\nUse !preemptible() instead, which is basically the same check as\npre-v5.2.(CVE-2023-52791)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhid: cp2112: Fix duplicate workqueue initialization\r\n\r\nPreviously the cp2112 driver called INIT_DELAYED_WORK within\ncp2112_gpio_irq_startup, resulting in duplicate initilizations of the\nworkqueue on subsequent IRQ startups following an initial request. This\nresulted in a warning in set_work_data in workqueue.c, as well as a rare\nNULL dereference within process_one_work in workqueue.c.\r\n\r\nInitialize the workqueue within _probe instead.(CVE-2023-52853)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nksmbd: fix UAF issue in ksmbd_tcp_new_connection()\r\n\r\nThe race is between the handling of a new TCP connection and\nits disconnection. It leads to UAF on `struct tcp_transport` in\nksmbd_tcp_new_connection() function.(CVE-2024-26592)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/ipv6: avoid possible UAF in ip6_route_mpath_notify()\r\n\r\nsyzbot found another use-after-free in ip6_route_mpath_notify() [1]\r\n\r\nCommit f7225172f25a (\u0026quot;net/ipv6: prevent use after free in\nip6_route_mpath_notify\u0026quot;) was not able to fix the root cause.\r\n\r\nWe need to defer the fib6_info_release() calls after\nip6_route_mpath_notify(), in the cleanup phase.\r\n\r\n[1]\nBUG: KASAN: slab-use-after-free in rt6_fill_node+0x1460/0x1ac0\nRead of size 4 at addr ffff88809a07fc64 by task syz-executor.2/23037\r\n\r\nCPU: 0 PID: 23037 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-01035-gea7f3cfaa588 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024\nCall Trace:\n \u0026lt;TASK\u0026gt;\n  __dump_stack lib/dump_stack.c:88 [inline]\n  dump_stack_lvl+0x1e7/0x2e0 lib/dump_stack.c:106\n  print_address_description mm/kasan/report.c:377 [inline]\n  print_report+0x167/0x540 mm/kasan/report.c:488\n  kasan_report+0x142/0x180 mm/kasan/report.c:601\n rt6_fill_node+0x1460/0x1ac0\n  inet6_rt_notify+0x13b/0x290 net/ipv6/route.c:6184\n  ip6_route_mpath_notify net/ipv6/route.c:5198 [inline]\n  ip6_route_multipath_add net/ipv6/route.c:5404 [inline]\n  inet6_rtm_newroute+0x1d0f/0x2300 net/ipv6/route.c:5517\n  rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597\n  netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543\n  netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]\n  netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367\n  netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908\n  sock_sendmsg_nosec net/socket.c:730 [inline]\n  __sock_sendmsg+0x221/0x270 net/socket.c:745\n  ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584\n  ___sys_sendmsg net/socket.c:2638 [inline]\n  __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667\n do_syscall_64+0xf9/0x240\n entry_SYSCALL_64_after_hwframe+0x6f/0x77\nRIP: 0033:0x7f73dd87dda9\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f73de6550c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e\nRAX: ffffffffffffffda RBX: 00007f73dd9ac050 RCX: 00007f73dd87dda9\nRDX: 0000000000000000 RSI: 0000000020000140 RDI: 0000000000000005\nRBP: 00007f73dd8ca47a R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 000000000000006e R14: 00007f73dd9ac050 R15: 00007ffdbdeb7858\n \u0026lt;/TASK\u0026gt;\r\n\r\nAllocated by task 23037:\n  kasan_save_stack mm/kasan/common.c:47 [inline]\n  kasan_save_track+0x3f/0x80 mm/kasan/common.c:68\n  poison_kmalloc_redzone mm/kasan/common.c:372 [inline]\n  __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:389\n  kasan_kmalloc include/linux/kasan.h:211 [inline]\n  __do_kmalloc_node mm/slub.c:3981 [inline]\n  __kmalloc+0x22e/0x490 mm/slub.c:3994\n  kmalloc include/linux/slab.h:594 [inline]\n  kzalloc include/linux/slab.h:711 [inline]\n  fib6_info_alloc+0x2e/0xf0 net/ipv6/ip6_fib.c:155\n  ip6_route_info_create+0x445/0x12b0 net/ipv6/route.c:3758\n  ip6_route_multipath_add net/ipv6/route.c:5298 [inline]\n  inet6_rtm_newroute+0x744/0x2300 net/ipv6/route.c:5517\n  rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597\n  netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543\n  netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]\n  netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367\n  netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908\n  sock_sendmsg_nosec net/socket.c:730 [inline]\n  __sock_sendmsg+0x221/0x270 net/socket.c:745\n  ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584\n  ___sys_sendmsg net/socket.c:2638 [inline]\n  __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667\n do_syscall_64+0xf9/0x240\n entry_SYSCALL_64_after_hwframe+0x6f/0x77\r\n\r\nFreed by task 16:\n  kasan_save_stack mm/kasan/common.c:47 [inline]\n  kasan_save_track+0x3f/0x80 mm/kasan/common.c:68\n  kasan_save_free_info+0x4e/0x60 mm/kasan/generic.c:640\n  poison_slab_object+0xa6/0xe0 m\n---truncated---(CVE-2024-26852)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ninet: inet_defrag: prevent sk release while still in use\r\n\r\nip_local_out() and other functions can pass skb-\u0026gt;sk as function argument.\r\n\r\nIf the skb is a fragment and reassembly happens before such function call\nreturns, the sk must not be released.\r\n\r\nThis affects skb fragments reassembled via netfilter or similar\nmodules, e.g. openvswitch or ct_act.c, when run as part of tx pipeline.\r\n\r\nEric Dumazet made an initial analysis of this bug.  Quoting Eric:\n  Calling ip_defrag() in output path is also implying skb_orphan(),\n  which is buggy because output path relies on sk not disappearing.\r\n\r\n  A relevant old patch about the issue was :\n  8282f27449bf (\u0026quot;inet: frag: Always orphan skbs inside ip_defrag()\u0026quot;)\r\n\r\n  [..]\r\n\r\n  net/ipv4/ip_output.c depends on skb-\u0026gt;sk being set, and probably to an\n  inet socket, not an arbitrary one.\r\n\r\n  If we orphan the packet in ipvlan, then downstream things like FQ\n  packet scheduler will not work properly.\r\n\r\n  We need to change ip_defrag() to only use skb_orphan() when really\n  needed, ie whenever frag_list is going to be used.\r\n\r\nEric suggested to stash sk in fragment queue and made an initial patch.\nHowever there is a problem with this:\r\n\r\nIf skb is refragmented again right after, ip_do_fragment() will copy\nhead-\u0026gt;sk to the new fragments, and sets up destructor to sock_wfree.\nIOW, we have no choice but to fix up sk_wmem accouting to reflect the\nfully reassembled skb, else wmem will underflow.\r\n\r\nThis change moves the orphan down into the core, to last possible moment.\nAs ip_defrag_offset is aliased with sk_buff-\u0026gt;sk member, we must move the\noffset into the FRAG_CB, else skb-\u0026gt;sk gets clobbered.\r\n\r\nThis allows to delay the orphaning long enough to learn if the skb has\nto be queued or if the skb is completing the reasm queue.\r\n\r\nIn the former case, things work as before, skb is orphaned.  This is\nsafe because skb gets queued/stolen and won\u0026apos;t continue past reasm engine.\r\n\r\nIn the latter case, we will steal the skb-\u0026gt;sk reference, reattach it to\nthe head skb, and fix up wmem accouting when inet_frag inflates truesize.(CVE-2024-26921)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: core: Fix unremoved procfs host directory regression\r\n\r\nCommit fc663711b944 (\u0026quot;scsi: core: Remove the /proc/scsi/${proc_name}\ndirectory earlier\u0026quot;) fixed a bug related to modules loading/unloading, by\nadding a call to scsi_proc_hostdir_rm() on scsi_remove_host(). But that led\nto a potential duplicate call to the hostdir_rm() routine, since it\u0026apos;s also\ncalled from scsi_host_dev_release(). That triggered a regression report,\nwhich was then fixed by commit be03df3d4bfe (\u0026quot;scsi: core: Fix a procfs host\ndirectory removal regression\u0026quot;). The fix just dropped the hostdir_rm() call\nfrom dev_release().\r\n\r\nBut it happens that this proc directory is created on scsi_host_alloc(),\nand that function \u0026quot;pairs\u0026quot; with scsi_host_dev_release(), while\nscsi_remove_host() pairs with scsi_add_host(). In other words, it seems the\nreason for removing the proc directory on dev_release() was meant to cover\ncases in which a SCSI host structure was allocated, but the call to\nscsi_add_host() didn\u0026apos;t happen. And that pattern happens to exist in some\nerror paths, for example.\r\n\r\nSyzkaller causes that by using USB raw gadget device, error\u0026apos;ing on\nusb-storage driver, at usb_stor_probe2(). By checking that path, we can see\nthat the BadDevice label leads to a scsi_host_put() after a SCSI host\nallocation, but there\u0026apos;s no call to scsi_add_host() in such path. That leads\nto messages like this in dmesg (and a leak of the SCSI host proc\nstructure):\r\n\r\nusb-storage 4-1:87.51: USB Mass Storage device detected\nproc_dir_entry \u0026apos;scsi/usb-storage\u0026apos; already registered\nWARNING: CPU: 1 PID: 3519 at fs/proc/generic.c:377 proc_register+0x347/0x4e0 fs/proc/generic.c:376\r\n\r\nThe proper fix seems to still call scsi_proc_hostdir_rm() on dev_release(),\nbut guard that with the state check for SHOST_CREATED; there is even a\ncomment in scsi_host_dev_release() detailing that: such conditional is\nmeant for cases where the SCSI host was allocated but there was no calls to\n{add,remove}_host(), like the usb-storage case.\r\n\r\nThis is what we propose here and with that, the error path of usb-storage\ndoes not trigger the warning anymore.(CVE-2024-26935)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ninit/main.c: Fix potential static_command_line memory overflow\r\n\r\nWe allocate memory of size \u0026apos;xlen + strlen(boot_command_line) + 1\u0026apos; for\nstatic_command_line, but the strings copied into static_command_line are\nextra_command_line and command_line, rather than extra_command_line and\nboot_command_line.\r\n\r\nWhen strlen(command_line) \u0026gt; strlen(boot_command_line), static_command_line\nwill overflow.\r\n\r\nThis patch just recovers strlen(command_line) which was miss-consolidated\nwith strlen(boot_command_line) in the commit f5c7310ac73e (\u0026quot;init/main: add\nchecks for the return value of memblock_alloc*()\u0026quot;)(CVE-2024-26988)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: fix to avoid potential panic during recovery\r\n\r\nDuring recovery, if FAULT_BLOCK is on, it is possible that\nf2fs_reserve_new_block() will return -ENOSPC during recovery,\nthen it may trigger panic.\r\n\r\nAlso, if fault injection rate is 1 and only FAULT_BLOCK fault\ntype is on, it may encounter deadloop in loop of block reservation.\r\n\r\nLet\u0026apos;s change as below to fix these issues:\n- remove bug_on() to avoid panic.\n- limit the loop count of block reservation to avoid potential\ndeadloop.(CVE-2024-27032)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: Fix clk_core_get NULL dereference\r\n\r\nIt is possible for clk_core_get to dereference a NULL in the following\nsequence:\r\n\r\nclk_core_get()\n    of_clk_get_hw_from_clkspec()\n        __of_clk_get_hw_from_provider()\n            __clk_get_hw()\r\n\r\n__clk_get_hw() can return NULL which is dereferenced by clk_core_get() at\nhw-\u0026gt;core.\r\n\r\nPrior to commit dde4eff47c82 (\u0026quot;clk: Look for parents with clkdev based\nclk_lookups\u0026quot;) the check IS_ERR_OR_NULL() was performed which would have\ncaught the NULL.\r\n\r\nReading the description of this function it talks about returning NULL but\nthat cannot be so at the moment.\r\n\r\nUpdate the function to check for hw before dereferencing it and return NULL\nif hw is NULL.(CVE-2024-27038)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: phy: fix phy_get_internal_delay accessing an empty array\r\n\r\nThe phy_get_internal_delay function could try to access to an empty\narray in the case that the driver is calling phy_get_internal_delay\nwithout defining delay_values and rx-internal-delay-ps or\ntx-internal-delay-ps is defined to 0 in the device-tree.\nThis will lead to \u0026quot;unable to handle kernel NULL pointer dereference at\nvirtual address 0\u0026quot;. To avoid this kernel oops, the test should be delay\n\u0026gt;= 0. As there is already delay \u0026lt; 0 test just before, the test could\nonly be size == 0.(CVE-2024-27047)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: rtl8xxxu: add cancel_work_sync() for c2hcmd_work\r\n\r\nThe workqueue might still be running, when the driver is stopped. To\navoid a use-after-free, call cancel_work_sync() in rtl8xxxu_stop().(CVE-2024-27052)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: wilc1000: fix RCU usage in connect path\r\n\r\nWith lockdep enabled, calls to the connect function from cfg802.11 layer\nlead to the following warning:\r\n\r\n=============================\nWARNING: suspicious RCU usage\n6.7.0-rc1-wt+ #333 Not tainted\n-----------------------------\ndrivers/net/wireless/microchip/wilc1000/hif.c:386\nsuspicious rcu_dereference_check() usage!\n[...]\nstack backtrace:\nCPU: 0 PID: 100 Comm: wpa_supplicant Not tainted 6.7.0-rc1-wt+ #333\nHardware name: Atmel SAMA5\n unwind_backtrace from show_stack+0x18/0x1c\n show_stack from dump_stack_lvl+0x34/0x48\n dump_stack_lvl from wilc_parse_join_bss_param+0x7dc/0x7f4\n wilc_parse_join_bss_param from connect+0x2c4/0x648\n connect from cfg80211_connect+0x30c/0xb74\n cfg80211_connect from nl80211_connect+0x860/0xa94\n nl80211_connect from genl_rcv_msg+0x3fc/0x59c\n genl_rcv_msg from netlink_rcv_skb+0xd0/0x1f8\n netlink_rcv_skb from genl_rcv+0x2c/0x3c\n genl_rcv from netlink_unicast+0x3b0/0x550\n netlink_unicast from netlink_sendmsg+0x368/0x688\n netlink_sendmsg from ____sys_sendmsg+0x190/0x430\n ____sys_sendmsg from ___sys_sendmsg+0x110/0x158\n ___sys_sendmsg from sys_sendmsg+0xe8/0x150\n sys_sendmsg from ret_fast_syscall+0x0/0x1c\r\n\r\nThis warning is emitted because in the connect path, when trying to parse\ntarget BSS parameters, we dereference a RCU pointer whithout being in RCU\ncritical section.\nFix RCU dereference usage by moving it to a RCU read critical section. To\navoid wrapping the whole wilc_parse_join_bss_param under the critical\nsection, just use the critical section to copy ies data(CVE-2024-27053)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: fix potential \u0026quot;struct net\u0026quot; leak in inet6_rtm_getaddr()\r\n\r\nIt seems that if userspace provides a correct IFA_TARGET_NETNSID value\nbut no IFA_ADDRESS and IFA_LOCAL attributes, inet6_rtm_getaddr()\nreturns -EINVAL with an elevated \u0026quot;struct net\u0026quot; refcount.(CVE-2024-27417)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngenirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline\r\n\r\nThe absence of IRQD_MOVE_PCNTXT prevents immediate effectiveness of\ninterrupt affinity reconfiguration via procfs. Instead, the change is\ndeferred until the next instance of the interrupt being triggered on the\noriginal CPU.\r\n\r\nWhen the interrupt next triggers on the original CPU, the new affinity is\nenforced within __irq_move_irq(). A vector is allocated from the new CPU,\nbut the old vector on the original CPU remains and is not immediately\nreclaimed. Instead, apicd-\u0026gt;move_in_progress is flagged, and the reclaiming\nprocess is delayed until the next trigger of the interrupt on the new CPU.\r\n\r\nUpon the subsequent triggering of the interrupt on the new CPU,\nirq_complete_move() adds a task to the old CPU\u0026apos;s vector_cleanup list if it\nremains online. Subsequently, the timer on the old CPU iterates over its\nvector_cleanup list, reclaiming old vectors.\r\n\r\nHowever, a rare scenario arises if the old CPU is outgoing before the\ninterrupt triggers again on the new CPU.\r\n\r\nIn that case irq_force_complete_move() is not invoked on the outgoing CPU\nto reclaim the old apicd-\u0026gt;prev_vector because the interrupt isn\u0026apos;t currently\naffine to the outgoing CPU, and irq_needs_fixup() returns false. Even\nthough __vector_schedule_cleanup() is later called on the new CPU, it\ndoesn\u0026apos;t reclaim apicd-\u0026gt;prev_vector; instead, it simply resets both\napicd-\u0026gt;move_in_progress and apicd-\u0026gt;prev_vector to 0.\r\n\r\nAs a result, the vector remains unreclaimed in vector_matrix, leading to a\nCPU vector leak.\r\n\r\nTo address this issue, move the invocation of irq_force_complete_move()\nbefore the irq_needs_fixup() call to reclaim apicd-\u0026gt;prev_vector, if the\ninterrupt is currently or used to be affine to the outgoing CPU.\r\n\r\nAdditionally, reclaim the vector in __vector_schedule_cleanup() as well,\nfollowing a warning message, although theoretically it should never see\napicd-\u0026gt;move_in_progress with apicd-\u0026gt;prev_cpu pointing to an offline CPU.(CVE-2024-31076)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: brcmfmac: Fix use-after-free bug in brcmf_cfg80211_detach\r\n\r\nThis is the candidate patch of CVE-2023-47233 :\nhttps://nvd.nist.gov/vuln/detail/CVE-2023-47233\r\n\r\nIn brcm80211 driver,it starts with the following invoking chain\nto start init a timeout worker:\r\n\r\n-\u0026gt;brcmf_usb_probe\n  -\u0026gt;brcmf_usb_probe_cb\n    -\u0026gt;brcmf_attach\n      -\u0026gt;brcmf_bus_started\n        -\u0026gt;brcmf_cfg80211_attach\n          -\u0026gt;wl_init_priv\n            -\u0026gt;brcmf_init_escan\n              -\u0026gt;INIT_WORK(\u0026amp;cfg-\u0026gt;escan_timeout_work,\n\t\t  brcmf_cfg80211_escan_timeout_worker);\r\n\r\nIf we disconnect the USB by hotplug, it will call\nbrcmf_usb_disconnect to make cleanup. The invoking chain is :\r\n\r\nbrcmf_usb_disconnect\n  -\u0026gt;brcmf_usb_disconnect_cb\n    -\u0026gt;brcmf_detach\n      -\u0026gt;brcmf_cfg80211_detach\n        -\u0026gt;kfree(cfg);\r\n\r\nWhile the timeout woker may still be running. This will cause\na use-after-free bug on cfg in brcmf_cfg80211_escan_timeout_worker.\r\n\r\nFix it by deleting the timer and canceling the worker in\nbrcmf_cfg80211_detach.\r\n\r\n[arend.vanspriel@broadcom.com: keep timer delete as is and cancel work just before free](CVE-2024-35811)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: amdgpu_ttm_gart_bind set gtt bound flag\r\n\r\nOtherwise after the GTT bo is released, the GTT and gart space is freed\nbut amdgpu_ttm_backend_unbind will not clear the gart page table entry\nand leave valid mapping entry pointing to the stale system page. Then\nif GPU access the gart address mistakely, it will read undefined value\ninstead page fault, harder to debug and reproduce the real issue.(CVE-2024-35817)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: tc358743: register v4l2 async device only after successful setup\r\n\r\nEnsure the device has been setup correctly before registering the v4l2\nasync device, thus allowing userspace to access.(CVE-2024-35830)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndyndbg: fix old BUG_ON in \u0026gt;control parser\r\n\r\nFix a BUG_ON from 2009.  Even if it looks \u0026quot;unreachable\u0026quot; (I didn\u0026apos;t\nreally look), lets make sure by removing it, doing pr_err and return\n-EINVAL instead.(CVE-2024-35947)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Fix division by zero in setup_dsc_config\r\n\r\nWhen slice_height is 0, the division by slice_height in the calculation\nof the number of slices will cause a division by zero driver crash. This\nleaves the kernel in a state that requires a reboot. This patch adds a\ncheck to avoid the division by zero.\r\n\r\nThe stack trace below is for the 6.8.4 Kernel. I reproduced the issue on\na Z16 Gen 2 Lenovo Thinkpad with a Apple Studio Display monitor\nconnected via Thunderbolt. The amdgpu driver crashed with this exception\nwhen I rebooted the system with the monitor connected.\r\n\r\nkernel: ? die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434 arch/x86/kernel/dumpstack.c:447)\nkernel: ? do_trap (arch/x86/kernel/traps.c:113 arch/x86/kernel/traps.c:154)\nkernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu\nkernel: ? do_error_trap (./arch/x86/include/asm/traps.h:58 arch/x86/kernel/traps.c:175)\nkernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu\nkernel: ? exc_divide_error (arch/x86/kernel/traps.c:194 (discriminator 2))\nkernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu\nkernel: ? asm_exc_divide_error (./arch/x86/include/asm/idtentry.h:548)\nkernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu\nkernel: dc_dsc_compute_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1109) amdgpu\r\n\r\nAfter applying this patch, the driver no longer crashes when the monitor\nis connected and the system is rebooted. I believe this is the same\nissue reported for 3113.(CVE-2024-36969)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: sched: sch_multiq: fix possible OOB write in multiq_tune()\r\n\r\nq-\u0026gt;bands will be assigned to qopt-\u0026gt;bands to execute subsequent code logic\nafter kmalloc. So the old q-\u0026gt;bands should not be used in kmalloc.\nOtherwise, an out-of-bounds write will occur.(CVE-2024-36978)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: bridge: xmit: make sure we have at least eth header len bytes\r\n\r\nsyzbot triggered an uninit value[1] error in bridge device\u0026apos;s xmit path\nby sending a short (less than ETH_HLEN bytes) skb. To fix it check if\nwe can actually pull that amount instead of assuming.\r\n\r\nTested with dropwatch:\n drop at: br_dev_xmit+0xb93/0x12d0 [bridge] (0xffffffffc06739b3)\n origin: software\n timestamp: Mon May 13 11:31:53 2024 778214037 nsec\n protocol: 0x88a8\n length: 2\n original length: 2\n drop reason: PKT_TOO_SMALL\r\n\r\n[1]\nBUG: KMSAN: uninit-value in br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65\n br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65\n __netdev_start_xmit include/linux/netdevice.h:4903 [inline]\n netdev_start_xmit include/linux/netdevice.h:4917 [inline]\n xmit_one net/core/dev.c:3531 [inline]\n dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547\n __dev_queue_xmit+0x34db/0x5350 net/core/dev.c:4341\n dev_queue_xmit include/linux/netdevice.h:3091 [inline]\n __bpf_tx_skb net/core/filter.c:2136 [inline]\n __bpf_redirect_common net/core/filter.c:2180 [inline]\n __bpf_redirect+0x14a6/0x1620 net/core/filter.c:2187\n ____bpf_clone_redirect net/core/filter.c:2460 [inline]\n bpf_clone_redirect+0x328/0x470 net/core/filter.c:2432\n ___bpf_prog_run+0x13fe/0xe0f0 kernel/bpf/core.c:1997\n __bpf_prog_run512+0xb5/0xe0 kernel/bpf/core.c:2238\n bpf_dispatcher_nop_func include/linux/bpf.h:1234 [inline]\n __bpf_prog_run include/linux/filter.h:657 [inline]\n bpf_prog_run include/linux/filter.h:664 [inline]\n bpf_test_run+0x499/0xc30 net/bpf/test_run.c:425\n bpf_prog_test_run_skb+0x14ea/0x1f20 net/bpf/test_run.c:1058\n bpf_prog_test_run+0x6b7/0xad0 kernel/bpf/syscall.c:4269\n __sys_bpf+0x6aa/0xd90 kernel/bpf/syscall.c:5678\n __do_sys_bpf kernel/bpf/syscall.c:5767 [inline]\n __se_sys_bpf kernel/bpf/syscall.c:5765 [inline]\n __x64_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5765\n x64_sys_call+0x96b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:322\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-38538)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nRDMA/hns: Fix UAF for cq async event\r\n\r\nThe refcount of CQ is not protected by locks. When CQ asynchronous\nevents and CQ destruction are concurrent, CQ may have been released,\nwhich will cause UAF.\r\n\r\nUse the xa_lock() to protect the CQ refcount.(CVE-2024-38545)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/mediatek: Add 0 size check to mtk_drm_gem_obj\r\n\r\nAdd a check to mtk_drm_gem_init if we attempt to allocate a GEM object\nof 0 bytes. Currently, no such check exists and the kernel will panic if\na userspace application attempts to allocate a 0x0 GBM buffer.\r\n\r\nTested by attempting to allocate a 0x0 GBM buffer on an MT8188 and\nverifying that we now return EINVAL.(CVE-2024-38549)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5: Discard command completions in internal error\r\n\r\nFix use after free when FW completion arrives while device is in\ninternal error state. Avoid calling completion handler in this case,\nsince the device will flush the command interface and trigger all\ncompletions manually.\r\n\r\nKernel log:\n------------[ cut here ]------------\nrefcount_t: underflow; use-after-free.\n...\nRIP: 0010:refcount_warn_saturate+0xd8/0xe0\n...\nCall Trace:\n\u0026lt;IRQ\u0026gt;\n? __warn+0x79/0x120\n? refcount_warn_saturate+0xd8/0xe0\n? report_bug+0x17c/0x190\n? handle_bug+0x3c/0x60\n? exc_invalid_op+0x14/0x70\n? asm_exc_invalid_op+0x16/0x20\n? refcount_warn_saturate+0xd8/0xe0\ncmd_ent_put+0x13b/0x160 [mlx5_core]\nmlx5_cmd_comp_handler+0x5f9/0x670 [mlx5_core]\ncmd_comp_notifier+0x1f/0x30 [mlx5_core]\nnotifier_call_chain+0x35/0xb0\natomic_notifier_call_chain+0x16/0x20\nmlx5_eq_async_int+0xf6/0x290 [mlx5_core]\nnotifier_call_chain+0x35/0xb0\natomic_notifier_call_chain+0x16/0x20\nirq_int_handler+0x19/0x30 [mlx5_core]\n__handle_irq_event_percpu+0x4b/0x160\nhandle_irq_event+0x2e/0x80\nhandle_edge_irq+0x98/0x230\n__common_interrupt+0x3b/0xa0\ncommon_interrupt+0x7b/0xa0\n\u0026lt;/IRQ\u0026gt;\n\u0026lt;TASK\u0026gt;\nasm_common_interrupt+0x22/0x40(CVE-2024-38555)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrivers/perf: hisi_pcie: Fix out-of-bound access when valid event group\r\n\r\nThe perf tool allows users to create event groups through following\ncmd [1], but the driver does not check whether the array index is out of\nbounds when writing data to the event_group array. If the number of events\nin an event_group is greater than HISI_PCIE_MAX_COUNTERS, the memory write\noverflow of event_group array occurs.\r\n\r\nAdd array index check to fix the possible array out of bounds violation,\nand return directly when write new events are written to array bounds.\r\n\r\nThere are 9 different events in an event_group.\n[1] perf stat -e \u0026apos;{pmu/event1/, ... ,pmu/event9/}\u0026apos;(CVE-2024-38569)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nRDMA/hns: Fix deadlock on SRQ async events.\r\n\r\nxa_lock for SRQ table may be required in AEQ. Use xa_store_irq()/\nxa_erase_irq() to avoid deadlock.(CVE-2024-38591)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nring-buffer: Fix a race between readers and resize checks\r\n\r\nThe reader code in rb_get_reader_page() swaps a new reader page into the\nring buffer by doing cmpxchg on old-\u0026gt;list.prev-\u0026gt;next to point it to the\nnew page. Following that, if the operation is successful,\nold-\u0026gt;list.next-\u0026gt;prev gets updated too. This means the underlying\ndoubly-linked list is temporarily inconsistent, page-\u0026gt;prev-\u0026gt;next or\npage-\u0026gt;next-\u0026gt;prev might not be equal back to page for some page in the\nring buffer.\r\n\r\nThe resize operation in ring_buffer_resize() can be invoked in parallel.\nIt calls rb_check_pages() which can detect the described inconsistency\nand stop further tracing:\r\n\r\n[  190.271762] ------------[ cut here ]------------\n[  190.271771] WARNING: CPU: 1 PID: 6186 at kernel/trace/ring_buffer.c:1467 rb_check_pages.isra.0+0x6a/0xa0\n[  190.271789] Modules linked in: [...]\n[  190.271991] Unloaded tainted modules: intel_uncore_frequency(E):1 skx_edac(E):1\n[  190.272002] CPU: 1 PID: 6186 Comm: cmd.sh Kdump: loaded Tainted: G            E      6.9.0-rc6-default #5 158d3e1e6d0b091c34c3b96bfd99a1c58306d79f\n[  190.272011] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552c-rebuilt.opensuse.org 04/01/2014\n[  190.272015] RIP: 0010:rb_check_pages.isra.0+0x6a/0xa0\n[  190.272023] Code: [...]\n[  190.272028] RSP: 0018:ffff9c37463abb70 EFLAGS: 00010206\n[  190.272034] RAX: ffff8eba04b6cb80 RBX: 0000000000000007 RCX: ffff8eba01f13d80\n[  190.272038] RDX: ffff8eba01f130c0 RSI: ffff8eba04b6cd00 RDI: ffff8eba0004c700\n[  190.272042] RBP: ffff8eba0004c700 R08: 0000000000010002 R09: 0000000000000000\n[  190.272045] R10: 00000000ffff7f52 R11: ffff8eba7f600000 R12: ffff8eba0004c720\n[  190.272049] R13: ffff8eba00223a00 R14: 0000000000000008 R15: ffff8eba067a8000\n[  190.272053] FS:  00007f1bd64752c0(0000) GS:ffff8eba7f680000(0000) knlGS:0000000000000000\n[  190.272057] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  190.272061] CR2: 00007f1bd6662590 CR3: 000000010291e001 CR4: 0000000000370ef0\n[  190.272070] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[  190.272073] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[  190.272077] Call Trace:\n[  190.272098]  \u0026lt;TASK\u0026gt;\n[  190.272189]  ring_buffer_resize+0x2ab/0x460\n[  190.272199]  __tracing_resize_ring_buffer.part.0+0x23/0xa0\n[  190.272206]  tracing_resize_ring_buffer+0x65/0x90\n[  190.272216]  tracing_entries_write+0x74/0xc0\n[  190.272225]  vfs_write+0xf5/0x420\n[  190.272248]  ksys_write+0x67/0xe0\n[  190.272256]  do_syscall_64+0x82/0x170\n[  190.272363]  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[  190.272373] RIP: 0033:0x7f1bd657d263\n[  190.272381] Code: [...]\n[  190.272385] RSP: 002b:00007ffe72b643f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\n[  190.272391] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f1bd657d263\n[  190.272395] RDX: 0000000000000002 RSI: 0000555a6eb538e0 RDI: 0000000000000001\n[  190.272398] RBP: 0000555a6eb538e0 R08: 000000000000000a R09: 0000000000000000\n[  190.272401] R10: 0000555a6eb55190 R11: 0000000000000246 R12: 00007f1bd6662500\n[  190.272404] R13: 0000000000000002 R14: 00007f1bd6667c00 R15: 0000000000000002\n[  190.272412]  \u0026lt;/TASK\u0026gt;\n[  190.272414] ---[ end trace 0000000000000000 ]---\r\n\r\nNote that ring_buffer_resize() calls rb_check_pages() only if the parent\ntrace_buffer has recording disabled. Recent commit d78ab792705c\n(\u0026quot;tracing: Stop current tracer when resizing buffer\u0026quot;) causes that it is\nnow always the case which makes it more likely to experience this issue.\r\n\r\nThe window to hit this race is nonetheless very small. To help\nreproducing it, one can add a delay loop in rb_get_reader_page():\r\n\r\n ret = rb_head_page_replace(reader, cpu_buffer-\u0026gt;reader_page);\n if (!ret)\n \tgoto spin;\n for (unsigned i = 0; i \u0026lt; 1U \u0026lt;\u0026lt; 26; i++)  /* inserted delay loop */\n \t__asm__ __volatile__ (\u0026quot;\u0026quot; : : : \u0026quot;memory\u0026quot;);\n rb_list_head(reader-\u0026gt;list.next)-\u0026gt;prev = \u0026amp;cpu_buffer-\u0026gt;reader_page-\u0026gt;list;\r\n\r\n.. \n---truncated---(CVE-2024-38601)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nserial: max3100: Lock port-\u0026gt;lock when calling uart_handle_cts_change()\r\n\r\nuart_handle_cts_change() has to be called with port lock taken,\nSince we run it in a separate work, the lock may not be taken at\nthe time of running. Make sure that it\u0026apos;s taken by explicitly doing\nthat. Without it we got a splat:\r\n\r\n  WARNING: CPU: 0 PID: 10 at drivers/tty/serial/serial_core.c:3491 uart_handle_cts_change+0xa6/0xb0\n  ...\n  Workqueue: max3100-0 max3100_work [max3100]\n  RIP: 0010:uart_handle_cts_change+0xa6/0xb0\n  ...\n   max3100_handlerx+0xc5/0x110 [max3100]\n   max3100_work+0x12a/0x340 [max3100](CVE-2024-38634)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbpf: Allow delete from sockmap/sockhash only if update is allowed\r\n\r\nWe have seen an influx of syzkaller reports where a BPF program attached to\na tracepoint triggers a locking rule violation by performing a map_delete\non a sockmap/sockhash.\r\n\r\nWe don\u0026apos;t intend to support this artificial use scenario. Extend the\nexisting verifier allowed-program-type check for updating sockmap/sockhash\nto also cover deleting from a map.\r\n\r\nFrom now on only BPF programs which were previously allowed to update\nsockmap/sockhash can delete from these map types.(CVE-2024-38662)",
  "id": "OESA-2024-1768",
  "modified": "2026-08-06T11:07:14Z",
  "published": "2024-06-28T11:07:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1768"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47381"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47427"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47469"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-39180"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52696"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52791"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52853"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26592"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26852"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26921"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26935"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26988"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27032"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27038"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27047"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27052"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27053"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27417"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-31076"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35811"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35817"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35830"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35947"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36969"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36978"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38538"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38545"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38549"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38555"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38569"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38591"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38601"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38634"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38662"
    }
  ],
  "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-47381",
    "CVE-2021-47427",
    "CVE-2021-47469",
    "CVE-2023-39180",
    "CVE-2023-52696",
    "CVE-2023-52791",
    "CVE-2023-52853",
    "CVE-2024-26592",
    "CVE-2024-26852",
    "CVE-2024-26921",
    "CVE-2024-26935",
    "CVE-2024-26988",
    "CVE-2024-27032",
    "CVE-2024-27038",
    "CVE-2024-27047",
    "CVE-2024-27052",
    "CVE-2024-27053",
    "CVE-2024-27417",
    "CVE-2024-31076",
    "CVE-2024-35811",
    "CVE-2024-35817",
    "CVE-2024-35830",
    "CVE-2024-35947",
    "CVE-2024-36969",
    "CVE-2024-36978",
    "CVE-2024-38538",
    "CVE-2024-38545",
    "CVE-2024-38549",
    "CVE-2024-38555",
    "CVE-2024-38569",
    "CVE-2024-38591",
    "CVE-2024-38601",
    "CVE-2024-38634",
    "CVE-2024-38662"
  ]
}

SSA-613116

Vulnerability from csaf_siemens - Published: 2025-08-12 00:00 - Updated: 2026-02-24 00:00

Summary

SSA-613116: Multiple Vulnerabilities in Third-Party Components in SINEC OS before V3.1

Scope

381 vulnerabilities in this advisory, including CVE-2023-52853.

CVE-2023-52853

Known not affected: 3 products

Open the full advisory

SUSE-SU-2024:2008-1

Vulnerability from csaf_suse - Published: 2024-06-12 11:33 - Updated: 2024-06-12 11:33

Summary

Security update for the Linux Kernel

Severity

Important

Scope

561 vulnerabilities in this advisory, including CVE-2023-52853.

CVE-2023-52853

4.7 (Medium)


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

Recommended: 36 products

Open the full advisory

SUSE-SU-2024:2011-1

Vulnerability from csaf_suse - Published: 2024-06-12 16:39 - Updated: 2024-06-12 16:39

Summary

Security update for the Linux Kernel

Severity

Important

Scope

308 vulnerabilities in this advisory, including CVE-2023-52853.

CVE-2023-52853

4.7 (Medium)


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

Recommended: 6 products

Open the full advisory

SUSE-SU-2024:2019-1

Vulnerability from csaf_suse - Published: 2024-06-13 10:40 - Updated: 2024-06-13 10:40

Summary

Security update for the Linux Kernel

Severity

Important

Scope

541 vulnerabilities in this advisory, including CVE-2023-52853.

CVE-2023-52853

4.7 (Medium)


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

Recommended: 35 products

Open the full advisory

SUSE-SU-2024:2189-1

Vulnerability from csaf_suse - Published: 2024-06-25 06:34 - Updated: 2024-06-25 06:34

Summary

Security update for the Linux Kernel

Severity

Important

Scope

320 vulnerabilities in this advisory, including CVE-2023-52853.

CVE-2023-52853

4.7 (Medium)


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

Recommended: 148 products

Open the full advisory

SUSE-SU-2024:2190-1

Vulnerability from csaf_suse - Published: 2024-06-25 08:50 - Updated: 2024-06-25 08:50

Summary

Security update for the Linux Kernel

Severity

Important

Scope

557 vulnerabilities in this advisory, including CVE-2023-52853.

CVE-2023-52853

4.7 (Medium)


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

Recommended: 186 products

Open the full advisory

SUSE-SU-2024:2571-1

Vulnerability from csaf_suse - Published: 2024-07-22 10:34 - Updated: 2024-07-22 10:34

Summary

Security update for the Linux Kernel

Severity

Important

Scope

285 vulnerabilities in this advisory, including CVE-2023-52853.

CVE-2023-52853

4.7 (Medium)


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

Recommended: 181 products

Open the full advisory

SUSE-SU-2024:2896-1

Vulnerability from csaf_suse - Published: 2024-08-13 14:09 - Updated: 2024-08-13 14:09

Summary

Security update for the Linux Kernel

Severity

Important

Scope

402 vulnerabilities in this advisory, including CVE-2023-52853.

CVE-2023-52853

4.7 (Medium)


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

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

Detection rules are retrieved from Rulezet.

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

Related by attack behaviour

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

Action not permitted

CVE-2023-52853 (GCVE-0-2023-52853)

OESA-2024-1767 (CVE-2021-47231)

OESA-2024-1768 (CVE-2021-47381)

Tags

Sightings

Nomenclature

Related by attack behaviour